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

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

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

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

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

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

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

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

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

실용적인 정의는 다음과 같습니다: AI 어시스턴트 시스템은 모델 인터페이스, 컨텍스트 조립, 도구 실행, 상태 관리 및 텔레메트리(telemetry)를 결합하여 사용자 의도를 응답 또는 행동으로 전환하는 런타임입니다. 이것이 유용한 문서가 단순히 모델 카드(model card)가 아닌 이유입니다. 유용한 문서는 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 검색 및 파일 검색은 벡터 스토어 위에 의미론적 및 키워드 검색을 층(layer)으로 쌓습니다. Pinecone, Weaviate, pgvector, Milvus는 네 가지 일반적인 저장 형태를 나타냅니다: 완전 관리형, 오픈소스 벡터 네이티브, Postgres 네이티브, 분산 벡터 데이터베이스. Hermes와 OpenClaw는 모든 메모리가 벡터 스토어에 속하는 것은 아니라는 유용한 알림을 추가합니다: 파일 기반 메모, 검토된 프로모션, 세션 스코프 스냅샷은 종종 더 정직한 설계입니다. AI 어시스턴트에서의 메모리 시스템은 크로스 프레임워크 모델을 매핑하고, Hermes 에이전트 메모리 시스템는 하나의 제품에서 유한한 코어 메모리와 고정된 세션 스냅샷을 해체합니다.

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

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

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

캡처, 부스팅, 응답

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

캡처 단계는 일반적으로 보이는 것보다 더 중요합니다. OpenClaw와 Hermes는 둘 다 어시스턴트 앞에 지속 가능한 게이트웨이를 배치합니다. 왜냐하면 인그레스(ingress)는 단순히 텍스트 입력이 아니기 때문입니다. 이는 채널 메타데이터, 식별자, 인증, 세션 경계, 직접 메시지, 그룹, 크론 틱(cron ticks) 및 전송 시맨틱스를 포함합니다. 만약 이 레이어를 건너뛰고 원시 채팅 위젯 추상화에 의존한다면, 결국 어드혹(ad hoc) 미들웨어로 다시 붙이게 될 것입니다.

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

응답 단계는 “텍스트 생성"이 아닙니다. 그것은 “현재 루프 닫기"입니다. 모델이 직접 답변할 수 있다면 그렇게 합니다. 도구가 필요하다면 구조화된 요청을 방출합니다. 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는 강하게 에이전트 루프 우선입니다. 하지만 둘 다 어시스턴트가 단지 “프롬프트 plus 모델"이라는 얕은 아이디어를 거부합니다. 그들은 채널, 식별자, 메모리 시맨틱스, 도구 표면 및 백엔드 이질성을 일급 관심사로 모델링합니다. 이것이 프로덕션 아키텍처가 해야 할 일입니다.

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

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의 공식 문서 모두 이러한 패턴의 버전을 지원하며, 비록 이름을 다르게 부른다고 해도 마찬가지입니다.

전문가 메시 패턴은 에이전트 수가 증가함에 따라 별도의 엔지니어링 дисциплина(학문/실무)로 성장합니다. 6가지 정통 조정 패턴 — 오케스트레이터-워커, 순차 파이프라인, 팬아웃(fan-out), 계층적, 스웜(swarm), 메시 — 및 특정 실패 모드와 프로덕션 결정 프레임워크에 대해서는 다중 에이전트 오케스트레이션 패턴을 참조하세요.

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

테이블 참고: 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 호환 서버 plus Anthropic Messages API 지원을 노출합니다. Ollama는 로컬 임베딩 및 모델 워크플로우를 문서화합니다. llama.cpp는 OpenAI 호환 채팅, 응답 및 임베딩 라우트 plus Anthropic 호환 채팅 완료를 문서화합니다.

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

실패 모드 및 완화

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

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

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

더 읽기

더 깊이 들어가려면 어시스턴트 아키텍처를 설계하거나 검토하는 동안 열어두어야 할 가장 유용한 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은 직접 읽을 가치가 있습니다. 왜냐하면 호스트, 클라이언트, 서버, 도구, 프롬프트, 리소스, 전송 및 기능 협상을 깔끔하게 설명하기 때문입니다. MCP와 Agent2Agent 프로토콜의 실용적 비교 및 다중 에이전트 시스템이 두 레이어 모두를 필요로 할 때에 대해서는 A2A vs MCP: AI 에이전트는 정말로 두 프로토콜 모두 필요할까?를 참조하고, A2A 개념 자체 — 에이전트 카드, 작업 라이프사이클, 메시지, 파트 및 아티팩트 — 에 대해서는 A2A 프로토콜이란? 에이전트 카드 및 작업 설명을 참조하세요.

• 배경 및 사전적 어시스턴트: 툴링 레이어는 어시스턴트가 행동하는 방식의 일부에 불과합니다. 어시스턴트가 스스로 감시하고, 결정하고, 행동하도록 만드는 방법 — 스케줄러, 큐 기반 워커, 클레임 프로토콜, 내구성 워크플로우 및 의미론적 폴링 — 에 대해서는 AI 어시스턴트에서의 폴링 에이전트: 11가지 구현 패턴을 참조하세요.

• A2A 프로토콜 및 채택: 에이전트가 독립적으로 배포되고 소유 경계를 넘어 협업해야 할 때 A2A가 관련성이 높아집니다. A2A가 실제로 견인을 얻고 있는 곳, 그것이 제기하는 보안 질문, 그리고 채택할 시기에 대한 결정 프레임워크에 대한 실용적인 2026년 관점을 위해 2026년 Google A2A 프로토콜: 채택, 과열 및 현실을 참조하세요. 에이전트가 단일 채팅 턴 대신 장기 작업을 교환할 때, A2A 스트리밍 및 장기 에이전트 워크플로우용 비동기 작업은 프로토콜 경계에서 SSE, 푸시 및 input_required 설계를 다룹니다.

• 프레임워크 및 라우팅: 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.