중소기업이 거듭 저지르는, 비용이 큰 앱 개발 실수 8가지

어긋나는 앱 프로젝트에는 불편한 진실이 있습니다. 코드가 잘못돼 보이기 시작할 무렵이면, 프로젝트는 이미 몇 주 전에 진 싸움입니다. 중소기업 앱 개발에서 비용이 큰 실수는 키보드 앞에서 일어나는 일이 거의 없습니다. 그것은 가벼운 대화 속에서 일어납니다. 끝내 글로 남기지 않은 요구사항, 누군가 '하는 김에' 덧붙인 기능, 친구가 추천했다는 이유로 고른 개발자. 그 순간에는 어느 것도 결정처럼 느껴지지 않습니다. 그러나 그 모든 것이 나중에 당신에게 비용을 치르게 합니다.

저는 많은 소기업이 첫 앱을 발주하는 것을 지켜봤고, 일이 벌어진 뒤 수습을 부탁받은 적도 숱합니다. 사장님들이 부주의한 사람인 경우는 드뭅니다. 그들은 날카롭고, 신중하며, 사업 운영에 능합니다. 하지만 소프트웨어에는 그들의 일상 어디에도 없는 고유한 함정이 있고, 아무도 그것을 경고해 주지 않았습니다. 그래서 그들은 매번 거의 같은 순서로, 같은 여덟 개의 함정으로 곧장 걸어 들어갑니다.

이것은 모든 사장님이 한 푼이라도 쓰기 전에 손에 들고 있었으면 하는 목록입니다. 이론이 아니라, 실제로 되풀이되는 실수와 각 프로젝트를 구할 수 있었던 작은 진로 수정입니다. 이제 막 앱을 만들려 하거나, 이미 개발 중인데 무언가 어긋난 느낌이 든다면 이것부터 읽어 보십시오. 대부분은 일찍 알아채면 아직 바로잡을 수 있습니다.

실수 1: 누군가 원한다는 것을 입증하기 전에 만들기 시작한다

가장 비용이 큰 실수는 동시에 가장 흔한 실수입니다. 앱이 사람들이 돈을 내거나 사용할 만한 문제를 해결한다는 실제 증거가 나오기 전에 본격적인 개발에 뛰어드는 것입니다. 사장님에게는 그 아이디어가 자명해 보입니다. 당연히 고객이 원하지 않겠느냐고요. 바로 그 확신이 위험합니다. 확신은 수요의 검증처럼 느껴집니다. 그러나 검증이 아닙니다.

검증이란 친구 열 명에게 아이디어가 마음에 드느냐 묻는 것이 아닙니다. 모두 친절하게 '좋다'고 말할 뿐입니다. 검증이란 가능한 한 작은 버전을 실제 상황 속에서 진짜 사용자 앞에 두고, 그들이 실제로 무엇을 하는지 지켜보는 것입니다. 클릭 가능한 시제품, 가입 수를 측정하는 랜딩 페이지, 자동화를 손으로 흉내 내는 수동 '컨시어지' 버전 — 어느 것이든 직감으로 만든 완성 앱보다 더 많은 것을 알려 줍니다. 순서가 중요합니다. 수요를 싸게 입증하고, 그다음에 비싸게 만드십시오. 이를 뒤집으면, 아무도 두 번 열지 않을 것을 다듬는 데 예산을 전부 써 버릴 수 있습니다.

실수 2: 야심으로 포장한 범위 확장

모든 앱은 군더더기 없이 깔끔하게 시작합니다. 그러다 '하는 김에'가 시작됩니다. 예약 화면을 만드는 김에, 기프트 쿠폰도 처리할 수 있지 않을까요? 적립 포인트도? 추천 시스템도? 추가 하나하나는 그 자체로 합리적으로 들립니다. 합쳐지면 일정과 청구액을 조용히 세 배로 만들고 — 출시를 너무 멀리 밀어내 처음의 추진력을 죽여 버립니다.

해법은 좋은 아이디어에 '아니오'라고 말하는 것이 아닙니다. 그것을 잠시 보류하는 것입니다. 빛나는 아이디어가 저마다 차례를 기다리는, 눈에 보이는 '버전 2' 목록을 두십시오. 이것은 실무적으로도, 심리적으로도 효과가 있습니다. 자기 아이디어의 자리가 나중에 정말로 있다고 믿으면, 사람들은 첫 출시에 기능을 욱여넣으려 다투기를 멈춥니다. 첫 버전은 한 가지를 정말 잘해야지, 열 가지를 어설프게 해서는 안 됩니다. 하나의 업무 흐름을 완벽히 처리하는 앱은 사용됩니다. 모든 것을 절반만 하는 앱은 버려집니다.

실수 3: 글로 적은 요구사항이 없다 — 머릿속에 공유된 그림만 있다

이 실수는 물릴 때까지 보이지 않습니다. 사장님의 머릿속에는 명확한 앱이 있습니다. 개발자의 머릿속에도 명확한 앱이 있습니다. 킥오프 회의에서 모두 고개를 끄덕입니다. 아무도 제대로 적어 두지 않습니다 — 그리고 두 그림은, 알고 보니 한 번도 같은 그림이 아니었습니다. 당신은 이를 한가운데서 알게 됩니다. 만들어지는 것이 상상하던 것이 아니고, 이제 누가 무엇을 말했느냐를 두고 논쟁이 벌어집니다.

백 페이지짜리 명세서는 필요 없습니다. 새로 온 누구라도 읽고 이해할 수 있는 몇 페이지가 필요합니다. 누가 이 앱을 쓰는가, 그들이 앱으로 해야 할 서너 가지는 무엇인가, 성공한 결과는 어떤 모습인가. 핵심 화면의 대략적인 스케치를 더하십시오. 그게 전부입니다. 요구사항의 목적은 관료주의가 아닙니다 — 기억과 현실이 어긋나기 시작할 때, 두 사람이 함께 가리킬 수 있는 공유된 기준점입니다. 그리고 그 어긋남은 늘 일어납니다.

실수 4: 잘못된 방식으로 개발자를 고른다

대부분의 사장님은 두 가지 빈약한 신호 중 하나로 첫 개발자를 고릅니다. 가장 낮은 견적이거나, 다른 업종의 누군가가 한 개인적 추천입니다. 둘 다 운이 좋으면 통할 수 있습니다. 그러나 어느 쪽도, 상당한 돈과 사업의 미래 몇 달을 맡길 사람을 고르는 믿을 만한 방법은 아닙니다.

가장 낮은 견적은 소프트웨어에서 특히 위험합니다. 견적과 완성 비용 사이의 간극이 거대하고, 또 보이지 않기 때문입니다. 재작업을 세 번 거치고, 두 주 동안 사라지고, 다른 누구도 유지보수할 수 없는 코드를 남기는 싼 개발자는, 조금 비싸도 한 번에 제대로 해내는 개발자보다 훨씬 비쌉니다. 가격은 보이는 것이고, 총비용은 실제로 치르는 것입니다.

실제로 확인할 것

그들이 출시해 지금도 돌아가는 것을 보여 달라고 하고, 가능하면 개발자가 없는 자리에서 그 고객들과 이야기하십시오. 프로젝트 도중의 변경을 어떻게 다루는지 물으십시오. 변경은 반드시 생기기 때문입니다. 완성되면 코드와 계정을 누가 소유하는지 물으십시오 — 답은 언제나 당신이어야 합니다. 그리고 그들이 좋은 질문을 되묻는지 살피십시오. 지시만 받는 개발자는 잘못된 것을 아주 효율적으로 만들어 냅니다. 좋은 개발자는 반박하고, 당신 생각의 빈틈을 짚어 주며, 요구사항을 고정된 쇼핑 목록이 아니라 대화의 출발점으로 다룹니다.

실수 5: 개발 예산은 잡아도 나머지를 잊는다

앱은 인쇄된 브로슈어처럼 한 번 사고 끝나는 물건이 아닙니다. 먹이를 줘야 하는 살아 있는 존재입니다. 사장님들은 으레 개발 예산만 잡고 그 밖에는 잡지 않다가, 뒤이어 닥치는 비용에 허를 찔립니다. 호스팅, 앱스토어 수수료, 휴대폰 OS 업데이트를 따라잡기 위한 유지보수, 그리고 진짜 사람들이 쓰기 시작하면 어김없이 따라오는 수정과 작은 개선의 한 차례입니다.

현명한 어림 규칙은 이렇습니다. 개발에 얼마가 들든, 그 의미 있는 일부를 운영 첫해를 위해 다시 떼어 두십시오. 정확한 숫자는 다양하지만, 실수는 보편적입니다 — 출시일을 결승선으로 여기는 것입니다. 사실 그것은 출발선인데도요. 출시된 뒤 유지할 예산이 없어 조용히 버려지는 앱은, 이 분야 전체에서 가장 슬프고 가장 흔한 결말 가운데 하나이며, 사전의 정직한 계획으로 완전히 피할 수 있습니다.

실수 6: 사용자가 아니라 자신을 위해 설계한다

당신은 자기 사업을 속속들이 알기에, 당신의 앱이 쓰기 쉬운지를 판단하기에는 최악의 사람입니다. 당신에게 당연한 것들 — 전문 용어, 일을 처리하는 순서, 생각 없이 쓰는 지름길 — 은 처음 쓰는 사용자에게는 어리둥절합니다. 사장님에게는 완벽히 말이 되고 나머지 모두를 헷갈리게 하는 앱은, 아무리 영리해도 실패한 것입니다.

처방은 싸고 조금 겸손하게 만듭니다. 출시 전에 진짜 사람들이 쓰는 모습을 지켜보는 것입니다. 이미 어떻게 작동해야 하는지 아는 당신의 팀이 아니라 — 한 번도 본 적 없는 실제 고객이나 직원입니다. 앱을 건네고, 과제를 주고, 아무 말도 하지 마십시오. 그들이 망설이고, 엉뚱한 곳을 누르고, 한숨을 쉬는 그곳이 당신의 디자인 피드백입니다. 가장 심각한 문제를 드러내는 데는 다섯 명이면 충분합니다. 이 단계를 건너뛰면, 아무도 못 찾는 '제출' 버튼과, 시도한 사람의 절반을 놓치는 가입 흐름을 안은 채 앱이 세상에 나옵니다.

• 테스터에게 둘러보기가 아니라 진짜 과제를 주십시오 — '다음 주 화요일로 예약을 잡아 보세요'라고 한 뒤 입을 다무십시오.
• 결국 성공했는지뿐 아니라, 그들의 손과 표정을 보십시오.
• 모든 망설임을 적으십시오. 멈칫함은 안에서는 보이지 않는 디자인 문제입니다.
• 설명하고 싶은 충동을 누르십시오 — 설명해야 한다면, 그것은 앱이 했어야 할 일입니다.
• 다섯 명으로 테스트하고, 명백한 실패를 고친 뒤, 다시 테스트하십시오.

실수 7: 필요도 없는데 iOS와 안드로이드 네이티브를 만든다

첫날부터 큰 브랜드들이 하듯 iPhone과 안드로이드 양쪽에 완전 네이티브로 '제대로 된' 앱을 만들고 싶은 충동이 있습니다. 대부분의 소기업에게 그것은 사용자가 결코 알아채지 못할 이점을 위해 비용과 복잡성을 두세 배로 치르는 일입니다. 더 나쁘게도, 이제 당신은 두 개의 별도 코드베이스를 영원히 유지보수하며, 앞으로의 모든 수정을 두 배로 늘리게 됩니다.

올바른 첫걸음이 아예 네이티브 앱이 아닌 경우가 많습니다. 어떤 휴대폰의 브라우저에서도 동작하는 잘 만든 웹 앱이나, 하나의 코드베이스에서 양쪽 스토어 버전을 만들어 내는 크로스플랫폼 방식은, 더 빠르고 더 싸게 시장에 도달하게 해 줍니다 — 그리고 실제 사용이 그 가치를 입증하면 언제든 나중에 완전 네이티브로 갈 수 있습니다. 물어야 할 질문은 추상적인 '네이티브냐 웹이냐'가 결코 아닙니다. 그것은 이렇습니다. 진짜 사용자가 핵심 일을 해낼 수 있는, 가장 작고 가장 싼 것은 무엇인가? 그것을 만들고, 거기서 배우고, 그런 다음 가정이 아니라 증거를 가지고 큰돈을 쓰십시오.

실수 8: 출시를 일의 끝으로 여긴다

여덟 번째 실수는 앱이 공개되면 프로젝트가 끝났다고 믿는 것입니다. 끝나지 않았습니다 — 그때가 진짜 프로젝트의 시작입니다. 사용자의 손에 닿게 할 계획도, 그들의 생각을 들을 방법도, 배운 것을 바탕으로 개선할 의지도 없는 앱은, 몇 달 안에 빛이 바래는 앱입니다. 개발은 쉬운 부분이었습니다. 사용 확산이 어려운 부분이고, 거의 아무도 그것을 계획하지 않습니다.

출시 전에 세 가지를 아십시오. 사람들이 앱의 존재를 어떻게 알게 되는가, 그들이 실제로 쓰는지 어떻게 측정하는가, 그리고 다음 차례의 일을 추측이 아니라 현실이 이끌도록 그들이 들려주는 것을 어떻게 모으는가. 이 가운데 비싼 것은 없습니다. 그저 다른 마음가짐일 뿐입니다 — 앱은 끝내고 떠나는 물건이 아니라, 당신이 유지하는 관계입니다. 이를 이해하는 사장님은 시간이 갈수록 더 유용해지는 앱을 얻습니다. 그렇지 못한 사장님은 출시일의 급등과 길고 조용한 하락을 얻습니다.

여덟 가지를 한꺼번에 피하는 법

함께 읽어 보면, 이 실수들에는 하나의 공통된 뿌리가 있습니다. 증거 위를 천천히 가는 대신, 가정 위를 빠르게 가는 것입니다. 하나하나가 신중한 단계를 건너뛰는 편이 더 싸 보였던 지점입니다. 그리고 하나하나가, 개발 뒤보다 개발 전에 다루는 편이 훨씬 쌉니다. 여덟 가지를 조용히 피하는 순서가 여기 있습니다.

1. 1
   만들기 전에 수요를 입증하라

   시제품, 랜딩 페이지, 또는 수동 버전. 예산을 투입하기 전에 누군가 이것을 원한다는 실제 증거를 확보하십시오.
2. 2
   요구사항과 버전 2 목록을 적어라

   누구나 이해할 수 있는 몇 페이지의 명확한 문서에, v1을 탈선시키지 않도록 모든 '하는 김에' 아이디어를 둘 보류 공간을 더하십시오.
3. 3
   개발자는 가격이 아니라 실적으로 골라라

   출시한 작업물, 추천처 확인 통화, 코드와 계정 소유권의 명확함, 그리고 좋은 질문을 되묻는 사람.
4. 4
   개발만이 아니라 첫해 전체의 예산을 잡아라

   호스팅, 유지보수, 수정, 지원. 출시일은 출발선이므로, 그것을 운영하는 데 자금을 대십시오.
5. 5
   일을 해내는 가장 작은 플랫폼을 골라라

   대부분의 경우 먼저 웹이나 크로스플랫폼. 사용이 요구할 때만, 증거를 가지고 나중에 완전 네이티브로.
6. 6
   진짜 사용자로 테스트한 뒤, 출시를 계획하라

   낯선 다섯 명이 쓰는 모습을 지켜보고, 명백한 실패를 고치고, 사람들이 어떻게 찾을지와 사용을 어떻게 측정할지 미리 정하십시오.

자주 묻는 질문