새 서비스 개발 프로젝트 진행 순서

새로운 서비스를 처음부터 만들 때 무엇을 어떤 순서로 준비해야 하는지 기승전결 네 단계로 정리한 체크리스트다. 사이드 프로젝트를 시작할 때 빠뜨린 단계가 없는지 점검하는 용도로 쓰기 좋다.

기: 기획

셋 다 "작게 먼저 만들어 본다"지만, 답하려는 질문이 다르다.

큰 프로젝트의 작은 결정 수백 개는 이메일과 메신저에 흩어지므로, 끝난 뒤 몰아 쓰지 말고 진행하는 동안 결정 로그(decision log)를 쓴다. 첫 방향이 정해진 뒤 시작하고, 내부 초안이니 언제든 고친다.

무엇을	왜
매일의 작은 결정과 그 이유	결정을 설명하기 쉬워지고, 글로 쓰면 논리의 빈틈이 보인다
지금은 상관없지만 개발 때 문제 될 피드백	나중에 이슈가 될 것을 미리 잡아 둔다
길 찾기(내비게이션)·기능 규칙	막힐 때 다시 볼 길잡이가 된다
쓰는 색·글꼴 계층	스타일 가이드와 디자인 시스템의 뼈대가 되고 프런트엔드 개발을 앞당긴다

기존 서비스를 갈아엎는 리뉴얼은 새 프로젝트보다 변수가 많다.

원칙	이유
일정은 보수적으로, 범위는 실행 가능한 만큼 먼저	일정은 회의와 개발이 진행될수록 늘어난다
디자인·기획 범위를 개발 일정과 함께 확정	개발 중 잦은 디자인 변경이 가장 큰 지연 요인이다. 바꾸려면 비용을 인정하고 합의한다
기획 문서는 최소한 팀이 공유할 수준으로	문서가 부실하면 이후 작업마다 해석이 갈린다
레거시 데이터 이전은 전담자와 넉넉한 시간	이전 스크립트와 정합성 검증에서 시행착오가 가장 많다
인프라는 아는 사람이 맡는다	모르는 채로 떠안으면 시간과 에너지를 크게 잃는다
베타 테스트 결과가 나오기 전에 오픈일을 확정하지 않는다	베타에서 나온 문제를 고칠 시간이 일정에 없으면 품질을 포기하게 된다
보안 점검은 베타 단계에서	오픈 뒤 외부 제보로 발견되는 일을 줄인다
서비스 중단 작업은 트래픽이 적은 시간에, 사후 수정 시간까지 잡는다	전환 직후 버그가 몰린다. 팀 전체가 버그를 찾고 바로 고치는 안정화 기간을 둔다
기존 서비스 운영 인력을 보호한다	긴 리뉴얼 기간에도 매출은 기존 서비스에서 나온다