AI를 활용하여 실제 게임 만들기: Bezi, Claude & Unity

이 모든 것을 리팩토링하고 다시 보내는 데 얼마나 걸렸나요? 아마 한두 시간 정도요. 저는 몇 주가 걸릴 것 같아요. 이건 여러분의 많은 지식을 대체합니다. Jason과 저는 이 점에 대해서는 의견이 다를 수 있다는 것에 동의할 수 있습니다. Greg, 어떤 작업들을 해 오셨는지부터 시작해 볼까요? 학습 게임을 만들고 계신 것으로 알고 있어요. 계속하고 계신가요? 더 많이 만드시는 건가요? 지금 AI를 사용하고 있나요? 네. 그래서요, 저는 Legends of Learning을 위해 교육용 게임을 만들어 왔어요. 처음에는 그들을 위한 수학 게임, 곱셈과 나눗셈 게임을 만들었어요.

이건 거의 제가 직접 코딩한 거예요. 이건 AI가 정말 대중화되기 전의 일이에요. ChatGPT를 이용해 약간 복사 붙여넣기를 했었죠. 그리고 역사 게임을 했는데 이때 Bezi를 많이 사용했어요. 이 게임은 George Washington, John Adams, Alexander Hamilton, Ben Franklin 같은 NPC들과 상호작용하는 대화 기반 게임이었어요. 여러분이 그들과 대화를 나누는 거죠. 그래서 그들이 무언가를 말하면 여러분은 선택할 수 있는 세 가지 응답을 받게 돼요. 그리고 어떻게 응답하느냐에 따라 그들이 반응하기도 했죠. 그리고 헌법 제정 회의로 이어졌던 온갖 종류의 주제들에 대해 사람들과 토론을 진행할 수도 있었어요.

사실 Kevin, 잠깐만요. 당신이 할 말이 별로 없네요. 그럼 Bezi가 뭔지 모르고 당신을 본 적 없는 모든 사람들에게 당신이 누구인지 말해줄래요? 아직 듣고 계신 분들 중 GPT, 케빈이 화면에 나타날 때마다 엄청나게 화려한 편집들을 해주세요. 거대한 전환 효과, 폭발 같은 것들을요. 네, 아무튼 여러분, 제 이름은 Kevin입니다. 저는 Jason을 몇 달 동안 알고 지냈어요. 올해 GDC에서 만났죠. 저는 Bezi의 개발자 관계 담당자예요. 좋든 싫든, 그건 제가 커뮤니티와 지원을 맡고 있다는 뜻이에요.

제 배경은 프로젝트 관리 및 제작 분야입니다. 저는 이 역량으로 인디 게임 업계에서 10년을 보냈습니다. 그래서 Bezi가 무엇이냐고요? 비기술적인 관점에서, 처음 누군가와 이야기할 때, 저는 Bezi를 Claude나 ChatGPT에 비유하면서도, 좀 더 구체적으로는 게임 개발을 위한 것이라고 설명하는 것을 좋아합니다. 하지만 저는 이것이 그 이상이라는 것도 알고 있기 때문에, 엔지니어링 관점에서 Bezi가 무엇인지 Greg에게 들려주려고 합니다. 왜냐하면 제가 그가 자신의 업무에서 매일 사용한다는 것을 알기 때문입니다. 그래서 이것은 Unity에 직접 통합되는 AI 어시스턴트입니다.

음, 요즘 많은 사람들이 Unity CLI와 Claude 같은 것을 사용하여 에디터에 들어가지 않고도 게임을 직접 만드는 것을 알고 있습니다. 음, Unity는 에디터를 열어 두고, 여러분은 기본적으로 Unity가 아니라 Bezi가 Unity 에디터에 연결됩니다. 그래서 매우 프로젝트 인지적(project aware)입니다. 즉, 제 전체 프로젝트에 관한 모든 것을 알고 있다는 것입니다. 이것은 기본적으로 하네스(harness)와 같습니다. 만약 Claude 코드나 Codex 또는 다른 것을 사용해 봤다면 이와 같은 인터페이스에 익숙할 겁니다. 새로운 스레드를 만들거나 기존 스레드에서 작업할 수 있습니다.

사용자 지정 페이지를 가질 수도 있습니다. 예를 들어, Legends of Learning의 경우, 저희 프로젝트 요구사항과 설정이 있습니다. 이것들은 제가 준수해야 하는 제약 조건입니다. 그리고 저는 이들을 프롬프트에 태그할 수 있어서, Bezi가 여기에 주의를 기울이도록 할 수 있습니다. 또한 스킬(skills)도 가질 수 있습니다. 그래서 여러분은 많은 사용자 지정 스킬을 만들 수 있습니다. 실제로 저는 Bezi에게 Legends of Learning에 유용할 사용자 지정 스킬들을 만들게 했습니다. Legends of Learning의 모든 것은 현지화(localization)를 거쳐야 합니다. 따라서 공개적으로 노출되는 모든 텍스트는 현지화되어야 합니다.

그리고 언어 파일의 JSON 키-값 쌍을 생성할 것입니다. 모든 UI 요소가 사용자에게 표시되는 모든 것을 로컬라이제이션(localization)을 사용하여 표시하도록 할 것이라는 점을 보장합니다. 또한 음성 인식(speech-to-text) 또는 음성을 텍스트로 변환하는 기능, 즉 텍스트 음성 변환(text-to-speech)도 있습니다. 따라서 시각적으로 표시되는 것뿐만 아니라 사용자에게 말해질 모든 것에 대해 언어 키를 사용하도록 할 것입니다. 또한 서브 에이전트(sub-agents)도 만들 수 있습니다. 예를 들어, 메커니즘의 프로토타입을 만들고 싶다고 가정해 보겠습니다. 제가 내장된 Bezi 스킬을 사용하여 증명(proofs)을 생성하는 스킬을 가지고 있고, 잠시 후에 이 증명들을 보여드리겠습니다. 이것은 기본적으로 설계하고 있는 모든 것의 웹 기반 프로토타입과 같습니다.

그래서 저는 '교육적 메커니즘 프로토타이퍼'라는 스킬을 실제로 만들었습니다. 이 스킬은 Bezi의 create proof 스킬을 사용하여 증명을 구축합니다. 그리고 저는 그 증명을 Unity에 구현하도록 Bezi에게 요청할 수 있습니다. 그리고 저는 이것을 모형(mockups)을 만드는 데 사용합니다. 기본적으로, 더 이상 아무것도 손으로 하지 않습니다. 그래서 제가 학습 목표를 위한 몇 가지 게임 디자인 아이디어를 Bezi에게 제공했습니다. 예를 들어, 이러한 핵심 학습 목표와 플레이어는 게임플레이를 통해 배워야 하는 주변 학습 목표를 충족하는 판 구조론(plate tectonics)에 대한 게임을 만들고 싶었습니다.

그리고 저는 기본적으로 Google MCP 서버를 사용하여 Bezi가 이를 생성하도록 했습니다. 제가 제공한 게임 아이디어를 기반으로 이 게임 디자인 문서가 만들어졌습니다. 그리고 저에게는 다양한 아이디어들을 주었고, 그들이 일부는 다른 레벨에, 일부는 미니 게임에 사용하도록 했습니다. 학습 목표는 'Legends of Learning'에서 가져왔습니다. 그리고 저는 Gemini에게 게임 아이디어 10개를 달라고 요청했고, 여기에 다른 요구 사항 및 제한 사항들, 즉 기술적 요구 사항들도 주었습니다. 예를 들어, 압축되지 않은 빌드 크기는 30메가바이트보다 작아야 한다는 것입니다.

이것은 WebGL 빌드입니다. 저사양 Chromebook에서도 잘 실행되어야 합니다. 드래그 앤 드롭 같은 기능은 넣을 수 없습니다. 제가 이런 제약 조건들을 모두 알려주고, 그녀에게 플레이어가 게임플레이를 통해 이러한 개념들을 배울 수 있는 게임 아이디어 10가지를 만들어 달라고 했습니다. 좋아요. 그리고 그냥 클릭만 해서 지나가는 게임이 될 수는 없습니다. 단순히 강의나 퀴즈 기반일 수도 없어요. 실제로 무언가를 플레이해서 배우게 하는 방식이어야 합니다. 그러자 그녀가 여러 가지 아이디어를 주었습니다. 그래서 제가 마음에 드는 것들을 골라 Bezi에게 전달했고, 이 개념들과 게임 아이디어들이 이러한 제약 조건들로 레벨과 미니게임으로 구현된 게임 디자인 문서(GDD)를 만들어 달라고 했습니다.

그래서 네 개의 레벨과 네 개의 미니게임을 만들었습니다. 그런데 Bezi가 이 전체 문서를 작성했습니다. 지금 보이는 목업들은 제가 Bezi에게 만들게 한 프로토타입 증명서, 즉 프로토타입 증거(proofs)에서 가져온 스크린샷입니다. 그리고 저는 그냥 스크린샷들을 GDD의 일부로 붙여 넣었습니다. 그래서 약 네 번 정도 과정을 거쳤습니다. 피드백을 받고, 그들이 마음에 들지 않는 부분이나 제가 다루어야 할 부분이 있는 것들 때문에 돌아왔거든요. 그래서 저는 Bezi에게 이 피드백에 응답하는 것을 도와달라고 했습니다. 어떻게 하면 이러한 우려 사항들을 해결하기 위해 변경할 수 있을까요? 라고요.

그래서 저는 게임 디자인 문서의 해당 섹션을 다시 작성해야 했고, 그 프로토타입을 위한 증명서도 리팩터링(refactor) 해야 했습니다. 그리고 새로운 목업 스크린샷을 생성해서 검토를 위해 그들에게 보냈습니다. 그래서 제가 이 모든 것을 그렇게 처리했습니다. 아마 한두 시간 정도 걸렸어요. 한두 시간요. 좋아요. 그런데 어떻게 생각하세요? 예전에는 얼마나 오래 걸렸을까요? 아, 세상에, 영원히요. 그리고 중요한 점은, 일단 승인되면, 게임 디자인 문서가 오늘 검토자로부터 '우려 사항들이 해결되었고 이 게임 디자인 문서는 사용 준비가 되었다'는 답장을 받았다는 것입니다.

그래서 저는 화요일쯤에는, 월요일이 공휴일이라서, Legends of Learning에서 공식 승낙을 보내줄 거라고 추측하고 있어요. '좋아, 네 게임 디자인 문서가 승인되었어. 게임을 제출할 시간이 10주야.'라고요. 이제 Bezi가 있고, 제가 이미 이 프로토타입의 대부분을 가지고 있기 때문에, 아마도 일주일 안에 완전히 기능하는 게임을 만들 수 있을 거예요. 그리고 나머지 아홉 주는 최적화(optimization), 다듬기(polish), 재미 요소를 추가하며 반복 작업에 쓸 수 있죠. 그리고 그들은 직원이 없는 인디 개발자로서 제가 제출할 수 있었던 것보다 훨씬 더 나은 게임을 얻게 될 거예요.

하지만 지금 이 대화에 덧붙이고 싶은 한 가지는, 여러분 둘 다 경험 많은 개발자라는 점이에요. 그러니 만약 이걸 보고 계신 분들이라면, Greg이 자신이 무엇을 하는지 이미 알고 있고 AI를 사용해서 자신의 작업 흐름(workflow)을 가속화하고 있다는 것을 이해해 주세요. 이건 아무런 경험이 없는 사람이 처음으로 AI를 만져보며 게임을 만들려고 시도하는 것과는 매우 달라요. 그래서 모든 사람에게 유용합니다. 하지만 제가 사람들에게 지원을 제공하거나, 특히 직업을 잃을까 봐 걱정하는 사람들과 AI에 대해 이야기할 때 가장 좋아하는 말 중 하나는, 자신이 무엇을 하는지에 대해 더 많이 알수록 그 특정 작업에 대해 AI가 자신과 함께 일하기에 더 좋다는 거예요.

이건 여러분의 경험이나 지식을 대체하지 않아요. 절대 그렇지 않을 거예요. 아니, 완전히라고는 말 안 했지만, 많은 지식은 대체해요. 예전에 알아야 했던 것들 중 상당수는 이제 알 필요가 없어요. 아, 괜찮아. 제이슨과 저는 그 부분에 대해서는 의견이 다를 수 있을 것 같아요. 저는 여전히 지식과 경험이 중요할 거라고 생각해요. 하지만 제가 최근에 올린 영상에서 9살짜리 아이가 자신만의 Roblox 게임을 만들 수 있었다고 언급했어요. 이건 제가 도와준 게 아니었어요. 그리고 그 아이는 어떻게 자신만의 게임을 만드는지 알아내서 친구들과 공유했고, 다른 아이들이 거기서 함께 놀았어요.

그는 무언가를 만들고 즐거워했습니다. 그래서 저는 많은 사람들이 걱정하고 있다는 것을 알고 있습니다. 특히 자신의 직업이 프로그래밍이고 코드를 작성하는 것을 좋아하는 사람들은요. 하지만 저는, 있잖아요, 1984년에 프로그램을 처음 배운 이후로 게임을 만드는 것이 더 재미있다고 말하고 싶어요. 그렇죠? - 네, 그리고 컴퓨터가 제가 시키는 대로 작동한다는 것을 처음 깨달았을 때, 마치 머릿속에 전구가 켜진 것 같았습니다. 저는 '이것이 프로그래밍이구나'라고 생각했죠. 음, 그래서 있잖아요, 제 직장에서는 고객에게 가치를 제공하는 신뢰할 수 있는 소프트웨어를 전달해야 합니다. 그렇죠? 제 일은 아키텍처가 아니고, 디자인도 아니며, 코드를 작성하는 것도 아니고, 테스트도 아니며, 최적화도 아니고, 문서화도 아닙니다. 제 일은 가치를 제공하는 소프트웨어를 생산하는 것입니다. 이 모든 다른 것들은 단지 제 직무의 일부인 업무일 뿐입니다. 그리고 제가 사용 가능한 어떤 도구로 그 업무들을 자동화할 수 있는 정도에 따라, 저는 훨씬 더 나은 직원, 회사에 훨씬 더 가치 있는 직원이 됩니다. 그리고 저는 그렇지 않았을 때보다 고객에게 훨씬 더 나은 가치를 제공합니다. 이것이 제가 Reddit에서 이야기할 때 가장 많이 하는 말 중 하나입니다.

모르는 분들을 위해 말씀드리자면, 저는 r/gamedev를 관리하는 것을 돕고 있습니다. 이곳은 플랫폼에서 게임 개발에 관한 가장 큰 서브레딧입니다. 그래서 AI와 고용에 대한 대화가 나올 때마다 제가 사람들에게 정말로 요청하는 것은 이 새로운 기술과 도구들이 무엇을 할 수 있는지 스스로 교육하고 인지하라는 것입니다. 왜냐하면 만약 여러분이 자신의 업무 분야에 도입되는 새로운 기술에 적응하지 못한다면, 결국 누군가에게 대체될 것이기 때문입니다.

여러분은 AI가 자신의 업무에 어떻게 적용될 수 있는지, 그리고 어떤 부분에서 기여하는 데 실패하는지를 탐구하고 알아내야 합니다. 왜냐하면 AI는 모든 것에 사용될 수는 없기 때문입니다. 어디에 사용할 수 있을지 스스로 파악하는 것이 여러분에게 달려 있습니다. 제가 생각하기에 많은 스튜디오들이 현재 파이프라인 측면에서 하고 있는 일이 바로 이것입니다. 즉, AI의 다양한 활용 방안을 탐구하고, 어느 부분에서는 의미가 있고 어느 부분에서는 그렇지 않은지를 알아내는 것입니다. 실제로 팀의 시간을 절약해 주는 곳은 어디인지, 아니면 단지 마찰(friction)만 일으키는 곳은 어디인지를 말이죠?

여기에는 많은 뉘앙스가 존재하며 사람들은 여전히 이를 탐구하고 있습니다. 예를 들어, 저는 한 팀의 일원이며 저희에게는 스프린트 보드(sprint board)가 있습니다. 저는 더 이상 사용자 스토리(user stories)를 작성하지 않고 Claude가 대신합니다. 제가 작업하는 어떤 기능에 대해서도 사양 계획서(spec plan)를 가지고 있으며, 이 기능을 개발하는 다른 팀들과 소통합니다. 요구사항을 받으면, 기본적으로 Claude에게 우리가 현재 어느 단계에 있는지, 무엇이 완료되었는지, 무엇이 아직 할당되지 않았는지, 그리고 제가 질문에 대한 답변이 필요한 모든 것을 기록한 일련의 Confluence 문서를 최신 상태로 유지하도록 시킵니다.

그리고 제가 해야 할 작업이라면 무엇이든 Claude에게 스토리(story)를 생성하고, 저에게 할당하고, 이를 스프린트로 이동시키라고 지시합니다. 그리고는 '좋아, 이 스토리를 구현하기 시작해'라고 말합니다. 그러면 코드를 작성하는 브랜치(branch)를 만들고, 코딩을 시작하며, 이를 진행 중(in progress)으로 옮깁니다. 스토리에 증거(evidence)를 추가하고 테스트(testing)로 이동시킵니다. 제가 가져가서 상위 환경(higher environment)에 배포하고 테스트할 수 있는 diff를 제공해 줄 것입니다. 그리고 만약 버그가 있다면, 어떤 버그였는지 다시 가져오기만 하면 됩니다. Claude가 그것을 수정할 것이고, '완료(done)'로 옮기고 스토리 안에 모든 증거를 넣어줄 것입니다.