ksungz
Engineering

개인 AI 에이전트 워크스페이스 설계

OpenClaw + Ollama Cloud + Obsidian 기반의 멀티 모델 에이전트 시스템을 설계하고 운영한 경험

OpenClawOllama CloudObsidianMCPMulti-AgentDiscord

왜 만들었나

AI 도구를 쓰다 보면 자연스럽게 궁금해진다 — 이 도구의 내부 구조는 어떻게 되어 있을까? 내가 원하는 방식으로 동작하게 만들 수는 없을까?

단순히 AI를 "사용"하는 것과, 에이전트가 작업을 받고 → 어떤 모델로 처리하고 → 결과를 어디에 기록하는지 전체 흐름을 직접 설계하는 것은 완전히 다른 경험이다. 후자를 해보고 싶었다.

전체 아키텍처

사용자 (Discord 채널)
  → OpenClaw Gateway (오케스트레이션)
    → Ollama Cloud (멀티 모델 추론)
    → Obsidian Vault (지식 베이스 + 메모리)
    → MCP Workspace (실제 프로젝트 코드 접근)

각 구성요소의 역할

구성요소역할
Discord작업 지시 입력, 결과 출력. 채널별로 프로젝트가 매핑되어 컨텍스트 자동 전환
OpenClaw Gateway중앙 오케스트레이터. 작업 분석, 모델 라우팅, 서브에이전트 관리
Ollama Cloud역할별 모델 풀 운영 (메인 라우터, 한국어 특화, 장문 분석, 경량 보조)
Obsidian Vault프로젝트 문서, 일일 메모리, 작업 지시서, 도메인 지식 저장
MCP파일시스템 접근으로 실제 코드 프로젝트를 읽고 수정

모델 풀 설계

단일 모델로 모든 작업을 처리하지 않는다. 역할에 따라 모델을 분리했다.

역할용도선택 기준
메인 라우터작업 분석, 도구 호출, 기획Agentic 성능 + 멀티모달
한국어·범용한국어 분석, 이미지 입력한국어 품질 + 비용 효율
장문 분석대용량 컨텍스트 처리1M 토큰 컨텍스트
경량 보조단순 텍스트 처리속도 + 비용 최소화

핵심: 초다중검토 (멀티 모델 심의 시스템)

가장 핵심적인 기능이다. 중요한 의사결정에서 단일 모델의 편향을 제거하기 위해 설계했다.

왜 필요한가

하나의 모델에게 물어보면 그 모델의 학습 편향이 그대로 결과에 반영된다. 특히 기획이나 구조 설계처럼 정답이 없는 문제에서, 하나의 관점만으로는 빈틈이 생긴다.

동작 구조

Stage 1 — 관점별 초안 생성

3개 모델이 각각 다른 관점에서 동일 주제를 분석한다:

  • 모델 A → 기술·구현 관점
  • 모델 B → 비즈니스·사용자 관점
  • 모델 C → 구조·리스크 관점

Stage 2 — 교차 비판

각 모델이 다른 모델의 초안을 비판한다. "A가 놓친 점", "B의 논리적 허점" 등을 지적하며 수렴 리포트를 생성한다.

Stage 3 — 합의 검증

합의도 ≥ 80% → 최종 결과 확정
합의도 < 80% → 재시도 (최대 3회)
3회 실패 → 사람이 직접 판단

실제 효과

단일 모델 대비 결과물의 빈틈이 확연히 줄어든다. 특히 "내가 미처 생각 못한 관점"을 교차 비판 단계에서 잡아내는 것이 가장 큰 가치다.

Self-Improving 메모리 구조

에이전트는 매 세션 새로 시작된다. 그래서 파일 기반 메모리 시스템을 설계했다.

3단계 메모리 티어

티어로드 시점내용
HOT항상핵심 규칙, 최근 교정 사항 (100줄 이내)
WARM프로젝트 매칭 시프로젝트별 컨텍스트, 도메인 지식
COLD명시적 요청 시아카이브, 오래된 기록

승격·디모션 규칙

  • 3회 이상 적용된 교정 → HOT 승격 (사람 확인 필수)
  • 30일 미사용 → 디모션 후보
  • 90일 미사용 → COLD 아카이브 이동

핵심은 에이전트가 같은 실수를 반복하지 않도록 학습 결과가 자동으로 축적되는 구조다.

채널-프로젝트 자동 매핑

Discord 채널별로 프로젝트가 매핑되어 있다. 특정 채널에서 말하면 해당 프로젝트의 문서와 코드가 자동으로 컨텍스트에 로딩된다.

이 설계의 핵심은 컨텍스트 전환 비용 제거다. 여러 프로젝트를 동시에 관리하면서도, 채널만 바꾸면 에이전트가 해당 프로젝트의 맥락을 이미 알고 있는 상태가 된다.

"도구 사용자"에서 "시스템 설계자"로

대부분의 AI 활용은 "좋은 프롬프트를 쓰는 것"에서 끝난다. 하지만 직접 시스템을 설계해보면 관점이 완전히 달라진다.

  • 어떤 모델이 어떤 작업에 강한지 체감하게 된다
  • 에이전트의 한계가 "모델 성능"이 아니라 "컨텍스트 설계"에 있다는 걸 알게 된다
  • 메모리가 없으면 매번 같은 실수를 반복한다는 걸 직접 겪는다

이 시스템을 만들면서 AI에 대한 이해가 "사용법"에서 "동작 원리와 구조 설계" 수준으로 바뀌었다.

배운 것

  1. 단일 모델의 한계는 구조로 극복할 수 있다 — 모델을 바꾸는 것보다, 여러 모델이 협력하는 구조를 설계하는 것이 더 안정적인 품질을 만든다.

  2. 컨텍스트 설계가 프롬프트보다 중요하다 — 좋은 프롬프트를 쓰는 것보다, 에이전트가 필요한 정보를 자동으로 갖고 있게 만드는 구조가 결과를 더 크게 바꾼다.

  3. 메모리 없는 에이전트는 매번 처음부터 시작한다 — 파일 기반 메모리와 승격 시스템으로, 에이전트가 시간이 지날수록 나아지는 구조를 만들 수 있다.