AI 에이전트와 자동화 워크플로의 차이: 업무 사례별 선택 기준

“고객 문의를 자동으로 처리하자”는 목표가 있어도 모든 단계에 AI 에이전트가 필요한 것은 아니다. 주문번호 형식을 확인하는 일은 규칙으로 충분할 수 있고, 한 문장에 섞인 불만과 변경 요청을 해석하는 일에는 모델이 도움이 될 수 있다. 핵심은 업무의 어느 지점에서 판단이 필요한지를 찾는 것이다. 이 글은 같은 가상 고객 문의 업무를 정해진 워크플로, 단일 에이전트, 여러 에이전트로 설계해 비교한다.

1. 세 방식이 맡는 판단의 범위

Anthropic의 설계 글은 미리 정해진 코드 경로를 따르는 워크플로와 모델이 과정을 동적으로 결정하는 에이전트를 구분한다. OpenAI의 구축 가이드는 단일 에이전트에서 출발해 필요할 때 다중 구조로 확장할 것을 권한다. 제품마다 용어는 다를 수 있지만, 이 글에서는 누가 다음 단계를 결정하는가를 비교 기준으로 사용한다.

2. 같은 문의를 세 방식으로 처리해 본다

가상 입력: “어제 주문한 제품의 배송지를 바꾸고 싶어요. 출고됐다면 취소할 수 있나요?” 주문번호는 메시지에 없다. 이는 배송지 변경과 취소 가능성이라는 두 의도가 섞인 사례다. 실제 고객 정보나 정책을 사용한 사례가 아니다.

주문 상태를 조회하고 승인된 문구를 골라 보내는 정도라면 정해진 워크플로가 단순하다. 복잡한 예외 설명이 자주 들어오면 단일 에이전트가 문의를 해석하되 주문 상태는 시스템에서 확인해야 한다. 변경·취소·환불 부서의 규칙과 도구가 크게 다르고 단일 에이전트가 지속해서 잘못된 도구를 고른다면 분리할 이유가 생긴다. 멀티에이전트 구축 글의 작업 계약이 이때 필요하다.

3. 혼합 설계가 실무에서 다루기 쉽다

모든 단계를 한 방식으로 처리할 필요는 없다. 위 사례라면 입력 형식 확인과 주문 조회는 정해진 코드로 처리하고, 문장이 여러 뜻으로 읽힐 때만 모델이 의도를 분류할 수 있다. 배송지 변경처럼 실제 상태를 바꾸는 작업은 인증·권한 확인과 사용자 확인을 거친 뒤 정해진 도구로 실행한다. 모델이 정책이나 주문 상태를 추측해서 답하지 않도록 조회 결과와 정책 버전을 함께 전달한다.

예외 처리도 미리 정한다. 주문번호를 찾지 못하거나 정책 문서가 충돌하면 자동 처리를 중단하고 ‘추가 확인 필요’로 표시한다. 오류가 난 경우에는 입력, 선택한 분기, 사용한 자료, 실행한 도구를 기록해 원인을 추적한다. 개인정보가 포함된 문의에서는 필요한 데이터만 전달하고 기록 보관 규칙을 따른다.

4. 시작하기 전에 세 가지로 비교한다

가장 먼저 실제 문의 20~30건 정도의 표본을 모으되, 개인정보를 제거하고 유형을 확인한다. 표본 수는 여기서 제안하는 작은 시작 규모일 뿐 성능을 보장하는 기준은 아니다. 세 방식의 후보 중 구현 비용이 낮은 것부터 시도하고 다음 결과를 같은 조건에서 비교한다.

• 정확성: 주문 상태, 정책, 담당 부서의 선택이 맞았는가?
• 운영 비용: 모델 호출과 사람의 재검토·수정 시간을 모두 합쳤는가?
• 처리 시간: 고객이 검토 가능한 답을 받기까지의 전체 시간이 줄었는가?

한 번 맞힌 답의 수만으로 판단하지 않는다. 변경이나 취소를 잘못 실행하는 오류는 단순 분류 오류보다 영향이 크다. 실패 유형별로 비용을 다르게 보고, 중요한 상태 변경에는 별도 확인을 둔다.

선택 체크리스트

• 입력과 분기가 명확하면 먼저 규칙으로 구현했는가?
• 모델이 판단해야 하는 모호한 단계가 구체적으로 있는가?
• 단일 에이전트가 실제로 한계를 보였는가?
• 외부 상태 변경의 권한·확인·실패 처리 절차가 있는가?
• 정확성, 전체 비용, 처리 시간을 같은 표본으로 비교했는가?

이름이 새롭다는 이유로 에이전트를 추가하지 않는다. 업무를 작은 단계로 나누고, 규칙으로 충분한 부분을 먼저 고정하면 AI가 판단해야 할 구간이 드러난다. 그 구간이 단일 에이전트의 범위를 넘어설 때 비로소 여러 에이전트를 검토한다.