메뉴
HN
Hacker News 35일 전

제품 개발 전 반드시 세워야 할 3가지 제약 조건

IMP
7/10
핵심 요약

10년 차 개발자가 복잡성과 정체성 부족으로 실패한 경험을 바탕으로, 제품 개발 시작 전 반드시 적용하는 3가지 핵심 제약 조건을 공유합니다. 이 세 가지 제약은 아이디어의 복잡성을 통제하고, 장기적인 자산을 구축하며, 제품의 명확한 정체성을 확립하여 성공적인 제품 개발을 돕습니다. 제약은 창의성을 방해하는 것이 아니라 오히려 문제 해결을 위한 혁신적인 아이디어를 도출하는 원동력이 됩니다.

번역된 본문

제가 무언가를 만들기 전 세우는 3가지 제약 조건 (2026년 4월 7일)

이것은 제가 무언가를 만들기 시작하기 전 사용하는 3가지 제약 조건입니다. 저는 제약이 창의성을 이끌어내는 원동력이라고 믿습니다. 제약은 우리가 탐색해야 할 범위를 좁혀주고, 문제에 대한 혁신적인 해결책을 찾도록 돕습니다. 저는 10년간 제품을 만들어왔지만, 지나치게 복잡하거나 정체성이 없어서 아무런 성과도 내지 못한 제품들도 만들었습니다. 이것은 제가 그런 실수들을 겪은 후 정착한 제약 조건들입니다.

  1. 한 페이지에 담지 못하면 만들지 않는다 이 제약은 복잡성과 모호성을 제한합니다. 여러분의 모든 아이디어에 대해 원페이지(One-pager) 문서를 작성하세요. 원페이지는 여러분의 핵심 목표(North star)를 담아야 합니다. 이것은 타협할 수 없고, 정확하며, 야심 차고, 군더더기 없어야 합니다. 원페이지가 작성되면 모든 형태의 커뮤니케이션에 적용할 수 있습니다. 투자자, 기여자, 팀원, 친구 또는 가족을 위한 메모로 공유하세요. 제품을 협업하다 보면 항상 의견 충돌이 발생하기 마련이며, 어떤 문제에 집중해야 할지 알기 어려울 때가 있습니다. 만약 그것이 원페이지에 없다면, 싸울 가치가 없거나 원페이지를 수정해서라도 그 내용을 포함시켜야 합니다. 원페이지는 소통에 유용할 뿐만 아니라, 여러분 자신의 생각을 정리하는 데도 도움이 됩니다. 한 페이지를 채우지 못한다면 군더더기로 빈칸을 채우지 마세요. 그것은 만들 준비가 되지 않았다는 뜻입니다. 먼저 조사하고, 계획하고, 프로토타입을 만든 다음, 원페이지를 다시 작성하세요. 반복하세요. 만약 한 페이지 이상이 필요하다면, 그것은 너무 복잡한 것이므로 만들지 마세요.

  2. 핵심 기술(Core tech)은 제품과 분리될 수 있어야 한다 이 제약은 여러분을 진정한 영향력과 독창성이 있는 아이디어로 제한합니다. 제품을 지원하지만 제품 자체는 아닌 핵심 기술을 개발하세요. 핵심 기술은 여러분이 현재 하는 일을 지원하지만, 그 제품 없이도 살아남을 수 있는 방법, 기술, 도구 또는 제품이어야 합니다. 이는 일종의 재사용 가능한 지적재산(IP)입니다. 왜 그럴까요? 핵심 기술을 분리하면, 여러분이 만들고 있는 제품 그 이상을 생각하도록 강요받기 때문입니다. 제품은 항상 방향을 바꾸지만, 핵심 기술은 변하지 않으며 복리처럼 누적됩니다. 누적된 노력은 장기적인 관점에서 비선형적인 이익을 창출합니다. 리누스 토르발스는 리눅스 커널 개발 워크플로우를 개선하기 위해 Git을 개발했습니다. HashiCorp에는 HCL(HashiCorp Configuration Language)이 있습니다. 구글에는 Kubernetes가 있습니다. 하지만 핵심 기술을 만드는 데 빅테크의 자원이 필요한 것은 아닙니다. 그것은 코드베이스에서 추출한 라이브러리거나, 여러분이 다듬고 전념하는 방법론이 될 수도 있습니다. 핵심 기술은 장기적인 전념입니다. 그것은 제품의 방향과 독립적입니다. 하지만 여러분 또는 여러분의 회사의 장기적인 비전과 일치해야 합니다. 만약 여러분의 아이디어가 핵심 기술을 가능하게 하지 않는다면, 그것은 영향력이 충분히 크지 않다는 뜻입니다.

  3. 제품을 형성하는 하나의 명확한 제약 조건이 있어야 한다 이 제약은 기능의 무분별한 확장(Feature creep)을 막고, 제품의 정체성을 강제합니다. 여러분의 제품의 가장 핵심이 되는 제약 조건을 정의하세요. 이것은 사용자가 항상 보고 상호작용하는 것을 의미합니다. 그것은 명백하며 제품에 정체성을 부여하는 것입니다. 좋은 제약은 제품에 독특한 느낌을 주며, 사용자 경험의 모든 부분을 스며듭니다. 마인크래프트는 모든 것이 블록으로 만들어집니다. 이케아(IKEA)는 평면 포장된 조립식 가구입니다. 여러분이 선택한 제약은 의사결정 공간을 줄여 범위를 제한하고, 진정으로 차이를 만드는 문제에 집중할 수 있게 해줍니다. 제약을 선택하지 않거나 나쁜 제약을 선택하면, 모든 것을 하려고 하는 부풀려진 제품을 만들게 될 것입니다. 제품의 디자인은 잘 설계된 제약 조건에서 자연스럽게 도출됩니다. 제품과 마찬가지로, 여러분의 제약 조건은 원페이지 문서의 핵심 중심에 있어야 합니다.

마무리 규칙 무엇을 만들지 결정할 때, 아이디어가 이 제약 조건들 중 하나라도 충족하지 못한다면 저는 그것을 만들지 않습니다.

원문 보기
원문 보기 (영어)
3 constraints before I build anything 7 Apr 2026 These are the 3 constraints that I use before I start building anything. I'm a believer in constraints as an enabler for creativity. Constraints help us collapse the search space, and figure out innovative solutions to problems. I've been a builder for 10 years, and I've built products that went nowhere because they were either too complex or had no identity. These are the constraints that I landed on after making those mistakes. One page or it doesn't get built This constraint limits complexity and ambiguity. Write a one pager for all of your ideas. Your one pager captures your north star. It's non-negotiable, precise, ambitious, and lean. Once your one pager is written, it is applied to all different types of communication. Share it as a memo for investors, contributors, team members, friends, or family. Working collaboratively on a product, there will always be contention points and conflict, it can sometimes be difficult to know what battles to pick. If it's not in the one pager, then it's either not worth fighting over, or the one pager ought to be amended to include the thing. Not only is a one pager useful for communication, it's useful for organising your own thoughts. If you can't fill one page, don't fill the gaps with fluff, it means you're not ready to build. First research, plan, prototype, then write the one pager again. Iterate. If it requires more than one page, it's too complex, don't build it. The core tech must be separable from the product This constraint limits you to ideas that have real leverage and originality. Develop a core piece of technology that supports your product and is not the product itself. The core tech is a method, skill, tool, or even product that supports what you're doing today but must survive without it. It's a type of reusable IP. Why? Separating the core tech forces you to think beyond the product that you're building. Products pivot in direction all the time, while your core tech is constant and compounding. Compounding efforts have non-linear gains over longer time horizons. Linus Torvalds developed git to improve the Linux kernel development workflow. HashiCorp has HCL (HashiCorp Configuration Language). Google has Kubernetes. But you don't need big tech resources to build core tech, it could be a library that you extract from your codebase, or even a methodology that you refine and commit to. Your core tech is your long term commitment. It is independent of your product's direction. However, it must be aligned with you or your company's long term vision. If your idea doesn't enable core tech, then it isn't high enough leverage. One defining constraint must shape the product This constraint limits feature creep and forces identity. Define your own constraint that is front and centre to your product. That means the user sees and interacts with it all the time. It is obvious and it is what gives your product identity. A good constraint gives your product a feel , it permeates through all parts of the user experience. Minecraft is built entirely from blocks. IKEA is flat-pack, self-assembly furniture. The constraint that you choose limits scope by reducing your decision space, enabling you to concentrate on the problems that really make the difference. If you don't choose a constraint, or choose a bad constraint, you will build a bloated product that will try to do everything. The design of your product will "fall out" of a well-designed constraint. Like in your product, your constraint must be front and centre in your one pager. Closing Rule When it comes to deciding what to build, if it fails any of these constraints, then I don't build it. Share