HOIBLOG먼저 읽는 요약
사례의 범위 — 두 제작자가 공개한 제작 과정과 반응을 정리한 해설입니다. 제가 게임을 만들거나 두 작품을 직접 플레이한 후기는 아닙니다.
핵심 차이 — 게임이 실행되는지와 한 판 더 하고 싶은지는 별도로 확인해야 합니다.
도구의 역할 — 엔진·모델링·리깅·애니메이션의 역할과 자산 이용 조건을 나눠 봅니다.
시작 방법 — 작은 규칙의 최소 플레이 버전을 직접 해보고, 선택·목표·보상·실패 이유에서 문제 하나씩 고쳐봅니다.
AI로 게임을 구현하는 일과 재미를 확인하는 일은 구분해야 합니다. 장면이 뜨고 규칙이 작동하며 캐릭터가 움직여도, 사람이 한 판 더 하고 싶은지는 직접 해봐야 알 수 있습니다. 두 제작자의 실제 사례를 바탕으로 이 차이를 정리했습니다. 제가 게임을 만들거나 두 작품을 직접 플레이한 후기는 아닙니다.
단순한 방해에 승리 조건을 더한 사례
첫 제작자는 Opus5.5와 UnityMCP를 활용해 4일 동안 게임을 만들었다고 소개했습니다. 흥미로운 부분은 제작 기간보다 규칙을 고친 이유였습니다. 처음에는 방해만 하는 방식이었지만 실제로는 재미가 약했다고 합니다.
이후에는 경기에서 이기면서 동시에 아군 캐리를 이탈시켜야 한다는 조건을 붙였습니다. 우리 편의 핵심 전력을 내쫓으면서 팀은 이겨야 하니, 방해꾼에게도 실적 평가가 생긴 셈입니다. 단순히 기능이 작동하는 데서 그치지 않고 어느 정도 방해해야 유리한지 고민하게 만든 것입니다. 재미를 만든 것은 AI가 코드를 작성했다는 사실만이 아니라, 어떤 갈등을 규칙에 넣을지 정한 제작자의 판단이었습니다.
엔진·모델링·리깅은 서로 다른 작업입니다
첫 사례의 제작 과정에는 여러 도구가 나뉘어 쓰였습니다. Unity는 장면·오브젝트·규칙을 한 프로젝트에서 실행하는 엔진이고, UnityMCP는 편집기를 조작하고 실행 결과를 다시 확인하는 흐름을 돕습니다. 게임을 작동시키는 데 필요한 구성이지, 그 자체로 재미까지 보장하지는 않습니다.
맵·건물·미니언 같은 자산 제작에는 Blender와 Python 스크립트를 사용했다고 설명했습니다. Blender는 3D 모델과 장면을 만들고, Python은 작업을 자동화하거나 반복하는 데 쓰입니다. 이미지나 텍스트로 3D 자산을 만드는 TRELLIS 같은 도구를 함께 사용할 수도 있습니다. 다만 외형을 만든 뒤에도 UV·텍스처·리깅·애니메이션을 갖춰야 게임에서 쓸 수 있는 캐릭터가 됩니다.
Mixamo의 자동 리깅은 캐릭터의 뼈대를 잡고, 애니메이션 라이브러리는 움직임을 적용하는 데 도움을 줍니다. 자동 리깅과 라이브러리는 기본적으로 이족보행 인간형을 전제로 합니다. 인간형에 적합한 도구가 거미나 특이한 크리처까지 같은 방식으로 해결해 줄 것이라고 기대하기는 어렵습니다. 가격뿐 아니라 지원하는 캐릭터 형태를 먼저 봐야 합니다.
자산과 도구의 이용 조건도 따로 확인해야 합니다. Unity Personal은 일정 매출·자금 조건 아래 무료이지만 콘솔 배포까지 자동으로 허용하는 것은 아닙니다. Blender의 GPL은 프로그램의 사용·수정·배포 조건이며, 만든 창작물을 전부 공개하라는 뜻은 아닙니다. TRELLIS류 도구는 모델·코드·하위 구성요소의 조건을 각각 봐야 합니다. Mixamo도 추가 구독 없이 이용할 수 있는 편이지만 가져온 원본 캐릭터나 음악의 권리까지 해결해 주지는 않습니다.
실행 확인과 재미 검증은 기준이 다릅니다
두 번째 제작자는 채팅에서 기획한 내용을 Codex에 넘긴 뒤 본인이 직접 플레이하며 피드백했다고 설명했습니다. 공개 웹게임 링크가 있었지만 제가 직접 실행한 것은 아닙니다. 첫 사례와 제작 방식은 달라도, 구현 뒤에 사람이 플레이하며 확인했다는 점은 같습니다.
댓글에는 방어적으로 버티는 전략이 지나치게 강하다는 의견, 전략 선택지 부족, 원거리 유닛과 전열 충돌, 업그레이드 설명, 보상과 진행 속도에 관한 지적이 있었습니다. 제작자도 추가 테스트가 필요하다고 인정했습니다. 저는 이 대목이 좋습니다. 실행되는 게임과 계속 하고 싶은 게임의 통과 기준이 다르다는 사실이 드러나기 때문입니다. 유닛이 움직이는 것뿐 아니라 무엇을 고를지 고민하게 하고, 왜 졌는지 납득할 수 있게 해야 합니다. 버그 수정만으로 끝나기 어려운 부분입니다.
작은 규칙 하나를 직접 플레이하며 고칩니다
처음 AI로 게임을 만든다면 작은 규칙 하나로 시작하는 편이 낫습니다. 예를 들어 위험하지만 보상이 큰 길과 안전하지만 이득이 적은 길 중 하나를 고르게 할 수 있습니다. 최소 플레이 버전을 직접 해보며 같은 행동만 반복해도 이기는지, 목표와 보상이 이해되는지, 실패 이유가 드러나는지 기록합니다. 위험한 길을 고를 이유가 없다면 그 문제 하나를 고친 뒤 다시 해보는 식입니다. 상점·직업·보스·세계관을 늘리는 일은 그다음이어도 됩니다.
총평: 구현을 빠르게 해도 재미는 직접 확인해야 합니다
제가 기대하는 AI 게임 제작은 한 번의 프롬프트로 재미까지 완성하는 방식이 아닙니다. 규칙 후보와 최소 버전을 빨리 만들고, 직접 테스트하며 문제를 하나씩 고치는 반복을 돕는 쪽에 가깝습니다. 제작자의 “됐다”를 플레이어의 “한 판 더”로 바꾸는 일은 여전히 사람 몫입니다. 솔직히 저는 그 점이 오히려 마음에 듭니다. 게임이 아직 사람을 귀찮게 한다는 뜻이니까요.
