갤럭시S9

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

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

루팅과 Termux 환경까지 다 갖춰놓고도, 정작 카카오톡 봇의 핵심인 IRIS 서버 APK 하나가 설치되지 않아 발목을 잡힌 적이 있다. 원인과 해결법, 그리고 이후 장애 복구 때마다 참고하는 수동 기동 절차를 정리해둔다. Termux 사이드로딩부터 막혔다 Termux 자체를 F-Droid나 GitHub에서 받은 arm64-v8a apk로 설치하려는 시도부터 전부 “패키지를 파싱하는 중 문제가 발생했습니다"로 실패했다. adb install로 우회해봐도 이번엔 INSTALL_FAILED_VERIFICATION_FAILURE로 막혔다. 원인은 Play Protect였다. 설정 → Play 스토어 → Play Protect → “기기에서 앱 검사” 토글이 켜져 있으면, Play 스토어 밖에서 받은 apk의 설치 자체를 사전 검증 단계에서 막아버린다. 이 폰은 개인용이 아니라 전용 서버로만 쓸 것이므로 이 토글을 영구적으로 꺼두기로 했다. 이후 Termux(v0.118.3, GitHub release)는 문제없이 설치됐다.

지금까지 나는 유휴 휴대폰 두 대를 각각 다른 용도의 서버로 굴리고 있었다. 갤럭시 퀀텀2는 Cloudflare Tunnel로 노출된 FastAPI 기반 업비트 시세 서버, 갤럭시 S9는 루팅해서 만든 IRIS 카카오톡 봇 서버. 이번에 이 두 서버의 기능을 S9 하나로 합쳤다. 왜 합쳤나 두 폰을 따로 유지보수하는 비용이 생각보다 컸다. 각 폰마다 Termux 환경, proot-Ubuntu, Claude Code 원격 세션을 따로 관리해야 했고, 장애가 나면 어느 폰의 어느 서비스인지부터 확인해야 했다. 서버 자체의 부하는 두 서비스를 합쳐도 충분히 감당할 수준이라 판단해서, 한 대로 통합하는 쪽을 택했다.

상시 구동 서버로 쓰고 있는 루팅 갤럭시 S9(SM-G960N)의 저장 공간이 빠듯해졌다. RAM도 4GB에 실제 스왑은 2GB뿐이라, “SD카드를 추가로 사서 스왑으로 쓰면 메모리 부족 문제까지 같이 해결되지 않을까” 하는 생각이 들었다. 결론부터 말하면 그렇게 하지 않기로 했다. 안드로이드는 이미 zram을 쓰고 있다 먼저 확인해야 했던 건 이 폰이 이미 스왑 비슷한 걸 쓰고 있는지였다. cat /proc/swaps free -h /dev/block/zram0 항목이 보이면, 이미 zram(RAM 일부를 압축해서 스왑처럼 쓰는 방식)이 동작 중이라는 뜻이다. 디스크 기반 스왑이 아니라 RAM 안에서 압축·해제하는 방식이라, SD카드 스왑을 추가로 얹는 것과는 성격이 다르다.

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

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