워크플로 vs 에이전트

Stephen Grider · Anthropic 기술 스태프

워크플로와 에이전트의 여러 측면을 비교·대조하며 마무리하겠습니다. 먼저 떠올려 봅시다. 워크플로는 Claude 호출을 미리 정의해 둔 일련의 시퀀스입니다. 작업을 끝내는 데 필요한 정확한 단계의 순서를 잘 알 때 워크플로를 자주 씁니다.

반면 에이전트는 어떤 작업이 주어질지 정확히 모릅니다. 그래서 대신 탄탄한 기본 도구 세트를 제공하고, Claude가 그 도구들을 조합해 주어진 작업을 끝내리라 기대합니다.

워크플로의 공통된 주제를 눈치챘을 겁니다 — 큰 작업을 훨씬 작은 작업들로 나눈다는 것입니다. 작아진 각 작업은 성격이 훨씬 구체적이라, Claude가 한 번에 한 영역에만 집중할 수 있습니다. 이렇게 집중이 높아지면 에이전트에 비해 작업 완수의 정확도가 대체로 더 높아집니다.

워크플로가 실행하는 단계의 정확한 순서를 우리가 알기 때문에, 테스트와 평가도 훨씬 쉽습니다.

에이전트는 돌에 새긴 듯한 단계 순서에 매이지 않습니다. 대신 Claude가 다양한 도전 과제를 처리할 방법을 창의적으로 찾아냅니다. 이 유연함과 함께 사용자 경험의 유연함도 따라옵니다. 워크플로는 아주 특정한 입력 세트를 받기를 기대하지만, 에이전트는 사용자에게서 받은 질의를 바탕으로 스스로 입력을 만들어 낼 수 있고, 필요할 때 사용자에게 추가 입력을 요청할 수도 있습니다.

에이전트의 단점은, 워크플로에 비해 작업 완수 성공률이 대체로 더 낮다는 것입니다 — 그만큼 많은 일을 Claude에 위임하기 때문입니다. 게다가 테스트와 평가도 더 어렵습니다. 에이전트가 주어진 작업을 끝내려고 어떤 단계의 순서를 밟을지 우리가 잘 모르는 경우가 많기 때문입니다.

결국, 에이전트는 정말 흥미롭지만 기억하세요 — 엔지니어로서 여러분의 일차적 목표는 문제를 안정적으로 해결하는 것입니다. 사용자는 여러분이 화려한 에이전트를 만들었는지에는 별 관심이 없습니다. 그들이 정말 원하는 건 100% 동작하는 제품입니다.

이 점을 염두에 두면, 일반적인 권장은 이렇습니다 — 가능한 곳에서는 항상 워크플로를 구현하고, 정말로 꼭 필요할 때만 에이전트에 기댄다.