게임 채팅 AI 모니터링 개선기: 운영 이슈만 남기는 LLM 리포트 만들기

게임 채팅 로그는 운영 이슈를 가장 빨리 드러내는 신호 중 하나다. 문제는 모든 채팅을 사람이 계속 읽을 수 없고, 단순 키워드 필터만으로는 맥락을 판단하기 어렵다는 점이다.

이 글은 채팅에 AI를 붙였다는 이야기보다, 운영자가 실제로 볼 만한 리포트만 남기기 위해 false positive를 줄인 과정에 가깝다.

1. 배경

일반 채팅에는 운영에 도움이 되는 신호와 무시해도 되는 대화가 섞여 있다.

• 특정 스테이지나 보상에서 발생하는 버그 제보
• 핵, 매크로, 어뷰징 의심 정황
• 결제, 접속, 계정 관련 반복 이슈
• 단순 불만, 잡담, 농담, 밈, 개인 대화

처음부터 모든 메시지를 리포트로 만들면 운영자는 다시 노이즈를 사람이 걸러야 한다. 그래서 목표를 "채팅 요약"이 아니라 운영 액션으로 이어질 수 있는 신호 추출로 잡았다.

2. 문제 정의

2.1 운영자가 원하는 결과물

운영자가 필요한 것은 긴 대화 전문이 아니라 다음 정보였다.

반대로 아래와 같은 내용은 리포트가 되면 안 됐다.

• "게임 어렵다", "운영 별로다" 같은 일반 불만
• 한두 문장만으로 판단하기 어려운 모호한 표현
• 유저 간 농담이나 밈
• 증거 메시지 없이 모델이 추측한 내용

2.2 LLM을 붙이면 바로 해결될까?

LLM은 맥락을 읽는 데 강하지만, 운영 시스템에 붙일 때는 다른 문제가 생긴다.

• 일반 불만을 버그로 과대 해석할 수 있다
• 핵/어뷰징처럼 민감한 카테고리를 근거 없이 만들 수 있다
• 긴 대화 윈도우에서 중요한 메시지와 잡담을 섞어 판단할 수 있다
• 모델 응답 포맷이 조금만 흔들려도 저장/조회 로직이 깨질 수 있다

결국 중요한 것은 모델 호출 자체가 아니라, 모델 앞뒤에 있는 분석 단위, 프롬프트, 저장 기준, 테스트 더블이었다.

3. 처리 흐름

flowchart LR
    A["게임 채팅"] --> B["Kafka Consumer"]
    B --> C["채팅 윈도우 구성"]
    C --> D["LLM 분석"]
    D --> E["응답 정규화"]
    E --> F{"리포트 저장 대상?"}
    F -->|Yes| G["운영 리포트 저장"]
    F -->|No| H["none 처리"]

채팅을 메시지 단위로 바로 분석하지 않고, 일정 범위의 윈도우로 묶어서 분석했다. 단일 메시지만 보면 농담인지 신고인지 구분하기 어렵고, 너무 긴 윈도우는 잡담이 섞여 판단이 흐려진다.

그래서 dev/prod 환경별로 윈도우 기준을 조정하면서 운영자가 확인할 수 있는 단위로 맞췄다.

4. 프롬프트 개선 방향

프롬프트는 "문제가 있으면 알려줘"가 아니라, 무엇을 문제로 보지 말아야 하는지를 명확히 하는 쪽이 중요했다.

4.1 제외 기준을 먼저 박는다

다음과 같은 경우는 리포트 대상에서 제외하도록 했다.

• 일반 잡담
• 근거 없는 추측
• 단순 밸런스 불만
• 운영자가 확인할 액션이 없는 대화
• 카테고리를 특정할 수 없는 대화

LLM은 친절하게 무언가를 만들어내려는 경향이 있다. 그래서 "애매하면 만들지 말라"는 기준을 강하게 주는 것이 false positive를 줄이는 데 효과적이었다.

4.2 none도 정상 결과로 다룬다

운영 시스템에서 흔한 실수는 "문제 없음"을 예외처럼 다루는 것이다. 하지만 채팅 모니터링에서는 대부분의 윈도우가 문제 없는 대화다.

그래서 none 카테고리를 실패가 아니라 정상 분석 결과로 취급했다. 필요한 경우에는 none도 저장해 분석 이력과 모델 판단 흐름을 추적할 수 있게 했다.

4.3 근거 메시지를 요구한다

리포트에는 반드시 판단 근거가 있어야 한다.

나쁜 예: "핵 의심 유저가 있습니다."
좋은 예: "A 유저가 비정상 재화 획득을 언급했고, B 유저가 동일 현상을 확인했습니다."

운영자가 바로 확인할 수 있도록, 제목과 요약보다 근거 메시지 ID와 키워드가 더 중요했다.

5. 서버 쪽 가드레일

프롬프트만 믿으면 운영 기능으로 쓰기 어렵다. 모델 출력은 항상 흔들릴 수 있으므로 서버 쪽에서 한 번 더 정리했다.

5.1 응답 정규화

모델이 내려준 카테고리, 제목, 키워드, 근거 메시지를 그대로 저장하지 않고 정규화했다.

• 허용된 카테고리만 저장
• 빈 제목이나 과도하게 긴 제목 보정
• 키워드 개수와 길이 제한
• 존재하지 않는 메시지 ID 제거
• 리포트 저장 대상 여부를 별도 조건으로 판단

이 과정은 "모델을 믿지 않는다"기보다, 운영 데이터로 저장 가능한 형태를 보장하는 단계다.

5.2 confidence 기준은 보조 정보로 다룬다

처음에는 confidence를 강한 필터로 쓰는 방식을 고려했다. 하지만 모델이 부여한 confidence가 실제 운영 정확도와 항상 맞지는 않았다.

그래서 confidence는 임시로 약화하고, 카테고리/근거/제외 기준 중심으로 저장 여부를 판단하는 방향으로 조정했다.

6. 테스트 전략

실제 LLM을 호출하는 테스트는 느리고 불안정하다. 테스트에서는 fake LLM을 사용해 다음 케이스를 고정했다.

• 일반 대화는 리포트가 생성되지 않아야 한다
• 버그/핵/어뷰징 신호가 있으면 리포트가 생성되어야 한다
• none 카테고리도 정상 분석 결과로 처리되어야 한다
• 잘못된 메시지 ID나 빈 필드는 정규화되어야 한다
• 같은 윈도우가 중복 저장되지 않아야 한다

AI 기능을 테스트할 때 핵심은 "모델이 똑똑한지"가 아니라, 모델 응답이 흔들려도 서버 계약이 유지되는지다.

7. 배운 점

채팅 AI 모니터링에서 어려웠던 부분은 LLM 호출이 아니었다. 진짜 작업은 운영자가 볼 수 있는 리포트가 되도록 노이즈를 줄이고, 애매한 결과를 저장하지 않으며, 테스트 가능한 경계를 만드는 것이었다.

정리하면 다음 기준이 중요했다.

1. AI 결과를 곧바로 운영 데이터로 믿지 않는다
2. none을 예외가 아니라 정상 상태로 다룬다
3. 프롬프트에는 포함 기준보다 제외 기준을 더 명확히 쓴다
4. 리포트는 요약보다 근거 메시지가 중요하다
5. 테스트는 실제 모델보다 fake LLM 기반 계약 테스트를 우선한다

AI를 운영 시스템에 붙일 때는 "무엇을 찾아낼 것인가"보다 "무엇을 버릴 것인가"가 더 중요했다.