오늘 저는 Halo를 단일 자율 루프(single autonomous loop)에서 Planner, Orchestrator, Vulnerability Discovery, Attacker, Debugger라는 제대로 된 5개 에이전트 아키텍처로 전환했습니다. 실제 타겟을 대상으로 이를 연결하며 어떻게 구현되었는지, 그리고 무엇을 배웠는지 소개합니다.

핵심 설계 원칙

코드를 작성하기 전, 아키텍처는 단 하나의 규칙으로 요약되었습니다: 오직 두 명의 에이전트만이 도구(tools)를 사용할 수 있다는 것입니다. Vulnerability Discovery는 정찰(recon)을 담당합니다 (nmap, httpx, gobuster, nikto). Attacker는 침투(exploitation)를 담당합니다 (sqlmap, hydra, searchsploit). Planner와 Orchestrator는 순수 로직(pure logic)입니다. 예외 없이 도구 접근 권한이 없습니다. Debugger는 실패를 진단하고 Orchestrator에게 순위가 매겨진 수정 목록을 전달하지만, 이 역시 도구를 절대 건드리지 않습니다.

이러한 분리는 생각보다 훨씬 중요합니다. 이는 Orchestrator가 무언가가 왜 실패했는지 이해할 필요가 없음을 의미합니다. 그저 Debugger의 최상위 권장 사항을 실행하기만 하면 됩니다. 또한, 나중에 새로운 도구를 추가할 때 시스템 전체가 아닌 단 한 명의 전문가 코드만 수정하면 된다는 것을 의미합니다.

공유 메시지 엔벨로프 (Shared Message Envelope)

모든 에이전트는 동일한 형식, 즉 agent, engagement_id, task_id, status, result를 포함하는 엄격하게 제한된 AgentMessage 형식을 사용하여 통신합니다. 마치 병원에서 외과의의 기록과 방사선 전문의의 기록에 담긴 구체적인 내용은 완전히 다르더라도, 모든 부서가 동일한 형태의 차트를 작성하는 것과 같다고 생각하면 됩니다.

Debugger의 결과에는 SuggestedFix 객체의 순위 목록(action, params, confidence level 포함)이 포함됩니다. 덕분에 Orchestrator는 실패 원인 자체를 추론할 필요 없이 최상위 순위의 제안을 그대로 받아들일 수 있습니다.

스텁(Stubs)을 이용한 우선 구축

Orchestrator는 실제 전문가 에이전트들이 존재하기 전에 가짜 대역(fake stand-in) 에이전트들을 대상으로 구축 및 테스트되었습니다. 이를 통해 네트워크에 실제로 접속하는 요소를 연결하기 전에, assigned_to 필드에 따라 작업을 올바르게 배정하는 라우팅 로직(routing logic)이 작동함을 증명할 수 있었습니다. 실제 Vulnerability Discovery 에이전트가 준비되었을 때, 이를 교체하는 것은 라우팅 딕셔너리(routing dictionary)의 한 줄만 수정하면 되는 작업이었습니다. Orchestrator의 다른 부분은 변경할 필요가 없었습니다.

실제 버그, 실제 수정

실제 Metasploitable 타겟을 대상으로 테스트한 결과, 실제 파라미터 불일치(parameter mismatch) 문제가 드러났습니다. 저의 Attacker 에이전트가 타겟 IP를 searchsploit의 검색 키워드로 전달하고 있었는데, searchsploit은 IP가 아닌 서비스 이름과 버전을 기대합니다. Searchsploit은 충돌(crash)이 아닌 잘못된 입력값으로 인해 정확하게 “No Results”를 반환했습니다.

이 실패는 Debugger를 위한 첫 번째 실제 테스트 케이스가 되었습니다. 정확한 실패 메시지를 입력하자, Debugger는 “키워드가 실제 익스플로잇(exploit) 항목과 일치하지 않을 가능성이 높음”이라고 정확히 진단했으며, 높은 신뢰도로 도구를 전환할 것을 권장했습니다. 이는 제가 불과 한 시간 전에 수동으로 수정했던 버그에 대해 추론한 결과였습니다.

다음 단계

다섯 개의 에이전트는 존재하며 각각 독립적으로 작동합니다. 다음 단계는 이들을 하나의 연속적인 인게이지먼트 루프(engagement loop)로 연결하는 것입니다. 즉, Planner의 출력이 Orchestrator로 전달되고, Orchestrator가 실제 전문가들에게 작업을 배정하며, Vuln Discovery의 발견 사항이 Attacker의 입력으로 흐르고, Debugger가 그 과정에서 발생하는 실패를 포착하도록 만드는 것입니다. 그것이 앞으로 진행할 통합 작업입니다.

Repo: github.com/XenoCoreGiger31/GEMMA-by-GOOGLE