메신저 봇의 사고는 서버 장애보다 무섭습니다. 서버가 죽으면 기능이 멈추지만 봇이 오작동하면 실제 사람들의 대화방에 잘못된 메시지가 발송됩니다. 지울 수도 없고 받은 사람의 기억에서 되돌릴 수도 없습니다. 해외 매장의 왓츠앱 봇을 두 달 넘게 무인 운영하며 우리가 기능보다 공들인 것이 안전장치였습니다. 그 목록을 정리합니다.
1. 발송은 기본 차단: provider-safe 게이트
가장 중요한 장치부터. 봇의 외부 발송 경로(메시지 전송, 파일 전송)는 기본값이 차단입니다. 명시적으로 허용을 켜기 전까지 발송 요청은 거부되고 개발·테스트 중의 어떤 실수도 실제 방에 도달하지 못합니다.
이 게이트의 가치는 배포 순간에 드러납니다. 새 기능을 올릴 때 수신·처리 경로를 실데이터로 검증하면서도 발송만 잠가 둘 수 있어 "받고 처리하는 것"과 "내보내는 것"의 위험을 분리해 단계적으로 열 수 있습니다. 번역 자동 답장도 검증이 끝난 특정 방(화이트리스트)에만 열었습니다. 전체 방에 일괄 적용이 아니라 방 단위 개통이 원칙입니다.
2. 모르는 방에서는 아무것도 하지 않는다: fail-closed
봇은 초대되거나 동기화 과정에서 예상 밖의 방을 만납니다. 이때의 기본 동작이 안전의 갈림길입니다. 우리 라우팅은 등록되지 않은 방, 역할이 해석되지 않는 설정을 전부 "무동작"으로 처리합니다. 설정 실수의 결과가 침묵이 되도록.
반대 기본값(모르면 일단 번역이라도)은 편리해 보이지만 봇이 엉뚱한 방에서 갑자기 말을 시작하는 사고가 됩니다. 고객 채팅방에서 그 사고는 신뢰의 문제가 됩니다.
3. 의존성이 없어도 죽지 않는다: 모의 폴백
봇은 외부 의존성 위에 서 있습니다. LLM API, 시트, 드라이브. 이 중 하나가 죽거나 키가 비어 있을 때 전체가 멈추면 안 됩니다. 우리는 외부 호출마다 표식이 붙은 모의 응답 폴백을 두어 의존성이 빠져도 파이프라인의 흐름 자체는 돌게 했습니다. 모의 응답에는 명확한 표식이 붙어 실데이터와 절대 섞이지 않습니다.
이 폴백은 장애 대응이면서 개발 안전장치이기도 합니다. 키 없는 환경에서 전체 흐름을 리허설할 수 있으므로, 실제 키를 꽂는 순간이 첫 테스트가 되는 위험을 없앱니다.
4. 설정은 원자적으로, 쓰는 자는 하나만
봇의 동작을 결정하는 설정(방 라우팅, 사전)은 주기 동기화로 갱신되는데, 갱신 중간 상태를 실시간 경로가 읽으면 반쯤 쓰인 설정으로 동작하는 사고가 납니다. 우리는 설정 파일을 임시 파일에 쓴 뒤 원자적 교체(rename)로 반영하고 설정을 쓰는 주체를 동기화 워크플로 하나로 제한했습니다(single writer). 읽기는 언제나 완전한 버전을 봅니다.
5. 세션은 끊긴다는 전제: 자가 복구와 잠금 정리
웹 세션 방식의 봇에게 세션 단절은 일상입니다. 재연결 루틴, 브라우저 프로세스의 잔류 잠금 파일 정리, 그리고 세션이 정말 죽었을 때 운영자가 브라우저에서 QR로 다시 연결하는 절차까지 갖춰야 "며칠 방치해도 살아 있는" 봇이 됩니다. 자기 메시지를 자기가 처리하는 루프 방지 가드도 세션 계층의 필수 항목인데, 이 이야기는 메신저 실시간 번역 봇에서 다뤘습니다.
| 안전장치 | 기본값 | 막는 사고 |
|---|---|---|
| 발송 게이트 | 차단 (화이트리스트 개통) | 테스트 메시지의 실방 유출 |
| 라우팅 | fail-closed (미등록 = 무동작) | 엉뚱한 방에서의 오작동 |
| 외부 의존 | 표식 있는 모의 폴백 | 의존성 장애의 전면 정지 |
| 설정 갱신 | 원자적 교체 + 단일 기록자 | 반쯤 쓰인 설정으로 동작 |
| 세션 | 자가 복구 + 재연결 절차 | 조용한 수신 중단 |
봇 안전장치는 견적 항목이다
이 목록의 공통점은 기능 명세서에 안 적힌다는 것입니다. "번역 봇 만들어 주세요"라는 요구에 발송 게이트나 원자적 설정 갱신은 등장하지 않습니다. 하지만 실제 고객 방에서 무인으로 도는 봇의 개발 공수는 절반 이상이 이런 안전장치입니다. 봇 외주를 검토한다면 "오작동하면 어떻게 되나요"를 견적 단계에서 물어보세요. 그 답의 구체성이 업체의 실운영 경험을 드러냅니다. 무인 시스템 안전장치의 일반론은 무인 자동화 안전장치 설계에서, 이 장치들이 실제로 도는 시스템은 왓츠앱 번역 자동화 사례에서 볼 수 있습니다.
자주 묻는 질문
메신저 봇 안전장치 중 가장 먼저 갖출 것은 무엇인가요?
발송 기본 차단 게이트입니다. 봇 사고의 최악 형태는 실제 사람들의 방에 잘못된 메시지가 나가는 것이고 이는 되돌릴 수 없습니다. 발송 경로를 기본 차단으로 두고 검증된 방부터 화이트리스트로 여는 구조가 그 사고를 원천 차단합니다.
봇이 새로운 방에 초대되면 어떻게 동작해야 하나요?
아무것도 하지 않아야 합니다(fail-closed). 등록되지 않은 방은 무동작이 기본값이고 운영자가 설정에서 역할을 명시적으로 켰을 때만 동작을 시작해야 엉뚱한 방에서의 오작동이 구조적으로 불가능해집니다.
외부 API 장애가 나면 봇 전체가 멈추나요?
폴백 설계에 달렸습니다. 외부 호출마다 표식이 붙은 모의 응답 폴백을 두면 의존성 장애가 해당 기능의 품질 저하로 한정되고 파이프라인은 계속 돕니다. 표식 덕에 모의 응답이 실데이터로 오인되는 일도 없습니다.
안전장치 때문에 개발 비용이 너무 커지지 않나요?
실제 고객 방에서 무인으로 도는 봇이라면 안전장치는 선택이 아니라 원가입니다. 안전장치 없는 봇은 결국 사람이 지켜보게 되거나 사고 후 신뢰 비용을 치릅니다. 견적에서 이 항목이 빠져 있다면 싼 것이 아니라 덜 만든 것입니다.