게임 개발용 AI 하네스를 설계하는 방법

게임에서 LLM을 효과적으로 쓰려면 코드뿐 아니라 게임 상태, 데이터, 실행 결과를 에이전트가 읽고 조작할 수 있게 만들어야 함 결정론적 상태 재현과 저장/불러오기를 개발 초기부터 설계하면, 에이전트가 같은 조건에서 변경을 반복 검증할 수 있음 단일 객체 타입과 명령 패턴으로 상태 변경을 구조화하고 데이터를 외부로 분리하면, 재컴파일 없이 게임을 조작하고 수치를 시험하는 반복 작업이 가능함 게임 시뮬레이션을 엔진과 별도 라이브러리로 분리하고, 이미지 차이와 텍스트 프로파일링 결과를 제공하면 에이전트가 변경 효과를 더 쉽게 평가할 수 있음 이 구조에서는 게임 자체가 하네스가 되어 전체 반복 주기를 수초 안에 돌릴 수 있음. 다만 주된 적용 대상은 큰 프로젝트이며, 작은 게임에는 이런 설계가 필요하지 않을 수 있음 웹 개발과 달리 게임이 LLM에 불투명한 이유 mood.site는 ChatGPT 웹 인터페이스에 코드를 복사해 넣는 방식으로 약 2~3주간 밤에 작업해, 총 20시간 정도에 구현한 사례임 직접 검증할 부분이 많고 작업 방식도 불편했지만, 실제로 작동하는 사이트를 완성했으며 이후 LLM 활용의 시험대가 됨 Claude Code와 후속 Claude 모델을 사용한 개인 경험에서는 웹 기술 스택으로 구현하지 못할 일이 거의 없다고 느낄 만큼 발전했음 게임 개발에서는 반대로 LLM이 제대로 작업하지 못하는 경험이 반복됨 약 15년의 게임 프로그래밍 경험에 비해 Svelte 웹 앱 경험은 적다는 점이 코드 품질 판단에 편향을 줄 수 있음 공개된 고품질 웹 프로젝트가 많다는 점은 웹 코드 품질을 기대할 근거지만, 게임 학습 데이터가 훨씬 적다는 것은 추정임 게임에는 코드로 쉽게 표현하기 어려운 에셋과 여러 시스템이 있으며, 웹에서 다루는 텍스트와 레이아웃도 그중 일부에 불과함 Three.js 기반 일회성 게임 생성은 에셋을 단순한 상자형 기본 도형으로 표현해 에셋 제작, 규격 맞춤, 처리 작업을 상당 부분 건너뜀 이런 결과물은 LLM이 만드는 평균적인 형태를 벗어난 창작자의 개성이 부족한 경우가 많지만, 모든 요소를 코드로 표현한다는 점에서는 LLM이 이해하고 수정하기 쉬움 기존 게임에서 중요한 비코드 요소가 불투명하게 남아 있으면, LLM은 그 요소를 조작하거나 변환하는 작업에서 막힘 여기서 다루는 문제는 사회적 영향이 아니라 개발 도구로서의 역량임 게임에서 LLM을 잘 쓰는 문제를 게임이나 LLM의 본질적 한계보...