AI 에이전트 아키텍처 3번의 실패기 — 13개에서 10개로의 여정

인격 피어에서 기능적 서브에이전트로, 설계 패러다임 전환의 기록

핵심 요약

13개 에이전트 단일 워크스페이스 → 인격 피어 구조 → 기능적 서브에이전트 구조로 3회 변경
핵심 전환점: 에이전트를 "누구인가(Who)"가 아니라 "무엇을 하는가(What)"로 재정의
월 운영비 약 $20, 서브에이전트 프롬프트 17줄로 극단적 경량화 달성

배경

개인 비서 AI 시스템을 만들면서 아키텍처를 3번 완전히 갈아엎었다. 초기 13개 에이전트에서 시작해 현재 10개 구조로 정착하기까지의 과정을 기록한다.

본문

1차: 13개 에이전트 + 단일 워크스페이스 (Windows)

"동일한 기억을 공유하는 다중 인격체"를 설계 개념으로 삼았다. 결과는 처참했다. 파일 생성 출처 추적 불가, 시스템 변경 영향 범위 파악 불능, 운영 복잡도 극대화. 교훈: 목적과 권한에 따라 워크스페이스를 물리적으로 분리해야 한다.

2차: 멀티에이전트 인격 피어 구조 (v0.3)

Mac Mini로 이전 후 트렌드인 멀티에이전트를 도입했다. mir(메인) 외에 haon, raon, dan 3개 인격 에이전트를 추가하고 sessions_send로 상호 메시지를 교환하게 했다.

런타임에서 세 가지 문제가 터졌다. - 세션 데이터 무한 누적: sessions_send가 기존 세션에 컨텍스트를 계속 덧붙여 maxChildrenPerAgent 한도(기본 10) 도달 - 토큰 오버헤드: 각 에이전트가 성격 유지를 위해 매 API 호출마다 시스템 프롬프트 주입 - 디버깅 불능: 4개 에이전트 간 대화 로그를 역추적하여 원인 특정 불가

멀티에이전트 자체가 나쁜 것은 아니었다. 내 시스템이 필요로 한 것은 "전문가 그룹의 토론"이 아니라 "단일 개인 비서"였을 뿐이다.

3차: 기능적 서브에이전트 구조 (v0.4) — 현재

에이전트를 "누구인가"가 아니라 "무엇을 하는가"로 재정의했다. 인격을 제거하고 순수 기능 모듈로 전환. 모든 서브에이전트는 sessions_spawn(cleanup:"delete")로 호출되어 임무 완수 후 즉시 소멸한다.

User → mir (유일한 인격체, Premium)
       ├─ monitor (시스템 모니터링, 로컬 LLM)
       ├─ researcher (웹 검색, 가성비 모델)
       ├─ communicator (메시지 작성, Premium)
       ├─ orchestrator (코드 작성, Balanced)
       ├─ google (Gmail/Calendar API, 가성비)
       ├─ memory-runner (파일 I/O, 로컬 LLM)
       ├─ memory-manager (정기 정리, 크론)
       ├─ reviewer (월간/주간 리뷰)
       └─ telegram-ops (메시지 포워딩)

티어 기반 모델 라우팅으로 월간 비용을 약 $20으로 구조화했다. 서브에이전트 프롬프트는 17줄 수준.

시행착오 / 주의사항

sessions_spawn 호출 시 대상 에이전트의 자체 모델을 무시하고 부모 모델을 강제 상속하는 버그가 있다(v2026.3.13 기준 미수정). 반드시 명시적으로 모델 파라미터를 오버라이드해야 한다.

sessions_spawn({
  agentId: "memory-runner",
  model: "ollama/qwen3.5:35b-a3b-16k",
  cleanup: "delete"
})

마무리

항목	v0.3 인격 피어	v0.4 기능적 서브에이전트
세션 관리	영구 누적	일회성 자동 삭제
토큰 오버헤드	매우 높음	매우 낮음
디버깅	N x M 복잡도	1:1 명확함

개인 비서에 가장 부합하는 아키텍처는 거창한 멀티에이전트가 아니라, 철저히 통제되는 기능적 서브에이전트 구조였다.

이 블로그 검색

MaJu's Note