Phase 6-1 · Multi-Agent 설계 패턴¶
예상 소요 1시간
이대리
"Agent를 하나만 쓰면 뭐가 문제냐고? 뭐든 혼자 다 하는 직원 생각해봐. 일이 몰리면 느려지고, 실수하고, 어디서 망가졌는지도 모르잖아."
Agent 하나의 한계¶
Phase 5에서 만든 log_agent.py는 로그만 봤습니다. 실제 장애 대응에 필요한 건:
이걸 하나의 Agent에게 몰아주면:
| 문제 | 설명 |
|---|---|
| 컨텍스트 폭발 | 도구 수가 많아질수록 LLM이 헷갈림 |
| 책임 불분명 | 어느 단계에서 실패했는지 추적 어려움 |
| 재사용 불가 | 로그 분석 로직을 다른 곳에 쓸 수 없음 |
패턴 1 · Supervisor (감독자-작업자)¶
사용자 요청
│
▼
[Supervisor Agent]
├── "로그 봐줘" ──→ [Log Agent] → 결과 반환
├── "메트릭 봐줘" → [Metrics Agent] → 결과 반환
└── "이벤트 봐줘" → [Event Agent] → 결과 반환
│
▼
최종 요약 브리핑
Supervisor가 하는 일: - 사용자 요청을 분석해서 어떤 Worker를 호출할지 결정 - Worker의 결과를 받아서 종합 답변 생성 - 필요하면 같은 Worker를 여러 번 호출
적합한 업무: - 상황마다 필요한 정보가 달라지는 경우 - Worker 실행 순서를 동적으로 결정해야 하는 경우
Supervisor 패턴의 핵심
Supervisor도 LLM입니다. "어떤 도구를 부를지 결정하는 도구"를 가진 LLM입니다. Worker도 LLM이거나, 단순한 Python 함수일 수 있습니다.
패턴 2 · Sequential (파이프라인)¶
[Step 1: Log Collector]
로그 수집
│
▼
[Step 2: Error Analyzer]
에러 패턴 분석
│
▼
[Step 3: Report Writer]
브리핑 문서 생성
│
▼
최종 보고서
특징: - 각 단계의 출력이 다음 단계의 입력 - 순서가 고정됨 — 유연성 없음, 대신 예측 가능
적합한 업무: - 데이터 가공 파이프라인 - 수집 → 분석 → 포맷팅처럼 순서가 항상 동일한 경우
패턴 3 · Parallel (병렬 Fan-out/Fan-in)¶
[Orchestrator]
├──────────────────────────────────┐
│ │
▼ ▼
[Log Agent] [Metrics Agent]
로그 수집 (동시 실행) 메트릭 수집 (동시 실행)
│ │
└──────────┬───────────────────────┘
▼
[결과 취합 + 요약]
특징: - 독립적인 작업을 동시에 실행 → 전체 시간 단축 - Fan-out: 하나의 요청을 여러 Agent에게 분배 - Fan-in: 여러 결과를 하나로 합침
적합한 업무: - 서로 의존성 없는 정보 수집 여러 건 - 처리 시간이 중요한 경우
세 패턴 비교¶
| 항목 | Supervisor | Sequential | Parallel |
|---|---|---|---|
| 유연성 | 높음 (동적 결정) | 낮음 (고정 순서) | 중간 |
| 예측 가능성 | 낮음 | 높음 | 높음 |
| 구현 복잡도 | 중간 | 낮음 | 중간 |
| 처리 속도 | 단계 수에 비례 | 단계 수에 비례 | 빠름 (병렬) |
| 적합한 상황 | 상황에 따라 경로 달라짐 | 항상 같은 처리 흐름 | 독립적 작업 여러 건 |
라이브러리 없이 구현하는 이유¶
LangGraph, AutoGen, CrewAI 같은 프레임워크들이 있지만, 이번 실습에서는 OpenAI SDK만 사용합니다.
| 라이브러리 | OpenAI SDK 직접 | |
|---|---|---|
| 학습 곡선 | 높음 (프레임워크 문법 따로) | 낮음 |
| 원리 이해 | 추상화 뒤에 숨음 | 직접 보임 |
| 실무 전환 | 쉬움 (원리 알면) | — |
원리를 이해한 다음 프레임워크를 선택하는 것이 순서입니다.
한밭푸드 장애 대응 시나리오에 적용하면¶
박대리
"그럼 저희는 어떤 패턴이 맞아요?"
이대리
"장애마다 필요한 정보가 달라. 어떤 날은 로그만 봐도 되고, 어떤 날은 메트릭이 핵심이야. 그럼 어떤 패턴?"
장애 대응은 상황마다 경로가 다릅니다. → Supervisor 패턴이 적합합니다.
장애 감지
│
▼
[Supervisor]
판단: "지금 어떤 정보가 필요한가?"
├── 파드 죽어있음 → Log Agent + Event Agent
├── 응답 느림 → Metrics Agent + Log Agent
└── 배포 직후 장애 → Event Agent만으로 충분
│
▼
30초 브리핑
팀 토론 (15분)¶
각 팀에서 다음 질문에 답해보세요.
- Supervisor가 잘못된 Worker를 선택하면 어떻게 되나? 방어 방법은?
- Parallel 패턴에서 하나의 Worker가 실패하면 전체가 멈춰야 하나?
- Log Agent와 Metrics Agent 중 하나만 쓸 수 있다면 장애 대응에서 어떤 걸 선택하겠나?
정리¶
| 확인 내용 | 결과 |
|---|---|
| Supervisor 패턴 구조 이해 | ✅ |
| Sequential 패턴 구조 이해 | ✅ |
| Parallel 패턴 구조 이해 | ✅ |
| 한밭푸드 시나리오에 패턴 적용 | ✅ |