개발 배경: 어느 월요일 아침의 절망
“이 시스템의 전체 구조, 혹시 아는 분 계신가요?”
주 초 회의에서 제가 던진 이 한마디에 팀 전체가 침묵에 빠졌습니다.
우리 손에 들려 있는 것은 수년간 덧붙여져 마치 ‘비법 소스’처럼 되어버린 거대한 데이터베이스였습니다. 최신 ER 다이어그램은 어디에서도 찾을 수 없었고, 유일한 정답은 현재 돌아가고 있는 ‘코드(DDL)‘뿐이었죠.
테이블 정의를 하나씩 에디터로 열어보며 머릿속으로 관계를 조립하는 작업.
“아, 이게 user_id가 아니라 owner_id로 연결되어 있었구나…” 그런 발견을 할 때마다 엔지니어로서의 소중한 시간이 녹아내리는 기분이었습니다.
“SQL을 붙여넣기만 하면 순식간에 예쁜 ER 다이어그램이 나오면 얼마나 좋을까.”
그런 생각에 기존 도구들을 찾아보았지만, 어떤 것은 “SQL을 서버에 업로드하세요”라며 보안상 불안감을 주었고, 어떤 것은 “전용 소프트웨어 설치”가 필요해 당장 쓰고 싶은 제 니즈와는 맞지 않았습니다.
특히 기밀성이 높은 프로젝트의 설계 정보를 출처를 알 수 없는 서버로 보내는 것은 엔지니어의 자존심이 허락하지 않았습니다. “100% 안전하고, 지금 당장, 브라우저만으로 완결되는 ER 다이어그램 생성기.” 제가 가장 필요로 했던 이 도구를 직접 만들기로 결심한 것이 SQL to ER 다이어그램 변환 도구 개발의 시작이었습니다.
기술적 도전: 브라우저라는 ‘고독한 환경’에서의 사투
서버 사이드의 강력한 라이브러리를 쓰지 않고 브라우저의 JavaScript만으로 SQL을 해석하는 것은 예상보다 훨씬 더 고된 작업의 연속이었습니다.
1. 끝없는 ‘SQL 방언’과의 싸움
SQL에는 MySQL이나 PostgreSQL 같은 각자의 ‘방언’이 있습니다.
처음에는 “CREATE TABLE 문이 거기서 거기겠지”라고 가볍게 생각했지만, 막상 구현을 시작하니 컬럼 정의의 미세한 표기법이나 인라인으로 작성된 제약 조건 등 고려해야 할 패턴이 산더미처럼 쏟아졌습니다.
정규표현식을 고쳐서 테스트하고, 다시 다른 패턴의 SQL에서 깨지는 과정을 수없이 반복했습니다. 그런 사이클을 거치며 조금씩 ‘SQL의 마음’을 이해할 수 있는 파서를 키워나갔습니다.
2. 구세주 Mermaid.js
해석한 데이터를 어떻게 ‘도표’로 만들 것인가. 이 난제를 해결해 준 것이 바로 **Mermaid.js**였습니다.
엔지니어들이 마크다운에서 자주 사용하는 이 도구를 엔진으로 삼음으로써 ‘SQL -> 중간 데이터 -> Mermaid 구문 -> SVG’라는 깔끔한 변환 라인이 완성되었습니다.
erDiagram
USER ||--o{ POST : writes
USER {
string username
string email
}이 구조 덕분에 사용자는 도표를 이미지로 저장할 수 있을 뿐만 아니라, 생성된 ‘코드’를 복사해 GitHub 문서 등에 그대로 활용할 수 있다는 부가적인 장점도 얻게 되었습니다.
보안에 대한 ‘집착’
이 도구를 만들며 가장 포기할 수 없었던 원칙은 “데이터는 한 걸음도 브라우저 밖으로 나가지 않는다”였습니다.
개발 도중 ‘서버에서 처리하는 게 훨씬 편하겠다’는 유혹에 몇 번이나 빠졌지만, 그럴 때마다 “그건 내가 쓰고 싶은 도구가 아니야”라며 마음을 다잡았습니다.
통신이 발생하지 않는다. 그래서 누구의 눈치도 보지 않고 사내 기밀인 DML이나 DDL을 붙여넣을 수 있다.
이 안심이야말로 도구로서의 본질적인 가치라고 믿습니다.
마치며
SQL to ER 다이어그램 변환 도구는 저 자신의 ‘귀찮음’이라는 감정에서 태어난 도구입니다.
개발자가 본래 마주해야 할 것은 문서의 정리가 아니라, 더 나은 시스템의 설계여야 합니다.
“설계도가 없다”며 막막해하는 누군가에게 이 도구가 닿아 한 줄기 빛이 된다면 더할 나위 없이 기쁠 것 같습니다.
자, 이제 손에 든 SQL을 붙여넣고 여러분의 설계를 ‘정답 확인’해 보세요.