
기획서는 길게 쓴다고 좋은 문서가 아닙니다. 프로그래머가 읽고 질문 없이 구현할 수 있고, 그래픽 팀이 필요한 리소스 목록을 바로 뽑을 수 있어야 합니다. 수…
면접관이 시스템 기획자에게 확인하는 것
시스템 기획자는 강화, 제작, 성장, 상점, 길드처럼 게임 안에서 반복적으로 돌아가는 규칙을 설계하는 직무입니다. 콘텐츠 기획이 '무엇을 경험하게 할지'에 가깝다면, 시스템 기획은 '그 경험이 어떤 규칙으로 돌아가는지'를 정합니다. 그래서 면접에서도 재미있는 아이디어보다 규칙의 일관성과 빈틈 없는 설계를 더 중요하게 봅니다.
면접관은 포트폴리오를 미리 읽고 들어오는 경우가 많습니다. 문서에 적힌 규칙 하나를 짚어 '이 경우에는 어떻게 되나요'라고 묻는 식으로 시작해, 설계를 얼마나 깊이 생각했는지 확인합니다. 따라서 면접 준비의 출발점은 내 포트폴리오의 모든 규칙에 대해 '왜'와 '만약'을 스스로 물어보는 것입니다.
포트폴리오 시스템에 대한 질문
가장 먼저 나오는 질문은 대개 '이 시스템을 왜 만들었나요', '이 시스템이 게임 전체에서 어떤 역할을 하나요'입니다. 답변 방향은 유저에게 어떤 행동을 유도하려 했는지, 그것이 게임의 다른 시스템과 어떻게 연결되는지를 설명하는 것입니다. 예를 들어 제작 시스템을 설계했다면, 사냥으로 얻은 재료가 제작으로 소비되고 제작한 장비가 다시 사냥 효율을 높이는 순환 구조를 그려 보이며 설명할 수 있습니다.
'다른 게임의 비슷한 시스템과 무엇이 다른가요'라는 질문도 자주 나옵니다. 참고한 게임이 있다면 숨기지 말고, 무엇을 가져왔고 무엇을 바꿨는지, 바꾼 이유가 무엇인지를 말하는 것이 좋습니다. 완전히 새로운 것을 만들었다고 주장하기보다, 기존 구조의 문제를 발견하고 개선한 과정을 보여 주는 편이 설득력 있습니다.
'이 시스템에서 가장 고민했던 결정은 무엇인가요'라는 질문도 준비해 두세요. 강화 실패 시 재료를 잃게 할지 말지, 제작 시간을 즉시 완료로 할지 대기 시간을 둘지처럼 두 선택지 사이에서 고민한 지점을 하나 골라, 각각의 장단점과 최종 선택의 이유를 말할 수 있으면 좋습니다. 이 질문에 대한 답은 설계 능력을 가장 직접적으로 보여 주는 장면이 됩니다.
예외 처리와 데이터 구조에 대한 질문
시스템 기획자 면접의 핵심은 예외 상황 질문입니다. '강화 중에 접속이 끊기면 어떻게 되나요', '인벤토리가 가득 찬 상태에서 보상을 받으면요', '같은 아이템을 두 사람이 동시에 사면요' 같은 질문이 대표적입니다. 이런 질문은 정답을 맞히는 것보다 예외를 다루는 사고방식을 보려는 것입니다.
답변 방향은 유저가 손해를 보지 않는 쪽, 악용될 여지가 없는 쪽, 구현이 지나치게 복잡하지 않은 쪽 사이에서 어떤 기준으로 판단하는지 말하는 것입니다. 문서에 이미 정리해 둔 예외라면 그 내용을, 생각해 보지 못한 상황이라면 그 자리에서 기준을 세워 답하고 '문서에 보완하겠다'고 덧붙이면 됩니다. 답하기 전에 잠깐 생각할 시간을 갖는 것은 전혀 문제가 되지 않습니다.
데이터 구조 질문도 나올 수 있습니다. '이 시스템의 데이터 테이블은 어떻게 구성했나요', '아이템 정보와 강화 정보를 한 테이블에 넣었나요, 나눴나요'처럼 묻습니다. 테이블을 나눈 기준, 각 칸이 무엇을 뜻하는지, 기획자가 수치를 바꿀 때 어디만 고치면 되는지를 설명할 수 있어야 합니다. 스프레드시트로 정리한 데이터 시트를 포트폴리오에 함께 넣어 두면 이 질문에 훨씬 구체적으로 답할 수 있습니다.
협업과 문서 작성에 대한 질문
- 개발자가 문서를 보고 다르게 구현했다면 어떻게 하겠나요?
- 구현이 어렵다는 의견을 받으면 어떻게 대응하나요?
- 문서를 쓸 때 가장 신경 쓰는 점은 무엇인가요?
- 기획 의도와 다른 플레이가 나왔을 때 어떻게 하나요?
이 질문들은 시스템 기획자가 혼자 일하지 않는다는 점을 확인하려는 것입니다. 답변 방향은 문서의 모호한 부분을 내 책임으로 보고 고치는 태도, 구현 난이도를 들으면 핵심 의도를 지키는 선에서 대안을 찾는 태도를 보여 주는 것입니다. 실제 팀 프로젝트에서 순서도나 상태 다이어그램으로 문서를 보완했던 경험이 있다면 구체적으로 말하세요.
피해야 할 답변
| 피해야 할 답 | 왜 문제인지 |
|---|---|
| 그 부분은 개발자가 알아서 할 거예요 | 예외 처리를 기획자 몫으로 보지 않는다는 인상 |
| 재미있을 것 같아서 넣었어요 | 설계 근거 없이 감으로 만든다는 신호 |
| 완전히 새로운 시스템입니다 | 참고와 개선의 과정을 숨기는 것처럼 보임 |
| 수치는 대충 정했어요 | 밸런스와 데이터에 대한 이해 부족 |
모르는 질문에 아는 척하는 것도 피해야 합니다. 시스템 기획 면접은 꼬리 질문이 길게 이어지는 경우가 많아, 아는 척한 답은 두세 번째 질문에서 드러납니다. 모르는 부분은 인정하고 어떤 기준으로 판단해 보겠다고 말하는 편이 훨씬 낫습니다.
면접 전에 해 둘 준비
포트폴리오의 시스템마다 예상 예외 상황을 열 개 정도 스스로 뽑아 답을 정리해 두세요. 순서도를 손으로 다시 그려 보면 문서에서 빠진 분기가 보이기도 합니다. 지원 회사의 게임을 플레이하며 시스템 하나를 골라 구조를 분석해 두면, '우리 게임에서 개선하고 싶은 점'을 물을 때 구체적으로 답할 수 있습니다.
내 포트폴리오의 시스템 문서가 면접의 꼬리 질문을 버틸 만큼 탄탄한지 혼자 판단하기는 쉽지 않습니다. SBS아카데미게임학원 게임기획 과정 상담에서는 지금 가진 시스템 문서를 놓고 예외 처리와 데이터 구조에서 보완할 부분을 함께 짚을 수 있습니다.
자주 묻는 질문
시스템 기획자 면접에서 코딩 질문도 나오나요?
회사마다 다르지만, 직접 코딩을 요구하기보다 구현 원리를 이해하는지 묻는 경우가 많습니다. 조건문이나 데이터 테이블 구조를 설명할 수 있으면 대화에 도움이 됩니다.
포트폴리오에 시스템 문서가 하나뿐이어도 괜찮을까요?
하나라도 규칙, 예외, 데이터까지 깊이 있게 정리되어 있다면 충분히 대화가 가능합니다. 문서 수보다 깊이가 중요합니다.
가까운 캠퍼스에서 게임기획 알아보기
사는 곳과 가까운 캠퍼스를 고르면 수업 내용, 오시는 길, 상담 신청을 한 번에 볼 수 있습니다.