[게임 기획 실무] AI 프롬프트로 스킬 시스템 엑셀(DB) 테이블 설계하는 방법
어제 올린 글에서 "이력서에 단순 AI 툴 사용 가능이라고 쓰지 말고, 기획을 검증한 과정을 증명하라"라고 강조했습니다. 그러자 게시글 보셨던 지인(지망생) 분이 묻습니다. "대체 그 게임 기획 AI 프롬프트를 실무에서 어떻게 쓴다는 겁니까?"
오늘은 10년 차 이상 중소기업 시스템 파트장인 제가 실제로 AI를 협업 툴이자 시뮬레이터로 쥐어짜는 방식을 가감 없이 공개하겠습니다.
단언컨대, 저는 AI에게 "스킬 시스템 DB 구조를 만들어줘"라고 명령하고 그것을 복사해서 붙여넣는 1차원적인 접근은 절대 하지 않습니다.
1. 신입 기획자의 함정: AI에게 완성된 '기획서'를 한 번에 요구하지 마십시오
스킬 시스템 기획서를 쓴다고 가정해 봅니다.
신입이나 지망생분들이 가장 많이 하는 실수는 챗GPT를 켜자마자 이렇게 입력하는 것입니다.
"MMORPG WOW 스타일의 스킬 시스템 기획서를 작성해 줘!"
이렇게 나온 텍스트는 겉보기엔 그럴싸합니다.
하지만 이건 여러분의 프로젝트 엔진이나 서버 아키텍처에는 1도 맞지 않는 '실무에서 작동하지 않는 껍데기'에 불과합니다.
기획은 소설을 쓰는 게 아닙니다.
기획자는 데이터(Data)가 클라이언트와 서버 사이에서 어떻게 굴러가는지 통제해야 합니다.
이를 고민하지 않은 결과물은 현업 개발자들에게 반려 대상 1순위가 됩니다.
👉핵심 요약: AI에게 완성된 기획서를 통째로 요구하지 마십시오. 데이터 통제력이 결여된 기획서는 실무 포트폴리오로 사용할 수 없습니다.
2. 게임 DB 테이블 설계의 본질: 데이터의 방향성과 규칙 정립
AI에게 키보드를 두드리기 전에, 기획자 본인의 머릿속에서 먼저 '이 시스템이 우리 게임에서 어떻게 굴러갈 것인가'에 대한 확고한 뼈대가 정립되어야 합니다.
한 번 찍으면 고정되는 '트리(Tree)형' 스킬을 만들 것인가?
유저가 룬이나 보석을 박아 속성을 마음대로 개조할 수 있는 '자유 조합형' 스킬인가?
기획자가 "어떤 구조를 만들겠다"는 명확한 목적지가 있어야, AI가 엉뚱한 대답을 할 때 궤도를 수정할 수 있습니다.
중간 연차(3~5년 차) 기획자들이 단순 오퍼레이터를 넘어 '아키텍트(설계자)'로 레벨 업 하려면 이 방향성 설정 능력이 필수입니다.
3. 실전 게임 기획 AI 프롬프트: 다중 페르소나 롤플레잉
방향성이 정해졌다면, 이제 AI를 프로그래머들과의 '가상 회의실'로 끌고 올 차례입니다.
기획자가 엑셀 테이블을 짤 때 가장 많이 놓치는 것이 "개발자가 이 데이터를 어떻게 파싱(Parsing)하여 사용할 것인가?"입니다.
저는 아래와 같은 구체적인 조건을 던지며 3자의 입장에서 토론을 지시합니다.
[실전 AI 프롬프트 1단계: 다중 페르소나 시뮬레이션]
"나는 지금 '내 기본 공격력의 1,000% 데미지를 주고, 얼음 속성 몬스터에게는 200% 추가 데미지가 들어가며, 10% 확률로 출혈 피해를 주는' 복잡한 액션 RPG 스킬을 만들려고 해.
이 스킬을 게임에 구현하기 위해 엑셀(DB) 테이블을 구성해야 하는데, 아래 3명의 전문가 관점에서 각각 어떤 구조로 데이터를 나누는 것이 가장 효율적인지 토론하고 논의 결과를 정리해 줘.
- 클라이언트 프로그래머: 스킬 이펙트 연출과 상태이상 애니메이션을 호출하기 쉬운 구조
- 서버 프로그래머: 서버 트래픽 부하를 최소화하고, 파싱(Parsing) 에러가 나지 않는 안전한 구조
- 시스템 기획자: 새로운 속성이 추가되었을 때 하드코딩 없이 기획자가 확장하기 쉬운 구조"
이 프롬프트의 핵심은 완성된 표를 달라는 것이 아니라, "개발 직군별 발생 가능한 이슈를 미리 시뮬레이션 해달라"는 데 있습니다.
4. 엑셀 테이블의 함정: 배열(Array) 금지와 모듈화 팩트 폭격
위의 1단계 프롬프트를 던지면, AI는 각자의 입장에서 그럴싸한 테이블 구조를 제안합니다.
이때 가장 빈번하게 등장하는 AI의 치명적인 함정이 바로 '배열(Array)'과 '무한 컬럼'입니다.
AI는 보상이 여러 개 나갈 수 있으니, 컬럼 하나에 Reward = [100, 200] 처럼 콤마로 묶거나, 컬럼을 가로로 길게 늘리라고 제안할 것입니다.
물론, JSON 자동 파서 환경이 완벽히 구축된 일부 프로젝트라면 배열 사용이 문제가 되지 않습니다.
하지만 대부분의 엑셀/CSV 기반 개발 환경에서 이는 휴먼 에러를 유발하는 치명적인 방식입니다.
현업 기획자라면 여기서 AI의 제안을 단호하게 잘라내고 필터링해야 합니다.
[실전 AI 프롬프트 2단계: 기획자의 교정 및 모듈화 지시]
"둘 다 기각한다.
배열(콤마)을 쓰면 기획자의 휴먼 에러(오타)가 터지고, 가로로 늘리면 유지보수가 불가능하다.
모든 데이터를 참조 ID 기반의 세로 구조로 모듈화(Modularization)해라.
- 기본 이펙트 효과는 [Effect_Table]로 분리할 것.
- 추가 효과 데이터는 [Additional_Table]로 분리할 것.
- 상태이상(출혈 등)은 [Condition_Table]로 분리할 것.
- 메인 스킬 테이블은 이 분리된 테이블들의 ID만 참조하도록 구조화해 줘."
위와 같은 교정(티키타카) 과정을 거치면, AI는 비로소 아래와 같이 '직관적인 분리형 DB 구조'를 뱉어내기 시작합니다.
다만, 이 표가 나왔다고 끝이 아닙니다.
이 테이블들이 어째서 이런 구조로 도식화(연결)되었는지 기획자 본인이 완벽히 이해해야 합니다.
원리를 모른 채 무턱대고 결과물만 복사+붙여넣기 한다면, 실무 회의에서 프로그래머의 질문 한 번에 식은땀을 뻘뻘 흘리고 있는 자신을 보게 됩니다.
[AI가 도출한 테이블 모듈화 예시]
▼ Skill_Table (메인 스킬 정보)
| ID | Name | Effect_Value | Effect_ID | Condition_ID | Additional_ID |
| 1001 | Ice Strike | 10.0 (1000%) | 2001 | 3001 | 4001 |
▼ Condition_Table (속성 조건 정보)
| ID | TargetType | Element | BonusDamage |
| 3001 | Monster | Ice | 2.0 (200%) |
▼ Additional_Table (추가 효과 정보)
| ID | Status_ID (출혈 상태이상) | Probability |
| 4001 | 5001 | 0.1 (10%) |
▼ Effect_Table (추가 효과 정보)
| ID | Effect | Desc |
| 2001 | 얼음 폭발 공격 | 설명 ID입력 |
이 과정은 단순한 문서 작성을 넘어 '타 부서의 개발이 어떠한 방식으로 진행하는 지' 시뮬레이션 할 수 있는 유익한 시간 입니다.
그리고 모듈화 된 이 테이블을 이어주는 귀찮은 작업을 서버 프로그래머들이 수용하는 이유는 단순합니다.
기획자가 보기 편한 테이블을 만들어야 치명적인 파싱 에러(오타)가 없고, 그래야 새벽에 서버가 터지는 사태를 막을 수 있다는 '생존 본능(상호 이익)'이 일치하기 때문입니다.
👉핵심 요약: 엑셀 테이블 내 배열(콤마) 사용은 오타의 주범입니다. 데이터를 모듈화하여 직관적인 세로 구조(참조 ID)를 유지하십시오.
5. 실무 검증: AI를 샌드백으로 활용해 기획의 구멍을 방어하는 법
결론적으로 기획자에게 AI란, 마법의 자판기가 아니라 '가장 훌륭한 샌드백이자 시뮬레이터'입니다.
다양한 직군의 관점과 극단적인 예외 상황을 텍스트로 미리 부딪혀보고, 실제 개발팀 회의에 들어갔을 때 공격받을 구멍들을 사전에 방어하는 용도입니다.
주니어와 지망생 여러분, 포트폴리오에 단순히 예쁜 UI 화면만 넣지 마십시오.
"내가 기획한 로직을 다중 페르소나를 통해 검증했고, 데이터 파싱 오류를 막기 위해 테이블을 어떻게 모듈화하여 설계했는지" 이 치열한 논리적 인과관계를 문서 한편에 증명하십시오.
면접관은 당신을 당장 실무에 투입해도 서버를 터뜨리지 않을 '안전한 1인분 기획자'로 판단할 것입니다.
지금 당장 위 3번의 [다중 페르소나 프롬프트]를 복사해서 AI 챗봇에 붙여넣고, 본인만의 스킬 기획을 대입해 보십시오.
이 단순한 실증 과정을 직접 해보고 AI와 티키타카를 해본 사람과, 눈으로만 읽고 넘긴 사람의 기획서는 3개월 뒤 전혀 다른 깊이를 가지게 될 것입니다.
작성자 소개: 시스템 파트장 17년 차 게임 시스템 기획자. 현재 중소 개발사 재직 중.
이 블로그는 허황된 껍데기 기획이 아닌, 엑셀과 DB로 증명하는 진짜 '현업 시스템 기획과 생존법'을 기록하기 위해 씁니다.