“중력이 약한 행성에서 로봇이 장애물을 피해 달리는 게임을 만들어줘.”
몇 년 전까지만 해도 이런 문장은 게임의 아이디어에 불과했다. 실제로 플레이하려면 규칙을 설계하고, 오브젝트를 배치하고, 캐릭터의 움직임과 충돌을 구현한 뒤 필요한 스크립트와 데이터를 연결해야 했다. 하지만, 지난 10월 7일 Google이 공개한 Playground에서는 이 문장 자체가 제작의 시작이 된다.
사용자가 만들고 싶은 게임을 자연어로 설명하면 브라우저에서 바로 실행할 수 있는 형태로 생성하고, 이후에도 대화를 이어가며 물리와 규칙, 캐릭터, 환경을 수정할 수 있다. 코딩 경험이 없어도 게임을 만들고 플레이한 뒤 링크로 공유하거나 커뮤니티 갤러리에 공개할 수 있다는 것이 Google의 설명이다. 현재는 미국의 18세 이상 이용자를 대상으로 제공되는 실험적 플랫폼이다.
심지어 Google은 여기서 한 단계 더 나아가기 위해 Unity와도 손을 잡았다. 두 회사가 같은 날 발표한 Unity Spark는 자연어와 AI를 활용해 게임을 만들고 수정할 수 있도록 설계된 브라우저 기반 게임 제작 플랫폼으로, 현재 클로즈드 베타 테스트를 앞두고 있다. 두 회사가 제시한 방향은 비교적 분명하다. Playground에서 간단한 프롬프트로 시작한 아이디어를 Spark에서는 보다 복잡한 게임 메커니즘과 고품질 3D, Unity Runtime을 활용하는 제작으로 확장한다는 것이다. Unity는 브라우저 기반의 간소화된 에디터와 AI 지원, Asset Store의 아티스트 제작 에셋 활용까지도 예고하고 있다.
물론 아직 이것을 “프롬프트만으로 상용 게임을 만드는 시대”라고 부르기는 어렵다. Playground는 초기 실험이고 Spark는 정식 출시조차 되지 않았다.
그럼에도 흥미로운 변화는 있다. 지금까지 게임의 아이디어를 실행하려면 먼저 코드나 게임 엔진의 기능으로 옮겨야 했다. 이제는 원하는 게임의 동작을 먼저 자연어로 설명하고, 만들어진 결과를 플레이하면서 다시 지시하는 방식이 그 앞에 놓이기 시작했기 때문이다.
게임 개발자와 기획자의 역할은 어떻게 달라질까
프롬프트 기반 제작이 늘어난다고 해서 게임 안의 구현 자체가 사라지는 것은 아니다. 플레이어가 특정 공간에 들어왔는지 확인하고, 적을 생성하고, 문을 잠그고, 남은 적 수를 체크한 뒤 다시 문을 여는 과정은 여전히 어떤 형태로든 게임 내부에서 작동해야 한다. 달라지는 것은 사람이 그 구현에 접근하는 방식이다.
예전에는 이런 기능을 만들려면 개발자가 직접 코드나 비주얼 스크립트를 작성해야 했다. 기획자는 “플레이어가 방에 들어오면 적 5명이 등장하고, 모두 처치할 때까지 출구가 잠겨 있어야 한다”는 규칙을 정하고, 개발자는 그 규칙을 실제로 작동하는 로직으로 옮겼다. 다시 말해 기획과 구현 사이에는 한 번의 번역 과정이 있었다.
프롬프트 기반 제작에서는 이 중간 과정의 일부를 AI가 맡을 수 있다. 기획자가 자연어로 규칙을 설명하면, AI가 이를 바탕으로 1차적인 게임 로직을 만들어주는 식이다. 그렇다고 개발자의 일이 없어지는 것은 아니다. AI가 만든 로직이 제대로 작동하는지, 예외 상황은 없는지, 성능 문제는 없는지, 다른 시스템과 충돌하지 않는지 확인하고 필요하면 직접 수정해야 한다.
그래서 개발자의 역할은 단순히 “코드를 덜 쓰게 된다”기보다 조금 넓어질 수 있다. 직접 만드는 일과 함께, AI가 만든 구조를 이해하고 검증하고 통제하는 일의 비중이 커지는 것이다. 특히 프로젝트 규모가 커질수록 생성된 결과를 그대로 믿기보다, 왜 그렇게 작동하는지 이해하고 문제가 생겼을 때 직접 고칠 수 있는 능력이 더 중요해질 수 있다.
기획자의 역할도 비슷하게 달라질 수 있다. 자연어로 게임을 만들 수 있다고 해서, 문장을 잘 쓰는 것만으로 좋은 결과가 나오는 것은 아니다. “재미있는 전투를 만들어줘”처럼 막연한 요청보다, 플레이어가 적에게 가까이 갈수록 위험과 보상이 함께 커지고, 후퇴하면 적의 추격 강도가 단계적으로 낮아지는 식으로 규칙을 구체적으로 정의해야 원하는 플레이가 만들어진다.
이때 중요한 것은 표현력이 아니라 게임 규칙을 얼마나 분명하게 설계할 수 있느냐다. 거리, 위험, 보상, 상태 변화가 어떤 관계로 작동하는지 먼저 정해져 있어야 AI도 그 구조를 구현할 수 있다. 결국 게임 기획자가 오래 다뤄온 조건과 상태, 예외, 수치 밸런스, 플레이 흐름 같은 요소가 프롬프트 기반 환경에서도 그대로 중요하게 남는다.
오히려 기획자가 만든 규칙이 구현과 더 가까워질 가능성도 있다. 이전에는 기획 문서를 개발자가 다시 코드로 옮기는 과정이 필요했다면, 앞으로는 기획자가 정의한 규칙이 AI를 통해 곧바로 첫 번째 플레이 가능한 형태로 만들어질 수 있기 때문이다. 그만큼 기획자는 자신의 설계를 더 빠르게 시험해보고 수정할 수 있고, 개발자는 모든 작은 기능을 처음부터 작성하기보다 생성된 결과를 더 깊게 검증하는 데 시간을 쓸 수 있다.
정리하면 기존에는 대체로 기획자가 규칙을 설계하고, 개발자가 그것을 구현하는 구조였다면, 프롬프트 기반 환경에서는 기획자가 규칙을 더 직접적으로 입력하고, AI가 1차 구현을 만들고, 개발자가 그 결과를 검증하고 다듬는 구조가 늘어날 수 있다.
결국 구현의 진입장벽은 낮아질 수 있다. 하지만 그만큼 무엇을 구현해야 하는지 판단하는 능력과, 만들어진 결과가 제대로 작동하는지 확인하는 능력의 중요성은 오히려 더 커질 수 있다.
게임 개발은 ‘작성’에서 ‘반복’으로 바뀔까
Playground가 보여주는 변화는 프롬프트를 사용할 수 있다는 사실 자체보다, 아이디어를 시험하는 방식이 달라질 수 있다는 점에 있다. 기존 게임 개발도 아이디어를 기획하고 기능을 구현한 뒤, 빌드해서 직접 플레이해보고 다시 수정하는 과정을 반복해왔다. 다만 아이디어가 실제로 재미있는지 확인하려면 먼저 일정 수준까지 작동하는 형태로 만들어야 했다. 캐릭터가 어떻게 움직일지, 어떤 조건에서 적이 등장할지, 플레이어가 무엇과 상호작용할지를 코드나 비주얼 스크립팅, 엔진 설정 등을 통해 구현해야 비로소 실제 플레이를 확인할 수 있었던 것이다.
Playground에서는 이 과정의 일부를 AI가 대신할 수 있다. 자연어로 원하는 규칙과 동작을 설명하면 우선 플레이 가능한 형태를 만들고, 그 결과를 직접 확인한 뒤 다시 수정 지시를 내리는 식이다. Google도 Playground에서 물리, 규칙, 캐릭터, 환경을 추가 프롬프트로 계속 변경할 수 있다고 설명한다. WIRED의 체험에서도 처음 생성한 게임에 보스나 새로운 적을 추가하고, 캐릭터가 특정 위치에 끼이는 문제를 자연어로 다시 지시해 수정하는 과정이 반복됐다. 물론 수정 과정에서 또 다른 문제가 생기거나, 원하는 만큼 세밀하게 바꾸기 어려운 경우도 있었다.
Unity가 Spark를 설명하는 방식도 비슷하다. Unity CEO Matt Bromberg는 Spark를 한 번의 프롬프트로 완성된 게임을 만들어내는 ‘one-shotting’ 도구로 보지 않는다고 설명했다. 처음 나온 결과를 그대로 사용하는 것이 아니라, 만들고 확인하고 다시 다듬는 과정을 반복하는 것에 더 가깝다는 뜻이다. 따라서 AI가 줄이는 것은 게임 개발 과정 전체라기보다, 아이디어와 첫 번째 플레이 가능한 버전 사이에 사람이 직접 처리해야 했던 구현 작업의 일부일 가능성이 크다.
이 차이는 생각보다 중요하다. 첫 번째 버전을 만드는 시간이 짧아지면, 아이디어를 판단하는 시점도 함께 빨라질 수 있기 때문이다. 예전에는 며칠 동안 기능을 구현한 뒤에야 “생각했던 만큼 재미가 없네”라는 결론에 도달했다면, 앞으로는 훨씬 이른 단계에서 직접 플레이해보고 같은 판단을 내릴 수 있다.
그만큼 아이디어를 버리는 것도 쉬워진다. 하나의 안을 오래 구현한 뒤 수정하는 대신, 서로 다른 규칙이나 움직임, 전투 구조를 짧게 만들어보고 비교한 뒤 더 나은 쪽을 선택하는 방식이 가능해진다. 단순히 개발 속도가 빨라진다고 보기보다, 시도와 판단 사이의 간격이 짧아진다고 보는 편이 더 정확할 수 있다. 이렇게 되면 제작자의 일에서도 조금 다른 능력이 중요해진다. AI가 첫 번째 결과를 빠르게 만들어줄수록 사람은 그 결과를 보고 의도한 플레이가 맞는지, 무엇이 재미없는지, 어떤 부분을 버리고 무엇을 더 발전시킬지 더 자주 결정해야 한다.
결국 프롬프트 기반 제작에서 늘어나는 것은 단순히 ‘생성’의 횟수가 아니라 시도하고, 플레이하고, 판단하고, 다시 수정하는 횟수일 수 있다. AI가 만드는 속도를 높일수록, 그중 무엇을 선택할지를 결정하는 사람의 기준은 오히려 더 중요해진다.
게임 개발의 시작점이 달라진다
지금도 AI는 게임 개발 방식을 빠르게 바꾸고 있다. 생성형 AI로 콘셉트 아트나 임시 에셋을 만들고, 코드 작성과 디버깅을 보조하며, 게임 엔진 안에서도 AI를 이용해 반복 작업을 줄이는 기능이 늘고 있다. Unity 역시 Editor 안에서 코드를 생성하고 문제를 해결하거나 다양한 에셋을 만드는 AI 도구를 제공하고 있다. 이런 변화는 기존 개발 과정에 AI를 더해 속도를 높이는 방식이었다.
Unity Spark가 흥미로운 것은 여기서 한 걸음 더 나아간다는 점이다. Spark는 기존 Unity Editor에 AI 기능을 추가하는 형태가 아니라, 처음부터 브라우저와 AI를 중심으로 게임을 만들도록 설계된 별도의 제작 환경이다. Unity는 게임 개발 경험이 없어도 시작할 수 있는 simplified editor와 AI assistance를 전면에 내세우고 있고, Google 역시 Playground에서 시작한 아이디어를 Spark에서 더 복잡한 게임 제작으로 확장하는 흐름을 제시하고 있다.
이 차이는 단순한 편의 기능 이상의 의미를 갖는다. 지금까지는 Unity 같은 엔진을 먼저 열고 그 안에서 AI를 사용하는 방식이었다면, Spark가 지향하는 흐름에서는 먼저 자연어로 게임을 만들기 시작하고, 필요할 때 엔진의 더 깊은 기능으로 내려가는 방식이 가능해진다.
결국, 게임 엔진 안에서 개발을 보조하던 AI가, 이제는 게임 제작의 시작점 자체로 이동하고 있는 셈이다.
