에이전트 팀이 처음으로 제대로 작동할 때, 그것은 마치 치팅(cheating)을 하는 것처럼 느껴집니다.

당신은 한 에이전트에게 주요 작업을 부여합니다. 다른 에이전트를 실행하여 코드베이스를 검사하게 합니다. 또 다른 에이전트는 테스트를 확인합니다. 다른 에이전트는 엣지 케이스(edge cases)를 찾습니다. 한 명은 문서를 조사합니다. 한 명은 패치(patch)를 작성합니다.

갑자기 작업이 병렬적으로 느껴집니다.

그 느낌은 중독적입니다.

하지만 바로 그 지점에서 많은 문제들이 시작됩니다.

저는 이것을 고통스러운 과정을 통해 배웠습니다. 처음에는 Amari AI 시절의 초기 AI 제품 작업을 통해, 그다음에는 Torram을 통해, 그리고 결국 Claude, Codex, 브라우저 자동화(browser automation), 예약된 자동화(scheduled automations), 그리고 서브에이전트(subagent) 팀을 구축하는 훨씬 더 강도 높은 루프를 통해 배웠습니다. 우리는 Claude와 OpenAI 크레딧에 거의 1만 달러를 사용했으며, 그중 상당 부분은 에이전트 오케스트레이션(agent orchestration)이 실제로 어떻게 실패하는지를 배우기 위한 수업료였습니다.

요약하자면 다음과 같습니다:

서브에이전트(Subagents)는 유용합니다. 서브에이전트 팀은 강력합니다. 하지만 인수인계 영수증(handoff receipts)이 없다면, 이들은 더 나은 브랜딩을 입은 채 조용히 혼돈으로 변합니다.

문제는 위임(delegation)이 아니다

저는 위임(delegation)을 매우 찬성합니다.

Claude Code의 서브에이전트 모델은 방향성이 옳습니다: 분리된 컨텍스트 윈도우(context windows), 전문화된 역할, 집중된 도구, 그리고 메인 세션으로의 요약 전달. Codex의 멀티 에이전트/워크트리(multi-agent/worktree) 방향성 또한 방향성이 옳습니다: 병렬 작업, 격리된 작업, 리포지토리 기반 실행(repo-grounded execution), 그리고 백그라운드 진행.

그것이 바로 진지한 AI 코딩 작업이 진화해야 하는 방식입니다.

문제는 에이전트들 사이에서 일어나는 일입니다.

자식 에이전트(child agent)는 늦게 시작할 수 있습니다. 유용한 작업을 수행하기도 전에 실패할 수 있습니다. 작업의 잘못된 버전을 수행할 수 있습니다. 다른 에이전트가 이미 수행한 작업을 중복할 수 있습니다. 약한 근거를 숨기는 자신만만한 요약을 반환할 수 있습니다. 타임아웃(time out)이 발생할 수 있습니다. 부모 에이전트가 다음 단계로 넘어간 후에도 계속 실행될 수 있습니다. 올바르게 완료할 수는 있지만 유용한 인수인계(handoff)를 남기지 않을 수 있습니다.

외부에서 보기에는 이 모든 것들이 비슷해 보일 수 있습니다:

"에이전트가 작업 중입니다."

그 문장은 증거가 아닙니다.

그것은 느낌(vibe)일 뿐입니다.

그리고 그 느낌은 비용이 많이 듭니다.

생존성(Liveness)은 유용성이 아니다

우리가 계속해서 맞닥뜨렸던 한 가지 교훈은 이것입니다: 생존성(liveness)이 곧 유용성(usefulness)은 아니라는 점입니다.

에이전트가 살아있다고 해서 반드시 작업을 진전시키고 있는 것은 아닙니다.

파일을 영원히 읽고만 있을 수도 있습니다. 로컬 루프(local loop)에 빠져 있을 수도 있습니다. 동일한 가정을 계속해서 재확인하고 있을 수도 있습니다. 빠르게 실패(fail fast)했어야 할 명령을 기다리고 있을 수도 있습니다. 짧은 실수를 길게 요약하고 있을 수도 있습니다.

이는 서브에이전트(subagent)를 사용할 때 특히 고통스럽습니다. 왜냐하면 부모 에이전트(parent agent)는 종종 계속 진행하기를 원하기 때문입니다.

부모는 이렇게 말합니다. "작업자(worker)를 파견했다." 좋습니다. 그런데 그 작업자가 시작했나요? 올바른 파일을 읽었나요? 패치(patch)를 생성했나요? 검증기(verifier)를 통과했나요? 차단 요소(blocker)에 부딪혔나요? 다른 작업자와 작업이 겹쳤나요? 깔끔한 결과물을 남겼나요?

만약 이러한 질문들에 대한 답이 보이지 않는다면, 오케스트레이션 레이어(orchestration layer)는 기본적으로 당신에게 '블랙박스 안의 또 다른 블랙박스'를 믿으라고 요구하는 것과 같습니다.

그것은 워크플로우(workflow)가 아닙니다.

그것은 로그(logs)를 곁들인 기도일 뿐입니다.

인수인계 영수증(handoff receipt)에 포함되어야 할 내용

우리는 위임된 모든 작업이 작은 영수증을 필요로 한다는 생각을 하기 시작했습니다.

거대한 보고서나 소설이 아닙니다. 인간이나 부모 에이전트가 추측 없이 다음 결정을 내릴 수 있을 만큼의 충분한 상태(state) 정보면 충분합니다.

영수증은 다음 질문에 답해야 합니다:

• Task (작업): 작업자에게 실제로 요청된 작업은 무엇인가?
• Owner (소유자): 어떤 에이전트나 역할이 이를 담당했는가?
• Scope (범위): 어떤 파일, 인터페이스(surfaces), 또는 결정 영역을 다루었는가?
• Start proof (시작 증명): 실제로 시작되었는가, 그리고 어떤 컨텍스트(context)를 로드했는가?
• Result (결과): 무엇이 변경되었거나 무엇을 배웠는가?
• Verifier (검증기): 결과가 유효함을 증명하는 체크 항목은 무엇인가?
• Blocker (차단 요소): 무엇이 작업을 중단시켰는가? (있다면)
• Stop reason (중단 이유): 왜 작업이 지금 종료되는가?
• Next action (다음 조치): 다음에 무엇이 일어나야 하는가? (있다면)

그게 전부입니다.

마법은 형식이 아닙니다. 마법은 그렇지 않으면 서로 모호하게 뒤섞여 버릴 상태(states)들을 시스템이 명확히 구분하도록 강제하는 데 있습니다.

"여전히 작업 중"은 "인증 문제로 차단됨"과 다릅니다.

"완료됨"은 "패치는 작성되었으나 테스트되지 않음"과 다릅니다.

"발견 사항 없음"은 "관련 경로를 조사하지 않음"과 다릅니다.

"실패함"은 "검증기가 오래되어(stale) 실패함"과 다릅니다.

그러한 상태(states)가 명시되면, 부모 에이전트(parent agent)는 더 나은 결정을 내릴 수 있습니다. 사람 또한 마찬가지입니다.

팀 규모가 커질수록 이것이 더 중요한 이유

하나의 저장소(repo)에서 하나의 에이전트만 사용한다면, 주의력(attention)으로 이를 보완할 수 있습니다.

터미널을 지켜보고, 차이점(diff)을 읽고, 다시 유도(nudge)합니다. 이상한 점을 잡아냅니다.

하지만 여러 에이전트, 백그라운드 작업(background tasks), 브라우저 자동화(browser automations), 예약된 실행(scheduled runs), 또는 도구 간 워크플로(cross-tool workflows)를 갖게 되면, 주의력은 더 이상 확장(scaling)되지 않습니다.

이 문제는 우리의 MartinLoop 성장 작업에서도 뼈아프게 나타났습니다.

자동화는 아침, 점심, 저녁에 걸쳐 스윕(sweeps)을 수행하도록 되어 있었습니다. 서류상으로는 워크플로가 명확했습니다: GitHub, Reddit, Hacker News, Product Hunt, OpenAI 커뮤니티, 학생 포럼 및 기타 플랫폼을 검색합니다. 인증(auth)과 스레드 품질이 뒷받침되는 곳에 가치 중심적인 댓글을 게시합니다. 후보를 기록합니다. 관심 목록(watchlists)을 업데이트합니다. 실제 결과로부터 학습합니다.

하지만 현실 세계는 무질서합니다.

브라우저 인증(auth)이 시각적으로는 존재하지만 에이전트가 제어할 수는 없을 수도 있습니다. Reddit 작성창이 나타나지만 쓰기 가능한 에디터(editor)를 노출하지 않을 수도 있습니다. HN은 댓글 하나는 수락하지만 다음 댓글은 속도 제한(rate-limit)을 걸 수도 있습니다. OpenAI 커뮤니티는 너무 홍보성인 답글을 숨길 수도 있습니다. LinkedIn은 대기열 위생(queue hygiene)이 필요하지만, 신원 및 계정 안전이 확인될 때까지는 실시간 전송을 할 수 없을 수도 있습니다.

이 중 그 어떤 것도 "모델이 나쁘다"는 뜻이 아닙니다.

이것들은 워크플로 상태(workflow state)의 문제입니다.

그리고 자동화가 영수증(receipts)을 남기지 않는다면, 다음 실행은 민간 전승(folklore)에서부터 시작하게 됩니다.

무슨 일이 일어났나요? 채널이 차단되었나요? 인증이 누락되었나요? 브라우저 브릿지(browser bridge)가 깨졌나요? 스레드가 닫혔나요? 게시를 했나요? 초안만 작성했나요? 무언가를 배웠나요?

영수증이 없다면, 매 실행은 작은 고고학적 발굴 작업이 됩니다.

그 지점에서 드리프트(drift)가 가중됩니다.

부모 에이전트는 지루해야 한다

훌륭한 멀티 에이전트(multi-agent) 워크플로에서 부모 에이전트는 영웅이 되어서는 안 됩니다.

부모는 지루해야 합니다.

어떤 작업이 존재하는지, 각 작업자(worker)가 어떤 상태에 있는지, 어떤 증거(evidence)가 돌아왔는지, 그리고 다른 시도가 정당한지를 알고 있어야 합니다.

그것은 화려하지 않지만, 오케스트레이션(orchestration)과 소음(noise)을 가르는 차이입니다.

서브에이전트 (subagent) 팀의 경우, 이제 저는 개별 작업자가 얼마나 인상적으로 들리는지보다 부모 에이전트가 다음 질문에 답할 수 있는지에 더 집중합니다:

• 어떤 하위 작업 (child tasks)이 활성화되어 있는가?
• 어떤 작업이 차단 (blocked)되었는가?
• 어떤 작업이 검증된 결과물 (verified work)을 생성했는가?
• 어떤 작업이 검토 (review)를 필요로 하는가?
• 어떤 작업을 종료 (killed)해야 하는가?
• 어떤 작업을 재시도 (retried)해서는 안 되는가?

마지막 질문이 중요합니다.

사람들은 에이전트를 재시도하는 것을 좋아합니다. 때로는 그것이 옳을 수도 있습니다. 하지만 때로는 그것은 그저 영리한 모자를 쓰고 있는 예산 낭비 (budget burn)일 뿐입니다.

재시도하기 전에, 저는 실패 유형 (failure class)이 변했는지, 검증기 (verifier)가 개선되었는지, 남은 예산이 추가 시도를 정당화하는지, 그리고 다음 작업자가 이전 작업자와 다른 계획을 가지고 있는지 알고 싶습니다.

그렇지 않다면, 당신은 오케스트레이션 (orchestration)을 하고 있는 것이 아닙니다.

그저 다시 굴리고 (rerolling) 있는 것입니다.

우리가 결국 도달한 규칙

제가 지금 선호하는 규칙은 다음과 같습니다:

영수증 (receipt)이 없으면, 신뢰도 없다.

가혹하게 들릴 수 있지만, 사실 이는 자유를 줍니다.

이는 에이전트가 완벽할 필요가 없음을 의미합니다. 그저 다음 결정이 합리적일 수 있도록 충분한 증거를 남기기만 하면 됩니다.

서브에이전트가 자신이 무엇을 시도했는지, 무엇이 자신을 차단했는지, 그리고 다음에 무엇이 일어나야 하는지를 정확히 알려준다면, 유용하게 실패할 수 있습니다.

반면 서브에이전트가 증거 없이 자신감 넘치는 요약만을 반환한다면, 위험하게 성공할 수 있습니다.

이것이 바로 사고방식의 전환 (mindset shift)입니다.

목표는 에이전트를 더 숙련된 것처럼 보이게 만드는 것이 아닙니다. 목표는 그들의 작업이 검사 가능 (inspectable)하게 만드는 것입니다.

그것이 바로 우리가 MartinLoop를 통해 포착하려는 것입니다. Claude, Codex 또는 다른 코딩 에이전트를 대체하는 것이 아니라, 예산 (budgets), 검증 게이트 (verifier gates), 중단 사유 (stop reasons), 그리고 실행 기록 (run records)으로 루프를 감싸서 인간이 사후에 추측만 하며 남겨지지 않도록 하는 것입니다.

왜냐하면 미래는 하나의 완벽한 에이전트가 모든 것을 수행하는 모습이 아니기 때문입니다.

미래는 아마도 수많은 불완전한 에이전트들이 유용한 작업 조각들을 수행하고, 인간과 런타임 시스템 (runtime systems)이 무엇을 실제로 계속 진행할지 결정하는 모습일 것입니다.

그 미래에는 영수증 (receipts)이 필요합니다.

지금 바로 MartinLoop를 다운로드하여 당신의 에이전트 루프가 책임감을 가질 수 있도록 관리하세요.

Open Source Repo: https://github.com/Keesan12/Martin-Loop

2분 다운로드:
npm install -g martin-loop
npx -y martin-loop@latest doctor

npx -y martin-loop@latest start
npx -y martin-loop@latest demo