VS Code에서 ERD 그리기

작성 WorksCove 2026년 8월 31일 업데이트 2026년 9월 4일

편집기에서 코드를 보다가 테이블 구조가 궁금해질 때, 브라우저를 열고 별도 도구에 로그인하는 흐름은 생각보다 번거롭습니다. VS Code에는 ERD를 그리거나 보는 확장이 여러 개 있어서, 창을 옮기지 않고 처리할 수 있는 범위가 꽤 넓습니다.

VS Code ERD 작업에서 전용 편집, 문서용 다이어그램, 자유로운 작도, 접속한 DB의 구조 확인은 서로 다른 확장이 맡습니다. 아래 정보는 2026년 8월 기준이며, 설치할 때는 VS Code 마켓플레이스의 게시자 이름도 함께 확인해야 합니다.

확장을 고르는 기준 세 가지

설치하기 전에 세 가지만 정하면 후보가 금방 줄어듭니다.

저장 파일이 텍스트인가. 팀에서 저장소에 올려 함께 관리할 계획이라면 이게 가장 중요합니다. 텍스트로 저장되는 형식은 변경 내역이 diff로 보이고 코드 리뷰에 올릴 수 있지만, 이미지 파일은 무엇이 바뀌었는지 알 수 없습니다.

DDL을 주고받을 수 있는가. 이미 운영 중인 DB가 있다면 CREATE TABLE 문을 가져와서 그리는 기능이 있는지, 그린 결과를 DDL로 내보낼 수 있는지가 작업량을 좌우합니다. 그림만 나오는 확장이라면 거기서 작업이 멈춥니다.

결과를 어디에 붙일 것인가. README에 넣을 그림, 회의 자료용 이미지, 실제 DB에 적용할 스키마 중 무엇이 목적이냐에 따라 맞는 확장이 다릅니다.

ERD Editor: 편집기 안의 전용 ERD 도구

게시자: dineug

VS Code 안에서 본격적으로 ERD를 그릴 생각이라면 이 확장이 가장 적합합니다. 확장을 설치하고 .erd.json 확장자로 빈 파일을 만들어 열면 전용 편집 화면이 뜹니다.

테이블과 컬럼을 만들고 관계를 연결하는 기본 작업은 물론이고, 관계의 개수도 0 또는 1, 정확히 1, 0 이상, 1 이상 네 가지로 지정할 수 있습니다. 까마귀발 표기에서 쓰는 조합과 같은 체계라, 기호가 낯설다면 ERD 표기법 총정리를 함께 보시면 됩니다.

실무에서 도움이 되는 건 가져오기와 내보내기입니다. SQL DDL을 붙여넣어 다이어그램을 만들 수 있고, 반대로 그린 결과를 DDL로 뽑을 수도 있습니다. DBML이나 GraphQL 스키마에서 가져오는 것도 지원합니다. 운영 DB의 스키마를 한 번 가져와 두면 그 뒤로는 편집기 안에서 구조를 확인할 수 있습니다.

파일이 텍스트 기반이라 저장소에 올려 관리하기도 좋습니다. 브라우저와 IntelliJ에서도 같은 편집기를 쓸 수 있어서, 팀원마다 도구가 달라도 같은 파일을 공유할 수 있습니다.

Mermaid: 문서에 그대로 들어가는 다이어그램

게시자: Matt Bierner (Markdown Preview Mermaid Support)

README나 위키에 구조도를 넣는 게 목적이라면 별도의 ERD 도구가 필요 없습니다. 마크다운 문서에 Mermaid 코드 블록을 적고, 프리뷰 확장을 설치하면 편집기 안에서 바로 렌더링된 그림을 볼 수 있습니다.

erDiagram
  MEMBERS ||--o{ POSTS : "작성"
  POSTS ||--o{ COMMENTS : "댓글"

이 방식의 장점은 결과물이 코드라는 점입니다. git에 그대로 들어가고, 변경 이력이 diff로 남고, GitHub에서도 같은 그림이 그려집니다. 문법과 관계 기호 읽는 법은 Mermaid로 ERD 그리기에 게시판 예제로 정리해 두었습니다.

대신 배치를 직접 조정할 수 없고 자료형이나 인덱스 같은 세부 정보를 담기 어렵습니다. 문서용 요약도로 쓰고, 정밀한 설계는 다른 도구에 맡기는 역할 분담이 잘 맞습니다.

Draw.io Integration: 자유롭게 그려야 할 때

게시자: hediet

draw.io를 VS Code 안에서 그대로 사용하는 확장입니다. .drawio, .dio, .drawio.svg, .drawio.png 파일을 편집기에서 열면 draw.io 편집 화면이 뜹니다. 오프라인 버전이 내장되어 있어 인터넷 연결 없이도 동작합니다.

ERD만이 아니라 시스템 구성도나 흐름도까지 한 저장소에서 같은 도구로 관리하고 싶을 때 잘 맞습니다. Entity Relation 도형 라이브러리를 켜면 까마귀발 커넥터까지 그대로 사용할 수 있는데, 도형을 찾는 방법과 관계선 설정은 draw.io로 ERD 그리는 법에 정리되어 있습니다.

같은 .drawio 파일은 XML로도 열리고, 두 화면이 서로 동기화됩니다. 텍스트로 열어 값을 일괄 수정하고 그림으로 확인하는 작업이 가능합니다. Live Share로 여러 명이 같은 다이어그램을 함께 편집할 수도 있습니다.

MSSQL 확장의 스키마 디자이너: SQL Server를 쓴다면

게시자: Microsoft (MSSQL 확장)

SQL Server를 다루고 있다면 선택지가 하나 더 있습니다. Microsoft의 MSSQL 확장에 스키마 디자이너가 들어와 2026년에 정식 기능이 되었습니다. T-SQL을 직접 쓰지 않고 화면에서 테이블, 외래 키, 기본키, 제약 조건을 만들고 고칠 수 있습니다.

검색, 드래그 앤 드롭, 필터, 확대, 미니맵, 자동 배치를 지원해서 테이블이 많은 스키마에서도 다루기 좋습니다. 변경 내용을 시각적으로 확인하고 스크립트를 생성하는 흐름까지 한 화면에서 이어집니다.

SSMS에서 같은 작업을 하는 방법은 SSMS로 데이터베이스 다이어그램 만들기에 정리해 두었습니다. 편집기에서 끝내고 싶은지, SSMS의 다이어그램 기능을 쓸 것인지에 따라 고르면 됩니다.

Database Client: 접속한 DB의 구조 보기

게시자: cweijan

새로 그리는 게 아니라 이미 있는 DB의 구조를 확인하는 게 목적이라면, DB 클라이언트 확장이 빠릅니다. Database Client는 MySQL, PostgreSQL을 비롯해 여러 데이터베이스에 접속해 SQL 편집기와 데이터 그리드를 제공하고, ER 다이어그램 보기도 함께 지원합니다.

접속 정보만 넣으면 되니 스키마를 파일로 뽑는 단계가 생략됩니다. 다만 확장 안에서 보는 그림이라, 접속 권한이 없는 사람에게 보여줘야 한다면 이미지나 DDL로 꺼내는 단계가 따로 필요합니다.

마켓플레이스에서 확장을 고를 때

마켓플레이스에는 이름이 비슷한 확장이 여럿 올라와 있습니다. 설치 전에 세 가지만 확인하면 실수가 줄어듭니다.

게시자 이름을 봅니다. 같은 기능을 표방하는 확장이 여러 개인 경우가 있어서, 이 글에 적어 둔 게시자와 일치하는지 확인하고 설치하는 편이 안전합니다. 확장 페이지 상단에 게시자 이름이 표시됩니다.

마지막 업데이트 시점을 봅니다. 몇 년째 갱신이 없는 확장은 VS Code 버전이 올라가면서 동작하지 않는 경우가 생깁니다. 다운로드 수나 평점보다 마지막 업데이트 날짜가 더 실용적인 신호입니다.

오프라인에서 동작하는지 확인합니다. 폐쇄망에서 작업하는 환경이라면 외부 통신이 필요한 확장은 쓸 수 없습니다. Draw.io Integration처럼 오프라인 버전을 내장한 확장은 이런 환경에서도 문제없이 동작합니다.

VS Code ERD Editor 사용법: 첫 다이어그램 만들기

설치했다면 실제로 그려 보는 게 빠릅니다. 순서는 이렇습니다.

프로젝트 안에 schema.erd.json 처럼 .erd.json으로 끝나는 빈 파일을 만듭니다.
파일을 열면 텍스트 편집기 대신 ERD 편집 화면이 뜹니다.
테이블을 추가하고 이름을 입력한 뒤, 컬럼과 자료형을 채웁니다. 기본키로 쓸 컬럼에 표시를 해 둡니다.
부모 테이블에서 자식 테이블로 관계를 연결하고, 개수를 지정합니다.
내보내기에서 DDL을 선택하면 CREATE TABLE 문이 나옵니다.

이미 운영 중인 DB가 있다면 3번부터 시작할 필요가 없습니다. DDL을 먼저 가져와서 전체 구조를 올린 다음, 새로 추가할 테이블만 그리는 방식이 훨씬 빠릅니다. DDL을 뽑는 명령은 SQL을 ERD로 변환하기의 1단계에 DBMS별로 정리되어 있습니다.

Mermaid로 게시판 전체를 그려 보면

앞의 예제는 관계 두 줄뿐이었지만, 실제 문서에 넣을 때는 컬럼까지 적게 됩니다. 게시판을 네 테이블로 그리면 이런 모양입니다.

erDiagram
  MEMBERS ||--o{ POSTS : "작성"
  MEMBERS ||--o{ COMMENTS : "작성"
  CATEGORIES ||--o{ POSTS : "분류"
  POSTS ||--o{ COMMENTS : "댓글"

  MEMBERS {
    bigint id PK
    varchar email UK
    varchar nickname
  }
  POSTS {
    bigint id PK
    bigint member_id FK
    int category_id FK
    varchar title
  }

관계를 위에 모으고 테이블 정의를 아래에 두면, 코드의 첫 몇 줄만 봐도 구조가 읽힙니다. 변경이 생겼을 때도 관계가 바뀐 것인지 컬럼이 바뀐 것인지가 diff에서 분리되어 보입니다.

상황별 조합 예시

확장 하나로 끝내기보다, 팀의 작업 방식에 맞춰 두세 개를 나눠 쓰는 경우가 많습니다.

문서를 중심에 두는 팀. README와 위키에 구조도를 유지하는 게 목적이라면 Mermaid 프리뷰 하나로 충분합니다. 스키마가 바뀔 때 코드 블록을 고치고, 리뷰에서 diff로 확인하면 됩니다. 그림 파일을 따로 관리하지 않아도 됩니다.

설계를 자주 하는 팀. 새 기능마다 테이블을 추가한다면 ERD Editor로 설계하고 DDL로 내보내는 흐름이 맞습니다. .erd.json 파일을 저장소에 두고, 마이그레이션 파일과 함께 리뷰에 올리면 구조 변경이 코드 리뷰 안에서 다뤄집니다.

SQL Server를 쓰는 팀. MSSQL 확장의 스키마 디자이너로 편집기 안에서 설계하고, 결과를 스크립트로 뽑아 적용하는 흐름이 자연스럽습니다. SSMS를 함께 쓴다면 SSMS로 데이터베이스 다이어그램 만들기의 내용과 이어집니다.

용도별로 정리하면

확장	파일 형식	DDL 가져오기	DDL 내보내기	확장 없이 보기
ERD Editor (dineug)	`.erd.json` (텍스트)	지원 (DBML·GraphQL도)	지원	불가
Mermaid 프리뷰 (bierner)	마크다운 코드 블록	없음	없음	GitHub·GitLab에서 렌더
Draw.io Integration (hediet)	`.drawio` 계열 (XML)	없음	없음	`.drawio.png`·`.drawio.svg`면 가능
MSSQL 스키마 디자이너 (Microsoft)	DB 스키마 직접 편집	접속으로 대체	스크립트 생성	불가
Database Client (cweijan)	접속 기반	접속으로 대체	도구 기능에 따름	불가

표에서 실제로 갈리는 지점은 오른쪽 두 열입니다. DDL을 주고받을 수 있으면 도구를 바꿔도 자산이 남고, 확장 없이 볼 수 있으면 팀 밖에 보여줄 때 별도 작업이 필요 없습니다. 설계까지 한다면 ERD Editor, 문서가 목적이면 Mermaid, 이미 있는 DB를 보는 게 목적이면 DB 클라이언트 계열입니다.

그림 파일이 곧 원본이 되는 방식

Draw.io Integration에서 알아 둘 만한 게 하나 있습니다. 파일을 .drawio.png나 .drawio.svg로 저장하면, 그 파일은 보통의 이미지이면서 동시에 편집 가능한 원본이 됩니다. 이미지 뷰어에서는 그림으로 열리고, VS Code에서는 편집기로 열립니다.

위키나 이슈에 그대로 붙이면 그림으로 보이고, 저장소에 있는 같은 파일을 열면 바로 수정할 수 있습니다. 원본과 이미지를 따로 관리하다가 둘이 어긋나는 문제가 이 방식에서는 생기지 않습니다.

다만 이미지 파일이라 git에서 diff는 보이지 않습니다. 변경 내역을 리뷰해야 하는 다이어그램이라면 텍스트 형식이 낫고, 문서에 붙여 두고 가끔 손보는 그림이라면 이 방식이 편합니다.

팀에서 쓸 때 생각해 둘 것

파일 형식이 협업 방식을 정합니다. 텍스트로 저장되는 형식은 저장소에 올려 diff로 리뷰할 수 있습니다. 스키마 변경을 코드 리뷰와 같은 흐름에서 다루고 싶다면 이 점이 중요합니다. 반대로 이미지 파일은 무엇이 바뀌었는지 확인할 수 없고, 두 사람이 동시에 고치면 충돌을 해결하기도 어렵습니다.

확장 설치를 강요하지 않는 경로를 하나 남겨 둡니다. 기획자나 다른 팀에게 구조를 보여줘야 하는 순간이 옵니다. 확장을 설치하지 않은 사람도 볼 수 있도록, 이미지로 내보내는 방법이나 링크로 공유하는 경로를 미리 정해 두면 그때 헤매지 않습니다.

확장 생태계는 바뀝니다. 지금 쓰는 확장이 몇 년 뒤에도 유지된다는 보장은 없습니다. 그래서 원본을 DDL이나 텍스트로 남겨 두는 습관이 안전합니다. DDL만 있으면 확장이 사라져도 다른 도구에서 다시 그릴 수 있습니다. DDL을 뽑는 방법은 SQL을 ERD로 변환하기에 DBMS별로 정리되어 있습니다.

자주 묻는 질문

VS Code만으로 ERD를 그릴 수 있나요?

그릴 수 있습니다. ERD Editor 확장을 설치하면 편집기 안에서 테이블을 만들고 관계를 연결하는 전용 화면이 열리고, SQL DDL을 가져오거나 반대로 DDL로 내보낼 수도 있습니다. 문서에 넣을 그림이 목적이라면 Mermaid 프리뷰 확장만으로도 충분합니다.

기존 DB의 구조를 VS Code에서 볼 수 있나요?

DB에 접속하는 확장을 쓰면 됩니다. Database Client 계열 확장은 접속한 데이터베이스의 테이블을 ER 다이어그램으로 보여주고, SQL Server를 쓴다면 Microsoft의 MSSQL 확장에 들어 있는 스키마 디자이너를 사용할 수 있습니다.

확장으로 그린 ERD를 팀과 공유하려면 어떻게 하나요?

확장마다 파일 형식이 달라서 방법이 갈립니다. 상대도 같은 확장을 설치했다면 파일을 그대로 저장소에 올리면 되고, 확장을 설치하지 않은 사람에게 보여줘야 한다면 이미지로 내보내거나 DDL을 뽑아 브라우저 도구에 넣는 편이 확실합니다.

ERD 파일을 git으로 관리해도 되나요?

텍스트 기반 형식이라면 권장할 만합니다. Mermaid 코드나 ERD Editor의 파일처럼 텍스트로 저장되는 형식은 변경 내역이 diff로 보여서 리뷰가 가능합니다. 반대로 이미지 같은 바이너리 파일은 무엇이 바뀌었는지 알 수 없고 충돌도 해결하기 어려우니, 원본은 텍스트로 두고 이미지는 필요할 때 만드는 쪽이 깔끔합니다.

새 스키마 설계에는 ERD Editor, 문서에는 Mermaid, 자유로운 작도에는 Draw.io Integration, 기존 DB 확인에는 DB 클라이언트 확장이 맞습니다. ERD 원본을 DDL이나 텍스트로 보관하면 확장을 바꿀 때도 구조를 다시 사용할 수 있습니다.

편집기 밖으로 그림을 꺼내야 하는 단계라면 DDL을 WorksCove ERD에 붙여넣어 다이어그램과 테이블 명세서를 만들고 링크로 공유하는 방법도 있습니다. 브라우저에서 쓰는 무료 도구들의 비교는 무료 온라인 ERD 툴 5가지 비교에 정리해 두었습니다.