챗봇이 방송 중 두 번 응답할 때 해야 할 일

먼저 중복의 유형을 파악하세요

똑같은 응답이 연달아 두 번 오는 것은 하나의 고장이 아니라 최소 두 가지의 서로 다른 문제입니다. 첫 번째 경우: 봇이 하나의 이벤트를 받았지만 두 번 받았습니다. 두 번째: 이벤트는 하나만 왔는데 봇이 두 번 보냈습니다. 해결 방법이 다르므로 코드 수정부터 시작하지 말고 로그부터 확인하세요.

봇의 로그를 열고 중복이 발생한 시점을 찾으세요. 그다음 두 필드를 보세요: 이벤트 식별자와 수신 시간입니다.

• 동일한 event_id(또는 message_id, notification_id — 명칭은 플랫폼에 따라 다릅니다)를 가진 두 요청이 밀리초 차이로 들어왔다면, 이는 하나의 이벤트가 재전송된 것입니다. 중복 제거를 찾으세요.
• 서로 다른 식별자를 가진 두 요청이라면, 채널에 실제로 두 개의 핸들러가 구독되어 있는 것입니다. 두 번째 구독을 찾으세요.

로그가 아예 없다면 플랫폼 패널부터 확인하세요. 거기서 채널 이벤트를 누가 구독하고 있는지 볼 수 있습니다.

패널에서 이중 구독이 나타나는 방식

플랫폼이 "봇이 두 번 연결됨"이라고 한 줄로 보여주지는 않습니다. 징후는 여러 섹션에 흩어져 있습니다.

Twitch

계정 설정의 Connections 섹션을 확인하세요. 연결된 애플리케이션 목록이 있습니다. 동일한 봇이 채널 애플리케이션으로도, 개인 계정 애플리케이션으로도 인증되어 있을 수 있습니다. 게다가 EventSub 구독은 별도로 존재합니다: 패널에서 연동을 해제한 후에도 애플리케이션이 channel.chat.message에 대한 활성 구독을 유지하고 있을 수 있습니다. 로컬에서 실행 중인 두 번째 봇 인스턴스도 정상 인스턴스와 똑같이 이벤트를 받습니다.

YouTube

여기서는 봇 자체보다 채팅 접근 권한이 더 자주 원인입니다: 봇이 방송에 모더레이터로도, 별도의 참여 계정으로도 연결되어 있는 경우입니다. 모더레이터 목록과 채널의 인증된 애플리케이션 목록을 확인하세요. 별도로 — 봇이 여러 Google Cloud 프로젝트를 통해 작동한다면 키가 두 개의 서로 다른 경로로 흐를 수 있습니다.

Discord

가장 명확한 경우: 하나의 서버에 동일한 토큰을 가진 두 개의 애플리케이션이 있는 경우입니다. 둘 다 채널의 메시지를 보고 둘 다 응답합니다. 서버의 봇 목록을 확인하고 같은 이름의 두 번째 웹훅이 채널에 연결되어 있지 않은지 확인하세요.

이 방법의 단점은 봇뿐만 아니라 채널 패널에도 접근 권한이 필요하다는 것입니다. 채널을 여러 사람이 운영한다면 다른 사람이 두 번째 인스턴스를 띄웠을 수 있고, 당신은 그것을 모를 수 있습니다.

웹훅 재전송: 이벤트가 두 번 오는 이유

외부 서비스가 웹훅을 전달하고 확인 응답을 기다립니다. 정해진 시간 안에 응답을 받지 못하면 다시 보냅니다. 두 번째 요청은 동일한 이벤트를 담고 있지만, 봇은 이를 새로운 것으로 인식하고 다시 응답합니다. 이는 서버가 잠시 멈출 때마다 발생합니다: 부하가 클수록 더 자주 발생합니다.

봇 측의 중복 제거로 해결됩니다. 하나의 이벤트에 대한 모든 사본에서 동일하고, 서로 다른 이벤트에서는 고유한 키가 필요합니다. 키는 요청 본문이나 헤더에서 가져옵니다 — API에 따라 다르지만 방식은 동일합니다.

중복 제거 키 예시

새로운 후원에 대한 웹훅을 상상해 보세요. 본문에는 id 필드를 가진 객체가 옵니다 — 재전송 시에도 변하지 않는 고유한 거래 번호입니다. 로직은 다음과 같습니다:

1. 요청을 받으면 본문에서 id를 추출합니다.
2. 저장소(Redis, 데이터베이스 테이블)에서 최근 예를 들어 하루 동안 이 값이 있었는지 확인합니다.
3. 있었다면 서비스에 "접수됨"이라고 응답하고 채팅에는 아무것도 보내지 않습니다.
4. 없었다면 기록하고 평소처럼 처리합니다.

키는 반드시 이벤트에서 가져온 것이어야 하며 직접 생성한 것이 아니어야 합니다: 직접 생성하면 하나의 이벤트에 대한 두 번의 전송이 서로 다른 키를 갖게 되어 중복 제거가 작동하지 않습니다. 일부 플랫폼은 전송 식별자가 담긴 헤더를 제공합니다 — 그렇다면 그것을 사용하세요, 더 안정적입니다. 이 접근법의 단점은 저장소와 정리 정책이 필요하다는 것입니다. 그렇지 않으면 키 데이터베이스가 끝없이 커집니다.

중복이 서로 다른 두 소스에서 온 경우

별개의 이야기로, 이벤트가 반복되는 것이 아니라 실제로 두 곳에서 오는 경우입니다. 전형적인 예: 봇이 채팅에서도, 브리지를 통한 플랫폼 간 전달에서도 명령에 응답하는 경우입니다. 또는 자동 응답이 동일한 문구에 반응하는 두 개의 트리거에 설정된 경우입니다.

이러한 중복은 로그상 웹훅 재전송과 다릅니다: 요청의 소스가 다르지만(다른 플랫폼, 다른 핸들러) 의미상 하나의 이벤트입니다. 트리거의 교차점을 찾아 그중 하나를 비활성화하세요. 브리지의 경우 — 봇 자신의 메시지를 다시 전달하지 마세요.

방송 전 점검

1. 테스트 명령을 보내고 응답이 몇 개 오는지 확인하세요.
2. 하나를 제외한 모든 연동을 비활성화하고 반복하세요.
3. 중복이 다시 나타날 때까지 하나씩 활성화하세요 — 이렇게 하면 원인을 찾을 수 있습니다.
4. 로그에서 두 응답의 이벤트 식별자를 대조하세요: 같으면 전송 반복, 다르면 두 번째 구독입니다.

원인을 찾을 수 없다면 문제가 되는 이벤트에 대한 자동 응답을 비활성화하고 로그와 반복 시간을 첨부하여 서비스 지원팀에 문의하세요. 기다리는 동안에는 채팅을 직접 운영하세요: 저녁 하나 자동화를 잃는 것이 방송을 똑같은 문구로 도배하는 것보다 낫습니다.