[로블록스]#17 - 데이터 중심 설계

[로블록스]#17 - 데이터 중심 설계

게임을 만들다 보면 반드시 이런 순간이 온다.
“아이템 하나만 더 추가하면 되는데…”
그런데 코드가 너무 얽혀 있어서 손을 대기 무섭다.
이 문제의 정답은 거의 항상 하나다.
데이터 중심 설계(Data-Driven)를 하지 않았기 때문이다.

---

 

 

 

1. 하드코딩은 왜 반드시 터질까?

초반에는 하드코딩이 빠르다.

• 아이템 가격 직접 입력
• 보상 수치 코드에 작성
• 조건 분기 if / else 남발

하지만 게임이 커지는 순간, 이 선택은 기술 부채가 된다.

하드코딩은
“지금은 편하지만, 나중에 반드시 값을 치른다.”

 

 

 

---

2. Data-Driven이란 무엇인가?

데이터 중심 설계란 간단히 말해,

코드는 “어떻게 할지”만 알고,
“무엇을 할지”는 데이터가 결정한다.

즉, 코드와 데이터를 의도적으로 분리하는 설계다.

 

 

 

---

3. Unity 경험자가 가장 먼저 체감하는 변화

Data-Driven 설계를 하면 개발 체감이 이렇게 바뀐다.

• 새 아이템 추가 → 코드 수정 없음
• 밸런스 조정 → 수치만 변경
• 이벤트 추가 → 데이터 한 줄 추가

이때부터 개발자는 “만드는 사람”에서 설계하는 사람으로 바뀐다.

 

 

 

---

4. 로블록스에서 Data-Driven이 특히 중요한 이유

• 라이브 업데이트 빈번
• 이벤트성 콘텐츠 많음
• 밸런스 수정이 잦음
• 운영 중 데이터 마이그레이션 발생

로블록스 게임은 “완성 → 출시”가 아니라
“출시 → 계속 수정”이다.

 

 

---

5. 데이터로 분리해야 할 대표 항목

• 아이템 정보 (가격, 효과)
• 보상 테이블
• 스테이지 / 웨이브 구성
• 쿨타임 / 제한 조건
• UI 문구

“바뀔 가능성이 있는 것”은 전부 데이터 후보군이다.

 

 

 

---

6. 나쁜 예 vs 좋은 예 (사고 방식)

▣ 나쁜 사고

• if item == "Sword" then 공격력 10
• if level == 5 then 보상 지급

▣  좋은 사고

• 아이템 테이블에서 공격력 조회
• 레벨별 보상 테이블 참조

조건을 늘리는 게 아니라, 데이터를 늘리는 구조다.

 

 

 

---

7. 서버 데이터 구조의 기본 형태

GameConfig
 ├─ Items
 ├─ Rewards
 ├─ Stages
 └─ Settings
    

서버는 이 구조를 기준으로만 판단한다.

클라이언트는 “요청”만 보낸다.

 

 

 

---

8. Data-Driven이 보안을 강화하는 이유

놀랍게도 데이터 중심 설계는 보안까지 강화한다.

• 클라이언트 입력은 ID만 전달
• 실제 수치는 서버 데이터 기준
• 변조 가능한 값 최소화

즉, 핵이 개입할 여지가 줄어든다.

 

 

 

---

9. 개발자가 가장 많이 하는 실수

• “이건 안 바뀔 것 같아서” 하드코딩
• 데이터 구조를 나중에 정리하려는 생각
• 초반 속도를 이유로 설계를 생략

Data-Driven은 늦을수록 도입 비용이 커진다.

 

 

 

---

10. 데이터 중심 설계 핵심 요약

• 코드는 로직만 담당
• 값과 규칙은 데이터로
• 확장은 데이터 추가로
• 밸런스는 코드 수정 없이
• 라이브 운영 필수 기본기

 

 

 

---

11. 다음 글 예고

다음 글에서는 시스템 분리 & Service 구조를 다룬다.

“Script 하나에 모든 걸 넣지 마라”

---