agentic workflow는 LLM이 응답 한 번으로 끝나지 않고, 여러 단계를 거치며 스스로 판단해 작업을 끝내도록 짠 시스템 패턴이다. 콘텐츠 생성이나 리서치처럼 복잡한 일을 LLM 호출 한 번으로 해결하려 하면 금방 구조적 한계가 드러난다. 결과가 특정 category로 쏠리고, 쓸모없는 noise가 섞이고, 같은 내용이 표현만 바꿔 반복된다.
LLM을 제품 pipeline에 붙이다 보면 흔히 빠지는 대응이 있다. 결과가 마음에 안 들면 prompt에 한 줄을 더 보탠다. 그러다 보면 prompt는 길어지는데 어디가 문제인지는 점점 더 안 보인다. 이 상태를 벗어나는 데 패턴 이름이 도움이 된다. 이름이 생기면 문장이 아니라 구조를 놓고 이야기할 수 있다. 아래는 Anthropic이 정리한 다섯 가지 패턴 [1]과, 그걸 pipeline 하나로 엮을 때 내가 기준으로 삼는 점들이다.
왜 호출 한 번으로는 부족한가
LLM 출력 품질이 좋아질수록 “한 번 호출”로는 풀기 어려운 일을 맡기고 싶어진다. 그런데 한 번 호출로 결과를 대량으로 한꺼번에 받으면 세 가지 한계가 반복해서 나온다.
- category 쏠림: 모델은 안전하고 무난한 category 쪽으로 답을 몰아주는 경향이 있다.
- 저가치 noise: 산업이나 brand 맥락 없이 어디에나 들어갈 법한 일반적인 결과가 섞인다.
- 중복 패턴: 같은 의도를 표현만 살짝 바꿔 여러 번 생성한다.
prompt를 더 정교하게 쓴다고 이 셋이 다 사라지지는 않는다. 생성과 검사가 한 호출 안에 섞여 있으면, 모델이 자기 출력의 분포를 스스로 바로잡을 기회가 없다. 일을 여러 단계로 쪼개고 단계마다 역할과 검증 기준을 따로 두는 시스템 설계가 필요하다. agentic workflow가 필요한 이유가 여기 있다.
workflow와 agent는 다르다
Anthropic은 이 둘을 구분한다 [1]. workflow는 미리 정의한 code path를 따라 LLM과 tool을 orchestration하는 방식이고, agent는 LLM이 다음 행동을 스스로 정하면서 과정을 동적으로 끌고 가는 방식이다.
전통적인 자동화는 모든 분기를 사람이 미리 정한다. agentic 접근은 판단의 일부를 LLM에게 맡기는 hybrid 설계에 가깝다. 실제로는 둘을 깔끔하게 나누기보다 섞어 쓰는 경우가 많다. 예측 가능한 구간은 workflow로 고정하고, 판단이 필요한 구간에만 agent 같은 자율성을 준다. 나도 이 순서로 생각한다. 먼저 고정할 수 있는 건 전부 code로 고정하고, 남은 판단만 모델에게 넘긴다. 고정된 구간은 재현이 되고, 재현이 돼야 디버깅이 된다.
다섯 가지 핵심 패턴
Anthropic이 정리한 다섯 가지 패턴은 이렇다 [1].
| 패턴 | 정의 | 쓰는 시점 |
|---|---|---|
| Prompt Chaining | 작업을 순차 단계로 나누고, 각 단계 출력을 다음 단계 입력으로 넘김 | 복잡한 일을 작은 단위로 쪼갤 때 |
| Routing | 입력을 분류해 전문화된 후속 처리로 분기 | 입력 유형마다 처리가 달라야 할 때 |
| Parallelization | 같은 입력을 여러 LLM이 동시에 처리하거나, 작업을 나눠 병렬 실행 | 처리량·속도가 중요하거나 여러 관점이 필요할 때 |
| Evaluator-Optimizer | 생성 LLM과 평가 LLM이 반복 loop를 도는 구조 | 품질 기준이 분명하고 자동 평가가 가능할 때 |
| Orchestrator-Workers | 중앙 LLM이 하위 작업을 동적으로 배분 | 작업 범위를 미리 예측할 수 없을 때 |
각 패턴은 따로 써도 되지만, 실제 pipeline은 보통 몇 개를 섞어야 복잡한 자동화를 감당한다.
네 패턴을 엮은 pipeline
대량의 결과 목록을 만드는 pipeline이라면 다섯 중 네 개를 엮는 구성이 잘 맞는다. 빠지는 건 대개 Orchestrator-Workers다. 처리 순서가 이미 정해진 pipeline에서 작업을 동적으로 배분하면 복잡도만 늘어난다.
흐름은 대략 이렇다.
- 전처리 (Prompt Chaining · gate): 중복 제거와 저가치 입력 필터링을 먼저 거친다.
- 분류 (Routing): pattern matching을 먼저 적용하고, 애매한 경우만 LLM이 판단한다.
- quota (Prompt Chaining · gate): category 균형을 맞추고 저가치 결과를 한 번 더 걸러낸다.
- LLM 보충 (Parallelization + Evaluator-Optimizer): batch 단위로 병렬 생성하고, self-validation loop로 품질을 올린다.
- 후처리 (Prompt Chaining): 상업적 가치 기준으로 최종 정렬한다.
이렇게 단계마다 역할을 떼어 두면, 문제가 생겼을 때 “어느 단계에서 품질이 무너졌는지”를 바로 짚을 수 있다. 거대한 prompt 하나로 처리하면 이 진단 자체가 안 된다. 2번에서 pattern matching을 먼저 두는 이유도 같은 맥락이다. 규칙으로 잡히는 입력에 LLM을 부를 이유가 없고, 규칙으로 처리한 몫은 매번 같은 결과가 나온다. LLM 호출은 비용과 latency와 분산을 같이 가져오니, 정말 판단이 필요한 곳에만 쓴다.
gate: 단계 사이의 통과/차단 조건
Prompt Chaining에서 제일 중요한 건 단계 사이에 두는 통과/차단 조건(gate)이다. 다음 단계로 넘길 만큼 품질이 나왔는지, 중간에 걸러야 하는지를 명시적으로 판정하는 지점이다.
gate가 없으면 뒤 단계가 앞 단계의 저품질 결과를 그대로 물려받는다. 반대로 gate를 촘촘히 두면 처리 비용은 늘지만 최종 결과의 품질 편차가 크게 줄어든다. 비용과 품질 사이 어디에 선을 그을지가 pipeline 설계에서 가장 손이 많이 가는 결정이다.
control engineering에서 출발한 내 눈에는 gate가 interlock과 같은 역할로 보인다. 조건이 안 맞으면 다음 동작으로 못 넘어가게 막는 장치다. 차이도 있다. interlock 조건은 대부분 측정값에 대한 결정론적 판정인데, LLM pipeline의 gate는 판정 자체를 LLM이 하는 경우가 있다. 그래서 나는 gate를 두 층으로 나눈다. 길이, 필수 field, 중복, 금지어처럼 code로 판정되는 건 code로 막고, 그걸 통과한 것만 LLM judge에 넘긴다. gate마다 통과율도 기록해 둔다. 통과율이 갑자기 바뀌면 앞 단계나 모델 쪽에 무슨 일이 생겼다는 신호다.
GEO 콘텐츠 pipeline에 적용하면
이 패턴들은 GEO(Generative Engine Optimization) 콘텐츠를 만드는 일에도 그대로 들어맞는다. 정의·통계·출처를 넣은 콘텐츠가 generative engine에 인용될 가능성이 높아진다는 연구 결과가 있는데 [2], 이를 gate 조건으로 옮길 수 있다. “출처가 들어 있나”, “질문에 바로 답하는 정의가 맨 위에 있나” 같은 조건을 전처리·후처리 단계에 넣으면, 사람이 매번 검토하지 않아도 일정한 구조를 유지할 수 있다.
다만 gate가 보장하는 건 구조까지다. gate를 통과했다는 건 연구에서 효과가 보고된 형식을 갖췄다는 뜻이지, 실제 AI 검색에서 인용됐다는 뜻은 아니다. 인용 여부는 pipeline 바깥에서 따로 재야 하고, 그 측정 결과를 다시 gate 조건에 반영할 때 pipeline이 처음으로 닫힌 loop가 된다.
패턴을 고를 때 확인할 것
- 작업이 순서대로 깔끔하게 쪼개진다: Prompt Chaining
- 입력 유형이 다양하고 유형마다 처리가 달라야 한다: Routing
- 같은 작업을 여러 관점에서 동시에 처리해야 한다: Parallelization
- 품질 기준을 자동으로 평가할 수 있다: Evaluator-Optimizer
- 작업 범위 자체를 미리 예측할 수 없다: Orchestrator-Workers
agentic workflow는 LLM을 더 많이 쓰는 일이 아니라, LLM을 어디에 어떤 역할로 둘지 정하는 일이다. 결과가 마음에 안 들 때 prompt에 문장을 보태기 전에, 그 문제가 어느 단계의 책임인지부터 묻는다.
