테이블 정의서와 ERD 차이, 개발자 질문 막는 법

테이블 정의서와 ERD 차이, 개발자 질문 막는 법

데이터 설계 회의에서 은근 자주 막히는 지점이 있습니다. ERD는 테이블끼리 어떻게 연결되는지 보는 그림이고, 테이블 정의서는 각 테이블 안에 어떤 컬럼이 있는지 보는 표에 가깝습니다.

둘 다 데이터베이스 이야기라서 처음 보면 비슷해 보입니다. 그런데 회의에서는 역할이 확 갈려요. ERD만 보면 컬럼 상세가 부족하고, 테이블 정의서만 보면 테이블 간 관계가 한눈에 안 들어옵니다.

테이블 정의서와 ERD 차이를 이렇게 나눠두면 회의에서 어디를 봐야 하는지 빨리 잡힙니다. 관계가 궁금하면 ERD, 값의 규칙이 궁금하면 테이블 정의서입니다.

이 글은 비개발자 PM도 회의에서 따라갈 수 있게 두 문서를 나눠봅니다. 개발자처럼 DB를 설계하자는 뜻이 아니라, 질문을 제대로 던지자는 쪽에 가깝습니다.

문서 이름을 외우는 것보다 더 중요한 건 언제 어떤 문서를 봐야 하는지입니다. 관계가 헷갈리면 그림을 보고, 값의 규칙이 헷갈리면 표를 봅니다. 이 순서만 잡아도 회의에서 덜 멈춥니다.

처음부터 DB 용어를 다 알 필요는 없어요. 내가 봐야 할 칸만 좁히면 충분합니다. 회의에서 필요한 건 멋진 설명보다 “어디가 연결되고, 어떤 값이 저장되는지”를 묻는 감각, 딱 그 정도입니다.

초반 회의에서는 두 문서의 역할을 먼저 나눠두면 이야기가 덜 꼬여요. 검색해서 들어온 분이라면 이 한 줄만 먼저 잡아도 됩니다. 그림은 관계, 표는 컬럼. 여기서 시작하면 됩니다.

잠깐 정리하면, 관계와 컬럼만 나눠도 충분해요

• 두 문서의 차이는 표와 관계 그림의 차이로 보면 편해요.
• ERD는 어떤 데이터가 서로 연결되는지 빠르게 보는 데 좋습니다.
• 테이블 정의서는 컬럼명, 타입, 필수 여부처럼 구현에 가까운 세부값을 봅니다.
• 기능 범위가 흔들리면 요구사항 정의서 작성법도 같이 봅니다.
• 화면 입력값, 상태값, 삭제 처리는 두 문서를 같이 봐야 덜 놓칩니다.
• 회의 전에는 관계, 컬럼, 상태값 세 가지만 표시해도 대화가 훨씬 짧아져요.
• 화면 설계서와 같이 펼쳐두면 어떤 값이 저장되는지 더 빨리 보입니다.

ERD는 선으로 얽힌 관계를 먼저 보여줍니다

두 문서의 차이를 이해하려면 ERD를 먼저 그림으로 보면 됩니다. 회원 테이블, 주문 테이블, 결제 테이블이 있고 서로 선으로 이어져 있다면 그게 관계를 보여주는 방식이에요.

테이블 정의서와 ERD 차이를 처음 볼 때는 관계 그림부터 보는 편이 덜 복잡합니다. “이 테이블이 왜 저 테이블과 이어지지?”가 먼저 보이거든요.

ERD는 “회원 한 명이 주문을 여러 개 가질 수 있는지”, “주문과 결제가 1:1인지” 같은 관계 질문에 강합니다. 데이터가 어디에서 어디로 이어지는지 빠르게 파악할 수 있어요.

다만 ERD만으로는 컬럼의 자세한 규칙을 알기 어렵습니다. 이름, 전화번호, 상태값, 생성일 같은 컬럼이 어떤 타입인지, 필수인지, 기본값이 있는지는 따로 봐야 해요.

관계가 복잡할수록 테이블 정의서와 ERD 차이를 같이 봐야 빈틈이 줄어듭니다.

그래서 두 문서의 차이는 “큰 지도”와 “주소록”의 차이처럼 볼 수 있습니다. ERD는 길을 보여주고, 테이블 정의서는 집마다 붙은 세부 정보를 보여줍니다.

테이블 정의서는 칸 안의 규칙을 체크합니다

테이블 정의서는 각 테이블 안의 컬럼을 정리한 표입니다. 컬럼명, 설명, 데이터 타입, 길이, 필수 여부, 기본값, 예시값 같은 항목이 들어갈 수 있어요.

두 문서의 역할은 여기서 다시 갈립니다. ERD가 관계를 보여준다면, 테이블 정의서는 저장 규칙을 더 작게 보여줍니다.

PM이 특히 봐야 할 건 설명, 필수 여부, 상태값입니다. 화면에서는 선택 입력처럼 보이는데 테이블에서는 필수로 잡혀 있으면 저장 단계에서 문제가 생길 수 있어요.

예를 들어 닉네임이 선택 입력인데 DB에서는 필수라면 회원가입 흐름에서 충돌이 납니다. 상태값도 “대기, 승인, 반려”처럼 화면에 보이는 말과 DB 값이 맞아야 합니다.

입력값을 검토할 때도 테이블 정의서와 ERD 차이를 알면 어디를 확인해야 할지 빨리 보입니다.

기능정의서 작성방법을 쓸 때 입력값과 저장값을 같이 보는 이유도 여기 있습니다. 화면 요구사항과 테이블 규칙이 다르면 구현 중에 말이 엇갈립니다.

둘 중 하나만 보면 빈칸 체크가 생깁니다

두 문서를 표로 비교하면 더 빠릅니다.

ERD만 보면 서비스의 데이터 흐름은 이해되지만, 실제 저장 규칙이 흐릿할 수 있습니다. 테이블 정의서만 보면 컬럼은 자세하지만 “왜 이 테이블이 여기랑 연결되는지”가 늦게 보입니다.

실무 회의에서는 테이블 정의서와 ERD 차이를 이렇게 나눠두면 서로 다른 문서를 보고 말하는 일을 줄일 수 있습니다.

두 문서는 우열 문제가 아닙니다. 회의 초반에는 ERD로 관계를 보고, 구현 세부를 잡을 때는 테이블 정의서로 내려가는 식이 자연스럽습니다.

작업 일정을 쪼갤 때는 구글 스프레드시트 WBS에 ERD 확인과 테이블 정의서 확인을 따로 넣어두면 좋습니다. 둘은 같은 일이 아닙니다.

PM은 전부 말고 이 정도만 체크

PM이 모든 타입과 인덱스를 깊게 알아야 하는 건 아닙니다. 그래도 두 문서의 역할을 알면 회의에서 질문이 달라집니다.

테이블 정의서와 ERD 차이를 알면 “이 값은 어디에 저장되나요” 같은 질문이 훨씬 쉬워집니다.

먼저 화면에서 저장되는 값이 어떤 테이블로 들어가는지 봅니다. 그다음 필수값, 상태값, 삭제 여부, 변경 이력처럼 서비스 운영에 영향을 주는 컬럼을 확인합니다.

예를 들어 회원 탈퇴 기능을 만든다면 “회원 행을 지우는지, 상태를 바꾸는지”를 확인해야 합니다. ERD는 연결된 주문과 결제를 보여주고, 테이블 정의서는 상태값과 삭제 처리 방식을 보여줍니다.

API 문서 요청 응답 예시와도 연결됩니다. API 응답에 내려오는 값이 결국 어떤 테이블의 어떤 컬럼에서 오는지 알면 기획과 개발 대화가 훨씬 짧아집니다.

회의 전 질문은 짧을수록 덜 막힙니다

두 문서의 역할을 이해했다면 회의 전에 질문을 짧게 준비하면 됩니다. 너무 개발자처럼 보이려고 할 필요는 없어요. 서비스 흐름이 깨질 만한 지점을 묻는 게 중요합니다.

• 화면의 주요 데이터가 저장되는 테이블을 확인합니다.
• 필수 입력값과 선택 입력값이 테이블 정의서와 맞는지 봅니다.
• 상태값은 화면 문구와 DB 값이 서로 대응되는지 맞춰봅니다.
• 삭제, 취소, 반려 같은 예외 흐름이 어디에 남는지 표시합니다.
• ERD에서 연결된 테이블 때문에 같이 수정해야 할 기능을 따로 적습니다.

일정표에 넣을 때도 테이블 정의서와 ERD 차이를 분리하면 확인 업무를 더 작게 나눌 수 있습니다.

이 차이를 모르면 이런 질문이 “개발 쪽에서 알아서 해주세요”로 뭉개집니다. 반대로 조금만 알아도 기획자가 챙길 수 있는 범위가 보입니다.

자주 묻는 질문, 여기서 막힙니다

표와 관계 그림의 차이는 이렇게 보면 됩니다

ERD는 테이블 사이의 관계를 보여주는 그림이고, 테이블 정의서는 테이블 안 컬럼의 세부 규칙을 정리한 표입니다. 테이블 정의서와 ERD 차이는 관계를 보느냐, 컬럼 상세를 보느냐로 나누면 이해가 쉽습니다. 회의 초반에는 관계를 보고, 구현 직전에는 컬럼 규칙을 보면 덜 헷갈립니다. 그래서 둘을 같은 문서로 뭉개면 대화가 길어져요.

PM이 테이블 정의서를 볼 때는 여기만 잡습니다

팀마다 다릅니다. PM이 직접 DB 타입까지 정할 필요는 없지만, 화면 입력값과 저장값이 맞는지는 봐야 합니다. 두 문서의 차이를 알면 개발자가 만든 문서를 검토할 때 질문이 훨씬 정확해집니다. 특히 필수값, 상태값, 삭제 처리는 서비스 운영에도 바로 영향을 줘요. 이 부분은 출시 후 CS와도 연결됩니다. 이 정도만 봐도 회의 참여가 훨씬 편해집니다.

ERD 없이 테이블 정의서만 있으면 생기는 빈칸

작은 기능은 가능할 수 있지만, 테이블이 여러 개 연결되면 ERD가 없는 상태에서 관계를 이해하기 어렵습니다. 둘을 같이 보면 저장 규칙과 데이터 흐름을 함께 확인할 수 있습니다. 기능이 커질수록 하나만 보는 방식은 놓치는 부분이 생겨요. 특히 주문, 결제, 회원처럼 연결이 많은 기능은 같이 보는 편이 안전합니다.

문서 이름보다 회의 질문이 먼저입니다

두 문서 이름을 외우는 것보다 중요한 건 어떤 질문을 해야 하는지 아는 겁니다. ERD는 관계를 보고, 테이블 정의서는 컬럼 규칙을 봅니다.

테이블 정의서와 ERD 차이는 결국 문서 암기가 아니라 회의에서 덜 헤매기 위한 기준입니다.

회의 전에 화면 입력값, 필수 여부, 상태값, 삭제 처리만 체크해도 대화가 꽤 선명해집니다. DB 문서를 다 외우지 않아도 괜찮습니다. 서비스 흐름이 깨질 만한 지점을 찾는 눈이 먼저입니다.

현장에서 헷갈린 문서 캡처나 컬럼명이 있다면 그 기준으로 더 쉽게 풀어볼 수 있습니다. 다음에는 테이블 정의서 예시를 PM 문서 관점에서 더 작게 쪼개볼게요. 회의에서 막힌 컬럼명 하나만 있어도 좋은 출발점이에요.