58. 뉴에스큐엘 (NewSQL) 및 구글 클라우드 스패너(Spanner)

⚠️ 이 문서는 과거의 단일 서버 RDBMS(오라클, MySQL)가 가진 완벽한 트랜잭션(ACID)과 SQL의 장점을 그대로 유지하면서도, NoSQL(몽고DB, 카산드라)처럼 전 세계 수백 대의 서버로 데이터를 쪼개어 무한히 확장(Scale-out)할 수 있는 'RDBMS와 NoSQL의 완벽한 하이브리드 진화형'인 NewSQL 아키텍처와 그 정점인 구글 스패너(Spanner)의 원자 시계 동기화(TrueTime) 기술을 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: "SQL(JOIN, 트랜잭션)을 포기하고 속도(NoSQL)를 택할 것인가, 속도 확장을 포기하고 정합성(RDBMS)을 지킬 것인가?"라는 수십 년간의 IT 딜레마를 깨부수고, 수천 대의 분산 서버에서도 완벽한 트랜잭션을 보장하는 3세대 데이터베이스다.
  2. 가치: 구글, 넷플릭스 같은 글로벌 서비스가 미국 서버에 있는 고객 잔고 100달러를 차감하고, 동시에 한국 서버에 있는 친구 계좌에 100달러를 더하는 금융 트랜잭션(분산 락)을 수 밀리초(ms) 만에 데이터 유실 없이 무결하게 처리해 낸다.
  3. 기술 체계: 구글 스패너, CockroachDB, TiDB 등이 대표적이며, 데이터가 흩어져 있는 상황에서도 '누가 먼저 썼는지'를 100% 정확히 알아내기 위해 GPS와 원자 시계를 이용한 트루타임(TrueTime) API와 뗏목(Raft) 합의 알고리즘을 사용한다.

Ⅰ. 데이터베이스 진화의 역사: SQL에서 NoSQL, 그리고 NewSQL

"확장성"과 "정합성(트랜잭션)"은 영원히 양립할 수 없는 물과 기름 같았다.

  1. 1세대 RDBMS (스케일업의 한계):
    • 은행의 생명은 ACID(원자성, 일관성, 격리성, 지속성)다.
    • 오라클이나 MySQL은 이 정합성을 완벽히 지키지만, 데이터가 100테라바이트로 커지면 1대의 서버 메모리(Scale-up)를 늘리는 데 수십억 원이 들고 한계에 부딪힌다. (수평적 확장, Scale-out 불가)
  2. 2세대 NoSQL (정합성의 포기):
    • 아마존, 페이스북은 데이터가 너무 커지자, JOIN과 트랜잭션을 깔끔하게 포기했다. (DynamoDB, Cassandra 등)
    • "서버 1,000대에 데이터를 쪼개서 저장하자. A 고객의 '좋아요' 개수가 1초 정도 늦게(Eventual Consistency) 반영돼도 세상이 망하진 않잖아?"
    • 속도와 확장은 잡았지만, 1원이라도 틀리면 안 되는 결제, 금융 시스템에는 NoSQL을 절대 쓸 수 없었다.
  3. 3세대 NewSQL의 탄생:
    • 2012년 구글이 논문으로 발표한 Spanner(스패너)가 세상을 뒤집었다. "수천 대의 서버로 데이터를 찢어(Sharding) 놓았는데, 완벽한 SQL JOIN과 강력한 글로벌 트랜잭션(ACID)이 0.1초 만에 된다고?"

📢 섹션 요약 비유: 과거 은행(RDBMS)은 1명의 완벽한 천재 금고지기에게 모든 돈 계산을 맡겨 속도가 느렸습니다. 인터넷 기업(NoSQL)은 1,000명의 알바생에게 각자 돈을 세게 하고 나중에 장부를 대충 맞추는 꼼수로 속도를 냈습니다. 구글(NewSQL)은 1,000명의 알바생의 뇌를 텔레파시로 실시간 연결해, 1,000명이 동시에 1원짜리 동전 하나까지 완벽하게 장부를 일치시키는(ACID) 외계인 수준의 협동 기법을 발명해 낸 것입니다.

Ⅱ. 분산 트랜잭션의 지옥과 원자 시계(TrueTime)의 해법

"누가 먼저 돈을 보냈는가?" 지구 반대편의 시간을 동기화하라.

  1. 글로벌 분산 락(Lock)의 불가능성:
    • 뉴욕 서버에 있는 A 계좌와 서울 서버에 있는 B 계좌에서 동시에 송금이 일어났다. 이 둘을 하나의 트랜잭션으로 묶으려면(Two-Phase Commit), 전통적인 RDBMS는 지구 반대편에 "너 준비됐어? 락(Lock) 걸어!"라고 물어보느라 수 초가 걸린다 (성능 마비).
  2. 소프트웨어 시계의 배신 (Clock Drift):
    • 두 서버가 "몇 시 몇 분에 돈을 썼다"고 꼬리표(타임스탬프)를 달아 보내지만, 컴퓨터의 내부 시계는 하루에도 수 밀리초씩 오차가 발생한다. 뉴욕의 12시 00분 01초가 서울의 12시 00분 02초보다 사실은 먼저 발생한 일일 수 있다. (분산 시스템의 스플릿 브레인)
  3. TrueTime API (구글 스패너의 무기):
    • 구글은 전 세계 모든 데이터센터의 서버 랙(Rack) 안에 진짜 GPS 수신기와 원자 시계(Atomic Clock) 하드웨어를 박아버렸다.
    • 스패너는 이 하드웨어를 통해 두 서버 간의 시간 오차 범위(불확실성 구간, $\epsilon$)를 정확히 '1밀리초(ms)에서 7밀리초' 사이로 완벽하게 보정하고 예측한다.
    • 트랜잭션을 커밋(Commit)할 때 딱 이 최대 오차 시간(7ms)만큼만 잠깐 숨을 멈추고 기다렸다가(Wait) 쓰면, 전 세계 어느 노드에서 읽어도 100% 최신(가장 나중에 쓰인) 데이터만 조회된다는 수학적 증명(External Consistency)을 완성해 냈다.

📢 섹션 요약 비유: 뉴욕의 육상 선수와 서울의 육상 선수가 동시에 출발할 때, 각자 찬 싸구려 전자시계가 1초씩 달라서 누가 먼저 들어왔는지 판정(트랜잭션 순서)할 수 없는 개판이 벌어집니다. 구글은 전 세계 경기장마다 수십억짜리 0.0001초 오차의 원자 시계를 강제로 달아놓고, "심판이 0.007초만 늦게 출발 총성을 울리면(Wait), 모든 선수의 기록이 절대 틀리지 않는다(TrueTime 보장)"는 우주적 규모의 타이밍 꼼수를 써서 분산 DB를 완성했습니다.

Ⅲ. NewSQL 생태계와 도입의 한계 (Trade-off)

구글의 마법을 오픈소스로 흉내 낸 수많은 후발 주자들이 등장했다.

  1. 오픈소스 NewSQL의 약진 (CockroachDB, TiDB):
    • 구글처럼 돈이 많지 않은 기업들은 원자 시계를 살 수 없다.
    • 대신 소프트웨어적인 논리적 시계 동기화(NTP 개조)와 뗏목(Raft) 합의 알고리즘을 극도로 튜닝하여, 바퀴벌레(Cockroach)처럼 서버를 밟아 죽여도 살아남는 강력한 오픈소스 분산 RDBMS 생태계를 만들었다.
  2. 과도한 인프라 오버헤드:
    • NewSQL은 여전히 일반 단일 MySQL(RDBMS)보다 단건 쿼리의 지연 시간(Latency)이 미세하게 느리다. (합의를 거쳐야 하므로)
    • 데이터가 1TB도 안 되는 작은 스타트업이 무턱대고 "최신 기술이다!"라며 NewSQL 클러스터를 세팅하면 배보다 배꼽이 더 커진다. (서버 관리 비용 폭증)
  3. 도입의 스위트 스팟 (Sweet Spot):
    • 수십 테라바이트 이상의 트랜잭션 데이터를 감당하면서(NoSQL 수준의 확장), 글로벌 금융 결제나 게임 아이템 거래처럼 단 1개의 데이터도 틀리면 안 되는(RDBMS 수준의 강결합) 초대형 엔터프라이즈 환경에서만 그 진가를 발휘한다.

📢 섹션 요약 비유: 동네 작은 분식집(단일 MySQL)에서 라면을 끓이는데 굳이 미국, 중국 지점의 주방장들과 화상 회의로 0.01초 단위 레시피 합의(NewSQL 트랜잭션)를 거쳐 요리할 필요는 없습니다. NewSQL은 초당 10만 건의 결제가 쏟아지는 글로벌 메가뱅크나 알리바바 급의 초거대 기업만이 감당하고 가치를 뽑아낼 수 있는 슈퍼카 엔진입니다.