게임 속 아이템, 몬스터, 스킬, 퀘스트의 수치와 정보는 대부분 데이터 테이블에 들어 있습니다. 프로그래머가 만든 시스템이 '틀'이라면, 데이터 테이블은 그 틀을 채우는 '내용'입니다. 테이블 설계가 엉성하면 콘텐츠가 늘어날수록 오류와 수정 비용이 커집니다. 데이터 테이블을 처음 설계할 때 알아야 할 원칙을 정리합니다.

데이터 테이블이 하는 일

데이터 테이블은 게임이 읽어 들이는 표 형식의 데이터입니다. 기획자가 엑셀 등에서 작성하면, 개발팀이 만든 변환 도구를 거쳐 게임이 읽을 수 있는 형태로 바뀝니다. 이 구조 덕분에 기획자는 코드를 고치지 않고도 새 아이템을 추가하거나 몬스터 체력을 조정할 수 있습니다.

데이터 테이블의 구조를 정의한 것을 스키마라고 합니다. 어떤 열이 있고, 각 열에 어떤 종류의 값(정수, 소수, 문자, 참·거짓)이 들어가는지, 비어 있어도 되는지를 정한 규칙입니다. 스키마는 개발자와 함께 정해야 하며, 한 번 정하면 함부로 바꾸지 않습니다.

ID 설계가 첫 단추

모든 행은 다른 행과 겹치지 않는 고유 ID를 가져야 합니다. 이름은 번역되거나 바뀔 수 있지만 ID는 게임 내부에서 그 대상을 가리키는 유일한 이름이기 때문입니다.

• 자릿수로 분류를 표현하는 방식이 흔합니다. 예를 들어 앞자리로 종류(무기, 방어구, 소비)를, 다음 자리로 등급을 나타내면 ID만 보고도 대략의 성격을 알 수 있습니다.
• 번호 사이에 여유를 둡니다. 1001, 1002처럼 촘촘하게 붙이면 나중에 중간에 항목을 넣기 어렵습니다.
• 한 번 쓴 ID는 삭제된 뒤에도 다른 대상에 다시 쓰지 않습니다. 이미 그 ID를 가진 아이템을 보유한 플레이어 데이터와 충돌할 수 있습니다.

열 설계 원칙

표시 문자열을 분리해 두면 다국어 출시 때 번역 파일만 바꾸면 되고, 문구 수정이 데이터 오류로 번지지 않습니다.

테이블 간 관계 설계

하나의 테이블에 모든 정보를 넣으면 열이 끝없이 늘어납니다. 그래서 성격이 다른 정보는 테이블을 나누고 ID로 연결합니다. 몬스터 테이블에는 드롭 그룹 ID만 두고, 드롭 테이블에서 그 그룹에 어떤 아이템이 어떤 확률로 나오는지 정의하는 식입니다.

1. 몬스터 테이블: 몬스터 ID, 이름 키, 레벨, 체력, 공격력, 드롭 그룹 ID
2. 드롭 테이블: 드롭 그룹 ID, 아이템 ID, 확률, 최소·최대 수량 (한 그룹에 여러 행)
3. 아이템 테이블: 아이템 ID, 이름 키, 종류, 등급, 능력치, 판매 가격

이렇게 나누면 여러 몬스터가 같은 드롭 그룹을 공유할 수 있고, 드롭 아이템을 바꿀 때 드롭 테이블만 수정하면 됩니다. 대신 연결된 ID가 실제로 존재하는지 항상 확인해야 합니다. 없는 ID를 참조하면 게임에서 오류가 납니다.

검증으로 사고 막기

• ID 중복 검사: COUNTIF로 같은 ID가 두 번 이상 나오는지 확인합니다.
• 참조 무결성 검사: 다른 테이블의 ID를 참조하는 열은 그 ID가 실제로 있는지 조회 함수로 확인합니다.
• 범위 검사: 확률은 0~100% 사이인지, 레벨은 최대 레벨을 넘지 않는지 조건부 서식으로 표시합니다.
• 합계 검사: 드롭 그룹별 확률 합계가 의도한 값인지 확인합니다.

검증 열을 테이블 옆에 두고 문제가 있으면 빨간색이 뜨게 만들어 두면, 데이터를 넘기기 전 마지막 점검이 몇 분이면 끝납니다. SBS아카데미게임학원 시스템기획 과정은 엑셀 데이터 구조화, 스키마 구성, 테이블 간 관계 설계를 실습하며 아이템·몬스터·스킬 데이터를 직접 설계하는 단계를 포함합니다.

자주 묻는 질문