NoSQL — 스키마가 사라진 것이 아니라 책임이 옮겨 간 것

한 줄 요약

NoSQL 은 관계형의 상위 호환이 아니라 특정 제약을 포기하고 특정 능력을 얻는 거래이며, 무엇을 포기했는지 모르고 고르면 그 대가를 나중에 치른다.

왜 이게 필요했나

관계형 데이터베이스는 강력하지만 몇 가지를 전제한다. 스키마가 미리 정해져 있고, 데이터가 한 대에 들어가거나 적어도 조인이 가능한 범위 안에 있으며, 강한 일관성이 필요하다는 전제다.

2000년대 후반 웹 서비스들이 이 전제를 하나씩 못 지키게 되면서 다른 선택지가 나왔다. 핵심 동기는 수평 확장이었다. 한 대를 더 크게 만드는 대신 여러 대에 나누려면 조인과 트랜잭션 같은 기능이 걸림돌이 되었고, 그것을 포기한 설계들이 등장했다.

어떻게 동작하나

부류별 성격은 이렇게 갈린다.

| 부류 | 데이터 모델 | 강점 | 대가 |
| --- | --- | --- | --- |
| 키값 | 키 하나에 값 하나 | 단순 조회가 매우 빠름 | 값 내부로 질의 불가 |
| 문서 | JSON 유사 문서 | 스키마 유연, 한 문서에 다 담아 조회 | 문서 간 조인과 정합성은 앱 책임 |
| 와이드 컬럼 | 행 키 + 컬럼 패밀리 | 대량 쓰기, 시계열 | 질의 패턴을 미리 정해 설계해야 함 |
| 그래프 | 노드와 간선 | 관계 탐색 | 대량 집계는 약함 |

여기서 가장 널리 퍼진 오해를 짚어야 한다. "스키마가 없다"는 말은 스키마가 사라졌다는 뜻이 아니라 스키마를 강제하는 주체가 데이터베이스에서 애플리케이션으로 옮겨 갔다는 뜻이다. 필드 이름을 오타 낸 문서가 조용히 들어가고, 몇 달 뒤 그 필드를 읽는 코드가 조용히 실패한다. 데이터베이스가 막아 주던 것을 이제 코드 리뷰와 테스트가 막아야 한다.

CAP 도 자주 오용된다. 네트워크 분단이 실제로 일어난 순간에 일관성과 가용성 중 무엇을 고를지의 문제이지, 평상시에 셋 중 둘을 고르는 이야기가 아니다. 분단이 없을 때는 대부분의 시스템이 둘 다 제공한다.

현장에서 만나는 모습

선택의 기준은 유행이 아니라 질의 패턴이다. 몇 가지 실용적인 신호가 있다.

여러 엔티티를 조합해 보는 질의가 자주 바뀐다면 관계형이 여전히 유리하다. 문서 저장소는 저장할 때 정해 둔 형태로만 잘 읽힌다.
한 번 쓰고 그 형태 그대로 자주 읽는다면 문서 저장소가 자연스럽다.
캐시나 세션처럼 키로만 접근한다면 키값 저장소가 맞다.
관계의 깊이를 따라가는 질의(친구의 친구, 권한 상속)라면 그래프가 압도적으로 낫다.

그리고 현대 관계형 데이터베이스가 상당 부분을 흡수했다는 점도 감안해야 한다. PostgreSQL 의 jsonb 는 문서 저장소의 유연성을 상당히 제공하면서 트랜잭션과 조인을 유지한다. 다만 남용하면 안 된다. 조회하거나 정렬하거나 제약이 필요한 필드는 컬럼으로 승격하고 나머지 원본만 jsonb 에 남기는 것이 실용적인 경계다. jsonb 안의 값에는 정확한 통계가 없어 플래너의 행 수 추정이 어긋나고, 그 결과 조인 방식 선택이 틀어지기 때문이다.

이어지는 퀴즈에서 확인할 것

각 부류가 무엇을 포기하고 무엇을 얻는지, 그리고 "스키마 없음"이 실제로 무엇을 뜻하는지 설명할 수 있는지 확인한다.