12 KiB
| from | origin_project | archive_date | archive_scope | status | version | tags | related_rules | note | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 개발_서버팀장 (BurningTimes 조직 이관) | 수상한잡화점 (NerdNavis, 2026-04-14 ~ 2026-04-17) | 2026-04-21 | 서버 파트 시행착오 추출 (조직 자산 보존) | 완료 | v1 |
|
|
docx 원본(`2026-04-17_서버_작업_참고자료_v1.2.docx`)은 접근 제약으로 미포함. 필요 시 PM이 anthropic-skills:docx로 재추출. |
서버 파트 시행착오 아카이브 — 개발_서버팀장 관점 v1
1. 개요
수상한잡화점 프로젝트(NerdNavis, ~2026-04-17)의 서버 파트는 정식 가동 이전에 일시 보류된 상태로 종결되었다. PlayFab 기반 백엔드가 구조적으로 존재했으나 ① Critical 보안 3건(전투 연산 클라 권한·AES 키 하드코딩·IAP 영수증 검증 미구현)이 실제 서비스 오픈 전 블로커로 확인되었고, ② 인간 서버 개발자 미배정 상태에서 서버 파트 정비를 보류하고 클라이언트 우선 개발로 방향 확정되었다. 본 아카이브는 BurningTimes 신설 조직(EerieVillage 프로젝트 및 차기 프로젝트)이 서버 아키텍처 초기 설계 단계에서 동일 시행착오를 재발하지 않도록 핵심 교훈을 추출한다.
특히 **"어뷰징 판정 책임 주체"**의 결정이 PD님 직접 지시로 2회 번복된 사건(서버 경계값 검증 → 클라 100% 책임)은 서버/클라 경계 설계가 기술 결정이 아니라 운영 정책 결정임을 실증한 사례로 보존한다.
2. 핵심 시행착오 · 교훈 표
| # | 영역 | 시행착오 내용 | 발견 경위 | 교훈·재발 방지 |
|---|---|---|---|---|
| S1 | 전투 연산 권한 | 데미지·HP·Shield·Buff 계산 전 로직이 Actor.cs/PCActor.cs/MobActor.cs 기반 100% 클라 연산. 서버는 결과만 수신 |
05_서버연동_현황_v1.md C11 보안 점검 (2026-04-14) |
초기 아키텍처 단계에 "서버 권위 영역" 명시 후 클라 구현 착수. 코어 프레임워크 INetworkService 추상화와 함께 차기 프로젝트 기본 탑재 |
| S2 | 암호화 키 관리 | CryptoUtil.cs에 AES Key 32byte · IV 16byte 평문 하드코딩. IL2CPP 빌드도 메모리 덤프로 추출 가능 |
05 보안 점검 (2026-04-14) | 런타임 유도 키 (디바이스ID 해시 혼합) + 서버 페이로드 HMAC 서명. 키 하드코딩은 어떤 난독화로도 정당화 불가 |
| S3 | IAP 영수증 검증 | InappInfo.cs의 PlayFab ValidateGooglePlayPurchase 호출이 전체 주석 처리된 상태로 릴리스 경로 진입 직전. 클라 단독 성공 판단 후 재화 지급 구조 |
05 보안 점검 (2026-04-14) | 결제 로직은 블로커급 우선순위. "나중에 붙인다" 승인 금지. 프로토타입 단계라도 검증 API 호출 뼈대는 유지 |
| S4 | 서버 인력 공백 상태에서 설계 확정 | 인간 서버 개발자 미배정 상태에서 개발팀장이 단독으로 서버 역할·API·경계 매트릭스 초안 작성. 환경 제약으로 Task(subagent_type='서버팀장') 호출 불가 상황에서 양쪽 관점 분리 표기로 대응 |
2026-04-17_RPT_서버역할_정리_초안.md C23 정직성 주석 |
초기 설계는 채용·배정 전에도 착수 가능하되, 원칙·경계·안건까지. 세부 API 스펙은 배정된 개발자의 기술 스택 선호 반영 후 확정 (재작업 리스크 회피) |
| S5 | 어뷰징 판정 책임 번복 | 기획팀 v1 기획서는 서버가 "시뮬 경계값 + 안전마진" 기반 F1/F2/F3 플래그 판정 주체. 개발팀장 v1.0 업무지시서도 이 구조 반영. 그러나 PD님 재확정으로 "어뷰징 판정 = 클라 100% 책임, 서버는 is_abuse_flag 플래그만 수신·지급 거부"로 변경. 업무지시서 v1.1 재작성 (446줄 → 요약판) |
2026-04-17 PD 지시 재확정 (업무지시서 v1.1 섹션 5) | 서버/클라 경계는 기술 최적이 아닌 운영 부담 최적 기준. 기획 설계 시점에 "이 로직을 어느 팀이 유지보수하는가"를 PD와 선합의. PM은 경계 설계 결정은 C36 적용 — 방향 수준이므로 PM 재량 금지 |
| S6 | 일일 리셋 시간 기준 | 일일 미션·상점 리셋이 클라 DayOfYear 비교 — 기기 시간 조작으로 어뷰즈 가능. 보류 상태로 릴리스 경로 진입 |
05 + 서버 역할 정리 초안 PD-⑤ | 서버 시간 기준 리셋은 보안 기본값. PD 재검토 불요 수준. 차기 프로젝트 코어 프레임워크 기본 탑재 |
| S7 | 세이브 SOT 하이브리드의 보안 영향 | "로컬 1차 + 클라우드 보조" 하이브리드 구조가 오프라인 플레이 편의는 있으나 재화·진행도·별 수까지 로컬 SOT로 저장되어 조작 경로 다수 존재. PD-④에서 "차기는 서버 1차 SOT" 방향 확정 | 서버 역할 정리 초안 A-4 | 서버 1차 SOT + 로컬 오프라인 캐시 구조를 차기 프로젝트 기본값으로 설계. 오프라인 플레이는 예외 경로 |
| S8 | ACTk 적용 범위 협소 | ObscuredInt/ObscuredLong 필드 약 10개만 적용. SpeedHackDetector·TimeCheckDetector 비활성화. 로컬 변조 1차 방어선 조차 제한 |
05 보안 점검 | ACTk는 서버 검증 대체재가 아님. 재화·레벨·카드 보유 수량 전면 적용 + Detector 활성화 기본화 |
| S9 | DevOps 자동화 hook 공백 | scripts/post_tool_validate.sh·session_end_sync.sh 미존재. 서버 config·코드 수정 후 syntax 오류가 다음 턴까지 검출되지 않는 리스크. 서버팀장 점검보고(업무공유체계_점검_서버팀.md A-2)에서 최초 제기 후 미해결 |
서버팀장 자체 점검 (2026-04-17) | 서버 재개 전에 PostToolUse·SessionEnd hook 신설. 배포·DB 마이그레이션·인시던트·API 변경 기록 채널(공유/운영기록/) 사전 설계 |
| S10 | Firebase 반쪽 도입 | Firebase 초기화 코드 파편만 존재, google-services.json 부재 → Analytics·Crashlytics 양쪽 모두 미동작. 실효성 0이나 리소스·로드 비용만 존재 |
05 현황 점검 | "깔려만 있고 작동 안 하는 모듈"은 보안·운영 양쪽에서 가짜 안전 느낌을 유발. 도입은 완전 가동까지 책임자 배정 후에만 |
3. 신규 프로젝트(EerieVillage·차기) 적용 체크리스트
3-A. 서버 아키텍처 초기 설계 단계 (구현 착수 전)
- 서버 권위 영역 명시 문서 작성 — "서버가 최종 판정하는 영역"·"클라가 계산하고 서버는 저장만"·"클라 단독 처리" 3분류로 모든 게임 액션 매핑 (P18 설계 문서화 의무)
- 보상 형태 단일화 원칙 확정 — 수잡 PD 가이드 "모든 보상 = 재화"의 정합성 재확인. 비재화 보상 허용 시 지급 주체 정책 사전 확정
- 어뷰징 판정 책임 주체 PD 사전 결정 — 서버 주도 / 클라 100% / 하이브리드 중 택1. 결정 번복 시 기획·서버·클라 3개 문서 동시 재작성 비용 선고지
- 일일/주간 리셋 시간 기준 = 서버 시간 기본값 고정. 클라 시간 기반 로직 금지
- 세이브 SOT 기본값 = 서버 1차 확정. 오프라인 캐시는 예외 경로로만 허용
3-B. 보안 기본선 (Critical 3종 재발 방지)
- 전투·데미지 연산 핵심부에 서버 재연산 또는 서명 검증 경로 설계 단계에서 삽입
- 암호화 키 하드코딩 코드 리뷰 차단 — dev-auditor 감사 체크 항목에 "
constAES Key/IV 문자열 검출" 추가 검토 - IAP 영수증 검증은 MVP 범위에 필수 포함 — 결제 시스템이 "나중" 대상이 되지 않도록 초기 백로그에 고정
- ACTk
SpeedHackDetector·TimeCheckDetector활성화 기본 템플릿 제공
3-C. 인력·협업 체계
- 인간 서버 개발자 배정 전에도 원칙·경계·안건까지는 팀장 단독 작성 가능 (S4). 세부 API 스펙은 배정 후 공동 확정
- Agent 호출 환경 제약 시 "단독 분석 + 관점 분리 표기" 방식 사용 (C23 정직성 준수,
2026-04-17_RPT_서버역할_정리_초안.md작성 주석 참조) - 서버 인력 합류 시 선행 Read 패키지 표준화 — 본 아카이브 + 프로젝트 서버 설계 문서 + 관련 feedback 메모리 묶음
- 서버/클라 경계 변경은 C36 적용 — PD 명시 승인 후에만 변경. PM 재량 금지
3-D. 운영 기록 채널 (서버팀장 점검보고 B-1 미집행분)
공유/운영기록/하위배포/·DB_마이그레이션/·인시던트/·API_변경/4종 디렉토리 신설- 인시던트 기록 템플릿 정의 (탐지·영향·타임라인·조치·근본원인 C2·재발방지)
- API Breaking Change 영향 분석 체크리스트 (P13 구체화)
- PostToolUse·SessionEnd hook 신설 (PM·전 팀장 합의 후)
4. PM 보고 안건 (BurningTimes 조직 차원)
-
안건 A — 서버 권위 경계 기본 정책 PD 사전 확정 요청: EerieVillage 착수 시점에 ① 어뷰징 판정 주체 ② 보상 형태 단일화 여부 ③ 세이브 SOT 기본값 ④ 리셋 시간 기준 4종을 설계 착수 전 PD 결정 안건으로 상정. 수잡에서 중반 번복 시 3개 문서 재작성 비용 실증을 근거로 제시.
-
안건 B — 보안 Critical 감사 자동화 도입: dev-auditor 모드 A 감사 체크리스트에 "암호화 키 하드코딩 검출"·"IAP 영수증 검증 호출 주석 감지"·"전투 연산 서버 경로 유무" 3항 추가. 서버 파트 코드 최초 commit 시 자동 발동.
-
안건 C — 서버 재개 체크리스트 조직 표준화: 수잡 서버팀장 점검보고(C 섹션)의 "재개 예비 4종" 및 본 아카이브 3-A~3-D를 조직 표준 서버 착수 체크리스트로 정식화 제안. 차기 프로젝트 신규 서버 인력 배정 시 1차 온보딩 자료로 사용.
-
안건 D — docx 원본 처리 방침:
공유/서버_작업_참고자료/2026-04-17_서버_작업_참고자료_v1.2.docx는 docx 접근 제약으로 본 아카이브 작성 시 미참조. PM 판단 요청: (가)anthropic-skills:docx로 텍스트 추출 후 본 아카이브 v2 보완 / (나) docx 자체를 조직자산 보존 대상으로 유지 / (다) 둘 다. 본 서버팀장 권장: (다). -
안건 E — EerieVillage 서버 스택 선정 시점: 수잡 PD-③("PlayFab 유지 vs 하이브리드 vs 자체 서버")은 인간 개발자 배정 후 기술 선호 수렴을 근거로 보류되었음. EerieVillage도 동일 구조로 갈 것인지, 아니면 서버 스택 사전 확정 후 인력 탐색인지 PD 방침 확인 필요.
5. 참조 원본 (읽기 전용, 원본 위치 보존)
프로젝트/수상한잡화점/개발/05_서버연동_현황_v1.md(Critical 3건 + C11 판정 + 우선순위 제안)공유/서버_작업_참고자료/2026-04-17_서버_작업_참고자료_v1.2.docx(docx — 본 아카이브 미참조, 안건 D 참조)공유/소통/완료/2026-04-17_서버개발자_업무지시서_최종본.md(v1.1 요약판, 어뷰징 클라 100% 책임 반영 최종본)공유/소통/완료/2026-04-17_RPT_서버역할_정리_초안.md(서버 역할·경계 매트릭스·PD 안건 5종)공유/소통/완료/2026-04-17_어뷰징판정_솔루션_기획서_v1.md(기각된 서버 경계값 판정 구조 원안 + 기각안 5종)공유/소통/완료/2026-04-17_업무공유체계_점검_서버팀.md(서버팀장 자체 점검보고, 재해복구·hook 공백 포함)공유/PD_지시_트래킹/개발팀_PD_지시_로그.md#2 (서버 Critical 3건 보류 상태)
서명: 개발_서버팀장 (BurningTimes 조직 이관 담당) 아카이브 목적: 헌법 제1원칙 ② (경험 축적·계승·발전) 준수 — 수상한잡화점 서버 파트 시행착오가 EerieVillage 및 차기 프로젝트에서 재발하지 않도록 조직 자산화 검증 권장: PM 교차 검토 + dev-auditor 모드 A 1회 + 차기 프로젝트 서버 인력 배정 시 온보딩 필수 Read