반응형
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가 디버깅까지 하는 이유는
내가 기획을 더 잘 이해하기 위해서입니다.하지만 그 일이 반복되면,
기획은 자꾸 뒤로 밀리게 돼요.
그래서 우리는 그 구조부터 개선해야 해요.”
반응형
