2026 All-Day-Project (027/365)
이 글은 디자인은 가설이다에서 다뤘던 "실패하는 가설의 가치"를 확장한 것이다.
우리는 실패를 '비용'으로 처리하도록 훈련받았다. 손익계산서의 적자. 회수 불가능한 매몰 비용. 누군가의 책임. 그러나 제품을 만드는 맥락에서 이 회계적 관점은 위험하다. 모든 제품은 가설이고, 가설은 검증되거나 반증되기 위해 존재한다.
반증된 가설을 '실패'라고 부르면, R&D 투자를 손실로 오인하게 된다. 실패는 비용이 아니다. 학습에 대한 투자다.
나는 이전 글에서 "좋은 가설은 빠르게 실패한다"고 썼다. 불완전한 문장이었다. 더 정확히 말하면, 좋은 가설은 빠르게 실패할 수 있도록 설계된다. 그리고 좋은 조직은 그 실패로부터 학습하도록 구조화되어 있다.
반대 상황부터 보자. 많은 조직이 가설을 실패하지 못하게 만든다.
첫째, 가설을 명시하지 않는다.
"사용자 경험 개선"이라는 목표 아래 버튼 색을 바꾸고 레이아웃을 조정한다. "이 변경이 어떤 행동 변화를 일으킬 것인가?"라는 예측 없이 진행된다. 가설이 없으면 반증도 없다. 결과가 나빠도 "원래 이런 거다"라고 말할 수 있다.
둘째, 측정 지표를 사후에 선택한다.
론칭 후 데이터를 보며 "이 지표가 올랐으니 성공"이라고 선언한다. 과녁을 쏜 뒤에 화살 주변에 동그라미를 그리는 것과 같다. 실험은 먼저 과녁을 정하고, 그 과녁에 맞았는지를 확인하는 것이다.
셋째, 실패를 정치화한다.
"이 기능은 김 상무님 아이디어였는데..."라는 말이 나오는 순간, 가설 검증은 정치적 생존의 문제가 된다. 누군가의 체면이 가설에 묶여 있으면, 그 가설은 반증될 수 없다. 데이터가 명백해도 "사용자가 아직 익숙하지 않아서"라는 합리화가 등장한다.
이것은 과학이 아니라 신앙이다. 신앙에는 배움이 없다.
어떻게 '실패할 수 있는' 가설을 설계할 것인가?
2-1. 구체적 예측
"사용자 만족도가 올라갈 것이다"는 가설이 아니다. "신규 사용자의 7일 내 재방문율이 15%에서 20%로 상승할 것이다"가 가설이다. 숫자 자체가 중요한 게 아니다. 예측이 명확해야 반증이 가능하다.
편의점 모니터링 시스템을 예로 들어보자. "점주가 이 대시보드를 좋아할 것이다"는 검증 불가능하다. "점주의 대시보드 일평균 체류 시간이 10분에서 5분으로 줄어들고, 권장 조치 실행률은 60%에서 80%로 증가할 것이다"는 검증 가능하다. 전자는 희망이고, 후자는 가설이다.
2-2. 최소 검증 단위
가설은 작아야 한다. 큰 가설은 실패해도 무엇이 틀렸는지 알 수 없다.
"우리 앱을 쓰면 사용자의 삶이 나아질 것이다"가 반증되었다고 하자. 어디서부터 손대야 하는가? 온보딩인가, 핵심 기능인가, 가격인가, 마케팅 메시지인가? 모든 것이 뒤엉켜 있다.
반면 "온보딩에서 3단계 튜토리얼을 제공하면, 첫 핵심 액션 완료율이 상승할 것이다"가 반증되었다면, 다음 질문은 명확하다. 튜토리얼이 너무 길었는가? 내용이 잘못되었는가? 튜토리얼 자체가 방해가 되는가?
작은 가설은 실패해도 다음 단계가 보인다. 큰 가설은 실패하면 모든 것이 안개 속이다.
2-3. 사전 합의된 결정 규칙
실험 전에 "결과가 이러면 A를 하고, 저러면 B를 한다"를 합의해야 한다. 이것이 없으면 결과 해석은 언제나 편향된다.
"전환율이 5% 이상 오르면 전체 출시, 3~5% 사이면 추가 실험, 3% 미만이면 가설 폐기"라는 합의가 있으면, 결과가 2.9%일 때 논쟁의 여지가 없다. 합의 없이 2.9%가 나오면 "거의 3%인데", "표본이 작아서", "계절 영향이 있었을 수도" 같은 합리화가 시작된다.
사전 합의는 가설에서 정치를 제거한다.
2-4. 가설의 위계
모든 가설이 평등하지는 않다. 버튼 색깔을 검증하느라 시간을 낭비하지 마라.
좋은 조직은 "이 가설이 틀리면 우리 사업이 망하는가?"를 먼저 묻는다. 가장 위험하고 가장 불확실한 가설부터 검증대에 올려야 한다. 이것을 'Leap of Faith Assumption'이라고 부른다. 틀리면 모든 것이 무너지는 전제.
작은 리스크는 직관으로 넘어간다. 치명적 리스크는 실험으로 돌파한다.
3. 실패의 해상도
앞서 '디자인은 가설이다'에서 나는 "가설의 해상도"를 말했다. 실패에도 해상도가 있다.
흐릿한 CCTV 화면으로는 범인을 잡을 수 없다. 저해상도의 실패 데이터로는 문제의 원인을 특정할 수 없다.
| 저해상도 |
"안 됐다." > 막막하다
| 중해상도 |
"전환율이 예상보다 낮았다." > 어디를 봐야 할지 모르겠다
| 고해상도 |
"25-34세 여성의 결제 단계 이탈률이 23% 높았다. 히트맵에서 '약관 동의' 체크박스에서 주저하는 패턴이 발견되었다." > "약관 동의 UI를 단순화하면 이탈률이 줄어들 것이다"
고해상도로 실패하면, 다음 가설은 구체적이다. 저해상도로 실패하면, 다음 가설도 막연해진다.
로그 설계는 기획의 일부다
고해상도 실패를 위해서는 처음부터 측정 설계가 정교해야 한다.
기획자는 개발자에게 기능만 요구하는 것이 아니다. "이 가설이 틀렸을 때 어떤 로그가 남아야 하는지"를 명세서의 필수 항목으로 정의해야 한다. 기능 명세만큼 중요한 것이 데이터 명세다.
성공인지 실패인지 판단할 로그가 정의되지 않은 기획서는 미완성이다. 개발에 착수해서는 안 된다.
측정할 수 없다면 만들지 않는다. 이것이 실험하는 조직의 규율이다. 추적 코드 없는 기능 배포는 눈을 감고 운전대를 잡는 것과 같다.
가설이 잘 설계되어도, 조직이 실패를 받아들이지 못하면 소용없다.
4-1. 실패를 기록한다
성공한 A/B 테스트만 공유되는 조직에서는 같은 실패가 반복된다. "우리도 3년 전에 그거 해봤는데 안 됐어"라는 구전에 의존하면, 사람이 떠날 때 지식도 떠난다.
어떤 가설을 세웠고, 왜 그렇게 생각했고, 결과는 어땠고, 무엇을 배웠는지를 문서화한다. 이것이 조직의 인식론적 자산이다.
4-2. 실패를 인센티브로 연결한다
"이 가설이 틀렸음을 증명해줘서 고맙다"가 진심으로 말해지는 문화가 필요하다. 문화만으로는 부족하다. 시스템이 뒷받침되어야 한다.
가설 반증은 조직이 잘못된 방향에 더 큰 자원을 투입하는 것을 막는다. 이것은 실패가 아니라 비용 회피다. 인사 평가 항목에 '가설 검증 횟수'를 포함하거나, 의미 있는 학습을 도출한 실패에 보상을 부여하는 것도 방법이다.
물론 모든 실패가 칭찬받아야 하는 건 아니다. 게으름으로 인한 실패와 용기 있는 가설 검증으로 인한 실패는 다르다.
4-3. 실패에서 다음 가설을 도출한다
"왜 틀렸는가?"는 "다음에 무엇을 실험할 것인가?"로 이어져야 한다.
"사용자는 AI 추천을 신뢰할 것이다"가 반증되었다면, 멈추지 말고 파고들어야 한다. 추천의 정확도 문제인가? 설명 가능성의 부재인가? '추천받는다'는 경험 자체에 대한 거부감인가?
각각의 대답은 다른 가설을 낳는다. 실패는 끝이 아니라 분기점이다.
5. 실험할 수 없을 때
현실의 제약이 있다. 모든 결정을 A/B 테스트할 수는 없다. 트래픽이 부족하거나, 시간이 없거나, 이해관계자가 동의하지 않거나.
특히 B2B나 엔터프라이즈 환경에서는 '작은 실패'를 설계하기 어렵다. 점주의 신뢰도 하락, 운영 리스크, 계약 관계의 복잡성. 실제 유저에게 실험한다는 것 자체가 민감할 수 있다.
시뮬레이션과 샌드박스
B2B나 하드웨어처럼 실패 비용이 큰 환경에서는 시뮬레이션이나 Closed Beta가 핵심 도구다. 실제 운영 환경에 영향을 주지 않으면서 가설을 검증할 수 있는 공간.
AI 시대에는 이 가능성이 확장된다. 가상 유저 시뮬레이션으로 실제 유저 노출 전에 '가상 실패'를 먼저 겪게 할 수 있다. 시뮬레이션이 현실을 완벽히 반영하지는 않지만, 명백한 실패를 사전에 걸러내는 데는 효과적이다.
고객의 약속을 테스트한다
B2B에서는 제품이 없어도 가설을 검증할 수 있다.
고객에게 제안서를 보여주고 구매 의향서(LOI)나 유료 파일럿을 제안해보라. 고객이 "좋네요, 나오면 연락주세요"라고 한다면 그것은 예의 바른 거절이다. 반면, 예산을 묻고 일정을 따진다면 그것은 검증된 가설이다.
"무료로 써보실래요?"에 대한 긍정은 가짜 신호다. "유료 베타에 참여하시겠습니까?"에 대한 거절은 진짜 실패다. B2B의 실험은 코드가 아니라 고객의 약속을 받아내는 과정이다.
조건부 가설
실험할 수 없다고 해서 가설을 세우지 않아도 되는 것은 아니다.
"우리는 이것이 맞다고 믿고 진행한다. 하지만 6개월 후 이 지표가 이 수준에 도달하지 않으면 재검토한다."
이런 조건부 가설도 유효하다. 중요한 건 실험 여부가 아니라 가설을 의식하는 것이다.
AI는 실험의 속도를 높인다. 프로토타입을 몇 분 만에 만들 수 있고, 변형을 무한히 생성할 수 있으며, 분석도 자동화된다.
빠르게 실험할 수 있다는 것은 빠르게 실패할 수 있다는 뜻이다. 하지만 실패가 학습으로 이어지지 않으면, 빠르게 돈을 쓰는 것일 뿐이다.
AI가 가져온 속도의 이점을 살리려면, 가설-실험-학습 사이클이 그 속도를 따라가야 한다.
"일주일에 10개 실험"이 아니라 "일주일에 10개의 고해상도 실패와 10개의 다음 가설"이 목표가 되어야 한다.
실패를 두려워하는 것은 자연스러운 반응이다. 하지만 제품을 만드는 사람에게 실패는 두려움의 대상이 아니라 학습의 원천이다.
90%의 사용자가 당신의 가설을 거부했다면, 그것은 패배가 아니라 발견이다. "사람들은 이렇게 행동하지 않는다"를 배운 것이다. 그 배움이 다음 가설을 더 정교하게 만든다.
좋은 제품은 수많은 실패 위에 서 있다. 더 정확히 말하면, 좋은 제품은 잘 설계된 실패로부터 배운 조직이 만든다.
당신의 조직은 실패를 어떻게 다루는가?
손익계산서의 적자로 처리하는가, R&D 투자로 처리하는가?
숨기는가, 기록하는가?
처벌하는가, 학습하는가?
그 대답이 제품의 미래를 결정한다.
가설은 증명되기 위해서가 아니라 더 좋은 가설을 낳기 위해 존재한다. 실패는 그 탄생을 돕는 산파다.