
게임은 사람이 동시에 즐기는 경우가 많아 서버와 네트워크 지식도 중요합니다. 과정 후반에는 여러 명이 접속하는 간단한 멀티플레이 기능을 구현해 보며 클라이언트…
면접관은 왜 모를 법한 질문을 던질까
게임 프로그래머 기술 면접에서는 일부러 지원자의 수준보다 조금 어려운 질문을 섞는 경우가 많습니다. 어디까지 알고 있는지 경계선을 찾기 위해서입니다. 그래서 질문이 점점 깊어지다가 결국 모르는 지점에 닿는 것은 자연스러운 흐름입니다. 모르는 질문이 나왔다는 것 자체가 실패를 뜻하지 않습니다.
실무에서 프로그래머는 매일 처음 보는 문제를 만납니다. 엔진의 낯선 기능, 특정 기기에서만 생기는 버그, 문서가 부족한 라이브러리 같은 것들입니다. 면접관이 모르는 질문으로 확인하려는 것은 이런 상황에서의 태도입니다. 모르는 것을 인정하고, 아는 것에서 출발해 가설을 세우고, 확인할 방법을 떠올리는 사람이 팀에 들어오면 안심이 됩니다.
모르는 질문에 답하는 네 단계
- 질문 다시 확인하기: 무엇을 묻는지 정확히 이해했는지 짧게 되묻기
- 아는 범위 밝히기: 정확히 모르는 부분과 알고 있는 관련 지식 구분하기
- 추론해 보기: 아는 원리에서 출발해 가능한 답을 소리 내어 생각하기
- 확인 방법 말하기: 실제 업무라면 어떻게 찾아보고 검증할지 제시하기
첫 단계는 생각보다 중요합니다. 질문을 잘못 이해해서 모른다고 느끼는 경우가 적지 않습니다. "말씀하신 것이 렌더링 쪽 메모리를 말씀하시는 건지, 게임 로직 쪽 객체 관리를 말씀하시는 건지 확인해도 될까요?"처럼 물어보면 시간을 벌면서 질문의 방향도 분명해집니다.
두 번째 단계에서는 "정확한 내부 구현은 모르지만, 이런 원리로 동작한다고 알고 있습니다"처럼 경계선을 긋습니다. 이렇게 말하면 면접관은 내가 어디까지 알고 있는지 정확히 파악하고, 다음 질문을 그 수준에 맞춰 조정할 수 있습니다.
추론 과정을 말로 보여 주는 예
예를 들어 "수많은 총알을 화면에 띄울 때 성능 문제를 어떻게 줄이나요?"라는 질문에 구체적인 기법 이름이 떠오르지 않는다고 해 봅시다. 이때 "잘 모르겠습니다"로 끝내기보다, 아는 것에서 출발해 생각을 풀어 갈 수 있습니다.
"총알을 계속 새로 만들고 지우면 메모리 할당과 해제가 반복되어 부담이 될 것 같습니다. 그렇다면 미리 만들어 두고 다시 쓰는 방식이 도움이 될 것 같고, 화면 밖으로 나간 총알은 계산에서 빼는 방법도 생각할 수 있습니다. 실제로 적용한다면 프로파일러로 어디서 시간이 많이 드는지 먼저 확인하겠습니다." 이런 식으로 말하면, 오브젝트 풀링이라는 이름을 몰라도 그 원리에 도달하는 사고 과정을 보여 줄 수 있습니다.
추론하다가 틀린 방향으로 갈 수도 있습니다. 괜찮습니다. 면접관이 힌트를 주면 받아들여 다시 생각을 이어 가면 됩니다. 힌트를 듣고 생각을 고치는 모습도 협업 능력으로 평가됩니다.
질문 유형별로 꺼낼 수 있는 출발점
모르는 질문이라도 대부분 아는 주제와 닿아 있습니다. 엔진 내부 동작을 묻는 질문이라면 내가 써 본 기능의 겉모습에서 출발해 "이렇게 동작하려면 내부에서 이런 처리가 필요할 것 같다"고 추론할 수 있습니다. 수학 질문이라면 벡터의 내적과 외적처럼 기본 개념으로 문제를 나눠 보는 식입니다.
네트워크나 서버처럼 경험이 적은 분야의 질문이라면, 경험이 없다는 사실을 먼저 밝히고 클라이언트 입장에서 겪어 본 현상으로 연결합니다. 예를 들어 지연 때문에 캐릭터 위치가 튀는 현상을 본 적이 있다면, 그 현상을 줄이려면 어떤 정보가 오가야 할지 생각을 풀어 볼 수 있습니다. 출발점이 분명하면 답이 완벽하지 않아도 대화가 이어집니다.
피해야 할 대응 세 가지
첫째, 긴 침묵입니다. 생각할 시간이 필요하다면 "잠시 생각해 봐도 될까요?"라고 말한 뒤 생각하면 됩니다. 아무 말 없이 오래 멈춰 있으면 면접관은 지원자가 포기했는지, 생각 중인지 알 수 없습니다. 생각하는 내용을 조금씩 말로 꺼내는 편이 훨씬 낫습니다.
둘째, 아는 척입니다. 들어 본 용어를 엮어 그럴듯하게 말하면 당장은 넘어간 것처럼 보일 수 있지만, 면접관은 대부분 꼬리 질문 한두 번으로 실제 이해도를 확인합니다. 틀린 내용을 자신 있게 말한 것이 드러나면 앞에서 잘 답한 내용까지 신뢰를 잃습니다.
셋째, 변명입니다. "그 부분은 수업에서 안 배웠습니다", "제 프로젝트에서는 쓸 일이 없었습니다"처럼 모르는 이유를 길게 설명하는 것은 도움이 되지 않습니다. 이유보다는 지금 아는 것과 앞으로 확인할 방법을 말하는 데 시간을 쓰세요.
면접 뒤에 할 일과 평소 대비법
면접이 끝나면 답하지 못한 질문을 바로 기록해 두세요. 기억이 흐려지기 전에 질문의 표현과 내가 한 답을 적고, 집에 돌아가 정확한 내용을 찾아봅니다. 같은 질문은 다른 회사 면접에서도 형태를 바꿔 나올 가능성이 큽니다. 이렇게 쌓인 질문 목록이 다음 면접의 가장 좋은 준비 자료가 됩니다.
평소에는 개념의 이름보다 원리를 설명하는 연습을 합니다. 자료구조, 메모리 관리, 게임 루프, 충돌 처리 같은 기본 주제를 친구에게 설명하듯 말로 풀어 보세요. 원리를 알고 있으면 처음 보는 질문도 그 원리에서 출발해 추론할 수 있습니다. 내가 만든 포트폴리오 게임의 코드도 다시 열어, 각 기능을 왜 그렇게 구현했는지 설명해 보는 연습이 효과적입니다.
기술 면접은 결국 대화입니다. 모르는 질문을 만나는 순간을 두려워하기보다, 생각을 보여 줄 기회로 받아들이면 답변이 훨씬 자연스러워집니다. 내 포트폴리오 코드 기준으로 어떤 꼬리 질문이 나올지 미리 점검하고 싶다면, SBS아카데미게임학원 언리얼엔진(Unreal) 과정 상담에서 프로젝트 구조를 설명하는 연습 방향을 함께 정할 수 있습니다.
자주 묻는 질문
모른다고 말하면 바로 떨어지지 않을까요?
한두 개를 모른다는 이유만으로 불합격하는 경우는 드뭅니다. 기본 개념 대부분을 모르는 것이 문제이고, 경계선을 정직하게 밝히는 태도는 오히려 긍정적으로 평가받습니다.
코딩 테스트 중에 막히면 어떻게 하나요?
완성하지 못하더라도 접근 방법과 시간 복잡도에 대한 생각을 주석이나 말로 남기세요. 부분 구현과 사고 과정을 함께 보는 경우가 많습니다.
가까운 캠퍼스에서 게임프로그래밍 알아보기
사는 곳과 가까운 캠퍼스를 고르면 수업 내용, 오시는 길, 상담 신청을 한 번에 볼 수 있습니다.