Slack의 Event Subscriptions는 안정적인 HTTPS 엔드포인트, 검증 가능한 서명, 빠른 JSON 응답을 요구합니다. OpenClaw 게이트웨이를 작은 Linux VPS에 두면 장애의 대부분은 「Slack 장애」가 아니라 TLS 프런트, Slack 앱 설정과 리버스 프록시 사이의 경로 불일치, 또는 서명 시크릿을 보기도 전에 403을 돌려주는 인증 레이어입니다. 설치·바인드 주소·TLS까지 재현 가능한 레이아웃은 2026 OpenClaw Linux 클라우드 VPS 실전: curl 설치 vs Docker 비교, 환경 검증과 자주 보는 오류 FAQ에서 정리한 것과 같이 맞춘 뒤, 토큰과 콜백 URL은 2026 OpenClaw Telegram·Discord 듀얼 채널 실무: 봇 설정, 페어링·허용, 권한 매트릭스와 다채널 충돌 FAQ에서 다른 채널과 동일한 방식으로 정렬해 페어링과 허용 목록을 지루할 정도로 단순하게 유지하세요.
Slack이 전선에서 기대하는 것
Slack 앱을 만들거나 재사용하고 Event Subscriptions를 켠 다음, VPS 호스트명의 443으로 이어지는 Request URL을 붙입니다. Slack은 먼저 url_verification 단계에서 챌린지를 던지므로, 스택은 몇 초 안에 챌린지 JSON을 반환해야 하고 본문을 두 번 버퍼링하면 안 됩니다. 검증 후에는 X-Slack-Signature와 X-Slack-Request-Timestamp가 붙은 봉투가 옵니다. Signing Secret은 SecretRef나 게이트웨이 사용자만 읽을 수 있는 잠긴 파일에 두고, Git이나 world-readable한 /etc 드롭인에는 넣지 마세요. 봇 토큰(xoxb-)은 답장 게시 등 Web API 호출에 쓰이므로, 실제로 쓰는 채널과 메서드에만 스코프를 좁혀 유출 시 워크스페이스 전체로 퍼지지 않게 하세요.
콜백 URL → TLS 엣지 → 루프백 게이트웨이
OpenClaw 설정에 적힌 포트로 게이트웨이를 127.0.0.1에 바인드하고, TLS는 Nginx나 Caddy에서 종료한 뒤 일반 POST와 필요 시 WebSocket 업그레이드를 함께 전달합니다. Slack에 넣은 공개 경로(예: /slack/events)는 TLS를 종료하는 location과 반드시 일치해야 합니다. 후행 슬래시 불일치나 이중 접두사(/openclaw/slack/slack/events)만으로도 프록시는 403을 내고 루프백에 대한 curl은 여전히 「녹색」으로 보일 수 있습니다. 엣지에서의 업스트림 상태 코드와 게이트웨이 프로세스 로그를 분리해 기록해, Node 워커가 돌기 전에 엣지가 끊었는지 구분하세요.
curl -sS -D- \
-H 'Content-Type: application/json' \
-d '{"type":"url_verification","challenge":"ping"}' \
https://claw.example.com/slack/events
슬래시 커맨드·단축키·대화형 URL
Event Subscriptions는 수신 경로 중 하나일 뿐입니다. 슬래시 커맨드, 메시지 단축키, Block Kit 대화형은 각각 Slack 앱 설정에 별도 Request URL을 선언하며, 모두 동일한 TLS 엣지와 경로 규율로 도달해야 합니다. 이벤트만 OpenClaw로 보내고 대화형은 옛 터널 호스트를 가리키면 DM은 오는데 버튼은 무반응인 「분할 뇌」 설정이 흔한 이전 후 함정입니다. 모든 콜백을 같은 인증서와 로깅 파이프라인에 두면 403 추적을 한 번의 저널 쿼리로 재사용할 수 있습니다.
재현 가능한 구성 체크리스트(Linux VPS)
Ubuntu LTS 또는 Debian 12를 준비하고, 프로덕션에서 고정한 패키지 채널로 OpenClaw를 설치한 뒤 UTF-8 셸과 전용 UNIX 사용자로 온보딩을 한 번 실행합니다. 관리 IP에서만 22/tcp, ACME와 Slack 콜백을 위해 세계에 80/443, 게이트웨이 포트는 0.0.0.0/0에 열지 마세요. openclaw gateway status로 루프백 리스너를 확인한 뒤 인증서를 발급하고 프록시를 리로드한 다음에야 Slack의 Event Subscriptions 토글을 켭니다. Signing Secret을 바꾸기 전에 ~/.openclaw와 워크스페이스를 스냅샷해 두면 롤백은 「tar 복원 후 unit 리로드」로 끝나고 발굴 작업이 되지 않습니다.
X-Slack-Signature를 지워 버리는 경우가 있습니다.
계층형 403, 재전송, 중복 전달 FAQ
디버깅할 때는 스택을 위에서부터 순서대로 내려가세요. 각 계층은 액세스 로그와 애플리케이션 로그에 다른 지문을 남깁니다.
| 계층 | 증상 | 먼저 볼 것 |
|---|---|---|
| 1 · 엣지 | Slack UI에서 URL 검증 실패; curl에 리다이렉트 루프나 인증서 오류 | ACME 갱신, SNI 호스트 일치, POST 제외 HTTP→HTTPS 리다이렉트, 프록시 버퍼 크기 |
| 2 · 경로·인증 | Slack 본문 없이 HTTP 401/403 | Basic 인증 잔재, IP 허용 목록, WAF 토큰 규칙, 누락된 proxy_set_header Host |
| 3 · 게이트웨이 토큰 | 검증 성공 후에만 안정적으로 403 | 게이트웨이 Bearer와 SecretRef 불일치, systemd의 오래된 환경, 잘못된 UNIX 사용자 홈 |
| 4 · 서명·재전송 | 배포 후나 일광절약 전후 무작위 403 | chrony/systemd-timesyncd, 서명 베이스 문자열과 raw 본문 비교, 오래된 타임스탬프 거부 |
Slack은 이벤트 전달을 재시도할 수 있으므로, 핸들러는 event_id(또는 결정적으로 유도한 중복 제거 키)에 대해 멱등하게 설계하세요. 부수 효과 전에 성공을 에코하면 재시도가 외부 API를 이중 청구할 수 있고, 작업을 먼저 끝내면 Slack HTTP 타임아웃을 넘겨 재시도가 나기도 합니다. ACK는 빠르게, 무거운 작업은 큐로 넘기고, 있을 때 X-Slack-Retry-Num 헤더를 로그에 남겨 운영자가 최초 전달과 재전송을 구분할 수 있게 하세요.
비밀 순환 후에는 unit으로 게이트웨이를 재시작하고 프로세스가 새 환경을 물려받았는지 확인한 뒤, Slack 개발자 UI에서 테스트 이벤트를 다시 보냅니다. 검증은 통과하는데 라이브 메시지가 멈추면 OAuth 스코프와 채널 멤버십을 다시 보세요. Event Subscriptions는 봇이 실제로 참여하고 적절한 세분화 스코프를 가진 워크스페이스에서만 발화합니다.
Slack on Linux은 단조롭게, 운영자 데스크는 빠른 Mac으로
게이트웨이와 Slack 콜백은 잠긴 작은 Linux 엣지에 두고, 사람은 서명 검증·로그 테일·브라우저와 터미널을 하루 종일 씁니다. 클라우드 Mac mini M4는 Safari 옆에 네이티브 Unix 셸을 두고, 긴 장애 대응에서 글꼴과 렌더링을 예측 가능하게 유지하며, SSH 세션 옆에서 로컬 캐시나 에디터를 돌릴 때 Apple Silicon 메모리 대역폭이 유리합니다. macOS는 Gatekeeper와 SIP로 일반 관리용 노트북보다 악성코드 위험을 낮추고, 유휴 전력 약 4W로 세션을 붙여 두기에도 부담이 적습니다.
공개 TLS와 OpenClaw는 Linux VPS에, 운영자 데스크는 macOS에 두는 분리는 총소유비용을 합리적으로 유지합니다. 팬 소음과 「내 노트북에선 된다」류의 변수를 줄이고, 자동화 옆에서 창작 업무를 같은 벤더 스택으로 이어갈 수 있습니다.
그 macOS 쪽을 물리 책상 하나에 묶지 않고 호스팅하고 싶다면 VPSSpark 클라우드 Mac mini M4가 실용적인 출발점입니다——지금 플랜 살펴보기로 팀 생산성은 유지한 채 Slack 연동만 지루하게 유지하세요.