이제 에이전트가 무엇을 할지, 어디에 배치할지 정했다면, 중요한 질문을 던질 차례입니다.

이 문제가 정말 에이전트가 필요한 문제인가요?

모든 프로젝트에 에이전트가 필요한 것은 아닙니다. 자동화 프로젝트라고 해도 마찬가지입니다. 때로는 간단한 워크플로우, 스크립트, 또는 규칙 기반 프로세스가 더 효과적일 수 있습니다. 이 차이를 이해하면 시간, 비용, 혼란을 줄일 수 있습니다.

AI 에이전트는 단순히 명령을 실행하는 것 이상을 위해 설계되었습니다. 자연어로 읽고, 쓰고, 말할 수 있습니다. 의도를 해석하고, 지식을 적용하며, 불확실한 상황에서 결정을 내립니다. 이런 유연성이 강점이지만, 동시에 복잡성도 높입니다. LLM 호출마다 토큰, 시간, 위험이 발생하므로, 실제로 추론이나 언어 이해가 필요한 작업에만 에이전트를 사용하는 것이 합리적입니다.

작업이 결정적(즉, 예측 가능한 입력과 출력이 하나씩 있는 경우)이라면, 워크플로우나 자동화 도구가 보통 더 적합합니다. (참고로, Botpress는 이 두 가지 모두 지원합니다!)

작업에 맥락, 해석, 대화가 포함된다면 AI 에이전트가 올바른 선택입니다.

Terminal Roast가 이 문제를 어떻게 접근하는지 살펴봅시다.

Taryn의 팀은 첫 번째 과제로 새로운 커피 맛과 레시피에 대한 고객 피드백 수집을 정했습니다. 수석 바리스타 Adrian은 에이전트가 이 작업을 처리할 두 가지 방법을 제안합니다.

첫 번째는 대화형 방식입니다. 에이전트가 고객에게 음료를 좋아하거나 싫어한 이유를 묻고, 그 이유를 이해하려고 합니다. 여기에는 미묘한 해석과 기억이 필요하므로 에이전트에 적합합니다.

두 번째는 프로그램 방식입니다. 에이전트가 새로운 레시피 목록을 보여주고, 고객에게 '예' 또는 '아니오'로 답하게 합니다. 이 상호작용에는 추론이 필요하지 않으므로 자동화에 딱 맞는 작업입니다.

이 두 흐름을 분리함으로써 팀은 시스템을 더 효율적으로 만듭니다. 언어 이해가 중요한 부분에는 에이전트를, 논리만으로 충분한 부분에는 워크플로우를 사용합니다.

많은 팀이 이 구분을 흐리게 만듭니다. 모든 기능(질문 응답, 데이터 조회, 기록 업데이트, 거래 관리 등)을 하나의 에이전트에 넣으려 하지만, 기능이 늘어날수록 비용, 지연, 유지보수 부담이 커집니다. 더 나은 방법은 에이전트와 워크플로우를 조합하는 것입니다.

구조와 신뢰성이 필요한 부분에는 워크플로우를, 지능과 적응력이 필요한 부분에는 에이전트를 사용하세요.

에이전트를 사용자의 요구를 이해하는 '최전선' 인터페이스로 생각하고, 구조화된 작업은 자동화 시스템에 넘겨 정확하게 실행하게 하세요. 이 두 시스템이 명확히 정의되면, 결과는 더 안정적이고 확장 가능하며 투명해집니다.

간단한 테스트가 있습니다.

스스로에게 물어보세요: 이 작업은 자연어 이해가 필요한가요, 아니면 간단한 규칙 집합으로 처리할 수 있나요? 만약 의도 파악, 모호성 처리, 지식 참조 등 이해가 필요하다면 에이전트가 필요합니다. 그렇지 않다면 워크플로우로 만드세요.

논리와 데이터가 명확해진 후에는 언제든지 에이전트를 추가할 수 있습니다. 이미 잘 작동하는 워크플로우를 지능적으로 확장하는 것이, 복잡하고 과도하게 설계된 에이전트를 디버깅하는 것보다 훨씬 쉽습니다.

Terminal Roast의 접근법(대화형과 프로그램형 작업 분리)은 좋은 모델입니다. 각 부분에 가장 적합한 방식으로 더 간결한 시스템을 만들 수 있습니다.

이런 명확함은 나중에 유지보수, 비용, 성능 면에서 큰 도움이 됩니다.

실행: 계획 중인 에이전트의 작업을 검토하고, 진정한 언어 이해가 필요한 작업이 무엇인지 식별하세요.

이런 작업만 에이전트가 담당하도록 하고, 나머지는 표준 워크플로우로 자동화할 계획을 세우세요.

‍