AI가 게임 버그를 제대로 고치게 하려면? 재현·검증 환경 만드는 5단계
AI 코딩 에이전트에게 게임 코드를 보여 주고 “이 장면의 버그를 고쳐 달라”고 요청하면, 수정안은 빨리 나올 수 있습니다. 하지만 게임에서 중요한 것은 코드 밖에도 있습니다. 플레이어의 위치, 난수, 입력 순서, 저장 상태, 화면 변화와 프레임 시간까지 알아야 수정이 맞았는지 판단할 수 있습니다.
게임 개발자 카일 쿡스텔은 자신의 발표를 정리한 글에서 게임 자체를 AI가 관찰하고 되풀이해 시험할 수 있는 환경으로 만들자고 제안합니다. 여기서 ‘하네스’는 AI에 특별한 권한을 주는 장치가 아니라, 같은 상황을 다시 만들고 결과를 읽을 수 있게 하는 도구와 절차의 묶음입니다. 아래 내용은 그 제안을 실무 점검 순서로 재구성한 것입니다.
1. 같은 출발점을 먼저 만듭니다
버그가 매번 다른 위치에서 나타나면 AI가 코드를 고친 뒤에도 원인을 비교하기 어렵습니다. 테스트용 난수 시드를 고정하고, 시작 위치·장비·적의 상태처럼 결과에 영향을 주는 값을 함께 기록해 보세요. 같은 입력에서 같은 결과가 나오는 조건을 확보하면 ‘수정 전후에 무엇이 달라졌는지’ 확인하기 쉬워집니다.
다만 시드 하나만 고정한다고 모든 게임이 똑같이 재생되는 것은 아닙니다. 시간, 네트워크 응답, 병렬 처리와 외부 입력이 결과를 바꿀 수 있습니다. 재현이 흔들리면 이런 값도 테스트 조건에 포함해야 합니다.
2. 문제가 생긴 순간을 저장하고 되돌립니다
“보스를 만난 뒤 가끔 문이 열리지 않는다”는 설명보다 문제 직전의 저장 상태가 유용합니다. 플레이어·적·문·퀘스트의 핵심 상태를 저장하고, 그 상태로 다시 시작할 수 있으면 같은 장면에서 여러 수정안을 시험할 수 있습니다. 전체 게임을 처음부터 플레이할 필요도 줄어듭니다.
저장할 항목은 버그에 영향을 주는 값부터 정합니다. 예를 들어 문 문제라면 잠금 여부, 열쇠 보유 여부, 이벤트 진행 단계, 마지막 입력을 기록합니다. 파일 형식은 사람이 읽고 비교하기 쉬울수록 원인 추적에 도움이 됩니다.
3. 입력을 명령 기록으로 남깁니다
저장 상태가 ‘어디에서 시작했는가’를 말해 준다면 명령 기록은 ‘무엇을 했는가’를 알려 줍니다. 이동, 공격, 아이템 사용 같은 동작을 시간 순서로 기록하고 재생하면 AI와 개발자가 같은 경로를 따라 문제를 확인할 수 있습니다.
예를 들어 “저장 상태 A를 불러온 뒤 오른쪽 이동 2초, 공격 1회, 문 상호작용 1회”처럼 최소한의 재현 절차를 만들 수 있습니다. 입력 로그와 결과 로그를 함께 남기면 버그를 고쳤다는 주장도 같은 절차로 다시 검증할 수 있습니다.
4. 화면은 필요한 부분만 비교합니다
스크린샷은 화면 구성 오류를 찾는 데 도움이 되지만, 게임 화면 전체를 무작정 비교하면 애니메이션·파티클·시계 같은 변화가 실제 문제를 가릴 수 있습니다. 확인하려는 영역을 잘라 비교하고, 허용할 차이를 미리 정하는 편이 낫습니다.
예를 들어 체력 표시 오류를 확인한다면 UI 영역만 비교합니다. 이미지 차이가 줄었다고 기능까지 정상이라는 뜻은 아닙니다. 입력 결과와 게임 상태를 함께 확인해야 합니다.
5. 성능도 읽을 수 있는 결과로 남깁니다
AI가 “최적화했습니다”라고 말해도 실제 프레임 시간이 나빠질 수 있습니다. 같은 장면과 같은 입력을 사용해 수정 전후의 프레임 시간, 메모리 사용량, 느린 함수의 실행 시간을 비교해야 합니다. 측정 결과를 텍스트나 표로 내보내면 사람이 검토하기도 쉽습니다.
측정 조건도 함께 적어야 합니다. 기기 성능, 해상도, 빌드 설정이 바뀌면 수치가 달라질 수 있기 때문입니다. 한 번의 측정값보다 같은 조건에서 반복해 나타나는 차이를 봅니다.
작은 게임이라면 어디서 시작할까요?
처음부터 게임 구조 전체를 바꿀 필요는 없습니다. 가장 자주 재현해야 하는 버그 하나를 골라 테스트 시드, 저장 상태, 입력 순서, 기대 결과를 적은 작은 재현 묶음을 만들어 보세요. 그다음 화면 비교나 성능 측정이 필요한 경우에만 도구를 늘리면 됩니다.
원저자 역시 모든 프로젝트에 복잡한 구조가 필요한 것은 아니라고 덧붙입니다. 중요한 기준은 AI가 코드를 얼마나 많이 고쳤는지가 아니라, 같은 상황을 다시 실행하고 결과를 확인할 수 있는지입니다. 마지막 판단은 실제 플레이와 개발자의 검토로 마무리해야 합니다.
원문과 참고
이 글은 카일 쿡스텔의 2026년 10월 10일 글 Your Game Is A Harness를 읽고 핵심 개념을 한국어로 재구성한 글입니다. 원문의 경험과 견해를 보편적 성능 보장으로 해석하지 않았으며, 본문 예시는 설명을 위한 가상 상황입니다.
