# 잃어버린 확신 (Lost confidence)

> Clean Markdown view of GeekNews topic #30919. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=30919](https://news.hada.io/topic?id=30919)
- GeekNews Markdown: [https://news.hada.io/topic/30919.md](https://news.hada.io/topic/30919.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-06-29T09:35:01+09:00
- Updated: 2026-06-29T09:35:01+09:00
- Original source: [longform.asmartbear.com](https://longform.asmartbear.com/confidence/)
- Points: 12
- Comments: 2

## Topic Body

- 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의 거듭제곱으로 제한하면 회의에서 합의 가능한 숫자로 수렴 가능  
  
### 결론  
  
- 확신을 정량화하거나 정의할 수 있는 척을 멈출 것  
- 대신 **미래가 예측 불가능할 때마다 작동하는 기법**을 사용할 것 — 미래는 언제나 예측 불가능하기 때문

## Comments



### Comment 60674

- Author: hmmhmmhm
- Created: 2026-06-29T10:29:33+09:00
- Points: 1

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

### Comment 60666

- Author: spilist2
- Created: 2026-06-29T10:00:23+09:00
- Points: 1

아주 훌륭한 글이네요.