TiDB: AI 에이전트 워크로드를 위한 분산 SQL 데이터베이스
TiDB는 PingCAP이 오픈소스로 공개한 클라우드 네이티브 분산 SQL 데이터베이스로, Go로 작성되었습니다. 이름의 Ti는 티타늄에서 따왔습니다. 데이터 규모와 접근 패턴을 예측하기 어려울 때 단일 노드 데이터베이스는 용량과 가용성의 한계에 부딪히고, 트랜잭션, 분석, 벡터 검색을 서로 다른 시스템에 나누면 데이터 사일로가 생깁니다. TiDB는 2단계 커밋과 Raft 합의로 ACID 트랜잭션과 고가용성을 제공하고, TiKV 행 저장소와 TiFlash 열 저장소로 HTAP을 구현합니다. 컴퓨팅과 스토리지를 분리해 온라인으로 수평·수직 확장이 가능하며 MySQL 8.0과도 호환됩니다. 최신 포지셔닝은 AI 에이전트 워크로드를 겨냥하며 트랜잭션, 분석, 벡터 검색을 기본 지원합니다. 강한 일관성과 탄력적 확장이 필요하고, 업무 DB, 분석 DB, 에이전트 메모리를 하나의 시스템에 담고 싶은 팀에 적합합니다.
배경
단일 노드 MySQL은 트래픽이 몇 배로 뛰면 가장 먼저 한계에 닿습니다. 그러면 팀은 손으로 샤딩을 하거나 애플리케이션 계층에 라우팅 로직을 얹습니다. 이후 보고서용 분석 저장소와 추천용 벡터 저장소가 따로 생기고, 데이터는 여러 시스템 사이를 오가며 저마다 사일로가 됩니다. PingCAP이 오픈소스로 공개한 TiDB는 바로 이 고통의 사슬을 겨냥합니다.
TiDB는 Go로 작성된 클라우드 네이티브 분산 SQL 데이터베이스입니다. 목표는 고가용성, 수평·수직 확장, 강한 일관성, 높은 성능입니다. 이름의 Ti는 티타늄에서 따왔고, 단단하면서 가볍다는 뜻을 담았습니다. 저장소 star는 약 4만 개로, 오픈소스 데이터베이스 커뮤니티의 관심이 작지 않음을 보여 줍니다.
최신 프로젝트 설명은 AI 에이전트 워크로드에 초점을 맞춥니다. 이런 부하는 증가 폭을 예측하기 어렵지만 ACID 보장은 똑같이 필요하고, 트랜잭션과 분석과 벡터 검색이 함께 있어야 합니다. 그래서 TiDB는 단순한 MySQL 대체재나 단일 용도의 분석 엔진이 아니라, 세 가지 요구를 한 번에 받는 기반 계층을 자처합니다.
심층 분석
설계는 네 갈래로 정리됩니다. 첫째는 분산 트랜잭션입니다. 2단계 커밋 프로토콜로 ACID를 보장하며, 트랜잭션이 여러 노드에 걸쳐도 네트워크 분할이나 노드 장애 중에 데이터가 정확해야 합니다. 둘째는 고가용성입니다. Raft 합의 프로토콜로 데이터를 여러 복제본에 두고, 과반수 복제본에 기록된 뒤에야 커밋으로 칩니다. 일부 복제본이 죽어도 강한 일관성과 가용성이 유지되고, 복제본의 지리적 배치를 정해 재해 복구 수준에 맞출 수도 있습니다.
셋째는 탄력적 확장입니다. 컴퓨팅과 스토리지가 분리되어 있어 각각 따로 조절할 수 있고, 노드를 더하거나 단일 노드 자원을 올려도 중단이 없습니다. 샤딩 미들웨어와 달리 분할, 스케줄링, 일관성을 데이터베이스가 직접 맡으므로 애플리케이션은 샤드 규칙을 알 필요가 없습니다.
넷째는 HTAP입니다. 행 저장소 TiKV와 열 저장소 TiFlash라는 두 엔진을 둡니다. TiFlash는 Multi-Raft Learner 프로토콜로 TiKV의 데이터를 실시간 복제해 양쪽을 일치시키고, TiDB Server가 쿼리마다 더 알맞은 엔진을 고릅니다. 분석 쿼리가 오프라인 동기화 파이프라인을 거치지 않으니, 유지할 복사본과 시스템이 하나씩 줄어듭니다.
산업 영향
도입 문턱은 낮게 잡았습니다. MySQL 8.0과 호환되어 익숙한 프로토콜, 프레임워크, 도구를 그대로 쓸 수 있고, 마이그레이션에 코드 변경이 없거나 조금만 필요합니다. MySQL 자산이 큰 팀에는 이 점이 중요합니다. 이전 비용은 데이터베이스 자체보다 드라이버, ORM, 운영 스크립트에 숨어 있기 때문입니다.
배포 선택지도 넓습니다. 퍼블릭 클라우드, 온프레미스, Kubernetes 네이티브 모두 가능하고, TiDB Operator가 Kubernetes에서 클러스터 운영을 자동화합니다. 손을 덜고 싶은 팀은 완전 관리형 TiDB Cloud로 몇 번의 클릭만에 클러스터를 만들 수 있습니다. README에는 빠른 시작, 아키텍처 설명, 기여 가이드, 지원 채널이 갖춰져 있습니다.
에이전트 개발자에게 제시되는 전형적 패턴은 세션 기억, 업무 상태, 벡터 데이터를 같은 SQL 데이터베이스에 두는 것입니다. 일관성은 트랜잭션으로, 권한과 백업은 하나의 정책으로 관리합니다. 시스템이 줄면 데이터 이동과 일관성 문제도 줄어듭니다. 프로젝트 주제 태그에 agent-memory, agent-context가 들어 있다는 점은 PingCAP이 TiDB를 에이전트의 데이터 계층으로 의도적으로 자리매김하고 있음을 보여 줍니다.
전망
위험도 분명합니다. 분산 시스템은 단일 노드 데이터베이스보다 복잡합니다. 2단계 커밋과 다중 복제는 지연을 더하고, 노드 간 트랜잭션 튜닝, 클러스터 운영, 용량 계획에는 팀의 학습 시간이 듭니다. MySQL 호환이 완전한 동일성은 아니므로, 이전하기 전에 공식 호환성 문서를 항목별로 대조해야 합니다.
에이전트 부하에서 벡터 검색이 어디까지 해낼지도 열린 질문입니다. 프로젝트 설명이 아니라 공식 문서와 팀 자체 벤치마크로 확인해야 합니다.
지켜볼 방향은 세 가지입니다. 벡터 검색이 트랜잭션, 분석과 얼마나 깊이 결합할지, 컴퓨팅·스토리지 분리가 클라우드에서 비용을 어떻게 다룰지, 에이전트 기억을 둘러싼 도구가 안정적인 관행으로 자리 잡을지입니다. 그렇게 된다면 업무 데이터, 분석, 에이전트 기억을 한 시스템에 담겠다는 TiDB의 선택은 설득력을 얻을 것입니다.
Sources
FAQ
TiDB는 무엇이며 최신 포지셔닝은 어떤가요?
TiDB는 PingCAP이 공개한 Go 기반 오픈소스 분산 SQL 데이터베이스로 MySQL 8.0과 호환됩니다. 최신 포지셔닝은 AI 에이전트 워크로드이며 트랜잭션, 분석, 벡터 검색을 기본 지원합니다.
트랜잭션, 분석, 벡터 검색을 한 시스템에 담는 것이 왜 중요한가요?
업무, 분석, 벡터 저장소를 나누면 시스템 간 데이터 이동이 필요하고 사일로가 생깁니다. 하나로 합치면 시스템 수와 이동, 일관성 문제가 줄고 에이전트 메모리도 일관되게 관리됩니다.
TiDB 도입 전에 무엇을 확인해야 하나요?
분산 시스템은 단일 노드보다 복잡합니다. 2단계 커밋과 복제로 지연이 늘고 튜닝과 용량 계획도 필요합니다. MySQL 호환성을 사전에 검증하고 벡터 검색은 직접 벤치마크하세요.