개발 일지

이 블로그 자체가 유휴 휴대폰을 서버로 쓰는 프로젝트인데, 사실 이 방식을 먼저 시도해본 기기가 하나 더 있습니다. 오래된 갤럭시 S9입니다. 이 시리즈는 그 S9 위에서 카카오톡 챗봇 “Iris"를 돌리고, 여러 기능을 개발하면서 겪은 과정을 기록합니다. 루팅 이후, 서버 환경부터 지난 글에서 이 S9을 루팅하기까지의 과정(그리고 일반적인 방법이 안 통해 TWRP로 돌아갔던 이야기)을 다뤘습니다. 이번 글은 그 이후, 루팅된 안드로이드 위에 실제로 상시 구동되는 서버 환경을 어떻게 쌓아올렸는지부터 시작합니다. Termux + proot-distro 조합 기본 구조는 이 블로그의 다른 서버(휴대폰 서버)와 동일합니다. Termux를 리눅스 유저랜드로 쓰고, 그 위에 proot-distro로 우분투 컨테이너를 하나 더 얹습니다. 루트 권한이 있는 기기라고 해도 Claude CLI가 안드로이드 환경에서 구동되지 않기 때문에 이 기기를 agent로 두고 Claude를 통해 이 휴대폰 서버에서 돌아가는 모든 서비스를 원격으로 통제하기 위해서는 우분투 환경이 필수적이었습니다.

2026년 9월 8일 만들어져 9월 21일 인수인계로 임무를 마친 코인추천 자동화 세션의 13일간 기록입니다. 클라우드 라우틴 실험으로 시작해 포지션 추적표, 개인 블로그 미러링, SEO 개선을 거쳐 새 서버(S9)로 넘어가기까지의 과정을 정리했습니다. 탄생 — 라우틴 하나로 시작된 실험 2026년 9월 8일, 업비트 코인 시세를 하루 여러 번 분석해 워드프레스에 자동으로 포스팅하는 “코인추천” 자동화를 위해 이 세션이 만들어졌습니다. 당시로선 다소 실험적인 방식이었습니다 — claude.ai의 RemoteTrigger(클라우드 라우틴) 기능에 persist_session이라는, 문서화되지 않은 옵션을 걸어서 매번 새 클라우드 샌드박스를 띄우는 대신 하나의 세션을 계속 재사용하도록 만든 것입니다. 스케줄은 하루 3번, 한국시간 오전 7시·오후 1시·저녁 7시였습니다.

폰 한 대로 상시 구동 서버를 만들 수 있을까. 답은 “된다"였지만, 그 과정은 생각보다 여러 겹의 장애물을 넘는 일이었다. 시작은 Termux였다. 안드로이드 폰 안에 리눅스 환경을 올려서 코드를 짜고 서버를 띄우는 건 어렵지 않다. 문제는 그 위에 Claude Code를 올리려는 순간 터졌다 — npm install -g @anthropic-ai/claude-code가 linux-arm64-android 네이티브 바이너리가 없다는 이유로 실패했다. 안드로이드용 Node.js 바이너리 생태계가 표준 리눅스 배포판과 미묘하게 다르다는 걸 이때 처음 체감했다. 해법은 한 겹 더 감싸는 것이었다. proot-distro로 Termux 안에 진짜 우분투 컨테이너를 하나 더 띄우고, 그 안에서 Claude Code를 설치했다. proot-distro login ubuntu로 들어가면 완전한 리눅스 환경이라 패키지 생태계 문제가 사라진다. 대신 파일 경로가 두 겹이 됐다 — Termux 쪽에서 보는 /data/data/com.termux/files/home/phoneserver와 우분투 컨테이너 안에서 보는 /root/termux-home/phoneserver가 바인드 마운트로 연결된 같은 파일이다. 어느 쪽에서 편집해도 같은 파일이 바뀌지만, 이 이중 구조를 모르면 “분명히 저장했는데 안 보인다"는 혼란에 빠지기 딱 좋다.

카카오톡 챗봇 Iris를 돌리려면 루팅된 안드로이드 기기가 필요합니다. 이 시리즈의 무대인 갤럭시 S9도 처음엔 그냥 평범한 완제품 폰이었습니다. 이번 글은 이 폰을 루팅하기까지 겪은 과정 — 정확히는, “보통 이렇게 하면 된다"는 방법이 이 기종에서는 안 통해서 다른 길로 돌아간 이야기입니다. 1차 시도: Magisk 패치 + 오딘 삼성 기기를 루팅하는 가장 흔한 방법은 이렇습니다. 기기의 순정 AP(부트 이미지가 포함된 펌웨어) 파일을 받아서, Magisk 앱으로 그 이미지를 패치한 뒤, 그 패치된 AP를 오딘(Odin)으로 다시 기기에 플래시하는 방식입니다. 커스텀 리커버리를 따로 설치할 필요가 없고, 절차도 비교적 간단해서 여러 기종에서 표준처럼 쓰이는 방법입니다.

미국 증시 마감 시황 루틴을 운영하다 보면 자연스럽게 “이 데이터를 더 정확하고 안정적으로 가져올 방법이 없을까"라는 질문을 하게 됩니다. 유료 금융 데이터 API는 대부분 비용이 상당하지만, 웹페이지 형태로는 무료로 볼 수 있는 곳도 많습니다. 문제는 그런 사이트일수록 크롤링을 막아둔 경우가 많다는 점입니다. 실제로 몇몇 후보 사이트를 대상으로 간단히 점검해본 결과를 정리합니다. 점검 방법 사이트마다 robots.txt를 먼저 확인하고, 이어서 일반적인 페이지 요청(curl)이 실제로 콘텐츠를 돌려주는지 테스트했습니다. 별도의 브라우저 자동화나 로그인 없이, 가장 단순한 방식으로 접근 가능한지만 확인하는 수준의 점검입니다.

이 블로그의 글마다 붙어 있는 썸네일 이미지들은 전부 Python의 Pillow(PIL) 라이브러리로 직접 그린 것입니다. 그런데 이 기능을 처음 만들 때, 정작 가장 중요한 한글 텍스트가 화면에 텅 빈 네모 박스로만 나오는 문제를 겪었습니다. 이번 글은 그 원인과 해결 과정입니다. 증상: 글자가 전부 빈 네모로 나온다 썸네일 생성 스크립트를 처음 실행했을 때, 제목이나 카테고리 배지에 들어가야 할 한글 텍스트가 화면에 아예 보이지 않거나 깨진 네모(이른바 “tofu”)로만 표시됐습니다. 처음엔 좌표 계산이 잘못됐나 의심했지만, 텍스트의 bbox(경계 상자)를 찍어보니 높이가 0으로 나오는 경우까지 있어 좌표 문제가 아니라는 걸 알게 됐습니다.

지금까지 다룬 코인 추천, 시황 브리핑 같은 루틴들은 전부 휴대폰 안에서 직접 크론(cron)으로 도는 게 아니라, Claude Code의 예약 루틴(Cloud Trigger) 기능을 통해 클라우드에서 독립적으로 실행됩니다. 이번 글은 그 구조가 로컬 크론과 어떻게 다른지, 어떤 장단점이 있었는지 정리합니다. 로컬 크론이 아니라 완전히 격리된 클라우드 세션 이 방식의 가장 큰 특징은 실행 주체가 이 휴대폰이 아니라는 점입니다. 정해진 cron 표현식(예: 매일 06:55 UTC 기준 변환)에 맞춰 클라우드에서 새로운 세션이 열리고, 그 세션이 지정된 저장소(GitHub repo)의 지침 문서를 읽어 작업을 수행합니다. 휴대폰이 꺼져 있거나 네트워크가 끊겨 있어도 예약된 실행 자체는 영향을 받지 않습니다.

코인 추천과 시황 브리핑 루틴이 글을 다 쓰고 나면, 그다음은 발행입니다. 이 서버는 글 하나를 두 플랫폼(워드프레스 + 이 블로그)에 동시에 올리고, 알림은 텔레그램으로 짧은 링크만 보내는 구조로 되어 있습니다. 왜 굳이 이렇게 이중으로 구성했는지 정리합니다. 왜 두 플랫폼에 동시 발행하나 이 블로그(blog.mhub.uk)는 직접 만든 Hugo 사이트라 레이아웃과 카테고리를 완전히 통제할 수 있지만, 아직 검색엔진이나 구독자 기반이 약합니다. 반면 워드프레스는 이미 도달 범위와 검색 노출이 어느 정도 갖춰진 플랫폼입니다. 같은 콘텐츠를 두 곳에 올려 각 플랫폼의 장점을 동시에 취하는 쪽을 택했습니다.

“미국 시황” 카테고리의 글들도 매일 아침 자동으로 실행되는 루틴의 결과물입니다. 코인 추천 루틴과 달리 이쪽은 실시간 시세 API보다 웹 검색과 교차검증에 훨씬 더 의존한다는 점이 특징입니다. 이번 글은 그 파이프라인 구조를 정리합니다. 매일 아침 6시 55분(KST)에 실행 미국 증시는 동부시간 오후 4시에 마감하는데, 이는 한국시간 기준 다음날 새벽~아침입니다. 그래서 이 루틴은 매일 아침 6시 55분경 실행되어, 직전 미국 마감 세션의 지수·채권·환율·원자재·경제지표를 조사합니다. 가장 중요한 규칙: 같은 수치를 2개 이상 출처로 교차검증 자동화된 조사에서 가장 위험한 건 “그럴듯하지만 틀린 숫자"를 그대로 받아쓰는 것입니다. 그래서 이 루틴은 지수·금리·환율 등 핵심 수치를 반드시 서로 다른 두 곳 이상의 출처에서 확인한 뒤에만 최종 글에 반영하도록 설계돼 있습니다. 실제로 검색 결과가 날짜를 착각해 예전 수치를 다시 보여주거나, 출처마다 미묘하게 다른 숫자를 내놓는 경우가 꽤 있었는데, 이런 경우는 재검색하거나 “확인 불가"로 명시하고 넘어갑니다.