개발 일지

이번 글은 겉보기엔 서버 쪽 로직이 아니라 아주 평범한 웹 프론트엔드 버그처럼 보였지만, 실제로는 모바일 브라우저의 특성을 몰라서 한참 헤맸던 사례입니다. 채팅 랭킹과 등급 시스템 Iris 봇에는 누적 채팅 수에 따라 자동으로 등급이 올라가는 채팅 랭킹 시스템이 있습니다. 이번에 포팅하면서 기존 방식(누적 채팅수 기반 자동 승급)에 더해, 포인트를 소모해서 등급을 직접 “구매"하는 방식도 선택적으로 켤 수 있도록 기능을 추가했습니다. 등급 자체의 개수(최대 6개)도 방마다 다르게 설정할 수 있게 만들었습니다. 증상: 줄이기는 되는데 늘리기가 안 된다 이 등급 개수를 설정하는 UI는 숫자 입력창(스피너)이었습니다. 테스트해보니 이상한 패턴이 나타났습니다 — 값을 줄이는 건 잘 되는데, 늘리는 조작만 화면에 반영되지 않는 것처럼 보였습니다. 처음엔 서버 쪽 유효성 검사 로직이 최댓값을 잘못 제한하고 있는 줄 알고 그쪽을 한참 들여다봤지만 문제가 없었습니다.

구글 애드센스 사이트 소유권 인증이 계속 실패했다. “사이트를 확인할 수 없습니다"라는 메시지만 반복해서 뜨고, 메타태그도 붙였고 스니펫도 넣었는데 변화가 없었다. 가장 먼저 의심한 건 Cloudflare의 Bot Fight Mode였다. 자동화된 크롤러를 막는 기능이니, 구글 애드센스의 검증 크롤러도 같이 막고 있을 가능성이 실무에서 꽤 흔한 원인이기 때문이다. 그런데 이 설정을 대시보드에서 찾는 것부터 난관이었다 — 클라우드플레어 UI가 한글로 번역되어 있다 보니 메뉴 이름과 실제 기능이 매끄럽게 매칭되지 않았고, 예전에 봤던 것 같은 비슷한 화면은 정작 모드를 바꿀 수 있게 되어 있지도 않았다.

Iris로 카카오톡 봇을 포팅하면서 가장 흥미로웠던 부분은, 공식 문서가 없는 프로토콜을 상대로 직접 원인을 추적해야 하는 순간들이었습니다. 이번 글은 그중에서도 가장 인상 깊었던 사례 하나를 기록합니다. 만들고 싶었던 기능: 메시지 삭제 감지 오픈채팅방을 운영하다 보면 메시지가 사라지는 경우가 두 가지 있습니다. 하나는 운영진이 특정 메시지를 “가리기”(숨김) 처리하는 경우, 다른 하나는 작성자 본인이 자기 메시지를 “스스로 삭제"하는 경우입니다. 이 둘을 구분해서 감지하는 기능을 만들고 싶었습니다 — 운영 로그를 남기거나, 특정 조건에서 자동 대응하기 위해서였습니다.

블로그 관리자 페이지의 글쓰기 에디터를 세 번 연속으로 다시 만들었다. 세 번 다 “고쳤다"고 생각했는데, 실제로 브라우저를 열면 카테고리 목록도 안 뜨고 툴바 버튼도 하나도 반응하지 않았다. 원인은 라이브러리가 아니라, 훨씬 더 근본적인 곳에 있었다. 처음 시도는 Tiptap이었다. esm.sh CDN에서 @tiptap/core, @tiptap/starter-kit, @tiptap/extension-placeholder를 각각 따로 불러왔는데, 패키지마다 별도로 번들링된 esm.sh 특성상 같은 클래스가 서로 다른 인스턴스로 중복 로드될 위험이 있는 조합이었다. 전혀 동작하지 않아서 Quill.js로 바꿨다 — 단일 UMD 스크립트라 이 위험 자체가 없는 선택이었다. 그런데도 여전히 안 됐다.

지난 글에서 카카오톡 봇 Iris를 관리자·랭킹·경제·경마·미니게임·경매·AI 등 9개 파일로 나눴다는 이야기를 했습니다. 이번 글은 그 과정에서 실제로 부딪힌, 파이썬을 오래 써도 은근히 잘 모르고 지나가는 함정 하나를 기록합니다. 증상: 봇이 두 번 뜬다 메인 파일 irispy.py를 python3 irispy.py로 직접 실행해서 봇을 띄웠습니다. 문제는 서브 모듈(예: 랭킹 기능 파일)에서 메인의 봇 인스턴스나 DB 헬퍼 함수를 쓰려고 import irispy를 했을 때 발생했습니다. 봇이 두 개가 뜬 것처럼 동작하거나, 초기화 로직이 중복 실행되는 이상한 증상이 나타났습니다.

하루 두세 번, 업비트 시세를 모아 코인 추천 글을 자동으로 쓰고 텔레그램에 발송하는 파이프라인이 있다. 처음엔 이 파이프라인의 연결 고리(시세 조회, 텔레그램 릴레이)를 전부 Zapier로 짰다. 문제는 그 편리함에 비용이 따라온다는 것이었다 — 할당량이 생각보다 빨리 소진됐다. 같은 일을 Make로 옮기는 작업은 단순 이전이 아니었다. 텔레그램 발송처럼 “메시지 하나 보내고 끝"인 시나리오는 쉬웠지만, 업비트 시세 조회는 “HTTP 요청을 보내고 결과를 그 자리에서 돌려받아야” 하는 요청-응답형 작업이라 난이도가 달랐다. Make의 시나리오는 기본적으로 비동기 워크플로우 모델이라, 이걸 동기 호출처럼 쓰려면 HTTP 모듈로 요청을 구성한 뒤 별도로 응답 인터페이스를 설정하고, responsive: true 옵션으로 호출하면 결과가 그 자리에서 돌아오게 만드는 구조가 필요했다.

지난 글에서 루팅된 갤럭시 S9 위에 Termux + proot-distro로 서버 환경을 만든 이야기를 했습니다. 이번 글은 그 위에 실제로 올린 첫 번째이자 가장 중요한 서비스, 카카오톡 챗봇 “Iris” 이야기입니다. Iris란 Iris는 루팅된 안드로이드 기기에서 카카오톡 클라이언트의 로컬 메시지 DB를 직접 읽고, app_process로 띄운 데몬이 HTTP API(127.0.0.1:3000)와 웹소켓 이벤트를 제공하는 프레임워크입니다. 카카오톡 자체의 공식 API가 아니라, 기기에 이미 로그인되어 있는 카카오톡 앱의 데이터를 활용하는 방식이라 루팅된 기기가 전제 조건입니다. 왜 포팅이 필요했나 원래는 “메신저봇R"이라는 Node.js 기반 봇으로 채팅 랭킹, 아이템 경제, 경마 게임, 미니게임, 경매, AI 질문 응답 같은 기능들을 이미 운영하고 있었습니다. 이번 작업은 그 기존 코드와 기획을 Iris(파이썬) 환경으로 전면 포팅하는 것이었습니다. 단순히 언어만 바꾸는 게 아니라, 프레임워크가 제공하는 이벤트/API 모델 자체가 다르기 때문에 상당 부분을 다시 설계해야 했습니다.

무료 AI API 하나만 물려서 쓰면 반드시 하루 어딘가에서 한도에 걸린다. 이걸 해결하려고 만든 게 3단 폴백 구조의 작은 FastAPI 서버였다. 순서는 Cloudflare Workers AI → Groq → Gemini다. 처음엔 Gemini를 1순위로 뒀는데, 자동응답 기능이 Gemini의 하루 500회 한도를 낮 시간에 다 써버리면 정작 사람이 직접 명령어를 칠 때 쓸 한도가 안 남는 문제가 있었다. 그래서 “사실상 무제한"이라고 생각했던 Cloudflare Workers AI를 앞으로 보내고, 응답 형식이 엄격하게 필요한 자동응답 호출만 별도로 Groq부터 시작하도록 순서를 분기했다.

루팅을 마치고 Termux + proot-distro로 서버 환경까지 만들었는데, 정작 그 위에서 tmux 세션들이 가만히 있다가 조용히 죽어있는 일이 반복됐습니다. 카카오톡 봇이 이유 없이 응답을 멈추길래 확인해보면, Termux 프로세스 자체가 안드로이드 시스템에 의해 강제 종료돼 있었습니다. 이번 글은 그 문제를 해결하기까지의 과정입니다. 증상: 화면을 안 보고 있으면 죽는다 패턴은 명확했습니다. 화면을 켜서 Termux를 보고 있을 때는 멀쩡하다가, 다른 앱을 쓰거나 화면을 꺼두고 시간이 좀 지나면 tmux 세션 안의 프로세스들이 통째로 죽어있는 경우가 잦았습니다. 전형적인 안드로이드의 백그라운드 프로세스 관리 — 특히 삼성 기기의 배터리 최적화가 공격적이기로 유명합니다 — 에 의해 Termux가 “안 쓰는 앱"으로 분류되어 정리되는 것으로 보였습니다.