이번 주에 작은 것을 출시하기

튜토리얼 루프에 갇힌 대부분의 사람들은 기술 문제가 아니라 출시 문제를 가지고 있다. Python 콘텐츠를 40시간 봐도 자신의 프로젝트를 만들려고 앉는 순간 얼어붙을 수 있는데, 그 이유는 튜토리얼이 모든 결정을 대신해주기 때문이다. 이 가이드는 강제 함수다: 작은 것을 선택하고, 완성하고, 누군가에게 보여주고, 이번 주에 하자.

주말 안에 완성할 수 있는 프로젝트를 선택하라

실패 패턴은 범위다. 사람들은 첫 번째 프로젝트가 인증, 결제, 대시보드가 있는 SaaS 앱이어야 한다고 생각한다. 그건 주말 프로젝트로 위장한 6개월짜리 프로젝트다.

대신 하나의 명확한 기능을 가진 것을 선택하자:

• EXIF 날짜를 기반으로 폴더의 파일을 이름을 바꾸는 CLI 도구
• 공개 API를 스크래핑해서 매일 요약본을 이메일로 보내는 스크립트
• 하나의 양식과 하나의 출력 페이지가 있는 Flask 앱
• 방문하는 모든 페이지에서 특정 키워드를 강조하는 브라우저 확장

코드를 작성하기 전에 범위를 한 문장으로 적어둬라. 그 문장에 "and"가 한 번 이상 필요하다면 줄여라. "비용을 추적하고 분류하고 차트를 만드는 도구"는 세 개의 프로젝트다. 추적기부터 출시하자.

실제 마감일과 실제 청중을 정하자

결과가 없는 마감일은 마감일이 아니다. 친구에게 말하거나, Discord 서버에 올리거나, 금요일에 동료에게 데모를 보여주겠다고 약속하자. 청중이 마감일보다 더 중요하다. 누군가가 실제로 그 것을 볼 거라는 것을 알면 어떻게 만들지가 달라진다. 아키텍처를 멋지게 꾸미는 걸 멈추고 행복한 경로가 실제로 작동하는지 확인하기 시작한다.

느낌이 아니라 숫자를 정하자. "시간이 날 때 작업하겠다"는 아무것도 만들지 않는다. "오늘 밤 2시간, 내일 2시간, 토요일 아침 출시"는 프로젝트를 만든다.

못생긴 버전부터 만들자

폴더 구조 논쟁, CSS 프레임워크 선택, Postgres와 SQLite 중에서 40개의 행만 저장할 도구를 위해 선택하는 것을 건너뛰자. 파일 하나를 작성하자. print() 문을 로거 대신 사용하자. 데이터베이스 대신 Python 리스트를 사용하자.

# expenses.py - ugly version, and that's fine
import csv
from datetime import date

def add_expense(amount, category):
    with open('expenses.csv', 'a', newline='') as f:
        writer = csv.writer(f)
        writer.writerow([date.today().isoformat(), amount, category])

add_expense(12.50, 'coffee')

그게 작동하는 비용 추적 도구다. 확장 가능하지 않고, 테스트가 없고, 내일 실제로 사용할 수 있는 것까지 90%를 달성한다. 작동하는 못생긴 것은 리팩토링할 수 있다. 존재하지 않는 아름다운 것은 리팩토링할 수 없다.

어디든 배포하자, 아무리 못하더라도

노트북 위의 프로젝트는 출시한 것으로 계산되지 않는다. 인터넷에 보여주거나 누군가가 직접 실행할 수 있게 하자.

• CLI 도구: 정확한 설치 및 실행 명령을 보여주는 2단락 README와 함께 공개 GitHub 저장소에 푸시하자
• 웹 앱: Render, Fly.io, 또는 $5 DigitalOcean 드롭렛에 배포하자. 한 명의 사용자를 가진 프로젝트를 위해 Kubernetes 옵션을 비교하는 데 3일을 쓰지 말자
• 스크립트: cron 작업이나 GitHub Action을 설정해서 손을 대지 않고도 실행되게 하자

배포 마찰은 기술적 도전보다 더 많은 사이드 프로젝트를 죽인다. 지금 Render 같은 플랫폼으로 git push하기가 너무 많다면 로컬에서 실행 중인 90초짜리 Loom 비디오를 녹화해서 보내자. 포인트는 외부 증명이다. 인프라 성숙도가 아니다.

깨진 것을 적어두자

출시 후 15분을 들여서 잘못된 세 가지와 그것을 고친 방법을 적자. 다른 사람을 위한 게 아니라 너를 위한 거다. 이게 실제 배움이다. 튜토리얼은 문법을 가르쳤다. 깨진 pip install, CORS 에러, 자정의 off-by-one 날짜 버그. 그것들이 소프트웨어가 실제로 어떻게 작동하는지 가르친다.

한 파일에 이 메모들을 계속 적어두자. 5개나 6개의 작은 프로젝트 후에는 같은 종류의 버그들이 나타나는 것을 볼 거고, 그게 너의 실제 커리큘럼이다: 튜토리얼이 절대 다루지 않는 간격들.

그 다음은 조금 더 큰 것을 선택하자

CLI 스크립트에서 분산 시스템으로 뛰어넘지 말자. 한 번에 복잡성의 한 가지 차원을 더하자: 다음 프로젝트는 CSV 대신 데이터베이스를 가지거나, 기본 테스트 스위트를 가지거나, 두 번째 사용자를 가진다. 작고 복합적인 단계들은 3주차에 정지되는 하나의 야심찬 재작성을 이긴다.

이 후 체계적인 다음 단계를 원한다면 Korra Studio의 Python과 DevOps 섹션이 첫 출시 프로젝트 직후에 사람들을 곤경에 빠뜨리는 배포와 도구 간격을 정확히 다룬다.