Post-mortem

포스트모템

2022 — 2026 · 3 Cases · 6 Questions

상황 · 목표 · 문제 · 대응 · 결과와 한계 · 다음 원칙의 여섯 항목으로 프로젝트를 회고합니다. 문제는 감상이 아니라 관찰 가능한 현상으로, 대응은 실제 산출물과 프로세스로 기록했습니다.

Case 01
글로벌 모바일 게임
2022.06 — 2022.12 · 라이브 서비스
Case 02
Taimanin Squad
2023.05 — 2025.12 · 시스템 · 전투 메인 기획
Case 03
소규모 신작 · 2인 개발
2026.01 — 2026.05 · 공동 개발 · 구조 인수

Principle

회고를 관통하는 원칙

툴로 막는다. 문서로 이해시킨다. 문제를 드러내 공유한다.

검증할 수 없는 자동화는 신뢰할 수 없고, 사람이 이해하지 못하는 시스템은 반복 가능한 결과를 만들지 못합니다. 그래서 툴로 오류를 막고, 문서로 이해시키고, 문제는 조기에 드러내 공유하는 순서를 세 프로젝트에서 공통으로 적용했습니다.

단일 해법이 모든 문제를 해결하지는 않습니다. 자동화는 반복 오류에 강하지만 예외를 놓칠 수 있고, 문서는 공통 이해를 만들지만 실제 준수와 책임 구조가 없으면 효과가 제한됩니다.

상황

역할 · 맥락

목표

완료 기준

문제

관찰된 현상

대응

산출물 · 절차

결과와 한계

변화 · 잔여 위험

다음 원칙

다음 규약

Case 01

2022.06 — 2022.12
글로벌 모바일 게임 · 라이브 서비스
첫 게임업계

검증 수단 없는 자동화는 오류를 배포 이후로 미룬다

상황역할 · 맥락

글로벌 모바일 게임의 라이브 서비스에 참여해 한국 · 일본 · 유럽 대응을 맡았습니다.

목표완료 기준

라이브 데이터 대응과 다국어 · 웹이벤트 콘텐츠를 실수 없이 안정적으로 처리합니다.

문제관찰된 현상

참조가 많은 데이터 테이블과 깨진 엑셀 함수가 잦은 휴먼 에러를 만들었습니다. 자동화는 있었지만 결과를 검증하는 수단이 없어, 한 곳의 오류가 배포 후에야 발견되어 유저 문의와 서버 파트의 긴급 대응으로 이어졌습니다.

대응산출물 · 절차

함수와 참조가 깨진 지점을 자동으로 찾는 데이터 정합성 검증 도구를 직접 제작했습니다.

결과와 한계변화 · 잔여 위험

같은 유형의 실수는 크게 줄었지만 복잡한 테이블 구조 자체는 남았습니다. 오류를 뒤에서 잡는 것보다 구조 설계 단계에서 단순성과 검증 가능성을 확보해야 한다는 한계를 확인했습니다.

다음 원칙다음 규약

새 프로젝트에서는 검증 도구를 먼저 만들고, 테이블은 간단하고 직관적인 참조 구조로 설계합니다.

원칙 1

구현보다 먼저 검증 경로를 만든다.

원칙 2

복잡한 참조는 데이터 구조부터 줄인다.

원칙 3

자동화의 성공과 결과의 정확성을 분리해 확인한다.

Case 02

2023.05 — 2025.12
Taimanin Squad · 모바일 수집형 RPG · 약 40명 규모
시스템 / 전투 메인 기획

툴만으로는 사람의 실수를 막을 수 없다

상황역할 · 맥락

개발 총괄의 장기 부재와 별도 PM이 없는 환경에서 신입 비중이 높은 팀의 전투 · 시스템 설계와 데이터 적용을 맡았습니다.

목표완료 기준

전투와 시스템 설계를 이어가면서 규약이 부재한 환경의 리소스 · 데이터 무결성을 유지합니다.

문제관찰된 현상

커밋 규약과 작업 파이프라인이 없어 완성된 리소스가 씬에서 재생되지 않았고, 케이스가 제각각이라 사람 눈 검수가 반복됐습니다. 외주 데이터를 직접 확인하는 시간이 제작 시간을 넘어섰고, 검수 요청이 반복되면서 지적과 재작업 요청이 기획 파트에 집중됐으며, 파트 간 책임 경계가 규약이 아닌 개인 관계로 처리됐습니다.

대응산출물 · 절차

데이터 무결성 검사, Unity 자동화, FBX · Magica 유틸리티를 만들었습니다. 파트별 제작 기준과 온보딩 · 외주 검수 기준을 가이드 문서 13종 이상으로 표준화하고, 인력 충원과 정기 검수 프로세스를 요청했습니다.

결과와 한계변화 · 잔여 위험

설계한 전투 시스템과 스킬 메커니즘이 출시 버전에 반영됐습니다. 툴만으로는 사람의 실수를 완전히 막을 수 없었습니다. 검수 부담을 개인이 흡수하는 대신 팀 이슈로 공개하고 정기 검수 프로세스를 요청한 뒤, 오류 대응이 개인 책임에서 프로세스 단위로 옮겨졌습니다. 다만 PM과 프로세스 부재는 개인이 완전히 해결할 수 없는 한계였습니다.

다음 원칙다음 규약

규약과 파이프라인을 먼저 세우고, 툴과 함께 사람이 이해할 가이드 문서를 만듭니다. 문제는 조기에 공유하며 파트 간 책임 경계를 명확히 둡니다.

직접 만든 결과물

데이터 무결성
참조와 누락 자동 검사
Unity 자동화
반복 작업과 설정 검증
FBX 유틸리티
프리팹 교체와 규격 확인
Magica 동기화
설정 복제와 누락 방지
가이드 13종 이상
아트 · 외주 · 툴 · 온보딩 기준
SQUAD MANAGER
데이터 검사와 작업 지원

Case 03

2026.01 — 2026.05
소규모 신작 · 2인 개발(가제)
공동 개발

역할과 결정 권한은 착수 시점에 합의해야 한다

상황역할 · 맥락

가까운 동료와 2인 체제로 소규모 신작 개발을 시작했습니다.

목표완료 기준

작은 팀의 짧은 의사결정 경로를 활용해 빠르게 합을 맞추고 신작을 완성합니다.

문제관찰된 현상

역할과 결정 권한을 착수 시점에 합의하지 않은 상태로 시작했습니다. 그 결과 같은 사안이 여러 번 재논의됐고, 의사결정에 드는 시간이 제작 시간을 압박했습니다.

대응산출물 · 절차

합의 없이 계속하는 대신 각자의 목표에 맞게 프로젝트를 분리하기로 결정했습니다. 진행 중이던 기획 · 데이터 구조를 인수해 정리했고, 공동 개발자는 별도 프로젝트로 이어갔습니다.

결과와 한계변화 · 잔여 위험

인수한 프로젝트는 이후 1인 개발작 《Fire Vow: Dark Fantasy》로 발전했습니다. 다만 관계와 업무의 경계를 초기에 명확하게 세우지 못한 점은 한계로 남았습니다.

다음 원칙다음 규약

친밀도와 업무 효율을 구분하고, 소통의 목적을 정확성과 책임 연결에 둡니다. 역할과 결정 권한은 착수 시점에 합의합니다.

합의된 분리

각자의 목표에 맞게 프로젝트를 분리했습니다.

구조 인수

진행 중이던 기획 · 데이터 구조를 인수해 정리했습니다.

1인 개발로 전환

인수한 구조를 《Fire Vow: Dark Fantasy》로 발전시켰습니다.

Contact