AI 에이전트(AI agents)는 연산(compute)의 문제가 아닙니다. 그것은 데이터의 문제입니다.

에이전트형 AI(agentic AI)에 관한 대부분의 논의는 모델의 능력, 즉 더 나은 추론(reasoning), 더 긴 컨텍스트 윈도우(context windows), 더 똑똑한 계획(planning)에 집중합니다. 이는 중요한 요소입니다. 하지만 실제 운영 환경에서 에이전트 시스템을 무너뜨리는 진짜 원인은 그 모든 것의 밑바닥에 있습니다. 바로 데이터베이스(database)입니다.

구체적인 실패 모드는 다음과 같습니다. 에이전트는 세 가지 일을 동시에 수행해야 합니다: 실시간 운영 상태(live operational state)를 읽고, 과거 데이터에 대해 분석적 추론(analytical reasoning)을 실행하며, 발견한 내용을 바탕으로 트랜잭션(transaction)을 실행하는 것입니다. 오늘날 대부분의 아키텍처에서 이 세 가지 작업은 세 개의 서로 다른 시스템을 거칩니다. 상태(state)는 Postgres에 저장되어 있습니다. 분석(analytics)은 데이터 웨어하우스(warehouse)에서 실행됩니다. 벡터 컨텍스트(vector context)는 별도의 저장소(store)에서 가져옵니다. 세 가지 쿼리가 모두 완료되어 에이전트가 행동할 준비가 되었을 때, 첫 번째 쿼리의 데이터는 더 이상 현실을 반영하지 못할 수도 있습니다. 에이전트는 이미 변해버린 세상의 모습에 기반하여 행동하게 됩니다.

이것은 모델의 실패가 아닙니다. 모델은 올바르게 추론했습니다. 다만 오래된 데이터(stale data)를 바탕으로 추론했을 뿐입니다.

삼각형 문제 (The triangle problem)

OLTP와 OLAP를 단일 시스템에서 결합하려는 시도는 수없이 많았습니다. 이것이 성공하지 못한 이유는 엔지니어들이 '삼각형 문제(triangle problem)'라고 부르는 것 때문입니다. 속도(트랜잭션 처리량), 확장성(데이터 볼륨 및 동시성), 효율성(작업당 비용) 중 하나를 최적화할 수는 있지만, 실질적인 트레이드오프(tradeoffs) 없이는 세 가지 모두를 최적화할 수 없습니다. 이전의 모든 HTAP 시도들은 어떤 형태로든 이 제약에 부딪혔습니다.

실패한 접근 방식들은 일반적으로 이를 연산(compute) 문제로 해결하려 했습니다. 더 빠른 쿼리 엔진을 구축하거나, 더 많은 메모리 계층(memory tiers)을 추가하거나, 워크로드(workloads)를 서로 다른 연산 경로로 라우팅하는 식입니다. 그 결과는 항상 특정 워크로드 유형에는 최적화되어 있지만 다른 유형은 겨우 감내하는 수준의 시스템이었습니다.

다른 시작점

실제로 작동하는 접근 방식은 컴퓨팅 계층 (compute layer)이 아니라 스토리지 계층 (storage layer)에서 시작됩니다. 스토리지 아키텍처가 처음부터 동일한 데이터에 대해 행 지향적 트랜잭션 액세스 (row-oriented transactional access)와 열 지향적 분석 스캔 (columnar analytical scans)을 모두 처리할 수 있도록 설계되면, 트레이드오프 (tradeoffs)가 변화합니다. 전통적인 시스템에서 OLTP와 OLAP가 충돌하는 이유는 서로 다른 컴퓨팅이 필요해서가 아닙니다. 서로 다른 데이터 레이아웃 (data layouts)이 필요하기 때문이며, 기존의 스토리지는 오직 하나만을 처리할 수 있기 때문입니다.

트랜잭션 잠금 (transactional locks)으로 분석 쿼리를 차단하지 않고 (또한 분석 쿼리가 트랜잭션 정리 작업을 지연시키지 않도록 하는) 동시성 제어 프로토콜 (concurrency control protocol)이 결합되면, 두 워크로드 (workloads)가 교대로 실행되는 것이 아니라 실제로 동시에 실행되는 시스템을 얻을 수 있습니다.

실제 수치는 어떤 모습인가

두 가지 구체적인 벤치마크가 이를 입증합니다.

혼합 부하 상황에서의 트랜잭션 처리량 (Transactional throughput under mixed load)
200,000개의 웨어하우스 (warehouses), 10개의 노드 (nodes), 각 노드당 14개의 코어 (cores) 환경에서의 TPC-C 테스트입니다. 99% 임계값 내에서 12.86 tpmC를 기록했습니다. 이 벤치마크는 동일한 데이터에 대해 OLAP 쿼리가 동시에 실행되는 상태에서 수행되었습니다. 성능 저하는 없었습니다. TPC-C 수치를 발표하는 대부분의 데이터베이스는 동시적인 분석 부하 없이 격리된 상태에서 테스트를 진행합니다.

동시 쓰기 압박 상황에서의 분석 처리량 (Analytical throughput under concurrent write pressure)
100억 개의 행 (rows)을 가진 두 테이블 간의 JOIN 작업으로, 모든 행은 노드에 분산되어 있으며 공동 배치 (co-location)나 인덱스 (indexes)가 없는 상태입니다. 동시에 동일한 데이터에 대해 초당 50,000건의 ACID 준수 쓰기 (ACID-compliant writes)가 수행되었습니다. 50개의 인스턴스, 각 64GB RAM, 4개의 코어 환경입니다. JOIN은 174초 만에 완료되었습니다. 모든 쓰기는 커밋 (committed)되었습니다. 두 워크로드 간의 경합 (contention)은 없었습니다.

두 번째 벤치마크가 에이전트 워크로드 (agent workloads)에 특히 중요한 이유는 다음과 같습니다. 다른 에이전트들이 동일한 레코드에 상태 변경 (state changes)을 기록하는 동안, 분석적 컨텍스트 (analytical context)를 읽고 있는 에이전트는 두 작업 모두가 정확하게 완료되어야 합니다. 파편화된 아키텍처 (fragmented architecture)에서 이 두 작업은 서로 다른 일관성 보장 (consistency guarantees)을 가진 서로 다른 시스템에 존재합니다. 단일 동시성 모델 (single concurrency model)을 가진 시스템에서는 이들이 동일한 트랜잭션 (transaction)입니다.

에이전트에게 실제로 필요한 것

에이전트가 데이터베이스로부터 필요로 하는 세 가지 요소는 대부분의 데이터베이스가 동시에 제공하지 못하는 것들입니다:

동시성 (Concurrency) 상황에서의 트랜잭션 정확성. 단순히 10명의 동시 사용자가 아닙니다. 공유된 레코드를 읽고 쓰는 수백, 수천 개의 동시 에이전트 인스턴스들입니다. 단일 인스턴스 내부뿐만 아니라 분산된 노드(distributed nodes) 전체에 걸쳐 유지되는 직렬화 가능 격리 (Serializable isolation)가 필요합니다.

라이브 데이터 (Live data)에 대한 분석적 추론. 어젯밤 파이프라인을 통해 생성된 어제의 스냅샷 (snapshot)이 아닙니다. 쿼리 시점에 최신 상태인 데이터를 대상으로 복잡한 분석 쿼리 (analytical query)를 실행하고, 그 결과에 작용하는 트랜잭션 (transaction)과 동일한 작업 내에서 이를 수행할 수 있는 능력이 필요합니다.

자연어 접근성 (Natural language access). 에이전트는 사람이 질문하는 것과 동일한 방식으로 데이터를 쿼리할 수 있어야 합니다. SQL 지식이나 미리 정의된 쿼리 템플릿 (query templates) 없이도, 어떤 에이전트든 라이브 운영 데이터에 대해 자연어 쿼리를 실행할 수 있게 해주는 MCP 네이티브 인터페이스 (MCP-native interface)가 바로 이 루프를 완성하는 핵심입니다.

이것이 동시성 모델 (concurrency model) 및 스토리지 계층 (storage layer) 수준에서 어떻게 작동하는지에 대한 전체적인 기술적 분석은 원문 포스트에서 확인할 수 있습니다: The Shift to Agentic AI and a Modern Database