잃어버린 확신 (Lost confidence)

• RICE 등 확신 기반 우선순위 프레임워크는 대부분 노이즈이며, 알 수 없는 미래를 아는 척하지 않고 의사결정하는 방법이 필요함
• 확신 점수는 이런 (small) 프로젝트엔 높고 큰(large) 프로젝트엔 낮게 매겨지므로, 가치가 큰 프로젝트를 체계적으로 밀어내 우선순위를 왜곡함
• 확신 점수는 정의가 모호하고 검증 데이터도 부족하며, 프로젝트는 늘 늦어지고 기대보다 임팩트가 작기에 신뢰할 수 없음
• 해법은 확률(probability)이 아닌 불확실성(uncertainty) 영역에서 "어떤 확률 분포에서도 현명한 행동이 무엇인가"를 묻는 것
• 확신 대신 항상 참인 것·고객 임팩트·옵션 확보·비대칭 베팅 같은 기법으로 우선순위를 정하는 것이 중요함

---

확신 게임 (Confidence games)

• 많은 우선순위 프레임워크는 예측한 노력으로 예측한 임팩트를 낼 수 있다는 확신을 점수에 포함함
  • 동일 가치·동일 노력의 두 프로젝트 중 실행 확신이 높은 쪽을 고르는 것 자체는 합리적
  • 그러나 실제 사용 방식은 "1) 점수 매김 → 2) 명확한 승자 실행 → 3) 동점이면 확신 높은 쪽 선택"이 아님
• RICE는 1단계 점수 계산식에 확신을 직접 곱해 넣음
  • RICE 공식: Score = (Reach × Impact × Confidence) / Effort
  • RPS 공식: Score = Reach × Potential × Solution Confidence
• 이 방식은 서로 다른 두 시나리오를 동급으로 취급해 거짓 등가를 만듦
  • 작지만 확실히 실행 가능한 점진적 기능
  • 임팩트는 크지만 리스크를 안은 대형 기능
• 보통 작은 프로젝트엔 확신이 높고 큰 프로젝트엔 낮으므로, 확신을 곱하면 가치를 최대로 전달하는 방향에서 체계적으로 멀어짐
  • Agile 운동의 핵심 동기 자체가 "대형 프로젝트 성공은 늘 확신이 낮아야 한다"는 통찰이었음
• 확신 점수를 믿지 않는 이유
  • 정의가 모호함: "30%"가 무엇을 뜻하는지 불명확. 원래는 모든 프로젝트의 확신 점수를 기록하고 실제 결과와 대조해 정확도를 수치로 계산해야 하나, 실제로는 그렇게 하지 않음
  • 매년 소수의 주요 기능만 출시하면 사후에도 검증할 데이터 자체가 부족함
  • 프로젝트는 거의 항상 늦고, 기대보다 임팩트가 작고 느림. 9개월·6개팀 프로젝트도 "어느 정도 확신"이 있었기에 시작했음
• Hofstadter's Law 인용: "Hofstadter's Law를 감안해도 항상 예상보다 오래 걸린다"
• 경험 많은 PM에게 "분명히 환영받을 거라 확신했는데 아니었던 기능"을 물으면 누구나 여러 사례를 가짐
  • 고객 대화, 명시적 요청, 구매 약속 같은 근거가 있어도 막상 만들면 약속한 사람조차 거의 안 씀
  • 예측 개선 기법: 고객에게 실제 워크플로에서 단계별로 어떻게 쓸지 설명하게 함. 단계를 밟다 보면 "이건 코드를 다시 짜야 하니 안 하겠다"는 식으로 스스로 깨닫게 됨
• 콘텐츠 제작자도 마찬가지로, 별 기대 없이 급히 낸 글이 그해 가장 높은 조회·반응을 얻고, 수십 시간 공들인 역작이 외면받기도 함
  • "확신 여부 × 결과(사랑받음/무관심)" 2×2 표의 네 칸 모두 사례가 가득함

확신과 리스크 대신 무엇을 쓸 것인가 (What to use in place of confidence and risk)

• 답은 확률이 아닌 불확실성(uncertainty) 영역에 있음
  • 확률은 분포를 안다는 전제. 공정한 동전 100회 던지기는 앞면 40~60회 사이가 매우 유력하다고 예측 가능
  • 스타트업의 거의 모든 것은 이와 다름. 성공·전략·기능은 전례가 없거나 너무 복잡하거나 입력 변수의 정밀도가 없어 유의미한 확률 부여 불가
  • 경제학자 Frank Knight의 1921년 저작에서 유래한 "Knightian Uncertainty(나이트적 불확실성)" 개념
  • Bayesian 방법도 수치적 사전확률과 조건부확률이 필요한데, 둘 다 알 수 없고 정의 불가
• 불확실성 영역의 질문: "확률 분포와 무관하게 어떤 행동이 현명한가"

• 항상 참인 것 (True always)

  • 어떤 상황에서도 항상 참인 것에 집중 — Bezos의 장기 상수(long-term constants) 원칙
    • 사용자는 보편적으로 빠르고 반응성 좋은 소프트웨어를 선호함. 백그라운드 동기화·즉각적 상호작용·모든 기기에서의 동작을 가치 있게 여김
    • 최악의 경우(속도에 무관심)에도 속도를 부정적으로 보지는 않음. 최선의 경우 Notion, Figma, Miro, Gmail, Google Docs처럼 성능이 핵심 차별화 요소가 됨
  • 모든 기능이 보편적 매력을 갖진 않음. 정밀한 수치 분해 대신 사실상 모든 고객이 가치 있게 여기거나 최소한 좋아할 기능을 식별
    • 때로는 의무이기에 확실함. SOC 2 컴플라이언스 같은 엔터프라이즈 요구사항은 흥미롭진 않아도 엔터프라이즈 판매 시 확실히 가치 있음
    • 이런 확실성이 차별화 부재를 보완함
  • 단, 가장 혁신적이고 차별화된 아이디어는 "절대적으로 확실한" 범주에 거의 들지 않음
    • 확실한 것은 가치 있지만 전략적 차별화 요소가 되긴 어려움
    • 훌륭한 제품엔 신뢰할 만한 개선과 혁신적 도약 둘 다 필요함

• 빠른 발견, 빠른 회복 (Quick discovery, quick recovery)

  • 빌드 전 잠재 고객을 체계적으로 인터뷰해 아이디어를 검증하는 것을 오래 옹호해 왔으나, 이 역시 "확신의 함정"에 빠짐
    • 만들어 보기 전엔 결코 확실히 알 수 없음
    • 다만 빌드 전에 검증 실패(invalidate)는 가능해 수개월~수년의 낭비를 막을 수 있으므로 여전히 출발점으로 옳음
  • 전형적 해법은 SLC(MVP를 업그레이드한 개념)를 만드는 것 — 단순하지만 완결된 제품으로 진짜 피드백을 얻음(예측이 아닌 경험)
    • 기존 제품은 확실한 승리와 혁신적 베팅 사이의 균형 잡힌 포트폴리오를 유지하며 각각 다른 검증 방법 적용
  • "더미 기능(dummy features)" 예시: 클릭하면 "이 기능은 아직 없습니다. 어떻게 쓰실지 알려주세요"가 뜨는 버튼
    • 관심 사용자 수와 잠재 인터뷰 대상자를 행동으로 확보하는 실제 신호 제공
    • 설문보다 100배 나은 신호. 설문엔 쉽게 "예"라 하지만, 버튼 클릭 같은 행동은 진짜 관심을 요구함. 관찰된 행동이 진술된 의도를 이김

• 확신 대신 고객 임팩트에 집중 (Focus instead on customer impact)

  • 확신을 임팩트로 대체. 임팩트는 두 가지로 정의됨
    • 다수결(Majority rule): 다수 사용자가 정기적으로 쓰는 기능은 명백히 중요하며, 채택·유지의 핵심 이유일 가능성이 큼
    • 열성 옹호자(Passionate advocates): 소수에게 열성 팬을 만드는 기능. "오직 이것 때문에 샀다"는 사람들. 보편적이진 않아도 특정 세그먼트에 깊은 충성을 부름("magnificent delighters")
  • 사용자가 특정 부분을 진심으로 사랑하면 다른 결함은 감내함
    • iPod의 매력 덕에 수십억 명이 최악의 소프트웨어인 iTunes를 참아냄
    • 아름답게 설계된 소프트웨어는 기능 누락·플랫폼 제한이 있어도 디자인 경험만으로 받아들여짐
  • 고임팩트 기능의 정량 정의
    • (1) 고객의 최소 51%가 정기적으로 사용하거나
    • (2) 고객의 최소 15%가 선택·유지 이유 상위 3개로 언급
    • 높은 기준이지만 혁신적·리스크 있는 기능엔 높은 기준이 마땅하며, 보상의 크기가 리스크를 정당화해야 함

• 레버리지에 투자 (Invest in leverage)

  • 작은 점진적 변화가 큰 결과를 내는 영역이 존재함
  • 수학적·구조적으로 거의 항상 성립하는 레버리지 영역이 있음
    • (관련 도서 홍보 부분은 광고로 제외)

• 옵션 극대화 (Maximize optionality)

  • 미래를 알 수 없다면, 도달했을 때 가질 수 있는 선택지의 수를 최대화하는 선택을 함
    • 단순한 유연성·락인 회피를 넘어, 무엇이 생기든 처리할 수 있게 설계
  • 예시
    • 낮은 비용 유지 → 수익성을 지키며 다양한 가격·패키징 실험과 미래 회복력 확보
    • 잘 검증되고 활발히 개발되는 크로스플랫폼 UI 라이브러리·프레임워크 선택 → 플랫폼·기기 진화 대응
    • 플러그인 아키텍처 → 본인과 커뮤니티가 지금 상상 못 할 것을 구축
    • API-first 아키텍처 → 팀 격리, 프런트엔드·백엔드·고객 통합 연결
    • 벤더 서비스 래퍼 → 불안정·고비용·뒤처진 벤더를 교체 가능
  • 미래 옵션 확보는 오늘의 추가 작업을 요구함
    • 벤더 래핑 API는 오늘 당장은 가치를 더하지 않음
    • 안정성·예측성이 중요한 성숙 기업엔 현명하나, 속도로 기존 강자를 이겨야 하는 초기 단계엔 잘못된 선택일 수 있음
  • 회사 전체의 옵션을 극대화하는 길은 훌륭한 회사를 만드는 것
    • 건강하고 지속적인 성장, 크고 확대되는 총마진, 유지·업그레이드·입소문으로 증명되는 고객의 사랑, 장기근속·경력 성장으로 증명되는 직원의 사랑
    • 훌륭한 회사는 인수·존속·자금 조달·IPO·승계 등 많은 옵션을 가짐

• 베팅 포트폴리오 (Portfolio of bets)

  • 포트폴리오는 변동성을 줄이는 대신 최대 상방도 줄임
    • 승리가 전무할 가능성은 낮아 하방은 나쁘지 않으나, 승리가 손실을 메워야 하므로 가끔의 대박조차 단독 베팅만큼 크지 않음
    • 비유: IPO 때 Amazon을 사 영원히 보유하면 최고였겠지만, 같은 해 다른 IPO에 적용했다면 $0이 됐을 수도. 포트폴리오는 0이 되진 않으나 최대 성장은 최고 종목보다 훨씬 작음
  • 수학적 사이드바: 포트폴리오가 분포와 무관하게 작동하는 이유는 중심극한정리(Central Limit Theorem)
    • 안정적이나 알 수 없는 분포의 모집단에서 N개 표본을 반복 추출해 표본 평균의 히스토그램을 그리면, 그 분포는 가우시안(정규분포)으로 수렴함(평균은 모평균, 분산은 모분산의 1/n)
    • Lindeberg–Lévy CLT는 각 표본이 서로 다른 분포에서 나와도 성립함을 보임(독립성·유한 분산·단일 변수 미지배 조건 하에서)
    • 단, 스타트업 환경에 흔한 분포에선 이 조건이 깨질 수 있음(일부 Power Law는 분산이 무한)
  • 포트폴리오는 예측 가능하나 평범한 결과를 원할 때 작동하고, 아웃라이어를 원할 땐 작동하지 않음
    • 벤처·엔젤 포트폴리오 예시: 65%가 손실을 보고, 약 10%만이 리스크·비유동성을 정당화할 수익을 냄
    • 아웃라이어를 노릴 땐 포트폴리오가 아닌 올인 투자가 필요(스타트업 수익 분포는 Lindeberg 기준을 위반하는 Power Law이기 때문)
  • 결론: 시장 차별화·성장 동력을 찾는 우선순위라면 포트폴리오는 잘못된 도구. 작고 신뢰할 만한 점진적 결과엔 적합하며, 이 경우 확신을 두고 다툴 필요가 없음

• 비대칭 베팅 (Asymmetric bets)

  • 포트폴리오의 자연스러운 대척점. 포트폴리오가 신뢰성을 위한 것이라면 비대칭 베팅은 아웃라이어를 위한 것
    • 베팅의 성패를 예측하는 게 아니라, 하방은 제한·정량화되고 상방은 큰 베팅을 취함
  • 최악이 "2개월 손실", 최선이 "완전한 차별화"라면 확률은 거의 무의미함
    • 하방이 생존 가능하고 상방이 한 번의 승리로 열 번의 손실을 메울 만큼 크면 됨
    • 정확한 확률은 알 수 없으나 각 베팅의 형태(shape)는 알 수 있음
  • 전략 수준의 비대칭 베팅은 대개 형태가 미리 정해져 있음(복리 추천이 쌓이는 신규 시장, 팔수록 깊어지는 해자)
    • 기능 수준에선 비대칭을 직접 구성해야 함. 소프트웨어 프로젝트의 기본 형태는 "2주 → 2개월 → 너무 오래 써서 끝낼 수밖에 없음"으로 표류하기 때문
    • 메커니즘은 시작 전에 적어두는 예산: "엔지니어 2명, 3주, 그 후 멈추고 점검". 타임박스가 곧 제한된 하방
  • 확신을 "얼마나 비대칭적인가"로 대체하는 것도 방법
    • RICE는 알 수 없다고 인정한 확률을 추정하라고 요구함
    • 비대칭은 실제로 추정 가능한 두 가지를 물음: 시간·비용 기준 최악과 고객 가치 기준 최선. 둘 다 구체적이며, 모든 수치를 10의 거듭제곱으로 제한하면 회의에서 합의 가능한 숫자로 수렴 가능

결론

• 확신을 정량화하거나 정의할 수 있는 척을 멈출 것
• 대신 미래가 예측 불가능할 때마다 작동하는 기법을 사용할 것 — 미래는 언제나 예측 불가능하기 때문

[hmmhmmhm]

"대신 미래가 예측 불가능할 때마다 작동하는 기법을 사용할 것, 미래는 언제나 예측 불가능하기 때문" 멋지네요

[spilist2]

아주 훌륭한 글이네요.