기획 맛보기 #3 — 게임의 시스템과 콘텐츠는 어떻게 상호작용하는가

오늘의 한 문장

시스템은 플레이가 작동하는 규칙이고, 콘텐츠는 그 규칙을 이용해 플레이어가 실제로 경험하는 대상이다.

1. 시스템과 콘텐츠의 차이

게임을 구성하는 요소는 크게 로직과 데이터, 또는 시스템과 콘텐츠의 관점으로 나눠볼 수 있다.

• 시스템: 여러 대상에 반복 적용되는 규칙과 구조
• 콘텐츠: 그 규칙을 이용해 만들어진 개별 대상과 경험

예를 들어 RPG의 아이템을 생각해보자.

시스템

• 아이템을 획득할 수 있다.
• 인벤토리에 보관할 수 있다.
• 같은 아이템은 최대 99개까지 중첩된다.
• 장비 아이템은 지정된 슬롯에 착용한다.
• 소비 아이템은 사용하면 효과가 발동하고 수량이 감소한다.

콘텐츠

• 체력을 50 회복하는 하급 물약
• 공격력이 20 증가하는 철검
• 화염 저항을 부여하는 붉은 반지
• 사용하면 마을로 이동하는 귀환 주문서

즉, 인벤토리와 장착·사용 규칙은 시스템이고, 철검과 물약은 그 시스템을 통해 작동하는 콘텐츠다.

Unreal Engine 공식 문서도 게임을 구성하는 요소를 로직과 데이터로 구분한다. 로직은 게임 요소가 따르는 명령과 구조이고, 데이터는 그 로직이 구체적으로 무엇을 수행할지 설명한다. 다만 실제 프로젝트에서는 두 영역이 완전히 분리되지 않고 서로 섞일 수 있다고 설명한다.
Epic Games — Balancing Blueprint and C++

---

2. 시스템은 가능성을 만들고 콘텐츠는 가능성을 증명한다

시스템과 콘텐츠의 관계는 다음과 같다.

시스템이 가능한 행동의 범위를 만든다
                ↓
콘텐츠가 그 규칙을 구체적인 경험으로 만든다
                ↓
콘텐츠를 테스트하며 부족한 규칙을 발견한다
                ↓
시스템을 수정하거나 확장한다
                ↓
새로운 콘텐츠를 만들 수 있게 된다

시스템이 콘텐츠보다 먼저 존재하는 경우가 많지만, 개발이 한 방향으로만 진행되는 것은 아니다.

예를 들어 아이템 시스템에 다음 필드가 있다고 가정하자.

이름종류가격효과 값

하급 물약	소비	100	체력 +50
철검	장비	500	공격력 +20

이 구조로는 일반적인 회복 아이템과 장비를 만들 수 있다.

그런데 콘텐츠 기획자가 다음 아이템을 제안했다.

적에게 던진 뒤 플레이어에게 되돌아오는 부메랑

현재 시스템에는 투척, 비행, 충돌, 귀환에 관한 규칙이 없다. 이때 선택지는 두 가지다.

1. 부메랑 아이디어를 포기하거나 기존 규칙에 맞게 바꾼다.
2. 부메랑을 구현할 가치가 충분하다면 투척 무기 시스템을 확장한다.

두 번째 선택을 하면 부메랑 하나만 만들어지는 것이 아니다. 이후 투척 단검, 폭탄, 회수 가능한 창 같은 새로운 콘텐츠를 만들 수 있다.

따라서 좋은 콘텐츠 아이디어는 단순히 시스템을 소비하는 데 그치지 않고 새로운 시스템의 필요성을 발견하는 실험이 되기도 한다.

---

3. 몬스터 AI에서의 상호작용

시스템이 먼저 정의하는 것

몬스터 AI 시스템은 개별 몬스터가 아니라 공통 행동 규칙을 다룬다.

대기 → 탐색 → 추적 → 공격 → 피격 → 사망

여기에 다음 규칙이 포함될 수 있다.

• 플레이어를 발견하는 거리와 각도
• 소리에 반응하는 범위
• 추적을 포기하는 조건
• 공격 가능 거리
• 경로 탐색 방식
• 피격 시 행동 전환
• 대상이 사라졌을 때의 처리

시스템으로 만드는 콘텐츠

공통 AI 시스템에 데이터와 행동을 조합하면 여러 몬스터를 만들 수 있다.

몬스터	탐지 거리	이동	주요 행동
고블린	10m	지상 추적	접근 후 근접 공격
궁수	18m	거리 유지	원거리 공격
늑대	14m	빠른 추적	측면 이동 후 돌진

같은 탐지·추적 시스템을 사용하지만 수치와 행동 조합에 따라 다른 전투 경험이 만들어진다.

콘텐츠가 시스템을 확장하는 순간

콘텐츠 기획자가 “천장을 기어 다니다가 플레이어 위로 떨어지는 거미”를 제안했다고 가정해보자.

기존 AI가 지상 이동만 지원한다면 다음 기능이 추가로 필요하다.

• 벽과 천장 이동
• 천장 대기 상태
• 낙하 공격
• 지상과 천장 사이의 경로 전환
• 카메라 밖 공격을 방지하는 경고

거미 콘텐츠가 새로운 AI 기능을 요구했고, 확장된 시스템은 이후 박쥐나 벽을 타는 몬스터에도 재사용할 수 있다.

---

4. 아이템에서의 상호작용

아이템 시스템

• 획득과 버리기
• 인벤토리 보관
• 중첩과 최대 수량
• 장착 슬롯
• 사용 조건
• 효과 적용
• 강화와 분해

아이템 콘텐츠

• 회복 물약
• 무기와 방어구
• 제작 재료
• 퀘스트 아이템
• 버프 음식
• 열쇠와 지도

Epic Games의 Unreal Engine 아이템 예제에서는 먼저 모든 아이템이 공통으로 가져야 할 ID, 종류, 이름, 설명 등의 데이터 구조를 정의하고, 이후 데이터 테이블의 각 행에 개별 아이템을 입력한다. 아이템마다 별도의 코드를 만드는 방식은 아이템 수가 늘어날수록 비효율적이므로, 공통 구조와 중앙화된 데이터로 관리하는 방식을 제안한다.
Epic Games — Manage Items and Data

콘텐츠가 요구하는 확장

“착용한 상태에서 플레이어의 체력이 낮아지면 공격력이 증가하는 반지”를 만든다고 가정해보자.

기존 시스템이 고정 능력치만 지원한다면 다음 기능이 필요하다.

• 체력 변화 감지
• 조건부 효과
• 효과의 활성화와 비활성화
• 여러 효과가 겹칠 때의 계산 순서
• UI에 현재 활성 상태 표시

콘텐츠 하나가 조건부 효과 시스템을 만들게 하고, 이후 다양한 장비 콘텐츠에 재사용할 수 있다.

---

5. 퀘스트에서의 상호작용

퀘스트 시스템

퀘스트 시스템은 이야기의 내용보다 진행 규칙을 정의한다.

잠김 → 수락 가능 → 진행 중 → 완료 가능 → 완료
                         ↘ 실패

주요 규칙은 다음과 같다.

• 퀘스트 수락 조건
• 목표 달성 판정
• 여러 목표의 순서
• 실패 조건
• 보상 지급
• 선행·후행 퀘스트
• 저장과 불러오기
• NPC와 UI의 상태 변화

퀘스트 콘텐츠

늪에서 실종된 약초꾼을 찾아 마을로 데려온다.

콘텐츠 기획자는 다음을 정한다.

• 퀘스트를 주는 NPC
• 약초꾼의 위치
• 조사해야 할 흔적
• 등장하는 적
• 대화와 전투 순서
• 완료 보상

콘텐츠가 시스템을 확장하는 순간

기획자가 다음 선택지를 추가하려고 한다.

약초꾼을 구하거나, 그가 가진 희귀 약초만 빼앗아 돌아올 수 있다.

이 콘텐츠를 구현하려면 퀘스트 시스템이 다음을 지원해야 한다.

• 선택 결과 저장
• 상호 배타적인 목표
• NPC 생존 상태
• 결과에 따라 달라지는 보상
• 이후 퀘스트와 대사의 변화

단순한 일자형 퀘스트가 분기형 콘텐츠로 발전하면서 시스템에도 선택 기록과 상태 추적 기능이 필요해진다.

---

6. 전투에서의 상호작용

전투 시스템

• 공격 입력과 애니메이션 상태
• 공격 범위와 적중 판정
• 피해 계산
• 회피 무적 시간
• 방어와 패링
• 상태이상
• 사망과 보상 처리

전투 콘텐츠

• 무기별 공격 동작
• 개별 스킬
• 몬스터의 공격 패턴
• 보스전 구성
• 전투 공간과 적 배치

콘텐츠가 시스템을 확장하는 순간

“보스의 공격을 정확한 순간에 막으면 무기가 부서지고 보스가 그로기 상태가 된다”는 패턴을 기획했다고 가정해보자.

이를 위해서는 다음 기능이 필요하다.

• 패링 성공 시간 판정
• 보스 무기의 내구도
• 무기 파괴 상태
• 그로기 게이지와 상태 전환
• 전용 카메라·이펙트·사운드
• 한 번 파괴된 무기가 다시 나타나지 않도록 하는 저장

보스 콘텐츠의 아이디어가 전투 시스템을 확장한다. 그리고 이 기능이 범용적으로 설계되면 다른 보스나 일반 적에게도 무기 파괴 콘텐츠를 적용할 수 있다.

---

7. 실제 사례: 《젤다의 전설 브레스 오브 더 와일드》

《젤다의 전설 브레스 오브 더 와일드》는 시스템이 다양한 콘텐츠 경험을 만들어내는 사례다.

불, 바람, 전기, 금속, 물리 오브젝트 등이 각 장소에서 별도의 연출로만 작동하는 것이 아니라 비교적 일관된 규칙으로 상호작용한다.

예를 들면 다음과 같다.

• 풀과 나무 오브젝트에 불이 붙는다.
• 불로 발생한 상승기류를 타고 날아오를 수 있다.
• 금속 물체는 전기와 상호작용한다.
• 물리 오브젝트를 밀거나 굴려 적을 공격할 수 있다.

각 상황을 개발자가 하나씩 정답으로 제작하지 않아도 시스템의 조합을 통해 여러 해결 방법이 발생한다.

이 게임의 테크니컬 디렉터 Takuhiro Dohta는 개발 목표 중 하나를 multiplicative gameplay라고 설명했다. 통일된 규칙 속에서 플레이어가 자신만의 해결 방법과 재미를 찾도록 하는 방향이다.
Nintendo — Breath of the Wild and “Multiplicative Gameplay”

이 사례에서 시스템은 단순히 콘텐츠를 담는 그릇이 아니다. 여러 시스템이 서로 반응하면서 개발자가 직접 만들지 않은 플레이 상황까지 발생시키는 콘텐츠 생성기에 가깝다.

---

8. 실제 사례: 기능에서 콘텐츠의 모습이 결정되다

Nintendo는 《Nintendo Land》 개발 당시 여러 프로토타입을 먼저 만든 뒤, 서로 다른 게임을 하나로 묶을 테마파크 콘셉트를 적용했다.

특히 《Donkey Kong’s Crash Course》에서는 프로토타입의 삼각형 형태가 플레이하기에 가장 재미있었기 때문에 최종 디자인에도 유지했다. 외형을 먼저 정한 뒤 기능을 끼워 넣은 것이 아니라, 재미있는 작동 방식이 콘텐츠의 형태를 결정한 것이다.
Nintendo — Iwata Asks: Design Follows Function

《Super Mario 3D World》의 Cat Mario 역시 벽을 오르고, 적을 할퀴고, 골대 기둥을 올라가는 기능을 중심으로 만들어졌다. 개발진은 기존 균형을 흔들 가능성보다 실제로 재미있는지를 우선해 여러 아이디어를 제작하고 검증했다고 설명한다.
Nintendo — Iwata Asks: Super Mario 3D World, “Function First”

이처럼 시스템과 기능에서 시작한 아이디어는 이후 캐릭터의 외형, 스테이지 구조, 적 배치 같은 콘텐츠로 확장된다.

---

9. 시스템을 먼저 만드는 것이 유리한 이유

콘텐츠를 반복해서 만들 수 있다

아이템 사용 규칙을 한 번 만들면 물약, 음식, 주문서 등 여러 콘텐츠를 같은 구조로 제작할 수 있다.

일관성을 유지할 수 있다

같은 상태이상인데 몬스터마다 적용 방식이 다르면 플레이어가 규칙을 학습하기 어렵다. 공통 시스템을 사용하면 비슷한 상황에서 같은 결과가 발생한다.

수정 비용을 줄일 수 있다

피해 계산 공식을 하나의 시스템에서 관리하면 전체 무기와 몬스터에 일관되게 반영할 수 있다.

팀이 병렬로 작업할 수 있다

프로그래머가 제작 도구와 공통 구조를 준비하면 콘텐츠 기획자와 아티스트가 개별 몬스터, 아이템, 퀘스트를 동시에 만들 수 있다.

대량 콘텐츠를 관리하기 쉽다

Unreal Engine은 데이터 테이블과 커브 테이블을 이용하면 외부 스프레드시트에서 수치를 관리하고 다시 게임에 반영할 수 있다고 설명한다. 특히 업데이트가 오래 지속되고 반복적인 밸런스 조정이 필요한 게임의 작업량과 복잡도를 줄이는 데 도움이 된다.
Epic Games — Data Driven Gameplay Elements

위험한 의존성을 일찍 발견할 수 있다

전투가 없는 상태에서 몬스터를 100종 기획하면 공격 판정이나 AI 규칙이 바뀔 때 모든 몬스터를 수정해야 한다. 핵심 시스템과 대표 콘텐츠를 먼저 검증하면 이런 대규모 재작업을 줄일 수 있다.

---

10. 시스템 우선이 항상 정답은 아니다

“시스템 먼저”는 모든 시스템을 완성한 뒤 콘텐츠를 만들라는 뜻이 아니다.

콘텐츠 없이 시스템만 설계하면 실제 요구를 알 수 없어 지나치게 복잡하거나 사용할 수 없는 구조를 만들 수 있다. 따라서 보통은 다음처럼 진행하는 편이 안전하다.

최소 시스템
    +
대표 콘텐츠 1~3개
    ↓
직접 플레이
    ↓
시스템과 콘텐츠를 함께 수정
    ↓
검증된 구조로 콘텐츠 확장

콘텐츠나 경험을 먼저 검증해야 하는 경우

독특한 보스전이 게임의 핵심일 때

보스 한 명의 전투 경험이 게임의 핵심이라면 범용 전투 시스템 전체보다 대표 보스를 먼저 프로토타이핑하는 편이 낫다. 그 보스를 구현하면서 실제로 필요한 시스템을 발견할 수 있다.

서사와 선택이 핵심일 때

분기형 어드벤처 게임이라면 전투나 인벤토리보다 대화 선택, 결과 저장, 감정 전달이 먼저 검증되어야 한다. 이 경우 대표 에피소드가 필요한 내러티브 시스템을 정의한다.

한 번만 등장하는 연출일 때

게임 전체에서 한 번 사용하는 장면을 위해 지나치게 범용적인 시스템을 만들면 개발 비용이 더 커질 수 있다. 재사용 가능성과 구현 비용을 비교해 전용 연출로 처리할 수 있다.

실험적인 플레이를 찾는 단계일 때

아직 무엇이 재미있는지 모르는 상태에서는 시스템 구조를 확정하기보다 빠른 프로토타입으로 여러 행동과 콘텐츠를 시험하는 것이 우선이다.

IP나 콘텐츠 제약이 강할 때

원작 캐릭터의 특정 능력, 이야기의 필수 장면, 실제 스포츠 규칙처럼 바꿀 수 없는 콘텐츠가 있다면 시스템이 그 요구사항을 지원하도록 설계해야 한다.

---

11. 실무에서 사용할 판단 기준

새로운 콘텐츠 아이디어가 나왔을 때 다음 질문을 확인할 수 있다.

1. 기존 시스템으로 구현할 수 있는가?
2. 구현할 수 없다면 콘텐츠를 조정할 수 있는가?
3. 시스템을 확장하면 다른 콘텐츠에도 재사용할 수 있는가?
4. 확장 비용에 비해 플레이 경험의 가치가 충분한가?
5. 기존 콘텐츠와 충돌하거나 예외를 지나치게 늘리지 않는가?
6. 대표 콘텐츠로 먼저 재미를 검증했는가?

특히 “재미있어 보인다”는 이유만으로 시스템을 계속 확장하면 일정이 무너질 수 있다. 반대로 현재 시스템에 맞지 않는다는 이유로 모든 새로운 아이디어를 거부하면 콘텐츠가 단조로워질 수 있다.

중요한 것은 콘텐츠의 가치와 시스템 확장 비용을 함께 판단하는 것이다.

---

오늘 배운 점

시스템과 콘텐츠는 뼈대와 살처럼 구분할 수 있지만 실제 개발에서는 계속 서로 영향을 준다.

• 시스템은 콘텐츠가 작동할 수 있는 규칙을 제공한다.
• 콘텐츠는 시스템이 실제로 재미있는지 검증한다.
• 새로운 콘텐츠는 기존 시스템의 한계를 발견한다.
• 확장된 시스템은 다시 더 다양한 콘텐츠를 만들게 한다.

따라서 가장 현실적인 개발 방식은 모든 시스템이나 모든 콘텐츠 중 하나를 먼저 완성하는 것이 아니다.

핵심 시스템을 최소한으로 만들고, 대표 콘텐츠로 검증한 뒤, 둘을 함께 확장하는 것이 중요하다.