핵심 원칙
| 원칙 | 이유 |
|---|---|
| 기획데이터는 클라/서버 어느 쪽에도 종속시키지 않는다 | 한쪽에 종속되면 빌드 의존성이 생기고 순환 참조로 이어짐 |
| key는 불변 ID로 발급한다 | 파일 시스템 path는 언제든 바뀔 수 있음 |
| 클라/서버가 독립적으로 기획데이터를 가져다 쓴다 | 서로 간의 빌드 의존성 제거 |
언리얼 엔진에서의 문제 패턴
path를 key로 쓸 때
- 언리얼은 에셋 참조에 path 사용
- 파일 이동/이름 변경 시 redirector로 라우팅 → path가 변할 수 있는 값
- 서버는 DB key의 불변성을 요구하지만 클라/기획은 소극적이 됨
클라이언트가 원본일 때 발생하는 순환 참조
서버 빌드
→ 기획데이터 검증 필요
→ 클라 빌드에서 export 필요
→ 서버 패킷/enum 필요
→ 기획데이터 필요 ← 순환
enum 발급 순서 혼란
- 정상 흐름: 서버가 공유 enum 발급 → 클라·기획데이터가 사용
- 클라가 원본이면: 클라 빌드 전에 서버 enum 생성이 불가능 → 선후관계 불분명
스키마 export 방식 (임시 해결책)
클라/서버 종속을 완전히 피하지 못하는 상황에서의 차선책:
- 클라에서 기획데이터 전체가 아닌 스키마만 export
- 서버: 스키마로 검증기 빌드 + 패킷/enum 생성
- 클라: 서버 결과물 받아 최신 빌드
- 기획데이터 export → 서버 검증기로 검사
순환은 깨지지만 빌드 파이프라인 자동화가 전제조건.
enum 발급 주체
| enum 종류 | 발급 주체 | 이유 |
|---|---|---|
| 기획표에 직접 등장하는 값 (몬스터 종류, 아이템 등급, 스킬 타입 등) | 기획데이터 | 기획자가 값 추가·수정 시 서버/클라 코드 불필요 |
| 서버·클라 공유지만 기획데이터와 무관한 값 (패킷 타입, 에러 코드 등) | 서버 | 클라가 임의로 값을 추가해 서버와 불일치가 생기는 상황 방지 |
| 한쪽만 사용하는 값 (클라 내부 렌더링 상태, 서버 내부 처리 단계 등) | 각자 | 공유 레이어를 거칠 이유 없음 |
이 구분이 무너지면 순환 의존 발생 — 발급 주체가 잘못 정해진 것이 원인.
관련
- 블로그: design-data-in-engine 원문 글