▲

규모가 되지 않는 일을 하라 (2013)

 (paulgraham.com)
3P by GN⁺ 9일전 | ★ favorite | 댓글 1개
  • Y Combinator는 창업 초기에 '규모화할 수 없는 일' 을 적극적으로 해야 한다고 조언함
  • Stripe, Airbnb 등 성공적인 스타트업들은 초기 사용자 모집에 직접적이고 공격적인 접근을 선택함
  • 대부분의 스타트업은 초기에는 매우 취약하며, 창업자가 직접 뛰는 수고스러움이 성장의 핵심임
  • 초기 사용자에게 탁월한 경험과 만족감을 제공하는 것이 장기적 성장에 중요함
  • 시작 단계에서는 자동화 대신 수작업, 틈새시장 공략, 직접적인 컨설팅 등이 효과적임

서론: 스타트업 성장의 실상

  • 많은 예비 창업자는 스타트업이 저절로 성장한다고 생각하지만, 실제로는 창업자가 직접 나서서 성장의 불씨를 지펴야 함
  • 예전 자동차 시동 손잡이와 같이 초기에는 노동집약적인 과정이 필수적임

사용자 직접 모집 (Recruit)

  • 대부분의 스타트업은 수동적으로 사용자가 찾아오길 기다리지 말고, 직접 찾아 나서는 노력이 필요함
  • Stripe의 경우도 초기에 'Collison installation'이라는 방식으로, 베타 버전을 소개받은 상대의 노트북을 직접 받아 설치하는 공격적인 사용자 확보 전략을 사용함
  • 창업자들이 이러한 일을 꺼리는 이유는 거절에 대한 두려움, 수치심, 적은 사용자 숫자에 대한 저평가 때문임
  • 실제로는 복리 성장의 효과로, 주간 10% 성장만 유지해도 2년 후 수백만 사용자가 될 수 있음
  • Airbnb도 뉴욕에서 직접 호스트들을 찾아가 등록을 도울 만큼 적극적이었음

초기 스타트업의 취약함 (Fragile)

  • 거의 모든 스타트업은 초기에 매우 불안정하며, 단기간의 직접적인 노력으로 성공과 실패가 엇갈림
  • 외부 평론가나 투자자의 무관심보다, 본인 스스로 자신의 사업 가치를 과소평가하는 것이 더 위험
  • 초기에는 '이 회사가 세계를 바꿀까?'가 아닌, '올바른 노력을 했을 때 어디까지 커질 수 있을까?' 를 스스로 물어야 함
  • 예시로 Microsoft, Airbnb의 창업 초기도 겉보기에 매우 미미했으나, 최선의 길이었음
  • 적합한 사용자는 자신과 유사한 사람들에서 출발하거나, 초기 사용자 중 가장 열성적인 층을 파악해 그 집단을 집중 공략해야 함

사용자 기쁨 극대화 (Delight)

  • 사용자 모집뿐만 아니라, 기존 사용자에게 극진한 만족을 주는 비상한 노력이 필요함
  • Wufoo는 신규 가입자마다 손글씨 감사 편지를 보낼 만큼 극적인 서비스로 초기 신뢰를 쌓음
  • 대기업 고객서비스의 상식에 얽매이지 말고, 창업 초기만이 제공할 수 있는 개인화된 경험을 강조할 것
  • 초기 사용자를 기쁘게 하는 일이 지나치게 많아져 감당하기 어려울 정도라면 그것이 오히려 바람직한 성장 신호임
  • 초기 창업자의 고객 서비스 경험 부족이, 작은 회사만의 경쟁 우위를 충분히 살리지 못하는 이유 중 하나임

사용자 경험의 집착 (Experience)

  • 'Insanely great'(광적으로 탁월함) 이라는 Steve Jobs의 표현처럼 초기에는 사용자 경험에 집착할 필요성
  • 초기 제품의 완성형보다는, 불완전하더라도 사용자와의 상호작용을 통한 개선이 더 중요함
  • 사용자와 직접 교감하며 얻는 피드백이 성장에 가장 큰 영향을 미침

시장을 좁혀 시작하기 (Fire)

  • Facebook, Airbnb처럼 처음엔 의도적으로 아주 작은 시장(예: 하버드 학생) 에서 시작해, 그 집단 내에서 임계질량을 달성하는 전략을 활용
  • 가장 반응이 빠른 얼리어답터 집단을 찾는 것이 초기에는 더 효과적임
  • YC 같은 엑셀러레이터 프로그램은 다른 스타트업을 고객으로 삼는 시장 접근에도 유리하게 작용

하드웨어 스타트업의 특수 전략 (Meraki)

  • 하드웨어 스타트업은 초기 대량 생산 비용이 크므로, Meraki, Pebble처럼 창업자들이 직접 제품을 조립함
  • 직접 만들어보며 설계 최적화, 부품 수급 방법 등 경험적 학습이 일어남

컨설팅 방식의 극한 사용자 접근 (Consult)

  • B2B 제품은 특정 한 명의 고객을 위해 컨설팅하듯 맞춤 제작을 진행, 이후 인접 시장으로 확장
  • 고객이 실제로 필요로 하는 문제에 완전히 맞춰보는 과정에서 성장의 실마리가 나옴
  • 초기에는 고객 대신 직접 소프트웨어를 사용해주거나, 필요한 기능을 곧장 반영하는 방법도 있음

완전 수동화 전략 (Manual)

  • 사용자 수가 적을 때는 수동으로 일 처리가 가능하며, 이후 점진적으로 자동화로 전환
  • Stripe는 초기 '즉시 계정 개설'을 수작업으로 처리해 사용자 경험을 전달
  • 처음부터 자동화에 집착하지 말고, 수작업을 통해 제품과 고객의 실제 문제를 파악하는 것이 우선

'대형 런칭'의 비효율 (Big)

  • 한 번에 대대적으로 런칭하거나, 대기업과의 파트너십에 성장을 맡기는 전략은 대체로 실패
  • 초기엔 소수 사용자 확보에 집중해야 하며, 강렬한 노력과 직접적 방법이 더 중요
  • 사용자의 관심은 천천히, 직접적인 관리와 만족 제공을 통해 성장함

스타트업 아이디어의 2차원적 접근 (Vector)

  • 성공하는 스타트업은 제품(무엇을 만들 것인가) + 비규모화 전략(처음에 어떤 일을 직접 할 것인가) 의 벡터로 생각할 필요
  • 이렇게 초기의 직접 행동이 제품 DNA에 긍정적 영향을 남김
  • 초기 직접적 노력은 시간이 지나 제품, 조직 문화로 전환되어 지속적인 성장의 원동력이 됨
▲
GN⁺ 9일전  [-]
Hacker News 의견

  • 내가 최근에 들은 팟캐스트 내용 중 정말 공감했던 말이 있었음: 스타트업에 가장 큰 문제는 관성이라는 점임. 세상은 우리를 별로 좋아하지도 않고, 필요하다고 느끼지도 않음... 우리는 그걸 뒤집어야 함. 완전히 처음부터 모멘텀을 만들어야 하고, 창업자가 해야 할 진짜 중요한 일은 관성을 역전시키는 행동임. 이건 물리적으로도 실제로 일어나는 일임. 세상은 멈춘 상태로 있고, 우리는 처음 시동을 거는 것처럼 모멘텀을 직접 만들어야 한다는 이야기임. 이런 관점에서 보면, 처음에는 확장성 없는 일을 해도 이상하지 않음. 이미 돌아가는 기계를 최적화하는 게 아니라, 엔진이 제대로 돌기 시작하게 하나하나 돌려봐야 하는 단계임. Paul Graham의 포인트는, 확장 가능한 성장이나 자동화는 그다음 문제라는 점임. 수동적인 접근으로 사용자 한 명 한 명을 직접 만나야 진짜로 무엇이 통하는지 배울 수 있음. 사용자가 나를 필요한 존재로 여긴다는 증거를 쌓으면서, 무엇이 확장할 가치가 있는지 입증하는 과정임

    • 내가 생각하기에 수작업의 진짜 가치는 직접 배운다는 것임. 내 고객 중 한 분은 주간 중요한 금융·증권 뉴스를 직접 선별해서 큐레이션된 리스트로 제공했음. 작은 니치 안의 또 다른 니치였는데, 사용자가 정말 좋아했음. 그런데 어느 순간 전부 자동화하려고 하면서 콘텐츠가 선별성 없이 많아지고 스팸성 정보도 늘어가면서 가치가 사라졌고, 결국 제품 자체도 같은 길을 걸음. 더 많은 뉴스를 담았지만, 직접 선별·편집하지 않으니 신호와 잡음의 비율이 더 나빠졌음. 실제로 수작업이 범위는 제한적이어도 훨씬 더 가치 있었음. 많은 회사들이 그걸 이해하지 못하고 너무 일찍 자동화에만 집착함. 또 다른 예시로, 경쟁사 가격을 수작업으로 체크하던 클라이언트가 있었음. 자동화를 원해서 엑셀 기반의 간단한 스크래퍼를 만들었음. 처음엔 만족했지만, 직접 경쟁사 사이트를 탐색하다가 신제품, 카탈로그 트렌드 등을 배우는 기회를 놓치고 있다는 걸 나중에야 알게 됨. 결국 다시 수작업으로 탐색하고, 스크래퍼는 단순한 가격 분석에만 사용함. 하지만 내 다른 고객 대부분은 제품과 문제의 본질보다는 자동화에만 신경 써서 중요한 학습 기회를 계속 놓치고 있음

    • 그래서 “사람들이 원하는 것을 만들어라”라는 말이 스타트업 업계 명언인 이유임

    • “관성을 역전시키는 일”이라는 표현이 정말 마음에 들었지만, 이 접근이 모든 스타트업에 적용되는 건 아님. Sequoia의 Arc 프레임워크에 따르면 세 가지 방식이 있음: Hair on Fire(시급한 고통, 모멘텀이 중요), Hard Fact(고통을 갖고 있지만 습관을 바꿔야 하는 경우), Future Vision(사람들이 아직 그 일이 가능하다고 믿지 않으니 신뢰부터 쌓아야 하는 경우). 확장되지 않는 일을 직접 해서 성과를 얻는 건 Hair on Fire 분야에선 필수지만, 나머지는 현실 자체를 재구성하거나 공신력을 먼저 만들어야 하는 식임

  • 내 이론은 세 단계로 나눌 수 있음: Not Scaling(확장 전), Scaling(확장), 그리고 Antiscaling(비호감 단계). Not Scaling은 시장에서 자기만의 해자(moat)를 구축하는 단계임. Scaling은 제품이 충분히 인기를 얻어 고객이 새로운 고객을 불러오고, 서버나 DB 쪼개기를 해서 증가하는 수요만 처리하면 되는 시점임. Antiscaling은 현대 웹의 문제점이 된 기업처럼 변할 때임. 정보기관이 테러리스트 이용 문제로 연락해오고, 시청이나 정부가 라이선스나 규제 법을 직접 만들어 타겟팅하는 단계임. 창업자가 유명해져 밈이 돌고 위치 추적도 되는 상황임. 세상을 지배할 필요는 없고, 돈을 벌면 됨. 세상을 바꾼다고 나서는 사람치고 실제로 좋은 결과가 나오는 경우가 드물기에, 그냥 쓸만한 무언가를 만드는 게 중요함

    • "그냥 돈을 벌면 된다"는 말은, 어떤 지표(예: 수익)가 목표로 바뀌면 그 지표는 좋은 측정값이 아니라는 Goodhart’s Law를 떠올리게 함

    • 이 관점이 너무 편향됐다고 느껴짐. 아무도 원하지 않는 걸 만들었을 때의 극도의 무관심은 여기서 다루지 않음. 그리고 사실 더 흔한 경우는, 아주 평범하게 조금만 성공한 사례임. 아무도 싫어하지 않고, 그렇다고 미치게 사랑하는 사람도 없음. 약간 긍정적이지만, 하이프나 독점적 경쟁력 없이 아무도 딱히 신경쓰지 않는 케이스가 제일 많음

  • 관련 사례를 더 모으고 싶어서 아래 링크를 남김

  • 모든 초기 창업자와 초기 멤버로 합류한 직원 모두에게 추천하고 싶은 내용을 공유함. 우리는 15명 넘는 규모가 됐는데도 매번 신규 가입자마다 직접 전화를 걸고 있음. 그 이유는 1) 어떻게 우리를 알게 됐는지 2) 처음 쓰는 데 도움이 필요한지 3) (암묵적으로) 우리 팀이 직접 신경 쓰고 있다는 걸 전달하기 위함임. 우리 서비스는 B2B 플랫폼이라서 더 잘 작동하는 것 같고, 대상이 개발자인데도 막상 전화해보면, ‘아니, 판매 전화를 하려는 거 아니에요’라는 점만 지나면 정말 솔직하고 좋은 얘기가 많이 오감

  • Paul Graham을 비판하는 목소리가 많은데, 이 글 자체는 프리머추어 옵티마이제이션(너무 이른 최적화) 하지 말라는 요지로 요약할 수 있음. 즉, 덩치 큰 기업처럼 굴지 말라는 뜻임. 창업자가 직접 실무를 해보면 비효율적이더라도 실전 경험과 피드백을 쌓을 수 있고, 확장 가능한 솔루션을 애초에 빠르게 도입하지 않음으로써 빨리 피드백을 받아볼 수도 있음. 그리고 나만의 차별화를 만드는 데도 효과적임. “확장되지 않는 일을 하라”는 말을 글자 그대로 머릿속에 새겨 두면 좋을 것 같음

    • 과도한 인기나 수요 때문에 서비스를 못 견디고 무너질까 걱정된다는 이유로, 실제로 필요가 전혀 없는 단계부터 지나치게 확장할 수 있는 시스템을 만드는 경우가 많음. 그런데 나는 수직적 확장(리소스만 더 추가하는 방식)이 지나치게 과소평가 받는다고 느낌. 기존 모놀리식 백엔드에 자원만 더 투입해도 서비스에 대해 제대로 이해할 시간은 벌 수 있음. 무엇보다, 실제로 사용자가 우리 제품에서 좋아하는 ‘핵심 가치’가 뭔지 재고해보게 됨. 또, 사용자가 정말로 우리 제품을 사랑하면, 초기엔 약간 성능이 부족해도 이해해줌. 트위터 초기에 “fail whale”이 자주 떴지만, 원하는 기능만 제대로 됐기에 폭발적으로 성장했음. 초기 단계는 빠른 피드백과 반복, 그리고 고객 만족이 전부임. 확장보다 실험, 사용자 소통, 관찰이 먼저임. 딱 촉이 올 때 그때 확장 고민을 하는 게 맞고, 그 시점은 예측할 수 없음. 기술은 도구일 뿐이고, 명품 바이올린이 있더라도 무엇보다 ‘좋은 음악’부터 만들어야 함

    • 모든 성공적인 사업이 수백만, 수십억 사용자를 대상으로 하는 건 아님을 명심해야 함. 나는 내부 툴을 만드는 일을 하는데, 우리 환경의 규모는 이미 정해져 있고, 퍼포먼스에 크게 민감하지도 않으며 불규칙 트래픽도 없음. 그런데 우리 팀원 중 오직 몇 밀리초 줄이려고 혼자만 아는 언어로 전체 코드를 갈아엎는 데 집착했던 사람이 있었음. 아무도 신경 쓰지 않고, 그가 구축한 건 유지보수 위험만 남겼음. 그가 퇴사하자 관리자 판단 하에 싹 폐기했는데, 더 단순하고 느린 설계였으면 다른 사람도 인수인계받기 훨씬 쉬웠을 것임

    • “프리머추어 옵티마이제이션”과 “Do Things That Don’t Scale”은 미묘하게 다름. 전자는 확장 가능버전이 ‘최적’임을 전제하는데, 후자는 확장 불가능한 방식이 오히려 최고일 수 있다는 시사임. 예를 들어, CEO가 직접 연락처를 맡아주는 방식이 모든 걸 처리하는 공유 인박스보다 훨씬 낫다는 식임. 확장되는 방식(문의 폼)은 처음부터 최적화된 게 아니라, 실제로는 프로세스 품질 저하임. 스케일링 자체가 악임은 아니지만, 어쩔 수 없이 따라오는 복잡성과 고객과의 거리감이 큼. 상황에 따라 프로세스가 나빠질 수 있음을 인지해야 함. 내 생각엔 “프리머추어 프로세스 열화 방지”에 더 가까운 메시지임

    • 결국 "아직 없는 문제를 미리 풀려 하지 마라"로 요약할 수 있음

    • “큰 기업처럼 행동하지 마라”는 조언은 솔직히 모든 규모의 조직에 다 적용됨. 나는 컨설턴트로서, 스타트업이나 중소기업이 법인이라는 이유만으로 덩치 큰 조직의 규칙·정책을 도입하려 할 때마다 그걸 막는 데 많은 시간을 씀. 그런 정책들은 수백 명 규모에서나 필요한데, 작은 조직에서는 오히려 발목을 잡음. 예를 들면 k8s, nosql, 필요 이상으로 엄격한 보안정책 등이 있음. Netflix 사내 문화 가이드도 이걸 잘 보여줌. 작은 조직이라면 채용을 잘했다는 전제 하에 진짜 권한 위임을 하고, 팀원 각자가 판단할 수 있게 해야 함. 문제나 리스크가 실제로 커질 때까지는 굳이 모든 걸 규정으로 가둘 필요 없음

  • Stripe는 YC 포트폴리오 중 가장 성공적인 회사 중 하나인데, Stripe가 해결한 문제는 정말 급박하고 시급한 문제였음. 누구도 유저를 기다리는 쪽으로 나갔을 법한 상황에서, Stripe는 오히려 매우 공격적인 유저 확보로 유명했음. 그때가 12년 전이었고, 이 정도까지 크게 성장할 줄 몰랐음. 그때 투자할 수 있었으면 정말 좋았을 것임

  • 물론 생존자 편향(survivor bias)이 있는 건 사실임. 하지만 직접 일을 해보고 자동화하지 않는 시기 자체가 중요하다는 포인트는 완전히 공감함. 그렇게 해야 전체 프로세스나 시스템을 더 정교하게 머릿속에 새길 수 있는데, 이건 단순한 슬라이드나 문서로는 불가능함. 그리고 요즘 말로는 ‘테이스트’를 쌓는 과정이라고 부를 수 있음. 좋은 게 뭔지, 왜 그런지 직접 감각이 생기고, 남들은 고민조차 하지 않는 의사결정 지점에서 뚜렷한 관점을 잡아가는 시기임. 요즘 AI가 있으니 너무 빨리 자동화로 건너뛰려는 곳이 많은데, www.socratify.com에서도 콘텐츠는 직접 수작업으로 만들고 있음. 모두가 AI로 만들어야 한다고 하지만, 우리는 문맥과 품질을 제대로 큐레이션하려고 함이 주 목적임. 검증 프로세스는 추후에 어느 정도 자동화할 수 있지만, 인간의 두뇌와 통찰을 완벽하게 대체하긴 무리라는 걸 실제로 많이 간접 체험하고 있음

  • YC가 시드 펀딩을 훨씬 쉽게 만든 덕분에 판이 바뀌었음. Paul Graham, Jessica Livingston, YC 팀이 기존 시스템의 문제를 제대로 보고 고쳤다고 확신함. YC 나오기 전엔 시드 펀딩이 거의 불가능할 정도였음. 불평등하고, 마치 오래된 은행 사무실에서 화난 파트너 8명을 상대로 발표하는 기분이었음. 공이 있다면 제대로 인정해야 하기에, 이 시장을 고친 건 그들임

    • 이 부분은 논란의 여지가 있다고 생각함. 더 많은 사람들에게 펀딩이 열렸다고 해도, 사실 YC 이전이나 이후나 시딩 자체는 여전히 어려움. 차이점은 YC처럼 규모 큰 플레이어가 생기면서 자가수혈(bootstrapping) 창업자의 입지가 더 약해졌다는 점임. 어느 순간부터 창업자가 진짜로 원하는 것도 아니고, YC가 고르는 주제만 따라가는 상황이 생김. 창업자가 스스로 숙련하고 싶은 걸 할 기회가 줄었음

  • OpenAI 같이 큰 회사들이 “Do Things That Don’t Scale”을 진지하게 읽고, 실제로 참고했으면 하는 바람이 있음. 그 정도 자본이면 필요한 데이터 라이선스를 정당하게 샀을 수도 있었을 것임. 하지만 이들은 확장되는 방식(scraping, stealing)만을 택했고, 슬쩍 많이 뺏어 써도 결국에는 모르거나, 뒤늦게 문제 제기가 날아오길 바란 듯함. 지금의 콘텐츠 제작자들이 알지 못하게 AI 훈련 데이터로 쓰인 대가를 한 푼도 못 받는 상황이 그냥 지나가길 바란 셈임

    • 이건 스케일링 문제라기보다, 자본주의에서 필연적으로 ‘돈 안 쓰려는 욕심’과 더 밀접하다고 봄

  • 이 글이 Hacker News에서 처음 본 글이었음. 가끔 다시 올라올 때마다 옛 추억이 살아남

답변달기