왜 만들었나
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에 대한 이해가 "사용법"에서 "동작 원리와 구조 설계" 수준으로 바뀌었다.
배운 것
-
단일 모델의 한계는 구조로 극복할 수 있다 — 모델을 바꾸는 것보다, 여러 모델이 협력하는 구조를 설계하는 것이 더 안정적인 품질을 만든다.
-
컨텍스트 설계가 프롬프트보다 중요하다 — 좋은 프롬프트를 쓰는 것보다, 에이전트가 필요한 정보를 자동으로 갖고 있게 만드는 구조가 결과를 더 크게 바꾼다.
-
메모리 없는 에이전트는 매번 처음부터 시작한다 — 파일 기반 메모리와 승격 시스템으로, 에이전트가 시간이 지날수록 나아지는 구조를 만들 수 있다.