Essay 스타트업은 한 곳에 집중하는 것이다

• 스타트업이 제품을 계속 늘리는 가장 큰 이유는 현실의 어려움 때문임
• 자원은 적고, 런웨이는 짧고, 시장 반응은 불확실하니 하나만 붙잡는 게 오히려 더 위험하게 느껴짐
• 그래서 초기 기업은 한 제품이 기대만큼 안 되면 바로 다음 시장, 다음 제품, 다음 파이프라인으로 이동하기 쉬움
• 문제는 그렇게 늘어난 제품들이 전략의 결과가 아니라, 실패를 인정하지 못하고 흩어진 흔적일 때가 많다는 점
• 결국 창업자는 “여러 제품을 조금씩 벌리는 회사”를 만들고 있는지, “큰 회사를 만들기 위해 한 문제를 끝까지 파고 있는지” 스스로 물어봐야 함

왜 초기 스타트업일수록 단순해야 하나?

• 초기 스타트업은 기본적으로 자원이 부족함
• 돈도 부족하고, 사람도 부족하고, 창업자의 경험도 충분하지 않은 경우가 많음
• 그래서 하는 일이 단순해야 함. 제품도 단순하고, 고객도 좁고, 메시지도 한 문장으로 설명돼야 함
• 그런데 현실에서는 반대로 가기 쉬움. 일론 머스크, 워런 버핏 같은 극소수의 성공 사례를 보며 넓은 사업 감각을 먼저 흉내 냄
• 하지만 그들은 수십 년의 시간과 고통을 통과한 사람들임. 이제 막 걷기 시작한 창업자가 달리기와 수영을 동시에 배우겠다고 하는 것과 비슷함

제품 파이프라인은 언제 함정이 되나?

• 어떤 스타트업이 좋은 소재 기술을 만들었다고 해보자
• 기술은 단순하고, 적용 범위도 넓음. 창업자 입장에서는 여러 시장이 보일 수밖에 없음
• 처음엔 하나의 제품으로 시작함. 빠르게 만들고, 시제품도 몇 개 팔림
• 그런데 후속 계약이 잘 안 나옴. 그러면 “시장이 작나?”, “기술이 너무 이른가?”라는 생각이 들고 다음 시장을 두드리게 됨
• 그렇게 제품이 하나씩 늘어나고, 어느새 카탈로그가 생김. 창업자는 그것을 파이프라인이라고 부름
• 하지만 냉정하게 보면 기대만큼 성공하지 못한 제품들의 모음일 수 있음

겉으로 보이는 말	실제로 확인해야 할 것
제품 파이프라인	각 제품이 독립적으로 팔리고 있는가
시장 확장	첫 시장을 충분히 파고들었는가
기술 적용 범위	고객이 실제로 돈을 냈는가
전략적 로드맵	실패한 실험을 포장한 건 아닌가

왜 한 제품을 끝까지 파는 경험이 중요한가?

• 하나의 제품으로 시장을 완전히 공략해본 경험은 창업자에게 큰 학습을 줌
• 누가 고객인지, 왜 안 사는지, 무엇을 바꿔야 하는지, 가격은 맞는지 끝까지 부딪혀야 알 수 있음
• 이 과정을 거치지 않고 다음 제품으로 넘어가면, 창업자는 회피를 성공 방식으로 학습하게 됨
• “이 시장이 안 되면 다음 시장”, “이 제품이 안 되면 다음 제품”이라는 방식이 반복됨
• 물론 이렇게 해도 매출이 나올 수는 있음. 하지만 큰 성과를 만드는 힘은 점점 약해질 수 있음

왜 버티는 회사가 되기 쉬운가?

• 런웨이가 줄어드는 창업자에게 “하나만 더 파보라”는 말은 쉽게 받아들이기 어려움
• 하나만 붙잡는다는 건 나머지 가능성을 포기한다는 뜻임
• 그 하나가 실패하면 회사가 크게 흔들릴 수 있다는 뜻이기도 함
• 그래서 많은 창업자는 여러 제품, 여러 고객, 여러 시장을 붙잡고 버티는 방식을 고름
• 이 방식이 나쁘다는 뜻은 아님. 다만 지금 만드는 회사가 “버티는 회사”인지 “크게 이기는 회사”인지 구분해야 함

제품을 여러 개 만들면 항상 나쁜가?

항상 나쁜 건 아님. 다만 첫 제품으로 시장을 충분히 파보지 않은 상태에서 제품이 늘어난다면 위험 신호임. 새로운 제품이 전략인지, 기존 제품의 실패를 덮는 회피인지 구분해야 함.

왜 초기 창업자는 제품을 줄이기 어렵나?

초기 창업자는 자원이 적고 런웨이 압박이 큼. 그래서 제품을 줄이라는 말이 “가능성을 일부 포기하라”는 말처럼 들릴 수 있음. 하지만 큰 회사를 만들려면 결국 어떤 가능성을 버릴지 정해야 함.

버티는 회사와 큰 회사는 무엇이 다른가?

버티는 회사는 여러 기회를 조금씩 잡으며 매출을 만들 수 있음. 큰 회사는 보통 한 문제를 깊게 파고들어 시장 안에서 강한 위치를 만듦. 둘 다 가능하지만, 서로 다른 게임임.

1인기업 관점

나도 usedesktop이라는 computer-use agent 인프라를 만들면서 이걸 거의 그대로 겪는 중임. 처음에는 모든 의사결정을 LLM이 하는 remote control CUA를 생각했는데, LLM 특유의 nondeterministic 성격 때문에 실제로 쓰면 task completion이 안 되었음. 그래서 deterministic한 로컬 제어와 LLM의 유연함을 섞는 Tauri 기반 로컬 앱으로 바꿨고, 한때는 로컬에서 학습 가능한 앱, B2C용 친숙한 캐릭터 UI까지 가봤음.

그런데 결국 일반 소비자 쪽 PMF는 잘 안 보였고, 지금은 데이터 수집, 정규화, training, eval, RLVF, model deployment까지 이어지는 computer-use agent 인프라 쪽으로 다시 보고 있음. 다만 여기서도 전부 다 하려 하면 또 같은 함정에 빠지는 듯. 피봇은 필요하지만, 피봇을 많이 했다는 사실이 방향이 선명하다는 뜻은 아니니까. 결국 이 전체 흐름 안에서 내가 가장 강하게 잡아야 하는 한 지점을 정해야 할 것 같음.

---

관련: 더 빨리 만들수록 검증은 줄고 기능만 늘어난다와 AI 코딩 시대 MVP 글도 같이 보면 좋습니다.