대부분의 멀티 에이전트 (multi-agent) 데모는 5분 동안은 인상적이지만 5시간 동안은 쓸모가 없습니다. 오픈 소스 로컬 멀티 에이전트 개발 워크스페이스인 Task Hounds를 몇 달간 구축한 후, 실제로 중요했던 설계 결정 사항들을 공유합니다.

설정 (The setup)

Task Hounds는 하나의 프로젝트를 중심으로 세 개의 에이전트를 루프 (loop) 형태로 실행합니다:

• 매니저 (Manager): 컨텍스트 (context)를 이해하고, 계획을 유지하며, 사이클당 정확히 하나의 구체적인 작업을 할당합니다.
• 워커 (Worker): 작업을 구현하고 구조화된 보고서(변경사항, 테스트 결과, 알려진 문제 등)를 제출합니다.
• 리뷰어 (Reviewer): 매니저가 다음 단계를 결정하기 전에 버그, UX 문제, 리스크를 검사합니다.

사람은 디렉티브 (Directive) (미션)를 작성하며, 실행 도중에 생각이나 새로운 작업을 주입할 수 있습니다. 계획, 할 일 목록 (todos), 보고서, 피드백, 실시간 에이전트 스트림 등 모든 것은 로컬 SQLite에 저장되며 실시간 대시보드에 렌더링됩니다.

레슨 1: 모든 것을 병렬로 처리하는 것보다 한 번에 하나의 작업을 처리하는 것이 낫다

저의 첫 번째 본능은 병렬 워커 (parallel workers)였습니다. 데모는 훌륭했지만 결과물은 아무것도 내놓지 못했습니다. 에이전트들이 서로의 파일을 침범했고, 매니저는 실패의 원인을 파악할 수 없었습니다. 루프당 하나의 작업으로 직렬화 (serializing)하는 것이 더 느려 보이지만, 결과적으로 훨씬 더 많은 작업을 완료합니다.

레슨 2: 사람에게 쓰기 방지된 앵커 (write-protected anchor)를 제공하라

목표 이탈 (Goal drift)은 긴 루프의 조용한 살인자입니다. 루프 10회차쯤 되면 계획이 당신이 요청한 것과 미묘하게 달라지기 시작합니다. 우리의 해결책은 다음과 같습니다: 인간의 디렉티브 (Human Directive)를 모든 세션에 복사하고, 루프가 이를 수정하는 것을 _금지_하는 것입니다. 오직 사람만이 미션을 변경할 수 있습니다. 이제 이탈은 조용한 변이가 아니라, 고정된 앵커 (anchor)로부터 눈에 띄게 벗어나는 형태로 나타납니다.

레슨 3: 채팅 기록이 아닌 구조화된 핸드오프 (Structured handoffs)

에이전트 간에 대화 기록 (conversation history)을 전달하는 방식은 두 가지 측면에서 실패합니다. 하나는 컨텍스트 윈도우 (context window)를 과도하게 소모한다는 것이고, 다른 하나는 하류 (downstream) 에이전트가 상류 (upstream) 에이전트의 추론 노이즈 (reasoning noise)에 앵커링 (anchor)되게 만든다는 점입니다. Task Hounds의 모든 단계 (hop)는 고정된 문서입니다. 매니저 (Manager)의 메모리는 루프당 한 번 읽히는 명시적인 JSON 핸드오프 (handoff)이며, 워커 (Worker)의 출력은 고정된 리포트 스키마 (report schema)입니다. 만약 기계 판독 가능한 할 일 (todo) JSON이 유효하지 않다면, 루프는 작업이 실행되기 전에 이를 수정합니다.

레슨 4: 리뷰어 (Reviewer)는 권한을 가져서는 안 된다

초기에는 리뷰어가 직접 수정 사항을 할당할 수 있었습니다. 그 결과, 두 에이전트가 영원히 협상하며 무한한 리뷰 스파이럴 (review spirals)에 빠지는 현상이 발생했습니다. 이제 리뷰어는 매니저에게 구조화된 피드백을 제출하기만 하며, 최종 결정(수정, 계속, 또는 중단)은 매니저가 내립니다. 판단 (judging)과 결정 (deciding)을 분리함으로써 전체 루프가 안정화되었습니다.

레슨 5: 신뢰는 모델의 문제가 아니라 UI의 문제다

시스템에 부여하는 자율성의 정도를 결정하는 데 있어 가장 큰 변화는 더 나은 모델을 사용하는 것이 아니라, 바로 '지켜볼 수 있게 된 것'이었습니다. 모든 결정이 SQLite의 한 행(row)이자 대시보드의 한 패널로 나타날 때, "한 시간 동안 실행하게 둬도 될까?"라는 질문은 믿음의 문제가 아닌 증거의 문제로 변합니다.

여전히 어려운 점들

• LLM과의 텍스트 계약 (text contracts)은 여전히 취약합니다. 구조화된 출력 (structured outputs) / 도구 호출 (tool-calling)이 우리의 수정 레이어 (repair layer) 일부를 대체할 것입니다.
• 비용: 세 가지 역할은 원샷 프롬프팅 (one-shot prompting)보다 더 많은 토큰을 사용합니다. 우리의 베팅은 '계획(plan) → 구현(implement) → 리뷰(review)' 과정이 혼란에 빠진 단일 에이전트에게 다시 프롬프트를 입력하는 것보다 낭비가 적을 것이라는 점입니다. 이는 긴 작업에는 해당되지만, 작은 수정에는 해당되지 않습니다.
• 크로스 플랫폼 완성도 (현재 관리형 런타임은 Windows 우선이며, Docker는 어디서나 실행됩니다).

시도해보기

Task Hounds는 MIT 라이선스입니다: https://github.com/catowabisabi/task-hounds
3분 데모:

만약 여러분이 에이전트 루프 (agent loops)를 구축해 보셨다면, 여러분의 루프는 어디에서 실패하나요: 계획, 실행, 아니면 리뷰인가요? 댓글을 통해 의견을 나누고 싶습니다.