ER 다이어그램 만들기 — 텍스트로 개체 관계 다이어그램 생성
데이터베이스 스키마를 텍스트로 작성하면 ER 다이어그램이 실시간으로 그려집니다. PDF나 SVG로 내보내세요.
모든 작업은 브라우저에서 실행되며 다이어그램은 업로드되지 않습니다. 스크롤하면 확대/축소, 드래그하면 이동합니다. PDF 내보내기는 인쇄 대화상자를 엽니다. "PDF로 저장"을 선택하세요.
문제를 발견하셨거나 개선할 점이 있나요? 모든 메시지를 읽고 빠르게 고칩니다.
이 무료 ER 다이어그램 도구는 입력하는 대로 텍스트를 개체 관계 다이어그램으로 그려 줍니다. 왼쪽에 테이블과 필드를 정의하고 표준 카디널리티 표기법(일대다, 다대다)으로 연결하면 오른쪽 다이어그램이 실시간으로 바뀝니다. 완성되면 문서용 PDF나 슬라이드·위키용 SVG로 내보내세요.
실제 데이터베이스 작업에서는 텍스트 기반 다이어그램이 끌어다 놓기 방식보다 낫습니다. 스키마를 버전 관리할 수 있고(마이그레이션과 함께 git에 넣으세요), 풀 리퀘스트에서 리뷰할 수 있으며, 사각형을 몇 분씩 옮기는 대신 몇 초 만에 고칠 수 있습니다. 문법은 표준 Mermaid erDiagram 표기법이므로 여기서 만든 다이어그램은 GitHub, GitLab, Notion에서도 그대로 렌더링됩니다.
사용 방법
- 도구 모음의 가이드를 열어 2분짜리 문법 레퍼런스를 보거나, 내장 예시 스키마 중 하나를 불러오세요.
- 각 개체를 블록으로 정의하세요. 개체 이름 다음에 속성마다 한 줄씩 타입과 함께 적습니다. 기본 키는 PK, 외래 키는 FK로 표시하세요.
- 카디널리티 화살표로 개체를 연결하세요. CUSTOMER ||--o{ ORDER : places는 '고객 한 명이 주문을 0개 이상 한다'는 뜻입니다.
- 스크롤해서 확대·축소하고, 끌어서 이동하고, 화면에 맞추기로 가운데에 다시 놓으세요. PDF 다운로드(인쇄 대화상자가 열리면 'PDF로 저장' 선택)나 SVG 다운로드로 내보내세요.
자주 묻는 질문
ER 다이어그램이란 무엇인가요?
개체 관계 다이어그램은 데이터베이스를 설계하고 문서화하는 표준 방법입니다. 개체(고객, 주문, 상품처럼 저장하는 대상)는 상자로, 속성(필드)은 각 상자 안에, 개체 간의 관계(일대일, 일대다, 다대다)는 카디널리티 표시가 있는 선으로 나타냅니다. 팀은 마이그레이션을 작성하기 전에 스키마를 합의하고 기존 데이터베이스를 문서화하는 데 이를 씁니다.
이 도구는 어떤 문법을 쓰나요?
표준 Mermaid erDiagram 문법입니다. 널리 지원되는 개방형 텍스트 표기법입니다. 여기서 작성한 다이어그램은 GitHub README, GitLab, Notion, Obsidian 등 Mermaid를 지원하는 모든 곳에서 똑같이 렌더링되므로 소스 텍스트를 어디서든 쓸 수 있습니다.
다대다 관계는 어떻게 표현하나요?
개체 사이에 }o--o{를 쓰거나(양쪽 모두 0개 이상), 연결 테이블로 명시적으로 모델링하세요. 예를 들어 POST ||--o{ POST_TAG와 TAG ||--o{ POST_TAG처럼 쓰면 실제 SQL로 구현하는 방식에 더 가깝습니다. 내장 블로그 예시가 연결 테이블 패턴을 보여 줍니다.
스키마가 어딘가에 업로드되나요?
아니요. 렌더링은 전부 브라우저에서 이루어지며 텍스트는 기기를 벗어나지 않습니다. 운영 중인 데이터베이스 스키마를 다이어그램으로 그릴 때 중요한 점입니다.
작업은 어떻게 저장하나요?
다이어그램 소스는 일반 텍스트입니다. 파일, 티켓, 저장소에 복사해 두고 언제든 다시 붙여 넣어 이어서 작업하세요. 완성된 그림은 PDF(문서용)나 SVG(무한 확대 가능, 슬라이드와 위키에 깔끔하게 삽입)로 내보내세요.
카디널리티 표기법 치트 시트
• || — 정확히 하나 (필수 단일 레코드)
• o| — 0 또는 1 (선택적 단일 레코드)
• |{ — 하나 이상 (필수 다수)
• o{ — 0개 이상 (선택적 다수)
양쪽에서 기호를 하나씩 조합하세요. CUSTOMER ||--o{ ORDER는 모든 주문이 정확히 한 고객에게 속하고, 고객은 주문을 몇 개든 가질 수 있다는 뜻으로, 비즈니스 스키마에서 가장 흔한 관계입니다. 비식별 관계에는 실선(--) 대신 점선(..)을 쓰세요.
코드를 쓰기 전에 스키마를 설계해야 하는 이유
고아 레코드, 중복 데이터, 아무도 조인할 수 없는 테이블 같은 가장 비싼 데이터베이스 문제 대부분은 계획 없이 커진 스키마에서 비롯됩니다. ER 다이어그램을 10분만 그려 보면 중요한 질문을 일찍 마주하게 됩니다. 이 개체를 고유하게 식별하는 것은 무엇인가? 이 관계는 정말 일대다인가, 아니면 고객이 주소를 두 개 갖는 순간 다대다가 되는가? 삭제하면 어떻게 되는가?
기술 담당자와 비기술 이해관계자 사이의 가장 빠른 공통 언어이기도 합니다. 사업 담당자도 다이어그램에서 '고객 한 명이 주문을 여러 개 한다'를 읽고, 잘못된 가정이 6개월치 코드에 녹아들기 전에 바로잡아 줄 수 있습니다. 공유된 다이어그램은 구현 전에 팀이 스키마에 합의하는 데 도움이 됩니다.