TIL 2026.07.01 (수) - 드디어 유저 플로우 확정

컨디션: 잠을 많이 못자서 수면 부족 🤑

📌 오늘 한 일

• 구구레터(전해조) MVP 범위 및 유저 플로우 정의 회의 진행
• MVP 핵심 플로우 확정: 카드 작성 → 로그인 → 발송 → 쪽지 열람
• 유저 플로우를 수신자 / 발신자(회원 대상·비회원 대상)로 분리하여 정리
• 서비스 용어 통일: 메시지 단위는 "쪽지", 페이지 용어는 설정 페이지 / 나의 홈화면 / 상대방의 홈화면으로 정리
• 기능 우선순위를 P0(개발 최소 기능) ~ P1(V1 배포 목표) 기준으로 구분 제안

💡 오늘 배운 것

1. 결국 유저플로우 범위는 유저 설문 전이나 후나 같았다

며칠 전 TIL에 "설문 결과가 나와야 플로우를 정할 수 있다는 말이 이해가 안 간다. 왜 모르겠다는 건지 나도 잘 모르겠다." 🤣

오늘 팀원들과 유저 플로우를 처음부터 같이 그렸다. 그리고 완성된 플로우는 내가 기존에 미리 만들어뒀던 플로우와 똑같았다. 설문 전이든 후든, 발신자 중심이든 수신자 니즈를 반영하든, "쪽지를 작성하고 → 전달하고 → 읽는다"는 뼈대는 변하지 않았다.

편하게 비유하면 이렇다. 저글링을 하면서 편지를 보내든, 그냥 편지를 보내든 "편지를 보낸다"는 사실은 똑같다. 설문 결과가 바꾸는 건 저글링(온보딩 문구, 톤, 부가 기능)이지, 편지를 보낸다는 본질이 아니다. 디자인 튜터님이 말씀하신 "타깃이 바뀌어도 유지될 기능부터 잡아라"가 정확히 이 뜻이었다.

그런데 오늘의 더 큰 배움은 따로 있다. 어제 나는 이 결론을 문서로 남겼지만 팀원들은 이해하지 못했다. 오늘 팀원들이 이해한 건 내가 더 잘 설명해서가 아니라, 직접 플로우를 그려보는 과정을 함께 통과했기 때문이다. 그리다 보니 "어? 어떻게 그려도 이 뼈대네?"를 스스로 발견한 것이다.

2. MVP 범위는 "검증하려는 가설"이 기준이 된다

기능을 넣을지 뺄지 논의할 때 계속 흔들리다가, "우리가 검증하려는 핵심 가설이 뭐지?"로 돌아오니 정리가 빨라졌다. 우리 가설은 발신 허들 감소다. 그래서:

• 답장 기능 → 가설 검증과 직접 관련이 낮아 MVP 제외 (P2 이후)
• 문구 가이드 → 빈 화면이 곧 발신 허들이므로 최소 수준(Lv.1)으로 P0 포함

같은 "있으면 좋은 기능"이라도 가설과의 거리로 판단하면 논쟁이 아니라 기준의 문제가 된다.

2. 유저 플로우는 진입 경로에 따라 분기해야 한다

처음엔 하나의 플로우로 그리려 했는데, 링크로 진입하는 유저와 서비스에 직접 진입하는 유저는 로그인 시점과 다음 액션이 완전히 다르다. 수신자/발신자 각각, 그리고 발신자는 다시 "회원에게 보내는 경우 / 비회원에게 먼저 보내는 경우"로 나눠 총 4개의 플로우로 정리했다. 플로우를 쪼개니 로그인 체크 시점 같은 엣지 케이스가 자연스럽게 드러났다.

3. 운영 관점은 기능 정의 단계부터 들어가야 한다

부적절한 쪽지에 대한 신고 기능을 이야기하면서, 신고를 "받는" 것만이 아니라 신고 이후 누가 어떻게 처리하는지(쪽지 숨기기, 운영 이메일)까지 함께 정의해야 한다는 걸 확인했다. 구현이 어려우면 슬랙 알림 기반 수동 운영으로 대체하는 백업 플랜도 세웠다. 기능 = 화면이 아니라 기능 = 화면 + 운영 프로세스.

오후에는 일정이 있어서 아침부터 오후 3시까지 유저 플로우를 논의했다. 🤣

TIL 2026.07.02 (목) — 기능 명세서와 화면 명세서 작성

• 구구레터 기능/화면 정의 회의 진행 및 회의록 작성
• 프로필/닉네임, 알림, 상태 메시지, 공유, 로그인 타이밍 등 화면 단위 세부 정책 결정
• 산출물 우선순위 확정: 기능명세서 완료 → 화면 정의 → UI 디벨롭

💡 오늘 배운 것

1. 산출물은 기능 명세서부터

화면 정의를 하려면 기능명세서의 넘버링·상태 정의가 먼저 필요하다.

"기능명세서 완료 → 와이어프레임 -> 화면 정의 → UI 디벨롭"으로 우선순위를 명확히 했다.

TIL 2026.07.03 (금) — 티켓 관리를.. 잘 하자.. 🥲

• 컨디션: 그럭저럭..

📌 오늘 한 일

• 구구레터 PRD v2.0을 거의 최종본 수준까지 혼자 작성 완료 (금요일 오전 ~ 자정)
• 디자인 튜터님 1:1 피드백 세션 (16:30~17:10) 및 회의록 작성
• 튜터님 피드백 기반으로 홈 화면 구조·CTA 개선 방향 정리, 팀 공유 및 반영 범위 결정
• 문제 정의 재구조화: "수신 욕구"와 "발신 행동" 분리
• 핵심 KPI 수정: 친구 홈 진입 대비 쪽지 발송 완료율
• 직접 쪽지 발신형을 P1 보조 흐름으로 분리, 타깃 정의를 "모집 범위 vs 검증 대상"으로 이원화
• 리텐션 지표를 핵심 KPI에서 보조 지표로 재배치

💡 오늘 배운 것

1. 사용자의 기대를 배신하는 UI는 없느니만 못하다

알림 아이콘이 있으면 사용자는 "별도 알림함"을 기대한다. 그런데 실제로는 받은 쪽지 목록으로 연결된다면? 기대와 결과가 어긋나며 혼란만 생긴다. 그래서 알림 페이지 자체를 제거하고 받은/보낸 쪽지 리스트 내 표시로 대체했다.

2. 로그인 타이밍은 허들과 기술 리스크의 트레이드오프

친구 홈에 진입한 비로그인 사용자에게 처음부터 로그인을 요구하면 이탈 가능성이 높다. 그래서 "작성 후 로그인" 흐름을 제안했고 팀 결론으로 채택됐다. 다만 이 선택에는 비용이 따른다 — 작성 내용 임시 저장 로직이 필요하고, 브라우저를 닫으면 내용이 날아갈 수 있는 기술 리스크가 있다. UX 개선 결정은 공짜가 아니며, 반드시 기술 검증(튜터 확인)과 세트로 움직여야 한다.

3. 플로우는 "끊는 지점"도 설계해야 한다

미리보기 화면에서 바로 OS 공유 시트를 띄우면, 사용자가 외부 앱으로 이탈했다가 돌아왔을 때 여전히 미리보기 화면에 남아 복귀 경로가 어색해진다. 그래서 쪽지 보내기 → 저장 → 완료 화면으로 흐름을 명시적으로 끊기로 했다. 해피 패스만 그리는 게 아니라, 사용자가 중간에 나갔다 돌아오는 경우까지 고려한 상태 설계가 필요하다.

4. 간소화의 기준: 뎁스를 늘릴 가치가 있는가

오늘 내린 결정들에는 공통 기준이 있었다.

• 상태 메시지 수정: 별도 페이지/모달 대신 홈 화면 인라인 수정 (연필 아이콘)
• 쪽지함 공유: 별도 공유 페이지 대신 OS 공유 시트 or 링크 복사 + 토스트
• 프로필 사진 업로드: 갤러리 접근·이미지 저장 공수 대비 MVP 검증 기여가 낮아 제외
• 이모지 반응: 복수 선택은 UI·정책 복잡도가 커져 1개만 선택

전부 "이 기능을 위해 화면 뎁스나 개발 공수를 늘릴 가치가 있는가"라는 질문으로 수렴한다. MVP에서는 기본값이 '간소화'이고, 뎁스 추가가 예외여야 한다.

😔 오늘 있었던 일

기획/기능 명세서 제출 마감일
나는 크로스 체크를 위해 티켓마다 정/부 담당을 두는 시스템을 만들어뒀었다. 한 명이 놓쳐도 다른 한 명이 잡아줄 거라고 믿었다.

그런데 이번 주 PRD 담당 팀원들의 조퇴와 결석이 겹쳤고, 나도 마감 일정에 쫓겨 작업하다 보니 PRD 문서가 완료되지 않았다는 사실을 제출 직전까지 확인하지 못했다.

결국 금요일 밤, 혼자 자정까지 PRD를 작성했다...

다음부터는

• 마감 D-1에 산출물 상태를 확인하는 고정 체크포인트를 넣는다. 사람이 기억하는 게 아니라 일정에 박아둔다.
• 데일리 스크럼에서 "누가 무엇을 한다"만이 아니라 "제출물 기준으로 지금 몇 %인가"를 묻는다.
• 조퇴·결석 발생 시 그 사람의 정/부 티켓을 당일 재배정하는 규칙을 만든다.

💡 그래도, PRD를 다시 쓰며 배운 것

그래도 내가 작성한 김에 제대로 썼다.
PRD v2.0을 다듬으면서 확실해진 것: PRD는 기능 설명서가 아니라, 검증 논리를 정렬하는 문서다.

1. 문제 정의: 넓은 현상을 좁은 검증 단위로

처음 문제 정의는 "좋은 말을 받고 싶은 욕구가 있다"에서 출발했다. 하지만 이건 배경 근거일 뿐, MVP가 직접 검증할 문제가 아니었다. 좋은 말을 받고 싶은 마음은 혼자 충족될 수 없다 — 누군가 실제로 쪽지를 작성하고 발송해야 서비스 가치가 생긴다.

그래서 이렇게 좁혔다.
가까운 관계에서 마음을 표현하고 싶지만, "지금 말해도 된다"는 계기와 명분이 부족해 표현을 주저하거나 축소하게 되는 문제

마음 표현이 어렵다
→ 가까운 관계에서 표현을 주저하거나 축소한다
→ 그중 이번 MVP는 '표현을 시작할 계기와 명분 부족'을 본다
→ 공유된 친구 홈이 그 계기와 명분으로 작동하는지 검증한다

2. KPI는 "무엇이 작동했는지"를 보여줘야 한다

이전에는 주간 메시지 발송 완료 수, 작성 시작 대비 발송 완료율로 되어있었다. 하지만 검증하려는 건 "쪽지를 잘 보냈는가"가 아니라 공유된 친구 홈이 방문자에게 '지금 쪽지를 남겨도 된다'는 계기로 작동했는가다.

핵심 KPI: 친구 홈 진입 대비 쪽지 발송 완료율

3. 핵심 흐름은 하나여야 한다

홈 링크 공유형과 직접 쪽지 발신형을 모두 MVP에 넣으려다 보니 문서가 복잡해졌다. 읽는 사람은 "핵심 검증 흐름이 두 개인가?"라고 느낄 수 있었다.

• 홈 링크 공유형: 1차 MVP 핵심 검증 흐름

• 직접 쪽지 발신형: 개발 여유가 있을 경우 구현하는 P1 보조 흐름

직접 발신형은구현되지 않아도 핵심 가설 검증에 영향이 없다고 명시했다. 이렇게 정리하니 MVP의 중심이 다시 선명해졌다.

4. 타깃: 인구통계와 문제 속성을 분리한다

"핵심 타깃은 관계·맥락 기준"이라 쓰면서 동시에 "20~30대"라고 적으면 읽는 사람이 헷갈린다.

1차 모집 범위는 20~30대, 실제 검증 대상은 그중 가까운 친구에게 마음을 전하고 싶지만 표현을 주저하거나 축소해서 표현한 경험이 있는 사용자

20~30대는 문제를 가장 크게 겪는 집단이어서가 아니라, 초기 모집과 검증이 가능한 범위라는 점도 명확히 했다.

5. 수치가 있다고 목표값이 되는 건 아니다

예전 PRD에는 발송 완료율 50%, 2회 이상 전송 유저 30% 같은 목표값이 있었다. 하지만 기존 데이터가 없는 상태의 목표값은 근거 없는 숫자이고, 오히려 문서의 신뢰도를 떨어뜨린다.

1차 MVP에서 중요한 건 목표값이 아니라 기준값(baseline)을 만드는 것이다. 리텐션 지표(서로 다른 날짜에 2회 이상 발송한 사용자 비율)는 버리기 아까워서 보조 지표로 남기되, 목표값 없이 1차 배포 데이터를 v2 비교 기준으로 삼기로 했다.

오늘의 결론

PRD는 기능을 많이 설명하는 문서가 아니라, 팀이 같은 질문을 보게 만드는 문서이기도 하는구나 라고 배웠다.

• 우리는 어떤 문제를 보고 있는가?
• 그 문제를 어떤 행동으로 검증할 것인가?
• 어떤 기능은 지금 필요하고, 어떤 기능은 후속으로 미뤄야 하는가?
• 어떤 지표를 보면 이 가설이 맞았는지 판단할 수 있는가?

그리고 하나 더. 좋은 문서를 만드는 것만큼, 문서가 제때 완성되게 하는 운영도 PM의 일이다.