도구를 만들었다면 그 도구가 겨냥한 문제는 사라져야 합니다. 앱을 20개 넘게 만들면서 제가 세운 기준입니다.
그런데 이 기준을 제 앱들에 대어 보면 통과하는 앱과 통과하지 못하는 앱이 갈립니다. 갈리는 이유를 따라가 보니, 도구의 완성도보다 문제를 어떤 크기로 정의했는지가 더 큰 변수였습니다. 이 글은 통과하지 못한 식단관리 앱과 통과한 클립키보드, 그리고 그 사이에서 제가 문제를 다루는 방식에 대한 기록입니다.
식단관리 앱으로 풀고 싶었던 문제는 "건강하게 먹고 체중을 관리하는 것"이었습니다. 앱이 완성된 뒤에도 그 문제는 그대로 남아 있었습니다. 기록은 쌓였지만, 기록이 쌓인다고 식습관이 바뀌지는 않았습니다.
원인은 문제와 도구 사이의 거리입니다. 감량까지 가는 길은 기록 → 인식 → 행동 변화 → 감량으로 이어지는데, 앱이 직접 닿는 칸은 첫 번째 하나뿐입니다. 나머지 화살표에는 스트레스, 수면, 오래된 습관, 가족의 저녁 식탁 같은 변수가 끼어 있고, 앱은 그 어느 것도 건드리지 못합니다.
더 불편한 사실도 있습니다. 기록이 습관이 되면 "그래도 기록은 하고 있잖아"라는 안도감이 생깁니다. 도구를 쓰는 행위가 성취감을 주면서, 정작 바뀌어야 할 행동에 대한 긴장은 풀립니다. 앱이 실패한 것이 아니라, 제가 앱에 맡긴 문제가 앱보다 컸던 것입니다.
같은 앱을 한 단계 아래의 문제로 평가하면 결과가 달라집니다. 감량이라는 큰 문제 아래에는 더 작은 문제들이 있고, 그중 몇 개는 앱이 생긴 날 실제로 사라졌습니다.
하위 문제 | 앱이 한 일 | 결과 |
|---|---|---|
기록이 귀찮아서 사흘 만에 끊긴다 | 입력 마찰을 줄였다 | 사라짐 |
흩어진 식사를 한눈에 볼 수 없다 | 날짜별로 정리해 보여준다 | 사라짐 |
지난 기록을 다시 찾을 수 없다 | 데이터를 보존한다 | 사라짐 |
기록을 보고도 다르게 먹지 않는다 | 닿지 못함 | 남아 있음 |
큰 문제가 남아 있다는 것과 도구가 아무것도 하지 못했다는 것은 다른 이야기입니다. 제 실수는 약속의 단위에 있었습니다. "살을 빼 드립니다"는 도구가 지킬 수 없는 약속이고, "기록이 끊기지 않게 해 드립니다"는 지킬 수 있는 약속입니다. 앱은 거울을 선명하게 만들었고, 거울 앞에서 무엇을 고칠지는 여전히 사람의 몫으로 남았습니다.
클립키보드가 겨냥한 문제는 작고 구체적입니다. 이메일 주소, 계좌 안내, 자주 쓰는 인사말을 매번 다시 타이핑하거나 메모 앱으로 넘어가 복사해 오는 일입니다. 키보드 위에 저장된 문구가 버튼으로 떠 있으니 탭 한 번이면 끝납니다.
이 문제는 앱을 설치한 날 실제로 사라집니다. 문제와 도구 사이에 화살표가 하나뿐이기 때문입니다. 식단관리 앱처럼 사용자의 의지가 중간에 끼어들 자리가 없습니다. 버튼을 누르면 문장이 입력되고, 그걸로 문제는 끝납니다.
다만 사라진 자리에서 새 문제가 생겼습니다.
앱 전환이 0회가 됐다고 말했지만, 그 비용은 지구본 버튼으로 키보드를 바꾸는 동작으로 옮겨 갔을 수 있습니다.
저장한 문구가 늘어날수록 원하는 버튼을 찾는 시간도 함께 늘어납니다.
문제를 풀었다고 해서 그 문제를 가진 사람이 도구를 찾아오지는 않습니다. 주간 다운로드는 10건 수준이었고, 유료 기능을 한시적으로 무료로 연 프로모션 기간에야 3,500건이 나왔습니다.
마지막 항목이 특히 중요합니다. 문제를 없애는 도구를 만드는 일과, 그 문제를 가진 사람에게 도구가 닿게 하는 일은 별개의 문제였습니다. 도구는 문제를 없애면서 동시에 자기만의 문제를 만듭니다.
클립 키보드 써보기: https://apps.apple.com/kr/app/%ED%81%B4%EB%A6%BD%ED%82%A4%EB%B3%B4%EB%93%9C/id1543660502
두 앱을 나란히 놓고 보니 제가 문제를 다루는 순서가 보였습니다. 처음부터 이렇게 한 것은 아니고, 대부분 비싼 수업료를 내고 얻은 순서입니다.
코드 한 줄에 대응할 만큼 쪼갭니다. 알고리즘을 짤 때 단계를 코드 한 줄과 1:1로 맞을 때까지 나누던 습관을 문제 정의에도 씁니다. "살을 뺀다"는 한 줄이 되지 않지만, "기록이 사흘 만에 끊긴다"는 한 줄이 됩니다.
도구가 책임질 칸만 고릅니다. 화살표 하나로 닿는 문제만 도구의 약속으로 삼고, 나머지는 사람의 몫이라고 분명히 적습니다.
실패를 알아챌 장치를 함께 만듭니다. 마케팅으로 매출이 999% 뛰었을 때, 약한 온보딩과 흐름 중간의 버그, 원인 모를 크래시가 한꺼번에 드러났고 사용자는 떠났습니다. 트래픽이 문제를 만든 것이 아니라 보이게 한 것이었습니다. 그 뒤로는 기능을 만들 때 그 기능이 실패하는 걸 알아챌 방법(단계별 이탈률, 크래시 리포트, 세션 길이)도 같이 만들고, 예산은 10% 정도만 먼저 써서 새는 곳을 막은 뒤 나머지를 씁니다.
가설이 무의미해지면 문제를 다시 정의합니다. 앱에 귀여움을 넣는 챌린지를 하다가, 귀여움이 필요한지 판단하는 법을 익히고 나서 제 앱에는 필요 없다는 결론에 닿았습니다. 그래서 문제를 "앱을 쓰면서 지치지 않게 만들기"로 바꿨고, 사용자의 목표와 기능이 맞물리면서 실제 사용이 나아졌습니다.
이 순서의 핵심은 처음 정의한 문제를 끝까지 붙들지 않는 것입니다. 저는 문제를 푸는 사람이기 이전에, 문제를 계속 다시 자르는 사람에 가깝습니다.
제목의 기준은 여전히 유효합니다. 다만 한 문장을 덧붙여야 합니다. 도구가 사라지게 할 수 있는 크기로 문제를 정의해야 합니다.
도구를 만들고도 문제가 남아 있다면 저는 두 가지를 의심합니다. 도구가 덜 만들어졌거나, 문제를 너무 크게 잡았거나. 식단관리 앱은 후자였고, 클립키보드는 문제를 작게 잡았기에 사라지게 했지만 그 자리에 새 문제를 남겼습니다.
그래서 다음 도구를 만들기 전에 먼저 묻습니다. "이 도구가 완성되면 정확히 무엇이 사라지는가?" 대답이 한 문장으로 나오지 않으면, 아직 더 쪼개야 한다는 신호입니다.
