ERD를 먼저 그려야 하는 이유

ERD를 먼저 그려야 하는 이유

처음엔 이런 생각을 했습니다.

시간 없는데 그냥 코드 작성부터 해서 테이블 만들고 수정하면 되지 않나?

---

ERD 없이 시작하면 생기는 일

처음엔 빠르게 진행되는 것처럼 보였습니다.

User 테이블 만들고
Post 테이블 만들고
Comment 테이블 추가하고
엥? 좋아요는 어디 넣지?

그리고 곧 이런 상황들이 찾아왔습니다

• 외래키 관계가 머릿속에서만 존재함
• 컬럼 추가할 때마다 영향 범위 파악이 어려움
• 테이블 이름·관계를 사람마다 다르게 이해하는 문제가 생김
  -> 나는 comment를 게시글에 대한 댓글이라 생각하고 구현했지만 다른 사람은 댓글에 대한 답글이라 생각할 수 있음
• 이거 왜 이렇게 설계했지? 하며 과거의 나 자신과 싸우게 됨

ERD를 안 그린 대가는 나중에 구조적 혼란으로 돌아왔습니다.

---

ERD의 진짜 목적

많이들 이렇게 생각합니다.

ERD = 문서용, 형식적인 산출물

하지만 실제로 느낀 목적은 달랐습니다.

관계를 시각화해서 사고 비용을 줄이는 도구

ERD는 코드를 대신하는 게 아니라 코드보다 먼저 생각을 정리하는 수단입니다.

---

ERD를 그리면 달라지는 것들

관계가 강제됩니다

• 1:N인지, N:M인지, 중간 테이블이 필요한지 코드 작성 전에 실수가 걸러집니다.

도메인 이해가 빨라집니다

• 새로 온 팀원이 ERD를 보면 서비스 구조를 빠르게 파악할 수 있습니다.

수정 비용이 줄어듭니다

ERD 단계에서 수정하면

선 하나 지우는 것으로 끝

DB/코드 단계에서 수정하면

마이그레이션
데이터 보정
API 수정
테스트 수정

초기 설계 비용보다 사후 수정 비용이 훨씬 크다는 걸 직접 경험했습니다.

---

그렇다면 언제 ERD를 안 그려도 될까?

솔직히 안 그려도 되는 경우도 있다고 생각합니다.

• 테이블 2~3개짜리 실험용 토이 프로젝트
• 단기 스크립트성 작업
• 이미 검증된 구조를 그대로 구현하는 경우

이전에 여러 번 구현해봤고 구조가 머릿속에 이미 완성돼 있다면 ERD를 그리는 게 오히려 비용일 수 있습니다.

이런 경우엔 머릿속 구조로도 충분히 가능합니다.

---

회고

이번 경험을 통해 ERD는 필수 문서가 아니라 필수 사고 과정이라는 걸 느꼈습니다.
빨리 만들고 싶으면 안 그릴 수 있습니다. 하지만 잘 만들고 싶다면 그려야 한다고 생각합니다.
대부분의 경우 나중에 고치느니 미리 그리는 게 비용·시간·스트레스 모든 면에서 낫습니다.
긴 글 읽어주셔서 감사합니다.