AI 에이전트 (AI agents)가 많은 관심을 받고 있지만, 많은 비즈니스 소유자들은 에이전트가 실제로 무엇을 해야 하는지 여전히 확신하지 못하고 있습니다.

어떤 이들은 웹사이트에 앉아 있는 챗봇 (chatbot)을 상상합니다. 다른 이들은 인간의 개입 없이 영업, 지원, 보고 및 운영을 관리할 수 있는 완전 자율 시스템 (fully autonomous system)을 기대합니다. 유용한 해답은 대개 그 중간 어디쯤에 있습니다.

훌륭한 AI 에이전트는 명확하게 정의된 프로세스를 처리하고, 팀이 이미 사용 중인 도구들과 함께 작동하며, 언제 작업을 사람에게 넘겨야 하는지를 알고 있습니다.

모델이 아닌 워크플로 (workflow)부터 시작하세요

첫 번째 결정은 어떤 언어 모델 (language model)을 사용할지가 아니어야 합니다. 어떤 워크플로가 가장 많은 시간을 낭비하고 있는지가 되어야 합니다.

매주 80건의 웹사이트 문의를 받는 회사를 가정해 봅시다. 직원은 모든 메시지를 읽고, 요청된 서비스를 식별하고, 발신자의 위치를 확인하며, 리드 (lead)를 적절한 담당자에게 배정해야 할 수도 있습니다.

그 프로세스는 AI 에이전트가 수행하기에 충분히 반복적입니다.

에이전트는 다음과 같은 일을 할 수 있습니다:

문의 내용 읽기
관련 정보 추출하기
리드 분류하기
CRM 업데이트하기
적절한 팀원에게 알림 보내기

사람은 여전히 특이한 사례를 검토할 것입니다. 에이전트는 단순히 반복적인 분류 작업을 제거할 뿐입니다.

이것은 명확한 책임이 없는 범용 어시스턴트 (general purpose assistant)를 구축하는 것보다 대개 더 가치가 있습니다.

에이전트가 무엇을 할 수 있는지 정의하세요

AI 에이전트에게는 경계가 필요합니다.

고객 지원을 위한 에이전트를 만들고 있다고 가정해 봅시다. 에이전트는 배송 시간, 계정 접속 또는 제품 기능에 대한 질문에 답변하는 것이 허용될 수 있습니다. 하지만 환불을 처리하는 것은 지원 매니저의 승인이 필요할 수 있습니다.

그러한 규칙은 개발이 시작되기 전에 결정되어야 합니다.

간단한 권한 구조는 다음과 같을 수 있습니다:

저위험 요청:
에이전트가 자동으로 응답

중위험 요청:
에이전트가 사람의 검토를 위해 응답 초안 작성

고위험 요청:
에이전트가 케이스를 팀원에게 직접 전달

이러한 설정은 에이전트에게 너무 일찍 너무 많은 권한을 부여하는 흔한 실수를 방지합니다.

제한된 권한으로 시작하세요. 충분한 실제 상호작용을 검토한 후에 권한을 확장하십시오.

에이전트에게 신뢰할 수 있는 정보에 대한 접근 권한을 부여하세요

에이전트는 검색할 수 있는 정보의 양만큼만 유용합니다.

만약 회사의 정책이 오래된 PDF, Slack 메시지, 공유 드라이브, 그리고 개별 직원의 메모 등에 흩어져 있다면, 에이전트는 일관되지 않은 답변을 생성할 수 있습니다. 이는 항상 모델의 문제는 아닙니다. 종종 정보의 문제입니다.

에이전트를 내부 문서에 연결하기 전에, 소스 자료(source material)를 검토하십시오.

오래된 파일을 제거하세요. 현재의 정책을 명확하게 라벨링하세요. 공개 정보와 민감한 비즈니스 데이터를 분리하세요. 몇 시간의 정리 작업이 몇 주간의 혼란스러운 테스트 결과를 방지할 수 있습니다.

지원(support) 에이전트의 경우, 지식 소스에는 다음이 포함될 수 있습니다:

• 제품 문서 (Product documentation)
• 배송 및 반품 정책
• 승인된 응답 템플릿 (Approved response templates)
• 자주 묻는 질문 (FAQs)

운영(operations) 에이전트의 경우, 내부 절차, 벤더(vendor) 상세 정보 및 보고 규칙이 포함될 수 있습니다.

목표는 비즈니스가 지금까지 생성한 모든 문서를 업로드하는 것이 아닙니다. 목표는 하나의 특정 업무를 위해 적절한 정보를 제공하는 것입니다.

업무가 이루어지는 시스템에 연결하세요

AI 에이전트는 행동을 취할 수 있게 될 때 훨씬 더 유용해집니다.

질문에 답하는 것도 도움이 되지만, CRM 레코드를 업데이트하거나, 티켓(ticket)을 생성하거나, 후속 조치(follow-up)를 예약하는 것은 실제 직원의 시간을 절약해 줍니다.

일반적인 통합(integration) 사례는 다음과 같습니다:

• 고객 관계 관리 (CRM) 플랫폼
• 이메일 시스템
• 헬프 데스크 (Help desk) 소프트웨어
• 캘린더
• 내부 데이터베이스
• 프로젝트 관리 도구

통합 계층(integration layer)은 종종 대부분의 실질적인 개발 작업이 이루어지는 곳입니다.

API에는 속도 제한(rate limits)이 있을 수 있습니다. 필드 이름(field names)이 일관되지 않을 수 있습니다. 인증(authentication)이 만료될 수 있습니다. 한 시스템은 국가 코드가 포함된 전화번호를 저장하는 반면, 다른 시스템은 그렇지 않을 수 있습니다.

이러한 세부 사항들은 흥미롭지는 않지만, 에이전트가 평범한 월요일 아침에 안정적으로 작동할지 여부를 결정합니다.

자신의 비즈니스를 위한 AI 에이전트 (AI agent) 구축 방법을 연구하는 기업은 프로세스에 관여하는 시스템을 매핑하는 것부터 시작해야 합니다. 이를 통해 모델이나 자동화 플랫폼을 선택하기 전에 기술적인 작업량을 더 쉽게 추정할 수 있습니다.

적절한 시점에 인간의 검토 (Human review) 추가하기

인간의 개입이 AI 에이전트의 능력을 떨어뜨리지는 않습니다. 오히려 시스템을 더 안전하게 만들고 개선하기 쉽게 만듭니다.

리드 자격 검증 (Lead qualification) 에이전트는 명확한 문의는 자동으로 처리하되, 모호한 요청은 검토를 위해 플래그(flag)를 표시할 수 있습니다. 보고 (Reporting) 에이전트는 주간 요약본을 준비하면서, 배포 전 관리자가 수치를 승인하도록 요구할 수 있습니다.

인간의 검토는 출시 후 처음 몇 주 동안 특히 유용합니다.

직원이 에이전트를 수정하는 사례들을 추적하세요. 이러한 수정 사항들은 누락된 지침, 취약한 데이터 소스, 또는 새로운 규칙이 필요한 상황을 드러내 줍니다.

예를 들어, 에이전트가 대부분의 영업 리드 (sales leads)를 정확하게 식별하지만, 파트너십 요청과 기술 지원 질문이 동시에 포함된 메시지에는 어려움을 겪을 수 있습니다. 이는 유용한 발견입니다. 워크플로 (Workflow)를 업데이트하여 의도가 혼재된 메시지를 사람에게 전달하도록 경로를 지정할 수 있습니다.

실제 사례로 테스트하기

깔끔한 데모만으로는 충분하지 않습니다.

에이전트는 지저분한 입력값 (messy input)으로 테스트되어야 합니다. 실제 고객은 완벽한 메시지를 쓰는 경우가 드물기 때문입니다.

오타를 시도해 보세요. 불완전한 요청을 사용해 보세요. 중복된 양식을 제출해 보세요. 무관한 세부 정보를 포함해 보세요. 에이전트가 승인된 범위 (scope)를 벗어나는 질문을 던져보세요.

시스템 장애 (system failures)도 테스트해야 합니다.

CRM을 사용할 수 없다면 어떻게 될까요? 에이전트가 요청을 재시도하나요, 일시적으로 저장하나요, 아니면 누군가에게 알리나요? 문서를 검색할 수 없을 때는 어떻게 되나요?

이러한 실패 경로 (failure paths)는 성공적인 경로만큼이나 중요합니다.

유용한 테스트 세트에는 이전 고객 대화에서 추출한 50~100개의 사례가 포함될 수 있습니다. 개인 정보를 제거한 다음, 에이전트의 결과와 귀하의 팀이 실제로 내린 결정을 비교해 보세요.

비즈니스에 영향을 미치는 결과 측정하기

정확도 (Accuracy)는 유용하지만, 그것이 유일한 지표가 되어서는 안 됩니다.

에이전트가 높은 정확도 (Accuracy)로 문의 사항을 분류하더라도, 직원이 모든 결과를 일일이 확인해야 한다면 비즈니스 가치는 거의 창출되지 않을 수 있습니다.

다음과 같은 실질적인 결과들을 측정하세요:

• 요청당 절약된 시간 (Time saved per request)
• 개입 없이 완료된 작업의 비율 (Percentage of tasks completed without intervention)
• 잘못 에스컬레이션된 케이스 수 (Number of cases escalated incorrectly)
• 평균 응답 시간 (Average response time)
• 주간 직원 수정 횟수 (Employee corrections per week)

워크플로우에 맞는 측정 지표를 두세 개 선택하세요.

지원 에이전트 (Support agent)의 경우 응답 시간과 에스컬레이션 품질이 가장 중요할 수 있습니다. 리드 에이전트 (Lead agent)의 경우, 중요한 수치는 자격 검증 정확도 (Qualification accuracy)와 후속 조치 속도 (Follow-up speed)가 될 수 있습니다.

출시 후 이러한 측정치들을 검토하세요. 테스트 중에 성능이 좋았던 에이전트라도 요청량이 증가하면 변경이 필요할 수 있습니다.

먼저 유용한 에이전트 하나를 구축하세요

가장 좋은 첫 번째 프로젝트는 회사 전체를 운영하는 에이전트인 경우가 거의 없습니다.

명확한 입력값 (Inputs), 예측 가능한 동작 (Actions), 그리고 측정 가능한 결과 (Measurable outcome)를 가진 하나의 프로세스를 선택하세요. 리드 라우팅 (Lead routing), 예약 일정 관리 (Appointment scheduling), 지원 분류 (Support triage)

및 반복적인 보고서 준비가 일반적인 시작점입니다.

해당 에이전트가 안정적으로 작동하기 시작하면, 동일한 기반을 통해 더 많은 워크플로우를 지원할 수 있습니다.

이러한 접근 방식은 영업 발표에서 거창한 약속을 하는 것보다 느립니다. 하지만 팀이 계속해서 사용할 만한 무언가를 만들어낼 가능성은 훨씬 더 높습니다.