이 도구가 해결하는 일

SI 프로젝트의 영원한 숙제 — 테이블 정의서(엑셀)와 실제 DDL이 따로 놉니다. 컬럼 하나 추가될 때마다 두 곳을 고쳐야 하고, 어느 쪽이 최신인지 아무도 모르게 됩니다. 이 도구는 DDL → 정의서, 정의서 → DDL 양방향 변환으로 한쪽만 진실로 두고 다른 쪽을 생성하는 흐름을 만들어 줍니다.

양방향 — 무엇이 오가나

방언(Oracle·PostgreSQL·MySQL) 차이는 주로 코멘트 문법에 반영됩니다 — 컬럼 코멘트를 인라인으로 쓰는 방언과 별도 COMMENT ON 문으로 쓰는 방언을 구분해 출력합니다.

실무 시나리오

• 산출물 마감 — 개발 막바지에 실제 스키마(DDL)를 덤프해 정의서로 변환하면, 문서가 현실을 따라갑니다. 반대 방향으로 손으로 맞추는 것보다 빠르고 정확합니다.
• 설계 리뷰 준비 — 설계 단계에 엑셀로 정리한 정의서를 DDL로 변환해 개발 DB에 바로 만들어 봅니다.
• 인수인계 문서화 — 문서가 없는 레거시 테이블의 DDL을 정의서로 변환해 인수인계 자료 초안을 만듭니다.
• 스키마 비교 준비 — 두 환경의 DDL을 각각 정의서(TSV)로 변환하면 컬럼 단위 비교가 쉬워집니다.

예시

CREATE TABLE users (
  user_id    BIGINT       NOT NULL,
  login_id   VARCHAR(50)  NOT NULL,
  created_at TIMESTAMP    DEFAULT CURRENT_TIMESTAMP
);

→ 정의서(요지)

| 컬럼      | 타입          | NULL | 기본값             |
| user_id   | BIGINT       | N    |                    |
| login_id  | VARCHAR(50)  | N    |                    |
| created_at| TIMESTAMP    | Y    | CURRENT_TIMESTAMP  |

자주 겪는 함정

• 정의서 열 순서 — 엑셀 정의서마다 열 배치가 다릅니다. 변환 전에 도구가 기대하는 열 구성과 맞는지 확인하세요.
• 제약조건의 범위 — 기본키·NOT NULL 수준은 왕복되지만, 복잡한 체크 제약·트리거는 정의서 표에 담기지 않는 정보라 DDL 원본을 별도 보관해야 합니다.
• 타입 방언 차이 — NUMBER(Oracle)와 NUMERIC(표준) 같은 타입명은 그대로 유지됩니다 — 방언 간 이관은 타입 매핑 검토가 따로 필요합니다.
• 어느 쪽이 진실인가 — 도구는 변환만 합니다. "DDL이 진실, 정의서는 생성물" 같은 팀 규칙을 정하는 것이 드리프트를 끝내는 방법입니다.

사용 순서

• ① 방향을 고릅니다 — DDL을 문서로 만들 것인지, 문서를 DDL로 만들 것인지.
• ② 원본을 붙여넣습니다 — DDL은 CREATE TABLE 문 그대로, 정의서는 표(마크다운 또는 엑셀 복사 TSV)로.
• ③ 결과를 확인하고 복사합니다 — 정의서는 엑셀에, DDL은 DB 툴에 바로 붙습니다.

정의서 품질이 곧 소통 품질

테이블 정의서는 개발자끼리의 문서가 아니라 현업·검수·운영이 함께 보는 계약서에 가깝습니다. 컬럼 코멘트가 채워진 DDL에서 생성한 정의서는 "이 컬럼이 무엇인지"가 설명된 문서가 되고, 코멘트 없는 스키마에서 나온 정의서는 이름만 나열된 표가 됩니다 — 변환 결과가 비어 보이면 스키마의 코멘트부터 채우라는 신호로 읽는 것이 맞습니다. 역방향(정의서→DDL)은 그 설명을 COMMENT 문으로 되살려 스키마에 넣어줍니다.

양방향이라 가능한 워크플로

한 방향 변환기는 "문서 만들기"까지만 돕지만, 양방향이면 순환이 만들어집니다: 설계 단계엔 정의서→DDL로 빠르게 실물을 만들고, 개발이 진행되며 스키마가 바뀌면 DDL→정의서로 문서를 재생성합니다. 문서를 고치는 것이 아니라 다시 만들어내는 흐름이 되면, "문서가 낡는" 문제 자체가 사라집니다 — 산출물 마감 주간의 야근을 줄이는 가장 실질적인 방법입니다.

변환 결과를 검수할 때는 컬럼 수·기본키·NOT NULL 세 가지만 원본과 대조해도 큰 사고는 걸러집니다. 나머지 속성은 어긋나도 눈에 띄지만, 이 셋은 조용히 틀린 채 문서로 굳는 항목들입니다.

자주 묻는 질문

여러 테이블을 한 번에 변환할 수 있나요?

CREATE TABLE 문 단위로 처리합니다 — 테이블별로 넣는 것이 결과 확인에 안전합니다.

TSV 출력은 어디에 쓰나요?

복사해서 엑셀에 붙여넣으면 셀 단위로 갈라져 들어갑니다 — 기존 정의서 양식에 옮겨 담기 좋습니다.

스키마 정보가 외부로 나가나요?

아니요. 변환은 브라우저 안에서 끝납니다 — 사내 스키마를 다뤄도 전송이 없습니다.

인덱스도 변환되나요?

중심은 컬럼 정의입니다. 인덱스·파티션 같은 부가 정의는 DDL 원본에서 별도로 관리하세요.

코멘트가 없는 DDL은요?

코멘트 열이 비어 있는 정의서가 나옵니다 — 정의서에 설명을 채운 뒤 역방향 변환하면 COMMENT 문이 생성됩니다.

함께 쓰는 도구

정의서로 만든 테이블에 테스트 데이터를 채우려면 목데이터 생성이 바로 이어집니다. 운영 쿼리 분석은 로그 바인더, 값 목록 조회는 IN절 생성기를 쓰세요.