AI가 버그를 찾으면, 사람은 무엇부터 봐야 하나 — Jev로 자동 플레이 리포트 분류하기

자동 플레이가 끝난 아침에는 실패한 게임보다 실패한 리포트를 먼저 마주칠 때가 있다. 밤새 수백 번 실행한 결과를 열면 제목은 비슷한데, 하나는 진행을 막고 하나는 잠깐 멈췄으며 또 하나는 로그 한 줄만 남아 있다. 모두 같은 순서로 읽을 수는 없다. 먼저 볼 대상을 정하는 속도가 실행 속도를 따라가지 못하기 때문이다.

여기서 필요한 것은 버그를 한 숫자로 단정하는 점수라기보다, 왜 이 리포트를 먼저 봐야 하는지 드러내는 분류라고 생각한다. TypeSafe의 Score 문서는 한 기준을 순서가 있는 단계로 평가하고, 기준별 Score를 애플리케이션 코드에서 가중 결합하는 방법을 보여준다. 이 생각을 자동 플레이 리포트에 적용한다면, 심각도와 리포트 품질은 먼저 서로 다른 질문으로 다뤄야 한다.

점수에 합치기 전에 나눠 볼 것

심각도는 문제가 플레이나 제품에 미치는 영향이다. 진행을 막거나 저장 데이터를 망가뜨리는 실패와, 화면 가장자리에 잠깐 나타나는 어색함은 같은 우선순위일 수 없다. 재현 가능성은 같은 조건에서 다시 발생하는지에 관한 판단이다. 매번 같은 행동 뒤에 멈추는 문제와, 여러 번 실행한 뒤 한 번만 나온 문제는 조사 방법이 다르다.

증거 품질은 그 판단을 뒷받침할 단서가 충분한지를 묻는다. 자동 플레이의 상태, 선택한 행동, 실행 결과, 로그가 같은 시점에 연결되어 있는가. 리포트를 읽은 사람이 실패 지점까지 다시 따라갈 수 있는가. 증거가 빈약하다는 이유로 심각도까지 낮춰 버리면, 가장 위험하지만 아직 설명이 어려운 문제부터 대기열 아래로 밀릴 수 있다.

예를 들어 보스 전투 중 화면이 멈췄지만 마지막 상태와 로그가 빠졌다고 해 보자. 이때 필요한 표시는 “심각도 높음, 재현 여부 불명, 증거 부족”에 가깝다. 낮은 증거 품질은 낮은 심각도의 다른 말이 아니다. 셋을 따로 남겨야 누군가는 재현을 더 돌릴지, 로그를 보강할지, 지금 사람에게 넘길지 설명할 수 있다.

점수는 정렬을 돕고, 정책은 팀이 가진다

세 기준을 적당한 가중치로 합치면 긴 대기열을 정렬하는 데 쓸 수 있다. 다만 어떤 가중치를 쓸지, 어느 점수부터 P0라고 부를지는 Score가 대신 정해 주지 않는다. 게임의 진행 구조와 플레이어 영향, 출시 위험을 아는 코드와 팀이 정해야 한다. 점수는 그 정책을 실행하는 표현이지, 정책의 출처가 되어서는 안 된다고 생각한다.

Agent Trace 관찰성의 흐름을 빌리면, 최종 점수만 저장하는 대신 어떤 입력에서 각 판단과 경로가 나왔는지 함께 살펴볼 수 있다. 점수가 높은 리포트는 우선 큐로 보내고, 심각도는 높지만 재현이나 증거에 대한 신뢰도가 낮은 항목은 사람 검토로 라우팅하는 식이다. 사람이 보는 곳에 도착했을 때는 숫자뿐 아니라 판단 근거도 남아 있어야 한다.

Rekon의 증거 묶음은 이 분류 과정에 넣을 자료가 될 수 있다. 다만 현재 Rekon에 Jev 자동 플레이 리포트를 점수화하거나 자동 분류하는 기능이 있는 것은 아니다. 앞서 쓴 Jev와 캡처 글은 자동 플레이에서 무엇을 증거로 남길지 다뤘고, 여기서는 그 증거를 사람이 어떤 순서로 읽을지 생각해 본다. 캡처는 질문을 다시 조사할 재료를 남기지만, 그 질문의 중요도와 답을 정하는 책임까지 넘겨주지는 않는다.

자동화가 리포트를 줄 세울수록, 사람에게는 그 순서가 왜 나왔는지 되짚을 길이 더 필요해진다. 품질을 숫자로 표현하는 일은 가능해 보여도, 숫자가 모르는 것을 숨기지 않게 만드는 일은 여전히 팀의 몫인 것 같다.