1. 요약 (Summary)

• 감시자 초대 → 수락 → 통지 → 반응 4단계를 구현한다.
• 설계 전체가 두 개의 절대 가드레일에서 나온다 — PENDING 상태에 발송 0건, 이의 기간 종료 전 발송 0건.
• 연락처는 스키마에 자리를 만들지 않는 방식으로 수집을 구조적으로 불가하게 한다.

2. 전제 및 현재 시스템

• 영향받는 모듈: 인증 — 실패 확정 이벤트 제공. 알림 — 통지·반응 발송. 챌린지 — 패널티 설정 항목. 마이페이지 — 조회 전용 화면.
• 현재 상태: 초대·수락·목록 API의 기존 구현이 있으나 2026-09-14 계약 정합화 반영이 필요하다. 정리본 밖 레거시의 웹 등록·SMS·인원 제한은 구현 근거로 사용하지 않는다.
• 외부 의존성: 카카오톡 공유 SDK — 클라이언트가 호출하며 서버는 토큰과 카드 메타만 내려준다.

3. 목표 / 목표가 아닌 것

Goals

• PENDING 발송 0건, 조기 발송 0건을 서버 검증으로 보장한다.
• 반응 1회 제한을 DB UNIQUE 제약으로 보장한다 — 서버 카운터로 풀지 않는다.
• 수락 증적은 관계 DB, 푸시 설정은 알림 설정 DB, 차단은 사용자 차단 DB에 각각 보관하고 실행 과정은 CloudWatch 구조화 로그로 감사한다.

Non-Goals

• 실패 판정 — 인증 모듈. 알림 발송 인프라 — 알림 모듈. 방 내부 실패 공유 — 방 내부 모듈. 관계 해제 — 정책상 폐지.

4. 계획 (Plan)

4-1. DB 스키마 상세

기준: MySQL 8.x / InnoDB · UUIDv7를 BINARY(16)으로 저장 · DATETIME(3)은 UTC