AI workflow vs agent

"에이전트"라는 이름은 Anthropic의 정의에서부터 두 가지를 동시에 가리킨다.^[1] 이 페이지는 그 두 가지를 가르는 기준이 자율성의 유무가 아니라 control이 어디 있는지라는 점을 정리한다.

Workflow와 agent를 가르는 기준

• Agent Patterns 노트는 Anthropic이 다음 두 가지를 모두 "agentic system"으로 분류한다고 기록한다.^[1:1]
  • 장기간에 걸쳐 독립적으로 작동하며 다양한 tool로 복잡한 작업을 수행하는 완전 자율 system.
  • 미리 정해진 workflow에 따라 작동하는 system.
• 이 노트는 workflow를 LLM과 여러 tool이 미리 정해진 code path에 따라 작동하는 system으로, agent를 LLM이 자신의 작업 과정과 tool 사용 방식을 동적으로 제어하는 system으로 구분한다.^[1:2]
• 노트 작성자는 "정해진 워크플로우, 즉 바운더리를 정해놓고 그 범위 내에서 자율적으로 수행하는 것"이라는 자기 해석을 남겼다.^[1:3] 이는 원 source의 재인용이 아니라 노트 작성자 본인의 정리다.

이 예측 가능성·위험 열은 source가 명시하지 않은, control path 구분에서 따라오는 해석이라고 본다.

Spectrum으로 보는 편이 나은 이유

Source가 두 정의를 모두 "agent system"으로 인정한다는 사실 자체가, workflow와 agent를 상호 배타적인 두 범주로 나누기보다 spectrum으로 다루는 편이 낫다는 근거로 읽힌다. 실용적 agent system은 완전 자율과 완전 고정 workflow 사이 어딘가에 있고, 설계는 자율성을 무한히 늘리는 것이 아니라 task risk와 반복성에 맞게 control boundary를 정하는 일에 가깝다.

Fixed script -> AI workflow -> bounded agent -> highly autonomous agent

선택 기준과 혼동 포인트

• 절차가 명확하고 실패 비용이 크면 workflow 쪽으로 둔다.
• 중간 상태를 보고 다음 행동을 골라야 하면 agent 쪽으로 둔다.
• Tool 사용은 필요하지만 범위를 통제해야 하면 bounded agent로 설계한다.
• 반복성과 예측 가능성이 중요하면 dynamic control을 줄인다.
• Tool을 쓴다고 항상 agent는 아니다 — source가 정해진 workflow도 agent system으로 인정하는 것과는 별개로, tool 사용 여부만으로 agent 여부를 판단하면 안 된다.
• 완전 자율이어야만 agent라는 뜻도 아니다.
• Workflow와 agent를 이름으로만 나누면 실제 설계 기준을 놓친다. 핵심은 control boundary다.

경계 사례: LLM이 분류하고 코드가 분기하는 챗봇

판정 기준은 source의 정의(미리 정해진 code path인가, LLM이 과정과 tool 사용을 동적으로 제어하는가)를 따른다.^[1:4] 아래 챗봇 예시와 위험 서술은 source가 직접 다루지 않는 Wiki 해석이다.

• LLM이 고객 문의를 "환불 / 배송 / 기타"로 분류하고, 코드가 그 결과로 정해진 API를 호출한 뒤 LLM이 답변을 다듬는 챗봇은 workflow다. LLM이 판단을 하고 tool도 쓰이지만, 그 판단이 들어갈 자리와 이후 경로를 code가 미리 정했기 때문이다.
• 이 챗봇은 환불 API 결과가 애매해도 스스로 배송 조회를 추가로 하지 못한다. 그런 분기는 code에 적혀 있을 때만 일어난다.
• Agent로 바꾸려면 code의 분기 대신 LLM에게 tool을 주고, tool 결과를 다시 LLM에게 돌려 다음 행동과 종료 시점을 LLM이 정하게 해야 한다. 이 반복 구조는 ReAct의 Thought-Action-Observation loop로 설명된다.
• 그 대가로 유연성은 커지지만, 환불처럼 되돌릴 수 없는 tool의 오호출, 끝나지 않는 반복, 비용과 지연 증가, 같은 입력에도 경로가 달라지는 테스트 어려움이 생긴다. 위 표의 "주요 위험" 열과 같은 맥락이다.

경계를 잘못 그었을 때 생기는 문제

• 단순 workflow를 agent라고 부르며 불필요한 자율성을 추가하는 경우.
• 탐색이 필요한 task를 rigid workflow로 묶어 예외 처리를 못 하는 경우.
• Bounded agent가 필요한데 control boundary 없이 tool을 열어두는 경우.
• Agent 평가 없이 "동적 제어"를 품질 향상으로 가정하는 경우.

관련

• AI Agent: workflow와 agent의 경계를 반영해 agent 정의를 조정한다.
• AI Agent Architecture: control boundary와 orchestration layer 설계에 직접 연결된다.
• AI agent interaction design: prompt, tool, observation뿐 아니라 control boundary도 interaction stack의 일부다.

출처

테스트 질문

• AI workflow와 AI agent의 핵심 차이는 무엇인가?
• Tool을 쓰는 정해진 workflow는 agent인가?
• LLM이 문의를 분류하고 code가 분류별 API를 호출하는 챗봇은 workflow인가, agent인가?
• 언제 dynamic agent보다 workflow가 더 적합한가?