Perplexity가 검색 제품에 웹 콘텐츠를 공급하는 읽기 경로에서 Amazon DynamoDB를 걷어내고, 자체 키-값 저장소 CobbleDB로 대체했다. Rust로 약 4만 줄 규모다. 회사가 공개한 CobbleDB 연구 자료에 따르면 엔지니어 두 명이 상시 가동되는 코딩 에이전트 수백 개를 지휘해 약 두 달 만에 구축했다. 그중 어떤 에이전트에도 프로덕션 배포를 승인할 권한은 주어지지 않았다.
핵심 요약
- 배치 읽기 지연 시간 중앙값은 DynamoDB의 31.4ms에서 CobbleDB의 5.60ms로 약 82% 줄었다. 99퍼센타일 지연도 123ms에서 24.2ms로 떨어졌다.
- 엔지니어 두 명이 약 두 달간 코딩 에이전트 수백 개를 지휘했고, 아키텍처 결정과 코드 리뷰, 프로덕션 승인은 사람이 그대로 쥐었다.
- Perplexity CEO Aravind Srinivas는 DynamoDB에서 벗어나면 연간 최대 1억 달러를 아낄 수 있다고 밝혔다. 내부 전망은 대규모 운영 시 저장 계층 비용이 DynamoDB보다 20% 이상 낮아진다고 본다.
Perplexity가 DynamoDB를 떠난 이유
방아쇠는 가격과 통제권이었다. Perplexity는 DynamoDB에 필요 이상으로 돈을 쓰면서도 읽기 성능을 원하는 만큼 손볼 여지를 얻지 못했다고 판단했다. 답변 하나를 만들 때마다 저장된 문서를 한꺼번에 여러 건 끌어와야 하는 제품에서 이 제약은 무겁다.
DynamoDB의 과금은 상당 부분 옮긴 바이트 양을 따른다. 이런 모델은 트랜잭션 성격의 작업에는 잘 맞지만, 답변 엔진처럼 넓게 퍼지는 읽기 중심 패턴과는 궁합이 떨어진다. 자사의 접근 형태에 맞춰 전용 저장소를 만들면 범용 관리형 서비스를 비용과 성능 양쪽에서 동시에 이길 수 있다는 것이 Perplexity의 주장이다.
시스템을 어떻게 짰나
Perplexity는 하나의 덩어리를 만드는 대신 각각 따로 손볼 수 있는 세 요소로 일을 나눴다. Pillar는 문서의 내구성을 관리하고 레코드가 바뀔 때마다 버전을 추적한다. Lorry는 들어오는 업데이트를 배치로 묶어 시스템에 밀어 넣는다. CobbleDB 자체는 서빙 계층에 자리 잡고 질의 시점의 저지연 읽기만 전담한다.
내부적으로 CobbleDB는 실제 데이터 트랜잭션을 RocksDB에 의존한다. 팀은 그 위에 조정 가능한 파티셔닝과 캐싱 전략을 얹어 피크 부하에서도 성능을 유지하도록 했다. 공개된 수치를 보면 개선은 중앙값에만 몰리지 않고 분포 전반에 걸쳐 나타났다. 90퍼센타일 지연은 56.7ms에서 9.77ms로 줄었다.
에이전트에게 허용된 것과 막힌 것
업계가 논쟁할 대목은 인력 구성이다. Perplexity는 이번 구축을 엔지니어 두 명에 더해, 세션을 넘나들며 지속적으로 점검하고 후속 작업을 이어간 상시 가동형 AI 에이전트 수백 개의 결과물로 설명했다. Srinivas는 X에 엔지니어 두 명과 상시 에이전트 수백 개가 두 달 만에 만든 DynamoDB 대체품이라고 적었다. 파장이 큰 결정은 사람이 남겨뒀다.
이 경계선은 기술적 한계가 아니라 의도적인 거버넌스다. 에이전트는 코드를 만들고 고쳤고, 엔지니어는 아키텍처를 책임지고 반영될 코드를 검토했으며 실제 트래픽 앞에 무언가를 내보낼 권한을 쥐었다. 인프라를 작성하는 일과 인프라를 운영하는 일을 서로 다른 권한으로 갈라둔 것이다.
OpenAI의 Rust 재작성과 겹치는 지점
구도가 낯익다. 며칠 앞서 OpenAI는 엔지니어 두 명과 Codex가 모든 ChatGPT 데이터 읽기를 떠받치는 서비스를 Rust로 다시 썼다고 밝혔다. 두 곳이 각자 같은 패턴에 도달했다는 점, 즉 아주 작은 사람 팀과 대규모 에이전트 함대, Rust, 그리고 저장소의 핫 패스라는 조합은 이것이 일회성이 아니라 하나의 표준형으로 굳어가고 있음을 시사한다.
Perplexity가 포기한 것
CobbleDB는 DynamoDB의 기능을 그대로 복제한 물건이 아니다. 강한 일관성도, 복잡한 트랜잭션도 지원하지 않는다. 관리형 서비스라면 기본으로 제공하는 것들이다. 검색 색인에 캐시된 웹 문서를 공급하는 용도라면 받아들일 만한 거래이지만, 트랜잭션 보장이 필요한 시스템에는 실격 사유다.
Perplexity는 초당 수십만 건 규모에서 프로덕션 검증을 마치면 CobbleDB를 오픈소스로 공개하겠다고 밝혔다. 다만 공개 시점은 제시하지 않았다. 코드가 공개되기 전까지 지연 시간과 비용 수치는 회사 자체 측정에 기대고 있다.
자주 묻는 질문
CobbleDB는 오픈소스인가
아직 아니다. Perplexity는 초당 수십만 건 규모의 프로덕션 환경에서 검증을 거친 뒤 CobbleDB를 오픈소스로 공개할 계획이라고 밝혔다. 공개 일정은 아직 발표되지 않았다.
CobbleDB가 DynamoDB를 완전히 대체하나
Perplexity 검색 스택에서 웹 콘텐츠를 공급하는 읽기 계층을 대체한 것이지 모든 DynamoDB 용도를 대신하는 것은 아니다. CobbleDB에는 강한 일관성과 복잡한 트랜잭션 지원이 없어, 그런 보장이 필요한 작업에는 후보가 되지 못한다.
코드 중 AI 에이전트가 실제로 쓴 비중은 얼마인가
Perplexity는 약 4만 줄의 Rust 코드에 대해 줄 단위 분석을 공개하지 않았다. 회사는 두 달간의 구현 작업 대부분을 상시 코딩 에이전트 수백 개의 몫으로 돌리면서, 아키텍처와 리뷰, 배포 권한은 엔지니어 두 명이 쥐었다고 설명한다.
