처음 100일, 무엇을 배우고 무엇은 미뤄도 될까

날짜가 아니라 끝났다고 확인할 수 있는 것으로 나눕니다

흔한 로드맵은 “1주 차 변수, 2주 차 조건문”처럼 시간표로 되어 있습니다. 이 방식의 문제는 진도를 나갔는지 아닌지를 판단할 방법이 없다는 점입니다. 영상을 다 봤으면 끝난 것인지, 예제를 따라 쳤으면 끝난 것인지가 애매하니, 대개는 “봤으니 아는 것”으로 넘어갑니다. 그리고 한 달 뒤 빈 파일 앞에서 아무것도 못 쓰는 상태로 돌아옵니다.

대신 각 구간의 끝을 남에게 보여 줄 수 있는 물건으로 정의하면 판정이 단순해집니다. 파일이 있으면 끝난 것이고 없으면 안 끝난 것입니다. 아래 네 구간의 주차는 참고용 순서일 뿐이고, 실제로 중요한 것은 각 구간에 붙은 산출물입니다.

1구간 — 혼자 돌릴 수 있는 스크립트 (대략 1~2주)

산출물은 파일 하나입니다. 터미널에서 python hello.py 같은 명령으로 실행되고, 무언가를 출력하고, 오류가 나면 그 메시지를 읽고 스스로 고칠 수 있으면 이 구간은 끝입니다. 여기서 다루는 것은 변수, 조건문, 반복문, 함수 정의, 그리고 실행 환경입니다. 실행 환경이 문법만큼 큰 비중을 차지합니다. 편집기에서 초록색 화살표를 눌러야만 코드가 돌아가는 상태로는 다음 구간이 계속 막힙니다.

이 구간을 끝냈는지 확인하는 방법도 간단합니다. 컴퓨터를 껐다 켠 뒤, 편집기를 열지 않고 터미널만으로 그 파일을 다시 실행해 보면 됩니다. 어디에 저장했는지, 어떤 명령으로 실행하는지, 어떤 버전으로 도는지를 헤매지 않는다면 넘어가도 좋습니다.

이 구간에서 안 해도 되는 것: 가상환경 관리 도구를 여러 개 비교하는 일, 편집기 설정을 몇 시간씩 다듬는 일, 자료구조 이름을 외우는 일입니다.

2구간 — 입력을 받아 결과를 내는 프로그램 (대략 3~5주)

산출물은 두 가지입니다. 사용자 입력이나 파일을 받아 처리하고 결과를 내놓는 프로그램 하나, 그리고 그것을 만드는 동안 쌓인 커밋 이력입니다. 가계부 정리든 단어장이든 주제는 상관없고, 조건은 “중간에 멈추지 않고 끝까지 도는 것” 하나입니다.

이 구간에 git을 넣는 이유는 협업 때문이 아닙니다. 어제 잘 돌던 코드를 오늘 망가뜨렸을 때 되돌아갈 지점이 있어야 실험을 겁내지 않게 되기 때문입니다. 명령은 add, commit, log, diff 넷이면 충분합니다.

이 구간에서 처음 만나는 벽은 대개 문법이 아니라 “무엇을 만들지 정하지 못하는 것”입니다. 주제를 크게 잡을수록 완성되지 않으므로, 화면 하나 또는 명령 하나로 끝나는 크기까지 줄이는 편이 좋습니다. 다 만든 뒤에 기능을 붙이는 것은 쉽지만, 절반쯤 만든 큰 프로그램은 되살리기가 어렵습니다.

이 구간에서 안 해도 되는 것: 브랜치 전략, 예쁜 커밋 메시지 규칙, 성능 최적화, 프레임워크 도입입니다.

3구간 — 남이 실행할 수 있는 상태 (대략 6~9주)

산출물은 실제로 접속되는 주소이거나, 그게 어렵다면 실행 방법이 적힌 README입니다. 이 구간의 핵심은 기능 추가가 아니라 내 컴퓨터 밖으로 나가는 경험입니다. 내 컴퓨터에만 있던 파일 경로, 하드코딩된 비밀번호, 설치해 둔 것을 잊고 있던 라이브러리가 이때 한꺼번에 드러납니다.

판정 기준은 명확합니다. 다른 사람에게 저장소 주소만 주었을 때, 추가 설명 없이 실행까지 갈 수 있으면 끝입니다. 스스로 확인하려면 다른 폴더에 새로 내려받아 README만 보고 따라 해 보면 됩니다.

이 구간에서 안 해도 되는 것: 도커 이미지 최적화, CI 파이프라인 구성, 도메인 구입, 디자인 다듬기입니다.

4구간 — 고쳐 본 흔적 (대략 10~14주)

산출물은 버그 하나를 재현하고 고친 커밋, 그리고 테스트 하나입니다. 여기서 핵심은 “재현” 쪽입니다. 어떤 입력을 넣으면 어떤 잘못된 결과가 나오는지 문장으로 적을 수 있어야 하고, 그 입력을 그대로 테스트로 옮겨 실패하는 것을 본 다음 고쳐서 통과시키면 됩니다. 테스트가 하나뿐이어도 상관없습니다. 이 흐름을 한 번 완주해 본 사람과 아닌 사람의 차이는 나중에 꽤 크게 벌어집니다.

고칠 버그가 없다고 느껴진다면 대개는 프로그램을 정해진 방식으로만 써 봤기 때문입니다. 빈 값을 넣어 보고, 아주 긴 문자열을 넣어 보고, 없는 파일 이름을 넣어 보면 금방 하나가 나옵니다. 남이 잠깐 써 보게 하는 것도 방법입니다. 만든 사람은 자기도 모르게 안전한 입력만 넣습니다.

이 구간에서 안 해도 되는 것: 커버리지 수치 맞추기, 목(mock) 라이브러리 심화, 설계 패턴 적용입니다.

매주 스스로 물어보는 것

[ ] 이번 주에 내가 처음부터 끝까지 직접 친 코드가 있는가
[ ] 막힌 문제 하나를 검색 없이 30분 이상 붙들어 본 적이 있는가
[ ] 오류 메시지를 읽고 원인을 맞힌 적이 한 번이라도 있는가
[ ] 커밋이 최소 세 개 이상 남았는가
[ ] 지난주의 나에게 설명할 수 있는 것이 하나 늘었는가
[ ] 아직도 튜토리얼만 따라 치고 있지는 않은가

세 개 미만이면 진도를 늘리지 말고 같은 구간을 한 주 더 반복

100일 차에 남아 있어야 할 것

구간을 다 지났다면 결과는 저장소 하나로 요약됩니다. 화려할 필요는 없고, 아래 정도면 충분합니다.

my-first-project/
├── README.md          실행 방법, 무엇을 하는 프로그램인지 3~5줄
├── .gitignore         가상환경, 캐시, 로컬 설정 파일 제외
├── requirements.txt   설치해야 하는 것 목록
├── src/
│   ├── main.py        진입점
│   └── parser.py      기능이 나뉘기 시작한 흔적
└── tests/
    └── test_parser.py 실패를 재현했던 그 테스트 하나

$ git log --oneline | wc -l
37

로드맵이 오히려 해로울 때

진도표에는 고유한 부작용이 있습니다. 가장 흔한 것은 표를 지키는 일 자체가 목적이 되는 경우입니다. 이번 주에 반복문을 끝내기로 했는데 절반쯤에서 막히면, 이해하지 못한 채로 다음 항목으로 넘어가게 됩니다. 넘어간 자리는 사라지지 않고 두세 구간 뒤에 훨씬 큰 덩어리로 다시 나타납니다. 막혔을 때 표를 어기는 것이 정상이고, 표는 그러라고 있는 도구입니다.

두 번째는 남의 로드맵에 나를 맞추는 경우입니다. 엑셀 매크로를 짜 본 사람에게 “1주 차 변수와 조건문”은 이미 아는 내용인데, 목록에 있으니 처음부터 다시 돕니다. 반대로 수학을 오래 놓았던 사람에게는 같은 한 주가 턱없이 짧습니다. 로드맵은 순서를 참고하라고 있는 것이지, 칸을 다 채우라고 있는 것이 아닙니다. 아는 부분은 건너뛰고 남는 시간을 막히는 곳에 쓰는 편이 낫습니다.

세 번째로, 100일이라는 숫자에는 별 의미가 없습니다. 하루 네 시간을 쓸 수 있는 사람과 퇴근 후 40분을 겨우 내는 사람이 같은 기간에 같은 지점에 도착할 이유가 없습니다. 직장, 학업, 돌봄 상황에 따라 가용 시간은 크게 달라지므로, 이 글의 주차 표기는 무시하고 순서와 산출물만 가져가시면 됩니다. 4구간을 반년에 걸쳐 지났다고 해서 덜 배운 것은 아닙니다.

이번 주에 바로 할 수 있는 것

• 지금 내가 네 구간 중 어디에 있는지, 마지막으로 완성한 산출물을 기준으로 적어 봅니다.
• 다음 산출물 하나를 “무엇이 있으면 끝난 것인지” 한 문장으로 정의합니다.
• 위 주간 점검 여섯 줄을 메모 앱이나 저장소의 NOTES.md에 붙여 둡니다.
• 이미 아는 항목이 로드맵에 있다면 지우고, 그 시간을 지금 막힌 곳에 배정합니다.
• 이번 주 커밋을 최소 세 개 남기는 것을 목표로 잡습니다.

구간별로 무엇을 볼지 더 구체적으로 정하고 싶다면 로드맵 모음을 참고하시고, 1구간을 아직 시작하지 않았다면 첫 언어 고르기부터 읽으시면 됩니다. 2구간의 git은 첫 주의 git에 필요한 만큼만 정리돼 있고, 3구간에서 결과물을 정리할 때는 포트폴리오는 실력을 대신하지 않는다를 같이 보시면 방향을 덜 잃습니다.