Sqemo

논리 모델과 물리 모델 — 산출물 관점에서 다시 보기

· 갱신

논리모델 물리모델 차이를 검색하면 대체로 같은 표가 나옵니다. 논리는 업무 관점, 물리는 구현 관점. 논리는 엔터티와 속성, 물리는 테이블과 컬럼. 논리는 DBMS 독립적, 물리는 DBMS 종속적. 틀린 설명은 아니지만, 이 표를 다 외워도 실무에서 겪는 문제는 하나도 풀리지 않습니다.

국내 프로젝트에서 두 모델의 관계가 특별한 이유는 정의가 달라서가 아니라, 논리 ERD가 산출물이기 때문입니다. 분석·설계 단계의 결과물로 제출되고, 검토되고, 승인 서명이 붙습니다. 그 순간 논리 모델은 설계 과정의 중간 표현이 아니라 합의의 증거가 됩니다. 이 성격 변화가 이후 모든 일을 결정합니다. 그래서 이 글에서 다룰 질문은 “둘의 차이가 무엇인가”가 아니라 “제출한 다음에 그것은 어떻게 되는가” 입니다.

두 모델이 갈라진 이유

데이터베이스 설계는 처음부터 서로 다른 두 작업이었습니다. 업무에 어떤 개체가 있고 그것들이 어떻게 얽히는지 밝히는 작업과, 그 구조를 특정 DBMS 위에 어떤 물리 구조로 앉힐지 정하는 작업입니다. 두 작업은 필요한 지식이 다르고, 결정을 검토할 수 있는 사람도 다릅니다. 현업 담당자는 “주문 하나에 배송지가 여러 개일 수 있는가”에 답할 수 있지만 VARCHAR(20)이 맞는지는 답할 수 없고, DBA는 정확히 그 반대입니다.

데이터베이스 아키텍처를 세 층으로 나누는 오래된 구분(외부 · 개념 · 내부 스키마)도 결국 같은 이야기를 합니다. 사용하는 관점, 의미를 정의하는 관점, 저장하는 관점을 분리해 두면 한쪽의 변경이 다른 쪽을 흔들지 않는다는 것입니다.

국내에서는 여기에 한 겹이 더 얹혔습니다. 논리 ERD가 검수 대상 문서가 된 것입니다. 산출물 목록에 한 줄로 존재하고, 정해진 시점에 제출되며, 통과하면 그 단계가 종료됩니다. 이 제도 자체는 합리적입니다. 업무 합의를 문서로 고정해 두지 않으면 개발 중간에 “그건 그렇게 하기로 한 적 없다”가 반복되기 때문입니다. 문제는 제도가 만들어 내는 부수 효과입니다. 제출과 승인이 끝나는 순간, 그 문서를 계속 고칠 이유가 사라집니다.

논리 모델이 답해야 하는 질문

논리 모델의 품질 기준은 하나로 요약됩니다. SQL을 쓰지 않는 현업 담당자가 읽고 “그건 틀렸다”고 말할 수 있는가. 그 조건을 만족하면 좋은 논리 모델이고, 만족하지 못하면 아무리 정교해도 검토받지 못한 모델입니다.

그래서 논리 모델이 답해야 하는 질문은 전부 업무 언어로 물을 수 있는 것들입니다.

가장 흔한 실패는 이 층에 타입과 길이를 적어 넣는 것입니다. 검토 회의에서 CUST_NO VARCHAR(20)을 본 현업 담당자는 두 가지 중 하나를 합니다. 아무 말 없이 넘어가거나, 자기가 판단할 근거가 없는 길이 값에 의견을 냅니다. 어느 쪽도 검토가 아닙니다. 반대로 “고객번호: 본인인증이 완료되어 계정이 활성화된 시점에 채번한다”라고 적혀 있으면, 그 사람은 즉시 “아니요, 신청 시점에 채번합니다”라고 말할 수 있습니다. 그 한 문장이 논리 모델이 존재하는 이유 전부입니다.

물리 모델이 답해야 하는 질문

물리 모델의 기준도 하나입니다. 이 DDL이 이 DBMS에서 실행되고, 예상 데이터량과 쿼리 패턴에서 견디는가.

여기서 중요한 사실 하나. 물리 모델에는 논리 모델에 대응물이 없는 요소가 반드시 생깁니다. 인덱스, 파티션, 반정규화한 중복 컬럼, 이력 테이블, 코드 테이블, 생성일시·생성자 같은 감사 컬럼이 그렇습니다. 이것들은 업무 개념이 아니라 구현 결정이므로 논리 모델에 없는 것이 정상입니다.

문제는 존재 자체가 아니라 결정의 근거가 어디에도 남지 않는다는 점입니다. 이력 테이블을 만든 이유가 성능이 아니라 “변경 전 값을 3년간 보관해야 한다”는 업무 규칙이었다면, 그것은 논리 모델에 남았어야 할 결정입니다. 물리에만 남으면 몇 년 뒤 누군가 그 테이블을 “안 쓰는 것 같은데 정리하자”고 제안하게 됩니다.

제출한 논리 ERD가 실제 DB와 어긋나는 경로

어긋남은 한 번에 일어나지 않습니다. 거의 항상 아래 순서를 밟습니다.

  1. 설계 단계 종료 시점. 논리 ERD를 제출하고 승인받습니다. 이 시점에는 논리와 물리가 정확히 일치합니다. 이때의 일치가 이후 모든 오해의 근거가 됩니다.
  2. 개발 중 속성 추가. 화면을 만들다 빠진 값이 나옵니다. ALTER TABLE로 컬럼을 추가하면 5분이면 끝납니다. 논리 ERD 파일은 다른 사람의 로컬 PC에 있고, 열어서 고치고 다시 배포하는 데는 반나절이 듭니다. 첫 번째 균열이 여기서 생깁니다.
  3. 성능 대응. 조회가 느려 반정규화를 하고 집계 테이블을 만듭니다. 이것은 물리 결정이므로 논리 ERD를 고칠 이유가 없다고 판단합니다. 그 판단은 대체로 옳습니다. 다만 이때 논리에도 남았어야 할 업무 규칙이 함께 물리 쪽으로만 흘러갑니다.
  4. 오픈 직전 산출물 최종본. 문서를 실제와 맞춰야 하는데 시간이 없습니다. 그래서 운영 DB에서 테이블·컬럼 목록을 뽑아 문서의 표를 갈아끼웁니다. 다이어그램은 손대지 못합니다. 이 시점에서 논리 ERD는 형식만 논리이고 내용은 물리인 문서가 됩니다. 업무 정의는 이 과정에서 사라집니다. DB에서 뽑을 수 없는 유일한 정보이기 때문입니다.
  5. 몇 년 뒤 고도화 착수. 새 팀이 산출물을 받아 읽고, 곧 실제 DB와 다르다는 것을 발견합니다. 한 번 다르다는 것이 확인되면 그 문서는 전체가 신뢰를 잃습니다. 맞는 부분과 틀린 부분을 구분할 방법이 없기 때문입니다.
  6. 역공학. 결국 운영 DB에서 스키마를 역으로 뽑아 새로 그립니다. 여기에는 컬럼명과 타입은 있지만 업무 정의는 없습니다. 정의를 아는 사람을 찾지만, 그 사람은 대개 이미 그 조직에 없습니다.

이 경로에서 개인의 게으름을 탓할 지점은 사실상 없습니다. 각 단계의 판단은 그 시점에서 모두 합리적입니다. 어긋남은 비용의 비대칭에서 나옵니다. DDL을 고치지 않으면 코드가 즉시 깨지지만, 논리 ERD를 고치지 않아도 오늘은 아무 일도 일어나지 않습니다. 한쪽에만 강제력이 있고 다른 쪽에는 없다면, 두 문서가 갈라지는 것은 시간 문제가 아니라 정해진 결과입니다.

두 모델을 연결된 상태로 유지하는 방법

해법은 “문서를 성실히 갱신하자”가 아닙니다. 그 결심은 이미 여러 번 실패했습니다. 구조를 바꿔야 합니다.

첫째, 두 모델을 한 곳에 둡니다. 논리 ERD 파일과 DDL이 별개의 산출물이면 동기화라는 작업이 생기고, 동기화 비용은 언제나 문서 쪽이 집니다. 하나의 모델에 논리명과 물리명이 함께 있고 보기만 전환되는 구조라면 동기화라는 작업 자체가 없어집니다.

둘째, 물리명을 생성합니다. 논리명을 고치면 물리명이 따라오게 만들면, 이름 차원의 어긋남은 발생할 수 없습니다. 그 방법은 데이터 표준화 글에서 단어사전·용어사전·도메인으로 나누어 정리했습니다.

셋째, 물리 전용 요소를 감추지 않되 근거를 남깁니다. 인덱스와 이력 테이블은 물리에만 있는 것이 맞지만, 그것을 만든 업무적 이유는 모델 안에 설명으로 남아야 합니다.

넷째, 산출물을 손으로 만들지 않고 뽑아냅니다. 테이블 정의서와 컬럼 정의서를 스프레드시트로 따로 작성하는 순간, 관리해야 할 사본이 하나 더 생깁니다. 정의서는 모델에서 내보내는 뷰여야 합니다. 어떤 항목을 손으로 적고 어떤 항목을 뽑아내야 하는지는 정의서 쓰는 법 글에서 항목별로 나누어 정리했습니다.

다섯째, 실제 DB와 주기적으로 대조합니다. 문서를 믿지 말고 검사를 믿는다는 뜻입니다. 대조를 사람이 하면 분기에 한 번 하게 되고, 자동으로 하면 매일 하게 됩니다.

Sqemo는 이 다섯 가지를 전제로 만든 ERD 도구입니다. 논리와 물리는 별도 문서가 아니라 하나의 모델이고, 도구 막대에서 논리 · 물리 · 명명 · 용어사전 · 도메인 보기를 전환하며 같은 대상을 다른 각도로 봅니다. 이 부분은 무료 기능이고 가입 없이 로컬 파일로 바로 쓸 수 있습니다. 산출물 쪽으로는 엔터티·컬럼·인덱스·관계 정의서를 CSV로 내보내고, 다이어그램은 PNG·SVG로 내보내거나 A4·A3 용지에 맞춰 인쇄·PDF로 저장할 수 있습니다. 손으로 다시 만드는 대신 모델에서 뽑아내는 쪽이 어긋남을 원천에서 없앱니다.

실제 DB와의 대조는 Pro에서 제공합니다. npx sqemo-mcp lint 로 프로젝트 파일과 운영 DB를 비교해 어긋난 지점을 보고하고, 위반이 있으면 종료 코드로 CI를 실패시킬 수 있습니다. PostgreSQL과 MySQL은 직접 접속해 대조하고, 다른 방언은 스키마 덤프 파일로 대조합니다. 접속 정보는 로컬 또는 CI 작업에서만 쓰이고 Sqemo 서버로 전송되지 않습니다. 절차는 Connect to a Live Database 문서 (영문)에 단계별로 정리되어 있고, 플랜별 범위는 요금제 페이지에서 확인하실 수 있습니다.

논리 모델과 물리 모델의 차이를 다시 정리하는 것보다 먼저 해 볼 일이 있습니다. 지금 산출물 폴더에 있는 논리 ERD와 운영 DB를 나란히 놓고 테이블 개수부터 세어 보시기 바랍니다. 숫자가 다르다면 이미 위 경로의 어딘가에 들어와 있는 것이고, 벌어진 간격은 시간이 지나도 저절로 좁아지지 않습니다.