📎 어제의 이야기
어제(3일차)는 "설문조사 팀(3명)"과 "아이디에이션 팀(2명)"이 나뉘어 활동을 했다.
나는 이전에 설문조사를 배포한 경험이 있기에 설문조사 팀으로 배정되었다.
따로 활동을 하다가 오후 7시 30분에 두 팀이 함께 모여서 이야기를 나누게 되었는데, 저녁 튜터님께서 오시는 시간대와 겹치게 되었고, 그러다보니 함께 서로의 첫 공유물을 튜터님 앞에서 보는 상황이 펼쳐졌다.
우리 조에서 그동안 생각해온 모습은 "사용자의 맥락을 고려한 인앱 푸시 설계를 통해 사용자가 감정 기록 어플에 꾸준하게 접속할 수 있도록 한다"였는데, 아이디에이션 팀이 구상해온 모델은 인앱 푸시 알림이 아닌 "이메일 알림"이어서 꽤 당황스러웠다.
그러나 같이 이야기를 나눌 시간이 부족해서 '왜 앱 푸시 알림에서 이메일로 변경이 되었는지'에 대한 자세한 이야기를 하지 못했고, "내일 12시까지 조원들 각자 아이디에이션을 해온 것을 발표하고, 어떻게 프로덕트를 설계하는 것이 좋을지"에 대해 이야기를 나누기로 했다.
🏃♀️ 오늘 한 일
12시에 조원들을 만나기 전에 부트캠프 내의 PM튜터님과 개발 튜터님께 찾아가 궁금한 점에 대해 여쭈어보았다.
"저희 조가 가려는 방향은 ‘알림을 적절하고 불쾌하지 않게, 그리고 사용 지속성을 위해서 도움이 되도록 주는 것’인데 메일로 알림을 하게 되면 적절하지 않을까봐, 그리고 실제로 배포를 했을 때 저희 조에서 보고자 했던 '지표'라던가 '개선'이 무의미해질까봐 걱정이 됩니다.'
👩🏫 PM 튜터님의 피드백 요약
✅ A. 이메일 알림으로 전환은 가능
• 문제 정의 자체가 “개인화되지 않은 알림 구조 문제”였기 때문에, 이메일 방식도 논리적으로 이어질 수 있음.
• 단, 이메일로 전환하는 경우에도 개인 맞춤 맥락(위치, 일정 등)을 고려한 설계를 잘 해야 함.
• 이메일 안에 버튼(CTA)을 넣어 서비스로 직접 연결되도록 구현하면 전환율 개선 가능.
⚠️ B. 이메일 알림의 단점 및 허들
• 사용자가 이메일 앱 알림을 꺼두었거나, 열어보지 않으면 실효성이 없음.
• 이메일 알림은 접근까지의 허들이 많음:
1. 이메일 알림 허용 설정
2. 메일함 진입 → 클릭 → 앱 진입
• → 따라서 온보딩 단계에서 알림 설정 유도 필요 (예: “이메일 알림을 허용해 주세요”)
🎯 3. 지표 설정 및 유저 수 관련 조언
📊 A. 1차 MVP 지표에 너무 집착하지 말기
• MVP 1차 지표는 정확도보다는 방향성 확인용.
• 실무에서도 1차 목표치는 대부분 실패하거나 조정됨.
• → “달성하겠다”보다 “가능성 테스트”의 관점에서 설정해야 함.
👥 B. 유의미한 테스트를 위한 사용자 수
• 1차 배포 시 유저 50~100명 확보 권장 (지표 확인 및 개선용).
• 내부 팀원, 가족, 지인 등 지인 네트워크 적극 활용.
• 이후 개선된 버전은 타겟 커뮤니티를 활용한 바이럴 및 마케팅 추진.
🧩 4. 참고 사례
• ‘첨벙’ 팀 : 자유 수영 관련 서비스 → 커뮤니티 활용 → 약 300~400명 확보
• ‘무지개 다리’ 팀 : 반려동물 사별 위로 편지 → AI 활용 → 커뮤니티 바이럴 통해 한 달간 회원 가입자 1,000명 이상 확보
👨🏫 개발 튜터님의 피드백
📌 1. 푸시 알림 기능 관련 기술적 제약
❌ 인앱 푸시 알림 : 앱 설치 기반 기능이며, 프레이머는 웹앱이라 기술적으로 구현 불가능.
❌ 웹 푸시 알림 : 구현 가능은 하나, 6주 내 MVP 수준에서 구현하기에는 난이도 높음.
✅ 이메일 알림 : 가장 현실적인 구현 방법. 기술적 진입장벽 낮고, 단순한 텍스트/링크 포함 가능.
❗ 앱 설치 유도 기획 : 비용이 많이 들고 최신 트렌드에 부적합, 웹앱으로 유지하는 게 바람직함.
📨 2. 이메일 vs 카카오톡 메시지/챗봇
이메일
- 장점 : 구현 쉬움, 웹과 궁합 좋음
- 단점 : 메일 앱 알림 설정 필요, 노이즈/스팸으로 인식 가능
카카오 챗봇
- 장점 : 모바일 앱 설치 없이 알림 전송 가능, 사용자 경험 친숙
- 단점 : 카카오 디벨로퍼 등록, 채널 생성 및 정책 준수 필요전화번호 수집 등 민감정보 처리에 정책 허들이 존재
💬 3. 대체 구현 아이디어 및 조언
- 온보딩 시 카카오 챗봇 추가 유도 + 메시지 전송
: 현실성 있음, 기술 난이도는 낮고 정책 리서치가 관건 - 구글 캘린더 연동 → 일정 기반 알림
: 불가능에 가까움, 구글과의 제휴/API 인증 필요 - 프레이머 내 자체 캘린더 UI 구성
: 가능, 일정 직접 입력 + 저장은 구현 가능하나, 매력도와 우선순위 검토 필요 - 감정일기 기록 기능 외 기존 프로덕트의 기능 껍데기 구현 여부
: 자유롭게 결정 가능, 필수 아님, 단 껍데기 제공 시 개선 포인트 전달에 유리함
⚠️ 4. 프레이머는 웹앱이다: 팀 내 혼동 정리 필요
• 웹앱 : 브라우저 기반 접속, 설치 불필요 → 현재 프레이머가 만드는 것
• 앱(앱 어플리케이션): 앱스토어 설치 기반, 알림 구현 가능하지만 비용/난이도/정책 부담 큼
• → 웹앱 기준으로 접근해야 함 (모바일 브라우저 기준 UX)
"🗣PM이라면 앱 vs 웹 차이를 반드시 알고 있어야 한다. 팀원과 인식 정렬 필요”
🔧 5. MVP 개발 범위와 목표에 대한 리마인드
- 기능 범위 : 완성도보다 문제 정의와 설계 논리 중심. 껍데기만 구현해도 무방함.
- 구현 우선순위 : ‘지금 필요한 핵심 기능 중심’으로 구성. 기능 모두 구현할 필요 없음.
- 지표 기준 : 1차 MVP는 테스트용 → 정확한 지표보다 변화 방향과 개선 기반 확보가 중요
- 추천 접근 : 기능 구현 < 논리 설계 및 기획 근거. 발표 시 이를 강조하는 게 중요
🌌 저녁 스크럼 시간 재편성
우리 조는 오전 9:30에 아침 스크럼을, 오후 7:30에 저녁 스크럼을 했는데
그러다보니 저녁 튜터님께서 우리 조에 방문하시는 시간과 겹치게 되어, 조에서 얼라인되지 않은 내용을 튜터님 앞에서 발표를 해야하는 상황이 연속적으로 발생해서 조원들과 저녁 튜터님(우리의 이야기를 듣는 튜터님의 거친 생각과... 불안한 눈빛과...)의 동공지진을 볼 수 있었다.
그래서 오전 스크럼 시간은 그대로 두되, 저녁 스크럼 시간을 오후 7:30 -> 오후 5:00로 당겨서(특강이 있거나 조사가 미루어지는 등의 상황은 예외) 조에서 얼라인된 내용을 튜터님에게 이야기하고 피드백을 받을 수 있도록 하기로 했다.
💬 오늘의 회고
오늘 두 분의 튜터님과의 피드백을 통해, 아이디어가 아무리 매력적이어도 “현실적인 구현”과 “기술적 제약”을 고려하지 않으면 소용없다는 것을 체감했다.
우리가 하고자 했던 건 ‘사용자에게 맥락 기반의 맞춤 앱 기반 푸시 알림을 제공하여 사용 지속성을 높이는 것’이었지만, 인앱 푸시가 기술적으로 불가능하다는 사실 앞에서 방향을 틀 수밖에 없었다.
'사용자에게 이메일 알림이 나을 것인가, 카카오톡 알림이 나을 것인가'에 대한 니즈는 설문지를 돌리면서 확인해보기로 했다.
만약 이메일 알림이 압도적으로 니즈가 많다면 이메일 알림으로,
카카오톡 알림이 압도적으로 니즈가 많다면 카카오톡 알림으로 (물론 정책상의 이유로 불가능한 경우에는 이메일 알림으로 가야한다는 점에서 조원들 모두 동의했다),
그리고 만약 니즈가 반반으로 비슷하다면 한 그룹은 이메일 알림을, 다른 그룹에는 카카오톡 알림을 제공하여 A/B 테스트를 하는 방향도 있음을 확인했다.
MVP는 결국 완성도가 아니라, “기획 → 제약 → 재해석 → 실행”의 사이클을 어떻게 설득력 있게 끌고 가느냐의 싸움이라는 걸 오늘 배웠다.
앞으로 이 프로젝트가 어떻게 흘러갈지 굉장히 궁금해진다.
