개발 일지

블로그도, API 서버도, SSH 접속도, 정기 자동 발행 작업도 전부 다른 기기로 옮겼다. quantum2에는 이제 상시로 떠 있는 서버 프로세스가 하나도 남지 않았다. 이건 실패의 기록이 아니라, 계획된 은퇴다. 정리하면서 예상 못 한 것도 하나 나왔다. 로컬 cron으로 하루 세 번 돌던 코인추천 자동화가, 실제로는 최근 며칠 동안 매번 실행될 때마다 100% 실패하고 있었다 — root 권한으로 도는 환경에서 특정 안전 옵션을 쓸 수 없다는 이유였다. 다행히 같은 작업을 처리하는 클라우드 쪽 정기 작업이 따로 살아있어서 실제 서비스에는 영향이 없었지만, 조용히 죽어 있던 자동화를 발견한 채로 그냥 넘어가지 않고 같이 정리했다. 서버를 내려놓는 작업이 아니었다면 한동안 더 몰랐을 문제다.

방마다 다양한 설정(등급 개수, 자동발송 on/off, 랜덤박스 확률 등)이 늘어나면서, 이걸 전부 카카오톡 명령어로만 조작하기엔 한계가 있었습니다. 그래서 브라우저에서 켜고 끌 수 있는 설정 페이지를 만들게 됐고, 그 과정에서 Cloudflare Tunnel 사용 방식도 함께 바뀌었습니다. 카톡 명령어로 여는 임시 링크 !설정, !랜덤박스설정 같은 명령어를 채팅방에 입력하면, 봇이 그 방 전용의 임시 설정 페이지 링크를 발급해줍니다. 이 링크는 자체 토큰이 붙어 있고 10분 동안만 유효합니다. 링크를 열면 브라우저에서 그 방의 설정을 켜고 끌 수 있는 UI가 뜹니다. 명령어를 실행한 사람만 접근 가능하도록 토큰 기반으로 제한하고, 유효시간을 짧게 둬서 링크가 유출되더라도 위험을 최소화하는 구조입니다.

Iris 봇에는 방 관리자가 명령어로 켜고 끌 수 있는 정기 자동발송 기능이 있습니다. 일정 간격으로 짧은 이모티콘 메시지를 자동으로 전송하는 단순한 기능인데, 실제 운영 환경에서는 생각보다 까다로운 문제가 있었습니다. 증상: 설정해도 며칠 지나면 꺼져 있다 관리자가 명령어로 자동발송을 켜두면 잘 동작합니다. 문제는 시간이 좀 지나고 나서 확인하면 어느새 다시 꺼져 있는 경우가 반복된다는 점이었습니다. 관리자가 실수로 끈 것도 아니고, 딱히 에러 로그가 남는 것도 아니어서 처음엔 원인을 특정하기 어려웠습니다.

양쪽 서버 다 정상, DNS도 정상, 그런데 도메인 하나만 계속 안 됐다. 원인을 끝까지 좁혀갔지만 결국 답을 못 찾은 채로 우회를 택한, 조금 다른 종류의 마무리 이야기다. 블로그를 옮길 때 썼던 것과 완전히 같은 구조 — 같은 토큰으로 두 기기에 커넥터를 하나씩 띄우는 방식 — 을 API용 도메인과 SSH용 도메인에도 그대로 적용했다. 블로그 때는 문제없이 됐던 방식인데, 이번엔 그 도메인만 응답이 아예 오지 않았다. 원인을 하나씩 지워나갔다. 새 기기의 origin(uvicorn 8000번 포트)은 로컬에서 직접 curl로 확인하니 즉시 정상 응답했다. 기존 기기(quantum2)의 origin도 마찬가지로 멀쩡했다. DNS 레코드도 API로 직접 조회해서 정확한 CNAME이 해당 터널을 가리키고 있는 걸 확인했다. Cloudflare Access 같은 접근 정책이 이 도메인에 걸려 있는지도 확인했지만 없었다. 심지어 같은 계정, 같은 방식으로 구성된 blog.mhub.uk는 그 사이에도 계속 200을 잘 돌려주고 있었다 — 즉 이 패턴 자체가 근본적으로 안 되는 게 아니라, 이 특정 터널 하나만 문제였다.

블로그 이전이 순조롭게 끝난 뒤, 같은 방식이면 나머지도 쉬울 줄 알았다. 정기 자동 실행 작업(routine)을 새 기기에 묶는 작업에서 예상 밖의 막힘이 나왔다. Anthropic의 정기 실행 시스템은 특정 세션에 “영구 바인딩"할 수 있는 옵션(persist_session)이 있다. 이게 켜져 있으면, 정해진 시각에 클라우드의 새 임시 샌드박스가 아니라 실제로 그 기기에서 계속 열려 있는 세션이 깨어나서 작업을 수행한다 — 로컬 파일이나 로컬 네트워크 접근이 필요한 작업에는 이게 필수다. 문제는 API로 새 정기 작업을 만들 때, 이 옵션이 어떤 조건에서 자동으로 켜지는지가 명확한 문서로 나와 있지 않았다는 것이다. 예전 사례를 근거로 “그 세션 안에서 직접 생성하면 자동으로 바인딩된다"고 안내했는데, 실제로 새 기기에서 똑같이 시도하니 persist_session: false로 나왔다.

여러 오픈채팅방을 동시에 운영하는 봇이라면, 관리자 권한을 한 단계로 두기 어렵습니다. 이번 글은 Iris 봇에 3단계 권한 구조를 만들면서 겪은, 계층 검사 로직에서 흔히 빠지기 쉬운 함정 하나를 기록합니다. 왜 3단계가 필요했나 봇을 여러 방에서 동시에 운영하다 보니 권한을 단순히 “관리자냐 아니냐"로만 나눌 수 없었습니다. 그래서 세 단계로 나눴습니다. 최상위 관리자: 모든 방, 모든 기능에 접근 가능한 최고 권한 방별 메인관리자: 방마다 정확히 한 명, 해당 방의 설정 전반을 관리 방별 일반관리자: 방마다 여러 명 가능, 제한된 관리 기능만 사용 상위 등급은 하위 등급의 권한을 당연히 포함해야 합니다. 최상위 관리자는 메인관리자가 할 수 있는 일도, 일반관리자가 할 수 있는 일도 모두 할 수 있어야 합니다.

호스팅 기기를 완전히 바꾸는 작업, 그것도 도메인이 걸린 실제 운영 중인 블로그를 옮기는 작업은 보통 다운타임을 전제로 한다. 이번엔 그걸 피할 수 있는 구조가 이미 손에 있었다. blog.mhub.uk는 Cloudflare Tunnel로 외부에 노출되어 있었다. 터널이라는 게 결국 “이 도메인으로 오는 요청을, 이 토큰을 가진 어떤 커넥터든 받아서 로컬 포트로 넘겨준다"는 구조라는 걸 다시 떠올렸다 — 여기서 핵심은 “어떤 커넥터든"이라는 부분이다. 하나의 터널에 같은 토큰으로 여러 개의 cloudflared 프로세스를 동시에 띄우면, Cloudflare가 이걸 자동으로 고가용성(HA) 구성으로 인식해서 트래픽을 분산하거나 장애 시 다른 쪽으로 넘긴다.

블로그 관리자 페이지를 만들면서 로그인 기능을 붙여야했다. 처음에는 구글 OTP 로그인을 붙이려고 했으나 블로그 도메인이 Cloudflare 기반으로 동작하는 점에 착안하여 Cloudflare Access로 해결하기로 했다. Cloudflare Access를 걸어서 관리자가 브라우저로 직접 접속할 때만 로그인 화면을 거치게 만드는 방식으로 구축했는데, 이 설정 하나가 전혀 예상 못 한 곳에서 자동화 파이프라인 전체를 조용히 멈춰 세웠다. Cloudflare Access는 경로 단위로 보호를 건다. 관리자 페이지 전체를 Cloudflare Access 로그인이 필요하도록 설정하면, 그 경로로 들어오는 모든 요청이 예외 없이 이 검사를 통과해야 한다 — 브라우저든, curl이든, 서버 간 자동화 스크립트든 구분하지 않는다. 문제는 코인 분석과 미국 증시 마감 시황 브리핑, 이 두 자동화 파이프라인이 새 글을 올릴 때 정확히 이 관리자 경로로 POST 요청을 보내고 있었다는 것이다.