docs: record rb8001 slack signing secret recovery

journey/troubleshooting/260227_gateway_slack_events_signature_mismatch_and_500_mapping.md

@@ -88,6 +88,11 @@
 - `/gateway/slack/events` 실유입 기준으로 200/403 분포를 24시간 관찰
 - 재발 시 게이트웨이 원문 body 전달(`content=raw_body`) 경로와 nginx 로그를 시각 동기화해 재검증
 
+## 후속 복구
+
+- 2026-03-17 실제 재발은 게이트 본문 전달 문제가 아니라 24서버 `rb8001`의 `SLACK_SIGNING_SECRET` 오값과 compose 빈값 덮어쓰기 구조가 직접 원인이었습니다.
+- 상세 복구 기록: [rb8001 Slack Signing Secret 오값 복구 및 실유입 검증](../worklog/260317_rb8001_slack_signing_secret_오값복구_및_실유입검증.md)
+
 ## 관련 파일
 
 - `robeing-gateway/app/routers/slack.py`

journey/worklog/260317_rb8001_slack_signing_secret_오값복구_및_실유입검증.md

@@ -0,0 +1,49 @@
+---
+tags: [robeing, rb8001, slack, signing-secret, recovery, worklog]
+---
+
+# rb8001 Slack Signing Secret 오값 복구 및 실유입 검증
+
+**날짜**: 2026-03-17  
+**작성자**: Codex
+
+## 왜
+
+- 23서버 게이트를 거쳐 24서버 `rb8001`까지 Slack 이벤트가 도달했지만, `rb8001`에서 `Invalid Slack signature`가 반복되어 로빙이 응답하지 못했습니다.
+- 로그 기준 직접 증상은 `2026-03-17 22:23:41`, `22:23:42`, `22:24:43`, `22:37:30`, `22:37:31`, `22:37:36`, `22:37:37`의 `Invalid Slack signature`였습니다.
+
+## 무엇을 확인했는가
+
+1. 24서버 `rb8001` 실행 환경에서 `SLACK_SIGNING_SECRET`, `SLACK_BOT_TOKEN`, `SLACK_APP_TOKEN`, `JWT_SECRET_KEY`, `SERVICE_API_KEY`가 비어 있던 상태를 확인했습니다.
+2. `rb8001`의 `docker-compose.yml`이 `env_file` 값을 쓰는 동시에 `${...}` 셸 치환으로 같은 키를 다시 주입하고 있었고, 호스트 셸에 값이 없어서 빈 문자열로 덮어쓰고 있음을 확인했습니다.
+3. Slack 앱 `A092HLQA1NW`의 실제 `Signing Secret`은 `995cdf...af22`인데, 당시 `rb8001`에는 다른 값이 들어가 있음을 확인했습니다.
+4. 문서와 코드 기준 정상 경로는 `Slack -> 23서버 게이트(/gateway/slack/events) -> 24서버 rb8001(/api/slack/events)`이며, 이번 장애의 직접 원인은 게이트 이전이 아니라 24서버 런타임 시크릿 오값이었습니다.
+
+## 어떻게 복구했는가
+
+1. `/home/admin/workspace-config/secrets.env`에 누락된 Slack/JWT/API 키를 SSOT로 복구했습니다.
+2. `rb8001/docker-compose.yml`에서 `${SLACK_*}`, `${JWT_SECRET_KEY}` 등 셸 치환으로 SSOT 값을 덮어쓰던 항목을 제거해 `env_file`만 단일 출처로 사용하도록 정리했습니다.
+3. `SLACK_SIGNING_SECRET`를 실제 Slack 앱 값으로 교체했습니다.
+4. `rb8001` 컨테이너를 재생성했습니다.
+
+## 검증
+
+1. `rb8001` 컨테이너가 `healthy` 상태로 기동했습니다.
+2. 컨테이너 환경에 `SLACK_SIGNING_SECRET`, `SLACK_BOT_TOKEN`, `SLACK_APP_TOKEN`, `JWT_SECRET_KEY`, `SERVICE_API_KEY`가 정상 주입됨을 확인했습니다.
+3. 현재 `SLACK_SIGNING_SECRET`으로 서명한 `POST /api/slack/events` 테스트가 `200`과 challenge 응답을 반환했습니다.
+4. 실유입 로그에서 `2026-03-17 22:49:58` 시점 `POST /api/slack/events HTTP/1.1" 200 OK`, `Event: message from U09BQSN72UT: 로빙?`, `Scheduling async processing`가 기록되어 실제 Slack 이벤트가 서명 단계 통과 후 처리되기 시작했음을 확인했습니다.
+
+## 원인값
+
+- 24서버 `rb8001`의 `SLACK_SIGNING_SECRET`가 운영 Slack 앱의 실제 값과 달랐습니다.
+- 동시에 `docker-compose.yml`의 `${...}` 셸 치환이 `env_file` 기반 SSOT를 빈 문자열로 덮어쓰는 구조여서, 복구 이후에도 재발 가능성이 있었습니다.
+
+## 재발 방지
+
+1. 운영 시크릿은 `/home/admin/workspace-config/secrets.env`만 SSOT로 사용합니다.
+2. `docker-compose.yml`에서 같은 키를 `${...}`로 다시 주입하지 않습니다.
+3. Slack 앱 시크릿 교체 시 `workspace-config/secrets.env`와 실행 컨테이너 환경을 함께 검증합니다.
+
+## 관련 문서
+
+- [Gateway Slack Events 서명 불일치 및 500 매핑 이슈 정리](../troubleshooting/260227_gateway_slack_events_signature_mismatch_and_500_mapping.md)