한 스타트업의 기획자가 말했다.
“이 기능, 있으면 당연히 쓰지 않을까요?”
그 말 한마디로 시작된 개발은
두 달 뒤, 아무도 누르지 않는 버튼으로 남았다.
나는 그 기능이 어떤 API를 쓸지, 어떤 상태를 어떻게 관리할지 고민하며 만들었고,
디자이너는 애니메이션을 붙였고,
기획자는 “이건 우리만의 차별화”라고 했다.
하지만 결과는?
전체 사용자 중 클릭률 0.8%.
전환 없음. 피드백 없음.
기능에 대한 불만도 없음. 즉, 존재조차 모름.
개발자가 가장 많이 마주하는 상황 중 하나다.
가장 공들인 기능이 가장 쓰이지 않는다.
왜냐하면 그 기능은 **'필요해서 만든 것'이 아니라, '있으면 좋아 보일 것 같아서 만든 것'**이기 때문이다.
좋아 보이는 건 사용자 기준이 아니라, 기획자 기준이다.
그리고 문제는, 대부분의 기획은 행동을 보기 전에 기능을 정의한다.
실제 사례도 있다.
한 B2B AI 스타트업이 초기 제품을 설계하면서
“우리 클라이언트들은 데이터를 직접 커스터마이징하고 싶어할 거야”라는 가정으로
복잡한 분석 대시보드와 모델 커스터마이징 기능까지 집어넣었다.
하지만 제품이 출시되고 나서 클라이언트는 딱 한 마디 했다.
“그냥 버튼 하나만 누르면 자동 분석되면 안 되나요?”
이후 실제 사용자는 복잡한 설정 기능을 한 번도 쓰지 않았다.
그들은 '기능이 많아서 불편한' 것이 아니라,
**'기능이 많다는 이유로 시작하지도 않은 것'**이었다.
그 스타트업은 결국 기능 대부분을 걷어내고,
딱 두 개의 버튼과 자동 실행 기능으로 바꿨다.
그리고 나서야 실제 사용이 시작됐다.
또 다른 사례도 있다.
한 모바일 서비스는 화면 하나에 모든 기능을 넣으려고 했다.
“이게 다 한눈에 보여야 직관적이죠”라는 말이 기획팀 입버릇이었다.
그 결과, 사용자는 무엇을 눌러야 할지 몰랐다.
오히려 자주 쓰는 기능이 묻혀서,
“기능이 없는 줄 알았다”는 피드백까지 나왔다.
이후 해당 팀은 A/B 테스트를 통해
사용자의 컨텍스트에 따라 기능을 단계적으로 드러내는 구조로 전환했고,
그때부터 반응이 오기 시작했다.
기능은 '있으면 좋은 것'이 아니다.
'없으면 멈추는 것'만 남겨야 한다.
그러려면 반드시 행동 기반의 피드백이 필요하다.
| “이 기능 있으면 좋지 않을까?” | 사용자 반응 없는 추측 |
| “경쟁사도 넣었으니까 우리도” | 맥락이 다름 |
| “기능이 많을수록 고급스러워 보여요” | 실제 사용성과 무관 |
| “일단 만들고 보자” | 유지/보완 리소스 낭비, 클릭 0 |
정말 필요한 기능은
사용자가 먼저 요청하든가,
아니면 기능 없이 쓰다가 멈추든가
둘 중 하나일 때만 생겨야 한다.
- 사람들이 회원가입 중 80% 이탈한다
→ “가입 방식 단순화 필요” - 결제 버튼을 누른 사람 중 60%가 포기했다
→ “결제 프로세스 줄이기 필요” - 특정 필터 기능을 매일 반복 사용한다
→ “필터 고정 기능 제공 필요”
이게 기획의 출발점이어야 한다.
기능은 만들고 나서 보완하는 게 아니라,
만들기 전에 줄이는 과정이 있어야 한다.
정리하자면 이렇게 말할 수 있다.
| 실제 사용자 요청이 있었는가 | 인터뷰, 메일, 댓글 등 |
| 이 기능이 없어서 사용이 끊긴 적이 있는가 | 이탈 데이터, 행동 로그 |
| 기능 추가 전/후 성과 비교가 가능한가 | 지표 기반 기획 |
| 개발 리소스를 투자할 ‘명확한 목적’이 있는가 | 매출, 전환율, 반복 사용 |
개발자는 화려한 기능보다
명확한 이유가 있는 단순한 기능을 더 신뢰한다.
“좋아 보여서 만들었다”는 말보다
“없었더니 사용자가 멈췄다”는 말이
개발을 설득하는 가장 정확한 방식이다.