OpenAI Game Builders Seoul - < 2 > | 삐에로의 지식창고

개요

지난 글에서는 게임 개발 오케스트레이션을 Agent-first 구조로 다시 설계한 과정을 정리했다. 판단은 Codex가 맡고, MCP는 외부 도구를 다루며, 최종 승인과 재미 판단은 사람이 맡도록 책임을 나눴다.

구조를 가볍게 만든 이유는 멋진 설계도를 보여주기 위해서가 아니었다. 실제 게임을 더 빨리 만들고 고치기 위해서였다.

이제 그 구조 위에 올릴 게임의 방향이 조금 더 구체화됐다. 하나의 공통 스토리를 바탕으로 2D와 3D 버전을 동시에 만든다. 두 게임을 끝까지 모두 만드는 것은 아니다. 먼저 각각의 작은 MVP를 빠르게 만든 뒤, 더 좋은 경험을 주는 쪽을 골라 완성된 게임으로 키울 계획이다.

같은 이야기도 그림책, 연극, 영화로 만났을 때 느낌이 다르다. 이번 실험은 우리 이야기에 가장 잘 맞는 게임의 말하기 방식을 찾는 과정이다.

스토리의 구체적인 내용은 아직 공개하지 않는다. 이 글에서는 스포일러 대신, 그 이야기를 어떤 방식으로 게임에 옮기려 하는지와 이를 위해 파이프라인을 어떻게 고치고 있는지만 다룬다.

공통 스토리에서 2D와 3D MVP로 나뉜 뒤 플레이 비교를 거쳐 한 방향을 선택하는 흐름

1. 왜 하나를 바로 고르지 않았나

팀은 이미 공통 스토리와 중요하게 보여주고 싶은 장면을 갖고 있다. 하지만 좋은 이야기가 곧 좋은 게임을 뜻하지는 않는다.

게임에서는 플레이어가 직접 움직인다. 영화 속 주인공이 문을 여는 모습을 보는 것과, 내가 조작해서 그 문을 여는 것은 느낌이 다르다. 카메라의 위치, 공간의 크기, 이동 방법이 달라져도 같은 장면에서 받는 감정이 달라진다.

회의만으로 2D와 3D 중 하나를 고르면 결국 머릿속 상상을 비교하게 된다. 그래서 작은 두 버전을 실제로 만들고 플레이하기로 했다.

여기서 MVP(Minimum Viable Product)는 핵심을 시험할 수 있는 가장 작은 게임을 뜻한다. 집 전체를 짓기 전에 작은 모형을 만들어보는 것과 비슷하다. 문이 어디에 있어야 편한지 모형에서 확인하면, 완성한 집의 벽을 다시 허무는 일을 줄일 수 있다.

이번 MVP에서 모든 스테이지와 대사를 완성할 필요는 없다. 대신 다음 질문에 답할 수 있어야 한다.

기획자가 중요하게 생각한 분위기와 하이라이트 장면이 살아나는가?
이야기만 읽을 때가 아니라, 직접 조작할 때도 재미있거나 몰입되는가?
이 방향을 더 큰 게임으로 발전시킬 이유가 보이는가?

답은 아직 정하지 않았다. 2D가 더 싸고 빠르다는 이유만으로 선택하지도 않고, 3D가 더 현실적으로 보인다는 이유만으로 선택하지도 않는다. 플레이해본 결과가 선택의 근거가 되어야 한다.

2. 2D 방향 — 움직이는 동안 이야기를 심는다

2D 버전은 산나비와 같이, 기본적인 게임 플레이 사이에 이야기의 단서를 조금씩 놓는 구성을 생각하고 있다.

플레이어는 먼저 캐릭터를 움직이고 장애물을 넘는 등 게임의 규칙을 배운다. 그러는 사이 배경, 대화, 사물, 짧은 사건이 “이 이야기에는 무언가 더 있다”는 신호를 준다. 처음에는 그냥 지나쳤던 장면이 나중에 다른 뜻으로 돌아올 수도 있다.

누구나 이해할 수 있는 보물찾기로 비유해보자.

앞으로 나아가는 일은 게임의 기본 플레이다.
길에 놓인 쪽지는 이야기의 단서다.
마지막에 쪽지들이 연결되는 순간이 하이라이트다.

이 방식의 장점은 플레이와 이야기가 번갈아 앞으로 나아갈 수 있다는 것이다. 이야기를 보기 위해 계속 멈추지 않아도 되고, 직접 움직이는 과정 자체가 다음 장면을 궁금하게 만들 수 있다.

반대로 조심할 점도 있다. 조작이 너무 어렵거나 빠르면 플레이어가 단서를 놓칠 수 있다. 이야기가 너무 자주 끼어들면 게임의 흐름이 끊길 수 있다. MVP에서는 화려한 콘텐츠 수보다 이 두 박자가 자연스럽게 맞는지를 먼저 확인하려 한다.

현재 2D의 세부 조작과 장르 규칙은 확정하지 않았다. “산나비와 똑같은 게임을 만든다”는 뜻도 아니다. 참고하는 것은 플레이를 이어가면서 복선을 쌓고, 중요한 장면에서 그 의미를 돌려주는 구성 방식이다.

3. 3D 방향 — 좁은 공간을 깊게 체험한다

3D 버전은 1인칭 시점에서 제한된 공간을 탐색하며 주인공의 서사를 따라가도록 구상하고 있다.

1인칭은 화면 속 인물의 등을 보는 대신, 주인공의 눈으로 세계를 바라보는 방식이다. 복도 끝을 볼 때도 내가 그곳에 서 있는 느낌을 줄 수 있고, 뒤에서 들리는 소리나 가까이 놓인 물건 하나에도 시선을 집중시키기 좋다.

공간을 제한하는 것도 단순히 개발량을 줄이기 위해서만은 아니다. 운동장 전체를 뛰어다닐 때보다 불이 꺼진 교실 하나에 있을 때 작은 소리와 물건이 더 크게 느껴질 수 있다. 넓이 대신 밀도를 선택하는 셈이다.

3D MVP에서는 다음과 같은 경험을 확인하려 한다.

플레이어의 시선을 자연스럽게 중요한 곳으로 이끌 수 있는가?
같은 장소가 빛, 소리, 물건의 변화만으로 다른 감정을 줄 수 있는가?
직접 걷고 살펴보는 행동이 주인공의 서사에 몰입하게 만드는가?

여기에도 위험은 있다. 걷고 보기만 해서는 게임보다 관람에 가깝게 느껴질 수 있다. 연출을 강조하느라 플레이어가 할 일이 사라져도 안 된다. 3D라는 형식 자체가 아니라, 플레이어의 행동이 장면의 감정을 더 강하게 만드는지가 핵심이다.

4. 두 게임을 만드는 것이 두 배의 낭비가 되지 않으려면

2D와 3D를 동시에 만든다고 하면 일이 정확히 두 배가 될 것처럼 보인다. 실제로 아무 준비 없이 각각 개발하면 그럴 가능성이 크다.

그래서 공통으로 쓸 수 있는 과정은 하나의 파이프라인으로 묶고, 결과물이 달라지는 지점만 갈라놓으려 한다.

공통 스토리와 기획 의도
        ↓
하이라이트 장면과 검증 질문 정의
        ↓
   ┌────┴────┐
   ↓         ↓
2D MVP     3D MVP
   ↓         ↓
브라우저에서 직접 플레이
   └────┬────┘
        ↓
분위기·재미·몰입감 비교
        ↓
선택한 방향을 완성 게임으로 확장

같은 시험 문제를 두 학생에게 주고 풀이 방법을 비교하는 것과 비슷하다. 시작 이야기와 평가 질문이 같아야 2D와 3D의 차이를 볼 수 있다. 한쪽에만 더 많은 장면과 시간을 주면 어떤 형식이 나았는지가 아니라, 어느 쪽에 더 공을 들였는지를 비교하게 된다.

현재는 기획 담당 팀원이 공통 스토리와 게임 디자인을 마무리하고 있다. 나머지 팀원은 기획이 확정됐을 때 두 MVP를 빠르게 출발시킬 수 있도록 파이프라인을 정리하는 중이다.

5. 파이프라인 수정도 Issue에서 출발한다

지난 구조에서는 개발 과정이 코드와 여러 문서에 흩어질 수 있었다. 이번에는 파이프라인 자체를 고치는 일도 GitHub Issue와 연결한다.

쉽게 말하면 Issue는 작업 전에 쓰는 수리 요청서, 브랜치는 그 수리만 하는 별도의 작업대, Pull Request는 수리가 제대로 됐는지 확인받는 검사표다.

Issue #1
  → 1-feat-pixellab-prompts 브랜치
  → 정해진 범위 안에서 구현과 테스트
  → Closes #1을 적은 Pull Request
  → 검토와 병합

브랜치 이름의 첫 숫자와 Issue 번호가 맞아야 하고, Pull Request도 같은 Issue를 닫도록 연결해야 한다. GitHub Actions가 이 관계를 자동으로 검사한다. 문서의 오타처럼 아주 작은 예외를 제외하면, 열린 Issue 없이 파이프라인 작업을 시작하지 않는 규칙도 두었다.

이 구조가 중요한 이유는 AI 에이전트도 작업의 경계를 읽을 수 있기 때문이다. Issue에는 목표뿐 아니라 이번에 바꿀 것, 바꾸지 않을 것, 완료 조건, 실행할 테스트가 적힌다. 새로운 세션의 에이전트가 와도 “어디까지 손대도 되는가?”를 다시 추측할 필요가 줄어든다.

실제 예시는 [pipeline] PixelLab 2D 에셋 프롬프트 최적화 및 토큰 사용량 개선(비공개..)에서 볼 수 있다. 구현 결과만 적은 것이 아니라 진행률, 테스트 결과, 변경 파일, 아직 남은 PR 검토까지 한곳에 기록했다.

파이프라인 변경 기록은 게임 화면에 바로 보이지 않는다. 하지만 나중에 “왜 생성 방식이 바뀌었지?”라는 문제가 생겼을 때 돌아갈 주소가 생긴다. 빠르게 만드는 팀일수록 이런 주소가 필요하다.

6. PixelLab 2D 에셋 생성 — 전부 자동보다 승인 지점을 둔다

이번에 가장 구체적으로 다듬은 부분은 PixelLab을 이용한 2D 에셋 생성 흐름이다.

AI에게 “이 게임에 필요한 그림을 전부 만들어줘”라고 하면 빠르게 많은 이미지를 얻을 수 있다. 하지만 캐릭터마다 눈 크기가 달라지거나, 같은 숲인데 나무의 색과 픽셀 크기가 제각각일 수 있다. 양은 많아도 한 게임에서 나온 그림처럼 보이지 않는 문제가 생긴다.

그래서 흐름을 두 단계로 나눴다.
( 정확히는 여러 대체방안 중 퀄리티 유지에 도움이 되며 제일 효율적인 Image to Image 방식을 차용한 것이다. )

1단계 — 사람이 기준 이미지를 고른다

먼저 게임 콘셉트에 맞는 초기 시안을 만든다. 사람은 그중 1~4장을 보고 “이 방향이 맞다”고 승인한다.

이 이미지는 미술 시간에 선생님이 보여주는 참고 작품과 비슷하다. 말로 “조금 어둡지만 따뜻하게”라고 설명하는 것보다, 실제 그림 몇 장을 함께 보여주면 기준을 맞추기 쉽다.

2단계 — 승인된 기준으로 필요한 자산을 늘린다

승인된 이미지를 스타일 기준으로 사용해 캐릭터, 몬스터, 타일, 소품, UI 같은 추가 에셋을 만든다. PixelLab의 공식 MCP는 초기 시안을 만드는 데 사용하고, 같은 방향의 변형을 여러 개 만들 때는 REST API를 사용한다.

자동 검사도 추가했다.

그림 크기가 약속과 맞는가?
투명해야 할 배경이 제대로 비어 있는가?
캐릭터가 너무 작거나 화면 끝에서 잘리지 않았는가?
이어 붙여 쓰는 타일에 구멍이나 눈에 띄는 경계가 없는가?

다만 자동 검사가 “이 캐릭터가 우리 이야기와 잘 어울린다”까지 판단하지는 않는다. 자로 잴 수 있는 문제는 코드가 검사하고, 분위기와 의미는 사람이 승인한다.

현재 이 작업은 관련 테스트 89 passed, 전체 테스트 384 passed, 1 skipped, 세 MCP 서버의 계약 검사 통과까지 확인했다. 구현 브랜치는 원격 저장소에 반영됐고, 이제 Pull Request 검토와 병합이 남아 있다.

자동화와 사람의 역할을 나누는 기준은 단순하다. 틀렸는지 숫자로 확인할 수 있는 일은 자동화하고, 작품에 맞는지는 사람이 본다.

7. 무엇으로 더 좋은 방향을 고를 것인가

두 MVP가 만들어지면 그래픽이 더 화려한 쪽을 고르는 것이 아니다. 비교 기준은 처음부터 두 가지다.

① 기획자가 원한 분위기가 하이라이트 장면에 살아 있는가

중요한 장면을 플레이한 뒤 기획자가 의도한 감정과 플레이어가 실제로 받은 감정이 가까운지 확인한다. 장면의 세부 내용은 공개하지 않지만, 2D의 플레이 흐름과 3D의 공간 연출 중 무엇이 그 감정을 더 잘 전달하는지 비교할 수 있다.

② 게임으로서 더 재미있거나 몰입되는가

“스토리가 좋다”와 “게임이 좋다”는 같은 말이 아니다. 플레이어가 직접 하는 행동이 궁금증과 감정을 키우는지 봐야 한다.

이를 위해 플레이가 끝난 뒤 다음처럼 쉬운 질문을 사용할 수 있다.

가장 기억에 남은 순간은 어디였는가?
다음 장면이 궁금해서 계속 플레이하고 싶었는가?
조작 때문에 이야기에 집중하기 어려운 순간이 있었는가?
내가 직접 행동해서 장면이 더 강하게 느껴졌는가?

플레이 시간이나 오류 수 같은 숫자도 기록할 수 있다. 하지만 감정과 재미를 숫자 하나로 줄이지는 않을 생각이다. 설문 답변, 플레이 중 막힌 지점, 기획자의 판단을 함께 놓고 본다.

아직 2D와 3D 중 어느 쪽이 이길지는 모른다. 그것을 모르는 상태로 두는 것이 이번 개발 방식의 중요한 부분이다.

8. 지금은 게임보다 게임을 빨리 시험하는 길을 닦는 중

첫 글에서 복잡한 오케스트레이션을 줄였다. 이번에는 그 가벼워진 구조가 실제 제작 속도와 품질로 이어지도록 작업 단위를 정리하고 있다.

기획 담당자는 공통 스토리와 게임 디자인을 마무리한다.
파이프라인 변경은 Issue, 브랜치, Pull Request로 이어지게 한다.
2D 에셋은 사람이 고른 1~4장의 기준 이미지로 품질 방향을 고정한다.
기술적으로 검사할 수 있는 결함은 자동으로 찾는다.
2D와 3D MVP는 같은 하이라이트와 질문으로 비교한다.

도로를 닦는 데만 시간을 쓰면 목적지에 도착하지 못한다. 반대로 길이 없는 상태에서 두 게임을 동시에 만들면 같은 문제를 두 번 겪게 된다. 지금의 목표는 완벽한 파이프라인이 아니라 두 MVP를 만들기에 충분하고, 문제가 생기면 곧바로 고칠 수 있는 파이프라인이다.

다음 글에서는 게임 디자인이 확정된 뒤 이 흐름이 실제 MVP 제작에서 어디까지 작동했는지 기록하려 한다. 계획과 실제 결과가 다르면, 다른 지점도 그대로 남길 예정이다.

한줄 평

AI의 생산성이 폭발적으로 늘어나는 시대이기에 시도해볼만한 상황이라 생각한다. 물론 기한의 한계점이 보일 수 있지만, 그것또한 경험으로 병목구간을 확인하는 것에 의미가 있다고 생각한다!