멀티 프로젝트 관리법: 동시에 여러 사이드 프로젝트를 굴릴 때의 원칙

1. 여러 프로젝트보다 어려운 것은 ‘전환’이다

사이드 프로젝트를 여러 개 갖는 것 자체가 문제는 아닙니다. 진짜 비용은 프로젝트를 바꿀 때 발생합니다. 이전 코드의 맥락을 다시 읽고, 어디까지 했는지 떠올리고, 다음 할 일을 정하는 데 시간이 듭니다. 이 과정이 반복되면 실제 제작보다 정리와 재적응에 더 많은 에너지를 쓰게 됩니다.

아이디어 수와 진행 중인 프로젝트를 구분하기

아이디어가 많다는 이유로 모두 개발 중으로 취급하지 마세요. 프로젝트는 다음 세 상태 중 하나로만 분류합니다.

메인: 이번 주 작업 시간의 대부분을 쓰는 단 하나의 프로젝트
백버너: 언젠가 만들 수 있지만 현재는 유지 작업만 허용하는 프로젝트
보관함: 아이디어와 자료만 저장하고 당분간 열지 않는 항목

조코헌트에는 지금까지 316개의 프로덕트가 출시됐고, 출시한 메이커는 239명입니다. 이 숫자는 여러 아이디어를 가진 사람이 드물지 않다는 점을 보여주지만, 아이디어의 개수보다 실제로 출시 상태까지 가져가는 운영 방식이 중요하다는 뜻으로 읽을 수 있습니다.

새 아이디어는 ‘시작’하지 말고 기록하기

새로운 생각이 떠올랐을 때 바로 저장소를 만들거나 기술 스택을 고르지 마세요. 제목, 해결하려는 문제, 예상 사용자, 다음에 확인할 질문만 적습니다. 일주일 뒤에도 여전히 중요해 보일 때만 백버너 후보로 검토합니다.

2. 메인 1개 + 백버너 2개의 경계선

메인 프로젝트는 열심히 하는 대상이 아니라, 종료 조건이 있는 대상이어야 합니다. “완성도 높이기”처럼 끝이 없는 표현 대신 “핵심 흐름으로 첫 사용자가 결과를 얻는다”, “랜딩페이지와 기본 피드백 경로를 공개한다”처럼 관찰 가능한 상태를 적으세요.

메인 프로젝트의 종료 조건

시작할 때 다음 세 문장을 작성하면 범위가 크게 흔들리지 않습니다.

이번 사이클이 끝나면 사용자가 할 수 있는 일은 무엇인가?
이번 사이클에서 의도적으로 하지 않을 일은 무엇인가?
출시 또는 공개 후 어떤 반응을 확인할 것인가?

출시 전 범위를 줄이는 방법은 MVP 범위 정하기 같은 글의 원칙과도 연결됩니다. 기능을 더하는 기준이 아니라, 첫 번째 학습을 얻는 기준으로 메인을 운영해 보세요.

백버너에 허용할 작업

백버너는 완전히 방치하는 공간이 아닙니다. 다만 허용 작업을 제한해야 합니다.

아이디어 문서 수정
사용자 문제에 대한 짧은 인터뷰
경쟁 제품이나 대체 방법 조사
메인 프로젝트에서 재사용할 수 있는 작은 실험

새 기능 개발, 전체 디자인 개편, 새로운 도구 학습은 메인 프로젝트가 종료된 뒤로 미룹니다. 백버너에서 코드를 쓰기 시작하는 순간 사실상 또 하나의 메인이 됩니다.

3. 프로젝트 전환 비용을 줄이는 운영 규칙

여러 프로젝트를 병행해야 한다면 의지보다 전환 절차를 표준화하세요. 작업을 끝낼 때 다음 사람에게 넘긴다는 마음으로 기록하면, 그다음 접속 때 재시동 시간이 짧아집니다.

종료할 때 남길 세 줄

매 작업 종료 시 아래만 기록합니다.

현재 상태: 무엇이 동작하고 무엇이 막혔는가
다음 한 걸음: 다시 시작하면 가장 먼저 할 일은 무엇인가
주의점: 재현 방법, 임시 결정, 확인하지 않은 가정

작업 시간 자체를 메인과 백버너로 나누는 방법은 딥워크 vs 얕은 작업의 모드 구분을 참고할 수 있습니다. 메인에는 긴 집중 블록을, 백버너에는 짧은 정리 시간을 배정하면 전환이 덜 무거워집니다.

전환은 달력이 결정하게 하기

“기분이 내키는 프로젝트를 한다”는 방식은 새 아이디어에 계속 끌려가는 구조입니다. 요일이나 시간대별로 프로젝트를 고정하고, 계획에 없는 전환은 메모만 남긴 뒤 다음 검토 시간까지 미룹니다. 갑자기 떠오른 아이디어를 즉시 실행하지 않는 것이 자기 통제의 핵심입니다.

4. ‘하나 출시 전엔 새것 금지’ 규칙의 실제 적용

이 규칙은 모든 코딩을 금지하는 선언이 아니라, 시작 비용이 큰 행동을 막는 장치입니다. 새 저장소 생성, 도메인 구매, 결제 연동, 대규모 UI 작업처럼 되돌리기 어려운 착수를 잠시 보류합니다.

대신 새 아이디어는 문서로만 발전시킬 수 있습니다. 메인 프로젝트가 출시되거나 명확한 중단 결정을 내리면 백버너 후보를 다시 평가합니다. 출시 후 반응을 확인하는 것도 종료 조건의 일부입니다. 조코헌트 데이터에서 출시 첫 24시간 안에 업보트나 댓글을 하나라도 받은 프로덕트는 52%였고, 댓글을 받은 프로덕트는 31%였습니다. 모든 출시가 같은 반응을 얻는다고 가정하기보다, 공개 후 무엇을 배울지 미리 정하는 편이 현실적입니다.

출시 당일의 준비와 관찰 항목은 런치 데이 운영 매뉴얼처럼 별도 체크리스트로 분리해 두면 메인 프로젝트를 ‘완성 직전’에서 계속 붙잡는 일을 줄일 수 있습니다.

5. 이번 주에 바로 적용할 체크리스트

오늘 20분만 투자해 프로젝트 목록을 정리해 보세요.

현재 메인 프로젝트를 하나만 표시했는가?
메인의 종료 조건을 한 문장으로 썼는가?
백버너를 두 개 이하로 제한했는가?
나머지 아이디어를 보관함으로 옮겼는가?
각 프로젝트의 다음 한 걸음을 적었는가?
새 프로젝트를 시작할 수 있는 조건을 정했는가?

여러 프로젝트를 잘 굴리는 사람은 의지가 강해서 모든 것을 동시에 하는 사람이 아닙니다. 지금 집중할 대상을 좁히고, 나머지는 잃어버리지 않도록 안전하게 보관하는 사람에 가깝습니다. 메인 하나를 출시 가능한 상태까지 밀어붙이는 경험이 쌓이면, 다음 프로젝트를 선택하는 기준도 훨씬 선명해집니다.