데이터 모델링 (Data Modeling)
목차
- 데이터 모델링이란
- 엔티티와 관계 설계
- 1:1, 1:N, N:M 관계 모델링
- PK와 FK 선택 기준
- Surrogate Key와 Natural Key
- 정규화와 비정규화의 실무 기준
- 인덱스와 스키마의 관계
- 실무에서 자주 쓰는 컬럼 패턴
- 조회 패턴을 보고 모델을 조정하는 방법
- 면접 포인트
- 참고 자료
데이터 모델링이란
데이터 모델링(Data Modeling) 은
비즈니스 요구사항을 테이블, 컬럼, 키, 관계, 제약 조건으로 바꾸는 작업입니다.
이 문서는 데이터베이스 구현·운영 관점에서 스키마를 어떻게 설계하고 유지할지를 다룹니다.
RDBMS와 NoSQL 중 무엇을 고를지, 읽기 복제본과 샤딩 같은 저장 전략 선택은 데이터베이스 설계 문서와 함께 보면 경계가 더 분명합니다.
백엔드 면접에서 데이터 모델링은 단순히 ERD를 그릴 줄 아는지 묻는 문제가 아닙니다.
보통 다음 질문이 같이 나옵니다.
- 어떤 엔티티를 분리할 것인가
- 관계를 어디까지 데이터베이스 제약으로 강제할 것인가
- PK와 FK를 어떻게 잡을 것인가
- 정규화와 비정규화를 어디까지 적용할 것인가
- 조회 패턴을 보고 스키마를 어떻게 조정할 것인가
즉, 핵심은 “테이블을 만들었다”가 아니라
업무 규칙과 조회 패턴을 안정적인 스키마로 바꿀 수 있는가입니다.
엔티티와 관계 설계
데이터 모델링은 보통 엔티티(Entity) 와 관계(Relationship) 를 찾는 것부터 시작합니다.
예를 들어 주문 시스템이라면 다음 엔티티가 자연스럽게 나옵니다.
usersordersorder_itemspaymentsproducts
좋은 엔티티 분리는 다음 기준으로 판단하는 편이 좋습니다.
- 수명주기가 다른가: 사용자와 주문은 생성/삭제 주기가 다름
- 책임이 다른가: 결제 상태와 배송 상태를 같은 테이블에 억지로 섞지 않는 편이 나음
- 변경 빈도가 다른가: 자주 바뀌는 속성과 거의 안 바뀌는 속성을 분리하면 쓰기 비용과 락 경합을 줄일 수 있음
- 제약 조건이 다른가: 결제 테이블은 중복 결제를 막는 unique 제약이 더 중요할 수 있음
면접에서는 엔티티를 너무 잘게 쪼개면 조인 비용과 복잡도가 커지고,
너무 크게 뭉치면 null 컬럼과 의미 없는 중복이 늘어난다는 점까지 같이 말하는 편이 좋습니다.
1:1, 1:N, N:M 관계 모델링
관계 모델링은 실무에서 매우 자주 나옵니다.
| 관계 유형 | 예시 | 일반적인 모델링 방식 |
|---|---|---|
| 1:1 | 사용자와 민감 정보 프로필 | 별도 테이블 + PK/FK 공유 또는 unique FK |
| 1:N | 주문과 주문 항목 | 자식 테이블이 부모 FK 보유 |
| N:M | 사용자와 권한 | 연결 테이블(bridge table) 사용 |
1:1
1:1 관계는 항상 분리하는 것이 아니라, 분리할 이유가 있을 때 나누는 편이 좋습니다.
- 보안상 분리해야 하는 경우
- 접근 패턴이 다른 경우
- 컬럼이 너무 커서 hot row를 피하고 싶은 경우
예를 들어 users 와 user_private_profiles 를 나누면
개인정보 접근을 더 엄격하게 통제할 수 있습니다.
1:N
가장 흔한 관계입니다.
orders:order_itemsusers:addressesposts:comments
보통 자식 테이블이 부모의 FK를 가집니다.
이때 중요한 점은 단순 FK 선언이 아니라, 부모 삭제 시 어떤 정책을 쓸지까지 같이 생각하는 것입니다.
ON DELETE RESTRICTON DELETE CASCADE- 애플리케이션 레벨 soft delete
N:M
N:M은 보통 직접 표현하지 않고 연결 테이블로 풉니다.
예를 들어 사용자와 권한 관계는 다음처럼 풀 수 있습니다.
CREATE TABLE user_roles (
user_id BIGINT NOT NULL,
role_id BIGINT NOT NULL,
granted_at TIMESTAMP NOT NULL,
PRIMARY KEY (user_id, role_id)
);
연결 테이블을 단순 매핑 용도로만 보지 말고,
granted_at, source, status 같은 관계 자체의 속성을 담을 수 있다는 점까지 설명하면 좋습니다.
PK와 FK 선택 기준
PK (Primary Key)
PK는 행을 유일하게 식별하는 키입니다.
좋은 PK는 다음 조건을 만족하는 편이 좋습니다.
- 유일성: 중복되지 않아야 함
- 안정성: 자주 바뀌지 않아야 함
- 짧고 단순함: 인덱스와 조인 비용에 직접 영향
FK (Foreign Key)
FK는 테이블 간 참조 무결성을 강제하는 장치입니다.
- 장점: 잘못된 참조를 DB 차원에서 막을 수 있음
- 장점: 스키마만 봐도 관계가 드러남
- 주의점: 대규모 쓰기 경로에서는 제약 비용과 삭제/업데이트 전략을 같이 봐야 함
면접에서는 FK를 무조건 걸거나 무조건 안 거는 식으로 말하면 약합니다.
- 핵심 정합성이 중요한 관계는 FK가 자연스럽다
- 대용량 이벤트 저장소나 비동기 적재 경로에서는 애플리케이션 보장과 운영 비용을 같이 비교할 수 있다
즉, 기준은 “DB가 강제해야 하는가”와 “그 비용을 감당할 가치가 있는가”입니다.
관련 무결성과 락 영향은 트랜잭션 처리 및 일관성 문서와 같이 보면 좋습니다.
Surrogate Key와 Natural Key
PK를 잡을 때 자주 나오는 질문입니다.
| 구분 | Surrogate Key | Natural Key |
|---|---|---|
| 의미 | 비즈니스 의미가 없는 인공 식별자 | 업무적으로 의미 있는 값 |
| 예시 | auto increment id, UUID | email, 주민번호, 국가코드 |
| 장점 | 안정적이고 변경에 강함 | 중복 방지 의미가 분명함 |
| 단점 | 비즈니스 의미가 없음 | 업무 규칙 변경에 약할 수 있음 |
실무에서는 보통 다음처럼 많이 갑니다.
- PK는 surrogate key
- 업무상 유일해야 하는 값은 UNIQUE 제약으로 관리
예를 들어 users.id 는 BIGINT 나 UUID 같은 surrogate key로 두고,
email 은 unique constraint를 따로 두는 방식입니다.
이렇게 하면 얻는 장점은 다음과 같습니다.
- email 변경이 PK 변경으로 번지지 않음
- FK 전파 범위를 줄일 수 있음
- 조인 키를 더 안정적으로 유지 가능
반면 natural key가 더 자연스러운 경우도 있습니다.
- ISO 국가 코드
- 통화 코드
- 외부 시스템과 이미 강하게 정렬된 기준 코드
좋은 답변은 surrogate key를 기본값으로 보되,
업무상 정말 안정적인 값이면 natural key도 후보가 될 수 있다고 여지를 두는 편입니다.
정규화와 비정규화의 실무 기준
정규화는 데이터 중복을 줄이고 무결성을 높이는 방향이고,
비정규화는 읽기 성능과 단순한 조회를 위해 일부 중복을 허용하는 방향입니다.
| 항목 | 정규화 | 비정규화 |
|---|---|---|
| 강점 | 수정 일관성, 무결성, 중복 감소 | 조회 단순화, 조인 감소, 응답 속도 개선 |
| 단점 | 조인 증가, 조회 복잡도 증가 | 중복 데이터 관리와 동기화 비용 |
| 잘 맞는 경우 | 주문, 결제, 정산, 회계 | 피드, 대시보드, 목록성 조회 |
실무에서는 보통 다음 흐름이 자연스럽습니다.
- 원본 데이터는 정규화 중심으로 시작
- 실제 병목이 확인되면 일부 읽기 모델을 비정규화
- 캐시, materialized view, 배치 집계 테이블도 함께 검토
면접에서는 “비정규화가 빠르다”로 끝내지 말고,
어떤 데이터는 원본을 유지하고, 어떤 응답만 별도로 최적화하는가를 설명하는 편이 좋습니다.
정규화와 비정규화의 선택 기준은 RDBMS와 SQL 문서와도 직접 연결됩니다.
인덱스와 스키마의 관계
스키마와 인덱스는 따로 보면 안 됩니다.
- 어떤 컬럼을 PK/FK로 두는가
- 어떤 컬럼 조합으로 자주 조회하는가
- 어떤 정렬과 범위 검색이 자주 나오는가
이 질문들이 결국 인덱스 설계로 이어집니다.
예를 들어 주문 조회 API가 다음 패턴을 자주 쓴다면:
user_id조건status필터created_at정렬
스키마 설계 단계부터 이런 조회 패턴을 보고 인덱스를 같이 설계해야 합니다.
CREATE INDEX idx_orders_user_status_created_at
ON orders (user_id, status, created_at DESC);
이때 주의할 점은 다음과 같습니다.
- 인덱스가 많아질수록 쓰기 비용이 늘어남
- nullable 컬럼과 저선택도 컬럼은 기대만큼 효과가 없을 수 있음
- soft delete 컬럼이 많으면 복합 인덱스 전략이 더 중요해질 수 있음
즉, 좋은 데이터 모델은 ERD만 예쁘게 그리는 것이 아니라
핵심 조회 패턴과 인덱스 비용까지 같이 설명할 수 있는 모델입니다.
세부 튜닝과 실행 계획은 데이터베이스 최적화 문서가 더 직접적입니다.
실무에서 자주 쓰는 컬럼 패턴
nullable
- 장점: 유연하게 시작하기 쉬움
- 주의점: null 의미가 많아질수록 쿼리와 검증이 복잡해짐
가능하면 “정말 값이 없을 수 있는가”를 먼저 따지는 편이 좋습니다.
unique
- 이메일, 외부 결제 ID, 주문 번호처럼 업무상 유일성이 중요한 값은 unique 제약으로 관리하는 편이 자연스럽습니다.
- 단, soft delete와 같이 쓰면 단순 unique만으로는 부족할 수 있어 partial index나 상태 조건을 같이 검토해야 합니다.
soft delete
soft delete는 운영 복구와 감사 추적에는 유리하지만, 쿼리 복잡도와 인덱스 비용이 늘어납니다.
- 장점: 복구와 이력 관리가 쉬움
- 단점: 모든 조회에
deleted_at IS NULL같은 조건이 붙기 쉬움
그래서 핵심 테이블에서는 soft delete가 정말 필요한지 먼저 따지는 편이 좋습니다.
status 컬럼
상태 컬럼은 흔하지만, 의미 없이 한 테이블에 모든 상태를 몰아넣으면 관리가 어려워집니다.
- 주문 상태
- 결제 상태
- 배송 상태
이런 상태는 수명주기와 책임이 다르므로, 정말 같은 엔티티의 상태인지 구분해야 합니다.
조회 패턴을 보고 모델을 조정하는 방법
좋은 모델링은 ERD에서 끝나지 않고, 실제 조회 패턴을 보고 조정됩니다.
대표 질문은 다음과 같습니다.
- 가장 자주 조회하는 API는 무엇인가
- 어떤 조건과 정렬이 반복되는가
- 목록 조회가 많은가, 단건 조회가 많은가
- 조인이 많은가, 집계가 많은가
- 읽기와 쓰기 중 어느 쪽이 병목인가
예를 들어:
- 주문 상세 조회가 많다면
orders,order_items,payments조인 비용을 먼저 봐야 합니다. - 관리자 목록 조회가 많다면 검색/정렬 컬럼 중심으로 인덱스를 설계해야 합니다.
- 대시보드 집계가 많다면 원본 테이블만으로 버티기보다 집계 테이블이나 materialized view를 검토할 수 있습니다.
즉, 데이터 모델링은 “정답 스키마”를 한 번에 만드는 작업이 아니라
업무 규칙과 조회 패턴을 같이 보며 진화시키는 작업입니다.
면접 포인트
- 데이터 모델링은 비즈니스 요구사항을 테이블, 관계, 제약으로 바꾸는 작업입니다.
- 엔티티 분리는 수명주기, 책임, 변경 빈도, 제약 조건 차이를 기준으로 설명하는 편이 좋습니다.
- PK는 보통 안정적인 surrogate key를 쓰고, 업무상 유일성은 UNIQUE 제약으로 분리하는 방식이 실무에서 많습니다.
- 정규화와 비정규화는 절대선이 아니라 무결성과 조회 비용 사이의 트레이드오프입니다.
- 좋은 답변은 스키마, 인덱스, 조회 패턴, 운영 비용을 한 흐름으로 연결합니다.