472. NewSQL과 구글 스패너 (Google Spanner)

⚠️ 이 문서는 "RDBMS는 완벽하지만 확장(Scale-out)이 안 되고, NoSQL은 무한 확장이 되지만 데이터가 자꾸 틀린다"는 딜레마를 해결하기 위해, **RDBMS의 ACID 트랜잭션과 NoSQL의 무한 확장성을 동시에 달성해 버린 구글의 외계인 고문 기술, 'NewSQL'의 대명사 스패너(Spanner)**를 다룹니다.

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

  1. 본질: SQL과 트랜잭션(ACID)을 완벽하게 지원하면서도, 데이터를 전 세계 여러 대의 서버에 쪼개서(Sharding) 수평 확장할 수 있는 차세대 관계형 데이터베이스다.
  2. 가치: NoSQL처럼 노드만 추가하면 무한히 커지면서도, RDBMS처럼 "A 서버에서 돈 빼고 B 서버에 돈 넣기"를 완벽하게 보장하는 분산 트랜잭션을 제공한다.
  3. 기술 체계: 이 기적을 가능하게 한 구글의 핵심 무기가 바로 GPS와 원자시계를 이용해 서버 간의 시간 오차를 없애버린 **트루타임(TrueTime - 388번 문서)**과, 다수결로 데이터를 안전하게 복제하는 팩소스(Paxos) 알고리즘이다.

Ⅰ. 개요: 딜레마의 파괴 (Context & Necessity)

오랫동안 데이터베이스 세계에는 슬픈 타협이 있었다.

  • RDBMS (MySQL 등): SQL도 되고 조인도 되고 트랜잭션도 완벽해! 하지만 서버를 1대 이상으로 늘리는 건 너무 힘들어. (Scale-up의 한계)
  • NoSQL (MongoDB 등): 서버 100대로 늘리는 거 엄청 쉬워! 하지만 복잡한 조인 쿼리도 안 되고, 돈 계산할 때 가끔 데이터가 꼬일 수 있어. 알아서 해. (Scale-out)

구글은 생각했다. "그냥 둘 다 되는 걸 만들면 안 돼?" 그래서 전 세계 데이터센터에 흩어져 있는 수만 대의 컴퓨터를 엮어서, 마치 내 책상 위에 있는 1대의 완벽한 MySQL처럼 쓸 수 있는 데이터베이스를 만들었다. 이 새로운 종족을 NewSQL이라고 부른다.

📢 섹션 요약 비유: RDBMS가 튼튼하지만 너무 무거워서 혼자서만 조종할 수 있는 **'거대한 철인 28호'**라면, NoSQL은 각자 맘대로 날아다니는 **'수만 마리의 드론 떼'**와 같습니다. NewSQL은 수만 마리의 드론이 공중에서 완벽하게 합체하여 철인 28호처럼 강력한 주먹을 휘두를 수 있게 만드는 **'군집 제어 마법'**입니다.

Ⅱ. 구글 스패너의 2대 마법 무기 ★

스패너가 NewSQL의 끝판왕이 될 수 있었던 근본적인 아키텍처다.

1. TrueTime (트루타임 API) - 글로벌 일관성 보장

  • 문제: 한국 서버와 미국 서버의 시계가 0.1초만 달라도 "누가 먼저 입금했는가?"가 꼬여버린다. (Clock Skew)
  • 해결: 데이터센터 지붕에 GPS 수신기를 달고 서버실에 원자시계를 박았다. 그리고 "한국에서 10시 0분 1초에 기록한 데이터는, 미국에서도 무조건 10시 0분 1초에 기록된 것으로 인정한다"는 완벽한 시간 일치(최대 오차 7ms)를 보장했다.
  • 결과: 거리와 상관없이 전 세계 서버가 완벽하게 일관된(Strong Consistency) 트랜잭션 순서를 가지게 되었다. (388번 문서 참조)

2. Paxos (팩소스) - 무결점 동기화

  • 문제: 서버 한 대가 불타 없어졌을 때 어떻게 멈추지 않고(가용성) 복구할 것인가?
  • 해결: 스패너의 데이터는 무조건 3군데 이상의 다른 데이터센터에 쪼개져서(Sharding) 분산 복제된다. 데이터를 쓸 때는 '다수결 투표 알고리즘'인 Paxos를 써서 "3곳 중 2곳이 성공했다고 하면 무조건 전체 성공으로 치고 넘어가는" 방식을 쓴다.
  • 결과: 서버 1대가 벼락을 맞아도 쿼리는 0.01초도 멈추지 않고 정상 처리된다.

Ⅲ. 실무 활용: NewSQL 시대의 도래

구글 스패너 논문이 발표된 후, 이 철학을 벤치마킹한 오픈소스 NewSQL들이 폭발적으로 성장하고 있다.

  • CockroachDB (바퀴벌레 DB): 구글 내부자들만 쓰던 스패너의 '분산 트랜잭션'과 '생존력'을 오픈소스로 모방하여 만든 훌륭한 대안이다. "핵폭탄이 떨어져도 바퀴벌레처럼 살아남는다"는 뜻이다.
  • TiDB: 역시 MySQL 호환성을 강력하게 지원하며 분산 트랜잭션(NewSQL)을 제공하는 현대적인 데이터베이스다.
┌──────────────────────────────────────────────────────────────┐
│           RDBMS vs NoSQL vs NewSQL의 포지셔닝 비교 시각화          │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│                [ 트랜잭션 안전성 (ACID) ]                        │
│                 ▲                                            │
│   (기존 RDBMS)  │               (NewSQL: 스패너)                 │
│   MySQL, Oracle │               CockroachDB                  │
│                 │                                            │
│                 └──────────────────────────▶ [ 확장성 ]      │
│                                              (Scale-out)     │
│                 (NoSQL)                                      │
│                 MongoDB, Cassandra                           │
│                                                              │
│ ★ 특징: NewSQL은 두 세계의 장점만 꼭대기에서 흡수한 궁극의 아키텍처다.      │
└──────────────────────────────────────────────────────────────┘

Ⅳ. 결론

"물리적 한계를 돈과 하드웨어로 박살 낸 구글의 오만함, 그리고 승리." 분산 시스템 학자들은 CAP 이론(463번 문서)을 들먹이며 "일관성(C)과 가용성(A)을 둘 다 완벽하게 잡는 건 불가능하다"라고 말했다. 구글 스패너는 이 말에 동의한다. 스패너도 네트워크가 끊기면(P) 가용성이 떨어진다. 하지만 구글은 **"네트워크가 아예 안 끊어지게 해저 케이블을 우리가 직접 수백 개 깔면 되잖아? 시계가 다르면 원자시계를 박으면 되잖아?"**라는 무지막지한 하드웨어 인프라 물량 공세로 이론의 한계를 우회해 버렸다. 돈이 지배하는 글로벌 분산 DB 시대에 NewSQL은 기업들이 가장 도달하고 싶어 하는 꿈의 인프라다.

📌 관련 개념 맵

  • 해결 기술 1: TrueTime (클럭 스큐 해결 - 388번 문서)
  • 해결 기술 2: Paxos (팩소스 알고리즘), Raft (라프트 - 더 쉬운 투표 알고리즘)
  • 극복한 이론: CAP 정리 (463번 문서 - 사실상 CA에 가깝게 작동하는 CP 시스템)
  • 비교 아키텍처: NoSQL (Eventual Consistency), 전통 RDBMS

👶 어린이를 위한 3줄 비유 설명

  1. RDBMS는 혼자서 100인분의 요리를 완벽하게 해내는 최고의 천재 셰프예요. (근데 셰프가 아프면 식당이 멈춰요)
  2. NoSQL은 요리를 대충 배운 100명의 알바생이에요. (엄청 빨리 많이 만들 수 있지만, 가끔 요리 맛이 이상할 때가 있죠)
  3. NewSQL(스패너)은 100명의 천재 셰프들이 머리에 텔레파시 기계(트루타임)를 달고 하나처럼 똑같이 움직이며 요리하는 기적의 주방이랍니다!