본문 바로가기
서비스기획 및 PO & PM

[스타트업에서 초보 PO가 겪는 10가지 상황] 9. 디버깅은 PO가 하게 돼요

by 쭈~~울 2025. 5. 9.
반응형

9. 디버깅은 PO가 하게 돼요

💬 “테스트는 QA가 한다고 했잖아요…”

(그런데 왜 또 내가 다 보고 있지?)

 


📍 상황 예시

PO 데이븐은 “사용자 맞춤 알림 설정” 기능을 출시했다.

기획도 잘 되었고, 디자인도 깔끔했고,

개발팀도 일정 맞춰 작업을 끝냈다.

 

QA팀은 테스트를 마쳤다고 했고,

릴리즈도 무사히 진행됐다.

 

그런데 다음날부터 사용자 피드백이 쏟아졌다:

  • “푸시 설정했는데 알림이 안 와요”
  • “초기 설정값이 이상해요”
  • “이벤트 알림은 되는데 나머진 안 돼요”

결국 데이브는 직접 디버깅에 돌입한다.

테스트 기기를 바꿔가며

시나리오를 수십 번씩 돌려보는 자신을 보며 문득 생각했다:

“QA는 뭐 했지? 왜 또 내가 다 하고 있지?”

 


🔍 왜 이런 문제가 생길까?

디버깅은 PO의 일이 아니지만,

현실에선 자주 PO가 맡게 된다.

문제 설명
QA와 PO 역할 경계 모호 범위가 명확하지 않음
실제 사용자 흐름 미반영 테스트 시나리오 부족
예외/경계 케이스 누락 사용자 상황 다양성 간과
QA 인력 부족 PO가 대신 책임지는 구조

🧠 이렇게 풀 수 있어요

✅ 1. QA는 기능을, PO는 ’경험’을 본다

QA는 명세 기반 체크,

PO는 사용자 관점 흐름 확인.

  • QA: “작동 여부 확인”
  • PO: “전체 맥락에서의 경험 확인”

✅ 2. PO 디버깅은 ’설계의 연장선’이다

디버깅은

“문제를 잡는 과정”이 아니라

“내가 의도한 흐름이 실제로 구현됐는지 검증하는 과정”

→ 기획자의 책임이자 마지막 점검이다

✅ 3. 테스트 시나리오를 PO가 정리하자

시나리오 예상 동작 확인 결과
앱 설치 후 알림 설정 전체 OFF
특정 알림 ON 후 앱 재실행 설정 유지 ⚠︎
이벤트 알림만 ON 알림 수신됨

 

✅ 4. 문제를 ’현상’이 아닌 ’경로’로 전달하자

  • “알림이 안 와요” ❌
  • “설정 ON → 로그아웃 → 재로그인 후 테스트 → 미수신” ✅

→ 이렇게 전달하면 개발자 디버깅도 빨라진다

✅ 5. PO의 테스트 시간도 일정에 포함되야 한다

PO가 QA 역할까지 한다면

그 시간은 기획 일정의 일부로 반영해야 한다.

  • “릴리즈 전 PO 검수 필요 1일”
  • “시나리오 기반 확인 포함 일정 명시”

💬 PO의 말 한마디

“PO가 디버깅까지 하는 이유는
내가 기획을 더 잘 이해하기 위해서입니다.

하지만 그 일이 반복되면,

기획은 자꾸 뒤로 밀리게 돼요.

그래서 우리는 그 구조부터 개선해야 해요.”

 

반응형