AI 자동화의 첫 화면에는
‘발행’ 버튼이 없어야 합니다

고객 문의 20건을 세 종류로 나누는 일부터 시작합니다

예시 업무는 ‘결제’, ‘기능 문의’, ‘기타’ 분류입니다. 과거 문의 20건에서 개인정보를 지우고 사람이 먼저 정답을 붙입니다. 이 정답지가 있어야 AI 결과가 좋아졌는지 나빠졌는지 판단할 수 있습니다.

첫 실행에서 18건을 맞혔다고 바로 자동 답변을 보내지 않습니다. 틀린 두 건이 단순 기능 문의인지 환불·계정 삭제처럼 되돌리기 어려운 요청인지 봅니다. 오류율이 같아도 사고 비용은 다릅니다.

n8n 공식 문서도 AI를 한 덩어리 기능으로 설명하지 않습니다

n8n의 AI 문서 첫 화면에는 AI 구성 요소, LangChain, 테스트와 개선, 예제가 따로 나뉘어 있습니다. 모델 하나를 연결하는 것과 운영 가능한 흐름을 만드는 것이 다른 작업이라는 뜻으로 읽힙니다.

어떤 모델을 쓰는지보다 입력 데이터가 어디서 오고, 응답이 어디에 저장되며, 실패 시 무엇을 남기는지가 먼저입니다. 모델은 나중에 바꿀 수 있지만 기록이 없는 실패는 다시 분석할 수 없습니다.

검수 대기함과 자동 중단 조건을 만듭니다

AI 결과는 먼저 ‘검수 대기’ 데이터베이스에 저장합니다. 원문, 분류, 짧은 근거, 실행 시각, 사용한 모델 버전을 한 행에 둡니다. 사람이 승인한 뒤에만 고객 답변 초안이나 게시 큐로 이동시킵니다.

신뢰도 값이 낮거나 필수 필드가 비어 있으면 재시도를 반복하지 않고 담당자에게 보냅니다. 같은 입력을 같은 프롬프트로 세 번 실행해도 근거가 생기지 않습니다. 외부 API 오류와 모델의 애매한 판단도 서로 다른 실패 코드로 남겨야 합니다.

토큰 비용보다 재작업 비용을 함께 셉니다

모델 API 사용료가 월 10달러라고 해도 사람이 매일 잘못 분류된 결과를 한 시간씩 고치면 싼 자동화가 아닙니다. 처리 건수, API 비용, 사람 검수 시간, 오분류 건수, 누락 건수를 같은 주간 기록에 둡니다.

반대로 정확도가 완벽하지 않아도 사람이 읽어야 할 문의를 절반으로 줄이고 위험한 유형을 놓치지 않는다면 가치가 있습니다. 목표를 ‘사람 제거’가 아니라 ‘사람이 읽을 순서 정하기’로 바꾸면 현실적인 성과를 측정할 수 있습니다.

애매한 문의를 억지로 세 종류에 넣지 않습니다

“결제가 두 번 됐는데 계정도 로그인이 안 됩니다”는 결제와 기능 문제가 함께 있습니다. 하나의 정답만 강제하면 중요한 부분이 사라집니다. 복수 라벨을 허용하거나 ‘사람 확인 필요’ 범주를 두는 편이 낫습니다.

개인정보가 포함된 원문을 외부 모델에 보낼 때는 계정 유형과 데이터 정책, 조직 규칙을 확인합니다. 이름과 이메일이 분류에 필요 없다면 전송 전에 제거합니다. 테스트 데이터에도 실제 고객 정보를 그대로 복사하지 않습니다.

20건을 통과한 뒤에도 곧바로 전체 연결하지 않습니다

다음 단계는 하루치 문의를 그림자 모드로 처리하는 것입니다. 기존 업무에는 영향을 주지 않고 AI 결과와 사람의 실제 처리를 비교합니다. 일주일 동안 특정 유형에서 반복적으로 틀리는지 본 뒤에만 승인 후속 작업을 연결합니다.

운영을 시작한 뒤에는 프롬프트와 모델을 동시에 바꾸지 않는 편이 좋습니다. 두 요소를 한꺼번에 바꾸면 정확도가 달라진 원인을 찾기 어렵습니다. 변경 전 샘플 결과와 버전, 날짜를 남기고 한 가지씩 바꿔야 문제가 생겼을 때 이전 설정으로 돌아갈 수 있습니다.

워크플로우를 만들 도구가 아직 없다면 n8n 첫 워크플로우 만들기에서 입력과 저장부터 연습할 수 있습니다. AI 노드는 그 흐름이 안정된 다음에 넣는 편이 원인을 찾기 쉽습니다.