DB 설계/ERD가 왜 견적에 큰 영향인가

데이터베이스는 소프트웨어의 기초 구조입니다. 모든 기능은 데이터를 저장하고 조회하므로, DB 설계의 복잡도가 곧 개발 비용입니다.

테이블 수와 비용의 관계:

왜 이렇게 영향이 큰가?

1. 테이블 1개당 CRUD API가 2~5개 필요

2. 테이블 간 관계(JOIN)가 복잡하면 쿼리 개발 공수 증가

3. 데이터 유효성 검증, 인덱싱, 마이그레이션 공수

4. 관리자 페이지에서 각 테이블의 관리 화면 필요

예를 들어, "카테고리가 1단계"면 테이블 1개지만, "3단계 카테고리(대분류→중분류→소분류)"면 테이블 3개 + 재귀적 쿼리가 필요하여 공수가 3~5배 증가합니다.

문제 1: 성능 저하

정규화가 안 된 DB는 데이터가 늘어나면 급격히 느려집니다. "처음엔 빠르던 페이지가 데이터 1만 건 넘으니 10초 걸린다"는 전형적인 증상입니다.

문제 2: 기능 추가 불가

초기 설계가 부실하면 새로운 기능을 추가할 수 없거나, 추가하려면 전체 구조를 뜯어고쳐야 합니다. 예를 들어, "상품에 옵션을 추가해주세요"라는 단순한 요청도 DB 구조에 따라 1일짜리가 될 수도, 2주짜리가 될 수도 있습니다.

문제 3: 데이터 불일치

제약 조건(Constraint)이 없으면 잘못된 데이터가 들어갈 수 있습니다. 예: 존재하지 않는 사용자 ID가 주문 테이블에 들어가는 경우.

문제 4: 마이그레이션 지옥

운영 중에 DB 구조를 바꾸는 것은 매우 위험합니다. 기존 데이터를 새 구조로 변환해야 하고, 실패하면 데이터가 손실될 수 있습니다.

교훈: DB 설계는 한 번 잘 해놓으면 2년을 편하게 쓰고, 대충 하면 3개월 후 전면 수정이 필요합니다.

ERD(Entity Relationship Diagram)를 직접 설계할 필요는 없지만, 아래 항목은 확인하세요.

기본 확인 사항:

성능 관련:

보안 관련:

ERD를 이해하기 어렵다면 개발사에게 "각 테이블이 무엇을 저장하는지, 테이블 간 관계가 어떻게 되는지"를 쉽게 설명해달라고 요청하세요.

SI 프로젝트에서의 추천: PostgreSQL이 가장 무난합니다. 관계형 데이터를 안정적으로 처리하고, JSON 지원도 우수하며, AWS RDS에서 쉽게 운영할 수 있습니다.

MongoDB 주의사항: 스키마가 자유로워서 초기에는 빠르지만, 데이터가 복잡해지면 관리가 어려워질 수 있습니다. 관계형 데이터가 많은 서비스에는 부적합합니다.