개념
멀티플레이 결함은 세 가지 조건에서 드러난다
싱글플레이 게임은 한 기기 안에서 모든 것이 결정된다. 멀티플레이는 여러 기기와 서버가 서로 다른 시점의 서로 다른 정보 를 가진 채 하나의 세계를 흉내 낸다. 그래서 사무실의 빠른 네트워크에서 두 명이 해 보면 멀쩡하던 기능이 세 가지 조건에서 무너진다.
| 조건 | 무엇이 깨지는가 | 이 레슨의 절 |
|---|---|---|
| 네트워크가 나쁠 때 | 순간이동, 맞았는데 안 맞음, 상태 어긋남 | 넷코드, 열화 시험 |
| 누군가 속일 때 | 속도·위치·재화·확률 조작 | 치트와 서버 검증 |
| 사람이 몰릴 때 | 로그인 실패, 매칭 지연, 서버 다운 | 동시접속 부하 |
권위는 누가 갖는가
권위(authority) 는 "진짜 상태를 누가 결정하는가"다. 이건 레슨 1에서 본 클라이언트·서버 메커닉의 구분과 같은 질문이다.
| 방식 | 진짜 상태 | 장점 | 위험 |
|---|---|---|---|
| 서버 권위 | 서버가 계산하고 클라이언트는 입력만 보냄 | 조작이 어렵다 | 지연만큼 반응이 늦어 보인다 |
| 클라이언트 권위 | 각 클라이언트가 계산해 결과를 보고 | 반응이 즉각적 | 조작된 결과를 서버가 그대로 믿는다 |
| 혼합 | 이동은 클라이언트, 피해·보상은 서버 등 | 절충 | 경계가 어디인지 모르면 구멍이 생긴다 |
QA가 가장 먼저 확인할 것은 중요한 결과가 어디서 결정되는가 다. 피해량, 사망 판정, 아이템 획득, 재화 증감, 확률 추첨은 서버에서 결정되어야 한다. 이걸 개발자에게 물어 표로 만들어 두는 것만으로 치트 시험의 범위가 정해진다.
예측, 보정, 보간 — 지연을 숨기는 기술
서버 권위 게임에서 버튼을 누를 때마다 서버 응답(예: 왕복 100ms)을 기다리면 조작이 끈적해진다. 그래서 세 가지 기술로 지연을 숨긴다.
[클라이언트 예측] 입력 즉시 내 화면에서 먼저 움직인다 (서버 응답 전)
[서버 보정] 서버의 확정 결과가 오면 내 예측과 비교해,
다르면 서버 쪽으로 위치를 고친다 (reconciliation)
[보간] 다른 플레이어는 받은 위치 두 개 사이를 부드럽게 이어 그린다
→ 그래서 다른 플레이어는 늘 약간 과거의 모습으로 보인다각 기술에는 고유한 결함 증상이 있다.
| 기술 | 결함 증상 | 테스트 관점 |
|---|---|---|
| 예측·보정 | 러버밴딩(앞으로 가다 뒤로 끌려감), 문 통과 후 되돌려짐 | 지연을 키우고 빠른 방향 전환·충돌 |
| 보간 | 다른 플레이어가 순간이동하거나 미끄러짐 | 패킷 손실·지터 추가 |
| 지연 보상 | 벽 뒤로 숨었는데 맞음 | 고지연 플레이어와 저지연 플레이어의 교전 |
지연 보상 — 누구의 시간 기준으로 맞았는가
슈팅 게임에서 내가 적을 조준해 쏜 순간, 내 화면의 적은 이미 과거 위치 다(보간 때문). 서버가 현재 위치로 판정하면 정확히 쏴도 빗나간다. 그래서 서버는 쏜 사람의 지연만큼 시간을 되감아 판정한다. 이게 지연 보상(lag compensation)이다.
지연 보상의 대가는 맞는 쪽의 불만이다. 벽 뒤로 이미 숨었는데, 고지연 상대의 화면에서는 아직 숨지 않았으므로 맞는다. QA는 이 트레이드오프가 기획이 정한 한도 안에 있는지 본다. 보통 되감기 최대 시간(예: 200ms)을 두는데, 그 한도를 넘는 지연의 플레이어에게는 보상이 적용되지 않아야 한다. 한도 값을 경계값으로 삼아 190ms·200ms·210ms 지연에서 판정을 비교하면 모듈 3의 경계값 분석이 네트워크 시험에 그대로 적용된다.
롤백 넷코드
격투 게임처럼 프레임 단위 정밀도가 필요한 장르는 롤백 넷코드 를 쓴다. 상대 입력이 아직 안 왔으면 "직전 입력을 유지했을 것"이라고 예측해 게임을 진행하고, 실제 입력이 도착해서 예측과 다르면 그 프레임으로 되돌아가(rollback) 다시 계산한 뒤 현재 프레임까지 빠르게 재실행한다.
롤백 방식이 성립하려면 게임 로직이 결정론적 이어야 한다. 같은 입력이면 모든 기기에서 정확히 같은 결과가 나와야 한다. 그래서 롤백 게임의 대표 결함은 동기화 어긋남(desync) 이다.
| desync 원인 | 예 |
|---|---|
| 부동소수점 차이 | 다른 CPU·컴파일러에서 계산 결과가 미세하게 다름 |
| 난수 시드 불일치 | 한쪽만 난수를 한 번 더 뽑음 |
| 상태 저장 누락 | 롤백 시 복원되지 않는 변수(이펙트 타이머 등)가 로직에 영향 |
| 프레임 의존 로직 | 렌더링 프레임 수에 따라 달라지는 계산 |
desync 시험은 두 기기의 매 프레임 상태 체크섬 을 비교하는 방식으로 한다. 개발 빌드에 체크섬 로그를 켜고, 서로 다른 플랫폼·CPU 조합으로 긴 매치를 반복한다. 체크섬이 처음 달라진 프레임 번호가 결함 리포트의 핵심 증거다.
지연·지터·패킷 손실 조건에서 시험한다
모듈 29에서 네트워크 열화를 만드는 방법(레슨 5의 리눅스 AP와 tc netem)과 열화 시험의 체크포인트(레슨 7)를 배웠다. 게임에서는 그 조건을 이렇게 구성한다.
| 프로파일 | 왕복 지연 | 지터 | 패킷 손실 | 대표 상황 |
|---|---|---|---|---|
| 기준 | 20ms | 2ms | 0% | 유선, 같은 지역 서버 |
| 일반 모바일 | 60ms | 15ms | 0.5% | LTE·5G 양호 |
| 나쁜 모바일 | 150ms | 50ms | 2% | 지하철, 혼잡 지역 |
| 원거리 | 250ms | 20ms | 0.5% | 해외 서버 접속 |
| 순간 단절 | 정상 → 3초 100% 손실 → 정상 | 터널, 와이파이 전환 |
프로파일마다 확인할 것은 정해져 있다.
- 러버밴딩·순간이동의 빈도와 크기가 허용 기준 안인가
- 스킬·피격·사망 판정이 양쪽 화면에서 같은 결과로 끝나는가
- 순간 단절 뒤 상태가 서버 기준으로 정확히 복구되는가(체력, 위치, 쿨타임, 인벤토리)
- 지연 표시(핑 아이콘)와 연결 불안정 안내가 뜨는가
- 결제·보상 지급 같은 중요 요청이 중복되거나 유실되지 않는가
마지막 항목이 특히 중요하다. 보상 수령 버튼을 누른 순간 연결이 끊기고 클라이언트가 재전송하면, 서버가 같은 요청을 두 번 처리 해 보상이 두 번 지급될 수 있다. 모든 재화 관련 요청에 요청 고유 번호를 붙여 중복을 거르는지(멱등성)가 시험 대상이다.
매치메이킹, 재접속, 호스트 이전
| 기능 | 확인 항목 |
|---|---|
| 매치메이킹 | 실력 구간·지역·지연 조건, 대기 시간이 길어질 때 조건 완화, 파티 인원 조합, 취소 직후 매칭 성사 경쟁 조건 |
| 재접속 | 매치 중 앱 종료·네트워크 단절 후 복귀, 재접속 허용 시간 경계, 그 사이 캐릭터 처리(AI 대체·자리 비움) |
| 호스트 이전 | P2P 방식에서 방장이 나갈 때 다른 참가자에게 권한 이전, 이전 중 발생한 입력·상태 처리 |
| 이탈 처리 | 탈주 페널티 적용 조건, 비정상 종료와 의도적 이탈의 구분 |
재접속 허용 시간이 3분이라면 2분 59초·3분·3분 1초가 경계값이다. 매칭 취소 버튼을 누른 순간 매칭이 성사되는 경쟁 조건 은 수동으로 재현하기 어려우므로, 매칭 서버의 테스트 모드나 자동화 클라이언트로 수백 번 반복한다.
치트와 서버 검증
치트 시험의 목표는 치트 프로그램을 만드는 것이 아니다. 서버가 클라이언트를 믿는 지점을 찾는 것 이다.
| 치트 유형 | 원리 | 서버 검증 시험 |
|---|---|---|
| 스피드핵 | 클라이언트 시간을 빠르게 해 이동·공격 속도 증가 | 서버가 이동 거리·공격 간격을 최대치와 비교해 거부하는가 |
| 메모리 변조 | 클라이언트 메모리의 체력·재화 값 수정 | 변조된 값이 서버 상태에 반영되지 않는가 |
| 패킷 변조 | 요청의 수량·아이템 ID·가격을 바꿔 전송 | 서버가 요청 값의 범위·권한·소유를 검증하는가 |
| 패킷 재전송 | 정상 보상 요청을 캡처해 반복 전송 | 같은 요청의 중복을 거부하는가 |
| 복제(dupe) | 거래·우편·창고 이동 중 연결 끊기·동시 요청 | 트랜잭션이 원자적으로 처리되는가 |
| 벽 투시·자동 조준 | 클라이언트에 있는 정보를 표시·이용 | 보이지 않는 적의 위치를 서버가 보내지 않는가 |
복제 결함은 대부분 두 작업이 동시에 일어나는 틈 에서 생긴다. 거래 확정 버튼을 두 기기에서 동시에 누르기, 아이템을 우편으로 보내는 순간 창고로 옮기기, 판매 요청 직후 연결을 끊고 재접속하기 같은 것들이다. 시험 뒤에는 로그로 재화 총량을 대조 한다. 시험 전후 두 계정의 재화 합이 늘었다면 복제다.
안티치트 솔루션(클라이언트 보호 모듈)을 쓰는 게임이라면, QA는 그 모듈이 정상 플레이어를 오탐하지 않는지 도 본다. 화면 녹화 프로그램, 오버레이, 접근성 도구, 에뮬레이터를 쓰는 정상 사용자가 차단되는지 확인해야 한다.
치트 시험은 권한과 격리 가 전제다. 반드시 테스트 서버에서, 허가된 테스트 계정으로, 사전에 승인된 범위만 수행한다. 라이브 서버에서 허가 없이 패킷을 변조하면 그 자체가 약관 위반이고 법적 문제가 될 수 있다.
동시접속 부하 — 로그인 대기열, 출시 첫날, 이벤트
모듈 16 레슨 2에서 부하·스트레스·스파이크·내구 테스트를 배웠다. 게임은 스파이크 가 극단적이다. 출시 첫날 오픈 시각, 대형 업데이트 직후, 한정 이벤트 시작 시각에 사용자가 몇 분 사이에 몰린다.
| 시나리오 | 부하 모양 | 확인할 것 |
|---|---|---|
| 출시·점검 종료 | 수 분 안에 평소 최대의 몇 배 접속 | 로그인 대기열 동작, 인증 서버 한계 |
| 이벤트 시작 | 정각에 특정 기능(보상 수령, 한정 상품)으로 집중 | 특정 API 병목, DB 잠금 |
| 대규모 전투 | 한 지역·한 서버에 수백 명 | 서버 틱 레이트 저하, 동기화 지연 |
| 장시간 운영 | 며칠간 지속 부하 | 메모리 누수, 세션 정리 |
로그인 대기열은 부하 상황의 안전장치 다. 서버가 감당할 수 있는 수만 입장시키고 나머지는 순번대로 기다리게 한다. 대기열 자체의 확인 항목이 따로 있다.
- 대기 순번과 예상 시간이 실제로 줄어드는가
- 대기 중 앱을 종료했다 다시 켜면 순번이 유지되는가(정책에 따라)
- 대기열 서버가 넘치면 어떻게 되는가
- 입장 직후 로딩에서 튕기면 다시 맨 뒤로 가는가
부하 테스트에는 실제 게임 클라이언트 대신 헤드리스 봇 클라이언트 를 쓴다. 로그인·캐릭터 선택·이동·전투·보상 수령을 프로토콜 수준에서 흉내 내는 봇을 수천~수만 개 띄워 서버 지표(응답 시간 백분위수, 오류율, CPU·메모리, DB 대기)를 본다. 봇 시나리오는 실제 플레이어 행동 비율을 텔레메트리에서 가져와야 현실적이다.
실무에서 왜 필요한가
사무실 네트워크는 플레이어의 네트워크가 아니다. 사내 테스트에서 한 번도 안 보이던 러버밴딩과 판정 불일치가 출시 첫 주 리뷰를 채운다. 열화 프로파일을 정해 두고 매 빌드 돌리는 것이 해법이다.
치트 한 건이 경제 전체를 무너뜨린다. 복제 결함이 라이브에서 악용되면 복구에 롤백·계정 제재·보상 공지가 필요하고, 정직한 플레이어의 신뢰까지 잃는다. 서버가 무엇을 믿는지 아는 QA가 이 위험을 출시 전에 줄인다.
출시 첫날의 장애는 되돌릴 수 없다. 첫날 접속 실패는 첫인상을 결정한다. 로그인 대기열과 스파이크 부하 시험은 서버팀만의 일이 아니라, 대기열 UX와 재시도 동작을 보는 QA의 일이기도 하다.
채용시장에서의 위치
온라인 게임사의 QA 공고에는 "네트워크·서버 테스트 경험", "부하 테스트 도구 사용 경험", "보안(치트) 테스트 이해"가 우대사항으로 자주 나온다. 대형사는 서버 QA나 보안 QA를 별도 파트로 두기도 한다. 기능 QA에서 출발해 이 영역으로 넓히면 기술 QA로 성장하는 경로가 열린다.
면접에서 강한 이야기는 "보상 수령 직후 연결을 끊고 재접속하면 보상이 두 번 지급되는 결함을 찾았고, 서버 로그로 재화 총량 증가를 증명해 요청 고유 번호 기반 중복 제거가 들어갔다" 처럼 원리(멱등성), 재현(네트워크 단절), 증거(로그)가 한 줄에 들어간 이야기다.