이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
게임 품질을 높이기 위해 중요하게 생각하는 테스트 방법은 실제 플레이어처럼 자유롭게 탐색하는 방식과 미리 시나리오를 정해두는 방식을 병행하는 것입니다. 시나리오 기반 테스트만 하면 예상치 못한 경로에서 생기는 버그를 놓치고, 탐색적 테스트만 하면 중요한 기능이 충분히 검증됐는지 확인하기 어렵습니다. 수업 게임 프로젝트에서 QA를 진행할 때, 플레이어가 일부러 비정상적인 행동을 했을 때 어떻게 반응하는지 확인하는 게 예상 외로 많은 버그를 발견하는 방법이었습니다. 빠르게 클릭하거나 뒤로 가기를 반복하거나 순서를 건너뛰는 시도가 충돌이나 데이터 꼬임을 드러냈습니다.
재현 조건을 구체적으로 기록하는 것이 수정 속도를 결정합니다. 버그 발생 상황을 모호하게 적으면 개발자가 재현하는 데 시간이 더 걸립니다. 좋은 버그 리포트가 좋은 테스트만큼 중요하다고 생각합니다.
게임 품질에서 제가 의식한 건 테스트를 단계로 나눠 거르는 것입니다. 개발 중 스모크 테스트 → 내부 알파 → 클로즈드 베타 → 오픈 베타로 가며, 단계마다 거르는 게 달랐습니다. 또 버그를 블로커·크리티컬·메이저·마이너로 분류해, 무엇을 먼저 잡을지 정했습니다. 출시 여부는 버그 수가 아니라, 블로커·크리티컬 0건과 핵심 지표(잔존율·세션 길이·결제 전환)를 기준으로 봤습니다.
버그 개수만 세면, 치명적인 하나를 놓쳤습니다. 그래서 단계와 우선순위로, 어디까지 됐을 때 내보낼지를 정했습니다. 막연히 '많이 테스트한다'가 아니라, 단계별 게이트가 핵심이었습니다.
게임 테스트에서 제가 어렵게 본 건 재현성이 낮은 버그입니다. 일반 소프트웨어와 달리, 비결정적 게임플레이라 같은 조작에도 다르게 동작하는 버그가 있었습니다. 한 번은 분명히 봤는데 다시 재현이 안 되는 버그에 막혔습니다. 또 레벨·아이템·대사 같은 콘텐츠 볼륨이 커, 다 검증하기 어려웠습니다. 그래서 재현 조건을 최대한 구체적으로 기록하고, 자주 쓰는 경로부터 우선 검증했습니다.
다 잡았다고 말하긴 어려웠고, 어디까지 봤는지를 정직하게 남겼습니다. 그래서 게임 QA는 완벽이 아니라, 위험이 큰 곳부터 거르는 일이었습니다. 재현 안 되는 버그가 가장 까다로웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 스마일게이트 프로덕트 매니저 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.