0에서 1로 가는 마지막 단계: 다음 작품에 방향을 제시하는 회고를 하는 방법

진정으로 유용한 회고는 축하 모임이나 책임 추궁의 자리가 아니라 계획, 실제 결과, 증거, 다음번의 규칙을 연결하는 작업이다. 최종적으로 세 가지 자산을 만들어야 한다. 계속 유지할 방식, 반드시 바꿔야 할 시스템, 다음 프로젝트 착수 전에 검증할 가설이다. 담당자와 실행 계기가 없는 ‘교훈’은 금세 잊힌다.

두 차례로 나누어 진행할 수 있다. 출시 며칠 뒤에는 운영 회고를 통해 진행을 막는 문제와 협업 부담을 다루고, 몇 주 뒤에는 판매량, 완료 현황, 피드백이 비교적 안정되었을 때 프로젝트 회고를 진행한다. 매번 타임라인, 예산, 버전, 결함, 테스트, 데이터, 사용자 증거를 미리 모아 회의에서 기억에 의존해 논쟁하지 않도록 한다.

각 직무의 구성원이 먼저 독립적으로 작성하게 한다. 원래 목표, 실제 결과, 가장 큰 예상 밖의 일, 유지해야 할 것 하나와 바꿔야 할 것 하나다. 민감한 문제를 익명으로 수집하면 권력 관계의 영향을 줄일 수 있지만, 결론에서는 여전히 프로세스 담당자의 책임을 공개적으로 명시해야 한다. 익명 속으로 사라지게 해서는 안 된다.

프로젝트 승인 당시의 플레이어에게 한 약속, 범위, 하지 않을 일 목록, 예산, 성공 지표를 꺼내 항목별로 비교한다. 무엇을 지켰고, 무엇을 의도적으로 수정했으며, 무엇이 의사결정 없이 슬그머니 달라졌는가? 프로젝트 결과가 좋아도 그 과정은 재현할 수 없을 수 있다. 시장 성과가 평범해도 중요한 가설을 검증했을 수 있다.

산출물과 성과를 구분한다. 200분을 촬영한 것은 산출물이고, 플레이어가 이해하고 다시 플레이하고 싶어 하는 것은 성과다. 엔딩 12개를 만든 것은 산출물이고, 엔딩이 선택의 의미를 회수하는 것은 성과다. 회고에서는 성과를 중심으로 산출물을 만들 가치가 있었는지 설명한다.

소재 선정, 핵심 루프, 대본, 프로토타입, 사전 제작, 촬영, 후반 작업, 통합, 테스트, 출시, 운영까지 단계별로 점검한다. 모든 문제에 대해 최소한 다음을 묻는다. 처음 확인할 수 있는 징후는 언제 나타났는가, 당시 왜 처리하지 않았는가, 어떤 프로세스나 유인이 문제를 지속시켰는가, 최종적으로 어떤 영향을 미쳤는가.

시스템 문제를 ‘누군가가 꼼꼼하지 못했다’로 환원하지 않는다. 안정적인 ID, 자동 검증, 명확한 기준 목록이 없어서 파일을 잘못 연결했다면 개인에게 주의를 주는 것만으로는 다음 프로젝트에서도 같은 일이 반복된다. 반대로 ‘프로세스 문제’라는 말로 실제 의사결정을 흐리지도 말자. 누가 언제 이를 바꿀 권한을 가졌는지 기록한다.

창작에서는 선택지 이해, 캐릭터의 연속성, 전개 속도, 엔딩, 반복 플레이를 살핀다. 제작에서는 중복을 제외한 고유 영상 분량, 촬영 효율, 추가 촬영, 재작업, 자산 오류를 살핀다. 기술에서는 전환, 저장, 성능, 도구를 살핀다. 사업에서는 스토어 전환율, 위시리스트, 환불, 평가, 지원 비용을 살핀다. 네 영역을 같은 타임라인에 놓아야 인과관계를 볼 수 있다.

예를 들어 플레이어가 분기가 의미 없다고 불평한다면, 대본에서 분기가 너무 일찍 합쳐졌기 때문일 수 있다. 예산 때문에 반응을 보여 주는 장면을 삭제했거나, 현장에서 분기 출구 장면을 빠뜨렸거나, 프로그램의 로딩 오류로 항상 같은 영상에 진입하기 때문일 수도 있다. 회고에서 문제를 마지막으로 접한 직무에만 책임을 떠넘겨서는 안 된다.

유지할 항목에는 적용 조건을 명시해야 한다. 예를 들면 ‘기술적 불확실성이 클 때는 3분짜리 버티컬 슬라이스를 유지한다’이다. 중단할 항목에는 대안을 제시해야 한다. 예를 들면 ‘단체 채팅에서 자산을 확인하는 일을 중단하고, 체크섬이 포함된 자산 목록을 사용한다’이다. 시도할 항목은 검증 가능한 실험으로 작성한다. 예를 들면 ‘다음 프로젝트에서는 먼저 노드 다섯 개로 세로 화면 선택지 배치를 테스트한다’이다.

각 항목에 담당자, 실행 시점, 완료 증거를 지정한다. ‘소통 강화’를 ‘대본을 확정할 때마다 프로듀서가 영향표를 배포하고, 네 직무가 24시간 안에 확인한다’로 바꾼다. 구체적일수록 다음번의 행동을 바꿀 가능성이 높다.

노드 카드, 변수표, 분기 예산, 상태 카드, 촬영 기록표, 인코딩 프리셋, 테스트 매트릭스, 출시 체크리스트를 갱신한다. 템플릿에는 버전, 출처 프로젝트, 사용 조건을 명시한다. 다음 프로젝트를 시작할 때는 여전히 적합한지부터 의문을 제기한다. 모범 사례는 현재 증거에 따른 기본값이지 영원한 법칙이 아니다.

최종 빌드, 원본 파일, 라이선스, 저장 데이터 샘플, 데이터 사전, 대시보드 정의, 주요 의사결정을 보관한다. 원래 담당자만 특정 클라우드 저장소 폴더를 아는 상태로 두지 말고, 새 구성원도 찾아서 이해할 수 있게 한다.

답을 얻지 못한 질문을 나열한다. 세로 화면 사용자는 더 짧은 선택지를 선호하는가? 듀얼 플레이어는 저사양 기기에서 안정적인가? 특정 유형의 엔딩은 반복 플레이를 촉진하는가? 영향과 불확실성에 따라 우선순위를 정하고, 최상위 항목은 다음 프로젝트의 프로토타입에 넣는다. 곧바로 대규모 제작에 넣지는 않는다.

반증된 가설도 기록해 팀이 이름만 바꿔 다시 투자하지 않도록 한다. 반증은 실패가 아니다. 다음번의 범위를 더 명확하게 만든다.

회의가 끝났다고 완료된 것은 아니다. 2주 안에 회고 문서를 공개하고, 템플릿과 프로세스를 갱신하며, 담당자가 추적할 수 있는 실행 항목을 만든다. 다음 프로젝트 승인 회의에서는 각 항목을 채택했는지 하나씩 확인한다. 어떤 결정을 더 이상 실행하지 않는다면 조용히 잊는 대신 새로운 이유를 기록한다.

마지막으로 한 페이지짜리 프로젝트 지도를 남긴다. 한 문장으로 된 플레이어에게 한 약속에서 완성품에 이르는 과정, 가장 중요한 결정 다섯 가지, 가장 큰 편차 세 가지, 다음번에 가장 먼저 검증할 사항을 담는다. 수십 페이지의 일지보다 새 팀이 과거를 이해하는 데 더 도움이 된다.

다음 단계: 두 시간짜리 프로젝트 회고 회의를 잡고, 모두에게 회의 전에 증거를 제출하도록 요구한다. 회의에서는 가장 중요한 유지, 중단, 시도 항목 다섯 가지만 결정하고, 이를 다음 프로젝트의 템플릿과 착수 승인 조건에 바로 반영한다.