Agent Workflow

단일 호출은 검색 한 번, 계산 한 번처럼 짧은 일에는 충분하지만, 도중 결과를 보고 계획을 바꿔야 하는 작업에는 약합니다. 중간 단계에서 실패했을 때 다시 시도할지, 다른 도구를 쓸지, 멈출지를 결정할 구조가 없으면 긴 업무형 과제에서 쉽게 막힙니다.

tool use가 붙은 뒤 많은 팀이 곧바로 깨달은 것은, 현실 업무는 한 번의 호출로 끝나지 않는다는 점이었습니다. 검색 결과를 읽고 다시 검색하거나, 상태를 확인한 뒤 조건에 따라 다른 행동을 택해야 했기 때문에 모델을 반복 루프 안에서 제어하는 패턴이 agent workflow라는 이름으로 정리됐습니다.

보통은 사용자 목표와 현재 상태를 바탕으로 모델이 다음 행동을 고르고, 런타임이 그 행동을 실제로 실행합니다. 도구 결과나 오류는 observation(중간 실행 결과)으로 다시 상태에 합쳐지고, 모델은 그 상태를 보고 계속할지 멈출지를 다시 판단합니다. 이때 토큰 예산, 도구 권한, 최대 스텝 수, 실패 시 fallback이 루프 전체를 안정시키는 제어점이 됩니다.

agent workflow와 tool use는 둘 다 모델이 텍스트 밖의 일을 하게 만들지만, tool use는 개별 호출 능력이고 agent workflow는 그 호출을 여러 번 묶어 목표를 향해 조정하는 제어 루프입니다. 한 번의 조회나 실행이면 tool use로 충분하고, 중간 결과를 보고 계획을 바꿔야 하면 agent workflow를 봐야 합니다. 경로가 이미 정해진 작업까지 agent로 풀면 오히려 제어 비용만 커진다는 점이 한계입니다.

agent workflow의 가장 큰 이득은 중간 결과를 보고 경로를 바꾸거나 복구할 수 있다는 점입니다. 대신 스텝 수가 늘수록 지연, 비용, 도구 남용 가능성, 디버깅 난도가 함께 커집니다. 다음 행동이 이전 observation에 실제로 달려 있는 작업에는 강하지만, 경로가 이미 정해진 조회나 변환 작업이라면 고정 워크플로나 단일 tool call이 더 단순하고 안정적입니다.

실무에서는 조사형 비서, 복합 업무 처리, 지원 자동화처럼 한 번의 질의응답으로 끝나지 않는 작업에서 씁니다. 다만 모든 문제를 agent로 풀 필요는 없습니다. 경로가 이미 정해진 짧은 작업은 고정 워크플로가 더 예측 가능하고, agent workflow는 단계 간 판단이 실제로 필요한 경우에만 쓰는 편이 운영이 덜 흔들립니다.