Jev가 게임을 플레이할 때, 버그는 누가 기록하나

게임을 대신 플레이하는 에이전트가 생기면 반복 테스트도 자연스럽게 줄어들 것처럼 보입니다. 그런데 플레이하는 사람이 사라지면 함께 사라지는 역할이 하나 있습니다. 화면을 보다가 "방금 뭔가 이상했는데"라고 말해 주는 사람입니다.

2026년 9월 15일 TypeSafe AI가 Jev를 early access로 공개하며 Doom 플레이 데모를 함께 소개했습니다. 빠른 AI가 게임을 계속 움직일 수 있다는 장면도 흥미롭지만, QA 엔지니어에게는 그다음 질문이 더 중요합니다. 자동 플레이가 이상한 상태에 도달했을 때, 그 직전에는 무슨 일이 있었을까요?

Jev가 실제로 한 일

Jev는 자유로운 문장을 만드는 챗봇보다 코드 안의 판단 함수에 가깝습니다. 게임이 구조화한 현재 상태와 미리 정한 행동 후보를 보내면, Choice 같은 타입이 정해진 결과로 선택·확률·신뢰도를 돌려줍니다. 게임 코드는 그중 허용된 행동만 실행합니다.

공식 설명에는 중요한 단서도 있습니다. Doom 데모는 화면 이미지를 본 것이 아니라 텍스트를 포함한 구조화 상태를 입력으로 썼고, 비AI 봇이 더 잘 플레이할 수도 있다고 밝힙니다. Jev가 모든 게임을 설치 즉시 플레이하는 범용 봇이라는 뜻은 아닙니다. 어떤 상태를 보여줄지, 어떤 행동을 허용할지, 선택한 행동을 Unity에서 어떻게 실행할지는 여전히 프로젝트 코드가 맡아야 합니다.

자동 플레이가 만드는 새 공백

사람이 플레이할 때는 캐릭터가 벽에 끼거나 같은 행동을 반복하면 곧바로 알아챕니다. 영상을 저장하고, 기억나는 조작을 적고, 로그를 붙입니다. 자동 플레이는 밤새 더 많은 경로를 탐색할 수 있지만, 아침에 남는 것이 position invalid 한 줄뿐이라면 개발자는 다시 그 경로를 걸어야 합니다.

테스트 실행 수가 늘어난 만큼 실패의 증거도 함께 늘어나야 합니다. 최종 상태만 저장해서는 부족합니다. 어떤 상태를 Jev에 보냈는지, 무엇을 선택했는지, 신뢰도는 얼마였는지, Unity가 실제로 어떤 결과를 만들었는지가 시간 순서대로 남아야 합니다. 이것은 게임 상태 스냅샷 하나로 끝나는 문제가 아니라, 실패 직전 구간을 보존하는 문제입니다.

이상은 게임이 판단하고, 증거는 Rekon이 남긴다

역할을 나누면 연결은 단순해집니다. Jev는 고수준 행동을 고릅니다. Unity는 그 행동이 현재 상태에서 유효한지 다시 확인하고 실행합니다. 게임의 테스트 코드가 불변식 위반을 판단합니다. 그리고 그 지점에서 Rekon 캡처를 호출합니다.

using RekonOps.Rekon;

Debug.Log($"[Jev] step={step} action={actionName} confidence={confidence:F2}");
RekonContext.Add("jev.step", step.ToString());
RekonContext.Add("jev.action", actionName);
RekonContext.Add("jev.confidence", confidence.ToString("F2"));

if (anomalyDetected && !captureRequested)
{
    captureRequested = true; // 다음 자동 플레이 실행을 시작할 때 false로 초기화
    RekonContext.Add("anomaly.reason", reason);
    Rekon.Capture($"Jev 자동 플레이 이상: {reason}");
}

매 step의 행동은 로그에 누적하고, 현재 step·행동·신뢰도는 컨텍스트에 넣습니다. captureRequested는 한 실행에서 같은 이상이 여러 frame 이어져도 리포트가 한 번만 생성되게 막고, 다음 실행을 시작할 때 초기화합니다. 이상 조건이 처음 참이 되면 Rekon.Capture()가 핫키와 같은 경로로 캡처를 시작합니다. PC/Mac/Linux의 Play Mode나 Standalone 환경에서 FFmpeg가 준비되어 있다면 직전 약 60초의 영상과 로그, 기본 게임 상태를 함께 남길 수 있습니다. 영상이 어떻게 과거 시점을 보존하는지는 롤링 버퍼 방식에 정리했습니다.

무엇을 이상으로 볼 것인가

이 부분은 Jev도 Rekon도 대신 정해 주지 않습니다. 프로젝트가 정상 상태의 경계를 알아야 합니다.

• 이동 명령 뒤 일정 시간 동안 위치가 바뀌지 않는다
• 같은 행동이 N회 반복되는데 진행 상태가 그대로다
• 체력이 0인데 Alive 상태가 유지된다
• 씬 전환이나 전투가 제한 시간을 넘긴다
• Jev의 신뢰도가 임계값 아래로 반복해서 떨어져 러너가 SafeStop으로 전환한다

마지막 항목은 게임 버그라고 단정할 수 없습니다. 상태 정보가 부족하거나 행동 후보가 잘못 설계됐을 수도 있습니다. 그래서 낮은 신뢰도는 실패 판정보다 "검토할 구간을 남기는 신호"에 가깝습니다. 모든 낮은 신뢰도에 캡처를 걸면 리포트만 넘치므로, 반복 횟수나 진행 정체 같은 게임 조건과 함께 묶는 편이 낫습니다.

자동화와 품질 책임은 다르다

Jev와 Rekon이 자동으로 연결되는 완성품은 아직 아닙니다. 게임별 상태·행동 어댑터와 이상 조건을 직접 설계해야 합니다. Rekon 영상 캡처도 현재는 데스크톱과 FFmpeg가 전제이며, 모바일에서는 영상 없이 로그와 상태 중심으로 접근해야 합니다. 이 경계를 숨기면 멋진 데모는 만들 수 있어도 반복 가능한 QA 인프라는 만들기 어렵습니다.

자동 플레이의 가치는 사람이 걷지 못한 경로를 더 많이 걷는 데 있습니다. 품질 엔지니어링의 가치는 그중 실패한 경로가 다시 설명 가능한 증거로 남게 하는 데 있다고 생각합니다. Jev가 행동을 고르고, 프로젝트 코드가 이상을 판단하고, Rekon이 직전 맥락을 붙잡는 구조라면 자동 플레이는 단순한 데모를 넘어 실제 테스트 러너에 조금 더 가까워집니다.