BurningTimesAi/공유/조직자산/시행착오_아카이브/개발_서버팀장_v1.md

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
시행착오_아카이브
서버팀장
PlayFab
보안Critical3건
어뷰징판정
클라서버경계
C2
C6-2
C11
C13
C29
C36
P13
P14
P18
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 감사 체크 항목에 "const AES 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 조직 차원)

  1. 안건 A — 서버 권위 경계 기본 정책 PD 사전 확정 요청: EerieVillage 착수 시점에 ① 어뷰징 판정 주체 ② 보상 형태 단일화 여부 ③ 세이브 SOT 기본값 ④ 리셋 시간 기준 4종을 설계 착수 전 PD 결정 안건으로 상정. 수잡에서 중반 번복 시 3개 문서 재작성 비용 실증을 근거로 제시.

  2. 안건 B — 보안 Critical 감사 자동화 도입: dev-auditor 모드 A 감사 체크리스트에 "암호화 키 하드코딩 검출"·"IAP 영수증 검증 호출 주석 감지"·"전투 연산 서버 경로 유무" 3항 추가. 서버 파트 코드 최초 commit 시 자동 발동.

  3. 안건 C — 서버 재개 체크리스트 조직 표준화: 수잡 서버팀장 점검보고(C 섹션)의 "재개 예비 4종" 및 본 아카이브 3-A~3-D를 조직 표준 서버 착수 체크리스트로 정식화 제안. 차기 프로젝트 신규 서버 인력 배정 시 1차 온보딩 자료로 사용.

  4. 안건 D — docx 원본 처리 방침: 공유/서버_작업_참고자료/2026-04-17_서버_작업_참고자료_v1.2.docx는 docx 접근 제약으로 본 아카이브 작성 시 미참조. PM 판단 요청: (가) anthropic-skills:docx로 텍스트 추출 후 본 아카이브 v2 보완 / (나) docx 자체를 조직자산 보존 대상으로 유지 / (다) 둘 다. 본 서버팀장 권장: (다).

  5. 안건 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