AI 어시스턴트 아키텍처: LLM, 메모리, 도구, 라우팅, 가시성

프로덕션 환경의 AI 어시스턴트는 단순히 “프롬프트가 붙은 LLM"이 아닙니다. 의도(intent)를 수용하고, 상태를 유지하며, 언제 검색하거나 행동을 취할지 결정하는 시스템입니다. 또한 실패 원인을 디버깅할 수 있도록 충분한 런타임 세부 정보를 노출해야 합니다.

이러한 시스템 수준의 관점은 어시스턴트가 단일 모델 호출을 넘어설 때 AI 시스템 클러스터에서 탐구합니다.

OpenAI는 에이전트를 계획하고, 도구를 호출하며, 협력하고, 다단계 작업을 위해 충분한 상태를 유지하는 애플리케이션으로 설명합니다. 반면 Anthropic은 동일한 문제를 파일 실행, 명령어 실행, 웹 접근 및 코드 실행을 안전하게 수행할 수 있는 관리된 하니스(managed harness)로 해결하는 방식으로 프레임화합니다.

가장 깔끔한 아키텍처는 책임 다섯 가지로 역할을 분리합니다: LLM, 메모리, 도구(Tooling), 라우팅, 그리고 관찰성(Observability). 이러한 분리는 주요 제공업체 API, MCP, vLLM 및 llama.cpp와 같은 자체 호스팅 런타임, 그리고 OpenClaw와 Hermes와 같은 실제 어시스턴트 시스템이 노출하는 기능과 일치합니다.

메모리는 “더 긴 컨텍스트"보다 더 중요한 것으로 취급되어야 합니다. 검색 시스템은 외부 지식을 명시적인 비파라메트릭(non-parametric) 메모리로 변환합니다 — 이는 검색 증강 생성(RAG)에서 심층적으로 다루는 설계 영역과 동일합니다. Anthropic의 컨텍스트 가이드라인과 “Lost in the Middle” 논문은 컨텍스트에 더 많은 토큰을 단순히 쐐기듯 넣는다고 해서 신뢰할 수 있는 기억 회수가 보장되지 않는다고 경고합니다.

도구 사용은 마법이 아니라 계약의 경계(contract boundary)입니다. OpenAI 함수 호출, Anthropic 도구 사용, MCP 모두 동일한 패턴에 의존합니다: 모델이 구조화된 요청을 방출하고, 어떤 런타임이 이를 실행하며, 그 결과가 대화로 다시 흐릅니다. 이 경계가 느슨하면 어시스턴트도 느슨해집니다.

저의 편향은 단순합니다: 지루하게 시작하십시오. 오케스트레이터 하나, 내구성 있는 메모리 경로 하나, 요청당 추적(trace) 하나, 그리고 도구 실행을 위한 명시적 정책 하나. 다중 에이전트 그래프는 유용하지만, 추측 없이 단일 에이전트의 실패 사례를 설명할 수 있을 때만 가치가 있습니다.

AI 어시스턴트 시스템이란 무엇인가

실용적인 정의는 다음과 같습니다: AI 어시스턴트 시스템은 모델 인터페이스, 컨텍스트 조합, 도구 실행, 상태 관리 및 텔레메트리를 결합하여 사용자 의도를 응답이나 행동으로 변환하는 런타임입니다. 이것이 바로 유용한 문서가 단순히 모델 카드가 아닌 이유입니다. 유용한 문서는 API 참조, 도구 계약, 검색 가이드, 라우팅 문서, 추적 문서입니다. OpenAI의 Responses API는 상태ful(stateful) 상호작용, 내장 도구, 함수 호출을 노출합니다. Anthropic의 Claude API는 직접적인 Messages 접근뿐만 아니라 Managed Agents도 노출합니다. OpenClaw와 Hermes는 한 단계 더 나아가 이러한 기능을 지속 가능한 게이트웨이, 채널, 세션, 메모리 뒤에 배치했을 때 발생하는 상황을 보여줍니다.

즉, 어시스턴트 시스템은 채팅 완료(chat completion)보다 더 광범위한 계약을 가지고 있습니다. 좋은 내부 계약은 다음과 같습니다:

AssistantRequest  = 사용자 의도 + 정체성 + 세션 + 첨부파일 + 정책
AssistantResponse = 답변 + 행동 + 인용 + 상태 변경 + 추적 ID

이 계약은 중요하며, 모든 프로덕션 논쟁은 결국 다음 질문들 중 하나로 귀결됩니다: 어떤 컨텍스트가 가시적이었는가, 어떤 도구가 실행되었는가, 어떤 모델이 답변했는가, 어떤 메모리가 읽히거나 기록되었는가, 그리고 추적이 시스템이 시간을 어디에 썼는지 말해주는가. OpenTelemetry는 추적을 애플리케이션을 통과하는 요청의 경로로 정의하는데, 이는 심각한 어시스턴트가 필요한 정확한 추상화입니다. LangSmith와 OpenLIT는 이 아이디어를 LLM, 도구, 벡터 저장소 및 에이전트 워크플로우에 맞게 전문화합니다.

핵심 구성 요소 및 인터페이스

아래의 구성 요소 분리는 제가 가장 내구성이 있다고 느끼는 것입니다. 또한 이는 사람들이 실제로 운영하는 공식 API 및 오픈소스 런타임과 가장 잘 일치하는 분리 방식입니다.

위의 표는 공식 제공자 인터페이스, MCP, 벡터 데이터베이스 문서, 그리고 vLLM, llama.cpp, OpenClaw, Hermes의 런타임 문서에서 유래되었습니다.

LLM 레이어는 세 가지를 잘 수행해야 합니다: 현재 작업 컨텍스트를 소비하고, 최종 답변 또는 구조화된 행동 요청을 방출하며, 재시도 및 추적을 지원하기 위한 충분한 메타데이터를 반환해야 합니다. OpenAI의 Responses API는 상태ful 상호작용 및 내장 도구와 함수 호출을 위해 명시적으로 설계되었습니다. Anthropic의 Messages API는 tool_use 블록과 tool_result 반환을 통해 동일한 핵심 루프를 노출하며, Managed Agents는 루프를 직접 구축하지 않을 경우 호스팅된 하니스를 제공합니다. vLLM과 llama.cpp와 같은 자체 호스팅 런타임은 익숙한 제공자 스타일 인터페이스를 유지하면서 추론을 자체 환경에 배치할 수 있게 해주므로 중요합니다.

메모리 레이어는 정신적으로 세 가지 범주로 나뉘어야 합니다: 작업 메모리, 내구성 있는 기호적 메모리, 그리고 검색 가능한 의미적 메모리. OpenAI 임베딩은 색인화 및 검색 가능한 벡터를 반환합니다. OpenAI Retrieval 및 File Search는 벡터 저장소 위에 의미적 및 키워드 검색을 레이어링합니다. Pinecone, Weaviate, pgvector, Milvus는 네 가지 일반적인 저장소 형태를 나타냅니다: 완전 관리형, 오픈소스 벡터 네이티브, Postgres 네이티브, 분산 벡터 데이터베이스. Hermes와 OpenClaw는 모든 메모리가 벡터 저장소에 속하는 것은 아니라는 유용한 알림을 추가합니다: 파일 기반 메모리, 검토된 프로모션, 세션 범위의 스냅샷은 종종 더 정직한 설계입니다. AI 어시스턴트의 메모리 시스템이 크로스 프레임워크 모델을 매핑하고, Hermes 에이전트 메모리 시스템이 하나의 제품에서 바운더드 핵심 메모리와 고정된 세션 스냅샷을 해체합니다.

도구 레이어는 어시스턴트가 요약기를 멈추고 소프트웨어가 되는 곳입니다. OpenAI 함수 호출은 도구를 모델이 호출하기로 결정할 수 있는 스키마 정의 기능으로 취급합니다. Anthropic은 더 명시적으로 동일한 내용을 말합니다: 도구 사용은 애플리케이션과 모델 간의 계약이며, 모델은 자체적으로 아무것도 실행하지 않습니다. MCP는 호스트가 도구를 노출하는 하나 이상의 서버에 연결하는 클라이언트-서버 프로토콜로 이 계약을 일반화합니다 — 이는 Go의 MCP 서버에서 단계별로 설명된 동일한 경계입니다. LangChain과 LlamaIndex는 오케스트레이션 라이브러리로서 여기에 자연스럽게 위치합니다: LangChain은 사전 구축된 에이전트 아키텍처와 통합에 초점을 맞추고, LlamaIndex는 컨텍스트 증강 데이터 액세스, 쿼리 엔진 및 워크플로우에 초점을 맞춥니다.

라우팅 레이어는 “어떤 모델?“이 유일한 질문이 아니기 때문에 존재합니다. 또한 “어떤 제공자 경로, 어떤 테넌트, 어떤 예산, 어떤 대기 시간 클래스, 그리고 어떤 폴백인가?“도 필요합니다. LiteLLM은 공식 문서가 놀랍도록 구체적이므로 유용합니다: 가중 선택, 가장 덜 바쁜, 대기 시간 기반, 비용 기반 라우팅 및 제한된 장애 조치는 모두 일급 패턴입니다. OpenClaw는 라우팅을 채널 및 에이전트 격리까지 상향식 확장하고, Hermes는 요약, 컨텍스트 압축, MCP 도구 라우팅과 같은 주요 및 보조 작업을 위한 모델 슬롯까지 하향식 확장합니다. 이것이 올바른 정신 모델입니다: 라우터는 모델보다 더 많은 것을 선택합니다. 그것은 실행 로우(execution lane)를 선택합니다.

관찰성 레이어는 아키텍처가 구전 설화로 변하는 것을 방지합니다. OpenTelemetry는 추적 추상화를 제공합니다. LangSmith는 LLM 애플리케이션 단계에 대한 엔드투엔드 가시성을 제공하며 클라우드, 하이브리드 및 자체 호스팅 배포 형태를 지원합니다. OpenLIT는 LLM, 에이전트 프레임워크, 벡터 데이터베이스 및 GPU를 지원하는 제로 코드 및 수동 계측 옵션을 갖춘 OpenTelemetry 네이티브 AI 관찰성을 제공합니다. 추론 및 에이전트 워크플로우 전반의 프로덕션 지표, 추적 및 SLO 패턴에 대해서는 LLM 시스템의 관찰성를 참조하십시오. 어시스턴트에 요청당 추적이 없고, 모델 호출당 스팬이 없으며, 도구 실행을 위한 이벤트 기록이 없다면 아직 아키텍처가 있는 것이 아닙니다. 그것은 단지 분위기(vibes)에 불과합니다.

캡처, 풍부화, 응답

실제 시스템에서 계속 나타나는 시퀀스는 캡처 -> 풍부화 -> 응답 -> 기록입니다. 다른 프레임워크는 이를 다르게 감싸지만, 흐름은 백본으로 취급하기에 충분히 안정적입니다.

캡처 단계는 일반적으로 보이는 것보다 더 중요합니다. OpenClaw와 Hermes는 모두 게이트웨이를 어시스턴트 앞에 배치합니다. 왜냐하면 인그레스는 단순한 텍스트 입력이 아니기 때문입니다. 이는 채널 메타데이터, 정체성, 인증, 세션 경계, 다이렉트 메시지, 그룹, 크론 틱 및 전달 시맨틱스를 포함합니다. 이 레이어를 건너뛰고 원시 채팅 위젯 추상화에 의존하면 결국 우발적 미들웨어로 다시 붙이게 될 것입니다.

풍부화(enrich) 단계는 성숙한 시스템이 장난감 데모와 차별화되는 곳입니다. OpenAI Retrieval 및 File Search는 벡터 저장소 및 검색 호출을 통해 검색을 명시적으로 만듭니다. LlamaIndex는 데이터 커넥터, 인덱스, 쿼리 엔진 및 워크플로우를 통해 동일한 패턴을 공식화합니다. Hermes는 모델 에스테이트를 주요 및 보조 슬롯으로 분리하여 압축, 요약, 라우팅과 같은 작업을 더 작거나 전문화된 모델로 오프로딩하는 것을 더 멀리 갑니다. 이는 훔칠 만한 설계 패턴입니다: 가장 비싼 모델 토큰을 잡일에 사용하지 마십시오.

응답 단계는 “텍스트 생성"이 아닙니다. 그것은 “현재 루프를 닫는 것"입니다. 모델이 직접 답변할 수 있다면 그렇게 합니다. 도구가 필요하면 구조화된 요청을 방출합니다. Anthropic의 도구 사용 계약과 OpenAI의 함수 호출 가이드는 모두 이를 명시합니다. 이것이 아키텍처적으로 중요한 이유는 출력에 이제 언어와 제어 흐름이 모두 포함되기 때문입니다. 응답 객체는 부분적으로 산문이고 부분적으로 런타임 계획입니다.

기록 단계는 일관성 시맨틱스가 나타나는 곳입니다. Pinecone은 쓰기 및 읽기 경로를 분리하고 내구성 있는 확인 후 쓰기를 처리합니다. Hermes 메모리는 세션당 고정된 스냅샷으로 주입되어 프리픽스 캐시 성능을 유지할 수 있으므로 새 쓰기는 현재 세션 프롬프트에 자동으로 나타나지 않습니다. OpenClaw의 Dreaming 시스템은 검토된, 기반된 후보만 MEMORY.md로 프로모션하며, 이는 항상 켜져 있는 것이 아니라 옵트인(opt-in) 방식입니다. 실용적인 교훈은 메모리가 모든 레이어에서 진정한 읽기 후 쓰기(read-after-write)가 거의 없다는 것입니다. 단계적 가시성(staged visibility)을 위해 설계해야 합니다.

OpenClaw와 Hermes를 참조 시스템으로

OpenClaw와 Hermes는 하나의 제공자 API를 감싸는 래퍼가 아니기 때문에 유용한 참조 사례입니다. 둘 다 게이트웨이, 세션, 도구, 메모리 및 다중 모델 백엔드를 갖춘 장기 실행 시스템으로 어시스턴트를 제시합니다.

이 매핑은 공식 OpenClaw 및 Hermes 문서 및 리포지토리에 기반합니다. OpenClaw는 게이트웨이 아키텍처, 다중 에이전트 라우팅, vLLM 및 Ollama를 포함한 커스텀 및 자체 호스팅 제공자 지원, 선택적 활성 메모리 및 Dreaming 기반 프로모션을 문서화합니다. Hermes는 메시징 게이트웨이, 중앙 AIAgent 루프, 주요 및 보조 모델 슬롯, 내장 메모리 및 네이티브 MCP 통합을 문서화합니다.

제 약간 편향된 해석은 두 시스템이 다른 악센트로 동일한 아키텍처적 논쟁을 한다는 것입니다. OpenClaw는 강력하게 게이트웨이 우선(gateway-first)입니다. Hermes는 강력하게 에이전트 루프 우선(agent-loop-first)입니다. 그러나 둘 다 어시스턴트가 단순히 “프롬프트 + 모델"이라는 얕은 아이디어를 거부합니다. 그들은 채널, 정체성, 메모리 시맨틱스, 도구 표면 및 백엔드 이질성을 일급 관심사로 모델링합니다. 이것이 프로덕션 아키텍처가 해야 할 일입니다.

두 시스템에서 영감을 받은 실용적인 하이브리드 스택은 다음과 같습니다:

edge:
  gateway: hermes or openclaw

routing:
  proxy: litellm
  policy: latency and budget aware
  tenancy: session and channel scoped

llm:
  primary: openai responses or anthropic messages
  local_fallback: vllm
  local_dev: ollama or llama.cpp

memory:
  session: sqlite or postgres
  semantic: pgvector or weaviate
  embeddings: openai embeddings or ollama embeddings

tools:
  contract: json schema tools plus mcp
  examples: filesystem, browser, web search, internal APIs

observability:
  traces: opentelemetry
  ai_dashboards: openlit or langsmith
  evals: openai evals plus app-specific regression sets

이 스택은 벤더가 지정한 청사진이 아닌 합리적 배포 패턴입니다. 이것이 작동하는 이유는 공식 인터페이스가 일치하기 때문입니다: OpenAI와 Anthropic은 도구 지향 API를 노출하고, vLLM과 llama.cpp는 제공자 스타일 엔드포인트를 에뮬레이션하며, Ollama는 로컬 모델 및 임베딩을 처리하고, MCP는 외부 도구를 표준화하고, LiteLLM은 라우팅 및 장애 조치를 처리하며, OpenTelemetry 호환 플랫폼은 전체 경로를 추적할 수 있습니다.

패턴, 테이블 및 트레이드오프

명명할 가치가 있는 몇 가지 반복 가능한 어시스턴트 패턴이 있습니다. **관리된 어시스턴트(managed assistant)**는 런타임의 대부분을 제공자 API 내부에 유지합니다. **검색 우선 어시스턴트(retrieval-first assistant)**는 메모리와 검색을 주요 차별자로 취급합니다. **도구 우선 어시스턴트(tool-first assistant)**는 챗봇보다 운영자처럼 행동합니다. **게이트웨이 어시스턴트(gateway assistant)**는 메시징 표면을 통한 항상 켜진 접근을 우선시합니다. **전문가 메시(specialist mesh)**는 작업을 다중 에이전트 또는 경로로 분해합니다. OpenAI, Anthropic, LlamaIndex, LiteLLM, OpenClaw, Hermes의 공식 문서는 모두 이러한 패턴의 버전을 지원하며, 이름만 다를 뿐입니다.

이 패턴 테이블은 단일 벤더의 주장이 아니라 제공자 문서, 프레임워크 문서 및 참조 시스템으로부터의 종합입니다.

테이블 참고: OpenAI 호스팅 File Search는 관리형 도구이며, Anthropic은 관리형 하니스를 제공합니다. Pinecone은 관리형 벡터 서비스이며, vLLM, llama.cpp, Ollama, pgvector, Weaviate, Milvus, LangSmith 자체 호스팅, OpenLIT는 모두 다양한 정도로 자체 관리 또는 하이브리드 운영을 지원합니다.

테이블 참고: Pinecone은 관리형 제어 평면 및 지역 데이터 평면을 문서화합니다. Weaviate는 여러 벡터 인덱스 유형과 함께 벡터 및 역색인을 문서화합니다. pgvector는 Postgres에 정확 및 근사 최근접 이웃 검색을 추가합니다. Milvus는 오픈소스 고성능, 확장 가능한 벡터 데이터베이스로 위치하며, Zilliz Cloud를 관리형 옵션으로 제공합니다.

테이블 참고: OpenAI는 Responses를 상태ful 응답 및 내장 도구를 위한 고급 인터페이스로 문서화합니다. Anthropic은 Managed Agents와 별도로 Messages API 및 도구 사용 계약을 문서화합니다. vLLM은 OpenAI 호환 서버 및 Anthropic Messages API 지원을 노출합니다. Ollama는 로컬 임베딩 및 모델 워크플로우를 문서화합니다. llama.cpp는 OpenAI 호환 채팅, 응답 및 임베딩 라우트 및 Anthropic 호환 채팅 완료를 문서화합니다.

이 트레이드오프 매트릭스는 벤더 벤치마크가 아닌 공식 문서로부터의 아키텍처적 추론입니다. 일관성 행은 많은 블로그 포스트가 인정하는 것보다 중요합니다: Pinecone은 쓰기 및 읽기 경로를 분리하고, Hermes는 메모리를 세션 시작 프롬프트로 고정하며, OpenClaw는 단계적 검토를 통해 내구성 있는 메모리를 프로모션합니다. 이는 “메모리 업데이트됨"과 “현재 답변에 메모리가 가시적임"이 종종 다른 진리임을 의미합니다.

실패 모드 및 완화

대부분의 어시스턴트는 기본 모델이 “나쁘기” 때문에 실패하지 않습니다. 그들은 주변 시스템이 모델에 거짓말을 하거나, 올바른 컨텍스트를 굶기거나, 도구가 유영하게 하거나, 디버깅을 불가능하게 만들기 때문에 실패합니다.

이 테이블의 증거 기반은 넓지만 일관적입니다. Anthropic의 도구 문서는 도구 사용이 계약 경계임을 명확히 합니다. OpenAI Guardrails는 File Search를 통해 참조 지식베이스에 대한 환각 감제를 포함합니다. SelfCheckGPT는 샘플 간 자체 일관성이 근거 없는 주장을 감지하는 데 도움이 될 수 있음을 보여줍니다. “Lost in the Middle” 결과와 Anthropic의 컨텍스트 가이드라인은 동일한 운영 교훈을 강화합니다: 더 많은 토큰은 컨텍스트 큐레이션의 필요성을 제거하지 않습니다.

선호하는 완화 스택은 지루하고 반복적일 수 있습니다: 모든 요청 추적, 프롬프트 버전 관리, 검색 독립적으로 평가, 도구 멱등성 유지, 그리고 라우트 또는 메모리 정책 변경 전 회귀 평가 실행. OpenAI의 Evals 문서 및 리포지토리는 왜 그런지 직설적입니다: 평가 없이는 모델 또는 프롬프트 변경이 사용 사례에 어떤 영향을 미치는지 이해하기 어렵고 시간이 많이 걸립니다. 이는 프롬프트만큼 라우터와 검색에도 동일하게 적용됩니다.

더 읽기

더 깊이 들어가려면 어시스턴트 아키텍처를 설계하거나 검토할 때 열어두어야 할 가장 유용한 기본 소스가 있습니다.

• OpenAI: Responses Overview, Function Calling, Using Tools, Retrieval, File Search, Evals, 그리고 원격 도구 서버를 위한 MCP.

• Anthropic: API Overview, Tool Use, 도구 사용 계약, Managed Agents, Context Windows, 그리고 MCP 커넥터.

• MCP 자체: Architecture Overview 및 Specification은 호스트, 클라이언트, 서버, 도구, 프롬프트, 리소스, 전송 및 기능 협상을 깔끔하게 설명하므로 직접 읽을 가치가 있습니다.

• 프레임워크 및 라우팅: LangChain Overview, LlamaIndex 컨텍스트 증강 문서, LiteLLM 라우팅 문서, LangSmith 관찰성 문서.

• 자체 호스팅 런타임 및 어시스턴트 시스템: vLLM, llama.cpp 서버, Ollama 임베딩, OpenClaw 문서 및 리포지토리, Hermes 문서 및 리포지토리.

• 저장소 및 관찰성: Pinecone, Weaviate, pgvector, Milvus, OpenTelemetry, OpenLIT.

• 연구 논문: Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, Lost in the Middle, 그리고 SelfCheckGPT.