타임라인

• 1일차: 개발 시작
• 7일차: 웹 버전 완성 및 런칭
• 7-10일차: 140명의 초기 사용자 확보
• 10일차: 안드로이드 & iOS 앱 개발 완료, Google Play Store 테스트 모드 런칭

겨우 열흘 만에 웹과 모바일 앱을 모두 런칭했다. 이 속도에 대해 많은 사람들이 놀라워한다. 어떻게 가능했을까? 그리고 왜 이렇게 서둘렀을까?

가설: 모바일 접근성이 핵심이다

웹 버전을 만들면서 확인한 것은 사람들이 기록이라는 행위 자체에 관심이 있다는 것이었다. 140명이 가입했고, 실제로 사용했다. 프로덕트 마켓 핏의 초기 신호를 확인한 셈이다.

하지만 나에게는 더 중요한 질문이 있었다:

“사람들은 데스크탑 앞에 앉았을 때만 기록하는가, 아니면 일상의 순간순간에 기록하고 싶어 하는가?”

이 질문에 답하려면 웹 버전만으로는 부족했다. 웹은 의도적으로 접속해야 한다. 브라우저를 열고, 북마크를 찾거나 URL을 입력해야 한다. 이건 이미 하나의 장벽이다.

반면 모바일 앱은 다르다:

• 항상 주머니 속에 있다
• 홈 화면에서 한 번의 탭으로 접근 가능하다
• 푸시 알림으로 리마인드할 수 있다
• 버스, 카페, 침대에서도 자연스럽게 사용할 수 있다

내 가설은 이것이었다: 모바일의 접근성이 사용 빈도를 극적으로 높일 것이다.

빠른 실행이 가능했던 이유

1. 명확한 검증 목표

웹 버전을 만들 때부터 다음 단계가 명확했다. “웹에서 기본적인 프로덕트 마켓 핏을 확인하면, 즉시 모바일로 이동한다.” 이 명확함이 우선순위 결정을 쉽게 만들었다.

2. MVP 원칙의 철저한 준수

웹 버전에서 핵심 기능을 검증했기 때문에, 앱 버전에서는 같은 기능을 모바일 UX에 맞게 구현하는 것에 집중할 수 있었다.

포함한 것:

• 기록 작성 및 조회
• 기본적인 검색 기능
• 구글 로그인

포함하지 않은 것:

• 고급 필터링
• 소셜 기능
• 복잡한 데이터 시각화
• 완벽한 UI 폴리싱

3. AI 도구의 전략적 활용

Claude Code는 이번 프로젝트에서 게임 체인저였다. 특히 모바일 앱 개발에서:

• React Native 보일러플레이트 빠른 설정
• 네이티브 기능 통합 (푸시 알림, 딥링킹 등)
• 플랫폼별 빌드 설정 자동화
• 디버깅 및 에러 해결

완벽하지 않았지만, 빠른 반복을 통해 작동하는 앱을 만들 수 있었다.

4. 완벽함보다 학습

이 시점에서 완벽한 앱이 목표가 아니었다. 목표는:

• 사용자 행동 데이터 수집
• 모바일 vs 웹 사용 패턴 비교
• 푸시 알림의 효과 측정
• 실제 모바일 환경에서의 UX 문제 발견

이런 것들은 실제 사용자가 실제 기기에서 사용해봐야만 알 수 있다.

테스트 모드로 시작한 이유

Google Play Store와 App Store 모두 테스트 트랙으로 먼저 런칭했다. 이유는:

1. 빠른 피드백 루프

프로덕션 리뷰는 시간이 걸린다. 테스트 트랙은 훨씬 빠르다.

2. 리스크 관리

초기 사용자들과 함께 문제를 찾고 고칠 수 있다.

3. 점진적 확장

작은 그룹에서 검증하고, 확신이 서면 공개 런칭으로 전환할 수 있다.

이제 시작되는 진짜 실험

앱이 스토어에 올라갔다. 이제 진짜 궁금한 질문들에 답할 시간이다:

데이터로 답할 질문들:

• 웹 vs 모바일 사용 빈도는 얼마나 차이나는가?
• 사람들은 하루 중 언제 가장 많이 기록하는가?
• 푸시 알림이 사용률을 높이는가?
• 세션 길이는 플랫폼별로 어떻게 다른가?
• 모바일 전용 기능(예: 카메라 통합)이 필요한가?

UX 개선을 위한 질문들:

• 어떤 화면에서 사용자들이 막히는가?
• 어떤 기능을 가장 자주 사용하는가?
• 어떤 에러가 가장 자주 발생하는가?

이 모든 질문들은 웹 버전만으로는 답할 수 없었던 것들이다.

속도의 진짜 의미

많은 사람들이 “열흘 만에 웹과 앱을 다 만들었다”는 점에 주목한다. 하지만 진짜 중요한 것은 속도 그 자체가 아니다.

진짜 중요한 것은:

1. 명확한 가설: 무엇을 검증하고 싶은지 알고 있었다
2. 빠른 학습: 실제 데이터로 배우는 것을 우선시했다
3. 집중: 검증에 필요한 것만 만들었다
4. 반복: 한 번에 완벽하게가 아니라, 빠르게 개선

속도는 결과가 아니라 이런 원칙들의 부산물이다.

다음 단계

앱 스토어에서 테스트가 승인되면:

1. 기존 웹 사용자들에게 앱 다운로드 안내
2. 사용 패턴 데이터 수집 시작
3. 주간 단위로 데이터 분석 및 가설 검증
4. 모바일 특화 기능 우선순위 결정
5. 공개 런칭 준비

결론: 만드는 것보다 배우는 것

일주일 만에 웹을 만들고, 열흘 만에 앱을 만든 것이 자랑스럽다. 하지만 더 자랑스러운 것은 이제 진짜 질문들에 답할 수 있는 도구를 손에 쥐었다는 것이다.

스타트업은 빠르게 만드는 것이 아니라 빠르게 배우는 것이다. 그리고 배우려면 실제 사용자의 손에 프로덕트를 쥐어줘야 한다.

이제 사용자들이 매일 주머니 속 KnotNet을 열어볼지 지켜볼 차례다. 데이터가 다음 방향을 알려줄 것이다.

그게 린 스타트업의 본질 아닐까.