AI 시스템: 자체 호스팅 어시스턴트, RAG 및 로컬 인프라

Page content

대부분의 로컬 AI 설정은 모델과 런타임에서 시작합니다.

양자화(quantized) 모델을 다운로드하고, Ollama 또는 다른 런타임을 통해 실행한 뒤 프롬프트 입력을 시작합니다. 실험을 위한 수준이라면 이것만으로도 충분합니다. 그러나 단순한 호기심을 넘어선 시점—메모리, 검색 품질, 라우팅 결정, 비용 인지 등이 중요해지기 시작하는 순간—이러한 단순함의 한계가 드러나기 시작합니다.

이 클러스터는 다른 접근 방식을 탐구합니다. AI 어시스턴트를 단일 모델 호출로 보는 것이 아니라, 하나의 조율(coordinated) 시스템으로 다루는 방식입니다.

이 구별은 처음에는 미묘해 보일 수 있지만, 로컬 AI에 대한 사고 방식을 완전히 변화시킵니다.

로컬 LLM, RAG, 메모리 계층을 활용한 AI 시스템 오케스트레이션

AI 시스템이란 무엇인가?

AI 시스템은 단순한 모델을 넘어섭니다. 추론, 검색, 메모리, 실행을 연결하여 일관된 어시스턴트처럼 작동하는 조율(orchestration) 계층입니다.

모델을 로컬에서 실행하는 것은 인프라 작업입니다. 그 모델을 중심으로 어시스턴트를 설계하는 것은 시스템 엔지니어링 작업입니다.

다음과 같은 보다 포괄적인 가이드를 탐구해 보셨다면:

이미 추론이 스택의 한 계층에 불과하다는 것을 알고 계실 것입니다.

AI Systems 클러스터는 이러한 계층 위에 위치합니다. 그것들을 대체하지는 않지만, 결합합니다.

프로덕션 어시스턴터에서 이러한 계층들이 어떻게 함께 작동하는지에 대한 횡단적 맵—LLM, 메모리, 툴링, 라우팅, 관측 가능성, 그리고 OpenClaw와 Hermes를 참조 시스템으로 활용—에 대해서는 AI 어시스턴트 아키텍처: LLM, 메모리, 툴, 라우팅, 관측 가능성을 참조하세요.

어시스턴트 아키텍처가 견고해지면, 다음 단계는 이를 능동적으로 만드는 것입니다. AI 어시스턴트의 폴링 에이전트: 11가지 구현 패턴은 배경 폴링 워커, 큐 기반 실행, 내구성 워크플로, 시맨틱 LLM 평가자가 반응형 어시스턴트를 스스로 관찰하고, 결정하고, 행동하는 것으로 전환하는 방식을 다루고 있습니다.

단일 어시스턴트로는 부족하고 여러 에이전트가 조정(coordination)해야 할 때, 조정 패턴의 선택이 모든 것을 결정합니다: 레이턴시, 장애 허용, 비용, 디버깅 용이성. 멀티 에이전트 오케스트레이션 패턴: 실용적 가이드는 오케스트레이터-워커, 순차 파이프라인, 팬아웃, 위계적, 스웜, 메시라는 6가지 정규 패턴과 구체적인 실패 모드, 적절한 아키텍처를 선택하기 위한 의사결정 프레임워크를 다룹니다.

OpenClaw: 셀프 호스티드 AI 어시스턴트 시스템

OpenClaw는 로컬 인프라에서 실행되면서 메시징 플랫폼 전반에 걸쳐 작동하도록 설계된 오픈 소스 셀프 호스티드 AI 어시스턴트입니다.

실용적인 수준에서, OpenClaw는 다음과 같은 역할을 합니다:

  • Ollama 또는 vLLM과 같은 로컬 LLM 런타임 사용
  • 인덱싱된 문서에 대한 검색 통합
  • 단일 세션을 넘어선 메모리 유지
  • 툴 및 자동화 작업 실행
  • 계측 및 관측 가능
  • 하드웨어 제약 내에서 작동

단순한 모델 래퍼가 아닙니다. 추론, 검색, 메모리, 실행을 연결하여 일관된 어시스턴트처럼 작동하는 조율 계층입니다.

시작 가이드 및 아키텍처:

컨텍스트 및 분석:

OpenClaw 확장 및 구성:

플러그인은 OpenClaw 런타임을 확장합니다 — 메모리 백엔드, 모델 프로바이더, 통신 채널, 웹 툴, 관측 가능성을 추가합니다. 스킬은 에이전트 행동을 확장합니다 — 에이전트가 이러한 역량을 어떻게, 언제 사용할지 정의합니다. 프로덕션 구성은 실제로 시스템을 사용하는 사람을 중심으로 둘 다를 결합하는 것을 의미합니다.

Hermes: 스킬과 툴 샌드박싱을 갖춘 영속적 에이전트

Hermes Agent는 영속적 운영에 집중하는 셀프 호스티드, 모델 비종속적 어시스턴트입니다: 장기간 프로세스로 실행할 수 있고, 구성 가능한 백엔드를 통해 툴을 실행하며, 메모리와 재사용 가능한 스킬을 통해 워크플로를 시간에 따라 개선할 수 있습니다.

실용적인 수준에서, Hermes는 다음과 같은 경우가 유용합니다:

  • 메시징 앱으로 브리징할 수도 있는 터미널 우선 어시스턴트
  • OpenAI 호환 엔드포인트와 모델 스위칭을 통한 프로바이더 유연성
  • 로컬 및 샌드박스 백엔드를 통한 툴 실행 경계
  • 진단, 로그, 구성 위생으로 2일차 운영

Hermes 프로파일은 완전히 격리된 환경입니다 — 각각 고유한 구성, 시크릿, 메모리, 세션, 스킬, 상태를 가지며 — 개별 스킬이 아닌 프로파일을 실제 프로덕션 소유权的 단위로 만듭니다.

영속적 지식과 메모리

일부 문제는 더 큰 컨텍스트 윈도우만으로 해결되지 않습니다 — 영속적 지식(그래프, 인제스트 파이프라인)과 에이전트 메모리 플러그인(Honcho, Mem0, Hindsight 및 유사한 백엔드)이 Hermes나 OpenClaw와 같은 어시스턴트에 통합되어야 합니다.

MCP: Model Context Protocol 서버

Model Context Protocol(MCP)은 Anthropic이 AI 언어 모델을 외부 데이터 소스, 툴, 시스템에 연결하기 위해 도입한 오픈 표준입니다. N×M 통합 문제를 해결하며, 보편적 인터페이스를 제공합니다 — AI 애플리케이션용 USB-C 포트라고 생각하면 됩니다. MCP 서버를 구축하면 파일, 데이터베이스, API, 호출 가능한 툴을 위한 커스텀 통합으로 AI 어시스턴트를 확장할 수 있으며, 이는 stdio 또는 HTTP를 통한 간단한 JSON-RPC 기반 프로토콜을 사용합니다.

  • 에이전트 스킬 vs MCP 서버: 의사결정 프레임워크 — 언제 스킬을 사용할지, 언제 MCP 서버를 구축할지, 씽-서버 패턴이 둘 다를 어떻게 결합하는지에 대한 실용적 의사결정 프레임워크
  • Go로 MCP 서버 구현 — 프로토콜 아키텍처, JSON-RPC 메시지 구조, 능력 협상, 공식 Go SDK, Go로 MCP 서버를 구축하는 단계별 튜토리얼
  • Python으로 MCP 서버 구축 — 웹 검색 및 스크래핑 MCP 서버, stdio 및 SSE 트랜스포트, Claude Desktop 통합을 다루는 실용적 Python 구현 가이드

A2A: Agent-to-Agent Protocol

Agent2Agent Protocol(A2A)은 독립적으로 배포된 AI 에이전트 시스템 간 통신을 위한 오픈 표준입니다. MCP가 에이전트를 툴에 연결한다면, A2A는 에이전트를 다른 에이전트에 연결합니다 — 상호 발견(Agent Cards를 통해), 작업 및 메시지 교환, 진행 상황 스트리밍, 타입화된 산출물 반환을 가능하게 합니다. A2A는 에이전트가 다른 팀에 의해 소유되고, 다른 프레임워크로 구축되거나, 상호 운용이 필요한 별도 서비스로 배포되는 시스템을 위해 설계되었습니다.

AI 시스템을 특별하게 만드는 것들

여러 가지 특성이 AI 시스템을 더 면밀히 검토할 가치가 있게 만듭니다.

모델 라우팅을 설계 선택으로

대부분의 로컬 설정은 하나의 모델로 기본값을 설정합니다. AI 시스템은 의도적으로 모델을 선택하도록 지원합니다.

이는 다음 질문들을 도입합니다:

  • 작은 요청은 더 작은 모델을 사용해야 하는가?
  • 언제 추론이 더 큰 컨텍스트 윈도우를 정당화하는가?
  • 1,000 토큰당 비용 차이는 얼마인가?

이 질문들은 LLM 성능 가이드에서 논의된 성능 트레이드오프와 LLM 호스팅 가이드에概述된 인프라 결정과 직접 연결됩니다.

AI 시스템은 이러한 결정들을 숨기기 대신 표면화합니다.

검색은 진화하는 구성요소로 취급됩니다

AI 시스템은 문서 검색을 통합하지만, 단순한 “임베딩 및 검색” 단계가 아닙니다.

그것들은 다음을 인식합니다:

  • 청크 크기가 리콜과 비용에 영향을 미칩니다
  • 하이브리드 검색(BM25 + 벡터)이 순수한 dense retrieval보다 우수할 수 있습니다
  • 리랭킹은 레이턴시 비용으로 관련성을 향상시킵니다
  • 인덱싱 전략이 메모리 소비에 영향을 미칩니다

이러한 주제들은 RAG 튜토리얼에서 논의된 더 깊은 아키텍처 고려 사항과 일치합니다.

차이점은 AI 시스템이 검색을 격리된 데모로 제시하기보다, 살아있는 어시스턴트에 내장한다는 것입니다.

메모리를 인프라로

무상태(stateless) LLM은 세션 간 모든 것을 잊습니다.

AI 시스템은 영속적 메모리 계층을 도입합니다. 이는 즉시 설계 질문을 제기합니다:

  • 장기적으로 무엇을 저장해야 하는가?
  • 언제 컨텍스트를 요약해야 하는가?
  • 토큰 폭발을 어떻게 방지하는가?
  • 메모리를 어떻게 효율적으로 인덱싱하는가?

이 질문들은 데이터 인프라 가이드의 데이터 계층 고려 사항과 직접 교차합니다. Hermes Agent에 특히—제한된 2파일 메모리, 프리픽스 캐싱, 외부 플러그인—Hermes Agent 메모리 시스템과 프레임워크 간 비교 에이전트 메모리 프로바이더 비교로 시작하세요. AI Systems 메모리 허브는 관련 Cognee 및 지식 계층 가이드를 나열합니다.

메모리는 기능이 멈추고 저장 문제가 됩니다.

관측 가능성은 선택이 아닙니다

대부분의 로컬 AI 실험은 “응답한다"에서 멈춥니다.

AI 시스템은 다음을 관찰할 수 있게 만듭니다:

  • 토큰 사용량
  • 레이턴시
  • 하드웨어 활용도
  • 처리량 패턴

이는 관측 가능성 가이드에 설명된 모니터링 원리와 자연스럽게 연결됩니다.

AI가 하드웨어에서 실행된다면, 다른 워크로드처럼 측정 가능해야 합니다.

사용해보니 어떤 느낌인가?

겉으로 보면, AI 시스템은 여전히 채팅 인터페이스처럼 보일 수 있습니다.

표면 아래에서는 더 많은 일이 일어납니다.

로컬에 저장된 기술 보고서를 요약해 달라고 요청하면:

  1. 관련 문서 세그먼트를 검색합니다.
  2. 적절한 모델을 선택합니다.
  3. 응답을 생성합니다.
  4. 토큰 사용량과 레이턴시를 기록합니다.
  5. 필요 시 영속적 메모리를 업데이트합니다.

가시적인 상호작용은 여전히 간단합니다. 시스템 행동은 계층적입니다.

이러한 계층적 행동이 시스템과 데모를 구분합니다.

AI 시스템이 스택에서 어디에 위치하는가

AI Systems 클러스터는 여러 인프라 계층의 교차점에 위치합니다:

  • LLM 호스팅: 모델이 실행되는 런타임 계층 (Ollama, vLLM, llama.cpp)
  • RAG: 컨텍스트와 기반을 제공하는 검색 계층
  • 성능: 레이턴시와 처리량을 추적하는 측정 계층
  • 관측 가능성: 지표와 비용 추적을 제공하는 모니터링 계층
  • 데이터 인프라: 메모리와 인덱싱을 처리하는 저장 계층

이 구별을 이해하는 것은 유용합니다. 직접 실행해 보면 차이가 더 명확해집니다.

OpenClaw를 사용한 최소 로컬 설치에 대해서는 OpenClaw 퀵스타트 가이드를 참조하세요. 이는 로컬 Ollama 모델 또는 클라우드 기반 Claude 구성을 사용한 Docker 기반 설정을 안내합니다.

설정에서 Claude에 의존한다면, 에이전트 툴을 위한 이 정책 변경가 왜 3자 OpenClaw 워크플로에서 이제 API 결제가 필요한지 명확히 합니다.

관련 리소스

A2A: Agent-to-Agent Protocol:

MCP 서버:

AI 어시스턴트 가이드:

인프라 계층:

구독하기

시스템, 인프라, AI 엔지니어링에 관한 새 글을 받아보세요.