게임 개발 포스트모템 회고록: 반드시 답해야 할 12가지 질문

핵심 요약

좋은 게임 개발 포스트모템은 성공과 실패를 나열하는 글이 아니라 다음 프로젝트에서 반복할 결정과 중단할 결정을 증거와 함께 남기는 문서다. 목표·일정·품질·기술·사용자 반응을 같은 기준으로 질문하고 계획 대비 실제 결과와 원인을 분리해 기록하면 회고가 실행 항목으로 바뀐다.

게임 개발 포스트모템은 왜 질문 중심으로 작성해야 할까?

포스트모템은 기억에 의존하면 “바빴다”나 “커뮤니케이션이 부족했다”처럼 재사용하기 어려운 결론으로 끝나기 쉽다. 질문을 고정하면 프로젝트마다 같은 항목을 비교할 수 있고 원인과 대응책을 분리할 수 있다.

특히 Unity 6, Unreal Engine 5, Godot 4처럼 엔진이 달라도 아래 항목은 공통으로 확인할 수 있다.

영역	확인할 증거	회고에서 답할 질문
목표	출시 목표, 플랫폼, 핵심 재미 가설	무엇을 만들기로 했고 무엇을 실제로 출시했는가?
일정	마일스톤, 이슈 트래커, 빌드 기록	계획과 실제 일정은 어디에서 갈라졌는가?
품질	크래시율, 프레임 타임, 버그 수	품질 기준을 언제부터 측정했는가?
개발 비용	투입 인원, 작업 시간, 외주 비용	가장 비싼 결정은 무엇이었는가?
사용자 반응	스토어 리뷰, 플레이테스트, 이탈 구간	기대와 실제 반응은 어떻게 달랐는가?

1. 처음의 목표와 출시한 게임은 어떻게 달라졌는가?

가장 먼저 초기 기획서나 첫 번째 마일스톤을 기준점으로 둔다. “기능이 줄었다”고만 쓰지 말고 무엇을 왜 줄였는지 적는다.

프로젝트의 핵심 재미 가설은 무엇이었는가?
목표 플랫폼과 목표 플레이 시간은 무엇이었는가?
출시 버전에서 삭제·축소·대체된 기능은 무엇인가?
그 변경이 재미, 일정, 성능, 운영 중 어느 항목을 개선했는가?

예를 들어 “절차적 퀘스트를 삭제했다”보다 “퀘스트 생성 규칙 검증 비용이 높아 수작업 퀘스트 20개로 범위를 축소했고 QA 기간을 2주 확보했다”가 다음 프로젝트의 판단에 훨씬 유용하다.

2. 일정 예측은 왜 빗나갔는가?

일정은 완료한 작업 수가 아니라 검증 가능한 결과물을 낸 시점으로 비교해야 한다. 기능 구현 완료와 플레이 가능한 빌드 완료는 다르다.

일정 오차율은 간단히 다음처럼 기록할 수 있다.

\text{일정 오차율} = \frac{\text{실제 소요 기간} - \text{계획 기간}}{\text{계획 기간}} \times 100

일정 회고에 필요한 질문

가장 큰 일정 지연을 만든 작업은 무엇이었는가?
지연 원인은 추정 오류, 의존성, 재작업, 버그 수정 중 어디에 있었는가?
위험이 발견된 시점과 일정에 반영한 시점 사이에 며칠의 차이가 있었는가?
다음 프로젝트에서 프로토타입으로 먼저 검증할 항목은 무엇인가?

“UI 작업이 오래 걸렸다”는 결과다. “해상도별 레이아웃 규칙이 정해지지 않아 화면마다 프리팹을 복제했고 이후 수정이 전 화면에 전파됐다”처럼 구조적 원인을 기록해야 한다.

3. 어떤 기능이 게임의 핵심 재미에 가장 크게 기여했는가?

기능의 가치는 구현 난이도가 아니라 플레이 경험으로 판단한다. 플레이테스트 영상, 세션 길이, 튜토리얼 이탈률, 설문 응답을 함께 본다.

플레이어가 자발적으로 반복한 행동은 무엇이었는가?
설명하지 않아도 이해한 규칙은 무엇이었는가?
제작 비용에 비해 반응이 약했던 기능은 무엇이었는가?
핵심 루프에서 불필요하게 복잡했던 단계는 어디였는가?

플레이테스트 관찰 기록과 이탈 구간을 정리한 게임 개발 회고 예시

기능별로 아래처럼 한 줄 결론을 남기면 우선순위 판단이 쉬워진다.

기능	기대 효과	실제 관찰	다음 결정
첫 10분 튜토리얼	규칙 학습	특정 조작에서 반복 질문 발생	입력 안내를 상호작용 직전에 배치
장비 강화	장기 목표 제공	재료 획득 경로를 이해하지 못함	획득 경로를 강화 화면에 표시
수집 도감	탐험 동기	완성률 확인 빈도가 낮음	출시 후 업데이트 후보로 보류

4. 성능과 안정성 문제는 언제 발견됐고 왜 늦었는가?

성능 회고는 “최적화했다”가 아니라 측정 조건과 기준을 남겨야 한다. 예를 들어 목표 기기가 Android, Nintendo Switch, Steam Deck인지에 따라 허용 가능한 프레임 타임과 메모리 예산이 달라진다.

테스트한 기기, 해상도, 그래픽 품질 설정은 무엇인가?
평균 FPS뿐 아니라 1% low FPS 또는 최악 프레임 타임을 측정했는가?
Unity Profiler, Unreal Insights, Godot Profiler 중 무엇으로 병목을 확인했는가?
로딩, 전투, UI 전환 중 어느 상황에서 GC Alloc, 드로우 콜, 셰이더 컴파일 문제가 발생했는가?

60 FPS 목표라면 프레임 예산은 다음과 같다.

\text{프레임 예산} = \frac{1000\text{ ms}}{60} \approx 16.67\text{ ms}

이 값보다 CPU 또는 GPU 프레임 시간이 지속적으로 높다면 “최적화가 필요했다”가 아니라 어떤 장면과 어떤 시스템이 예산을 넘겼는지 써야 한다.

5. 기술 부채는 어떤 방식으로 개발 속도를 떨어뜨렸는가?

기술 부채를 일반적인 반성문으로 쓰지 않는다. 변경 비용이 커진 구조를 구체적으로 적는다.

한 기능을 수정할 때 함께 수정해야 했던 파일이나 씬은 몇 개였는가?
데이터가 코드, ScriptableObject, DataTable, JSON 중 어디에 분산돼 있었는가?
테스트 빌드와 배포 빌드를 재현하는 절차는 문서화돼 있었는가?
저장 데이터, 입력 처리, 씬 전환처럼 모든 기능이 의존하는 공통 시스템은 안정적이었는가?

다만 모든 불편을 리팩터링 대상으로 분류할 필요는 없다. 출시 후 한 번도 바뀌지 않은 코드보다 반복 수정되는 경계와 데이터 흐름을 우선한다.

6. 팀의 의사결정과 소통은 어디에서 막혔는가?

소통 문제는 개인 평가가 아니라 정보 흐름의 문제로 다룬다. 결정권자, 결정 시점, 기록 위치가 불명확하면 같은 논의가 반복된다.

기능 범위 변경을 최종 승인한 사람은 누구였는가?
결정이 문서, 이슈, 메신저 중 어디에 남았는가?
기획 변경이 아트·클라이언트·QA에 전달되기까지 얼마나 걸렸는가?
블로커를 드러내는 정기 점검이 있었는가?

회의 횟수보다 중요한 것은 결론의 추적 가능성이다. 변경 요청마다 담당자, 결정일, 영향받는 마일스톤, 되돌릴 조건을 남기는 방식이 가장 단순하다.

게임 개발 포스트모템을 실행 항목으로 바꾸는 3단계

증거를 먼저 모은다. 마일스톤 일정, 빌드 로그, 이슈 완료일, 플레이테스트 메모, 스토어 리뷰를 한곳에 모은다.
질문별로 사실과 해석을 분리한다. “출시가 3주 지연됐다”는 사실이고 “콘텐츠 범위가 컸다”는 해석이다. 둘을 한 문장에 섞지 않는다.
다음 행동을 한 문장으로 확정한다. 예를 들어 “다음 프로젝트에서는 전투 프로토타입을 2주 안에 목표 기기에서 측정한다”처럼 담당 시점과 검증 기준을 포함한다.

실행 항목은 너무 많이 만들지 않는 편이 낫다. 가장 큰 반복 원인 3개만 골라 다음 마일스톤의 체크리스트에 넣는다.

자주 묻는 질문 (FAQ)

포스트모템은 프로젝트가 실패했을 때만 작성해야 하나요?

아니다. 성공한 프로젝트일수록 무엇이 효과적이었는지 기록해야 다음 프로젝트에서 재현할 수 있다.

포스트모템은 언제 작성하는 것이 좋은가요?

출시 직후의 내부 회고와 사용자 데이터가 쌓인 뒤의 후속 회고를 나누는 것이 좋다. 전자는 제작 과정에 후자는 실제 플레이 경험에 집중한다.

팀 규모가 1명이어도 회고가 필요한가요?

필요하다. 1인 개발에서는 시간 사용과 범위 결정이 가장 큰 비용이므로 삭제한 기능과 재작업 원인을 남기는 것만으로도 다음 프로젝트의 추정 정확도가 높아진다.

마무리

포스트모템의 목적은 잘못을 찾는 것이 아니라 다음 선택의 비용을 줄이는 데 있다. 이번 프로젝트에서 가장 큰 지연 원인 하나, 가장 효과가 컸던 기능 하나, 다음에 먼저 검증할 위험 하나를 명확히 적는 것부터 시작하면 충분하다.