안녕하세요, 여러분! 15년 차 백엔드 개발자이자, 여러분과 함께 밤새워 코드를 고민하는 멘토입니다. 오늘 커피는 다들 한 잔씩 하셨나요? ☕ 저는 오늘 유난히 진한 에스프레소가 당기네요. 우리가 다룰 주제가 아주 '진하고 깊은' 맛이 나는 녀석이기 때문입니다.
혹시 관계형 데이터베이스(RDBMS)의 안락함에 젖어 계시다가, NoSQL, 그중에서도 AWS DynamoDB라는 거친 파도를 만나 당황하신 적 없으신가요? 특히 "테이블 하나에 모든 데이터를 다 때려 넣으라고? 그게 말이 돼?"라며 싱글 테이블 디자인(Single Table Design) 전략 앞에서 고개를 갸웃거렸던 경험, 저도 있습니다. 솔직히 고백하자면, 제가 처음 DynamoDB를 접했을 때 RDBMS처럼 설계했다가 3개월짜리 프로젝트를 싹 다 갈아엎고 팀원들에게 피자를 10판 넘게 샀던 뼈아픈 기억이 있습니다. 당시 조회 속도가 200ms를 넘어가며 타임아웃이 발생했고, 결국 구조적 한계에 부딪혔던 것이죠.
하지만 싱글 테이블 디자인을 제대로 적용한 후, 동일한 로직의 응답 속도를 8ms 이하로 줄이는 기적을 경험했습니다. 오늘은 제 경험담을 바탕으로, 왜 싱글 테이블 디자인이 DynamoDB의 꽃인지, 그리고 파티션 키(PK)와 정렬 키(SK)를 어떻게 조합해야 마법 같은 성능이 나오는지 아주 상세하게, 그리고 깊이 있게 이야기해보려 합니다. 단순히 "이렇게 하세요"가 아니라 "왜 이렇게 해야만 하는지" 원리를 파헤쳐 드리겠습니다. 자, 준비되셨나요?
1. 패러다임의 대전환: 데이터 중심에서 쿼리 중심으로
DynamoDB 모델링을 시작하기 전에 우리는 뇌 구조를 조금 바꿔야 합니다. 관계형 데이터베이스(MySQL, PostgreSQL 등)를 다룰 때 우리는 보통 '데이터'를 먼저 봅니다. "사용자가 있고, 주문이 있고, 상품이 있네? 그럼 User 테이블, Order 테이블, Product 테이블 만들고 외래 키(FK)로 연결해야지!"라고 생각하죠. 이것이 바로 정규화(Normalization)입니다. 데이터의 중복을 없애고 정합성을 지키는 것이 지상 과제였습니다.
하지만 DynamoDB의 세계, 특히 싱글 테이블 디자인의 세계에서는 이 순서가 완전히 뒤집힙니다. 데이터를 어떻게 저장할지 고민하기 전에, "누가 이 데이터를 어떻게 조회할 것인가?" 즉, 접근 패턴(Access Patterns)을 먼저 정의해야 합니다. 이 과정 없이 테이블을 만들었다가는 나중에 원하는 데이터를 가져오기 위해 비효율적인 스캔(Scan)을 돌리거나, 코드가 엉망진창이 되는 지옥을 맛보게 됩니다. 데이터를 중복 저장하더라도 읽기 성능을 극대화하는 비정규화(Denormalization)가 핵심 철학입니다.
RDBMS vs DynamoDB 싱글 테이블 디자인 비교
두 데이터베이스 시스템의 차이를 명확히 이해하기 위해 아래 비교표를 준비했습니다. 이 표를 머릿속에 넣어두고 시작해야 합니다.
| 구분 |
RDBMS (Multi-Table) |
DynamoDB (Single-Table) |
| 설계 우선순위 |
데이터 정규화 (중복 제거) |
접근 패턴 최적화 (속도 우선) |
| 데이터 조회 방식 |
JOIN 연산을 통한 테이블 결합 |
Item Collection을 통한 단일 요청 조회 |
| 확장성 (Scaling) |
수직적 확장 (Scale-up, 비용 급증) |
수평적 확장 (Scale-out, 무한에 가까움) |
| 쿼리 유연성 |
높음 (Ad-hoc 쿼리 가능) |
낮음 (설계된 패턴 외 조회 어려움) |
| 성능 특성 |
데이터 양이 늘어나면 느려짐 |
데이터 양과 상관없이 일정함 (O(1)) |
2. 싱글 테이블 디자인의 핵심: Pre-Join과 데이터 지역성
RDBMS에서 우리가 `JOIN`을 사용하는 이유는 무엇일까요? 데이터가 흩어져 있기 때문입니다. 사용자 정보와 그 사용자의 주문 내역을 보려면 두 테이블을 런타임에 합쳐야 합니다. CPU와 메모리를 써서 말이죠. 데이터가 적을 땐 괜찮지만, 트래픽이 폭주하는 블랙 프라이데이 같은 날에는 이 `JOIN` 연산이 DB 서버의 CPU를 100%로 치솟게 만드는 주범이 됩니다. 제가 예전에 맡았던 이커머스 프로젝트에서도 바로 이 조인 연산 때문에 DB가 뻗어서 2시간 동안 장애가 났던 적이 있습니다. 그때 손실액만 수천만 원이었죠.
싱글 테이블 디자인은 이 문제를 해결하기 위해 데이터를 쓸 때 미리 합쳐둡니다(Pre-Join). 즉, 자주 함께 조회되는 데이터는 물리적으로 인접한 위치에 저장하는 것입니다. 이것을 '데이터 지역성(Data Locality)'이라고 합니다. 마치 도서관에서 '해리포터 1권' 옆에 '해리포터 2권'을 꽂아두는 것과 같습니다. 만약 1권은 1층에, 2권은 5층에 있다면 사서가 얼마나 힘들까요? DynamoDB는 파티션 키(PK)를 기준으로 데이터를 모아두기 때문에, 단 한 번의 요청으로 관련된 모든 데이터를 가져올 수 있습니다. 이것이 성능의 핵심입니다.
PK와 SK: 단순한 컬럼이 아닙니다
싱글 테이블 디자인에서는 보통 테이블의 기본 키 이름을 `UserId`나 `OrderId` 같은 구체적인 이름 대신, `PK`(Partition Key)와 `SK`(Sort Key)라는 추상적인 이름으로 짓습니다. 처음엔 이게 정말 어색하실 겁니다. "아니, 이게 무슨 데이터인지 어떻게 알아?"라고 반문하실 수도 있죠. 하지만 이렇게 일반적인 이름을 사용하는 이유는 하나의 테이블에 '사용자', '주문', '상품' 등 전혀 다른 성격의 엔티티들을 모두 담아야 하기 때문입니다.
`PK`는 데이터를 어떤 파티션(물리적 서버 공간)에 저장할지 결정하는 기준이 되고, `SK`는 그 파티션 내에서 데이터를 정렬하고 검색
댓글
댓글 쓰기