하루 두세 번, 업비트 시세를 모아 코인 추천 글을 자동으로 쓰고 텔레그램에 발송하는 파이프라인이 있다. 처음엔 이 파이프라인의 연결 고리(시세 조회, 텔레그램 릴레이)를 전부 Zapier로 짰다. 문제는 그 편리함에 비용이 따라온다는 것이었다 — 할당량이 생각보다 빨리 소진됐다.

같은 일을 Make로 옮기는 작업은 단순 이전이 아니었다. 텔레그램 발송처럼 “메시지 하나 보내고 끝"인 시나리오는 쉬웠지만, 업비트 시세 조회는 “HTTP 요청을 보내고 결과를 그 자리에서 돌려받아야” 하는 요청-응답형 작업이라 난이도가 달랐다. Make의 시나리오는 기본적으로 비동기 워크플로우 모델이라, 이걸 동기 호출처럼 쓰려면 HTTP 모듈로 요청을 구성한 뒤 별도로 응답 인터페이스를 설정하고, responsive: true 옵션으로 호출하면 결과가 그 자리에서 돌아오게 만드는 구조가 필요했다.

이 구조를 실제로 만들고 나서 반드시 거친 절차가 있었다 — 새 시나리오만 따로 실행해서 시세 데이터가 정상적으로 돌아오는지 먼저 확인하고, 그 검증이 끝난 뒤에야 실제 코인추천 트리거의 프롬프트를 수정해서 이 새 경로를 쓰도록 바꿨다. 자동화 파이프라인의 특정 단계 하나를 바꿀 때, 그 단계만 독립적으로 검증하지 않고 전체 트리거를 재실행해서 확인하면 실패했을 때 어느 지점이 문제인지 알기 어렵다는 걸 이전에 겪어본 뒤로 생긴 습관이다.

이 파이프라인을 운영하면서 반복적으로 부딪힌 다른 문제도 있었다. 하나는 워드프레스 MCP 연결이 짧은 시간에 여러 번 인증을 시도하면 로그인 서버 쪽에서 자체적으로 요청을 제한한다는 것이었다 — 트리거를 연속으로 여러 번 재실행시키면서 겪었다. 이때는 무작정 재시도하지 않고, 몇 분 기다린 뒤 다시 확인하는 쪽을 택했다. 재시도를 서두르는 게 오히려 제한을 더 강하게 만들 수 있어서다.

또 하나는 썸네일 이미지가 밤 시간대 실행에서 깨져 보이는 문제였다. 원인은 이미지를 워드프레스에 올릴 때 쓰던 base64 인코딩 방식에 있었다 — 인코딩 함수를 줄바꿈이 포함된 방식으로 바꾸고 나서야 특정 시간대에만 재현되던 깨짐 현상이 사라졌다.

결과적으로 지금은 시세 조회부터 글쓰기, 텔레그램 발송까지 전부 Zapier 의존 없이 돌아간다. 다만 이 파이프라인은 이후 두 갈래로 갈라진다 — 하나는 클라우드에서 정해진 시각에 자동으로 깨어나는 정기 실행 루틴으로, 다른 하나는 이 폰의 로컬 cron으로. 이 로컬 cron 쪽에 숨어 있던 문제는 나중에 이 폰이 서버 역할을 완전히 내려놓을 때가 되어서야 발견됐는데, 그 이야기는 시리즈 뒷부분에서 다룬다.