Appearance
에이전트 vs 워크플로우
이 장에서 얻는 것
- Anthropic의 공식 정의 기준으로 workflow와 agent를 구분하는 정확한 어휘
- "이 유스케이스는 에이전트가 필요한가?"를 5분 안에 판정하는 결정 표
- 에러 복합(error compounding) 관점에서 자율성이 왜 공짜가 아닌지에 대한 직관
- 잘못된 선택이 프로덕션에서 어떤 증상으로 나타나는지에 대한 실패 모드 표와, 설계 리뷰에서 쓸 체크리스트
왜 문제가 되는가
플랫폼에 올라오는 "에이전트" 신청서의 상당수는 에이전트가 아니다. 문서를 분류해서 요약하고 티켓을 생성하는 시스템, 고객 질문을 FAQ·환불·에스컬레이션으로 나눠 처리하는 시스템 — 이들은 단계가 사전에 알려져 있고, LLM은 각 단계 안에서 변환기 역할만 한다. 그런데 팀들은 이것을 자율 루프를 도는 에이전트 프레임워크 위에 올리고, 그 결과 플랫폼은 예측 불가능한 토큰 비용, 감사(audit) 불가능한 실행 경로, 재현 불가능한 버그 리포트를 떠안는다.
반대 방향의 실패도 있다. 단계를 미리 열거할 수 없는 문제 — 원인 불명의 장애 조사, 레거시 코드베이스 탐색 — 를 고정 파이프라인으로 강제하면, 분기 케이스가 늘어날 때마다 if가 하나씩 추가되다가 결국 아무도 유지보수할 수 없는 유사-에이전트가 된다.
이 결정은 개별 팀의 취향 문제가 아니라 플랫폼의 문제다. 어느 쪽을 선택하느냐에 따라 비용 모델(고정 vs 개방형), 관측 전략(파이프라인 스텝 메트릭 vs 궤적(trajectory) 평가), 권한 모델(정적 스코프 vs 동적 툴 인가), 그리고 장애 대응 방식이 전부 갈린다. 플랫폼은 이 결정을 각 팀이 일관된 기준으로 내리도록 어휘와 판정 절차를 제공해야 한다.
핵심 개념
Anthropic의 정의
Anthropic은 "Building effective agents"(2024-12-19)에서 두 아키텍처를 이렇게 구분한다(anthropic.com):
Workflows are systems where LLMs and tools are orchestrated through predefined code paths.
Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks.
구분의 축은 LLM 사용 여부도, 툴 호출 여부도 아니다. 제어 흐름(control flow)을 누가 소유하는가다. 워크플로우에서는 코드가 제어 흐름을 소유하고 LLM은 각 노드 안의 변환기다. 에이전트에서는 LLM이 제어 흐름을 소유한다 — 다음에 어떤 툴을 부를지, 언제 끝낼지를 모델이 매 스텝 결정한다.
같은 글의 핵심 권고는 이것이다:
When building applications with LLMs, we recommend finding the simplest solution possible, and only increasing complexity when needed.
즉 기본값은 단일 LLM 호출 + retrieval이고, 그것이 부족할 때 워크플로우로, 워크플로우로도 부족할 때만 에이전트로 올라간다. 에이전트는 상위 티어가 아니라 다른 트레이드오프 지점이다. 원문의 대비를 그대로 옮기면:
Workflows offer predictability and consistency for well-defined tasks, whereas agents are the better option when flexibility and model-driven decision-making are needed at scale.
미정착 영역
"agent"의 정의는 업계 표준이 없다. 이 책은 Anthropic의 정의(제어 흐름의 소유자 기준)를 일관되게 사용하지만, 벤더에 따라 "툴을 호출하는 모든 LLM 앱"이나 "goal + memory + tools를 가진 시스템"을 agent라 부르기도 한다. 외부 문서를 읽을 때는 그 문서가 어느 정의를 쓰는지 먼저 확인하라. 이 정의 차이는 벤치마크 비교("agent framework A가 B보다 빠르다" 류)를 무의미하게 만드는 주범이다.
워크플로우 5패턴 (요약)
Anthropic 원문은 워크플로우를 다섯 가지 패턴으로 정리한다(출처). 이 책에서 상세한 구현과 선택 기준은 오케스트레이션 패턴 챕터가 정본이므로, 여기서는 결정에 필요한 최소한만 요약한다.
| 패턴 | 한 줄 요약 | 제어 흐름의 소유자 |
|---|---|---|
| Prompt chaining | 작업을 고정된 순차 단계로 분해, 단계 사이에 프로그램적 게이트 삽입 가능 | 코드 |
| Routing | 입력을 분류해 특화된 하위 경로로 분기 | 코드 (분류만 LLM) |
| Parallelization | 독립 하위 작업 동시 실행(sectioning) 또는 같은 작업 다중 실행 후 집계(voting) | 코드 |
| Orchestrator-workers | 중앙 LLM이 하위 작업을 동적으로 분해·위임 | 부분적으로 LLM — 에이전트로 가는 경계 지점 |
| Evaluator-optimizer | 생성 LLM과 평가 LLM의 루프 | 코드 (루프 종료 조건은 코드가 소유) |
주목할 점: orchestrator-workers는 하위 작업의 개수와 내용을 LLM이 정하므로 이미 스펙트럼상 에이전트 쪽에 걸쳐 있다. "워크플로우 vs 에이전트"는 이분법이 아니라 LLM에게 위임한 제어 흐름의 양으로 정의되는 연속선이며, 결정 표는 그 연속선 위에서 어디에 설 것인지를 정하는 도구다.
자율성의 비용: 에러 복합
에이전트를 기본값으로 삼지 말아야 하는 정량적 이유가 에러 복합이다. Anthropic 원문도 이를 명시한다:
The autonomous nature of agents means higher costs, and the potential for compounding errors.
직관은 단순하다. 스텝당 성공 확률이 p이고 스텝들이 독립적으로 성패가 갈린다면, n스텝 궤적의 성공 확률은 pn으로 감쇠한다. 예컨대 p = 0.95라도 20스텝이면 0.9520 ≈ 0.36 — 스텝 단위로는 우수해 보이는 시스템이 궤적 단위로는 세 번에 두 번 실패한다. 워크플로우는 스텝 수 n을 코드로 고정하고 각 스텝 사이에 결정론적 검증 게이트를 끼워 넣어 이 감쇠를 끊을 수 있지만, 에이전트는 n 자체가 실행 시점에 결정되므로 감쇠 곡선의 어디에 놓일지 사전에 알 수 없다.
⚠️ 비공식 출처 기반 — 공식 문서 교차확인 필요
pn 모델 자체는 산수이지만, "프로덕션 에이전트의 실측 스텝당 성공률이 얼마인가"에 대한 공개 수치는 대부분 개인 블로그·컨퍼런스 발표 기반이며 워크로드별 편차가 크다. 실제 스텝 간 오류는 독립적이지도 않다(한 스텝의 오염된 출력이 이후 모든 스텝의 컨텍스트에 남는다). 자신의 워크로드에서 측정한 값만 신뢰하라 — 측정 방법론은 Part 3 평가 하니스가 정본이다.
같은 이유로 Anthropic은 에이전트에 대해 sandboxed 환경에서의 광범위한 테스트와 guardrail을 권고한다(출처). 플랫폼 관점에서 이것은 "에이전트 허용 = 궤적 평가 하니스 + 스텝 상한 + 비용 상한 + 툴 인가가 갖춰진 뒤"라는 게이트 조건으로 번역된다.
플랫폼·빌더 관점: 산출물의 종류를 빌더가 결정한다
이 책의 메타 플랫폼에서는 빌더 에이전트가 사용자 요구사항으로부터 새 시스템을 생성한다. 이때 흔한 착각이 "빌더가 에이전트니까 산출물도 에이전트"라는 것이다. 산출물의 아키텍처는 산출물이 풀 문제의 성질이 결정한다 — 빌더가 받은 요구사항이 "매일 아침 리포트를 수집·요약·배포"라면 산출물은 prompt chaining 워크플로우여야 하고, 빌더는 요구사항 대화 단계에서 이를 판별해야 한다. 이 판별 로직(단계 열거 가능성, 감사 요구, 실패 허용도를 묻는 질문 설계)은 Part 11 요구사항 대화에서 다룬다. 이 장의 결정 표는 사람 아키텍트뿐 아니라 빌더 에이전트의 판별 프롬프트에 그대로 들어가는 기준이다.
또 하나의 플랫폼 함의: 워크플로우와 에이전트는 다른 운영 계약을 요구한다. 워크플로우는 스텝별 latency/성공률 메트릭과 재시도 정책으로 충분하지만, 에이전트는 궤적 로깅, 스텝 예산, 그리고 실행 중 툴 목록이 동적으로 바뀔 수 있다는 전제의 인가 모델이 필요하다. 플랫폼이 이 두 계약을 구분해서 제공하지 않으면, 모든 팀이 더 무거운 쪽(에이전트 계약)을 쓰게 되고 단순 워크플로우조차 에이전트의 운영 비용을 낸다.
결정 표
| 상황 | 선택 | 이유 | 트레이드오프 |
|---|---|---|---|
| 단계를 사전에 열거할 수 있고, 케이스 분기가 유한하다 (문서 파이프라인, 정형 리포트 생성) | 워크플로우 (prompt chaining / routing) | 예측 가능성·일관성이 그대로 확보되고, 스텝 사이 검증 게이트로 에러 복합을 차단 | 새 케이스가 나타날 때마다 코드 수정 필요 |
| 규제 산업·감사 요구가 강하다 (금융 거래 처리, 의료 기록) | 워크플로우 | 실행 경로가 결정론적이어야 감사 추적과 사후 재현이 가능 | 유연성 포기 — 예외 케이스는 사람에게 에스컬레이션 |
| 하위 작업이 독립적이고 지연이 중요하다 | 워크플로우 (parallelization) | 코드 레벨 동시 실행이 에이전트의 순차 루프보다 빠르고 저렴 | 하위 작업 간 의존성이 생기면 재설계 |
| 출력 품질 기준은 명확한데 한 번에 달성이 안 된다 | 워크플로우 (evaluator-optimizer) | 루프 종료 조건을 코드가 소유해 비용 상한이 유지됨 | 평가 기준을 프롬프트로 명문화할 수 있어야 함 |
| 필요한 스텝 수·종류를 입력을 보기 전에 알 수 없다 (장애 원인 조사, 코드베이스 탐색·수정) | 에이전트 | 고정 경로로는 케이스 폭발 — 유연성과 모델 주도 결정이 요구사항 자체 | 비용 개방형, p^n 감쇠, 궤적 평가·guardrail 필수 |
| 열린 탐색이고 중간 결과가 다음 행동을 결정한다 (리서치, 멀티소스 교차 검증) | 에이전트 (필요시 orchestrator-workers부터) | 탐색 폭·깊이를 실행 시점에 조정해야 함 | 관측·재현이 어려움 — 궤적 로깅 없이는 디버깅 불가 |
| 에이전트가 필요해 보이지만 궤적 평가 하니스가 아직 없다 | 워크플로우로 시작 | 측정 없는 자율성은 회귀를 감지할 수 없음 | 초기 커버리지 손실 — 에스컬레이션 경로로 보완 |
| 애매하다 | 워크플로우 | "simplest solution possible" 원칙 — 복잡성은 필요가 증명된 뒤에만 추가 | 나중에 승격 비용 발생 (승격 기준을 SLI로 정의해 두면 완화) |
실패 모드
| 증상 | 근본 원인 | 확인 방법 | 해결 |
|---|---|---|---|
| 같은 입력인데 실행마다 결과·비용이 크게 다르다 | 워크플로우로 충분한 작업을 에이전트로 구현 — 제어 흐름이 불필요하게 LLM에 위임됨 | 궤적 로그에서 툴 호출 시퀀스의 분산 확인: 시퀀스가 사실상 매번 동일하면 그 경로는 고정 가능 | 지배적 궤적을 코드로 고정(워크플로우로 강등)하고 잔여 케이스만 에스컬레이션 |
| 멀티스텝 작업 성공률이 스텝별 평가 점수로는 설명이 안 되게 낮다 | 에러 복합 — 스텝 단위 평가만 하고 궤적 단위 평가가 없음 | 스텝 성공률 p와 평균 스텝 수 n으로 p^n을 계산해 실측 궤적 성공률과 대조 | 스텝 수 축소(툴 통합, 스텝 사이 결정론적 검증 게이트), 궤적 평가 도입 |
if/분기 케이스가 계속 늘어나는 파이프라인, 스프린트마다 분기 추가 PR | 에이전트가 필요한 열린 문제를 워크플로우로 강제 | 최근 N개월 분기 추가 커밋 빈도와 분기당 트래픽 커버리지 확인 — long tail이면 열거 불가능한 문제 | 해당 구간만 에이전트(또는 orchestrator-workers)로 승격, 나머지 경로는 유지 |
| 에이전트가 종료하지 않고 툴 호출을 반복하다 비용 상한/타임아웃에 걸림 | 종료 조건을 모델 판단에만 의존, 스텝 예산 부재 | 궤적에서 동일 툴+유사 인자 반복 호출 패턴 탐지 | 스텝 상한·루프 감지·예산 캡을 플랫폼 레벨 guardrail로 강제 (팀 재량에 맡기지 않음) |
| 감사 요청에 "왜 이 결정이 났는가"를 재현하지 못함 | 결정론이 필요한 도메인에 에이전트 투입, 궤적 보존 부재 | 임의 과거 실행 1건을 골라 실행 경로를 문서로 재구성해 보기 | 규제 대상 경로는 워크플로우로 재설계, 에이전트가 불가피하면 전체 궤적(프롬프트·툴 IO 포함) 보존 |
| 빌더 에이전트가 모든 요구사항을 에이전트 산출물로 생성 | 빌더의 요구사항 대화에 아키텍처 판별 단계가 없음 | 빌더 산출물 중 워크플로우 비율 확인 — 0%에 가깝다면 판별 로직 부재 | 요구사항 대화에 이 장의 결정 표를 판별 기준으로 주입 |
안티패턴
- ❌ "일단 에이전트 프레임워크로 시작" — 프레임워크가 결정을 대신해 주지 않는다 → ✅ 단일 LLM 호출 → 워크플로우 → 에이전트 순으로, 각 단계의 부족함이 측정으로 증명될 때만 승격
- ❌ 에이전트로 만든 뒤 프롬프트에 "반드시 A → B → C 순서로 하라"를 적어 순서를 강제 → ✅ 순서를 알고 있다면 그것은 워크플로우다 — 순서를 코드로 옮기고 LLM은 각 스텝 안으로
- ❌ 워크플로우의 분기 폭발을 분기 추가로 계속 대응 → ✅ 분기 커버리지의 long tail을 측정하고, 열거 불가능이 확인된 구간만 에이전트로 승격
- ❌ 스텝 단위 평가 점수만 보고 배포 ("각 툴 호출 정확도 95%") → ✅ 궤적 단위 성공률을 별도 SLI로 계측 — p^n 때문에 둘은 전혀 다른 숫자다
- ❌ 에이전트와 워크플로우에 동일한 운영 계약(메트릭·권한·비용 통제) 적용 → ✅ 플랫폼이 두 계약을 분리 제공: 워크플로우는 스텝 메트릭+정적 스코프, 에이전트는 궤적 로깅+스텝/비용 예산+동적 툴 인가
- ❌ "에이전트가 더 지능적이니 품질도 더 좋다"는 가정 → ✅ 잘 정의된 작업에서는 워크플로우가 예측 가능성과 일관성에서 우위라는 것이 원문의 명시적 결론
계측 (SLI)
어느 쪽을 선택했든, 선택이 옳았는지를 사후 검증하는 지표를 처음부터 계측한다.
- 궤적 성공률 (에이전트): 최종 목표 달성 기준의 end-to-end 성공률. 스텝 성공률과 별도로 계측 — 이 둘의 괴리가 에러 복합의 크기다. 정의와 측정 하니스는 Part 3 참조.
- 궤적 분산 (에이전트): 동일·유사 입력에 대한 툴 호출 시퀀스의 편차와 스텝 수 분포(p50/p95). 분산이 0에 수렴하는 경로는 워크플로우 강등 후보라는 신호.
- 스텝 예산 소진율 (에이전트): 스텝 상한·비용 캡에 걸려 강제 종료된 실행 비율. 높으면 종료 조건 설계 결함 또는 작업-아키텍처 불일치.
- 분기 커버리지와 에스컬레이션율 (워크플로우): 기존 분기가 처리하지 못해 사람 또는 fallback으로 넘어간 요청 비율. 지속 상승하면 에이전트 승격 검토 트리거.
- 분기 추가 속도 (워크플로우): 단위 기간당 라우팅 분기·예외 처리 추가 건수. 코드 리뷰 부하로 나타나는 "열거 불가능성"의 조기 신호.
- 실행당 비용 분포 (공통): 워크플로우는 좁은 분포가 정상이고 분포가 벌어지면 회귀. 에이전트는 p95/p50 비율 자체를 SLO로 관리.
이 지표들은 승격/강등 결정을 데이터로 내리게 해 준다: 에스컬레이션율이 임계치를 넘으면 워크플로우 → 에이전트 승격을 검토하고, 궤적 분산이 임계치 아래로 떨어지면 에이전트 → 워크플로우 강등을 검토한다.
체크리스트
설계 리뷰(사람이든 빌더 에이전트든)에서 다음을 확인한다.
- [ ] 이 작업의 단계를 입력을 보기 전에 열거할 수 있는가? 열거 가능하면 워크플로우가 기본값이다.
- [ ] 단일 LLM 호출 + retrieval로 부족하다는 근거(측정 또는 구체적 반례)가 있는가?
- [ ] 감사·재현 요구가 있는 경로에 에이전트를 넣고 있지 않은가?
- [ ] 에이전트를 선택했다면: 스텝 상한, 실행당 비용 캡, 루프 감지가 플랫폼 레벨에서 강제되는가?
- [ ] 에이전트를 선택했다면: 배포 전 궤적 단위 평가 하니스(Part 3)가 존재하는가?
- [ ] 스텝 성공률만이 아니라 궤적 성공률을 SLI로 계측하는가?
- [ ] 워크플로우를 선택했다면: 에스컬레이션율·분기 추가 속도를 계측해 에이전트 승격 트리거를 정의했는가?
- [ ] 워크플로우 상세 패턴 선택은 오케스트레이션 패턴의 기준을 따랐는가?
- [ ] 빌더 에이전트 경유 생성이라면: 요구사항 대화에서 아키텍처 판별 질문이 실행되었는가?
- [ ] 6개월 뒤 이 결정을 뒤집을 때(승격/강등)의 마이그레이션 경로를 한 문단이라도 적어 두었는가?
참고
- Anthropic, "Building effective agents" (2024-12-19) — workflow/agent 정의, 5개 워크플로우 패턴, 단순성 원칙의 원문: https://www.anthropic.com/engineering/building-effective-agents
- 이 책 내 관련 챕터: 오케스트레이션 패턴 (워크플로우 패턴 상세), 단일 vs 멀티 에이전트 (에이전트로 결정한 뒤의 다음 분기), 평가 하니스 (궤적 평가와 에러 복합 실측), 요구사항 대화 (빌더 에이전트의 아키텍처 판별)