모바일앱개발, 왜 항상 일정은 밀리고 기능은 누락될까?

솔직히 고백하겠습니다. 저도 주니어 PM 시절에는 개발 일정을 산정할 때 개발자의 "이거 3일이면 돼요"라는 말을 곧이곧대로 믿었습니다. 3일 뒤에 기능이 완성될 것이라 믿고, 4일 차에 QA를 잡고, 5일 차에 배포하는 완벽한 엑셀 시트를 만들었죠. 하지만 결과는 어땠을까요. 배포 당일 새벽 3시까지 사무실에 남아 터져 나오는 버그를 잡느라 개발팀과 함께 피를 말리는 시간을 보내야 했습니다. 그때의 무력감은 아직도 생생합니다.

왜 이런 일이 반복될까요. 우리가 흔히 모바일앱개발이라고 부르는 과정이 단순히 '코드를 작성하는 행위'라고 착각하기 때문입니다. 앱을 만든다는 건 건물을 짓는 것과 비슷합니다. 설계도 없이 벽돌부터 쌓기 시작하면, 나중에는 배관을 넣을 자리가 없어서 멀쩡한 벽을 다시 부숴야 하는 사태가 벌어집니다. 오늘은 제가 수많은 프로젝트를 지연시키며 뼈저리게 배운, 앱 개발 프로세스의 단계별 핵심 과업과 현실적인 일정 관리 노하우를 공유하려 합니다.

우선, 개발 프로세스를 단순히 '기획-디자인-개발'로 퉁치지 마세요. 각 단계는 훨씬 더 치밀해야 합니다. 제가 실무에서 적용하는 프레임워크는 크게 네 단계로 나뉩니다.

첫 번째는 '정의 및 설계(Discovery & Design)' 단계입니다.
가장 많은 실수가 여기서 발생합니다. 기획서(SB)만 덜렁 던져주고 개발을 시작하라고 하면 필패합니다. 여기서 PM이 챙겨야 할 핵심은 '정책 정의'와 '데이터 구조'입니다. 화면이 어떻게 보일지보다, 회원가입 시 수집한 데이터를 어떤 스키마로 저장할지, 예외 처리는 어떻게 할지(예: 네트워크가 끊겼을 때)를 먼저 정의해야 합니다. 개발자가 코드를 치기 전에 디자이너, 백엔드 엔지니어와 함께 모여 PRD(제품 요구사항 정의서)를 리뷰하는 시간을 반드시 가지세요. 이 2시간의 회의가 나중에 2주의 재작업을 막아줍니다.

두 번째는 '개발 착수 및 구현(Development)' 단계입니다.
여기서 중요한 건 프론트엔드(앱)와 백엔드(서버)의 속도 차이를 조율하는 것입니다. 보통 서버 API가 나오지 않았는데 앱 개발자가 UI 작업을 먼저 시작하곤 합니다. 그러다 API 명세가 바뀌면 앱 코드를 다 뜯어고쳐야 하죠. 이를 방지하기 위해 저는 'API 명세서 선행 확정'을 철칙으로 삼습니다. Swagger나 Notion으로 API 입출력 값을 먼저 합의하고, 모킹(Mocking) 데이터를 이용해 앱 개발을 병렬로 진행해야 리소스 낭비를 막을 수 있습니다.

세 번째는 '테스트 및 안정화(QA & Stabilization)' 입니다.
많은 스타트업이 일정에 쫓겨 이 단계를 건너뛰거나, 개발자가 직접 테스트하고 끝냅니다. 하지만 개발자는 본인이 짠 로직대로만 테스트하는 'Happy Path' 편향을 가지고 있습니다. 제 3자, 혹은 전문 QA가 엣지 케이스(Edge Case)를 집요하게 파고들어야 합니다. 단순히 기능이 작동하는지를 넘어, 구형 기기에서의 퍼포먼스나 배터리 소모량 같은 비기능적 요구사항까지 체크리스트에 포함해야 합니다.

마지막은 '배포 및 스토어 심사(Release)' 단계입니다.
모바일앱개발의 복병은 애플과 구글의 심사입니다. 웹 배포처럼 버튼 하나 누른다고 끝나는 게 아닙니다. 심사 리직(Reject)은 언제든 발생할 수 있습니다. 개인정보 처리방침 문구 하나 때문에, 혹은 로그인 테스트 계정을 제공하지 않아서 심사가 거절되기도 합니다. 따라서 배포 목표일로부터 최소 1주일, 안전하게는 2주 전에는 첫 심사를 넣어야 합니다.

이제 가장 중요한 일정 관리 이야기를 해보죠. 개발자가 "3일 걸립니다"라고 하면, 저는 마음속으로 'X 1.5'를 합니다. 개발자를 불신해서가 아닙니다. 그 3일은 '아무런 방해 없이, 예상치 못한 기술적 난관이 없으며, 컨디션이 최상일 때' 가능한 시간이기 때문입니다. 회의 시간, 코드 리뷰, 갑작스러운 버그 수정 시간을 고려하면 1.5배의 버퍼(Buffer)는 선택이 아닌 필수입니다.

또한, 일정을 관리할 때는 진척도를 '기능 단위'가 아닌 '상태 단위'로 체크하세요. "로그인 기능 80% 됐어요"라는 말은 믿지 마세요. 개발에서의 90% 완료는 사실 50% 정도 온 것입니다. 대신 "로그인 API 연동 완료, 에러 처리 완료, QA 대기 중"처럼 명확한 상태로 커뮤니케이션해야 합니다. 그래야 병목이 어디서 발생하는지, 리소스를 어디에 더 투입해야 할지 데이터 기반으로 판단할 수 있습니다.

앱을 만든다는 것은 불확실성과의 싸움입니다. 완벽한 계획은 없지만, 구조화된 프로세스는 존재합니다. 오늘 공유한 단계별 과업들이 여러분의 프로젝트를 밤샘의 늪에서 조금이나마 구해주길 바랍니다. 프로세스는 우리를 옭아매는 족쇄가 아니라, 치열한 개발 현장에서 우리를 지켜주는 안전장치라는 점을 기억해 주셨으면 합니다.