조용한 사보타주: 왜 대부분의 내 죽은 프로젝트가 과잉 사고로 사라졌는가

Source: Dev.to

소개

Kevin Lynagh는 이번 주에 과도한 고민, 범위 확장, 구조적 차이(diff) 때문에 자신의 프로젝트를 스스로 방해하는 방법에 대한 짧은 에세이를 발표했습니다. 그는 Emacs 단축키만 필요했을 때도 의미론적 차이 도구를 조사하는 데 네 시간을 썼고, Clojure‑Rust 하이브리드와 제약 기반 CAD 도구에 대한 배경 연구에 수백 시간을 투자했지만—둘 다 출시되지 않았습니다. 이 글은 제가 출시하지 않고 죽인 프로젝트 목록을 계속 관리해 온 저에게 강하게 다가왔습니다.

Source: …

죽은 프로젝트의 패턴

• 지난 3년 동안 나는 약 40개의 프로젝트를 중단하고 20개를 출시했다.
• 내가 하나를 출시할 때마다 두 개를 중단한다.
• 시장과 경쟁이 이 프로젝트들을 중단시킨 것이 아니라, 나는 구축하기 전에 너무 많이 생각해서 중단시켰다.

모든 죽은 프로젝트에는 내 노트에 research graveyard가 있다: 틈새 아키텍처 선택에 대한 깊은 읽기, 실제로는 절대 사용하지 않을 라이브러리의 벤치마크, 상태‑관리 패턴의 비교 표—모두 코드를 한 줄도 쓰기 전에 수집한 것이다.

연구 묘지

연구의 깊이는 언제나 불균형합니다. UI 흐름을 그리기 전에 Rust async 런타임을 네 층이나 파고들 수도 있고, 사용자들이 벡터 검색이 필요한지조차 모르는 상황에서 세 개의 벡터 데이터베이스의 지연 시간 트레이드오프를 파악하고 있을 수도 있습니다. 연구가 생산적인 것처럼 보이는 이유는 노트가 가득 차기 때문이지만, 실제로는 똑똑한 변명으로 미루는 행동입니다.

핵심: 가장 작은 배포 가능한 버전보다 연구에 더 많은 시간을 보냈다면, 그것은 연구가 아니라 약속을 회피하는 것입니다.

실제 사례

• Kevin의 선반 프로젝트: 선반을 설계하기 위한 CAD 앱을 만들기 위해 프로그래밍 언어에 수백 시간을 투자했지만, 선반은 절대 만들어지지 않았다.
• 내 분석 뷰: 지난 30일간의 간단한 막대 차트를 원했다. “계획”이 끝날 무렵, 나는 자체 호스팅 Plausible 대안을 위한 문서를 작성하고 있었다. 막대 차트도 OSS 분석 플랫폼도 전혀 배포되지 않았다.

범위가 마일스톤을 생산하기 전에 점점 확대되면, 원래의 필요가 버려진다. 그 버려진 필요는 새로운 범위가 이제 주말 하나에 하기엔 너무 야심차게 되면서 조용히 사라진다. 이미 하루 일도 가지고 있기 때문이다.

The Yak‑Shave Trap

프로젝트를 시작하려고 편집기를 열었을 때 뭔가 어색함을 느낍니다. 토요일 내내 dotfiles를 손보고, 새로운 터미널을 설정하고, 폰트‑렌더링 파이프라인을 다시 구축합니다… 일요일 밤이 되어도 프로젝트의 코드는 한 줄도 쓰지 않았지만, 멋진 터미널을 갖게 됩니다.

야크‑쉐이브는 도구와 관련돼 있기 때문에 실제 작업과 인접해 보이지만, 도구는 그 도구가 가능하게 하는 일이 동시에 진행될 때만 생산적입니다.

Sanity Check

방금 시작한 작업이 프로젝트가 아니고 다음 한 시간 안에 프로젝트를 직접적으로 언블록하지 않는다면, 탭을 닫으세요.

최소 배송 프로세스

이 모든 것은 사전 조사가 필요하지 않다. 작은 쐐기를 선택하고 첫 버전이 예측할 수 없는 방식으로 틀릴 것임을 받아들이는 것이 필요하다.

도구를 현명하게 선택하기

연구를 위해 또 다른 탭을 열려고 할 때, 나는 스스로에게 묻는다:

• 약간 더 못한 도구로도 진행할 수 있는가?
• 의미적으로 정확한 diff 도구가 필요한가, 아니면 git diff를 사용하고 넘어가도 되는가?
• 벡터 데이터베이스가 필요한가, 아니면 처음 1 000명의 사용자를 위해 SQLite 전체 텍스트 검색을 사용할 수 있는가?
• 실제 디자인 시스템이 필요한가, 아니면 Tailwind 기본값을 사용하고 배포해도 되는가?

답은 거의 항상 예이다. 더 못한 도구라도 보통 충분하며, 절약된 시간은 실제 제품 개발에 투입된다.

부끄러움을 신호로

나는 “이걸 올바르게 하는 방법은 무엇인가?” 라는 질문을 그만두고 “유용하게 나를 부끄럽게 만들 수 있는 가장 작은 제품은 무엇인가?” 라는 질문을 하게 되었다.

v0.1이 사용자에게 보여졌을 때 당신을 움찔하게 만든다면, 그 움찔함이 다음에 무엇을 만들어야 할지 알려준다. v0.1이 너무 다듬어져 있다면, 범위를 과하게 잡은 것이며 실제로 중요한 것이 무엇인지 배우지 못한다.

내가 가장 성공한 제품들은 모두 출시 당시 나를 부끄럽게 만들었다:

• theSVG는 카테고리 선두가 10,000개를 보유하고 있을 때 400개의 아이콘만으로 출시했다.
• Stacklit은 더 정교한 방법들이 존재함에도 불구하고 단 하나의 압축 알고리즘만으로 출시했다.
• Glin‑Profanity는 한 언어만을 위해 출시했다.

각각은 첫 번째 버전이 출시되고 사용자가 무엇을 고쳐야 할지 알려줬기 때문에 성공했다.

배운 교훈

• 가장 큰 후회는 시작했지만 끝내지 못한 프로젝트가 아니라, 죽은 것을 인정하기 전까지 조용히 배경에서 8개월 동안 걱정하며 살아있게 만든 프로젝트이다.
• 각각의 8개월 좀비는 매달 주말을 연구와 필기에 소비하게 했으며, 아무것도 생산하지 못했다.
• 만약 여러분이 60일 이상 동안 누구도 사용해 본 적 없는, 배포된 버전이 없는 무언가를 작업하고 있다면, 아마도 끝내지 못할 것이다. 그것을 없애라. 슬픔은 느린 출혈보다 짧다.

과도한 생각이 프로젝트를 방해하는 이유는 생각 자체가 나쁘기 때문이 아니라, 마감일 없이 생각하기 때문이다. 배송 날짜가 없으면 새로운 정보 하나하나가 중요해 보이고, 프로젝트는 인접성에 빠져 허우적거린다.

행동 촉구

작은 것을 만들어라. 나쁜 것을 출시해라. 사용자에게 좋은 것이 무엇인지 말하게 하라.

당신에게 묘지가 있나요? 당신이 출시하지 않은 프로젝트들을 죽인 것은 무엇인가요? 댓글을 열어두었습니다.