개요
2026.07.10 ~ 2026.08.09, 31일. 사전 과제 제출을 마쳤다. 15편에 걸쳐 적어온 내용을 한 번 정리하고, 다음에 반드시 다르게 할 것을 남기는 편이다.
제출물 한 줄 요약
AI로 게임을 만든 것이 아니라, 게임을 만드는 AI 파이프라인을 만들었다.
- 게임 : Slime Ranch (슬라임 목장) · Unity 6000.5.5f1 · 2D URP
- 게임 저장소 : ys143112/Slime
- 오케스트레이터(비공개) : min-0o0/Game-Developer-AI
결국 어떤 구조였나
개발을 두 단계로 나눴다.
1단계 · 자동 생성 — 아이디어 한 줄을 넣으면 기획 → 기능 명세 분해 → C# 코드 생성 → 픽셀 에셋 생성 → 빌드 → 검증까지 돌아간다. LangGraph 상태 머신 노드 16개, 되돌림 루프마다 횟수 상한, 상한을 넘기면 무조건 사람에게 넘어온다.
2단계 · 바이브 코딩 — Unity MCP + Claude Code로 사람이 플레이하며 고친다. 게임의 대부분의 기능은 사실 이 단계에서 완성됐다.
직접 만든 것과 가져다 쓴 것
| 구분 | 내용 |
|---|---|
| 팀이 설계 | 파이프라인 절차(노드 16개·승인 게이트·재시도 상한), 기획 규칙(RAG·근거/반례 강제·금지어·spec-lint), 검증 규칙(L1~L7·구조 대조·오류 리포트 스키마), 출력 통제(JSON Schema), 비용 통제(usage 집계) |
| 가져다 씀 | Unity 엔진 제어(Unity 공식 AI Assistant MCP), 픽셀 에셋 생성(Pixellab.ai API), 코드 작성(Claude Code) |
이 구분을 문서에 굳이 적은 이유가 있다. AI로 개발하면 “내가 만든 것”의 경계가 흐려진다. 그 경계를 스스로 그어두지 않으면 나중에 무엇을 고칠 수 있고 무엇을 못 고치는지도 모르게 된다.
정직하게 남기는 실패 기록
성공만 적으면 회고가 아니다.
| 문제 | 증상 | 대응 |
|---|---|---|
| 클래스명이 문서 ID로 생성 |
Spec001.cs ~ Spec006.cs 가 나옴 |
설계 단계와 결과 검사가 같은 정규식을 공유하도록 수정 (규칙 L1) |
| 프리팹 규칙이 문장으로만 존재 | 저장소 전체에 prefab 문자열 0건 — 지키는지 논할 수조차 없었음 |
규칙마다 구현 위치 + 위반 탐지 검사를 표로 못 박음 |
| 파일 간 문맥 단절 | 다른 파일에 이미 있는 타입을 재정의 | 선언된 모든 타입을 다음 호출의 existing_types 로 전달 |
| 프롬프트 캐싱이 조용히 실패 | 최소 길이 미달 시 오류 없이 무시되어 “절감했다는 착시”만 남음 | 토큰 수 추정 후 기준 초과 시에만 캐시 지점 부착 + 회귀 테스트 |
| 자체 LoRA 에셋 품질 미달 | tile·prop이 9 epoch까지 기준(0.25) 미달, GPU는 VRAM 6GB 한 대 | 자체 학습 폐기, Pixellab.ai API로 전환 |
| 무거운 import로 서버 기동 실패 | 존재 확인용 import가 torch를 끌어와 55.2초 — 30초 제한 초과로 서버 1대 증발 |
importlib.util.find_spec 으로 교체(3.2초) + 회귀 테스트 고정 |
| MCP 설정 경로 오류 | 서버 전체가 “지정된 경로를 찾을 수 없습니다”로 즉사 | 경로 규칙 통일 + 확인 절차를 SETUP.md에 명문화 |
도달하지 못한 것 — 완전 무인 실행, 자체 에셋 생성 모델, 과거 성공 사례를 자동 주입하는 RAG 예시 검색, 에셋 사람 검수 절차의 운영 정착. QA AI도 일정이 겹쳐 단순 코드 점검 수준까지만 돌렸다.
액션 아이템
다음에 반드시 다르게 할 것들을 항목으로 남긴다.
1. 게임 기획 템플릿 — 초안 뒤에 세부를 직접 고칠 수 있게
지금은 기획 산출물이 한 번에 통째로 나온다. 그러다 보니 “여기 한 줄만 바꾸고 싶은데” 가 안 돼서 결국 전체를 다시 돌리게 된다.
칸이 정해진 템플릿으로 뽑아서, 사람이 그 칸만 열어 고치고 다시 검사만 태우는 흐름으로 바꿔야 한다. (전체 재생성 = 비용 + 방금 잘 나온 부분까지 사라짐)
2. 에이전트 마이그레이션 매뉴얼 (가이드 보드)
지금 구조는 만든 사람 머릿속에 절반이 있다. 에이전트 하나를 다른 프로젝트로 옮기려면 뭘 챙겨야 하는지 문서가 없다.
에이전트마다 입력·출력·의존 도구·환경변수·검사 항목을 한 장으로 정리해 두면, 옮기는 게 “복사 후 이 표대로 채우기” 가 된다.
3. 구현된 게임 구조를 그림·문서로 동시 생성
이번에 디버깅이 오래 걸린 지점은 대부분 구조가 눈에 안 보여서 였다. 코드는 만들어지는데 “이 시스템이 저 시스템을 부르는 게 맞나?” 를 확인할 그림이 없었다.
코드 생성과 동시에 클래스 관계도·씬 구성도·데이터 흐름도를 뽑게 하면, 논리 오류를 코드 읽기 전에 그림에서 잡을 수 있다.
4. 애니메이션 스프라이트 생성 도구
이번에 제일 아팠던 부분이다. Asset 서버는 “글 → 정지 이미지 한 장” 밖에 못 했고, 게임은 8방향 회전과 프레임 애니메이션이 필요했다. 결국 54종 중 4종만 쓰고 나머지는 사람이 웹에서 다시 뽑았다.
게임에 바로 들어갈 수 있는 형태(방향별 시트, 프레임 시퀀스, 아틀라스)로 뽑는 것까지가 도구의 범위여야 한다.
5. 에셋 생성 프로세스 고도화 — 프롬프트와 피드백을 문서로
무기를 분리해 쓰면 5점, 포함해 쓰면 2점. 이런 건 실측해봐야 알 수 있고, 알아낸 뒤엔 기록해두지 않으면 다음 사람이 또 겪는다.
프롬프트 → 결과 → 점수 → 수정된 프롬프트를 한 쌍으로 남기면, 그 자체가 다음 RAG의 학습 데이터가 된다.
이번 프로젝트에서 배운 두 가지
① AI 협업은 불안정하다 — 그래서 기획이 더 중요해진다
AI는 같은 요청에도 매번 다른 답을 낸다. 이 흔들림을 사람이 매번 손으로 잡으면 개발이 진행되지 않는다.
그래서 합격 기준에 금지어를 두고 측정 가능한 문장만 허용했다. 기획이 애매하면 AI 산출물도 애매해지고, 그 애매함은 결국 코드에서 드러난다.
“프롬프트를 잘 쓰는 것”보다 “무엇이 완성인지 먼저 정하는 것”이 효과가 컸다.
② 사람이 디버깅할 수 있게 설계해야 한다
AI에 의존할수록 토큰 소모가 커지고, 문제가 생겼을 때 AI에게 다시 물어보는 것 자체가 비용이 된다.
- 코드 생성 프롬프트에 “클래스 위에 원인 기능 id를 주석으로 남긴다”를 넣어 오류를 기능 단위로 되짚게 함
- 사람이 읽을 수 있는 폴더·파일 구조를 정하고 README에 적어 어디를 봐야 하는지 남김
- 모든 되돌림 루프에 상한을 두어, 막히면 AI가 계속 태우는 대신 사람에게 넘어오게 함
한줄 평
- 한 달 동안 만든 건 게임이 아니라 “게임을 만드는 방법”이었고, 그 방법의 절반은 실패 기록이었다..! 그래도 다행히 마감기한 내에 제출해서 고생해준 팀원분들이 너무 고맙다!!