기획자는 코딩을 어디까지 알아야 할까?

이 글과 연결된 과정게임기획 과정 알아보기

기획서는 길게 쓴다고 좋은 문서가 아닙니다. 프로그래머가 읽고 질문 없이 구현할 수 있고, 그래픽 팀이 필요한 리소스 목록을 바로 뽑을 수 있어야 합니다. 수…

코드를 몰라도 되지만 구조는 알아야 하는 이유

기획서는 결국 프로그래머가 읽고 코드로 옮기는 문서입니다. 예를 들어 '공격하면 가끔 치명타가 터진다'라고만 쓰면 구현할 수 없습니다. 치명타 확률은 어디에 저장되는지, 확률은 공격할 때마다 새로 계산되는지, 버프가 겹치면 어떻게 합쳐지는지까지 정해야 합니다. 이런 질문을 스스로 떠올리려면 프로그램이 어떻게 판단하고 계산하는지 알아야 합니다.

구조를 모르는 기획자의 문서는 '알아서 잘 만들어 주세요'가 됩니다. 그러면 프로그래머가 빈칸을 추측으로 채우고, 결과물이 의도와 달라져 다시 만드는 일이 생깁니다. 반대로 예외 상황까지 정리된 문서는 질문이 적고 일정도 지켜집니다. 코딩 지식은 결국 문서의 빈틈을 줄이는 도구입니다.

기획자가 꼭 알아야 할 프로그래밍 개념

언어 문법보다 개념이 먼저입니다. 아래 개념을 '내 기획서에서 이 부분이 여기에 해당하는구나' 하고 연결할 수 있으면 실무 대화에 큰 어려움이 없습니다.

• 변수와 데이터 타입: 체력, 이름, 보유 여부처럼 값의 종류를 구분하는 법
• 조건문: '만약 체력이 0 이하면 사망 처리'처럼 상황에 따라 다르게 동작하는 규칙
• 반복과 타이머: 일정 시간마다 회복되거나 매 프레임 확인되는 처리
• 상태(State): 대기, 이동, 공격, 피격처럼 캐릭터가 지금 어떤 모드인지
• 데이터 테이블과 ID: 아이템·몬스터를 번호로 관리하고 표에서 값을 읽어 오는 방식
• 클라이언트와 서버: 어떤 판정을 내 기기에서 하고 어떤 판정을 서버가 하는지

특히 상태와 데이터 테이블은 기획자가 매일 다루는 개념입니다. 상태가 바뀌는 조건을 그림으로 그려 문서에 넣으면 프로그래머가 훨씬 빠르게 이해합니다.

분야별로 필요한 수준은 이렇게 다릅니다

시스템 기획자는 규칙과 공식을 설계하므로 조건과 데이터 구조를 가장 깊이 이해해야 합니다. 테이블 사이의 관계를 설계하는 일도 맡기 때문에 데이터베이스의 기본 개념을 알면 유리합니다.

레벨 디자이너는 엔진 안에서 직접 작업하는 시간이 깁니다. 그래서 언리얼의 블루프린트처럼 노드를 연결해 동작을 만드는 비주얼 스크립팅을 다룰 줄 알면 문을 열거나 함정을 작동시키는 장치를 직접 만들어 볼 수 있습니다. 밸런스 기획자는 코드보다 엑셀 함수와 수식이 주 무기이고, 시나리오 담당은 대사 출력 조건과 분기 정도를 이해하면 됩니다.

회사 규모도 변수입니다. 인원이 적은 팀에서는 기획자가 간단한 스크립트 수정이나 데이터 반영을 직접 맡는 일이 있습니다. 큰 회사는 역할이 잘게 나뉘어 있어 코드를 만질 일이 적은 대신, 여러 프로그래머와 동시에 일하므로 정확한 용어로 소통하는 능력이 더 중요해집니다. 지원할 회사의 규모와 공고 문구를 보고 준비의 무게를 조절하면 됩니다.

직접 만들어 보면 좋은 작은 연습

개념은 책으로 읽기보다 손으로 만들어 볼 때 오래 남습니다. 거창한 게임을 만들 필요는 없고, 기획 문서에 자주 나오는 기능 하나를 엔진에서 따라 만들어 보는 정도면 충분합니다.

1. 엔진 튜토리얼로 캐릭터를 움직이고 점프시키는 기본 프로젝트 만들기
2. 체력 변수와 피격 처리를 넣어 0이 되면 재시작되게 만들기
3. 아이템 값을 엑셀 표로 정리하고, 그 표의 값을 바꿔 결과가 달라지는지 확인하기
4. 만든 기능을 기획서로 거꾸로 정리해 보며 빠진 예외를 찾아보기

마지막 단계가 핵심입니다. 직접 만들어 본 기능을 문서로 옮기면 '이건 미리 정해 줘야 했구나' 하는 지점이 보입니다. 이 경험이 쌓이면 처음부터 빈틈 없는 기획서를 쓰는 감각이 생깁니다.

코딩 공부에 빠져 기획을 놓치는 경우

기획 지망생 중에는 코딩이 필요하다는 말을 듣고 프로그래밍 언어 강의부터 길게 듣는 경우가 있습니다. 문법을 익히는 데 몇 달을 쓰고 나면 정작 포트폴리오에 넣을 기획서가 한 편도 없는 상황이 생깁니다. 기획 직무 면접에서는 코드 실력보다 기획 문서의 논리와 완성도를 먼저 봅니다.

균형을 잡으려면 '기획서를 쓰다가 막히는 부분만 찾아 공부한다'는 원칙이 좋습니다. 문서에 상태 전환을 그리다 막히면 상태 개념을 찾아보고, 보상 구조를 정리하다 막히면 테이블 설계를 찾아보는 식입니다. 이렇게 하면 공부한 내용이 바로 문서 품질로 이어집니다. 또 모르는 용어가 나오면 그 자리에서 프로그래머 지인이나 커뮤니티에 물어보는 습관도 도움이 됩니다. 질문하는 과정 자체가 실무에서 하게 될 대화의 연습이 되기 때문입니다.

프로토타입을 직접 만들 줄 알면 생기는 장점

필수는 아니지만, 간단한 프로토타입을 스스로 만들 수 있는 기획자는 아이디어를 말이 아닌 플레이로 보여 줄 수 있습니다. 회의에서 '이렇게 하면 재미있을 것 같다'고 설득하는 대신 직접 해 보게 하면 판단이 훨씬 빨라집니다. 포트폴리오에서도 문서와 함께 짧은 플레이 영상을 넣으면 기획 의도가 선명하게 전달됩니다. 완성도가 낮아도 괜찮습니다. 핵심 규칙 하나가 제대로 동작하는지 보여 주는 것만으로도 충분한 의미가 있습니다.

결국 기획자에게 코딩은 목표가 아니라 소통과 검증을 돕는 수단입니다. 지금 내 수준에서 어디까지 공부하면 될지, 기획서와 프로토타입을 어떤 비율로 준비할지 정하기 어렵다면, SBS아카데미게임학원 게임기획 과정 상담에서 Unity로 기능을 구현해 보는 단계까지 포함한 준비 순서를 함께 짜 볼 수 있습니다.

자주 묻는 질문

가까운 캠퍼스에서 게임기획 알아보기

사는 곳과 가까운 캠퍼스를 고르면 수업 내용, 오시는 길, 상담 신청을 한 번에 볼 수 있습니다.

함께 읽으면 좋은 글