SQL to ERD: 운영 DB에서 다이어그램 뽑는 법

2026년 8월 12일

운영 중인 DB가 있다면 ERD를 처음부터 그릴 이유가 없습니다. 스키마는 이미 DB 안에 있으니, DDL로 꺼내서 도구에 넣으면 다이어그램은 자동으로 만들어집니다.

이 글에서는 SQL에서 ERD를 뽑는 방법 세 가지를 비교하고, 쇼핑몰 DB 하나를 잡아 DDL 추출부터 다이어그램 완성까지 실제 화면으로 확인합니다.

방법은 세 가지, 상황에 따라 고르면 됩니다

SQL에서 ERD를 만드는 경로는 크게 세 갈래입니다.

방법	잘 맞는 상황	준비물
DB 툴 내장 기능 (MySQL Workbench, DBeaver)	이미 쓰는 툴에서 혼자 구조를 확인할 때	DB 접속
코드로 생성 (Mermaid 등 텍스트 다이어그램)	문서 안에 텍스트로 넣고 git으로 관리할 때	변환 스크립트
브라우저 툴에 DDL 붙여넣기	편집하고, 공유하고, 명세서까지 이어갈 때	DDL 파일

DB 툴 내장 기능: Workbench와 DBeaver

이미 깔려 있는 툴이니 추가 설치가 없다는 게 가장 큰 장점입니다.

MySQL Workbench에서는 Database 메뉴 → Reverse Engineer를 선택하고 접속 정보와 스키마를 고르면 EER 다이어그램이 만들어집니다. EER은 Enhanced ER의 약자로, Workbench가 부르는 ER 다이어그램의 확장 명칭이라고 이해하면 됩니다.

DBeaver는 더 간단합니다. 접속한 데이터베이스에서 스키마나 테이블을 열면 ER Diagram 탭이 이미 있어서 클릭 한 번으로 관계도가 보입니다. 특정 테이블 몇 개만 모아 보는 커스텀 다이어그램도 만들 수 있습니다.

다만 이 그림은 DB에 접속할 수 있는 사람만 볼 수 있습니다. 접속 권한이 없는 기획자나 신입에게 보여주려면 결국 이미지로 내보내서 전달하게 되고, 스키마가 바뀔 때마다 같은 일이 반복됩니다. 다이어그램을 편집해 설계안을 만들거나 명세서 문서로 잇는 것도 이 방식으로는 어렵습니다.

코드로 생성: Mermaid 같은 텍스트 다이어그램

DDL을 Mermaid 문법으로 변환하는 스크립트를 쓰거나 AI에게 변환을 맡기는 방식입니다. 결과물이 텍스트라 마크다운 문서에 그대로 들어가고, git diff로 변경 이력이 보인다는 매력이 있습니다. README나 위키에 구조도를 박제하는 용도로는 이만한 게 없습니다.

대신 결과물이 읽기 전용에 가깝습니다. 배치를 다듬거나 컬럼을 고치는 작업은 코드를 다시 만지는 일이 되고, 자료형·인덱스·코멘트 같은 세부 정보는 문법의 표현력 한계로 상당 부분 생략됩니다.

브라우저 툴에 붙여넣기

DDL 파일 하나만 있으면 되고, DB 접속도 설치도 필요 없습니다. 만들어진 다이어그램을 그 자리에서 편집하고, 링크로 공유하고, 명세서까지 이어갈 수 있습니다. 위의 두 방식이 구조를 보는 데서 끝난다면, 이 방식은 여기서부터 작업이 이어집니다.

이 글의 실습은 이 방법으로 진행합니다.

1단계: DB에서 DDL 뽑기

어느 방법을 쓰든 시작은 DDL입니다. DBMS별로 한 줄이면 됩니다.

# MySQL / MariaDB — 데이터 없이 스키마만
mysqldump -u USER -p --no-data mydb > schema.sql

# PostgreSQL — 반드시 plain(텍스트) 형식으로
pg_dump -U USER --schema-only -Fp mydb > schema.sql

--no-data(PostgreSQL은 --schema-only)가 핵심입니다. ERD에 필요한 건 CREATE TABLE 문뿐이라 데이터까지 뽑을 이유가 없고, 실데이터가 파일로 나가지 않으니 보안 검토에서도 걸릴 게 없습니다. 수 GB짜리 DB라도 스키마만 뽑으면 수십 KB 텍스트 파일입니다.

PostgreSQL은 한 가지 더 있습니다. 형식이 plain(-Fp)이어야 합니다. 백업용으로 흔히 쓰는 custom 형식(-Fc)은 바이너리 아카이브라, 열어 보면 텍스트가 아니어서 어떤 도구에도 붙여넣을 수 없습니다. 이미 custom 형식 백업만 있다면 pg_restore로 텍스트로 풀면 됩니다.

# custom 형식 백업(-Fc)을 plain SQL로 변환
pg_restore --schema-only -f schema.sql backup.dump

특정 테이블만 필요하면 테이블 이름을 뒤에 붙이면 됩니다.

# 주문 관련 테이블만
mysqldump -u USER -p --no-data mydb orders order_items payments > orders.sql

GUI가 편하면 그쪽도 됩니다. DBeaver에서는 테이블을 선택하고 우클릭 → DDL 생성을 누르면 CREATE TABLE 문이 바로 복사되고, Oracle은 SQL Developer의 데이터베이스 내보내기(DDL만 체크)에서, SQL Server는 SSMS의 태스크 → 스크립트 생성 기능에서 같은 결과를 얻습니다.

이미 있는 파일을 써도 됩니다. 마이그레이션 폴더의 SQL, 동료가 넘겨준 백업 덤프, 위키에 붙어 있던 CREATE TABLE 문까지, 출처가 어디든 DDL이면 재료가 됩니다. 실데이터가 섞인 전체 덤프를 그대로 넣어도 도구가 스키마 문장만 골라 읽는 경우가 많지만, 파일이 무겁고 민감할 수 있으니 처음부터 스키마만 뽑는 습관이 낫습니다.

2단계: 붙여넣고 가져오기

쇼핑몰 DB로 실제로 해 보겠습니다. 회원, 카테고리, 상품, 주문, 주문 상세, 결제까지 여섯 테이블짜리 전형적인 커머스 뼈대입니다. 모두 작성하기엔 길어서 두 테이블만 옮기면 이런 모양입니다.

CREATE TABLE orders (
  id           BIGINT AUTO_INCREMENT PRIMARY KEY,
  member_id    BIGINT NOT NULL COMMENT '주문 회원',
  status       VARCHAR(20)   NOT NULL DEFAULT 'PAID' COMMENT '주문 상태',
  total_amount DECIMAL(12,2) NOT NULL COMMENT '주문 총액',
  ordered_at   DATETIME      NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '주문 시각',
  CONSTRAINT fk_orders_member FOREIGN KEY (member_id) REFERENCES members (id)
) COMMENT='주문';

CREATE TABLE order_items (
  id         BIGINT AUTO_INCREMENT PRIMARY KEY,
  order_id   BIGINT NOT NULL COMMENT '소속 주문',
  product_id BIGINT NOT NULL COMMENT '주문 상품',
  quantity   INT NOT NULL COMMENT '수량',
  unit_price DECIMAL(12,2) NOT NULL COMMENT '주문 시점 단가',
  CONSTRAINT fk_order_items_order   FOREIGN KEY (order_id)   REFERENCES orders (id),
  CONSTRAINT fk_order_items_product FOREIGN KEY (product_id) REFERENCES products (id)
) COMMENT='주문 상세';

WorksCove ERD에서 프로젝트 가져오기 → SQL 스키마 가져오기를 열고, 파일을 업로드하거나 텍스트를 그대로 붙여넣습니다.

SQL 스키마 가져오기 모달에 쇼핑몰 DDL을 붙여넣은 화면 (WorksCove ERD)

가져오기 모드가 두 가지인 점은 알아두면 좋습니다. 기존 테이블을 유지하고 추가하는 모드는 작업 중인 다이어그램에 테이블을 보태고, 삭제 후 가져오기는 처음부터 새로 만듭니다. 처음이라면 어느 쪽이든 결과는 같습니다.

가져오기를 누르면 여섯 테이블이 관계선까지 연결된 채 캔버스에 올라옵니다. 배치가 흩어져 있으면 자동 정렬을 쓰면 되는데, 방식이 다섯 가지(Grid, Force-directed, Hierarchical, Circular, Orthogonal)라 스키마 성격에 맞춰 고를 수 있습니다. FK로 위아래 흐름이 있는 업무 스키마라면 Hierarchical이 대체로 가장 읽기 좋습니다. 참조하는 테이블이 위, 참조받는 테이블이 아래로 계단처럼 배치되기 때문입니다.

DDL에서 자동 생성된 쇼핑몰 ERD — 6개 테이블과 FK 관계선 (WorksCove ERD)

여기까지 손으로 그린 건 없습니다. 컬럼도, 자료형도, FK 연결선도, 한글 코멘트도 전부 DDL에서 왔습니다. 실제로 걸리는 시간은 DDL을 뽑는 시간이 거의 전부입니다. 관계선 끝의 까마귀발 기호를 읽는 법은 ERD 표기법 총정리에 따로 있습니다.

덤으로 얻는 것도 있습니다. DDL의 COMMENT가 다이어그램의 컬럼 설명으로 들어와 있어서, Physical 뷰(물리명)와 Logical 뷰(논리명)를 전환하며 볼 수 있습니다. 개발자는 member_id로 보고, 기획자에게는 "주문 회원"으로 보여주는 식입니다. 운영 DB에 코멘트를 꾸준히 달아 온 팀이라면 그 자산이 여기서 빛을 봅니다.

DBMS 종류만은 꼭 맞춰 주세요

한 가지만 조심하면 됩니다. 가져오기 화면에서 프로젝트의 DBMS 타입이 실제 DDL과 일치해야 합니다.

같은 CREATE TABLE이어도 DBMS마다 문법이 조금씩 다르기 때문입니다. 파서 네 종류를 만들면서 확인한 대표적인 차이를 꼽으면 이렇습니다.

컬럼 코멘트의 위치가 다릅니다. MySQL은 컬럼 정의 안에 COMMENT '설명'을 쓰지만, PostgreSQL은 CREATE TABLE이 끝난 뒤 COMMENT ON COLUMN ... 문이 따로 나옵니다. MySQL 기준으로만 읽는 파서에 pg_dump 결과를 넣으면 테이블은 만들어지는데 코멘트는 흔적도 없이 사라집니다.
자료형 이름이 다릅니다. MySQL의 AUTO_INCREMENT는 PostgreSQL에서 bigserial 또는 IDENTITY 구문이 되고, Oracle 덤프에는 NUMBER(10,0)처럼 다른 체계의 타입과 TABLESPACE 같은 스토리지 설정이 함께 붙어 나옵니다.
덤프에 스키마 밖 문장이 섞여 나옵니다. 실제 mysqldump 파일에는 SET 문과 잠금 관련 문장이, pg_dump에는 소유자·권한 설정이 함께 들어 있습니다. 파서가 이런 문장을 자연스럽게 건너뛰지 못하면 첫 줄부터 오류를 만나게 됩니다.

그래서 도구가 내 DBMS의 덤프를 곧이곧대로 읽을 수 있는지가 생각보다 중요합니다. WorksCove ERD는 MySQL/MariaDB, PostgreSQL, Oracle, SQL Server 네 종류의 DDL을 각각의 문법대로 파싱하고, 반대로 내보낼 때도 같은 네 종류를 지원합니다. MySQL로 들어온 스키마를 PostgreSQL DDL로 꺼내는 DBMS 간 변환도 되는데, 이때는 자료형 대응까지 문법에 맞춰 바뀝니다.

파일 없이 DB에 직접 연결하기

DDL 파일을 만드는 단계도 생략할 수 있습니다. 리버스 엔지니어링, 그러니까 DB에 직접 연결해 스키마를 읽어오는 기능을 쓰면 접속 정보만 넣고 테이블을 골라 가져오면 끝입니다. WorksCove ERD의 원격 데이터베이스 가져오기는 네 DBMS 모두 지원하고, 외부 접속이 막힌 DB를 위해 SSH 터널을 거치는 연결도 됩니다.

주기적으로 스키마가 바뀌는 DB를 추적할 때 이 방식이 특히 편합니다. 바뀔 때마다 덤프 파일을 만들어 옮기는 대신, 다시 연결해서 가져오면 끝이기 때문입니다.

운영 DB 계정을 외부 도구에 입력하는 게 마음에 걸린다면 무리할 필요는 없습니다. 스키마 조회 권한만 있는 읽기 전용 계정을 따로 만들어 쓰거나, 처음 방식대로 DDL 파일을 뽑아 붙여넣으면 같은 결과를 얻습니다.

다이어그램이 생긴 다음에 할 일

레거시 DB를 인수인계받았을 때를 떠올려 보면, 다이어그램이 생기는 건 파악의 끝이 아니라 시작입니다. ERD가 만들어지고 나면 같은 데이터로 할 수 있는 일이 이어집니다.

테이블 명세서 뽑기. 스키마가 이미 도구 안에 있으니 컬럼 정의표는 문서 탭에서 바로 나옵니다. 검수나 인수인계 문서로 제출할 명세서를 따로 만들 필요가 없습니다. 만드는 과정과 형식은 테이블 명세서 작성법에서 확인할 수 있습니다.

설계 검증 돌리기. PK 누락, 순환 참조, FK 인덱스 같은 항목을 자동 점검할 수 있습니다. 특히 오래 운영된 DB일수록 "이거 왜 이렇게 돼 있지?" 싶은 지점이 검증 목록으로 정리되어 나오는 게 유용합니다. AI가 만든 스키마를 같은 방식으로 검증하는 사례를 AI로 ERD 그리기에서 다룹니다.

팀에 공유하기. 읽기 전용 공유 링크를 만들면 DB 접속 권한이 없는 동료도 구조를 볼 수 있습니다. "그림 좀 최신으로 다시 뽑아줘"라는 요청과, 그때마다 이미지를 다시 내보내는 일이 함께 사라집니다.

변경을 계속 반영하기. 스키마가 바뀌면 바뀐 DDL을 다시 가져오거나 DB에 다시 연결하면 됩니다. 버전을 남겨 두면 릴리스 사이에 구조가 어떻게 변했는지 비교할 수도 있습니다.

정리하면 흐름은 세 단계입니다. DDL을 뽑고, 붙여넣고, 정렬한다. 오늘 옆에 있는 그 DB로 한번 해 보세요. 생각보다 빨리 끝나서 허무할 수도 있습니다.

자주 묻는 질문

데이터도 같이 뽑아야 하나요?

아니요. ERD에 필요한 건 테이블 구조뿐이라 스키마만 있으면 됩니다. mysqldump라면 --no-data 옵션으로 CREATE TABLE 문만 내보내면 되고, 파일도 가벼워지고 데이터가 밖으로 나가지 않아 보안 면에서도 안전합니다.

DDL 파일 없이 DB에 직접 연결해서 가져올 수도 있나요?

리버스 엔지니어링을 지원하는 도구라면 가능합니다. WorksCove ERD는 MySQL/MariaDB, PostgreSQL, Oracle, SQL Server에 직접 연결해 스키마를 읽어올 수 있습니다. 다만 운영 DB 계정을 외부 도구에 입력하는 게 부담스럽다면, DDL 파일을 뽑아 붙여넣는 쪽이 마음 편합니다.

테이블이 아주 많은데 전부 올라가나요?

도구마다 무료 한도가 다르니 그 점만 확인하면 됩니다. WorksCove ERD 무료 플랜은 프로젝트당 40테이블까지라, 초기 서비스 규모라면 대체로 들어갑니다. 스키마가 그보다 크면 핵심 도메인의 DDL만 잘라서 넣는 것도 실용적인 방법입니다.

다이어그램 그림만 있고 DDL이 없으면 어떻게 하나요?

그림에서 스키마를 자동으로 복원하는 표준적인 방법은 없습니다. 이때는 그림을 보면서 AI에게 DDL 작성을 맡기는 게 타이핑을 크게 줄여줍니다. 받은 DDL을 붙여넣으면 이 글의 흐름 그대로 진행할 수 있습니다.