QA 버그 티켓 중복 탐지와 담당 개발자 자동 매칭 AI 시스템 설계
QA 버그 티켓의 중복을 임베딩과 규칙으로 판별하고 컴포넌트 소유권과 과거 해결 이력을 결합해 담당 개발자를 추천하는 AI 시스템의 설계와 운영 방법을 정리합니다. 임계값, 검수 큐, 개인정보와 핵심 지표까지 함께 설명합니다.
TL;DR
QA 버그 티켓의 중복 여부는 제목만 비교하지 말고 재현 절차, 기대 결과, 실제 결과, 게임 버전, 플랫폼, 로그를 정규화한 뒤 BM25 검색과 임베딩 유사도를 함께 사용해 판단해야 합니다. 담당 개발자는 컴포넌트 소유권, 과거 해결 이력, 최근 코드 변경, 현재 업무량을 종합해 추천하되 최종 확정은 QA 리드나 PM이 검수하도록 하는 것이 안전합니다.
핵심은 AI가 티켓을 자동으로 닫는 것이 아니라 중복 후보와 담당자 후보를 빠르게 좁혀 트리아지 시간을 줄이는 것입니다.
QA 버그 티켓 중복 문제는 왜 반복될까?
게임 개발 프로젝트에서는 같은 결함이 여러 경로로 보고됩니다. QA는 재현 절차를 중심으로 작성하고 기획자는 사용자 영향 중심으로 설명하며 고객센터는 사용자의 불편을 자연어로 전달합니다. 표현은 달라도 근본 원인이 같을 수 있습니다.
반대로 문장이 비슷해도 실제 원인은 다를 수 있습니다. 예를 들어 ‘전투 중 화면 멈춤’이라는 제목은 네트워크 타임아웃, 셰이더 컴파일 지연, 메모리 부족, 애니메이션 상태 전이 오류를 모두 가리킬 수 있습니다.
따라서 중복 탐지 시스템은 다음 두 가지를 분리해야 합니다.
| 구분 | 판단 기준 | 처리 방식 |
|---|---|---|
| 표현 유사도 | 제목과 본문의 문장이 비슷한가 | 중복 후보 검색 |
| 원인 유사도 | 동일한 조건에서 동일한 결함이 발생하는가 | QA 검수 후 중복 확정 |
중복 확정은 기존 티켓을 닫는 행위와 연결되므로 표현 유사도만으로 자동 처리하면 안 됩니다.
AI 중복 탐지 시스템은 어떤 구조로 동작할까?
권장 구조는 규칙 기반 필터, 키워드 검색, 벡터 검색, 재순위화 모델을 차례로 적용하는 하이브리드 방식입니다.
flowchart TD
A[QA 버그 티켓 입력] --> B[텍스트 정규화 및 개인정보 마스킹]
B --> C{동일 해시 존재}
C -- 예 --> D[강한 중복 후보 생성]
C -- 아니오 --> E[BM25 키워드 검색 및 임베딩 검색]
E --> F[Cross-Encoder 재순위화]
F --> G{중복 점수 판정}
G -- 0.85 이상 --> H[중복 후보 검수 큐]
G -- 0.60 미만 --> I[신규 티켓으로 분류]
G -- 0.60-0.84 --> H
H --> J[QA 리드 또는 PM 확인]
J --> K[원본 티켓 연결 및 담당자 추천]1. 입력 데이터 정규화
비교 전에 티켓에서 변동성이 큰 표현을 정리합니다.
- 대소문자와 불필요한 공백을 통일한다.
- 타임스탬프, 세션 ID, 플레이어 ID처럼 매번 달라지는 값을 마스킹한다.
- ‘재현 절차’, ‘기대 결과’, ‘실제 결과’, ‘발생 빈도’를 별도 필드로 보존한다.
- 게임 버전, 플랫폼, 디바이스, 네트워크 상태를 구조화된 메타데이터로 저장한다.
- 로그와 영상 링크는 원문 전체를 임베딩하지 않고 요약 텍스트와 오류 코드만 우선 사용한다.
예를 들어 다음 두 티켓은 문장은 다르지만 비교 가능한 공통 필드를 갖습니다.
| 필드 | 티켓 A | 티켓 B |
|---|---|---|
| 증상 | 보스전 진입 후 화면 정지 | 보스방 로딩이 끝나지 않음 |
| 조건 | PlayStation 5, 버전 1.4.2 | PS5, 1.4.2 |
| 재현 절차 | 컷신 스킵 후 보스방 입장 | 컷신을 건너뛰고 보스방 이동 |
| 오류 코드 | BOSS_SCENE_LOAD_TIMEOUT | BOSS_SCENE_LOAD_TIMEOUT |
오류 코드와 재현 조건이 일치한다면 단순한 문장 유사도보다 강력한 중복 신호로 볼 수 있습니다.
2. BM25와 임베딩 검색 결합
BM25는 고유명사, 오류 코드, 스킬 이름처럼 정확한 토큰이 중요한 경우에 유리합니다. 반면 임베딩 검색은 ‘아이템 장착이 풀림’과 ‘장비 설정이 저장되지 않음’처럼 표현이 다른 문장을 연결하는 데 적합합니다.
기술 스택은 다음과 같이 구성할 수 있습니다.
| 영역 | 예시 기술 | 역할 |
|---|---|---|
| API | Python 3.12, FastAPI | 티켓 수집과 추천 결과 제공 |
| 검색 | Elasticsearch BM25 | 키워드와 오류 코드 검색 |
| 벡터 저장소 | PostgreSQL 16, pgvector | 티켓 임베딩 저장과 유사도 검색 |
| 임베딩 모델 | multilingual-e5-large 또는 BGE-M3 | 한국어와 영어 티켓 의미 비교 |
| 재순위화 | Cross-Encoder 계열 모델 | 상위 후보의 정밀한 중복 판정 |
| 연동 | Jira, Linear, GitHub 또는 사내 이슈 트래커 API | 티켓과 코드 소유권 연결 |
임베딩 모델은 운영 중 임의로 바꾸지 말고 모델명과 버전을 티켓별로 기록해야 합니다. 모델이 바뀌면 같은 티켓의 유사도 점수도 달라질 수 있기 때문입니다.
3. 중복 점수와 판정 임계값 설정
후보 티켓의 중복 점수는 하나의 모델 출력에만 의존하지 않는 편이 좋습니다. 다음은 각 판단 근거를 설명할 수 있는 점수 조합의 예입니다.
각 항목은 0과 1 사이로 정규화합니다. 오류 코드가 없는 티켓은 해당 항목을 0으로 고정하기보다 사용 가능한 항목만 재가중하는 방식이 더 합리적입니다.
운영 초기에는 다음과 같이 보수적인 구간을 둘 수 있습니다.
| 점수 구간 | 의미 | 자동 처리 |
|---|---|---|
| 0.85 이상 | 강한 중복 후보 | 검수 큐에 우선 배치 |
| 0.60 이상 0.85 미만 | 유사하지만 불확실함 | QA 확인 필요 |
| 0.60 미만 | 중복 근거가 약함 | 신규 티켓 후보 |
이 값이 모든 프로젝트에 통하는 정답은 아닙니다. 실제 승인 데이터를 모아 정밀도와 재현율을 비교하면서 조정해야 합니다.
DUPLICATE_HIGH = 0.85
DUPLICATE_LOW = 0.60
def classify_duplicate(score: float) -> str:
if score >= DUPLICATE_HIGH:
return 'review_priority_duplicate'
if score >= DUPLICATE_LOW:
return 'review_required'
return 'likely_new'높은 점수라도 자동으로 원본 티켓을 종료하지 않고 ‘중복 후보’ 상태로만 표시하는 것이 중요합니다.
담당 개발자 자동 매칭은 어떻게 설계할까?
담당자 추천은 단순히 가장 많은 티켓을 처리한 개발자를 찾는 문제가 아닙니다. 해당 결함이 속한 시스템의 소유권과 현재 업무 상황을 함께 고려해야 합니다.
추천 점수는 다음처럼 구성할 수 있습니다.
각 변수의 의미는 다음과 같습니다.
| 변수 | 의미 | 데이터 출처 |
|---|---|---|
component_ownership | 해당 기능의 현재 코드 오너인가 | CODEOWNERS, 서비스 카탈로그 |
historical_resolution | 유사 버그를 실제로 해결한 이력이 있는가 | 과거 티켓과 커밋 |
code_change_proximity | 최근 관련 모듈을 변경했는가 | Git 커밋, PR, 브랜치 |
availability | 현재 업무량과 긴급도를 고려했을 때 얼마나 대응 가능한가 | 스프린트 보드, 업무량 |
on_call_fit | 해당 빌드나 플랫폼 담당 당번인가 | 온콜 일정, 릴리스 담당표 |
availability는 업무량이 적을수록 높은 점수를 주되 개발자에게 무조건 일을 몰아주는 방식으로 사용하면 안 됩니다.
추천 결과에는 반드시 추천 근거와 현재 할당량을 함께 표시해야 합니다.
예를 들어 시스템은 다음과 같이 보여줄 수 있습니다.
| 순위 | 개발자 | 추천 점수 | 근거 |
|---|---|---|---|
| 1 | 개발자 A | 0.88 | 전투 UI 오너, 최근 관련 PR 2건, 유사 버그 해결 4건 |
| 2 | 개발자 B | 0.76 | PS5 빌드 담당, 유사 티켓 해결 2건 |
| 3 | 개발자 C | 0.61 | 그래픽 모듈 오너지만 해당 기능 변경 이력 적음 |
추천 근거가 없거나 소유권 정보가 오래된 경우에는 담당자를 임의로 지정하지 말고 ‘수동 배정 필요’로 표시해야 합니다.
중복 티켓과 담당자를 연결하는 업무 절차는 어떻게 될까?
Step 1. 티켓 생성 시 구조화된 정보를 확보한다
제목만 필수로 받으면 중복 탐지 품질이 빠르게 떨어집니다. 다음 필드를 템플릿으로 고정합니다.
- 재현 절차
- 기대 결과
- 실제 결과
- 발생 빈도
- 게임 버전과 플랫폼
- 발생 지역 또는 기능명
- 로그와 오류 코드
- 영향도와 긴급도
자유 서술을 없앨 필요는 없습니다. 자유 서술을 유지하되 핵심 필드를 별도로 수집해야 검색과 통계가 안정적입니다.
Step 2. 기존 티켓에서 상위 후보를 검색한다
신규 티켓이 등록되면 최근 해결 티켓을 포함해 검색합니다. 열린 티켓만 검색하면 이미 해결된 동일 결함을 놓칠 수 있습니다.
권장 검색 범위는 다음과 같습니다.
- 동일한 오류 코드가 포함된 티켓
- 동일한 컴포넌트와 플랫폼을 사용하는 티켓
- 최근 12개월 내 해결된 유사 티켓
- 같은 릴리스 버전에서 발생한 티켓
- 같은 로그 패턴을 가진 티켓
검색 결과에는 후보 티켓 ID, 유사도 점수, 일치한 필드, 차이가 나는 필드를 함께 보여줍니다.
Step 3. 중복 여부를 검수하고 연결한다
QA 리드나 PM은 후보를 검토해 다음 중 하나를 선택합니다.
- 동일 결함: 기존 티켓에 링크하고 신규 티켓을 중복 상태로 전환한다.
- 관련 결함: 별도 티켓으로 유지하되 관련 이슈로 연결한다.
- 다른 결함: 신규 티켓으로 유지한다.
- 판단 불가: 추가 로그나 재현 영상을 요청한다.
이 결정값은 단순한 관리 기록이 아니라 다음 모델을 개선하는 라벨이 됩니다. 검수자, 결정일, 결정 사유를 저장하면 나중에 오탐과 누락을 분석할 수 있습니다.
Step 4. 담당자 후보를 추천하고 사람이 확정한다
중복으로 확인된 티켓은 기존 티켓의 담당자를 그대로 복사할 수 있습니다. 다만 기존 담당자가 퇴사했거나 팀이 변경된 경우를 대비해 현재 CODEOWNERS와 업무량을 다시 조회해야 합니다.
신규 티켓이라면 다음 순서로 추천합니다.
- 컴포넌트와 플랫폼의 1차 오너를 찾는다.
- 최근 3~6개월의 유사 티켓 해결 이력을 조회한다.
- 관련 모듈의 최근 커밋과 PR을 확인한다.
- 현재 스프린트 업무량과 릴리스 일정을 반영한다.
- 상위 3명의 후보와 추천 근거를 표시한다.
- 팀 리드 또는 트리아지 담당자가 최종 배정한다.
자동화 범위는 어디까지 허용해야 할까?
AI 시스템의 자동화 수준은 결함의 영향도에 따라 다르게 설정해야 합니다.
| 티켓 유형 | AI 권장 역할 | 사람 승인 |
|---|---|---|
| 낮은 영향도의 UI 문구 오류 | 중복 후보와 담당자 추천 | 선택적 승인 |
| 일반 기능 결함 | 중복 후보 생성과 우선순위 보조 | 필수 |
| 결제, 저장 데이터, 계정 관련 오류 | 검색과 근거 제공만 수행 | QA 리드와 PM 필수 |
| 크래시, 보안, 개인정보 관련 오류 | 유사 티켓 탐색과 알림 | 관련 책임자 필수 |
특히 중복 티켓 자동 종료, 우선순위 자동 하향, 담당자 자동 재배정은 별도의 승인 정책 없이 활성화하면 안 됩니다. AI의 확신도와 업무 규칙의 허용 범위는 서로 다른 문제이기 때문입니다.
시스템 품질은 어떤 지표로 측정해야 할까?
정확도 하나만으로는 운영 가치를 판단하기 어렵습니다. 다음 지표를 함께 관리해야 합니다.
| 지표 | 정의 | 확인할 문제 |
|---|---|---|
| 중복 정밀도 | 중복으로 추천한 티켓 중 실제 중복 비율 | 오탐이 많은가 |
| 중복 재현율 | 실제 중복 티켓 중 탐지한 비율 | 같은 버그를 놓치는가 |
| 잘못된 병합률 | 서로 다른 결함을 하나로 묶은 비율 | 위험한 자동화가 있는가 |
| 담당자 추천 수락률 | 추천 담당자가 최종 배정된 비율 | 소유권 데이터가 정확한가 |
| 평균 트리아지 시간 | 등록부터 분류와 배정까지 걸린 시간 | 업무가 실제로 빨라졌는가 |
| 검수 이탈률 | 검수자가 AI 추천을 무시한 비율 | 근거가 부족한가 |
처음부터 완벽한 모델을 목표로 하기보다 주간 단위로 검수 결과를 샘플링하고 임계값과 가중치를 조정하는 방식이 현실적입니다.
운영할 때 주의해야 할 데이터와 권한 문제
개인정보와 민감 정보 마스킹
QA 티켓에는 플레이어 ID, 이메일, 결제 정보, 내부 서버 주소가 섞일 수 있습니다. 임베딩 생성 전에 개인정보를 마스킹하고 원문 접근 권한과 검색 인덱스 접근 권한을 분리해야 합니다.
모델 버전과 설명 가능성 기록
다음 항목은 티켓 처리 이력에 남기는 것이 좋습니다.
- 임베딩 모델명과 버전
- 검색 시점과 대상 인덱스 버전
- 상위 후보 목록
- 각 점수와 일치 필드
- 최종 검수자와 결정 사유
- 담당자 추천 점수와 근거
이 정보가 있어야 모델이 바뀐 뒤 과거 결정이 왜 달라졌는지 설명할 수 있습니다.
피드백 루프의 편향 관리
과거 배정 이력만 학습하면 특정 개발자에게 업무가 계속 몰릴 수 있습니다. 추천 모델에는 현재 업무량, 휴가, 온콜 상태, 팀 변경 정보를 반영하고 일정 기간마다 업무 분배 편향을 점검해야 합니다.
도입 순서는 어떻게 정하는 것이 좋을까?
- 관찰 단계: 기존 티켓을 대상으로 중복 후보만 생성하고 실제 업무에는 반영하지 않는다.
- 보조 단계: QA 트리아지 화면에 후보 티켓과 추천 담당자를 표시한다.
- 승인 단계: 검수자가 승인한 경우에만 티켓 링크와 담당자 추천을 이슈 트래커에 기록한다.
- 제한 자동화 단계: 낮은 영향도의 반복 티켓에 한해 일부 상태 변경을 자동화한다.
- 정기 평가 단계: 중복 정밀도, 잘못된 병합률, 추천 수락률을 기준으로 모델과 규칙을 조정한다.
이 순서를 따르면 AI가 잘못 판단했을 때 기존 QA 프로세스를 멈추지 않고 원인을 추적할 수 있습니다.
자주 묻는 질문
티켓 제목만으로 중복 여부를 판단해도 되나요?
권장하지 않습니다. 제목은 검색의 시작점으로 활용하고 재현 절차와 오류 코드, 환경, 로그 패턴을 함께 비교해야 합니다.
임베딩 유사도가 높으면 자동으로 중복 처리해도 되나요?
아닙니다. 임베딩은 의미가 비슷한 후보를 찾는 도구입니다. 서로 다른 원인의 결함을 연결할 수 있으므로 중복 확정은 사람의 검수를 거쳐야 합니다.
담당 개발자를 완전히 자동 배정해도 되나요?
위험도가 낮은 반복 업무에서는 제한적으로 가능하지만 일반적으로는 상위 후보와 추천 근거를 제공하고 팀의 트리아지 담당자가 최종 확정하는 방식이 안전합니다.
정리
QA 버그 티켓 자동화의 핵심은 ‘AI가 판단을 대신한다’는 데 있지 않습니다. 정규화된 티켓 데이터에 BM25와 임베딩 검색을 결합하고 중복 점수의 근거를 표시하며 컴포넌트 소유권과 과거 해결 이력으로 담당자 후보를 좁히는 데 있습니다.
중복 확정과 담당자 배정은 처음부터 완전 자동화하지 말고 검수 가능한 보조 시스템으로 시작해야 합니다. 검수 결과와 업무 지표를 지속적으로 쌓으면 프로젝트 규모가 커져도 버그 트리아지의 속도와 일관성을 함께 개선할 수 있습니다.
