게임 개발에서 LLM이 무너지는 이유는 코드가 아닌 에셋에 있다

게임 프로그래머 Kyle Kukshtel이 캘거리에서 열린 인디 게임 행사 Indie Rodeo에서 'Your Game Is A Harness'라는 제목으로 45분 발표를 진행하고, 그 내용을 블로그 글로 정리했다. 결론은 단순하다. LLM은 웹 애플리케이션에서는 거의 못 하는 일이 없을 정도가 됐지만, 게임에서는 구조적으로 계속 넘어진다는 것이다.

그의 출발점은 무드보딩 사이트 mood.site였다. 에이전트라는 개념이 나오기 전, ChatGPT 웹 인터페이스에 코드를 복사해 붙여넣는 방식으로 만든 프로젝트다. 과정 자체는 형편없었지만 결과물은 나왔고, 밤 시간을 쪼개 2~3주, 합쳐서 20시간 남짓이면 끝났다. 같은 사이트를 직접 짰다면 지금도 첫 버전을 붙잡고 있었을 것이라고 그는 적었다. 이후 Claude Code와 최신 Claude 모델을 거치면서 웹 스택에 한해서는 LLM이 못 하는 일이 거의 없다는 감각을 갖게 됐다.

문제는 게임이었다. 게임과 관련된 작업에 LLM을 투입할 때마다 번번이 무너졌다. 이유를 그는 데이터와 표현 방식에서 찾는다. 웹은 소스가 공개된 고품질 프로젝트가 넘쳐나 학습 재료가 풍부하지만, 게임 쪽은 그에 비해 몇 자릿수 적은 데이터밖에 없다. 게다가 게임에는 코드로 잘 표현되지 않는 요소가 대량으로 들어 있다. 정적인 이미지와 텍스트를 배치하는 일은 게임이 처리해야 할 수십 개 시스템 가운데 하나의 부분집합일 뿐이다.

그래서 LLM에게 게임은 불투명하다. 게임에도 물론 코드가 있지만, 코드가 아닌 나머지 부분은 모델이 읽어낼 수 없다. 게임의 동작이 그 불투명한 부분을 조종하고 변형하는 데 의존한다면, LLM은 그 게임을 다루는 순간 실패한다. 게임 개발 커뮤니티 일각에서 LLM을 두고 부정적인 평가가 나오는 배경도 여기에 있다고 그는 본다.

예외는 있다. Three.js로 게임을 만드는 원샷 워크플로가 그렇다. 에셋을 단순한 박스형 도형으로 표현하고, 게임에 보통 필요한 에셋 생성·가공·변환 작업을 건너뛸 수 있기 때문이다. 모든 것이 코드로 존재하면 LLM이 추론하고 수정하기 쉬워진다. 다만 그렇게 나온 결과물은 LLM의 중간값을 벗어나지 못해 작가적 목소리가 빠지기 십상이라고 그는 지적한다.

발표는 LLM 프롬프트의 구조로 이어진다. 요청은 시스템 프롬프트, 어시스턴트 프롬프트, 유저 프롬프트로 나뉘는데, 사용자가 실제로 건드리는 것은 유저 프롬프트다. 중요한 건 세션 안에서 이전에 주고받은 메시지가 매번 통째로 다시 제출된다는 점이다. 대화가 길어질수록 컨텍스트가 쌓이고, 초반의 잘못된 내용이 이후 작업을 계속 오염시킬 수 있다. 이 제약 때문에 컨텍스트를 관리하는 별도의 엔지니어링 실무, 이른바 컨텍스트 엔지니어링이 등장했다는 것이 그의 설명이다.

실무적으로 시사하는 바는 분명하다. 게임에 LLM을 제대로 쓰려면 게임의 비코드 요소를 모델이 다룰 수 있는 형태로 바꾸는 작업이 먼저 필요하다. 웹 개발에서 통하던 감각을 그대로 가져오면 같은 지점에서 반복해서 걸려 넘어지게 된다.

다만 그도 자신의 판단에 편향이 섞여 있음을 인정한다. 게임 프로그래머로 15년을 일해온 만큼 나쁜 게임 코드는 멀리서도 알아보지만, Svelte 기반 웹 앱은 그만큼 익숙하지 않아 LLM이 뱉은 코드를 좋다고 받아들이기 쉽다는 것이다. 실제로는 형편없는 코드일 수도 있다는 여지를 남겨둔다. 아울러 이 글은 AI가 쓴 것이 아니라 발표 슬라이드만 참고해 사람이 직접 작성했다고 밝히고 있다.