개발 일지

도메인 앞에 Worker를 세우는 순간 모든 방문자가 그 코드를 지나간다. 그래서 첫 배포는 아무것도 하지 않는 Worker였다. 들어온 요청을 그대로 폰으로 넘기기만 하는 코드다. 이 글은 그 “통과만 하는 Worker"에서 시작해 하나씩 역할을 빼앗아 온 과정이다. 1단계: fetch(request) 한 줄 DNS는 그대로 폰의 터널을 가리키고 있었다. 이 상태에서 라우트 mhub.uk/*를 Worker에 붙이면, Worker 안에서 fetch(request)를 호출했을 때 Cloudflare가 원래 목적지(폰)로 요청을 보낸다. 즉 Worker는 투명한 중계기가 된다. export default { async fetch(request) { return fetch(request); // 일단 전부 폰으로 }, }; 이걸 먼저 배포한 이유는 “라우트를 붙였을 때 뭔가 깨지는가"를 서비스 중단 없이 확인하기 위해서였다. 깨지면 라우트만 떼면 그만이다. 아무 문제 없이 돌아가는 것을 보고 다음으로 갔다.

이 글은 ‘폰 서버 안정화 일지’ 시리즈의 첫 번째다. 재부팅만 하면 절반쯤의 서비스가 안 올라오던 시절, 원인이 부팅 스크립트의 한 줄이었다는 이야기와, 그걸 고치려고 만든 첫 워치독이 거꾸로 건강한 봇을 매번 죽이던 이야기다. 증상: 재부팅 뒤 Claude 세션이 안 뜬다 폰을 재부팅하면 카카오톡 봇은 살아나는데 Claude Code 세션과 터널 몇 개가 안 올라오는 날이 반복됐다. 재부팅 직후 tmux 세션 목록을 보면 iris만 있고 claude, cloudflare, blogadmin 같은 세션이 없었다. 하루는 수동으로 띄우고 넘어갔지만, 같은 일이 세 번째 반복되자 부팅 스크립트를 처음부터 끝까지 읽었다.

Cloudflare 이전의 첫 단계는 “GitHub에 커밋하면 Cloudflare가 알아서 Hugo를 돌려 배포한다"를 만드는 것이었다. Workers Builds는 저장소를 연결하면 빌드 명령과 배포 명령을 실행해 준다. 간단해 보였지만, 폰에서 만들던 결과물과 똑같이 나오게 하려면 네 가지를 못 박아야 했다. 빌드 명령은 스크립트 하나로 wrangler.jsonc의 build.command에 bash scripts/cf-build.sh를 넣었다. Cloudflare 빌드 환경에는 Hugo가 없으므로 스크립트가 직접 내려받는다. PIN="${MHUB_HUGO_VERSION:-0.154.5}" curl -fsSL -o hugo.tar.gz \ "https://github.com/gohugoio/hugo/releases/download/v${PIN}/hugo_extended_${PIN}_linux-amd64.tar.gz" tar -xz -f hugo.tar.gz hugo export TZ=Asia/Seoul hugo --minify 버전 변수 이름을 HUGO_VERSION이 아니라 MHUB_HUGO_VERSION으로 한 데는 이유가 있다. Cloudflare 대시보드의 빌드 변수에 HUGO_VERSION이 있으면 플랫폼이 그 값을 다른 의미로 읽을 수 있어서, 내 스크립트만 읽는 전용 이름을 쓰는 편이 안전했다.

이 블로그는 한동안 루팅한 갤럭시 S9 한 대가 전부 떠받치고 있었다. Hugo로 만든 정적 파일을 폰 안의 Caddy가 내보내고, 글쓰기 화면과 조회수·댓글 API는 폰 안의 Node 서버가 처리하고, 바깥과는 Cloudflare Tunnel로 이어져 있었다. 잘 돌았지만 “폰이 꺼지면 블로그도 꺼진다"는 사실이 늘 마음에 걸렸다. 2026년 10월 10일, 이 구조를 끝내기로 했다. 이 글은 그 결정의 이유와 계획이고, 이어지는 시리즈는 실제로 옮기면서 겪은 일들이다. 왜 지금이었나 계기는 두 가지였다. 하나는 폰 쪽 감시 스크립트가 블로그 터널을 닷새 동안 17번이나 재시작한 기록을 본 것이다. 서비스는 대체로 살아 있었지만, 사람이 없을 때 폰 혼자 버티는 구조는 언제든 조용히 멈출 수 있었다. 다른 하나는 내가 AI 코딩 세션을 길게 쓰는 기간이 끝나간다는 점이었다. 그 전에 블로그를 “혼자서도 운영할 수 있는 모양"으로 만들어 두고 싶었다. 폰 안의 tmux 세션과 크론과 셸 스크립트를 유지보수하는 것보다, 관리 화면에서 글을 쓰고 GitHub에 저장되고 알아서 배포되는 쪽이 훨씬 단순하다.

루팅한 갤럭시 S9 한 대가 내 홈 서버다. 처음엔 카카오톡 봇 하나 돌리려고 시작했는데, 어느새 블로그와 자동화 루틴, 데이터 수집기까지 전부 이 폰 위에 올라가 있다. 지난 한 달 동안 이 폰에서 겪은 장애와 수정 기록을 시리즈로 남기기 전에, 먼저 “지금 이 폰에서 무엇이 어디서 돌아가는가"를 한 장의 지도로 정리해 둔다. 이 글은 이어질 시리즈들의 서문이자 색인이다. 두 겹의 리눅스 폰 안에는 리눅스가 두 겹으로 있다. 바깥은 Termux다. 안드로이드 위에 리눅스 유저랜드를 올려주는 앱이고, tmux 서버와 cloudflared 터널, 그리고 카카오톡 봇처럼 안드로이드와 직접 닿아야 하는 것들이 여기서 돈다. 안쪽은 proot-distro로 올린 Ubuntu 컨테이너다. 블로그 관리 서버, 데이터 수집기, 자동화 루틴, 그리고 이 모든 것을 관리하는 Claude Code 원격 세션이 여기서 돈다.

매일 아침 유투브로 전일 미국 시장 정보를 습득하는 편인데 영상을 처음부터 보려면 너무 많은 시간이 소비된다. 그리고 이러한 영상들은 대부분 스크립트를 제공하지 않는다. 그래서 스크립트를 제공하지 않는 영상의 스크립트를 추출해서 AI를 활용해 요약본을 만들 수 있게 만드는 개인용 파이프라인을 설계했다. 아직 구상 단계지만, 각 단계를 어떤 도구로 어떻게 연결할지는 구체적으로 정리해뒀다. 1단계: 오디오 추출 — AI 없이 로컬에서 가능 가장 먼저 필요한 건 영상에서 오디오만 뽑아내는 작업이다. 이건 AI가 필요 없는 단순 작업이라 로컬에서 처리한다.

렌터카 업계 지인에게 우연히 들은 이야기 하나가 아이디어의 출발점이 됐다. 개인들의 경우 미납된 고속도로 통행료나 과태료가 있을 경우 개인 차량에 이 비용이 귀속되니 문제가 없지만 렌터카 회사는 이야기가 다르다. 미납 통행료나 과태료 발생 사실을 일찍 확인한다면 각 통행료 징수 주체와 과태료 부과 관공서에 실제 차량을 빌려간 손님으로 납부 대상자 변경을 하면 된다. 문제는 이 변경 신청 기간이 짧다는 것이다. 통상 고지서는 미납 통행료, 과태료가 발생한 시점보다 2~3개월 뒤 통지된다. 당시 차량을 렌트했던 고객이 연락이 잘되고 통행료/과태료 부과 사실을 수긍하여 정상적으로 납부를 해준다면 아무런 문제가 없겠으나, 고객 입장에서도 몇달 전 벌어진 기억도 안나는 통지서를 쉽게 수긍하기는 어렵다. 때문에 렌터카 회사에서 이 비용을 추후에 받아내는 것은 여간 성가신 일이 아니다. 전국 50개가 넘는 유료도로 운영사에 흩어져 있는 미납 내역과 미납 과태료를 납부자 변경 신청 마감 전에 일일이 확인하는 건 사람이 손으로 하기엔 너무 번거로운 일이다.

로컬 코딩 LLM 파이프라인을 검증하면서 처음엔 단순하게 접근했다. 모델별로 딱 한 번씩 돌려보고, 가장 빠르고 결과물이 깔끔한 모델을 고르면 된다고 생각했다. 그런데 최종 결정을 내리기 직전에 “정말 이 결과가 우연이 아닐까?“라는 의문이 들어서, 가장 유력했던 모델(DeepSeek-Coder-V2-16B)만 완전히 동일한 프롬프트로 한 번 더 돌려봤다. 두 번째 실행에서 벌어진 일 1차 실행에서는 9분 30초 만에 요청한 4개 함수(add, subtract, multiply, divide)만 정확히 작성하고 끝났다. 2차 실행은 22분 55초가 걸렸고, 요청하지 않은 함수 4개(거듭제곱, 나머지, 제곱근, 팩토리얼)를 임의로 추가했으며, 코드 스타일 오류(flake8)도 훨씬 많이 남겼다.

한동안 월 20달러 Claude Pro 플랜을 쓰다가, 110달러짜리 Max 플랜으로 갈아탔다. 단순 변심이 아니라 명확한 이유가 있었다. Pro에서 걸린 벽 Pro 플랜은 사용량 한도(5시간 단위 세션 한도, 주간 한도)가 있는데, 여러 프로젝트를 동시에 굴리다 보니 이 한도에 자주 걸렸다. 특히 코딩 작업처럼 컨텍스트를 많이 쓰는 작업을 하는 날에는 하루에도 몇 번씩 한도 초과 메시지를 만났다. 작업 흐름이 끊기는 게 누적되니, 요금 차이(월 90달러)보다 그로 인한 비효율이 더 크다고 판단했다. Max로 올린 뒤 Max 플랜으로 올린 뒤로는 지금까지 단 한 번도 한도에 걸린 적이 없다. 여러 기기(아이맥, 루팅폰 2대)에서 동시에 원격 세션을 돌리고, 코딩 작업과 문서 작업을 병행해도 여유가 있다.