에이전트 여러 개가 써도 안 깨지는 DB

혼자 만든 사이드 프로젝트에 에이전트를 두세 개 동시에 붙여서 돌려본 적 있나. 나는 지난 주말에 그랬다가 DB가 먼저 나가떨어지는 걸 봤다.

에이전트 하나가 뭘 읽는 동안 다른 에이전트가 같은 줄을 고쳐버리면 데이터가 꼬인다. SQLite 하나로 버티던 사이드 프로젝트는 이럴 때 제일 먼저 무너지는 부분이다. 그러다 GitHub에서 별 4만 개 넘게 받은 TiDB라는 걸 봤는데, 정체를 알고 나니 이게 딱 이 문제를 겨냥하고 있더라.

TiDB는 분산 SQL 데이터베이스다. '분산'이라는 게 뭐냐면, 데이터를 한 대 컴퓨터에 몰아넣는 대신 여러 대에 나눠 저장해두고 마치 한 대인 것처럼 다루게 해주는 방식이다. '트랜잭션'은 여러 작업을 하나로 묶어서 전부 성공하거나 전부 실패하게 만드는 안전장치인데, TiDB는 이걸 여러 서버에 걸쳐서도 확실하게 보장한다. 그래서 에이전트 여러 개가 동시에 같은 DB를 건드려도 중간에 어중간하게 깨진 상태로 남는 일이 없다.

서버 하나가 갑자기 죽어도 서비스가 안 죽는 이유도 있다. TiDB는 데이터를 여러 벌 복제해서 여러 서버에 나눠두고, 그중 과반수가 살아있으면 계속 돌아가게 만든다. 서버 한 대가 밤중에 뻗어도 내가 자고 있는 동안 알아서 넘어간다는 뜻이다.

예전 같으면 서비스 커질 때마다 DB 서버 새로 파고, 데이터 옮기고, 새벽에 다운타임 잡아놓고 이관 작업했을 거다. TiDB는 노드를 그냥 더 붙이면 서비스 멈추는 것 없이 저장 용량이랑 처리 속도가 같이 늘어난다. 컴퓨팅이랑 저장을 분리해놔서 필요한 쪽만 따로 늘릴 수도 있고.

Claude Code 쪽에서 보면 이건 MCP 서버(클로드에 꽂는 확장 커넥터, 콘센트 멀티탭 같은 것)로 연결해서 쓰기 딱 좋은 그림이다. 전엔 에이전트한테 DB 스키마 짜달라고 하고 나서 직접 콘솔 열어서 쿼리 날려 확인했는데, 이제는 클로드가 MCP로 TiDB에 바로 붙어서 테이블 만들고 데이터 넣고 확인까지 한 번에 끝낸다. 실시간 서비스용 DB랑 나중에 통계 뽑는 분석용 DB를 따로 만들 필요도 없다 — 같은 DB 안에서 둘 다 돌아간다니까(HTAP라고 부르더라).

혼자 사이드로 돌리는 프로젝트에 이 정도 분산 DB가 과한가 싶다가도, 에이전트를 여러 개 굴리는 순간부터는 얘기가 달라지는 것 같다. 어차피 MySQL 문법 그대로 쓸 수 있어서 갈아타는 비용도 크지 않고.

데이터 안 꼬이게 막는 장치 하나가, 에이전트를 몇 대까지 늘릴 수 있는지도 같이 정해주더라.

에이전트 두 개 이상 동시에 돌려본 사람, DB 쪽에서 진짜 문제 난 적 있나? 나는 그날 이후로 트랜잭션 없이는 못 믿겠다.

출처: GitHub — pingcap/tidb