😀
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. 미래를 향해 도전하라
  • 2. 과거에서 배워라
  • 3. 행복한 회사는 모두 다르다
  • 4. 경쟁 이데올로기
  • 5. 라스트 무버 어드밴티지
  • 6. 스타트업은 로또가 아니다
  • 7. 돈의 흐름을 좇아라
  • 8. 발견하지 못한 비밀
  • 9. 기초를 튼튼히 하라
  • 10. 마피아를 만들어라
  • 11. 회사를 세운다고 고객이 올까
  • 12. 사람과 기계, 무엇이 중요한가
  • 13. 테슬라의 성공
  • 14. 창업자의 역설
  1. 기타
  2. Business Model

제로투원

1. 미래를 향해 도전하라

‘수평적 진보, 확장적 진보’는 1 에서 n 으로 확장하는 것. 글로벌화를 의미. ‘수직적 진보, 집중적 진보’는 0 에서 1 로 발명하는 것. 기술을 의미. 저자는 수직전 진보를 더 중요시 한다.

신생기업일수록 수직전 진보를 이루기 용이하다.(관료제적 계급 조직에 비해)

2. 과거에서 배워라

닷컴 버블로 인해 얻은 교훈이 있고, 이것이 스타트업의 세계에서 원칙으로 자리잡고 있지만 저자는 이에 대해 정반대로 생각한다.

  1. 사소한 것에 매달리는 것보다는 대담하게 위험을 감수하는 편이 낫다.

  2. 나쁜 계획도 계획이 아예 없는 것보다는 낫다.

  3. 경쟁이 심한 시장은 이윤을 파괴한다.

  4. 판매 역시 제품 만큼이나 중요하다.

진정으로 남들과 다른 사람은 다수에게 반대하는 사람이 아니라 스스로 생각하는 사람이다.

3. 행복한 회사는 모두 다르다

완전 경쟁 하에서는 경쟁을 통해 모든 이윤이 사라져버린다… ‘지속적인 가치를 창출하고 또 보유하고 싶다면, 차별화되지 않는 제품으로 회사를 차리지 마라.’

독점 기업은 경쟁을 걱정할 필요가 없기 때문에 자신의 직원들이나 제품에 더욱 정성을 쏟을 수 있다. 또 더 큰 세상에 미치는 자신들의 영향력에 관해서도 더욱 관심을 기울일 수 있다.

독점은 진보의 원동력이다. 수년간 혹은 수십 년간 독점 이윤을 누릴 수 있다는 희망은 혁신을 위한 강력한 동기가 되기 때문이다.

하지만 비즈니스는 이와는 정반대다. 행복한 기업들은 다들 서로 다르다. 다들 독특한 문제를 해결해 독점을 구축했기 때문이다. 반면에 실패한 기업들은 한결같다. 경쟁을 벗어나지 못한 것이다.

4. 경쟁 이데올로기

경쟁을 더 많이 할 수록 우리가 얻을 수 있는 것은 더욱 줄어들지만, 오늘날 교육제도에서부터 경쟁을 미화하고 경쟁을 부추기기에 경쟁을 파괴적인 것으로 인식하지 못한다.

경쟁 구도는 해묵은 기회를 지나치게 강조하게 만들고, 과거에 효과가 있었던 것을 그대로 베끼게 만든다.

경쟁 구도에 몰입하는 나머지 새로운 발명과 이에 따르는 기회를 얻지 못하고 현재의 경쟁에 승리하는 것에만 집착하게 만든다는 것.

경쟁자를 이길 수 없고 계속 싸운다면 함께 몰락의 길을 갈 것 같다면 합병 하는 편이 나을 수 있다고 저자는 말함. 예시로 페이팔과 엑스닷컴 이야기.

경쟁을 가치의 표식으로 보지 않고 파괴적인 것으로 인식할 수 있다면, 이미 어지간한 사람들보다는 분별이 있는 것이다.

5. 라스트 무버 어드밴티지

독점 기업의 특징

독자기술

독자 기술이야말로 기업이 가질 수 있는 가장 실질적인 이점이다. 독자기술은 가까운 대체 기술보다 중요한 부분에서 ‘10배’는 뛰어나야 진정한 독점적 우위를 확보할 수 있다.

네트워크 효과

더 많은 사람들이 사용할수록 해당 제품을 더 유용하게 만들어 주는 것. 역설적이게도 네트워크 효과가 필요한 사업들은 특히나 더 작은 시작에서 시작해야한다. (페이스북 하버드 대학생 사이에서 사용된 것 예시)

규모의 경제

결국 규모의 경제가 이루고자 하는 것은 단위 생산당 비용의 절감인데 소프트웨어 스타트업은 그런 측면에서 비용이 제로에 가까워서 아주 적합하다.

브랜드 전략

일반적인 브랜드 전략 외에 저자가 말하는 바는 결국 ‘실질’이 아닌 브랜드에서부터 시작하려는 것은 위험하다는 것.

독점기업 세우기

작게 시작해서 독점화 하라

모든 신생기업이 처음에는 작게 시작한다. 모든 독점기업은 시장을 크게 지배한다. ‘따라서 모든 신생기업은 아주 작은 시장에서 시작해야한다.’ 너무 작다 싶을 만큼 작게 시작하라. 이유는 간단하다. 큰 시장보다는 작은 시장을 지배하기가 더 쉽기 때문이다.

몸집 키우기

틈새 시장을 만들어내 지배하게 되었다면, 관련 있는 좀 더 넓은 시장으로 서서히 사업을 확장해야 한다.

아마존이 책에서 시작해서 다른 품목으로 넓혀한 것이 예시.

파괴하지 마라

신생기업들이 파괴에 집착한다는 것이 결국 구식 회사들의 시각으로 자기 자신을 본다는 뜻과 같음. 저자는 가능하면 경쟁을 피하라고 계속 이야기함.

결론적으로 퍼스트 무버가 되어서 헤매지 말고 라스트 무버로 들어가되 특정 시장에서 훌륭한 발전을 이뤄내어 몇 년간 심지어 몇십 년간 독점 이윤을 누리라고 주장함.

6. 스타트업은 로또가 아니다

4분면 매트릭스를 이용해서 명확한 낙관주의, 불명확한 낙관주의, 명확한 비관주의, 불명확한 비관주의를 설명함. ‘잘은 모르겠으나 이렇게 하면 잘 되겠지’ 하고 특별한 계획없이 막연히 좋은 커리어 밟아 나가는게 불명확한 낙관주의.

결국 핵심은 ‘계획’이다. 장기 비전이 확실하다면 흔들리지 않는 신념으로 나아갈 수 있다. (야후의 페이스북 인수 제안에 마크 저커버그가 고려하지 않은 것 예시)

미래가 제멋대로 펼쳐질거라고 보는 사람들의 세상에서는 훌륭하고 명확한 계획을 가진 회사가 언제나 과소평가 될 수 밖에 없다.

신생기업을 성공시키려면 그 무엇보다 큰 노력이 필요하지만 그 노력은 완벽하게 우리 손 안에 쥐어져 있다… 우연이라는 불공평한 폭군부터 거부해야한다. 우리는 복권이 아니지 않은가.

6장 전체에서 결국 말하고자 하는 바는 ‘운’ 이라는 걸 아예 생각하지 말라는 것. 다 노력과 계획으로 성취할 수 있고, 실패해도 노력과 계획이 부족한 것이라고 생각하자는 것.

7. 돈의 흐름을 좇아라

‘거듭제곱의 법칙’ 에 따라서 회사를 차린다면 회사의 운영 과정에서 ‘거듭제곱의 법칙’을 반드시 기억해야함. 가장 중요한 것들은 오직 하나씩 뿐이라는 것.(모든 면에서) 인재도, 시장도, 제품도 모든게 마찬가지.

시간도, 의사 결정도 모두 거듭제곱 법칙을 따른다. 따라서 어느 한순간은 다른 모든 순간보다 중요하다.

8. 발견하지 못한 비밀

‘발견하지 못한 비밀’ 이란 여러 분야에 적용할 수 있는데 비즈니스에 적용을 해보면 아직 비즈니스화 되지 않은 사업영역이나 아이디어 및 제품, 서비스를 의미한다. 즉, ‘나올거 다 나왔다’ 라고 생각하는게 ‘더 이상 발견하지 못한 비밀은 없다’ 고 생각하는 것이다.

하지만 여러 비즈니스 사례가 이를 증명하듯 ‘발견하지 못한 비밀’ 은 계속 있다. 에어비엔비의 사례만 해도 그렇다. 반대로 HP 는 최고점을 찍고 기업 스스로도 더 이상 ‘발견하지 못한 비밀’은 없다고 생각하여 발전을 하지 못해 가치가 내려앉았다.

저자는 숨겨진 비밀은 찾아다니지 않으면 발견할 수 없다고 하고 있다.

비즈니스의 경우도 마찬가지다. 세상이 어떻게 움직이는지에 관해 누구나 생각할 수 있지만 아무도 미처 발견하지 못한 숨겨진 비밀을 발견할 때 위대한 기업이 만들어질 수 있다.

너무나 간단해 보이는 것을 다시 생각할 수 있는 통찰력만으로도 중요하고 가치 있는 기업을 세울 수 있다면 세상에는 아직도 세울 수 있는 훌륭한 회사들이 많이 남아 있다.

숨겨진 비밀을 찾기에 가장 좋은 장소는 아무도 찾고 있지 않은 장소다. 대부분의 사람들은 배운 대로만 생각한다 … 그렇다면 이렇게 물어 볼 수 있을 것이다. ‘중요하지만 아직 표준화되거나 제도화되지 않은 분야는 없을까?’

9. 기초를 튼튼히 하라

시작이 중요하다는 이야기. 공동 창업자가 있다면 그 관계가 매우 중요하다는 등. 저자 개인적 경험상 CEO 가 급여를 적게 가져가는 회사일 수록 성공확률이 높았다고 함.

10. 마피아를 만들어라

‘기업 문화’ 란 기업 자체와 별개로 존재하는 것이 아니다. 깅버 문화를 ‘가진’ 회사는 없다. 오히려 모든 ‘회사 자체가’ 하나의 기업 문화다. 신생기업이란 같은 목표를 가진 사람들이 하나의 팀으로 뭉친 것이다. 훌륭한 기업 문화란 그것이 회사 내에서 드러난 모습일 뿐이다.

저자가 뉴욕에 있는 로펌에서 일할때의 경험

우리는 이력서를 꼼꼼히 검토하거나 단순히 가장 재능 있는 사람들을 고용해 마피아를 만든 것이 아니다. 그런식으로 접근했을 때 어떤 결과가 나오는지는 뉴욕에 있는 로펌에서 근무할 때 나도 직접 목격한 적이 있다. 내가 함께 일했던 변호사들은 가치 있는 기업을 운영하고 있었고, 한 사람씩 다지면 매우 인상적인 사람들이었지만 이상하게도 그 안에서 서로의 관계는 튼튼하지 못했다. 하루 종일 함께 시간을 보냈지만, 사무실 밖에서는 서로 할 얘기가 별로 없는 사람들이 대부분인 것 같았다.

저자가 페이팔 채용 할 때 경험

… 처음부터 나는 페이팔이 거래 관계가 아니라 단단히 엮인 관계가 되길 바랐다. 나는 사람들 사이의 관계가 튼튼해지면, 단순히 사무실에서만 더 행복하고 잘하게 되는 것이 아니라 페이팔을 넘어 우리의 커리어에서도 더욱 성공할 수 있을 거라고 생각했다. 그래서 청므부터 우리는 실제로 즐겁게 함께 일할 수 있는 사람들을 채용했다. 재능도 있어야 하지만, 특히 ‘우리’ 라는 사람들과 함께 일하는 것을 신나게 생각해야 했다. ‘페이팔 마피아’는 그렇게 시작되었다.

페이팔의 경우 달러화를 대체할 수 있는 새로운 디지털 통화를 만든다는 아이디어에 흥분되는 살마이라면 우리로서는 대화를 해보고 싶었고, 그렇지 않다면 우리가 찾는 사람이 아니었다.

11. 회사를 세운다고 고객이 올까

세일즈 중요성을 강조하는 내용이었다. 특히 엔지니어들은 세일즈를 사기나 정직하지 못한 것으로 보고 힘들고 어려운 일이 아니라고 생각하는 경향이 있지만 저자는 그것이 잘못된 태도라고 말함.

12. 사람과 기계, 무엇이 중요한가

기술 발전은 사람을 대체하는 것이 아니라 상호 보완의 역할을 할 것이라는 저자의 견해가 대다수였다. 예시로 든 페이팔 내 사기 거래 방지 방식은 기술로 필요 탐색을 거친뒤 판단은 사람에게 맡기는 사람-기계 상호모델은 이러한 맥락에서의 성공적인 예시이다.

링크드인 사례도 마찬가지인데 채용 담당자들의 역할을 100% 기술로 대체하고자 한 것이 아니라 채용 담당자들이 일하는 방식을 기술로써 변화시켰다는 점에서 사람-기계 상호 보완적인 사례라 할 수 있다.

13. 테슬라의 성공

청정기술이 주목받던 시기에 대다수의 기업이 망했고, 그 이유는 청정기술이 대체하고자 한 영역에 대해서 가진 우위가 비슷하거나 아주 조금 뛰어나거나 오히려 기존 것보다 못한 수준이었기 때문. 최소 10배는 뛰어나야했는데 그러지 못하였고, CEO 들도 기술중심과는 거리가 매우 먼(책의 표현에 따르면 양복에 넥타이를 매고 다니는) 사람들이었다.

가장 분명한 단서는 옷이었다. 청정기술 기업의 경영자들은 양복에 넥타이를 매고 돌아다녔다. 아주 큰 적신호였다. 진자 기술 전문가들은 티셔츠에 청바지를 입고 다니기 때문이다. 그래서 우리는 ‘창업자가 미팅에 양복을 입고 나타나는 회사는 제외한다’ 라는 일반 규칙을 정했다.

최고의 세일즈는 숨어 있다. 제품을 팔 수 있는 CEO 가 잘못된 것은 아니지만, 실제로 세일즈맨처럼 ‘보인다면’ 세일즈를 잘하는 사람은 아닐 것이고 기술은 더 모를 것이다.

테슬라가 처음에 자신이 지배할 수 있는 아주 작은 ‘고가의 전기차 스포츠카’ 시장에 집중했듯이 작은 시장부터 지배하고 넓혀가야함을 계속 강조한다.

… 하지만 가치 있는 기업이 되려면 틈새시장을 찾아내 작은 시장을 지배하는 데서부터 시작해야 한다. 페이스북은 대학 캠퍼스 하나를 위한 서비스에서 시작해 다른 학교로 전파되고 전 세계로 퍼져나갔다.

14. 창업자의 역설

창업가들의 분포가 일반적인 정규분포를 따르지 않는다는 저자의 주장.

Previous린 스타트업NextMIT 스타트업 바이블

Last updated 1 year ago