T-063 서버 — 창고 칸 한도(자원·캐릭터·장비 각 200) · 칸이 모자라면 뽑기 거부

배경

클라 창고는 탭마다 칸 프레임 200개를 쓴다. 넘치면 뒤쪽이 잘리고 경고 로그만 남는다 (StorageGridPresenter — "칸 프레임이 N개인데 표시할 것이 M개다").

서버에는 한도가 전혀 없다 (2026-09-17 확인).

캐릭터: GachaService.Draw → User.GrantGachaCharacters가 개수 검사 없이 개체를 늘린다
자원: GainItem이 TID마다 한 줄씩 늘린다 — 종류 수 검사 없음
장비: 시스템은 섰다(T-002 ✅ 2026-09-17 · 뽑기는 T-067 ✅ 2026-09-19) — 한도 검사만 없다

그래서 200칸이 차도 캐릭터 뽑기가 통과하고, 넘친 캐릭터는 화면에서 보이지 않는 채로 보유된다.

할 일

[x] 칸 계산 규칙 확정 — 자원 = 보유 수량 > 0인 아이템 종류 수 / 캐릭터 = 개체 수 / 장비 = 개체 수
[x] 한도 값의 위치 결정 — 지금은 서버 상수 User.StorageCapacity = 200. T-077이 서면 시트로 옮긴다 (2026-09-22)
[x] EResultCode.StorageFull = 103 — 뽑기·상자 개봉 공용
[x] GachaService.Draw 순서 조정 — 추첨(순수) → 칸 검사 → 비용 차감 → 지급. 지금은 차감이 추첨보다 앞이라, 검사를 넣으려면 추첨을 앞으로 당긴다. 거절 시 재화·보유는 그대로
[x] 칸 검사는 이번 결과가 새로 차지할 칸만 센다 — 이미 보유한 자원 TID는 칸을 더 쓰지 않는다
[x] 장비 뽑기가 생기면 같은 검사를 쓰도록 검사를 한곳에 둔다 — User.HasStorageFor(User.Storage.cs). 상자 개봉도 같은 검사를 탄다(전부 열면 상자 칸이 비는 것까지 본다). 캐릭터는 DB 대기분(_pendingCharacterCount)도 센다 (T-002에 메모) — 장비 뽑기가 생겼다(T-067 · 2026-09-19). GachaService.Draw 장비 분기도 검사 대상이다
[x] 뽑기 외 획득 경로 방침 결정 → 이번 범위에서 정하지 않고 T-084로 넘겼다. (막을지·버릴지·넘치게 둘지) — 채집 정산(User.WorkStation → GainItem), 치트 GiveItem·GiveCharacter. 특히 채집은 방치 중 거절할 수 없어서 따로 정해야 한다. 이번 범위에서 정하지 못하면 새 일감으로 등록
[x] 테스트 (server-tdd) — StorageLimitTest 8건 — 199칸 + 10연차 거절 · 이미 보유한 TID만 나오면 통과 · 거절 시 재화 불변
[x] 프로토콜 미러 커밋 (EResultCode 변경) — d8ac663에 함께 담았다

완료 조건

캐릭터 200명을 보유한 계정이 캐릭터 뽑기를 보내면 StorageFull(가칭)로 거절되고 골드·보유가 변하지 않는다. 자원 뽑기도 새로 차지할 종류 수가 남은 칸보다 많으면 같은 코드로 거절된다. 테스트가 이를 확인하고, 미러가 커밋돼 있다.

막고 있는 것 / 선행 일감

없음. 장비 부분만 T-002가 생긴 뒤 적용한다. 끝나면 T-064가 열린다

참고

GachaService.cs
PacketEnum.cs — 결과 코드 대역

배경

할 일

완료 조건

막고 있는 것 / 선행 일감

관련 커밋

참고