이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
게임의 초기 설계부터 완성까지 진행한 경험은 수업 팀 프로젝트에서 2D 플랫포머를 8주간 개발하고 발표한 것입니다. 기획 → 프로토타입 → 기능 개발 → 폴리싱 → 발표 순서로 진행하며 각 단계의 전환 기준을 팀 내에서 정의했습니다. 초기 기획에서 범위를 좁게 잡지 않아 중반에 기능을 컷해야 했던 경험이 스코핑의 중요성을 가르쳐 주었습니다. 개발 후반에는 버그 수정과 새 기능 추가 사이에서 우선순위를 정하는 것이 가장 어려운 의사결정이었습니다.
출시 전 플레이 테스트를 진행해 초기 사용자 반응을 수집하고 마지막 폴리싱에 반영했습니다. 전체 사이클을 경험한 것이 실무에서도 전체 그림을 보며 작업할 수 있는 기반이 되었다고 생각합니다.
팀 프로젝트 중반에 팀원 한 명이 개인 사정으로 이탈하면서 남은 팀이 범위를 줄여야 했던 경험이 있습니다. 처음 설계한 기능 목록의 절반 이상을 출시 전에 잘라내야 했고, 어떤 것을 남기고 어떤 것을 버릴지 결정하는 것이 기술 구현보다 더 어려운 작업이었습니다. 핵심 루프와 완성도 유지에 집중하고, 사이드 콘텐츠는 전부 후속 업데이트로 미뤘습니다. 결국 축소된 범위로 제출했는데, 평가에서 완성도가 높다는 피드백을 받아서 범위 조정이 나쁜 선택이 아니었다는 걸 확인했습니다. 개발 일정은 처음 설계한 대로 흘러가지 않는다는 것, 그리고 변화가 생겼을 때 무엇을 버릴지 결정하는 능력이 완성도를 지키는 방법이라는 걸 그 경험이 알려줬습니다.
완성하지 못한 기능이 있는 게임보다 완성된 작은 게임이 낫다는 걸 그날 몸으로 배웠습니다. 작은 범위에서 완성하는 경험이 다음 프로젝트의 설계 기준이 된다는 걸 그 경험이 알려줬습니다.
수업 팀 프로젝트를 발표한 뒤 교수님과 다른 팀의 피드백에서 설계 단계의 약점을 발견한 경험이 있습니다. 튜토리얼 없이 게임을 시작하는 구조가 개발팀 시선에서는 자연스럽지만, 처음 보는 사람에게는 진입 장벽이 된다는 피드백이 핵심이었습니다. 만드는 동안에는 보이지 않았던 것이 발표장에서 다른 사람의 플레이를 보면서 바로 보였습니다. 그 이후 프로젝트를 진행할 때마다 개발이 어느 정도 됐을 때 외부인에게 한 번 플레이시켜보는 루틴을 꼭 넣게 됐습니다.
개발자는 자기 게임을 너무 많이 알기 때문에 처음 보는 사람의 시선을 시뮬레이션할 수 없다는 걸 그 경험이 알려줬습니다. 런칭 후 회고는 다음 프로젝트의 설계 기준이 된다는 것도 배웠고, 지금은 발표 후 피드백을 다음 프로젝트 체크리스트로 변환하는 루틴이 있습니다.
런칭 후 회고를 문서로 남기는 루틴이 지금도 프로젝트마다 이어지고 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 이스트소프트 게임 클라이언트 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.