안녕하세요, makeviibe입니다.
서비스를 만들다 보면 이런 요청을 종종 듣습니다:
“이 기능 있으면 사용자들이 좋아할 것 같아요.”
“이 버튼을 추가하면 더 편할 것 같아요.”
하지만 정말 사용자들이 그 기능을 원하고 있을까요?
makeviibe 팀은 그렇게 믿지 않습니다.
기능보다 먼저 확인해야 할 건 ‘사용자 데이터’입니다.
✅ 기능 요청 전에 반드시 확인해야 할 것
사용자 로그 분석
- 해당 기능을 요청한 사용자는 실제로 기존 기능을 얼마나 활용했는가?
- 그 페이지에는 하루에 몇 명이 들어오는가?
- 기능을 요청한 사용자는 전체 유저 중 몇 %인가?
이런 데이터를 통해 요청의 ‘비중’을 판단할 수 있습니다.
📌 실무에서의 예시
케이스 1 – “댓글에 답글 기능 넣어주세요”
데이터 분석 결과, 전체 댓글 중 92%가 1개 댓글로 끝났습니다.
실제 ‘대화’가 오가는 비율이 매우 낮았던 것.
💡 그래서 우리는 우선 ‘좋아요 기능’만 넣고, 답글은 MVP 이후로 보류했습니다.
불필요한 기능을 줄여서 개발 리소스를 아끼고,
정말 필요할 때 더 강력한 기능으로 대응할 수 있었습니다.
케이스 2 – “푸시를 자동으로 보내주세요”
하루에 전송되는 푸시 알림이 10건 이하였고,
모두 관리자 요청으로 직접 보내는 상황이었음
💡 자동화보다는 수동 전송 기능만 먼저 만들었습니다.
운영 데이터를 통해 발송량이 증가할 때 자동화를 적용해도 늦지 않다고 판단했기 때문입니다.
🔍 우리는 데이터를 이렇게 활용합니다
makeviibe 팀은 항상 사용자 행동 로그를 기반으로 기능 우선순위를 정합니다.
- DAU, MAU 같은 지표뿐만 아니라
- 클릭 이벤트, 체류 시간, 전환율 등도 함께 분석
📌 그리고 이 데이터를 기반으로
“지금 이 기능이 정말 필요한가?” 를 내부에서 먼저 검증하고
클라이언트에게도 데이터 기반 근거를 제공해 제안합니다.
💬 클라이언트가 자주 하는 질문
“그냥 이 기능 있으면 좋을 것 같아서 넣고 싶어요.”
좋습니다.
하지만, 그렇게 만든 수많은 기능 중 실제로 ‘사용되는 기능’은 얼마나 될까요?
💥 한 번 만든 기능은 운영, 유지보수, 테스트, 관리 등 지속적인 비용이 발생합니다.
기능은 최대한 ‘검증된 니즈’를 바탕으로 추가하는 것이
가장 빠르고 효율적인 개발 방식입니다.
✍️ 마무리
makeviibe는 개발보다 먼저 데이터를 봅니다.
요청 기능이 진짜 필요한지, 지금이 적절한 시기인지 판단하기 위해
항상 로그 기반의 데이터를 먼저 분석합니다.
다음 3편에서는,
소규모 프로젝트에서도 적용 가능한 로그 시스템 구성법을 소개해드릴게요.
함께 보면 더 명확해집니다 💡
'개발일지' 카테고리의 다른 글
| 📊 A/B 테스트, 정말 필요한가요? (5) | 2025.07.31 |
|---|---|
| 🛠 [3편] 소규모 프로젝트에서 꼭 필요한 로그 시스템 구성법 (2) | 2025.07.30 |
| 📌 [1편] 로그에도 두 종류가 있습니다 – ‘사용자 로그’와 ‘시스템 로그’의 차이 (0) | 2025.07.30 |
| 🛠️ 외주 프로젝트에서 Pulumi, Terraform을 사용하는 이유 – 인프라도 코드로 관리해야 하는 진짜 이유 (2) | 2025.07.29 |
| 처음부터 서버리스? 아니요, 우리는 이렇게 확장합니다 (4) | 2025.07.25 |