먼저 정할 세 가지
이 세 가지에 답하지 못하면 아래의 어떤 표도 쓸 수 없다. 반대로 세 가지에 답하면 후보가 대개 둘셋으로 줄어든다.
원자성 단위
첫 질문은 “트랜잭션이 필요한가”가 아니다. 한꺼번에 성공하거나 한꺼번에 실패해야 하는 데이터 묶음이 레코드 하나로 접히는가다.
MongoDB 공식 문서는 단일 문서 연산이 원자적이라고 명시한다(“In MongoDB, an operation on a single document is atomic”). 그리고 같은 문서가 설계 방향을 직접 권한다 — 임베디드 문서와 배열로 관계를 표현하면 “multi-document transactions are not necessary for many practical use cases”. 즉 원자성 단위를 하나의 레코드 안으로 접는 것은 회피가 아니라 권장 설계다.
이 질문을 먼저 두는 이유는 답이 “접힌다”일 때 트랜잭션 축이 선택에서 사라지기 때문이다. 주문과 주문 항목을 한 문서에 담을 수 있다면 다중 문서 트랜잭션도, 그 트랜잭션의 리전 제약도, 격리 수준 표도 검토할 필요가 없다. 반대로 결제와 재고처럼 서로 다른 수명주기를 가진 데이터를 한 레코드로 묶으면 갱신 경합과 문서 크기 증가를 대신 떠안는다.
판단을 이렇게 쓴다.
| 원자성 단위 | 다음 질문 |
|---|---|
| 레코드 하나로 접힌다 | 트랜잭션 축 종료. 데이터 모델과 조회 패턴으로 넘어간다 |
| 두 레코드 이상이 필요하다 | 일관성 범위를 정한다 |
| 접을 수 있지만 갱신 경합이 심하다 | 쪼갠 뒤 일관성 범위를 정한다 |
일관성 범위
원자성 단위가 접히지 않으면 다음은 어느 경계까지 보장이 필요한지를 정한다. “강한 일관성이 필요하다”로 물으면 답이 나오지 않는다. 같은 레코드인지, 같은 샤드인지, 같은 리전인지, 리전을 넘는지로 물어야 제품이 답할 수 있다.
확인된 경계는 이렇다.
| 필요한 범위 | 확인된 보장 | 제품 |
|---|---|---|
| 단일 레코드 | 원자적 | MongoDB 단일 문서, DynamoDB 단일 아이템 |
| 여러 컬렉션·여러 샤드 | ACID 지원, read/write concern 설정에 따름 | MongoDB |
| 단일 리전 안의 여러 아이템 | 최대 100 아이템·4 MB | DynamoDB TransactWriteItems |
| 리전을 넘는 트랜잭션 | 지원하지 않음 | DynamoDB 글로벌 테이블 |
| 분산 SQL 의 격리 수준 | snapshot isolation | Amazon Aurora DSQL |
DynamoDB 문서는 글로벌 테이블의 한계를 문장으로 못박는다 — 트랜잭션의 ACID 보장은 “only within the AWS Region where the write API was invoked” 이고 글로벌 테이블에서 리전 간 트랜잭션은 지원되지 않는다. 멀티 리전 쓰기를 전제한 설계에서 트랜잭션에 기대고 있었다면, 이 한 문장이 아키텍처를 되돌린다.
한 단계가 더 있다. 트랜잭션 자체의 격리 수준만 보면 부족하다. 그 트랜잭션과 동시에 도는 다른 종류의 연산, 그것의 격리 수준까지 봐야 한다. 실제 사고는 거기서 난다. DynamoDB 는 연산별로 격리 수준이 다르고, 그중 하나는 Serializable 이 아니다. 자세한 표는 아래 “DynamoDB 의 트랜잭션 제약”에 둔다.
성장하는 축
세 번째는 무엇이 커지는가다. 읽기 요청, 쓰기 요청, 누적 데이터량 중 어느 것이 커지는지에 따라 같은 워크로드가 다른 제품으로 간다.
절대 임계값(“몇 TB 를 넘으면 무엇으로 간다”)은 공개된 1차 근거로 제시할 수 없다. 대신 제품이 스스로 밝힌 하한과 상한이 있고, 그것들은 근거로 쓸 수 있다.
- 분석 데이터량의 하한 — ClickHouse 문서는 데이터가 “under ~150 GiB and not growing” 이면 다른 선택지를 보라고 자기 제품의 부적합 조건에 적어 두었다.
- 데이터량의 상한이 라이선스로 정해지는 경우 — ScyllaDB 의 무료 사용은 전체 배치 합산 스토리지 10TB, 50 vCPU 상한 안에서만 허용된다.
- 동시성의 상한이 라이선스로 정해지는 경우 — CockroachDB 는 라이선스 키 없이 운영하면 유예 기간 후 동시 오픈 SQL 트랜잭션이 5개로 스로틀된다.
- 쓰기 수평 확장 — MySQL 계열은 Vitess, PostgreSQL 계열은 PlanetScale Neki 가 이 축을 맡는다. Neki 의 공식 설명은 “Horizontal sharding for Postgres: data topology, query routing, online schema changes” 다.
- 확장을 서비스에 맡김 — Aurora DSQL 은 인프라 관리 없이 컴퓨트·I/O·스토리지를 워크로드에 맞춰 조정한다고 문서에 적는다.
- 읽기 확장과 내구성의 트레이드오프 — Redis 는
replica-read-only yes가 기본이고, 쓰기 가능 복제본은 공식 문서에서 “exist only for historical reasons” 로 설명되며 권장되지 않는다. - 분석 워크로드가 트랜잭션을 침범하지 않게 — TiDB 는 열 저장소 TiFlash 를 행 저장소 TiKV 와 다른 노드에 배치하라고 권고한다.
마지막 두 항목은 순수한 기술 제약이 아니라 라이선스 조항이다. 규모 계획을 세우기 전에 라이선스를 읽어야 하는 이유이고, 아래 “라이선스가 규모 상한을 정하는 경우”에서 다시 다룬다.