고객 문의 20건을 세 종류로 나누는 일부터 시작합니다
예시 업무는 ‘결제’, ‘기능 문의’, ‘기타’ 분류입니다. 과거 문의 20건에서 개인정보를 지우고 사람이 먼저 정답을 붙입니다. 이 정답지가 있어야 AI 결과가 좋아졌는지 나빠졌는지 판단할 수 있습니다.
첫 실행에서 18건을 맞혔다고 바로 자동 답변을 보내지 않습니다. 틀린 두 건이 단순 기능 문의인지 환불·계정 삭제처럼 되돌리기 어려운 요청인지 봅니다. 오류율이 같아도 사고 비용은 다릅니다.
category: billing | product | other
confidence: 0~1
reason: 원문에서 판단에 사용한 짧은 근거긴 자연어 답변보다 정해진 필드로 받으면 누락과 형식 오류를 다음 단계에서 검사하기 쉽습니다.
n8n 공식 문서도 AI를 한 덩어리 기능으로 설명하지 않습니다
n8n의 AI 문서 첫 화면에는 AI 구성 요소, LangChain, 테스트와 개선, 예제가 따로 나뉘어 있습니다. 모델 하나를 연결하는 것과 운영 가능한 흐름을 만드는 것이 다른 작업이라는 뜻으로 읽힙니다.
어떤 모델을 쓰는지보다 입력 데이터가 어디서 오고, 응답이 어디에 저장되며, 실패 시 무엇을 남기는지가 먼저입니다. 모델은 나중에 바꿀 수 있지만 기록이 없는 실패는 다시 분석할 수 없습니다.
검수 대기함과 자동 중단 조건을 만듭니다
AI 결과는 먼저 ‘검수 대기’ 데이터베이스에 저장합니다. 원문, 분류, 짧은 근거, 실행 시각, 사용한 모델 버전을 한 행에 둡니다. 사람이 승인한 뒤에만 고객 답변 초안이나 게시 큐로 이동시킵니다.
신뢰도 값이 낮거나 필수 필드가 비어 있으면 재시도를 반복하지 않고 담당자에게 보냅니다. 같은 입력을 같은 프롬프트로 세 번 실행해도 근거가 생기지 않습니다. 외부 API 오류와 모델의 애매한 판단도 서로 다른 실패 코드로 남겨야 합니다.
환불 승인, 계정 삭제, 가격 변경, 세금·의료·법률 판단, 공개 발행. 초안까지 자동화하더라도 마지막 동작은 명시적인 사람 승인 뒤에 둡니다.
토큰 비용보다 재작업 비용을 함께 셉니다
모델 API 사용료가 월 10달러라고 해도 사람이 매일 잘못 분류된 결과를 한 시간씩 고치면 싼 자동화가 아닙니다. 처리 건수, API 비용, 사람 검수 시간, 오분류 건수, 누락 건수를 같은 주간 기록에 둡니다.
반대로 정확도가 완벽하지 않아도 사람이 읽어야 할 문의를 절반으로 줄이고 위험한 유형을 놓치지 않는다면 가치가 있습니다. 목표를 ‘사람 제거’가 아니라 ‘사람이 읽을 순서 정하기’로 바꾸면 현실적인 성과를 측정할 수 있습니다.
코드와 달라서 ‘돌려보는’ 수밖에 없습니다
앞에서 정답지 20건을 만들라고 했는데, 왜 그래야 하는지를 n8n 공식 문서가 정확히 설명합니다. “AI 모델은 근본적으로 코드와 다르다. 코드는 결정론적이고 따져 볼 수 있다. LLM은 블랙박스라 그게 어렵다. 대신 데이터를 흘려보내고 출력을 관찰해 측정해야 한다.”
문서가 드는 평가의 효용 세 가지가 그대로 실무 이유입니다.
| 효용 | 없을 때 벌어지는 일 |
|---|---|
| 다양한 입력 범위에서 테스트 | 엣지 케이스가 운영 첫날 고객에게서 발견됩니다 |
| 다른 곳을 망가뜨리지 않고 변경 | 프롬프트 한 줄 고쳤더니 멀쩡하던 분류가 틀어집니다 |
| 모델·프롬프트 간 성능 비교 | “바꿨더니 좋아진 것 같다”는 느낌으로 결정하게 됩니다 |
평가는 배포 전후로 성격이 다릅니다
문서는 평가를 두 단계로 나눕니다. 처음부터 완벽한 데이터셋을 만들려다 지치는 걸 막아 주는 구분입니다.
| 가벼운 평가 (배포 전) | 지표 기반 평가 (배포 후) | |
|---|---|---|
| 데이터셋 | 몇 건이면 충분합니다. 문서 표현으로 “a handful of examples” | 운영 실행 기록에서 더 크고 대표성 있는 데이터셋을 만듭니다 |
| 판정 방법 | 공식 지표 없이 눈으로 결과를 비교해 품질 감각을 잡습니다 | 건별 확인이 불가능하므로 지표(수치)로 품질을 측정하고 실행 간 변화를 추적합니다 |
| 목적 | 출시 가능한 수준(또는 PoC)까지 반복 개선 | 회귀 방지와 품질 추적 |
그리고 운영 단계의 핵심 습관이 하나 나옵니다. 버그를 발견하면 그 원인이 된 입력을 데이터셋에 추가하고, 고칠 때는 데이터셋 전체를 다시 돌려 회귀 테스트를 하는 것입니다. 문서가 굳이 이 순서를 적어 둔 이유는, 수정이 “다른 곳을 의도치 않게 악화시키지 않았는지” 확인해야 하기 때문입니다. AI 워크플로우에서는 한 군데를 고치면 다른 데가 틀어지는 일이 흔합니다.
이 관점에서 보면 앞서 만든 검수 대기함이 두 배로 쓸모 있어집니다. 사람이 반려한 항목이 곧 다음 평가 데이터셋이기 때문입니다. 반려 사유를 함께 남겨 두면 데이터셋을 따로 만들 필요 없이 운영이 곧 수집 과정이 됩니다.
지표를 하나 고르는 것부터가 설계입니다
지표 기반 평가로 넘어가려면 “무엇을 숫자로 볼 것인가”를 정해야 합니다. 문서는 지표를 “특정 특성을 나타내는 수치 값”으로 정의하고, 이 값이 있어야 실행 간 품질 변화를 추적할 수 있다고 설명합니다. 앞의 분류 예제라면 고를 수 있는 축이 이렇게 나뉩니다.
| 지표 | 무엇을 잡아내나 | 한계 |
|---|---|---|
| 정확도(정답 일치율) | 전체적인 성능 변화 | 사고 비용이 다른 오답을 구분하지 못합니다. 환불 오분류와 기능 문의 오분류가 같은 1점으로 깎입니다 |
| 중대 오류 건수 | 되돌리기 어려운 실수만 따로 | 건수가 적어 통계적으로 흔들립니다. 대신 0이어야 한다는 기준선으로 쓰기 좋습니다 |
| 신뢰도 임계값 아래 비율 | 모델이 스스로 애매하다고 말한 비중 | 모델이 과신하면 잡히지 않습니다 |
| 사람 개입률 | 검수 대기함에서 실제로 손이 간 비율 | 운영 부담을 직접 반영합니다. 자동화의 실질 효용에 가장 가깝습니다 |
처음이라면 정확도 하나와 중대 오류 건수 하나, 두 개면 충분합니다. 지표를 많이 만들면 어느 것을 보고 판단할지 다시 고민하게 됩니다. 중요한 건 숫자의 절대값이 아니라 같은 데이터셋으로 반복 측정해 변화를 보는 것입니다. 절대값은 데이터셋이 바뀌면 의미가 없어집니다.
그래서 데이터셋을 바꿀 때는 규칙이 하나 필요합니다. 데이터셋을 늘린 회차와 프롬프트를 고친 회차를 섞지 마세요. 둘을 같이 바꾸면 점수가 움직여도 원인을 모릅니다. 데이터셋은 고정한 채 프롬프트만 바꿔 비교하고, 데이터셋을 늘렸다면 그 회차는 새 기준선을 잡는 데만 씁니다.
애매한 문의를 억지로 세 종류에 넣지 않습니다
“결제가 두 번 됐는데 계정도 로그인이 안 됩니다”는 결제와 기능 문제가 함께 있습니다. 하나의 정답만 강제하면 중요한 부분이 사라집니다. 복수 라벨을 허용하거나 ‘사람 확인 필요’ 범주를 하나 마련해 두는 쪽이 안전합니다.
개인정보가 포함된 원문을 외부 모델에 보낼 때는 계정 유형과 데이터 정책, 조직 규칙을 확인합니다. 이름과 이메일이 분류에 필요 없다면 전송 전에 제거합니다. 테스트 데이터에도 실제 고객 정보를 그대로 복사하지 않습니다.
20건을 통과한 뒤에도 곧바로 전체 연결하지 않습니다
다음 단계는 하루치 문의를 그림자 모드로 처리하는 것입니다. 기존 업무에는 영향을 주지 않고 AI 결과와 사람의 실제 처리를 비교합니다. 일주일 동안 특정 유형에서 반복적으로 틀리는지 본 뒤에만 승인 후속 작업을 연결합니다.
운영을 시작한 뒤에는 프롬프트와 모델 가운데 한 번에 하나만 바꾸는 것을 원칙으로 삼으세요. 두 요소를 한꺼번에 바꾸면 정확도가 달라진 원인을 찾기 어렵습니다. 변경 전 샘플 결과와 버전, 날짜를 남기고 한 가지씩 바꿔야 문제가 생겼을 때 이전 설정으로 돌아갈 수 있습니다.
워크플로우를 만들 도구가 아직 없다면 n8n 첫 워크플로우 만들기에서 입력과 저장부터 연습할 수 있습니다. AI 노드는 그 흐름이 안정된 다음에 넣어야 문제가 생겼을 때 원인을 좁히기 쉽습니다.
n8n AI 문서와 OpenAI 운영 모범 사례를 2026년 8월 26일 확인했습니다.