NewSQL(뉴에스큐엘)
1. 개요
NewSQL은 관계형 데이터베이스(RDBMS)의 강한 일관성과 ACID 트랜잭션, 표준 SQL 인터페이스를 그대로 유지하면서, [[nosql]]이 보여준 수평 확장성(scale-out)과 고가용성을 동시에 달성하도록 설계된 차세대 분산 관계형 데이터베이스 계열을 말한다. 2011년 451 Group의 애널리스트 Matthew Aslett이 "SQL의 보증을 지키면서도 OLTP를 확장하는 신흥 DB"를 지칭하며 처음 명명하였다.
전통적인 데이터 처리 기술은 오랫동안 상충하는 두 축 사이에서 하나를 포기하도록 강요해 왔다. 한쪽에는 수십 년간 검증된 단일 노드 RDBMS가 있다. 정규화된 스키마, 트랜잭션의 ACID 보증, 선언형 SQL이라는 강력한 무기를 제공하지만, 처리량이 한 대의 서버 한계에 부딪히면 더 큰 장비로 바꾸는 수직 확장(scale-up) 외에는 길이 없어 비용과 상한선의 벽에 막혔다. 다른 한쪽에는 2000년대 후반 등장한 NoSQL이 있다. 샤딩을 통한 수평 확장과 고가용성을 손쉽게 얻었지만, 그 대가로 강한 일관성을 결과적 일관성(eventual consistency)으로 완화하고, 다중 행·다중 테이블에 걸친 트랜잭션과 조인, 표준 SQL을 상당 부분 포기했다.
NewSQL은 "확장성을 얻으려면 일관성을 버려야 한다"는 이 오랜 이분법에 정면으로 도전한다. 즉 개발자에게는 변함없이 ACID와 SQL을 제공하되, 그 밑에서는 데이터를 자동으로 분할·복제·동기화하는 분산 시스템을 숨기는 것이 NewSQL의 본질이다. 논술 답안에서 NewSQL은 단순히 "확장되는 RDBMS"로 축소해서는 안 되며, (1) 샤딩·복제를 애플리케이션에 투명하게 감추는 분산 아키텍처, (2) 분산 환경에서도 직렬성(serializability)을 지키는 분산 트랜잭션·합의 메커니즘, (3) NoSQL과 구별되는 SQL·ACID의 보존이라는 세 축으로 서술해야 한다.
가. 등장 배경과 필요성
첫째, 웹 스케일 트랜잭션 수요의 폭증이 결정적 동인이다. 글로벌 전자상거래, 핀테크 결제, 대규모 게임의 과금처럼 초당 수만~수십만 건의 쓰기를 처리하면서도 "주문 중복·이중 결제가 절대 없어야 하는" 업무가 늘었다. NoSQL의 결과적 일관성으로는 이런 금융성 트랜잭션의 정확성을 보장하기 어렵고, 단일 RDBMS로는 처리량을 감당할 수 없어, 둘의 장점을 합친 해법이 절실해졌다.
둘째, NoSQL 운영 경험의 반작용이다. 많은 기업이 확장성을 위해 NoSQL을 도입했으나, 애플리케이션 계층에서 조인·집계·트랜잭션을 직접 구현하는 복잡성과, 결과적 일관성이 유발하는 미묘한 데이터 정합성 버그에 시달렸다. "SQL과 트랜잭션이 그립다"는 현장의 피드백이 NewSQL 수요로 이어졌다.
셋째, 하드웨어·분산 기술의 성숙이 NewSQL을 현실화했다. 대용량 메모리, 빠른 네트워크, 그리고 Paxos·Raft 같은 검증된 분산 합의 알고리즘([[distributed-consensus]])이 보편화되면서, 과거에는 이론에 머물던 "강한 일관성을 유지하는 수평 확장"이 상용 수준으로 구현 가능해졌다. 2012년 구글이 발표한 Spanner 논문은 전 지구적 규모에서 외부 일관성(external consistency)을 달성할 수 있음을 증명하며 이 흐름의 결정적 분기점이 되었다.
2. NewSQL 전체 아키텍처
NewSQL 시스템은 겉으로는 하나의 거대한 RDBMS처럼 보이지만, 내부적으로는 상태를 공유하지 않는(shared-nothing) 다수의 노드가 데이터를 잘게 나눠 분담하는 분산 구조를 갖는다. 핵심 설계 사상은 "SQL 계층과 저장 계층의 분리"다. 애플리케이션은 일반 RDBMS처럼 SQL을 던지고, 그 아래에서 분산 SQL 엔진이 질의를 여러 노드로 쪼개 실행한 뒤 결과를 모은다.
graph TB
APP["애플리케이션(표준 SQL·JDBC)"] --> LB["로드밸런서·게이트웨이"]
LB --> SQL1["SQL 노드(파서·옵티마이저·분산 실행)"]
LB --> SQL2["SQL 노드(파서·옵티마이저·분산 실행)"]
SQL1 --> TXN["분산 트랜잭션 코디네이터(타임스탬프·2PC)"]
SQL2 --> TXN
TXN --> SH1["샤드/레인지 1(Leader + 복제본)"]
TXN --> SH2["샤드/레인지 2(Leader + 복제본)"]
TXN --> SH3["샤드/레인지 3(Leader + 복제본)"]
SH1 -. "Raft/Paxos 복제" .- R1["복제본 A·B"]
SH2 -. "Raft/Paxos 복제" .- R2["복제본 A·B"]
META["메타데이터·배치 관리자(샤드 위치·리밸런싱)"] --> SH1
META --> SH2
META --> SH3
위 구조에서 애플리케이션은 표준 SQL과 드라이버(JDBC/PostgreSQL 와이어 프로토콜 등)로 접속하므로, 기존 RDBMS를 쓰던 코드를 거의 그대로 재사용할 수 있다. SQL 노드는 들어온 질의를 파싱·최적화하여 어느 샤드에 어떤 데이터가 있는지를 메타데이터 관리자로부터 파악한 뒤, 관련 샤드에만 질의 조각을 보내 병렬 실행한다. 저장 계층은 데이터를 키 범위(range) 또는 해시 기준으로 샤드로 나누고, 각 샤드는 다시 Raft/Paxos로 여러 복제본에 동기 복제되어 노드 하나가 죽어도 자동으로 리더가 선출되며 서비스가 끊기지 않는다. 관건은 이 모든 분할·복제·장애 복구가 애플리케이션에 전혀 보이지 않도록 투명하게(transparent) 동작해야 한다는 점이며, 이것이 NewSQL이 [[db-sharding]]을 수동으로 구현하던 과거 방식과 결정적으로 다른 지점이다.
가. 분산 트랜잭션과 합의 메커니즘
NewSQL의 가장 어려운 과제는 여러 샤드에 흩어진 데이터를 수정하는 트랜잭션에서도 ACID를 지키는 것이다. 단일 노드라면 로컬 락과 로그만으로 충분하지만, 데이터가 여러 노드에 흩어지면 "모두 커밋되거나 모두 롤백되는" 원자성을 네트워크 너머로 보장해야 한다. 이를 위해 NewSQL은 전통적 [two-phase-commit]으로 다중 샤드의 원자적 커밋을 조율하되, 각 샤드 내부의 복제는 2PC보다 장애에 강한 Raft/Paxos 합의로 처리하는 2계층 구조를 흔히 쓴다.
여기서 더 미묘한 문제가 격리성(isolation), 특히 직렬성이다. 분산 환경에서는 서로 다른 노드의 시계가 어긋나 "어느 트랜잭션이 먼저인가"를 판정하기 어렵다. 구글 Spanner는 TrueTime이라는, GPS와 원자시계로 오차 범위를 수 ms 이내로 제한한 시간 API를 두어, 커밋 시점에 불확실 구간만큼 의도적으로 대기(commit-wait)함으로써 전역적으로 모순 없는 순서, 즉 외부 일관성을 달성한다. 반면 CockroachDB는 특수 하드웨어 없이 하이브리드 논리 시계(HLC, Hybrid Logical Clock)로 물리 시각과 논리 카운터를 결합하고, 읽기 시 타임스탬프 갱신(read refresh)으로 직렬성(SERIALIZABLE)을 보장한다. 이처럼 "분산 시계를 어떻게 다루느냐"가 각 NewSQL 제품의 정체성을 가르는 핵심 기술 선택이 된다.
나. 샤딩과 자동 리밸런싱의 동작
NewSQL의 수평 확장성은 데이터를 작은 조각으로 나누고, 노드 추가·삭제·부하 변화에 맞춰 그 조각을 자동으로 재배치하는 능력에서 나온다. CockroachDB는 이 단위를 레인지(range), TiDB는 리전(region)이라 부르며, 보통 수백 MB 단위로 쪼개 특정 키 범위를 담당한다. 조각이 너무 커지면 분할(split)하고, 특정 노드에 부하가 쏠리면 다른 노드로 이동(rebalance)하는 전 과정을 시스템이 스스로 수행한다.
graph LR
START["쓰기 유입·데이터 증가"] --> CHK{"레인지 크기/부하 초과?"}
CHK -->|"아니오"| KEEP["현 상태 유지·복제본 동기화"]
CHK -->|"예"| SPLIT["레인지 분할(split)"]
SPLIT --> DECIDE{"노드 간 부하 불균형?"}
DECIDE -->|"예"| MOVE["복제본 이동·리밸런싱"]
DECIDE -->|"아니오"| PLACE["배치 유지"]
MOVE --> RAFT["Raft 그룹 재구성·새 리더 선출"]
PLACE --> RAFT
KEEP --> RAFT
RAFT --> SERVE["무중단 서비스 지속"]
SERVE --> START
위 흐름에서 중요한 것은 리밸런싱이 서비스 중단 없이(online) 일어난다는 점이다. 복제본을 옮길 때도 Raft 그룹에 새 복제본을 먼저 추가해 데이터를 따라잡게 한 뒤 기존 복제본을 제거하므로, 과반수(quorum)가 항상 유지되어 읽기·쓰기가 끊기지 않는다. 예컨대 블랙프라이데이 트래픽 급증 시 노드를 몇 대 추가하면, 시스템이 뜨거운(hot) 레인지를 자동으로 새 노드로 분산시켜 수 분 내에 처리량이 선형에 가깝게 늘어난다 — 이것이 NewSQL이 내세우는 탄력적 확장(elasticity)의 실체다.
3. 핵심 기술 요소
NewSQL이 "확장성과 일관성을 동시에"라는 목표를 달성하기 위해 동원하는 기술은 여러 계층에 걸쳐 있으며, 각각은 독립적으로 발전해 온 분산 시스템 연구의 집약이다. 아래 표는 보조적 정리이며, 각 기술이 "왜 필요한가"는 문장으로 이해해야 한다.
| 계층 | 핵심 기술 | 해결하는 문제 |
|---|---|---|
| 저장·분할 | Range/Hash 샤딩, 자동 리밸런싱 | 데이터·부하의 수평 분산 |
| 복제·가용성 | Raft/Paxos 동기 복제, 자동 장애 조치 | 노드 장애 시 무중단([[database-replication-high-availability]]) |
| 트랜잭션 | 분산 2PC, MVCC([[mvcc-snapshot-concurrency-control]]) | 다중 샤드 원자성·동시성 |
| 시간·순서 | TrueTime, HLC, 타임스탬프 오라클 | 분산 직렬성·외부 일관성 |
| 질의 | 분산 SQL 옵티마이저, 푸시다운 | 표준 SQL을 노드 병렬 실행으로 |
특히 MVCC(다중 버전 동시성 제어)는 NewSQL 성능의 숨은 토대다. 읽기가 쓰기를 막지 않도록 각 행의 여러 버전을 타임스탬프로 관리하면, 장시간 분석 질의가 진행 중이어도 짧은 OLTP 쓰기가 지연 없이 흐를 수 있다. 또한 푸시다운(push-down) 최적화는 필터·집계 연산을 데이터가 있는 저장 노드로 내려보내 네트워크로 옮기는 데이터량을 줄이는 기법으로, 분산 환경에서 질의 성능을 좌우하는 결정적 요소다.
4. NewSQL의 유형 분류
Andy Pavlo와 Matthew Aslett은 2016년 공동 논문에서 NewSQL을 구현 방식에 따라 세 갈래로 분류했는데, 이 틀은 지금도 유효한 서술 기준이다.
첫째, 완전 신규 아키텍처(New Architectures)다. Spanner, CockroachDB, TiDB, VoltDB, YugabyteDB처럼 분산을 전제로 바닥부터 새로 설계한 엔진으로, shared-nothing 구조와 네이티브 분산 트랜잭션을 갖춘다. 가장 순수한 NewSQL이며, 확장성과 일관성 양쪽에서 가장 강력하지만 구현 복잡도와 성숙도 리스크가 크다.
둘째, 투명한 샤딩 미들웨어(Transparent Sharding Middleware)다. Vitess(MySQL 기반, 유튜브가 개발)나 Citus(PostgreSQL 확장)처럼 기존 단일 RDBMS 여러 대 앞단에 샤딩 계층을 두어, 애플리케이션에는 하나의 DB처럼 보이게 하는 방식이다. 검증된 RDBMS 엔진을 재활용해 안정적이지만, 분산 트랜잭션의 강도는 신규 아키텍처만큼은 아니다.
셋째, DBaaS(Database-as-a-Service)다. Amazon Aurora, Google AlloyDB처럼 클라우드 사업자가 스토리지와 컴퓨트를 분리해 관리형으로 제공하는 형태로, 운영 부담을 사업자에게 넘기면서 자동 확장을 누린다.
5. RDBMS·NoSQL·NewSQL 비교
세 계열의 차이는 단순한 기능 나열이 아니라, 각자가 무엇을 지키려고 무엇을 희생했는가라는 설계 철학의 차이로 이해해야 한다.
| 구분 | 전통 RDBMS | NoSQL | NewSQL |
|---|---|---|---|
| 확장 방식 | 수직(scale-up) | 수평(scale-out) | 수평(scale-out) |
| 일관성 | 강한 일관성(ACID) | 결과적 일관성(BASE) | 강한 일관성(ACID) |
| 질의 | 표준 SQL·조인 | 제한적·API 중심 | 표준 SQL·조인 |
| 트랜잭션 | 완전 지원 | 제한적(단일 키) | 분산 트랜잭션 지원 |
| 대표 | Oracle, MySQL | MongoDB, Cassandra | Spanner, CockroachDB, TiDB |
RDBMS가 일관성·SQL을 지키려다 확장성을 희생했다면, NoSQL은 확장성·가용성을 얻으려 일관성·SQL을 희생했다. NewSQL은 "둘 다 지키되, 그 비용을 분산 합의와 네트워크 지연으로 지불"한다 — 즉 공짜가 아니라, CAP 정리의 제약 아래에서 지연시간과 지리적 복제 비용을 치르고 일관성을 사는 전략이다. 따라서 "NewSQL이 무조건 우월하다"는 서술은 틀리며, 지역 분산 환경에서의 쓰기 지연 증가라는 트레이드오프를 반드시 함께 언급해야 한다.
6. 구현 사례 비교
구체적 제품으로 내려가면 설계 선택의 차이가 뚜렷이 드러난다. Google Spanner는 TrueTime 하드웨어(GPS·원자시계)를 전제로 전 지구적 외부 일관성을 달성하며, 구글 광고 시스템(F1)의 수조 원대 트랜잭션을 떠받친다 — 다만 특수 인프라에 묶여 사실상 구글 클라우드 전용이다. CockroachDB는 Spanner에서 영감을 얻었으나 범용 하드웨어에서 HLC로 직렬성을 구현해 어디서든 돌릴 수 있고, PostgreSQL 와이어 호환으로 이식성을 높였다. TiDB는 MySQL 호환 SQL 계층과 Raft 기반 분산 KV인 TiKV를 분리하고, 컬럼 저장 엔진 TiFlash를 더해 [[htap]]까지 아우른다 — 하나의 데이터로 OLTP와 실시간 분석을 함께 처리하려는 점이 특징이다. 국내에서도 대규모 전자상거래·게임·금융 분야에서 TiDB·CockroachDB 도입 사례가 늘고 있으며, 수백 TB급 데이터를 단일 논리 DB로 운영하면서 샤딩 운영 부담을 크게 줄인 보고가 이어진다.
7. 심화: 최신 동향 — "Distributed SQL"로의 재정의와 수렴
최근 업계는 'NewSQL'이라는 다소 모호했던 용어 대신 "분산 SQL(Distributed SQL)"이라는 명칭을 선호한다. 이는 "바닥부터 분산을 전제로 설계하고 표준 SQL·강한 일관성을 제공하는 DB"라는 더 좁고 명확한 범주로, CockroachDB·YugabyteDB·TiDB·Spanner가 스스로를 이 범주로 재포지셔닝하고 있다. 초창기 NewSQL에 포함되던 단순 샤딩 미들웨어나 인메모리 OLTP 제품과 구분하려는 시도다.
두 번째 흐름은 스토리지-컴퓨트 분리와 서버리스화다. CockroachDB Serverless, TiDB Serverless처럼 사용량에 따라 자동으로 0까지 축소·확장되는 과금 모델이 등장해, 중소 규모 서비스도 초기 비용 부담 없이 분산 DB의 이점을 누릴 수 있게 되었다. 세 번째는 HTAP·AI 워크로드와의 수렴이다. 행 저장과 컬럼 저장을 한 시스템에 통합해 운영 데이터에 대한 실시간 분석·벡터 검색을 함께 제공하려는 방향으로, 트랜잭션·분석·AI의 경계가 데이터베이스 안에서 흐려지고 있다. 다만 분산 SQL은 여전히 단일 노드 RDBMS 대비 쓰기 지연이 크고 운영 전문성이 많이 요구되므로, 모든 업무에 맞는 만능 해법은 아니라는 점은 변함없다.
8. 고려사항 및 시사점
첫째, 일관성 요구 수준에 따른 선별 적용이 핵심이다. 글로벌 결제·재고처럼 강한 일관성과 확장성이 동시에 필요한 핵심 OLTP에는 NewSQL이 적합하지만, 단일 리전에서 충분한 업무를 굳이 분산 SQL로 옮기면 쓰기 지연과 운영 복잡성만 늘 뿐이다. "확장성이 실제로 단일 RDBMS의 한계를 넘는가"를 먼저 검증한 뒤 도입을 결정해야 한다.
둘째, 지연시간-일관성-지리적 분산의 트레이드오프를 정량적으로 설계해야 한다. 다중 리전 동기 복제는 네트워크 왕복 때문에 쓰기 지연이 수십 ms 이상 늘 수 있으므로, 데이터의 지역성(locality)을 활용한 배치 정책(지역별 파티셔닝)으로 지연을 제어하는 설계 역량이 성패를 가른다.
셋째, 운영 성숙도와 생태계 리스크를 고려해야 한다. 신규 아키텍처 NewSQL은 상대적으로 역사가 짧아, 장애 대응·백업·모니터링 도구와 숙련 인력이 전통 RDBMS만큼 풍부하지 않다. PoC를 통해 장애 주입(chaos) 시나리오와 업그레이드·마이그레이션 경로를 반드시 검증하고, 벤더 종속(lock-in)과 오픈소스 라이선스 변화 가능성도 함께 점검해야 한다.
넷째, 기존 자산과의 전환·공존 전략이 필요하다. 전면 교체보다 Strangler 방식으로 확장 병목 업무부터 점진 이관하고, 데이터 마이그레이션·CDC 기반 동기화로 무중단 전환을 설계하는 것이 현실적이다. 표준 SQL·PostgreSQL 호환성이 이식 비용을 크게 낮추므로, 제품 선정 시 호환 프로토콜과 마이그레이션 도구의 완성도를 핵심 평가 항목으로 삼아야 한다.
다섯째, 기술사 관점의 전망에서, NewSQL/분산 SQL은 클라우드 네이티브·멀티리전 서비스의 기본 데이터 계층으로 자리 잡아가고 있으며, HTAP·벡터·AI 기능을 흡수하며 "하나의 데이터로 거래·분석·지능"을 처리하는 통합 데이터 플랫폼으로 진화할 것으로 전망된다.
참고자료
- Andrew Pavlo, Matthew Aslett, "What's Really New with NewSQL?" ACM SIGMOD Record (2016): https://db.cs.cmu.edu/papers/2016/pavlo-newsql-sigmodrec2016.pdf
- Google, "Spanner: Google's Globally-Distributed Database" (OSDI 2012): https://research.google/pubs/pub39966/
- CockroachDB Architecture — Transaction Layer: https://www.cockroachlabs.com/docs/stable/architecture/transaction-layer
- PingCAP TiDB Architecture 문서: https://docs.pingcap.com/tidb/stable/tidb-architecture
- Wikipedia, "Distributed SQL": https://en.wikipedia.org/wiki/Distributed_SQL
한 줄 요약: NewSQL(분산 SQL)은 샤딩·Raft 복제·분산 트랜잭션과 TrueTime/HLC 기반의 분산 시계를 통해 RDBMS의 ACID·표준 SQL을 지키면서 NoSQL의 수평 확장성을 달성한 분산 관계형 DB로서, 지연시간·일관성·운영 복잡성의 트레이드오프를 이해하고 핵심 OLTP에 선별 적용하는 것이 관건이다.