AI를 활용한 기획 특강 - 김인권 튜터님
한 줄 요약: 좋은 기획은 좋은 아이디어가 아니라, 좋은 "결정"들이 쌓인 결과다.
1. 분위기 vs 결정
게임 기획 문서는 결국 두 종류로 갈린다.
| 구분 | 특징 | 결과 |
|---|---|---|
| 분위기 문서 | 사람마다 다르게 해석되는 문장 | 팀원이 서로 다른 그림을 그림 |
| 결정 문서 | 누가 읽어도 같은 그림이 그려지는 문장 | 팀원이 같은 목표를 가짐 |
같은 의도, 다른 문장
| 분위기 (해석 갈림) | 결정 (해석 동일) |
|---|---|
| 박진감 넘치는 전투 | 일반 전투 평균 8초, 보스전 3분 이내 |
| 방대한 세계관 | 스테이지 3개, 각 10~15분 |
| 다양한 빌드 | 무기 4종, 패링 타이밍 모두 다름 |
| 긴장감 있는 보스전 | 최종 보스 첫 클리어까지 사망 5±2회 |
분위기를 결정으로 바꾸는 방법은 단 하나, 수치 또는 구체적 사물로 적는 것.
한 문장 판정 기준
이 문장을 팀원 4명이 각자 읽었을 때, 머릿속에 같은 그림이 그려지는가?
분위기 문서를 없앨 필요는 없다. 다만 결정이 그 옆에 함께 있어야 한다.
2. 역할 분담 — 누가 무엇을 결정하는가
"다 같이 잘하자"로 시작해서 "왜 이건 아무도 안 했지?"로 끝나는 이유는 역할이 모호하기 때문이다.
4~6주짜리 프로젝트는 명확한 역할 분담 위에서만 굴러간다. 4인 팀 기준 최소 5개 역할(겸직 가능).
| 역할 | 책임 | 핵심 결정 |
|---|---|---|
| 콘셉트 리드 | 게임의 정체성과 방향성 | 한 줄 컨셉, 톤앤매너, 차별점 |
| 시스템 리드 | 게임 규칙과 메커니즘 | 공식 시스템 목록, 시스템 간 연결 |
| 밸런싱/데이터 리드 | 수치와 데이터 형식 | 스탯 공식, RowName 규칙, CSV 관리 |
| 레벨/콘텐츠 리드 | 스테이지/퀘스트/아이템 | 맵 구성, 콘텐츠 흐름, 난이도 배치 |
| PM | 일정/문서/회의 운영 | 마일스톤, 회의 진행, Decision Log |
- 콘텐츠 단위로 나누면 (캐릭터 담당, UI 담당 식) 사각지대가 생긴다 → 책임 단위로 나누는 편이 안전하다.
- PM이 없으면 결정이 기록되지 않는다. 별도 인원이 맡거나 콘셉트 리드가 겸직.
DRI (Directly Responsible Individual)
각 역할은 자기 영역의 DRI다.
- DRI는 합의가 안 됐을 때 책임지고 결정하는 사람이다.
- DRI는 독재자가 아니다. 다른 의견을 무시하는 사람이 아니라, 토론의 결론을 정리하고 기록할 책임을 지는 사람이다.
- DRI가 정해져 있어야 다른 팀원도 마음 편하게 의견을 던질 수 있다.
- DRI = 결정권자가 아니라 결정 책임자.
역할 간 연결 흐름
콘셉트 → 콘텐츠 → 시스템 → 밸런싱 → 데이터
└─ 레벨 ─┘앞 단계의 결정이 흔들리면 뒤 단계가 무너진다. 반드시 콘셉트부터 결정한다.
3. 콘셉트 기획 — 게임의 정체성
콘셉트는 다른 게임과 우리 게임을 가르는 한 문장이다.
콘셉트가 명확하지 않으면 콘텐츠와 시스템이 흩어진다. "이 게임이 무엇인가"에 대한 답이 한 문장 안에 있어야 한다.
결정해야 할 것
| 항목 | 핵심 질문 |
|---|---|
| 한 줄 컨셉 | 모르는 사람에게 한 문장으로 설명한다면? |
| 톤앤매너 | 어떤 분위기/색감/음악인가? |
| 세계의 결핍 | 세계가 무엇을 잃었는가? |
| 주인공의 이해관계 | 왜 이 주인공이 움직이는가? |
| 차별점 | 비슷한 게임과 무엇이 다른가? |
한 문장으로 답이 안 나오면 아직 분위기 단계다.
최종 산출물: A4 한 장
요즘 기획서는 분량 제한이 있는 경우가 많다. 많이 쓰는 것보다, 핵심을 잘 압축하는 게 더 어렵다.
4. 콘텐츠 기획 — 무엇을 채울지 결정
콘텐츠 기획은 콘셉트에서 정한 정체성을 구체적인 사물로 옮기는 작업이다.
| 항목 | 핵심 질문 |
|---|---|
| NPC | 누가 등장하고, 무엇을 원하는가? |
| 무기/장비 | 어떤 종류가 몇 개 있는가? |
| 퀘스트/이벤트 | 어떤 사건이 일어나는가? |
| 아이템/자원 | 무엇을 모으고 무엇과 교환하는가? |
| 플레이어 선택 | 플레이어는 무엇을 결정할 수 있는가? |
양보다 의미
6~9주 프로젝트에서 콘텐츠를 무한히 늘리는 것은 불가능하다. 콘셉트와 강하게 연결된 작은 콘텐츠가 흩어진 많은 콘텐츠보다 낫다.
| 나쁜 방향 | 좋은 방향 |
|---|---|
| 무기 20개 만들기 | 콘셉트와 연결된 무기 4개 |
| NPC 15명 만들기 | 명확한 역할이 있는 NPC 3명 |
| 퀘스트 30개 만들기 | 목표와 장애물이 분명한 퀘스트 5개 |
5. 시스템 기획 — 규칙을 결정
모든 게임 시스템은 입력 → 규칙 → 출력 구조다.
콘텐츠가 "무엇이 있는가"라면, 시스템은 "그것들이 어떻게 작동하는가"이다.
시스템 = 함수
| 시스템 | 입력 | 규칙 | 출력 |
|---|---|---|---|
| 전투 | ATK, DEF, 스태미나 | 데미지 공식 | HP 변화 |
| 부활 | 죽음 | 부활 + 적 리스폰 | 진행 상태 변화 |
| 자원 | 적 처치 | 흡수/소멸 | 자원 보유량 변화 |
매개변수 → 메서드 → 반환값. 시스템 설계는 결국 클래스 설계.
데미지 공식 — 시스템 단계에서 결정해야 한다
"만들면서 맞추자"고 미루면 후반 밸런싱이 무너진다.
- 차감형의 함정:
Damage = ATK − DEF. 후반의 ATK가 DEF를 압도하면 DEF가 무의미해진다. 보스 DEF가 80이든 10이든 ATK 200 앞에서는 데미지 차이가 거의 없어진다. - 비율형의 K값:
Damage = ATK × (1 − DEF / (DEF + K)). K가 크면 DEF 영향이 작아지고, K가 작으면 DEF가 강력해진다. 소울라이크는 보통 K = 100 전후.
자원 경제 — Source = Sink
골드/경험치/재화 같은 자원은 들어오는 곳(Source)과 나가는 곳(Sink)을 함께 설계해야 한다.
| 상태 | 증상 |
|---|---|
| Source > Sink | 자원이 남음 → 업그레이드가 시시함 |
| Source < Sink | 자원이 부족 → 진행이 막힘 |
| Source ≈ Sink | 적정 긴장감 |
시스템은 5~7개가 한계
6~9주짜리 프로젝트는 시스템 5~7개가 한계. 그 이상은 완성되지 않는다.
예) "푸른 사막"의 시스템 5개:
1. 전투: 공격 / 방어 / 회피 / 패링
2. 스태미나: 모든 액션의 비용
3. 오아시스: 부활 + 적 리스폰
4. 물 자원: 적 처치로 얻고, 강화에 사용
5. 무기: 4종, 패링 타이밍이 각각 다름
데미지 공식: ATK × (1 − DEF / (DEF + 100)) — 비율형.
6. 레벨 기획 — 공간과 흐름
같은 콘텐츠와 시스템이라도 레벨 설계에 따라 완전히 다른 경험이 된다.
| 항목 | 핵심 질문 |
|---|---|
| 스테이지 구성 | 몇 개의 스테이지, 각자 무엇이 다른가? |
| 목표 플레이 타임 | 한 스테이지 몇 분, 현재 몇 분? |
| 난이도 곡선 | 어디서 학습하고, 어디서 도전하고, 어디서 절정인가? |
| 체크포인트 | 부활 지점은 어디인가? |
| 보상 배치 | 어디서 무엇을 얻는가? |
난이도 곡선의 기본 패턴
학습 → 적용 → 도전 → 절정
| 스테이지 | 역할 |
|---|---|
| 1 | 학습/튜토리얼 |
| 2 | 적용, 본격적인 도전 |
| 3 | 난이도 상승, 중간 보스 |
| 최종 | 절정, 보스전 |
7. 밸런싱 — 수치를 결정
밸런싱은 감이 아니라 절차다.
공식 → 변수 조정 → 시뮬레이션 → 검증 순서. 감으로 잡은 수치는 정당성이 없어서 회의가 끝나지 않는다.
통과 기준이 가장 자주 빠진다
밸런싱의 마지막 단계는 "이 정도면 통과"라고 말할 수 있는 검증 기준이다. 통과 기준 없이 "재밌게 만들자"로 가면 작업이 영원히 끝나지 않는다.
소울라이크의 통과 기준은 보통 사망 횟수다.
| 구간 | 목표 사망 횟수 |
|---|---|
| 1스테이지 | 1~2회 |
| 2스테이지 | 2~4회 |
| 3스테이지 | 더 높은 도전 |
| 최종 보스 | 5±2회 |
너무 적으면 시시하고, 너무 많으면 좌절한다.
스탯 공식의 구성
Stat(Lv) = Base + Growth × (Lv − 1)^Curve| 요소 | 의미 |
|---|---|
| Base | 1레벨 기본값. "초반에 적을 몇 번 때려야 잡히는가"의 기준 |
| Growth | 매 레벨 증가량. "한 레벨 올렸을 때 체감되는가"의 기준 |
| Curve | 곡선 지수. 1.0이면 직선, 초과면 후반 가속, 미만이면 후반 감속 |
이유 없는 수치는 밸런싱이 아니라 추측이다. 시나리오가 밸런싱의 정당성을 만들어준다.
8. 데이터 — 결정을 데이터로 옮긴다
데이터 기획서는 엔진(UE 등)에 그대로 Import 가능해야 한다.
엑셀에 정리해뒀는데 Import 할 때 한 번 더 손봐야 한다면, 그건 데이터 기획서가 아니라 메모다.
데이터 드리븐으로 관리할 대상:
- 무기/몬스터 스탯
- 아이템 정보, 보상 테이블
- 퀘스트 정보, 강화 비용, 스킬 수치
오늘의 정리
- 아이디어보다 결정이 중요하다. 분위기 문서는 그대로 두되, 옆에 결정을 함께 둔다.
- 수치와 구체적 사물로 적어야 분위기가 결정으로 바뀐다.
- 역할은 콘텐츠 단위가 아니라 책임 단위(DRI)로 나눈다.
- 콘셉트 → 콘텐츠 → 시스템 → 레벨 → 밸런싱 → 데이터 순서를 지킨다. 앞이 흔들리면 뒤가 무너진다.
- 시스템은 함수다. 입력 → 규칙 → 출력. 데미지 공식과 자원 경제(Source = Sink)는 시스템 단계에서 결정해야 한다.
- 밸런싱은 절차다. 통과 기준(사망 횟수 등)이 빠지면 작업은 끝나지 않는다.
- 데이터 기획서는 메모가 아니라 Import 가능한 형태여야 한다.
