요약
게임을 AI 에이전트가 읽고 조작할 수 있게 만들면 게임 자체가 에이전트의 하네스가 됩니다.
15년 가까이 게임을 만들어 온 프로그래머 카일 쿡시텔이 캘거리의 인디 로데오 행사에서 한 발표를 글로 옮겼습니다. 그는 LLM이 웹 개발은 잘하지만 게임에는 약하다고 보고, 그 해법을 게임 구조에서 찾자고 제안합니다.
왜 중요한가
- Claude Code 같은 하네스(에이전트의 행동을 이끄는 틀)는 코드만 볼 뿐 실행 중인 게임 속은 들여다보지 못합니다.
- 장면, 에셋, 수치 조정처럼 코드 밖에 있어 AI에게 보이지 않던 부분을 에이전트가 다룰 수 있게 하자는 제안입니다.
- 이 구조를 갖추면 에이전트가 변경할 때마다 몇 초 만에 직접 실행해 보고 결과를 확인할 수 있습니다.
핵심 내용
- 시드를 고정한 난수 하나와 저장·불러오기를 프로젝트 초기에 넣어 어떤 상태든 똑같이 재현하게 하라고 권했습니다.
- 모든 변경을 직렬화할 수 있는 명령(커맨드 패턴)으로 만들면 에이전트가 컴파일 없이 게임을 조작할 수 있다고 했습니다.
- 시뮬레이션을 엔진에서 떼어 별도 라이브러리로 두면 엔진 없이 C# 테스트만으로 검증할 수 있다고 했습니다.
- 스크린숏 원본 대신 odiff(이미지 비교 도구)의 유사도 점수를, 성능은 samply의 텍스트 결과를 넘기자고 했습니다.
- 다만 최근 출시한 작은 게임에는 이 기법을 하나도 쓰지 않았고, 큰 프로젝트에 맞는 방법이라고 덧붙였습니다.
HN 반응
- 여러 이용자가 LLM이 게임을 처음부터 만들기는 잘해도 세부를 다듬는 단계에서는 자꾸 망가뜨린다는 경험을 전했습니다.
- 결정론적 설계는 여러 플랫폼에서 지키기 까다롭다는 반론에, 고정소수점 라이브러리와 체크섬 검사로 충분하다는 반박이 맞섰습니다.
이거 재미있네요. 저도 올해 LLM의 도움을 받아 게임을 조금 만들어 봤거든요.
간단한 퐁 게임 하나를 몇 주 동안 붙잡고 다듬으면서 여기저기 조금씩 고쳤습니다. 그런데 최신 모델들은 기능 하나를 바꾸거나 추가하면 꼭 다른 곳이 망가졌어요. 그래도 "혼자" 하는 것보다는 생산성이 나았지만, 꽤 짜증스러웠습니다.
그런데 한편으로 모델에게 훨씬 복잡한 게임(대략 100배쯤)을 통째로 만들어 달라고 했더니, 한 방에 아무 문제 없이 완벽하게 만들어 냈습니다.
이 두 가지가 어떻게 동시에 가능한지 모르겠어요. 뭐랄까, "학습 분포 안"이라서 그런 걸까요?
네, 말씀하신 게 맞습니다. 본 적 있는 다른 코드를 대충 베끼는 게, 주어진 코드를 충분히 이해해서 필요한 부분만 정확히 고치는 것보다 훨씬 쉽습니다.
Rust(예를 들어 Bevy)로 해보셨나요? 컴파일 타임 보장이 그런 문제를 막아 줄 테니, 큰 도움이 될 것 같은데요.
새로 만든 쪽은 다듬지 않으신 것 같네요.
"기본 구현"을 끝낸 다음부터 출시까지 이어지는 어려운 작업 말이에요. 말로 표현하기조차 어렵고 반복에 반복을 거듭해야 하는 그 부분요. 그걸 AI로 해보시겠다면 행운을 빕니다.
정확히 그겁니다.
저는 네 살 아이에게 줄 수학 게임을 한 방에 만들었습니다. 화면 흔들림, 폭발 애니메이션 같은 "쥬시한" 연출도 잔뜩 넣어서요.
아주 잘 돌아갔는데, 아주 사소한 것 하나라도 바꾸려 하면 결과가 처음 출력보다 나빠졌습니다. 테스트와 명세로 아무리 단단히 고정해 보려 해도, 바꿀 때마다 보기에도 느낌도 더 나빠졌어요.
kkukshtel님, 그 정보는 링크와 함께 남겨 두셔야 합니다. 링크가 본인 사이트로 가는 것이라도요. 독자에게 부담을 지우지 마세요.
추신: 글의 앞쪽 절반은 읽고 나머지는 훑어봤습니다(저는 가끔 검색할 때 말고는 LLM을 쓰지 않습니다).
저는 게임 개발을 5년 했습니다. LLM이 게임 개발을 장악하지는 못할 거라는 예감이 듭니다. 플레이어에게 훌륭한 경험을 주려면 아주 작은 디테일을 수없이 통제해야 하고, 개발의 어떤 부분은 말로 설명할 수 없기 때문입니다.
작은 디테일: 움직이는 모든 부분을 다듬고 미세 조정해야 할 때가 오면, 그 과정은 손으로 하는 편이 계속 훨씬 빠를 거라는 게 제 예감입니다. 프롬프트로 더듬더듬 진행하는 것보다 특정 필드나 코드 한 줄을 직접 고치고 테스트하며 반복하는 쪽이 더 빠를 겁니다(마지막 20%에 작업 시간의 80%가 들어갑니다).
말로 설명할 수 없는 것: 비전을 가진 예술가는 몸의 움직임으로만 그 비전을 구현할 수 있습니다. 훌륭한 작품에 담기는 모든 디테일을 말로 전달하는 것은 불가능합니다. 색, 선, 형태, 배치, 구체적인 감정, 역사 같은 것들은 입 밖으로 나오는 언어를 넘어서 있습니다.
예술가가 자기만의 편향을 가지고 만들고, 그 특정한 편향에 관심 있는 관객이 있는 매체로서의 게임이라는 관점에서 말씀하시는 것 같네요.
"비전, 색, 배치" 등을 말씀하시지만, 모바일에서 13년째 가장 많이 플레이되는 게임은 캔디 크러시입니다. 이 게임은 인지와 인지신경과학에서 나온 직접적인 신호와 단서를 쓰는 것만으로 그걸 해냈죠.
말씀하신 종류의 게임은 일반 대중이 즐기거나 관심을 갖는 게임의 작은 일부일 뿐입니다.
여기서 더 나아가 게임이 어떠해야 하는지에 대한 플레이어의 기대를 빚어내면 획일화로 밀어붙일 수도 있습니다. 스카이림은 걷는 시간과 빈 시간이 너무 많으니 포트나이트처럼 빠른 전투와 액션에 맞추는 게 낫다는 식으로요. 그렇게 플레이어층을 길들여서, 신경생리학에 더 맞춰진 단순한 게임에 쉽게 빠지게 만드는 겁니다.
캔디 크러시조차 성공의 큰 부분은 아주 작은 디테일이었습니다. 화사한 색, 그림, 눈에 띄는 애니메이션과 잘 안 띄는 애니메이션까지요. LLM도 기술적으로는 그 모든 걸 할 수 있습니다. 계속 일깨워 주고, 엄격한 규칙을 주고, 끊임없이 감독한다면요. 하지만 알아서 그렇게 하면서 일관성과 통일성까지 지키는 일은 절대 없을 겁니다.
예를 들어 키 큰 초록색 알약 사탕과 빨간색 동그란 사탕을 끌 때 둘 다 딱 3px씩 커지게 하면, 여전히 "보기에" 이상하고 불쾌한 골짜기에 빠질 수 있어요. 게다가 이건 "빨간 사탕 추가해 줘"라고 했을 때 LLM이 같은 값을 골랐다고 가정한 얘기입니다. 임의로 다른 값을 골랐을 수도 있잖아요.
저도 게임이나 CSS 애니메이션을 몇 번 만들어 봤는데, 왜 그런지, 뭘 바꿔야 하는지는 몰라도 "느낌"이 안 맞는다는 건 알겠더라고요. 그걸 해내는 예술가와 애니메이터에게는 정말 존경심이 듭니다. 그리고 LLM에게 "사탕을 끌 때 느낌이 이상해"라고 말해서, 키 큰 세로 사탕은 동그란 사탕과 X축, Y축으로 커지는 정도가 달라야 한다는 걸 알아내게 하려면 어떻게 말해야 하는지는 전혀 모르겠습니다.
원글 작성자는 캔디 크러시를 만드는 얘기를 하는 게 아닙니다. 예술을 만드는 얘기를 하는 거예요. 둘은 같은 세상에 공존하면서 각자 성공할 수 있습니다. 리얼리티 TV가 존재하고 성공했다고 해서 영화 제작이라는 예술이나 영화 보는 즐거움이 부정되지는 않잖아요. 게임도 마찬가지입니다.
원글 작성자는 좋은 게임에는 디테일, 예술성, 취향 같은 게 필요하다는 이유로 이 블로그 글을 반박하고 있습니다.
제 말은, 사람들이 실제로 무엇을 플레이하는지 보면 그런 것에 신경 쓰는 사람은 소수라는 겁니다. 지금은 그런 데 신경 쓰지 않고 인지적 측면에 집중해서 플레이어의 주의를 붙잡는 편이 훨씬, 훨씬 쉽습니다. 그리고 인간의 인지적 유인도 원글 작성자의 견해에 유리하게 짜여 있지 않습니다.
캔디 크러시는 역대 매출 최상위 게임 중 하나지만, 매출 상위 20개 게임을 보면 대다수는 캔디 크러시와 전혀 닮지 않았습니다.
조잡한 캔디 크러시였다면 디테일과 완성도에 엄청나게 공을 들이지 않고서는 그만큼 성공하지 못했을 겁니다.
저는 프로토타이핑에 유용하다고 느꼈습니다. 게임 메커니즘 하나를 얼른 세워 놓고, AI 플레이어를 만들게 하고, 부딪힌 밸런스 문제를 알려 달라고 하고, 그 메커니즘이 재미있는지 AI를 상대로 직접 해 보는 겁니다. 그러고 나서 반복하는 거죠.
메커니즘을 조금 손봤더니 LLM 밸런스 테스트가 곧바로 큰 문제를 찾아낸 적이 몇 번 있습니다. LLM이 만든 AI 플레이어가 그냥 게임을 못하는 경우도 있고요. 여전히 생각은 직접 해야 하지만, 밸런스 테스트가 있고 실험할 때마다 싸게 고칠 수 있다는 것만으로도 굉장히 값집니다. 저는 종이로 만든 시제품으로 친구들을 억지로 앉혀 놓고 플레이하게 했던 게임에 이걸 적용해 봤습니다. 그 플레이 테스트에서 놓쳤던 온갖 문제를 찾아냈어요. 사람이 하는 테스트를 대체하지는 못했지만, 문제를 더 빨리 찾게 해 줘서 사람과 하는 테스트에서 더 많은 걸 얻을 수 있었습니다.
대체로 맞는 말씀이라고 생각합니다. 다만 프롬프트를 쓰느냐 마느냐의 양자택일로 보시는 것 같아요(아니면 원글 작성자가 그랬을 수도 있겠네요. 저도 글을 대충 훑어봤거든요). LLM은 어떤 일(뼈대 잡기, 리뷰, 리팩터링 등)에는 아주 좋지만, 다른 일(미세 조정이나 예술가의 안목을 발휘하는 일)에는 효율이 훨씬 떨어집니다.
핵심은 이거라고 봅니다. 그런 미세 조정을 LLM에게 대신 시키지 말고, 사람이 직접 더 빠르고 효과적으로 조정할 수 있게 해 주는 도구를 LLM에게 만들게 하세요.
예를 들어 저희는 Steam 게임 하나에서 온갖 변경과 조정을 빠르게 하는 도구가 아마 백 개쯤 있는데[0], 물론 그 작업은 전부 손으로 합니다. 도구는 기존 수작업 흐름을 빠르게 만들어 줄 것들을 기준으로 LLM이 만들었고, 일단 만들어지고 나면 그냥 우리 팀원들이 실력을 발휘하게 해 주는 도구일 뿐입니다.
일단 손으로 해 본다
그 일을 손으로 더 쉽게 할 수 있게 해 주는 도구를 LLM에게 만들게 한다
????
비전을 가진 예술가가 그 비전을 더 빠르게 구현한다
[0] https://i.imgur.com/b4nSFjV.png
글쓴이는 LLM과 예술에 관한 중요한 교훈을 얻을 길에 들어선 것 같습니다. LLM은 게임 개발의 코딩 쪽을 완전히 해결했습니다. 하지만 그건 애초에 어려운 부분이 아니었어요. 근처에도 못 갈 정도로요.
난수 고정과 결정론 이야기는 이론상으로는 훌륭해 보이지만(이런 이야기는 다 그렇죠), 현실에서는 비디오 게임을 만드는 방식으로 극도로 갑갑합니다. 여러 플랫폼에 걸쳐 결정론을 유지하는 데서부터 상황이 아주 지저분해지고요.
바로 쓸 수 있는 AI 게임 개발 경험을 원한다면, 왜 확산 모델에 더 올인하지 않을까요? 그러면 도구와 통합 문제를 거의 전부 피해 갈 수 있습니다. 확산 모델을 쓰면 연동할 게임 엔진 자체가 없으니까요.
그건 정확히 맞는 말은 아닙니다. 지금은 어떤 구조가 내 게임에 가장 잘 맞을지 LLM에게 여전히 안내해 줘야 합니다. 그렇지 않으면 게임플레이를 여러 번 반복해서 고친 끝에 성능은 끔찍하고 코드베이스는 엉망진창이 됩니다. 다만 그 문제는 머지않아 해결될 거라고 봅니다.
맞아요, "틀렸다고조차 할 수 없는" 얘기죠. 그리고 가장 기본적인 게임플레이 문제는 놓칩니다. 그래도 예쁘기만 하고 플레이할 수 없는 재미없는 물건을 아무것도 없는 상태에서 그렇게 빨리 만들어 낸다는 건 정말 인상적이긴 합니다. 그것도 LLM과 계획을 여러 차례 세운 뒤에 말이죠. 그 계획은 그냥 할 수 있다는 이유만으로 무시하고 진행하더군요.
추신: 이 모든 문제를 100% 해결해 준다는 당신의 대체 하네스 같은 건 관심 없어요. 날 믿으라고요, 하는 얘기잖아요.
저는 어릴 때 하던 옛날 게임을 비슷하게 따라 한 재미있는 게임을 하루 만에 순전히 LLM으로만 만들었어요. 코드는 한 줄도 안 봤고, 게임 개발 경험도 전혀 없습니다. 또 계획 세션은 한 번뿐이었는데 LLM이 그 계획을 잘 실행했어요.
참고로 1년쯤 전에 같은 걸 시도했을 때는 결과가 끔찍했습니다. 훨씬 더 형편없었어요.
물론 AAA급은 아니고, 그림은 엉망이고, 대부분의 사람들은 아마 재미없어 하겠죠. 하지만 저한테는 플레이하는 게 재미있었고, 다른 사람들도 즐길 수 있는 수준까지 끌어올릴 수 있을지 조금 더 작업해 볼 생각입니다.
이건 역사 왜곡입니다. 코딩은 분명히 어려운 부분 중 하나였어요!
지난 10년의 게임 개발 얘기라면, 어렵지는 않습니다. 오래 걸리고, 지치고, 가끔 지루할 뿐이죠. 하지만 코딩의 대부분은 이미 해결됐고, 끝났고, 아마 50번쯤은 재발명됐습니다. "아무도 풀지 못한 이 문제를 깊이 파고들어 풀어야 해"라는 식의 어려움은 아니에요.
그런 건 전부 시간과 돈이잖아요. 그러니까 난이도죠.
시간이나 돈이 곧 난이도라고 단정할 수는 없다고 생각합니다. 만드는 데 오래 걸리거나 돈이 많이 들지만 그래도 만들기는 쉬운 것도 얼마든지 있으니까요.
죄송하지만 아닙니다. 그건 사실이 아니에요. 분명히 어려웠습니다. 얼마나 어려웠으면 실제로 게임을 만드는 사람이 많지 않았겠어요. 저는 GAS(언리얼 엔진)를 쓰면서 프레임워크의 복잡성에 어안이 벙벙했던 게 기억납니다. 그러다 GAS를 안 쓰니, 이번엔 GAS가 처리해 주던 것들의 복잡성에 어안이 벙벙했고요. 어려운 겁니다.
왜 '지저분'하다는 거죠? 해결해야 할 문제라는 건 인정하지만, 고정소수점 수학 라이브러리를 쓰면 괜찮습니다. 결정론은 갑갑한 게 아니라 오히려 자유롭게 해 줍니다. 롤백 넷코드, 리플레이, 쉬운 디버깅 같은 걸 할 수 있게 해 주니까요. 당신 개인이 익숙한 방식이 우연히 '현실'이라고 말할 수는 없습니다.
에이전트가 코드 깊숙한 곳에 라이브러리 함수 대신 네이티브의 비결정적 삼각함수를 끼워 넣지 않았다는 전제에서 그렇습니다. 그런 실수는 하기 쉽고, 큰 게임에서는 디버깅하기 어렵습니다. 탄탄한 CI 매트릭스가 없으면 드러나지도 않을 겁니다. 그러니 유지하기가 정말 "지저분"할 수 있죠.
또 결정론은 시뮬레이션 상태에는 통할 수 있어도, 플랫폼 간 셰이더와 그래픽 차이는 정말 지저분할 수 있고 라이브러리로는 구해 줄 수 없습니다. WebGPU 같은 것으로도 안 되고요. GPU 타이밍에 의존하는 레지던시 스트리밍 같은 걸 하고 있다면 그걸 결정적으로 만들려는 건 악몽일 겁니다.
GPU 출력이 게임 루프 시뮬레이션으로 되먹임되지 않는 한 악몽은 없습니다.
저는 의도적으로 결정론을 적용한 게임들에서 일해 봤는데, 아주 값진 도구입니다. 플레이테스터가 겪은 버그에 대해 게임 입력(시계 포함) 기록을 개발자에게 넘기면, 개발자는 정확한 시점까지 빨리 감아서 100% 재현할 수 있습니다. 어려운 버그를 쫓는 데 절약되는 시간이 엄청납니다.
하지만 그 CI는 설정하기가 아주 쉽습니다.
주어진 시작 지점에서 입력 세트를 넣고, 결과 상태의 체크섬을 계산합니다. 그 체크섬이 여러 플랫폼에서 일치하는지 확인하면 됩니다.
그리고 언어가 좋다면 로직을 특정 숫자 타입에 대해 매개변수화할 수 있어서, 특정 고정소수점 구현이 일관되게 쓰이도록 할 수 있습니다.
좋은 소프트웨어 엔지니어링 관행(디버깅 용이성, 반복 속도, 신뢰성 등)에 사람들이 신경 쓰기 시작하려면 AI가 발명되어야 했다는 게 좀 웃기네요.
게임을 만드는 데요? 그럴 수도 있겠죠.
이미 만들어진 게임에는요? 글쎄요, 경우에 따라 다를 것 같아요.
사례 연구를 하나 들죠. 어릴 때 했던 1997년 PC 게임을 요즘 하드웨어에서 돌아가게 만들고, 제 머릿속에 있던 모습으로 보이게 만드는 작업을 진행 중입니다.
Claude Code가 첫 번째 일을 30분 만에 해냈고, 그 과정에서 기본적인 리버스 엔지니어링 환경도 갖췄어요. 그다음 여러 측면을 반복해 가며 코드 대부분을 점차 디컴파일했고요. 그러다 "컴퓨터 사용" 방식의 플레이가 제 PC를 차지하는 게 짜증스럽다고 했더니, 셈(shim) DirectX DLL을 확장해 게임을 헤드리스로 돌리게 만들었습니다. 현대 윈도의 "Private Desktop" 기능까지 써서요. 저는 그런 기능이 있는지도 몰랐습니다. 덕분에 게임 인스턴스를 여러 개 병렬로 돌릴 수 있게 됐죠. 플레이는 관련 메모리 주소와 게임 로직 스크립트를 금세 파악해서, 직접 쓴 시나리오 파일, 레벨 데이터 패치, 메모리 해킹을 조합해 필요한 건 뭐든 해냅니다.
이 모든 과정에서 제가 조금씩 유도해 주기는 했지만, 게임이 어떻게 만들어졌는지 저에게 통찰을 주는 보조 도구를 어마어마하게 많이 만들어 줬습니다. 덕분에 저는 LLM의 작업을 검증하고 더 잘 지시할 수 있었어요.
그래서 전반적인 취지에는 동의할 수 없습니다. Claude가 지금은 중요한 장면의 괜찮은 스크린샷까지 곁들인 전체 레벨 공략집을 제로샷으로 써 주고 있으니까요.
요약: 그냥 LLM이 게임을 직접 계측해서 스스로 알아내게 하세요.
작은 프로젝트에서 제가 도달한 결론과 일치합니다. 가장 중요한 건 스크린샷과 분리된 시뮬레이션이었어요.
메타 차원에서는, 에이전트를 밀어붙여 결과물을 더 읽기 쉽게 만들게 하세요. 알아서 해낼 겁니다.
또 하나 관찰한 점은, 에이전트가 무한히 참을성 있다는 사실을 기억하라는 겁니다. 그래서 "Factorio 개발 일지 스타일로 각 게임 메커니즘 영상이 들어간 인터랙티브 설계 문서를 만들어 줘" 같은 프롬프트로 변경 사항 검토를 쉽게 만들 수 있어요. 일반적인 발상은, 시간이 없어서 못 만들던 소소한 편의 개발 도구를 전부 곁가지 에이전트를 띄워 만들게 하라는 겁니다. 메인 작업과 무관한 것이라면 백그라운드에서 알아서 진행시키면 되고요.
제가 아는 한 게임 개발이 그만큼 투자하지 않은 한 가지는 관측 가능성(observability)입니다. 디버그 빌드에는 성능 계측이 많이 있지만, DPS나 체력 같은 것을 내보내는 지표 시계열로 측정하는 건 본 적이 없습니다. 진행 곡선이나 밸런스를 살펴볼 때처럼, 에이전트는 사람보다 이런 데서 훨씬 큰 이득을 볼 거라고 생각합니다.
제 경우에 가장 값졌던 프롬프트는 "네가 이것저것 만지는 동안 내가 PC를 쓸 수 있게 게임을 헤드리스로 돌리는 방법을 알아내 줘"였습니다. 정말 알아냈고, 덕분에 여러 인스턴스를 병렬로 돌릴 수 있게 됐어요. 이제 가정을 확인하거나 변경 사항을 검증해야 할 때마다 알아서 그렇게 씁니다.