지속 가능한 개발 속도 찾기: 단거리 스프린트 대신 마라톤 페이스 설계

빠르게 만드는 능력보다 더 중요한 것은 다음 주에도 다시 만들 수 있는 상태를 유지하는 일입니다. 출시 직전의 밤샘은 당장의 속도를 높여주지만, 이후 며칠을 통째로 잃게 만들 수 있습니다. 1인 개발자에게 필요한 것은 항상 전력 질주하는 일정이 아니라, 회복을 포함한 개발 시스템입니다.

1. 속도가 아니라 회복 가능한 출력이 기준이다

개발 속도를 하루에 처리한 커밋 수나 작업 시간으로만 평가하면 무리한 일정이 정상처럼 보입니다. 대신 “이번 주에 끝낸 양”과 함께 “다음 주에도 이어갈 수 있는가”를 기록해보세요.

조코헌트에 출시된 프로덕트는 378개입니다. 이 숫자는 모든 메이커가 같은 속도와 방식으로 출시하지 않아도, 각자의 리듬으로 결과물이 쌓일 수 있다는 점을 보여주는 맥락으로 참고할 만합니다. 또 출시 첫 24시간 안에 업보트나 댓글을 하나라도 받은 프로덕트는 44%였습니다. 첫날 바로 반응이 오지 않았다고 해서 제품이나 개발자의 노력이 실패했다고 단정하기는 어렵습니다.

밤샘은 속도를 빌리는 일이다

밤샘은 미래의 집중력과 회복 시간을 당겨 쓰는 방식입니다. 특히 혼자 개발하면 코드 작성뿐 아니라 기획, 디자인, 문의 대응, 배포까지 모두 같은 사람에게 돌아옵니다. 한 번의 과로가 여러 역할의 품질을 동시에 낮출 수 있습니다.

좋은 속도의 질문

매주 다음 질문에 답해보세요.

• 이번 주의 작업량은 다음 주에도 반복할 수 있었나?
• 급한 일과 중요한 일을 구분했나?
• 쉬는 동안에도 계속 죄책감을 느꼈나?
• 일정이 밀렸을 때 기능을 줄였나, 수면을 줄였나?

마지막 질문의 답이 계속 수면이라면 속도가 아니라 범위를 조정해야 합니다.

2. 주간 작업량 상한을 숫자로 고정하기

할 일 목록은 끝이 없으므로, 시작 전에 이번 주에 받을 수 있는 작업량의 상한을 정해야 합니다. 직장이나 가족 일정이 있다면 가용 시간을 모두 개발 시간으로 계산하지 말고, 예상치 못한 문의와 오류를 처리할 여유를 남겨두세요.

이번 주의 핵심 작업 고르기

작업을 모두 나열한 뒤 다음 세 묶음으로 나눕니다.

• 핵심: 이번 주가 지나면 제품 상태가 실제로 달라지는 일
• 유지: 버그 수정, 배포, 문의처럼 미룰 수 없는 운영 작업
• 보류: 있으면 좋지만 다음 주로 넘겨도 되는 개선

핵심 작업은 소수만 남기고, 유지 작업을 먼저 일정에 배치하세요. 보류 작업까지 계획에 넣으면 계획이 아니라 희망 목록이 됩니다.

상한을 넘을 때 줄이는 순서

일정이 밀리면 먼저 기능의 범위를 줄이고, 다음으로 완성도를 조정하고, 마지막에 출시 시점을 재검토합니다. 수면과 회복 시간을 줄이는 것은 가장 뒤에도 두기 어려운 선택입니다. 범위를 좁히는 기준은 MVP 범위 정하기 같은 원칙을 참고해 제품의 핵심 약속과 직접 관련 없는 일을 덜어내는 것입니다.

3. 회복일을 일정의 빈칸이 아니라 작업으로 보기

회복일은 일이 남았을 때 채우는 빈칸이 아닙니다. 다음 작업 주기의 품질을 유지하기 위해 미리 확보하는 운영 자원입니다. 완전히 쉬는 날을 만들기 어렵다면, 최소한 코드를 수정하지 않는 시간대와 알림을 확인하지 않는 구간부터 정하세요.

회복일에 해도 되는 일과 안 되는 일

가벼운 산책, 메모 정리, 사용자의 피드백 읽기처럼 긴장도를 낮추는 활동은 괜찮습니다. 반면 “잠깐만”이라며 배포하거나 새 기능을 설계하는 일은 회복일을 다시 업무일로 바꿉니다.

죄책감을 줄이는 기록

회복일 전에는 다음 작업을 적어두세요.

• 다음 개발 세션의 첫 작업
• 중단한 지점과 남은 질문
• 지금은 결정하지 않아도 되는 항목

이 기록은 쉬는 동안 문제를 붙잡고 있지 않게 해줍니다. 하루를 잘 쉬는 것도 제품을 운영하는 일의 일부라는 기준을 팀원이 아닌 자신에게 먼저 설명해야 합니다.

4. 의도적 저속 구간을 운영하기

모든 주를 같은 강도로 운영하지 말고, 일부러 속도를 낮추는 구간을 일정에 넣으세요. 새 기능을 빠르게 추가하는 대신 문서, 테스트, 로그, 정리처럼 미래의 마찰을 줄이는 일을 하는 기간입니다.

저속 구간에는 새로운 약속을 만들지 않는 것이 좋습니다. 이미 시작한 작업을 마무리하고, 자주 발생하는 실수를 기록하고, 다음 가속 구간에서 무엇을 할지 한정합니다. 이 방식은 번아웃이 온 뒤 강제로 쉬는 것보다 조정 폭이 작습니다.

집중이 필요한 개발 시간과 문의·정리 같은 얕은 작업을 나누고 싶다면 딥워크 vs 얕은 작업의 시간 설계도 함께 참고할 수 있습니다. 중요한 것은 도구가 아니라, 고강도 작업이 하루 전체를 점령하지 않도록 경계를 만드는 일입니다.

5. 매주 페이스를 조정하는 15분 회고

주말이나 한 주의 마지막 세션에 짧은 회고를 남기세요. 평가 대상은 의지가 아니라 시스템입니다.

• 실제로 끝낸 작업은 무엇인가?
• 예상보다 오래 걸린 이유는 범위, 의존성, 집중력 중 무엇인가?
• 다음 주에 제거할 약속은 무엇인가?
• 회복을 방해한 신호는 무엇이었나?

답을 바탕으로 다음 주의 상한을 낮추거나, 유지 작업을 먼저 배치하거나, 저속 구간을 추가합니다. 동기가 떨어진 날에도 계속 이어지는 구조를 만들고 싶다면 동기가 식어도 출시되는 사이드 프로젝트 시스템도 도움이 됩니다.

지속 가능한 개발 속도는 느리게만 일하는 방법이 아닙니다. 가속할 때와 멈출 때를 미리 정해, 한 번의 출시가 다음 프로젝트를 망가뜨리지 않게 하는 방법입니다. 이번 주에는 더 많이 하려 하지 말고, 다음 주에도 반복 가능한 양부터 정해보세요.