첫 프로젝트는 무엇을 만들지보다 어디까지 만들지가 중요하다

처음 프로젝트를 시작할 때는 하고 싶은 것이 많다. 로그인도 넣고 싶고, 추천 기능도 넣고 싶고, 예쁜 UI도 만들고 싶다.

문제는 그 욕심이 자연스럽다는 점이다. 그래서 더더욱 범위를 작게 자르는 기준이 필요하다.

완주하지 못한 프로젝트는 배운 것을 거의 남기지 않는다. 중간에 멈춘 코드는 다시 열리지 않고, 다시 열리지 않는 코드에서는 왜 이렇게 만들었는지도 잊힌다.

완주 가능한 범위를 먼저 정한다

초보자 첫 프로젝트의 핵심은 기술 과시가 아니라 끝까지 만들어 보는 경험이다. 그래서 사용자 한 명이 어떤 입력을 넣고, 어떤 결과를 본다 정도의 한 흐름만 있어도 충분하다.

너무 큰 아이디어는 쪼개면 된다. 예를 들어 가계부 앱을 만들고 싶다면, 첫 버전은 수입과 지출 한 건 저장과 목록 보기까지만 해도 좋다.

주제는 내가 실제로 쓰는 것에서 고른다

무엇을 만들지 정하는 단계에서 대부분 시간을 버린다. 남들이 만든 것 중 괜찮아 보이는 것을 고르려 하기 때문이다. 그렇게 고른 주제는 중간에 막혔을 때 버틸 이유가 없다. 애초에 그 결과물이 필요하지 않았으니까.

그래서 기준은 하나면 된다. 완성되면 내가 한 번이라도 쓸 것인가. 매일 보는 사이트에서 반복해서 복사하는 정보, 손으로 계산하는 숫자, 메모장에 대충 관리하고 있는 목록 같은 것들이 후보다. 규모가 작아도 상관없다. 오히려 작아야 한다.

이 기준의 부수 효과가 하나 더 있다. 내가 사용자면 요구사항을 물어볼 사람이 필요 없고, 무엇이 불편한지 바로 안다. 초보자에게 가장 어려운 것이 무엇을 만들어야 하는지 정하는 일인데, 그 문제가 통째로 사라진다.

한 문장으로 적어 보면 크기가 보인다

범위를 줄이라는 말은 쉽지만 얼마나 줄여야 하는지는 감이 안 잡힌다. 이때 쓸 만한 기준이 하나 있다. 프로젝트를 누가, 무엇을 넣으면, 무엇을 본다라는 한 문장으로 적어 보는 것이다. 이 문장에 접속사가 두 개 이상 들어가면 아직 크다.

SCOPE

[너무 큼]
사용자가 회원가입하고 로그인해서 지출을 입력하면
카테고리별로 분류되고 월별 그래프로 보이며
예산 초과 시 알림을 받는다.

[첫 버전]
사용자가 금액과 메모를 입력하면 목록에 한 줄이 추가된다.

아래 문장에는 접속사가 없다. 그래서 언제 끝났는지 판단할 수 있다.

두 번째 문장이 초라해 보이는 것이 정상이다. 하지만 여기에도 입력 받기, 저장하기, 목록으로 보여 주기가 다 들어 있다. 첫 프로젝트에서 배워야 할 것은 대부분 이 세 동작의 연결 지점에 있다. 기능을 더 붙인다고 새로 배우는 것이 비례해서 늘지 않는다.

그리고 이렇게 잘라 두면 다음 버전이 자연스럽게 생긴다. 목록이 되면 삭제를 붙이고, 삭제가 되면 수정을 붙인다. 하나씩 붙일 때마다 돌아가는 프로그램이 유지된다는 점이 중요하다. 처음부터 전부 만들려고 하면, 완성 전까지는 한 번도 돌아가지 않는 코드를 몇 주씩 들고 있게 된다.

완료 조건을 먼저 쓴다

시작할 때 이 프로젝트는 무엇이 되면 끝인지를 한 줄로 적어 두십시오. 적어 두지 않으면 계속 아이디어가 붙어서, 끝나지 않는 것이 아니라 끝을 정의한 적이 없는 상태가 됩니다.

첫 프로젝트 범위 줄이는 법

핵심 흐름을 한 문장으로 적는다.
그 문장에 접속사가 있으면 뒤쪽을 다음 버전으로 미룬다.
필수 기능과 있으면 좋은 기능을 분리한다.
로그인, 결제, 실시간 기능은 가능하면 첫 버전에서 뺀다.
완료 조건을 시작 전에 한 줄로 적어 둔다.
일주일 안에 데모 가능한 수준으로 자른다.

미루면 안 되는 것도 있다

다만 다 빼라는 말은 아니다. 나중에 붙이기가 유난히 비싼 것들이 있다. 데이터를 어디에 어떤 모양으로 저장할지가 대표적이다. 처음에 메모리에만 담아 두고 나중에 데이터베이스를 붙이겠다고 하면, 그 시점에 코드 대부분을 다시 쓰게 된다. 화면과 저장을 분리해 두는 정도의 구조는 첫 버전에도 두는 편이 싸다.

배포도 마찬가지다. 다 만들고 배포하겠다고 미루면, 배포 단계에서 만나는 문제가 한꺼번에 쏟아진다. 아무 기능도 없는 빈 화면을 먼저 배포해 두고 거기에 기능을 붙여 나가는 편이 훨씬 수월하다.

버전 관리도 같은 부류다. 다 만들고 나서 Git에 올리겠다는 계획은 중간에 코드를 날렸을 때 아무 도움이 되지 않는다. 첫 파일을 만든 날 저장소를 만들어 두는 데는 몇 분이면 충분하고, 그 뒤로는 되돌릴 지점이 계속 쌓인다. 미룰 수 있는 것은 기능이지 안전장치가 아니다.

작게 자르는 것이 답이 아닐 때

이 조언이 어긋나는 경우도 분명히 있다. 이미 두세 개의 작은 프로젝트를 끝내 본 사람에게 또 작게 자르라고 하면, 배우는 것이 없는 연습을 반복하게 된다. 완주 경험이 목적이던 단계를 지났다면, 다음에 필요한 것은 오히려 한 번에 다 안 보이는 크기의 문제다. 구조를 고민하고 중간에 설계를 바꿔 보는 경험은 작은 프로젝트에서는 나오지 않는다.

반대 방향의 오해도 있다. 작게 만들라는 말을 대충 만들라는 말로 읽는 경우다. 범위를 줄이는 것과 품질을 낮추는 것은 다르다. 기능이 하나뿐이더라도 이름을 제대로 짓고, 에러 상황을 처리하고, 다른 사람이 실행할 수 있게 실행 방법을 적어 두는 것까지가 완주다. 그 마무리가 빠지면 작은 프로젝트도 남는 것이 없다.

흔한 이탈 지점

기능이 절반쯤 됐을 때 갑자기 프레임워크를 바꾸거나 디자인을 새로 하고 싶어집니다. 대개 어려운 부분을 만나서 생기는 회피입니다. 그 시점에 무엇에 막혔는지 한 줄 적어 두면 판단이 쉬워집니다.

첫 프로젝트는 멋있어 보이는 것보다 끝까지 가 본 경험을 남겨 주는 것이 더 중요하다.

프로젝트와 성장

더 볼 것

첫 버전을 일찍 배포해 두는 쪽이 왜 유리한지는 한 번의 배포가 바꾸는 것에 따로 적었습니다. 데이터를 어떤 모양으로 담을지 고민된다면 파이썬 컬렉션 가이드부터 훑어보는 편이 빠릅니다.

이 글의 포인트

첫 프로젝트는 완주 가능성이 가장 중요하다.
핵심 흐름을 접속사 없는 한 문장으로 줄이면 크기가 보인다.
저장 구조와 배포는 오히려 일찍 정해 두는 편이 싸다.
범위를 줄이는 것과 대충 만드는 것은 다르다.
완주 경험이 쌓였다면 다음엔 일부러 큰 문제를 잡아도 된다.