처음 코딩을 배우면 문법은 이해했는데 막상 무엇을 만들어야 할지 막막해지는 시기가 옵니다. 수업에서는 이 시기를 짧게 넘기도록 작은 게임 하나를 정해 기능을 …
개발자는 자기 게임을 객관적으로 볼 수 없다
게임을 만든 사람은 조작법도, 숨겨 둔 길도, 보스의 약점도 모두 알고 있습니다. 그래서 개발자에게는 자연스러운 흐름이 처음 하는 사람에게는 전혀 보이지 않는 경우가 많습니다. 점프 버튼이 무엇인지, 다음에 어디로 가야 하는지, 왜 체력이 줄었는지를 개발자는 생각할 필요조차 없지만, 처음 하는 사람은 그 지점에서 멈춥니다.
플레이 테스트는 이 차이를 드러내는 가장 직접적인 방법입니다. 개발 중간중간 다른 사람의 눈으로 게임을 확인하면, 출시 직전에야 큰 문제를 발견하는 일을 막을 수 있습니다. 또한 '이 정도면 재미있겠지'라는 개발자의 추측을 실제 행동으로 검증해 볼 수 있습니다. 핵심 놀이가 실제로 손에 붙는지는 직접 해 보는 사람의 반응을 봐야 알 수 있습니다. 테스트는 한 번에 끝나는 행사가 아니라 개발 주기 안에 반복해서 넣는 일정입니다. 마일스톤마다 짧게라도 한 번씩 진행하면, 문제가 작을 때 발견해 적은 비용으로 고칠 수 있습니다.
테스트 전에 확인할 질문부터 정한다
막연히 '해 보고 의견 주세요'라고 하면 돌아오는 답도 막연합니다. 테스트를 준비할 때는 이번에 꼭 알아내고 싶은 질문을 두세 개로 좁혀 적어 둡니다. 질문이 정해져야 무엇을 관찰하고 무엇을 물어볼지도 정해집니다.
- 튜토리얼 없이 기본 조작을 스스로 알아내는가?
- 첫 번째 보스 앞에서 몇 번 정도 실패하고, 실패 이유를 이해하는가?
- 두 번째 스테이지로 가는 길을 헤매지 않고 찾는가?
- 게임 오버 뒤에 다시 하기를 누르는가, 아니면 그만두는가?
질문은 개발 단계에 따라 달라집니다. 초기 프로토타입이라면 핵심 놀이가 재미있는지, 중반이라면 난이도와 길 찾기가 적절한지, 출시 직전이라면 버그와 불편한 UI가 없는지를 주로 확인합니다. 단계에 맞지 않는 질문을 하면 지금 고칠 수 없는 의견만 잔뜩 모입니다.
테스터 모집과 준비
테스터는 개발에 참여하지 않았고, 게임에 대해 미리 들은 것이 없는 사람이 좋습니다. 가능하면 만들고 있는 게임 장르를 즐기는 사람과 그렇지 않은 사람을 섞으면 다양한 반응을 볼 수 있습니다. 친한 친구나 가족만으로 테스트하면 미안한 마음에 좋은 말만 해 주는 경향이 있으니, 같은 과정의 다른 팀이나 게임 동아리처럼 조금 거리가 있는 사람에게 부탁해 보세요.
빌드는 테스트 중에 멈추지 않을 정도로 안정되어 있어야 합니다. 알고 있는 큰 버그가 있다면 미리 고치거나, 그 구간을 건너뛰게 만들어 둡니다. 화면 녹화 프로그램을 준비하고, 가능하면 테스터의 손과 표정을 함께 볼 수 있게 자리를 배치합니다. 테스트 시간과 끝나고 물어볼 질문지도 미리 정해 두면 진행이 매끄럽습니다.
테스트를 진행할 역할도 나눠 두면 좋습니다. 팀이라면 한 사람은 테스터 옆에서 안내와 인터뷰를 맡고, 다른 사람은 조금 떨어진 곳에서 화면을 보며 기록만 합니다. 안내하는 사람이 기록까지 하려고 하면 테스터의 반응을 놓치기 쉽고, 기록하는 사람이 자꾸 말을 걸면 테스트가 흐트러집니다. 혼자 개발한다면 녹화를 최대한 활용하고, 테스트가 끝난 직후 기억이 생생할 때 영상과 함께 메모를 정리합니다.
진행 중에는 말없이 관찰하고 기록한다
플레이 테스트에서 개발자가 가장 하기 어려운 일은 가만히 있는 것입니다. 테스터가 길을 헤매면 '오른쪽이에요'라고 말해 주고 싶어집니다. 하지만 그 순간 말해 주면, 실제 플레이어가 혼자 헤맬 때 어떤 일이 벌어지는지 알 기회가 사라집니다. 시작할 때 '게임이 어려운 게 아니라 게임을 시험하는 자리이니 편하게 해 달라'고 안내하고, 이후로는 도움을 최소화합니다.
테스터에게 플레이하면서 떠오르는 생각을 소리 내어 말해 달라고 부탁하면 관찰이 훨씬 쉬워집니다. '저 문은 열리는 건가?', '왜 죽었지?' 같은 혼잣말이 곧 문제 지점입니다. 기록할 때는 의견보다 사실을 적습니다. '조작이 불편해 보임'보다 '점프 키를 찾느라 몇 번 다른 키를 눌러 봄'처럼 실제 행동을 적어 두면, 나중에 원인을 찾기 쉽습니다. 녹화 영상의 몇 분 지점인지 함께 적어 두면 다시 확인할 때 편합니다.
인터뷰와 결과 정리
플레이가 끝나면 짧게 인터뷰를 합니다. 이때 '보스전 재미있었죠?'처럼 답이 정해진 질문은 피합니다. 대신 '가장 기억에 남는 순간은 언제였나요?', '그만두고 싶었던 순간이 있었나요?', '친구에게 이 게임을 설명한다면 뭐라고 하겠어요?'처럼 열린 질문을 던집니다. 마지막 질문의 답이 내가 정한 핵심 재미와 비슷하다면 방향이 맞게 가고 있다는 신호입니다.
- 모든 테스터의 기록을 한곳에 모읍니다.
- 같은 지점에서 여러 사람이 막힌 문제를 묶어 위로 올립니다.
- 문제마다 원인이 무엇인지 팀이 함께 추측하고, 해결 방법을 정합니다.
- 고친 빌드를 다른 테스터에게 다시 시험해 효과를 확인합니다.
테스터가 제안한 해결책을 그대로 따를 필요는 없습니다. '보스가 너무 세다'는 말 뒤에는 공격 패턴을 읽기 어렵다는 진짜 원인이 숨어 있을 수 있습니다. 의견은 문제의 신호로 받아들이고, 해결책은 개발자가 원인을 보고 정하는 것이 좋습니다. 테스트에서 나온 문제를 버그와 설계 문제로 나눠 체계적으로 정리하는 법이 궁금하다면, SBS아카데미게임학원 게임QA 과정 상담에서 지금까지 모은 테스트 기록을 펼쳐 놓고 분류 기준부터 같이 세워 드릴 수 있습니다.
자주 묻는 질문
테스터는 몇 명 정도가 적당한가요?
많을수록 좋지만, 작은 프로젝트라면 몇 명만으로도 반복되는 큰 문제는 대부분 드러납니다. 한 번에 많이 모으기보다 고친 뒤 새로운 사람으로 다시 테스트하는 편이 효과적입니다.
온라인으로 빌드를 보내 테스트해도 되나요?
가능합니다. 다만 관찰이 어려우니 화면 녹화를 함께 부탁하거나, 영상 통화로 화면을 공유하며 진행하면 직접 보는 것에 가까운 정보를 얻을 수 있습니다.
가까운 캠퍼스에서 게임프로그래밍 알아보기
사는 곳과 가까운 캠퍼스를 고르면 수업 내용, 오시는 길, 상담 신청을 한 번에 볼 수 있습니다.