개념
에이전틱 워크플로(agentic workflow)는 모델이 질문 하나에 답 하나를 내놓고 끝내는 대신, 계획을 세우고 실행하고 결과를 점검하는 과정을 여러 차례 반복하도록 짜 놓은 구성이다. 사람이 초안을 쓰고 자료를 찾아보고 고쳐 쓰는 과정과 닮아 있으며, 한 번의 응답으로는 품질이 나오지 않는 작업에서 눈에 띄는 차이를 만든다.
자주 쓰이는 패턴은 몇 가지로 정리된다. 큰 요청을 작은 단계로 쪼개는 계획 수립, 필요한 정보를 함수 호출로 가져오는 도구 사용, 자신의 출력을 다시 읽고 문제를 찾아 고치는 자기 점검, 그리고 역할이 다른 여러 에이전트가 일을 나눠 맡는 분업이다. 이들을 어떤 순서로 엮느냐가 워크플로 설계의 실체다.
AI 에이전트와의 관계를 정리하면, 에이전트는 그렇게 동작하는 주체를 가리키고 에이전틱 워크플로는 그 동작을 어떤 순서와 구조로 배치했는가를 가리킨다. 실무에서는 완전히 자율적인 에이전트보다 분기와 종료 조건을 사람이 미리 정해 둔 반쯤 고정된 워크플로가 안정적으로 쓰이는 경우가 많다.
모든 작업에 필요한 방식은 아니다. 한 번의 호출로 충분히 풀리는 일에 루프를 씌우면 지연과 비용만 늘고 결과는 거의 그대로다. 반복이 값을 하는 것은 중간에 확인할 수 있는 신호가 있을 때이며, 그 신호가 없다면 단계를 늘리는 것이 곧 실패 지점을 늘리는 일이 된다.
쓰임새
코드 작성처럼 결과를 기계적으로 검증할 수 있는 작업에 특히 잘 맞는다. 코드를 쓰고 테스트를 돌려 실패하면 오류 메시지를 보고 고치는 루프는 검증 신호가 명확해서 반복이 실제로 품질을 끌어올린다. 조사 보고서 작성이나 데이터 정리처럼 여러 자료를 모아 정리하는 작업에도 널리 쓰인다.
설계할 때 가장 중요한 것은 멈출 조건이다. 반복 횟수 상한, 실패했을 때 사람에게 넘기는 지점, 되돌릴 수 없는 동작 앞의 확인 절차를 정해 두지 않으면 루프가 끝없이 돌거나 잘못된 판단이 그대로 실행된다. 단계마다 무엇을 문맥에 남기고 무엇을 버릴지 정하는 컨텍스트 엔지니어링도 함께 따라온다.
돌아가는 과정을 들여다볼 수 있게 만들어 두는 것도 그만큼 중요하다. 여러 단계가 안에서 돌기 때문에 최종 결과만 봐서는 어느 단계에서 어긋났는지 알 수 없다. 각 단계의 입력과 출력, 호출한 도구와 그 결과를 기록으로 남겨 두어야 문제가 생겼을 때 원인을 짚을 수 있고, 반복 구조를 손볼 근거도 생긴다.
자주 하는 오해
반복을 돌리면 알아서 좋아지지 않나?
점검 단계에 판단 근거가 없으면 모델은 자기 답을 다시 읽고도 문제를 찾아내지 못한다. 테스트 결과나 검색 결과처럼 외부에서 오는 신호가 있어야 반복이 의미를 갖는다.
단계를 잘게 쪼갤수록 정확해지지 않나?
단계마다 호출이 붙어 지연과 토큰 비용이 곱절로 늘고, 중간 오류가 뒤로 전파될 기회도 그만큼 많아진다.
사람이 개입하면 자동화에 실패한 것 아닌가?
위험한 동작 앞에 승인 지점을 두는 편이 실전에서 훨씬 오래 살아남는다. 전부 자동으로 돌리다 사고를 한 번 내고 나면 결국 시스템 전체를 못 쓰게 되므로, 개입 지점을 남겨 두는 쪽이 자동화의 범위를 넓히는 길이기도 하다.