Value Proposition¶

Umbra 는 길드 관리자에게 "사고가 나기 전에는 능동적 보호를, 사고가 난 후에는 완전한 복구를" 약속합니다. 이 약속은 세 개의 기둥 — Protect, Preserve, Restore — 으로 구현됩니다.

Why this matters¶

Discord 길드 운영자가 가장 두려워하는 순간은 서버가 "nuke" 당한 아침입니다. 역할이 전부 사라지고, 채널이 삭제되고, 멤버가 밴당한 상태를 마주하면, Discord 자체는 아무것도 해주지 못합니다. 관리자 계정 탈취든, 내부자의 악의든, 봇 오작동이든 사고의 원인은 다양하지만 결과는 같습니다. 몇 달 또는 몇 년에 걸쳐 만든 커뮤니티 구조가 순식간에 사라집니다.

기존 백업 봇은 대부분 "가끔 JSON 덤프를 만들어둠" 수준입니다. 복구는 수동이며, 이상 감지는 없고, 사고 발생 후의 UX 는 고려되지 않습니다. Umbra 는 이 공백을 체계적으로 메꿉니다.

Three pillars¶

Protect¶

사고가 나기 전에 막는다.

Umbra 는 길드의 모든 변경 이벤트를 실시간으로 감시합니다. 대량 역할 삭제, 대량 채널 삭제, 비정상적 권한 승격, 대규모 멤버 추방 같은 패턴이 감지되면 즉시 다음을 수행합니다.

• 사고 직전 상태를 강제 스냅샷으로 보존
• Discord Audit Log 를 분석하여 가해자 식별
• 길드 owner 에게 긴급 DM 발송
• (Enterprise) 가해자의 권한 자동 박탈

이 동작은 전적으로 서버 측에서 이루어지며, 공격자가 우리 봇을 제거한다 해도 이미 감지 및 대응 워크플로우가 시작된 이후입니다.

Preserve¶

상태를 잃지 않는다.

Umbra 는 길드에서 일어나는 모든 구조적 변경을 우리 DB 에 실시간 미러링합니다. 멤버가 가입하거나 탈퇴할 때, 역할이 생성되거나 수정될 때, 채널 권한이 변경될 때마다 이벤트가 수집되고 배치로 DB 에 반영됩니다.

이 실시간 미러링 위에 두 가지 보존 메커니즘이 있습니다.

• Scheduled snapshots — 플랜에 따라 매일 또는 매주 자동 스냅샷
• Manual snapshots — 관리자가 중요한 변경 직전 명시적으로 생성

스냅샷은 PostgreSQL JSONB 컬럼에 저장되며 트랜잭션 경계 안에서 생성됩니다. 부분 저장된 스냅샷이 존재할 수 없고, 저장 실패는 스냅샷이 아예 없는 것과 동일하게 처리됩니다.

Restore¶

완전하게 되돌린다.

복구는 Temporal 워크플로우로 실행됩니다. 수십 초에서 수 분이 걸리는 작업이며, 프로세스가 죽거나 네트워크가 끊겨도 다른 워커가 이어서 진행합니다. 중간에 Discord API rate limit 에 걸리면 자동 백오프 후 재시도합니다. 사용자는 대시보드에서 실시간 진행 상황을 확인할 수 있습니다.

복구 모드는 "Sync" 로 동작합니다. 스냅샷에 없는 현재 요소는 삭제되고, 있는 것은 생성 또는 업데이트됩니다. 이는 Git reset 과 같은 시점 복구이며, 관리자는 복구 실행 전 무엇이 추가되고 삭제되고 변경되는지 미리보기로 확인한 뒤 진행합니다.

복구 범위는 카테고리별 선택 가능합니다. Roles 만, Channels 만, 또는 전체 Full Restore 를 지원하며, 의존성(Permission Override 는 Roles 와 Channels 를 요구)은 자동으로 강제됩니다.

What makes Umbra different¶

기존 Discord 봇 생태계와 Umbra 를 구분하는 결정적 차이점입니다.

Proactive, not reactive¶

다른 백업 봇은 관리자가 "백업해줘" 명령을 내릴 때 동작합니다. Umbra 는 명령을 받지 않아도 동작합니다. Anti-Nuke 는 사고가 시작되는 순간 자동으로 발동하며, Scheduled Snapshot 은 관리자가 잊고 있어도 꾸준히 보존합니다.

Designed for failure¶

복구 자체가 실패할 수 있다는 전제로 설계되었습니다. Temporal 의 워크플로우 재시작, Discord API 의 rate limit 백오프, 부분 실패 시의 재개 지점 관리가 모두 내장되어 있습니다. 대형 길드의 복구도 완주합니다.

Hybrid billing¶

한 사람이 여러 길드를 운영하는 것은 흔한 패턴입니다. Umbra 는 결제 주체(User)와 적용 대상(Guild)을 분리하여 이 패턴을 자연스럽게 지원합니다. 빌링키 하나로 여러 길드의 구독을 관리하고, 각 길드마다 Plan 을 독립적으로 선택할 수 있습니다.

Transparent restore¶

복구는 "Git reset" 의 의미를 가지며, 실행 전 diff 미리보기를 제공합니다. 관리자는 무엇이 추가되고 삭제되고 변경되는지 명확히 알고 결정을 내립니다. 되돌릴 수 없는 작업이므로 UX 는 보수적입니다.

What Umbra does not promise¶

가치 제안을 정확하게 전달하기 위해 하지 않는 것도 명시합니다.

• 메시지 본문 복구는 하지 않습니다 — 프라이버시, 법적 부담, 용량 문제로 의도적 제외. 대신 모든 결제 SaaS 중 가장 프라이버시 친화적인 설계입니다.
• Discord 자체 장애의 우회 수단이 아닙니다 — Discord API 가 다운되면 우리도 복구를 진행할 수 없습니다.
• 봇이 길드에서 강퇴되면 그 시점 이후의 보호는 불가능합니다 — Anti-Nuke 도 봇이 있어야 동작합니다. 공격자가 먼저 봇을 강퇴하는 시나리오에 대해서는 Enterprise 플랜에서 추가 안전장치(다중 계정 관리자 알림, 복수 봇 분산)를 검토 중입니다.

Pricing tier alignment¶

각 가치 기둥이 플랜과 어떻게 매핑되는지입니다.

구체적 플랜 정의와 Feature 매핑은 domain/licensing.md 를 참조하세요.

Related docs¶

• overview/what-is-umbra.md — 프로젝트 정체성
• overview/glossary.md — 용어 사전
• domain/licensing.md — Plan 과 Feature 매핑
• domain/recovery/overview.md — Recovery 도메인 상세
• roadmap/mvp-scope.md — MVP 포함 범위