AI 자동화, 워크플로 vs 에이전트 — 무엇을 언제 쓰나

AI 자동화를 설계할 때 가장 먼저 갈리는 결정은 이것이다 — 정해진 순서대로 흐르는 워크플로(workflow)로 짤 것인가, 스스로 판단하며 도는 에이전트(agent)로 짤 것인가. 요즘 "에이전트"가 유행어가 되면서 뭐든 에이전트로 만들려는 분위기가 있는데, 실무에서는 이 선택을 잘못하면 비싸고 불안정한 시스템이 나온다.

둘의 차이는 제어권이 어디 있느냐다. 워크플로는 사람이 미리 흐름을 정한다. "문서를 받으면 → 요약하고 → 분류하고 → 저장한다." 각 단계에서 LLM을 쓰지만, 순서는 코드가 정한다. 에이전트는 다르다. 목표만 주고 "알아서 필요한 도구를 골라 여러 번 판단하며 달성하라"고 맡긴다. 흐름을 모델이 정하는 것이다.

워크플로가 이기는 경우

작업의 단계가 미리 정해져 있고, 매번 비슷하게 흐른다면 워크플로가 낫다. 청구서 처리, 문서 분류, 정해진 형식의 리포트 생성 같은 것들. 이런 일에 에이전트를 쓰면 오히려 손해다. 모델이 매 스텝 "다음에 뭘 할까"를 고민하느라 느리고 비싸지며, 같은 입력에도 다르게 행동해 결과가 들쭉날쭉해진다.

나는 문서 분류 파이프라인을 처음에 에이전트로 만들었다가 후회했다. 흐름이 뻔한 작업인데 모델이 매번 다르게 접근하니 디버깅이 악몽이었다. 워크플로로 바꿔 각 단계를 고정하자, 어디서 틀렸는지 바로 보이고 비용도 확 줄었다. 단계가 정해진 일에 자율성은 독이었다.

에이전트가 필요한 경우

반대로 흐름을 미리 정할 수 없을 때 에이전트가 값을 한다. 입력마다 필요한 단계가 다르고, 몇 번을 반복해야 할지 모르고, 상황에 따라 다른 도구를 골라야 하는 작업. 예를 들어 "이 버그를 조사해서 원인을 찾아라" 같은 일은 미리 순서를 못 짠다. 로그를 봐야 할지, 코드를 봐야 할지, 재현을 해봐야 할지가 상황에 따라 다르기 때문이다. 이럴 때 에이전트의 자율적 판단이 빛난다.

섞어 쓰는 게 현실

실전에서 가장 흔한 답은 하이브리드다. 전체 골격은 워크플로로 짜서 예측 가능성을 확보하되, 흐름을 미리 못 정하는 특정 단계 하나만 에이전트로 처리한다. 예를 들어 "문서 수집 → (에이전트: 내용을 조사해 필요한 정보를 찾음) → 정해진 형식으로 정리 → 저장." 대부분은 고정된 파이프라인이고, 자율성이 정말 필요한 한 지점에만 에이전트를 끼운다. 이러면 에이전트의 유연성을 얻으면서도 시스템 전체가 통제 불능이 되지 않는다.

선택의 원칙

내 규칙은 단순하다. 가장 단순한 것부터 시작한다. 고정 프롬프트 한 번으로 되면 그걸로 끝. 단계가 필요하면 워크플로. 워크플로로는 도저히 안 되는, 진짜 예측 불가능한 부분이 남을 때만 에이전트를 쓴다. 에이전트는 강력하지만 그만큼 비싸고 불안정하다. "멋있어서" 쓰는 게 아니라 "다른 방법으로 안 돼서" 쓰는 것이다.

자주 묻는 질문

요즘 다 에이전트를 쓴다는데 저도 그래야 하나요?

유행과 필요는 다르다. 작업의 단계가 대체로 정해져 있다면 워크플로가 더 빠르고 싸고 안정적이다. 에이전트는 흐름을 미리 짤 수 없는 탐색적·비정형 작업에서 값을 한다. "에이전트라서 좋다"가 아니라 "이 문제엔 자율 판단이 필요한가"를 먼저 물어야 한다. 많은 경우 답은 워크플로다.

에이전트가 더 비싼 이유는요?

매 단계에서 모델이 "다음에 뭘 할지"를 스스로 판단하기 때문이다. 그 판단마다 모델 호출이 일어나고, 여러 번 반복되며, 도구 호출과 결과 처리가 더해진다. 정해진 순서를 그냥 실행하는 워크플로보다 호출 수와 토큰이 크게 늘어난다. 게다가 비결정적이라 실패 시 재시도 비용도 예측하기 어렵다.

둘을 어떻게 섞나요?

전체를 워크플로로 설계하고, 흐름을 미리 정할 수 없는 특정 단계만 에이전트에 위임하는 방식이 흔하다. 골격은 고정돼 예측 가능하고, 자율성은 꼭 필요한 지점에만 국한된다. 이렇게 하면 시스템 전체가 통제를 벗어나지 않으면서, 유연성이 필요한 부분에서만 에이전트의 장점을 취할 수 있다.