워크플로우인가 에이전트인가: 다음에 무엇을 실행할지 결정하는 것은 누가 결정하는가

팀에서 느리거나, 비용이 많이 들거나, 예측 불가능한 AI 기능을 보여줄 때, 원인은 거의 모델에 있지 않습니다. 그 원인은 첫 시간에 내려지고 다시는 재검토되지 않는 결정, 즉 워크플로우(workflow)를 사용할지 에이전트(agent)를 사용할지, 그리고 에이전트를 사용한다면 몇 개를 사용할지에 달려 있습니다.

다음에 무엇을 실행할지, 당신의 코드(code)가 결정하는지 아니면 모델(model)이 결정하는지가 시스템의 비용, 실패 방식, 디버깅 방식을 결정합니다. 이것이 이 글의 핵심 주장이며, 그 증거는 생계를 위해 에이전트를 구축하는 팀들로부터 나옵니다.

만약 당신의 코드가 결정한다면, 그것은 워크플로우입니다. 모델이 결정한다면, 그것은 에이전트입니다. 만약 하나의 모델이 다른 모델들에게 작업을 넘겨준다면, 그것은 다중 에이전트 시스템(multi-agent system)입니다. 각각은 다른 청구서, 다른 종류의 실패, 그리고 다른 디버깅 방식을 의미합니다.

우리가 아는 방법

우리는 생계를 위해 에이전트를 구축하는 팀들, Anthropic, Cognition, Sierra의 주요 기술 보고서를 읽고, 다중 에이전트 실패에 대한 동료 검토 논문(peer-reviewed study)을 참고했으며, 출처가 명시한 문장 속 모든 수치를 인용했습니다.

기본값으로 워크플로우를 사용하고 에이전트에게 자리를 얻게 하라

Anthropic은 두 문장으로 그 경계를 긋습니다. 워크플로우는 모델과 도구(tools)가 미리 정의된 코드 경로를 통해 오케스트레이션되는 시스템입니다 []. 에이전트는 모델이 자체 프로세스와 도구 사용을 지시하는 시스템입니다 []. 이 경계는 모델이 얼마나 똑똑한지에 관한 것이 아니라, 누가 운전대를 잡고 있느냐에 관한 것입니다.

워크플로우로 처리된 지원 티켓(support ticket)

티켓 분류: 하나의 모델 호출이 이를 청구(billing), 버그(bug) 또는 계정(account)으로 라벨링합니다.
라벨별 경로 지정: 단순한 스위치(switch)가 다음 단계를 선택하며, 모델이 결정하지 않습니다.
답변 초안 작성: 하나의 모델 호출이 계정의 기록을 바탕으로 내용을 작성합니다.
승인 및 전송: 사람이 검토한 후에 내용이 외부로 나갑니다.

그 트랙의 모든 화살표는 당신이 작성한 코드입니다. 단위 테스트를 할 수 있고, 단일 단계를 재시도할 수 있으며, 감사관에게 잘못된 답변을 설명할 수 있습니다. 모델은 두 상자 안에서 실제 작업을 수행하지만, 다음에 어떤 상자가 올지 결정하지는 않습니다.

Anthropic의 조언은 가능한 가장 간단한 솔루션을 찾고 필요할 때만 복잡성을 높이는 것입니다 [[1]]. 그들은 고객 작업에서 얻은 관찰 결과, 가장 성공적인 구현 사례는 복잡한 프레임워크보다는 간단하고 조합 가능한 패턴을 사용한다는 것입니다 [[1]]. 루프를 숨기는 프레임워크는 모델에게 의도하지 않은 결정을 내리도록 쉽게 만들 수 있습니다.

대부분의 비즈니스 자동화가 여기에 속합니다: 청구서 분류, 티켓 요약, 승인을 위한 답변 초안 작성, 리드 정보 보강. 경로는 요청이 도착하기 전에 이미 알려져 있으므로, 모델이 단계 순서에 대해 결정할 것이 아무것도 없습니다. 단계 내부에서 판단을 부여하고, 순서는 코드에 유지하세요.

모델에게 위임하는 모든 결정은 토큰으로 비용이 청구됩니다

Anthropic은 자체 연구 기능이 얼마나 많은 토큰을 사용하는지 측정했습니다. 에이전트는 일반적으로 채팅보다 약 4배 더 많은 토큰을 사용하며, 멀티에이전트 시스템은 약 15배 더 많이 사용합니다 [[2]]. 추가적인 결정 하나하나가 지금까지의 컨텍스트를 다시 읽는 또 다른 호출을 의미합니다.

채팅 교환과 비교한 토큰 사용량 [[2]]

채팅 교환: 기준선(baseline)
단일 에이전트: 4배
멀티에이전트 시스템: 15배

그 지출은 무언가를 구매합니다. 같은 연구에서 토큰 사용량 자체가 시스템 성능의 분산(variance) 중 80%를 설명했습니다 [[2]]. 더 많은 토큰은 더 많은 검색과 더 나은 답변을 의미했으며, 이는 폭넓음 자체가 핵심인 연구 작업에서 그러했습니다.

거래는 명확하게 제시됩니다: 에이전트 시스템은 종종 더 나은 작업 성능을 위해 지연 시간(latency)과 비용(cost)을 거래하며, 이러한 상충 관계가 언제 의미가 되는지 고려해야 합니다 []1. 하루에 만 번 실행되는 티켓 라우터의 경우, 이는 거의 그렇지 않습니다. 분석가가 한 번 묻는 연구 질문의 경우에는 종종 그렇습니다.

따라서 구축하기 전에 요청당 가격을 책정하십시오. 성공적인 경로(happy path)에서 모델 호출 횟수를 계산하고, 각 호출이 담고 있는 컨텍스트를 곱한 다음, 이를 해당 작업의 가치와 비교하십시오. 이 수치를 적어낼 수 없다면, 아키텍처를 선택할 준비가 되지 않은 것입니다.

한 번 성공하는 에이전트는 두 번도 성공할 것이라는 것을 보여주지 못한다

Sierra는 시뮬레이션된 고객, 실제 도구(tool), 그리고 실제 정책을 사용하여 지원 대화에 대한 벤치마크를 구축했습니다. 그들이 테스트한 12개의 모든 에이전트가 어려움을 겪었으며, 심지어 가장 좋은 에이전트조차도 평균 성공률 50% 미만에 머물렀습니다 []3. 이것들은 장난감 같은 작업이 아니었습니다. 그것들은 지원팀이 매일 처리하는 반품 및 예약 변경 사항들이었습니다.

60% 감소: 동일한 리테일 작업이 한 번이 아닌 여덟 번 시도해야 했을 때 가장 좋은 에이전트의 점수가 하락했습니다 []3

그 감소폭이 걱정해야 할 수치입니다. 동일한 리테일 작업이 여덟 번 모두 성공해야 했을 때는 가장 좋은 에이전트가 약 25%까지 떨어졌습니다 []3. 월요일에 작동하는 워크플로우는 화요일에도 작동합니다. 월요일에 작동하는 에이전트는 한 번의 도박을 던진 것일 뿐입니다.

Sierra에서, 실제 사용자 대면형 대화 에이전트를 구현한 경험은 한 가지를 극도로 명확하게 만들었습니다: 에이전트 성능과 신뢰성에 대한 강력한 측정(measurement)이 성공적인 배포에 매우 중요합니다.

Karthik Narasimhan, 연구 책임자, Sierra []3

오류는 또한 누적됩니다. Anthropic은 기존 소프트웨어의 사소한 문제조차 에이전트를 완전히 망칠 수 있다고 지적합니다. 왜냐하면 각 단계가 이전 단계가 남긴 상태를 기반으로 구축되기 때문입니다 [[⁾₌]] (https://www.anthropic.com/engineering/multi-agent-research-system). 실행 초기에 잘못된 도구 결과 하나가 그 이후의 모든 것의 전제가 되어버립니다.

해결책은 더 나은 프롬프트가 아닙니다. 그것은 습관입니다: 첫날부터 모든 추적 기록을 남기고, 그것들을 읽고, 실제 실패를 테스트 케이스로 전환하는 것입니다. 언어 모델 기반 제품 출시를 도운 많은 팀들에게 Hamel Husain은 실패의 원인을 망설임 없이 지목합니다 [[⁾₌]] (https://hamel.dev/blog/posts/evals/).

저는 성공하지 못한 제품들이 거의 항상 공통된 근본 원인을 공유한다는 것을 발견했습니다: 견고한 평가 시스템을 구축하는 데 실패했다는 것입니다.

Hamel Husain, AI 컨설턴트 및 교육자, Parlance Labs [[⁾₌]] (https://hamel.dev/blog/posts/evals/)

두 번째 에이전트는 작업이 깔끔하게 분할될 때만 스스로를 증명한다

다중 에이전트 시스템은 적절한 조건 하에서 승리합니다. Anthropic의 다중 에이전트 설정은 자체 내부 연구 평가(internal research eval)에서 단일 에이전트보다 90.2% 더 나은 성능을 보였습니다 [[⁾₌]] (https://www.anthropic.com/engineering/multi-agent-research-system). 연구는 잘 분할됩니다: 여러 독립적인 검색들이 각각 요약된 짧은 내용을 주 에이전트에게 반환합니다.

90.2% 더 나은 성능으로, 서브에이전트들이 병렬로 검색하는 Anthropic의 내부 연구 평가에서 단일 에이전트보다 우수했습니다. [[⁾₌]] (https://www.anthropic.com/engineering/multi-agent-research-system)

같은 팀은 어느 부분에서 성능이 떨어지는지 명확합니다. 모든 에이전트가 동일한 컨텍스트를 공유해야 하거나, 에이전트 간에 많은 의존성이 관련된 도메인은 현재로서는 적합하지 않습니다 [[⁾₌]] (https://www.anthropic.com/engineering/multi-agent-research-system). 대부분의 코딩 작업은 연구보다 진정으로 병렬적인 부분이 더 적습니다 [[⁾₌]] (https://www.anthropic.com/engineering/multi-agent-research-system)

코그니션(Cognition)을 구축하는 코딩 에이전트 역시 다른 관점에서 같은 결론에 도달했습니다. 그 원칙은 행동에는 암묵적인 결정이 포함되며, 상충되는 결정은 나쁜 결과를 초래한다는 것입니다 []5. 결정을 일관되게 유지하는 가장 간단한 방법은 컨텍스트가 연속적인 단일 스레드 에이전트(single-threaded agent)를 사용하는 것입니다 []5.

저는 에이전트들이 서로 협업할 수 있는 장기적인 가능성에 대해 낙관적이지만, 2025년에는 여러 에이전트를 협력하여 실행하는 것이 취약한 시스템만을 초래한다는 것은 분명합니다.

Walden Yan, Co-founder, Cognition []5

버클리(Berkeley) 출신 팀은 7개의 멀티 에이전트 프레임워크에 걸쳐 1600개 이상의 트레이스(traces)를 주석 처리했으며 []6, 이들이 실패하는 14가지 고유한 방식을 발견했습니다 []6. 그들의 요약은 직설적입니다: 열광에도 불구하고, 인기 있는 벤치마크에서의 이득은 종종 미미합니다 []6.

에이전트를 추가하기 전에 유용한 테스트가 있습니다: 각 에이전트가 무엇을 소유하고, 무엇을 반환하며, 무엇을 절대 볼 수 없는지 적어보세요. 만약 이것을 할 수 없다면, 당신은 추가 단계와 더 큰 비용이 드는 단일 에이전트를 가진 것입니다.

제어(Control)가 설계 결정이며, 모델은 세부 사항이다

이 자료들 중 어느 것도 어떤 모델을 사용할지에 대해서는 논쟁하지 않습니다. 그들은 '제어'에 대해 논쟁합니다. Anthropic은 필요한 단계의 수를 예측하기 어렵거나 불가능하고, 고정된 경로를 하드코딩할 수 없는 개방형 문제(open-ended problems)에 에이전트를 보류하며 []1, 다음과 같은 테스트를 수행할 수 있습니다: 단계를 나열해 보세요. 만약 그것들을 그릴 수 있다면, 코드로 작성하고 상자 안에서 모델을 호출하세요. 그렇지 못하다면, 모델에게 핸들을 넘겨주고 트레이스(traces), 평가(evals) 비용과 돈을 보내거나, 지불하거나, 삭제하는 모든 것을 승인하는 사람의 비용을 지불하세요.

제가 보는 팀들은 보통 이 순서를 거꾸로 합니다. 좋은 엔지니어링처럼 보여서 에이전트(agent) 팀으로 시작한 다음, 핸드오프(handoff)를 디버깅하는 데 한 달을 보냅니다. 워크플로우(workflow)부터 시작해서 측정하고, 증거가 쌓일 때마다 결정 하나씩을 에이전트로 승격시키세요.

월요일에 할 일

누가 결정하는지 기록하기: 다음 AI 기능에 대해 단계별로 한 줄씩 작성하며, 코드가 실행할 다음 내용을 코드(code), 모델(model), 또는 슈퍼바이저 모델(supervisor model) 중 누가 선택하는지 적으세요.
먼저 워크플로우 구축하기: 코드가 순서를 담당하는 버전으로 배포하고, 실제 사례에서 고정된 경로가 처리할 수 없다는 것이 확실해질 때만 결정을 모델로 옮기세요.
요청 가격 책정하기: 빌드하기 전에 실행당 필요한 모델 호출(model calls)과 컨텍스트(context)를 추정하고, 실제 트래픽에서 측정하여 비교하세요.
동일한 작업 재실행하기: 각 테스트 케이스를 여러 번 실행하고, 한 번이 아니라 모든 실행에서 성공하는 빈도를 세세요.
사람을 보내는 것 유지하기: 무언가를 전송(sends), 결제하거나 삭제하는 것은 항상 인간의 승인을 기다리게 하고, 그 앞에 단계들을 결정하는 주체를 두세요.

랩에서 구축하세요

지금 만들고 있는 기능에 대해 다음으로 무엇이 실행될지 누가 결정하나요? 코드인가요 아니면 모델인가요?

출처

Anthropic, Building effective agents (2024)
Anthropic, How we built our multi-agent research system (2025)
Sierra, τ-Bench: Benchmarking AI agents for the real-world (2024)
Hamel Husain, Your AI Product Needs Evals (2024)
Cognition, Don’t Build Multi-Agents (2025)
Cemri et al., Why Do Multi-Agent LLM Systems Fail? (2025)