AI 연재 4/9 — 워크플로우로 충분한데 에이전트를 쓰고 있지는 않은가
"에이전트"라는 말이 너무 넓게 쓰인다. 도구 하나 붙인 챗봇도, 몇 시간씩 코드를 고치는 시스템도 에이전트라고 부른다. 설계 얘기를 하려면 이 단어부터 좁혀야 한다.
정의부터: 코드가 경로를 정하는가, 모델이 정하는가
Anthropic의 "Building effective agents"(2024-12)가 내린 구분이 가장 쓸모 있었다.
- 워크플로우: LLM과 도구가 미리 정해진 코드 경로를 따라 오케스트레이션되는 시스템
- 에이전트: LLM이 스스로 프로세스와 도구 사용을 지휘하는 시스템
차이는 "누가 다음 단계를 결정하는가"다. 1~3편에서 만든 보상 신청 파이프라인(추출 → 분류 → 판단 → 후처리)은 순서가 코드에 박혀 있으니 워크플로우다. 이건 약점이 아니라 장점이다. 예측 가능하고 평가하기 쉽고 비용이 정해져 있다.
이 글이 반복해서 하는 말은 단순함이다. 성공은 가장 정교한 시스템이 아니라 필요에 맞는 올바른 시스템을 만드는 데 달려 있다고 한다. 에이전트는 지연과 비용을 대가로 유연성을 사는 거래이고, 더 단순한 방법으로 해결되면 그걸 쓰라는 입장이다.
워크플로우 패턴 다섯 개
이 글이 정리한 패턴을 보상 신청 예시에 하나씩 대 본다. 예시 매핑은 내가 붙인 것이다.
Prompt chaining. 작업을 순차 단계로 나누고 단계 사이에 검증 게이트를 둔다. 서류 추출 → 필드 검증 → 판단 같은 구조. 하위 작업이 깔끔하게 나뉠 때 이상적이라고 한다.
Routing. 입력을 분류해서 전문 경로로 보낸다. 신청 유형(상해, 도난, 지연 등 무엇이든)에 따라 다른 프롬프트와 기준을 쓰고, 쉬운 건 작은 모델로 보내는 식이다.
Parallelization. 독립적인 하위 작업을 동시에 돌리거나(sectioning), 같은 작업을 여러 번 돌려 투표한다(voting). 3편에서 말한 일치도 신호가 이 voting이다.
Orchestrator-workers. 중앙 LLM이 작업을 동적으로 쪼개 하위 모델에 위임한다. 하위 작업을 미리 알 수 없을 때 쓴다.
Evaluator-optimizer. 한 모델이 생성하고 다른 모델이 평가하며 피드백을 주고받는다. 명확한 평가 기준이 있고 반복이 실제로 개선을 만들 때 의미가 있다. 고객 안내문 문구 다듬기 같은 곳에 어울린다.
앞의 셋은 순서가 코드에 정해져 있고, 뒤의 둘로 갈수록 모델 판단의 비중이 커진다. 에이전트는 이 스펙트럼의 끝에 있다.
에이전트는 언제 필요한가
같은 글은 에이전트가 환경에서 매 단계 "ground truth"(도구 실행 결과 같은 실제 피드백)를 얻으며 진행한다고 설명한다. 그리고 단계 수를 예측하기 어렵고 경로를 하드코딩할 수 없는 열린 문제에 적합하다고 한다. 반대로 오류가 누적될 수 있어서 샌드박스 테스트와 가드레일이 필요하다고 경고한다.
여기서 판단 기준을 도출해 보면 이렇다. 이건 원문 문구가 아니라 내 정리다.
- 경로를 미리 적을 수 있다 → 워크플로우
- 경로가 입력마다 크게 달라지고 중간 결과에 따라 계획이 바뀐다 → 에이전트 후보
- 실패 비용이 크고 재현·감사가 중요하다 → 에이전트의 자유도를 제한하거나 워크플로우 안에 가둔다
보상 신청 파이프라인 대부분은 워크플로우로 충분하다. 에이전트가 필요해 보이는 지점은 예를 들어 "서류가 모호할 때 추가로 무엇을 요청할지 스스로 판단하며 대화하는" 부분 정도다. 그 부분만 에이전트로 만들고 나머지는 코드가 흐름을 쥐는 하이브리드가 현실적이라고 본다. LangGraph 문서도 결정적 단계와 에이전트 단계를 섞는 설계를 염두에 둔 설명을 한다(PyPI 페이지의 설명 기준).
ReAct: 에이전트 루프의 뿌리
에이전트의 기본 루프(생각 → 행동 → 관찰 → 반복)는 Yao 등의 ReAct(2022, arXiv 2210.03629)가 대표적 원형이다. 초록 기준으로 추론과 행동을 교차시키는 방식을 제안하고, ALFWorld에서 모방학습·강화학습 대비 절대 성공률 34%p, WebShop에서 10%p 개선, HotpotQA와 FEVER에서는 위키 API를 써서 환각을 줄였다고 보고한다. 2022년 논문이라 오늘의 모델에서 이 수치가 그대로 유지된다고 말할 수는 없다. 구조를 이해하는 용도로 읽는 게 맞다.
도구 인터페이스에도 설계를 쏟는다
Anthropic은 에이전트가 쓰는 도구 인터페이스(ACI)에 인간용 인터페이스(HCI)만큼 공을 들이라고 한다. 파라미터에 설명과 예시를 넣고, 모델이 문자열 이스케이프 같은 형식 부담을 지지 않게 하고, 오용하기 어렵게 만들라는 것이다. 이 주제는 6편에서 더 본다.
그리고 프레임워크에 대한 권고가 인상적이었다. 처음엔 LLM API를 직접 써 보라는 것이다. 프레임워크가 내부 동작을 가려서 생기는 오해가 흔한 실수의 원인이라는 이유다. 나도 이 점에는 동의하는 편인데, 의견이 갈릴 수 있다. 상태 저장이나 중단·재개를 직접 만들기는 꽤 번거로워서 6편에서 다룰 LangGraph 같은 도구가 가치를 갖는 지점이 분명 있다.
흔한 실패
- 처음부터 에이전트로 만든다. 디버깅과 비용 예측이 어려워진다.
- 프레임워크를 얹고 나서 내부에서 무슨 일이 일어나는지 모른다.
- 도구 설명이 부실한데 모델 성능 탓을 한다.
- 단계마다 평가 없이 "에이전트가 알아서 하겠지" 한다.
다음 편에서는 워크플로우든 에이전트든 거의 모든 서비스에 등장하는 구성 요소, RAG를 뜯어본다.
연재 목차: 3편 · 4편(현재) · 5편 RAG 파이프라인
참고자료
- Anthropic, Building effective agents (2024-12)
- Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models (2022)
- LangGraph, PyPI 프로젝트 페이지