데이터베이스 설계 (Database Design)

데이터베이스 설계란

데이터베이스 설계(Database Design) 는 데이터를 어떤 구조로 저장하고, 어떤 저장소를 선택하며, 읽기와 쓰기를 어떻게 분산할지 정하는 과정입니다.

이 문서는 시스템 디자인 관점에서 어떤 저장 전략을 선택할지를 설명합니다.
제품별 동작 원리, 실행 계획, 인덱스 튜닝, 저장소별 운영 이슈는 NoSQL 데이터베이스, 데이터베이스 스케일링, 데이터베이스 최적화 문서가 더 직접적인 심화 자료입니다.

시스템 디자인 면접에서 데이터베이스 설계는 단순히 “MySQL 쓰겠습니다”로 끝나지 않습니다. 보통 다음을 함께 봅니다.

데이터 모델: 주문, 결제, 사용자, 로그처럼 데이터 구조가 어떤가
접근 패턴: 조회가 많은가, 쓰기가 많은가, 조인이 많은가
일관성 요구: 강한 일관성이 필요한가, 최종적 일관성이 허용되는가
확장성 요구: 저장량, 읽기 부하, 쓰기 부하가 어디까지 커지는가
운영 요구: 백업, 복구, 장애 전환, 모니터링이 얼마나 중요한가

즉, 데이터베이스 설계는 저장 기술 선택이 아니라 업무 요구사항과 데이터 특성에 맞는 저장 전략을 고르는 작업입니다.

데이터베이스 선택 기준

데이터베이스를 고를 때 가장 흔한 실수는 유행이나 익숙함만으로 선택하는 것입니다. 시스템 디자인 면접에서는 보통 아래 질문으로 선택 근거를 보여주는 편이 좋습니다.

이 데이터는 관계형 구조인가
- 주문, 결제, 재고처럼 관계와 무결성이 중요하면 RDBMS가 자연스럽습니다.
조인과 트랜잭션이 핵심인가
- 여러 엔티티를 함께 읽고 쓰는 비즈니스라면 관계형 모델이 더 안전합니다.
스키마가 자주 바뀌는가
- 반정형 데이터나 문서형 데이터가 많으면 문서형 DB가 더 유연할 수 있습니다.
읽기/쓰기 패턴이 어떤가
- 세션, 캐시, 리더보드처럼 단순 키 조회 중심이면 키-값 저장소가 맞을 수 있습니다.
확장성과 일관성 중 무엇이 더 중요한가
- 강한 일관성이 절대적이면 분산 설계의 대가를 감수하더라도 보수적으로 가는 편이 낫습니다.

예를 들면 다음과 같습니다.

주문/결제: RDBMS 우선 검토
세션/캐시: Redis 같은 인메모리 저장소 검토
콘텐츠/카탈로그: 문서형 DB도 후보
대용량 이벤트 로그: 컬럼 계열, 객체 저장소, 분석 저장소 검토

중요한 점은 “한 시스템에 DB 하나”가 아니라, 워크로드별로 저장소 역할을 나눌 수 있다는 점입니다.

RDBMS와 NoSQL 비교

면접에서는 RDBMS와 NoSQL을 단순히 “전통적 vs 최신”처럼 설명하면 약합니다. 각각의 강점을 접근 패턴과 함께 설명해야 합니다.

항목	RDBMS	NoSQL
데이터 모델	테이블, 스키마, 관계 중심	문서, 키-값, 컬럼, 그래프 등 다양
강점	조인, 트랜잭션, 무결성, 복잡한 조회	수평 확장, 유연한 스키마, 특정 패턴 최적화
약점	대규모 분산 쓰기 확장은 더 어렵다	제품별 기능과 보장 수준 차이가 큼
적합한 경우	주문, 결제, 회계, 정형 데이터	세션, 피드, 로그, 반정형 데이터

RDBMS가 유리한 경우는 다음과 같습니다.

여러 테이블 간 관계가 핵심이다
무결성과 트랜잭션이 중요하다
ad-hoc query와 관리 도구가 중요하다

NoSQL이 유리한 경우는 다음과 같습니다.

문서 구조가 유연하다
단순 키 조회나 대규모 분산 읽기/쓰기가 중요하다
관계보다 접근 패턴 최적화가 더 중요하다

다만 다음 점은 꼭 같이 말하는 편이 좋습니다.

RDBMS도 복제와 샤딩으로 확장할 수 있습니다.
NoSQL도 제품에 따라 강한 일관성이나 트랜잭션을 일부 지원합니다.¹
그래서 정답은 “무조건 NoSQL”이 아니라 데이터 구조와 운영 요구에 맞는 선택입니다.

관련 배경은 NoSQL 데이터베이스, 데이터베이스 트랜잭션과 일관성 문서와 이어집니다.
RDBMS와 NoSQL의 구현·운영 차이를 더 자세히 보려면 데이터베이스 스케일링 과 함께 읽는 편이 좋습니다.

읽기 복제본과 쓰기 분리

데이터베이스 설계에서 가장 먼저 검토하는 확장 전략 중 하나는 읽기 복제본(Read Replica) 과 쓰기 분리입니다.²

기본 아이디어는 단순합니다.

primary는 쓰기와 중요한 읽기를 담당합니다.
replica는 읽기 부하를 나눠 가집니다.
조회 API, 백오피스, 통계성 질의는 replica로 보낼 수 있습니다.

항목	장점	주의점
읽기 복제본	조회 부하 분산이 쉽다	replication lag가 생길 수 있다
쓰기 분리	primary 병목을 줄이는 데 도움	라우팅 로직이 복잡해질 수 있다
장애 전환	standby 승격 구조와 연결 가능	승격 시점과 데이터 정합성 확인 필요

여기서 자주 나오는 실무 포인트는 다음과 같습니다.

방금 쓴 데이터를 곧바로 읽는 요청은 replica가 아니라 primary로 보내야 할 수 있습니다.
replica lag 가 큰 상황에서는 오래된 데이터를 보여줄 수 있습니다.
분석성 질의 를 replica로 분리하면 메인 서비스 안정성에 도움이 됩니다.

중요한 점은 읽기 복제본이 읽기 확장 전략이지 쓰기 확장 전략은 아니라는 것입니다.
쓰기 병목이 심해지면 결국 큐, 파티셔닝, 샤딩 같은 더 큰 구조 변화가 필요할 수 있습니다.

즉, 여기서는 “왜 읽기/쓰기 분리를 선택하는가”를 다루고, replica lag 대응과 장애 전환 운영 같은 구현 상세는 데이터베이스 스케일링 문서에서 더 깊게 볼 수 있습니다.

정규화와 비정규화

스키마를 설계할 때 자주 나오는 질문은 정규화(Normalization) 와 비정규화(Denormalization) 사이의 선택입니다.

항목	정규화	비정규화
장점	중복 감소, 무결성 유지, 수정 일관성 확보	조회 속도 향상, 조인 감소, 읽기 최적화
단점	조인이 많아질 수 있음	데이터 중복과 동기화 비용이 생김
적합한 경우	쓰기 정확도와 무결성이 중요한 업무	조회 속도와 응답 단순성이 중요한 업무

정규화가 잘 맞는 경우:

주문, 결제, 정산, 회계 같은 핵심 트랜잭션
데이터 수정의 정확성이 매우 중요함
중복 상태가 치명적임

비정규화가 잘 맞는 경우:

조회가 압도적으로 많음
API 응답을 빠르게 만들기 위해 join을 줄여야 함
검색, 피드, 랭킹처럼 읽기 최적화가 중요함

실무에서는 둘 중 하나만 택하기보다 보통 이렇게 갑니다.

원본 데이터는 정규화 중심으로 설계
읽기 병목이 생기면 캐시나 읽기 모델을 따로 둠
필요한 부분만 선택적으로 비정규화

즉, 좋은 답변은 “정규화가 좋다” 또는 “비정규화가 빠르다”가 아니라
어떤 데이터를 어디까지 정규화할지 경계를 설명하는 것입니다.

인덱스와 스키마 설계의 연결

데이터베이스 설계는 스키마와 인덱스를 따로 보면 안 됩니다.
스키마는 데이터를 어떻게 저장할지 결정하고, 인덱스는 그 데이터를 어떤 질의로 빠르게 읽을지 결정합니다.

면접에서 자주 보는 포인트는 다음과 같습니다.

조회 패턴이 확정되지 않았는데 인덱스를 과하게 만드는 문제
저선택도 컬럼에 단독 인덱스를 거는 문제
정렬, 범위 검색, 조인 키를 고려하지 않은 스키마 설계
API 요구와 인덱스 전략이 연결되지 않는 문제

예를 들어 주문 조회 API가 아래 조건을 자주 사용한다면:

user_id 기준 조회
status 필터
created_at 정렬

스키마를 설계할 때부터 이런 조회 패턴을 염두에 두고 복합 인덱스를 설계해야 합니다.
반대로 조회 패턴과 무관한 인덱스는 쓰기 비용만 늘릴 수 있습니다.

이 지점에서 정규화/비정규화 선택도 연결됩니다.

정규화가 많으면 조인이 늘고 인덱스 전략이 더 중요해집니다.
비정규화를 하면 조인은 줄지만 데이터 중복과 인덱스 유지 비용이 생깁니다.
결국 핵심은 어떤 API와 어떤 쿼리를 가장 자주 실행하는가입니다.

관련 세부 내용은 데이터베이스 최적화 문서와 이어집니다.
실행 계획과 복합 인덱스 설계는 시스템 디자인 문서보다 데이터베이스 최적화 쪽이 더 구현 관점에 가깝습니다.

데이터베이스 설계의 트레이드오프

RDBMS: 무결성과 트랜잭션에 강하지만, 대규모 분산 쓰기에서는 구조가 복잡해질 수 있습니다.
NoSQL: 특정 패턴 최적화와 수평 확장에 유리하지만, 제품별 제약을 정확히 이해해야 합니다.
정규화: 수정 일관성에는 좋지만, 읽기 최적화 관점에서는 조인이 부담일 수 있습니다.
비정규화: 읽기는 빨라질 수 있지만, 데이터 중복과 동기화 비용이 생깁니다.

또한 읽기 복제본과 쓰기 분리는 강력한 전략이지만, 결국 애플리케이션이 데이터 최신성과 일관성 요구를 명확히 알고 있어야 합니다.

좋은 데이터베이스 설계는 “가장 유명한 저장소”를 고르는 것이 아니라,
업무 요구, 데이터 모델, 조회 패턴, 운영 목표를 함께 만족시키는 균형점을 찾는 것입니다.

면접 포인트

데이터베이스 설계는 DB 제품 하나를 고르는 문제가 아니라 저장 전략을 고르는 문제입니다.
RDBMS와 NoSQL은 대체 관계라기보다 문제 유형에 따라 역할이 갈리는 경우가 많습니다.
읽기 복제본은 읽기 확장에 유용하지만, replication lag를 함께 설명해야 합니다.
정규화와 비정규화는 무결성과 조회 성능 사이의 트레이드오프입니다.
좋은 답변은 스키마, 인덱스, API 조회 패턴을 연결해서 설명합니다.