AI에게 DM 분류 규칙을 작성하게 해도 즉시 반영되지 않는 이유: JSON화 → 재생 테스트 → 승인 과정을 거치는 Python 구현

AI에게 "환불 관련 DM은 우선 큐로, 신고된 경우 담당자에게 전달"하도록 요청하여 설정 JSON을 만들게 하는 것까지는 쉬워졌습니다.

어려운 부분은 그 JSON이 누가 옳다고 판단하고, 오분류나 AI 서비스 장애가 발생해도 DM 처리를 멈추지 않고 운영할 수 있는 형태로 만드는 것입니다. AI의 설명이 자연스러울수록 설정 자체도 올바르게 보이기 쉽습니다.

본고에서는 AI를 규칙 작성 보조에 한정하고, 실제 실행 시에는 결정적인 규칙 엔진을 사용합니다. 후보 JSON을 검증용 DM에 적용해보고, 사람이 차이점을 확인한 후에만 승인된 설정으로 격상시킵니다.

이번에 만들 흐름은 다음과 같습니다.

• 사람이 자연어로 DM 분류 요건 작성
• AI가 제약 조건이 있는 후보 JSON 생성
• Python으로 스키마, 금지 작업, 우선순위 검사
• 합성된 DM을 재생하여 기대하는 분류와 비교
• 사람이 결과를 확인하고 승인자 이름과 해시 추가
• 실제 앱은 승인된 JSON만 읽기

AI가 잘하는 것은 모호한 요건을 설정 후보로 변환하고, 변경 내용을 설명하는 것입니다. 반면, 다음 판단은 AI에게 맡기지 않습니다.

• 오검지를 어디까지 허용할 것인가
• 어떤 주제를 민감하게 다룰 것인가
• 자동 처리 시 사용자에게 무엇을 표시할 것인가
• 삭제, 차단, 답장 전송 등 되돌릴 수 없는 작업을 허용할 것인가
• 번역문만을 근거로 모더레이션해도 되는가

이러한 분리를 통해 AI가 사용할 수 없는 시간에도 승인된 규칙에 따른 DM 분류는 지속될 수 있습니다.

Tencent RTC의 Social Messaging 솔루션은 1:1 채팅, 그룹 디스커션, 커뮤니티, 리치 미디어, 라이브 스트리밍 룸 내 채팅 등의 시나리오를 다룹니다.

본고에서는 그중 1:1 DM을 예로 듭니다. 다만, 아래 Python 코드는 Tencent RTC SDK의 API를 재구현하는 것이 아닙니다. 책임 경계는 다음과 같이 나눕니다.

이번에는 실행 가능한 작업을 다음 3가지로만 제한합니다.

• standard_queue
  : 일반 큐 -
• priority_queue
  : 우선 큐 -
• human_handoff
  : 자동 판정을 멈추고 담당자 확인으로 이관

AI에게는 답장, 삭제, 차단, 신고 확정 등의 작업을 출력하게 하지 않습니다. 프롬프트로 금지할 뿐만 아니라, 후속 코드에서도 거부합니다.

AI에게 전달하는 요청 예시는 다음과 같습니다.

DM 분류 정책의 후보를 JSON으로 작성해 주세요.
요건:
- 신고된 DM은 담당자 확인으로 보냄
...

여기서 AI의 출력은 어디까지나 다음 공정의 입력일 뿐입니다. "JSON이 생성되었다"는 것이 "운영 정책이 타당하다"는 것을 의미하지 않습니다.

작업 디렉토리를 만듭니다.

mkdir dm-policy-gate
dcd dm-policy-gate
touch policy.candidate.json fixtures.json policy_gate.py

policy.candidate.json에 후보를 저장합니다.

{
"revision": "2026-10-18-01",
"default_action": "standard_queue",
...

다음으로, fixtures.json에 합성 메시지와 기대 결과를 저장합니다.

[
{
"name": "안내 동의가 없음",
...

automation_notice_accepted는 구현 예시 앱 정책이며, 보편적인 법적 요건을 나타내는 것이 아닙니다. 실제로 필요한 통지나 동의는 대상 지역, 서비스 약관, 처리 목적에 맞게 결정해야 합니다.

policy_gate.py에 다음 코드를 저장합니다. 외부 패키지는 사용하지 않습니다.

from __future__ import annotations
import argparse
import hashlib
...

python policy_gate.py

모든 케이스가 PASS가 되어도, 아직 실제용 파일은 생성되지 않습니다.

[PASS] 안내로의 동의가 없음: action=human_handoff reason=consent_missing
[PASS] 신고된 메시지를 최우선으로 처리: action=human_handoff reason=reported-message
[PASS] 환불 상담을 우선 큐로 이동: action=priority_queue reason=billing-keywords
...

후보 JSON의 action을 auto_delete로 변경하여 실행합니다.

policy_gate.py

허용 목록에 없기 때문에, 재생 전에 거부됩니다. AI 지침이 지켜지지 않았더라도, 실행 경계에서 막을 수 있습니다.

담당자가 출력 차분(diff)과 재생 결과를 확인한 후, 승인자 이름을 지정합니다.

APPROVER=reviewer-a python policy_gate.py --approve

생성된 파일을 검증합니다.

python policy_gate.py --verify-approved policy.approved.json

policy.approved.json 내부의 규칙을 나중에 수정하면, 해시 불일치로 거부됩니다. 하지만 SHA-256은 인증이나 권한 관리의 대용품이 아닙니다. 실제 운영 환경에서는 승인된 파일을 인증된 설정 스토어에 저장하고, 변경 이력과 롤백 지점도 관리해야 합니다.

SDK 고유의 수신 이벤트는 규칙 엔진으로 직접 전달하지 않고, 앱 측에서 작은 입력 형식으로 변환합니다.

Tencent RTC로 DM을 수신
↓
앱의 Adapter에서 정규화
...

연결 시 원칙은 다음 3가지입니다.

• 후보 파일을 운영 프로세스에서 읽지 않는다
• human_handoff를 '처리 완료'가 아닌 '담당자 확인 대기'로 표시한다 - 규칙 실행 결과에 policy_revision과 reason을 남긴다

특히 3번째 점이 중요합니다. '왜 우선 큐에 들어갔는지'를 나중에 확인할 수 없다면, 오분류를 규칙 개정으로 반영할 수 없습니다. DM 본문을 감사 로그에 복제해야 할 필요는 없으므로, 본문 저장 범위와 보존 기간은 별도로 설계합니다.

TUIChat에는 온디맨드 텍스트 메시지 번역에 대한 공식 절차가 있습니다. 대응하는 콘텐츠 형식, 언어, 에디션별 조건은 변경될 수 있으므로, 내장하기 전에 공식 문서를 확인해야 합니다.

번역 표시와 모더레이션 판정은 같은 판단으로 하지 않는 것이 안전합니다. 예를 들어, 번역문에 '사기'가 나타났다는 이유만으로 자동 조치를 취하면, 문맥이나 번역 오차를 포함하게 됩니다.

선택지는 다음과 같이 정리할 수 있습니다.

다국어 대응이 필요하다면, 먼저 각 언어의 합성 fixture를 추가합니다. 단순히 일본어 키워드를 늘리는 것만으로는 부정(否定), 인용(引用), 비유(皮肉), 표기 오류 등을 충분히 다룰 수 없습니다.

AI를 사용할 가치가 있는 경우는, 규칙 후보 생성 빈도가 높고 사람이 JSON을 손으로 작성하는 부담을 줄이고 싶을 때입니다. 반대로, 규칙이 몇 개에 불과하고 거의 변하지 않는다면, AI 연동보다 수동 편집과 코드 리뷰가 더 간단합니다.

| 판단 대상 | AI 활용 | 최종 결정 |
|---|---|
| 자연어 요구사항에서 후보 JSON 만들기 | 적합하다 | 사람이 검토한다 |
| ... |

눈에 잘 띄지 않는 비용은 AI 이용료만 아닙니다. fixture 유지보수, 언어별 테스트, 검토 담당자 확보, 오분류 조사, 롤백 훈련까지 포함하여 판단해야 합니다.

'사기가 아닙니다'와 같은 부정문이나, 과거 DM을 인용한 문장에도 일치합니다. 처음부터 자동 조치에 사용하기보다는, 우선 큐나 사람 확인의 보조 수단으로 시작하는 것이 다루기 쉬운 설계입니다.

최소한 다음 케이스들을 추가해야 합니다.

• 부정문
• 인용문
• 전각/반각 또는 대문자/소문자의 차이
• 공백 문자, 첨부 파일만, 삭제된 메시지
• 여러 규칙에 동시에 일치하는 문장
• 동의 상태가 결여된 이벤트
• 번역 전후로 의미가 변하는 문장
• 신고 상태와 키워드 조건이 충돌하는 문장

이 샘플의 해시값은 승인 후 의도치 않은 변경을 감지하는 것입니다. 악의적인 변경이나 승인자 사칭을 방지하려면, 인증된 배포 경로(deployment path), 접근 제어(access control), 서명(signature), 감사 로그(audit log) 등이 별도로 필요합니다.

human_handoff

담당 큐(queue), 접수 시각(time of reception), 현재 상태(current status), 사용자에게 표시할 안내 메시지를 정의합니다. 단순히 'AI가 판단할 수 없었습니다'라고만 보여주고 대화를 끊지 않는 것이 중요합니다.

• 운영 프로세스는 승인된 파일만 읽는다
• 허용되는 액션(action)이 열거되어 있다
• 회신, 삭제, 차단 등 되돌릴 수 없는 작업이 포함되어 있지 않다
• AI가 알지 못하는 필드를 추가하면 검증에 실패한다
• 규칙의 우선순위가 중복되지 않는다
• 부정(negation), 인용(quote), 다국어, 빈 메시지를 재생했다
• 판단 결과에 정책 수정 버전(policy revision)과 이유를 남긴다
• 사람이 확인 중임을 사용자에게 표시할 수 있다
• AI 서비스가 중단되어도 승인된 규칙이 작동한다
• 직전의 승인된 버전을 되돌리는 절차가 있다

채팅에서 설정 자체를 할 수 있다는 것은 편리합니다. 하지만 운영 투입(production deployment)의 신뢰성을 확보하는 것은 자연스러운 답변이 아니라, 허용 목록(allow list), 재생 가능한 테스트(replayable test), 사람의 승인(human approval), 그리고 변경 감지입니다. AI를 운영상의 판단자가 아니라, 검사 가능한 후보 생성자(candidate creator)로 배치하면, 편리함은 유지하면서 책임 소재를 명확히 할 수 있습니다.

관련 관계 공개: 필자는 Tencent RTC의 콘텐츠 제작에 참여하고 있습니다. 본고는 Tencent RTC 공식 문서를 구현상의 참고 자료로 사용했습니다.