DB 설계/ERD가 왜 견적에 큰 영향인가
데이터베이스 설계(ERD)가 소프트웨어 외주 개발 견적, 일정, 품질에 미치는 영향을 설명하고, 발주사가 알아야 할 DB 설계 핵심 개념을 정리합니다.
- •DB 설계는 건물의 기초 공사와 같아서, 잘못되면 나중에 전체를 뜯어고쳐야 합니다.
- •테이블 수가 많을수록, 관계가 복잡할수록 개발 비용이 증가합니다 (테이블당 API 2~5개).
- •설계 단계에서 ERD를 반드시 확인하고, 확장성을 고려한 구조인지 검토하세요.
DB 설계가 견적에 영향을 미치는 이유
데이터베이스는 소프트웨어의 기초 구조입니다. 모든 기능은 데이터를 저장하고 조회하므로, DB 설계의 복잡도가 곧 개발 비용입니다.
테이블 수와 비용의 관계:
| 테이블 수 | 프로젝트 규모 | 예상 API 수 | 비용 범위 |
|---|---|---|---|
| 5~10개 | 소규모 MVP | 15~30개 | 500만~1,500만 원 |
| 10~25개 | 중규모 서비스 | 30~75개 | 1,500만~4,000만 원 |
| 25~50개 | 대규모 서비스 | 75~150개 | 4,000만~1억 원 |
| 50개+ | 엔터프라이즈 | 150개+ | 1억 원+ |
왜 이렇게 영향이 큰가?
1. 테이블 1개당 CRUD API가 2~5개 필요
2. 테이블 간 관계(JOIN)가 복잡하면 쿼리 개발 공수 증가
3. 데이터 유효성 검증, 인덱싱, 마이그레이션 공수
4. 관리자 페이지에서 각 테이블의 관리 화면 필요
예를 들어, "카테고리가 1단계"면 테이블 1개지만, "3단계 카테고리(대분류→중분류→소분류)"면 테이블 3개 + 재귀적 쿼리가 필요하여 공수가 3~5배 증가합니다.
DB 설계를 망치면 생기는 문제
문제 1: 성능 저하
정규화가 안 된 DB는 데이터가 늘어나면 급격히 느려집니다. "처음엔 빠르던 페이지가 데이터 1만 건 넘으니 10초 걸린다"는 전형적인 증상입니다.
문제 2: 기능 추가 불가
초기 설계가 부실하면 새로운 기능을 추가할 수 없거나, 추가하려면 전체 구조를 뜯어고쳐야 합니다. 예를 들어, "상품에 옵션을 추가해주세요"라는 단순한 요청도 DB 구조에 따라 1일짜리가 될 수도, 2주짜리가 될 수도 있습니다.
문제 3: 데이터 불일치
제약 조건(Constraint)이 없으면 잘못된 데이터가 들어갈 수 있습니다. 예: 존재하지 않는 사용자 ID가 주문 테이블에 들어가는 경우.
문제 4: 마이그레이션 지옥
운영 중에 DB 구조를 바꾸는 것은 매우 위험합니다. 기존 데이터를 새 구조로 변환해야 하고, 실패하면 데이터가 손실될 수 있습니다.
교훈: DB 설계는 한 번 잘 해놓으면 2년을 편하게 쓰고, 대충 하면 3개월 후 전면 수정이 필요합니다.
발주사가 ERD에서 확인해야 할 포인트
ERD(Entity Relationship Diagram)를 직접 설계할 필요는 없지만, 아래 항목은 확인하세요.
기본 확인 사항:
성능 관련:
보안 관련:
ERD를 이해하기 어렵다면 개발사에게 "각 테이블이 무엇을 저장하는지, 테이블 간 관계가 어떻게 되는지"를 쉽게 설명해달라고 요청하세요.
DB 선택 가이드
| DB | 특징 | 적합한 경우 |
|---|---|---|
| PostgreSQL | 관계형 DB의 표준, 확장성 우수 | 대부분의 웹 서비스 (추천) |
| MySQL | 가장 널리 사용, 쉬운 운영 | 소~중규모 웹 서비스 |
| MongoDB | NoSQL, 유연한 스키마 | 비정형 데이터, 빠른 프로토타이핑 |
| Redis | 인메모리, 초고속 | 캐시, 세션, 실시간 랭킹 |
| Elasticsearch | 전문 검색 엔진 | 검색 기능이 핵심인 서비스 |
SI 프로젝트에서의 추천: PostgreSQL이 가장 무난합니다. 관계형 데이터를 안정적으로 처리하고, JSON 지원도 우수하며, AWS RDS에서 쉽게 운영할 수 있습니다.
MongoDB 주의사항: 스키마가 자유로워서 초기에는 빠르지만, 데이터가 복잡해지면 관리가 어려워질 수 있습니다. 관계형 데이터가 많은 서비스에는 부적합합니다.