제 저장소 목록을 열어 이름을 하나씩 세어봤습니다. 시작만 하고 배포까지 가지 못한 프로젝트가 열 개가 넘었습니다. 그중 절반은 로그인 화면까지는 만들어져 있었고, 몇 개는 데이터베이스 설계 문서만 남아 있었습니다. 코드를 다시 열어보니 문제는 실력이 아니었습니다.
공통점이 하나 있었습니다. 전부 처음 상상한 완성본이 너무 컸습니다. 만들려던 것 자체는 단순했는데, 거기에 회원 관리와 관리자 화면과 결제와 다국어가 자동으로 따라붙었습니다. 정작 만들고 싶었던 기능은 그 뒤에 있었고, 거기까지 도달하기 전에 흥미가 먼저 식었습니다.
이 글은 그 반대로 가는 방법입니다. 기간을 2주로 못박고, 거기에 들어가지 않는 것을 전부 잘라내는 순서를 정리했습니다. 2주는 임의의 숫자가 아니라 흥미가 식기 전에 결과를 보는 최대치에 가깝습니다. 적어도 저는 그 이상 끌면 대체로 못 끝냈습니다.
끝나지 않는 이유는 실력이 아니라 범위입니다
개인 프로젝트가 멈추는 지점은 대체로 정해져 있습니다. 어려운 알고리즘 앞에서 멈추는 사람은 드뭅니다. 대신 이런 곳에서 멈춥니다.
- 부수 작업이 본체보다 커질 때: 만들고 싶은 기능은 하루면 되는데, 그걸 감싸는 회원가입과 마이페이지에 일주일이 듭니다. 재미없는 작업이 앞에 놓이면 손이 잘 가지 않습니다.
- 완성 기준이 없을 때: "다 되면 배포"라는 기준은 영원히 충족되지 않습니다. 언제든 손볼 곳이 하나 더 보이기 때문입니다.
- 남에게 보여줄 상상을 먼저 할 때: 아직 아무도 안 쓰는데 트래픽 폭주를 대비한 구조를 고민합니다. 실제로 필요해질 확률보다, 그 고민 때문에 시작이 늦어질 확률이 훨씬 큽니다.
- 기술 선택을 곁들일 때: 안 써본 프레임워크를 이 참에 배워보자고 하면 프로젝트 하나에 학습 곡선이 얹힙니다. 둘 다 하려다 둘 다 못 끝내는 전형적인 경로입니다.
그래서 범위를 정하는 일은 기획 문서를 쓰는 게 아니라 무엇을 안 만들지 목록으로 확정하는 일입니다. 만들 것보다 안 만들 것을 적는 편이 훨씬 빠르게 결론이 납니다.
먼저 잘라내는 다섯 가지
아래는 제가 2주짜리 프로젝트에서 순서대로 걷어내는 항목입니다. 위쪽일수록 미련 없이 잘라도 되는 것들입니다.
- 회원가입과 소셜 로그인: 가장 먼저 자릅니다. 계정 체계를 넣는 순간 비밀번호 정책, 이메일 인증, 비밀번호 찾기, 탈퇴 처리, 개인정보 처리방침까지 줄줄이 따라옵니다. 사용자별 저장이 꼭 필요하면 브라우저 저장소나 공유 링크 방식으로 대체합니다.
- 결제: 두 번째로 자릅니다. 결제는 기술 문제만이 아니라 사업자 등록, 약관, 환불 정책까지 딸린 영역입니다. 유료화 의사가 있다면 "관심 있으면 여기에 이메일을 남겨주세요" 정도로 수요만 확인합니다.
- 관리자 화면: 세 번째입니다. 사용자가 없는 동안 관리할 것도 없습니다. 데이터를 봐야 하면 데이터베이스 클라이언트를 직접 열면 되고, 그것도 로그로 대부분 해결됩니다.
- 다국어: 네 번째입니다. 문자열을 밖으로 빼두는 습관은 좋지만, 번역 파일 구조와 언어 전환 UI까지 2주 안에 넣을 이유는 없습니다. 나중에 필요해지면 그때가 이미 성공한 상태입니다.
- 반응형 완벽 대응: 다섯 번째입니다. 다만 이건 완전히 자르기보다 한쪽만 제대로 만듭니다. 도구 성격이면 데스크톱, 소비 성격이면 모바일 하나만 잡고, 다른 쪽은 깨지지 않는 수준까지만 둡니다.
잘라낸 것들은 지우는 게 아니라 따로 적어둡니다. 파일 하나에 "2차에서 볼 것"이라고 목록을 남기면, 만드는 동안 자꾸 떠오르는 생각을 거기에 던져놓고 넘어갈 수 있습니다. 이 목록이 있는 것만으로 집중이 꽤 유지됩니다.
남길 핵심 한 가지를 고르는 법
다 잘라내고 나면 무엇을 남길지가 문제입니다. 저는 이 질문 하나로 정합니다. "이 서비스를 한 문장으로 설명할 때, 그 문장에 반드시 들어가는 동사는 무엇인가." 변환한다, 세어준다, 모아준다, 이어 쓴다 같은 동사 하나가 나옵니다. 그 동사에 해당하는 기능만 남깁니다.
여기서 판단이 애매하면 반대로 확인합니다. 어떤 기능을 뺐을 때 그 문장이 성립하지 않으면 핵심이고, 여전히 성립하면 부가 기능입니다. 예를 들어 원고 서식 변환기라면 "붙여넣은 원고의 서식을 정리한다"가 문장이고, 변환 규칙 저장이나 사용 기록은 빼도 문장이 성립하므로 부가 기능입니다.
핵심을 정했으면 화면 수로 다시 한번 좁힙니다. 2주 프로젝트의 적정선은 화면 3개 이내입니다. 입력 화면, 결과 화면, 그리고 이 서비스가 무엇인지 설명하는 한 장. 화면이 네 개를 넘어가기 시작하면 그 시점에 이미 범위가 새고 있다고 보면 대체로 맞습니다.
2주를 이렇게 나눕니다
하루에 쓸 수 있는 시간을 2~3시간으로 잡은 배분입니다. 퇴근 후에 만드는 경우를 기준으로 했고, 주말에는 조금 더 쓸 수 있다고 가정했습니다.
구간할 일끝났다는 기준
| 1주차 1~2일 | 한 문장 정의, 안 만들 목록 확정, 화면 3개 스케치 | 종이나 메모장에 화면 흐름이 그려짐 |
| 1주차 3~5일 | 핵심 동사 하나를 코드로 구현. UI 없이 함수와 테스트만 | 입력을 넣으면 원하는 출력이 나옴 |
| 1주차 6~7일 | 가장 단순한 화면에 붙이기. 스타일은 기본값 그대로 | 브라우저에서 내가 직접 써봄 |
| 2주차 1~2일 | 배포 먼저. 도메인 연결과 HTTPS까지 | 남에게 보낼 수 있는 주소가 생김 |
| 2주차 3~4일 | 내가 쓰면서 걸린 부분만 수정. 새 기능 금지 | 메모해둔 불편 목록이 비워짐 |
| 2주차 5~6일 | 설명 페이지, 오류 화면, 기본 로그 | 처음 온 사람이 무엇인지 알아봄 |
| 2주차 7일 | 공개하고 기록 한 편 남기기 | 글이 발행됨 |
이 표에서 가장 중요한 칸은 2주차 1~2일입니다. 배포를 마지막이 아니라 중간에 둡니다. 배포를 미루면 마지막 날에 처음 겪는 문제가 몰려서 터집니다. 반쯤 만든 상태로라도 한 번 올려두면 남은 일주일은 배포 부담 없이 고치는 데만 쓸 수 있습니다.
2주차 3~4일에 "새 기능 금지"를 적어둔 이유도 같습니다. 이 시점이 아이디어가 가장 많이 떠오르는 구간인데, 여기서 하나를 받아들이면 기간이 한 주씩 밀립니다. 떠오른 것은 아까 만든 목록에 적고 넘어갑니다.
마치며
범위를 정하는 일은 무엇을 만들지 정하는 게 아니라 회원가입, 결제, 관리자 화면, 다국어, 완벽한 반응형을 순서대로 잘라내는 일입니다. 남길 것은 한 문장에 들어가는 동사 하나이고, 화면은 세 개 이내이며, 배포는 마지막이 아니라 2주차 초입에 합니다.
오늘 할 수 있는 한 가지는 이겁니다. 만들고 싶은 것을 주어와 동사가 하나씩 들어간 한 문장으로 적어보는 것입니다. 그 문장이 두 줄을 넘어가면 아직 프로젝트가 아니라 여러 개의 프로젝트입니다. 한 줄로 줄어들 때까지 깎는 것부터가 시작입니다.