게임아카데미게임·웹툰·AI 진로 상담
QA의 핵심 결과물은 버그 리포트입니다. 어떤 상황에서, 어떤 순서로 했을 때, 무엇이 기대와 다르게 나왔는지 누구나 다시 재현할 수 있게 써야 합니다. 수업…
수동 테스트는 사람의 눈과 손으로 '이상함'을 잡아냅니다
수동 테스트는 테스터가 테스트 케이스를 따라 직접 조작하며 결과를 확인하는 방식입니다. 퀘스트가 끝까지 진행되는지, 상점에서 재화가 맞게 차감되는지, 특정 지형에서 캐릭터가 끼지 않는지를 손으로 확인합니다.
게임은 재미와 손맛을 다루는 소프트웨어라서 사람이 봐야만 알 수 있는 문제가 많습니다. 타격 이펙트가 반 박자 늦게 나오는 느낌, 튜토리얼 문구가 헷갈리는 순간, 보스 패턴이 지나치게 불공정하게 느껴지는 지점은 코드로 판정하기 어렵습니다. 이런 문제를 찾아 재현 순서까지 정리해 버그 리포트로 남기는 것이 수동 테스트의 핵심 역량입니다.
수동 테스트에는 정해진 케이스를 따라가는 방식과, 케이스 없이 자유롭게 부딪혀 보는 탐색 테스트가 함께 있습니다. 탐색 테스트에서는 '유저라면 여기서 이렇게 해 보지 않을까' 하는 상상력이 중요합니다. 인벤토리가 가득 찬 상태로 보상을 받거나, 로딩 중에 앱을 내렸다가 다시 여는 식의 예외 상황을 떠올리는 힘이 실력 차이를 만듭니다.
자동화 테스트는 반복을 기계에 맡겨 시간을 버는 방식입니다
자동화 테스트는 사람이 매번 하던 확인 작업을 스크립트로 만들어 자동으로 돌리는 방식입니다. 새 빌드가 나올 때마다 로그인, 메뉴 이동, 기본 전투 같은 핵심 흐름이 깨지지 않았는지 확인하는 회귀 테스트에 특히 많이 쓰입니다. 회귀 테스트란 수정 이후 기존 기능이 망가지지 않았는지 다시 점검하는 테스트를 말합니다.
자동화를 맡으려면 프로그래밍 기초가 필요합니다. 스크립트 언어로 테스트 시나리오를 작성하고, 실패했을 때 로그를 읽어 원인이 게임 버그인지 테스트 코드 문제인지 가려낼 수 있어야 합니다. 대신 한 번 잘 만들어 두면 밤사이 수많은 조합을 돌려 볼 수 있어 팀 전체의 검증 속도가 빨라집니다.
다만 자동화에도 관리 비용이 듭니다. 게임 화면이나 버튼 위치가 바뀌면 스크립트도 함께 고쳐야 하고, 테스트가 실패할 때마다 원인을 확인하는 시간이 필요합니다. 그래서 자동화 담당자는 '무엇을 자동화하지 않을지'를 판단하는 일도 함께 합니다.
같은 기준으로 놓고 보면 차이가 분명해집니다
| 기준 | 수동 테스트 | 자동화 테스트 |
|---|---|---|
| 주로 하는 일 | 플레이 확인, 사용성 점검, 버그 재현과 리포트 | 반복 시나리오 스크립트 작성, 결과 분석 |
| 필요한 역량 | 관찰력, 꼼꼼함, 문서 작성, 게임 이해 | 프로그래밍 기초, 로그 분석, 테스트 설계 |
| 강한 영역 | 새 콘텐츠, 연출, 밸런스 체감 | 자주 바뀌지 않는 핵심 흐름, 대량 조합 |
| 약한 영역 | 같은 확인을 수없이 반복하는 일 | 자주 바뀌는 화면, 느낌의 문제 |
| 진입 경로 | 신입 QA의 일반적인 출발점 | QA 경력 또는 개발 기초가 있는 사람 |
표에서 보듯 둘은 경쟁 관계가 아니라 역할 분담입니다. 실제 팀에서도 수동으로 꼼꼼히 확인한 항목 가운데 자주 반복되는 것을 골라 자동화로 옮기는 흐름이 일반적입니다.
실제 업데이트 일정 안에서 두 방식은 이렇게 섞입니다
라이브 게임의 업데이트를 예로 들어 보겠습니다. 새 던전이 추가되는 빌드가 나오면 QA 팀은 먼저 자동화로 로그인, 상점, 기존 콘텐츠 입장 같은 기본 흐름을 빠르게 확인합니다. 여기서 문제가 없으면 사람이 새 던전을 직접 돌며 몬스터 배치, 보상 지급, 연출 타이밍을 꼼꼼히 봅니다.
출시 직전에는 수정된 버그가 정말 고쳐졌는지 확인하는 작업이 몰립니다. 이때 수동 테스터는 수정 확인에 집중하고, 자동화는 다른 기능이 덩달아 깨지지 않았는지 넓게 훑습니다. 결국 사람이 깊게 보고 기계가 넓게 보는 구조라고 이해하면 쉽습니다.
처음부터 자동화만 노리면 생기는 빈틈
코딩을 조금 할 줄 안다고 해서 바로 자동화 QA로 가겠다는 계획은 빈틈이 생기기 쉽습니다. 무엇을 테스트해야 하는지 모르면 스크립트를 아무리 잘 짜도 의미 있는 검증이 되지 않기 때문입니다. 테스트 케이스를 설계하는 감각은 수동 테스트 경험에서 길러집니다.
반대로 수동 테스트만 오래 하면서 자동화 개념을 전혀 모르면 업무 폭이 좁아질 수 있습니다. 반복 작업 중 어떤 부분을 자동화하면 좋을지 제안할 수 있는 정도만 알아도 팀 안에서 평가가 달라집니다. 엑셀 함수로 테스트 결과를 정리하거나 간단한 스크립트로 로그를 걸러 보는 경험부터 쌓아도 충분한 출발입니다.
면접에서도 이 균형이 드러납니다. 자동화 도구 이름만 나열하기보다, 직접 테스트하다가 반복이 많아 불편했던 경험과 그것을 어떻게 줄이려 했는지를 설명하는 편이 설득력이 큽니다. 문제를 찾는 눈과 효율을 고민하는 태도를 함께 보여 주는 것이 핵심입니다.
이런 사람은 수동부터, 이런 사람은 자동화까지
- 게임을 오래 해 왔고 어색한 부분을 잘 찾아내는 사람: 수동 테스트로 시작해 버그 리포트 실력을 다지기
- 문서 정리와 커뮤니케이션에 자신 있는 사람: 수동 테스트 후 QA 리드나 기획 쪽으로 넓히기
- 프로그래밍 기초가 있고 반복 작업을 줄이는 데 흥미가 있는 사람: 수동 경험을 쌓으며 자동화 스크립트 연습 병행하기
- 개발자 진로도 열어 두고 싶은 사람: 자동화 QA를 개발 직무와의 연결 다리로 활용하기
어느 쪽이든 포트폴리오에는 직접 쓴 테스트 케이스와 버그 리포트가 들어가야 합니다. 자동화에 관심이 있다면 작은 테스트 스크립트와 그 결과 정리를 덧붙이면 방향성이 잘 드러납니다. 내 경험과 기초 실력으로 어디서 출발하는 게 맞을지 판단이 어렵다면, SBS아카데미게임학원 게임QA 과정 상담에서 테스트 케이스 작성부터 시작할지 함께 정할 수 있습니다.
자주 묻는 질문
자동화 테스트가 늘어나면 수동 QA 일자리가 사라지나요?
새 콘텐츠, 연출, 체감 밸런스처럼 사람이 판단해야 하는 영역은 계속 남습니다. 다만 단순 반복 확인만 하는 역할은 줄어들 수 있어 테스트 설계와 리포트 능력을 키우는 것이 중요합니다.
QA 지원 전에 어떤 프로그래밍 언어를 배워 두면 좋을까요?
회사마다 쓰는 도구가 달라 정답은 없습니다. 스크립트 언어 하나로 조건문, 반복문, 파일 읽기 정도를 다룰 수 있으면 자동화 개념을 이해하는 데 충분한 출발점이 됩니다.
모바일 게임과 PC 게임 QA는 테스트 방식이 다른가요?
모바일은 기종, 해상도, 통신 환경처럼 확인할 기기 조합이 많고, PC는 사양과 입력 장치 조합이 많습니다. 기본 원리는 같지만 테스트 환경 구성에서 차이가 납니다.
가까운 캠퍼스에서 게임 QA 알아보기
사는 곳과 가까운 캠퍼스를 고르면 수업 내용, 오시는 길, 상담 신청을 한 번에 볼 수 있습니다.