10. 우편 (Mail)

상위 문서: 게임기획코어.md 상태: 기획 확정(2026-09-22) · 서버 완료(운영 우편 T-081 · 넘침 보관 T-082) · 클라 화면 완료(T-083 · 2026-09-26) 바뀌면 갱신: 거래 · 게임UI · 게임기획코어 · 퀘스트

서버가 유저에게 보상을 맡겨 두는 곳. 운영자가 보내는 보상과, 인벤토리가 가득 차 받지 못한 보상이 여기에 쌓인다. 유저는 원할 때 열어서 받는다. 받지 않아도 사라지지 않는다 — 놓쳐도 손해가 없다(P3).

1. 확정 사항 (2026-09-22)

왜 안 받은 우편을 만료시키지 않나 — 만료가 있으면 우편함이 "오늘까지"를 세는 물건이 된다. P3의 금지 목록(미사용분 이월·"오늘까지" 표시)과 같은 이유다. 대신 받은 우편만 7일 뒤 지워 DB가 끝없이 커지지 않게 한다.

왜 우편함에 상한을 두나 — 상한이 없으면 인벤토리가 가득 찬 채로 상자를 계속 열 수 있다. 그러면 우편함이 두 번째 인벤토리가 되어 인벤토리 한도(200칸)가 의미를 잃는다.

2. 설계

2.1 우편 한 통의 상태

[안 받음] ──수령──> [받음] ──7일 경과 또는 유저 삭제──> (삭제)

• 되돌아가는 전이는 없다. 안 받음 → 삭제로 가는 길도 없다(1장 8·12번).

2.2 전체 우편

전체 우편은 한 곳에 한 줄로 저장하고, 받을 자격이 생긴 유저의 개인 우편함으로 복사한다.

• 한 유저가 같은 전체 우편을 두 번 받지 않는다 — 복사 기록이 곧 중복 방지다.

2.3 수령

• "들어간다"의 판정은 인벤토리 칸 계산(T-063)을 그대로 쓴다. 이미 가진 자원은 칸을 더 먹지 않는다.
• 골드는 칸을 먹지 않는다.

2.4 넘침 보관

서버가 보상을 준다 (상자 개봉 · 퀘스트 보상)
    ├─ 인벤토리에 전부 들어간다 → 바로 지급 (지금과 같다)
    └─ 안 들어간다
          ├─ 안 받은 우편 < 100통 → 보상 전체를 우편 1통으로 (넘침 템플릿)
          └─ 안 받은 우편 = 100통 → 원래대로 거절 (상자 개봉 거부 등)

• 보상을 쪼개지 않는다. 들어가는 것만 인벤토리에 넣고 나머지만 우편으로 보내지 않는다 — 보상 1건 = 우편 1통(1장 14번).
• 넘침 우편의 제목·본문은 넘침 전용 템플릿 한 줄을 쓰고, 첨부만 그때그때 채운다.
• 서버 구현(2026-09-22): 상자 개봉만 이 흐름을 탄다. 응답 S_ItemUseResponse.StoredInMail = true면 보상이 우편으로 갔다는 뜻이다. 퀘스트 보상은 지급 코드가 생길 때 같은 순서(HasStorageFor → HasMailboxRoom → StoreOverflowMail)를 탄다.
• ⚠️ 자원 칸 200은 실제로 차지 않는다 — 아이템이 176종뿐이다. 지금 넘침은 장비 칸이 찬 상태에서 상자가 장비를 줄 때 일어난다.

3. 데이터 설계

3.1 엑셀 — Mail.xlsx / MailTemplateTable (2026-09-22)

우편 한 통 = 한 줄. 첨부도 같은 줄에 담는다(시트 하나 — 여러 시트를 오가지 않고 한 줄로 읽는다).

• 넘침 보관용 템플릿(TID 2)은 첨부를 비워 둔 한 줄이다. 서버가 첨부를 채운다(T-082).
• 배열 컬럼에도 Ref가 걸려 있어 없는 TID는 파이프라인이 잡는다.

3.2 상수

3.3 DB

• 첨부를 보낸 순간 복사하므로 템플릿을 나중에 고쳐도 이미 보낸 우편은 그대로다.

4. 서버 / 클라 책임

새 우편 점은 게임 UI 2.4의 "버튼에 배지 금지"의 예외다. 숫자·타이머·기한이 없는 점 하나이고, 기다리는 것이 사라지지 않는 보상이라 "지금 누르지 않으면 손해"를 만들지 않는다.

5. 결정 필요

• 없음. 엑셀 이름(3장)은 엑셀 작업 때 확정받는다.

구현 일감: T-081(서버 — 운영 우편) · T-082(서버 — 넘침 보관) · T-083(클라 — 우편함 화면)