빠른 릴리스 환경에서 채팅 버그 보고를 놓치지 않는 방법: 버전 정보, AI 정리, 담당자를 하나의 접수 대장으로 통합하기

릴리스 주기를 빠르게 돌리고 싶습니다. 반면, 사용자 의견을 수집하기 위해 별도의 폼이나 커뮤니티를 늘리면, 이번에는 아무도 담당하지 않는 창구가 늘어나게 됩니다.

그래서 기존 채팅 기능을 피드백 진입점으로 사용하게 되면 다음과 같은 문제가 발생합니다.

• '로그인이 안 돼요'라는 내용만으로는 어떤 앱 버전에 대한 보고인지 알 수 없다.
• 동일한 접수 이벤트의 재전송으로 이슈 후보가 중복된다.
• AI 요약이 자연스러워서 재현 조건까지 확인된 것처럼 보인다.
• 담당자에게 전달했다고 생각해도, 사용자 입장에서는 상황을 파악할 수 없다.
• 번역문과 원문이 섞여 나중에 의미를 확인할 수 없다.

본 글에서는 채팅을 단순한 게시판이 아니라, 버전 정보가 포함된 피드백 접수 대장으로 취급합니다. AI는 분류 후보 생성에만 국한하고, 담당 지정, 공개 여부, 해결 판단은 사람이 주도하는 구조입니다.

빠른 릴리스 환경에서는 같은 문장이라도 버전이 다르면 다른 버그일 수 있습니다. 반대로 표현이 달라도 같은 버전·같은 조작으로 발생했다면 하나의 문제로 취급할 가능성이 있습니다.

따라서 채팅에서 다음 정보를 하나의 접수 레코드에 고정합니다.

사용자의 원문
+ 메시지 ID
+ 앱 버전
...

AI가 개선할 수 있는 부분은 요약, 분류 후보, 추가 질문 초안 작성 정도입니다. AI만으로는 실제로 재현했는지 여부, 수정 책임자가 누구인지, 해결되었는지를 확정할 수 없습니다.

다음 두 건이 채팅으로 접수되었다고 가정해 보겠습니다.

A: v4.8.0 / iOS / '로그인 화면에서 진행할 수 없습니다'
B: v4.8.1 / iOS / '로그인이 안 돼요'

문장 내용만 AI에게 전달하면, 같은 문제로 묶을 가능성이 있습니다. 하지만 만약 v4.8.1 버전에서 인증 처리를 변경했다면, 각각 따로 조사해야 할 수도 있습니다.

게다가 네트워크 재연결 등으로 A의 접수 이벤트가 재전송된 경우, 본문 내용만 키(Key)로 사용하면 다음 두 가지 중 하나가 됩니다.

• 동일한 보고를 2건 등록한다.
• 같은 문장을 작성한 다른 사용자의 보고까지 중복으로 처리한다.

중복 판정에는 본문 내용이 아닌, 채팅 기반에서 얻은 고유 메시지 식별자(Unique Message Identifier)를 사용합니다. 버전을 넘나드는 통합 작업은 자동 처리가 아닌 담당자의 판단에 남겨둡니다.

Tencent RTC의 Social Messaging은 1대1 채팅, 그룹, 커뮤니티, 리치 미디어, 라이브 스트리밍 룸 내 채팅 등을 다루는 시나리오로 안내되고 있습니다.

본 글에서는 Tencent RTC의 채팅을 사용자 접점으로 삼고, 다음 처리는 앱 측 서비스로 구현합니다.

Tencent RTC의 채팅
↓
수신 어댑터(Receiving Adapter)
...

AI에게 채팅 전송 권한이나 이슈 종료 권한을 직접 부여하지 않는 것이 핵심입니다.

Node.js 20 이상 버전을 전제로 합니다.

mkdir versioned-chat-feedback
cd versioned-chat-feedback
npm init -y
...

package.json에 테스트 명령어를 추가합니다.

{
"type": "module",
"scripts": {
...

src/inbox.ts를 생성합니다.

import { createHash, randomUUID } from "node:crypto";
export type ModerationResult = "ALLOW" | "REVIEW" | "BLOCK";
export type FeedbackState = 
...

이 모델에서는 AI가 제안을 반환하더라도 state는 변경되지 않습니다. 분류 결과가 그럴듯해 보여도, 담당자가 확정한 것은 아니기 때문입니다.

처음부터 실제 LLM(Large Language Model)을 연결하면, 워크플로우의 결함과 모델의 불안정성을 구분하기 어려워집니다. 먼저 고정 응답으로 확인합니다.

src/demo.ts
:

import { FeedbackInbox, type SuggestionEngine } from "./inbox.js";
const fakeAi: SuggestionEngine = {
async suggest(input) {
...

실행합니다.

npx tsx src/demo.ts

출력 예시입니다.

접수 ID: ...
상태: TRACKED
담당: mobile-oncall

이 문자열을 채팅으로 회신하면 사용자는 '전송 완료'뿐만 아니라 현재의 접수 상태도 확인할 수 있습니다. 내부용 AI 요약은 회신하지 않고, 필요한 경우 사람이 편집한 추가 질문만 전송합니다.

test/inbox.test.ts

:

import assert from "node:assert/strict";
import test from "node:test";
import { FeedbackInbox, type IncomingFeedback } from "../src/inbox.js";
...

실행합니다.

npm test

실제 구현에서는 사용 중인 Tencent RTC 채팅 SDK 또는 UI 컴포넌트로부터 받은 텍스트 메시지를 IncomingFeedback으로 변환합니다.

연결 시 애플리케이션 측에서 수행해야 할 처리는 다음 네 가지입니다:

• 수신 메시지의 식별자를 sourceMessageId로 설정하기
• 앱의 빌드 정보로부터 appVersion과 platform을 추가하기
• 현재 화면명을 개인정보를 포함하지 않는 열거형 값으로 변환하기
• publicReceipt()의 결과를 채팅으로 회신하기

SDK 고유의 수신/전송 메서드명은 채택하는 SDK와 버전의 공식 문서를 따르십시오. 본 기사의 접수 서비스는 그 외부에 위치하는 애플리케이션 계층입니다.

TUIChat에는 텍스트 메시지를 온디맨드로 번역하기 위한 공식 절차가 있습니다. 해당 콘텐츠 유형, 언어, 에디션별 조건은 도입 전에 공식 페이지에서 확인해 주십시오.

접수 대장에서는 번역문으로 originalText를 덮어쓰지 않도록 합니다.

type DisplayTranslation = {
sourceMessageId: string;
sourceLocale: string;
...

번역은 표시 보조 수단입니다. Issue화나 모더레이션 과정에서 의미가 논쟁거리가 될 경우 원문으로 되돌아갈 수 있도록, 원문과 번역문을 별도의 데이터로 취급합니다.

본 서비스 연결 전에 다음 체크리스트를 수행합니다:

• 동일한 메시지 이벤트를 2회 투입해도 접수 ID가 증가하지 않는지
• 동일한 본문이라도 메시지 ID가 다르면 다른 보고서로 남는지
• 서로 다른 앱 버전을 AI가 임의로 하나로 통합하지 않는지
• AI 이용 동의가 없는 보고서를 AI에게 보내지 않는지
• 모더레이션이 REVIEW인 경우 AI 처리보다 먼저 중단하는지
• AI가 정의되지 않은 카테고리를 반환했을 때 저장을 거부하는지
• AI의 제안만으로는 상태나 담당자가 변경되지 않는지
• 담당자가 없는 레코드를 Issue 추적 완료로 만들 수 있는지
• 채팅 상에서 접수 ID와 상태를 확인할 수 있는지
• 번역 표시 후에도 원문을 참조할 수 있는지
• 해결 통지를 보내기 전에 사람이 대상 버전으로 확인하는지

식별자가 대화 내에서만 고유하다면, conversationId + sourceMessageId의 복합 키로 사용합니다. 문자열 형식이나 보장 범위를 추측하지 말고, 이용할 SDK의 사양을 확인하십시오.

사용자에게 버전 번호를 입력하게 하면 미기입 또는 전사 오류가 발생합니다. 가능한 한 클라이언트 앱이 가진 빌드 정보로부터 부여하는 것이 좋습니다. 다만 웹 버전처럼 지속적으로 배포되는 환경에서는, 릴리스 번호나 커밋 식별자 등 팀 자체에서 추적 가능한 값을 별도로 설계해야 합니다.

URL 전체나 검색 쿼리를 그대로 screen에 넣으면 이메일 주소나 토큰이 혼입될 가능성이 있습니다. login, checkout, profile과 같은 허용 목록(whitelist)으로 정규화합니다.

possibleClusterKey는 검색 보조 수단에 불과합니다. 버전, OS, 조작 순서, 에러 내용이 다른 보고서를 하나로 통합하면 회귀 결함을 놓칠 가능성이 있습니다. 통합 후에도 원래의 접수 ID를 추적할 수 있도록 해야 합니다.

채팅을 이용할 수 없는 장애 상황에서는 채팅으로 보고할 수 없습니다. 서비스의 성격에 따라 상태 페이지나 다른 연락 경로를 준비해야 합니다. 다만 진입점을 늘린다면, 각 진입점에서 동일한 접수 대장으로 통합하고 담당자가 불분명한 별도의 큐를 만들지 않는 것이 중요합니다.

빠른 릴리스와 사용자 이해는 양립할 수 있지만, AI에게 채팅을 읽게 하는 것만으로는 운영이 될 수 없습니다.

필요한 것은 메시지에 버전 정보를 붙여 고정하고, 재전송을 Idempotent(멱등)하게 처리하며, AI의 정리 후보와 사람의 책임을 분리하는 것입니다. 사용자에게 보이는 접수 상태까지 반환할 수 있다면, 기존 채팅을 "아무도 소유하지 않는 새로운 창구"가 아니라 지속적인 개선으로 이어지는 진입점으로 만들 수 있습니다.

관계성 공개: 필자는 Tencent RTC와 관계가 있습니다. 본 기사의 제품 사양에 대한 설명은 구현 시 참조 자료로 Tencent RTC의 공식 문서 및 공식 솔루션 페이지를 사용했습니다.