사내 DB 포털/ERD 도구를 만들면서 계속 부딪힌 질문이 있다. “왜 예쁜 ERD를 그려줘도 개발자들은 잘 안 볼까?” 답을 정리해보니, 문제는 ERD 자체가 아니라 탐색 방식이었다.
정적 ERD의 한계
전체 스키마를 한 장에 펼친 ERD는 보기엔 근사하지만 실무에선 잘 안 열린다.
- 테이블이 수십~수백 개면 한눈에 안 들어온다 (스파게티)
- 개발자가 원하는 건 “전체 그림”이 아니라 “이 테이블/컬럼이 뭐지” 하나
- 스키마는 계속 바뀌는데 ERD는 금방 낡는다
탐색은 검색에서 시작한다
개발자의 실제 진입점은 검색이다. “user 들어간 테이블”, “created_at 있는 테이블” 처럼.
- 테이블·컬럼 전역 검색 — 이름 일부로 바로 점프
- 결과에서 컬럼·타입·코멘트·인덱스를 즉시 확인
- 거기서 연결된 테이블(FK)로 한 홉씩 확장
즉, ERD를 “펼쳐 놓고 찾기”가 아니라 “찾고 나서 주변만 펼치기” 로 뒤집는다.
컨텍스트 중심 뷰
한 테이블을 골랐을 때 필요한 정보:
- 컬럼 명세(타입·NULL·기본값·코멘트)
- 인덱스·제약(PK/FK/UNIQUE)
- 직접 연결된 테이블만 그린 지역 ERD (전체가 아니라 1~2홉)
- 가능하면 실제 사용 예(샘플 쿼리, 최근 참조)
설계 원칙
Note
“X 도구처럼”이 아니라 “이 원칙 때문에”로 결정한다. 한 제품을 golden standard로 삼으면 그 제품의 맹점까지 따라간다.
- 검색 우선 — 첫 화면은 전체 그림이 아니라 검색창
- 지역성 — 필요한 주변만 펼친다, 전체 ERD는 옵션
- 최신성 — 스키마에서 자동 생성, 수기 관리 금지
- 개발자 언어 — 컬럼 코멘트·명명 규칙을 그대로 노출
정리
- 정적 전체 ERD는 “보기 좋은 벽지”가 되기 쉽다
- 개발자는 검색 → 컨텍스트 → 지역 확장 흐름으로 스키마를 탐색한다
- 도구는 그 흐름을 따라가야 실제로 쓰인다