게임 제작 계획

들어가며#

왜 게임인가에 대한 설명도 필요할 것 같습니다.

사실 딱히 거창한 이유는 없습니다. AI로 코드를 빨리 쓰는 이야기까지는 이제 흔해졌습니다. 많은 분들도 이 변화에 대해서는 이미 체감하고 있을 거라고 생각합니다. 무엇을 출시 가능한 형태로 만들 것인가라는 다소 배부른 고민에서 시작된 것이 바로 게임 개발이었습니다.

이전에는 개발과 그래픽 등의 리소스, 그리고 운영까지 한 가지만 놓고 봐도 쉽게 발을 들일 수 없었던 영역이 지금은 별 생각 없이 시작해볼 수 있는 시대가 된 것 같습니다. 나아가 저도 재미있게 즐길 수 있고, 직업이 아닌 취미에 가까운 개발을 해보는 것도 나름 낭만적인 일인 것 같습니다.

서두가 길었네요. 이번 글에서는 제가 진행해보고자 하는 게임의 장르와, 왜 이런 행보를 선택했는지 이야기해보겠습니다.

구현 순서

왜 첫 장르는 스토리 퀴즈인가#

제가 가장 먼저 잡은 장르는 스토리 퀴즈입니다. 비주얼 노벨처럼 이야기가 전개되고, 중간이나 마지막에 추리를 풀면서 경험치를 얻는 구조입니다. 이 장르를 먼저 택한 이유는 단순합니다. 재미의 중심은 분명히 이야기와 추리에 있는데, 운영 부담은 상대적으로 낮게 유지할 수 있기 때문입니다.

여기서 AI는 모든 곳에 들어가지 않습니다. 스토리 퀴즈에서는 AI를 채점과 제작 보조에 가깝게 두고, 플레이 자체는 사람이 설계한 규칙과 연출 위에 올려놓는 편이 맞다고 생각하고 그렇게 구현했습니다. 그래야 운영이 폭주하지 않고, 동시에 작가(사용자)가 자신의 작품을 출판하는 모델을 실험할 수 있습니다.

아직 초기 구현이긴 하지만, 구현 방향도 이미 그쪽으로 잡혀 있습니다. 원고를 바로 DB에 넣는 방식이 아니라, 마크다운 원고 → 파싱 → 대본 보강 → 프롬프트 생성 → 번역 → import로 이어지는 제작 파이프라인으로 스토리 제작에 AI를 최적화하고자 합니다.

source.md
-> parse-episode.py
-> script-doctor.py
-> prompt-gen.py
-> translate-story.py
-> /bo/story-quiz/games/import

스토리 퀴즈는 어디까지 구현됐나#

현재 저장소 기준으로 스토리 퀴즈는 아이디어 단계에서 조금 더 나아간 상황입니다. 플레이어용으로는 게임 목록과 상세, 세션 생성, 이어하기, 답안 제출, 에필로그 조회까지 이어지는 API가 이미 있고, 백오피스에는 게임, 캐릭터, 페이즈, 블록, 퀴즈, 배경 에셋을 각각 관리하는 구조가 들어가 있습니다. 여기에 전체 게임 데이터를 JSON으로 import, export하는 흐름까지 붙어 있어서, 단일 게임이 아니라 출판 가능한 콘텐츠 포맷으로 다뤄지기 시작했습니다.

중요한 점은 이 장르가 콘텐츠 데이터와 플레이 세션을 분리해서 구현하고 있다는 것입니다. 하나의 게임은 캐릭터, 페이즈, 블록, 퀴즈, 배경 에셋으로 쪼개져 있고, 세션에서는 현재 페이즈, 현재 퀴즈, 사용한 힌트, 점수, 진행 상태가 따로 관리됩니다. 즉, 작가가 작품을 수정하는 흐름과 플레이어가 소비하는 흐름이 이미 다른 레이어로 나뉘어 있습니다.

채점도 같은 철학을 따릅니다. 객관식은 즉시 채점하고, 주관식은 KEYWORD_ONLY, LLM_ONLY, HYBRID, MANUAL 같은 전략과 백오피스 검토 흐름이 따로 잡혀 있습니다. 저에게 중요한 것은 AI가 다 맞다가 아니라 AI를 쓸 수 있는 문제만 AI에 맡기고, 나머지는 사람이 검수할 수 있게 남겨두는 구조입니다.

작품 출판 실험을 위해 전달 계층도 따로 정리하고 있습니다. 커버와 카드 이미지는 public source path와 preset 기반 thumbnail로 전달되고, Asset Studio에서는 Story Quiz와 Mystery의 캐릭터와 배경 자산을 함께 가져와 관리할 수 있게 만들어두었습니다. 결국 스토리 퀴즈는 게임이면서 동시에 작품 제작-검수-출판 파이프라인의 첫 시험장입니다.

왜 다음은 미스터리인가#

스토리 퀴즈가 작가가 설계한 구조화된 경험에 가깝다면, 미스터리는 그보다 훨씬 더 살아 있는 장르입니다. 플레이어는 단서를 읽는 데서 끝나지 않고, 역할을 맡고, 대화를 하고, 서로를 의심하고, 상황을 계속 갱신합니다. 매니악한 장르이긴 하지만, 한 번 잘 맞으면 인게이지먼트가 훨씬 깊어질 가능성이 큽니다.

그리고 바로 여기서 AI의 비중이 크게 올라갑니다. 스토리 퀴즈에서는 AI를 제한적으로 써도 되지만, 미스터리에서는 NPC 반응, 심문, 힌트 보조, 시나리오 보강 같은 영역이 훨씬 핵심 경험에 가깝습니다. 저는 이 장르를 AI가 본격적으로 플레이 경험 안으로 들어오는 두 번째 단계로 보고 있습니다.

미스터리는 어디까지 와 있나#

동시 진행을 하다 보니 미스터리도 이미 작은 단위의 프로토타입을 눈으로 볼 수 있는 형태까지 와 있습니다. 플랫폼 API에는 시나리오 조회, 세션 생성과 초대 코드 참가, 준비 상태, 시작, 페이즈 전환, 노트, 아이템, 심문 기록이 연결되어 있습니다. 세션은 티켓, 초대 코드, 플레이어 목록, 상태 전환을 기준으로 관리되고, 시작 아이템, 시작 노트, 시작 심문 같은 데이터도 따로 붙습니다. 즉, 한 판을 실제로 굴릴 수 있는 세션 모델이 먼저 자리 잡고 있습니다.

제작 쪽은 더 흥미롭습니다. 미스터리에는 Draft Scenario라는 백오피스 흐름이 있고, 생성 단계가 CONCEPT → TRUTH → CHARACTERS → TIMELINE → CLUES → ROLEPLAY → WORLD_BUILDING → SYNOPSIS → PROLOGUE → EPILOGUE로 분리되어 있습니다. 이것은 단순한 글 생성이 아니라, 정답과 동기, 인물 관계, 알리바이, 단서, 역할 반응을 각각 독립된 노드로 다루는 방식입니다. 저는 이 구조가 중요하다고 봅니다. 미스터리는 멋진 문장보다도 논리적 일관성이 먼저여야 하기 때문입니다.

실시간 대화 쪽도 이미 뼈대가 있습니다. 게임 세션 채팅 API에는 캐릭터와의 대화, SSE 스트리밍 응답, AI 조수 채팅이 들어가 있고, 모든 대화는 심문 히스토리에 저장됩니다. 즉, AI가 대답만 던지는 구조가 아니라 세션 안의 기억으로 축적되도록 설계돼 있습니다. 이 장르는 앞으로 AI 의존도가 가장 빠르게 높아질 가능성이 큰 영역입니다.

MMORPG를 마지막 도전으로 보는 이유#

MMORPG는 제게 기술적 호기심만이 아니라 개인적인 향수와도 연결돼 있습니다. 예전에 오래 플레이했던 리니지 같은 감각을 지금 시점의 도구와 구조로 어디까지 다시 만들 수 있는지 시험해보고 싶었습니다. 잘되면 상용화까지 가면 좋겠지만, 그보다 먼저 중요한 것은 이 정도로 무거운 장르를 지금의 개발 방식으로 어디까지 밀어붙일 수 있는가입니다.

또한 MMORPG 구현에서도 위에서 언급한 구조를 세계관, 스토리, NPC 설정 등으로 응용할 수 있는 부분이 많다고 생각합니다.

MMORPG는 구현이 어렵지 않나#

놀랍게도 현재 mmorpg-service도 스펙 기반으로 코드를 어느 정도 뽑아놓은 상태입니다. 현재 코딩 에이전트의 수준은 무엇을 상상해도 그 이상이라고 말할 수 있겠습니다. 단 몇 번의 프롬프트로 실시간 MMORPG의 클라이언트와 서버가 모두 생성되니까 말이죠.

게임은 제가 즐겨 플레이했던 리니지와 유사한 형태로 구현할 계획이고, 게임 서버의 경우 Netty 기반 게이트웨이, 세션 매니저, Redis 세션 동기화, 중복 접속 처리, 월드와 존 생성, 틱 스케줄러, 맵과 패스파인딩, AOI 동기화, 전투 브로드캐스트, 인벤토리와 상점, 드랍과 스폰 흐름이 구현되어 있으며 별도 서비스로 배포되어 있습니다.

런타임 쪽을 보면 GameWorld가 여러 Zone을 관리하고, 세션과 월드 인덱스를 분리해 플레이어를 붙입니다. 몬스터는 단순 스폰 객체가 아니라 IDLE, PATROL, CHASE, ATTACK, RETURN, DEAD 같은 FSM 상태를 가진 런타임 엔티티로 관리되고, 트리거 시스템은 함정 데미지, 주문, 대사, 채팅 같은 월드 반응을 직접 실행합니다. 여기에 월드 시간과 날씨를 따로 지속하는 WorldContinuum까지 붙어 있습니다.

사다리를 만들자#

스토리 퀴즈는 낮은 운영 부담으로 작품 출판을 실험하는 장르입니다. 미스터리는 AI가 플레이 경험 안으로 들어오는 역할 기반 추리를 실험하는 장르입니다. MMORPG는 가장 무거운 실시간 세계에서 지금의 개발 방식이 어디까지 가는지 시험하는 장르입니다.

그래서 이 셋은 서로 다른 프로젝트가 아니라 하나의 사다리처럼 연결되어 있습니다. 저는 가장 가벼운 장르에서 제작 파이프라인과 검수 구조를 먼저 세우고, 그다음에 AI 상호작용의 밀도를 높이고, 마지막에는 실시간 월드까지 올라가보려고 합니다.

결국 보고 싶은 것은 간단합니다. AI 덕분에 게임을 더 빨리 만드는가가 아니라, AI를 어디에 배치해야 사람이 끝까지 책임질 수 있는 게임이 되는가입니다. Omnilude에서 게임을 만드는 일은 지금 제게 그 질문을 가장 진지하게 실험하는 방식입니다.

마무리#

앞선 글들에서 저는 코딩 방식의 변화와 백엔드 구조를 설명했습니다. 이번 글은 그 구조 위에서 실제로 어떤 게임을 어떤 순서로 만들고 있는지에 대한 답에 가깝습니다.

다음에는 이 중 하나를 더 좁혀서, 스토리 퀴즈의 출판 파이프라인이 실제로 어떻게 돌아가는지 혹은 미스터리의 AI 심문 구조를 어떻게 설계하고 있는지 더 구체적으로 풀어볼 생각입니다.