Agent workflow를 설계할 때 가장 흔한 실수는 하나의 거대한 에이전트에게 모든 일을 맡기는 것입니다. 처음에는 간단해 보이지만, 도구 호출이 실패하거나 결과 검토가 필요해지는 순간 어디서 고쳐야 할지 흐려집니다.
이 글의 기준은 단순합니다. agent workflow는 똑똑한 한 번의 실행이 아니라, 실패를 작게 나누는 실행 구조입니다. plan, execute, review, retry, human approval을 나누면 품질을 고치기도 쉽고, 위험한 작업을 통제하기도 쉬워집니다.
LangGraph 문서는 상태가 있는 agent workflow를 구성하는 흐름을 설명하고, OpenAI Agents SDK는 multi-agent와 handoff 구조를 다룹니다. 이 글은 특정 프레임워크 사용법보다 workflow를 어떻게 쪼개야 하는지에 집중합니다.
왜 거대한 agent loop가 유지보수하기 어려울까
거대한 agent loop는 목표를 받고, 생각하고, 도구를 호출하고, 답변하는 흐름을 한 덩어리로 처리합니다. 데모에서는 잘 작동할 수 있지만 운영에서는 문제가 생깁니다. 실패 원인이 계획인지, 도구 호출인지, 결과 검토인지, 승인 누락인지 분리하기 어렵기 때문입니다.
workflow로 나누면 각 단계의 입력과 출력이 명확해집니다. 계획 단계가 잘못되면 계획만 고치고, 실행 단계가 불안정하면 도구 호출과 retry만 고칠 수 있습니다.
Plan 단계: 목표를 작업 단위로 쪼갠다
Plan 단계는 사용자의 요청을 바로 실행하지 않고, 수행 가능한 작은 작업 단위로 나눕니다. 중요한 것은 계획을 길게 쓰는 것이 아니라 다음 단계가 실행할 수 있을 정도로 구체화하는 것입니다.
plan:
goal: "기술 글 초안 만들기"
steps:
- collect_sources
- build_factpack
- draft_article
- review_claims
- create_wordpress_draft
approval_required:
- publish_article이렇게 나누면 publish처럼 되돌리기 어려운 작업은 처음부터 승인 대상으로 분리할 수 있습니다. 2편에서 다룬 Tool calling 안전 기준과도 이어지는 부분입니다.
Execute 단계: 도구 호출은 작고 관찰 가능해야 한다
Execute 단계는 실제 도구를 호출합니다. 검색, 파일 읽기, API 호출, draft 생성 같은 작업이 여기에 들어갑니다. 이 단계에서는 한 번에 너무 많은 일을 하지 않는 것이 중요합니다.
- 도구 호출 입력을 로그로 남길 수 있어야 한다.
- 도구 호출 결과가 다음 단계에서 검토 가능한 형태여야 한다.
- 외부 상태를 바꾸는 도구는 승인이나 dry-run을 먼저 둔다.
- 실패했을 때 같은 입력으로 재시도 가능한지 확인한다.
Review 단계: 결과를 그대로 믿지 않는다
agent workflow에서 review 단계는 선택이 아니라 핵심입니다. 에이전트가 만든 계획, 검색 결과, 코드, 문서 초안은 바로 최종 결과가 아닙니다. 검토 기준을 통과해야 다음 단계로 넘어가야 합니다.
예를 들어 글 작성 workflow라면 factpack의 출처와 본문 주장이 일치하는지, 코드 예제가 실행 가능한지, 개인정보가 섞이지 않았는지 확인해야 합니다. 개발 workflow라면 테스트와 lint, diff 검토가 여기에 들어갑니다.
execute_result -> review
if valid: continue
if fixable: retry with feedback
if risky: ask human approval
if invalid: stop and reportRetry 단계: 다시 시도할 조건을 미리 정한다
retry는 단순히 같은 일을 다시 해보는 것이 아닙니다. 어떤 실패는 재시도할 가치가 있고, 어떤 실패는 즉시 멈춰야 합니다. 네트워크 timeout은 재시도할 수 있지만, 권한 오류나 출처 부족은 사람이 판단해야 할 수 있습니다.
- 일시적 네트워크 오류는 제한된 횟수만 재시도한다.
- 검증 실패는 피드백을 넣어 수정 재시도한다.
- 권한 부족, 비용 발생, 공개 발행은 재시도하지 말고 승인으로 보낸다.
- 같은 실패가 반복되면 상태를 남기고 중단한다.
Human approval 단계: 위험한 작업을 분리한다
사람 승인은 workflow를 느리게 만드는 장치가 아니라 위험을 작게 만드는 장치입니다. 공개 발행, 결제, 삭제, 배포, 외부 메시지 전송처럼 되돌리기 어려운 작업은 자동 실행보다 승인 흐름이 안전합니다.
중요한 점은 승인 요청을 마지막에 갑자기 붙이는 것이 아닙니다. 처음 plan 단계에서 어떤 작업이 승인 대상인지 표시해야 합니다. 그래야 execute 단계가 위험한 도구를 몰래 호출하지 않습니다.
작은 업무 자동화 예시
블로그 글 작성 workflow를 예로 들면 agent는 다음처럼 움직일 수 있습니다. 이 예시는 특정 도구 홍보가 아니라 workflow 분리 감각을 보여주기 위한 구조입니다.
article_workflow:
plan:
output: brief
research:
output: factpack
review: sources_verified
draft:
output: article
review: quality_checklist
wordpress:
output: draft_url
approval_required: false
publish:
approval_required: true
output: public_url이 구조에서는 draft 생성과 publish가 분리됩니다. draft는 검토를 위한 준비 단계이고, publish는 공개 상태를 바꾸는 단계입니다. 이런 구분이 있어야 에이전트가 빠르게 일하면서도 중요한 지점에서는 멈출 수 있습니다.
Agent workflow 분리 기준
- 각 단계의 입력과 출력을 한 문장으로 설명할 수 있는가?
- 실패했을 때 어느 단계가 문제인지 알 수 있는가?
- 검토 기준이 코드나 체크리스트로 표현되어 있는가?
- 재시도해도 되는 실패와 멈춰야 하는 실패를 나누었는가?
- 사람 승인이 필요한 작업을 plan 단계에서 표시했는가?
정리
Agent workflow는 에이전트를 더 복잡하게 만들기 위한 구조가 아닙니다. 오히려 실패 지점을 작게 만들기 위한 구조입니다. plan, execute, review, retry, human approval을 나누면 도구 호출 실패, 잘못된 판단, 위험한 작업을 각각 다른 방식으로 다룰 수 있습니다.
다음 7편에서는 이렇게 나뉜 workflow가 실패했을 때 무엇을 로그로 남겨야 원인을 찾을 수 있는지 다루겠습니다.
