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

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

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

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

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

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

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

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

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

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

즉, 어시스턴트 시스템은 채팅 완료(chat completion)보다 더 넓은 계약을 가집니다. 좋은 내부 계약은 다음과 같습니다:

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

이 계약이 중요한 이유는 모든 프로덕션 상의 불일치가 결국 다음 질문들 중 하나로 귀결되기 때문입니다: 어떤 컨텍스트가 가시적이었는가, 어떤 도구가 실행되었는가, 어떤 모델이 답변했는가, 어떤 메모리가 읽히거나 쓰여졌는가, 그리고 추적이 시스템이 시간을 어디에 보냈다고 말하는가. OpenTelemetry는 추적(trace)을 애플리케이션을 통과하는 요청의 경로로 정의하는데, 이는 진지한 어시스턴트가 필요한 추상화입니다. 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 검색 및 파일 검색은 벡터 저장소 위에 의미론적 및 키워드 검색을 레이어링합니다. Pinecone, Weaviate, pgvector, Milvus는 네 가지 공통 저장소 형태를 나타냅니다: 완전히 관리되는, 오픈소스 벡터 네이티브, Postgres 네이티브, 분산 벡터 데이터베이스. Hermes와 OpenClaw는 모든 메모리가 벡터 저장소에 속하는 것은 아니라는 유용한 알림을 추가합니다: 파일 기반 노트, 검토된 프로모션, 세션 범위 스냅샷은 종종 더 정직한 설계입니다 — Hermes Agent Memory System에서 제한된 핵심 메모리와 고정된 세션 스냅샷을 위한 패턴이 unpacked됩니다.

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

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

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

캡처, 풍요화, 응답

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

sequenceDiagram
    participant U as User or Channel
    participant G as Gateway or UI
    participant R as Router
    participant M as Memory and Retrieval
    participant L as LLM
    participant T as Tools or MCP
    participant O as Observability

    U->>G: message, file, or command
    G->>O: start root trace
    G->>R: request + identity + session + policy
    R->>M: load session state and retrieve context
    M-->>R: notes, chunks, metadata
    R->>L: prompt + context + tool schemas
    L-->>R: answer or tool call
    alt tool call
        R->>T: execute tool or MCP action
        T-->>R: tool result
        R->>L: tool result + updated context
        L-->>R: final answer
    end
    R->>M: persist session changes and memory candidates
    R->>O: spans, metrics, eval events
    G-->>U: response

캡처 단계는 보통 보이는 것보다 더 중요합니다. OpenClaw와 Hermes는 둘 다 게이트웨이를 어시스턴트 앞에 지속적으로 두는데, 그 이유는 인그레스(ingress)가 단순히 텍스트 입력이 아니기 때문입니다. 이는 채널 메타데이터, 정체성, 인증, 세션 경계, 직접 메시지, 그룹, cron 틱, 그리고 전달 시맨틱스를 포함합니다. 이 레이어를 건너뛰고 원시 채팅 위젯 추상화에 의존하면 결국 결국 ad hoc 미들웨어로 다시 붙이게 됩니다.

풍요화 단계는 성숙한 시스템이 장난감 데모와 다른 곳입니다. OpenAI 검색 및 파일 검색은 벡터 저장소와 검색 호출을 통해 검색을 명시적으로 만듭니다. LlamaIndex는 데이터 커넥터, 인덱스, 쿼리 엔진, 워크플로우를 통해 동일한 패턴을 공식화합니다. Hermes는 모델 에스테이트를 주요 및 보조 슬롯으로 나누어 압축, 요약, 라우팅과 같은 작업을 더 작거나 더 전문화된 모델로 오프로드하여 더 나아갑니다. 이는 훔쳐쓸 가치가 있는 설계 패턴입니다: 가장 비싼 모델 토큰을 잡일(chores)에 쓰지 마세요.

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

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

참조 시스템으로서의 OpenClaw와 Hermes

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

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

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

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

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 호환 플랫폼은 전체 경로를 추적할 수 있습니다.

패턴, 표, 그리고 트레이드오프

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

이 패턴 표는 단일 벤더의 주장이 아니라 제공자 문서, 프레임워크 문서, 참조 시스템의 종합입니다.

표 노트: OpenAI 호스팅 파일 검색은 관리된 도구이며, Anthropic은 관리된 하네스를 제공하며, Pinecone은 관리된 벡터 서비스입니다. 반면 vLLM, llama.cpp, Ollama, pgvector, Weaviate, Milvus, LangSmith 자체 호스팅, OpenLIT는 다양한 정도로 자체 관리 또는 하이브리드 운영을 지원합니다.

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

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

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

실패 모드 및 완화

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

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

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

더 읽기

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

• 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.