무슨 일이냐면
PlanetScale이 'Neki'라는 이름의 샤딩 Postgres를 공식적으로 소개했어요. PlanetScale은 유튜브가 MySQL을 수평 확장하려고 만든 오픈소스 Vitess를 개발한 팀이 세운 회사예요. 오랫동안 MySQL 전문 회사였는데, 2025년에 Postgres 지원을 시작하면서 방향을 넓혔고, 그때부터 'Postgres용 샤딩 시스템을 새로 만들고 있다'고 예고해 온 게 바로 Neki예요. 그 결과물이 이번에 정식으로 이름을 걸고 나온 거죠.
왜 이게 중요하냐면, Postgres는 지금 가장 인기 있는 오픈소스 데이터베이스인데 정작 '한 대로 감당이 안 될 때 어떻게 하느냐'에 대한 답이 아직 깔끔하게 정해지지 않았거든요. MySQL 쪽에는 Vitess라는 검증된 답이 있었고, 그걸 만든 사람들이 Postgres에 같은 걸 만들겠다고 하니까 다들 궁금해하는 거예요.
샤딩이 뭐고 왜 어려운가
샤딩이 뭐냐면, 하나의 거대한 테이블을 여러 대의 데이터베이스 서버에 나눠 담는 거예요. 예를 들어 사용자 ID가 1부터 100만까지는 1번 서버, 100만부터 200만까지는 2번 서버에 두는 식이죠. 이렇게 나누는 기준이 되는 컬럼을 샤드 키라고 불러요. 도서관 책이 너무 많아져서 한 건물에 못 넣으니까 저자 이름 첫 글자로 분관을 나누는 것과 비슷해요.
그런데 서버를 키우는 수직 확장이나, 읽기 전용 복제본을 늘리는 방법과 달리 샤딩은 정말 골치 아픈 문제가 줄줄이 따라와요. 두 샤드에 걸친 데이터를 JOIN해야 하면 어떡하죠? 한 트랜잭션이 두 샤드를 건드리면 하나만 성공하고 하나는 실패할 수도 있잖아요. 이메일 컬럼에 UNIQUE 제약을 걸었는데 샤드가 다르면 중복을 어떻게 잡죠? 자동 증가 ID는 샤드마다 따로 올라가면 겹치고요. 그리고 제일 무서운 건 나중에 샤드를 4개에서 8개로 늘려야 할 때 서비스 안 멈추고 데이터를 옮기는 리샤딩이에요. 그래서 많은 회사가 애플리케이션 코드에서 직접 샤딩을 구현하다가, 이 문제들을 하나씩 다시 발명하면서 몇 년을 보내곤 해요.
Vitess가 했던 방식, 그리고 Neki
Vitess가 유튜브에서 증명한 접근은 '데이터베이스 앞에 똑똑한 프록시를 두자'였어요. 애플리케이션은 MySQL 하나에 접속하는 것처럼 프록시(VTGate)에 붙고, 프록시가 쿼리를 보고 샤드 키를 찾아서 해당 샤드로 보내요. 여러 샤드에 걸친 쿼리는 프록시가 쪼개서 보내고 결과를 합쳐주고요. 각 샤드는 손대지 않은 평범한 MySQL이고, 그 옆에 붙은 에이전트(VTTablet)가 백업이나 복제 상태를 관리해요. 리샤딩은 VReplication이라는 스트리밍 복제로 새 샤드에 데이터를 실시간으로 흘려보내다가 어느 순간 트래픽을 넘기는 방식이었죠.
PlanetScale은 Neki를 두고 'Vitess를 Postgres에 이식한 게 아니라 Vitess에서 배운 것을 바탕으로 처음부터 새로 만든 시스템'이라고 설명해 왔어요. 방향성은 Vitess와 같아요. 애플리케이션 입장에서는 Postgres 프로토콜로 말하는 하나의 엔드포인트만 보이고, 뒤에는 수정하지 않은 진짜 Postgres 여러 대가 샤드로 돌아가고, 샤드 키 기반 라우팅과 무중단 리샤딩을 시스템이 책임지는 구조예요. 다만 Postgres는 MySQL과 내부가 많이 달라요. 데이터 이동은 논리적 복제(logical replication)를 써야 하고, 시퀀스와 확장(extension) 호환성, 트랜잭션 격리 수준 처리 같은 부분은 Postgres에 맞게 다시 풀어야 하죠. 어떤 SQL이 샤드 간에 지원되고 어떤 게 제한되는지, 셀프호스팅이 가능한지 아니면 PlanetScale 관리형으로만 쓸 수 있는지는 공식 소개 글과 문서에서 꼭 직접 확인해 보세요.
경쟁 구도가 재밌어요
Postgres 샤딩 시장은 지금 여러 갈래로 나뉘어 있어요. 가장 오래된 건 Citus예요. Postgres 확장(extension) 형태라서 코디네이터 노드 안에서 동작하고, 마이크로소프트가 인수해서 Azure에서 관리형으로 제공해요. 프록시가 아니라 Postgres 내부에 들어가는 구조라 통합도는 높지만 코디네이터 자체가 병목이 되기 쉽다는 이야기가 있죠. Supabase는 Vitess 공동 창시자인 Sugu Sougoumarane를 영입해서 'Multigres'라는 이름으로 사실상 같은 목표의 프로젝트를 만들고 있어요. Vitess를 만든 사람들이 PlanetScale과 Supabase로 갈라져서 각자 Postgres 샤딩을 만드는 셈이라, 두 프로젝트의 설계 선택을 비교해 보는 것만으로도 공부가 돼요. 그 외에 Rust로 만든 경량 프록시 PgDog, AWS의 Aurora Limitless도 같은 고민의 답이고요.
반대편에는 CockroachDB나 YugabyteDB 같은 분산 SQL이 있어요. 이건 Postgres 호환 프로토콜을 쓰지만 엔진 자체를 처음부터 분산으로 만든 거라 샤딩이 자동이에요. 대신 '진짜 Postgres'가 아니라서 확장이나 세세한 동작에서 호환성 차이가 있고, 트랜잭션 지연도 다르게 나타나요. 지금 업계 흐름은 '진짜 Postgres를 그대로 쓰면서 위에 한 겹 얹어 샤딩하자'는 쪽으로 무게가 실리고 있고, Neki는 딱 그 흐름의 한가운데에 있어요.
한국 개발자에게는
솔직히 말하면 대부분의 서비스는 샤딩이 필요 없어요. Postgres 한 대에 읽기 복제본 몇 개면 꽤 큰 트래픽까지 버티고, 샤딩은 그걸로 안 될 때 마지막에 꺼내는 카드거든요. 쓰기 처리량이 한 대의 한계에 닿거나 테이블이 수 TB를 넘어서 VACUUM이나 인덱스 재구축이 감당이 안 될 때가 그 시점이에요. 국내에서는 커머스나 금융 쪽 대형 서비스들이 이 지점에 도달해서 애플리케이션 레벨 샤딩을 직접 구현하거나 ShardingSphere 같은 미들웨어를 쓰는 경우가 많은데, 그 고통을 데이터베이스 계층이 흡수해 준다면 상당한 개발 비용을 아낄 수 있죠.
당장은 Neki를 프로덕션에 넣기보다, 샤드 키를 어떻게 잡을지 미리 생각해 두는 게 현실적인 준비예요. 나중에 샤딩하게 될 때 가장 아픈 부분이 '샤드 키를 안 넣고 설계한 테이블'이거든요. 테넌트 ID나 사용자 ID가 대부분의 테이블에 들어가 있고, 대부분의 쿼리가 그 컬럼으로 필터링된다면 어떤 샤딩 시스템으로 옮기든 수월해요. 그리고 Neki와 Multigres가 각각 어떤 SQL을 제한하는지 따라가 보면, 분산 데이터베이스 설계의 핵심 트레이드오프를 실전 사례로 배울 수 있어요.
한 줄 정리: Vitess를 만든 팀이 진짜 Postgres 위에 얹는 샤딩 계층 Neki를 내놓았고, Supabase의 Multigres와 함께 'Postgres 수평 확장'의 표준 자리를 두고 경쟁이 시작됐어요.
여러분 서비스는 지금 데이터베이스 한 대로 어디까지 버티고 있나요? 샤딩을 직접 구현해 보신 분이 있다면 가장 후회한 설계 결정이 뭐였는지 궁금해요.
🔗 출처: Hacker News