Jordan Lord(소프트웨어 엔지니어, Footium 등 인디 프로젝트 창작자)이 자신의 블로그에 올린 글 “3 constraints before I build anything” 은 단순합니다. 제약이 없는 빌드는 실패한다. 그가 10년간 너무 복잡하거나 정체성이 없는 제품을 만들며 깨달은 것은, 시작 전에 강제로 통과시켜야 하는 3개의 게이트가 있다는 사실입니다.
원문: 3 constraints before I build anything — Jordan Lord
출발점 — 왜 제약인가
Jordan의 주장은 인디 해커 커뮤니티의 통념과 정반대 방향에서 시작합니다. “무엇이든 빠르게 만들고 시장이 답하게 하라” 가 아니라, “만들기 전에 스스로를 좁혀라” 는 것입니다.
“Constraints collapse the search space.”
이 한 줄이 글 전체의 기둥입니다. 무한한 가능성은 자유처럼 들리지만, 실은 결정 마비와 정체성 부재의 다른 이름입니다. 좋은 제약은 가능한 해법의 집합을 줄여, 남은 공간 안에서 창의성이 압력을 받게 합니다 — 시(詩)의 운율이 의미를 더 정교하게 깎아내는 것과 같은 메커니즘입니다.
Jordan의 회고는 이를 자신의 실패로 증언합니다. 10년 동안 만든 제품들이 너무 복잡했거나, 정체성이 없었거나, 둘 다였습니다. 그가 추출한 3가지 제약은 그 두 실패 모드를 정면으로 겨냥합니다.
제약 1 — The One Pager
규칙: 모든 아이디어는 한 페이지에 북극성(north star)으로 정리되어야 한다.
이 한 페이지는 다음 4가지 조건을 만족해야 합니다.
- Non-negotiable — 타협 불가능한 본질만 남긴다
- Precise — 모호한 수사를 허락하지 않는다
- Ambitious — 야심을 잃지 않는다
- Lean — 군더더기를 쳐낸다
핵심은 마지막 조건입니다. 한 페이지에 들어가지 않으면, 그 아이디어는 너무 복잡한 것이고 만들지 말아야 한다. 이는 단순히 문서 작성 가이드가 아니라 킬 스위치입니다. 한 페이지에 압축되지 않는 비전은, 빌드 단계에서는 더 압축되지 않습니다 — 오히려 폭발합니다.
이 제약의 미덕은 시작 전에 실패를 강제로 드러낸다는 점에 있습니다. 빌드에 한 달을 쓰고 깨닫는 게 아니라, 한 페이지를 쓰는 동안 깨닫게 됩니다.
제약 2 — Core Technology
규칙: 제품을 떠받치지만, 제품 자체는 아닌 핵심 기술 한 조각을 갖출 것.
Jordan은 이 “Core Technology"를 넓게 정의합니다. 방법론, 스킬, 도구, 또는 다른 제품일 수 있습니다. 중요한 것은 형식이 아니라 위치입니다 — 제품의 아래에 깔려 있어야 합니다.
여기서 가장 강력한 통찰은 이 한 줄입니다.
“Products pivot in direction while core tech remains constant and compounding.”
제품은 시장과 부딪히면서 방향을 바꿉니다. 한 번도 피벗하지 않은 제품은 거의 존재하지 않습니다. 그런데 피벗할 때마다 처음부터 다시 시작한다면, 10년 후에도 0년차 창업자입니다.
핵심 기술은 그 사이에서 누적되는 자산입니다. 제품이 A에서 B로 피벗해도, 핵심 기술은 그대로 살아남아 B에서도 작동합니다. 그래서 핵심 기술에 투자한 시간은 비선형적 이득을 만듭니다 — 긴 시간 지평에서 복리로 쌓입니다.
이는 인디 해커가 자주 빠지는 함정에 대한 해독제이기도 합니다. “이번 제품이 안 되면 다음 제품” 이라는 패턴은 핵심 기술 없이 반복되면 그저 무작위 시도의 무한 루프입니다. 핵심 기술이 있으면, 실패한 제품도 다음 제품의 발판이 됩니다.
제약 3 — Product Constraint
규칙: 제품의 전면에 드러나는 자기만의 제약을 정의하라. 사용자가 직접 보고 상호작용하는 명백한 제약 — 그것이 제품의 정체성을 만든다.
이 제약은 앞의 두 개와 결이 다릅니다. 앞의 둘이 창작자를 향한 제약이라면, 이건 사용자에게 보이는 제약입니다.
Jordan의 표현을 그대로 옮기면, 이 제약은 “front and centre” — 전면에 있어야 하고, 사용자가 그것과 상호작용해야 합니다. 숨기는 것이 아니라 드러내는 제약입니다.
왜 그래야 할까요? 정체성 때문입니다. 모든 기능을 다 하는 제품은 아무 정체성도 없는 제품과 같습니다. 가시적 제약은 이 제품이 무엇이고 무엇이 아닌지를 한 번에 전달합니다.
전형적인 예시들 — Twitter의 280자, Vine의 6초, Are.na의 비알고리즘 큐레이션, Things의 todo 외 거부 — 은 모두 이 패턴입니다. 제약 자체가 마케팅 카피이고, 제약 자체가 사용자가 그 제품을 선택하는 이유입니다.
세 제약을 묶는 논리
세 제약은 각각 다른 실패 모드를 막습니다.
| 제약 | 막는 실패 모드 | 작동 시점 |
|---|---|---|
| One Pager | 복잡성으로 인한 좌초 | 시작 전 |
| Core Technology | 피벗할 때마다 0에서 다시 시작 | 빌드/운영 전 구간 |
| Product Constraint | 정체성 부재로 인한 시장 무관심 | 출시 후 |
Jordan이 10년간 겪은 두 가지 실패 — 너무 복잡 과 정체성 없음 — 은 정확히 이 세 제약 중 하나가 빠졌을 때 발생하는 결과입니다. One Pager가 없으면 복잡성이 통제되지 않고, Product Constraint가 없으면 정체성이 생기지 않으며, Core Technology가 없으면 두 실패 사이를 무한히 오갑니다.
한국어 독자를 위한 함의
이 글의 메시지는 한국 인디/스타트업 환경에서 더 날카롭게 작동합니다.
- “일단 만들고 본다"의 한계 — MVP 컬트는 제약 없는 빌드를 미덕처럼 다루지만, Jordan의 진단은 그 반대입니다. 빌드 전에 자기 검열을 강제할 수 있는 사람만이 10년 후에도 같은 자리에 있지 않습니다.
- 피벗의 진짜 의미 — 피벗은 제품 방향의 변경이지 자산의 폐기가 아닙니다. 핵심 기술이 있는 사람의 피벗과 없는 사람의 피벗은 완전히 다른 사건입니다.
- 정체성은 빼기에서 온다 — 무엇을 하지 않는지를 명시한 제품만이 무엇을 하는지가 분명해집니다. Product Constraint는 마케팅 이전에 제품 설계의 의사결정 기준입니다.
결론 — 빌드하기 전에 통과시켜야 하는 3개의 게이트
Jordan Lord의 글은 짧지만, 자기 작업에 적용 가능한 체크리스트로 환원됩니다.
- 이 아이디어를 한 페이지로 압축할 수 있는가? (못한다면 빌드 금지)
- 이 제품 아래에, 제품이 피벗해도 살아남는 핵심 기술이 있는가?
- 사용자에게 전면으로 드러나는, 이 제품만의 가시적 제약이 있는가?
세 질문에 모두 예 라고 답할 수 없다면, 빌드를 시작하지 말아야 합니다. 최고의 엔지니어링은 항상 제약에서 태어난다 — 이 명제는 코드의 추상화에만 적용되는 것이 아니라, 제품 그 자체에도 그대로 적용됩니다.