「앱 기획」 F장 — 첫 버전을 어떻게 좋은 앱으로 키우는가. 풀어 쓴 설명 산문을 슬라이드마다 넣어, 강사가 읽고 그대로 말할 수 있게 했습니다. 텍스트가 잘리지 않도록 슬라이드 높이는 가변(최소 16:9)입니다.
이 장은 흩어진 팁을 나열한 게 아니라 한 질문을 끝까지 따라가는 하나의 논증이다. 본론에 들어가기 전, 우리가 지나갈 전체 길을 먼저 펼쳐 둔다. 앞 네 단계(통념→주장→왜→평가)는 '왜 반복이 답인가'를 논증하고, 뒤 두 단계(테스트→결론)는 '그럼 어떻게 한 바퀴를 도나'라는 실천법으로 잇는다.
앱을 처음 만든 학생들은 대개 똑같은 함정에 빠진다. 자기 첫 버전(v1.0)을 보고 "왜 이렇게 엉성하지"라며 실망하고, 심하면 처음부터 다시 만들려 한다. 좋은 앱은 한 번에 완성해 '짠' 하고 내놓는 것이라는 생각 — 이 통념을 깨는 데서 이 장이 시작된다.
잘 쓴 글도 처음부터 완벽하게 나오지 않는다. 초고를 일단 쓰고, 읽어 보며 어색한 곳을 퇴고한다. 초고가 거친 건 실패가 아니라 당연한 출발점이다 — 앱도 똑같다. 첫 버전이 엉성한 건 정상이고, 고쳐 나가면 된다.
이 장이 증명하려는 한 문장은 이것이다 — 좋은 앱은 '만들고 → 써 보고 → 고치기'를 작게 여러 번 돌며 자란다. 한 바퀴 돌 때마다 버전이 v1.0 → v1.1 → v1.2로 올라간다고 생각하면 된다. 한 번에 끝내려는 대신, 작은 한 바퀴를 반복하는 것이 핵심이다.
오래 고민해 '완벽한' 첫 버전을 만든다 → 내놓는다 → 막상 써 보니 문제투성이. 그동안 쓴 시간이 아까워 고치기를 포기한다. 한 번에 끝내려다 한 번도 못 고치는 셈이다.
만들고(작게) → 써 보고(직접) → 고치고(한두 개) → 다시 써 보고… 한 바퀴는 짧게, 횟수는 여러 번. 매 바퀴마다 앱이 조금씩 좋아진다.
반복이 효과가 있는 이유는 단순하다. 첫 버전을 직접 써 봐야 진짜 문제가 보이기 때문이다. 머릿속으로 아무리 상상해도 안 보이던 불편이, 손으로 만져 보는 순간 드러난다. 그래서 부족한 첫 버전은 실패의 증거가 아니라, 무엇을 고칠지 알려주는 진단표다. 그리고 이건 느낌이 아니라 데이터로 증명된다.
야콥 닐슨의 분석에 따르면, '써 보고-고치기'를 한 바퀴 돌 때마다 사용성이 중앙값 38%씩 좋아졌고, 첫 버전부터 마지막까지 누적하면 165%까지 향상됐다. 그래서 닐슨은 최소 세 바퀴는 돌라고 권한다. 한 번 만에 멈추면 가장 큰 향상을 놓치는 셈이다.
막연한 "별로야"는 고칠 수 없다. 어디가 왜 별론지 모르기 때문이다. 그래서 앱을 직접 써 보며 다섯 가지 축으로 나눠 점수를 매긴다. 각 축을 ●(좋음)·△(보통)·○(나쁨)로 표시하면, 막연한 불만이 구체적인 고칠 곳으로 바뀐다.
내가 만든 사람은 모든 버튼이 어디 있는지 안다. 그래서 나는 절대 안 헤맨다 — 진짜 문제가 나한테는 안 보인다. 친구는 첫 화면부터 막힐 수 있다. 그래서 디자이너는 실제 사용자에게 직접 시켜 보며 관찰한다. 이걸 사용성 테스트(usability testing)라고 한다.
"여기 누르면 돼"라고 알려주면, 친구는 막힘 없이 통과한다. 하지만 그 순간 진짜 문제는 가려진다 — 혼자였다면 헤맸을 곳을 못 보게 된다.
아무 말 없이 친구가 쓰는 걸 본다. 첫 화면에서 3초 머뭇거리는 것, 엉뚱한 버튼을 누르는 것 — 그 머뭇거림이 곧 '고칠 곳'이다.
고칠 곳이 열 개 보여도, 한 바퀴엔 한두 개만 고른다. 한꺼번에 다 바꾸면 무엇 때문에 좋아졌는지(또는 더 나빠졌는지) 알 수 없기 때문이다. 5축에서 ○가 나온 것 중 '가장 중요한 하나'부터 고치고, 다시 써 본다. 이 제약이 바로 우선순위를 정하는 훈련이다.
| 상황 | 욕심내면 (✗) | 한두 개만 (✓) |
|---|---|---|
| 고칠 양 | 색·글씨·버튼·기능 10곳 동시 | 가장 중요한 1~2곳만 |
| 효과 확인 | 뭐 때문에 변했는지 모름 | 그 하나의 효과를 명확히 봄 |
| 되돌리기 | 더 나빠지면 되돌리기 어려움 | 한 곳이라 쉽게 되돌림 |
| 다음 바퀴 | 기준이 사라져 개선 멈춤 | 다음 ○로 또 한 바퀴 |
지금까지의 논증을 몸으로 익히는 활동이다. 짝과 앱을 바꿔, 상대 앱을 직접 써 보며 5축에 점수를 매기고, "딱 한 가지만 고친다면?"을 한 줄로 적어 돌려준다. 핵심은 '말없이 지켜보기'와 '한두 개 제한' — 이 두 규칙이 이 장 전체의 요지다.
이 흐름은 sprint 수업과 그대로 이어진다.
교실에서 만든 앱으로 실제 v1.0 → v1.1 한 바퀴를 돌려 본다.
이 장은 흩어진 팁을 모은 게 아니라, 하나의 질문을 끝까지 따라간 추론이었다. 출발점은 "한 번에 완벽하게"라는 통념이었고, 도착점은 "작게 반복하며 키운다"는 주장이었다. 그 사이를 린 스타트업·닐슨·사용성 테스트가 각자의 역할로 이어주었다.
이 장에서 가장 자주 어기는 규칙을 한 문제로 점검한다. 정답보다 '왜'를 설명할 수 있는지가 중요하다.
한꺼번에 다 바꾸면 무엇 때문에 좋아졌는지(또는 나빠졌는지) 알 수 없다. 기준이 사라져 다음 개선의 방향을 잃고, 더 나빠져도 되돌리기 어렵다.
한 번에 한두 개씩만 고쳐야 그 하나의 효과를 명확히 확인할 수 있다. 5축에서 ○가 나온 것 중 가장 중요한 하나부터 고치고, 다시 써 본다.