게임 개발을 위한 AI 하네스 설계 방법: LLM 에이전트가 게임을 읽을 수 있게 만들기

핵심 주장: 당신의 게임이 하네스다

LLM이 게임 개발에 어려움을 겪는 이유는 코드를 잘 못해서가 아니라, 게임에는 언어 모델이 볼 수 없는 방대한 양의 비코드 상태가 포함되어 있기 때문입니다. 해결책은 구조적인 것입니다: 게임을 결정적(deterministic)이고, 주소 지정 가능(addressable)하며, 측정 가능하게 만들어 게임 자체가 AI 에이전트가 작업하는 하네스가 되게 하는 것입니다.

이것이 게임 프로그래머인 Kyle Kukshtel이 캘거리에서 열린 Indie Rodeo에서 했던 45분 강연을 각색한 블로그 게시물 "Your Game Is A Harness"의 핵심 주장입니다. 이 게시물은 2026년 10월 10일에 게시되었으며, Kukshtel은 이 글이 100% 인간이 작성했으며, 녹취록이 아닌 자신의 슬라이드에서 작성되었음을 명시적으로 밝혔습니다.

Kukshtel의 관점은 단호합니다: "LLM이 게임과 잘 작동하게 만드는 것은 맥락 문제이지, 게임이나 LLM이 '어떠하다'(또는 '아니다')는 것과 본질적으로 연결된 문제가 아닙니다."

LLM이 게임에 약해 보이는 이유

LLM이 웹 스택에 강한 이유는 웹 스택에서는 모든 것이 코드이고, 배울 수 있는 고품질의 오픈소스 웹 프로젝트가 방대하게 존재하기 때문입니다. 게임은 이 두 조건을 모두 깨뜨립니다.

Kukshtel의 주장은 세 부분으로 나뉩니다:

1. 게임은 코드만이 아니다. 게임에는 소스 코드로 쉽게 표현할 수 없는 에셋, 씬, 애니메이션, 오디오, 데이터가 포함됩니다. 이러한 구성 요소는 LLM에게 효과적으로 불투명합니다.
2. 훈련 데이터가 훨씬 적다. Kukshtel은 고품질의 공개 게임 프로젝트가 웹 프로젝트보다 수십 배 적다고 추정하며, 따라서 모델의 사전 지식(prior)이 더 약하다고 말합니다.
3. 표준 템플릿이 없다. 게임 엔진은 존재하지만, 게임 로직을 위한 표준화된 도구는 사실상 없습니다. 모든 게임이 각자의 필요를 다르게 표현하기 때문입니다.

이것이 원샷(one-shot) Three.js 데모가 작동하는 이유입니다: 게임을 단순한 프리미티브와 코드로 축소하여 에셋 생성과 규칙 준수 작업을 건너뜁니다. Kukshtel은 이것이 많은 데모가 '슬롭(slop)'처럼 느껴지는 이유이기도 하다고 지적합니다 — LLM 중간값 이상의 작가적 목소리가 부족하기 때문입니다.

실질적인 결과는 게임이 에이전트에게 블랙박스가 되고, 보이는 유일한 것은 작성된 코드뿐이라는 것입니다. 하네스만으로는 이 문제를 해결하지 못합니다. 하네스가 게임이 코드만이 아니라는 사실을 바꾸지 않기 때문입니다.

접근 방식을 동기화하는 컨텍스트 엔지니어링 기본

모든 LLM 호출은 세 부분으로 분해됩니다: 시스템 프롬프트(모든 사용자에게 공유되는 일반 텍스트), 어시스턴트 프롬프트(모델의 응답 방향을 형성하는 사이드카), 그리고 사용자 프롬프트(사실상 모든 입력이 들어가는 곳).

Kukshtel의 핵심 기계적 요점은 세션이 매 턴 새롭지 않다는 것입니다. 모든 이전 메시지는 새 메시지마다 다시 제출됩니다. 마치 각 플레이어가 자신의 기여를 추가하기 전에 다른 모든 사람의 기여를 다시 말해야 하는 놀이터 게임처럼 말입니다. 그 축적된 텍스트가 컨텍스트이며, 오직 최신 메시지만이 진정으로 새로운 것입니다.

이전 콘텐츠가 계속해서 새 작업에 영향을 주기 때문에, 세션 초기의 나쁜 콘텐츠는 퇴행된 결과를 낳습니다 — Kukshtel이 **컨텍스트 오염(context pollution)**이라고 부르는 실패 모드입니다. 떠오르는 컨텍스트 엔지니어링(context engineering) 분야는 오염을 최소화하면서 최상의 정보를 컨텍스트에 넣는 방법을 묻습니다.

Kukshtel은 Drew Breunig의 블로그 게시물 "How Contexts Fail and How to Fix Them"을 긴 컨텍스트 실패 모드에 대한 추가 읽기 자료로 인용합니다.

게임을 AI 에이전트가 읽을 수 있게 만들기

Kukshtel은 구체적인 체크리스트를 제시합니다. 그는 이러한 관행 대부분이 일반적으로 좋은 게임 개발이며, AI가 보상을 극대화한다고 지적합니다.

고정된 무작위성

게임 시작 시 시드된 무작위성의 단일 소스를 만들고, 모든 비결정적 호출을 그 소스를 통과시키세요. 코드가 게임플레이 동작을 결정하기 위해 30곳에서 Random.Float를 호출한다면, 30번째 호출도 매번 동일한 값을 생성하게 되며, 게임은 거의 모든 상태를 결정적으로 재현할 수 있습니다.

Kukshtel의 경고는 타이밍에 관한 것입니다: 생산 끝에 결정성을 개조하는 것은 매우 어렵고 마지막 순간에 근본적인 변경이 필요할 가능성이 높습니다. 첫 줄의 코드를 작성하기 전에 이 제약을 가정하세요.

스크린샷과 이미지 디핑

대부분의 엔진에는 내장 스크린샷 API가 있습니다. Kukshtel은 또한 에이전트가 특정 레이어에서 작업할 때 시각적 혼란을 줄일 수 있도록 UI 레이어와 게임플레이 레이어를 켜고 끌 수 있도록 권장합니다.

그러나 before/after 스크린샷만으로는 잘 작동하지 않습니다. 멀티모달 모델조차도 무엇이 변경되었는지, 변경이 목표를 향해 나아갔는지 파악하는 데 어려움을 겪습니다. Kukshtel은 이를 또 다른 형태의 컨텍스트 부패로 취급합니다: 프레임에서 변경 대상이 아닌 모든 것은 모델이 여전히 처리해야 하는 오염입니다.

해결책은 이미지 디핑입니다. Kukshtel은 무료 커맨드라인 이미지 디핑 도구인 odiff를 추천합니다. 두 이미지가 주어지면 odiff는 디프 이미지와 "85% 유사"와 같은 정량적 유사도 값을 생성합니다. 이 숫자는 에이전트가 턴마다 개선하려고 시도할 수 있는 안정적인 평가 기준선을 제공합니다.

결정적 상태와 저장/로드: 첫날부터

결정적 상태에 얼마나 가까운지 테스트하는 방법은 간단합니다: 게임에서 정확한 상태를 얼마나 쉽게 저장하고 로드할 수 있습니까? Kukshtel은 저장 및 로딩은 나중에 추가할 기능이 아니라, 처음부터 게임과 함께 프로그래밍할 때 개발의 슈퍼파워가 된다고 주장합니다.

사물 중심 개발(Thing-driven development): 모든 것에 대한 하나의 객체 유형

Kukshtel의 핵심 아키텍처 권장 사항은 게임의 모든 엔티티를 동일한 종류의 객체로 취급하고, 가능하면 Thing으로 유형화하는 것입니다. 그의 예에서 Thing은 stat 유형 값, isAlive 플래그, 유형 enum을 가지며, 구현 코드는 그 enum에 따라 분기합니다.

동기를 주는 관찰은 성숙한 객체 지향 게임 코드베이스에서 "나무는 개다"가 사실상 참이 된다는 것입니다: 나무는 메시와 콜라이더이고, 개는 메시와 콜라이더와 움직임입니다. 코드 관점에서 보면 동일한 구성 요소의 합성입니다.

에이전트에게 이점은 객체 모델의 단일 소스가 된다는 것입니다. Kukshtel은 100개의 클래스에 100개의 유형이 있으면 AI가 행동하려면 그 모두와 그 관계를 이해해야 하며, 이는 컨텍스트를 채우고 클래스를 확장할지, 유형을 변형할지, 새 클래스를 추가할지에 대한 모호성을 생성한다고 씁니다. 하나의 객체 유형으로 "AI는 변경할 위치를 매번 정확히 알 수 있습니다."

직렬화도 하나의 경로로 들어가고 하나의 경로로 나오는 것으로 축소되어 경쟁 조건과 다형적 역직렬화 문제를 피합니다. 게임은 거대한 Thing 목록이 됩니다. 저장은 하나의 경로를 통해 모두 저장하는 것이고 로딩은 그 반대입니다. Kukshtel은 또한 Dreams 제작자들과 유사한 시스템을 논의한 Wookash 팟캐스트 에피소드를 언급하고, Casey Muratori의 주장 — 이것이 보이는 것만큼 메모리 집약적이지 않다는 — 을 인용합니다.

주소 지정 가능한 상태와 커맨드 패턴

하나의 객체 유형으로 모든 상태 변경이 동일한 구조를 대상으로 하므로 커맨드 패턴이 실용적이 됩니다: 객체를 직접 변경하는 대신 처리 클래스를 통과하는 직렬화 가능한 커맨드 객체로 변경 사항을 캡처합니다.

이점은 정확한 재현입니다. 시작 상태와 직렬화된 커맨드 로그가 주어지면 플레이어에게 묻지 않고 정확히 무엇을 했는지 재생할 수 있습니다. AI 에이전트도 변경 사항이 상태에 어떤 영향을 미치는지 평가하기 위해 커맨드를 재생할 수 있습니다.

커맨드는 게임에서 시작될 필요도 없습니다. 텍스트 편집기에서 작성하거나 AI가 작성하여 컴파일 없이 실행 중인 인스턴스에서 재생할 수 있습니다. Kukshtel은 게임이 컴파일 없이 더 많이 변경될수록 에이전트 루프가 더 긴밀해진다고 강조합니다.

외부 데이터 관리

Kukshtel은 정적 운영 데이터 — 유형, attackDamage, walkSpeed, boatSpeed와 같은 사물이 어떻게 존재하는지 설명하는 값 — 는 게임 외부에 있어야 하며 게임에 컴파일되지 않아야 한다고 주장합니다. 데이터 변경은 데이터 소스를 편집하고 역직렬화하는 문제가 되며, 빌드나 편집기 액세스가 필요 없습니다.

그는 이것이 Cantata에서 사용된 정확한 워크플로우라고 설명합니다: 팀의 비프로그래머 약 7명이 빌드와 Depot라는 맞춤형 데이터 편집기를 받았고, 그가 새 빌드를 만들지 않고도 반복했습니다. 그는 지금 depot-editor.com에서 Depot를 독립 제품으로 전환하고 있습니다. 다른 팀은 Google Sheets나 맞춤 도구를 사용합니다; Riot Games는 자체 게임 데이터 서버에 대해 발표했습니다.

독립 시뮬레이션 (블랙박스 아키텍처)

Kukshtel은 게임의 시뮬레이션을 엔진에서 완전히 분리하여 자체 DLL 또는 라이브러리로 만들 것을 권장합니다. 엔진은 시뮬레이션에 커맨드를 보내고 업데이트된 상태를 다시 받은 다음, 상태 또는 이전 상태와의 디프를 해석합니다. 엔진은 의도적으로 "멍청하게" 유지됩니다: 시뮬레이션이 무언가가 움직였다고 말하면 엔진은 그것을 움직입니다.

구체적인 예: 엔진이 Thing에 대한 이동 요청을 보내고, 시뮬레이션이 대상이 유효한지 결정하고 이동을 해결하며, 엔진이 결과를 렌더링합니다. 핵심에 커맨드를 보낼 수 있는 것은 무엇이든 가능하므로 네트워크 프로그래밍이 훨씬 쉬워집니다 — 상태는 네트워크, LLM 또는 다른 곳에서 올 수 있습니다.

테스트도 다루기 쉬워집니다. Kukshtel은 게임 테스트가 주로 상태, 로직, 데이터가 밀접하게 결합되어 있어 고통스럽고, 분리된 시뮬레이션은 엔진이 실행되지 않은 상태에서 순수 C# 프로젝트와 표준 도구로 테스트할 수 있다고 주장합니다.

그는 이 패턴을 "블랙박스 게임 아키텍처"라고 부르며 Monster Train에 대한 Brian Cronin의 Roguelike Celebration 강연과 Solium Infernum 팀의 Game Data Podcast 에피소드를 인용합니다.

영향 평가: 에이전트가 읽을 수 있는 프로파일링

Unity, Unreal 또는 dotMemory와 같은 IDE의 전통적인 프로파일러는 인간 소비용으로 설계되었습니다 — 호출 스택과 그래프입니다. Kukshtel은 AI가 이러한 도구를 잘 사용하지 못한다고 관찰합니다. 에이전트에게 읽을 수 없기 때문입니다. 다만 Unity가 프로파일러를 에이전트가 읽을 수 있게 만드는 작업을 하고 있다고 언급합니다.

에이전트가 원하는 것은 텍스트입니다. Kukshtel은 캡처 출력을 콘솔에 덤프할 수 있는 무료 프로파일러인 samply를 추천합니다. 에이전트는 소스와 문서를 읽고, 캡처를 실행하고, 자신의 변경 사항을 자율적으로 평가할 수 있습니다.

전체 루프

이러한 기술을 결합하면 결정적 입력, 컴파일 없는 구조적 상태 수정, 격리된 검증, 영향 평가를 포함한 전체 사이클을 몇 초 안에 실행할 수 있는 에이전트 턴이 생성됩니다. 루프가 빠르기 때문에 '중요한' 변경에만 예약하는 대신 모든 변경에 대해 실행할 수 있습니다.

Kukshtel의 결론은 강연 제목입니다: 하네스는 당신의 게임입니다. 모든 게임은 이 모든 것이 가능하며, 즉 모든 게임이 자신의 하네스가 될 수 있습니다.

논의에서 나온 주의 사항과 반론

Hacker News 스레드(158점, 79개 댓글)는 상당한 의견 차이와 여러 확장을 표면화했습니다.

이 접근 방식은 대규모 3D 게임으로 확장되지 않을 수 있습니다. 댓글러 avaer는 Thing 접근 방식이 "성능 예산이나 계층화된 하위 시스템에 대해 막다른 길"이라고 주장했습니다. 수천 개의 Things로 구성된 30개 하위 시스템을 반복하고 복사하는 것은 프레임 시간 내에 불가능하며, 유일한 해결책은 완전한 재작성이라고 말했습니다. 그들은 ECS와 SOA를 다른 종류의 하네스가 필요한 아키텍처로 지적하고, 아트가 현대 게임의 생산 주기를 지배하며 자체 범주의 하네스가 필요하다고 언급했습니다. 또한 samply는 오버드로우를 진단하지 않으며, GPU 작업은 자체 절제와 속성 부여가 필요하다고 지적했습니다.

결정성은 제한적입니다. 댓글러 bob1029는 "LLM은 게임 개발의 코딩 측면을 완전히 해결했습니다. 그러나 이것은 결코 어려운 부분이 아니었습니다. 가깝지도 않습니다."라고 썼고, 여러 플랫폼에서 결정성을 유지하는 것이 문제가 되는 지점이라고 주장했습니다. 그들은 엔진 통합을 완전히 우회하는 대안으로 확산 모델을 제안했습니다.

에이전트는 직관에 반하는 방식으로 일관성이 없을 수 있습니다. 댓글러 andai는 프론티어 모델이 수주 간의 작업에도 단순한 Pong 게임에 기능을 변경하거나 추가하지 못하고 다른 것을 깨뜨리는 반면, 한 모델은 약 100배 더 복잡한 전체 게임을 원샷으로 만들었다고 보고했습니다. 그들은 차이가 분포 내 행동인지 추측했습니다.

일부 개발자는 동일한 기술로 강력한 결과를 보고합니다. 댓글러 vanyle는 스크린샷을 찍고 입력을 시뮬레이션하는 자동화된 테스트 시스템을 작성했으며, 이를 자신의 엔진 가이드(vectarineengine.com)에 문서화했습니다. 댓글러 theptip은 게시물이 자신이 독립적으로 도달한 것과 일치한다고 말했으며, 스크린샷과 분리된 시뮬레이션이 가장 큰 성과라고 덧붙였고, 에이전트는 무한히 인내심이 강하므로 "각 게임 메커니즘의 비디오가 포함된 대화형 디자인 문서를 만들어라"와 같은 프롬프트가 변경 사항 검토를 더 쉽게 만들 수 있다고 말했습니다. 또한 그들은 관찰 가능성(observability)이 게임 개발에서 저평가되어 있다고 지적하며, DPS와 체력에 대한 내보낸 시계열 메트릭이 에이전트에게 불균형적으로 도움이 될 것이라고 제안했습니다.

에이전트는 게임 스스로 계측할 수 있습니다. 댓글러 TeMPOraL은 Claude Code를 사용하여 1997년 PC 게임을 30분 만에 현대 하드웨어에서 실행하고, 점차 대부분을 디컴파일하고, 셰임된 DirectX DLL을 확장하여 Windows의 "Private Desktop" 기능을 사용해 헤드리스로 실행하고, 여러 게임 인스턴스를 병렬로 실행했다고 설명했습니다. 그들은 결론을 내렸습니다: "LLM이 게임을 계측하고 스스로 알아내도록 두세요."

이 관행은 오래된 관행입니다. 댓글러 hatthew는 "AI가 발명되기 전까지 사람들이 좋은 소프트웨어 엔지니어링 관행(디버깅 가능성, 반복 속도, 신뢰성 등)을 신경 쓰기 시작하지 않았다는 것이 재미있다"고 관찰했습니다. 댓글러 KolibriFly도 같은 요점을 말했습니다: "에이전트를 위한 좋은 아키텍처를 구축하는 것은 결국 시대를 초월한 소프트웨어 엔지니어링 관행을 반영하게 됩니다." 댓글러 marcus_holohan은 게시물을 "'엔티티 분리 101'을 통한 여행"으로 설명하고 게임이 정말 하드코딩된 스파게티인지 물었습니다.

창의적 한계에 대한 회의론. 5년 차 게임 개발자인 댓글러 YesBox는 많은 작은 디테일을 손으로 다듬는 것이 여전히 더 빠르고 개발의 일부 부분은 단어로 설명할 수 없기 때문에 LLM이 게임 개발을 대체하지 않을 것이라고 예측했습니다. 전 MMO 및 인디 개발자인 댓글러 dudeinhawaii는 AI 모델이 항상 "평범한 중간"을 만들며, 게임을 만드는 것이 재미있게 만드는 것과 같지 않고, 모델이 재사용 가능한 대규모 아키텍처 구축에 취약하다고 주장하며, 인간이 핵심 아키텍처를 구조화하고 AI가 그 안에서 코드를 작성하게 하라고 권장했습니다.

도메인 전문 지식은 출력을 판단하는 방식을 바꿉니다. 댓글러 transitorykris는 특정 형태의 Gell-Mann 건망증을 설명했습니다: 전문 지식이 있는 영역에서 잘못된 가정을 발견하고, 그렇지 않은 영역에서는 모델을 훨씬 더 신뢰해야 합니다.

저자 자신의 주의 사항. Kukshtel은 현재 이러한 기술 중 어느 것도 사용하지 않는 프로젝트를 출시 중이라고 게시물을 마무리합니다. 프로젝트가 매우 작기 때문입니다. 그는 하네스 접근 방식을 더 큰 프로젝트에 관련된 것으로 구성하고, 독자들이 효과가 있었던 것과 그렇지 않았던 것을 공유하도록 초대합니다.

SUMMARY: Kyle Kukshtel의 "Your Game Is A Harness"는 LLM이 게임 개발에 실패하는 이유가 게임이 코드만이 아니기 때문이며, 해결책은 게임의 상태를 결정적이고, 주소 지정 가능하며, diff 가능하게 만들어 게임 자체가 에이전트의 하네스가 되게 하는 것이라고 주장합니다.

TITLE: 게임 개발을 위한 AI 하네스 설계 방법: LLM 에이전트가 게임을 읽을 수 있게 만들기