[Day 122 TIL] 최종 프로젝트(9)

lemon·2026년 7월 16일

PM

목록 보기
46/59
post-thumbnail

2026년 7월 15일 수요일

  • 컨디션: 🙂 무난무난

📌 오늘 한 일

✅ 홍보를 위한 쪽지 작성
✅ posthog 지표 셋팅
✅ posthog 모니터링
✅ 긴급 배포
✅ UT 2건 진행


💬 데일리 스크럼

어제 오후 조퇴하고 나서 프로젝트에 신경을 많이 쓰지는 못했다... 오픈을 하긴 했는데 나도 그렇고 팀원들도 막 기뻐하지는 못한 느낌? 그리고 오픈 하고 나서 '허접mvp..', '디자인이 너무 구리다', '예상보다 너무 프로젝트가 못나와서 실망스럽다' 이런 이야기들이 많이 나와서 다들 본격적으로 사용하거나 홍보하지 않은 것 같은 느낌이 들었다(주관적임)

그래서 오늘 오전 스크럼에서 팀원들에게 이런 말을 전했다.

_'우리가 이렇게 앉아서 디자인 불평을 하는건 누구나 그냥 앉아서 할 수 있는 것이다. 나는 이 시간에 우리가 어떻게 버전2에서 디벨롭을 할것인지에 대해서 이야기 하는게 더 효율적이라고 생각한다. 우리가 우리 제품을 좋아하지 않으면 유저들도 다 안다. 어떤 사람이 나를 싫어하면 눈치채듯이, 우리가 우리 제품을 허접하다고, 별로라고 안좋아하면 유저도 느끼고 안쓴다. 우리가 우리 제품을 아끼고 좋아해야 겨우겨우 한명의 유저에게 닿을 수 있는거라고 생각한다. 그러니까 이제 우리가 쪽지도 쓰고 더 홍보하기 위해 노력해야 한다.'_ 라고 말씀을 드렸다. 그리고 모두 맞다고 동의하였고 나는 스크럼이 끝나고 모든 팀원들에게 칭찬 편지를 썼다. 이 서비스가 아니었으면 이렇게 감사하다는 말을 전할 수 있었을까?

나는 프로젝트의 결과가 우리의 실력, 그리고 우리의 결과라고 생각한다. 디자인이 허접한 것도 버그가 나는 것도 다 우리의 실력이다. 우리가 개발하지 않아도, 아이콘 이미지가 저화질이여서 허접해도 이건 다 우리의 실력과 결과다.

기획, 개발, 운영 기간이 짧았다는 것도 인지 했고, 앞에 시간이 많이 쓸수록 개발 퀄리티가 떨어지는 것은 당연한 것이다. 우리는 문제정의를 하는데 5일이라는 시간을 썼고, 개발은 단 4일 정도밖에 걸리지 않았다. 우리가 개발할 수 있는 시간을 정말 촉박하게 드린거였다. (4일이라고 쓰였지만 여기 개발 튜터님은 6개 프로젝트를 동시에 개발해서 사실상.. 개발시간이 거의 없었음ㅜ) 그걸 전부 감수하고 문제 정의를 한거고 그 촉박한 개발 시간에 대한 결과물을 받은 것이다.

쉽게 비유하자면.. 축구 32강 진출 못한 것은 그냥 우리나라 축구에 대한 결과인 것이다. 감독이 그렇게 된 걸 막지 못한 것, 유명한 축구 선수들이 목소리를 내지 않은 것,,, 그걸 그냥 보고 있는 사람들.. 그 모든 문제들이 합쳐져서 32강에 진출 못한 것이다.
그건 그냥 우리나라 축구 수준인거다. 유명하고 대단한 선수들이 있지만 축구는 개인전이 아니라 팀전인 것이다. 팀으로 합쳤을 때 시너지가 32강 진출 못한 것에 대한 결과인것이다.

우리도 뭐 좋은 대학교, 좋은 직업.. 좋은 집안 개인의 배경이 있을 수도 있지만 어쨌든 팀원끼리 만나서 나온 결과가 이 mvp이고 우린 이걸 받아들이고 더 좋은 프로젝트로 개발해야한다.

사기가 떨어질 수는 있지만 앉아서 불평하기 보다는 내가 할 수 있는 것들을 해야한다.


로그인 이탈로 메세지가 발송되지 않았다.

배포 후 데이터를 보다가, 친구 홈에서 쪽지를 다 쓰고 '보내기'를 눌렀는데도 실제로는 발송이 안 되는 사용자가 많다는 걸 발견했다. PostHog 퍼널에서 '보내기 버튼 → 발송 완료' 구간 이탈이 크게 나타났고, 데이터상 38명 정도가 이 지점에서 빠져나갔다...
;

🚨 원인 분석
우리 서비스는 '작성 후 로그인' 구조라, 보내기를 누르면 로그인을 해야 발송이 완료된다.
그런데 '보내기'라는 문구가 '완료' 느낌을 줘서, 사용자는 "이미 보냈다"고 착각한다.
그 상태에서 갑자기 로그인 화면이 뜨니까 → "어? 이미 보낸 거 아니야?" 하고 당황해서 이탈.
결국 받는 사람에게 쪽지가 전달되지 않는다.

👉 단순한 '로그인 허들'이 아니라 '보낸 줄 알았는데 안 간' 기대 불일치 가 진짜 원인이었다.

💡 해결안 (PM 튜터님과 논의 완료)
후보 두 가지를 놓고 트레이드오프를 따졌다.

  1. 진입 시 즉시 로그인: 보낸 줄 알았다는 혼란은 없으나, 쓰기 전에 이탈 위험 (진입장벽↑)
  2. 작성 후 로그인 유도 + CTA 문구 변경: 로그인 페이지 이탈은 줄지만, 안내가 명확해야 함

👉 메인 문제가 '착각'이므로 2번 채택. CTA 버튼을 "보내기" → "로그인하고 쪽지 보내기"로 변경.

📈 배포 후 데이터
너무 적은 데이터기는 하지만,, 배포 후 관찰 결과 이탈이 줄어들었다.. 아직 확정하기에는 그렇긴 함..

DB, PostHog timezone 셋팅

발송 건수를 볼 때 PostHog와 DB가 계속 달랐다. 원인을 하나씩 좁혔다.

  1. 동기화
  2. Timezone

결국 둘다 문제가 있었고, 지금 우리가 개발에 정확하게 손댈 수 없으니 posthog에서 할 수 있는 것 (이탈률, 퍼널)과 DB에서 볼 수 있는 것을 분리했다.

그리고 supabase랑 posthog 타임존이 둘다 utc라 따로 셋팅했다.

오늘까지 한 posthog 셋팅

  • 액션 6개 생성 (오토캡처 기반, selector+text+URL 조건)
  • 핵심 퍼널 2개: 친구 홈 발송 전환 퍼널 / 진입-작성 전환 퍼널
  • DB 카운터: 오늘·전체 가입자, 전체 발송량 (Supabase 연동 후 SQL)
  • 유입 경로 분석 (referrer 기준). $direct에는 카톡·인앱브라우저·복사링크 유입이 묶임 → 정확한 카톡 구분은 UTM 필요.
  • Supabase Data Warehouse 연동 (Session pooler = IPv4, 읽기 전용 권장)
  • 테스트 유저 제외 필터 (팀 계정 7개, is not으로 제외)
  • 배포 Annotation 준비

UT 후기

오늘은 UT를 두번 했다.
처음으로 UT를 직접 진행해봤는데, 생각보다 우리 앱이 정말 불친절하다는 걸 느꼈다. 확실히 직접 만든 사람과 처음 써보는 사람의 차이가 컸다. 우리는 "이렇게 하면 되지"라고 당연하게 생각했던 것들이, UT 참여자한테는 하나도 당연하지 않았다....

로그인 이탈 문제도 그렇고 직접 앱을 만들다보면 너무 익숙해져서 당연하다고 생각하는 것을 놓치게 되는 것 같다....

그치만 생각보다 UT 참여자분들께서 쪽지를 나누면서 좋아하는 모습을 보고 좀 뿌듯했고 다른 팀원들도 살짝 의욕이 없다가, 앱을 진심으로 사용해주는 유저를 만난 이후 뿌듯해졌다고 말해주어서 확실히 유저를 직접 만나는 것과 만나지 않은 것의 차이가 크다고 느꼈다.

회고

  • 잘한 것: 모니터링을 꼼꼼히 하고 유저 이탈 원인을 분석하고 바로 개발에 반영한 것(문제를 감이 아니라 데이터(퍼널 이탈)로 발견하고, 해결안을 트레이드오프로 정리해서 튜터님과 논의한 것.)

  • 다음에 챙길 것: CTA 문구 변경 후 이탈률이 실제로 줄었는지 재측정 — "문제 발견 → 원인 분석 → 해결 → 개선 후 지표 확인"의 마지막 조각을 완성해야 한다.

  • 다음에 챙길 것: UT용 코호트 설정

profile
나는야 핵심을 찌르는 사람

0개의 댓글