본문 바로가기
이노자일

ERD, 한 번 그리고 끝내면 왜 금방 실제와 달라질까?

비하인드 더 빌드7분 읽기이노자일

핵심 요약

ERD는 프로그램이 바뀔 때 함께 고치지 않으면 금방 실제와 달라집니다. 저희는 광고 관리 시스템을 만들며 ERD를 손으로 고치지 않고 매번 다시 만들어 검사하는 방식으로 바꿨습니다. 유지보수나 추가 개발을 맡길 때는 ERD부터 요청하고, 받은 ERD는 다섯 가지 질문으로 확인해 보세요.

외주 견적서나 산출물 목록에서 "ERD"라는 항목을 본 적이 있을 겁니다. 막상 받아 보면 상자와 선이 가득한 그림 한 장입니다. 개발을 모르는 입장에서는 이 그림을 어디까지 믿어야 하는지, 무엇을 확인해야 하는지 알기 어렵습니다.

※ ERD(Entity Relationship Diagram, 개체-관계 다이어그램): 프로그램이 다루는 데이터를 '무엇을(고객·주문·상품 같은 대상)', '어떤 항목으로(이름·가격·날짜 같은 정보)', '서로 어떻게 연결해(고객이 주문을 한다)' 저장하는지 그린 그림입니다. 집을 짓기 전에 설계도가 필요하듯, 데이터베이스를 만들기 전에 그리는 데이터의 설계도라고 보면 됩니다.

고객·주문·결제 같은 것이 각각 어떤 칸으로 이루어져 있고 서로 어떻게 이어지는지가 여기에 나옵니다. 나중에 기능을 추가하거나 다른 업체에 인수인계할 때 가장 먼저 찾게 되는 문서이기도 합니다. 개발자에게 ERD 없이 개발하라는 것은 배관·전선 도면 없이 건물을 고치라는 것과 같습니다. 벽 하나를 헐 때마다 그 뒤에 무엇이 묻혀 있는지 직접 뜯어 보고 확인해야 합니다. 그만큼 시간이 들고 확인을 놓친 곳에서 문제가 생깁니다.

문제는 이 문서가 그린 날에만 맞다는 점입니다. 프로그램은 운영하면서 계속 바뀌는데 ERD를 그대로 두면, 몇 달 뒤에는 그림과 실제가 다른 문서가 됩니다. 저희가 광고 관리 시스템을 만들면서 이 문서를 프로그램과 어떻게 맞춰 두었는지, 그 과정에서 무엇이 걸렸는지를 적습니다.

벽에 붙은 ERD 옆에서, 바뀐 표 하나가 반영된 새 ERD가 자동으로 출력되는 모습

ERD를 그리는 동안에도 프로그램은 바뀝니다

처음에는 사용자와 운영자를 따로 두는 비슷한 표 두 개가 있었는데, 개발을 진행하면서 하나로 합치고 로그인 아이디 칸을 새로 넣었습니다. 한 항목의 이름이 '비용유형'에서 '매입구분'으로 바뀌어 표로 정리해 둔 다른 문서에도 같이 반영해야 했습니다.

이런 변경은 특별한 사건이 아닙니다. 만들다 보면 비슷한 표를 합치는 일도, 이름을 더 정확한 말로 바꾸는 일도 계속 생깁니다. 변경 하나하나는 작지만 ERD에 반영하지 않으면 그림은 조금씩 과거의 프로그램을 가리키게 됩니다.

그래서 ERD가 맞는지 확인할 때 "잘 그렸는가"보다 먼저 볼 것은 "마지막으로 언제, 어떻게 맞춰 두었는가"입니다. 프로그램이 바뀔 때 ERD도 같이 바뀌는 순서가 있는지가 문서의 수명을 정합니다.

영어 이름만 있는 ERD는 개발자만 읽습니다

처음에는 오래 써 온 유료 설계 도구로 ERD를 그리려 했습니다. 막힌 점이 두 가지였습니다. 화면에는 한글 이름을 보여 주고 실제 데이터베이스에는 영어 이름을 쓰는 식으로 둘을 나눠 두기가 까다로웠습니다. 게다가 운영 중인 옛 데이터베이스 버전은 칸마다 설명을 붙이는 기능을 지원하지 않았습니다.

개발자는 영어 이름만 봐도 알지만 운영 담당자가 보는 ERD에 영어 이름만 있으면 그 문서는 개발자 전용이 됩니다. '매입구분'이 어느 칸인지 찾으려면 영어 이름을 하나씩 추측해야 합니다. 그래서 저희는 웹 브라우저로 여는 ERD 문서를 파일 하나로 따로 만들었습니다. 따로 설치할 것 없이 열리며 칸마다 한글 이름과 영어 이름을 나란히 적을 수 있는 형태입니다.

쓰면서 필요한 것을 하나씩 넣었습니다. 그림 그리는 방식을 한 번 바꿨습니다. 소수점이 있는 자료형(예: 전체 7자리 중 소수 4자리) 표기에서 그림이 깨지던 오류를 고쳤습니다. 끌어서 옮기고 확대·축소하는 기능, 표를 누르면 오른쪽에 상세가 나오는 기능, 연결된 표를 새 창으로 여는 기능이 차례로 들어갔습니다. 칸의 순서는 "키 · 한글 이름 · 영어 이름 · 자료형(몇 글자인지 포함)"으로 정리했습니다. 왼쪽 그림과 오른쪽 상세의 폭도 끌어서 조절할 수 있습니다.

설계를 결정한 이유도 ERD 안에 남겼습니다. 매입 세금계산서를 매출처럼 별도 표로 둘지 검토했습니다. 같은 정보가 두 곳에 생기는 위험과 조회가 쉬워지는 장점을 견준 끝에, 별도 표 대신 기존 자료에서 꺼내 보여 주는 '보기 전용 표'로 두기로 했습니다. 이 설명을 해당 영역에 접었다 펼치는 글로 넣고 상세 문서로 연결했습니다. 그래야 ERD만 보고도 왜 그 표가 없는지 알 수 있습니다.

손으로 고치지 않고, 다시 만듭니다

이렇게 하나씩 고치다 보면 완성된 문서를 직접 손보게 됩니다. 손으로 고치는 방식에는 두 가지 약점이 있습니다. 프로그램이 바뀔 때마다 사람이 그림을 다시 손봐야 하고 손으로 고친 부분은 어디를 왜 고쳤는지 기록이 남지 않습니다.

그래서 이 작업들을 묶어 다시 쓸 수 있는 AI 작업 도구로 만들었습니다. 동작 순서는 이렇습니다.

  1. 데이터베이스를 만드는 문장(표 정의 문장)을 읽는다.
  2. 그 내용을 정리된 데이터 파일로 바꾼다.
  3. 데이터 파일에서 ERD 문서를 자동으로 만든다.
  4. 만든 문서를 자동으로 검사한다.
  5. 검사를 통과하면 게시한다.

표 정의 문장에서 데이터 파일, ERD 문서를 거쳐 자동 검사 통과로 이어지는 네 단계

원칙은 하나입니다. 완성된 ERD 문서는 손으로 고치지 않습니다. 표나 칸이 바뀌면 데이터 파일을 고치고 모든 표에 공통으로 적용되는 기능이나 디자인이 바뀌면 틀을 고친 뒤 다시 만듭니다. 프로그램이 바뀌었을 때 할 일이 "그림을 다시 그린다"에서 "데이터 파일을 고치고 다시 만든다"로 바뀌면, ERD는 그린 날의 기록이 아니라 지금 프로그램의 설명서가 됩니다.

고객사 전용판과 다른 프로젝트에도 쓸 수 있는 범용판을 나눴습니다. 범용판은 프로젝트마다 이름 규칙 같은 것을 설정 파일로 정합니다. 같은 순서를 다른 프로젝트에서도 그대로 쓰기 위해서입니다.

만들 때마다 확인하는 세 가지

자동으로 만든다고 해서 자동으로 맞는 것은 아닙니다. 만들 때마다 세 가지를 검사합니다.

  • 브라우저로 실제로 열어 기능이 동작하는지. 화면 오류가 한 건도 없어야 통과합니다.
  • 그림이 깨지지 않고 그려지는지. 앞서 소수점 자료형에서 그림이 깨졌던 것처럼, 표기 하나로 그림 전체가 무너질 수 있기 때문입니다.
  • 데이터베이스 문장의 문법이 맞는지. ERD의 출발점이 되는 문장 자체가 틀리면 그 뒤는 전부 틀립니다.

이 순서는 표 71개, 표 사이 연결 94개 규모의 실제 모델에서 검증했습니다. 표 3개짜리 작은 시험 모델로도 전체 순서를 통과시켰습니다. 앞서 말한 '보기 전용 표'를 만드는 문장도 문법 검사를 통과한 것을 확인했습니다.

검사가 중요한 이유는 간단합니다. 문서가 틀렸다는 사실을 사람이 읽다가 발견하면 이미 늦습니다. 만들 때 걸러야 그 문서를 믿고 쓸 수 있습니다.

찾아보는 문서가 된 ERD

이렇게 만든 ERD 문서는 그림 한 장이라기보다 찾아보는 문서에 가깝습니다. 들어 있는 기능은 이렇습니다.

  • 묶음별 그림: 전체를 한 번에 보지 않고 관련된 표끼리 묶어 봅니다.
  • 표 검색과 체크: 이름으로 찾고, 보고 싶은 표만 골라 둡니다.
  • 조회 문장 자동 작성: 체크한 표들을 잇는 조회 문장을 만들어 줍니다. 개발자가 데이터를 꺼내 볼 때 바로 씁니다.
  • 번호 매기는 규칙 설명: 각 데이터에 번호가 어떤 규칙으로 붙는지 적어 둡니다.
  • 개발자 안내: 이 프로젝트의 데이터를 다룰 때 알아야 할 내용입니다.
  • 글자 크기 조절과 인쇄.

운영 담당자는 이름으로 찾아보고 개발자는 조회 문장과 안내를 바로 가져다 쓰는 식으로 같은 문서를 각자 필요한 만큼 씁니다.

기존 시스템을 고치거나 기능을 더할 때, ERD부터 요청하세요

기존 시스템의 유지보수를 맡기거나 새 기능을 추가 개발할 때 ERD가 없는 경우가 많습니다. 처음 만든 업체가 넘겨주지 않았거나, 처음에 그렸더라도 그 뒤 바뀐 내용이 반영되지 않은 경우입니다. 이때 새 업체는 데이터베이스를 직접 열어 보며 구조를 거꾸로 파악하는 데부터 시간을 씁니다.

그래서 유지보수나 추가 개발을 맡길 때는 ERD를 꼭 요청해 두세요. 지금 가진 ERD가 없다면 작업 범위에 "현재 데이터베이스 기준으로 ERD 작성"을 넣어 달라고 하고 작업이 끝날 때 바뀐 내용이 반영된 ERD를 함께 받아 두세요. 그래야 다음 작업을 맡길 때 같은 비용을 다시 치르지 않습니다.

업체에 물어볼 다섯 가지

업체에서 ERD를 받았거나 받을 예정이라면, 그림의 모양보다 다음을 물어보는 편이 낫습니다.

  1. 표와 칸에 한글 이름이 함께 적혀 있습니까? 영어 이름만 있으면 운영 담당자는 읽을 수 없습니다.
  2. 이 ERD는 언제, 무엇을 기준으로 만들었습니까? 지금 운영 중인 프로그램과 같은지, 다르다면 어디가 다른지 답할 수 있어야 합니다.
  3. 프로그램이 바뀌면 ERD는 어떻게 바뀝니까? 손으로 다시 그리는지, 원본 데이터에서 다시 만드는지에 따라 문서의 수명이 다릅니다.
  4. 만든 뒤에 검사합니까? 열어 보면 동작하는지, 그림이 깨지지 않는지, 출발점이 되는 문장이 맞는지를 확인하는 순서가 있는지 묻습니다.
  5. 설계를 결정한 이유가 남아 있습니까? 왜 이 표가 없는지, 왜 이렇게 합쳤는지를 문서 안에서 찾을 수 있으면 다음 담당자가 같은 고민을 반복하지 않습니다.

ERD는 받는 순간 완성되는 문서가 아니라, 프로그램과 함께 바뀌어야 하는 문서입니다. 받을 때 "다시 만들 수 있는가"를 확인해 두면 몇 달 뒤에도 쓸 수 있는 문서가 됩니다.

자주 묻는 질문

ERD를 꼭 받아야 하나요?
업무 시스템처럼 데이터가 쌓이는 프로그램이라면 받아 두는 편이 낫습니다. 기능을 추가하거나 업체를 바꿀 때 데이터가 어떤 표에 어떻게 담겨 있는지를 설명하는 문서가 ERD입니다. 다만 그림 한 장만 받는 것과, 다시 만들 수 있는 원본과 함께 받는 것은 다릅니다. 받을 때 원본의 형태와 다시 만드는 방법을 함께 묻는 것이 좋습니다.
받은 ERD가 지금 프로그램과 다른 것 같으면 어떻게 하나요?
먼저 업체에 ERD를 만든 시점과 기준을 묻습니다. 그다음 자주 쓰는 표 몇 개를 골라 실제 화면에 보이는 항목과 ERD의 칸이 맞는지 비교해 봅니다. 이름이 바뀌었거나 칸이 없어진 곳이 보이면, 그 부분만 고쳐 달라고 하기보다 현재 데이터베이스에서 다시 만들어 달라고 요청하는 편이 이후에도 맞춰 두기 쉽습니다.
업체가 "ERD는 도구에서 자동으로 뽑는다"고 하면 충분한가요?
자동으로 뽑는 것 자체는 좋은 신호입니다. 다만 세 가지를 더 확인합니다. 뽑는 원본이 지금 운영 중인 데이터베이스인지, 뽑은 결과에 한글 이름과 칸 설명이 들어가는지, 뽑은 뒤에 열어 보고 그림이 깨지지 않는지를 검사하는지입니다. 이 세 가지가 있으면 프로그램이 바뀐 뒤에도 같은 방법으로 ERD를 다시 받을 수 있습니다.

관련 글

내 프로젝트, 시작해도 될까?

요구사항·예산·리스크·AI 활용, 개발 전 준비사항을 약 3분 동안 점검해 드려요.

3분 무료 진단 시작

12문항 응답 후 이름·이메일·현재 단계를 입력하면 결과를 확인할 수 있어요.

진단보다 바로 이야기하고 싶다면 — 무료 첫 상담, 준비물 없이 화상 30분.