이 챕터의 흐름
단순히 "AI가 무엇인지"를 넘어서, 이제 "AI를 어떻게 일하게 할 것인가"를 다룬다. Agentic Workflow는 AI가 단발적으로 답변을 생성하는 것이 아니라, 목표를 향해 스스로 계획하고 실행하고 되돌아보는 순환형 작업 구조다. 이 챕터에서는 그 설계 원칙(Goal → Plan → Execute → Reflect)과 다중 에이전트 협업 구조, 그리고 RAG의 에이전트화(Agentic RAG)까지 다룬다.
2-1. Workflow란 무엇인가?
Traditional Workflow vs AI Agentic Workflow
Traditional Workflow (전통적 방식)
- 사전에 정의된 순서대로 진행되는 프로세스 (Linear Pipeline)
- Input → Process A → Process B → ... → Output
- 정해진 길을 따라가는 단방향 흐름 (Zero-shot)
- 한 번 실행되면 결과를 수정하거나 재시도하지 않음
AI Agentic Workflow (에이전틱 방식)
- 반복적인 자기 교정 과정을 포함하는 프로세스 (Iterative Loop)
- Goal ⟳ (Plan ⇌ Execute ⇌ Reflect) → Output
- 결과를 평가하고 스스로 개선하는 순환형 흐름
- 사람이 개입하지 않아도 품질을 스스로 높임
핵심 성능 데이터 (Andrew Ng, deeplearning.ai)
- GPT-3.5 (zero-shot): 48.1% 정확도
- GPT-4 (zero-shot): 67.0% 정확도
- GPT-3.5 + Agentic Workflow: 95.1% 정확도
더 강력한 모델로 업그레이드하는 것보다, Agentic Workflow를 적용하는 것이 더 큰 성능 향상을 가져올 수 있다. 이는 "강력한 모델 + 탄탄한 전략 = 우수한 성능"이라는 공식을 증명한다.
AI Agentic Workflow의 핵심 전략 요소 3가지
1. Planning (계획 수립)
- AI가 복잡한 목표를 단계적으로 나누어 수행할 수 있도록 설계
- 예: 개요 작성 → 정보 수집 → 초안 작성 → 검토 → 최종 정리
- 좋은 계획을 유도하기 위해 사람의 의도 전달이 중요 → 초기 설계와 전략적 개입은 Prompt를 통해 전달되어야 함
- Human: 계획 설계자 / AI: 계획 실행자이자 보완자
2. Reflection (자기 피드백)
- AI가 자신의 결과물을 되돌아보고 수정 또는 개선하는 루프 구성
- 예: 초안 오류 발견 → 재검색 & 재작성
- 루프 자체도 자동화하여 사람의 반복 개입 없이도 품질 향상 가능
3. Collaboration (다중 에이전트 협업)
- 하나의 Agent가 모든 일을 하지 않고, 역할을 나눠 전문화된 Agents 간 협업
- 예: 검색 에이전트 + 요약 에이전트 + 결과 검토 에이전트
2-2. Design Framework: Goal → Plan → Execute → Reflect
Agent는 사고 구조를 설계하는 것에서 시작한다.
AI Agentic Workflow 설계는 Strategic Layer와 Operational Layer로 구분된다.
2-2-1. Goal: 무엇이 달성되면 끝인가?
Goal은 "무엇을 할지"가 아니라, "무엇이 달성되면 끝인지"를 업무 관점에서 정의하는 단계다.
Desired Outcome (업무 결과 정의)
- 대상: 무엇에 대한 결과인가?
- 변화: 무엇이 달라져야 하는가?
- 결정/행동: 결과가 어떤 의사결정/행동에 사용되는가?
- 범위: 어디까지 포함/제외 하는가?
좋은 Goal 예시:
- "전기차 시장 침체에 대해 의사결정자가 실행 가능한 원인-근거-전략 구조의 인사이트를 얻는다."
- "고객 문의에 대해 정책 근거를 인용하여 재문의율을 낮추는 답변을 제공한다."
Success Criteria (측정 가능한 기준 정의)
성공 기준은 "좋은 답변 같은 정성 표현"이 아니라, 측정 가능한 기준으로 정의해야 한다.
| 구분 | 항목 | 내용 |
|---|---|---|
| 결과 품질 기준 (Quality) | 근거성 | 주장마다 근거가 있는가? (출처) |
| 완결성 | 필수 항목을 빠짐없이 포함했는가? | |
| 일관성 | 내부 모순이 없는가? | |
| 업무적 제약 조건 (Constraints) | Target Actor | 톤, 매너, 답변 길이 등 |
| Compliance | 내부정보 노출 금지, 법적 제한 등 | |
| Scope Boundaries | 포함, 제외 범위 | |
| Formatting | JSON, 템플릿, 표 등 | |
| 서비스 기준 (Operational) | Cost | 호출 횟수, Latency 등 |
| Error Handling | 근거 없을 때 응답 규칙 등 | |
| Consistency | 같은/유사 입력에 일관된 품질 수준 유지 | |
| Stability | 반복 실행 시 품질 변동 허용 범위 |
2-2-2. Plan: 어떻게 달성할 것인가?
Plan 단계는 다시 세 가지 하위 설계로 나뉜다: Task Decomposition, Control Strategy, Collaboration Structure.
2-2-2-1. Task Decomposition: 실행 단위 설계
Task Decomposition은 일을 나누는 단계가 아니라, Goal을 달성하기 위한 실행 단위를 설계하는 단계다. 분해된 Subtask는 작업 중심이 아니라 Outcome 중심으로 분해되어야 한다.
Task Decomposition 고려사항:
- Outcome Alignment: 이 단계가 Outcome에 직접 기여하는가? 이 단계가 없다면 Goal 달성이 어려운가?
- Dependency Structure: 병렬 가능한가? 반드시 순차적이어야 하는가? 실패 시 어느 단계로 돌아가는가?
- Granularity: 각 Subtask가 단일 책임을 가지는 수준으로 분해. 너무 크면 Reflection이 의미 없음. 너무 잘게 나뉘면 구조 복잡성 증가.
예시 (Goal: 정책 근거 인용 + 고객 재문의율 감소)
Task Decomposition은 Plan의 뼈대를 구성하는 단계다.
2-2-2-2. Control Strategy: 언제 진행하고 언제 멈출지 설계
Control Strategy는 "몇 번 반복할 것인가"를 정하는 것이 아니라, 언제 진행하고, 언제 되돌아가고, 언제 멈출지를 설계하는 단계다.
Linear Flow (선형 흐름)
- 가장 간단한 구조: Subtask A → B → C → Output
- 의존성이 명확할 때 적합
- Reflection의 의미가 약함
Loop Strategy (반복 제어)
- 부분 개선을 가능하게 만드는 구조: Plan → Execute → Reflect → (조건부 재진입)
- 설계 시 반드시 정의해야 할 것:
- 어떤 조건에서 재진입하는가?
- 어떤 단계로 돌아가는가?
- 무엇이 개선 대상인가?
Conditional Branch (조건 분기)
- 모델의 판단이 아니라 설계자의 정책으로 결정
- Branch 조건은 Prompt가 아니라 Rule로 정의되어야 함 (LLM에게 판단을 맡기면 흐름이 불안정해지기 때문)
Retry & Termination Policy (종료 정책)
- Retry는 품질 향상이 예상될 때에만 허용
- 종료 조건이 없으면 Agent는 멈추지 않음 → 반드시 정의 필요
- Max iteration (최대 반복 횟수)
- 실패 시 fallback 전략
- 근거 부족 시 응답 규칙
- 비용 초과 시 종료 정책
핵심: Task가 구조라면, Control Strategy는 의사결정 로직이다 (특히, 실패를 어떻게 처리할 것인가).
예시 (Control Strategy 적용):
2-2-2-3. Collaboration Structure: 책임과 의사결정 권한 설계
여러 에이전트가 협업할 때 누가 결정권을 가지는지를 설계하는 단계다.
A. Centralized Structure (중앙화 구조)
- 하나의 Agent 또는 Supervisor가 최종 판단
- 다른 Agent는 실행 단위 역할
- 예: Orchestration, Supervisor Pattern
- 적합한 케이스: Workflow가 복잡하고 Branch가 많은 경우, 품질 검증이 핵심인 도메인
B. Distributed Structure (분산 구조)
- 각 Agent가 자신이 맡은 역할 범위 내에서 부분적 의사결정 수행
- 역할 기반 분리: Search, Analysis, Development 등
- 예: 역할 기반 Multi-Agent, Chain 형태
- 적합한 케이스: 역할이 명확히 구분되는 경우, 확장성이 필요한 환경
C. Cross-Validation Structure (교차 검증 구조)
- 복수 Agent가 동일 문제를 독립적으로 수행
- Judge 또는 비교 로직으로 최종 선택
- 예: Cross-Check, Self-Consistency
- 적합한 케이스: 정확성이 매우 중요한 도메인 (법률, 정책, 의료 등), Hallucination 위험 완화 필요
D. Hybrid Structure (혼합 구조)
- Centralized, Distributed 등을 혼합
- 의사결정 권한을 계층적, 상황별로 분리하여 배분한 구조
- 적합한 케이스: 대규모 Agent 시스템, 다단계 Workflow, 품질 + 비용 균형이 필요한 경우
- 고려사항: 설계 난이도가 가장 높고, 초기 설계 실패 시 유지보수 부담이 증가
💡 Collaboration Structure 심화: 각 구조의 비교
구조를 선택할 때 핵심 기준은 두 가지다: 의사결정 권한의 집중/분산과 품질 vs 효율성의 트레이드오프.
구조 의사결정 비용 품질 제어 확장성 Centralized Supervisor 집중 중간 높음 낮음 (병목) Distributed 각 Agent 분산 낮음 보통 높음 Cross-Validation Judge 집중 높음 매우 높음 낮음 Hybrid 계층적 분배 높음 높음 중간 실제 프로덕션 시스템은 대부분 Hybrid 구조를 채택하며, 중요도가 높은 경로에만 Cross-Validation을 적용하는 방식으로 비용을 최적화한다.
2-2-3. Execute: 실행
Execute 단계는 Plan에서 설계된 내용을 실제로 수행하는 단계다.
- Tool Invocation: 정의된 도구를 순서에 따라 호출
- State Update: 실행 결과를 State에 기록하여 다음 단계에서 활용 가능하도록 관리
- Action Execution: 실제 행동 수행 (검색, 계산, API 호출 등)
2-2-4. Reflect: 품질 점검 방식
Reflection은 AI가 자기 응답을 되돌아보고 더 나은 답을 만드는 과정이다. 루프 자체도 자동화하여 사람의 반복 개입 없이도 품질을 향상시킬 수 있다.
역할 분담:
- Human: Reflection 구조 설계, 피드백 방향 설계, 최종 결과 검토 및 선택
- AI: Reflection 자동 실행
Reflection의 3가지 유형:
1. Self-Reflection
- LLM이 스스로 자신의 생성 결과를 평가하고 개선
- 구조: Generate LLM → Reflect LLM → (필요 시 재생성)
- 평가 기준: Success Criteria (Quality, Compliance, Operational)
2. Tool-based Reflection
- 외부 도구(검색, 계산기 등)를 활용하여 생성 결과를 검증
- 예: 생성된 답변의 사실 여부를 웹 검색으로 확인
3. External Judge Reflection
- 별도의 Judge 에이전트(또는 모델)가 결과를 평가
- 예: LLM-as-a-Judge 패턴에서 별도 LLM이 답변 품질을 평가
2-3. Multi-Agent Workflow
여러 에이전트가 협력하여 복잡한 작업을 수행하는 구조. 각각의 에이전트가 서로 다른 관점과 기능을 제공하여, 단일 에이전트가 할 수 없는 복잡한 과업을 분할/협력하여 처리한다.
주요 설계 패턴
1. Parallel Collaboration (병렬 협업)
- 여러 에이전트가 동시에 작업 수행 (병렬 수행)
- 예: 다양한 아이디어 제안 → 통합 에이전트가 정리
- 목적: 처리 시간 단축
2. Sequential Collaboration (순차 협업)
- 에이전트 간 단계별 흐름 (순차 협업)
- 예: 분석 → 요약 → 피드백 순서로 에이전트 연결
- 목적: 단계별 전문성 적용
3. Negotiation & Debates (토론 기반 협업)
- 서로 다른 의견을 가진 에이전트 간 토론
- 최종 결정을 내리기 위한 의사결정 루프 포함
- 목적: 다양한 관점에서 최선의 답 찾기
Multi-Agent 설계 시 유의사항
- 역할과 책임 분배: "누가 무엇을 할 것인지" 명확하게. 각 에이전트는 독립적, 중복되지 않도록 설계
- Agent Interface 표준화: 에이전트 간 데이터를 주고받는 방식이 통일되어야 함 → State. 어떤 형식, 어떤 정보 단위로 메시지를 주고받을지 규정
- Loop Design: 에이전트들이 서로 평가하고 수정만 하다 보면 무한루프 가능. 끝을 내주는 조건 또는 에이전트 추가 필요 (최대 반복 횟수, 의사결정 에이전트, Voting/Scoring)
💡 ChatDev: 멀티 에이전트 소프트웨어 개발 실험
ChatDev는 멀티 에이전트 협업으로 자동화된 소프트웨어 개발을 시도한 프로젝트다. 기획 → 설계 → 구현 → 테스트 → 배포까지 각 단계를 전담하는 에이전트들이 역할을 분담하고 의사소통하는 구조를 실험했다.
이는 AI Agent 협업의 가능성을 보여주는 초기 연구로, 현재 Superpowers, Cursor.AI 등 실제 코딩 에이전트 도구들의 이론적 배경이 되었다.
💡 Superpowers: AI Coding Agent의 설계 원칙
Superpowers는 AI Coding Agent가 코드를 작성하는 방식을 근본적으로 바꾼 오픈소스 소프트웨어 개발 프레임워크다. 그 워크플로우가 AI Agentic Workflow 설계의 교과서적 예시다:
- Brainstorming: 코드 짜기 전 "무엇을 만들 것인가?"를 먼저 질문하여 아이디어를 구체화. 사용자 검증을 거쳐 명확한 설계 문서를 먼저 작성해야만 다음 단계로 넘어감.
- Git Worktrees: 설계가 승인되면 메인 브랜치를 안전하게 보호하기 위해 완전히 격리된 개발 환경 구축.
- Planning: 전체 프로젝트를 2~5분 안에 끝낼 수 있는 아주 작은 단위의 작업으로 정의. 각 작업에는 정확한 파일 경로, 실행 코드, 검증 단계가 포함됨.
- Subagent-Driven Dev: 쪼개진 단위 작업은 새롭게 정의된 Sub-agent들에게 배분. Context가 꼬이거나 과부하가 걸리는 것을 방지.
- Test-Driven Dev (TDD): 엄격한 Red-Green-Refactor TDD 강제. 반드시 실패하는 테스트 코드를 먼저 작성하고, 이를 통과하는 최소한의 코드만 작성하도록 통제.
- Code Review: 초기 설계를 잘 따랐는지 1차 검증하고, 코드 품질에 대하여 2차 리뷰 진행. 치명적인 이슈가 발견되면 다음 단계 진행이 차단됨.
- Finishing: 모든 작업과 테스트가 성공적으로 완료되면 Pull Request 생성, 병합, 작업공간 정리.
2-4. Agentic RAG
RAG란?
RAG(Retrieval-Augmented Generation)는 LLM이 외부 문서나 데이터베이스에서 관련 정보를 검색하여 답변을 생성하는 방식이다. 전통적인 RAG는 단순히 "검색 → 답변 생성"의 단방향 프로세스다.
Agentic RAG란?
Agentic RAG는 AI Agent의 특성(Planning, Reflection, Collaboration)을 RAG에 적용한 개념이다.
Agentic RAG = [Planning + Reflection + Collaboration] + RAG
전통적 RAG와의 비교:
| 구분 | 전통적 RAG | Agentic RAG |
|---|---|---|
| 프로세스 | 검색 → 답변 생성 (단방향) | 계획 → 검색 → 평가 → 재검색 → 생성 → 검토 (순환) |
| 정보 검색 방식 | 사전에 인덱싱된 문서(Vector DB) 조회에 국한 | 웹검색, API 호출, 코드 실행, 계산기 등 다양한 도구를 목적에 맞게 선택 |
| 응답 생성 과정 | 단순히 검색된 정보를 바탕으로 응답 생성 | 검색된 정보를 요약, 통합, 분석 후 응답 생성 |
| 복잡한 요청 처리 | 제한적인 복잡성 처리 | 다단계 요청을 처리하며, 불확실성 해결하도록 반복 처리 |
| 실시간성 | 닫힌 지식 (Closed Domain) | 열린 지식 (Open Domain) |
| Cost | 빠르고 저렴함 (Single Call) | 상대적으로 느리고 비쌈 (Multiple Calls & Loops) |
| 적용 사례 | Simple Q&A, FAQ | In-depth Q&A, 검색 기반 보고서 생성 |
Strategy 비교:
| 전략 | 전통적 RAG | Agentic RAG |
|---|---|---|
| Planning | 검색 → 답변 생성 | AI가 목적에 맞게 검색 전략을 스스로 설계. 어떤 문서를 찾을지, 어떤 순서로 검색, 요약, 생성할지 결정 |
| Reflection | 검색된 정보 그대로 사용 (별도 평가 없음) | AI가 생성된 응답에 대해 스스로 검토. 검색 내용이 불충분하면 다시 검색→수정 루프를 수행 |
| Collaboration | Agent 아닌 정보 검색 프로세스 (협업 없음) | 여러 역할을 가진 Agent들이 협업 (검색 에이전트, 요약 에이전트, 응답 검토 에이전트 등 역할 분담) |
Agentic RAG Workflow
Agentic RAG의 전체 흐름:
각 단계의 의미:
- Router: 어떤 검색 전략을 사용할지 판단 (Vector DB vs Web Search 등)
- Query Transformation: 사용자의 질문을 검색에 최적화된 형태로 변환
- Grade Documents: 검색된 문서가 질문과 관련이 있는지 평가
- Query Rewrite: 검색 품질이 낮으면 쿼리를 재작성하여 재검색
- Hallucination 검증: 생성된 답변이 검색된 문서를 기반으로 하는지 확인
- Answer Relevance: 최종 답변이 사용자 질문에 실제로 답하는지 확인
핵심 요약
더 강한 모델보다 잘 설계된 워크플로우가 성능을 좌우한다. Agentic Workflow의 설계는 "무엇이 달성되면 끝인지"를 측정 가능한 기준으로 정의하는 Goal에서 시작하고, Task Decomposition · Control Strategy · Collaboration Structure로 구성된 Plan이 그 뼈대를 잡는다. 종료 조건 없는 루프는 Agent를 멈추지 않게 만드는 가장 흔한 함정이므로, 반복 횟수와 실패 시 처리 방식은 반드시 명확히 정해두어야 한다.
