개요

NAN(Next AI Network) 해커톤이 끝났다. 한 달 동안 만든 것은 게임 한 편이라기보다 게임을 만드는 AI 파이프라인에 가까웠다.

아이디어를 넣으면 기획하고, 기능 명세로 나누고, 코드를 만들고, 에셋을 생성하고, Unity에서 검증하는 흐름까지 연결했다. LangGraph 노드 16개와 여러 번의 검사·되돌림 과정도 만들었다. 당시에는 자동화 단계를 더 촘촘하게 잇는 것이 좋은 구조라고 생각했다.

그런데 실제 게임은 대부분 마지막 바이브 코딩 단계에서 완성됐다. 파이프라인은 돌아갔지만, 구조를 만든 우리조차 문제가 생겼을 때 어느 서버와 문서를 먼저 봐야 할지 헤매는 일이 생겼다.

자동화 단계가 많다고 좋은 오케스트레이션은 아니다. 중요한 것은 누가 판단하고, 어떤 도구가 어디까지 책임지는지 명확한가이다.

NAN 해커톤의 회고를 끝내자마자 OpenAI Game Builders Seoul 참가를 준비하게 됐다. 이번에는 기존 구조를 그대로 재사용하지 않고, 지난 한 달 동안 실제로 필요했던 것만 남기기로 했다.

1. 다음 행사가 던진 질문

OpenAI Game Builders Seoul의 온라인 예선은 Codex로 플레이 가능한 게임을 만드는 것이 핵심이다. 심사 기준에는 게임의 완성도뿐 아니라 독창성, Codex 활용 과정, 출시 가능성, 발표와 시연도 포함된다. 제출 결과물은 별도 설치 없이 브라우저에서 바로 실행되어야 한다.

즉, 이번에는 “AI 파이프라인이 얼마나 거대한가?”보다 다음 질문에 답해야 한다.

  1. 게임의 핵심 재미가 실제로 작동하는가?
  2. Codex와 사람이 각각 무엇을 결정했는가?
  3. 짧은 시간 안에 수정하고 다시 실행할 수 있는가?
  4. 그 개발 과정을 다른 사람에게 분명하게 설명할 수 있는가?

기존처럼 중앙 서버와 여러 AI 단계를 거쳐야만 코드 한 줄을 고칠 수 있다면 이 질문에 좋은 답을 내기 어렵다. 그래서 목표를 완전 자동화에서 빠르게 이해하고 고칠 수 있는 협업 구조로 바꿨다.

2. 기존 구조에서 무엇이 무거웠나

NAN 해커톤 당시 구조에는 분명 장점이 있었다. 각 단계가 해야 할 일을 정해두었고, 실패하면 어디로 돌아갈지도 표시했다. AI가 끝없이 재시도하지 않도록 횟수 제한도 뒀다.

문제는 비슷한 판단이 여러 곳에 흩어졌다는 점이다.

기존 구성 실제로 겪은 문제
중앙 웹/API 오케스트레이터 호스트 에이전트가 이미 할 수 있는 순서 판단을 다시 구현했다.
여러 역할의 모델 호출 파이프라인 앞 단계의 문맥이 다음 단계로 넘어갈 때 자주 끊겼다.
Git·QA 전용 MCP 로컬 Git과 테스트 명령으로 가능한 작업까지 별도 계층이 생겼다.
분산된 Doc/과 계획 문서 현재 규칙과 오래된 규칙을 구분하기 어려웠다.
샘플 게임과 생성 에셋 보관 다시 만들 수 있는 파일이 쌓여 저장소의 목적을 흐렸다.

쉽게 비유하면, 요리사 한 명이 충분히 판단할 수 있는데도 “칼질 지시 서버”, “불 조절 지시 서버”, “접시 검사 서버”를 따로 둔 셈이다. 사람이 많아진 것이 아니라 연락할 곳만 많아졌다.

그래서 먼저 모든 실행 경로를 펼쳐놓고 세 가지를 확인했다.

  • 이 구성은 외부 시스템과 연결되는 진짜 경계인가?
  • 호스트 에이전트가 직접 판단하면 더 단순해지는가?
  • 삭제해도 코드·테스트·Git 기록으로 다시 확인할 수 있는가?

이 기준을 통과하지 못한 계층은 제거했다.

3. Agent-first로 중심 바꾸기

새 구조의 핵심은 Agent-first다. Codex가 현재 상황을 읽고 작업 순서를 판단하며, MCP는 외부 도구를 안전하게 다루는 손과 눈의 역할만 맡는다.

사용자와 팀
    ↓ 목표·피드백
Codex — 판단, 순서 결정, 문맥 관리
    ├─ Research MCP — 근거와 반례 검색
    ├─ Unity MCP    — 에디터 조작과 실행 검증
    ├─ Asset MCP    — 게임 에셋 생성과 형식 검사
    └─ Native Git   — 승인 후 커밋·푸시·태그

여기서 중요한 것은 “MCP를 많이 쓰는가?”가 아니다. MCP(Model Context Protocol)는 AI가 다른 프로그램을 사용할 수 있게 연결해주는 표준 리모컨에 가깝다. 리모컨은 TV를 켤 수는 있지만, 무엇을 볼지는 사람이 정한다. 같은 방식으로 MCP는 검색·Unity 조작·에셋 생성을 실행하고, 무엇을 언제 실행할지는 Codex가 결정한다.

이번 리팩터링으로 유지한 것은 실제 외부 경계인 Research, Unity, Asset MCP 세 개다. 중앙 웹/API 오케스트레이터, 웹 UI, Git MCP, QA MCP, 예전 모델 호출 파이프라인은 제거했다. 재생성 가능한 샘플과 에셋은 저장소에서 빼고 var/ 런타임 출력으로 분리했다.

문서도 줄였다. 실행 규칙을 여러 문서에 복사하지 않고, 현재 구조를 설명하는 소수의 문서와 에이전트별 얇은 안내만 남겼다. 오래된 설계 문서에만 있던 규칙은 가능한 경우 코드 주석과 테스트로 옮겼다.

결과적으로 구조는 작아졌지만 할 수 있는 일은 줄지 않았다. 오히려 Codex가 기획 근거를 찾고 Unity를 수정한 뒤 테스트까지 이어가는 경로가 짧아졌다.

4. RAG도 같은 원칙으로 정리하기

오케스트레이션만 가벼워져도, 검색한 지식이 부정확하면 기획 결과는 흔들린다. 그래서 게임 디자인 리서치 저장소(현재 비공개)의 RAG 구조도 함께 손봤다.

RAG(Retrieval-Augmented Generation)는 어려워 보이지만 원리는 단순하다.

AI가 기억만 믿고 대답하지 않고, 필요한 자료를 먼저 찾아 읽은 뒤 답하게 하는 방식이다.

현재 리서치 저장소에는 게임, 장르, 게임 요소, Unity 아키텍처, 시장 신호를 카드 형태로 모은다. 카드의 Markdown 파일이 원본이며 Postgres와 pgvector는 언제든 다시 만들 수 있는 검색용 거울이다. 데이터베이스를 직접 고치지 않는 이유도 여기에 있다. 거울에 그림을 그려도 원본 사진은 바뀌지 않기 때문이다.

카드 전체가 아니라 필요한 절만 찾기

예전에는 관련 카드가 나오면 긴 본문을 통째로 읽는 경우가 많았다. 이제는 card_sections에 저장된 절 단위로 검색한다.

예를 들어 “덱빌딩 로그라이트의 흔한 실패”를 찾는다면 게임 소개 전체를 여러 장 읽지 않고, 실패 사례나 시장 포화 같은 관련 절부터 가져온다. 벡터 검색과 문자열 검색을 함께 사용하고, 화면에 보이는 한국어·영어 제목과 별개로 section_key라는 고정 키를 사용한다.

이전 방식 현재 방식
카드 본문 전체를 읽음 질문에 필요한 절만 읽음
한글 Markdown 제목을 정규식으로 다시 찾음 DB의 언어 중립 section_key를 직접 조회
비슷한 규칙이 여러 문서에 존재 AGENTS.md를 실행 정책의 단일 원본으로 사용
특정 벤더 SDK에 고정된 생성 스크립트 Codex·Claude가 같은 프롬프트와 CLI 계약을 사용
일부 패치 성공도 정상 완료처럼 보일 수 있음 모든 대상을 먼저 검사하고 하나라도 틀리면 쓰지 않음

에이전트가 읽는 프롬프트, 도구 설명, 카드 본문은 영어로 통일했다. 번역 자체가 목적은 아니다. 기계가 읽는 규칙의 표현을 하나로 맞춰 중복과 토큰 낭비를 줄이기 위해서다. 팀 회의, 사용자 요청, 사람이 작성하는 기획 입력은 계속 한국어로 사용할 수 있다.

현재 검증 결과

구조를 고친 뒤에는 “깔끔해 보인다”에서 끝내지 않고 실제 검사를 돌렸다.

  • 메인 오케스트레이션 MCP 테스트: 343 passed, 1 skipped
  • Research 11개, Unity 13개, Asset 9개 도구 계약 확인
  • RAG 카드 165장과 절 829개 형식 검사 통과
  • 검색 DB에 다이제스트 6개 동기화
  • 링크 감사의 확실한 결함 0건
  • DB의 해결되지 않은 참조 unresolved_refs: 0
  • Git 공백 오류 없음

아직 끝난 것은 아니다. 문맥을 읽어야 판단할 수 있는 링크 후보 8건이 남았고, 새 Agent-first 경로로 카드 작성 한 사이클을 실제 운영해봐야 한다. Unity 프로젝트가 연결되지 않은 환경에서는 Unity 산출물 검사도 건너뛴다. 자동화에서 가장 위험한 말이 “아마 될 것”이기에, 확인하지 못한 부분은 확인하지 못했다고 남겨둔다.

5. 이번 게임은 어떻게 만들 것인가

이번에는 처음부터 거대한 파이프라인을 완성한 뒤 게임을 넣지 않는다. 작게 플레이하고, 팀이 고치고, 다시 측정하는 순서로 진행하려 한다.

1단계 — 재미 하나를 먼저 실행한다

게임 아이디어 전체를 한 번에 구현하지 않고, 30초 안에 설명할 수 있는 핵심 플레이를 먼저 만든다.

아이디어 한 줄
  → RAG에서 근거·반례 검색
  → 핵심 행동 1개와 실패 조건 정의
  → Codex + Unity MCP로 구현
  → WebGL 빌드로 브라우저 플레이 확인

행사 제출물은 브라우저에서 바로 실행되어야 하므로 WebGL 빌드를 마지막에 붙이는 일이 아니라 첫 번째 세로 조각에 포함한다. “세로 조각”은 기획부터 화면 실행까지 가늘게라도 전부 연결된 작은 기능을 뜻한다.

2단계 — 팀이 고칠 수 있는 기획으로 만든다

AI가 긴 기획서를 한 번에 만들면 한 문장을 바꾸기 위해 전체를 다시 생성하게 된다. 이번에는 기획을 다음처럼 수정 가능한 칸으로 나눈다.

  • 플레이어의 핵심 행동
  • 1회 플레이의 목표와 종료 조건
  • 재미를 만드는 선택
  • 실패했을 때 배우는 정보
  • 필요한 화면·사운드 피드백
  • 구현 완료를 판단할 수 있는 검사 기준

팀원은 필요한 칸만 고치고, Codex는 바뀐 부분의 영향 범위만 다시 확인한다. 잘 만들어진 부분까지 매번 지우는 일을 줄이기 위한 방식이다.

3단계 — 구조 개선도 숫자로 확인한다

“전보다 편해졌다”는 느낌만으로는 다음 개선점을 찾기 어렵다. 기능 하나를 완성할 때 아래 항목을 함께 기록하려 한다.

  • 아이디어에서 첫 플레이까지 걸린 시간
  • 기능 수정에 사용한 에이전트 호출 수와 토큰
  • 실패 후 사람이 개입한 지점
  • RAG가 가져온 근거 중 실제로 사용한 비율
  • 빌드·테스트 실패 원인과 재발 여부

이 숫자가 쌓이면 도구를 더 붙여야 할지, 프롬프트를 고쳐야 할지, 아니면 사람이 결정해야 할지를 구분할 수 있다.

6. 이번 리팩터링에서 배운 것

① 오케스트레이션은 상자가 아니라 책임의 문제다

상자를 많이 그리면 설계가 정교해 보인다. 하지만 같은 판단을 여러 상자가 나눠 가지면 문맥을 전달하는 비용이 더 커진다.

이번에는 판단은 Codex, 외부 실행은 MCP, 최종 승인과 재미 판단은 사람으로 경계를 다시 그었다. 누가 책임지는지 한 문장으로 설명할 수 있으니 문제를 찾는 위치도 빨라졌다.

② RAG의 품질은 자료 수보다 검색 경로에서 갈린다

카드를 많이 모아도 질문과 상관없는 긴 글을 통째로 넣으면 중요한 근거가 묻힌다. 필요한 절만 찾고, 사실과 해석을 구분하고, 해결되지 않은 참조를 검사하는 과정이 카드 수를 늘리는 것보다 먼저였다.

③ 완전 자동화보다 사람이 다시 잡을 수 있어야 한다

AI는 빠르지만 항상 같은 답을 내놓지 않는다. 그래서 실패가 없게 만드는 것보다 실패했을 때 어디서 멈추고 사람이 어떻게 이어받는가를 설계하는 편이 현실적이다.

NAN 해커톤에서는 이 사실을 한 달 동안 시행착오로 배웠다. OpenAI Game Builders Seoul에서는 그 실패 기록부터 출발하려 한다.

한줄 평

  • 지난번에는 게임을 만드는 AI를 만들었다면, 이번에는 팀과 함께 계속 고칠 수 있는 게임 제작 방식을 만들어보고 싶다. 구조는 가벼워졌지만 이제부터 진짜 게임으로 증명해야 한다..!