Halo의 대부분의 기간 동안, 그것은 모든 것을 수행하는 단일 에이전트(single agent)였습니다. 하나의 루프(loop), 하나의 모델(model), 하나의 컨텍스트 윈도우(context window)가 정찰(reconnaissance), 착취(exploitation), 그리고 자기 수정(self-correction)을 한꺼번에 처리해 왔습니다. 이는 24개의 도구(tools)를 통합하고 각 인게이지먼트(engagement)별로 작동하는 실패 캐시(failure cache) 범위를 지정하는 데 충분히 잘 작동해 왔지만, 너무 많은 일을 한꺼번에 수행하도록 요청받은 단일 에이전트 시스템에서 예상할 수 있는 한계점들이 나타나기 시작했습니다. 즉, 컨텍스트(context)가 혼잡해지고, 인게이지먼트가 길어질수록 추론(reasoning)이 흐릿해지며, 한 단계에서의 실수(예: 잘못된 정찰 가정)가 이후의 모든 단계에 조용히 독을 퍼뜨리는 현상입니다.

Halo의 다음 주요 마일스톤(milestone)은 멀티 에이전트 오케스트레이션(multi-agent orchestration)이며, 이를 설계 문서(design doc)로 만들지 않고 그 형태에 대해 이야기해보고자 합니다.

왜 굳이 나누는가

침투 테스트(pentest)는 실제로 하나의 작업이 아닙니다. 그것은 무엇을 할지 파악하고, 누가 어떤 순서로 할지 결정하며, 실제로 실행하고, 추적할 가치가 있는 약점을 찾아내며, 그리고 결정적으로 — 무언가가 제대로 작동하지 않았을 때를 인식하고 경로를 수정하는 것 — 이 다섯 가지 또는 여섯 가지의 뚜렷한 사고 방식이 결합된 것입니다. 현재 Halo는 이 모든 것을 하나의 공유된 컨텍스트를 가진 단일 루프 내에서 수행합니다. 작동은 하지만, 이는 "공격" 마인드셋(mindset)과 "계획" 마인드셋(mindset)이 동일한 정신적 영역을 차지하기 위해 싸우고 있음을 의미합니다. 작업을 실행하는 동시에 자신의 실행을 감사(audit)하려고 시도해 본 사람이라면 누구나 그것이 어떻게 진행되는지 알고 있습니다.

이러한 책임들을 별도의 에이전트(agents)로 분리한다는 것은 각 에이전트가 더 작고 집중된 업무를 맡게 되며, 다른 곳에 속해야 할 관심사들에 의해 오염되지 않는 컨텍스트 윈도우(context window)를 갖게 된다는 것을 의미합니다. 또한 실패를 격리하기가 더 쉬워짐을 의미합니다. 만약 공격이 실패한다면, 그것은 디버깅 에이전트(debugging agent)에게 보내는 신호이지, 플래너(planner)가 도구 출력(tool output)의 벽 속에서 풀어내야 할 문제가 아닙니다.

다섯 명의 에이전트, 다섯 가지 작업

처음에 언급했던 "네 명의 에이전트"라는 프레임워크에도 불구하고, 실제로는 다섯 가지의 뚜렷한 역할로 정착하고 있습니다:

플래너 (The Planner). 상위 수준의 참여 목표 (high-level engagement goal)를 받아 이를 일련의 목표들로 분해합니다. 이 에이전트는 명령 (commands)보다는 전략 (strategy)의 관점에서 사고합니다. 즉, 다른 일이 일어나기 전에 무엇이 충족되어야 하는지, 그리고 전체적인 참여의 형태가 어떠해야 하는지를 고민합니다.

오케스트레이터 (The Orchestrator). 플래너와 다른 모든 에이전트 사이에 위치하며, 어떤 에이전트가 다음에 행동할지 결정하고 에이전트 간에 컨텍스트 (context)를 라우팅 (routing) 합니다. 이를 디스패처 (dispatcher)라고 생각하면 됩니다. 직접 기술적인 작업을 수행하는 것이 아니라, 적절한 전문가가 적절한 시점에 적절한 정보 조각을 전달받을 수 있도록 보장합니다.

취약점 발견 에이전트 (The Vulnerability Discovery agent). 공격할 가치가 있는 것들을 찾는 데 전적으로 집중합니다. 스캔 출력 (scan output), 열거 (enumeration) 결과, 정찰 (recon) 데이터가 해석되어 우선순위가 지정된 약점 목록으로 변환되는 곳입니다. 이는 공격 에이전트가 당시 수행 중인 작업의 부수 효과로 해석이 일어나는 것이 아니라, 독립적으로 수행됩니다.

공격자 (The Attacker). 구체적이고 명확하게 정의된 타겟을 받아 이를 대상으로 실행합니다. 이 에이전트는 전체 참여 계획을 알 필요가 없습니다. 타겟, 방법, 그리고 이를 수행할 도구만 있으면 됩니다.

디버거 (The Debugger). 실패를 감시합니다. 공격이 성공하지 않거나, 도구 호출 (tool call)에서 오류가 발생하거나, 무언가 잘못되어 보일 때, 이 에이전트의 역할은 그 이유를 파악하여 해당 이해를 시스템에 다시 전달하는 것입니다. 이상적으로는 이미 존재하는 실패 캐시 (failure cache)에 전달하여, 세 번의 참여가 지난 후에도 동일한 실수가 반복되지 않도록 합니다.

이것이 (아직) 아닌 것

여기서 메시지 전달 형식 (message-passing formats), 공유 상태 (shared state), 또는 이 에이전트들이 실제로 서로 어떻게 대화할지에 대해서는 의도적으로 다루지 않겠습니다. 그것은 아키텍처 스케치 (architecture-sketch)의 영역이며, 여전히 스케치 단계에 있기 때문입니다. 제가 말씀드릴 수 있는 것은 이것이 '스케치 우선 (sketch-first)' 접근 방식이라는 점입니다. 즉, 오케스트레이션 (orchestration) 코드를 한 줄도 쓰기 전에 종이 위에서 역할과 경계를 정확히 설정하는 것입니다. 설계에 흥분하면 바로 구축 단계로 뛰어들고 싶은 유혹을 느끼기 쉽지만, 멀티 에이전트 시스템 (multi-agent systems)은 초기에 잘못 설정된 경계를 나중에 되돌리는 데 큰 비용이 드는 바로 그런 종류의 시스템입니다.

이것이 Halo가 나아갈 방향에 중요한 이유

이러한 분할이 중요한 솔직한 이유는 단일 에이전트 (single-agent) 펜테스터 (pentester)는 한계에 부딪히기 때문입니다. 단일 에이전트는 전체 루프를 리셋해야 하기 전까지 보유할 수 있는 컨텍스트 (context)의 양, 동시에 추론할 수 있는 문제의 수, 그리고 스스로의 실수로부터 회복할 수 있는 횟수에 한계가 있습니다. 명확한 책임을 가진 전문화된 에이전트들과 인수인계 (handoffs)를 관리하는 코디네이터 (coordinator)가 결합될 때, 비로소 더 오래 실행되고, 더 우아하게 실패하며, 단순히 도구 목록만 조금 더 늘린 채 동일한 루프를 반복하는 대신 실제로 시간이 지남에 따라 개선되는 자율 시스템 (autonomous system)을 얻을 수 있습니다.

이 글은 '무엇이 출시되었다'는 게시물이라기보다는 '다음 장(next chapter)'에 관한 게시물에 가깝습니다. 하지만 한 명의 에이전트가 다섯 가지 일을 하는 것에서 다섯 명의 에이전트가 각각 한 가지 일을 하는 것으로의 전환은, 최초의 MCP 서버 이후 Halo가 겪은 가장 큰 아키텍처적 변화입니다. 저희는 대중이 저희의 여정을 함께 따라올 수 있도록 가능한 한 많은 투명성을 제공하기를 희망합니다.