데이터 주도 설계의 핵심은 데이터를 많이 두는 것이 아니라 경계를 잘 나누는 것이다
게임이나 서비스 개발에서 데이터 주도 설계라는 말을 들으면 흔히 모든 설정을 JSON이나 테이블로 빼는 그림부터 떠올린다. 물론 하드코딩을 줄이고 콘텐츠 수정 비용을 낮추는 데는 이런 접근이 큰 도움이 된다. 하지만 여기서 한 걸음 더 잘못 가면 데이터를 바꾸기 쉽게 하려다 코드 전체가 데이터 형식에 끌려다니는 문제가 생긴다.
핵심은 데이터를 많이 쓰는 것이 아니라, 데이터의 변경이 어디까지 퍼질 수 있는지를 통제하는 것이다. 마틴 파울러가 정리한 도메인 모델, 데이터 매퍼, 자기 캡슐화 같은 패턴도 결국 이 문제를 다룬다. 저장 형식과 핵심 로직이 서로를 직접 흔들지 않게 하려는 것이다.
데이터화 자체는 목표가 아니라 변경 비용을 줄이기 위한 수단이다
데이터를 외부로 빼면 기획자와 디자이너가 빌드 없이 값을 바꾸거나 실험하기 쉬워진다. 적의 체력, 아이템 드롭률, 대사, UI 문구처럼 자주 바뀌는 요소에는 분명 유리하다. 문제는 자주 바뀌는 값과 시스템의 개념을 구분하지 않을 때 생긴다.
예를 들어 몬스터의 수치 데이터와 전투 규칙은 성격이 다르다. 수치는 자주 바뀔 수 있지만, 전투 규칙은 시스템 전체의 의미를 건드린다. 이 둘을 같은 방식으로 다루면 데이터 파일 하나가 사실상 코드를 대신하는 상태가 된다.
가장 흔한 실패는 저장 형식이 도메인 모델을 지배하는 경우다
데이터 주도 설계가 무너지는 순간은 대개 게임 로직이 파일 구조나 직렬화 형식에 직접 기대기 시작할 때다. JSON 필드명이 바뀌면 게임 오브젝트 생성자까지 바뀌고, 테이블 열 하나가 추가되면 여러 시스템이 동시에 흔들리는 식이다.
이 문제를 줄이려면 최소한 세 층을 의식해야 한다.
- 저장 형식: JSON, CSV, DB 스키마처럼 바깥세계와 연결되는 구조
- 변환 계층: 저장 형식을 읽어 시스템이 이해하는 형태로 바꾸는 계층
- 도메인 모델: 실제 규칙과 상태 전이를 다루는 핵심 코드
저장 형식이 변해도 변환 계층에서 흡수하고, 도메인 모델은 가능한 한 안정적으로 남는 구조가 이상적이다.
번역 계층이 있어야 데이터가 바뀌어도 코어가 덜 흔들린다
파울러의 데이터 매퍼 패턴은 도메인 객체를 저장 구조와 직접 결합시키지 않으려는 접근이다. 게임 개발에서도 비슷한 원리가 통한다. 몬스터 데이터를 읽을 때 파일을 직접 파싱해 도메인 오브젝트가 모든 세부 형식을 아는 대신, 별도의 로더나 팩토리, 어댑터가 중간에서 번역하도록 두는 편이 안전하다.
이 구조의 장점은 세 가지다.
- 저장 형식이 바뀌어도 수정 범위를 줄일 수 있다
- 테스트에서 가짜 데이터나 축약된 입력을 쓰기 쉬워진다
- 핵심 로직이
무엇을 해야 하는가에 더 집중할 수 있다
반대로 이 계층이 없으면 나중에 데이터 한 줄 바꿨는데 왜 전투, UI, 저장, 툴이 다 깨지지 같은 일이 벌어진다.
데이터가 많아질수록 검증과 관측이 더 중요해진다
데이터 주도 설계의 또 다른 함정은 코드 리뷰는 해도 데이터 리뷰는 대충 하는 문화다. 하지만 실제 라이브 서비스에서는 오히려 데이터 실수가 더 자주 문제를 만든다. 드롭 테이블, 상점 가격, 스폰 주기, 이벤트 보상은 코드보다 더 자주 바뀌고, 그래서 더 자주 사고를 낸다.
그래서 데이터 중심 시스템에는 보통 이런 장치가 필요하다.
- 스키마 검증
- 기본값과 범위 체크
- 로딩 실패 시 에러 메시지와 진단 정보
- 변경 이력 추적
- 샌드박스 테스트나 검증용 툴
데이터를 외부로 뺐다면 이제 누가, 언제, 무엇을 바꿨고, 그 변화가 어디에 영향을 주는지도 함께 보여줄 수 있어야 한다.
마치며
데이터 주도 설계는 하드코딩을 없애는 운동이 아니다. 변화가 잦은 부분을 분리하되, 그 변화가 핵심 로직까지 무차별적으로 퍼지지 않게 하는 설계 방식이다. 결국 중요한 것은 데이터의 양이 아니라 경계의 질이다.
데이터를 늘리는 것보다 먼저 해야 할 일은 이것이다. 무엇이 자주 바뀌는 값이고, 무엇이 시스템의 개념인가. 이 선이 분명해질수록 데이터 주도 설계는 힘을 발휘하고, 그 선이 흐릴수록 시스템은 파일 형식에 끌려다니게 된다.