혼자 만들고 배포하는 개발자의 체크리스트: Cloudflare Pages 배포, 패키징 자동화, 검증 습관, 채용 시장 읽기

혼자 프로젝트를 만들다 보면 코드 외에 반복되는 일이 있다. 배포하는 일, 결과물을 묶는 일, 틀린 것을 일찍 잡는 일, 그리고 이 일을 계속할지 판단하는 일이다. 이 글은 그 네 가지를 이 블로그에서 직접 쓴 글과 연결해 정리한다. 모든 항목은 개인적인 경험에서 나온 것이며 팀 규모가 크면 달라질 수 있다.

1. 배포: 정적 사이트는 한 번에 올리고 한도를 확인한다

정적 사이트는 GitHub 연동이나 wrangler로 올리면 된다. 설정 순서와 운영에서 겪은 함정은 Cloudflare Pages 배포 가이드에 있다. 이 블로그에서 확인한 것 두 가지만 적으면 다음과 같다.

• _redirects 파일은 규칙이 1,000개가 넘어도 배포는 성공하지만, 라이브에서는 앞쪽 약 100개만 적용됐다.
• 정적 파일은 하나당 25MiB를 넘길 수 없다. shrinkto.app을 만들 때 32MB짜리 ffmpeg.wasm 코어를 넣지 못해 외부 CDN으로 뺐다.

두 번째 사례가 나온 프로젝트의 전체 이야기는 shrinkto.app 개발기에 있다.

2. 묶기: 사람이 하는 패키징을 자동화한다

모듈을 사람이 한 명씩 빌드해 모아서 압축하면 느리고, 버전이 하나라도 어긋나면 처음부터 다시 해야 한다. 릴리스 패키징 자동화 글은 릴리스 매니페스트 하나를 기준으로 삼고, 빌드 전에 검사하고, 바뀐 모듈만 병렬로 빌드하고, 같은 입력이면 같은 파일이 나오게 묶는 구조를 12개 모듈 데모로 측정했다. 직렬 20.9초가 병렬 9.7초, 캐시 적중 시 0초였고 버전 불일치 11건은 빌드 시작 전에 한 번에 나왔다. 장난감 규모라는 한계는 그 글에 적었다.

3. 검증: 만드는 동안 틀린 것을 일찍 잡는다

AI 도구와 같이 만들 때 특히 필요한 습관은 단계마다 빌드와 테스트가 통과한 상태로 끝내는 것, 라이브러리 API를 추측하지 않는 것, 출력 파일의 내용을 검사하는 테스트를 두는 것이다. 이 규칙들이 어떤 실수를 막았는지는 바이브 코딩 작업 규칙에 사례와 함께 적었다.

4. 판단: 시장을 숫자로 읽는다

계속 만들 것인지, 어떤 능력을 키울지 정할 때는 채용 시장 같은 외부 상황을 읽게 된다. 이때 “신입이 줄었다”는 말의 어디까지가 확인된 숫자인지 가려 읽는 방법은 AI 시대 개발자 채용 시장 읽는 법에 정리했다.

체크리스트

• 배포 후 라이브에서 규칙(리다이렉트, 헤더)이 실제로 적용되는지 curl -I로 확인했다.
• 파일 크기와 개수 한도를 확인했다.
• 릴리스에 들어갈 모듈과 버전이 한 파일에 적혀 있고 빌드 전에 검사한다.
• 단계마다 빌드와 테스트가 통과한 상태로 끝낸다.
• 확인하지 못한 범위를 문서에 “미검증”으로 적었다.

한계

이 글은 한 사람이 정적 사이트와 웹 도구를 운영한 경험이다. 서버가 있는 서비스, 여러 사람이 함께하는 릴리스에는 그대로 적용되지 않는다.