메시징 자동화에서 가장 쓸모 있는 순간은 "이 메시지가 오면 저것을 해라"가 성립할 때입니다. 특정 방에 새 글이 올라오면 나에게 알림을 보내거나, 어떤 키워드가 등장하면 로컬 스크립트를 돌리는 식입니다. 문제는 이걸 잘못 엮으면 순식간에 폭주하는 자동화가 된다는 점입니다. 이벤트가 몰릴 때 후속 동작도 같이 몰리면 상대 서버에 부담을 주고 계정도 위험해집니다. 이 글은 감시에서 후속 처리로 이어지는 파이프라인을, 폭주를 막는 장치와 함께 어떻게 설계했는지 정리합니다.
watch: 방을 지켜보는 계층
파이프라인의 출발점은 watch입니다. 실시간 연결을 유지하며 서버가 밀어 주는 이벤트를 받아 새 메시지를 구조화된 형태로 흘려보냅니다. --json과 함께 쓰면 각 이벤트가 기계가 읽는 형식으로 나오기 때문에, 이후 단계에서 다루기가 쉽습니다.
watch 자체는 읽기에 가까운 감시 동작이지만 여기에 후속 동작을 붙이는 순간 성격이 달라집니다. 그래서 감시에 부수 효과를 붙이는 것은 명시적으로 허용해야만 동작하도록 막아 뒀습니다. 그냥 지켜보기만 할 때와 지켜보다 무언가를 실행할 때를 구분해 후자를 켤 때 사용자가 의식하게 만들었습니다.
필터: 무엇에 반응할지 좁히기
모든 이벤트에 반응하면 후속 동작이 감당할 수 없이 많아집니다. 그래서 필터가 파이프라인의 핵심입니다. 특정 방으로 한정하거나, 지정한 키워드가 들어간 메시지만 고르거나, 메시지 타입으로 걸러 낼 수 있습니다. 이 세 가지 조건을 조합하면 "이 방에서 이 키워드가 나올 때만"처럼 반응 지점을 정밀하게 좁힐 수 있습니다.
필터를 앞단에 두는 것은 성능만의 문제가 아닙니다. 반응 조건이 좁을수록 후속 동작이 실행되는 빈도가 낮아지고 그만큼 폭주 위험도 줄어듭니다. 무엇에 반응할지 명확히 정의하는 일이 곧 안전장치이기도 한 셈입니다.
hook: 로컬에서 명령을 실행하기
필터를 통과한 이벤트로 로컬 명령을 실행하는 것이 hook입니다. 예를 들어 들어온 이벤트를 파일로 저장하거나, 다른 스크립트에 넘겨 후속 처리를 하게 할 수 있습니다. 이벤트가 표준입력으로 흘러 들어오니 평소 쓰던 커맨드라인 도구들과 그대로 엮입니다.
hook에는 최소 실행 간격과 실행 시간 제한이 걸립니다. 이벤트가 몰려도 명령이 최소 간격보다 자주 실행되지 않고 한 번의 실행이 너무 오래 붙들고 있으면 제한 시간에 끊깁니다. 자동화가 스스로를 갉아먹지 않게 하는 장치들입니다.
webhook: 외부로 알림 보내기
이벤트를 외부 서비스로 보내고 싶을 때는 webhook을 씁니다. 지정한 주소로 이벤트를 실어 보내는데, 형식을 raw뿐 아니라 슬랙과 디스코드에 맞춘 형태로 고를 수 있어 그대로 알림 채널에 꽂힙니다. 헤더를 덧붙이거나 서명 검증을 붙여 받는 쪽이 이 요청이 진짜인지 확인하게 할 수도 있습니다.
webhook에도 hook과 마찬가지로 최소 전송 간격과 요청 시간 제한이 있습니다. 특히 외부로 나가는 요청이라 보안에도 신경 썼습니다. 기본적으로 안전한 연결만 허용하고 보호되지 않은 주소로 보내는 것은 명시적으로 열어야만 가능합니다. 알림 하나를 보내더라도 기본값이 안전한 쪽에 서 있게 했습니다.
폭주를 막는 것이 설계의 절반
이 파이프라인에서 기능만큼 공들인 부분이 속도 제한입니다. 감시는 실시간이라 이벤트가 순간적으로 몰릴 수 있고 그때 hook과 webhook이 제한 없이 따라 튀면 그대로 사고가 됩니다. 그래서 각 후속 단계에 최소 간격과 시간 제한을 두고 감시에 부수 효과를 붙이는 것 자체를 명시적 허용으로 잠갔습니다.
정리하면 이 파이프라인은 감시, 필터, 후속 처리의 세 층이 각각 안전장치를 갖춘 구조입니다. 무엇에 반응할지 좁히고 얼마나 자주 반응할지 제한하고 부수 효과는 켜야만 동작하게 했습니다. 이 흐름이 딛고 선 실시간 연결 계층은 LOCO 프로토콜 리버스 엔지니어링에서, 이벤트를 다루는 JSON 인터페이스는 사람과 에이전트가 함께 쓰는 JSON CLI에서 이어집니다. 전체 도구의 안전 우선 설계는 카카오톡 자동화 CLI 오픈소스 사례에 정리돼 있습니다.
자주 묻는 질문
hook과 webhook은 어떻게 다른가요?
hook은 이벤트로 로컬에서 명령을 실행하는 것이고 webhook은 지정한 주소로 이벤트를 실어 외부 서비스에 보내는 것입니다. hook은 평소 쓰던 커맨드라인 도구와 엮어 후속 처리를 하고 webhook은 슬랙이나 디스코드 같은 알림 채널로 이벤트를 흘려보낼 때 씁니다. 둘 다 필터를 통과한 이벤트에만 반응합니다.
이벤트가 몰리면 자동화가 폭주하지 않나요?
그걸 막는 것이 설계의 절반입니다. 필터로 무엇에 반응할지 좁히고 hook과 webhook 각각에 최소 실행 간격과 시간 제한을 둬서 이벤트가 몰려도 후속 동작이 정해진 속도 이상으로 튀지 않게 했습니다. 감시에 부수 효과를 붙이는 것 자체도 명시적으로 허용해야만 동작합니다.
webhook으로 외부에 보낼 때 보안은 어떻게 챙기나요?
기본적으로 안전한 연결만 허용하고 보호되지 않은 주소로 보내는 것은 명시적으로 열어야만 가능합니다. 요청에 서명을 붙여 받는 쪽이 이 알림이 진짜인지 검증하게 할 수도 있고 전송 간격과 요청 시간 제한도 걸려 있습니다. 알림 하나를 보내더라도 기본값이 안전한 쪽에 서 있도록 설계했습니다.