데이터 저장의 세 가지 형태
대부분의 데이터베이스는 세 가지 계열에 속한다. 제품을 외울 필요는 없다 — 어떤 형태가 당신의 문제에 맞는지 알아보면 된다.
| 유형 | 예시 | 적합한 용도 | 트레이드오프 |
|---|---|---|---|
| 관계형 () | PostgreSQL, MySQL, SQLite | 관계가 있는 구조화된 데이터; 돈이나 정확성이 중요한 모든 것 | 스키마를 미리 설계해야 한다; 쓰기를 아주 크게 확장하기는 더 어렵다 |
| 문서형 / | MongoDB, Firestore, DynamoDB | 유연하거나 중첩된 데이터, 빠른 반복, 다양한 레코드 형태 | 일관성 없는 데이터를 만들기 쉽다; 관계와 리포팅이 어색해진다 |
| 키-값 | Redis, Memcached, Cloudflare KV | 캐싱, 세션, 카운터, 알려진 키로 빠른 조회 | 내용으로 쿼리할 수 없다; 보통 신뢰의 원천(source of truth)은 아니다 |
세 가지 형태는 데이터를 진짜로 다르게 저장한다. 나란히 그려 보면 이렇다:
관계형 (SQL) 문서형 (NoSQL) 키-값
행 + 열 독립된 데이터 덩어리 키 1개 → 값 1개
┌────┬───────┬──────┐ ┌──────────────────┐ ┌─────────┬─────────┐
│ id │ email │ name │ │ { │ │ key │ value │
├────┼───────┼──────┤ │ id, email, │ ├─────────┼─────────┤
│ 1 │ a@... │ Ana │ │ name, │ │ session │ "x9f2" │
│ 2 │ b@... │ Bob │ │ posts: [ ... ] │ │ count │ "42" │
└────┴───────┴──────┘ │ } │ └─────────┴─────────┘
테이블이 서로를 └──────────────────┘ 내부를 쿼리 못 함 —
참조한다 모두 중첩되어 있다 키로만 조회한다
관계형 데이터베이스는 서로를 참조할 줄 아는 스프레드시트 묶음이라고 생각하라. 그것과 대화할 때 쓰는 언어가 SQL(Structured Query Language, 구조적 질의 언어)이다. 프로젝트의 90%에 적합한 기본값: 관계형 데이터베이스(Postgres)로 시작하라. 성숙하고 예측 가능하며, 구조를 강제하고, 진짜 앱이 필연적으로 키워나가는 관계를 잘 다룬다. 데이터가 정말로 형태가 없을 때 문서형 저장소를 꺼내고, 키-값 저장소는 보조 계층(캐싱)으로 쓰되 주 저장소로는 쓰지 말라.
피해야 할 함정은 분위기로 고르는 것이다. "NoSQL(SQL 테이블을 쓰지 않는 데이터베이스 — 유연하고 자유로운 형태의 레코드를 저장한다)이 확장성이 더 좋다"는 말은 대부분의 앱이 결코 닿지 않는 좁은 문제 집합에서만 참이고, 그조차도 데이터를 신뢰할 수 있게 만드는 일관성 보장을 포기하는 대가를 치른다. 시스템 설계 영상에서 가장 인상적으로 들리는 형태가 아니라, 당신의 데이터에 맞는 형태를 골라라. 확신이 서지 않으면 관계형이 안전한 선택이다 — 캐시나 문서형 저장소는 나중에 언제든 더할 수 있지만, 엉킨 NoSQL 데이터 모델을 풀어내는 일은 고통스럽다.