에이전트 업무일지Agent work log · 2026-09-09

AI 게임 공장: 완료 보고 옆에 실제 확인한 것을 적기 시작했다

기록일 2026. 8. 3.수정 2026. 9. 9.

표시 날짜는 이 글이 다루는 작업의 대표 기록일이며, 당시 발행된 글을 뜻하지 않습니다. 이후 회고와 적용 방법은 2026년 9월에 정리했습니다.

이 글의 목적

AI의 ‘완료’ 보고를 그대로 받아들이면 안 되는 이유를, 같은 시기 네 프로젝트가 서로 다른 단계에 멈춰 있던 사례로 보여준다.

핵심 내용

종이새벽은 컨셉 잠금, 달빛 등불은 화면·조작 미통과, Stormglass Orbit은 웹·macOS 출시후보(모바일 미검증), Current Canticle은 출시후보(외부 플레이 별도) — 같은 ‘완료’ 밑에 네 가지 다른 상태가 섞여 있었다.

읽고 나서

AI가 ‘완료’라고 보고하면 어느 환경에서 어떤 행동까지 확인했는지 되물어, 상태를 최소 두 칸(대상 버전·확인 환경)으로 나눠 기록한다.

연재 목차

먼저 답하면

지금 남은 원장에는 이후에 개정된 규칙도 섞여 있어서, 지금 보이는 체크 항목 전부가 처음부터 있었다고 볼 수는 없다. 그래서 여기서는 날짜가 적힌 개별 게임의 상태만 기준으로 삼는다.

AI가 작업을 끝냈다고 하면 무엇을 기준으로 받아야 할까. 게임 공장을 진행하면서 ‘완료’라는 말 하나로는 상태를 알기 어려웠다. Codex 쪽 보존 프로젝트에서는 게임마다 품질 판정 원장을 두는 방식이 나왔다.

컨셉을 정했는지, 핵심 플레이가 되는지, 필요한 분량을 채웠는지, 어느 환경에서 확인했는지를 나눴다. 지금 남은 문서에는 나중에 고친 규칙도 섞여 있으니 처음부터 모든 검사를 갖췄던 것은 아니다.

8월 2일 기록의 종이새벽 배달단은 컨셉을 잠근 상태였다. 플레이 감각을 비교할 증거가 부족해 콘텐츠를 더 만들기 전에 다시 확인하도록 했다. 달빛 등불 공방에도 실제 화면과 조작 설명에서 미통과 항목이 남았다.

반면 Stormglass Orbit은 웹·macOS 범위의 출시 후보로 적혀 있다. 모바일은 실기기 검증을 하지 않아 따로 남겼다. Current Canticle도 출시 후보 표기는 있었지만 외부 플레이테스트와 스토어 운영은 다음 일이었다.

이 게임들을 한꺼번에 ‘전부 실패’나 ‘전부 완성’으로 묶으면 중요한 차이가 사라진다. 실행이 덜 된 게임과 내부 후보를 만든 게임, 배포가 남은 게임은 다음에 할 일이 다르다.

출시 후보라는 이름도 스토어에 제출했다는 뜻은 아니었다. 특정 환경의 검사 결과를 다른 환경으로 넓혀 쓸 수 없었다.

원장을 두면 상태를 돌아보기는 쉬워진다. 그렇다고 체크 표시가 늘어나는 만큼 품질이 좋아지는 것은 아니다. 어떤 버전을 어떻게 확인했는지가 빠지면 다시 같은 문제가 된다. 이후에는 검사 항목을 더하는 일뿐 아니라 그 검사가 잘못된 상태를 실제로 막는지도 보게 됐다.

진행표의 한 칸은 상태, 대상 버전, 확인 환경, 결과 위치로 구성할 수 있다. ‘웹 빌드 통과’와 ‘아이폰 조작 확인’을 서로 다른 칸으로 둔다. 전자가 통과했다고 후자의 빈칸을 채우지 않는 것이 핵심이다.

검사를 다시 해야 하는 조건도 적는다. 입력 코드나 저장 구조가 바뀌면 관련 통과 기록을 오래된 것으로 표시하고 재확인한다. 변경과 무관한 모든 항목을 무조건 다시 수행할 필요는 없지만, 어떤 의존성 때문에 재검사가 필요한지 설명할 수 있어야 한다.

이 원장은 다음 세션이 출발점을 찾는 데 유용하다. 다만 파일 경로나 캡처 이름만 등록했다고 증거가 생기지는 않는다. 실제 파일이 있고, 해당 버전에서 해당 행동을 했으며, 기대한 상태가 관찰되는지까지 대조해야 한다.