퍼플렉시티는 검색 트래픽 일부를 처리하기 위해 자체 데이터베이스 CobbleDB를 만들었다. 두 엔지니어가 두 달 동안 수백 개의 코딩 에이전트 도움을 받아 개발했으며, 회사는 DynamoDB보다 읽기 지연 시간이 낮고 비용도 적어도 20% 줄 것으로 예상한다.
CobbleDB는 Rust로 작성된 약 4만 줄 규모의 키-값 저장소다. 퍼플렉시티가 측정한 배치 읽기 중앙값 지연 시간은 DynamoDB 사용 당시 31.4밀리초에서 전환 후 5.6밀리초로 낮아졌다. 상위 1% 지연 시간(p99)은 123밀리초에서 24.2밀리초로 줄었다. 다만 두 수치는 같은 트래픽을 대상으로 동시에 비교한 결과가 아니다. DynamoDB 수치는 전환 전, CobbleDB 수치는 전환 후에 기록됐다.
검색 요청은 미리 나눈 문서 조각과 벡터 임베딩을 가져온다. 검색 API 호출 한 번에 페이지 키 100~120개를 10~20개씩 묶어 읽으며, 항목 하나의 평균 크기는 약 50KB다. 퍼플렉시티는 DynamoDB에서 읽기 처리 방식을 제어하기 어렵고, 느린 복제본 하나가 전체 읽기를 지연시킬 수 있었다고 설명했다. 검색·크롤링·재처리 과정에서 발생하는 대량 읽기와 쓰기의 비용도 트래픽과 데이터가 늘면서 부담이 됐다.
새 저장 구조는 세 부분으로 나뉜다. Pillar는 HDD가 탑재된 YTsaurus에 문서 상태와 버전 정보, 조각, 임베딩을 보관한다. Lorry는 변경분을 파티션별 묶음으로 만들어 S3를 거쳐 CobbleDB로 전달한다. CobbleDB는 파티션마다 세 개의 복제본을 두고, 자주 읽는 데이터는 RocksDB를 통해 메모리에 유지하며 나머지는 로컬 NVMe에 둔다. 가능한 경우 같은 가용 영역 안에서 읽고, 복제본이 느리면 다른 복제본을 시도한다. 업데이트도 복제본별로 독립 적용해 한 복제본이 뒤처져도 다른 복제본을 막지 않도록 했다.
퍼플렉시티는 초당 약 20만 건의 요청을 처리할 때 앞서 언급한 지연 시간을 측정했다. 별도의 부하 테스트에서는 성능이 떨어지기 시작하기 전 초당 50만 건에 도달했다. 회사가 평가한 약정 옵션에서 CobbleDB 비용은 DynamoDB보다 적어도 20% 낮았지만, 이 추산에는 데이터베이스를 지원하고 유지하는 데 드는 엔지니어링 비용이 포함되지 않았다. 퍼플렉시티는 CobbleDB를 언젠가 오픈소스로 공개할 계획이다.
코딩 에이전트는 여러 세션에 걸쳐 맥락을 유지하며 복구 가정과 런타임 설정의 문제를 찾아 수정과 테스트를 도왔다. 하지만 에이전트가 데이터베이스를 운영하거나 프로덕션 환경에 접근한 것은 아니다. 설계와 프로덕션 시스템의 통제권은 두 엔지니어가 유지했다. 카네기멜런대 교수 앤디 파블로(Andy Pavlo)는 AI 에이전트가 데이터베이스에서 특히 큰 도전에 직면하는 이유로 프로덕션 데이터의 실수는 되돌리기 어렵거나 불가능할 수 있다는 점을 든 바 있다.
이번 결과는 자체 데이터베이스가 모든 조직에 더 낫다는 뜻은 아니다. 지연 시간 비교는 통제된 동시 시험이 아니며, 예상 절감액도 유지보수 인력을 고려하지 않았다. 퍼플렉시티는 관리형 서비스를 자체 요구에 맞춘 시스템으로 대체했으며, 회사는 이를 AI 보조 개발로 소규모 엔지니어링 팀도 맞춤형 인프라를 구축하기 쉬워질 수 있는 사례로 제시한다. Shopify와 Ramp가 제삼자 모델을 기반으로 자체 코딩 에이전트를 만든 사례도 관련 보도에서 다뤄졌다.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요