카나리아 워크플로우: 클라이언트가 알아채기 전에 나에게 알림을 주는 가짜 n8n 작업

n8n에서 프로덕션 환경의 LLM 워크플로우를 운영하는 '빌드 인 퍼블릭(build-in-public)' 시리즈 중 일부입니다. 이번 내용은 제가 가진 가장 저렴한 보험, 즉 아무런 유용한 작업도 하지 않는 워크플로우에 관한 것입니다. 이 워크플로우는 매시간마다 클라이언트인 척 행동합니다. LLM을 호출하고, 자신에게 이메일을 보내고, 제 웹훅(webhook)을 건드리죠. 그리고 만약 그 어떤 것에서라도 이상한 낌새가 느껴지면 저에게 알림을 보냅니다. 제 고객들은 자동화 시스템이 다운되었다는 말을 단 한 번도 해준 적이 없습니다. 매번 카나리(canary)가 먼저 알려주었습니다.

최악의 알림은 클라이언트의 이메일이다

6개월 전, 저는 오전 11시 40분에 이런 메시지를 받았습니다. "혹시 요약본 자동화 시스템이 다운된 건 아닌가요? 화요일 이후로 받은 게 없어서요."

그날은 목요일이었습니다.

요약본 워크플로우는 화요일 밤부터 실패하고 있었습니다. Gmail OAuth 토큰이 만료되었는데, 이 워크플로우에는 알림 설정 자체가 되어 있지 않아 조용히 진행되고 있었던 것입니다. 이틀 동안 아무것도 발송되지 않았습니다. 고객이 저보다 먼저 알아차렸습니다. 제 모니터링 시스템이 잘못되어서가 아니라, 제가 워크플로우 내부에만 모니터링을 하고 플랫폼 자체를 모니터링하는 것이 없었기 때문입니다. 제가 소유한 모든 워크플로우는 기반 시설(foundation)이 망가졌음에도 불구하고 완벽하게 작동하는 코드로 보일 수 있었고, 저는 오직 누군가가 불평하기 전까지는 알지 못했을 것입니다.

그날 오후에 저는 "각 워크플로우를 어떻게 더 안정적으로 만들까"라는 질문을 멈추고, "이 모든 것 아래의 땅이 여전히 단단한지 어떻게 알 수 있을까"라는 질문을 하기 시작했습니다.

카나리: 가짜 워크플로우 하나, 프로브 네 개, 매시간 실행

그 답은 canary라는 이름의 워크플로우입니다. 이 워크플로우는 매시간마다 실행되지만 아무런 가치도 만들어내지 않습니다. 이 워크플로우의 유일한 임무는 제 시스템에 있는 모든 실제 워크플로우가 의존하는 네 가지 요소를 건드리는 것입니다.

1. LLM API — 가장 저렴한 모델로 10 토큰의 프롬프트("reply OK")를 전송하고 응답이 30초 이내에 도착하는지 확인합니다. 이를 통해 API 장애, 만료된 키, 그리고 모델은 작동하지만 호출당 4분이 걸리는 느린 성능 저하 문제를 감지할 수 있습니다.
2. Gmail 왕복(round-trip) — 고유한 제목으로 자신에게 이메일을 보낸 다음, 받은 편지함에서 해당 메일을 검색합니다. 이를 통해 OAuth 토큰 무효화, 범위(scope) 드리프트, 그리고 전송은 되지만 수신이 조용히 멈추는 경우를 감지할 수 있습니다.
3. Webhook 에코(echo) — 자신의 프로덕션 웹훅 중 하나로 서명된 페이로드(signed payload)를 POST하고 응답 코드가 10초 이내에 200으로 돌아오는지 확인합니다. 이를 통해 n8n 인스턴스가 다운되었거나, 리버스 프록시가 오작동했거나, TLS 인증서가 만료되는 등 전체 수신 경로(inbound path)를 엔드투엔드로 테스트할 수 있습니다.
4. n8n API 자체 쿼리(self-query) — 카나리아가 n8n API에 자신의 실행 기록을 요청합니다. 이를 통해 데이터베이스 연결 불가 및 큐 백업 문제를 감지하며, 이 두 가지 문제는 인스턴스가 실제로 아무것도 실행하지 않더라도 살아있는 것처럼 보이게 만듭니다.

각 프로브(probe)는 그 결과를 — 통과/실패 여부, 지연 시간(latency), 타임스탬프 — 한 시간에 한 행으로 로그에 기록합니다. 단 하나의 프로브라도 실패하면 Telegram을 통해 저에게 알림이 옵니다. 두 개의 프로브가 같은 실행에서 실패하면 저에게 알림이 오고 15분 동안 재확인 루프를 시작합니다. 그게 전부입니다. 전체 워크플로우는 총 9개의 노드로 구성됩니다.

카나리아를 정직하게 유지하는 네 가지 규칙

늑대 소리를 지르는 카나리아는 무시당하고, 무시당한 카나리아는 장식품에 불과합니다. 다음 규칙들은 지난 6개월 동안 제 시스템을 신뢰할 수 있게 만든 요소들입니다:

규칙 1: 카나리아는 보호하는 것보다 저렴해야 한다. 제 시스템은 LLM 호출로 월 약 $0.40이 소요됩니다 — 가장 저렴한 모델, 10 토큰의 프롬프트, 720회 실행입니다. 만약 카나리아가 실제 돈을 쓰기 시작하면, 누군가(저)는 이를 덜 자주 실행하고 싶어 할 것이고, 시간당 확인이 일일 확인에 불과하게 됩니다. 만약 당신의 카나리아가 비싸다면, 당신의 카나리아는 잘못된 것입니다. 프로브를 줄이고 스케줄을 줄이지 마십시오.

규칙 2: 건강 상태 엔드포인트가 아닌 실제 경로를 테스트하세요. /healthz가 200을 반환하는 것은 프로세스가 살아있다는 것만을 알려줄 뿐입니다. 이것이 Gmail에서 토큰을 취소했거나, 실제로 사용하는 모델이 404 오류를 반환하기 시작했거나, 또는 웹훅이 부하 상태에서 시간 초과되는 것을 의미하지는 않습니다. 제가 사용하는 프로브(probes)는 실제 작업을 수행합니다 — 실제 전송, 실제 모델 호출, 실제 웹훅 왕복 테스트입니다. 건강 상태 엔드포인트만 확인하는 카나리아는 추가 단계가 붙은 또 다른 건강 상태 엔드포인트에 불과합니다.

규칙 3: 카나리아 실패는 절대 자동 재시도해서는 안 됩니다. 이것은 의도적인 결정이었고, 처음에는 잘못된 느낌이었습니다. 제 플릿(fleet)의 다른 모든 워크플로우는 일시적 실패를 재시도하지만, 카나리아는 그렇지 않습니다. 그 이유는 다음과 같습니다. 재시도된 카나리아는 감지하도록 설계된 장애 자체를 숨깁니다. 만약 LLM API가 불안정하게 작동한다면(flapping), 저는 로그에서 그 변동을 보고 싶습니다 — 연속으로 세 시간 동안 빨간색 경고가 뜨는 것은, 재시도되어 녹색으로 돌아온 한 시간의 경고와는 다른 이야기를 합니다. 카나리아의 임무는 회복력이 뛰어난 작업자가 아니라 충실한 목격자여야 합니다. 회복력은 실제 워크플로우에 속합니다.

규칙 4: 모든 알림은 명백히 합성적(synthetic)이어야 합니다. 카나리아 이메일 제목은 [CANARY] hourly probe <timestamp>입니다. Telegram 알림도 동일한 태그로 시작합니다. 이것은 새벽 3시에 중요합니다: 제가 한눈에 이것이 테스트 실패인지, 고객 워크플로우의 실패인지를 알아야 하기 때문입니다. 또한 다른 모든 사람들에게도 중요합니다 — 카나리아의 이메일과 웹훅 히트는 로그와 받은 편지함에 나타나며, 아무도 이를 실제 트래픽으로 오해해서는 안 됩니다. 프로덕션 환경과 혼동될 수 있는 카나리아는 위험 요소가 됩니다.

카나리아가 실제로 포착한 것들

6개월 동안 네 건의 실제 사고가 발생했으며 — 이 네 경우 모두, 고객이 알아차리기 전에 카나리아가 저에게 알림을 보냈습니다:

• OAuth 토큰 취소 (원죄). Gmail이 일요일에 조용히 토큰을 취소했습니다. 카나리아의 왕복 탐지(round-trip probe)가 다음 시간에 실패했습니다. 월요일 요약본(digest) 제출 기한 전에 제가 재인증했습니다. 총 고객 영향: 제로.
• 모델 사용 중단 (Model deprecation). 제공업체가 한 워크플로우가 사용하던 정확한 모델 문자열을 사용 중단했습니다. 카나리아의 LLM 탐지(probe)는 404 스타일 오류를 반환했지만, 다른 모든 탐지는 정상이었고 — 이는 저에게 즉시 문제가 인스턴스가 아니라 모델 자체임을 알려주었습니다. 저는 전체 시스템에서 모델 문자열을 20분 만에 교체했습니다.
• 큐 백업 (Queue backup). n8n API의 자체 질의(self-query) 탐지가 시간 초과되기 시작했지만, 인스턴스의 웹 UI는 완벽하게 정상으로 보였습니다. 실행 큐는 막힌 실행 뒤에 쌓여 있었습니다. 카나리아가 없었다면 이전처럼 발견했을 것입니다: 요약본이 어디 있는지 묻는 고객의 문의를 통해서 말입니다.
• VPS에서의 TLS 인증서 만료. 웹훅 에코 탐지(webhook echo probe)가 인증서 오류와 함께 실제로 인증서가 만료되기 이틀 전에 실패했습니다 (탐지는 엄격한 TLS를 사용했기 때문에, 브라우저들은 캐싱 덕분에 여전히 괜찮았습니다). 시간이 남아있을 때 인증서를 갱신했습니다.

네 가지 사고, 고객 불만 제로. 이것이 전체 투자 수익(ROI) 진술이며, 유일하게 중요한 부분입니다.

카나리아가 볼 수 없는 실패 모드

제가 안주하지 않기 위해 스스로에게 말하는 것입니다: 카나리아는 _플랫폼_을 테스트할 뿐, _페이로드_를 테스트하지 않습니다. 이는 LLM API가 작동하고 있다는 것을 증명합니다. 제 분류 프롬프트(classify prompt)가 여전히 올바르게 분류한다는 것을 증명하지는 못합니다. 워크플로우는 모든 카나리아 검사를 통과하더라도 쓰레기를 생성할 수 있습니다 — 모델이 동작을 변경했거나, 프롬프트가 표류했거나, 입력 스키마가 이동했을 수 있습니다. 이것은 다른 실패 클래스이며, 제가 이 시리즈의 앞선 글들에서 다루는 바로 그것입니다: 녹색이지만 비어있는 실행에 대한 조용한 실패 감지기(quiet-fail detector), LLM 출력 변경을 위한 스키마 가드(schema guard), 프롬프트 표류를 위한 주간 집계(weekly tally)입니다.

제가 현재 사용하는 사고 모델은 이렇습니다: 카나리아(canary)가 "기반이 단단한가?"에 답하고, 워크플로우 내 가드(guard)들이 "작업 자체가 올바른가?"에 답합니다. 둘 다 필요하며, 하나를 다른 것으로 착각하는 것이 완벽한 가동 시간과 잘못된 결과물을 동시에 얻게 되는 방법입니다.

n8n 빌더들을 위한 시사점

만약 프로덕션 환경에서 클라이언트 워크플로우를 운영한다면, 첫 사고가 발생하기 전에 카나리아(canary)를 구축하세요. 즉, 이번 주에 구축해야 합니다. 필요한 장비는 매우 간단합니다: 크론(cron), 네 개의 프롭(probe), 하나의 로그(log), 그리고 페이지러(pager)만 있으면 됩니다. 규칙은 더 단순합니다: 비용을 저렴하게 유지하고, 실제 경로를 테스트하며, 목격자(witness)의 재시도는 절대 하지 않고, 모든 것을 합성(synthetic)으로 라벨링하세요. 이는 첫 번째 일요일에 절약해 주는 순간까지는 과잉 설계처럼 느껴질 것입니다. 그때가 되면 당신이 모든 것을 잃었을 때 가장 먼저 재구축하고 싶은 워크플로우가 될 것이며—지난번 배포할 때마다 git-버전 관리(git-versioning)를 하겠다고 글을 올린 점을 감안하면, 이제는 진지한 표정으로 할 수 있는 말이 되었습니다.

제 카나리아의 프롭 정의와 알림 패턴은 나머지 프로덕션 패턴들과 함께 github.com/zhp910318/n8n-ai-automation-lab에 문서화되어 있습니다. 네 개의 프롭을 가져가고, 네 가지 규칙을 유지하세요.

저는 AI Automation Lab을 구축하고 있습니다—프로덕션 준비가 된 n8n 워크플로우 템플릿과 컨택 페이지를 통해 고정 가격 맞춤 빌드(79달러부터)도 제공합니다. 이 시리즈의 표준 파이프라인은 AI Inbox Triage & Reply Drafter($29)로 판매되며, 무료인 AI Hook Generator는 제가 어떻게 구축하는지 위험 부담 없이 볼 수 있는 방법입니다. 저의 오픈 소스 패턴은 github.com/zhp910318/n8n-ai-automation-lab에서 확인하실 수 있습니다.