AI가 테스트를 실행하면, 누가 AI를 테스트하나 — Jev 자동 플레이의 실행 감사

야간 자동 플레이 뒤 실패 표시가 떴다고 해 보겠습니다. 캐릭터는 바닥 아래인데 로그는 is_alive: true입니다. 게임 물리 문제일까요? Jev의 잘못된 선택일까요? 오래된 상태를 넣었거나 기준을 잘못 잡은 하네스 문제일까요? 결과가 같아도 고칠 곳은 다릅니다.

자동화가 늘수록 질문이 남습니다. 게임을 테스트하는 AI는 누가 어떤 근거로 검토할까요?

TypeSafe의 Agent Trace Observability 사례는 고객 지원 에이전트의 실행을 지시문, 대화의 각 차례, 도구 호출과 인자·결과, 마지막 응답, 남아 있다면 고객 피드백까지 살펴봅니다. 검토 결과는 자동 종료, 버그 아님, 사람 검토, 우선 검토, 이슈 등록, 온콜 호출로 이어집니다. 특정 업무를 게임에 그대로 옮기기보다, 최종 답 하나가 아니라 실행의 맥락을 살핀다는 관점이 유용해 보입니다.

게임에서는 선택과 실행 사이를 봐야 한다

게임 테스트의 대화 차례는 상태를 읽고 행동을 선택하는 각 step에 해당합니다. 그 기록에는 run ID와 테스트 지시문(버전 포함), Jev에게 전달한 상태, 그 시점에 허용한 행동 목록, Jev의 선택과 신뢰도, Unity가 행동을 수락했는지 거부했는지, 실행 뒤 실제 상태가 무엇이었는지가 시간 순서대로 있어야 합니다. 최종 failed만으로는 어긋난 지점을 알 수 없습니다.

이 연결을 보면 비슷한 실패를 세 갈래로 나눌 수 있습니다. Unity가 허용된 행동을 실행했는데 게임 상태가 불변식을 어겼다면 게임플레이 결함일 수 있습니다. 허용된 행동 가운데 Jev가 부적절한 선택을 반복했다면 판단이나 상태 표현을 살펴야 합니다. Jev에게 보낸 값이 낡았거나, 허용 행동 목록과 Unity의 실제 실행 규칙이 달랐거나, 하네스의 판정 시점이 틀렸다면 테스트 환경의 결함일 수 있습니다. 한 화면만 보는 대신 무엇을 봤고 → 무엇을 골랐고 → Unity가 무엇을 했고 → 실제로 어떤 결과가 났는지를 이어야 원인을 좁힐 수 있습니다.

예를 들어 confidence가 낮으면 자동 진행을 멈추고 사람 검토로 보낼 수 있습니다. TypeSafe 문서에서 confidence는 선택지의 확률 분포로 계산한 확신의 신호입니다. 허가나 정답의 보증은 아닙니다. 권한 밖의 행동과 파괴적 작업은 수치와 무관하게 코드가 실행 전에 차단해야 합니다.

if (!allowedAtThisStep(choice) || isDestructive(choice))
{
    RecordDecision("blocked", choice, confidence);
    StopRun();
    return;
}

이 기록은 감시용 장식이 아니라 실패를 게임 코드, 에이전트 판단, 하네스 중 어디서 고칠지 결정하는 근거입니다. 정상 실행은 닫고, 예상 밖의 결과는 검토하고, 재현 가능한 결함은 이슈로 남길 수 있습니다. 권한 위반은 일반 품질 판정과 분리해 우선 대응해야 합니다. 계속할 이유보다 멈출 이유가 먼저 보이는 순간입니다.

Rekon이 보존하는 것과 아직 하지 않는 것

Rekon은 이런 판단을 대신하는 감사 시스템이 아닙니다. 현재는 게임 코드가 명시적으로 캡처를 요청할 때 영상·로그·게임 상태를 보존합니다. Jev 판단을 자동 수집하거나 권한을 검사해 실행을 멈추지는 않습니다. 남길 상태·행동과 안전 경계는 게임별 하네스에서 정해야 합니다. Jev 자동 플레이 캡처 연결도 같은 경계를 전제로 합니다.

자동화의 성숙도는 밤새 몇 번 플레이했는지만으로 설명되지 않는 것 같습니다. 실패한 run에서 에이전트가 본 것, 허용된 것, 실제로 한 일을 대조해야 결과에 책임을 붙일 수 있습니다. 게임, 판단, 테스트 중 무엇이 어긋났는지 밝히는 일은 아직 사람 몫입니다.