Make AI Agents 고객 문의 분류 자동화는 먼저 “문의 유형을 어떻게 나눌지”를 정한 뒤, 입력 채널, 분류 기준, 앱 액션, 예외 처리, 검토 로그 순서로 연결해야 안정적입니다. 바로 시나리오부터 만들기보다 영업 문의, 사용 문의, 오류 신고, 계약 문의, 스팸처럼 팀이 실제로 쓰는 분류표를 먼저 고정하면 자동화 결과를 검토하기 쉽고, CRM이나 헬프데스크로 넘길 때도 담당자가 덜 헷갈립니다.
핵심 요약: Make AI Agents는 반복 메시지를 읽고 분류한 뒤 여러 업무 앱의 액션과 연결하는 시각적 자동화 도구입니다. 실무에서는 입력 채널 하나, 분류 라벨 5개 안팎, 담당자 확인 단계, 실패 시 수동 처리 경로를 먼저 작게 설계한 뒤 확장하는 방식이 안전합니다. Make 화면, 기능명, 제공 범위, 사용 조건은 업데이트될 수 있으므로 실제 적용 전 공식 문서와 현재 화면을 다시 확인하세요.
1. Make AI Agents를 고객 문의 분류에 쓰는 이유
문의함, 웹폼, 채팅, 영업 메일, 제품 피드백은 대부분 같은 문제가 반복됩니다. 사람이 읽으면 어렵지 않지만, 매일 쌓이면 담당자 배정과 우선순위 판단에 시간이 들어갑니다. Make는 여러 앱을 시각적으로 연결하는 자동화 플랫폼이고, AI Agents는 그 흐름 안에서 자연어 메시지를 해석해 다음 액션을 고르는 용도로 활용할 수 있습니다. 예를 들어 웹사이트 폼으로 들어온 문장을 읽고 “가격 문의”, “기술 문의”, “데모 요청”, “기존 고객 요청”, “기타”로 나눈 뒤 Slack 알림, CRM 레코드 생성, 스프레드시트 기록, 헬프데스크 티켓 생성으로 이어갈 수 있습니다.
중요한 점은 AI가 모든 판단을 대신한다는 기대를 낮추는 것입니다. 처음부터 완전 자동 답변까지 연결하면 오분류를 발견하기 어렵습니다. 초반에는 “분류와 요약만 자동화하고, 답변이나 최종 처리는 사람이 확인한다”는 구조가 좋습니다. 이렇게 시작하면 팀이 분류표를 다듬고, 입력 데이터가 충분히 쌓인 뒤 더 넓은 자동화를 검토할 수 있습니다.
2. 시작 전 준비할 분류표와 입력 채널
가장 먼저 정할 것은 어떤 메시지를 어디에서 받을지입니다. Gmail, Google Forms, Typeform, HubSpot, Intercom, Zendesk, Slack, 웹훅 등 후보가 많아도 첫 운영은 한 채널만 고르는 편이 좋습니다. 입력 채널이 여러 개면 문장 형식, 필수 항목, 첨부 파일, 고객 식별 방식이 달라져 분류 기준이 흔들립니다. 한 채널에서 충분히 검증한 뒤 다른 채널을 복제해야 운영 난도가 낮아집니다.
분류표는 너무 세밀하게 만들지 않습니다. “제품 문의”와 “기능 문의”처럼 담당자가 실제로 다르게 움직이지 않는 라벨은 합치는 것이 좋습니다. 반대로 “긴급 오류”와 “일반 사용 질문”처럼 담당자, 알림 채널, 처리 시간이 다르면 분리합니다. 라벨마다 한 줄 설명과 예시 문장 2~3개를 붙이면 프롬프트를 만들 때도 흔들림이 줄어듭니다.
3. Make 시나리오 기본 구조
기본 구조는 입력 모듈, 정규화 단계, AI Agent 판단 단계, 라우팅 단계, 기록 단계로 나눌 수 있습니다. 입력 모듈은 새 폼 제출, 새 메일, 새 티켓 같은 트리거입니다. 정규화 단계에서는 이름, 이메일, 메시지 원문, 접수 시간, 출처 같은 값을 같은 필드명으로 정리합니다. 그다음 AI Agent가 메시지 원문과 분류표를 보고 라벨, 요약, 긴급도, 담당 팀을 반환하도록 설계합니다.
라우팅 단계에서는 라벨별로 다른 앱 액션을 실행합니다. 데모 요청은 CRM의 리드로 만들고, 오류 신고는 헬프데스크 티켓으로 만들며, 단순 자료 요청은 담당 채널에 요약 알림만 보낼 수 있습니다. 마지막 기록 단계는 꼭 남겨야 합니다. 자동화가 어떤 메시지를 어떤 라벨로 분류했는지, 어떤 앱 액션이 성공했는지, 사람이 수정했는지를 스프레드시트나 데이터베이스에 남기면 나중에 기준을 고칠 수 있습니다.
4. 프롬프트 작성 원칙
프롬프트는 길게 멋진 문장을 쓰는 것보다 출력 형식을 고정하는 것이 중요합니다. “아래 메시지를 읽고 category, summary, urgency, next_action을 JSON 형식으로 반환하라”처럼 원하는 필드를 명확히 적습니다. category에는 허용 라벨 목록만 쓰게 하고, 애매하면 “기타_검토필요”로 보내도록 정합니다. summary는 한 문장, urgency는 low, normal, high처럼 제한합니다.
또한 고객에게 보낼 답변을 바로 생성하지 않는 것이 안전합니다. 이 글의 범위는 내부 업무 분류와 전달입니다. 고객-facing 답변까지 연결하려면 브랜드 톤, 승인 단계, 금칙 표현, 담당자 확인 흐름이 별도로 필요합니다. 초반 자동화에서는 내부 요약과 분류만 만들고, 실제 응답은 사람이 확인하는 단계로 두면 실수 비용을 줄일 수 있습니다.
5. 앱 연결 전 체크리스트
- 입력 채널을 한 곳으로 제한했는가?
- 분류 라벨이 5~7개 안팎이고 담당 액션이 서로 다른가?
- AI Agent 출력 필드가 category, summary, urgency처럼 고정되어 있는가?
- 애매한 메시지를 담당자 검토로 보내는 예외 라벨이 있는가?
- CRM, 헬프데스크, 스프레드시트에 중복 생성 방지 키를 넣었는가?
- 자동화 실패 시 알림을 받을 Slack 또는 이메일 채널이 있는가?
- 분류 결과를 사람이 수정할 수 있는 기록 공간이 있는가?
6. 예시 설계표
| 문의 유형 | AI가 볼 단서 | 연결 앱 액션 | 사람 확인 기준 |
|---|---|---|---|
| 데모 요청 | 도입, 미팅, 시연, 일정 | CRM 리드 생성 후 영업 채널 알림 | 회사명이나 연락처가 비어 있을 때 |
| 가격 문의 | 플랜, 견적, 비용, 계정 수 | 영업 담당자에게 요약 전달 | 요구 조건이 길거나 범위가 불명확할 때 |
| 사용 질문 | 설정, 사용법, 연결 방법 | 헬프데스크 티켓 생성 | 제품 버전이나 화면 정보가 없을 때 |
| 오류 신고 | 작동 안 됨, 에러, 실패, 로그 | 우선순위 높음 티켓 생성 | 재현 단계가 빠졌을 때 |
| 기타 검토 | 라벨이 애매하거나 맥락 부족 | 운영 담당자 검토 큐로 이동 | 항상 사람 확인 |
7. 중복 생성과 실패 처리를 막는 방법
자동화에서 가장 흔한 문제는 같은 문의가 여러 번 들어와 CRM 레코드나 티켓이 중복 생성되는 상황입니다. 입력 데이터에 이메일, 폼 제출 ID, 메시지 ID, 접수 시간 같은 식별자가 있다면 기록 단계에 함께 저장해야 합니다. 이후 같은 식별자가 이미 있으면 새 레코드를 만들지 않고 기존 항목에 메모만 추가하는 방식으로 구성할 수 있습니다.
실패 처리도 별도로 설계해야 합니다. AI Agent 단계가 실패하거나 앱 연결 권한이 만료되거나 필수 필드가 비어 있으면 자동화가 조용히 멈추지 않도록 알림을 보내야 합니다. Make의 실행 기록을 확인하는 습관도 중요합니다. 처음 1~2주 동안은 매일 실행 기록과 분류 결과를 비교해 라벨 설명, 예시 문장, 예외 규칙을 고치는 것이 좋습니다.
8. 운영 로그를 어떻게 남길까
로그는 단순히 성공 여부만 보는 곳이 아닙니다. 원문 일부, AI 요약, 선택 라벨, 긴급도, 연결된 앱, 담당자 수정 여부를 함께 남기면 분류 품질을 개선할 수 있습니다. 특히 “기타 검토” 비율이 높다면 라벨 설명이 부족하거나 입력 폼 항목이 부실하다는 신호일 수 있습니다. 반대로 특정 라벨만 지나치게 많이 나오면 프롬프트가 특정 단어에 과하게 반응하는지 확인해야 합니다.
팀원이 수정한 라벨도 귀중한 자료입니다. 수정 전 라벨과 수정 후 라벨을 함께 저장하면 다음 프롬프트 개정 때 어떤 기준을 추가해야 할지 보입니다. 이 과정을 문서화하면 새 담당자가 들어와도 자동화 흐름을 빠르게 이해할 수 있습니다.
9. 화면·기능·사용 조건 변경 가능성 고지
Make와 연결 앱의 화면, 모듈 이름, AI Agents 제공 범위, 권한 설정, 사용 조건은 시점에 따라 바뀔 수 있습니다. 특히 새 AI 기능은 베타, 특정 플랜, 지역, 워크스페이스 설정에 따라 보이는 메뉴가 다를 수 있습니다. 이 글은 내부 업무 자동화 설계 순서를 설명하는 일반 가이드이며, 실제 적용 전에는 Make 공식 페이지와 현재 계정의 앱 화면에서 최신 기능, 연결 권한, 실행량 제한, 데이터 보관 옵션을 다시 확인해야 합니다.
10. 작은 파일럿 운영 순서
첫 파일럿은 20~50건 정도의 실제 문의로 시작하는 것이 좋습니다. 1단계에서는 자동 라벨과 요약만 만들고 사람이 최종 담당자를 정합니다. 2단계에서는 라벨별 Slack 알림과 스프레드시트 기록을 추가합니다. 3단계에서는 CRM이나 헬프데스크 생성까지 연결하되, 여전히 담당자 검토를 거치게 합니다. 4단계에서 오분류율과 예외 처리 비율이 낮아지면 일부 단순 라벨만 더 자동화할 수 있습니다.
파일럿 기간에는 성공 사례보다 실패 사례를 더 자세히 봐야 합니다. 자동화가 잘 맞춘 문의는 그대로 지나가지만, 잘못 분류한 문의는 라벨 정의, 입력 폼, 프롬프트, 앱 연결 방식 중 어디가 문제인지 알려줍니다. 이 과정을 거쳐야 자동화가 팀의 실제 업무 방식에 맞게 자리 잡습니다.
11. FAQ
Q1. Make AI Agents만 쓰면 고객 문의 답변까지 자동으로 처리해도 되나요?
A. 처음에는 내부 분류와 요약까지만 쓰는 편이 좋습니다. 답변 자동화는 브랜드 문장, 승인 흐름, 담당자 확인 기준이 더 필요하므로 별도 단계로 다루는 것이 안전합니다.
Q2. 분류 라벨은 몇 개가 적당한가요?
A. 첫 운영에서는 5~7개 안팎이 다루기 쉽습니다. 라벨이 너무 많으면 AI와 담당자 모두 헷갈리고, 너무 적으면 실제 라우팅 차이가 사라집니다.
Q3. CRM과 헬프데스크를 동시에 연결해도 괜찮나요?
A. 가능하지만 첫 파일럿에서는 한 앱부터 연결하는 편이 좋습니다. 여러 앱을 동시에 연결하면 중복 생성, 권한 만료, 필드 누락 원인을 찾기 어려워집니다.
Q4. 오분류를 줄이려면 무엇을 먼저 고쳐야 하나요?
A. 프롬프트보다 분류표와 예시 문장을 먼저 봐야 합니다. 담당자가 실제로 다르게 처리하는 기준을 라벨 설명에 넣고, 애매한 사례는 검토 라벨로 보내도록 설정합니다.
Q5. 실행 기록은 얼마나 자주 확인해야 하나요?
A. 도입 첫 1~2주는 매일 확인하는 것이 좋습니다. 이후 안정되면 주간 점검으로 줄이되, 앱 연결 변경이나 입력 폼 수정 후에는 다시 집중 점검합니다.
12. 마무리: 자동화보다 기준 정리가 먼저다
Make AI Agents 고객 문의 분류 자동화의 성패는 도구 자체보다 팀의 분류 기준에 달려 있습니다. 입력 채널을 좁히고, 라벨을 단순하게 만들고, 예외를 사람 검토로 보내며, 실행 로그를 남기면 작은 팀도 반복 문의 정리 시간을 줄일 수 있습니다. 처음부터 거대한 흐름을 만들기보다 한 채널, 한 분류표, 한 기록 공간으로 시작해 검증한 뒤 CRM, 헬프데스크, 보고서 자동화로 넓혀 가는 순서가 현실적입니다.
