From Monolithic Systems to Distributed Database Architecture

편집자 주: 이 글은 빌 켄달이 PingCAP 재직 당시 작성한 글입니다. 원래 2022년 1월에 게시되었으며, TiDB의 에이전트 상태 스택을 반영하여 2026년 8월에 업데이트되었습니다.

핵심 요약

단일 머신, 단일 장애 영역, 그리고 규모를 확장할수록 가파르게 증가하는 비용 곡선이라는 명확한 한계에 부딪힙니다.

분산 데이터베이스 아키텍처는 규모를 키우는 대신 확장하여, 장애를 허용하고 자동으로 재조정되는 노드에 데이터를 분산시킵니다.

분산 SQL은 트랜잭션, 조인 및 관계형 모델링을 해당 아키텍처 위에 유지하므로 정확성을 희생하지 않고도 확장성을 확보할 수 있습니다.

AI 에이전트도 지금 같은 문제에 직면해 있습니다. 영구적인 메모리, 상태 정보, 파일은 별도의 시스템이 아닌 분산 기반을 필요로 합니다.

많은 데이터 관리 엔지니어들처럼 저도 오라클로 경력을 시작했습니다. 실용적인 선택이었죠. 오라클은 성숙하고 안정적이며 기능이 풍부해서, 빠르고 대규모의 수직 확장이 가능한 시스템을 구축할 수 있었습니다. 데이터베이스에 더 많은 리소스가 필요해지면 더 큰 시스템으로 확장했고, 최종적으로는 오라클의 대표적인 엔지니어드 시스템인 엑사데이터까지 사용했습니다.

그러다 클라우드 시대가 도래했고, 그동안의 모든 작업의 근간을 이루었던 가정이 더 이상 유효하지 않게 되었습니다. 분산 데이터베이스 아키텍처는 더 이상 제가 책에서 읽는 주제가 아니라, 제 업무가 되었습니다. 저는 수년간 대규모 온프레미스 애플리케이션과 그 데이터베이스를 클라우드 인프라로 이전하는 작업을 해왔는데, 데이터베이스 이전이 항상 가장 어려운 부분이었습니다. 이러한 경험을 통해 저는 클라우드로의 전환이 단순히 스타일적인 선호가 아니라는 확신을 갖게 되었습니다. 확장성이 요구되고, 여러 지역에 걸쳐 운영되어야 하며, 장애 발생 시에도 온라인 상태를 유지해야 하는 모든 워크로드에는 분산 아키텍처가 가장 적합한 설계 방식입니다.

이 글을 처음 쓴 지 4년 후, 다른 영역에서 똑같은 변화가 다시 일어나고 있습니다. AI 에이전트들이 2014년 제 애플리케이션들이 부딪혔던 것과 같은 문제에 직면한 것입니다. 바로 자신들이 알고 있는 정보를 영구적으로 저장할 공간이 없다는 것입니다. 이 글은 제가 오라클에서 분산 SQL로 전환하게 된 과정과, 앞으로 이 길이 어디로 향할지에 대한 이야기입니다.

단일체 데이터베이스 아키텍처가 당시에는 효과적이었던 이유

모놀리식 데이터베이스 아키텍처는 컴퓨팅과 스토리지를 단일 서버에 배치하고 수직적으로 확장합니다. 하나의 머신이 데이터를 저장하고, 옵티마이저를 실행하고, 트랜잭션을 처리하고, 일관성을 유지합니다. 용량이 부족해지면 더 큰 머신을 구입합니다. 수십 년 동안 이것이 정답이었는데, 왜 더 이상 충분하지 않은지 설명하기 전에 그 이유를 먼저 살펴보는 것이 중요합니다.

기존 관계형 데이터베이스는 대체로 예측 가능한 워크로드를 위해 구축되었습니다. 일반 원장, ERP 시스템 또는 주문 입력 시스템은 사용자 수, 최대 사용량, 그리고 성장 곡선을 정확히 알고 있었고, 데이터베이스 관리자는 1년 치 예산을 미리 계획할 수 있었습니다. 컴퓨팅과 스토리지를 단일 노드에 집중시키면 이러한 워크로드를 더 쉽게 분석할 수 있었습니다. 트랜잭션은 정확히 한 곳에 커밋되었고, 일관성은 프로토콜의 속성이 아니라 시스템의 속성이었습니다. 튜닝, 백업 및 용량 계획은 모두 단일 목표를 향했습니다.

오라클 스타일의 엔터프라이즈 환경은 이러한 모델을 거의 한계까지 끌어올렸습니다. 엑사데이터는 데이터베이스를 특수 목적에 맞게 설계된 스토리지 및 네트워킹과 결합하여 10년 전만 해도 방 하나를 가득 채울 만큼의 하드웨어가 필요했을 워크로드를 하나의 시스템으로 처리할 수 있도록 했습니다. 저는 그런 시스템을 많이 구축해 봤고, 실제로 잘 작동했습니다. 워크로드가 하나의 시스템에 적합하고 시스템이 잘 설계되었다면, 확장성은 여전히 가장 간단하고 종종 가장 저렴한 아키텍처입니다.

단일체형 데이터베이스 자체가 잘못 설계된 것은 아닙니다. 다만 그 안에서 작업 부하의 형태가 변했을 뿐입니다.

단일 시스템이 한계에 도달하기 시작하는 지점

단일 시스템은 작업 부하가 하나의 머신에 더 이상 감당할 수 없게 되면 무너지며, 아무리 튜닝을 해도 이를 해결할 수 없습니다. 수직 확장은 구매 가능한 가장 큰 서버에 의해 결정되는 엄격한 한계가 있으며, 그 한계에 도달하는 비용 곡선은 선형적이지 않습니다. 용량의 마지막 증분은 항상 가장 비쌉니다.

애플리케이션을 클라우드로 이전하는 것은 비교적 간단했습니다. 지리적으로 분산시킬 수 있었고, 대부분의 고객은 이미 클라우드 네이티브 방식으로 설계되어 수평적으로 분산된 마이크로서비스 아키텍처를 사용하고 있었기 때문입니다. 하지만 오라클 데이터베이스는 훨씬 어려웠습니다. 처음부터 수직 확장을 염두에 두고 설계되었기 때문입니다. 규모를 키울 수는 있었지만, 클라우드 환경에서 요구하는 만큼 수평적으로 확장할 수는 없었습니다. 기존의 관계형 데이터베이스 시스템이 핵심 업무 애플리케이션의 병목 현상을 일으키고 있었기에, 저는 과감한 방향 전환을 해야 했습니다.

제가 참여했던 마이그레이션 프로젝트들에서 공통적으로 나타나는 오류 유형은 다음과 같습니다.

하드웨어 천장. 일단 사용 가능한 가장 큰 인스턴스에 접속했다면, 남은 유일한 방법은 애플리케이션을 다시 작성하는 것뿐입니다.
수직적 규모의 비용. 용량을 두 배로 늘릴 때마다 비용이 더 많이 들고, 24시간 내내 피크 시간대 요금을 지불해야 합니다.
가용성 위험. 단일 기본 서버는 단일 장애 지점입니다. 페일오버는 쓰기 작업이 중단되는 시간 간격을 의미합니다.
운영상의 복잡성. 하나의 노드 샤드를 초과하는 팀은 라우팅, 리밸런싱 및 샤드 간 조인을 애플리케이션 코드에 직접 푸시하여 수동으로 처리합니다.
글로벌 애플리케이션 수요. 세 대륙에 걸쳐 한 지역의 데이터를 읽는 사용자는 요청할 때마다 해당 지역에 대한 서비스 요금을 지불합니다.
혼합 작업 부하. 트랜잭션 기반 기본 데이터에 대한 분석은 두 가지 모두의 성능을 저하시키므로 대부분의 팀은 데이터 웨어하우스를 추가하고 수십 분 정도의 지연을 감수합니다.

이러한 기술적인 문제들은 오래가지 않습니다. 수동 샤딩은 릴리스 속도를 늦추고, 최대 용량으로 프로비저닝된 하드웨어는 비용을 증가시키며, 장애 조치 시간은 고객에게 직접적인 영향을 미치는 문제로 이어집니다. 결국 아키텍처가 제품의 성능 한계를 결정짓는 것입니다.

분산 데이터베이스 아키텍처는 어떤 변화를 가져올까요?

분산 데이터베이스 아키텍처는 데이터와 쿼리 처리를 하나의 논리적 데이터베이스처럼 동작하는 여러 노드에 분산시킵니다. 서버를 교체하여 규모를 확장하는 대신 노드를 추가하면 시스템이 데이터를 노드 간에 재분배합니다. 이러한 단일 변화, 즉 스케일 업이 아닌 스케일 아웃은 가용성, 샤딩 및 일관성 작동 방식 전반에 영향을 미칩니다.

2014년 초, 저는 구글 연구소에서 새로 발표한 논문을 받았습니다., Spanner: 구글의 전 세계에 분산된 데이터베이스. 그것은 밀집된 것을 묘사했습니다. 분산 데이터베이스 하나의 데이터 센터 또는 여러 데이터 센터에 걸쳐 데이터를 저장할 수 있었습니다. 데이터는 자동으로 샤딩되었고, 복사본은 클러스터 전체에 분산 및 균형 조정되었습니다. 애플리케이션은 어떤 노드에든 연결하여 어떤 데이터에든 접근할 수 있었습니다. 노드를 추가하거나 제거하여 양방향으로 확장할 수 있었습니다. 제가 읽어본 설계 방식 중 데이터베이스를 제 애플리케이션이 이미 처리되고 있는 방식과 동일하게 처리하는 첫 번째 사례였습니다.

라벨보다는 작동 방식이 더 중요합니다.

수평적 확장 및 데이터 분산. 데이터 세트는 노드에 분산된 범위로 나뉘며, 클러스터는 노드가 참여하거나 제거될 때 부하를 분산시키기 위해 범위를 이동합니다.
자동 샤딩. 분할 및 배치 작업은 애플리케이션 코드가 아닌 데이터베이스 내부에서 수행됩니다.
복제 및 내결함성. 각 범위는 여러 개의 복제본을 유지합니다. TiDB의 경우 Raft라는 합의 프로토콜이 범위별로 리더를 선출하여 노드 하나가 다운되더라도 클러스터가 계속 서비스를 제공할 수 있도록 합니다.
컴퓨팅과 스토리지의 조정. SQL 계층과 스토리지 계층을 분리하면 각 계층이 자체적인 축으로 확장할 수 있으므로 탄력적인 용량 관리가 실용화됩니다.
일관성 모델. 최종 일관성은 구축 비용이 저렴하지만 이해하기 어렵습니다. 강력한 일관성을 유지하려면 조정이 필요하지만 정확성을 보장합니다.
운영 탄력성. 롤링 업그레이드, 노드 교체 및 지역 장애는 더 이상 변경 관리 이벤트가 아닌 일상적인 작업이 됩니다.

단일형 아키텍처 vs. 분산형 아키텍처

두 아키텍처를 나란히 놓고 보면, 생산에 중요한 거의 모든 측면에서 차이가 있습니다.

차원	단일체 건축	분산 아키텍처
스케일링 모델	규모를 확장하세요. 더 큰 서버로 교체하세요.	확장하세요. 노드를 추가하고 클러스터가 재균형을 맞추도록 하세요.
데이터 배치	한 대의 기기에 한 부씩 저장하고, 백업 및 대기용으로도 사용합니다.	데이터는 여러 노드에 분산 및 복제됩니다.
실패 영역	서버는 장애 복구 도메인입니다. 서버에 장애가 발생하면 페일오버 또는 시스템 다운이 발생합니다.	노드는 장애 도메인입니다. 클러스터는 살아남은 복제본을 통해 서비스를 계속 제공합니다.
용량 상한	당신이 구입하고 감당할 수 있는 가장 큰 기계입니다.	실질적으로는 특정 머신 하나가 아니라 클러스터 크기에 의해 제한됩니다.
혼합 작업 부하	분석 기능은 거래 기능과 동일한 리소스를 놓고 경쟁하거나, 별도의 데이터 웨어하우스로 이동합니다.	행 기반 및 열 기반 저장소는 동일한 클러스터에서 트랜잭션과 분석을 모두 처리할 수 있습니다.
운영 모델	하나의 인스턴스를 최적화하세요. 용량이 부족해지면 애플리케이션 계층에서 수동으로 샤딩하세요.	클러스터를 관리하세요. 샤딩, 리밸런싱 및 장애 조치는 데이터베이스 내부에서 이루어집니다.

분산 SQL의 부상

분산 SQL은 분산 데이터베이스 아키텍처의 한 분야로, 데이터를 노드에 분산시키면서 SQL, 관계형 모델링 및 트랜잭션 일관성을 유지합니다. 이는 더 넓은 범주인 분산 데이터베이스보다 한 단계 아래에 위치합니다. 모든 분산 SQL 데이터베이스는 분산 데이터베이스이지만, 모든 분산 데이터베이스가 트랜잭션과 조인을 제공하는 것은 아닙니다.

이러한 차이가 발생하는 이유는 분산 시스템의 초기 물결이 확장성을 확보하기 위해 관계형 모델을 버렸기 때문입니다. NoSQL 스토어는 실제 문제를 해결했고, 추가 작업이 많거나 스키마가 느슨한 워크로드에는 여전히 적합한 도구입니다. 하지만 많은 팀이 깨달은 것은 없어서는 안 될 중요한 것들을 포기했다는 사실입니다. 다중 행 트랜잭션은 애플리케이션 코드로 이동하여 미묘한 버그의 원인이 되었습니다. 임시 쿼리를 실행하려면 두 번째 시스템이 필요했습니다. 참조 무결성은 보장이 아닌 관례가 되었습니다. 지급 장부나 재고 관리 시스템에서 "쓰기 작업이 제대로 수행되었을 가능성이 높다"는 답변은 받아들일 수 없습니다.

SQL이 살아남은 이유는 관계형 모델이 기업이 데이터를 설명하는 방식에 잘 맞고, 30년 동안 축적된 툴, 드라이버, ORM, 그리고 풍부한 인력 풀 덕분입니다. 분산 SQL은 이러한 표면적인 장점은 유지하면서 그 아래 실행될 내용을 바꾸려는 시도입니다. 즉, 익숙한 관계형 의미론과 ACID 트랜잭션을 기반으로 수평 확장이 가능하고 노드 손실에도 견딜 수 있는 아키텍처를 구현하는 것입니다.

PingCAP에서는 분산 SQL의 핵심인 멀티 노드 자동 샤딩 아키텍처를 기반으로 Spanner 및 기타 분산 SQL 데이터베이스가 제공하는 것보다 더 뛰어난 유연성을 제공하도록 확장했습니다. 그 데이터베이스가 바로 그것입니다. 티DB오픈 소스 MySQL 호환 분산 SQL 데이터베이스입니다. MySQL 와이어 프로토콜 호환성은 의도적인 선택입니다. 이는 기존 애플리케이션, 드라이버 또는 DBA 워크플로가 데이터베이스와 통신하는 방법을 이미 알고 있도록 하기 위함입니다.

TiDB 분산 데이터베이스 아키텍처 설계 원칙

TiDB는 단순히 분산형이라는 레이블을 붙이는 데 그치지 않고 위에서 설명한 속성들을 실제로 구현합니다. 2015년, 저희 창립자들은 대규모의 활발한 팀과 함께 TiDB를 처음부터 개발했습니다. GitHub의 오픈 소스 커뮤니티, 클라우드 네이티브 분산 SQL 아키텍처를 구축하기 위한 일련의 설계 원칙에 따라 작업했습니다. 핵심 원칙은 다음과 같습니다.

복잡하지 않게 확장 가능. 이 데이터베이스는 운영자 개입 없이 수평 확장이 가능합니다. 노드가 클러스터에 참여하면 TiDB가 자동으로 데이터를 재분배합니다. 인(in) 확장도 동일한 방식으로 작동합니다.
회복탄력성은 항상 활성화되어 있습니다. TiDB는 노드 장애가 발생하더라도 애플리케이션이 살아남은 노드에서 트랜잭션 처리를 계속하므로 복구 시간이 거의 0에 가깝습니다.
일관된 ACID 트랜잭션. 트랜잭션 시스템에서는 항상 최신의 정확한 데이터 복사본을 읽어야 합니다. 이는 금융 서비스 및 재고 관리에서 특히 중요합니다. TiDB는 트랜잭션 수준에서 높은 수준의 격리를 보장하여 데이터 일관성을 유지합니다.
OLTP 및 OLAP 워크로드 모두 지원합니다. 많은 분산 SQL 데이터베이스는 트랜잭션 트래픽만 처리합니다. TiDB는 대규모 집계 및 분석 함수를 처리하기 위해 행 기반 저장소와 함께 컬럼 기반 저장소인 TiFlash를 추가하여 트랜잭션, 분석 및 혼합 워크로드를 지원합니다. 이는 하이브리드 트랜잭션/분석 처리(HTAP) 방식이며, 비용 기반 옵티마이저가 각 쿼리에 어떤 저장소를 사용할지 결정합니다.
공통 API 인터페이스. TiDB는 개발자를 위해 개발자가 만든 데이터베이스이므로, 널리 사용되는 SQL 인터페이스를 통해 접근할 수 있습니다. 애플리케이션 개발자와 데이터베이스 관리자가 현재 프로덕션 환경에서 가장 널리 사용되는 SQL 프로토콜 중 하나인 MySQL을 활용할 수 있도록 MySQL과의 호환성을 선택했습니다.
어디든 설치하고 실행하세요. 데이터베이스는 온프레미스, 단일 클라우드 또는 여러 클라우드에 걸쳐 VM 또는 Kubernetes를 사용한 컨테이너 방식으로 배포될 수 있습니다. 배포 아키텍처는 조직의 요구 사항 변화에 따라 변경될 수 있습니다.

원칙을 실용화하는 운영상의 특징

설계 원칙에 따라 강력한 데이터베이스를 구축할 수 있으며, 운영 기능 덕분에 팀에서 실제로 운영할 수 있습니다. TiDB는 Prometheus와 Grafana는 물론 내장된 TiDB 대시보드를 통해 풍부한 메트릭과 모니터링 기능을 제공합니다. 역할 기반 접근 제어와 TLS 암호화는 전송 중인 데이터와 저장된 데이터를 안전하게 보호합니다. 내장된 비동기 변경 데이터 캡처 기능은 클러스터에서 데이터를 가져오고 내보내는 작업을 효율적으로 처리하여 마이그레이션 및 하위 시스템 데이터 전송에 도움을 줍니다. TiDB Cloud 동일한 아키텍처를 사용하지만 관리형 서비스로 운영하는데, 이것이 오늘날 대부분의 팀이 시작하는 방식입니다.

AI 에이전트에게 분산 데이터베이스 아키텍처가 중요한 이유

AI 에이전트는 기본적으로 상태를 저장하지 않습니다. 이는 기존의 모놀리식 데이터베이스가 남긴 아키텍처적 한계와 같습니다. 모델 호출은 입력을 받아 출력을 반환합니다. 마지막 호출에 대한 정보는 전혀 저장되지 않습니다. 컨텍스트 창은 메모리처럼 보이지만, 사실은 버퍼입니다. 즉, 특정 세션에 한정되고, 프로세스가 종료되면 사라집니다. 어제 6시간 동안 실행된 에이전트는 오늘 다시 시작할 때 이전 실행에 대한 아무런 정보도 가지고 있지 않습니다.

제작 담당자는 녹취록 이상의 것이 필요합니다. 충족해야 할 조건은 다음과 같은 범주로 나뉩니다.

이전 세션에서 학습한 사실과 선호도는 기기와 사용자 간에 유지되어야 합니다.
세션 및 작업 기록을 통해 상담원은 자신이 무엇을 언제 왜 했는지에 대한 질문에 답할 수 있습니다.
도구 출력 및 중간 결과물은 재생성하는 데 비용이 많이 들고 여러 단계를 거쳐야 합니다.
파일 및 아티팩트: 실행 중에 생성된 저장소, 생성된 코드, 로그 및 문서.
임베딩을 소스, 버전 및 액세스 규칙과 연결하는 검색 메타데이터입니다.

해당 상태에 대해 두 가지 접근 패턴이 실행되며, 둘 다 제대로 작동해야 합니다. 에이전트는 필터, 조인 및 트랜잭션을 사용하여 정확한 조회를 수행해야 합니다. 즉, 어떤 사용자가 이 레코드를 소유하고 있는지, 이 단계를 이미 실행했는지 등을 파악해야 합니다. 또한 정확한 키를 아무도 모르는 경우 의미론적 검색도 필요합니다. 단일 에이전트 턴에서 이 두 가지 모두가 필요한 경우가 많습니다.

일반적인 해결책은 시스템들을 서로 연결하는 것입니다. 레코드 저장을 위해 PostgreSQL을, 임베딩 저장을 위해 벡터 데이터베이스를, 파일 저장을 위해 객체 스토리지를, 세션 상태 저장을 위해 Redis를 사용합니다. 하지만 모든 경계는 일관성 문제를 야기합니다. 메모리가 수정, 대체 또는 삭제될 때, 변경 사항이 모든 곳에 반영되지 않으면 에이전트는 오래된 정보를 기반으로 작동하게 됩니다. 이것이 바로 우리가 시스템을 다루는 이유입니다. 에이전트의 메모리와 상태를 데이터베이스 문제로 보는 관점 검색 추가 기능이 아니라, 분산 SQL 데이터베이스를 사용하는 것입니다. 네이티브 벡터 검색 구조화된 레코드, 임베딩 및 검색 가능한 텍스트를 한 곳에 저장하고, 단일 쿼리로 하이브리드 검색을 실행하며, 가변 메모리 트랜잭션 보장을 제공할 수 있습니다.

TiDB 에이전트 상태 스택: 0, mem9 및 drive9

TiDB 에이전트 상태 스택은 세 개의 계층으로 구성되어 있으며, 이 계층들이 함께 에이전트에 영구적인 상태를 제공합니다. 이 모든 것은 TiDB 기술에 의해 구동됩니다. TiDB Cloud. TiDB Cloud Zero는 즉각적인 SQL 상태를 제공하고, mem9는 영구 메모리를 제공하며, drive9는 파일을 위한 영구 작업 공간을 제공합니다. 이들은 하나의 백엔드를 공유하므로 배포 규모가 커지더라도 메모리, 운영 기록, 검색 메타데이터, 파일 및 실행 기록이 지속적으로 연결된 상태를 유지합니다.

TiDB Cloud 제로를 사용하여 즉시 SQL 상태를 설정합니다.

TiDB Cloud 제로 가입이나 설정 없이 단 몇 초 만에 실제 MySQL 호환 TiDB Cloud 데이터베이스를 프로비저닝할 수 있는 솔루션입니다. 등록 절차나 클러스터 크기 조정이 필요 없습니다. 인스턴스는 TLS로 보호되며 조인, 트랜잭션, 표준 SQL은 물론 네이티브 벡터 검색 및 전체 텍스트 검색을 지원하므로 에이전트는 임베딩을 관계형 데이터와 함께 저장하여 시스템에 분산시키지 않고 관리할 수 있습니다.

Zero 인스턴스는 설계상 30일의 수명을 가진 일회용 인스턴스입니다. 이는 에이전트 세션, CI 실행, 데모 및 프로토타입에 적합합니다. 프로토타입을 영구적인 버전으로 발전시키고 싶을 때는 단 세 번의 클릭만으로 인스턴스를 영구적인 TiDB Cloud Starter 데이터베이스로 전환하고 데이터와 스키마를 그대로 이전할 수 있습니다. Zero는 MCP 서버 또는 사용자 지정 에이전트 도구의 데이터베이스로도 효과적으로 사용할 수 있습니다. Zero 자체는 MCP 서버가 아니지만, MCP 도구에 필요에 따라 프로비저닝할 수 있는 SQL 백엔드를 제공합니다. TiDB Cloud Zero는 현재 공개 미리 보기로 제공되고 있습니다.

mem9는 영구 에이전트 메모리용입니다.

mem9 AI 에이전트를 위한 영구 메모리 계층입니다. 코딩 에이전트, 사용자 정의 도구 및 다중 에이전트 시스템에 세션, 머신 및 사용자 간에 유지되는 공유 메모리 공간을 제공하여 한 에이전트가 학습한 내용을 다음 에이전트에서 사용할 수 있도록 합니다. 벡터 유사도와 키워드 검색을 동일한 쿼리에서 결합하는 하이브리드 검색을 지원하며, 임베딩을 서버 측에서 생성하므로 별도의 임베딩 파이프라인을 실행할 필요가 없습니다.

API 표면보다 더 중요한 두 가지 설계 결정이 있습니다. 첫째, mem9는 메모리를 단순한 저장소가 아닌 시스템으로 취급합니다. 인지 메모리는 수정, 대체, 만료 및 삭제되기 때문에 데이터 수집, 중복 제거, 순위 지정, 검색 및 평가가 모두 시스템의 일부입니다. 변경 가능한 메모리는 강력한 일관성을 필요로 하며, 이것이 바로 TiDB Cloud에서 실행되는 이유입니다. 둘째, 메모리를 검사할 수 있습니다. mem9 인터페이스를 통해 에이전트가 기억하는 내용을 시각화하고, 관리하고, 가져오고, 내보낼 수 있으므로 신뢰성을 확보하고 오류를 수정할 수 있습니다. mem9는 OpenClaw, OpenCode, Claude Code, Codex, Dify 앱을 포함한 다양한 에이전트 하네스와 통합되며, 모든 HTTP 클라이언트가 동일한 메모리 공간에 읽고 쓸 수 있습니다.

drive9 영구 에이전트 파일용

drive9 drive9는 디스크에서 실제 작업을 수행하는 에이전트를 위한 내구성 있는 파일 시스템입니다. 코딩 에이전트는 저장소를 복제하고, 종속성을 설치하고, 파일을 편집하고, 테스트를 실행하고, 로그를 생성하고, 여러 접근 방식을 병렬로 시도합니다. 에이전트가 실행되는 샌드박스는 몇 분 정도 지속될 수 있지만, 실제 작업은 보통 더 오래 걸립니다. drive9는 이러한 작업 공간 상태를 샌드박스 외부에 저장하므로 재설정 후에도 유지되며 완전히 다른 환경에서도 마운트할 수 있습니다.

drive9 워크스페이스는 로컬 파일 시스템으로 마운트하여 일반적인 도구를 사용하여 작업할 수 있습니다. 워크스페이스는 병렬 실행을 위해 포크할 수 있고, 체크포인트를 생성하거나 롤백할 수 있으며, 서버 측 충돌 감지 기능을 통해 커밋할 수도 있습니다. 파일은 쓰기 시 자동으로 포함되고 인덱싱되므로 에이전트는 경로를 추측하는 대신 의미를 기반으로 워크스페이스를 검색할 수 있습니다. 로컬 디스크에서 프로세스가 실행되고 Git이 최종 결과를 저장하며, drive9는 그 사이의 작업 상태를 유지합니다.

이 글의 나머지 내용과 비교해 볼 때, 이 세 가지 모두 새로운 변화는 아닙니다. 모두 새로운 워크로드에 적용된 동일한 아키텍처 변화일 뿐입니다. 즉, 상태가 취약하고 세션에 종속된 단일 머신 환경에서 벗어나 어떤 프로세스보다 오래 지속될 것으로 예상되는 분산 시스템으로 이동하는 것입니다.

단일형 데이터베이스에서 에이전트 지원 아키텍처로

오라클에서 20년 넘게 근무하면서 분산 SQL이 제가 구축할 수 있는 것들을 완전히 바꿔놓았다고 단언할 수 있습니다. 확장 가능한 아키텍처 하에서는 해결할 수 없었던 문제들을 팀들이 해결하는 모습을 지켜봤고, 이를 통해 커뮤니티에서 놀라운 수준의 창의성이 발휘되는 것을 목격했습니다.

오랜 시간 동안 변함없이 이어져 온 교훈은 아키텍처 설계 결정이 누적된다는 것입니다. 2010년에 확장 가능한 데이터베이스를 선택하는 것은 타당한 결정이었지만, 2020년에도 그 시스템이 할 수 있는 일의 한계를 설정해 버렸습니다. 인공지능 인프라에서도 이와 같은 누적 현상이 현재 진행 중입니다. 임시 상태를 기반으로 에이전트를 구축하는 팀은 나중에 그 비용이 발생하는 결정을 내리고 있습니다. 에이전트가 지난 화요일에 알고 있던 내용을 다시 질문해야 할 때, 메모리를 여러 머신 간에 이동해야 할 때, 또는 샌드박스 재설정에 상당한 시간이 소요될 때 말입니다. 클라우드 시대에 맞춰 데이터베이스의 확장성을 가능하게 했던 아키텍처 덕분에 이제 영구적인 에이전트 상태 저장이 가능해졌습니다. 그 이유는 분산, 복제, 일관성, 그리고 데이터 검색을 네 곳이 아닌 한 곳에서 수행할 수 있기 때문입니다.

실제로 어떤 느낌인지 알고 싶으시다면, TiDB Cloud Zero 인스턴스를 실행합니다.. 몇 초밖에 걸리지 않고, 가입도 필요 없으며, 에이전트가 즉시 연결할 수 있는 벡터 검색 기능이 있는 MySQL 호환 데이터베이스를 제공합니다.

자주 묻는 질문

분산 데이터베이스 아키텍처란 무엇인가요?

분산 데이터베이스 아키텍처는 데이터를 중앙 집중식 서버에 집중시키는 대신 여러 노드에 데이터와 처리를 분산시킵니다. 이러한 아키텍처는 대규모 사용자 또는 워크로드를 처리해야 하는 애플리케이션에 확장성, 가용성, 내결함성 및 성능을 향상시킵니다.

분산 데이터베이스 아키텍처는 단일체 데이터베이스 아키텍처와 어떻게 다른가요?

모놀리식 데이터베이스 아키텍처는 일반적으로 수직 확장이 가능한 중앙 집중식 시스템에 의존하는 반면, 분산 데이터베이스 아키텍처는 여러 노드에 걸쳐 수평 확장이 가능합니다. 분산 시스템은 더 큰 워크로드를 처리하고, 장애를 허용하며, 더 유연한 배포 모델을 지원합니다.

기업들이 단일형 데이터베이스에서 분산형 데이터베이스로 전환한 이유는 무엇일까요?

현대 애플리케이션은 기존의 확장형 아키텍처로는 충족하기 어려운 높은 가용성, 글로벌 규모, 실시간 데이터 접근성, 그리고 복원력을 요구하기 때문에 기업들은 분산 데이터베이스로 전환하고 있습니다. 분산 데이터베이스는 단일 장애 지점을 줄이고 워크로드 증가에 따른 확장을 용이하게 합니다.

분산 SQL은 분산 데이터베이스 아키텍처에서 어떤 역할을 할까요?

분산 SQL은 SQL, 관계형 데이터 모델링 및 트랜잭션 일관성을 유지하면서 데이터를 여러 노드에 분산하는 분산 데이터베이스 아키텍처의 한 유형입니다. 이는 익숙한 관계형 데이터베이스 기능을 포기하지 않고 수평적 확장이 필요한 팀에 적합합니다.

인공지능 에이전트가 메모리 관리를 위해 분산 데이터베이스를 필요로 하는 이유는 무엇일까요?

AI 에이전트는 호출 간에 상태를 유지하지 않으며, 컨텍스트 창은 영구적인 메모리가 아닌 임시 버퍼입니다. 에이전트는 세션이 종료된 후에도 유지되는 영구적인 상태, 즉 이전에 학습한 사실, 작업 기록, 도구 출력, 파일 및 검색 메타데이터가 필요합니다. 분산 데이터베이스는 구조화된 레코드와 임베딩을 함께 저장하고, 단일 쿼리로 정확한 조회와 의미론적 검색을 제공하며, 업데이트, 대체 또는 삭제되는 메모리에 트랜잭션 보장을 적용할 수 있습니다.

시작하기