모델 + Harness에서 Tape 및 단일 데이터 기반(data foundation)으로 — 왜 에이전트 런타임 데이터가 첫 번째 코드 라인부터 데이터베이스에 존재해야 하는가.

Photo by Brett Jordan on Unsplash

에이전트(agent) 경쟁은 모델 계층에서 데이터 계층으로 조용히 이동하고 있습니다. 에이전트가 실행될 때, 이들은 방대한 양의 반정형 트레이스 데이터(semi-structured trace data) — 고빈도 쓰기(high-frequency writes), 긴 생명주기(long lifecycles) — 를 생성하며, 전통적인 데이터베이스 아키텍처는 이를 따라가는 데 어려움을 겪습니다. 해당 데이터를 관측성 플랫폼(observability platforms), 벡터 스토어(vector stores), 캐시(caches) 사이에서 이리저리 옮기는 것은 기록(record) → 증류(distill) → 피드백(feed back) 루프의 효율성을 더욱 저하시킵니다.

이는 결정적인 차이를 드러냅니다:

에이전트 프레임워크(agent framework)로부터 아래 방향으로 데이터베이스를 구축하는 것은, 성숙한 데이터베이스를 위 방향으로 확장하여 에이전트 프레임워크와 연결하는 것과 같지 않습니다. 시작점이 다르며, 비용 구조 또한 다릅니다.

후자의 경로에서는 데이터가 첫 번째 코드 라인부터 일급 시민(first-class citizen)입니다. 실행(Run), 기록(record), 증류(distill), 평가(evaluate), 그리고 피드백(feed back) — 이 모든 과정이 시스템 간 데이터 이동이라는 오버헤드 없이 하나의 기반(foundation) 내에서 이루어집니다.

이것이 바로 올인원 데이터 기반(all-in-one data foundation)이 중요한 이유입니다. 이는 에이전트 데이터 루프를 파편화된 엔지니어링 조각들의 모음이 아닌, 내부 사이클로 전환합니다.

Harness의 정의에서 시작하여, 이 글은 오픈 소스 Bub 프로젝트를 인용하고, 계층화된 에이전트 아키텍처(layered agent architecture)를 논의하며, OceanBase의 탐색과 이 분야에서의 가치를 포함하여 데이터베이스 네이티브 Harness 접근 방식에 도달합니다.

I. 에이전트(Agents), Harness, 그리고 그 관계의 이해

완전한 에이전트는 모델 + Harness로 표현될 수 있습니다.

Harness는 모델 외부의 모든 엔지니어링 구성 요소를 다룹니다. 말에 얹는 안장(tack)처럼, Harness는 모델을 목적지로 조종하기 위한 전체 툴킷(reins, saddle, route — 고삐, 안장, 경로)이며, 이는 엔지니어링 수준에서 피드백 메커니즘(feedback mechanisms), 로깅 시스템(logging systems), 그리고 학습 방법(training methods)으로 매핑됩니다.

Harness는 명확한 계층 구조를 가집니다. 레이어 1(Layer 1)은 기본 도구와 외부 인터페이스를 포함하여 코딩 에이전트 빌더(coding-agent builder) 또는 SDK 벤더에 의해 제공됩니다. 레이어 2(Layer 2)는 사용자가 필요로 하는 구성 요소, 즉 RAG 시스템, 메모리 시스템(memory systems), BI 파이프라인(BI pipelines)과 같은 비즈니스 로직을 통해 사용자 측에서 확장됩니다.

에이전트 시나리오에서 모델 자체는 지속적인 상태 유지 시스템(stateful system)이 아닙니다. 모델은 구체적인 비즈니스 상태에 대한 인식 없이 요청에 대한 응답을 반환할 뿐입니다. 에이전트가 제품과 팀 내에서 안정적으로 작동할 수 있게 해주는 것은 Harness가 담당하는 컨텍스트 관리(context management), 도구 호출(tool invocation), 상태 기록(state recording), 실행 추적(run-trace tracking), 효과성 평가(effectiveness evaluation), 그리고 데이터 흐름(data flow) 책임입니다.

이 과정에서 우리는 핵심 요소들을 점진적으로 식별하고 추상화하며, 이를 프리미티브(Primitive)라고 정의합니다. 시스템 프롬프트(System prompts), 스킬(Skills), 작업 완료 방법론(task-completion methodologies), 그리고 멀티 에이전트 통신 메커니즘(multi-agent communication mechanisms)은 모두 실무에서 도출되는 중요한 프리미티브입니다. 이러한 프리미티브를 표준화하고 Harness에 통합하는 것은 한편으로는 비즈니스 성능을 향상시키고 역량을 확장하며, 다른 한편으로는 Harness 자체를 점진적으로 제품화(productize)합니다.

Harness에서 수집된 데이터 또한 똑같이 중요합니다. 이 데이터는 워크플로(workflow)의 효과성을 평가하며, 비식별화(de-identification) 과정을 거친 후 차세대 모델 학습을 위한 표준 데이터셋을 형성할 수 있습니다. 모델이 개선됨에 따라, 이들은 다시 Harness 내의 프리미티브(primitive) 발견 및 정교화 과정으로 피드백되어 — 심지어 과거의 동작을 수정하기까지 하며 — 지속적으로 개선되는 플라이휠(flywheel)을 형성합니다. 아래의 다이어그램(LangChain 블로그 출처)은 이 루프를 명확하게 보여줍니다.

II. 확장 가능한 에이전트 구축하기: Bub 프로젝트

Bub은 GitHub에 공개된 오픈 소스 Python 에이전트 프로젝트입니다. 이 프로젝트의 설계는 에이전트의 복잡성을 제어하는 핵심적인 접근 방식, 즉 경량 커널(lean kernel)과 플러그인 기반 확장(plugin-based extension)을 통해 안정성과 유연성의 균형을 맞추는 방식을 반영합니다.

ChatGPT, Qwen (Alibaba의 대화형 AI), ModelScope 서비스, 그리고 Dify 및 Flowise와 같은 로우코드(low-code) 플랫폼과 같은 주류 에이전트 제품들은 이미 내장된 에이전트 루프(agent loop)를 제공합니다. 하지만 핵심적인 문제는 여전히 남아 있습니다. 에이전트의 역량이 비즈니스 시나리오와 정확히 일치해야 한다는 점입니다. 기술(skills)과 도구(tools)가 역량을 확장할 수는 있지만, 작업을 효율적으로 완료하려면 여전히 각 특정 시나리오에 맞는 도구 세트(toolset)를 조립해야 합니다.

OpenClaw, Nanobot, Hermes Agent와 같은 제품들은 너무 많은 기능을 하나로 묶어 놓았습니다. 이는 두 가지 문제를 야기합니다. 사용자에게는 기능 간의 간섭과 인지 부하(cognitive load)를 일으키고, 개발자에게는 높은 시스템 복잡도와 어려운 유지보수 문제를 일으킵니다 (예를 들어, OpenClaw의 업그레이드는 종종 제품 전반의 많은 기능을 망가뜨립니다). 이러한 밀접하게 결합된(tightly coupled) 설계는 프로덕션 환경에서 그대로 사용하기 어렵습니다. 따라서 많은 벤더들이 특정 버전을 재포장하거나 완전히 자체적으로 구축하여 사용합니다.

Bub은 다른 아키텍처 전략을 취합니다: 가벼운 커널 (kernel)을 구축하고 플러그인 (plugins)을 통해 기능을 확장하는 방식입니다. 추가 기능은 플러그인으로 분리됩니다. 안정적인 에이전트 루프 (agent loop)를 구현하기 위해 신중하게 설계된 슬림한 커널만을 유지하며, 필요한 비즈니스 역량은 기능 플러그인을 통해 단계적으로 도입됩니다. 사용자는 플러그인이 올바르게 작동하는지만 확인하면 됩니다. 만약 플러그인이 실패하면, 해당 플러그인을 제거하고 서비스를 복구할 수 있어 유지보수성 (maintainability)이 크게 향상됩니다.

Bub의 핵심 설계 철학은 단일 에이전트가 얼마나 강력한가가 아니라, 단일 상호작용 (interaction) 내에서 단계들이 어떻게 나뉘는가에 관한 것입니다. Bub의 내장 에이전트이든, 외부에서 통합된 Codex 또는 LangChain이든, 어느 쪽이든 작업을 완료할 수 있습니다. Bub은 각 상호작용을 대화 상태 구축 (conversation state construction), 프롬프트 조립 (prompt assembly), 채널 입출력 정의 (channel input/output definitions) 등 명시적인 단계로 분해합니다. 이러한 단계별 분해는 흐름 제어 (flow control)를 가능하게 합니다. 즉, 모든 로직을 단일 에이전트에 쌓아두는 대신, 훅 (hooks)을 통해 각 단계에서 통합 지점을 노출합니다.

핵심적인 설계 중 하나는 출력에 대한 강제적인 바인딩 (binding)을 제거하는 것입니다. 전통적인 시스템은 메시지 응답을 입력 채널에 엄격하게 바인딩합니다. 반면 Bub은 에이전트가 특정 시나리오에서 메시지를 반환하지 않고 침묵할 수 있도록 허용합니다. 이는 개인 비서 설정에서는 결함처럼 보일 수 있지만, 다중 사용자 또는 다중 에이전트 협업 환경에서는 소음을 피하는 침묵이 오히려 친화적인 특성이 됩니다.

현재 커뮤니티에서는 에이전트 설계를 표준화하고 모듈화하는 접근 방식들이 물결처럼 나타나고 있습니다. 예를 들어:

• Agents.md — 시스템 및 작업 관련 프롬프트를 주입(inject)합니다.

• Skills — 일반적인 SOP(표준 운영 절차)(문서화, 코드 검토 등)를 에이전트 루프에 하드코딩하지 않고 배포 가능한 자산으로 패키징합니다.

• MCP (Model Context Protocol) — 플러그인을 통해 IM 채널 어댑터, 예약된 작업, AG-UI 시각화 등을 제공합니다.

이는 메인스트림 에이전트 프레임워크가 2026년에 나아가고 있는 방향입니다. Bub은 이 아이디어의 실천 사례이며, 단 몇백 줄의 핵심 인터페이스 코드만으로 유연한 인프라를 구축합니다.

III. Context에서 데이터 루프로: Tape 및 데이터베이스 네이티브 Harness

1. Tape을 중심으로 데이터 루프 구축

Tape(Bub과 우리가 개발 중인 AgentSeek의 핵심 개념)는 단순한 채팅 기록이 아닙니다. 어떤 면에서는 단일 에이전트 실행에서 주요 사실들을 기록하는 추적(trace)과 유사합니다.

OpenTelemetry 및 유사 관측 가능성(observability) 시스템의 트레이스와 달리, Tape의 시점은 더 간단하며 관련성은 높지만 지나치게 세부적인 내용에 초점을 맞추지는 않습니다. 그 고유한 가치는 다음과 같습니다:

• 관측 가능성 데이터와 컨텍스트 모델 모두 제공 — Tape은 중요한 작업을 위한 관측 가능성을 담고 동시에 에이전트의 런타임 컨텍스트 모델 역할을 합니다. 이는 인간과 AI가 동일한 데이터 뷰에서 협업할 수 있음을 의미합니다. 에이전트는 자신의 과거 행동을 검토하기 위해 자신의 Tape을 읽을 수 있습니다.

• 에이전트 자체 성찰 및 진단 가능하게 함 — 전통적으로 에이전트가 실패하면 엔지니어들이 관측 가능성 플랫폼을 통해 문제 해결(troubleshoot)합니다. Tape을 사용하면 사용자들은 에이전트에게 직접 말을 걸어

• 모델 학습 서빙 (Serving model training) — 비식별화되고 포맷팅된 내보내기(export)를 통해, Tape은 모델 학습 및 미세 조정 (fine-tuning)을 위한 작업 특화 데이터셋 (task-specific datasets)으로 즉시 전환될 수 있습니다. 이는 컨텍스트 (context)와 관측 가능성 (observability)을 폐쇄형 데이터 루프 (closed data loop) 내에서 모델 학습과 진정으로 연결합니다.

2. 데이터베이스 네이티브 Harness가 필요한 이유

OpenClaw와 같은 에이전트 시스템은 파일 시스템(다양한 .md 파일 등)에 크게 의존합니다. 이는 인간과 에이전트가 읽기에는 친숙하지만, 데이터 처리, 분석 및 핸들링에는 취약합니다. 현대적인 컨텍스트 엔지니어링 (context engineering)에는 가공되지 않은 작업 궤적 (raw task trajectories) 상위에 메모리 (Memory) 레이어가 필요하며, 여기에는 궤적의 요약과 인덱스 (index)가 모두 포함되어야 합니다. OpenClaw 커뮤니티의 lossless-claw와 같은 플러그인들이 이후 SQLite와 같은 데이터베이스를 사용하여 호출 체인 (call chains)과 메모리를 연결하기 시작했는데, 이는 이 레이어에서 데이터베이스가 필수적임을 보여줍니다.

데이터베이스를 Harness의 기반으로 사용하는 것은 모든 에이전트 런타임 (runtime) 데이터가 데이터베이스 내에서 네이티브하게 일급 시민 (first-class citizen)임을 의미합니다. 관측 가능성 (observability), 데이터 추출 (data extraction), 그리고 아카이브 분석 (archival analysis)은 복잡한 이기종 데이터 스택 (heterogeneous data stack, 예: MySQL + Elasticsearch + Redis)을 유지 관리할 필요 없이 데이터베이스의 네이티브 기능을 사용할 수 있습니다. 이는 통합된 데이터 기반 (unified data foundation)을 제공하고, 아키텍처를 단순화하며, 운영 비용을 낮춰줍니다.

OceanBase는 이 경로에 매우 적합합니다. 그 이유는 무엇일까요? OceanBase의 핵심 강점은 다음과 같습니다:

• AI 워크로드 준비성 (AI workload readiness) — OceanBase와 그 파생 도구들은 AI 에이전트 (AI agent) 워크로드에 최적화된 벡터 검색 (vector search) 및 하이브리드 검색 (hybrid retrieval)을 제공합니다. 여러 기술 스택을 유지 관리할 필요 없이, SQL과 벡터 및 전문 검색 (full-text search)이 내장된 기능으로 제공됩니다.

• HTAP 역량 — 하이브리드 트랜잭션/분석 처리 (HTAP) 데이터베이스로서, 에이전트 런타임 (agent runtime) 데이터에 대한 실시간 쿼리 및 복잡한 분석을 직접 지원하여 데이터 루프 (data loop)를 뒷받침합니다.

• 원활한 스케일 아웃 (scale-out)을 지원하는 통합 스토리지 — 모든 종류의 데이터를 균일하게 저장할 수 있어 추적 분석 (trace analysis), 검색 및 관련 워크로드를 지원합니다. 에지 (edge)에서의 단일 노드 배포(예: OceanBase seekdb)부터 분산된 OceanBase 클러스터까지 원활하게 확장되어, 비즈니스가 성장함에 따라 매끄러운 업그레이드 경로를 제공합니다.

IV. AgentSeek: 데이터베이스 네이티브 하네스 (Database-Native Harness) 탐색

에이전트 아키텍처에 대한 지속적인 탐구를 통해, OceanBase 팀은 완전히 데이터베이스 네이티브 (database-native) 역량을 기반으로 구축된 하네스 (Harness)인 AgentSeek를 구축하고 있습니다.

AgentSeek의 핵심 아이디어는 에이전트 런타임 데이터를 첫날부터 데이터베이스의 일급 시민 (first-class citizen)으로 만드는 것이며, 이를 통해 사용자가 데이터 루프 (data-loop) 시나리오를 구축할 수 있도록 돕는 것입니다. 이 프로젝트는 OceanBase 제품 역량과 AgentSeek 관련 래퍼 (wrappers)를 통합하며 활발히 진행 중입니다.

저장소 (Repository): github.com/ob-labs/agentseek

맺음말