View
PlanetScale 무료티어가 사라진 이후 개발자 커뮤니티에서 "Vitess를 직접 띄우자"는 글이 슬슬 보이기 시작했다. 다만 Vitess가 무엇이냐고 물으면 대부분 "MySQL 샤딩 도구?" 정도로만 알고 있는 듯하다. 사실 Vitess는 단순한 샤딩 도구가 아니라, 유튜브가 14년째 운영하고 있는 MySQL 클러스터 매니저이다. 슬랙, Square, GitHub, HubSpot 같은 곳들이 핵심 인프라에서 사용하고 있으며, CNCF에서 2019년에 졸업한 8번째 프로젝트이기도 하다.
이번 글에서는 Vitess가 정확히 무엇인지, 어떤 회사들이 실제 프로덕션에서 사용하고 있는지, 왜 2024~2025년에 갑자기 다시 화제가 되었는지를 한 번에 정리한다. 마지막에는 "그래서 우리 회사도 도입해야 하는가?"에 대한 솔직한 답까지 적어두었다.
Vitess란 무엇인가, 한 줄로 정리하면 MySQL 클러스터 매니저
출처: vitess.io
Vitess는 한마디로 MySQL을 수평확장 가능한 분산 데이터베이스로 바꿔주는 시스템이다. MySQL 위에 얇은 레이어를 깔아 여러 대의 MySQL 인스턴스를 마치 한 덩어리처럼 다룰 수 있게 해준다.
핵심 컴포넌트는 네 가지이다.
- VTGate: 쿼리 라우터. 애플리케이션이 MySQL 프로토콜로 여기에 접속한다. 어느 샤드에 쿼리를 보낼지 결정한다.
- VTTablet: 각 MySQL 인스턴스 앞에 붙는 프록시. 쿼리 보호, 풀링, 백업 등을 담당한다.
- VTctld: 컨트롤 플레인. 샤드 분할, 마이그레이션 같은 운영 작업을 처리한다.
- Topology Service: etcd, Consul, ZooKeeper 중 하나를 사용해 클러스터 메타데이터를 저장한다.
애플리케이션 입장에서는 그저 MySQL에 접속하는 것처럼 보인다. 드라이버를 바꿀 필요도, ORM을 교체할 필요도 없다. 이것이 Vitess의 가장 큰 무기이다. CockroachDB나 TiDB 같은 NewSQL은 결국 새로운 DB로 갈아타야 하지만, Vitess는 기존 MySQL 생태계를 통째로 살려준다.
CNCF 졸업 프로젝트라는 사실은 단순한 인증 마크가 아니라, 운영 안정성, 거버넌스, 보안, 커뮤니티 활성도가 모두 검증되었다는 의미이다. 쿠버네티스, 프로메테우스, 헬름과 동일한 등급에 속한다.
유튜브가 만들고 14년째 운영 중인 프로젝트
출처: YouTube > Google Cloud Tech
Vitess의 시작은 2010년이다. 유튜브가 폭발적으로 성장하면서 MySQL 단일 인스턴스로는 도저히 버틸 수 없는 상황이 왔다. 당시 선택지는 두 가지였다. 하나는 NoSQL로 갈아타는 것이고, 다른 하나는 MySQL을 직접 샤딩하는 것이었다.
유튜브 팀은 후자를 선택했다. 이유는 단순했다. 이미 트랜잭션, 정합성, SQL 쿼리에 의존하는 코드가 산더미였고, NoSQL로 전환하면 그것을 모두 다시 작성해야 했다. 그렇게 만들어진 것이 Vitess의 전신이다.
타임라인을 정리하면 다음과 같다.
- 2010년: 유튜브 내부 프로젝트로 시작
- 2012년: 오픈소스로 공개
- 2018년 2월: CNCF 인큐베이션 진입
- 2019년 11월: CNCF 졸업 (8번째 졸업 프로젝트)
- 2024년: v20.x 안정화, MySQL 8.0 호환성 강화
창시자 Sugu Sougoumarane는 PlanetScale을 공동 창업하면서 Vitess 상용화를 본격적으로 추진하기 시작했다. 구글이 자사 인프라를 오픈소스로 공개한 이유는 명확하다. 클라우드 네이티브 시대에 자사 표준을 깔아두면 인재 풀이 넓어지고 생태계가 커지므로 결국 구글에 이익이 된다. 쿠버네티스와 동일한 전략이다.
흥미로운 점은 유튜브가 여전히 Vitess를 핵심 인프라에서 운영하고 있다는 사실이다. 수천 개의 샤드, exabyte급 데이터를 처리하는 인프라가 14년째 동일한 시스템 위에서 돌아가고 있다. 이것이야말로 진정한 검증이다.
실제 도입 기업들, Vitess 성공 사례
이론보다 실제로 누가 사용하는지를 보면 그 기술이 진짜인지 아닌지 답이 나온다. Vitess 도입 기업 리스트는 GitHub 리포지토리의 ADOPTERS.md에 정리되어 있는데, 이름을 보면 다소 놀라게 된다.
슬랙, 수백 TB MySQL을 무중단으로 이전한 사례
슬랙은 2017년부터 Vitess 도입을 시작해 2020년에 99% 마이그레이션을 완료했다. 현재 슬랙은 3000개가 넘는 Vitess 샤드, 1PB가 넘는 데이터, 1조+ row를 운영하고 있다. 이는 슬랙 메시지 데이터베이스 전체를 거의 무중단으로 이전했다는 의미이다.
슬랙 엔지니어링 블로그에는 "Scaling Datastores at Slack with Vitess"라는 글이 게시되어 있는데, 마이그레이션을 실시간 트래픽 분산으로 처리한 과정이 상세히 기술되어 있다. VReplication 기능을 사용해 기존 MySQL에서 Vitess 클러스터로 데이터를 흘려보내고, 점진적으로 트래픽을 이전해갔다. 다운타임 없이 이를 해낸 것이야말로 Vitess의 진가를 보여준 사례이다.
Square (Block), Cash App 인프라에 적용
Square(현 Block)는 2017년 11월 Cash App에 Vitess의 첫 샤드 분할을 적용했고, 그 이후 Cash App의 핵심 데이터스토어로 사용하고 있다. P2P 결제는 절대 다운타임이 발생해서는 안 되고 데이터 정합성도 100% 보장되어야 하는 영역인데, 거기에 Vitess를 도입했다는 사실은 신뢰도가 충분히 검증되었음을 의미한다. Square 엔지니어링 팀은 Vitess 컨트리뷰터로 활동하면서 Online DDL, 스키마 마이그레이션 같은 기능 개선에 직접 기여했다.
HubSpot, 1000+ MySQL 클러스터 통합 사례
HubSpot은 2017년부터 Vitess 얼리 어답터로 도입을 시작했다. 이 사례가 다소 특이한데, 각 환경에서 운영 중인 1000개가 넘는 MySQL 클러스터를 통합하는 것이 목적이었다. 기존에는 클러스터마다 별도의 운영팀이 필요했고, 백업, 모니터링, 장애 대응이 모두 분산되어 있어 운영 비용이 어마어마했다. Vitess로 묶은 결과 운영이 표준화되고 인프라 비용도 절감되었다.
GitHub, Etsy, Pinterest 등의 사례
- GitHub: 메타데이터 일부에 Vitess를 사용. 2018년부터 적용.
- Etsy: 검색 카탈로그 인프라에 Vitess를 적용.
- Pinterest: 일부 서비스 데이터에 Vitess를 도입.
- JD.com: 중국 이커머스 거대 기업, 대규모 트랜잭션 처리에 사용.
- Stitch Labs, Nozzle 등: 중소 SaaS들도 다수 도입.
PlanetScale, Vitess로 창업한 사례
PlanetScale은 다소 특별한 위치에 있다. Vitess 창시자가 만든 회사이며, Vitess를 매니지드 서비스로 판매하는 것이 사업 모델이다. 2018년에 창업해 개발자 커뮤니티에서 폭발적으로 화제가 되었다. 무엇보다 "MySQL이지만 분산 가능"이라는 포지션이 통했다.
다만 PlanetScale이 2024년 초에 무료티어를 종료하면서 사용자들이 대거 이탈했고, 그 사용자들이 "직접 Vitess를 띄우자"는 방향으로 움직이면서 오히려 Vitess 본체에 대한 관심이 더 커졌다. 아이러니한 상황이다.
2024~2025년에 Vitess가 다시 부상하는 이유는 무엇인가
출처: dzone.com
Vitess는 사실 14년 된 기술인데, 왜 갑자기 지금 다시 화제인가? 네 가지 이유가 겹쳤다.
1. PlanetScale 무료티어 종료 사건
2024년 초에 PlanetScale이 무료티어를 종료하면서 개발자 커뮤니티가 다소 시끄러워졌다. 그동안 PlanetScale의 마케팅 효과로 Vitess 인지도가 올라간 상태였는데, 무료티어가 사라지자 "그렇다면 직접 Vitess를 깔자"는 흐름이 생긴 것이다. Hacker News, 긱뉴스에 관련 글이 자주 올라왔다.
2. AI/SaaS 붐으로 인한 데이터 폭증
2023~2024년 AI SaaS 스타트업들이 우후죽순 등장하면서 멀티테넌시와 스케일을 동시에 해결해야 하는 상황이 많아졌다. 테넌트별로 데이터를 격리하면서 전체 인프라는 효율적으로 운영해야 한다. Vitess의 샤딩 모델은 이 케이스에 거의 정확히 부합한다. 테넌트 ID로 샤딩 키를 잡으면 자동으로 분산되고, 큰 테넌트는 별도 샤드로 분리할 수도 있다.
3. Aurora, RDS 한계에 부딪힌 기업들
AWS Aurora가 단일 라이터 한계로 인해 버티지 못하는 케이스가 늘어났다. Aurora도 훌륭한 DB이지만 결국 single primary 구조이기 때문에 쓰기 처리량에 천장이 존재한다. 그 한계에 부딪힌 회사들이 대안을 찾다가 Vitess를 만나는 흐름이 형성되었다. 비용 측면에서도 Aurora는 데이터가 커질수록 비싸지는 구조이므로, 큰 테이블을 가진 곳은 Vitess가 유리하다.
4. 쿠버네티스 환경에서의 stateful 표준화
쿠버네티스는 stateless 워크로드는 잘 처리해왔지만 stateful은 오랫동안 약점이었다. 2023년부터 Vitess Operator가 GA 수준으로 안정화되면서, 쿠버네티스 위에서 데이터베이스를 운영하는 표준이 점점 자리잡고 있다. 컨테이너 환경에서 MySQL 클러스터를 운영하려면 Vitess가 거의 유일한 현실적 답이다.
Vitess vs TiDB vs Aurora, 분산 DB 비교
출처: mcobject.com
vs TiDB / CockroachDB, MySQL/PostgreSQL 호환 깊이의 차이
TiDB와 CockroachDB는 처음부터 분산을 가정하고 만든 NewSQL이다. SQL 호환성을 제공하지만 결국 별개의 DB이다. 기존 MySQL 코드, ORM, 마이그레이션 도구를 모두 검증해야 한다. 일부 기능은 동작하지 않기도 한다.
Vitess는 "진짜 MySQL"이다. 인스턴스 자체가 MySQL이며, Vitess는 그 위의 라우팅/관리 레이어이다. 따라서 ORM 호환성이 압도적으로 우수하고, 운영 노하우도 그대로 사용할 수 있다. 단점은 본격적인 분산 트랜잭션이 약하다는 점이다. cross-shard 트랜잭션은 사실상 불가능하다고 봐도 무방하다.
vs Aurora, 멀티 라이터와 비용 구조
Aurora는 매니지드 서비스이므로 운영이 편하다. 다만 단일 라이터 구조여서 쓰기 처리량에 천장이 있고, 데이터가 커지면 비용이 폭증한다. Vitess는 운영 부담이 크지만 멀티 라이터 구조라 쓰기 스케일이 자유롭다. 자체 호스팅하면 비용도 훨씬 저렴하다.
vs MongoDB / NoSQL, 트랜잭션 보존 여부
NoSQL은 스케일이 용이하지만 트랜잭션, JOIN, 정합성을 모두 양보해야 한다. Vitess는 "MySQL을 그대로 사용하면서 스케일까지 확보하는" 포지션이므로 트랜잭션, 외래키 일부, ACID가 모두 살아있다. 결제, 주문 같은 정합성이 중요한 도메인에서 NoSQL을 사용할 수 없는 곳은 Vitess가 답이다.
그렇다면 우리도 도입해야 하는가, 솔직한 답변
여기서부터가 진짜 중요하다. 결론부터 말하면 대부분의 한국 스타트업은 도입하지 않아도 된다. 다만 어떤 케이스에서는 정확한 답이 되기도 한다. 케이스별로 나누어 보았다.
도입해야 하는 케이스
- 단일 MySQL 인스턴스로는 도저히 버틸 수 없는 데이터량 (수십 TB 이상)
- 멀티테넌트 SaaS이면서 테넌트별 격리가 필요한 경우
- Aurora, RDS 비용이 월 수천만 원을 넘어가서 자체 호스팅으로 전환해야 하는 상황
- 이미 MySQL 생태계에 깊이 묶여 있어 NewSQL로 갈아타기가 부담스러운 경우
- 쿠버네티스 환경에서 DB까지 통합 운영하려는 경우
- 운영 인력이 충분한 곳 (DBA, SRE 풀타임 최소 2~3명)
도입하지 않아도 되는 케이스
- 데이터 1TB 이하: MySQL 한 대로 충분하다. 인덱스를 잘 설계하고 슬로우 쿼리를 잡으면 된다.
- 인력이 부족한 스타트업: Vitess 운영은 진짜 까다롭다. 컴포넌트만 4개이고, 토폴로지 서비스까지 합치면 5개이다. 장애가 발생했을 때 디버깅이 가능한 인력이 없으면 위험하다.
- 트래픽이 읽기 위주인 서비스: 읽기 스케일은 MySQL 리플리카로도 충분히 가능하다.
- 쓰기가 그렇게 많지 않은 곳: 단일 MySQL의 쓰기 처리량은 생각보다 크다. 실제 한계에 부딪힌 후에 도입을 고민해도 늦지 않다.
도입 비용과 학습 곡선의 솔직한 평가
운영 복잡도는 매우 높다. VTGate, VTTablet, VTctld, Topology Service를 모두 이해해야 하고, VReplication, Reshard 같은 워크플로우에도 익숙해져야 한다. 한국에는 사례도 적고 전문가도 거의 없어 영문 문서를 읽고 GitHub 이슈를 뒤져야 한다.
마이그레이션 자체도 가볍지 않다. 슬랙은 3년이 걸렸고, HubSpot도 2년 넘게 소요되었다. 작은 회사 기준으로도 최소 6개월~1년은 잡아야 한다.
다만 일단 자리잡고 나면 운영이 표준화되고 스케일이 자유로워진다는 점은 확실하다. PlanetScale 같은 매니지드 옵션도 존재하고, 자체 호스팅 가이드도 점점 개선되고 있다. 결국 "지금 우리에게 필요한가"의 문제이다.
Vitess가 분산 DB의 표준이 되는 이유
정리하면 다음과 같다. Vitess는 갑자기 부상한 것이 아니라 14년 동안 묵묵히 검증된 기술이며, 2024년에는 PlanetScale 사건, AI SaaS 붐, Aurora 한계, 쿠버네티스 stateful 표준화 같은 외부 요인이 동시에 터지면서 다시 주목받고 있다. 핵심을 정리하면 다섯 줄이다.
- 유튜브가 14년째 운영 중인 검증된 시스템이다
- MySQL 호환성 덕분에 기존 생태계를 그대로 활용할 수 있다
- 슬랙, Square, HubSpot 같은 거대 기업들이 핵심 인프라에 도입했다
- 쿠버네티스 + AI SaaS 시대의 데이터 스케일 요구에 거의 정확히 부합한다
- 운영 복잡도가 높아 작은 팀에는 오버스펙이지만, 일정 규모를 넘으면 다른 선택지가 거의 없다
결국 Vitess는 MySQL을 버릴 수 없는 회사들의 답이다. NewSQL로 갈아타기에는 코드가 너무 묶여 있고, NoSQL로 가기에는 트랜잭션이 필요하며, Aurora는 비싸거나 한계에 부딪힌 곳들. 이 자리를 정확히 채워주는 시스템이 Vitess이며, 그래서 시간이 갈수록 더 표준이 되어가는 흐름이다.
도입 결정은 진짜 신중하게 내려야 한다. 일단 데이터가 1TB를 넘고 운영 인력이 갖춰져 있다면 한 번 검토할 가치가 있다. 그 이하라면 MySQL을 잘 튜닝해서 사용하는 것이 답이다. 다음 글에서는 Vitess를 로컬에서 직접 띄우고 샤딩 테스트를 하는 방법을 정리할 예정이다. 관심이 있다면 기다려주길 바란다.
참고 자료:
'Database' 카테고리의 다른 글
| Citus 샤딩이 깨졌을 때, 할 수 있는 방법과 사례들을 정리한다 (0) | 2026.04.30 |
|---|---|
| RocksDB란 무엇이며 왜 다들 사용하는가 (0) | 2026.04.30 |
| Postgres는 테이블 락만 가능한가? 아니면 행 단위 락도 가능한가? 결론부터 정리한다 (0) | 2026.04.28 |
| StarRocks는 무엇이며 왜 이렇게 주목받는가? 토스와 네이버까지 도입한 이유 정리 (0) | 2026.04.28 |
| Postgres로 메시지 큐까지 돌려본 결과, 생각보다 쓸만하다 (0) | 2026.04.18 |
