
처음 코딩을 배우면 문법은 이해했는데 막상 무엇을 만들어야 할지 막막해지는 시기가 옵니다. 수업에서는 이 시기를 짧게 넘기도록 작은 게임 하나를 정해 기능을 …
언어와 컴퓨터 기초에서 나오는 질문
- 포인터와 참조는 어떻게 다른가요?
- 가상 함수는 어떻게 동작하나요? 소멸자는 왜 가상으로 두나요?
- 스택 메모리와 힙 메모리의 차이는 무엇인가요?
- C#의 값 형식과 참조 형식, 가비지 컬렉션이 게임에 주는 영향은?
- 프로세스와 스레드는 어떻게 다른가요?
이런 질문에 답할 때는 정의를 한 문장으로 말한 뒤, 그것이 게임에서 어떤 문제와 이어지는지 덧붙이는 구조가 좋습니다. 예를 들어 가비지 컬렉션을 설명한 뒤, 매 프레임 새 객체를 많이 만들면 순간적인 끊김이 생길 수 있어서 재사용 구조를 썼다는 식으로 연결하는 것입니다.
피해야 할 답은 책의 문장을 그대로 외워 말하는 것입니다. 면접관이 꼬리 질문으로 조금만 깊게 들어가도 막히기 쉽습니다. 모르는 부분은 아는 범위까지만 말하고, 모르는 부분을 솔직히 인정하는 편이 신뢰를 얻습니다.
엔진과 게임 구조에 대한 질문
엔진을 쓰는 지원자에게는 그 엔진의 기본 구조를 묻습니다. 유니티라면 생명주기 함수의 호출 순서와 물리 갱신 함수의 차이, 언리얼이라면 액터와 컴포넌트의 관계, 블루프린트와 C++을 나누는 기준 같은 질문이 자주 나옵니다. 엔진 공통 질문으로는 게임 루프, 델타 타임, 충돌 처리 방식이 있습니다.
답변 방향은 사용 경험에서 출발하는 것입니다. 이 함수를 어디에 썼고, 다른 함수와 헷갈려서 어떤 버그가 생겼는지 말하면 이해 수준이 자연스럽게 드러납니다. 피해야 할 답은 써 봤다고만 하고 왜 그렇게 동작하는지는 설명하지 못하는 경우입니다.
최적화 질문도 자주 나옵니다. 프레임이 떨어지면 어디부터 확인하는지, 화면에 오브젝트가 많을 때 어떻게 관리하는지 같은 질문입니다. 막연히 최적화했다고 하기보다, 어떤 도구로 원인을 찾았고 무엇을 바꿨는지 순서대로 말하는 것이 좋습니다. 바꾼 뒤 얼마나 나아졌는지 확인한 방법까지 말하면 더 좋습니다.
포트폴리오에 대한 깊은 질문
면접에서 가장 오래 이어지는 부분은 내 프로젝트에 대한 질문입니다. 이 기능은 왜 이렇게 설계했는지, 다시 만든다면 무엇을 바꾸겠는지, 가장 어려웠던 버그는 무엇이었는지 같은 질문이 계속 꼬리를 뭅니다. 면접관은 이 대화를 통해 실제로 내가 만들었는지, 얼마나 깊이 고민했는지를 확인합니다.
준비할 때는 프로젝트마다 핵심 기능 두세 개를 골라 구조를 그림으로 그려 보고, 다른 방법과 비교해 왜 이 방법을 골랐는지 정리해 두세요. 아쉬운 점을 묻는 질문에는 변명보다 개선 방향을 구체적으로 말하는 것이 좋습니다. 피해야 할 답은 팀 프로젝트에서 남이 한 부분을 내가 한 것처럼 말하는 것입니다. 꼬리 질문에서 금방 드러납니다.
자주 나오는 꼬리 질문의 흐름도 알아 두면 좋습니다. 저장 기능을 만들었다고 하면 어떤 형식으로 저장했는지, 저장 도중 게임이 꺼지면 어떻게 되는지, 버전이 바뀌면 이전 저장 파일은 어떻게 읽는지로 이어지는 식입니다. 내 기능 하나를 놓고 스스로 세 단계쯤 꼬리 질문을 던져 보면 빈 곳이 보입니다.
협업과 태도를 보는 질문
- 기획자가 구현하기 어려운 요구를 하면 어떻게 하나요?
- 팀원과 의견이 달랐던 경험과 해결 과정은?
- 일정이 부족할 때 무엇부터 포기하나요?
- 최근에 새로 공부한 기술은 무엇인가요?
이 질문들은 정답보다 사고 방식을 봅니다. 기획 요구 질문이라면 바로 거절하거나 그대로 받아들이기보다, 구현 비용을 설명하고 대안을 제시하는 방향이 좋습니다. 실제 팀 프로젝트에서 비슷한 상황이 있었다면 그 이야기를 짧게 들려주세요.
피해야 할 답은 팀원을 탓하는 이야기입니다. 갈등 경험을 묻는 질문에서 상대의 잘못만 강조하면, 함께 일하기 어려운 사람이라는 인상을 남깁니다. 내가 무엇을 배웠고 다음에는 어떻게 하겠는지로 마무리하는 것이 좋습니다.
모르는 질문이 나왔을 때의 대처
아무리 준비해도 모르는 질문은 나옵니다. 이때 아는 척 꾸며 내는 것이 가장 나쁜 선택입니다. 정확히는 모르지만 이런 원리라면 이렇게 동작할 것 같다고 추론 과정을 말하거나, 직접 다뤄 보지는 않았지만 비슷한 이런 경험이 있다고 연결하는 편이 훨씬 낫습니다.
면접이 끝난 뒤에는 받은 질문을 모두 기록해 두세요. 답하지 못한 질문을 찾아 정리하면 다음 면접에서 같은 질문이 나왔을 때 오히려 강점이 됩니다. 면접을 여러 번 보며 질문 목록을 쌓는 것도 중요한 준비 과정입니다.
질문의 뜻이 헷갈릴 때는 다시 물어봐도 괜찮습니다. 질문을 내가 이해한 말로 바꿔 확인한 뒤 답하면, 엉뚱한 방향으로 길게 답하는 실수를 막을 수 있습니다. 답을 생각할 시간이 필요하다면 잠시 정리하겠다고 말하고 숨을 고르는 것도 자연스러운 태도입니다.
준비는 말로 해 보는 연습까지 해야 끝납니다
머릿속으로 아는 것과 소리 내어 설명하는 것은 다릅니다. 예상 질문에 대한 답을 실제로 말해 보고 녹음해 들어 보면, 설명이 길어지거나 핵심이 빠지는 부분이 바로 보입니다. 친구나 스터디원에게 면접관 역할을 부탁해 꼬리 질문을 받아 보는 연습도 큰 도움이 됩니다.
내 포트폴리오로 어떤 질문이 나올지, 답변 방향이 맞는지 점검받고 싶다면 SBS아카데미게임학원 게임프로그래밍 과정 상담에서 모의면접과 포트폴리오 질문 준비 방법을 함께 안내받을 수 있습니다.
자주 묻는 질문
면접에서 화이트보드나 종이에 코드를 쓰게 하나요?
회사에 따라 간단한 코드를 직접 쓰게 하는 경우가 있습니다. 문법보다 풀이 과정을 말로 설명하면서 쓰는 것이 중요합니다.
기술 면접과 인성 면접은 따로 보나요?
회사마다 다릅니다. 한 번에 함께 보는 곳도 있고 단계를 나누는 곳도 있으니, 안내 메일에서 면접 구성을 확인하세요.
면접 마지막에 질문하라고 하면 무엇을 물어볼까요?
팀이 쓰는 개발 도구, 신입이 처음 맡는 업무, 코드 리뷰 방식처럼 일에 대한 질문이 좋습니다.
가까운 캠퍼스에서 게임프로그래밍 알아보기
사는 곳과 가까운 캠퍼스를 고르면 수업 내용, 오시는 길, 상담 신청을 한 번에 볼 수 있습니다.