데이터베이스 스키마와 애플리케이션 타입 정의가 어긋나는 순간, 버그는 조용히 시작됩니다. VARCHAR(255) NULL 로 선언된 컬럼을 코드에서 string 으로 받아 두면 실제 데이터가 null 로 들어오는 날 런타임 오류가 납니다. 이 도구는 CREATE TABLE 문을 그대로 붙여넣기만 하면 컬럼 타입, NULL 허용 여부, ENUM 값 목록, 기본값 주석까지 읽어 TypeScript 인터페이스·Zod 스키마·Pydantic 모델·JSON Schema로 변환합니다.
MySQL, PostgreSQL, MariaDB, SQL Server의 DDL 문법 차이를 함께 처리합니다. 백틱(` `)·큰따옴표·대괄호로 감싼 식별자, schema.table 형태의 수식된 테이블명, DOUBLE PRECISION 이나 TIMESTAMP WITH TIME ZONE 같은 여러 단어 타입, PostgreSQL의 배열 타입(TEXT[]), 테이블 레벨 PRIMARY KEY (id)` 제약조건까지 인식합니다. 변환은 전부 브라우저 안에서 일어나므로 사내 운영 DB 스키마를 붙여넣어도 네트워크로 나가지 않습니다.
사용 방법
- DDL 붙여넣기 — 왼쪽 입력창에
CREATE TABLE문을 붙여넣습니다. 여러 테이블을 한 번에 넣어도 되고,-- 주석이나/* 블록 주석 */,UNIQUE KEY같은 인덱스 정의가 섞여 있어도 자동으로 걸러냅니다. 감지된 테이블과 컬럼 수는 입력창 아래에 표시됩니다. - 출력 형식 선택 — TypeScript 인터페이스, Zod 스키마(런타임 검증용), Pydantic 모델(FastAPI·Python 백엔드용), JSON Schema(OpenAPI 문서용), JSON 샘플(목데이터·API 응답 예시용) 중에서 고릅니다. 형식을 바꿔도 입력은 유지됩니다.
- 네이밍·NULL 처리 옵션 조정 —
snake_case컬럼명을 프런트엔드 관례인 camelCase로 바꾸려면 컬럼명을 camelCase로를 켭니다. NULL 허용 컬럼을field?: string으로 받을지field: string | null로 받을지는 NULL 허용 컬럼을 옵셔널(?)로 옵션으로 결정합니다. API 응답 타입이라면 후자가, 폼 입력 타입이라면 전자가 보통 더 적합합니다. - 복사하거나 파일로 저장 — 오른쪽 상단의 복사 버튼으로 클립보드에 담거나, 다운로드 버튼으로
.ts·.py·.json파일을 내려받습니다. 파일명은 첫 번째 테이블 이름을 따릅니다.
자주 묻는 질문
MySQL과 PostgreSQL DDL을 모두 인식하나요?
네. 백틱으로 감싼 MySQL 식별자, 큰따옴표를 쓰는 PostgreSQL 식별자, 대괄호를 쓰는 SQL Server 식별자를 모두 처리합니다.
타입 매핑도 방언별로 맞춰 두었습니다. MySQL의 TINYINT(1) 은 관례상 불리언이므로 boolean 으로, ENUM('a','b') 은 "a" | "b" 리터럴 유니온으로 변환합니다. PostgreSQL의 SERIAL·BIGSERIAL 은 자동 증가 컬럼이므로 NOT NULL로 간주하고, TEXT[] 같은 배열 타입은 string[] 으로, JSONB 는 Record<string, unknown> 으로 바꿉니다.
DATE·TIMESTAMP 컬럼이 Date로 나오는데 문자열로 받고 싶습니다.
TypeScript 출력에서는 시간 컬럼을 Date 로 매핑합니다. Prisma나 TypeORM처럼 드라이버가 Date 객체를 돌려주는 환경을 기준으로 삼았기 때문입니다.
REST API의 JSON 응답 타입을 만드는 중이라면 Date 대신 string 이 맞습니다. 이 경우 JSON Schema 출력을 쓰면 { "type": "string", "format": "date-time" } 으로 나오고, Zod 출력의 z.coerce.date() 는 ISO 문자열을 받아 Date로 변환해 주므로 그대로 써도 안전합니다.
입력한 스키마가 서버로 전송되나요?
전송되지 않습니다. 파싱과 코드 생성 전부가 페이지를 연 브라우저의 자바스크립트로만 실행됩니다.
이 사이트는 정적 파일로만 배포되어 있어 입력을 받을 백엔드 자체가 존재하지 않습니다. 개발자 도구의 네트워크 탭을 열어 두고 변환해 보면 어떤 요청도 발생하지 않는 것을 확인할 수 있습니다. 사내 운영 DB의 스키마나 고객 정보가 들어간 컬럼명을 붙여넣어도 안전합니다.
생성된 타입을 그대로 프로덕션에 써도 되나요?
출발점으로는 충분하지만 한 번 훑어보길 권합니다.
특히 DECIMAL·NUMERIC 컬럼은 TypeScript에서 number 로 나오는데, 금액처럼 정밀도가 중요한 값은 JavaScript의 배정밀도 부동소수점으로 다루면 오차가 생길 수 있습니다. 이런 컬럼은 string 으로 받아 decimal 라이브러리로 계산하는 편이 안전합니다. Pydantic 출력에서는 이미 Decimal 로 매핑해 두었습니다.
알아두면 좋은 개념
DDL과 타입 시스템의 간극
SQL의 타입 시스템과 TypeScript·Python의 타입 시스템은 표현력이 다릅니다. SQL은 VARCHAR(80) 처럼 길이 제약을 타입에 담지만 TypeScript의 string 에는 길이 개념이 없습니다. 반대로 TypeScript의 유니온 타입은 SQL의 ENUM 으로만 근사할 수 있습니다.
이 간극 때문에 생성된 타입은 '컴파일 타임 힌트'일 뿐 런타임 보증이 아닙니다. 실제 검증까지 필요하다면 Zod 출력을 사용해 API 경계에서 schema.parse(data) 로 확인하세요. 길이 제약(z.string().max(80))과 정수 여부(z.number().int())까지 함께 생성됩니다.
NULL, undefined, 그리고 옵셔널의 차이
SQL의 NULL 은 '값이 없음'을 뜻하는 명시적 상태입니다. TypeScript에는 이에 대응하는 값이 null 과 undefined 두 가지 있고, 둘은 다릅니다. field?: string 은 키 자체가 없을 수 있다는 뜻이고, field: string | null 은 키는 있되 값이 null이라는 뜻입니다.
JSON 직렬화 관점에서 보면 차이가 분명해집니다. JSON.stringify 는 undefined 인 속성을 아예 빼 버리지만 null 은 그대로 남깁니다. DB에서 읽어 온 행을 그대로 응답으로 내보내는 API라면 | null 이 실제 동작과 일치하고, 부분 업데이트(PATCH) 요청의 본문 타입이라면 ? 가 더 맞습니다.
스키마를 단일 원천(Single Source of Truth)으로 두기
타입을 손으로 관리하면 마이그레이션이 쌓일수록 코드와 DB가 어긋납니다. 실무에서는 DB 스키마를 단일 원천으로 삼고, 타입은 거기서 파생시키는 방향을 권합니다.
규모가 커지면 Prisma, Drizzle, sqlc, SQLAlchemy 같은 도구를 CI에 붙여 자동 생성하는 편이 낫습니다. 다만 그런 파이프라인을 갖추기 전이나, 다른 팀에게서 DDL만 전달받았을 때, 또는 레거시 테이블 하나를 급히 붙여야 할 때는 이 도구처럼 붙여넣고 바로 결과를 얻는 방식이 훨씬 빠릅니다.