[Day 115 TIL ~ Day 117] 최종 프로젝트(7) - posthog 공부, 특강,UT 계획, 브로셔 작성, 1차 결과물 받고 QA

lemon·2026년 7월 9일

PM

목록 보기
44/59
post-thumbnail

2026년 7월 8일 수요일

  • 컨디션: 평일 12시간 공부, 몇개월동안 지속하다보니 햄스트링과 엉덩이가 너무 아프다.. 그래서 하체 혈액순환이 잘안되는 것 같다. 내일 찜질방이나 한의원에 가야겠다.. 🥲

📌 오늘 한 일

✅ Y튜터님 PM 실무 특강 수강 (기획부터 배포까지 전체 프로세스) + 강의자료 정리
✅ PostHog 학습 + 팀 공유 문서 작성
✅ 구구레터 조직 생성 및 팀원 초대, 코호트·메뉴 구조 답사

💡 오늘 배운 것

1. 특강: PM은 "무엇을"보다 "왜"를 먼저 정의하는 사람

특강의 뼈대는 기획 프로세스 8단계(문제 정의 → 요구사항 → 화면 설계 → 디자인 협업 → 개발 → QA → 배포 → 배포 후 분석)였다. 그런데 반복해서 강조된 메시지는 단계 자체가 아니라 태도였다.

문제 정의가 흐리면 이후 기획·디자인·개발·QA·배포까지 모두 흔들린다.

이 문장을 듣는데 지난주가 생각났다. 우리 팀이 6/25에 주제를 뒤집고 6/30에 유저 플로우가 막혔던 것,
결국 문제 정의(정확히는 공감대)가 제대로 되지 않은 상태로 다음 단계에 넘어갔기 때문이었다.

그리고 7/3에 PRD를 다시 쓰면서 기능·KPI가 정렬됐던 것도 말해주신 문제와 같았다. 이미 겪은 것을 말로 특강으로 들어오니 정리가 되었다.

(이런 상황이 되면 문제정의를 뭐.. 미리 해야했던걸까.. ? 그렇다고 해서 다같이 문제정의를 할 수는 없는데,, 하)

특강에서 가장 마음에 남은 세 가지:
1. "왜"를 계속 물어보자

  • "위에서 하라고 해서요"는 수동적 실행자의 말이다.
  • 왜 이 기능인지, 진짜 문제인지, 어떤 지표를 바꾸는지 계속 물어야 한다.

2 요구사항을 직접 구체화하자

  • 문제를 듣고 전달만 하면 부족하다.
  • 기능 범위·정책·예외 케이스·화면 흐름·MVP 범위로 직접 바꿀 수 있어야 한다.
  1. 내 일인지 애매하면 챙기자
  • QA 케이스, CS 가이드, 배포 커뮤니케이션, 정책 충돌 확인, 개발 중 예외 답변…
  • 주니어 PM은 일단 챙기는 태도가 신뢰를 만든다.

특히 배포 관련해서 지금까지 안 챙기던 걸 알게 됐다. CS 가이드와 롤백 기준이다. "이 기능 뭐예요?", "기존 기능 어디 갔어요?" 같은 예상 질문을 미리 정리해 두는 것, 그리고 "어떤 문제가 생기면 되돌릴 것인가"를 배포 전에 정해두는 것.

2026년 7월 9일 목요일 (조퇴)

  • 컨디션: 혈액순환이 너무 안되어서 결국 오후에 병원갔음 🥲

📌 오늘 한 일

✅ PRD + 기능명세서 일치 생각보다 오래걸렸다.
✅ 개발 튜터님에게 누락건 말씀드리기
✅ 오후 조퇴

2026년 7월 10일 금

  • 컨디션: 그럭저럭 항상 졸려

📌 오늘 한 일

✅ UT 리뷰
✅ 브로셔 최종 확인
✅ PRD + 기능명세서 일치
✅ 개발 1차 결과물 받기
✅ 정책서 작성
✅ QA

💡 오늘 배운 것

1. 최종확인은 내 눈으로 꼭 할 것,,

이번에 브로셔를 오전에 최종 확인하면서, 중복으로 작성된 부분이 있었다. A팀원에게 며칠 전부터 계속 내가 수정해달라고 했는데, 최종날이 되어서야 반영이 되었다. '그냥 이 부분은 지우면 되니까..'라고 말하셨지만, (지난번 PRD도 맡겼다가 마지막날 작성이 안되어서 혼자 밤까지 작업을 했었..다..)
최종 문서는 항상 내가 꼼꼼히 확인하는 습관이 생겼다. 어제 분명 팀원들에게 꼭꼭! 완료해달라고 부탁했지만, 이상 없다고 보고 받았다. 근데 중복 부분이 있었고,, 🥲

나는 내가 꼼꼼한 편이 아니라고 생각했다. 항상 물건을 깜빡하고, 커피를 쏟고 그랬는데, 여기 와서 내가 되게 꼼꼼한 편이라는걸 알았다! 좋은게 좋은거지.!~

2. 정책서 작성

브로셔 문서에 정책이 있어서 한번 러프하게 작성해보았다. 연령, 개인정보, 등등.. 이런것들은 사이드프로젝트 단계에서 어떻게 작성해야하는지 튜터님께 여쭤보았고, 답변이 왔지만, QA를 진행하느라 아직 확인하지 못했다. 🤨 일요일에 확인하고 정리해야지

3. QA 진행 엣지케이스는 어떻게 QA 하지?!

  • API 조회 실패, 404("찾을 수 없음") 같은 에러 케이스를 어떻게 재현해야할지 고민하다가 API만 Block하는 방법으로 진행했다. 굿!

  • 팀원들한테 QA 하는 방법을 알려줬다. 진짜 실무처럼 알려드렸다. 실무는 정말 상세하게 작성해야하고, 개발자, 기획자가 이 QA만 보고도 무슨 에러인지 파악할 수 있어야한다고 했다.

4. QA 진행할 때는 진짜 DB없이 어떻게 하지.. ?

이번에 QA를 진행하는데 아무래도 로그인<->탈퇴를 계속 해야해서 튜터님이 팀원들한테 알려주셨는데, 이게 하위테이블이랑 다 연관되어있어서 ;; 개발자가 아니면 절대 찾을 수 없는 에러였다.. ;;;

왜 DB 연결이.. 거꾸로 되어있지..?

✅ 일요일에 할 일

  • posthog 실습 & 셋팅

✅ 월요일에 할 일

  • 화요일 오후 조퇴로 정정하기
  • 할 일 정리 & 티켓 정리
  • PRD 3.0, 기능명세서 2.0 작성
profile
나는야 핵심을 찌르는 사람

0개의 댓글