개발 일지

이 블로그의 “코인 분석” 카테고리에 올라오는 글들은 사람이 매번 손으로 쓴 게 아니라, 하루 세 번(07시·13시·19시) 자동으로 실행되는 루틴이 작성해 발행한 것입니다. 이번 글은 그 자동화가 어떻게 만들어졌는지, IT 시리즈 관점에서 정리합니다. 루틴이 하는 일 정해진 시각이 되면 업비트 시세를 스크리닝해서 특정 기술적 조건(변동성 패턴, 박스권 이탈, 반등 신호 등)을 만족하는 종목을 후보로 골라내고, 각 후보에 대해 손절가와 목표가를 계산합니다. 그 결과를 정해진 형식의 글로 작성해 자동으로 발행까지 마칩니다.

앞선 글에서 다룬 다중 AI 모델 폴백 구조가 제대로 작동하려면, 지금 각 모델의 한도가 얼마나 남았는지를 정확히 알아야 합니다. 이번 글은 무료 티어 한도 안에서 챗봇을 24시간 돌리기 위해 실제로 적용한 관리 방법들입니다. 사용량을 모델별로 따로 기록한다 모든 AI 호출 결과를 로그 파일에 남기되, 모델별로 분리해서 관리합니다. Groq는 일일 토큰 총량을 별도 파일에 누적 기록하고, 다른 모델들도 각자의 한도 체계(요청 수 기준, 토큰 수 기준 등)에 맞춰 따로 추적합니다. 이렇게 모델별로 분리해두지 않으면 폴백 순서를 정할 때 “지금 어떤 모델이 여유가 있는지"를 판단할 근거가 없습니다.

이 휴대폰 서버의 핵심 기능 중 하나는 카카오톡으로 말을 걸면 AI가 답해주는 개인용 챗봇입니다. 처음엔 모델 하나만 붙여도 될 줄 알았는데, 무료 티어의 일일/분당 한도에 자주 걸리면서 “한도가 다 찼을 때 챗봇이 그냥 조용해지는” 문제를 겪었고, 이를 해결하기 위해 여러 AI 모델을 자동으로 오가는 폴백 구조를 만들게 됐습니다. 문제: 모델 하나에 의존하면 챗봇이 먹통이 된다 무료 API 한도는 모델마다 다르게 책정되어 있고, 사용량이 몰리는 시간대에는 순식간에 소진됩니다. 한 모델만 쓰면 한도를 넘는 순간부터 챗봇이 응답하지 않는 시간대가 생깁니다. 개인용으로 24시간 돌리는 챗봇이라면 이건 꽤 치명적인 문제였습니다.

이 서버를 세팅하면서 가장 자주 반복된 문제 하나를 꼽으라면 단연 apt-get입니다. Hugo, Caddy, 한글 폰트 패키지까지 — 덩치가 좀 있는 패키지를 설치하려 할 때마다 모바일 네트워크 환경에서 다운로드가 멈춘 채로 응답이 없는 상황을 여러 번 겪었습니다. 이번 글은 그 문제를 어떻게 우회했는지 기록입니다. 증상: 멈췄는지 느린 건지 구분이 안 된다 apt-get install -y <패키지>를 실행하면 진행률 표시 없이 그냥 멈춘 것처럼 보이는 경우가 많았습니다. timeout 60으로 감싸서 실행해도 60초 안에 끝나지 않고 그대로 종료(exit code 143)되는 일이 반복됐는데, 재시도해도 같은 패턴이 이어졌습니다. 원인은 명확히 특정하지는 못했지만, 모바일 데이터/와이파이 전환 구간에서 저장소 미러 서버와의 연결이 불안정했던 것으로 추정합니다.

지금 보고 계신 이 블로그(blog.mhub.uk) 자체가 이 시리즈의 소재입니다. Hugo 정적 사이트 생성기와 PaperMod 테마로 시작해서, 최근에는 카테고리 사이드바·추천글·전체 글 목록으로 이루어진 3분할 홈 화면으로 직접 레이아웃을 손봤습니다. 왜 Hugo인가 Hugo는 빌드마다 서버 자원을 거의 쓰지 않는 정적 사이트 생성기입니다. 휴대폰처럼 자원이 넉넉하지 않은 환경에서는 매 요청마다 서버 사이드 렌더링을 하는 방식보다, 미리 HTML을 만들어 두고 Caddy가 그냥 파일을 서빙하는 쪽이 훨씬 가볍습니다. 글을 쓰거나 설정을 바꿀 때만 hugo --minify로 다시 빌드하면 끝입니다.

휴대폰 안에 리눅스 환경을 만들었다고 해도, 그 안에서 돌아가는 웹사이트나 API를 외부에서 접속할 수 없다면 서버로서 의미가 없습니다. 문제는 이 폰이 가정용 모바일/와이파이 네트워크 뒤에 있어서 고정 공인 IP도, 포트포워딩도 쓸 수 없다는 점이었습니다. 이번 글은 이 문제를 Cloudflare Tunnel과 Caddy 조합으로 해결한 과정입니다. Cloudflare Tunnel: 포트를 열지 않고 밖으로 나가는 통로 Cloudflare Tunnel(cloudflared)은 서버 쪽에서 Cloudflare로 나가는 아웃바운드 연결만 유지하면, 외부 요청이 그 터널을 통해 들어오는 구조입니다. 방화벽에서 인바운드 포트를 하나도 열 필요가 없다는 게 핵심입니다. 도메인(blog.mhub.uk 등)을 Cloudflare에 연결해두고, cloudflared가 로컬에서 실행 중인 서비스로 트래픽을 넘겨주도록 설정했습니다.

서랍 속 유휴 휴대폰을 서버로 쓰기로 결심한 다음 가장 먼저 부딪힌 질문은 “루트 권한도 없는 안드로이드 폰에서 어떻게 진짜 서버 환경을 만들 것인가"였습니다. 이번 글에서는 실제로 이 서버를 세팅할 때 사용한 Termux + proot-distro 조합을 정리합니다. 왜 Termux인가 Termux는 안드로이드 위에서 동작하는 터미널 에뮬레이터이자 패키지 관리 환경입니다. 루트 권한 없이도 apt 기반 패키지 설치, SSH, Python, Node.js 실행이 가능합니다. 다만 Termux 자체의 리눅스 환경은 안드로이드 샌드박스 제약 때문에 일반 리눅스 배포판과 100% 동일하지는 않습니다. 그래서 그 위에 proot-distro를 얹어 진짜 우분투 환경을 통째로 격리 실행하는 방식을 선택했습니다.

서랍 속에 수년째 잠들어 있던 아주 오래된 구형 안드로이드 폰이 있었습니다. 업데이트도 중단되고 최근 앱을 실행하기에는 메모리도 부족해서 사용할 곳이 없는 고철덩어리였습니다. 서랍 속에서 완전히 죽은 기기로 남아 있던 이 휴대폰을 사용할 수 있을 방법이 없을까 고민했습니다. 이 블로그의 “IT” 카테고리는 그 폰을 어떻게든 다시 살려보자는 생각에서 시작됐습니다. 왜 하필 휴대폰이었나 집에 굴러다니는 구형 휴대폰보다는 라즈베리파이나 미니PC를 쓰는 게 훨씬 정석적인 방법이라는 건 알고 있었습니다. 하지만 따로 하드웨어를 사야 하고, 전용 전원과 공간도 필요합니다. 반면 안드로이드 폰은 이미 배터리(=UPS 역할)와 와이파이·모바일 데이터(=이중 네트워크)를 갖춘 완결된 소형 컴퓨터입니다. 성능은 요즘 서버용 CPU에 비할 바는 아니지만, 개인이 돌리는 자동화 스크립트나 소규모 챗봇 정도는 감당하기에 충분하다고 판단했습니다. “안 쓰는 자원을 최대한 활용해보자"는 것이 가장 솔직한 동기였습니다.