최근에는 AI 코딩 도구를 쓰는 개발자가 늘었지만, 생성된 코드가 맞는지 판단하려면 결국 기본기가 필요합니다. 수업에서는 직접 짜는 연습을 충분히 한 뒤 AI…
기획서를 받은 개발자가 가장 먼저 하는 일
기획서가 전달되면 개발자는 바로 코드를 쓰기보다 먼저 읽고 질문을 만듭니다. 기획서에는 기획자의 머릿속에서는 당연하지만 글로는 적히지 않은 부분이 늘 있기 때문입니다. 예를 들어 '인벤토리가 가득 차면 알림을 띄운다'는 문장만으로는 알림이 몇 초 동안 뜨는지, 다른 팝업과 겹치면 어떻게 되는지, 보상 우편은 받아지는지 알 수 없습니다.
- 예외 상황: 네트워크가 끊기거나 값이 0이 될 때 어떻게 되는가
- 우선순위: 일정이 부족하면 어떤 기능부터 넣을 것인가
- 수치 관리: 어떤 값을 데이터 테이블로 빼서 기획자가 조절할 것인가
- 기존 기능과의 관계: 이미 있는 시스템을 재사용할 수 있는가
- 연출: 애니메이션, 사운드, 이펙트가 언제 붙는가
이 질문을 빨리, 한꺼번에 정리해서 보내는 것이 좋은 개발자의 습관입니다. 구현 도중에 하나씩 묻다 보면 기획자도 개발자도 집중이 끊기고, 이미 짠 코드를 다시 고쳐야 하는 일이 생깁니다.
구현 범위와 일정은 함께 정합니다
기획서에 적힌 모든 내용을 정해진 일정 안에 넣기 어려운 경우가 많습니다. 이때 개발자는 '안 됩니다'로 끝내기보다 '이 부분은 이번에, 이 부분은 다음 업데이트에'처럼 나눠서 제안하는 편이 좋습니다. 기술적으로 어려운 부분이 있다면 비슷한 효과를 더 적은 비용으로 내는 대안을 함께 내놓으면 대화가 훨씬 생산적입니다.
기획자 입장에서는 개발자가 어떤 부분을 왜 오래 걸린다고 하는지 이해하는 것이 중요합니다. 화면에서는 버튼 하나 추가처럼 보여도, 서버와 데이터 구조를 함께 바꿔야 해서 시간이 오래 걸릴 수 있습니다. 서로 '왜'를 설명하는 습관이 있으면 일정 협의에서 감정이 상하는 일이 줄어듭니다. 합의한 범위는 회의 메모나 업무 관리 툴에 남겨 두어야 나중에 '그때 넣기로 하지 않았나요' 같은 혼선이 생기지 않습니다.
데이터 테이블은 두 직군의 공용 언어입니다
게임 속 수치와 문구는 대부분 코드에 직접 적지 않고 데이터 테이블로 관리합니다. 몬스터 체력, 아이템 가격, 스킬 쿨타임, 퀘스트 보상 같은 값을 스프레드시트 형태로 정리해 두면, 기획자가 코드 수정 없이 값을 바꿔 가며 밸런스를 조절할 수 있습니다.
그래서 클라이언트 개발자는 어떤 값을 테이블로 뺄지 기획자와 미리 합의합니다. 너무 적게 빼면 기획자가 작은 값 하나 바꾸려 해도 개발자에게 부탁해야 하고, 너무 많이 빼면 테이블이 복잡해져 실수가 늘어납니다. 칸 이름, 단위(초인지 밀리초인지), 비워 두면 어떤 값으로 처리하는지 같은 규칙을 정해 두면 이후의 혼란이 크게 줄어듭니다.
중간 빌드로 '느낌'을 맞추는 단계
기획서와 테이블로 전달되지 않는 것이 있습니다. 바로 손맛입니다. 캐릭터가 점프할 때의 높이와 속도, 버튼을 눌렀을 때의 반응 시간, 연출이 끝나는 타이밍은 직접 해 봐야 맞는지 알 수 있습니다. 그래서 개발자는 기능이 완성되기 전에 일부만 돌아가는 중간 빌드를 만들어 기획자에게 보여 줍니다.
- 핵심 동작만 넣은 간단한 빌드를 먼저 공유합니다.
- 기획자가 플레이해 보고 어색한 부분을 구체적으로 적어 줍니다.
- 수정할 값은 테이블로, 구조 변경은 개발자가 반영합니다.
- 연출과 UI를 붙인 뒤 다시 확인하고 마무리합니다.
이때 기획자의 피드백이 '좀 더 시원하게'처럼 막연하면 개발자는 무엇을 바꿔야 할지 모릅니다. 반대로 '공격 후 다음 입력을 받기까지가 길게 느껴진다'처럼 구체적이면 바로 원인을 찾을 수 있습니다. 개발자도 어떤 값을 조절하면 무엇이 바뀌는지 기획자에게 알려 주면, 기획자가 스스로 실험해 볼 수 있습니다.
QA와 버그를 사이에 두고 다시 만나는 두 직군
기능이 완성되어 QA로 넘어가면, 기획자와 개발자는 버그 리포트를 사이에 두고 다시 만나게 됩니다. 이때 자주 생기는 논쟁이 '이게 버그인가, 기획대로인가'입니다. QA가 이상하다고 올린 동작이 사실은 기획서에 그렇게 적혀 있었거나, 반대로 기획서에 아예 적혀 있지 않은 상황일 때가 많습니다.
이런 경우 개발자 혼자 판단해 고치기보다 기획자에게 의도를 확인하는 것이 순서입니다. 기획 의도와 다른 동작이라면 버그로 수정하고, 기획서에 빠진 상황이었다면 기획자가 기준을 정해 기획서에 추가합니다. 이 과정을 거치면 기획서가 점점 빈틈없어지고, 다음 기능에서는 같은 질문이 줄어듭니다. 개발자가 기획서의 빈틈을 발견했을 때 그냥 넘어가지 않고 알려 주는 것도 좋은 협업의 일부입니다.
자주 생기는 오해와 줄이는 방법
가장 흔한 오해는 기획서가 바뀌었는데 개발자가 몰랐던 경우입니다. 기획서를 수정할 때 변경 이력을 남기고 관련 개발자에게 알리는 규칙만 있어도 이런 문제는 대부분 사라집니다. 반대로 개발자가 구현하면서 임의로 동작을 바꾼 뒤 공유하지 않아 생기는 오해도 있습니다. 바꿀 이유가 생겼다면 바꾸기 전에 짧게라도 확인하는 것이 원칙입니다.
포트폴리오를 준비하는 학생이라면 팀 프로젝트에서 이런 협업을 직접 겪어 보는 것이 큰 도움이 됩니다. 기획 담당과 질문 목록을 주고받은 기록, 테이블 규칙을 정한 문서, 중간 빌드 피드백을 반영한 과정은 면접에서 협업 경험을 묻는 질문에 가장 좋은 답이 됩니다. 혼자 만든 게임만으로는 협업 이야기를 하기 어렵다고 느낀다면, SBS아카데미게임학원 유니티3D(Unity) 과정 상담에서 팀 단위 프로젝트 경험을 어떻게 쌓을 수 있을지 물어보세요.
자주 묻는 질문
클라이언트 개발자도 기획 회의에 들어가나요?
회사마다 다르지만 기능의 구현 가능성을 판단해야 하는 회의에는 참여하는 경우가 많습니다. 초기 단계에서 의견을 내면 나중의 큰 수정을 줄일 수 있습니다.
기획자가 코딩을 알면 협업이 더 쉬워지나요?
코드를 직접 짜지 않더라도 데이터 구조와 구현 비용을 이해하는 기획자는 개발자와 대화가 훨씬 수월합니다. 반대로 개발자도 기획 의도를 이해하려는 노력이 필요합니다.
가까운 캠퍼스에서 게임프로그래밍 알아보기
사는 곳과 가까운 캠퍼스를 고르면 수업 내용, 오시는 길, 상담 신청을 한 번에 볼 수 있습니다.