Antigravity Agent
101 lines
7.8 KiB
Markdown
101 lines
7.8 KiB
Markdown
---
|
|
id: pspo-ii
|
|
title: "PSPO II"
|
|
category: "10_Wiki/Topics"
|
|
status: "draft"
|
|
verification_status: "conceptual"
|
|
canonical_id: ""
|
|
aliases: ["Professional Scrum Product Owner II"]
|
|
duplicate_of: ""
|
|
source_trust_level: "B"
|
|
confidence_score: 0.85
|
|
created_at: 2026-06-12
|
|
updated_at: 2026-06-12
|
|
review_reason: ""
|
|
merge_history: []
|
|
tags: ["research", "Assumption Validation Loop", "Scrum", "Product Ownership"]
|
|
raw_sources: ["NotebookLM Synthesis"]
|
|
applied_in: ["PSPO II Exam Scenarios", "Advanced Product Certification Frameworks"]
|
|
github_commit: ""
|
|
---
|
|
|
|
# [[PSPO II]]
|
|
|
|
## 🎯 한 줄 통찰 (One-line insight)
|
|
[[PSPO II]] 수준의 제품 책임자(PO)는 전체 스프린트를 구축하기 전, 비즈니스를 붕괴시킬 수 있는 가장 위험한 가정을 식별하고 이를 가장 저렴하고 빠르게 검증하는 실험 설계 능력을 갖추어야 한다 [1, 2].
|
|
|
|
## 🧠 핵심 개념 (Core concepts)
|
|
- **가장 위험한 가정 테스트(RAT)**: 단순한 제품 구축(MVP)을 넘어, 실패 시 모든 것을 무의미하게 만들 단 하나의 핵심 가설을 격리하여 테스트하는 기법이다 [3, 4].
|
|
- **실험 기반의 가치 창출**: 전체 스프린트 자원을 투입하기 전, 시장의 신호를 생성하기 위한 가설 중심의 접근법을 사용한다 [1, 2].
|
|
- **빌드 트랩(Build Trap) 회피**: 기능의 출시 수(Output)가 아닌, 검증된 학습과 비즈니스 결과(Outcomes)를 통해 진척도를 측정한다 [5, 6].
|
|
- **경제적 실험 설계**: 최소한의 시간과 비용으로 유효한 증거를 수집하기 위해 [[Concierge MVP]], [[Wizard of Oz MVP]], [[Fake Door Test]] 등 적절한 모델을 선택하는 능력이다 [7, 8].
|
|
|
|
## 🧩 추출된 패턴 (Extracted patterns)
|
|
- **Learn-Measure-Build 루프**: 전통적인 'Build-Measure-Learn'의 함정(구축에 과도한 에너지 소모)을 피해, 학습과 측정을 먼저 수행하고 코드는 discovery의 마지막 단계로 작성하는 패턴이다 [9].
|
|
- **성공 임계값(Success Threshold) 선제적 설정**: 실험 결과가 나온 후 결과를 자의적으로 해석하는 확신 편향을 방지하기 위해, 테스트 시작 전 합격/불합격 기준을 문서화한다 [4, 10, 11].
|
|
- **증거의 계층 구조 활용**: 구두 확인(약함)보다 시간 투자(강함)를, 단순 가입보다 재정적 약속(가장 강함)을 더 높은 가치의 검증 신호로 판단한다 [12, 13].
|
|
|
|
## 📖 세부 내용 (Details)
|
|
[[PSPO II]] 자격증 시나리오는 제품 책임자가 개발 스프린트에 착수하기 전, 가장 가치 있는 실험을 식별할 수 있는지를 중점적으로 테스트한다 [1, 2]. 이는 조직이 기능 중심의 로드맵에서 벗어나 실제 사용자 니즈에 뿌리를 둔 연속적 탐색(Continuous Discovery)으로 전환하도록 이끄는 역할을 포함한다 [6].
|
|
|
|
고급 단계의 PO는 다음과 같은 세부 역량을 발휘해야 한다:
|
|
- **인지적 함정 탈피**: '제품'이라는 용어가 유도하는 코드 확장성이나 UI 디자인의 완성도에 매몰되지 않고, 비즈니스 모델의 존립을 위협하는 변수에 집중한다 [14].
|
|
- **가정 매핑 매트릭스 운용**: 중요도(사망 위험)와 불확실성(데이터 부족)을 축으로 하여, 실험이 필요한 '도약의 가정(Leap-of-faith assumptions)'을 선별한다 [15, 16].
|
|
- **노코드(No-code) 활용 역량**: 커스텀 소프트웨어 개발에 2,000~4,000시간을 쓰기 전, 노코드 툴 스택을 사용하여 200~400시간 내에 고충실도 경험을 구현하고 자본 가치를 증명한다 [17].
|
|
- **전략적 의사결정**: 실험 데이터를 바탕으로 감정이 아닌 증거에 기반하여 피벗(Pivot), 인내(Persevere), 또는 폐기(Kill)를 결정한다 [18, 19].
|
|
|
|
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
|
- **MVP와 RAT의 차이**: MVP는 최소한의 기능을 갖춘 '제품'을 의미할 때가 많아 엔지니어링 과잉을 유도할 수 있으나, RAT는 제품 없이도 신호만 생성하면 되는 더 날카로운 개념으로 강조된다 [3, 9].
|
|
- **가변적 "Viable" 정의**: 제품 개발에서 "Viable(생존 가능한)"은 단순히 동작함을 의미하는 것이 아니라, 사용자가 특정 문제를 해결하기 위해 일관되게 사용할 의지가 있음을 의미하는 것으로 좁게 해석되어야 한다 [20].
|
|
|
|
## 🛠️ 적용 사례 (Applied in summary)
|
|
- **시험 시나리오 적용**: PSPO II 시험은 PO가 전체 백로그를 구축하기 전, 단 일주일 내에 사용자 행동을 답변할 수 있는 '가장 저렴한 실험'을 선택하는 능력을 평가하는 시나리오를 포함한다 [1].
|
|
- **실무 가이드라인**: 개발 시작 전 10~20명의 잠재 고객과 'Mom Test' 원칙에 따라 인터뷰하여 과거 행동을 기반으로 가치를 검증하는 방식이 고급 PO의 표준 실무로 제시된다 [21, 22].
|
|
|
|
## ✅ 검증 상태 및 신뢰도
|
|
- **상태:** draft
|
|
- **검증 단계:** conceptual (실제 적용 사례 발견 시 applied/validated로 승격 가능)
|
|
- **출처 신뢰도:** B (전문가 기고문 및 제품 관리 프레임워크 기반)
|
|
- **중복 검사 결과:** 신규 생성 (New discovery)
|
|
|
|
|
|
## 🔗 관련 문서 링크 (Related document links)
|
|
|
|
### 상위/유사 개념
|
|
|
|
#### [루트 주제 및 프레임워크]
|
|
- [[Assumption Validation Loop]]
|
|
- 연결 이유: PSPO II의 핵심 역량인 가설 검증의 전체적인 시스템 구조임.
|
|
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 탐색과 전달의 통합 방법론.
|
|
|
|
#### [핵심 테스트 방법론]
|
|
- [[Riskiest Assumption Testing (RAT)]]
|
|
- 연결 이유: PSPO II 시험과 실무에서 가장 가치 있는 실험을 찾는 핵심 도구임.
|
|
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: MVP보다 빠른 검증 기법.
|
|
|
|
#### [성과 측정 체계]
|
|
- [[Innovation Accounting]]
|
|
- 연결 이유: 재무적 지표가 0일 때 진척도를 측정하는 PSPO II 수준의 대시보드 역량임.
|
|
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 학습 속도(Learning Velocity) 측정법.
|
|
|
|
### 심층 후속 질문 (Deeper Research Questions)
|
|
- PSPO II 시나리오에서 제품 책임자는 어떻게 '재정적 약속'을 이끌어내어 가설을 완벽하게 검증하는가? [12]
|
|
- 확신 편향에 빠진 이해관계자를 실험 데이터로 설득할 때 PO가 사용하는 구체적인 커뮤니케이션 패턴은 무엇인가? [23]
|
|
- 노코드 툴 스택을 활용한 고충실도 프로토타입이 커스텀 코드 개발 대비 창출하는 구체적인 ROI는 어떻게 계산되는가? [17]
|
|
- '성공 임계값' 설정 시 산업 벤치마크와 비즈니스 케이스 중 어느 것을 우선순위에 두어야 하는가? [24]
|
|
- 피벗(Pivot) 결정 시 기존 팀의 정체성(Identity) 붕괴를 막기 위해 PO가 수행해야 할 역할은 무엇인가? [25]
|
|
|
|
### 실무 적용 맥락 (Practical Application Contexts)
|
|
- **Implementation:** 전체 백로그 아이템을 스프린트에 넣기 전, RAT를 통해 가설을 먼저 검증함 [1].
|
|
- **System Design:** 노코드 도구를 활용하여 비즈니스 로직과 UI 흐름을 선제적으로 설계하고 테스트함 [17].
|
|
- **Operation / Maintenance:** 가동 중인 제품에 대해 기능 플래그(Feature Flag)를 사용하여 점진적으로 실험을 배포함 [26].
|
|
- **Learning Path:** PSPO I의 운영적 이해를 넘어, 전략적 제품 발견과 위험 관리 능력을 배양함 [2].
|
|
|
|
### 인접 주변 주제 (Adjacent Topics)
|
|
- [[Mom Test]]
|
|
- 확장 방향: 편향되지 않은 질문을 통해 실제 고객 행동 증거를 추출하는 기술.
|
|
- [[Kano Model]]
|
|
- 확장 방향: 검증된 기능들을 고객 만족도와 기쁨의 관점에서 우선순위화하는 방법.
|
|
|
|
## 📝 변경 이력 (Change history)
|
|
- 2026-06-12: Initial draft generated via Datacollector_MAC P-Reinforce engine. |