AI로 게임 개발하기 7일차 — 공백 후 복귀, 문서로 컨텍스트 복원

1주일 만의 복귀

6일차가 2월 25일이었다. 오늘은 3월 4일. 약 1주일의 공백이 있었다. 그 사이에 AI Trading 시리즈에 집중하느라 게임 프로젝트를 손대지 못했다.

1주일이 지나면 프로젝트의 상태가 머릿속에서 흐려진다. 어디까지 했는지, 뭐가 남았는지, 다음에 뭘 해야 하는지 — 전부 다시 파악해야 한다. 코드를 바로 작성하고 싶은 충동이 있지만, 공백 후 첫 세션에서 코드를 작성하면 높은 확률로 잘못된 방향으로 간다.

오늘은 코드를 한 줄도 작성하지 않았다. 대신 docs/PLAN.md와 docs/TODO.md를 열어서 현재 상태를 점검했다.

공백 후 복귀 전략 — 왜 상태 점검이 먼저인가

AI와 함께 개발할 때, 공백 후 복귀에는 특별한 주의가 필요하다.

사람 혼자 개발할 때는 코드를 직접 작성했으므로 맥락이 손에 남아 있다. 1주일 쉬어도 “아, 그때 그 버그”하고 기억이 돌아온다. 하지만 AI와 함께 개발하면 코드 생성 속도가 빨라서 맥락이 몸에 배기 전에 다음 피처로 넘어간다. 5일차에 하루 만에 무기 20종을 찍어냈던 것을 떠올려 보면, 그 코드들의 세부 구현을 1주일 뒤에 기억하는 것은 불가능하다.

그래서 복귀 첫 세션의 원칙을 정했다.

1. 문서 먼저. 코드가 아니라 PLAN.md와 TODO.md부터 연다.
2. 현황 파악. 전체 피처 목록에서 완료/미완료를 확인한다.
3. 우선순위 결정. 남은 피처들의 의존 관계와 난이도를 판단한다.
4. 다음 세션 계획. 오늘은 계획만 세우고, 실제 구현은 다음 세션에서 한다.

이 순서를 지키면 “1주일 전에 뭘 했더라?”라는 혼란 없이 바로 생산적인 상태로 복귀할 수 있다. AI에게도 정확한 컨텍스트를 전달할 수 있다.

현재 상태 — 31/36에서 32/36으로

6일차 기준 달성률은 31/36(86%)이었다. 오늘 TODO.md를 다시 점검한 결과, 미완료 항목이 4개로 확인되었다. 6일차에서는 업적과 도감을 별도 피처로 카운트해 5개 남은 것으로 봤지만, 다시 점검하니 업적 시스템의 핵심 로직이 기존 이벤트 시스템에 이미 포함되어 있었다. 업적을 완료 처리하고, 도감만 독립 피처로 남겼다.

32/36. 달성률 89%.

남은 4개 피처 분석

M4-27: 도감 시스템

게임 내에서 플레이어가 만난 적, 획득한 무기, 수집한 아이템을 기록하는 컬렉션이다. Vampire Survivors의 도감과 유사한 형태를 목표로 한다.

구현 관점에서 보면 이것은 데이터 수집 + UI다. 게임 플레이 중 발생하는 이벤트(적 처치, 무기 획득, 아이템 드롭)를 감지해서 PlayerPrefs나 SaveData에 기록하고, 도감 화면에서 카드 형태로 보여주면 된다. 6일차에 분석한 WeaponData ScriptableObject가 여기서 재활용된다 — 도감에 표시할 무기 이름, 아이콘, 설명이 이미 SO에 들어 있다.

난이도는 중간. UI 작업이 메인이고, 로직은 단순한 편이다.

M5-31: 온보딩 튜토리얼

첫 플레이 시 이동, 레벨업, 무기 선택을 순서대로 안내하는 3단계 튜토리얼이다.

뱀서라이크에서 튜토리얼이 필요한가? 장르 특성상 조작이 단순하므로 길게 할 필요는 없다. 하지만 “레벨업 시 무기를 선택하는 것”은 처음 접하는 플레이어에게 명확하게 알려줘야 한다. 3단계면 충분하다.

1. 조이스틱으로 이동 (화살표 가이드)
2. 경험치를 모아 레벨업 (강조 이펙트)
3. 무기 선택 창에서 무기를 고르기 (손가락 포인터)

구현은 TutorialManager가 게임 상태를 감시하다가, 조건 충족 시 오버레이 UI를 띄우는 방식이 될 것이다.

M5-32: 수익화 (보상형 광고)

보상형 광고 3곳을 넣어야 한다. 위치는 아직 확정하지 않았지만, 뱀서라이크의 일반적인 패턴을 따르면 다음과 같다.

1. 부활 — 사망 시 광고를 보고 1회 부활
2. 보상 2배 — 런 종료 후 골드 2배
3. 무료 뽑기 — 도감/상점에서 무료 아이템 획득

AdMob SDK 연동이 필요하다. Unity에서 AdMob은 GoogleMobileAds 패키지를 사용하며, 보상형 광고는 RewardedAd 클래스로 구현한다. 코드 자체는 보일러플레이트가 대부분이라 AI에게 맡기기 좋은 작업이다.

M5-35: 모바일 최적화

이것이 가장 까다로운 작업이다. 세 가지가 포함된다.

• SpriteAtlas 패킹 — 개별 스프라이트를 아틀라스로 묶어 draw call을 줄인다.
• 배칭(Batching) — 같은 머티리얼을 사용하는 오브젝트를 한 번에 그린다. Dynamic Batching, GPU Instancing 설정.
• Safe Area 대응 — 노치/펀치홀 디스플레이에서 UI가 잘리지 않도록 Screen.safeArea를 적용한다.

최적화는 “측정 → 병목 확인 → 개선 → 재측정” 사이클이 필요하므로, Android 빌드를 실기기에서 돌리면서 Unity Profiler로 프로파일링해야 한다. AI가 코드를 생성할 수는 있지만, 실기기 성능 측정은 사람이 직접 해야 한다.

우선순위 결정

4개 피처의 우선순위를 다음과 같이 정했다.

1순위: M4-27 도감 시스템
  → 게임 콘텐츠 완성도에 직결. 기존 SO 데이터 재활용 가능. AI에게 맡기기 좋음.

2순위: M5-31 온보딩 튜토리얼
  → 도감이 완성된 후에 튜토리얼에서 도감도 안내할 수 있음. 순서 의존.

3순위: M5-32 수익화
  → AdMob SDK 연동은 독립적. 도감/튜토리얼과 병행 가능하지만, 게임이 완성에 가까워진 후 넣는 것이 테스트에 유리.

4순위: M5-35 모바일 최적화
  → 모든 피처가 완성된 후 마지막에 수행. 중간에 최적화하면 이후 추가된 피처가 성능을 다시 떨어뜨릴 수 있음.

이 순서의 핵심 논리는 콘텐츠 → UX → 수익화 → 최적화다. 콘텐츠가 없으면 UX를 설계할 수 없고, UX가 없으면 수익화 위치를 정할 수 없고, 모든 기능이 들어간 후에야 최적화가 의미 있다.

AI와 공백 후 복귀 — 기록이 전부다

1주일 만에 돌아와서 30분 만에 상태를 완전히 파악할 수 있었던 이유는 docs/PLAN.md와 docs/TODO.md가 있었기 때문이다.

AI와 함께 개발할 때 가장 중요한 습관 중 하나는 진행 상황을 문서로 남기는 것이다. AI는 세션 간 맥락을 유지하지 못한다. 사람도 1주일이면 맥락을 잃는다. 문서만이 공백을 넘어 맥락을 전달할 수 있는 유일한 매체다.

이 프로젝트에서 유지하고 있는 문서는 다음과 같다.

이 세 파일만 읽으면 프로젝트의 현재 위치를 정확히 알 수 있다. AI에게 새 세션을 시작할 때 이 파일들을 먼저 읽게 하면, AI도 즉시 맥락을 파악한다.

복귀 시 흔히 하는 실수는 “기억에 의존해서 바로 코드를 작성하는 것”이다. 기억은 부정확하다. 특히 AI가 빠르게 생성한 코드의 세부 사항은 더 그렇다. 문서를 먼저 읽고, 현재 상태를 확인하고, 그 다음에 코드를 작성하는 것이 결국 더 빠르다.

숫자로 보는 하루

다음 단계

다음 세션에서는 도감 시스템(M4-27)에 착수한다. 구체적으로는 다음 순서로 진행할 계획이다.

1. GDD에 도감 카테고리 및 항목 목록 추가 (적 30종, 무기 20종, 아이템 목록)
2. CollectionData ScriptableObject 설계
3. CollectionManager 구현 — 이벤트 리스너로 수집 데이터 기록
4. 도감 UI 구현 — 카드 그리드, 잠금/해제 상태 표시, 상세 정보 팝업
5. SaveSystem에 도감 데이터 저장/로드 추가

기획이 확정되면 AI에게 한 번에 구현을 맡길 수 있다. 5일차에서 무기 20종을 하루 만에 찍어냈던 것처럼, 도감도 기획만 단단하면 하루면 끝날 것이다.

오늘은 코드를 한 줄도 작성하지 않았지만, 다음 세션에서 정확한 방향으로 코드를 작성할 수 있는 상태가 되었다. 6일차에서 “리뷰의 가치”를 이야기했다면, 7일차의 교훈은 “복귀 시 상태 점검의 가치”다.

1주일 공백 후 코드 대신 문서를 먼저 열었다 — AI와 함께 개발할 때 공백을 넘기는 유일한 방법은 기록이다.