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

Page content

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

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

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

이러한 구분은 처음엔 미묘해 보일 수 있지만, 로컬 AI에 대해 생각하는 방식을 완전히 변화시킵니다.

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

AI 시스템이란?

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

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

다음에 대한 우리의 폭넓은 가이드를 살펴보셨다면:

추론은 스택의 단 하나의 레이어에 불과하다는 것을 이미 알고 계실 것입니다.

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

프로덕션 어시스턴트에서 LLM, 메모리, 도구, 라우팅, 그리고 가시성이 어떻게 조화를 이루는지, OpenClaw와 Hermes를 참고 시스템으로 삼은 교차적인 지도를 보려면 AI 어시스턴트 아키텍처: LLM, 메모리, 도구, 라우팅, 가시성를 확인하세요.

어시스턴트 아키텍처가 안정되면, 다음 단계는 이를 능동적인(proactive) 것으로 만드는 것입니다. AI 어시스턴트 내 폴링 에이전트: 11가지 구현 패턴은 배경 폴링 워커, 큐 기반 실행, 내구성 워크플로, 그리고 시맨틱 LLM 평가자가 반응형 어시스턴트를 스스로 감시하고, 결정하고, 행동하는 어시스턴트로 전환하는 방법을 다룹니다.

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

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

OpenClaw는 로컬 인프라 위에서 메시징 플랫폼을 가로질러 운영되도록 설계된 오픈 소스 셀프호스티드 AI 어시스턴트입니다.

실용적인 차원에서, OpenClaw는 다음과 같은 기능을 제공합니다:

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

이것은 모델 주위의 단순한 래퍼가 아닙니다. 추론, 검색, 메모리, 실행을 연결하여 일관된 어시스턴트처럼 동작하도록 만드는 오케스트레이션 레이어입니다.

시작하기 및 아키텍처:

컨텍스트 및 분석:

OpenClaw 확장 및 구성:

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

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

Hermes Agent는 지속적 운영에 초점을 맞춘 셀프호스티드, 모델 독립적인 어시스턴트입니다: 긴 수명의 프로세스로 실행할 수 있고, 구성 가능한 백엔드를 통해 도구를 실행할 수 있으며, 메모리와 재사용 가능한 스킬을 통해 워크플로를 시간 흐름에 따라 개선할 수 있습니다.

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

  • 메시징 앱으로의 브리징도 가능한 터미널 우선 어시스턴트
  • OpenAI 호환 엔드포인트 및 모델 전환을 통한 프로바이더 유연성
  • 로컬 및 샌드박스 백엔드를 통한 도구 실행 경계
  • 진단, 로그, 구성 위생에 따른 Day-2 운영

Hermes 프로필은 완전히 격리된 환경입니다 — 각 프로필은 자체 구성, 시크릿, 메모리, 세션, 스킬, 상태를 가지며, 프로필은 개별 스킬이 아닌 실제 프로덕션 소유의 단위입니다.

지속적 지식과 메모리

일부 문제는 더 큰 컨텍스트 윈도우만으로 해결되지 않습니다 — 그것들은 지속적 지식(그래프, 인제스트 파이프라인)과 어시스턴트(예: Hermes 또는 OpenClaw)에 연결된 에이전트 메모리 플러그인(Honcho, Mem0, Hindsight 등 유사한 백엔드)을 필요로 합니다.

MCP: 모델 컨텍스트 프로토콜 서버

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

A2A: 에이전트 간 프로토콜

에이전트 간 프로토콜(A2A)은 독립적으로 배포된 AI 에이전트 시스템 간 통신을 위한 오픈 스탠더드입니다. MCP가 에이전트를 도구에 연결한다면, A2A는 에이전트를 다른 에이전트에 연결합니다 — 에이전트 카드(Agent Cards)를 통해 서로를 발견하고, 태스크와 메시지를 주고받고, 진행 상황을 스트리밍하고, 유형화된 산출물을 반환할 수 있게 합니다. A2A는 에이전트가 다른 팀에 의해 소유되고, 다른 프레임워크로 구축되거나, 상호 운용성이 필요한 별개의 서비스로 배포되는 시스템을 위해 설계되었습니다.

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

AI 시스템을 더 면밀히 살펴볼 가치가 있게 만드는 몇 가지 특성들이 있습니다.

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

대부분의 로컬 세팅은 기본적으로 단일 모델을 사용합니다. AI 시스템은 모델을 의도적으로 선택하는 것을 지원합니다.

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

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

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

AI 시스템은 그러한 결정들을 숨기지 않고 표면으로 올립니다.

검색은 진화하는 구성 요소로 취급됨

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

다음 사항들을 인정합니다:

  • 청크 크기는 재현율(recall)과 비용에 영향을 미친다
  • 하이브리드 검색(BM25 + 벡터)이 순수한 고밀도 검색보다 뛰어난 성능을 낼 수 있다
  • 리랭킹은 지연 시간 비용으로 관련성을 향상시킨다
  • 인덱싱 전략은 메모리 소비에 영향을 미친다

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

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

메모리를 인프라로

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

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

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

그 질문들은 데이터 인프라 가이드의 데이터 레이어 고려 사항과 직접 교차합니다. 특히 Hermes Agent에 대해 — 제한된 2개 파일 메모리, 접두사 캐싱, 외부 플러그인 — Hermes Agent 메모리 시스템과 크로스 프레임워크 비교 에이전트 메모리 프로바이더 비교에서 시작하세요. 자동 캡처와 성찰은 모델의 자체 추론을 미래 “증거"로 전환할 수도 있습니다 — 실패 모드는 AI 에이전트의 자기 강화형 메모리 루프를, 보수적이고 로컬적인 구현은 Hermes Agent용 Mnemosyne를 참고하세요. AI Systems 메모리 허브는 관련 Cognee 및 지식 레이어 가이드를 나열합니다.

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

가시성은 선택 사항이 아님

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

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

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

이것은 가시성 가이드에서 설명된 모니터링 원리와 자연스럽게 연결됩니다.

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

사용할 때 느껴지는 것

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

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

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

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

보이는 상호작용은 여전히 단순합니다. 시스템 행동은 계층적입니다.

그 계층적 행동이 데모와 시스템을 구별합니다.

AI 시스템이 스택에서 차지하는 위치

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

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

그 구분을 이해하는 것은 유용합니다. 스스로 실행해 보면 차이를 더 분명하게 알 수 있습니다.

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

Claude에 의존하는 설정이라면, 이 에이전트 도구 정책 변경이 왜 제3자 OpenClaw 워크플로에서 API 과금이 이제 필수적인지 명확히 해줍니다.

관련 리소스

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

MCP 서버:

AI 어시스턴트 가이드:

인프라 레이어:

구독하기

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