문의 관리에 AI 분류를 도입하면 편리합니다.

하지만 분류 결과를 그대로 업무 판단에 사용하기 전에, 서버 측에서 지켜야 할 것들이 있습니다.

어떤 답변을 분류 대상으로 했는가
어떤 버전으로 분류했는가
사람이 확인했는가
...

AI 분류는 '라벨을 붙이는 처리'가 아니라, 답변 레코드의 상태를 늘리는 처리로 취급합니다.

분류 전에 제외 대상을 결정하기

먼저, AI에게 전달하지 않을 답변을 결정합니다.

공란
중복
개인정보가 과도한 답변
...

삭제하는 것이 아니라, 제외 이유를 남깁니다.

exclude_from_ai: true
exclusion_reason: test_submission

이것이 없으면, 나중에 "왜 이 건수로 집계했는가"를 설명할 수 없습니다.

분류 결과는 버전과 함께 저장하기

AI 분류는 프롬프트(Prompt)나 카테고리 정의를 바꾸면 결과가 달라집니다.

따라서 분류 결과에는 버전을 부여합니다.

classification_status
classification_version
category
...

카테고리 정의를 바꾸면 버전을 변경합니다.

inquiry_2026_06_v1
inquiry_2026_06_v2

신구(新舊) 데이터를 섞지 않는 것이 중요합니다.

인간 리뷰를 별도의 상태로 분리하기

AI 분류 완료와 사람이 승인한 것은 별개입니다.

classification_status = done
review_status = unreviewed

이 상태는 분류는 끝났지만 미확인 상태임을 의미합니다.

업무에 사용하려면 리뷰 상태를 가집니다.

unreviewed
approved
corrected
...

수정한 경우에는 AI의 카테고리와 최종 카테고리를 구분합니다.

category_ai: 가격
category_final: 결함 의심
reviewer: 山田

다음 액션으로 연결하기

분류는 집계만을 위한 것이 아닙니다.

문의 관리에서는 다음 행동으로 연결합니다.

category = 결함 의심 -> 서포트 확인
category = 요금 -> 영업 확인
category = 대상 외 -> 제외 이유 확인

따라서 next_action을 가집니다.

next_action
owner
status
...

AI 분류만 배치하고 담당자와 상태가 없다면 운영으로 이어지지 않습니다.

지켜야 할 불변 조건 (Invariant)

classification_done does not mean approved
excluded requires exclusion_reason
category change requires version or review log
...

이 불변 조건을 서버 측에서 지킵니다.

UI나 프롬프트에서 주의를 환기하는 것만으로는 부족합니다.

체크리스트

[ ] exclude_from_ai 를 가짐
[ ] exclusion_reason 을 필수 항목으로 함
[ ] classification_version 을 가짐
...

AI 분류는 강력한 보조 도구가 됩니다.

하지만 답변 상태의 정본(Source of Truth)으로 삼으려면, 서버 측의 가드레일 (Guardrails)이 필요합니다.

문의 AI 분류의 전체 설계는 이곳에 정리해 두었습니다.

Discussion