커밋 히스토리를 처음부터 끝까지 훑어보면 그 프로젝트가 순탄했는지 아니었는지 금방 알 수 있다. Postlark의 git log는 후자에 가깝다. fix 커밋이 feat 커밋만큼 많고, audit 커밋이 그 사이사이에 박혀 있다. 이 연재의 마지막 편에서는 그 git log를 따라가며 6주간의 이야기를 정리해본다.

계획표는 30일짜리였다

처음에 그린 로드맵은 4주 구성이었다. 1주차에 API와 데이터 레이어, 2주차에 대시보드와 에디터, 3주차에 MCP 서버와 예약 발행, 4주차에 결제와 커스텀 도메인. 깔끔하게 떨어지는 30일 계획. 코어 기능을 구현하는 데는 거의 그 일정대로 갔다. 문제는 "코어 기능"이라는 게 전체의 절반도 안 된다는 사실을 론칭 직전에야 체감했다는 거다. API가 돌아가는 것과 서비스가 돌아가는 건 완전히 다른 문제였다.

코딩 전에 이미 한 번 엎었다

모노레포 구조를 잡고 설계 문서를 쓰던 날, 결제 시스템을 통째로 갈아탔다. 코드 한 줄 안 쓴 상태에서의 피벗이라 피해가 적었을 거라 생각할 수 있지만 — 문서를 전부 뒤집고 웹훅 플로우를 다시 설계하는 데 꼬박 하루가 갔다. 1인 개발자한테 세금이나 국제 결제 처리를 직접 맡기는 구조보다 대행 모델이 맞다는 판단이었고, 결과적으로 맞는 선택이었다. 하지만 첫날부터 일정이 밀린 건 사실이다. 돌이켜보면 이게 앞으로 6주의 예고편이었다.

만들고 부수고 고치는 루프

하루에 하나의 큰 기능을 올리고, 다음 날 아침에 깨진 걸 고치는 루프. 이게 반복됐다.

Markdown 에디터를 넣은 날은 순조로웠다. 스플릿 패인 미리보기까지 하루 만에 돌아갔다. 그런데 MCP 서버를 연결하는 시점에 API 에러 포맷이 바뀌어 있었다. 파싱 로직을 새벽에 다시 짰다. OG 이미지 자동 생성을 넣은 날은 한국어 폰트 렌더링에서 막혔고, 피드 카드에서 OG 이미지가 아예 안 보이는 건 며칠 뒤에야 발견했다. 결국 피드에서는 본문 첫 이미지를 쓰는 쪽으로 전략을 바꿨다.

Phase 3 — 결제 연동, 커스텀 도메인, 분석 대시보드를 한 주에 몰아넣은 주간이 가장 힘들었다. 통합 테스트에서 레이스 컨디션이 터졌을 때는 일정 자체를 의심했다. 코너 케이스가 쏟아졌고, 새벽에 고치고 아침에 올리고 점심에 또 깨졌다.

서비스 워커라는 지뢰

론칭 후 가장 치명적이었던 건 Reader 앱의 blank screen 버그다. git log에 네 번의 연속 커밋으로 흔적이 남아 있다.

처음에는 Android WebView 콜드 스타트 문제인 줄 알았다. iframe 재시도 로직을 넣었다. 안 됐다. 첫 설치 시 네비게이션 자체가 먹통인 게 진짜 문제였다. 서비스 워커 해제를 시도했다. 안 됐다. 페이지 로드 순서를 바꿔서 SW를 먼저 해제하도록 했다. 여전히 안 됐다.

결국 PWA 프레임워크를 통째로 걷어냈다. 서비스 워커가 캐시한 리소스와 SPA 라우팅이 충돌하고 있었고, 네이티브 래퍼까지 끼면 디버깅이 사실상 불가능했다. PWA 오프라인 지원을 포기하는 대신 앱이 정상 동작하는 쪽을 선택했다.

이런 결정을 빠르게 내릴 수 있다는 게 혼자 만드는 프로젝트의 장점이다. 회의도 설득도 필요 없이, "이거 빼자"로 끝난다.

론칭은 끝이 아니라 시작

Day 30에 프로덕션 배포를 마쳤을 때 끝인 줄 알았다. 착각이었다. 그 후 한 일들을 나열하면:

  • 랜딩 페이지 모바일 대응 (가로 오버플로우, 한국어 줄바꿈)

  • 배포 환경 설정 문제를 몇 번이나 고쳤는지 모른다

  • 영문·한국어 문서 사이트 작성과 동기화

  • Reader 앱 개발 (안드로이드)

  • 어드민 도구 — 콘텐츠 품질 모니터링, 관리 기능

  • SEO 작업 — 검색엔진 인덱싱, 탐색 페이지

계획표에 없던 것들이 계획표에 있던 것들만큼의 시간을 먹었다. 어쩌면 더.

6주를 돌아보며

혼자서 플랫폼을 론칭할 수 있었던 건 범위를 줄이는 데 주저하지 않았기 때문이다. PWA 걷어내기, 이미지 전략 변경, 결제 시스템 교체 — 전부 "이건 지금 안 된다"는 판단을 빠르게 내린 결과다. 완벽한 설계를 고수하는 것보다 동작하는 서비스를 내놓는 게 우선이었다.

1인 개발에서 제일 위험한 건 완벽주의가 아니다. 계획과 현실 사이의 간극을 인정하지 않는 것이다. 로드맵 30일이면 코드는 끝난다. 하지만 서비스는 코드가 아니다. 문서, 배포 안정화, 모바일 대응, SEO, 운영 도구 — 이것들이 나머지를 채운다. 나머지라고 부르기엔 분량이 절반보다 많다.

다음에 또 혼자 뭔가를 만든다면, 코딩 일정의 두 배를 "그 외 모든 것"에 할당할 거다. Postlark 13편의 기술 이야기 뒤에 있는, 가장 실용적인 한 줄짜리 교훈이다.