첫 제품에서 버릴 기능부터 정해야 하는 이유

작은 앱을 만들 때 가장 위험한 순간은 코드를 짜기 전입니다. 머릿속에서는 이미 좋은 제품이 되어 있습니다. 로그인도 있고, 통계도 있고, 알림도 있고, 예쁜 설정 화면도 있습니다. 하지만 첫 버전에서 그걸 모두 만들면 제품을 검증하기 전에 운영할 기능이 너무 많아집니다.

작은 제품의 첫 버전이라면 첫 질문은 “무엇을 만들까”가 아니라 무엇을 만들지 않을까가 되어야 합니다.

첫 버전의 목표는 완성된 제품이 아닙니다. 사용자가 하루에 한 번이라도 돌아와서 기록하거나 확인하는 흐름이 생기는지 보는 것입니다.

그래서 첫 버전은 “할 일 앱” 전체를 만들지 않습니다. 더 좁게 보면 오늘의 항목을 남기고, 완료하고, 다음 날 다시 열었을 때 어제가 남아 있는지 확인하는 실험입니다. 이 흐름이 버티지 못하면 알림, 통계, 계정 기능은 모두 장식이 됩니다.

먼저 버릴 기능

첫 버전에서 미뤄도 되는 기능은 생각보다 많습니다.

기능	왜 미루는가	다시 볼 시점
회원가입/로그인	계정 구조가 생기면 데이터 모델과 보안 범위가 커진다	여러 기기 동기화가 실제로 필요할 때
통계 대시보드	기록이 쌓이기 전에는 볼 데이터가 없다	2~4주 이상 데이터가 쌓일 때
푸시 알림	알림은 습관을 돕지만 귀찮음도 만든다	사용자가 다시 오지 않는 이유가 명확할 때
관리자 페이지	사용자 흐름 검증과 직접 관련이 적다	운영자가 반복 작업을 실제로 할 때
결제	가치 검증 전 결제는 설계 비용이 크다	무료 사용자가 명확한 한계를 만났을 때
소셜 공유	핵심 행동보다 외부 노출에 관심이 쏠린다	공유할 만한 결과물이 생겼을 때

기능을 버린다는 말은 영원히 포기한다는 뜻이 아닙니다. 검증 순서를 정한다는 뜻입니다.

첫 버전이 가져야 할 것

MVP는 허술한 제품이 아닙니다. 작지만 끝까지 이어지는 흐름이어야 합니다.

첫 제품의 첫 버전이라면 다음 정도면 충분합니다.

1. 오늘 할 일을 적는다
2. 완료 여부를 바꾼다
3. 오늘이 지나면 기록으로 남는다
4. 다시 열었을 때 어제와 오늘의 차이를 볼 수 있다

이 흐름이 없으면 알림이나 통계가 있어도 의미가 약합니다. 반대로 이 흐름이 자연스럽다면 로그인 없이도 첫 검증은 가능합니다.

첫 화면도 이 흐름에 맞춰 좁게 잡아야 합니다.

화면 영역	첫 버전에서 하는 일	제외할 것
오늘 입력	한 줄 항목을 빠르게 추가한다	우선순위, 라벨, 반복 규칙
오늘 목록	완료/미완료를 바로 바꾼다	드래그 정렬, 복잡한 필터
어제 기록	어제 완료한 항목을 짧게 보여준다	월간 리포트, 차트
빈 상태	오늘 하나를 적게 만든다	긴 온보딩, 튜토리얼
데이터 내보내기	백업 가능성만 남긴다	계정 기반 동기화, 팀 공유, 결제

이 정도면 화면은 작지만 검증 질문은 분명해집니다. 사용자가 정말 필요한 것은 완성형 생산성 도구가 아니라 오늘 다시 열 이유일 수 있습니다.

데이터는 작게 시작한다

첫 버전에서 서버를 붙이면 할 일이 늘어납니다. 인증, API, 데이터베이스, 배포, 백업, 장애 대응을 같이 생각해야 합니다.

처음에는 로컬 저장으로도 검증할 수 있습니다.

저장 방식	장점	단점
브라우저 로컬 저장	빠르게 만들고 배포 가능	기기 간 동기화 없음
간단한 서버 API	데이터 보존과 확장 가능	인증/운영 비용 발생
BaaS	빠른 계정/DB 구성	제품 구조가 서비스 제약에 묶일 수 있음

중요한 것은 “언젠가 서버가 필요하다”와 “지금 서버가 필요하다”를 구분하는 것입니다. 첫 버전은 사용 흐름을 확인하는 단계입니다. 서버 구조는 사용자가 실제로 계속 쓰는지 본 뒤 붙여도 늦지 않습니다.

저장 데이터도 처음부터 크게 잡지 않습니다.

day: 2026-07-02
items:
  - text: "아침에 할 일 하나 적기"
    done: true
    createdAt: 09:10
    completedAt: 09:42

첫 버전에서 필요한 데이터는 이 정도입니다. 누가 작성했는지, 어느 팀에 속하는지, 어떤 프로젝트와 연결되는지는 아직 핵심 질문이 아닙니다. 오히려 이런 필드가 일찍 들어오면 계정, 권한, 공유 범위까지 같이 커집니다.

판단 기준

기능을 넣을지 말지 애매할 때는 다음 질문을 합니다.

[ ] 이 기능이 없으면 핵심 행동을 할 수 없는가?
[ ] 이 기능이 없으면 사용자가 다음 날 돌아오지 못하는가?
[ ] 이 기능이 지금 없어서 잘못된 검증 결과가 나오는가?
[ ] 이 기능을 넣으면 운영 범위가 얼마나 늘어나는가?
[ ] 나중에 붙일 때 데이터 구조를 크게 갈아엎어야 하는가?

세 번째 질문이 중요합니다. 어떤 기능은 없어도 됩니다. 하지만 없으면 잘못된 결론을 만들 수 있는 기능은 필요합니다. 예를 들어 오늘 기록이 새로고침 후 사라진다면 사용 흐름을 검증할 수 없습니다. 반대로 예쁜 월간 통계는 첫날에는 없어도 됩니다.

첫 버전의 성공 기준

MVP의 성공 기준은 다운로드 수나 페이지뷰가 아닙니다. 작은 앱에서는 반복 행동이 더 중요합니다.

지표	보는 이유
첫 기록 완료율	사용자가 첫 행동을 이해했는지
다음 날 재방문	하루 단위 앱의 핵심
기록 수정 빈도	실제로 관리하는지
삭제/포기 지점	흐름이 어디서 부담스러운지
직접 피드백	숫자로 안 보이는 불편

이 지표를 보기 전에는 기능을 늘리는 것보다 흐름을 줄이는 편이 낫습니다.

다만 이 지표를 거창한 분석 시스템으로 시작할 필요는 없습니다. 첫 단계에서는 배포 후 직접 사용하면서 다음 네 가지를 기록해도 충분합니다.

[ ] 오늘 항목을 추가하는 데 5초 이상 걸리는가?
[ ] 완료 처리 위치를 한 번에 찾을 수 있는가?
[ ] 다음 날 열었을 때 어제 기록이 자연스럽게 보이는가?
[ ] 기록이 쌓일수록 화면이 지저분해지는가?

숫자는 나중에 붙여도 됩니다. 처음에는 반복 사용을 방해하는 지점이 보이는지가 더 중요합니다.

나중에 붙여야 할 기능

미룬 기능에도 순서가 있습니다.

기록 보존 안정성
내보내기/백업
계정과 동기화
알림
통계
결제

계정이 먼저가 아닐 수 있습니다. 오히려 사용자가 데이터를 잃지 않게 내보내기부터 제공하는 편이 작은 앱에는 더 맞을 수 있습니다. 로그인은 동기화와 여러 기기 사용이 실제 요구로 확인될 때 붙여도 됩니다.

첫 버전 범위

첫 제품의 범위는 이렇게 잡는 편이 좋습니다.

포함:
- 오늘 항목 작성
- 완료 처리
- 날짜별 기록
- 최소한의 로컬 저장
- 모바일에서 읽히는 화면

제외:
- 로그인
- 결제
- 푸시 알림
- 관리자 페이지
- 복잡한 통계
- 소셜 공유

이 범위는 작습니다. 그래서 만들 수 있습니다. 작은 제품은 첫 버전에서 많은 기능을 보여주는 것보다, 다음 버전을 만들 수 있는 피드백을 남기는 쪽이 중요합니다.

결론

첫 버전은 제품의 축소판이 아닙니다. 검증해야 할 행동만 남긴 실험입니다.

첫 제품이 검증해야 하는 것은 “사용자가 오늘의 기록을 남기고 다시 돌아오는가”입니다. 그 질문에 답하지 못하는 기능은 일단 미룹니다. 나중에 붙일 수 있는 기능보다, 지금 없으면 판단이 불가능한 기능을 먼저 만듭니다.