[LLM] 취약점 진단 에이전트 팀 구성하기

주의: 이 글에서 다루는 모의해킹 자동화 사례는 합법적·허가된 환경의 연구/교육 목적에만 해당합니다.
권한 없는 시스템에 대한 공격 행위는 정통망법에 저촉될 수 있습니다.

이번 연구를 위해 LLM 구독 및 API 요금을 지원해준 분께 감사의 인사를 드립니다.

멀티 에이전트 시스템의 3가지 아키텍처 패턴: 실전 모의해킹 파이프라인으로 살펴보기

들어가며

LLM 기반 멀티 에이전트 시스템(Multi-Agent System)이 빠르게 확산되고 있습니다. OpenAI Swarm, Google ADK, LangGraph, CrewAI 등 주요 프레임워크들이 잇달아 등장하면서 "에이전트 여럿이 협업하는" 구조는 이제 실험 단계를 넘어 실무에 적용되기 시작했습니다.

그런데 막상 멀티 에이전트를 실전에 적용해 보면 도구 자체의 문제보다 에이전트 간 업무 이양(Handoff)이 무너지는 문제가 훨씬 치명적입니다. 에이전트 A가 산출물을 만들었는데 에이전트 B가 그 형식을 이해하지 못하거나, 이전 라운드의 피드백이 다음 라운드에 전달되지 않거나, 최종 합의 조건이 모호해서 파이프라인이 무한 루프에 빠지는 식입니다.

이 글에서는 멀티 에이전트 오케스트레이션(Orchestration)의 핵심 아키텍처를 3가지 패턴으로 분류하고, 필자가 직접 구축·운용한 LLM 기반 모의해킹 자동화 파이프라인의 실제 구현을 사례로 들어 각 패턴의 동작 원리와 실패 지점을 살펴봅니다.

사전지식: 멀티 에이전트 오케스트레이션이란?

멀티 에이전트 오케스트레이션(Multi-Agent Orchestration)은 여러 LLM 에이전트에게 서로 다른 역할을 부여하고, 이들의 실행 순서·데이터 전달·합의 조건을 관리하는 설계 패턴입니다.

2025년 초 발표된 서베이 논문 "Multi-Agent Collaboration Mechanisms: A Survey of LLMs"(Tran et al., arXiv 2501.06322)에서는 멀티 에이전트 시스템을 Actors, Types, Structures, Strategies, Coordination Protocols의 5가지로 분류합니다. 또한 Google ADK 공식 문서(2025.12)는 Sequential Pipeline, Generator-Critic, Parallel Fan-Out 등 8가지 명명된 패턴을 제시합니다.

이 글에서는 이런 분류 체계를 참고하되, 실전 파이프라인에서 반복적으로 나타나는 3개의 핵심 아키타입(Archetype)에 집중합니다.

아키타입	학술/프레임워크 대응 용어	핵심 메커니즘
바톤패스	Sequential Pipeline, Chain, Assembly-Line	단계별 순차 이양
크리틱 루프	Generator-Critic, Adversarial Debate, Verifier-Worker	강제 반박·재검증 루프
툴 게이트	Schema-Gated Pipeline, Guardrails, FunctionMiddleware	스키마 검증 통과 필수

실전 사례 소개: codex_pentest 파이프라인

본문에서 참조하는 구현은 필자가 운용 중인 취약점 진단 팀 에이전트 프로젝트입니다. 이 시스템은 LLM 에이전트를 활용한 모의해킹 자동화 파이프라인으로, 안드로이드/웹 애플리케이션의 취약점 탐색부터 증거 수집, 교차 검증, 합의까지를 자동화합니다.

시스템 구성 개요

codex_pentest/
├── policy/           ← 역할 정책 (SSOT)
│   ├── ROLE_CORE.md       # 전체 에이전트 공통 역할·제약 정본
│   ├── REVIEW_POLICY.md   # 리뷰어 강제 규칙
│   └── COMPAT_MATRIX.md   # 모델별 스킬 호환 매핑
├── agents/           ← 에이전트별 규칙
│   ├── finder-static/     # 정적 분석 에이전트
│   ├── finder-dynamic/    # 동적 분석 에이전트 (ADB/Frida)
│   └── reviewer/          # 반박·재검증 에이전트
├── schemas/          ← 산출물 스키마
│   ├── finding.schema.json
│   └── review.schema.json
├── scripts/          ← 파이프라인 스크립트
│   ├── run-dual-tmux.sh     # 진입점: tmux 세션 생성
│   ├── tmux-monitor.sh      # 라운드 관리·합의 판정
│   ├── run-finder-static.sh
│   ├── run-finder-dynamic.sh
│   ├── merge-findings.sh    # 정적+동적 결과 병합
│   ├── gate-review.sh       # 리뷰 게이트 검증
│   ├── check-consensus.sh   # 최종 합의 판정
│   └── validate-role.sh     # 역할 동기화 검증
└── runs/             ← 실행 기록
    └── {run_id}/
        ├── context/    # 대상 스코프
        ├── rounds/     # 라운드별 findings/reviews
        ├── findings/   # 최신 finding 결과
        ├── reviews/    # 최신 review 결과
        ├── status/     # 상태 플래그 파일
        ├── artifacts/  # 증거 자료 (스크린샷, 스크립트)
        └── report.md   # 최종 보고서

실행 흐름

┌─────────────┐     ┌──────────────┐     ┌─────────────┐
│ finder-static│     │finder-dynamic│     │             │
│ (정적 분석)  │     │ (동적 분석)   │     │  reviewer   │
│  jadx/apktool│     │ ADB/Frida    │     │ (반박/검증)  │
└──────┬───────┘     └──────┬───────┘     └──────┬──────┘
       │                    │                     │
       └────────┬───────────┘                     │
                ▼                                 │
        merge-findings.sh                         │
         (결과 병합)                               │
                │                                 │
                ▼                                 │
        gate-review.sh ◄──────────────────────────┘
        (스키마 검증)           리뷰 결과
                │
                ▼
        check-consensus.sh
        (합의 판정)
                │
          ┌─────┴──────┐
          │            │
     consensus.ok  consensus.fail
     (최종 보고서)  (다음 라운드 재시도)

파이프라인은 tmux 세션 안에서 동작하며, tmux-monitor.sh가 전체 라운드 진행을 관리합니다. 최대 5라운드(MAX_ROUNDS)까지 반복하며, 전체 타임아웃은 3시간(MONITOR_TIMEOUT_SEC=10800)입니다.

아키타입 1: 바톤패스(Baton Pass) — 순차 이양 패턴

개념

바톤패스(Baton Pass)는 릴레이 경주에서 바톤을 넘기듯, 에이전트 A의 산출물이 에이전트 B의 입력이 되는 순차적 파이프라인 패턴입니다.

Google ADK 공식 문서에서는 이를 Sequential Pipeline Pattern이라 부르며, "클래식 조립 라인처럼 에이전트 A가 작업을 마치고 에이전트 B에게 바톤을 넘기는 구조"라고 설명합니다. OpenAI Swarm 프레임워크의 핵심 프리미티브도 이 Handoff 개념이며, 에이전트가 다른 에이전트 객체를 반환함으로써 제어권을 이전합니다.

학술 영역에서는 MetaGPT가 SOP(Standard Operating Procedures)를 강제하여 구조화된 산출물을 다음 단계로 넘기는 엄격한 체인 패턴을 구현했고, ChatDev 역시 설계→코딩→테스트→리뷰를 순차 이양하는 구조를 채택했습니다.

핵심 설계 원칙

바톤패스 패턴의 성패는 이양되는 컨텍스트의 완전성에 달려 있습니다.

산출물 형식의 사전 합의: 넘기는 측과 받는 측이 동일한 스키마를 공유해야 합니다
컨텍스트 손실 방지: 이전 단계의 판단 근거·피드백이 다음 단계에 함께 전달되어야 합니다
단방향 의존성 명확화: A→B→C 순서에서 C가 A의 산출물을 직접 참조해야 하는 경우, 명시적 컨텍스트 슬라이스(Context Slice)가 필요합니다

프로젝트에서의 구현

이 파이프라인에서 바톤패스는 finder-static → finder-dynamic → merge → reviewer 순서로 동작합니다.

1단계: 정적·동적 분석 병렬 실행 후 병합

# tmux-monitor.sh 발췌: 두 finder를 병렬로 실행
tmux new-window -d -t "$SESSION_NAME" -n "$static_window" "$static_cmd"
tmux new-window -d -t "$SESSION_NAME" -n "$dynamic_window" "$dynamic_cmd"

# 두 finder 모두 완료 대기
wait_for_round_finders_done "$round"

# 정적+동적 결과를 하나의 finding.json으로 병합
"$ROOT_DIR/scripts/merge-findings.sh" "$RUN_ID" \
    "$static_file" "$dynamic_file" "$finding_file"

finder-static(jadx/apktool 기반 정적 분석)과 finder-dynamic(ADB/Frida 기반 동적 분석)이 각각 독립적으로 취약점을 탐색한 뒤, merge-findings.sh가 두 결과를 하나의 finder.json으로 병합합니다. 이 병합된 JSON이 다음 단계인 reviewer 에이전트의 입력이 됩니다.

2단계: 라운드 간 컨텍스트 이양

# tmux-monitor.sh 발췌: 이전 라운드 리뷰를 다음 라운드 입력으로 전달
if (( round > 1 )); then
    prev_round=$((round - 1))
    prev_review_file="$ROUNDS_DIR/round-${prev_round}/reviews/reviewer.json"
    if [[ -f "$prev_review_file" ]]; then
        review_context_file="$prev_review_file"
    fi
fi

라운드 2부터는 이전 라운드의 reviewer.json이 컨텍스트 파일로 finder 에이전트에게 전달됩니다. 이를 통해 "어떤 finding이 증거 부족으로 반려되었는지"를 finder가 인지하고, 해당 부분의 증거를 보강할 수 있습니다.

3단계: 산출물 구조 통일

모든 에이전트의 산출물은 schemas/finding.schema.json과 schemas/review.schema.json으로 형식이 강제됩니다.

// finding.schema.json의 핵심 필수 필드
{
  "required": [
    "finding_id", "title", "severity_cvss", "root_cause",
    "attack_scenario", "poc_steps", "evidence",
    "impact", "expansion_paths"
  ]
}

각 finding은 취약점 ID, CVSS 점수, 근본 원인, 공격 시나리오, PoC 절차, HTTP 요청/응답 증거, 영향도, 확장 경로를 반드시 포함해야 합니다. 이 스키마 합의가 없으면 바톤패스 자체가 성립하지 않습니다.

바톤패스의 약점: 컨텍스트 유실

바톤패스 패턴의 가장 큰 약점은 컨텍스트 유실입니다. 필자가 특정 안드로이드 앱 대상으로 파이프라인을 실행했을 때, 라운드 1~4까지 진행되었음에도 합의에 도달하지 못했습니다. 핵심 원인 중 하나는 리뷰어가 지적한 보완 사항이 다음 라운드의 finder에게 효과적으로 전달되지 못해 동일한 증거 부족이 반복된 것이었습니다.

runs/{run_id}/status/
├── finder_static.r1.done ~ r4.done   ← 4라운드 모두 완료
├── finder_dynamic.r1.done ~ r4.done  ← 4라운드 모두 완료
├── reviewer.r1.done ~ r3.done        ← 3라운드 리뷰 완료
└── consensus.fail                    ← 합의 실패

시사점: 바톤패스에서는 "무엇을 넘기느냐"만큼 "이전 라운드에서 왜 실패했는지"를 함께 넘기는 것이 중요합니다. 단순한 산출물 전달이 아니라 피드백 컨텍스트의 구조화된 이양이 필요합니다.

아키타입 2: 크리틱 루프(Critic Loop) — 강제 반박 패턴

개념

크리틱 루프(Critic Loop)는 하나의 에이전트가 만든 산출물을 다른 에이전트가 체계적으로 반박·검증하는 적대적(Adversarial) 피드백 루프입니다.

Google ADK에서는 이를 Generator-Critic Pattern이라 부릅니다. 생성 에이전트(Generator)가 결과를 만들면, 비평 에이전트(Critic)가 사전 정의된 기준에 따라 검토하고, 기준 미달 시 피드백을 Generator에게 돌려보내 품질 게이트를 통과할 때까지 반복합니다.

학술 영역에서도 이 패턴은 활발히 연구되고 있습니다:

MAKER 프레임워크: 계층적 검증(hierarchical verification)을 통한 교차 심문(cross-examination). Verifier 에이전트가 Worker 산출물에 도전하여 긴 체인에서도 오류 누적을 거의 0으로 만든다고 보고됩니다.
Multi-Agent Debate 패턴: 에이전트들이 서로의 출력을 검토하며 반복적으로 입장을 수정합니다. 최종 결정은 다수결 또는 요약 에이전트가 내립니다.
GIRA(Guarded Tool-Using LLM Agents): OpenReview 2024에서 발표된 이 아키텍처는 제안 생성과 행동 승인을 분리하여, 다계층 안전 게이트가 차단·재작성·에스컬레이션할 수 있게 합니다.

핵심 설계 원칙

크리틱 루프가 효과적이려면 Critic의 검증 행위가 정량적이고 강제적이어야 합니다.

최소 검증 요건의 수치 명시: "충분히 검토한다"가 아니라 "반박 1회, 우회 2회, 추가 위협 2건, 신규 가설 3건" 같은 구체적 수치
판정 결과의 열거형 제한: accepted | rejected | needs_more_evidence 외의 애매한 판정을 허용하지 않음
루프 탈출 조건의 명확화: 무한 반복을 방지할 최대 라운드 수와 타임아웃

프로젝트에서의 구현

이 파이프라인의 크리틱 루프는 reviewer 에이전트가 담당합니다. Reviewer는 기본적으로 Finder의 결과를 의심하고 반박하는 역할입니다.

Reviewer의 강제 검증 규칙 (REVIEW_POLICY.md)

## Mandatory Review Actions
- 모든 finding마다 최소 1회 이상의 반박 시도를 수행한다.
- 차단 로직 또는 방어 로직이 있는 경우 최소 2개의 우회 경로를 제시하고 실제 시도한다.
- 각 finding마다 추가 위협(연계 공격) 최소 2개를 식별한다.
- 각 finding 검토마다 신규 취약점 가설 최소 3개를 제시한다.
- 증거가 부족하면 확정하지 않고 needs_more_evidence로 판정한다.

이 규칙은 단순한 가이드라인이 아니라 스키마 레벨에서 강제됩니다.

review.schema.json의 강제 필드:

{
  "rebuttal_attempts": {
    "type": "array",
    "minItems": 1,      // 반박 최소 1회
    "items": {
      "required": ["hypothesis", "test_steps", "result"]
    }
  },
  "bypass_attempts": {
    "type": "array",
    "minItems": 2,      // 우회 최소 2회
    "items": {
      "required": ["blocked_logic", "bypass_idea", "result"]
    }
  },
  "additional_threats": {
    "type": "array",
    "minItems": 2       // 추가 위협 최소 2건
  },
  "new_vulnerability_hypotheses": {
    "type": "array",
    "minItems": 3       // 신규 가설 최소 3건
  },
  "verdict": {
    "enum": ["accepted", "rejected", "needs_more_evidence", "need_more_evidence"]
  }
}

즉, Reviewer가 반박 0건으로 "문제없음"이라고 판정하는 것 자체가 스키마 유효성 검사에서 실패합니다. 이 설계는 LLM 에이전트가 "쉬운 길"을 택하는 경향(lazy agreement)을 구조적으로 차단합니다.

gate-review.sh의 검증 로직:

# gate-review.sh 발췌: finding별 검증 요건 확인
for fid in $finding_ids; do
    # 재현 산출물(repro_commands 또는 repro_script_py) 존재 확인
    repro_commands_count=$(jq --arg fid "$fid" \
        '[.findings[] | select(.finding_id == $fid)][0].repro_commands | length' \
        "$FINDING_FILE")

    if (( repro_commands_count < 1 && repro_script_len < 1 )); then
        echo "[FAIL] finding_id=$fid: reproducibility artifact missing"
        fail=1
    fi

    # 리뷰 필수 요건 확인
    rebuttal_count=$(jq ... '.rebuttal_attempts | length' ...)
    bypass_count=$(jq ... '.bypass_attempts | length' ...)

    if (( rebuttal_count < 1 )); then
        echo "[FAIL] finding_id=$fid: rebuttal_attempts must be >=1"
        fail=1
    fi
    if (( bypass_count < 2 )); then
        echo "[FAIL] finding_id=$fid: bypass_attempts must be >=2"
        fail=1
    fi
done

이 스크립트는 finding과 review를 동시에 검사하여, Finding 측의 재현 증거와 Review 측의 반박/우회 기록이 모두 충족되어야만 다음 단계로 진행을 허용합니다.

크리틱 루프의 강점과 한계

강점: 이 패턴은 LLM 에이전트의 과장(Hallucination)과 성급한 단정(Premature Conclusion)을 구조적으로 억제합니다. 실제로 Finder가 "심각도 9.0 취약점"이라고 보고해도, Reviewer가 반박과 우회를 시도한 결과 재현이 불가능하면 needs_more_evidence로 판정되어 과장된 보고가 최종 산출물에 포함되지 않습니다.

한계: 크리틱 루프만으로는 증거 부족의 원인을 해결할 수 없습니다. needs_more_evidence 판정이 쌓이기만 하고, 왜 증거가 부족한지(동적 재현 환경의 제약인지, 명령어 형식의 문제인지, 디바이스 의존성인지)를 분해하지 못하면 루프가 같은 자리를 맴돕니다.

아키타입 3: 툴 게이트(Tool Gate) — 스키마 검증 관문 패턴

개념

툴 게이트(Tool Gate)는 에이전트의 출력이 사전 정의된 스키마·규격·검증 조건을 통과해야만 다음 단계로 이동할 수 있는 관문(Gate) 패턴입니다.

이 패턴은 소프트웨어 공학의 Quality Gate와 유사하지만, LLM 에이전트 시스템에서는 비결정적 출력을 결정적 파이프라인에 적합시키는 핵심 메커니즘으로 작동합니다.

핵심 설계 원칙

게이트는 자동화되어야 한다: 사람이 수동으로 확인하는 것이 아니라, 스크립트가 JSON 스키마·필수 필드·수치 조건을 기계적으로 검증
Fail-Fast 원칙: 게이트 미통과 시 즉시 피드백하여, 후속 단계에서의 누적 오류를 방지
게이트 통과 ≠ 최종 승인: 개별 게이트 통과와 전체 파이프라인 합의는 분리해야 함

진단 파이프라인에서의 구현

이 파이프라인에는 두 단계의 게이트가 있습니다: 리뷰 게이트(gate-review.sh)와 합의 게이트(check-consensus.sh).

게이트 1: 리뷰 게이트 — 개별 finding의 품질 관문

gate-review.sh는 각 finding에 대해 다음을 검증합니다:

검증 항목	조건	실패 시 결과
재현 산출물	`repro_commands >= 1` 또는 `repro_script_py` 존재	게이트 실패
리뷰 존재	모든 finding_id에 대응하는 review 존재	게이트 실패
반박 시도	`rebuttal_attempts >= 1`	게이트 실패
우회 시도	`bypass_attempts >= 2`	게이트 실패
추가 위협	`additional_threats >= 2`	게이트 실패
신규 가설	`new_vulnerability_hypotheses >= 3`	게이트 실패

게이트를 통과하면 PROMOTE_ON_PASS=1일 때 산출물이 runs/{id}/final/ 디렉터리로 승격됩니다.

게이트 2: 합의 게이트 — 전체 파이프라인의 최종 관문

# check-consensus.sh 핵심 로직
total_findings=$(jq '.findings | length' "$FINDING_FILE")
accepted_count=$(jq '[.reviews[] | select(.verdict == "accepted")] | length' \
    "$REVIEW_FILE")

if (( accepted_count != total_findings )); then
    echo "[FAIL] Consensus check failed: \
        accepted=$accepted_count total=$total_findings"
    exit 1
fi

echo "[PASS] Consensus reached: all findings accepted."

합의 조건은 명확합니다: 모든 finding이 accepted 상태여야만 합의 도달(consensus.ok)입니다. 하나라도 needs_more_evidence이면 합의 실패이며, tmux-monitor.sh가 다음 라운드를 시작합니다.

# tmux-monitor.sh 발췌: 합의 실패 시 다음 라운드 진행
if "$ROOT_DIR/scripts/check-consensus.sh" "$RUN_ID" \
    "$finding_file" "$review_file"; then
    touch "$STATUS_DIR/consensus.ok"
    echo "[PASS] Consensus reached at round=$round"
    exit 0
fi

needs_count=$(jq '[.reviews[] | select(.verdict == "needs_more_evidence" \
    or .verdict == "need_more_evidence")] | length' "$review_file")

if (( needs_count > 0 && round < MAX_ROUNDS )); then
    echo "[INFO] need(s)_more_evidence count=$needs_count. Next round."
    round=$((round + 1))
    continue
fi

실패 사례: 안드로이드 앱 진단 파이프라인 실행

필자가 실제 운용한 안드로이드 앱 대상 실행에서는 총 10개의 finding 중 7개가 accepted, 3개가 needs_more_evidence로 판정되어 4라운드까지 반복한 끝에 consensus.fail로 종료되었습니다.

needs_more_evidence에 걸린 finding들의 공통 특징은 정적 분석에서는 취약점이 명확하지만 동적 재현 산출물이 부족했다는 점입니다. 예를 들어, 코드 분석으로 민감 정보가 onSaveInstanceState()에 평문으로 저장되는 것은 확인되었지만, 실제 기기에서 해당 데이터를 추출하는 재현 스크립트(repro_commands)가 환경 의존적이어서 게이트를 통과하지 못한 것입니다.

시사점: 툴 게이트의 needs_more_evidence는 원인 분해 없이 "더 증거를 모아라"만 반복하면 같은 곳에서 멈춥니다. 증거 누락의 원인을 세분화(명령어 부재 / 환경 의존성 / 디바이스 조건)해야 다음 라운드에서 실질적 보완이 가능합니다.

3개 아키타입의 협업: 계약 기반 오케스트레이션

실전에서는 위 3개 아키타입이 독립적으로 쓰이는 것이 아니라 겹쳐서 동작합니다. 이들을 안정적으로 연결하는 것이 4가지 계약 요소입니다.

계약 요소	역할	codex_pentest 구현
role_contract	에이전트의 역할·권한·제약 정의	`ROLE_CORE.md`를 SSOT로, `validate-role.sh`가 모든 에이전트 설정과 해시 동기화 검증
tool_scopes	에이전트별 허용 도구·산출물 범위	`agents/*/AGENTS.md`에서 각각 정적/동적/리뷰 범위 한정
context_slice	라운드 간 전달되는 컨텍스트 범위	`rounds/round-{n}/`에 라운드별 findings/reviews 저장, 이전 리뷰를 다음 라운드 입력으로 주입
stop_conditions	파이프라인 종료 조건	`check-consensus.sh`의 전원 accepted + `MAX_ROUNDS` 상한 + 타임아웃

이 4가지 중 하나라도 무너지면 파이프라인이 불안정해집니다. 예를 들어:

role_contract 위반: 에이전트가 역할 범위를 벗어나 임의 추정을 하면 산출물 신뢰도가 하락
tool_scopes 위반: 정적 분석 에이전트가 ADB 명령을 실행하려 하면 재현성이 보장되지 않음
context_slice 누락: 이전 라운드 피드백이 전달되지 않으면 같은 실패가 반복
stop_conditions 모호: 합의 조건이 불명확하면 무한 루프 또는 조기 종료

마치며

멀티 에이전트 LLM 시스템은 "에이전트를 몇 개 띄우면 된다"가 아니라 에이전트 간 업무 이양의 계약을 얼마나 견고하게 설계하느냐가 핵심입니다.

이 글에서 소개한 3가지 아키타입을 정리하면:

바톤패스: 순차적 산출물 이양. 컨텍스트 유실에 주의
크리틱 루프: 강제 반박을 통한 품질 향상. 수치화된 검증 요건 필요
툴 게이트: 스키마 검증 관문. 실패 원인의 세분화가 핵심

필자의 취약점 진단 에이전트 팀 파이프라인은 이 세 패턴을 조합하여 모의해킹 자동화에 적용한 사례입니다. 4라운드까지 돌아간 끝에 실패한 경험에서 얻은 교훈은, "도구가 고장난 게 아니라 계약이 빠져 있었다"는 것입니다.

멀티 에이전트 시스템을 설계할 때, 에이전트의 능력(어떤 LLM을 쓰느냐)보다 에이전트 간 인터페이스(무엇을 어떤 형식으로 넘기고, 어떤 조건에서 멈추는가)에 더 많은 시간을 투자하시길 권합니다.

References

Tran et al., "Multi-Agent Collaboration Mechanisms: A Survey of LLMs", arXiv 2501.06322, 2025
"Agentic AI: Architectures, Taxonomies, and Evaluation of LLM Agents", arXiv 2601.12560, 2026
Google ADK, "Developer's Guide to Multi-Agent Patterns", developers.googleblog.com, 2025
OpenAI, "Swarm: Educational framework for multi-agent orchestration", github.com/openai/swarm, 2024
Anthropic, "Building Effective AI Agents", resources.anthropic.com
Anthropic, "How We Built Our Multi-Agent Research System", anthropic.com/engineering
GIRA, "Guarded Tool-Using LLM Agents for Incident Response", OpenReview, 2024
"Exploration of LLM Multi-Agent Application Implementation Based on LangGraph+CrewAI", arXiv 2411.18241, 2024

저작자표시 비영리 동일조건 (새창열림)

'Side Project > AI Powered' 카테고리의 다른 글

[Vibe Coding Playbook] 2026 금융취약점분석평가 대응 인프라 진단 스크립트 고도화 (1)	2026.03.20
Claude에게 '초능력'을 부여하는 방법: Superpowers 플러그인 소개 (0)	2026.02.09
[OpenClaw] 운영에서의 보안상 유의사항 (0)	2026.02.01
[OpenClaw] mcporter에 Google Calendar MCP 등록하기 (0)	2026.02.01
OpenClaw 설치 및 리뷰 (0)	2026.01.31

멀티 에이전트 시스템의 3가지 아키텍처 패턴: 실전 모의해킹 파이프라인으로 살펴보기

들어가며

사전지식: 멀티 에이전트 오케스트레이션이란?

실전 사례 소개: codex_pentest 파이프라인

시스템 구성 개요

실행 흐름

아키타입 1: 바톤패스(Baton Pass) — 순차 이양 패턴

개념

핵심 설계 원칙

프로젝트에서의 구현

바톤패스의 약점: 컨텍스트 유실

아키타입 2: 크리틱 루프(Critic Loop) — 강제 반박 패턴

개념

핵심 설계 원칙

프로젝트에서의 구현

크리틱 루프의 강점과 한계

아키타입 3: 툴 게이트(Tool Gate) — 스키마 검증 관문 패턴

개념

핵심 설계 원칙

진단 파이프라인에서의 구현

실패 사례: 안드로이드 앱 진단 파이프라인 실행

3개 아키타입의 협업: 계약 기반 오케스트레이션

마치며

References

'Side Project > AI Powered' 카테고리의 다른 글

티스토리툴바