Claude with the Anthropic API #10 — Agentic Workflows

이번에는 Coursera Building with the Claude API 강의의 마지막 Module인 Agentic Workflows를 정리해본다.

지금까지 Claude API 호출, Prompt Engineering, Tool Use, MCP, RAG, Claude Code와 Computer Use를 살펴봤다. 마지막 Module에서는 이 기능들을 조합해 한 번의 Model 호출로 끝나지 않는 복잡한 Task를 처리하는 방법을 다룬다.

단일 Claude 호출
→ 하나의 Prompt에 하나의 Response

Workflow
→ 미리 정의한 순서와 분기에 따라 여러 Claude 호출을 연결

Agent
→ Goal과 Tool을 받은 Claude가 다음 Step을 스스로 결정

이번 글은 Coursera Module 7의 영상 7개를 강의 순서 그대로 모두 다룬다.

1. AI Workflows
2. Parallelization Workflows
3. Chaining Workflows
4. Routing Workflows
5. Agents and Tools
6. Environment Inspection
7. Workflows vs Agents

1. AI Workflows

복잡한 Task를 반드시 하나의 Prompt로 해결할 필요는 없다. 큰 문제를 작은 단계로 나누고, 각 단계의 Claude 호출을 Code로 연결하면 단계별 역할과 완료 조건을 명확하게 만들 수 있다. 이것이 AI Workflow다.

Input
  ↓
Claude Call 또는 Programmatic Step
  ↓
중간 결과 검증
  ↓
다음 Claude Call
  ↓
Output

Workflow에서는 실행 순서와 분기를 Application Code가 결정한다. Claude는 각 Step에 주어진 좁고 구체적인 Task를 처리한다. 전체 과정이 미리 정해져 있으므로 결과를 예측하고 Debugging하기 쉽다.

Workflow가 필요한 대표적인 이유는 다음과 같다.

• 하나의 Prompt로 처리하기에는 Task가 너무 크다.
• 중간 결과를 검증한 뒤 다음 단계로 넘어가야 한다.
• 입력 종류에 따라 서로 다른 Prompt와 Tool을 사용해야 한다.
• 독립적인 작업을 동시에 실행해 Latency를 줄이고 싶다.
• 여러 관점의 결과를 비교해 신뢰도를 높이고 싶다.

다만 여러 호출은 Latency와 Token 비용을 늘린다. 단일 Prompt, Prompt Engineering, RAG만으로 충분한 문제라면 Workflow를 추가하지 않는 편이 단순하다. 복잡성은 측정 가능한 품질 향상이 있을 때 추가해야 한다.

이번 Module에서 다루는 핵심 Workflow는 Parallelization, Chaining, Routing 세 가지다.

2. Parallelization Workflows

Parallelization Workflow는 서로 의존하지 않는 여러 Claude 호출을 동시에 실행하고 결과를 합치는 Pattern이다.

                    ┌─ Worker A ─┐
Input ──────────────┼─ Worker B ─┼─ Aggregator → Output
                    └─ Worker C ─┘

순차 실행 시 전체 시간은 각 작업 시간의 합에 가깝다. 병렬 실행 시에는 가장 오래 걸리는 작업의 시간에 가까워질 수 있다.

Sequential
3초 + 4초 + 2초 ≈ 9초

Parallel
max(3초, 4초, 2초) ≈ 4초

Sectioning

Sectioning은 큰 Task를 서로 독립적인 Subtask로 나누는 방식이다. 각 Worker가 다른 부분을 담당하고 Aggregator가 결과를 합친다.

Pull Request
├─ Worker A: Security Review
├─ Worker B: Performance Review
├─ Worker C: Maintainability Review
└─ Aggregator: 중복 제거 및 최종 Review 작성

각 Worker의 관심사를 분리하면 하나의 Prompt에서 모든 조건을 동시에 처리할 때보다 각 기준에 집중할 수 있다. Evaluation에서도 정확성, 관련성, 안전성처럼 서로 다른 항목을 별도 호출로 평가할 수 있다.

Python에서는 asyncio.gather()로 독립적인 호출을 묶을 수 있다.

import asyncio

async def review(code: str, criterion: str) -> str:
    return await call_claude(
        f"다음 Code를 {criterion} 관점에서 검토하세요.\n\n{code}"
    )

async def review_in_parallel(code: str) -> list[str]:
    return await asyncio.gather(
        review(code, "Security"),
        review(code, "Performance"),
        review(code, "Maintainability"),
    )

Voting

Voting은 같은 Task를 여러 번 수행한 뒤 결과를 비교하거나 투표하는 방식이다. 하나의 결과만으로 판단하기 어려운 분류, 위험 탐지, Review Task의 신뢰도를 높일 때 유용하다.

같은 Input
├─ Judge A → Safe
├─ Judge B → Unsafe
└─ Judge C → Unsafe
              ↓
        Majority Vote → Unsafe

Voting에서는 단순 다수결만 사용할 필요는 없다. 중요한 위험 항목은 한 명의 Reviewer만 문제를 찾아도 차단하거나, Reviewer별 Confidence를 반영할 수 있다.

Parallelization의 전제는 Subtask가 서로 독립적이라는 것이다. Worker B가 Worker A의 결과를 필요로 한다면 병렬화가 아니라 Chaining이 적합하다. API Rate Limit, 동시 요청 비용, 일부 Worker 실패 시 처리 방식도 함께 설계해야 한다.

3. Chaining Workflows

Chaining Workflow는 이전 Step의 Output을 다음 Step의 Input으로 전달하는 선형 Pipeline이다.

Input
  ↓
Step 1: 초안 작성
  ↓
Step 2: 기준에 따라 검토
  ↓
Step 3: 피드백 반영
  ↓
Final Output

각 단계가 앞 단계의 결과에 의존하거나, 하나의 복잡한 Task를 명확한 순서로 분해할 수 있을 때 사용한다.

예를 들어 기술 문서 생성 과정은 다음처럼 나눌 수 있다.

요구사항
  ↓
Outline 생성
  ↓
Outline 규칙 검증 ── 실패 → Outline 재작성
  ↓ 성공
본문 작성
  ↓
기술 정확성 검토
  ↓
최종 문서

각 Step 사이에는 Programmatic Gate를 둘 수 있다. JSON Schema 검증, 필수 Section 존재 여부, 금지된 표현 검사처럼 Code로 확인할 수 있는 조건은 Model에게 다시 묻지 않고 Code로 검증하는 편이 빠르고 결정적이다.

outline = generate_outline(requirements)

if not has_required_sections(outline):
    outline = revise_outline(outline, "필수 Section이 누락되었습니다.")

draft = write_document(outline)
review = review_accuracy(draft)
final_document = revise_document(draft, review)

Chaining은 한 번의 큰 Prompt를 여러 개의 쉬운 Prompt로 바꾸어 각 단계의 정확성을 높일 수 있다. 대신 Step 수만큼 Latency와 비용이 증가하고, 앞 단계의 오류가 뒤 단계로 전파될 수 있다.

따라서 중간 Output의 Format을 명확히 하고, 중요한 경계마다 Validation과 실패 경로를 추가해야 한다.

4. Routing Workflows

Routing Workflow는 입력을 먼저 분류한 뒤, 유형에 맞는 전문 처리 경로로 보낸다.

User Request
     ↓
   Router
  ├─ Technical Issue → Technical Support Prompt + Log Tool
  ├─ Refund Request  → Refund Policy + Approval Flow
  └─ General Query   → FAQ + RAG

모든 입력을 하나의 거대한 Prompt로 처리하면 서로 다른 요구사항과 규칙이 충돌할 수 있다. Routing을 사용하면 각 경로의 Prompt, Model, Tool과 권한을 독립적으로 최적화할 수 있다.

Router의 Output은 자유 형식 Text보다 제한된 Label이나 구조화된 Data가 적합하다.

{
  "route": "TECHNICAL_SUPPORT",
  "confidence": 0.94,
  "reason": "사용자가 결제 API의 502 오류를 보고함"
}

match route.route:
    case "TECHNICAL_SUPPORT":
        return handle_technical(request)
    case "REFUND":
        return handle_refund(request)
    case "GENERAL":
        return handle_general(request)
    case _:
        return request_clarification()

Routing은 Business Category뿐 아니라 Model 선택에도 활용할 수 있다. 단순하고 반복적인 요청은 빠르고 저렴한 Model로, 복잡하거나 예외적인 요청은 더 높은 성능의 Model로 보낼 수 있다.

Router가 잘못 분류하면 이후 경로 전체가 잘못되므로 다음 항목을 평가해야 한다.

• Route별 Precision과 Recall
• 낮은 Confidence에서의 Fallback
• 여러 Category에 걸친 요청 처리
• 새로운 유형의 입력을 위한 UNKNOWN 경로
• 오분류가 위험한 요청의 Human Review

5. Agents and Tools

Workflow는 다음 Step을 Code가 결정하지만, Agent는 Claude가 현재 상태를 보고 다음 Action을 결정한다. Agent에게는 Goal과 Goal을 달성하는 데 필요한 Tool이 제공된다.

Goal + Available Tools
          ↓
        Claude
          ↓
다음 Tool과 Argument 선택
          ↓
Application이 Tool 실행
          ↓
Tool Result를 Claude에게 반환
          ↓
완료 또는 중단 조건까지 반복

Tool은 역할에 따라 나눌 수 있다.

• Read Tool: File 읽기, Search, Database 조회
• Write Tool: File 수정, Ticket 생성, 상태 변경
• Execution Tool: Test, Build, Script와 Command 실행

Agent는 현재까지의 Message와 Tool Result를 바탕으로 어떤 Tool을 어떤 Argument로 호출할지 선택한다.

messages = [{"role": "user", "content": goal}]

for step in range(MAX_STEPS):
    response = call_claude(messages=messages, tools=tools)
    messages.append({"role": "assistant", "content": response.content})

    tool_uses = find_tool_uses(response)
    if not tool_uses:
        return response

    results = [execute_safely(tool_use) for tool_use in tool_uses]
    messages.append({"role": "user", "content": results})

raise MaxStepsExceeded()

Agent 구현 자체는 단순한 Tool Use Loop일 수 있다. 실제 품질은 Tool Interface에서 크게 좌우된다. 이름과 Description이 모호하거나 비슷한 Tool이 많으면 Agent가 잘못된 Tool을 선택하기 쉽다.

좋은 Tool은 다음 정보를 분명히 전달해야 한다.

• Tool이 수행하는 일
• 사용해야 하는 상황과 사용하면 안 되는 상황
• 각 Parameter의 의미와 Format
• 정상 결과와 Error 형태
• 외부 상태 변경 여부
• 호출 전 승인이 필요한 조건

특히 삭제, 결제, 배포, Message 전송 같은 Write Tool은 실행 전 사용자 확인과 Idempotency를 적용해야 한다. Agent의 자율성이 커질수록 Tool의 권한과 실패 범위는 더 작게 설계해야 한다.

6. Environment Inspection

Agent는 행동하기 전에 현재 환경을 확인해야 한다. Environment Inspection 없이 바로 수정이나 실행을 시작하면 존재하지 않는 File을 가정하거나, 이미 완료된 작업을 반복하거나, Project 규칙을 어길 수 있다.

Goal 수신
  ↓
Environment Inspection
├─ 사용 가능한 Tool 확인
├─ File과 Directory 구조 확인
├─ 현재 Git·Application 상태 확인
├─ 기존 설정과 규칙 확인
└─ 이전 작업 결과 확인
  ↓
Plan 수립 및 Action 실행

Coding Agent라면 다음과 같은 정보를 먼저 확인할 수 있다.

• 현재 Working Directory와 Repository 구조
• README, CLAUDE.md, Build 설정
• 관련 Source Code와 Test
• Git Diff와 최근 변경
• 실행 가능한 Test·Build Command
• 현재 Error Log와 재현 방법

Customer Support Agent라면 고객의 계정, 주문 상태, 이전 문의, 적용 가능한 정책을 읽은 뒤 행동해야 한다. 중요한 점은 추측 대신 Tool Result를 통해 Ground Truth를 얻는 것이다.

환경은 Agent가 행동한 뒤에도 바뀐다. 따라서 Agent Loop는 매 Step의 Tool Result를 읽고 현재 상태를 다시 판단해야 한다.

Inspect → Act → Observe → Re-plan → Act → Verify

완료 여부도 Agent의 주장만으로 판단하지 않는 편이 좋다. Test 통과, File 존재, API 응답, 상태 조회처럼 환경에서 얻은 증거로 성공을 검증해야 한다.

7. Workflows vs Agents

Workflow와 Agent의 가장 큰 차이는 Process의 통제권을 누가 가지는가다.

Workflow
→ 개발자가 Code로 Step과 분기를 정의한다.

Agent
→ Claude가 환경을 관찰하고 다음 Step을 동적으로 선택한다.

구분	Workflow	Agent
실행 경로	미리 정의됨	실행 중 동적으로 결정
예측 가능성	높음	상대적으로 낮음
유연성	제한적	높음
Debugging	단계가 고정되어 쉬움	경로가 매번 달라질 수 있음
비용·Latency	비교적 예측 가능	반복 횟수에 따라 증가
적합한 문제	구조화되고 반복 가능한 Task	경로를 미리 알기 어려운 Task

선택 기준을 간단히 정리하면 다음과 같다.

하나의 Prompt로 충분한가?
├─ Yes → Single LLM Call
└─ No
    ↓
Step을 미리 정의할 수 있는가?
├─ Yes → Workflow
│   ├─ 독립적인 Subtask → Parallelization
│   ├─ 순차 의존성 → Chaining
│   └─ 입력별 경로 분리 → Routing
└─ No → Agent 검토

Agent는 필요한 Step 수와 Tool 순서를 사전에 결정하기 어려운 개방형 Task에 적합하다. 여러 File을 탐색해 Bug를 수정하거나 다양한 Source를 조사해 결론을 내리는 작업이 예다.

하지만 자율성에는 비용이 따른다. Agent는 여러 Turn을 반복하므로 비용과 Latency가 커지고, 작은 판단 오류가 다음 Step에서 누적될 수 있다. 다음과 같은 통제 장치가 필요하다.

• 최대 Step과 전체 Timeout
• Token과 비용 Budget
• Tool별 Permission과 Allowlist
• 중요한 Write Action의 Human Approval
• 실패와 반복을 감지하는 중단 조건
• 모든 Prompt, Tool Call과 Result의 Trace
• Sandbox에서의 충분한 Evaluation

Workflow와 Agent를 반드시 하나만 선택할 필요는 없다. 상위 Process는 Routing Workflow로 통제하고, 특정 경로에서만 Agent를 실행하는 Hybrid 구조도 가능하다.

Request
  ↓
Routing Workflow
├─ FAQ → RAG Answer Workflow
├─ Refund → Fixed Approval Workflow
└─ Complex Technical Issue → Diagnostic Agent

가장 자율적인 구조가 가장 좋은 구조는 아니다. 먼저 단일 호출을 최적화하고, 부족하면 Workflow를 추가하고, 고정된 경로로 해결할 수 없을 때 Agent를 선택하는 것이 안전하다.

8. Production Agentic Architecture

Request
  ↓
Authentication / Authorization
  ↓
Router
  ├─ Single Call Handler
  ├─ Chaining Workflow
  ├─ Parallel Workflow
  └─ Agent Runtime
       ├─ Tool Registry
       ├─ Permission Check
       ├─ Environment State
       ├─ Step / Cost Budget
       └─ Human Approval
  ↓
Result Validator
  ↓
Response + Trace

Production에서는 최종 답변만 저장해서는 문제의 원인을 찾기 어렵다. 어떤 Route가 선택됐고, 각 Step에 무엇이 입력됐으며, 어떤 Tool이 호출됐고, 어떤 Result가 다음 판단에 사용됐는지를 추적해야 한다.

주요 Evaluation 항목은 다음과 같다.

• Task Success Rate: Goal을 실제로 완료했는가?
• Route Accuracy: 올바른 Workflow로 전달됐는가?
• Step Efficiency: 불필요한 호출과 반복이 없는가?
• Tool Selection Accuracy: 올바른 Tool과 Argument를 선택했는가?
• Groundedness: 환경의 실제 결과를 근거로 판단했는가?
• Safety: 권한과 승인 경계를 지켰는가?
• Latency / Cost: 품질 향상에 비해 비용이 합리적인가?

9. 전체 정리

AI Workflows
→ 여러 Claude 호출을 미리 정의한 Code Path로 연결한다.

Parallelization Workflows
→ 독립 Subtask를 동시에 처리하거나 여러 결과를 투표한다.

Chaining Workflows
→ 이전 Step의 Output을 다음 Step의 Input으로 전달한다.

Routing Workflows
→ 입력을 분류해 전문 Prompt, Model과 Tool로 보낸다.

Agents and Tools
→ Agent가 Goal과 현재 상태를 바탕으로 다음 Tool을 선택한다.

Environment Inspection
→ 행동 전에 환경을 확인하고 Tool Result로 Ground Truth를 얻는다.

Workflows vs Agents
→ 고정되고 반복 가능한 Task는 Workflow, 경로를 예측하기 어려운 Task는 Agent를 고려한다.

Agentic System의 핵심은 가능한 한 많은 판단을 Model에게 맡기는 것이 아니다. 문제에 필요한 만큼만 자율성을 부여하고, 나머지는 명시적인 Code Path, Validation, Permission과 중단 조건으로 통제하는 것이다.

단일 호출에서 시작해 Evaluation으로 한계를 확인하고, Parallelization·Chaining·Routing을 조합한 뒤, 고정 경로로 해결할 수 없는 문제에만 Agent를 적용하는 순서가 실용적이다.

10. Coursera Module 7 누락 확인

이번 글에 반영한 강의 구성은 다음과 같다.

• 영상 7개: AI Workflows, Parallelization Workflows, Chaining Workflows, Routing Workflows, Agents and Tools, Environment Inspection, Workflows vs Agents
• 읽기 2개: Introduction to the module, Next steps
• 퀴즈 2개: Quiz on workflows, Quiz on agents

이것으로 Coursera Building with the Claude API의 전체 Module 정리를 마친다. API의 기본 호출에서 시작해 Prompt Evaluation, Tool Use, MCP, RAG, Claude Code, Computer Use를 거쳐 마지막으로 Workflow와 Agent까지 연결했다.

참고 자료

• Coursera — Building with the Claude API
• Anthropic — Building effective agents
• Anthropic — Tool use with Claude
• Anthropic — Model Context Protocol