😀
fistkim TECH BLOG
  • Intro
  • 강의
    • Reactive Programming in Modern Java using Project Reactor
      • Reactor execution model 1
      • Reactor execution model 2
      • Reactor execution model 3 - parallelism
      • Reactor execution model 4 - overview
      • Transform
      • Combine
      • Side Effect Methods
      • Exception/Error handling
      • retry, retryWhen, repeat
      • BackPressure
      • Cold & Hot Streams
    • NEXTSTEP 클린코드 with java 9기
      • 정리노트
    • NEXTSTEP DDD 세레나데 2기
      • CH01 도메인 주도 설계 이해
      • CH02 크게 소리 내어 모델링 하기
      • CH03 도메인 주도 설계 기본 요소
      • CH04 도메인 주도 설계 아키텍처
      • CH05 도메인 이벤트
    • NEXTSTEP 인프라 공방 1기
      • 망 분리하기
      • 통신 확인하기
      • 도커 컨테이너 이해하기
      • [미션 1] 서비스 구성하기 실습
      • [미션 2] 서비스 배포하기 실습
      • 서버 진단하기
      • 어플리케이션 진단하기
      • [미션 3] 서비스 운영하기
      • 웹 성능 진단하기
      • 부하 테스트
      • k6
      • [미션 4] 성능 테스트
      • 리버스 프록시 개선하기
      • 캐싱 활용하기
      • [미션 5] 화면 응답 개선하기
      • Redis Annotation 및 설정
      • 인덱스 이해하기 & DB 튜닝
      • [미션 6-1] 조회 성능 개선하기
      • [미션 6-2] DB 이중화 적용
    • NEXTSTEP 만들면서 배우는 Spring 3기
      • CH01 올바른 방향 바라보기
      • CH02 HTTP 이해 - 웹 서버 구현
        • HTTP 파싱
        • HTTP 웹 서버 구현
      • CH03 MVC - @MVC 프레임워크 구현
        • Servlet 다시 짚기
        • Cookie, Session 다시 짚기
        • MVC 프레임워크 구현
      • CH04 나만의 라이브러리 구현
      • CH05 DI - DI 프레임워크 구현
      • CH06 Aspect OP
    • 스프링 시큐리티
      • 스프링 시큐리티 아키텍처
      • WebAsyncManagerIntegrationFilter
      • SecurityContextPersistenceFilter
      • HeaderWriterFilter
      • CsrfFilter
      • (+) 스프링 시큐리티 + JWT
      • (+) 마치며
    • 더 자바, 코드를 조작하는 다양한 방법
      • CH01 JVM 이해하기
      • (+) 클래스 로더 이해하기
      • CH02 바이트 코드 분석 및 조작
      • (+) jacoco
      • CH03 리플렉션
      • CH04 다이나믹 프록시
      • CH05 애노테이션 프로세서
    • 더 자바, 애플리케이션을 테스트하는 다양한 방법
      • CH01 JUnit 5
      • CH02 Mockito
      • (+) Spy vs Mock
      • CH03 도커와 테스트
      • CH04 성능 테스트
      • (+) VisualVM
      • (+) 테스트 자동화
      • CH05 운영 이슈 테스트
      • CH06 아키텍처 테스트
    • 모든 개발자를 위한 HTTP 웹 기본 지식
      • CH01 인터넷 네트워크
      • CH02 HTTP 기본
      • CH03 HTTP 메서드 속성
      • CH04 HTTP 메서드 활용
      • CH05 HTTP 상태코드
      • CH06 HTTP 헤더1 - 일반 헤더
      • CH07 HTTP 헤더2 - 캐시와 조건부 요청
      • (+) HTTPS 원리
    • 스프링 프레임워크 핵심 기술
      • CH01 IOC 컨테이너
      • CH02 AOP
      • (+) 스프링 의존성 관리
      • (+) 생성자 주입 장점
    • 코딩으로 학습하는 GoF의 디자인 패턴
      • 객체 생성
        • 싱글톤 패턴
        • 팩토리 메소드 패턴
        • 추상 팩토리 패턴
        • 빌더 패턴
        • 프로토타입 패턴
      • 구조
        • 어댑터 패턴
        • 브릿지 패턴
        • 컴포짓 패턴
      • 행동
        • (작성중)
    • 실전 Querydsl
      • CH01 프로젝트 환경구성
      • CH02 예제 도메인 모델
      • CH03 기본문법
      • CH04 중급 문법
      • CH05 실무활용 (스프링 데이터 JPA와 Querydsl)
      • CH06 스프링데이터JPA 가 제공하는 Querydsl 기능
      • (+) 별칭(alias)
      • (+) Slice 쿼리
    • 스프링 데이터 JPA
      • CH01 핵심개념이해 1
      • CH02 핵심개념이해 2
      • CH03 핵심개념이해 3
      • CH04 Spring Data Common
      • CH05 Spring Data JPA
    • 실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화
      • CH01 지연 로딩과 조회 성능 최적화
      • CH02 컬렉션 조회 최적화
      • CH03 전체 정리
    • 초보를 위한 쿠버네티스 안내서
      • CH01 쿠버네티스 시작하기
      • CH02 쿠버네티스 알아보기
      • CH03 쿠버네티스 실습 준비
      • CH04 쿠버네티스 기본 실습
    • Flutter Provider Essential
      • CH01 Introduction
      • CH02 Provider Overview
      • CH03 TODO App
      • CH04 Weather App
      • CH05 Firebase Authentication App
    • Flutter Bloc Essential
      • CH01 Introduction
      • CH02 Bloc Overview
      • CH03 TODO App
      • CH04 Weather App
      • CH05 Firebase Authentication App
    • Flutter Advanced Course - Clean Architecture With MVVM
      • CH01 Introduction
      • CH02 Clean Architecture 4 Layer
      • CH03 MVVM
      • CH04 Data Layer
      • (+) Data Layer - response to model
      • (+) Data Layer - Network
      • CH05 Domain Layer
      • CH06 Presentation Layer
      • CH07 Application Layer
      • (+) Application Layer - l10n
      • (+) Application Layer - DI
      • (+) Application Layer - environment
    • 자바 알고리즘 입문
      • CH01 문자열
      • CH02 Array(1, 2 차원 배열)
      • CH03 Two pointers, Sliding window[효율성: O(n^2)-->O(n)]
      • CH04 HashMap, TreeSet (해쉬, 정렬지원 Set)
      • CH05 Stack, Queue(자료구조)
      • CH06 Sorting and Searching(정렬, 이분검색과 결정알고리즘)
      • CH07 Recursive, Tree, Graph(DFS, BFS 기초)
      • CH08 DFS, BFS 활용
      • CH09 Greedy Algorithm
      • CH10 dynamic programming(동적계획법)
  • 도서
    • 만들면서 배우는 클린 아키텍처
      • 학습목표
      • CH01 계층형 아키텍처의 문제는 무엇일까?
      • CH02 의존성 역전하기
      • CH03 코드 구성하기
      • CH04 유스케이스 구현하기
      • CH05 웹 어댑터 구현하기
      • CH06 영속성 어댑터 구현하기
      • CH07 아키텍처 요소 테스트하기
      • CH08 경계 간 매핑하기
      • CH09 어플리케이션 조립하기
      • CH10 아키텍처 경계 강제하기
      • CH11 의식적으로 지름길 사용하기
      • CH12 아키텍처 스타일 결정하기
    • 클린 아키텍처
      • 들어가며
      • 1부 소개
        • 1장 설계와 아키텍처란?
        • 2장 두 가지 가치에 대한 이야기
      • 2부 벽돌부터 시작하기: 프로그래밍 패러다임
        • 3장 패러다임 개요
        • 4장 구조적 프로그래밍
        • 5장 객체 지향 프로그래밍
        • 6장 함수형 프로그래밍
      • 3부 설계 원칙
        • 7장 SRP: 단일 책임 원칙
        • 8장 OCP: 개방-폐쇄 원칙
        • 9장 LSP: 리스코프 치환 원칙
        • 10장 ISP: 인터페이스 분리 원칙
        • 11장 DIP: 의존성 역전 원칙
      • 4부 컴포넌트 원칙
        • 12장 컴포넌트
        • 13장 컴포넌트 응집도
        • 14장 컴포넌트 결합
      • 5부
        • 15장 아키텍처란?
    • 스프링 입문을 위한 자바 객체 지향의 원리와 이해
      • CH01 사람을 사랑한 기술
      • CH02 자바와 절차적/구조적 프로그래밍
      • CH03 자바와 객체 지향
      • (+) 자바 코드 실행에 따른 메모리 적재과정
      • CH04 자바가 확장한 객체 지향
      • CH05 객체 지향 설계 5 원칙 - SOLID
      • CH06 스프링이 사랑한 디자인 패턴
      • CH07 스프링 삼각형과 설정 정보
      • (부록) 람다(lambda)
    • 객체지향의 사실과 오해
      • CH01 협력하는 객체들의 공동체
      • CH02 이상한 나라의 객체
      • CH03 타입과 추상화
      • CH04 역할, 책임, 협력
      • CH05 책임과 메시지
      • CH06 객체 지도
      • CH07 함께 모으기
      • (+) 인터페이스 개념 바로잡기
    • 도메인 주도 개발 시작하기
      • CH01 도메인 모델 시작하기
      • CH02 아키텍처 개요
      • CH03 애그리거트
      • CH04 리포지터리와 모델 구현
      • CH05 스프링 데이터 JPA를 이용한 조회 기능
      • CH06 응용 서비스와 표현 영역
      • CH07 도메인 서비스
      • CH08 애그리거트 트랜잭션 관리
      • CH09 도메인 모델과 바운디드 컨텍스트
      • CH10 이벤트
      • CH11 CQRS
    • 자바 ORM 표준 JPA 프로그래밍
      • CH01 JPA 소개
      • CH02 JPA 시작
      • CH03 영속성 관리
      • CH04 엔티티 매핑
      • CH05 연관관계 매핑 기초
      • CH06 다양한 연관관계 매핑
      • CH07 고급 매핑
      • CH08 프록시와 연관관계 관리
      • CH09 값 타입
      • CH10 객체지향 쿼리 언어
      • CH11 웹 애플리케이션 제작
      • CH12 스프링 데이터 JPA
      • CH13 웹 애플리케이션과 영속성 관리
      • CH14 컬렉션과 부가 기능
      • CH15 고급 주제와 성능 최적화
      • CH16 트랜잭션과 락, 2차 캐시
    • 소프트웨어 세상을 여는 컴퓨터과학
      • CH01 컴퓨터 과학 소개
      • CH02 데이터 표현과 디지털 논리
    • 이펙티브 자바
      • 1 장 들어가기
      • 2장 객체 생성과 파괴
        • [01] 생성자 대신 정적 팩터리 메서드를 고려하라
        • [02] 생성자에 매개변수가 많다면 빌더를 고려하라
        • [03] private 생성자나 열거 타입으로 싱글턴임을 보증하라
        • [04] 인스턴스화를 막으려거든 private 생성자를 사용하라
        • [05] 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라
        • [06] 불필요한 객체 생성을 피하라
        • [07] 다 쓴 객체 참조를 해제하라
        • [08] finalizer 와 cleaner 사용을 피하라
        • [09] try-finally 보다는 try-with-resources 를 사용하라
      • 3장 모든 객체의 공통 메서드
        • [10] equals는 일반 규약을 지켜 재정의하라
        • [11] equals 를 재정의하려거든 hashCode도 재정의하라
        • [12] toString 을 항상 재정의하라
        • [13] clone 재정의는 주의해서 진행하라
        • [14] Comparable 을 구현할지 고려하라
      • 4장 클래스와 인터페이스
        • [15] 클래스와 멤버의 접근 권한을 최소화하라
  • 토픽
    • 서버 모니터링
      • CPU 사용량
      • 메모리 사용량
      • 스레드 풀
    • Spring Boot Monitoring
      • Spring actuator
      • Spring eureka
      • Prometheus
      • grafana
      • Spring actuator + Prometheus + grafana
    • JAVA 데일리 토픽
      • 메모리 누수(memory leak)
      • 객체 참조의 유형
      • 커스텀 스레드 풀
      • Mark And Compact
      • serialVersionUID 이해하기
      • 함수형 인터페이스
      • 메소드 참조
      • equals()와 hashCode()가 무엇이고 역할이 무엇인지
      • StringBuffer vs StringBuilder
      • String vs StringBuilder, StringBuffer
      • String interning
    • JAVA GC
    • 프로그래머스 문제 풀기
      • 해시
      • 스택/큐
      • 힙(Heap)
      • 정렬
      • 완전탐색
      • DFS/BFS
    • 데이터베이스 구성 및 작동 흐름
    • 데이터베이스 JOIN 원리
    • 객체지향생활체조 원칙
    • 상태(state), 상속(inheritance), 합성(composition) 의 상관관계
    • java enum은 메모리에 언제, 어떻게 할당되는가
    • Checked Exception vs UnChecked Exception
    • Reactive Streams 원리탐구 - 간단한 예제 직접 작성해보기
    • Flutter Basic
    • Flutter StatefulWidget 생명주기
    • Flutter 가 위젯을 그리는 원리
    • Flutter 클린 아키텍처
      • application layer
        • 패키지 구조 및 레이어 설명
        • environment
        • dependency injection
        • go_router
        • foreground & background
        • 다국어처리 (l10n, i18n)
        • Global 처리(시스템 점검, fore->back 등)
        • connection_manager
        • permission_manager
        • push_notification_manager
        • firebase 연동
      • data layer
        • 패키지 구조 및 레이어 설명
        • network
        • repository
      • domain layer
        • 패키지 구조 및 레이어 설명
      • presentation layer
        • 패키지 구조 및 레이어 설명
        • resources
    • 기술 관련 포스팅 읽기
  • 기타
    • 작업일지
      • 2023. 10
      • 2023. 09
      • 2023. 08
      • 2023. 07
      • 2023. 06
      • 2023. 05
      • 2023. 04
      • 2023. 03
      • 2023. 02
      • 2023. 01
      • 2022. 12
    • Business Model
      • 아이디어 불패의 법칙
      • 린 모바일 앱 개발
      • 린 스타트업
      • 제로투원
      • MIT 스타트업 바이블
      • 린치핀
    • 백로그 종합
Powered by GitBook
On this page
  • 1부 불변의 사실
  • 1-1. 시장 실패의 법칙
  • 1-2. 될 놈(The Right It)
  • 1-3. 생각은 접어두고 데이터를 모으라(Data Beats Opinions)
  • 2부 쓸모 있는 데이터를 수집하는 방법
  • 2-1. 사고 도구
  • 2-2. 프리토타이핑 도구
  • 2-3. 분석 도구
  • 3부 유연한 전략
  • 3-1. 전략 도구
  • 3-2. 완성 사례 버스 U flow 예시
  1. 기타
  2. Business Model

아이디어 불패의 법칙

책의 모든 내용이 무척 공감이 갔고, 도움이 많이 되었다. 세세하게 정리해두고 곱씹어볼 필요성을 느꼈다.

1부 불변의 사실

1-1. 시장 실패의 법칙

시장 실패, 시장 성공이란 무엇인가

설정한 기대치보다 낮은 결과는 모두 실패다. 무언가를 시작하기 전에 자신의 성공 기준을 명확하게 세워 두는 것이 중요하다.

시장 실패의 법칙

시장에 신제품을 출시할 때 여러 결과 중에서 확률이 가장 높은 것이 ‘실패’ 이다. 핵심은 ‘정말 잘, 유능하게 실행’해도 여러 결과 중에서 확률이 가장 높은 것이 ‘실패’라는 것이다. 작가는 개인적으로 그 어떤 신제품 아이디어든 실패 확률이 90퍼센트라고 가정하고 시작할 것을 제안한다.

성공 방정식

결과는 대개 다수의 핵심 요소간의 상호 작용에 따라 결정된다. A x B x C x D = 성공 과 같은 방식으로. 예를 들어 좋은 기획 x 분명히 존재하는 시장 x 편리한 UI x 잘 작동되는 App x 마케팅 = 성공 과 같은 식이다. 실패하려면 다수의 핵심 요소중 하나만 잘못되면 실패할 가능성이 매우 높아진다. 유능하게 실행해도 실패하는 이유는 여러 역사가 증명한다. 코카콜라, 디즈니, 구글 등 업계 최고 전문가들의 수많은 실패사례가 이를 증명한다.

실패의 패턴 FLOP

작가는 수십 명을 인터뷰하며 실패담의 뚜렷한 패턴을 찾았다. 대부분의 프로젝트가 실패하는 이유들은 세 가지인데 FLOP이라는 단어로 기억하기 쉽다.(대부분의 실패(Failure)는 출시(Launch) 또는 운영(Operation) 또는 전제(Premise) 때문이다.)

출시(Launch)는 마케팅과 관련이 깊다. 제품 및 서비스가 훌륭하게 문제를 해결해주고 완벽하게 동작한다고 해도 표적시장이 이 제품 및 서비스의 존재 자체를 모르거나 충분히 알지 못해서 사용해보지 못하는 문제이다.

운영(Operation)은 제품 및 서비스의 퀄리티 문제이다. 디자인이 예쁘지만 기능적으로 모자라거나 아예 부족하다던가, 앱이 자꾸 멈추거나 오래 걸려서 사용하는데 지장이 있는 문제이다. 아이디어가 훌륭하지만 구현을 충분히 못해냈을때 발생하는 문제이다.

전제(Premise)는 표적시장이 해당 제품 및 서비스에 아예 관심을 갖지 않을때 발생하는 문제이다. 표적시장에서 해당 제품 및 서비스가 무엇을 해결하려는지도 알겠고, 매우 잘 훌륭하게 동작해서 문제를 해결해주는 것도 알겠는데 굳이 그걸 사용할 필요나 관심이 없는 경우다.

작가는 이 중 전제(Premise)를 가장 근본적인 실패의 이유로 꼽는다. 처음부터 제품 및 서비스의 아이디어가 잘못된 것이 실패의 가장 근본적인 이유이며 가장 흔한 이유역시 이것이다. 결국 핵심은 ‘될 놈’을 구현하고 전달하는데 집중해야 한다. 이것이 작가가 책을 쓴 동기이자 이유라고 한다. 제대로 만드는 것 보다 더 중요한 것은 ‘될 놈’을 만드는 것이다.

1-2. 될 놈(The Right It)

될 놈, 안될 놈

‘될 놈’ 이란 ‘유능하게 실행할 경우 시장에서 성공할 신제품 아이디어’ 이다. ‘안될 놈’ 이란 ‘아무리 유능하게 실행해도 시장에서 실패할 신제품 아이디어’ 이다. FLOP 에서 정의한 Premise 가 잘못된 것. 아이디어의 기본 전제가 실제 현실의 니즈와 어긋난 것. 잠깐 어떻게 마케팅 등으로 관심을 받더라도 장기적인 성공 가능성은 0인 것.

생각랜드

소위 시장 조사라는 것들은 대부분 실제 시장을 조사한 게 아니라 ‘생각랜드(Thoughtland)’ 라고 부르는 허구의 환경을 조사한 것. ‘생각랜드(Thoughtland)’ 란 모든 잠재적 신제품이 단순하고 순수하고 추상적인 아이디어의 형태로 수명 주기를 시작하는 상상속 공간이다. 이 공간 자체가 잘못된 것이 아니라 여기에 너무 오래 머무르는 것이 문제이다. 제품 및 서비스가 생각랜드에 오래 머무를 수록 의견들이 붙는다. 적극적으로 투자한 것이 아무것도 없는 사람들이 별 생각 없이, 증거도 없이, 막 던지는 추측이 의견이다. 즉흥적 판단, 선호, 예측 과 같은 것들이다.

실패를 부르는 네 마리 요괴(아이디어 전달 문제, 예측력 문제, 적극적 투자가 없다는 문제, 확증 편향 문제)

‘아이디어 전달 문제’는 일종의 소통 문제이다. 제품 및 서비스가 구체적이고 눈에 보이는 형태가 되기 전에는 추상적인 내용에 불과하기에 다른 이에게 전달을 할때 전달의 문제가 발생한다. 설령 상대가 이를 이해 했다고 해도 둘 다 똑같은 것을 인식했는지는 알 수가 없으며, 각자 개인의 맥락 안에서 이를 이해하기 때문에 실질적으로 똑같은 것을 생각하고 있는지 결코 알 수 없다. 그리고 각자의 맥락 속에서 각자 다른 가치판단을 가지고 있기 때문에 판단 역시 달라진다.

‘예측력 문제’는 인간의 예측에 대한 한계를 말한다. 사람들은 아직 경험해보지 못한 어떤 것을 향후에 내가 원하게 될지, 좋아하게 될지, 얼마나 자주 찾게 될지 등에 관해서 아주 형편 없는 예측력을 가지고 있다. 즉, 예측이라는 행위 자체가 무의미한 행위이다.

‘적극적 투자(Skin in the Game)가 없다는 문제’는 이 책의 중심 컨셉이다. 적극적 투자란 결과에 분명한 이해관계를 갖는다는 뜻이다. 적극적으로 투자한 것이 없다면 대부분의 사람은 별생각 없이 의견이나 조언을 내놓는다. 결과가 어떻게 되든 잃는 것도 얻는 것도 없기 때문이다. 저자가 포커스 그룹 방식을 신뢰하지 않는 것도 포커스 그룹 관계자들이 적극적 투자를 하지 않은 상황에서 의견을 내기 때문이다.

‘확증 편향 문제’는 수집한 정보를 해석하는 것과 관련이 있다. ‘확증 편향’ 이란 나의 기존 신념이나 이론과 일치하는 증거를 찾아다니는 반면, 상반되는 증거는 모두 회피하고 무시하려는 우리의 경향을 말한다.

네 마리 요괴가 힘을 합치면 결국 최초의 아이디어가 전달 과정에서 왜곡이 발생하고 왜곡된 아이디어를 각기 다른 맥락으로 들여다보고 판단하며 적극적으로 투자한 것이 아무것도 없는 사람들이 의견들을 마구 내고, 아무런 위험부담을 지지 않는 사람들의 의견을 선별하여 우리가 믿고 싶었던 사항을 재확인하게 된다.

긍정 오류와 부정 오류

긍정 오류는 결국 ‘안될 놈’에 대해서 마치 될 것이라고 착각하고 과도한 투자를 하고 결국 망하는 것을 의미. 부정 오류는 반대로 ‘될 놈’이었는데 안 될 것이라고 생각하고 아이디어를 버리게 되는 것을 의미. 전문가들 조차 ‘그게 되겠어’ 하는 것들이 잘된 것들이 많은데 이런 케이스가 모두 부정 오류 케이스. 전문가들도 부정 오류를 아주 많이, 흔히 일으킨다는 것을 인지하자. 그래서 흔들리지 않고 나의 주관을 가지고 데이터를 믿고 나아가는 것이 중요한 것 같다.

1-3. 생각은 접어두고 데이터를 모으라(Data Beats Opinions)

구글의 핵심 운영 원칙 중 하나가 ‘Data Beats Opinions’. 사람의 의사 결정에는 자신의 주관적 의견과, 선호, 편향이 매우 많은 영향을 미치므로 항상 data based 된 주장을 하는 것이 합리적 의사 결정을 할 가능성을 높여 준다.

여기서 말하는 ‘Data’ 는 몇 가지 조건들이 있다.

(신선함) 데이터는 유효기간이 있다. 데이터가 어떠한 의미를 갖는다는 것은 반드시 그 시장 및 외부 조건들과 같이 반응 했을때 의미를 지니는 것이다. 하지만 외부 조건은 시간이 지날수록 변하기 마련이기 때문에 오래된 데이터는 유효기간이 지나서 의미가 없을 가능성이 있다. 예를 들어 페이지 로딩 시간만 해도 인터넷 초창기는 8초까지 괜찮았겠지만 8초가 2초가 되었고 2초가 0.5초가 되었다.

(확실한 관련성) 해당 데이터가 직접적으로 나의 결정에 적용할 수 있는 것이어야 한다. ‘그래서 뭐? 그게 이거랑 무슨 상관인데?’ 와 같은 의문이 0.1도 들지않고 결합도가 매우 높아야 한다.

(알려진 출처) 이건 데이터의 신뢰성과 관련된 이야기이다. 다른 기업이나 다른 프로젝트를 위해 만들어진 데이터는 해당 목적을 위해 왜곡되고 가공되었을 가능성이 크다. ‘그들의 데이터’ 일 수록 이럴 확률이 높다.

(통계적 유의성) 충분히 큰 샘플을 사용해야 신뢰가 있지, 모수가 작으면 그만큼 우연이 작용했을 확률이 크다.

그들의 데이터

다른 사람이, 다른 프로젝트를 위해, 다른 시기에, 다른 곳에서, 다른 방법과 다른 목적으로 수집하고 편집한 모든 시장 데이터 그들의 데이터를 전적으로 무시하라는 뜻은 아니다. 그들의 데이터에도 배울 수 있는 것이 일부, 어쩌면 많이 있을지도 모른다 요점은 그들의 데이터에 전적으로 의존하지 말고 ‘나만의 데이터’를 쌓으라는 것. 그들의 데이터는 ‘나만의 데이터’를 대체할 수 없다.

‘나만의 데이터’ 를 수집하라

나의 아이디어를 검증하기 위해서 나 또는 우리 팀원이 직접 수집한 시장 데이터. ‘신선하고 관련성 있고 믿을만하고 통계적으로 유의미’ 해야 ‘나만의 데이터’가 될 자격이 이있다. 그들의 데이터가 더 수집하기 쉽지만 나만의 데이터 1g 은 그들의 데이터 1톤의 가치가 있다. 새로운 아이디어가 ‘될 놈’일 가능성이 높은지를 결정할 수 있는 가장 믿을만한 방법이 바로 ‘나만의 데이터’ 를 수집하는 것이다.

2부 쓸모 있는 데이터를 수집하는 방법

2-1. 사고 도구

시장 호응 가설(market engagement hypothesis)

시장이 나의 제품 및 서비스에 어떻게 반응하고 그것을 어떻게 이용할지에 대한 나의 비전. 시장 호응 가설이 옳다면 시장 실패의 법칙에 맞서 싸워볼 기회가 있다.(시장 호응 가설이 옳아야 해당 아이디어가 ‘될 놈’ 일 가능성이 그나마 있다는 것) 시장 호응 가설은 숫자로 표현 되어야 하며 테스트 가능해야 한다. 시장 호응 가설은 아이디어의 기본 전제와 그에 대한 시장 호응에 대한 기대를 짧은 문장으로 표현한 것. 시장이 있다면 반드시 방법은 있다. 정확한 정의를 내리고 해당 시장 수요가 존재한다는 증거를 찾아 내는 것이 시장 호응 가설이 해줘야 할 일이다.

XYZ 가설

적어도 X퍼센트의 Y는 Z할 것이다. X퍼센트는 표적시장의 구체적 퍼센트를 의미한다. (표적 시장의 몇 퍼센트를 차지할 수 있을 것인가?) Y는 제품 및 서비스의 표적 시장을 명확하게 설명하는 말. (우리의 표적시장이 뭘까?) Z는 시장이 제품 및 아이디어에 어떤 식으로 호응할 것 같은지 나의 기대를 의미. (표적 시장은 우리 제품에 어떤 식으로, 정확히 어느 범위까지 호응할까?) XYZ 가설에 사용되는 숫자는 어림수면 충분하다. 숫자가 아니면 문제가 있겠지만 숫자이기만 하면 근사치가 최선이다.

범위 축소

목표는 구체적이긴 하지만 일반적인 가설의 범위를 좁혀 들어감으로써 ‘지금 당장 실행 가능하고 검증 가능한’ 가설을 얻는 것. XYZ 에서 xyz로 가는 방법이다. 범위 축소가 유의미 하기 위한 전제는 xyz 가 참이라면 XYZ 가 참이어야 하는 것이다. 표적 시장 축소(Y -> y)시 너무 적지 않은 표본의 확보와 표적 시장에 대한 표본의 대표성 확보가 매우 중요하다.(MZ 직장인 을 축소하면 blind 유저로 볼 수 있겠다) Z의 축소는 ‘프리토타이핑’ 으로 해결한다.

2-2. 프리토타이핑 도구

프리토타이핑(pretotyping)

pretend + prototype && pre(미리, 먼저) 프로토타입은 용어가 의미하는 바가 너무 포괄적. 예를 들어 수백명이 5년간 작업한 것도 프로토타입이라고 할 수 있다. 그리고 목적이 다르다. 프로토타입은 실제로 구현 가능한지, 어떤 형태가 최적일지 등을 알아보기 위함이고 프리토타입은 아이디어 자체를 검증하기 위한 것. 작가 개인의 실패 경험 및 주변의 실패 경험 모두를 회고하며, ‘프리토타이핑을 적용했다면 제품의 전제가 잘못되었다는 사실을 알 수 있었는가’ 라고 질문했을 때 거의 모든 경우 답이 예스 였다고 한다.

프리토타입 종류

미캐니컬 터크 프리토타입 : IBM 음성 인식 기술 시연시 사람이 박스 안에 들어가서 듣고 하는데, 사용자는 이를 모르게 한 사례. 체스 머신 ‘터크’ 에 체구가 작은 프로 체스 기사가 들어가서 체스를 한 사례에서 유래. 세탁 및 건조 후 기계가 세탁물 접어주는 아이디어 구현 전에 시장 존재 여부를 확인하기 위해 사용자를 속이고 사람이 뒤에서 접어주는 사례.

피노키오 프리토타입 : 팜파일럿 PDA 사례. 실제로 PDA 같은 컨셉의 기기 개발 전에 목재로 만들어서 실제 사용할 일이 있을때 그걸 꺼내서 사용하는 것처럼 스스로 연기를 해보며 실제로 사용할 일이 많은지, 많이 사용하게 되는지 등을 테스트 해보는 것. 시제품을 만들 리소스조차 아끼고 사실 아무 의미 없는 물체를 마치 그 제품인 것처럼 사용하며 데이터를 쌓는 것. 스마트경적 사례.

가짜문 프리토타입 : 개발하지도 않은, 개발 할 예정도 아닌 게임들을 컨셉만 뽑아서 실제로 개발 중인 것처럼 곧 나올 것처럼 광고하고 이메일 등으로 반응을 살펴 시장 존재가 확인된 것만 개발하는 방식. 윤리적 이슈가 있을 수 있는데 헛수고한 사람들에게 보상을 해주면 된다. 앤티크 서점 사례. 문만 만들어두고 노크한 사람의 수, 문 앞에 전단지 읽어본 사람의 수 등의 데이터를 수집. 다람쥐 관찰 책 사례. 사이트만 만들고 우선 예약 받는 식으로 시장 존재부터 확인하는 것.

외관 프리토타입 : 가짜문 프리토타입 변형이다. 가짜문 프리토타입과 외관 프리토타입의 핵심적인 차이는 고객이 구매를 했을때 실제로 고객이 응답을 받는 것이다. 인터넷 차 구매 사이트 열어두고 실제로 구매시 소매에서 사서 손해보고 차 갖다준 사례. 가짜문 프리토타입에서 발생하는 윤리적 문제를 해결할 수 있고, 실제로 한 flow 를 직접 해봄으로써 이것이 실제로 가능한지와 발생할 수 있는 문제들을 미리 겪어볼 수 있다. 그리고 실제 소비자와 접점이 생기기 때문에 인터뷰가 가능하다.(적극적 투자가 이뤄진 고객이기 때문에 인터뷰 답변에 대해서 어느정도 신뢰를 가질 수 있다)

유투브 프리토타입 : 구글 글래스 사례. 영상으로 있지도 않은 제품을 블루프린트를 보여주면서 체험단 모집. 중국 오염탐지기도 유투브로 있지도 않은 제품을 먼저 만들어서 보여주고 반응(적극적 투자를 끌어내는 등) 을 관찰할 수 있다.

하룻밤 프리토타입 : 이벤트성으로 1차적으로 기획해서 실제로 운영해보고 장기적으로 운영하고 비즈니스화 할만큼 시장 존재 확인하는 방식. 에어비엔비 창업자들이 실제로 취한 전략.(결과론적으로 하룻밤 프리토타입이었다)

잠입자 프리토타입 : 이미 발생한 트래픽에 들어가서 시장 존재를 확인. 이케아 잠입 사례.

상표 바꾸기 프리토타입 : 제품 및 서비스 외관을 조금만 바꿔서 새로운 제품이나 서비스로 만드는 것. 책에 나온 초밥 사례.

한입 프리토타입 : 문학 작품 등을 초반만 먼저 공개하고 반응을 보는 것. 마션이 대표적으로 그렇게 했다.

프리토타입의 본질

프리토타입은 적극적인 투자가 있는 ‘나만의 데이터’ 를 생성한다. 프리토타입은 빠르게 수행할 수 있어야 한다. 프리토타입은 저렴하게 수행할 수 있어야 한다.

2-3. 분석 도구

분석 도구

프리토타입들을 이용해서 가설들을 검증하고 ‘나만의 데이터를 확보’ 했다. 이러한 데이터들이 의사결정으로 바뀌기 위해 분석도구를 활용한다.

적극적 투자지표

적극적 투자를 하기 전에는 예상 고객이라고 보면 안되고 그냥 구경꾼 정도로 봐야 한다. 그들은 잃을게 전혀 없어서 말 그대로 ‘막 던진다’ 아이디어에 많은 것을 투자하기 전에 표적 시장으로부터 어느 정도의 ‘적극적 투자’를 이끌어 내야 한다. 적극적 투자지표를 이용해서 표적시장의 반응 유형에 따라 등급을 매길 수 있다. 의견(전문가, 비전문가 모두) 0점, 격려 혹은 비난 0점, 쓰지 않거나 가짜인 이메일 주소나 전화번호 0점, 소셜 미디어의 댓글이나 좋아요 수 0점, 온/오프라인 조사와 투표 및 인터뷰 0점(중요), 제품 업데이트 및 제품 정보 안내에 사용될 것임을 명시적으로 인지한 유효한 이메일 주소 1점, 제품 업데이트 및 제품 정보 안내에 사용될 것임을 명시적으로 인지한 유효한 전화번호 10점, 시간 투자(시연회 30분간 참석 등) 30, 현금 보증금(대기자 리스트 오르기 위한 현금 지불) 50점, 실제 주문 250점

될 놈 척도

아이디어가 얼마나 ‘될 놈’인지 알려주는 척도. 매우 높음, 높음, 50/50, 낮음, 매우 낮음 으로 구성. 화살표 하나 하나가 프리토타이핑 실험을 하면서 그 실험이 구체적으로 어느 성공 확률에 해당하는지를 의미. 화살표의 위치는 곧 실험을 통해 수집한 데이터가 가설을 얼마나 잘 입증하는지 그 정도로 산출. 데이터가 가설의 예측을 크게 상회하면 매우 높음, 살짝 상회하거나 비슷한 수준이면 높음, 가설에 살짝 못미친다면 낮음, 가설의 예측에 크게 못미친다면 매우 낮음. 마지막으로 데이터가 애매하거나 손상되었거나 해석하기 힘들다면 50/50 이거나 폐기. 화살표 하나 하나는 프리토타이핑이지만 각 프리토타이핑은 결국 하나의 아이디어를 실험해보기 위한 장치이다. 즉, 화살표 하나 하나가 아이디어가 각각 조금씩은 다를 수 있고 같을 수도 있다.

어느 정도의 데이터가 필요할까

결과에 대해 확신을 가지려면 여러 번의 프리토타이핑 실험을 실시해서 다수의 xyz 가설의 유효성을 확인해야 한다. 꼭 정답으로 n 번이 정해져있는 것이 아니다. 이 아이디어에 얼마나 많이 투자할 계획인가?, 이 아이디어가 잘못될 경우 잃어도 되는 시간이나 돈은 어느 정도인가?, 의사결정을 내리기 전에 어느 정도의 확실성이 필요한가?, 지금까지의 실험 결과들이 확실한가 불확실한가? 의 질문들을 통해서 추가적인 테스트가 필요한지 아닌지를 판단해볼 수 있다. 저자의 경험상 세번에서 다섯번 정도는 실험을 추천한다. 실험의 횟수는 실패의 파장이나 투자 정도와 맞아야 한다.

3부 유연한 전략

3-1. 전략 도구

생각은 글로벌하게, 테스트는 로컬하게

제품에 대한 글로벌 계획을 가져도 되지만, 그렇게 야심찬 해외 계획의 수립과 실행해 시간을 쓰기 전에 훨씬 작고 접근하기 쉬운 표적 시장의 하위 시장에서 아이디어를 검증해야 한다. 그런 첫 시장은 내가 사는 도시나 동네, 나의 직장이나 학교가 되어야 한다. 테스트 시장은 가까이에 있고 접근이 쉬울수록 좋다.

숫자로 이야기 하라(데이터까지의 거리)

오프라인에서 데이터를 수집한다면 데이터 까지의 거리를 실제 거리단위로 나타내고 그 단위를 최소화 하도록 한다. 단순히 숫자를 줄이는 것이지만 이렇게 하는 것이 결과론적으로 권도균 대표님 책에서 본 것처럼 ‘구체적인 사람들의 구체적인 문제’ 에 접근하게될 가능성이 크다.

내일보다는 오늘 테스트 하는게 낫다

생각랜드에 너무 오래 머무르게 하지 마라.

생각랜드에서 나오지 못하고 오래 머무르는 이유는 두려움 때문이다. 거절당할지 모른다는 두려움, 내가 애지중지 하는 아이디어에 시장이 전혀 관심을 갖지 않는다는 사실을 발견하게 될지 모른다는 두려움 때문이다. 시장과의 접촉을 미루지 마라.

숫자로 이야기 하라(데이터까지의 시간)

데이터 수집까지 걸리는 시간이다. 모든게 같다면 이 시간은 단축시킬수록 좋다. 최대한 빠르게 테스트하고 결과를 얻는 것.(당연한 이야기이다) 저자의 수업에서는 의도적으로 48시간을 준다고 한다.

싸게, 더 싸게, 제일 싸게 생각하라

저자가 생각하는 이상적인 프리토타이핑 예산은 팀원들 점심 피자값이라고 한다. 이건 그냥 비용을 최소화 하면 좋으니까 그런 것 같다. 특별한 이유를 굳이 밝히고 있진 않다. 다만 제약이 있을수록 그 제약 내에서 최대한 방법을 찾게되고 그런 과정에서 창의성이 발휘될 수 있다고는 한다.

숫자로 이야기 하라(데이터까지의 비용)

프리토타이핑 실행에 필요한 비용 (아까 예시로든 팀원들 점심 피자값 같은 실질 수치)

고치고 뒤집고 다 해보고 그만둬라

첫 실험에서 실망스러운 ‘나만의 데이터’가 나왔다고 해서 섣불리 낙담할 필요는 없다. 몇 가지만 손보면 ‘될 놈’이 될지도 모른다. 프리토타이핑이 바로 그렇게 손봐야 할 부분을 찾도록 도와줄 것이다. 보통 최초의 아이디어는 미치지 않은 ‘전제’에 기초하고 있다. 문제는 최초의 아이디어가 그 시장 기회와 가깝기는 해도 정답은 아닌 경우가 대부분이라는 것이다. 그래서 이를 고쳐나가면서 ‘될 놈’으로 바뀌어 나가야 한다. 계란그림 참고. 안될 놈이 될 놈으로 계속된 시도로 바뀌어 나가는 과정.

그래서 최초의 아이디어를 수정하고 바꿔가면서 실험할 필요가 있다. 그리고 이 과정을 거듭할 수록 ‘될 놈’이 될 가능성이 커진다. 그 과정에서 표적 시장에 대해서 몰랐던 사실들을 알게 된다. 하지만 어떻게든 변형시켜 보아도 ‘될 놈’이 아예 존재하지 않을 가능성도 있다.(계란에서 노른자 빠진 그림 참고. 전부다 ‘안될 놈’에 시도들이 있는 그림) 아예 값싼 초밥 자체는 안먹히는 사례에서 고급 포장 초밥으로 전환한 사례.

전면 수정보다는 부분 수정

시장이 정말로 원하는 게 무엇인지 알아내고 그에 맞춰 아이디어를 손볼 유일한 방법은 시장과 ‘진짜’ 접촉을 하는 것. 시장이 뭘 원한다고 ‘생각’하는지 묻기만 할 게 아니라 아이디어의 프리토타입을 시장에 내놓고 관심에 대한 증거로서 어느 정도의 즉각적인 투자를 ‘요구’ 하는 것이다. 고통스러운 피벗보다는 10번의 작은 손질이 낫다.

3-2. 완성 사례 버스 U flow 예시

전체 흐름 정리

  1. 최초의 버스U 아이디어를 설명한다.

  2. 버스U의 시장 호응 가설을 확인한다.

  3. 버스U의 시장 호응 가설을 XYZ 형식으로 작성한다.

  4. 범위 축소를 이용해 빠르게 테스트 가능한 xyz 가설을 만든다.

  5. 가설을 검증할 프리토타이핑 실험들을 찾아낸다.

  6. 데이터까지의 거리, 시간, 비용에 기초해서 실험들의 전략적 우선 순위를 정한다.

  7. 첫 번째 실험을 실시한다.

  8. 실험에서 나온 ‘나만의 데이터’의 객관적 분석에 기초해서 다음 단계를 결정한다.

흐름 도식화

PreviousBusiness ModelNext린 모바일 앱 개발

Last updated 1 year ago