Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
본 글은 게임 개발 과정에서 LLM의 역할을 논하며, LLM이 기본 골격 작성이나 리팩터링에는 강하지만 예술적 안목을 요하는 미세 조정 단계에서는 직접 수작업으로 개입하는 것이 더 효율적임을 강조합니다. 핵심은 LLM에게 조정을 대신 시키는 것이 아니라, 개발자가 수작업 변경을 쉽게 할 수 있도록 돕는 '도구'를 만들게 하는 것입니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 GeekNews의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기kkukshtel, 웹사이트에 있다는 이유로 자기소개와 작업 소개를 빼지 말고, 자기 사이트 링크라도 함께 남겨주면 좋겠음. 독자에게 찾아보는 부담을 넘기지 않아야 함.
글 앞부분을 읽고 나머지는 훑어봤으며, LLM은 가끔 검색할 때만 사용함. 게임 개발을 5년 해온 입장에서, 좋은 플레이 경험에는 수많은 세부 조정이 필요하고 말로 표현할 수 없는 작업도 있어 LLM이 게임 개발을 대체하기는 어려워 보임.
특히 마지막 다듬기 단계에서는 프롬프트로 지시하기보다 특정 필드나 코드 한 줄을 직접 바꾸고 테스트하는 편이 빠를 것 같음. 마지막 20%에 전체 시간의 80%가 드는 작업임. 예술가가 구상을 구현할 때 필요한 색, 선, 형태, 배치, 감정, 역사적 맥락 모두를 언어로 전달할 수는 없으며, 직접 몸을 움직여야 구현 가능한 부분이 있음.
특정한 미적 지향을 가진 예술가와 그 지향에 관심 있는 관객을 위한 매체로 게임을 바라보는 관점임. 하지만 Candy Crush는 인지과학과 인지신경과학의 신호와 단서를 활용해 13년간 모바일에서 가장 많이 플레이되는 게임으로 자리 잡았음.
그런 예술적 게임은 대중이 즐기거나 관심을 갖는 게임의 일부에 불과함. 게임이 어떠해야 하는지에 대한 기대를 바꾸면 획일화가 더 진행될 수도 있음. Skyrim의 걷기와 공백 시간을 줄이고 Fortnite처럼 빠른 전투와 행동에 집중하도록 취향을 형성하면, 신경생리학에 맞춘 단순한 게임에 더 쉽게 끌리도록 만들 수 있음.
세부 조정은 손으로 하는 편이 빠르다는 데 대체로 동의하지만, 프롬프트 사용을 전부 아니면 전무로 볼 필요는 없음. LLM은 기본 골격 작성, 검토, 리팩터링에는 강하지만 예술적 안목을 살리는 미세 조정에는 덜 효율적임.
핵심은 조정을 대신 시키는 게 아니라 직접 조정하기 좋은 도구를 만들게 하는 것임. 우리 Steam 게임에는 수작업 변경을 돕는 도구가 아마 100개쯤 있으며, 기존 작업 흐름을 빠르게 만들도록 LLM으로 제작함. 먼저 손으로 작업하고, 그 작업을 쉽게 만드는 도구를 LLM에 만들게 하면 예술가는 구상을 더 빨리 구현할 수 있음.
[0] https://i.imgur.com/b4nSFjV.png.
프로토타입과 밸런스 테스트에 유용하게 쓰고 있음. 게임 규칙을 구현하고 AI 플레이어를 만든 뒤 밸런스 문제를 찾게 하거나, 직접 AI와 플레이하며 재미를 확인하고 반복 개선할 수 있음.
규칙을 조금 바꾸자마자 LLM의 테스트가 큰 결함을 찾은 적도 여러 번 있음. 물론 AI 플레이어가 게임을 못하는 경우도 있어 판단은 여전히 필요함. 종이로 시제품을 만들어 친구들과 테스트했던 게임에서도 놓친 문제를 여럿 찾아냈음. 사람과의 테스트를 대체하지는 않지만, 문제를 빨리 걸러내 사람과 테스트하는 시간의 가치를 높여줌.
요즘 LLM으로 프로그래밍하면 르네상스 시대 회화 공방을 지휘하는 느낌이 점점 강해짐. 거장이 여러 화공을 지휘해 거대하고 정교한 그림을 빠르게 제작하고, 마지막에는 직접 필요한 부분에 붓질하던 방식과 비슷함. 최종 작품에 거장의 예술적 흔적이 남으므로 그 사람의 작품이라 부르는 것도 타당함.
두 사람이 같은 게임을 LLM으로 만들어도 결과는 서로 다를 것이고, 직접 만들면 또 다른 결과가 나올 것임. 모두 예술이자 게임이라는 사실은 변하지 않음.
기반을 충분히 이해한다면 마무리와 미세 조정은 직접 하는 편이 빠르다는 데 동의함. 지금 LLM으로 제대로 된 소프트웨어를 개발할 때의 큰 과제는, 직접 붓을 잡지 않으면서도 작업과 적절한 거리를 유지하는 것임.
직접 다듬는 편이 빠른지는 새로운 작업인지, 이미 수천 번 구현된 작업인지에 따라 달라짐. AI에는 말뿐 아니라 스케치, 사진, 그림도 입력할 수 있음.
현재 많은 미세 조정이 필요하다는 데는 동의하지만 미래를 단정하지는 않겠음. AI가 이렇게 발전할 줄도 몰랐는데 앞으로의 예측만 맞을 이유는 없음. 지금 Fable의 도움을 많이 받아 새로운 게임을 만들고 있으며 아주 만족스러움. 게임 자체는 새로워도 구성 요소 일부는 표준적인 것이어서, 예전에 너무 자주 했던 중복 구현을 피할 수 있어 좋음.
올해 LLM의 도움으로 게임을 개발하면서 이상한 차이를 겪었음. 단순한 Pong을 몇 주간 다듬을 때는 최첨단 모델도 기능을 수정하거나 추가할 때마다 다른 부분을 망가뜨렸음. 혼자 하는 것보다는 생산적이었지만 상당히 성가셨음.
반면 약 100배 복잡한 게임 전체를 만들어 달라고 하니 한 번에 문제없이 완성했음. 두 결과가 어떻게 양립하는지 모르겠음. 학습 데이터 분포 안에 있는 작업인지가 영향을 주는 걸까?
본 적 있는 코드를 대략 재현하는 편이, 주어진 코드를 충분히 이해하고 특정 부분만 수정하는 것보다 훨씬 쉬운 게 맞음.
Rust와 Bevy처럼 컴파일 시점의 보장을 활용해 다른 부분이 깨지는 것을 막아봤는지? 상당히 도움이 될 것 같음.
한 번에 만든 게임의 코드는 엉망이었을 수도 있음. 다만 내 생각에는 그게 꼭 중요하지는 않음.
새로 만든 게임은 아직 마무리 작업을 하지 않은 것 같음. 기본 구현과 실제 출시 사이에는 말로 표현하기조차 어렵고 수많은 반복이 필요한 작업이 있음. 그 모든 과정을 AI로 처리하기는 쉽지 않을 것임.
LLM과 예술에 관해 중요한 교훈을 배워가는 과정으로 보임. 게임 개발의 코딩은 LLM이 완전히 해결했지만, 애초에 코딩은 가장 어려운 부분과는 거리가 멀었음.
난수 고정과 결정론은 이론상 좋아 보여도 실제로는 게임 제작을 매우 제약함. 특히 여러 플랫폼에서 결정론을 유지하는 일은 대단히 까다로워짐.
곧바로 쓸 수 있는 AI 게임 개발 환경을 원한다면 확산 모델에 집중하는 편이 낫지 않을까? 확산 모델을 쓰면 통합할 게임 엔진 자체가 없으므로 도구와 통합에 관한 고민을 거의 모두 피할 수 있음.
코딩이 어려운 부분이 아니었다는 건 과거를 왜곡하는 것임. 코딩도 분명 어려운 부분 중 하나였음!.
코딩이 완전히 해결됐다는 건 아직 사실이 아님. 현재는 게임에 맞는 아키텍처를 안내해야 하며, 그렇지 않으면 게임플레이를 반복 수정한 끝에 성능이 나쁘고 엉망인 코드베이스가 되기 쉬움. 다만 이 문제도 머지않아 해결될 것으로 예상함.
왜 그렇게 까다롭다는 건지? 해결할 과제이기는 하지만 고정소수점 연산 라이브러리를 쓰면 됨. 결정론은 제약이 아니라 자유를 줌. 롤백 넷코드, 리플레이, 쉬운 디버깅을 가능하게 함. 본인이 익숙한 방식만 현실이라고 할 수는 없음.
많은 인디 게임에서는 코딩이 가장 어려운 부분이 아니라는 데 일부 동의함. 적절한 미술과 게임플레이가 있다면 AI가 코딩한 게임도 잘 팔릴 수 있음.
하지만 주요 게임 다수는 현재 AI의 능력을 넘어서는 복잡한 엔진과 온라인 서비스를 요구하며, 이런 장르에서는 엔지니어링이 거대한 진입 장벽임. 미술과 게임플레이 구상만 챙기면서 Cyberpunk 2077을 바이브 코딩할 수는 없음. 사람도 간신히 만들어낸 게임!
첫 슬라이드를 보자마자 왜 속성이 하드코딩돼 있는지 의아했으며, 이후 내용도 객체 간 결합도 낮추기 입문처럼 느껴졌음. 게임은 정말 이런 하드코딩된 스파게티 코드로 만들어지는지?
Acorn Atom 시절 어셈블리로 Missile Command를 만든 이후 게임을 작성해본 적은 없지만, 오히려 직접 만들어보고 싶어짐.
글쓴이의 다음 고백이 답이 될 수 있음. “이 분야에는 확실히 덜 익숙해서 LLM이 만든 코드를 좋은 코드로 받아들이는 경향이 있음. 실제로는 엉망일 수도 있음. 다만 Svelte와 웹 기술 쪽은 온라인에 소스가 공개된 고품질 프로젝트가 아주 많으므로 결과물도 좋을 거라 믿을 근거가 있음.”
계획을 제대로 세우는 것이 필요함. AI 없이 계획을 전부 세우거나, 게임을 충분히 설명하고 AI에게 계획 수립을 맡긴 뒤 그 계획을 따라야 함. 어느 쪽을 택해도 됨.
작은 프로젝트에서 내가 도달한 방식과 일치하며, 특히 스크린샷과 시뮬레이션 분리가 핵심이었음. 큰 틀에서는 에이전트에게 작업을 더 쉽게 파악할 수 있도록 만들라고 요구하면 방법을 찾아냄.
에이전트는 무한히 인내심이 있다는 점도 활용할 만함. “Factorio 개발일지 스타일로 각 게임 규칙의 영상이 들어간 대화형 설계 문서를 만들어줘” 같은 요청은 변경 사항 검토를 쉽게 해줌. 시간이 없어 못 만들던 개발 편의 도구도 별도 에이전트에 맡기고, 주 작업과 독립적이라면 뒤에서 병행 제작할 수 있음.
게임 개발은 관측 가능성에 상대적으로 덜 투자한 것 같음. 디버그 빌드의 성능 계측은 많지만 초당 피해량이나 체력을 시계열 지표로 내보내는 방식은 보지 못했음. 이런 기능은 성장 곡선과 밸런스를 살필 때 사람보다 에이전트에게 더 큰 도움이 될 것임.
내게 가장 가치 있었던 요청은 “네가 작업하는 동안 내가 PC를 쓸 수 있게 게임을 화면 없이 실행하는 방법을 찾아줘”였음. 이를 구현하자 여러 인스턴스를 병렬 실행할 수도 있게 됐고, 이제는 가정을 확인하거나 변경 사항을 검증할 때 스스로 활용함.
AI를 발명하고 나서야 디버깅 용이성, 반복 속도, 신뢰성 같은 좋은 소프트웨어 공학 관행에 관심을 갖기 시작했다는 게 좀 재미있음.
정말 그렇게 되고 있는지? 어떤 점에서 그런지 잘 보이지 않아 진지하게 묻는 것임.
보통 Claude에게 프레임률이 낮은 구간을 집요하게 최적화하라고 요청함. Pixel 10에서 eden 에뮬레이터로 실행한 BOTW를 충돌하는 상태에서 약 2fps로, 다시 20~30fps까지 개선했음.
실행·검증 환경은 기본적으로 adb, 일부 프로파일링 수정, 모델이 프레임을 덤프할 수 있는 기능으로 구성됨.
LLM이 게임을 만드는 데 약할 수는 있지만, 이미 만들어진 게임을 다루는 능력은 경우에 따라 다름. 어릴 때 하던 1997년 PC 게임을 최신 하드웨어에서 실행하고, 기억 속 모습에 가깝게 바꾸는 작업을 진행 중임. Claude Code는 30분 만에 실행 문제를 해결하면서 기본 역공학 환경까지 구축함. 이후 여러 부분을 반복 개선하며 게임 대부분을 디컴파일했음. PC를 점유하는 컴퓨터 조작이 불편해 화면 없이 실행하도록 요청하자, 호환성 계층으로 쓰던 DirectX DLL을 확장하고 나도 몰랐던 Windows의 “Private Desktop” 기능까지 활용함. 덕분에 게임 여러 개를 병렬 실행할 수 있게 됐음.
게임 플레이에 필요한 메모리 주소와 논리 스크립트를 빠르게 파악하고, 직접 작성한 시나리오 파일과 레벨 데이터 수정, 메모리 조작을 조합해 필요한 작업을 수행함. 내가 조금씩 방향을 잡아주자 게임 구조를 들여다볼 보조 도구도 엄청나게 만들어, 결과를 검증하고 더 정확하게 지시할 수 있게 됐음.
이제는 주요 순간의 꽤 괜찮은 스크린샷을 포함한 전체 레벨 공략까지 별도 예시 없이 작성하므로, LLM이 게임에 약하다는 일반론에는 동의하기 어려움. 게임을 계측할 도구를 LLM이 만들고 스스로 파악하게 맡겨보면 됨..