티스토리 뷰
오늘 컨디션: 보통 🙂
오늘 한 일
✅ posthog 셋팅 방법, 지표 보는 방법, 지표 셋팅 방법, db 조회 방법 팀원들에게 공유
✅ 면접 특강 듣기
✅ PRD 3.0 작성을 위한 데이터 분석
✅ PRD 3.0 작성을 위한 데이터 분석을 위한 버전2 posthog 지표 셋팅
✅ 버전2 QA 진행
PostHog 사용법 공유
어제 퇴실 전 팀원들이 PostHog 사용법과 데이터를 확인하는 방법을 물어봤다.
PostHog와 관련해 공부한 내용은 Figma와 Notion에 상세히 정리해두었고, 팀원들에게도 이미 접근 권한이 부여되어 있었다. 그래서 처음에는 무엇을 추가로 설명해야 할지 조금 난감했다.
별도의 발표 자료를 다시 만들기보다는, 팀원들이 궁금한 부분을 질문하면 실제 화면을 함께 보면서 답하는 방식으로 진행했다.
이번 경험을 통해 문서를 남겨두는 것과 팀원이 실제 도구를 사용할 수 있게 만드는 것은 다른 일이라는 점을 느꼈다. 문서가 충분히 상세하더라도, 처음 사용하는 사람에게는 어떤 메뉴부터 봐야 하는지, 지표를 어떻게 해석해야 하는지에 대한 시작점이 필요할 수 있다.
내가 먼저 공부한 내용을 팀원들에게 설명할 수 있었다는 점은 좋았다.
면접 특강
오늘 면접 특강에서는 한 수강생이 미리 촬영한 면접 영상을 함께 보며 피드백을 나눴다.
다른 수강생의 영상이다 보니 부족한 부분을 직접 이야기하는 것이 조심스러웠지만, 실제 영상을 보면서 면접자의 시선, 자세, 표정, 답변 전달 방식이 어떻게 보이는지 구체적으로 확인할 수 있었다.
말로만 면접 연습을 하는 것보다 영상을 촬영하면 내가 인지하지 못했던 습관을 객관적으로 확인할 수 있다는 점이 인상적이었다. 나도 면접 영상을 촬영한 뒤 답변 내용뿐 아니라 말의 속도, 시선 처리, 불필요한 움직임을 함께 점검해야겠다.
QA 2차 진행
개발 결과물이 예상보다 빠르게 반영되어 2차 QA를 진행했다.
이번에는 팀원들이 함께 QA를 진행해 비교적 빠르게 확인을 마칠 수 있었다. 혼자 전체 기능을 점검하는 것보다 기능과 화면을 나눠 확인하니 속도가 빨랐고, 서로 다른 관점에서 오류를 확인할 수 있었다.
확실히 팀원들도 기능 명세서 작성하는 스킬이 늘어서 이번 QA 건은 총 4개정도 나왔다.
PostHog 지표 재설정
PostHog 지표 설정은 예상보다 쉽지 않았다.
현재는 이벤트를 코드에 명확히 심기보다 HTML 태그, 버튼 텍스트, URL 조건을 조합해 액션을 정의하고 있다. 이 때문에 액션이 정확히 잡히지 않는 경우가 있었고, 버튼 문구가 변경되면 기존 지표 조건도 다시 수정해야 했다.
이전 버전과 현재 버전의 성과를 비교하려면 각 버전의 지표를 동일한 기준으로 구성해야 한다. 하지만 초기에 KPI를 잘못 이해해 일부 퍼널을 잘못 설정해둔 상태였다.
이를 수정하기 위해 세션 리플레이를 하나씩 확인하면서 실제 사용자 행동과 페이지 이동 경로를 다시 추적했다. 그 결과 버전 1과 버전 1.5의 주요 지표를 다시 설정했고, 내일은 버전 2.0 지표까지 구성할 예정이다.
이번 작업을 통해 자동으로 수집된 데이터가 있다고 해서 바로 신뢰할 수 있는 지표가 만들어지는 것은 아니라는 점을 배웠다.
지표를 보기 전에는 다음 내용을 먼저 확인해야 한다.
- 측정하려는 행동을 정확히 정의했는가
- 각 버전에서 동일한 기준으로 측정하고 있는가
- 설정한 조건이 실제 사용자 행동을 제대로 포함하고 있는가
- 세션 리플레이나 원본 데이터로 지표를 검증했는가
데이터가 전혀 없는 것보다는 이미 쌓인 데이터를 바탕으로 지표를 재설정할 수 있다는 점은 다행이었다. 다만 처음부터 측정 기준을 명확히 정했다면 다시 확인하는 시간을 줄일 수 있었을 것이다.
또한 기존 PRD에는 실제 의사결정에 필요하지 않은 지표도 일부 포함되어 있었다. PRD 3.0에서는 수집할 수 있는 지표를 많이 나열하기보다, 어떤 판단을 내리기 위해 이 지표가 필요한지를 먼저 생각해 작성해야겠다.
팀장 역할과 업무 분배
오늘도 PRD 작성에 필요한 업무를 팀원들에게 나눠드렸다.
이번 PRD에는 UT 인사이트, 서비스 후속 과제, 데이터 지표 등 여러 내용이 포함되어 있어 혼자 작성하는 것보다 독립적으로 진행할 수 있는 단위로 업무를 나누는 것이 효율적이라고 판단했다.
UT 인사이트와 서비스 후속 과제처럼 각자 자료를 보고 정리할 수 있는 부분은 담당자를 나눠 진행하도록 했다.
업무를 분배할 때는 단순히 일을 나누는 것보다, 어떤 작업은 독립적으로 진행할 수 있고 어떤 작업은 기준을 먼저 맞춰야 하는지 구분하는 것이 중요하다는 점을 다시 느꼈다.
'TIL > 2026 부트캠프' 카테고리의 다른 글
| [2026년 07월 26일] 이력서 & 면접 영상 찍기 (0) | 2026.10.03 |
|---|---|
| [2026년 7월 25일] 최종프로젝트 (15) (0) | 2026.10.03 |
| [2026년 7월 23일] 최종 프로젝트(14) (0) | 2026.10.03 |
| [2026년 7월 21일] 최종프로젝트(12) (0) | 2026.10.03 |
| [2026년 7월 20일] 최종프로젝트(11) (0) | 2026.10.03 |
- Total
- Today
- Yesterday
- 인스턴스
- ORACLE MERGE INTO 동일테이블
- npm이란
- merge into 단일테이블
- package.json
- 개발자퇴사
- 백준
- 신입사원개발자
- 단일쿼리문
- java1.7 다운
- ORACLE MERGE INTO 같은테이블
- C++
- merge into using dual
- jdk 이전버전 다운
- ORACLE MERGE INTO USING DUAL
- npm init
- Java
- merge into
- 자바
- 개발자
- 파이썬
- 신입개발자퇴사
- 알고리즘
- 초보개발자
- jdk1.7 다운
- ORACLE 단일테이블
- 신입사원
- merge into 같은 테이블
- 백준알고리즘
- merge into using
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 31 |
