개발자 필수 역량! ‘데이터 모델링’으로 앱 확장성과 유지보수성 2배 높이는 비법

2. 실전 데이터 구조 설계: 프로 개발자의 체크리스트

---

데이터 모델링은 추상적인 개념 같지만, 실무에서 적용할 수 있는 구체적인 원칙과 체크리스트가 존재합니다. 프로 개발자들은 다음 요소들을 항상 고려하며 데이터 모델을 설계합니다.

2-1. 데이터 흐름 및 상태(Enums, 라이프사이클) 설계

애플리케이션 내의 데이터는 정적이지 않고, 다양한 상태를 거치며 변화합니다. 이러한 상태 전이(State Machine)를 명확히 설계하는 것이 매우 중요합니다.

• ‘상태 전이(State Machine)’를 먼저 그려라!
  • 예를 들어, 온라인 주문 시스템을 설계할 때, 주문이 PENDING (대기) → PAID (결제 완료) → SHIPPED (배송 중) → DELIVERED (배송 완료) 또는 CANCELLED (취소) 등으로 어떻게 상태가 변화하는지 경로를 미리 정의해야 합니다.
  • 각 상태에서 다음 상태로의 유효한 전이를 명확히 하고, 허용되지 않는 전이를 차단하는 로직을 데이터 모델 레벨에서부터 고려합니다.
• 상태값은 ENUM(열거형) 혹은 제한된 문자 타입(alias)로 지정:
  • 데이터 일관성을 확보하고, 개발자의 실수나 외부 유입으로 인한 잘못된 데이터(Invalid State)가 시스템에 들어오는 것을 방지합니다. 예를 들어, order_status 컬럼에 PENDING 대신 오타로 PENDINGG가 들어가는 것을 막을 수 있습니다. (출처: Domain Modeling Best Practices)
• 비즈니스 엔티티와 관계 다이어그램화:
  • ERD(Entity-Relationship Diagram)와 같은 시각화 도구를 활용하여 사용자-주문-상품-결제와 같이 비즈니스의 핵심 엔티티와 그 관계를 명확하게 다이어그램으로 표현합니다.
  • 이는 개발팀뿐만 아니라 기획자, 비즈니스 분석가 등 모든 이해관계자가 데이터 흐름을 직관적으로 이해할 수 있도록 돕습니다.

2-2. 방어적 설계와 예외 관리

데이터 모델은 시스템의 ‘입구’와 같습니다. 이 입구에서부터 유효하지 않거나 예상치 못한 데이터가 들어오는 것을 막는 방어적인 설계가 중요합니다.

• Null 침투 차단:
  • 가능한 모든 컬럼에 Non-nullable 설계 원칙을 적용하고, 필수 필드의 경우 데이터베이스 레벨에서 NOT NULL 제약조건을 강제합니다.
  • NULL 값은 예외 상황을 유발하고 쿼리를 복잡하게 만들며, 데이터의 의미를 모호하게 할 수 있습니다. NULL 대신 “미정”, “알 수 없음”, “기본값” 등 의미 있는 기본값을 반드시 지정하는 습관을 들여야 합니다.
• 데이터 유효성 검사 (Validation):
  • 사용자 입력값에 대한 유효성 검사는 프론트엔드와 백엔드 양측에서 이중화하여 체크 포인트를 마련합니다. 클라이언트 측 검사는 사용자 경험을 향상시키고, 서버 측 검사는 데이터 무결성을 최종적으로 보장합니다.
  • 외부 API에서 받아오는 데이터나 시스템으로 수집되는 데이터처럼 비신뢰할 수 있는 소스에 대해서는 더욱 철저한 검증 및 정제 체계를 마련해야 합니다.
• DB 무결성 강화:
  • Primary Key와 Foreign Key를 통해 테이블 간의 관계적 무결성을 보장합니다.
  • Unique Index를 사용하여 특정 컬럼의 값이 중복되지 않도록 강제하고, Check Constraints를 활용하여 컬럼 값의 범위나 형식을 제한하는 등 데이터의 도메인 무결성을 강화합니다.

2-3. 정규화 vs 비정규화: 트레이드오프의 이해

데이터베이스 설계의 가장 큰 고민 중 하나는 정규화(Normalization)와 비정규화(Denormalization) 사이의 선택입니다. 각각의 장단점을 이해하고 서비스의 특성과 예상되는 쿼리 패턴에 따라 적절한 조합을 찾는 것이 핵심입니다.

설계 방식	장점	단점	추천 적용 사례
정규화	데이터 중복 최소화, 데이터 일관성/무결성 극대화	조인 연산 증가로 조회 성능 저하 가능성, 쿼리 복잡성 증가	쓰기/수정이 빈번한 시스템, 강한 데이터 일관성이 요구되는 금융/회계 DB
비정규화	조회 속도 극대화, 쿼리 단순화, 조인 오버헤드 감소	데이터 중복 증가, 데이터 동기화/일관성 유지 부담, 저장 공간 증가	조회 빈도가 매우 높고, 대용량 로그/Feed 기반 시스템, 분석용 데이터 웨어하우스

• 정규화: 데이터를 여러 테이블에 분리하여 저장하고, 중복을 최소화합니다. 이는 데이터의 일관성을 높이고 이상 현상(Anomaly)을 방지하는 데 유리합니다.
• 비정규화: 일부 데이터 중복을 허용하고, 데이터를 특정 테이블에 통합하여 조회 성능을 우선시합니다. 읽기 중심의 서비스나 대량의 데이터를 빠르게 조회해야 하는 경우에 유리합니다.

서비스의 특성, 트래픽 패턴, 그리고 미래 확장성을 고려하여 두 방식을 적절히 조합하는 하이브리드 접근법이 가장 현실적입니다. 예를 들어, 자주 변경되지 않지만 자주 조회되는 데이터는 비정규화하여 성능을 확보하고, 중요한 마스터 데이터는 정규화하여 일관성을 유지하는 방식입니다. (출처: Data Modeling for Scalability)

SQL

CREATE TYPE order_status AS ENUM ('PENDING', 'PAID', 'SHIPPED', 'CANCELLED', 'DELIVERED');

CREATE TABLE orders (
    order_id SERIAL PRIMARY KEY,
    user_id INT NOT NULL,
    status order_status NOT NULL DEFAULT 'PENDING',
    created_at TIMESTAMP DEFAULT NOW(),
    updated_at TIMESTAMP
);

[User] ---< [Order] >--- [Product]
       \             /
        [Payment]   [OrderItem]