AI 시스템: 셀프 호스트드 어시스턴트, RAG 및 로컬 인프라

Page content

대부분의 로컬 AI 세팅은 모델과 런타임으로 시작합니다.

양자화된(quantized) 모델을 다운로드하고, Ollama나 다른 런타임을 통해 실행한 뒤 프롬프팅을 시작합니다. 실험을 위해선 이 정도면 충분합니다. 하지만 단순 호기심을 넘어 메모리, 검색 품질, 라우팅 결정, 비용 인식을 중요하게 여기기 시작하면, 그 단순함이 한계를 드러내기 시작합니다.

이 클러스터는 AI 어시스턴트를 단일 모델 호출이 아닌, 조정(coordination)된 시스템으로 다루는 다른 접근법을 탐구합니다.

그 차이는 처음엔 미묘해 보일 수 있지만, 로컬 AI에 대해 생각하는 방식을 완전히 바꾸어 놓습니다.

로컬 LLM, RAG, 메모리 레이어를 통한 AI 시스템 오케스트레이션

AI 시스템이란 무엇인가?

AI 시스템은 모델 그 이상입니다. 추론, 검색, 메모리, 실행을 연결하여 일관된 어시스턴트처럼 행동하는 무언가를 만드는 오케스트레이션 레이어입니다.

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

다음과 같은 광범위한 가이드를 탐구해 보셨다면:

이미 추론이 스택의 단 하나의 레이어일 뿐임을 알고 계실 것입니다.

AI 시스템 클러스터는 이러한 레이어들의 위를 구성합니다. 그것들을 대체하는 것이 아니라 결합합니다.

프로덕션 어시스턴트에서 LLM, 메모리, 도구, 라우팅, 관측성 등 이러한 레이어들이 어떻게 함께 작동하는지에 대한 횡단적 맵, 그리고 OpenClaw와 Hermes를 참조 시스템으로 한 사례는 AI 어시스턴트 아키텍처: LLM, 메모리, 도구, 라우팅, 관측성에서 확인하십시오.

어시스턴트 아키텍처가 견고해진 후, 다음 단계는 그것을 능동적으로 만드는 것입니다. AI 어시스턴트에서의 폴링 에이전트: 11가지 구현 패턴은 백그라운드 폴링 워커, 큐 기반 실행, 지속적 워크플로, 시맨틱 LLM 평가자가 반응형 어시스턴트를 스스로 관찰하고, 결정하고, 행동하는 존재로 전환하는 방법을 다룹니다.

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

자율성을 추가하기 전에, 에이전트가 어떤 결정을 내릴 수 있도록 허용해야 하는지 묻는 것이 중요합니다. 결정 LLM: 모델이 결정해야 할 때와 결정하면 안 될 때는 모델의 판단과 시스템의 권한을 분리합니다: 5가지 결정 역할, 각 결정을 가장 작은 유능한 티어로 라우팅, 그리고 모델의 호출을 사후 감사 가능하게 만드는 결정 저장소, 불변식, 블래스트 래디어스(영향 범위) 게이트입니다.

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

OpenClaw는 로컬 인프라에서 실행되며 메신저 플랫폼을 가로질러 작동하도록 설계된 오픈소스 셀프호스티드 AI 어시스턴트입니다.

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

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

모델에 대한 래퍼(wrapper)에 불과한 것이 아닙니다. 추론, 검색, 메모리, 실행을 연결하여 일관된 어시스턴트처럼 행동하는 무언가를 만드는 오케스트레이션 레이어입니다.

시작하기 및 아키텍처:

컨텍스트 및 분석:

OpenClaw 확장 및 구성:

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

Hermes: 스킬과 도구 샌드박싱을 갖춘 지속적 에이전트

Hermes Agent는 지속적 운영에 초점을 맞춘 셀프호스티드, 모델-어그노스틱(모델에 무관한) 어시스턴트입니다:长寿 과정으로 실행할 수 있고, 구성 가능한 백엔드를 통해 도구를 실행할 수 있으며, 메모리와 재사용 가능한 스킬을 통해 시간이 지남에 따라 워크플로를 개선할 수 있습니다.

실용적인 수준에서, Hermes는 다음과 같은 것을 원할 때 유용합니다:

  • 메신저 앱으로 브리징할 수도 있는 터미널 우선 어시스턴트
  • OpenAI 호환 엔드포인트와 모델 전환을 통한 제공자 유연성
  • 로컬 및 샌드박스화된 백엔드를 통한 도구 실행 경계
  • 진단, 로그, 구성 위생으로 이루어진 데이투(운영일) 운영

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 기반 프로토콜을 사용합니다.

A2A: 에이전트-간(Agent-to-Agent) 프로토콜

Agent2Agent Protocol(A2A)는 독립적으로 배포된 AI 에이전트 시스템 간의 통신을 위한 오픈 표준입니다. MCP가 에이전트를 도구에 연결하는 반면, A2A는 에이전트를 다른 에이전트에 연결합니다 — Agent Cards를 통해 서로를 발견하고, 작업을 주고받으며, 메시지를 교환하고, 진전을 스트리밍하며, 타입된 아티팩트를 반환할 수 있습니다. A2A는 에이전트가 다른 팀에 의해 소유되거나, 다른 프레임워크로 구축되거나, 상호 운용해야 하는 별도의 서비스로 배포되는 시스템용으로 설계되었습니다.

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

AI 시스템을 더 세밀하게 검토할 가치가 있게 만드는 몇 가지 특성들이 있습니다.

디자인 선택으로서의 모델 라우팅

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

이것은 다음과 같은 질문을 도입합니다:

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

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

AI 시스템은 그러한 결정을 숨기는 대신 드러냅니다.

진화하는 컴포넌트로 취급되는 검색

AI 시스템은 문서 검색을 통합하지만, 단순한 “임베딩하고 검색” 단계로서는 하지 않습니다.

그들은 다음을 인정합니다:

  • 청크 크기가 recall과 비용에 영향을 미칩니다
  • 하이브리드 검색(BM25 + 벡터)은 순수 밀집(Dense) 검색보다 우월할 수 있습니다
  • 리랭킹은 지연 시간의 비용으로 관련성을 개선합니다
  • 인덱싱 전략이 메모리 소비에 영향을 미칩니다

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

차이는 AI 시스템이 검색을 고립된 데모가 아닌 살아있는 어시스턴트에 통합한다는 것입니다. Deep Research는 그 아이디어를 가장 멀리 가져갑니다: 하나의 검색 패스가 아닌, 시스템이 계획하고, 분기하고, 재확인하고, 증거가 충분할 때까지 반복합니다. 셀프호스티드 Deep Research 시스템: 12가지 도구 비교는 12개의 셀프호스티드 시스템 — 재귀적 리서치 트리, 플래너-서브에이전트 디자인, 증거 갭 루프 — 과 각 시스템이 어떻게 검색을 적응형 리서치 루프로 전환하는지를 다룹니다.

인프라로서의 메모리

무상태(Stateless) LLM은 세션 사이에 모든 것을 잊어버립니다.

AI 시스템은 지속적 메모리 레이어를 도입합니다. 이는 즉시 디자인 질문을 제기합니다:

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

그 질문은 데이터 인프라 가이드의 데이터 레이어 고려 사항과 직접 교차합니다. Hermes Agent의 특정 경우 — 제한된 2개 파일 메모리, 프리픽스 캐싱, 외부 플러그인 — Hermes Agent 메모리 시스템과 크로스 프레임워크 비교 에이전트 메모리 제공자 비교에서 시작하십시오. 자동 캡처와 성찰(reflection)은 모델의 자신의 추론을 미래의 “증거"로 전환할 수도 있습니다 — 실패 모드는 AI 에이전트의 자기 강화 메모리 루프에서, 보수적인 로컬 구현은 Hermes Agent를 위한 Mnemosyne에서 확인하십시오. AI 시스템 메모리 허브에는 관련 Cognee 및 지식 레이어 가이드가 나열되어 있습니다.

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

옵션이 아닌 관측성

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

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

  • 토큰 사용량
  • 지연 시간
  • 하드웨어 사용률
  • 처리량 패턴

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

AI가 하드웨어에서 실행된다면, 그것은 다른 워크로드와 마찬가지로 측정 가능해야 합니다.

사용해보니 어떤 느낌인가

바깥에서 보면, AI 시스템은 여전히 채팅 인터페이스처럼 보일 수 있습니다.

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

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

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

가시적인 상호작용은 단순하게 남습니다. 시스템 행동은 레이어가 됩니다.

그 레이어화된 행동이 데모를 시스템과 차별화시킵니다.

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

AI 시스템 클러스터는 여러 인프라 레이어의 교차점에 있습니다:

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

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

OpenClaw를 통한 최소한의 로컬 설치는 OpenClaw 퀵스타트 가이드에서 확인하십시오. 이 가이드는 로컬 Ollama 모델 또는 클라우드 기반 Claude 구성을 사용하는 Docker 기반 세팅을 안내합니다.

세팅이 Claude에 의존한다면, 이 에이전트 도구용 정책 변경은 왜 서드파티 OpenClaw 워크플로에 이제 API 계정이 필요한지를 명확히 합니다.

관련 리소스

A2A: 에이전트-간 프로토콜:

MCP 서버:

비교:

AI 어시스턴트 가이드:

인프라 레이어:

구독하기

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