스스로 멈추는 에이전트 루프

· 중국어 버전 읽기 →

AI가 작성한 내용을 신뢰할 수 있을까요? 그리고 그것을 확인하는 데 드는 비용은 얼마일까요? 이 두 가지는 AI 코딩에 관한 정직한 질문이며, 모두가 두 질문 모두에 대해 목소리를 높이고 있습니다. 하지만 제가 많이 듣지 못한 것은 이 두 질문이 사실상 같은 질문이라는 점입니다. 당신은 하나의 설계로 이 두 문제를 모두 해결할 수 있습니다.

편향(Bias) 사례는 익숙한 것입니다. 모델은 세상의 왜곡된 단면을 바탕으로 학습되며, 출력물은 그 왜곡을 물려받기 때문에 완전히 신뢰할 수 없습니다. 모두 사실입니다. 하지만 그렇다고 해서 멈춰야 한다는 뜻은 아닙니다. 그것은 단 하나의 모델에만 의존하는 것을 멈춰야 한다는 의미입니다. 몇 개의 모델을 실행하여 서로를 점검하게 하세요. 그러면 한 모델이 보지 못하는 것을 보통 다른 모델이 잡아냅니다.

그리고 이 해결책이 바로 비용을 두 번째 질문으로 만드는 정확한 이유입니다. 두 개의 모델은 하나보다 비용이 더 많이 듭니다. 세 명의 에이전트가 서로 대화하는 것은 세 명이 각자 일하는 것보다 비용이 더 많이 들며, 아무도 감시하지 않는 루프는 원하는 만큼 비용을 발생시킵니다. 따라서 당신은 하나의 설계로 두 가지 문제를 해결하고 있는 것입니다. 즉, 오류를 잡아낼 수 있을 만큼 충분한 불일치(Disagreement)를 확보하되, 그 불일치가 당신이 동의하지 않은 청구서를 만들어내지 않도록 차단하는 것입니다. 검증(Verification)을 구축하고 이를 제한(Capping)하는 것은 결국 같은 작업임이 드러납니다.

세 가지 도구가 서로 다른 규모로 이를 수행하며, 여기에는 제가 직접 만든 도구도 포함되어 있습니다.

opencode-fusion: 논쟁하는 패널, 그리고 판사

opencode-fusion은 Samir Patil(@sampatil1010)이 OpenRouter의 Fusion(@OpenRouter)을 로컬 환경에서 구현한 방식입니다. 하나의 작업을 여러 모델 패널(Panel)을 통해 동시에 실행한 다음, 불일치를 평균화하여 없애는 대신 그 불일치를 해결합니다. 기본 패널은 Sonnet, GPT, GLM이며, 모델을 추가하거나 제거하기 위해 편집할 수 있는 bash 배열로 정의되어 있습니다. 이들은 OpenCode CLI를 통해 병렬로 실행되며, 각 출력은 자체 임시 파일에 기록됩니다. 실패 사례는 기록되지만 실행이 중단되지는 않습니다.

그다음 판사 모델 (judge model)이 모든 출력을 읽고 구조화된 보고서를 작성합니다. 모델들이 서로 동의하는 부분, 서로 모순되는 부분과 어느 쪽이 맞을 가능성이 높은지, 모든 모델이 놓친 부분은 무엇인지, 그리고 무엇이 위험해 보이는지를 기록합니다. 합성기 (synthesizer)는 원래의 작업 (task), 판사의 보고서, 그리고 가공되지 않은 출력물 (raw outputs)을 가져와서 여러분이 실제로 보게 될 단 하나의 답변을 생성합니다.

여러분은 단 한 줄의 명령어로 이 모든 과정을 실행할 수 있습니다:

bash run_fusion.sh "<TASK>"

병렬 처리 (parallelism)는 지루한 부분입니다. 여러분이 실제로 얻는 가치는 바로 '불일치 (disagreement)'입니다. 두 모델이 동일한 답변에 도달하고 세 번째 모델이 엉뚱한 곳으로 빠졌을 때, 그 간극은 단일한 확신에 찬 응답에서는 결코 알 수 없는 무언가를 알려줍니다. 판사가 읽는 작업을 수행하므로, 여러분은 세 개의 전사 (transcripts) 대신 하나의 답변을 받게 됩니다.

agmsg: 서로 메시지를 주고받는 에이전트들

opencode-fusion은 원샷 (one-shot) 방식입니다. 질문하면 패널이 답변하고 끝납니다. 때로는 모델들이 서로 의견을 주고받기를 원할 수도 있습니다. 그것이 바로 @fujibee가 만든 agmsg입니다.

agmsg는 CLI 에이전트들이 공유된 SQLite 파일을 통해 서로 메시지를 주고받을 수 있게 해줍니다. 데몬 (daemon)도, 네트워크도 필요 없으며, 에이전트 기술 (agent skill)로 설치되는 bash와 sqlite3만 있으면 됩니다. 이는 벤더 간 교차 사용 (cross-vendor)이 가능하므로, Claude Code, Codex, Gemini CLI, 그리고 Copilot CLI가 동일한 팀에 합류하여 메시지를 전달할 수 있습니다. 또한 메시지가 지속 (persist)된다는 점이 다른 대안들과 차별화되는 요소입니다. 내장된 서브 에이전트 (subagent)는 일시적 (ephemeral)이며 부모의 벤더에 종속됩니다. MCP는 한 에이전트가 도구 (tools)를 사용하는 방식입니다. 반면 agmsg는 다른 형태를 띱니다. 즉, 독립적인 에이전트들이 서로 다른 모델을 사용하면서 내구성이 있는 채널 (durable channel)을 통해 서로 대화하는 것입니다.

설치는 한 줄로 끝납니다:

bash <(curl -fsSL https://raw.githubusercontent.com/fujibee/agmsg/main/setup.sh)

재시작 후 에이전트들은 명령어를 받게 되며 (Claude Code와 Copilot CLI에서는 /agmsg, Codex와 Gemini CLI에서는 $agmsg), 팀과 이름을 선택한 뒤 대화를 시작합니다.

무엇인가에 연결하기 전에 한 가지 알아두어야 할 점은, agmsg는 의도적으로 멍청하게 설계되었다는 것입니다. 이 도구는 메시지를 이동시킬 뿐 그 이상의 기능은 수행하지 않습니다. 따라서 지나치게 예의 바른 두 에이전트가 서로를 확인하느라 즐겁게 대화를 이어가다 보면, 여러분의 토큰 비용이 전화번호처럼 길어질 수도 있습니다. 그 루프를 끝내는 것은 오직 여러분의 몫입니다.

내가 만든 것

나는 공유 인박스(shared inbox)를 감시하고 세 명의 에이전트 사이에서 메시지를 자동으로 전달하는 작은 브리지(bridge)에 agmsg를 연결했습니다. 에이전트들 사이에서 무언가를 전달하는 인간은 없습니다.

이 브리지는 단 한 가지 일만 수행합니다. 4초마다 SQLite 인박스를 폴링(polling)하여 읽지 않은 행을 SELECT 문으로 조회한 다음, 각 행을 대상 에이전트에게 전달합니다. 파일 와처(file watcher)나 다른 영리한 기능 없이, 오직 루프와 쿼리만 존재합니다.

세 명의 에이전트는 하나의 팀에 속해 있으며, 이들은 모두 서로 다른 방식으로 작동합니다. 하나는 로컬 설정 파일에 모델이 지정된 CLI를 통해 실행되고, 하나는 원샷(one-shot) 명령으로 실행되며, 나머지 하나는 HTTP API를 통해 응답합니다. 각 에이전트는 서로 다른 모델에 고정되어 있으며, 해당 모델은 브리지가 아닌 에이전트 자체의 설정에 저장됩니다. 브리지는 메시지 반대편에 어떤 모델이 있는지 알지 못하며 신경 쓰지도 않는데, 이것이 핵심입니다. 메시지를 이동시키는 장치를 건드리지 않고도 어떤 에이전트의 모델이든 교체할 수 있기 때문입니다.

세 가지 서로 다른 모델을 사용한 이유는 에이전트들이 서로 대화할 수 있기 때문이 아닙니다. 그중 하나가 무언가 잘못했을 때, 서로 다른 데이터로 학습된 모델이 이미 그 오류를 잡아낼 준비를 하고 있기 때문입니다.

이는 모델들이 실제로 독립적일 때만 유효합니다. 주로 동일한 텍스트로 학습된 두 모델은 동일한 사각지대를 공유하며, 이 경우 틀린 답에 대해서도 정답만큼이나 빠르게 동의해 버립니다. 그러면 내가 기대하는 불일치(disagreement)는 결코 나타나지 않습니다. 여러 벤더(gpt-4.1, Sonnet 4.6, 그리고 내가 만든 모델 중 하나)를 가로지르는 방식은 단일 모델의 세 가지 버전을 사용하는 것보다 더 높은 독립성을 확보해 주지만, 이는 헤지(hedge, 위험 분산)일 뿐 보장은 아닙니다.

브리지 자체는 폴링 루프와 아래에 설명할 일련의 가드(guards)로 이루어진 작은 규모입니다. 곧 오픈 소스로 공개하기 위해 코드를 정리하고 있습니다.

스스로를 잡아먹지 않게 만들기

agmsg는 두 에이전트가 서로에게 영원히 질문을 던지며 명확화(clarifying)하는 것을 막아주지는 못합니다. 여기서 발생하는 폭주 루프(runaway loop)는 실제 비용을 매우 빠르게 소모하므로, 모든 제어(containment)는 브리지(bridge)에서 이루어집니다. 각각 다른 오류 상황을 방지하기 위한 네 가지 가드(guards)가 존재합니다.

두 개의 슬라이딩 윈도우 카운터(sliding-window counters)가 있으며, 둘 다 300초 윈도우를 기준으로 작동합니다. 하나는 윈도우당 총 디스패치(dispatches) 횟수를 12회로 제한합니다. 다른 하나는 봇 간의 홉(bot-to-bot hops) 횟수를 윈도우당 6회로 제한하는데, 이는 사람이 개입하여 지루함을 느끼고 중단하기 전에 두 에이전트가 서로에게 답하며 통제 불능 상태로 이어지는 교환 방식이기 때문입니다. 두 제한 중 하나라도 걸리면 메시지는 드롭(dropped)되고 로그에 기록되며, 절대 재시도되지 않습니다. 드롭된 메시지는 루프를 돌리는 것보다 비용이 저렴합니다.

그다음은 에이전트별 인플라이트 락(per-agent in-flight lock)입니다. 이를 통해 각 에이전트는 한 번에 하나의 턴(turn)만 처리하며, 생각 중인 동안 새로운 작업이 쌓이지 않도록 합니다. 그리고 각 에이전트가 허용되는 속도에 따라 설정된 월드 클락 킬(wall-clock kills)이 있습니다: 280초, 150초, 그리고 120초입니다. 멈춰버린 턴은 락(lock)을 영원히 점유하는 대신 시계(clock)에 의해 종료됩니다.

토큰 예산(token budget) 방식은 아닙니다. 카운터와 클락은 비용을 간접적으로 제한하며, 이는 제가 계속해서 재조정해야 하는 달러 금액보다 추론하기가 더 쉽습니다.

/orchestrate: UI를 통한 동일한 개념

직접 배관(plumbing) 작업을 구축하고 싶지 않다면, GitHub Copilot app이 더 높은 수준에서 이와 유사한 버전을 제공합니다. /orchestrate는 메인 세션을 코디네이터(coordinator)로 전환합니다. 이는 자식 세션(child sessions)을 생성하고, 각 세션에 고유한 브랜치(branch)와 작업(task)을 부여하며, 메인 세션이 조종하고 요약하는 동안 세션들이 보고할 수 있게 합니다. 하나의 세션, 하나의 브랜치, 하나의 PR(Pull Request) 구조입니다. 각 세션은 자체적인 git 워크트리(worktree)에서 실행되므로 서로의 파일을 덮어쓰며 편집하지 않으며, 세션별로 모델을 선택할 수 있습니다.

브리지와 동일한 개념이지만, 대신 관리해 주는 방식입니다: 여러 에이전트와 다양한 모델을 사용하면서도 서로 충돌하지 않도록 유지합니다. 직접 구축할 때 얻을 수 있는 미세한 제어권(fine control)은 포기해야 하지만, 그 대가로 그 어떤 것도 직접 유지 관리할 필요가 없습니다.

이러한 도구들 중 그 어떤 것도 단일 모델이 항상 옳다고 가정하지 않습니다. 이들은 모델이 때때로 틀릴 수 있음을 전제로 하며, 워크플로 (workflow) 내에 검증 절차를 구축하고, 그 검증 비용을 저렴하게 유지합니다.

이것이 핵심적인 움직임입니다. "모델이 편향되었다"라거나 "실행 비용이 너무 비싸다"라는 말은 대기해야 할 이유로 취급되곤 합니다. 하지만 그렇지 않습니다. 이들은 하나의 설계 문제(design problem)의 양면일 뿐이며, 해결책은 어느 쪽에서 보든 동일합니다. 하나 이상의 모델을 실행하고, 어차피 의견이 갈렸을 지점에서 모델들이 서로 다르게 판단하도록 내버려 두며, 사용자가 직접 할 필요가 없도록 그 불일치를 읽어내는 무언가를 경로에 배치하는 것입니다. 상한선(cap)이 바로 정직함을 유지해 주는 요소입니다. 불일치를 읽어내는 비용은 그것이 잡아내는 버그(bug)의 비용보다 결코 커서는 안 됩니다.

이를 구축하기 전에 한 가지 유의할 점이 있습니다. 여기에 언급된 모든 것은 제가 직접 사용해 온 것들을 있는 그대로 공유한 것입니다. 여러분의 환경에 맞게 검증된 것이 아니며, 제가 작성하지 않은 도구들의 보안을 보장할 수도 없습니다. 코드를 직접 읽고, 안전한 곳에서 테스트한 뒤, 스스로 결정하십시오. 저에게 유용한 것이 여러분에게 안전하다는 뜻은 아닙니다. 그 부분은 여러분이 직접 확인해야 할 몫입니다.

원문은 X에 게시되었습니다.