대부분의 경우 n8n 채팅 웹훅(chat webhook)은 대화에 걸쳐 분산된 소수의 메시지와 같은 일반적인 트래픽을 처리합니다. 그러다 무언가가 갑작스러운 트래픽 폭증(burst)을 보냅니다. 엔드포인트(endpoint)를 스크래핑하는 봇, 열려 있는 웹훅을 탐색하는 스캐너, 또는 한꺼번에 유입되는 실제 방문자의 급증 등이 이에 해당합니다. 이러한 요청 하나하나가 다운스트림(downstream)에서 유료 API 호출을 트리거할 수 있습니다. 만약 당신의 워크플로(workflow)가 메시지마다 OpenAI를 호출한다면, 트래픽 폭증은 단순한 트래픽 급증이 아니라 비용 급증이 됩니다.

이것이 실제 문제입니다. "누군가 내 웹훅 URL을 찾아냈다"와 "내 워크플로가 실행되었고, 그들이 보낸 모든 요청에 대해 비용을 지불했다" 사이를 막아줄 장치가 아무것도 없다는 점입니다.

트래픽 폭증이 실제로 발생하는 곳

웹훅 URL이 공용 인터넷에서 접근 가능해지면, 당신의 위젯(widget)뿐만 아니라 HTTP 요청을 보낼 수 있는 모든 것이 접근할 수 있게 됩니다. 공개용 봇을 구축하던 한 포럼 사용자가 이 문제에 직접 직면하여 "잠재적인 DDOS를 피하고 크레딧을 절약하기 위해 여러분은 무엇을 하나요"라고 질문하기도 했습니다. 봇과 스캐너는 당신의 워크플로가 무엇을 하는지 알 필요가 없습니다. 그들은 URL만 있으면 되며, 채팅 위젯의 웹훅은 페이지 소스를 읽는 누구에게나 매우 쉽게 발견될 수 있습니다.

정당한 트래픽도 폭증할 수 있습니다. 여러 방문자가 동시에 위젯에 접속하거나, 첫 번째 클릭이 등록되었다는 표시가 없어 한 방문자가 전송 버튼을 두 번 클릭하는 경우에도 동일한 형태의 문제가 발생합니다. 즉, 워크플로나 다운스트림 API 예산이 감당하도록 설계된 것보다 짧은 시간 내에 더 많은 요청이 들어오는 것입니다.

어떤 경우든, 워크플로는 스크립트로 엔드포인트를 두들기는 재시도(retries) 폭증과 실제 20명의 사람이 동시에 도착하는 상황을 구분할 방법이 없습니다. 세 가지 경우 모두 요청의 더미처럼 보입니다. 그 지점 이전에 무언가가 필터링하지 않는 한, 세 가지 모두 워크플로 뒤에 있는 유료 API로 전달됩니다.

트래픽 폭증과 API 청구서 사이의 단계

방문자 / 봇 / 스크립트
        |
        v
...

게이트웨이 단계가 없다면, 위의 모든 화살표는 하나로 합쳐집니다: 브라우저에서 n8n으로, 그리고 n8n에서 OpenAI로 직행하게 됩니다. "요청 도착"과 "API 과금" 사이에 아무것도 존재하지 않게 되는 것입니다.

워크플로(Workflow) 수준의 해결책이 이를 막지 못하는 이유

본능적인 대응은 n8n 내부에서 이를 처리하는 것입니다. 직접 체크 로직을 만들거나, Wait 노드를 추가하거나, 중복된 페이로드(Payload)를 제거(Dedupe)하는 식입니다. 동일한 포럼 스레드에서는 Cloudflare WAF 규칙을 직접 만들고 위젯 위에 JS 난독화(Obfuscation)를 적용하는 방안이 제시되기도 했습니다. 이는 실질적인 임시방편(Workaround)이 될 수는 있지만, 동시에 해결책이 워크플로 내부에 있지 않다는 신호이기도 합니다. 난독화된 JavaScript는 여전히 브라우저에서 실행되므로, 결심을 굳힌 스크립트는 여전히 URL을 추출하여 위젯(및 모든 클라이언트 측 로직)을 완전히 우회하여 직접 호출할 수 있기 때문입니다.

워크플로 수준의 설정, 중복 제거(Dedupe) 노드, 순차적 실행(Sequential execution) 등은 n8n이 요청을 이미 수락한 이후에 이를 어떻게 처리할지를 제어합니다. 이들은 요청이 애초에 수락될지 여부를 제어하지 못합니다. 또한, 서비스할 가치가 있는 트래픽 폭증과 차단해야 할 트래픽 폭증을 구분할 수도 없습니다. 요청이 워크플로에 도달하는 시점에는, 그로 인해 하류(Downstream)에서 발생할 비용이 이미 확정된 상태입니다.

올바른 해결책: 웹훅(Webhook) 내부가 아닌, 웹훅 앞단에서 스로틀링(Throttle)하기

목표가 "트래픽 폭증으로 인한 비용 상한선 설정"이라면, 이는 요청이 워크플로 실행이나 OpenAI 호출로 이어지기 전, 즉 요청을 가장 먼저 받는 계층에서 이루어져야 합니다. 웹훅 앞단에 IP 및 세션별로 속도 제한(Rate limiting)을 수행하는 게이트웨이를 두면, 봇이나 스크립트, 혹은 비정상적으로 트래픽이 몰리는 방문자가 하류의 어떤 기능도 트리거되기 전에 즉시 벽에 부딪히게 됩니다.

토큰 버킷(Token-bucket) 속도 제한이란 정확히 무엇인가

토큰 버킷은 클라이언트당(여기서는 IP 및 세션당) 적용되는 간단한 카운터입니다. 버킷은 가득 찬 상태로 시작하여, 일정 상한선까지 초당 1개와 같은 일정한 속도로 채워집니다. 모든 요청은 1개의 토큰을 소모합니다. 토큰이 충분히 남아 있다면 요청이 통과됩니다. 버킷이 비어 있다면, 버킷이 다시 채워질 때까지 요청은 거부됩니다.

그 결과: 대화 전반에 걸쳐 몇 개의 메시지가 분산되는 일반적인 채팅 동작은 버킷을 결코 소모시키지 않습니다. 하지만 스크립트에 의한 것이든 실수든 갑작스러운 폭증(burst)이 발생하면 버킷은 빠르게 소모되며, 워크플로(workflow) 실행이나 API 호출이 일어나기도 전에 즉시 제한(throttled)됩니다. 이는 다운스트림(downstream)에서 에러가 발생하는 것보다 더 깔끔한 실패 모드입니다. 요청이 비용을 발생시킬 만큼 멀리 진행되지 않으므로, 위젯은 채팅이 고장 난 것처럼 보이는 대신 정상적인 "속도를 줄여주세요" 메시지를 표시할 수 있습니다.

직접 해당 계층 구축하기

핵심 아이디어는 IP 또는 세션당 카운터, 재충전 속도(refill rate), 그리고 요청이 전달되기 전의 확인 절차를 두는 것입니다. 더 어려운 부분은 제한기(limiter) 자체를 우회하기 어렵게 만드는 것입니다. IP당 제한(Per-IP limiting)만으로는 취약합니다. 공유 네트워크를 사용하거나 새로운 IP로 재연결되는 세션은 카운트를 초기화하기 때문입니다. 세션당 제한(Per-session limiting)만으로도 취약합니다. 스크립트는 사용자가 차단하는 속도보다 더 빠르게 새로운 세션을 생성할 수 있습니다. 두 가지 모두가 필요하며, 세션 측면은 스크립트가 즉석에서 위조할 수 없는 것, 즉 일반 쿠키(cookie)가 아닌 서명된 토큰(signed token)과 연결되어야 합니다.

이는 브라우저로부터 n8n 웹훅 URL을 숨기는 방법에 설명된 나머지 프록시(proxy) 작업 외에도 지속적으로 유지 관리해야 하는 보안 표면(security surface)입니다. 이미 해당 프록시를 운영 중이라면, 속도 제한(rate limiting)은 동일한 계층에 포함되어야 합니다.

ChatFlowGate가 n8n에 도달하기 전 요청의 속도를 제한하는 방법

이것이 바로 ChatFlowGate가 위치하는 지점입니다. n8n 웹훅의 앞단에서, 요청이 n8n에 도달하거나 다운스트림 API 호출을 트리거하기 전에 IP 및 세션별로 토큰 버킷(token-bucket) 속도 제한을 수행합니다. 엔드포인트(endpoint)를 몰아치는 봇이나 URL을 찾아낸 스캐너는 n8n이 아닌 게이트웨이(gateway)에서 제한되므로, 귀하의 OpenAI 계정에 비용이 청구되지 않습니다.

세션은 HMAC-SHA256으로 서명되며 24시간의 만료 시간을 가진 봇 바운드(bot-bound) 방식으로 관리됩니다. 따라서 리미터(limiter)의 세션당 제한 기능은 스크립트가 카운트를 피하기 위해 새로운 복사본을 생성할 수 없는 요소와 결합되어 있습니다. 오리진 검증(Origin validation) 및 도메인 화이트리스트(domain allowlisting)는 엔드포인트가 귀하의 위젯 외부에서 호출되는 것을 애초에 차단합니다. IP 차단, 국가 허용/차단 목록, 그리고 스팸 트랩(spam traps)은 일반적인 폭증(burst) 이상의 남용 패턴을 처리합니다. 이 중 그 어떤 것도 귀하의 n8n 워크플로우(workflow)에 영향을 주지 않습니다. n8n은 여전히 리미터를 통과한 메시지당 하나의 웹훅(webhook) 호출을 받게 되며, 다만 그 호출이 폭증을 일으킨 대상으로부터 직접 오는 것이 아니라 게이트웨이(gateway)를 통해 들어올 뿐입니다.

설정 방법:

1. ChatFlowGate의 봇 웹훅(webhook)을 기존의 n8n 웹훅 URL로 지정합니다.
2. 속도 제한(Rate limits)은 IP당 및 세션당 자동으로 적용되며, n8n 측에서의 별도 설정은 필요하지 않습니다.
3. 단일 스크립트 임베드(embed)를 삽입합니다. 폭증 트래픽은 게이트웨이에서 조절(throttled)되며, 귀하의 다운스트림(downstream) API 호출은 리미터를 통과한 요청에 대해서만 실행됩니다.
4. 워크플로우 내부에 이미 구현된 중복 제거(dedupe) 또는 스로틀링(throttling) 로직은 이 하위에서 여전히 잘 작동하며, 단지 워크플로우에 도달하는 폭증 트래픽 자체가 훨씬 적어질 뿐입니다.

무료 티어는 하나의 봇에 대해 한 달에 500개의 메시지를 지원하며, 이는 실제 채팅 위젯을 연결하여 본격적인 도입 전에 실제 폭증 상황에서 리미터가 잘 버티는지 확인하기에 충분한 양입니다.

FAQ

n8n 앞에 설정하는 WAF 규칙과는 어떻게 다른가요?
일반적인 WAF 규칙은 채팅 세션에 대해 알지 못합니다. IP별로 속도 제한을 할 수는 있지만, "이 방문자는 이미 유효한 세션을 가지고 있다"라는 개념은 없습니다. 세션당 제한(Per-session limiting)을 사용하면 공유 IP(사무실 와이파이, VPN)를 사용하는 정당한 방문자가 실제 봇과 함께 제한을 받는 일을 방지할 수 있습니다.

이미 웹훅 URL을 확보한 스크래퍼(scraper)를 막을 수 있나요?
그들이 n8n이 아닌 ChatFlowGate의 게이트웨이 URL을 호출하고 있다면, 그렇습니다. 리미터는 요청이 어디서 왔는지와 관계없이 모든 요청에 적용됩니다. 또한, 애초에 웹훅 URL을 브라우저로부터 숨기는 것이 중요한 이유이기도 합니다(위의 링크된 포스트를 참조하세요).

정상적인 트래픽 폭증도 제한(Throttled)되나요?
몇 명의 실제 방문자가 거의 동시에 도착하는 것과 같은 일반적인 급증(bursts)은 토큰 버킷(token bucket)의 리필 속도 범위 내에 충분히 머뭅니다. 제한기(limiter)는 방문자 타이밍의 일반적인 변동이 아니라, 지속적이거나 스크립트로 짜인 급증을 포착하도록 조정되어 있습니다.

트래픽이 적고 아직 급증이 문제가 되지 않는다면 어떻게 하나요?
그렇다면 이는 긴급한 사항이 아닙니다. 하지만 봇이 URL을 찾아내는 순간 상황은 긴급해지며, 그때는 예상치 못한 청구서 대신 5분 정도의 설정만으로 문제를 해결할 수 있습니다.

봇이 귀하의 채팅 위젯 웹훅(webhook)을 처음 발견했을 때 API 비용에 어떤 일이 벌어질지 확신할 수 없다면, 실제로 그런 일이 일어나기 전에 확인해 볼 가치가 있습니다. chatflowgate.com에서는 실제 워크플로우(workflow)에 대해 제한기가 어떻게 작동하는지 확인할 수 있는 무료 티어(free tier)를 제공합니다.