[2026년 07월 28일] 최종 프로젝트 (17)

컨디션: 두통이 너무너무 심했다

오늘 한 일

✅ 자동화 파이프라인 튜터님 피드백 반영
✅ 유저 cs 답장
✅ v2 2차 운영 데이터 분석
✅ v1~v1.1 1차 운영 데이터 분석 정리
✅ 최종 브로셔 작성 (진행중)
✅ v1.0·v1.1·v2.0 지표 분석 및 이벤트 트래킹 개선안 도출
✅ 운영 자동화는 무엇으로 성과를 판단해야 할까
✅ 2차 UT 진행 (내일 정리할 것)

---

지표 하나를 확인하는 데 왜 이렇게 오래 걸릴까

오늘 데이터를 정리하면서 예상보다 많은 시간이 들었다.

처음에는 확인하고 싶은 지표가 있으면 PostHog에서 퍼널 하나를 만들거나,
Supabase에서 쿼리 하나를 작성하면 된다고 생각했다.
하지만 실제로는 그보다 훨씬 많은 과정이 필요했다.

확인하려는 제품 질문 정의
→ 필요한 사용자 행동 확인
→ PostHog Action 생성
→ 이벤트가 제대로 수집되는지 검증
→ 퍼널 구성
→ 버전별로 달라진 Action 연결
→ 분석 기간 구분
→ 테스트 사용자 제외
→ Supabase 테이블 관계 확인
→ 필요한 쿼리 작성
→ PostHog와 실제 데이터 비교

서비스가 v1.0에서 v1.1, v2.0으로 바뀌면서
같은 행동을 나타내는 버튼과 이벤트도 달라졌다.
기존 퍼널에서 버전별 행동을 비교하려면 Action을 다시 만들고 합쳐야 했고,
각 버전의 운영 기간도 별도로 나눠야 했다.

Supabase에서도 지표마다 쿼리 하나만 필요한 것은 아니었다.
분자와 분모를 각각 구해야 했고,
전달 방식이나 로그인 여부에 따라 여러 테이블의 관계도 확인해야 했다.

오래 걸린 이유는 단순히 데이터 도구가 어려워서가 아니었다.
서로 다른 시기에, 서로 다른 방식으로 수집된 데이터를
비교 가능한 기준으로 다시 맞추는 작업이 필요했기 때문이다.

---

지표는 배포 후에 찾는 것이 아니라 기획할 때 설계해야 한다

PostHog Toolbar를 이용하면 개발 작업 없이도
버튼 행동을 Action으로 정의할 수 있다.
빠르게 데이터를 확인하고, 놓친 데이터를 볼 때는 편리하지만,
화면 구조나 버튼이 변경되면
동일한 행동을 안정적으로 비교하기 어렵다는 한계가 있었다.

결국 가장 깔끔한 방식은 기능 기획 단계에서 측정할 행동을 정의하고,
개발자에게 명시적인 이벤트를 요청하는 것이다.

예를 들어 버전마다 서로 다른 이벤트를 만드는 대신,
동일한 행동은 같은 이벤트명으로 유지하고 달라지는 조건을 속성으로 구분할 수 있다.

event: letter_write_start

properties
- flow_version: v1.0 / v1.1 / v2.0
- entry_type: friend_home / my_home
- login_status: logged_in / logged_out
- delivery_type: direct / link

이렇게 설계했다면 버전이 바뀔 때마다
Action과 퍼널을 다시 조합하는 비용을 줄일 수 있었을 것이다.

---

자동화의 성과는 기능 개수가 아니었다

구구레터에는 신규 회원가입, 쪽지 작성, 신고 접수,
유해 쪽지 탐지와 일일 운영 지표를 Slack으로 전달하는 자동화 기능이 있다.

처음에는 이런 자동화 기능을 구현했다는 사실 자체가 성과라고 생각했다.
하지만 튜터님 피드백을 통해 자동화의 성과는 기능의 개수가 아니라,
기존 운영 업무를 얼마나 줄였는지로 설명해야 한다는 점을 알게 됐다.

예를 들어 유해 쪽지 알림의 가치는 Slack 메시지를 만들었다는 데 있지 않다.

기존에는 문제가 발생해도 운영자가 DB를 직접 확인하거나
사용자의 신고를 기다려야 했다.
탐지 웹훅을 적용하면 조건에 해당하는 쪽지가 발생했을 때
운영자가 먼저 알림을 받고, 필요한 건만 확인할 수 있다.

전체 데이터를 직접 확인
→ 조건에 해당하는 건 자동 탐지
→ 운영자는 탐지된 건의 맥락만 확인
→ 숨김 여부는 사람이 판단

자동화의 효과를 확인하려면 다음과 같은 지표가 필요하다.

• 문제 발생부터 운영자 인지까지 걸린 시간
• 알림 이후 조치까지 걸린 시간
• 운영자가 DB를 직접 조회한 횟수
• 일일 지표를 수집하고 공유하는 데 드는 시간
• 반복 업무의 단계와 수작업 횟수
• 미확인·누락 건수
• 과탐과 미탐 건수

---

과거의 어드민 경험도 다시 보였다

이 내용을 정리하다 보니 이전 회사에서 신고 어드민과
신고 내용 추적 대시보드를 개선했던 경험이 떠올랐다.

당시에는 신고 기능과 대시보드가 제대로 작동하지 않아
운영자가 신고 내용을 확인하고 당시 상황을 추적하기 어려웠다.
이를 개선해 신고 데이터와 관련 사용자·콘텐츠 맥락을 확인할 수 있는 구조를 만들었다.

하지만 그때는 기능 구현과 정상 동작 여부에만 집중했다.
신고 확인 시간이 얼마나 줄었는지, 운영자가 몇 개의 화면을 오가야 했는지,
DB 직접 조회가 얼마나 감소했는지는 측정하지 않았다.

그래서 실제 운영 흐름은 달라졌지만, 이 경험을 다음과 같이밖에 설명하지 못했다.

신고 어드민과 대시보드를 개발했다.

지금 관점에서 보면 핵심은 달랐다.

정상적으로 작동하지 않던 신고 흐름을 보완하고, 운영자가 신고 당시의 콘텐츠와 사용자 맥락을 추적해 판단할 수 있도록 운영 구조를 개선했다.

다만 정량적 개선 폭은 측정하지 못했기 때문에,
처리 시간이 몇 퍼센트 줄었다는 식의 표현은 사용할 수 없다.

앞으로 운영 자동화를 기획할 때는
기능 요구사항보다 먼저 현재의 운영 흐름을 기록해야겠다.

현재 업무 단계와 소요 시간 측정
→ 자동화 목표 정의
→ 기능 구현
→ 같은 기준으로 다시 측정
→ 도입 전후 효과 비교