진짜 앱 개발 일정: 아이디어에서 출시까지

열 개 업체에 앱 개발에 얼마나 걸리는지 물으면 자신감 넘치는 답을 열 가지 받게 되지만, 그중 어느 것도 사실이 아닙니다. 솔직한 답은 첫날에 정확한 기간을 말해 줄 수 있는 사람은 없다는 것입니다. 하지만 소프트웨어를 실제로 출시해 본 사람이라면 그 '윤곽'은 말해 줄 수 있습니다. 어떤 단계가 있고, 어떤 단계가 조용히 일정을 갉아먹으며, 어디에서 여러분 자신의 결정이 일을 빠르게 하거나 완전히 멈추게 하는지 말입니다. 이것이 그 윤곽을 있는 그대로 적어 둔 것입니다.

저는 스케치에서 App Store까지 깔끔하고 직선적으로 진행되리라 기대하며 앱 프로젝트에 들어서는 중소기업 대표님들을 많이 보았습니다. 그러나 정작 마주하는 것은 여러 정체기와 갑작스러운 도약의 연속처럼 느껴지는 것입니다. 아무 일도 일어나지 않는 듯한 몇 주가 이어지다가, 어느 날 갑자기 모든 것이 맞아떨어집니다. 그 어느 것도 무언가 잘못되었다는 신호가 아닙니다. 소프트웨어는 원래 그렇게 만들어집니다. 그리고 각 단계에 이름을 붙일 수 있게 되면, 이 전체 과정은 돈을 넣고 최선을 바라기만 하는 블랙박스가 아니게 됩니다.

그러니 현실적인 기대치를 세워 봅시다. 사업용 앱의 집중된 첫 버전, 즉 비대해진 플랫폼이 아니라 한 가지 일을 잘 해내는 첫 버전이라면, 본격적인 시작부터 실제 출시까지 보통 3개월에서 5개월 범위를 보게 됩니다. 그 범위 안 어디에 안착할지는 기술보다, 얼마나 명확한지, 얼마나 빨리 결정하는지, 출시 전에 얼마나 많이 욱여넣으려 하는지에 달려 있습니다. 차근차근 살펴보겠습니다.

받으신 견적이 아마 틀린 이유

6주라는 숫자가 정확히 거짓말인 것은 아닙니다. 누구나 머릿속에 그릴 수 있는 부분을 만드는 데 걸리는 시간입니다. 화면. 버튼. 시연할 수 있는 것. 그 숫자가 조용히 무시하는 것은 눈에 보이는 앱을 둘러싼 모든 것입니다. 결정, 데이터, 이미 쓰고 계신 도구와의 연동, 테스트, 앱스토어 심사, 그리고 피할 수 없는 “사실, 이것도 되나요?” 한 바퀴입니다.

유용한 사고방식이 있습니다. 코딩이 병목이 되는 일은 드뭅니다. 병목은 명확성입니다. 개발자가 결정을 기다리는 한 시간, 즉 어느 결제 사업자인지, 예약이 취소되면 어떻게 되는지, 누가 무엇을 볼 수 있는지를 기다리는 한 시간은 그대로 일정이 밀리는 한 시간입니다. 빨리 끝나는 프로젝트는 최고의 엔지니어가 있는 곳이 아닙니다. 대표가 2주가 아니라 하루 만에 질문에 답하는 곳입니다.

그러니 아래 단계들을 읽으실 때, 공이 여러분 코트에 있는 순간에 주목하십시오. 그곳이 프로젝트가 추진력을 유지하느냐, 아니면 이메일 한 통에 답이 없어 조용히 3주를 멈추느냐의 갈림길입니다. 일정은 공동의 책임이며, 사람들이 과소평가하는 것은 바로 고객 쪽 절반입니다.

1단계: 디스커버리와 범위 설정 (1~3주)

누군가 화면 하나라도 설계하기 전에, 진척처럼 보이지는 않지만 모든 것을 좌우하는 단계가 있습니다. 무엇을 실제로 만들지, 그리고 더 중요하게는 무엇을 만들지 않을지를 가려내는 일입니다. 여기서 막연한 아이디어(“고객을 위한 앱”)가 버전 1을 위한 구체적이고 완료 가능한 기능 목록이 됩니다.

잘 해내면 디스커버리는 대부분 대화와 어려운 질문입니다. 누가, 어떤 기기에서 사용하는가? 탁월하게 해내야 할 단 한 가지는 무엇인가? 버전 2까지 미뤄도 되는 것은 무엇인가? 좋은 파트너는 여기서 반대 의견을 내며, 그러길 바라셔야 합니다. 지금 덜어 내는 기능 하나하나가 되찾는 몇 주이기 때문입니다. 결과물은 보통 짧은 글로 된 범위와 거친 와이어프레임으로, 손에 들고 그래, 이거다라고 말할 수 있는 것입니다.

2단계: 디자인과 프로토타입 (2~4주)

이제 앱은 진짜 코드 한 줄이 여러분을 무언가에 묶기 전에, 보고 클릭할 수 있는 것이 됩니다. 디자이너는 와이어프레임을 제대로 된 화면으로 만듭니다. 색, 흐름, 사용할 때의 실제 감각을, 보통은 본인 휴대폰에서 눌러 가며 진행하는 인터랙티브 프로토타입으로 구현합니다.

이 단계가 금쪽같은 이유는 하나입니다. 디자인을 바꾸는 것은 싸고, 만들어진 소프트웨어를 바꾸는 것은 비쌉니다. 프로토타입에서 버튼을 옮기는 데는 5분이 걸립니다. 기능이 코딩되고, 테스트되고, 데이터에 연결된 뒤 옮기면 하루가 걸릴 수 있습니다. 그러니 지금이 까다롭게 굴고, 실제 고객이나 직원 몇 분께 보여 드리며, “아, 이건 아무도 이해 못 하겠다”는 문제를 아직 무통으로 고칠 수 있을 때 잡아내는 순간입니다.

이 단계가 길어지는 가장 흔한 원인은 디자이너가 아니라 여러분 쪽의 우유부단함입니다. 끝없이 이어지는 자잘한 수정, 또는 결코 합의하지 못하는 거부권자 세 명. 누가 승인하는지 일찍 정하고, 피드백을 조금씩이 아니라 묶음으로 주시면 이 단계는 탄탄하게 유지됩니다.

3단계: 구축 (6~12주)

이것이 “앱을 만든다”고 생각할 때 누구나 떠올리는 부분이며, 단일 구간으로는 가장 긴 시기입니다. 다만 앞의 두 단계가 제대로 됐다면 가장 예측 불가능한 구간이 되는 일은 드뭅니다. 개발자는 앱을 덩어리로 만들며, 보통 짧은 주기로 진행합니다. 석 달간 사라졌다가 완성품과 함께 나타나는 대신, 한두 주마다 작동하는 부분을 보여 드립니다.

그 리듬이 중요합니다. 여러분께서 진행 보고서가 아니라 진짜로 돌아가는 소프트웨어에 일찍부터 반응하시길 바랍니다. 4주 차에 예약 흐름을 실제로 써 보시면, 그 어떤 명세서도 담아내지 못했을 것들을 알아차리게 됩니다. 그리고 그것을 4주 차에 고치는 편이 10주 차보다 훨씬 쌉니다. 좋은 구축 과정은 끝에서만이 아니라 앱을 여러분께 지속적으로 보이게 합니다.

구축을 조용히 늘리는 것

무엇보다 구축을 부풀리는 것이 둘 있습니다. 첫째는 연동입니다. 앱이 대화해야 하는 외부 시스템(결제 사업자, 기존 예약 도구, 회계 소프트웨어, 배송 서비스)은 저마다 작업을 더하고, 저마다 나름의 돌발 상황을 던집니다. 둘째는 스코프 크리프입니다. 하나하나는 사소해 보이는 작은 추가가 꾸준히 떨어지다가, 합쳐지면 출시를 한 달 미룹니다. 둘 다 관리할 수 있지만, 다가오는 것을 내다볼 때만 그렇습니다.

• 외부 연동은 저마다 며칠, 때로는 몇 주를 더합니다. 공짜라고 가정하지 말고 명시적으로 예산에 넣으십시오.
• “작은 기능 딱 하나만 더”는 출시일을 놓치는 단연 가장 흔한 원인입니다.
• 실제 데이터는 테스트 데이터보다 지저분합니다. 스프레드시트가 조용히 눈감아 준 예외 상황을 다룰 시간을 잡아 두십시오.
• 사용자 계정, 결제, 알림은 겉보기보다 깊어서 늘 보이는 것보다 더 듭니다.
• 여러분께서 팀에 넘겨야 할 승인과 콘텐츠(로고, 문구, 법률 문구)는 버그만큼이나 확실히 구축을 멈출 수 있습니다.

4단계: 테스트와 수정 (2~4주)

존재를 잊기 일쑤고, 막상 나타나면 원망받는 단계가 이것입니다. 앱이 만들어지면, 여러 휴대폰에서, 나쁜 인터넷에서, 그것을 만들지 않은 사람들이 아무도 예상 못 한 짓을 하며 철저히 시험해 봐야 합니다. 테스트는 형식이 아닙니다. 고객이 신뢰하는 앱과 첫 충돌 후 삭제하는 앱의 차이입니다.

여기서 버그와 거친 구석의 목록이 떠오르리라 예상하십시오. 그것은 구축이 잘못됐다는 신호가 아니라 이 단계의 바로 그 목적입니다. 어떤 것은 빠른 수정이고, 어떤 것은 다시 살펴봐야 할 결정을 드러냅니다. 이것을 잘 다루는 팀은 이를 정상적이고 계획된 작업의 일부로 대합니다. 비상사태도 아니고, 출시가 다가온다고 건너뛸 것도 아닙니다. 테스트를 건너뛴다고 시간이 절약되지 않습니다. 버그를 여러분의 테스트 휴대폰에서 고객의 휴대폰으로 옮길 뿐이며, 그곳에서는 고치는 데 열 배가 듭니다.

5단계: 출시와 앱스토어 대기 (1~2주, 심사 별도)

출시는 단일한 순간이라기보다 신중한 단계적 배포입니다. 웹 앱이라면 시점을 전적으로 여러분이 통제하며, 준비되면 스위치를 올립니다. Apple App Store나 Google Play로 간다면 일정의 일부를 그들에게 넘기게 됩니다. 심사 과정은 하루에서 한 주가 넘게 걸릴 수 있고, 가끔은 고칠 거리를 달아 되돌려 보냅니다. 이것은 고객에게 약속한 출시일이 기습당하지 않도록 미리 알아 둘 가치가 있습니다.

현명한 출시 방식은 전체 고객층을 향한 거창한 공개가 아닙니다. 먼저 작은 그룹에 조용히 내놓는 것입니다. 호의적인 고객이나 본인 직원 몇 분께 내어, 모두가 보기 전에 현실의 문제를 잡아냅니다. 그런 다음 문을 더 넓힙니다. 지루할 만큼 아무 일 없게 느껴지는 출시가 잘된 출시입니다.

1. 1
   작은 그룹에 소프트 론칭

   먼저 호의적인 사용자나 직원 몇 분께 공개하십시오. 실제 사용은 위험을 최대한 낮춘 상태에서 테스트가 놓친 것을 찾아냅니다.
2. 2
   앱스토어로 간다면 일찍 제출

   심사 시계를 쥔 쪽은 Apple과 Google이지 여러분이 아닙니다. 느린 심사나 반려가 약속한 날짜를 날리지 않도록 여유를 두고 제출하십시오.
3. 3
   첫 주를 면밀히 지켜보기

   빠르게 대응할 수 있도록 누군가를 대기시키십시오. 첫 주는 어떤 테스트 환경에서도 나오지 않는 현실의 예외 상황을 드러냅니다.
4. 4
   출시 전에 다음 날 이후 작업을 계획

   앱은 출시 시점에 결코 '완성'되지 않습니다. 피할 수 없는 작은 수정과 첫 피드백을 누가 처리할지 미리 정해 두십시오.

전체 일정을 한데 모으기

처음부터 끝까지 이어 붙이면 이 단계들은 현실적인 그림을 그려 줍니다. 어느 것도 이색적이지 않습니다. 사람들이 발을 헛디디는 까닭은, 화려하지 않은 단계들, 즉 디스커버리, 테스트, 앱스토어 대기가 반올림 오차가 아니라 달력 위의 진짜 시간임을 잊기 때문입니다. 집중된 첫 버전이 보통 몇 달에 걸쳐 어떻게 분포하는지 대략 보여 드립니다.

이를 합산하면 진짜 첫 버전에 3개월에서 5개월이 솔직한 범위인 이유, 그리고 6주를 약속하는 이들이 “앱”의 의미를 조용히 다시 정의하고 있는 이유가 보입니다. 비관이 아닙니다. 실제로 지킬 날짜와, 프로젝트 내내 사과하게 될 날짜의 차이입니다.

정말로 빠르게 하는 법 (그리고 그렇지 않은 법)

더 빨리 갈 수 있지만, 진짜 지렛대는 사람들이 손을 뻗는 그것이 아닙니다. 절반쯤 정의된 프로젝트에 개발자를 더 투입하면 대개 빨라지기는커녕 느려집니다. 솔직한 가속 장치는 화려하지 않습니다. 무엇을 빼놓을지 결정하고, 질문에 빠르게 답하며, 구축 중간에 무언가를 더하려는 충동을 누르는 것입니다.

단연 가장 큰 것은 가차 없는 범위입니다. 첫 버전이 작고 명확할수록 더 빨리 출시되며, 제값을 하는 출시된 앱은 또 다른 두 달의 기획보다 2주 만에 더 많은 것을 가르쳐 줍니다. 추가는 언제든 할 수 있습니다. 알고 보니 아무도 원하지 않은 기능을 만드느라 쓴 몇 달은 되찾을 수 없습니다.

소리 내어 말할 가치가 있는 관련된 진실이 있습니다. 모든 것이 애초에 맞춤 앱일 필요는 없습니다. 때로는 진짜 문제가, 앱 없이도 자동화 한 조각이 조용히 처리할 수 있는 한 토막의 수작업입니다. 좋은 파트너는 더 큰 구축을 팔아넘기는 대신, 그런 경우라면 그렇다고 말씀드립니다. 가장 싼 앱은 만들 필요가 없었던 앱이기 때문입니다.

자주 묻는 질문