ADR-0026: Anti-Nuke MVP Inclusion¶
Umbra 의 Anti-Nuke 기능은 MVP 범위에 포함한다. Phase 2 로 미루지 않는다. 다만 첫 릴리즈는 Plan 별 제한된 수준(Pro=감지+알림, Enterprise=+자동 대응)으로 시작한다.
Status¶
Accepted
- Decided at — 2026-04-13
- Decided by — Pablo
Context¶
Umbra 의 가치 제안(value-proposition.md)은 Protect / Preserve / Restore 세 기둥이다.
- Preserve (스냅샷) — MVP 에 당연히 포함
- Restore (복구) — MVP 의 핵심 기능
- Protect (Anti-Nuke) — MVP 포함 여부 결정 필요
Anti-Nuke 를 Phase 2 로 미루는 안의 근거:
- 구현 복잡도 (rolling window 이벤트 집계, Temporal workflow, 알림 발송)
- MVP 출시 시간 단축
Anti-Nuke 를 MVP 에 포함하는 안의 근거:
- 제품 정체성 — "nuke 당하기 전에 막아주는 봇" 이 마케팅 차별화의 핵심
- Restore 만으로는 부족 — 이미 사고 난 뒤 복구 vs 사고 방지, 후자가 더 가치 큼
- 경쟁사 차별화 — 단순 백업 봇과 명확히 구분
- 사용자 심리 — "복구할 수 있어" 보다 "지켜준다" 가 Pro 구독 동기 더 강함
Decision¶
Anti-Nuke 를 MVP 범위에 포함 한다.
단, 첫 릴리즈의 기능은 Plan 별로 차등:
Free Plan — Anti-Nuke 없음¶
감사 로그와 웹 조인만 제공. Anti-Nuke 는 유료 기능.
Pro Plan — 감지 + 알림¶
- 비정상 이벤트 패턴 감지 (rolling window 기반)
- 감지 시 자동 스냅샷 생성 (현재 상태 보존)
- 길드 owner 에게 Discord DM 알림 + 감사 채널 알림
- 가해자 추정 정보 제공 (Discord Audit Log 기반)
- 자동 대응 없음 — 관리자가 수동으로 판단
Enterprise Plan — 감지 + 알림 + 자동 대응¶
Pro 기능 전체 + 추가로:
- 가해자 권한 자동 박탈 — 감지된 사용자의 모든 역할 자동 제거
- 길드 잠금 — 모든 채널 SEND_MESSAGES 권한 임시 박탈 (옵션)
- 복수 관리자 알림 — owner 가 응답하지 않으면 등록된 sub-admin 에도 알림
감지 패턴 (MVP)¶
- Mass role deletion — 5분 내 5개 이상 역할 삭제
- Mass channel deletion — 5분 내 3개 이상 채널 삭제
- Mass kick/ban — 5분 내 10명 이상 멤버 추방
- Permission escalation — 기존 멤버가 Administrator 권한 획득
임계값은 플랜/길드별 조정 가능 (Enterprise 는 튜닝 지원).
선택 근거:
- 제품 정체성 확보 — "Anti-Nuke 기능 있음" 이 Phase 1 마케팅 핵심 카피
- Pro 티어 가치 제공 — "Pro = 알림까지, Enterprise = 자동 대응" 명확한 차등
- Temporal 워크플로우 인프라 활용 — Restore 에 이미 Temporal 을 쓰므로 AntiNuke 도 같은 인프라 재활용
- 제한된 범위 — 감지 패턴 4개로 제한하여 MVP 복잡도 관리
Consequences¶
Positive¶
- MVP 출시 시 완성된 가치 제안 표현 가능
- Pro/Enterprise 플랜의 가치 차별화 명확
- Restore 가 필요해지는 상황을 사전에 감지 하여 고객 만족도 ↑
- Temporal 인프라 두 번째 사용처 확보 (단일 용도 인프라 부담 해소)
Negative¶
- MVP 개발 범위 ↑ (AntiNuke workflow 와 패턴 감지 로직 추가)
- 오탐(false positive) 위험 — 정상 운영을 이상으로 오인
- 자동 대응(Enterprise)의 부작용 — 자동 박탈이 잘못되면 사용자 신뢰 타격
Neutral¶
- 감지 패턴은 데이터 축적 후 튜닝 가능
- Enterprise 자동 대응은 opt-in (플랜 구독만으로 자동 활성화하지 않음)
Implementation notes¶
AntiNuke workflow (Temporal)¶
길드별로 장기 실행 workflow.
AntiNukeWorkflow(guild_id):
loop:
await event signal (mass_delete, mass_kick, permission_escalation, etc.)
push event to rolling window
if threshold_exceeded(window):
trigger snapshot activity
trigger notification activity (owner DM)
if plan.enterprise && auto_response_enabled:
revoke_perpetrator_roles activity
if active restore exists:
signal restore workflow (추가 조치 전달)
check shutdown signal
- Rolling window 는 Temporal workflow 변수로 관리
- 감지 시 Snapshot trigger 는 ADR-0025 의 자동 스냅샷 생성 경로 재사용
Event source¶
Discord Gateway 이벤트가 Bot 프로세스에서 수신되면 Temporal signal 로 AntiNuke workflow 에 전달. Bot 은 이벤트 raw 데이터를 Temporal 에 보내고, workflow 가 집계/판정.
False positive mitigation¶
- 길드 관리자에게 알림 먼저 보내고 자동 대응은 Enterprise 에서 opt-in
- 감지 이력은
recovery.antinuke_incidents에 기록 → 사용자가 "이건 정상" 피드백 가능 - 임계값은 길드별 커스터마이즈 가능 (Enterprise 는 수치 직접 조정)
Alternatives considered¶
Alternative 1: Phase 2 로 연기¶
Pros
- MVP 범위 축소, 출시 시간 단축
Cons
- 제품 가치 제안 중 하나가 빠짐
- 경쟁사 차별화 약화
- Pro 플랜의 부족한 가치 → 유료 전환율 낮음
Why rejected — 제품 정체성의 결정적 부분이라 지연 비용이 큼.
Alternative 2: MVP 에 감지만, 알림/대응 없음¶
Pros
- 범위 더 제한적
Cons
- 감지해도 사용자가 모르면 가치 없음
- 차별화 이점 소멸
Why rejected — 알림 없이 감지는 의미 없음.
Alternative 3: Free Plan 에도 Anti-Nuke 제공¶
Pros
- 사용자 유입 ↑
Cons
- 유료 전환 인센티브 약화
- Temporal 인프라 비용 부담 (Free 사용자도 workflow 실행)
Why rejected — Pro 플랜의 차별화 가치 보존이 필요.
Alternative 4: Discord Audit Log Webhook 만으로 감지 (workflow 없이)¶
Pros
- 구현 단순
Cons
- rolling window 집계를 애플리케이션 자체 구현 → Temporal 이점 포기
- 복잡도는 다른 곳으로 이전
Why rejected — Temporal 인프라가 이미 있어 재활용이 자연스러움.
Compliance¶
- AntiNuke 구현은
engine/recovery/subdomain/antinuke/에 위치 - Plan 별 기능 gating 은 Licensing 도메인 권한 체크 경유
- 감지 이벤트는
recovery.antinuke_incidents에 기록 (Audit 와 별개, 내부 분석 용도) - 자동 대응(Enterprise) 실행 전 로그 남김 + 사용자 알림
- 임계값은 코드 하드코딩 아닌 설정 테이블 또는 플랜 메타데이터로 관리
Revisit triggers¶
- 오탐률이 높아 사용자 불만이 반복되면 감지 알고리즘 개선 (ML 기반 이상 탐지 등)
- 감지 패턴이 4개로 부족하면 추가 (예: Spam message, webhook hijack)
- 자동 대응 사고가 발생하면 Enterprise 자동 대응 정책 재평가