만들기 전에 고려해야 할 3가지 제약 조건

• 제품 아이디어는 제약조건을 먼저 걸어야 탐색 공간이 줄고, 너무 복잡하거나 정체성이 없는 결과물로 흐르는 일을 막아줌
• 모든 아이디어는 한 장짜리 one pager로 정리해야 하며, 그 안에 담기지 않는다면 조사, 계획, 프로토타입이 더 필요한 상태로 봐야 함
• 제품과 별개로 살아남을 수 있는 core tech를 함께 만들어야 하며, 방향 전환이 있어도 축적이 이어지는 누적 자산으로 남아야 함
• 사용자에게 계속 드러나는 하나의 defining constraint가 제품 중심에 있어야 하며, 이 제약이 제품의 feel과 정체성을 자연스럽게 규정함
• 세 기준 가운데 하나라도 통과하지 못하면 만들지 않는 태도가 범위 통제와 장기적 레버리지 확보에 중요함

---

만들기 전에 거는 세 가지 제약

• 제품을 만들기 전에 제약조건을 먼저 두면 탐색 공간이 줄어들고, 복잡하거나 정체성이 없는 결과물로 흐르는 일을 막아줌
• 10년간 여러 제품을 만들며 너무 복잡하거나 정체성이 없는 제품이 실패로 이어졌고, 그 시행착오 끝에 세 가지 기준으로 압축됨

• 한 페이지를 넘기면 만들지 않음

  • 모든 아이디어는 one pager로 정리해야 하며, 이 문서는 north star 역할을 함
  • one pager는 타협할 수 없고, 정확하며, 야심 있으면서도 군더더기가 없어야 함
  • 투자자, 기여자, 팀원, 친구, 가족 등 다양한 대상과의 커뮤니케이션에 같은 문서를 쓸 수 있음
  • 협업 중 충돌이 생겼을 때 one pager에 없는 내용은 싸울 가치가 없고, 정말 중요하다면 문서를 고쳐 반영해야 함
  • 한 페이지를 채우지 못했다면 억지로 내용을 불릴 일이 아니라, 아직 만들 준비가 안 된 상태로 봐야 함
  • 그 경우 먼저 조사, 계획, 프로토타입을 거친 뒤 one pager를 다시 써야 함
  • 한 페이지를 넘어갈 정도라면 너무 복잡하므로 만들지 않음

• 핵심 기술은 제품과 분리되어야 함

  • 제품 자체와 별개로, 제품을 떠받치는 core tech를 만들어야 함
  • core tech는 방법론, 기술, 도구, 또는 별도 제품일 수 있으며, 현재 제품이 없어도 살아남아야 함
  • 이런 분리는 제품 하나에 갇히지 않게 만들고, 방향 전환이 있어도 축적이 이어지게 만듦
  • 제품은 자주 방향이 바뀌지만 core tech는 지속적이고 누적적인 자산으로 남음
  • 장기적으로는 이런 누적 노력이 비선형적인 이득을 만들 수 있음
  • 예시로 Linus Torvalds의 git, HashiCorp의 HCL, Google의 Kubernetes가 제시됨
  • 꼭 대기업 수준의 자원이 필요한 것은 아니며, 코드베이스에서 분리한 라이브러리나 계속 다듬는 방법론도 가능함
  • core tech는 제품 방향과는 독립적이어야 하지만, 개인이나 회사의 장기 비전과는 맞아야 함
  • 아이디어가 core tech를 가능하게 하지 못하면 레버리지가 충분하지 않음

• 하나의 결정적 제약이 제품을 규정해야 함

  • 제품의 중심에는 사용자에게 항상 보이는 defining constraint가 있어야 함
  • 이 제약은 사용자가 계속 마주치고 상호작용하는 요소여야 하며, 제품의 정체성을 만듦
  • 좋은 제약은 제품의 feel을 만들고 사용자 경험 전반에 스며듦
  • Minecraft는 블록만으로 구성되고, IKEA는 flat-pack 자가 조립 가구라는 식으로 정체성이 제약에서 바로 드러남
  • 이런 제약은 결정 공간을 줄여 범위를 제한하고, 진짜 중요한 문제에 집중하게 해줌
  • 제약을 고르지 않거나 잘못 고르면 모든 것을 하려는 비대한 제품으로 흐르게 됨
  • 잘 설계된 제약이 있으면 제품 디자인은 그 제약에서 자연스럽게 따라 나오게 됨
  • 이 제약 역시 one pager의 전면에 놓여야 함

마무리 기준

• 세 가지 제약 중 하나라도 통과하지 못하면 만들지 않음

[GN⁺]

Hacker News 의견들

• 이런 걸 나는 product primitives라고 불러왔음
  Notion의 blocks, Telegram의 messages/conversations, Figma의 frames/layers, Twitter의 tweets, Excel의 cells/sheets, Photoshop의 tools/layers, CLI의 commands 같은 것들임

  좋은 제품 디자인은 이런 primitive 수가 아주 적을 때 나온다고 봄
  나쁜 제품은 자기 primitive가 뭔지 모르거나, 너무 많아서 제품 안의 모든 요소가 제각각 따로 노는 느낌을 줌
  그러면 사용자는 서로 다른 최상위 개념을 잔뜩 배워야 해서 헷갈리고 위축되고 가르치기도 어려워짐
  이상적으로는 핵심 primitive가 한두세 개면 충분함

  앱의 복잡성과 힘은 조합 가능한 깊이 있는 primitive를 고르는 데서 나옴
  Notion block, Excel cell, CLI command, Minecraft block처럼 적은 단위로도 많은 걸 할 수 있어야 함

  • 이건 Alexandrian Pattern Language와 닮아 보이지만, 실제로는 pattern보다 Alexander가 나중에 말한 Centers에 더 가까운 듯함

    내가 이해한 바로는 소프트웨어 업계는 그의 pattern을 크게 받아들였지만, Alexander는 말년에 시스템의 궁극적 구성 단위를 Center로 봤음
    밝은 안뜰, 창가 자리, 벽난로처럼 국소적인 유용성과 응집의 초점이 되는 것들임
    강한 center는 자연스럽게 조합 가능하고, 지역적인 긴장을 해소하며, 더 작은 center들로 구성되고, 더 큰 center를 만들어내는 빌딩 블록 역할을 함

    제품이 혼란스럽고 비대해지는 건 대개 의도가 나빠서가 아님
    사용자 요구는 경험적으로 비교적 찾을 수 있지만, 그 요구를 우아하게 흡수할 진짜 중심 구조는 아주 미묘해서 발견하기 어려움
    그래서 눈앞의 요구마다 고유하고 딱딱한 인터페이스를 하나씩 붙이는 쪽이 늘 가장 쉬운 경로가 됨
    그런 요구를 자연스럽게 흡수하는 핵심 primitive를 찾으려면 깊은 아키텍처 작업이 필요함

    그래서 결국 faster horses를 자꾸 만들게 되는지도 모르겠음

  • 예전에는 이걸 concept count라고 불렀음
    제품을 이루는 핵심 개념 수는 보통 최소화하는 편이 좋고, 제품의 nouns and verbs라고 부르기도 했음

  • 이 철학은 좀 과도하게 단순화된 듯함
    Tana는 primitive가 사실상 bullets와 supertags 두 개뿐인데도, 아주 단순한 작업조차 몇 시간짜리 튜토리얼을 봐야 할 정도로 쓰기 복잡함
    반대로 Google Maps는 primitive가 꽤 많아도, 사용 사례의 90%에서는 UX가 꽤 단단하게 잡혀 있음

  • 나는 프로그래밍 언어를 볼 때도 비슷한 기준을 썼음
    언어 규모가 커도 개념적으로 작으면 배운 뒤 나머지는 경험이 누적되며 따라오는데, 개념적으로 큰 언어는 진입 장벽이 컸음
    그걸 강하게 느낀 사례가 perl이었음

  • 작아야 하지만 너무 작아도 안 됨
    대표적으로 shell script(POSIX shell, bash)는 스크립팅조차 command로 모델링해서 새 개념을 도입하지 않으려 했는데, 결과는 다들 알다시피 뜨겁고 느리고 엉망인 혼합물이 됐음

• 세 제약 다 마음에 들지만, 1페이지 문서는 프로젝트 복잡도에 따라 달라져야 한다고 봄
  소규모~중간 규모 프로젝트라면 한 페이지면 충분하겠지만, 화성 비행 제어 소프트웨어라면 구현을 시작하기 전에 수많은 하위 명세로 하이퍼링크되는 one-pager가 필요할 수 있음

  기술과 제품 분리는 정말 현명함
  예로 Skype를 보면, 백엔드의 P2P 통신 기술과 프런트엔드의 호출 애플리케이션이 있었고, 똑똑한 창업자들은 이 둘을 별도 회사에 넣어뒀음
  그래서 프런트엔드 앱인 Skype가 Microsoft에 팔린 뒤에도, 핵심 IP와 P2P 백엔드 기술을 가진 회사는 계속 따로 보유할 수 있었음

  하나의 제약을 중심에 두기도 납득되지만, 나는 가끔 여러 제약이나 우선순위가 있는 목록을 두는 편이 나아 보임
  최상위 원칙이 상업화하기 어렵다면 그걸 불변의 교리처럼 다루는 순간 사업은 파산 쪽으로 몰릴 수 있음
  팀 안에 훨씬 팔기 쉬운 방향으로 크게 pivot할 아이디어가 있다면, 원래와 꽤 달라져도 살 길이 열릴 수 있음
  Twitter도 원래는 다른 걸 하려다 public status update가 곁가지 프로젝트에서 나온 사례였음

• 이 글은 예전에 연구 멘토와 함께 사업을 만들던 방식을 정말 잘 추려냈음

  우리는 먼저 뒤의 두 가지, 즉 핵심 기술과 제약부터 잡았음
  핵심 기술은 sparse data를 위한 임의의 hierarchical Bayesian graph model을 가능하게 하는 sampler였고, 제약은 CPU 바운드에서 계산 가능해야 한다는 것이었음
  가장 오래 걸린 건 최종 제품이 기반 기술과 분리되어야 한다는 사실을 깨닫는 일이었음

  시작 전부터 여러 사람에게 비슷한 조언을 들었지만, 어떤 교훈은 직접 겪어봐야 몸에 남음

  • tenants가 아니라 tenets가 맞음

• one-pager 아이디어가 정말 좋음
  제약을 한 페이지 분량으로조차 명확히 적어낼 시간을 못 쓴다면, 결국 진행하면서 허둥대며 그 제약을 뒤늦게 발견하게 됨
  그리고 그건 버그가 아니라, 아예 우리가 틀린 걸 만들고 있었다는 수준의 결함이 됨

  데이터로 증명할 수는 없지만, 내가 겪기론 모두를 개념적으로 같은 페이지에 올려두는 프로젝트가 훨씬 더 자주 성공했음
  한 장짜리 고수준 문서라도 우리가 무엇을 하고 무엇을 하지 않는지 분명히 해두면 효과가 큼
  반대로 즉흥적으로 밀어붙인 프로젝트는, 자기 생각을 명확히 말하지 않았던 사람들까지 결국 전부 실망하게 되더라

• 저자가 제약이 실제로 작동하는 완전한 예시를 하나 보여줬으면 좋았겠음
  특히 세 번째 항목이 실제로 어떻게 생기는지 잘 감이 안 옴

  • 좀 만들어진 hook처럼 느껴지기도 함
    결국 직접 뭔가 떠올려야 하는 듯함
    Linux의 everything's a file 같은 아이디어는 좋다고 봄
    그런 강한 개념 하나로도 꽤 멀리 갈 수 있음

• 제약은 과소평가되어 있음

  가장 우아한 해법은 보통 무한한 자유도에서 나오는 게 아니라, 분명한 제약을 두고 만들 때 나옴
  그리고 이건 1번 항목과도 연결됨
  one-pager를 작성하는 과정 자체가 그 제약을 정의하게 도와줌

• Google이 Kubernetes를 가진 건, 무엇보다 경쟁자 무력화 목적이 커 보임

• solo SaaS라면 내가 추가할 제약은 이번 주에 베타 사용자 한 명을 찾을 수 있는가임
  시간, 범위, 기술이 one-pager상으로 멀쩡해도 아무도 안 들어오면 프로젝트는 그대로 죽음
  그래서 처음부터 배포/유통 제약을 넣어두니 기능을 깊게 파기 전에 수요층 검증을 하게 됐음

  • 그건 엄밀히는 제약이라기보다 목표나 지표에 더 가까워 보임

• 핵심 기술은 제품과 분리 가능해야 한다는 말이 너무 이르게 추상화하고 디자인 패턴을 남발하게 만들지 않을까 싶음

  물론 관심사 분리, 비즈니스 도메인 레이어를 persistence/network/UI 같은 것과 깔끔히 나누는 건 맞음
  그래도 도메인 레이어는 결국 제품과 아주 강하게 묶일 수밖에 없음
  그건 피할 방법이 없다고 봄

  • 아마 구매자를 끌어들이는 겉면이 있고, 실제로 내부를 굴리는 것은 구매자의 관심사가 아니라는 뜻 아닐까 싶음

    두 층 사이에 인터페이스가 되는 개념 몇 개는 있을 수 있겠지만, 내부가 어떻게 진화하느냐는 바깥 제품층과 분리되어야 한다는 얘기 같음

• 지금 주방 리모델링 설계를 하는 중인데, 이 세 가지 제약이 소프트웨어보다 더 일반적인 디자인 작업에도 꽤 유용하겠다는 생각이 듦

  나도 이걸 바로 해보려 함

  • 사람 공간, 수납 공간, 작업 공간처럼 everything's a space로 잡아볼 수도 있겠음
    너무 단순한가 싶기도 하지만, 공간과 흐름으로 보면 더 재미있어짐
    사람의 흐름, 빛의 흐름, 음식의 흐름, 전환 같은 걸 생각할 수 있어서 꽤 재밌음