게임 QA는 무엇이 다른가 — 정답 없는 명세, 재미와 손맛, 거대한 상태 공간, 마일스톤

개념

명세에 정답이 없는 곳에서 품질을 판정한다

쇼핑몰의 장바구니를 테스트할 때는 판정 기준이 분명하다. "3만원 이상이면 무료배송"이라는 명세가 있고, 3만원짜리 주문의 배송비가 0원인지 확인하면 된다. 게임에도 이런 요구가 있다. "체력이 0이 되면 사망한다", "레벨 10이 되면 두 번째 스킬이 열린다" 같은 것들이다. 문제는 게임의 핵심 가치가 이런 요구에 있지 않다는 점이다.

표의 아래 네 줄이 게임 QA를 다르게 만든다. "타격감이 좋아야 한다"는 기대 결과를 한 줄로 적을 수 없다. 그렇다고 테스트할 수 없는 것은 아니다. 판정 기준을 대리 지표로 바꾸는 것 이 게임 QA의 첫 번째 기술이다. 타격감이라면 입력부터 피격 반응까지의 지연(프레임 수), 피격 시 화면 흔들림·히트스톱·사운드가 모두 나오는지, 경쟁작 대비 반응 시간이 얼마인지로 쪼갤 수 있다. "어렵지만 불공정하지 않다"는 사망 원인 로그에서 "회피 불가능한 공격으로 죽은 비율"로 바꿀 수 있다.

재미와 손맛은 누가 판정하는가

재미 자체의 판정은 기획자와 디렉터의 몫이다. QA가 "이 보스는 재미없다"고 결함을 등록하면 대개 반려된다. 그러나 QA는 재미를 깨뜨리는 원인 을 찾아 보고할 수 있고, 그건 분명한 결함이다.

• 공격 입력이 가끔 씹힌다(입력 버퍼 누락) — 손맛을 깨뜨린다
• 피격 판정 범위가 모델보다 넓어 닿지 않은 공격에 맞는다 — 불공정하게 느껴진다
• 특정 무기만 쓰면 모든 콘텐츠가 쉬워진다 — 선택의 재미가 사라진다
• 튜토리얼이 끝난 뒤 다음 목표를 알려주지 않는다 — 이탈로 이어진다

이 네 가지는 모두 "재미없다"는 감상이 아니라 재현 가능한 관찰이다. 레슨 2에서 이 관찰을 플레이 테스트 보고서와 밸런스 데이터로 만드는 법을 다룬다.

상태 공간이 사실상 무한하다

모듈 3에서 조건이 늘어나면 조합이 곱셈으로 늘어난다고 배웠다. 게임은 이 곱셈이 극단적이다. 오픈 월드 RPG 하나를 예로 들어 보자.

캐릭터 직업 6 × 레벨 구간 10 × 장비 조합 수천 × 퀘스트 진행 상태 수백
  × 위치(맵 좌표) 수백만 × 시간대·날씨 8 × 동료 NPC 조합 수십
  × 입력 타이밍(프레임 단위) × 네트워크 상태 × 플랫폼 5

이걸 전부 테스트할 수는 없다. 그래서 게임 QA는 세 가지를 조합한다.

1. 위험 기반 선택 — 진행 차단·결제·저장·멀티플레이처럼 실패 비용이 큰 곳에 집중한다
2. 탐색적 테스트 — 모듈 5의 차터로 "이 보스방에서 벽에 붙어 스킬을 쓰며 경계를 탐색한다" 같은 짧은 임무를 반복한다
3. 데이터와 자동화 — 봇이 맵을 돌며 끼임 지점을 찾거나, 시뮬레이션으로 수만 판의 전투 결과를 뽑는다

게임 현장에서 쓰는 테스트 유형

모듈 1에서 배운 테스트 유형이 게임 현장에서는 조금 다른 이름과 강조점으로 쓰인다. 공고와 테스트 계획서에서 자주 만나는 것들을 정리하면 이렇다.

표의 RC 는 릴리스 후보(Release Candidate)의 줄임말이다. "이대로 내보내도 될 것 같은 판" 을 뜻하고, 여기서 치명 결함이 나오면 다시 만들어 새 RC 를 낸다. | 호환성 테스트 | 기기·OS·GPU·해상도·컨트롤러 조합 | 베타 이후 | | 컴플라이언스 테스트 | 콘솔 인증·스토어 정책·등급·법규 요구 확인 | 베타·RC | | 회귀 테스트 | 수정이 다른 곳을 깨뜨리지 않았는지 | 매 수정·매 패치 | | 조합 테스트 | 직업×무기×스킬처럼 곱셈이 큰 영역을 페어와이즈로 축소 | 알파·베타 | | 플레이 테스트 | 대상 플레이어가 실제로 즐기는지, 어디서 막히는지 관찰 | 프로토타입부터 | | 첫 경험 테스트(FTUE) | 게임을 처음 보는 사람이 튜토리얼을 통과하는지 | 베타 전후 |

첫 경험 테스트에는 한 번도 게임을 본 적 없는 사람 이 필요하다. 매일 같은 빌드를 보는 QA는 튜토리얼의 빈틈을 이미 몸으로 알고 있어서 막히지 않는다. 그래서 FTUE 검증은 다른 팀이나 외부 인원을 불러 관찰하는 방식으로 운영하는 경우가 많다. 모듈 5의 탐색적 테스트가 "숙련자의 의도적 탐색"이라면, 첫 경험 테스트는 "초심자의 자연스러운 실수"를 모으는 일이다.

소크 테스트도 게임에서 유독 중요하다. 플레이어는 게임을 켠 채로 잠들고, 모바일 게임을 백그라운드에 며칠 둔다. 30분 테스트에서는 보이지 않던 결함, 예를 들어 파티클이 조금씩 쌓여 메모리가 늘거나 게임 내 시계가 누적 오차로 어긋나는 문제가 8시간째에 드러난다.

테스트하는 것과 그냥 플레이하는 것

게임 QA 지원자가 가장 많이 듣는 오해가 "게임하면서 돈 버는 직업"이다. 테스터도 게임을 플레이하지만, 플레이의 목적과 방식이 다르다.

"같은 보스를 조건만 바꿔 40번 잡는다"가 테스트의 전형이다. 첫 번째는 정상 공략, 두 번째는 피격 없이, 세 번째는 보스 패턴 전환 직전에 일시정지, 네 번째는 전환 순간 컷신 스킵, 다섯 번째는 파티원 한 명이 전환 순간 접속 종료… 이렇게 경계를 하나씩 건드린다.

게임 제품의 위험 목록

모듈 2에서 배운 위험 기반 테스트를 게임에 적용하면 위험 영역이 이렇게 정리된다.

이 표는 이 모듈의 레슨 순서와 거의 겹친다. 진행·경제는 레슨 2, 그래픽·사운드·조작·레벨은 레슨 3, 플랫폼 인증과 등급은 레슨 4, 멀티플레이는 레슨 5, 결제·확률은 레슨 6, 로컬라이제이션과 라이브 운영은 레슨 7이다.

게임 개발 파이프라인과 마일스톤

게임은 대체로 아래 마일스톤을 거친다. 회사마다 이름과 기준이 조금씩 다르지만 흐름은 비슷하다.

컨셉 → 프로토타입 → 버티컬 슬라이스 → 프로덕션 → 알파 → 베타 → 릴리스 후보(RC) → 골드 → 출시 → 라이브 서비스
                                                                          ↑
                                                              (콘솔: 인증 제출·통과)

QA에게 중요한 것은 각 마일스톤의 종료 기준(exit criteria) 이다. 예를 들어 베타 진입 기준이 "크래시·블로커 0건, A급 20건 이하, 전 구간 처음부터 끝까지 진행 가능"이라면 QA는 이 숫자를 매일 추적하고, 미달이면 마일스톤 판정 회의에서 근거와 함께 보고한다. 모듈 6에서 배운 결함 지표가 여기서 마일스톤 판정의 재료가 된다.

마일스톤이 뒤로 갈수록 변경의 위험 이 커진다. 알파에서는 시스템을 뜯어고쳐도 되지만, RC 이후의 수정은 한 줄이라도 전체 회귀와 인증 재점검을 부를 수 있다. 그래서 RC 단계에는 "이 결함을 고칠 것인가, 알려진 문제로 두고 데이원 패치로 넘길 것인가"를 판정하는 회의(흔히 버그 트리아지 또는 쇼 스토퍼 리뷰)가 매일 열리고, QA는 재현률·영향 범위·우회 방법을 들고 참석한다.

라이브 서비스 게임은 출시가 시작이다

패키지 게임은 골드가 끝이었지만, 온라인·모바일 게임은 출시가 시작이다. 매주 패치, 매달 이벤트, 분기마다 시즌이 나온다. 이때 QA의 일은 두 갈래로 나뉜다.

• 신규 콘텐츠 검증 — 새 캐릭터·던전·이벤트를 개발 QA처럼 검증
• 회귀와 운영 검증 — 기존 콘텐츠가 깨지지 않았는지, 서버 설정·이벤트 시간·보상 지급이 맞는지

라이브 게임에서 가장 큰 사고는 새 기능의 결함보다 운영 실수 에서 자주 나온다. 이벤트 종료 시각을 UTC로 넣어 9시간 일찍 끝나거나, 보상 수량 설정에 0을 하나 더 붙이는 식이다. 레슨 7에서 다룬다.

ISTQB CT-GaMe 실러버스와 이 모듈의 대응

ISTQB CT-GaMe(Certified Tester Game Testing) 실러버스 v1.0.1은 7개 장으로 되어 있다. 이 모듈은 그 범위를 모두 다루면서, 국내 실무에서 중요한 플랫폼 인증·등급분류·확률형 아이템 규제·라이브 운영을 추가한다.

2장의 용어는 이 모듈 전체에서 계속 쓰인다.

• 코어 루프 — 플레이어가 초 단위·분 단위로 반복하는 핵심 행동. 액션 RPG라면 "적을 만난다 → 싸운다 → 보상을 얻는다"
• 메타 루프 — 코어 루프 바깥에서 시간 단위·주 단위로 돌아가는 성장·수집·경제. "보상으로 장비를 강화한다 → 더 어려운 던전에 간다"
• 게임플레이 메커닉 — 전투·이동·점프·아이템 사용처럼 플레이 자체를 이루는 규칙
• 비게임플레이 메커닉 — 메뉴·설정·상점·우편함·친구 목록처럼 플레이를 둘러싼 기능. 일반 앱 테스트 기법이 그대로 통한다
• 클라이언트 메커닉 / 서버 메커닉 / 클라이언트-서버 메커닉 — 규칙이 어디서 계산되는가. 싱글플레이 점프는 클라이언트, 확률 추첨은 서버, 멀티플레이 전투는 둘 다다. 어디서 계산되는지가 곧 어디를 조작당할 수 있는지 와 어디서 어긋날 수 있는지 를 결정한다(레슨 5·6)

사례 — 베타 직전의 "의도된 사양"

가상의 액션 RPG에서 한 테스터가 "3장 보스가 너무 어렵다"는 결함을 올렸다. 기획은 "의도된 난이도"라며 반려했다. 테스터는 방식을 바꿨다. 사내 플레이 테스트 20명의 사망 로그를 모아 보니 3장 보스 사망의 62%가 "잡기 공격"에서 나왔고, 영상을 프레임 단위로 넘겨 보니 잡기 공격의 예고 모션이 6프레임(60fps 기준 0.1초)뿐이었다. 다른 보스의 예고 모션은 18~24프레임이었다. 결함을 "3장 보스 잡기 공격의 예고 모션이 다른 보스 대비 1/3 수준이라 회피가 사실상 불가능함(근거: 사망 로그 62%, 프레임 비교 영상)"으로 다시 올리자, 기획은 예고 모션을 18프레임으로 고치기로 했다. 난이도라는 판정 불가능한 문제가 프레임 수와 사망 비율 이라는 판정 가능한 문제로 바뀐 순간이다.

게임 QA 조직의 역할 분화

규모가 있는 게임사에서 QA는 한 팀이 아니다.

실무에서 왜 필요한가

판정 기준이 없으면 결함이 반려된다. 게임 QA가 가장 자주 겪는 좌절은 "이건 의도된 사양입니다"라는 반려다. 느낌으로 등록한 결함은 기획자의 느낌과 부딪힌다. 대리 지표(입력 지연 프레임, 사망 원인 비율, 승률)로 바꿔 등록하면 논쟁이 사실 확인으로 바뀐다.

마일스톤을 모르면 우선순위를 틀린다. 알파에서 텍스트 오탈자 100건을 등록하는 것과 RC에서 등록하는 것은 의미가 다르다. 알파에서는 시스템 결함에 집중하고, RC에서는 출시 차단 여부로 걸러야 한다. 지금이 어떤 마일스톤이고 종료 기준이 무엇인지 아는 테스터의 보고가 회의에서 채택된다.

상태 공간을 인정해야 전략이 생긴다. "다 해볼게요"는 게임에서 불가능한 약속이다. 위험 표로 집중할 곳을 정하고, 탐색적 차터로 넓히고, 자동화로 반복을 덜어 내야 한정된 인원과 기간으로 출시 품질을 설명할 수 있다.

클라이언트·서버 구분이 보안과 공정성을 가른다. 확률 추첨이나 재화 지급이 클라이언트에서 계산된다는 사실을 알아채는 것만으로도 치명적 결함 하나를 찾은 셈이다. 레슨 5와 6이 이 관점 위에 서 있다.

채용시장에서의 위치

게임 QA 공고의 자격요건에는 "게임에 대한 이해와 애정"이 거의 빠지지 않는다. 그러나 면접관이 실제로 확인하는 것은 애정이 아니라 게임을 테스트 대상으로 분해하는 능력 이다. 자주 나오는 질문은 "최근 플레이한 게임에서 발견한 버그와 재현 방법을 말해 보라", "이 게임의 코어 루프는 무엇이고 어디가 가장 위험하다고 보는가", "알파와 베타의 차이는 무엇인가"다.

좋은 답은 이 레슨의 구조를 따른다. 코어 루프와 메타 루프를 한 문장씩 말하고, 위험 표에서 가장 비싼 실패(진행·저장·결제)를 짚은 뒤, 그 위험을 어떤 테스트로 줄일지 말한다. 버그 경험을 말할 때는 "어떤 조건에서, 몇 번 중 몇 번, 어떤 증거로"를 붙인다. 외주 업체의 신입 포지션이라도 마일스톤 용어와 심각도 척도를 정확히 쓰는 지원자는 드물어서 눈에 띈다. ISTQB CT-GaMe 실러버스의 목차를 한 번 훑어 두면 이런 질문에 체계적으로 답할 수 있다.

실습 과제

과제 1 — 판정 불가능한 요구를 대리 지표로 바꾸기 (20분)

평소 즐기는 게임 하나를 골라 아래 세 요구를 각각 측정 가능한 대리 지표 2개 이상으로 바꾼다. 측정 방법(프레임 단위 녹화, 로그, 설문, 텔레메트리)도 함께 적는다.

① 조작감이 좋아야 한다
② 초반 30분이 지루하지 않아야 한다
③ 보스전이 어렵지만 불공정하지 않아야 한다

예를 들어 ①은 "입력부터 캐릭터 동작 시작까지 60fps 기준 4프레임 이하", "입력 버퍼 윈도우 안에서 입력 누락 0회(100회 시도)"로 바꿀 수 있다.

과제 2 — 코어 루프·메타 루프와 위험 표 (25분)

같은 게임의 코어 루프와 메타 루프를 각각 화살표로 그린다. 그리고 이 레슨의 위험 영역 표에서 해당 게임에 가장 중요한 영역 5개를 고르고, 각 영역마다 "실패하면 벌어지는 일"과 "대표 결함"을 그 게임의 구체적 요소로 채운다. 메커닉마다 클라이언트·서버·클라이언트-서버 중 어디서 계산될 것 같은지 추정해 적는다.

과제 3 — 마일스톤 종료 기준 초안 (20분)

가상의 모바일 RPG를 기준으로 알파·베타·RC 각각의 종료 기준을 3~5줄씩 작성한다. 결함 수 기준(심각도별), 진행 가능 여부, 성능 기준, 인증·심사 사전 점검 여부를 포함한다. 작성한 뒤 "이 기준을 누가, 어떤 데이터로 판정하는가"를 한 줄씩 덧붙인다.

자가 체크리스트

• 게임 QA가 일반 소프트웨어 테스트와 다른 이유 세 가지(판정 기준 부재, 재미와 손맛, 상태 공간)를 예를 들어 설명할 수 있다
• "재미없다"는 감상과 재미를 깨뜨리는 결함의 차이를 설명할 수 있다
• 판정이 불명확한 요구를 측정 가능한 대리 지표로 바꿀 수 있다
• 테스트와 그냥 플레이하는 것의 차이를 목적·경로·반복·기록으로 구분할 수 있다
• 게임 제품 위험 영역을 나열하고 각 영역의 대표 결함을 말할 수 있다
• 프로토타입·버티컬 슬라이스·알파·베타·RC·골드·라이브의 의미와 QA 초점을 설명할 수 있다
• 코어 루프·메타 루프, 게임플레이·비게임플레이 메커닉, 클라이언트·서버 메커닉을 구분할 수 있다
• ISTQB CT-GaMe의 7개 장을 말하고 이 모듈의 레슨에 대응시킬 수 있다

흔한 실수

• "재미없다"를 결함으로 등록한다. 재미의 판정은 기획의 몫이다. QA는 재미를 깨뜨리는 재현 가능한 원인을 보고한다.
• 게임을 잘하는 것과 테스트를 잘하는 것을 혼동한다. 고수는 위험한 길을 피한다. 테스터는 위험한 길을 일부러 간다.
• 모든 상태를 다 해보겠다고 약속한다. 상태 공간은 사실상 무한하다. 위험 기반 선택과 탐색적 차터, 자동화의 조합으로 범위를 설명해야 한다.
• 마일스톤을 무시하고 결함을 같은 무게로 등록한다. RC 단계에서 사소한 결함을 무더기로 올리면 정작 출시 차단 결함이 묻힌다.
• 비게임플레이 기능을 가볍게 본다. 상점·우편함·설정·계정 연동은 결제와 개인정보가 걸린 곳이다. 일반 앱 테스트 기법을 그대로 적용해야 한다.
• 계산이 어디서 일어나는지 묻지 않는다. 클라이언트에서 계산되는 보상과 확률은 조작의 표적이다. 메커닉마다 위치를 확인한다.
• 출시를 끝으로 생각한다. 라이브 서비스 게임의 사고는 출시 후 운영에서 더 많이 난다.

참고 자료

• ISTQB — Certified Tester Game Testing (CT-GaMe) — 실러버스 v1.0.1과 학습 목표
• ISTQB, Certified Tester Game Testing Syllabus v1.0.1 — 게임 테스트의 특수성·게임 메커닉·그래픽·사운드·컨트롤러·레벨·로컬라이제이션 7개 장
• Jesse Schell, The Art of Game Design: A Book of Lenses (CRC Press) — 코어 경험과 플레이 테스트 관점
• Charles P. Schultz, Robert Denton Bryant, Game Testing: All in One (Mercury Learning) — 게임 테스트 절차와 결함 보고
• 이 커리큘럼 모듈 5(탐색적 테스트)와 모듈 6(결함 관리) — 차터와 심각도·재현 절차의 기초