Agent Harness: 심층 탐색을 위한 다중 병렬 Agent 실행

Meta Description: Agent harness가 심층 탐색(deep exploration) 작업을 위해 어떻게 여러 개의 병렬 AI agent를 오케스트레이션(orchestrate)하는지 배워보세요 — fan-out/fan-in 아키텍처, 집계(aggregation) 전략, 코드베이스 분석 및 보안 감사와 같은 실제 사용 사례, 엔지니어링 과제, 그리고 진화하는 프레임워크 환경을 다룹니다. Agent Harness: 심층 탐색을 위한 다중 병렬 Agent 실행 목차 단일 Agent의 병목 현상 Agent Harness란 무엇인가? 왜 병렬성(Parallelism)인가? 다중 Agent 탐색의 필요성 핵심 아키텍처: Fan-Out / Fan-In 더 깊은 패턴: 기본 Fan-Out을 넘어서 결과 집계 전략 실제 사용 사례 엔지니어링 과제 프레임워크 환경 향후 방향 결론 단일 Agent의 병목 현상 단 한 명의 개발자에게 500,000줄에 달하는 코드베이스의 보안 취약점을 감사하라고 요청한다고 상상해 보세요 — 혼자서, 한 번의 앉은 자리에서, 모든 파일을 위에서 아래로 순차적으로 읽으면서 말입니다. 아무리 숙련된 엔지니어라도 무언가를 놓치게 될 것입니다. 주의력은 저하되고, 작업 기억(working memory)은 가득 차며, 12번째 서비스에 도달할 때쯤이면 1번째 서비스의 문맥(context)은 이미 오래전에 희미해졌을 것입니다. 단일 AI agent도 동일한 근본적인 제약 사항을 가집니다: 유한한 문맥 창(context window). 이를 128K 토큰, 200K 토큰, 심지어 100만 토큰까지 확장할 수는 있지만, 거대한 문제 공간을 탐색하는 단일 추론 스레드(reasoning thread)는 항상 직렬 처리량(serial throughput)에 의해 제한될 수밖에 없다는 사실에서 벗어날 수 없습니다. 더 결정적으로, 단일 agent는 단일한 관점을 가져옵니다. 하나의 추론 체인(reasoning chain). 하나의 활성화된 연상 집합. 탐색 그래프(exploration graph)를 통과하는 하나의 경로. 이것이 바로 병렬 탐색을 갖춘 agent harness가 해결하도록 설계된 문제입니다. 개별 agent를 더 똑똑하게 만드는 것이 아니라, 문제 공간의 서로 다른 조각을 각각 다루는 많은 agent를 동시에 실행한 다음, 그들이 찾아낸 것을 지능적으로 합성(synthesizing)함으로써 해결합니다. 이 포스트는 agent harness가 어떻게 작동하는지, 왜 중요한지, 그리고 어떻게 잘 설계할 수 있는지에 대한 심층적인 기술적 탐구입니다.

에이전트 하네스(agent harness): 하나의 오케스트레이터, 다수의 병렬 탐색기, 그리고 하나의 합성된 결과물. 에이전트 하네스가 무엇인가요? 본질적으로 에이전트 하네스는 여러 AI 에이전트의 라이프사이클을 관리하는 오케스트레이션 레이어입니다. 즉, 에이전트를 생성하고(spawning), 작업을 할당하며, 실행을 모니터링하고, 실패를 처리하며, 결과를 수집합니다. 이 하네스 자체가 지적인 작업을 수행하지는 않습니다. 대신, 실제로 작업하는 에이전트들을 담고 방향을 제시합니다. 하네스는 세 가지 개념적 계층(conceptual tiers)에 걸쳐 작동합니다.

1. 오케스트레이터 (The Orchestrator) — 작업 분해 및 에이전트 디스패치(agent dispatch)를 담당하는 최상위 컨트롤러입니다. 높은 수준의 목표(high-level goal)를 받고, 이를 하위 작업으로 어떻게 나눌지 결정하며, 각 하위 작업을 워커 에이전트(worker agent)에게 할당합니다. 오케스트레이터 자체도 LLM일 수 있습니다(

다중 에이전트 탐색의 필요성

에이전트를 병렬로 실행해야 하는 동기는 시간(time), 커버리지(coverage), 그리고 인지적 다양성(cognitive diversity)이라는 세 가지 독립적인 논거에 기반합니다.

시간: O(N)에서 O(1)로
단일 에이전트가 하나의 하위 작업(sub-task)을 처리하는 데 T초가 걸리고, N개의 하위 작업이 있다면 순차적 처리에는 O(N*T)의 시간이 소요됩니다. N개의 워커(worker)를 가진 병렬 하네스(parallel harness)는 이를 O(T) — 즉, 단일 하위 작업의 시간과 조정 오버헤드(coordination overhead)의 합 — 로 단축합니다. 수십 또는 수백 개의 하위 작업이 있는 탐색 작업의 경우, 이는 몇 분과 몇 시간의 차이를 만듭니다.

커버리지: 어떤 하위 공간도 남겨두지 않음
순차적 에이전트는 우선순위를 정해야만 합니다. 에이전트는 자연스럽게 가장 두드러진 스레드(thread)를 먼저 탐색하게 되며, 컨텍스트(context)가 소진되거나 턴 제한(turn limit)에 도달하면 다른 부분에 도달하지 못할 수도 있습니다. 병렬 하네스는 모든 하위 공간(sub-space)을 전담 에이전트에게 할당하여 커버리지를 보장합니다. 잊혀진 모듈도, 건너뛴 문서도, 우선순위에서 밀려난 공격 표면(attack surface)도 없습니다.

인지적 다양성: 다각적 관점
서로 다른 시스템 프롬프트(system prompt), 도구 세트(tool set), 또는 컨텍스트 프레이밍(contextual framing)을 가진 여러 에이전트에게 동일한 상위 목표를 부여하면, 그들은 서로 다른 것들을 찾아냅니다. 코드베이스를

효과적인 분해 (decomposition) 전략에는 도메인 분해 (domain decomposition, 모듈/서비스/파일별 분할), 관점 분해 (perspective decomposition, 동일한 입력에 대해 서로 다른 분석적 렌즈 적용), 샘플링 분해 (sampling decomposition, 대규모 코퍼스에서 무작위 서브셋 추출), 그리고 계층적 분해 (hierarchical decomposition, 테마별로 분할한 후 각 테마를 다시 하위 분할)가 포함됩니다.

2단계: 팬아웃 (Fan-Out, 분산)
오케스트레이터 (orchestrator)는 N개의 워커 에이전트 (worker agents)를 동시에 생성하며, 각 에이전트는 특정 하위 작업 프롬프트 (sub-task prompt), 관련 도구 (tools)에 대한 접근 권한, 그리고 전역적으로 적용 가능한 공유 컨텍스트 (shared context)를 부여받아 초기화됩니다. 워커들은 에이전트 간의 통신 없이 완전히 병렬로 실행됩니다.

3단계: 병렬 실행 (Parallel Execution)
각 워커 에이전트는 도구를 호출하고, 하위 작업을 통해 추론하며, 오류를 처리하는 등 결과를 생성할 때까지 자율적으로 작동합니다. 하네스 (harness)는 모든 워커를 동시에 모니터링하며, 타임아웃 (timeout), 일시적인 실패에 대한 재시도 (retries), 그리고 복구 불가능한 오류 발생 시 조기 종료 (early termination)를 처리합니다.

4단계: 팬인 (Fan-In, 집계)
워커들이 완료됨에 따라 결과가 수집됩니다. 모든 워커(또는 충분한 정족수)가 완료되면 집계 (aggregation) 단계가 실행됩니다. 이는 결정론적 병합 (deterministic merge), 발견 사항을 합성하기 위한 2차 LLM 호출, 또는 서로 다른 결과 유형을 서로 다른 핸들러 (handlers)로 라우팅하는 구조화된 파이프라인 (structured pipeline) 형태가 될 수 있습니다.

이 아키텍처의 우아함은 자연스러운 구성 (composes naturally)에 있습니다. 오케스트레이터 자체가 더 높은 수준의 하네스 내에서 하나의 워커가 될 수 있으므로, 전체 패턴을 재귀적으로 중첩 (recursively nestable)할 수 있습니다.

더 깊은 패턴: 기본 팬아웃을 넘어
계층적 / 트리 구조 하네스 (Hierarchical / Tree-Structured Harnesses)
깊게 중첩된 문제 공간의 경우, 단일 계층의 병렬 에이전트만으로는 불충분할 수 있습니다. 계층적 하네스는 여러 수준을 도입합니다. 최상위 오케스트레이터가 중간 수준의 코디네이터 (coordinators)들에게 팬아웃하고, 각 코디네이터는 다시 자신만의 리프 워커 (leaf workers) 풀로 팬아웃합니다. 결과는 연속적인 집계 단계를 거쳐 위로 전달됩니다 (bubble up). 이 패턴은 대규모 코드베이스의 자연스러운 계층 구조를 반영합니다. 즉, 최상위 계층은 저장소(repository)당 하나의 코디네이터를 할당하고, 각 코디네이터는 서비스(service)당 하나의 워커를 할당하며, 각 워커는 개별 파일(files)을 심층 조사합니다.

재귀적 Agent 생성 (Recursive Agent Spawning): 일부 하네스(harness)는 할당된 작업이 단일 컨텍스트 윈도우 (context window)를 초과할 때 워커 에이전트 (worker agent)가 하위 에이전트 (sub-agent)를 생성할 수 있도록 허용합니다. 에이전트는 하네스 런타임 (harness runtime)에 명시적인 도구 호출 (tool call)을 수행하며, 런타임은 새로운 워커를 생성하고 그 결과를 비동기적으로 반환합니다. 이는 동적으로 성장하는 에이전트 트리 (trees of agents)를 생성하며, 하위 작업의 복잡성을 사전에 알 수 없는 개방형 탐색 (open-ended exploration)에 자연스럽게 부합합니다. 위험 요소: 깊이 제한 (depth limits)과 비용 예산 (cost budgets)이 없다면, 재귀적 생성은 에이전트의 기하급수적인 증식을 초래합니다. 이 패턴을 지원하는 모든 프로덕션 하네스는 최대 트리 깊이와 하위 작업당 토큰 예산을 반드시 강제해야 합니다.

경쟁적 / 앙상블 하네스 (Competitive / Ensemble Harnesses): 작업을 분해하는 대신, 일부 하네스는 동일한 작업에 대해 서로 다른 전략, 시스템 프롬프트 (system prompts), 또는 모델 선택을 사용하여 여러 에이전트를 실행합니다. 결과들은 비교되며, 투표 (voting), 신뢰도 점수 산정 (confidence scoring), 또는 심판 에이전트 (judge agent)를 통해 최적의 답변이 선택됩니다. 이러한 앙상블 (ensemble) 접근 방식은 정확도를 위해 연산 자원 (compute)을 희생하며, 정확성이 비용보다 중요한 고위험 시나리오에서 흔히 사용됩니다.

군집 토폴로지 (Swarm Topologies): 군집 지능 (swarm intelligence)에서 영감을 얻은 실험적인 하네스들은 에이전트가 정의된 인접 그래프 (adjacency graph)를 통해 이웃과 통신할 수 있도록 합니다. 유망한 발견을 한 에이전트는 인접한 에이전트들의 탐색 방향에 편향을 주는 신호를 방송할 수 있으며, 이는 중앙 집중식 제어 없는 창발적 협력 (emergent coordination)을 가능하게 합니다. 이론적으로는 강력하지만, 프로덕션 환경에서 디버깅하고 예측하기는 어렵습니다.

결과 집계 전략 (Result Aggregation Strategies): 병렬 결과를 어떻게 집계하느냐는 에이전트를 어떻게 실행하느냐만큼 중요합니다. 이 전략은 최종 출력의 품질, 상세함 (verbosity), 그리고 신뢰성을 결정합니다.

전략 설명	최적의 용도	트레이드오프
Union Merge	모든 결과 결합	높은 상세함 (verbosity), 중복 발생
Voting / Quorum	N/M개의 에이전트가 동의한 결과만 유지	높은 신뢰도의 추출
Hierarchical Synthesis	메타 에이전트가 모든 출력을 읽고 통합 요약 작성	서사적 보고서 (Narrative reports)
Confidence-Weighted	모델의 신뢰도에 따라 순위를 매기고 상위 K개 유지	순위가 매겨진 권장 사항
Semantic Deduplication	발견 사항을 임베딩 (embed)하고 유사도에 따라 클러스터링하여 클러스터당 하나씩 유지	중복된 발견 제거
Critic-Review	전담 비판 (critic) 에이전트가 각 발견 사항에 이의를 제기	고위험 검증 (High-stakes validation)

Aggregation (집계): 병렬 탐색이 통합된 지능으로 변모하는 순간입니다. 실제로 대부분의 프로덕션 하네스 (production harnesses)는 여러 전략을 체인 형태로 연결합니다: 먼저 의미론적 중복 제거 (semantic deduplication)를 수행한 다음, 계층적 합성 (hierarchical synthesis)을 거쳐, 우선순위가 높은 발견 사항에 대해 비판 (critic) 단계를 적용합니다.

실제 사용 사례 (Real-World Use Cases)

대규모 코드베이스 탐색 (Large Codebase Exploration)
대규모 마이크로서비스 아키텍처 (microservices architecture)에서 서비스나 모듈당 하나의 에이전트를 할당합니다. 서로 다른 모듈에 할당된 병렬 에이전트들이 전체 코드베이스를 동시에 탐색합니다. 각 에이전트는 할당된 코드를 읽고, 패턴을 식별하며, 문제를 표시하고, 동작을 문서화합니다. 하네스는 단일 에이전트가 합리적인 시간 내에 생성할 수 없는 횡단적 아키텍처 요약 (cross-cutting architectural summary)으로 이를 집계합니다. 코드 모듈은 자연스럽게 독립적이므로, 팬아웃 (fan-out) 경계가 모듈 경계와 직접적으로 매핑됩니다.

보안 취약점 스캐닝 (Security Vulnerability Scanning)
인증 흐름 (authentication flows), SQL 쿼리 생성, 종속성 CVE, API 엔드포인트 입력 검증 등 서로 다른 공격 표면 (attack surfaces)을 동시에 탐색하도록 에이전트를 할당합니다. 각 에이전트에는 특정 위협 모델 (threat model)이 주입됩니다. 동일한 엔드포인트에서 서로 다른 공격 페르소나 (attack personas)를 가진 여러 에이전트를 실행하는 것은, 모드를 전환하는 단일 에이전트보다 더 포괄적인 커버리지를 생성합니다.

연구 합성 (Research Synthesis)
50편의 논문 코퍼스 (corpus)가 주어지면, 논문 한 편당 하나의 에이전트를 할당합니다.

각 에이전트는 핵심 주장 (claims), 방법론 (methodologies), 결과 (results), 그리고 한계점 (limitations)을 추출합니다. 어그리게이터 (aggregator)는 코퍼스 (corpus) 전반에 걸친 합의 사항, 모순점, 그리고 미해결 질문들을 식별하며, 이를 통해 몇 주가 아닌 몇 분 만에 체계적인 검토 (systematic review)를 생성합니다.

다중 관점 분석 (Multi-Perspective Analysis)
복잡한 결정 (아키텍처 검토, 장애 사후 분석 (incident post-mortems))을 위해, 동일한 문서를 서로 다른 분석적 페르소나 (persona)를 가진 여러 에이전트에게 동시에 실행할 수 있습니다: 보안 엔지니어 (security engineer), 성능 엔지니어 (performance engineer), 제품 관리자 (product manager), 신뢰성 엔지니어 (reliability engineer).
집계된 출력물은 단일 관점에서는 놓칠 수 있는 우려 사항들을 포착합니다.

엔지니어링 과제 (Engineering Challenges)
API 속도 제한 (Rate Limits) 및 처리량 예산 (Throughput Budgets)
50개의 에이전트를 동시에 생성하면 대부분의 Tier-1 API 할당량 (RPM/TPM)을 즉시 포화시킵니다. 완화 방법: 지터 (jitter)를 포함한 지수 백오프 (exponential backoff), 구성 가능한 동시성 제한 (concurrency limits)을 가진 에이전트 큐잉 (queuing), OpenAI/Anthropic/Azure OpenAI를 가로지르는 멀티 프로바이더 라우팅 (multi-provider routing), 그리고 트래픽이 적은 시간대에 에이전트 풀 (agent pools)을 사전 예열 (pre-warming)하는 방식이 있습니다.

토큰 예산 관리 (Token Budget Management)
각 병렬 에이전트는 독립적으로 토큰을 소비합니다. 4K 토큰의 컨텍스트 (context)를 가지고 2K 토큰의 출력을 생성하는 20개의 에이전트를 실행하는 하네스 (harness)는 사이클당 120K 토큰을 소모합니다. 권장 사항: 에이전트당 출력 토큰 한도를 엄격하게 설정하고, 리프 워커 (leaf workers)에는 더 작은 모델을, 오케스트레이터 (orchestrators)에는 더 큰 모델을 사용하며, p