[도서 리뷰] 유리링의 실전 게임 시스템 기획

AI가 어려운 문제까지 상당 부분 해결해 주는 요즘.. 블로그에 정리할 만한 소재가 점점 줄어들고 있다고 느끼던 시점이었습니다.

그런데 운 좋게 올해 한빛미디어 서평단에 참여하게 되면서 최소 월 1회 이상 도서 리뷰를 기록할 수 있는 계기가 마련되었습니다.

매달 초 여러 전자 도서 중에서 원하는 책을 선택해 리뷰를 작성하는 방식이라 평소 접하지 못했던 분야를 탐색해 볼 수 있다는 점도 매력적으로 느껴졌습니다.

이제는 AI의 도움으로 개인이 기획부터 구현까지 상당 부분을 혼자 수행할 수 있는 환경이 되었다고 생각합니다. 그러나 결국 무엇을 만들 것인가를 결정하는 영역은 여전히 사람의 몫이라고 생각합니다. 그래서 이번에는 기술 자체가 아니라, 조금 더 넓은 관점에서 기획이라는 영역을 이해해 보고자 이 책을 선택하게 되었습니다.

이번에 선택한 도서는 현재 제가 수행 중인 실무와 직접적으로 맞닿아 있지는 않지만, 완전히 동떨어진 분야도 아닙니다.
개발을 하면서도 항상 기획의 의도와 구조를 이해하는 것이 중요하다고 느껴왔기 때문입니다.
기획을 이해하지 못한 채 구현만 반복하다 보면, 결국 전체적인 방향성을 놓치게 된다고 생각합니다.

이 책에서 특히 인상 깊었던 문장은 “기획은 이론이 아니라 설계이며, 전달되지 않는 기획은 존재하지 않는 것과 같다”는 표현이었습니다.
개인적으로도 눈으로 확인하고 구조를 이해해야 납득하는 성향이 있기에 기획의 전달 가능성을 강조한 이 문장이 크게 와닿았습니다.

함께 읽고 있는 소프트웨어 아키텍처라는 책에서 이런 문장을 본 적이 있습니다.
지식을 세 가지로 구분하면, 내가 알고 있는 것, 존재는 알지만 정확히는 모르는 것, 그리고 무엇을 모르는지조차 모르는 것으로 나눌 수 있다는 내용이었습니다.

이번 한빛미디어 2026 <나는 리뷰어다> 활동은 평소 실무에서 깊게 다루지 못했던 영역을 얇지만 넓게 탐색해 보는 기회(흥미로운 책이 있으면 바뀔수도..)가 되었으면 합니다.

전문적인 실무 역량은 기술 서적을 통해 깊이를 쌓고, 이번 도서는 시야를 확장하는 관점에서 접근하면 좋겠다는 생각도 들었습니다.

아래에는 읽으며 인상 깊었던 내용을 일부 발췌해 정리했습니다.

도서 내용 목차

1부 게임 시스템 기획 개론

무언가를 기획하기 위해서는 먼저 의도와 방향성을 설정하기 위한 질문이 필요합니다.

어떤 문제를 해결하려는가?
어떤 플레이 흐름을 유도하려는가?
핵심 규칙은 무엇이며, 그 규칙은 어떤 경험을 만들어 내는가?

결국 게임 기획은 하나의 세계를 설계하는 일에 가깝다고 느꼈습니다. 각 시스템은 독립적으로 존재하는 것이 아니라 서로 유기적으로 연결되어 있기 때문에, 하나의 요소가 바뀌면 전체 균형에도 영향을 줍니다. 그래서 더욱 구조적인 접근이 필요합니다.

시스템 기획자는 게임의 전체 구조와 흐름을 설계하는 역할을 담당합니다. 따라서 게임이 어떤 방식으로 순환하고, 어떤 구조로 확장되는지에 대한 거시적 이해가 필수적입니다.

이 부분을 읽으며 개발자 역시 기획자와 유사한 수준의 구조적 시야를 갖추는 것이 중요하다고 느꼈습니다. 구현에 집중하는 것도 중요하지만, 전체 구조를 이해하고 있어야 설계 의도에 부합하는 일관된 구현이 가능하기 때문입니다.

2부 기획 의도 설계

기획 의도는 단순한 방향 설정이 아니라, **“왜 만드는가?”, “왜 지금 이 방식이어야 하는가?”**를 끊임없이 묻는 사고 과정이라는 설명이 인상 깊었습니다.

좋은 시스템은 기능의 나열이 아니라, 플레이어의 경험과 감정 흐름을 설계한 결과물이라는 점을 강조합니다. 단순히 콘텐츠를 추가하는 것이 아니라, 플레이어가 어떤 동기를 가지고 반복 플레이를 하게 되는지까지 고려해야 한다는 것입니다.

책에서는 기획 의도를 검증하기 위한 프레임워크도 제시합니다.

기획 의도 증명 프레임 6가지

1. 왜 이 기능이 필요한가? 왜 지금이어야 하는가?
2. 이 기능이 없다면 어떤 문제가 발생하는가? 그리고 그 문제는 왜 지금 해결되어야 하는가?
3. 이 기능이 도입되면 어떤 결과가 예상되는가? 그 결과가 긍정적일 것이라고 판단한 근거는 무엇인가?
4. 이 기능은 기존 시스템 또는 콘텐츠와 어떤 차별점을 가지는가?
5. 예상되는 리스크는 무엇이며, 이를 어떻게 관리하거나 완화할 것인가?
6. 위의 모든 판단을 뒷받침할 수 있는 데이터 또는 근거는 무엇인가?

이 프레임은 게임 기획뿐만 아니라, 기능 개발이나 아키텍처 설계에서도 그대로 적용할 수 있을 것 같다는 생각이 들었습니다. 결국 설계란, 선택에 대한 책임을 논리적으로 설명할 수 있는 상태를 만드는 과정이라는 점에서 공통점이 있기 때문입니다.

3부 시스템 구조화

UI 구조를 고민하는 것보다 먼저 시스템 기획을 시작할 떄 반드시 기능 단위로 분해하는 작업부터 선행이 필요합니다.

시스템 기획을 시작할 때는 UI 구조를 먼저 고민하기보다, 기능 단위로 분해하는 작업을 선행해야 한다고 설명합니다.

기능 단위 분해란, 시스템을 구성하는 각각의 행위와 동작을 최소 단위로 나누고, 이 기능들이 어떤 순서와 관계 속에서 작동하는지 구조화하는 과정입니다.
말 그대로 “보이는 화면”이 아니라 “실제로 동작하는 구조”를 먼저 설계하는 접근입니다.

기능 단위 분해 방법

1. 눈에 보이는 기능부터 나열한다.
2. 자동으로 처리되는 내부 기능을 정리한다.
3. 작동에 필요한 데이터와 조건을 정의한다.
4. 예외 상황과 실패 상황을 구체적으로 가정한다.

특히 예외 상황을 미리 정의하는 부분이 인상 깊었습니다.

• 우편함이 가득 찼을 경우 새 우편은 어떻게 처리되는가?
• 발신자가 캐릭터를 삭제했다면 우편은 어떻게 되는가?
• 기간이 만료된 우편을 플레이어가 클릭하면 어떤 동작을 하는가?

위의 이미지 처럼 기능 단위 분해는 특정 게임 시스템에만 국한되는 기법이 아니라, 다양한 기획과 설계 영역에서 활용할 수 있는 방법론이라고 생각합니다.

또한, 시스템 간의 유기적 관계를 이해하고 나면 왜 구조가 복잡해지는지 어디에서 설계가 꼬이는지 보다 명확히 보이기 시작합니다. 복잡도를 낮추는 출발점이 바로 구조화의 시작이지도 않을까요?

4부 규칙 설계

규칙 설계 단계에서는 플로우 차트와 같은 시각적 도구를 적극적으로 활용합니다. 규칙은 텍스트로만 설명하기보다 이미지의 흐름으로 표현했을 때 훨씬 명확해집니다.

개발에서도 구현에 앞서 다양한 설계 문서를 작성하게 되는데, 결국 이는 구현 이전에 사고를 정리하는 과정이라고 볼 수 있습니다.

특히 인상적이었던 점은 대형 게임사에서는 기획자가 플로우 차트 수준까지 구체적으로 문서화한다는 부분이었습니다..
이렇게 규칙과 흐름이 명확하게 정의되어 있다면 개발자는 구현 과정에서의 해석 오류를 줄일 수 있고, 의도에 맞는 결과물을 만들 수 있을 것이라 생각되는데.. 음..

5부 데이터 테이블 설계

이 챕터는 개인적으로 가장 흥미로웠던 부분입니다. 게임 기획자가 데이터 테이블 설계 수준까지 이해해야 하는가에 대해 의문이 들었기 때문입니다.

제가 경험한 프로젝트에서는 기획자가 시나리오나 정책을 문서로 정리하면 개발자가 이를 기반으로 DB 설계와 구현을 담당하는 구조가 일반적이었습니다. 하지만 책에서는 기획자가 데이터 구조까지 고려해야 한다고 설명합니다.

이 챕터만 놓고 보면 DB 설계 영역에 가깝다고 느껴졌습니다. 그러나 구조를 설계하는 사람이라면 그것이 기획자든 개발자든 데이터의 형태를 이해하는 것이 결국 도움이 된다고 생각됩니다.

특히 요즘처럼 AI 도구가 발전한 환경에서는 한 사람이 기획부터 개발, 디자인까지 수행하는 경우도 점점 늘어나고 있습니다?
그런 관점에서 보면, 데이터 구조에 대한 이해는 특정 직군의 전유물이 아니라 시스템을 설계하는 사람이라면 누구나 갖추면 좋은 역량이라는 생각이 듭니다.

6부 UX/UI 설계

보통 UI/UX라는 표현을 많이 쓰지만, 저자는 UX/UI라고 설명합니다. 책을 읽어보니 왜 UX가 먼저인지 이해가 되었습니다. 사용자 경험을 먼저 설계하고, 그 위에 UI를 입히는 구조이기 때문입니다. 결국 화면보다 경험이 먼저라는 의미입니다.

두 화면을 보면 게임마다 차이는 있지만 기본적인 배치와 구조에는 공통 포맷이 존재합니다. 이는 사용자 경험을 기반으로 설계되었기 때문이라고 생각합니다. 웹사이트, 모바일 OS, Windows, macOS 등도 마찬가지로 UX 중심의 일정한 패턴을 따르고 있습니다.

이 기본 구조를 크게 벗어나면 사용자는 혼란이나 거부감을 느낄 가능성이 있습니다. 차별화는 필요하지만.. 익숙함을 완전히 무너뜨려서는 안 된다는 점이 중요해 보입니다.

결국 UX/UI는 단순한 화면 디자인이 아니라, 사용자 경험을 기반으로 한 구조 설계입니다.

책에서 제시한 고려 요소는 다음과 같습니다.

• 시인성: 보이지 않으면 없는 것과 같다
• 직관성: 배우지 않아도 사용할 수 있어야 한다
• 일관성: 한 번 익힌 방식은 계속 통해야 한다
• 확장성: 콘텐츠가 늘어나도 구조는 유지되어야 한다
• 명확한 피드백: UI는 사용자와의 대화다
• 감정 설계: 손은 UI를 기억하고, 머리는 UX를 기억한다
• 역방향 점검: UI가 복잡하다면 시스템을 의심하라

전체적으로 공감되는 내용이었고, 특히 UI가 복잡하면 시스템을 의심하라는 부분은 개발 관점에서도 공감이 많이 되었습니다.

7부 시스템 기획서 작성

기획서는 결국 누가 읽는지를 고려해 작성해야 합니다. 개발자인 저는 기획서를 보면 구현 가능성과 설계 방식을 먼저 생각하게 됩니다. 그래서 기획서는 아이디어 정리가 아니라, 실행을 전제로 한 문서여야 한다고 느꼈습니다.

책에서는 기획서를 왜 → 무엇을 → 어떻게 순서로 작성한다고 설명합니다. 여기에 더해, 저는 “이미 유사한 서비스는 없는가?”라는 질문도 필요하다고 생각했습니다. 경쟁력과 차별성에 대한 고민이 선행되어야 하기 때문입니다.

또한 시스템 기획은 신규 프로젝트뿐 아니라 기존 서비스의 개선에도 중요합니다. AI 역시 선택이 아니라, 적극적으로 활용해야 할 도구라는 인상을 받았습니다.

8부 시스템 기획자의 실무

시스템 기획은 프로젝트와 함께 움직이는 협업 과정입니다. 결국 핵심은 문서화와 커뮤니케이션입니다.

책에서도 강조하듯, 의도가 명확하게 전달되지 않는 기획은 의미가 없습니다. 기획과 개발 모두 결국은 의도를 정확히 공유하는 일이라는 점을 다시 생각하게 되었습니다.

리뷰

시스템 기획자의 역할을 개발자의 관점에서 바라보면, 결국 하나의 구조를 설계한다는 점에서 아키텍처 설계와 유사하다고 느껴졌습니다. 게임 시스템 기획 이후 실제 구현은 개발자의 몫이지만, 초기 구조와 흐름을 정의하는 단계는 개발에서의 상위 설계 과정과 상당히 닮아 있습니다.

책에서는 시스템 기획자와 콘텐츠 기획자의 역할을 명확히 구분해 설명합니다. 이 구분은 개발자에게도 시사점을 줍니다. 아키텍처를 설계한 뒤 그 의도를 유지하며 일관되게 구현해 나가는 것이 중요하듯, 기획 역시 구조적 일관성을 기반으로 완성된다는 점을 다시 생각하게 되었습니다.