사이드 프로젝트를 망치는 3가지 덫: 과몰입, 범위 확장, 그리고 '구조 비교' 함정

왜 내 사이드 프로젝트는 항상 끝나지 않을까

개발자라면 한 번쯤 겪어본 경험이 있을 거예요. 주말에 신나게 시작한 사이드 프로젝트가 몇 주, 몇 달이 지나도 완성되지 않고 점점 무거워지는 상황 말이에요. Kevin Lynagh라는 개발자가 최근 자신의 뉴스레터에서 이런 현상을 아주 솔직하게 풀어냈는데요, 그는 스스로 프로젝트를 망치는 세 가지 패턴을 "과몰입(overthinking), 범위 확장(scope creep), 그리고 구조적 비교(structural diffing)"라고 정리했어요. 이 글은 특히 혼자서 작업하는 인디 개발자나 오픈소스 메인테이너들이 공감할 만한 내용이 많습니다.

핵심 세 가지 덫을 하나씩 뜯어보면

첫 번째는 과몰입이에요. 이게 뭐냐면, 간단한 문제를 푸는데 자꾸 "더 나은 방법이 있지 않을까?" 하면서 본질과 상관없는 구조나 아키텍처에 몇 시간씩 쏟아붓는 걸 말해요. 예를 들어 단순히 JSON 파일 하나 읽으면 되는 작업인데, "나중에 다른 포맷도 지원해야 할지 모르니까" 하고 추상화 레이어를 만들고 플러그인 구조를 설계하기 시작하는 거죠. Kevin은 이걸 "실제로 해야 할 일 대신 '생각하는 일'을 하는 것"이라고 표현했어요. 머리로는 일을 하는 것 같은데 실제로는 아무것도 만들어지지 않는 상태인 거예요.

두 번째는 범위 확장이에요. 원래 하려던 기능 A를 만들다가 "아 그러면 B도 있어야 자연스럽지" 하고, 다시 "B를 만들려면 C도 필요하네" 하면서 계속 일이 불어나는 현상이에요. 처음엔 주말 프로젝트였던 게 어느새 풀스택 SaaS 계획서로 바뀌어 있는 경험, 다들 있으시죠. 여기서 중요한 건 이 확장이 '논리적으로 타당해 보인다'는 점이에요. 그래서 멈추기가 어렵거든요.

세 번째가 가장 흥미로운데, '구조적 비교'예요. 이건 자기가 만든 것과 이상적인 모습을 계속 비교하면서 "아직 부족해"라고 판단하는 습관이에요. 특히 개발자는 깔끔한 코드, 잘 정돈된 아키텍처를 이상으로 삼다 보니, 현재 돌아가는 코드가 못나 보여서 자꾸 뜯어고치고 싶어져요. 문제는 이 비교가 "이 코드는 아직 세상에 내놓을 수 없다"는 변명이 된다는 거예요.

업계에서 이미 알려진 함정들과의 연결

사실 이 주제는 새로운 건 아니에요. 애자일 진영에서 말하는 YAGNI(You Aren't Gonna Need It, 지금 필요 없는 건 만들지 말라) 원칙이나, 린 스타트업의 MVP(최소 기능 제품) 개념도 비슷한 맥락이거든요. Paul Graham의 "Maker's Schedule" 에세이나 Basecamp의 Shape Up 방법론에서도 반복해서 나오는 이야기예요. 하지만 Kevin의 글이 특별한 이유는 이게 '프로젝트 관리 방법론'이 아니라 '개인의 심리적 덫'으로 접근했다는 점이에요. 외부 프로세스로 해결하는 게 아니라, 내가 지금 어떤 덫에 빠져 있는지 자각하는 게 먼저라는 거죠.

비슷한 관점으로 최근 몇 년 사이 John Carmack이나 DHH 같은 개발자들이 "완벽한 추상화보다 동작하는 구체적인 코드"를 강조하는 흐름과도 맞닿아 있어요. 실제로 Rails, Ruby on Rails 생태계가 최근 "No Build" 철학으로 돌아가는 것도 같은 맥락이에요.

한국 개발자에게 주는 시사점

국내 개발 커뮤니티에서도 "기술 블로그 시작하려고 Next.js + MDX + Contentlayer + Vercel 세팅만 3주째"라는 농담 같은 진담이 많잖아요. 이게 바로 Kevin이 말한 '구조적 비교'예요. 진짜로 글을 쓰는 게 목적인데, 블로그 시스템 자체를 완벽하게 만드는 데 에너지를 다 써버리는 거죠.

실무에서 바로 적용할 수 있는 팁을 정리하면 이래요. 먼저 타이머를 걸고 작업하기가 효과적이에요. 25분 안에 실제로 '돌아가는 뭔가'를 만들어내지 못하면 내가 지금 과몰입 상태인 건 아닌지 점검해보는 거예요. 두 번째는 범위를 적어놓고 시작하기. 종이에든 메모 앱에든 "이번 작업에서 할 것, 안 할 것"을 구체적으로 써놓으면 중간에 새로운 아이디어가 떠올라도 "이건 다음 버전"이라고 미룰 수 있어요. 세 번째는 부끄러운 버전으로 먼저 공개하기예요. 완벽할 때까지 기다리면 영원히 못 내놓거든요.

마무리

결국 사이드 프로젝트를 완성하는 힘은 기술력이 아니라 "내가 지금 진짜 일을 하고 있는지, 일하는 척하고 있는지"를 구분하는 자기 인식이에요. 여러분은 어떤 덫에 가장 자주 빠지시나요? 그리고 그걸 어떻게 빠져나오시는지 댓글로 나눠주시면 다른 분들에게도 큰 도움이 될 것 같아요.