게임 개발을 위한 AI 하네스 엔지니어링 방법
요약
본 글은 게임 개발 과정에 LLM(대규모 언어 모델)을 통합하는 실질적인 방법을 제시합니다. 단순히 데모를 넘어, 일상적이고 지속적인 개발 작업에 AI를 활용하여 효율성을 극대화하는 방안에 초점을 맞춥니다. LLM의 발전과 경험을 바탕으로 웹 기반 스택은 물론 비(非)웹 게임 분야에서도 LLM이 강력한 역할을 할 수 있음을 강조합니다.
핵심 포인트
- 게임 개발 전반에 걸쳐 LLM 활용 가능성을 제시함.
- 단순 데모가 아닌, 지속적인 실제 개발 과정에 AI를 적용하는 것이 중요함.
- LLM은 웹 기반 스택뿐만 아니라 비(非)웹 게임 분야에서도 강력한 도구임.
저는 26년 9월 12일 Calgary에서 열린 Indie Rodeo의 일환으로 “Your Game Is A Harness”라는 제목의 45분 발표를 했습니다. 강연 후 많은 사람들과 이야기를 나누면서, 제가 제시했던 아이디어를 컨퍼런스 참석자뿐만 아니라 더 넓은 범위의 사람들이 즐길 수 있는 형태로 공유하는 것이 좋을 것 같다고 생각했습니다.
또한, 이 블로그에서 AI에 대해 자주 이야기하기 때문에 사람들이 제가 AI를 사용해서 글을 쓴다고 오해합니다. 사실이 아닙니다! 아래 내용은 전부 100% 사람이 작성한 것이며, 저는 발표 슬라이드를 참고 자료로 삼아 포스팅을 작성했을 뿐입니다 (이는 녹취록이 아닙니다). 코딩이나 도구를 만드는 데 AI를 사용하는 것을 즐기지만, 특히 이 과정의 어떤 부분도 더 효율적으로 만들 필요가 없다는 이유로 '예전 방식'으로 글을 쓰는 것에서도 비슷한 즐거움을 느낍니다.
자, 이제 그런 이야기는 접어두고, 제가 했던 강연 내용을 처음으로 블로그 형식으로 여러분께 소개합니다. 즐겁게 읽으세요!
서론
[저는 저 자신과 제 작업에 대한 간단한 소개를 합니다. 이 부분은 생략하겠습니다. 웹사이트에서 확인하실 수 있습니다.]
저는 게임 개발에서 LLM(대규모 언어 모델)을 사용하는 것에 대해 이야기하고 싶습니다. 트위터에서 멋져 보이는 일회성 데모가 아니라, 실제 개발입니다. 즉, 매일 8시간씩, 주 5일 등 꾸준히 작업하는 방식 말입니다.
그리고 본론으로 들어가기 전에, LLM에 대해 기본적인 내용을 정리하는 것이 유용하다고 생각합니다. 아니면 적어도 기초 지식을 다져야 제가 여기서 이야기할 나머지 내용들이 이해하기 쉬울 것입니다. 많은 분들에게는 복습이 될 것이라는 점을 알고 있으니, 개발 루프(dev-loop) 관련 내용만 바로 보고 싶다면 다음 섹션으로 스크롤하세요.
제가 개발 작업에 LLM을 사용하기 시작한 여정은 mood.site라는 제가 만든 무드보드 사이트에서 출발했습니다. 이것은 '에이전틱(agentic)' 개념 이전의 것이었지만, 당시 ChatGPT가 실제로 코딩할 수 있는지 테스트해 보고 싶었습니다. 그 과정은 저에게 코드들을 ChatGPT 웹 인터페이스에 맹목적으로 복사/붙여넣기 하는 작업이 대부분이었습니다. 이 과정은 정말 힘들었지만, 결과물에는 놀랐습니다. 사이트를 만들었어요! 작동했어요! 여전히 제가 상당 부분을 직접 검증해야 했지만, 그것만으로도 저를 설득하기엔 충분했습니다. 만약 LLM에 접근할 수 없었다면, 그렇게 짧은 시간 안에(아마 총 20시간 정도의 밤샘 작업, 약 2~3주) 그 사이트를 만들 수는 없었을 겁니다. 아마 오늘날에도 첫 버전을 만드는 작업을 하고 있을 겁니다.
그 이후로 mood는 저에게 LLM 관련 작업들을 테스트하는 일종의 전시장(testbed)이 되었고 (그리고 자체적으로도 어느 정도 성공적인 프로젝트였죠!), 비슷한 스택을 사용하는 다른 많은 프로젝트를 시작하게 하는 영감을 주었습니다. 게다가 LLM들은 발전했고, 특히 Claude Code나 이후의 Claude 모델 같은 것들 덕분이었습니다. 저 자신의 경험으로는, 웹 기반 스택에 관해서는 LLM이 할 수 없는 것이 거의 없다고 느낍니다.
소프트웨어 대부분이 웹 소프트웨어이기 때문에, LLM이 모든 것을 할 수 있다고 말하기 쉬울 수도 있습니다. 하지만 제가 비(非)웹 게임 관련 '무언가'를 만드는 데 LLM을 사용하려고 할 때마다, 하나의 명확한 결론에 도달했습니다:
“LLMs는 게임에 취약하다”
제가 게임 관련 작업에 LLM을 사용해 보려고 할 때마다 무너지는 경험을 했습니다. 아마도 이건 저의 편견일 수도 있습니다. 저는 거의 15년 동안 게임 프로그래머로 일했기 때문에, 어떻게 돌아가는지 안다고 생각합니다. '나쁜' 게임 코드는 아주 멀리서도 맡아낼 수 있습니다. 하지만 Svelte 웹 앱에 관해서는 확실히 지식이 부족하고, LLM이 생성하는 어떤 코드든 '좋을 것'이라고 치우치게 생각하는 경향이 있습니다. 어쩌면 실제로 쓰레기일 수도 있습니다. 하지만 Svelte와 웹 스택 관련 자료가 품질이 있다는 믿음의 근거가 있는 것도 사실입니다. 그 이유는 온라인에 소스 코드가 공개된 고품질 웹 프로젝트가 엄청나게 많다는 점 때문입니다. 게임과 비교하면, 학습할 수 있는 데이터 자체가 몇 자릿수(orders of magnitude)로 훨씬 적을 것이라고 상상합니다.
이것뿐만이 아닙니다. 게임에는 코드 외의 많은 것들이 포함되어 있습니다. 게임은 단순히 정적 이미지와 텍스트를 레이아웃에 배치하는 것에 그치지 않습니다. 코드로 쉽게 표현할 수 없는 게임 속 요소들이 수없이 많습니다. 게다가 여기에 웹에서 필요한 모든 텍스트 레이아웃 관련 작업까지 더해져도, 그것은 게임이 처리해야 하는 100가지 이상의 시스템 중 일부일 뿐입니다.
이것이 많은 사람들이 Three.js로 게임을 만들고 있는 이유 중 하나입니다. 그들은 에셋(assets)을 단순한 박스형 기본 도형(primitives)으로 쉽게 표현할 수 있고, 일반적으로 게임에 필요한 에셋 생성/정합 작업 및 처리를 많이 건너뛸 수 있기 때문입니다. 결과적으로, 그런 요소들 중 상당수는 LLM의 평균적인 수준 외에는 실제 작가적 목소리(authorial voice)를 갖추지 못해 부실합니다.
하지만 어쩌면 그들이 맞는 말일지도 모릅니다.
원샷 Three.JS 워크플로우의 핵심 아이디어(그리고 웹 앱을 구축하는 LLM의 숙련도)는 모든 것이 코드라는 것입니다. '요소들'을 코드로 갖게 되면, LLM이 그것에 대해 추론하고 변경 사항을 만들기가 매우 쉬워집니다.
하지만 전통적인 게임의 경우에는 그렇지 않습니다. 적어도 전부는 아닙니다. 게임에는 명백히 코드가 있지만, 코드가 아닌 다른 것들이 아주 많습니다. 이는 게임에 효과적으로 불투명(opaque)한 핵심 구성 요소들이 존재한다는 것을 의미하며, 이러한 부분은 LLM에게는 이해하기 어렵습니다. 만약 여러분의 게임이 바로 이 불투명한 부분을 조종하고 변형하는 것에 의존한다면, LLM은 여러분의 게임을 다루려고 할 때 무너질 것입니다.
저는 많은 게임 개발 커뮤니티가 얼마 전에 LLM을 사용해 봤고 바로 이 문제에 부딪혔다고 생각합니다. 'LLM은 나쁘다/쓸모없다 등'이라는 정서는 (여기서 엄청난 주의 사항이 있습니다. 단지 능력에 대해서만 이야기하는 것이지, 사회를 끝장낼 잠재적 영향력에 대해 말하는 것이 아닙니다) 이러한 한계점들을 직접 경험하면서 나온 것입니다.
이는 구조적으로 LLM이 게임을 읽는 데 서툴다는 것을 의미합니다. 적어도 기본 상태에서는 그렇습니다.
LLM 기초 지식
왜 그런지, 그리고 우리가 무엇을 할 수 있는지 더 이야기해 봅시다.
어떤 LLM 서비스에 대한 호출(call) 또는 프롬프트는 세 가지 기본적인 구성 요소로 나뉩니다. 시스템 프롬프트(system prompt), 어시스턴트 프롬프트(assistant prompt), 그리고 사용자 프롬프트(user prompt)입니다:
시스템 프롬프트: 모든 사용자가 공유하는 일반 텍스트입니다. 이것은 보통 LLM 자체의 기본 정보를 설명하며,
사용자 프롬프트: 이곳이 정말 핵심입니다. AI 도구에 입력하는 모든 내용이 여기에 들어갑니다. 제출된 채팅, 코드 등이 모두 이 섹션에 담깁니다. 사람들이 '컨텍스트(context)'를 이야기할 때, 그것은 주로 '프롬프트의 사용자 및 어시스턴트 부분에 얼마나 많은 토큰이 저장되는지'에 대해 이야기하는 것입니다.
각 채팅 세션이 위 내용의 '새로운' 버전인 것처럼 생각하기 쉽지만, 실제로 일어나는 일은 다릅니다. 주어진 세션에서 모델을 사용하면서(여기서 '세션'의 범위는 어떤 서비스를 사용하는지에 따라 달라지며—닫기 전의 단일 Claude Code 세션일 수도 있고, 웹 호스팅 모델의 사이드 패널에서 접근 가능한 '채팅'일 수도 있습니다), 이전에 보낸 모든 메시지가 새로운 메시지를 보낼 때마다 다시 제출된다는 것입니다. 마치 예전 놀이터 게임을 하는 것과 비슷합니다. 자신의 차례에 다른 사람의 말을 모두 다시 말한 다음, 다음 사람이 추가할 내용을 본인이 추가하는 식입니다.
컨텍스트와 컨텍스트 오염 (Context and Context Pollution)
이것을 반복하면서 작업하고 있는 세션의 '컨텍스트'가 쌓이게 됩니다.
이 모든 것이 좋지만, 여기서 주목해야 할 핵심 사항은 사용자가 실제로 다룰 수 있는 것은 컨텍스트 내의 '최신' 내용뿐이라는 것입니다(즉, 새로운 메시지를 제출합니다). 이전 메시지들은 계속해서 모델에 반복적으로 제출됩니다. 따라서 컨텍스트에 담긴 내용이 '좋도록' 만드는 것이 중요하며, 그렇지 않으면 이전에 발생한 '나쁜' 내용들이 지속적으로 새로운 작업에 영향을 미쳐 컨텍스트가 오염되는 퇴행적인 시나리오에 빠질 수 있습니다.
따라서 컨텍스트를 관리하는 것은 LLM(대규모 언어 모델)을 다룰 때 핵심적인 요소이며, 이러한 제약 사항들로 인해 '컨텍스트 엔지니어링(context engineering)'이라는 새로운 공학적 실습이 등장했습니다. 컨텍스트 엔지니어링은
Context Engineering 자체는 이번 발표/블로그의 범위를 벗어나는 매우 큰 주제이지만, 여기서는 이 개념의 일부 원칙들을 활용하여 LLM이 게임 작업에 더 잘 수행할 수 있도록 돕는 방법을 탐구할 것입니다.
다르게 말하자면, LLM을 게임과 잘 작동하게 만드는 것은 게임이나 LLM 자체가 '어떤'지(또는 '아닌지')와 본질적으로 연결된 문제가 아니라 컨텍스트 문제입니다.
하지만 여기서 복잡한 요소는 게임이 이상하다는 것입니다. 적어도, 우리는 게임을 만들 수 있는 실제 템플릿이 없습니다. 게임 엔진은 있지만, 사실상 어떤 것이든 표준화된 도구가 0개입니다. 그 이유는 모든 게임이 서로 다르게 자신만의 요구사항을 나타내기 때문입니다.
이는 (제 생각에) 게임에만 매우 독특한 문제이지만, 다른 기술 영역에서도 충분히 나타나서, 에이전트가 어떤 작업 결과물과도 효과적으로 '작동'할 수 있도록 하는 새로운 개념인 하네스(Harnesses)가 등장했습니다.
하네스 아이디어 설명
하네스의 일반적인 아이디어는 에이전트가 잘 정의되었거나 (느슨하게) 정의된 예상 입력에 대응하여 취해야 할 일련의 행동 패턴입니다. 여러분은 아마 이미 Claude Code와 같은 하네스를 사용하고 있을 것입니다. 하지만 이러한 것들은 여러분이 수행하려고 하는 특정 작업을 더 잘 지원하기 위해 증강(augmented), 확장(extended), 정제(distilled), 추상화(abstracted)될 수 있습니다. 또한 최근 이 분야에서 많은 활동이 있었으며, 모든 종류의 것을 개발하기 위한 다양한 하네스들이 구축되었습니다:
AI 자동 생성 콘텐츠
본 콘텐츠는 HN AI Posts의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기