자동화 봇으로 스트레스 테스트와 이동 연산 QA를 설계하는 방법
자동화 봇으로 동시 접속·이동 명령을 재현해 서버 병목, 위치 불일치, 경로 탐색 지연을 찾는 방법을 정리합니다. 시나리오 설계, 핵심 지표, 판정 기준, 실패 로그 분석 절차까지 실무적으로 설명합니다.
자동화 봇 기반 스트레스 테스트는 사람이 반복하기 어려운 대규모 동시 이동 입력을 일정한 규칙으로 발생시켜 서버의 처리 한계와 동기화 오류를 찾는 방법이다. 필요한 봇 수는 대상 게임의 규모에 따라 달라진다. 핵심은 접속 수만 올리는 것이 아니라 실제 플레이에서 문제가 되는 이동 패턴과 판정 기준을 함께 정의하는 데 있다.
자동화 봇 스트레스 테스트가 필요한 이유
서버 권위형 게임에서는 이동 처리의 한 예로 입력 수신, 이동 검증, 위치 갱신, 관심 영역(AOI) 전파, 클라이언트 보정이 이어질 수 있다. 실제 순서와 책임은 네트워크 구조에 따라 다르다. 이동을 발생시키지 않는 접속 부하 테스트는 이동 처리 중에만 나타나는 CPU 부하, 패킷 증가, 위치 불일치를 재현하지 못할 수 있다.
특히 다음 조건이 겹치면 이동 연산 QA가 필요하다.
- 좁은 지역에 많은 플레이어가 몰리는 보스전, 대기실, 거점 전투
- NavMesh 또는 A* 경로 탐색을 서버에서 수행하는 구조
- 서버 권위형 위치 검증과 클라이언트 예측 이동을 함께 사용하는 구조
- 텔레포트, 넉백, 대시처럼 일반 이동과 다른 보정 규칙이 있는 구조
| 검증 대상 | 단순 접속 테스트 | 자동화 봇 이동 테스트 |
|---|---|---|
| 로그인·세션 처리량 | 확인 가능 | 확인 가능 |
| 이동 패킷 처리량 | 제한적 | 집중 검증 |
| AOI 브로드캐스트 폭증 | 놓치기 쉬움 | 재현 가능 |
| 위치 보정·롤백 | 확인 어려움 | 판정 가능 |
| 경로 탐색 병목 | 확인 어려움 | 시나리오별 측정 가능 |
이동 연산 QA에서 무엇을 측정해야 할까?
이동 테스트의 성공 여부는 평균값 하나로 판단하면 안 된다. 평균 응답 시간이 안정적이어도 일부 봇이 멈추거나 위치가 틀어지면 라이브 장애로 이어질 수 있다.
지표와 프로젝트별 예시 판정 기준
| 지표 | 정의 | 예시 판정 기준 |
|---|---|---|
| 동시 활성 봇 수 | 실제 이동 중인 봇 수 | 목표 CCU와 동일하거나 그 이상 |
| 이동 처리 지연 | 서버가 입력을 받은 시각부터 해당 입력의 권위 좌표를 확정한 시각까지 (같은 서버 시계 기준) | 예시: p95 200ms 이하 |
| 틱 처리 시간 | 서버 한 틱에 사용한 시간 | 예시: 20Hz 서버라면 p99 50ms 미만 |
| 위치 오차 | 서버 좌표와 예상 좌표의 거리 | 예시: 0.5 게임 단위 이하 또는 게임 규칙 기준 |
| 이동 명령 실패율 | 거절·타임아웃·예외 비율 | 0.1% 이하 |
| AOI 전송량 | 봇당 초당 송신·수신 바이트를 각각 측정 | 증가 추세와 상한 관찰 |
위치 오차는 다음처럼 계산할 수 있다. 2D 게임에서는 실제 플레이 평면에 사용하는 두 좌표축만 계산한다. 예를 들어 XZ 평면을 사용하는 경우 y축 항을 제외한다.
여기서 x_s, y_s, z_s는 서버가 확정한 좌표이고 x_e, y_e, z_e는 같은 틱에서 기대한 좌표다. 기대 좌표는 테스트 봇이 보낸 입력을 그대로 누적한 값이 아니라 충돌·속도 제한·상태 이상을 반영한 검증 모델로 계산해야 한다.
표의 수치는 판정 기준을 정하는 방법을 보여주는 예시이며, 모든 게임에 맞는 성능 목표나 업계 표준은 아니다. 테스트 목적과 실제 이용자 경험에 맞춰 조정해야 한다.
자동화 봇 시나리오는 어떻게 설계할까?
1. 실제 플레이를 행동 단위로 분해한다
먼저 로그, 기획 데이터, 라이브 지표에서 자주 발생하는 이동 행동을 고른다. 예를 들어 로비 집결, 퀘스트 NPC 왕복, 필드 몬스터 추적, 보스 회피, 지역 경계 통과는 서로 다른 부하를 만들 수 있다.
각 행동에는 시작 조건, 이동 방식, 종료 조건, 실패 판정을 명시한다.
| 시나리오 | 봇 행동 | 주로 찾는 문제 |
|---|---|---|
| 군집 회전 | 동일 지점에서 원형 이동 | 충돌 처리와 AOI 패킷 폭증 |
| 목적지 왕복 | 두 좌표 사이 반복 이동 | 누수, 누적 지연, 경로 캐시 오류 |
| 랜덤 워크 | 시드 기반 난수로 목적지 선택 | 예외 경로와 재현성 |
| 지역 경계 통과 | 셀·채널 경계를 반복 통과 | 엔티티 소유권 전환 실패 |
| 급격한 입력 전환 | 정지·대시·방향 전환 반복 | 속도 검증 및 보정 오류 |
그림의 봇 수, 지연 시간, CPU와 네트워크 수치는 설명을 위한 가상 예시이며 실제 측정 결과가 아닙니다.
2. 재현 가능한 입력과 시드를 사용한다
난수 목적지를 쓰더라도 테스트 실행마다 같은 결과를 재현할 수 있어야 한다. 봇 ID와 실행 번호로 고정 시드를 만들면 같은 런타임·실행 조건에서 특정 실패를 다시 조사할 수 있다. .NET의 HashCode.Combine은 프로세스별 임의 시드를 사용하므로 재현용 시드 생성에는 적합하지 않다.
uint hash = 2166136261;
unchecked
{
foreach (byte value in System.Text.Encoding.UTF8.GetBytes(testRunId))
hash = (hash ^ value) * 16777619;
hash = (hash ^ (uint)botId) * 16777619;
}
var random = new System.Random(unchecked((int)hash));
var target = new Vector3(
random.Next(minX, maxX),
0,
random.Next(minZ, maxZ)
);
await bot.MoveToAsync(target, cancellationToken);이 코드는 testRunId, botId, 좌표 범위, cancellationToken과 bot.MoveToAsync를 호출할 봇 객체가 미리 준비되어 있다고 가정한 C# 조각이다. Unity를 사용한다면 UnityEngine.Vector3, 서버 애플리케이션이라면 해당 프로젝트의 벡터 타입과 입력 API에 맞춰야 한다. 각 Random.Next(min, max) 범위는 최솟값을 포함하고 최댓값을 제외하며, 최솟값은 최댓값보다 작아야 한다.
위 코드는 목적지 선택 예시일 뿐이다. 실제 봇은 서버가 요구하는 입력 프로토콜에 맞춰 sequence 번호, 클라이언트 시각, 이동 상태를 함께 전송해야 한다. sequence 번호가 빠지면 패킷 재정렬이나 중복 처리 결함을 검증하기 어렵다.
3. 부하를 계단식으로 올리고 안정화 구간을 둔다
처음부터 목표 동시 접속 수를 투입하면 어느 지점에서 문제가 시작됐는지 알기 어렵다. 예를 들어 100봇 단위로 증가시키며, 각 단계에서 시스템에 맞는 시간 동안 안정화한 뒤 지표를 기록할 수 있다.
flowchart TD
A[기준 환경 준비] --> B[100봇 접속 및 이동]
B --> C{지표 기준 충족?}
C -- 예 --> D[봇 수 증가]
D --> B
C -- 아니오 --> E[로그·트레이스 수집]
E --> F[원인 분석 및 수정]
F --> A증가 폭은 시스템 특성에 맞춘다. 20Hz 서버에서 봇 1,000개가 초당 20개의 이동 입력을 보내면 입력만 초당 20,000건이다. 여기에 주변 엔티티 위치 전파가 더해지므로 봇 수 외에 초당 명령 수와 평균 관심 대상 수를 함께 기록해야 한다.
위치 불일치는 왜 발생하는가?
위치 불일치는 보통 하나의 버그가 아니라 시간 기준과 상태 전환이 어긋난 결과다. 다음 순서로 원인을 좁히면 조사 비용을 줄일 수 있다.
- 서버 로그에서 봇 ID, 이동 sequence, 수신 시각, 처리 틱, 확정 좌표를 연결한다.
- 클라이언트 또는 봇 로그에서 같은 sequence의 전송 시각과 예상 좌표를 확인한다.
- 충돌 판정, 속도 제한, 넉백·텔레포트 같은 상태 변경 이벤트가 그 사이에 있었는지 확인한다.
대표적인 원인은 다음과 같다.
- 클라이언트 시각과 서버 틱 기준을 혼용해 보간 기준이 달라진 경우
- 패킷 유실 후 재전송된 이전 sequence를 최신 입력처럼 처리한 경우
- 지역 경계에서 이전 월드의 좌표를 새 월드에 적용한 경우
- 경로 탐색 결과가 갱신된 장애물 데이터를 반영하지 못한 경우
- 부동소수점 누적 오차를 허용 범위 없이 직접 비교한 경우
좌표 비교는 완전 일치 대신 게임 단위에 맞는 허용 오차를 둔다. 다만 허용 오차를 넓혀 실패를 숨기지 않도록 오차 초과 횟수와 최대 오차도 별도로 기록해야 한다.
실패 로그는 어떤 형태로 남겨야 할까?
실패 이벤트 하나만 저장하면 원인 재현이 어렵다. 최소한 테스트 실행 ID, 봇 ID, 맵 ID, 서버 틱, sequence, 이전·예상·실제 좌표, 이동 상태, 오류 코드를 구조화해 남긴다.
{
"testRunId": "move-soak-2026-08-09-01",
"botId": 418,
"mapId": "field_03",
"serverTick": 934820,
"sequence": 16271,
"previousPosition": [120.0, 0.0, 88.5],
"expectedPosition": [124.0, 0.0, 88.5],
"actualPosition": [121.2, 0.0, 88.5],
"positionError": 2.8,
"movementState": "Dash",
"result": "PositionToleranceExceeded"
}위 JSON은 필드 형식과 오차 계산을 보여주는 가상 예시이며, 실제 테스트에서 수집한 로그가 아니다.
또한 실패 직전 입력 이력과 서버 성능 샘플을 일정한 시간 범위로 묶어 보관하는 방안을 검토할 수 있다. 예를 들어 5~10초 구간부터 시험하되 저장 비용과 장애 분석에 필요한 맥락을 함께 평가한다. 이 정보는 좌표 계산 오류와 틱 지연에 따른 연쇄 실패를 구분하는 데 도움이 될 수 있다.
자주 묻는 질문 (FAQ)
봇 수는 목표 CCU와 같으면 충분한가?
아니다. 목표 CCU는 기준일 뿐이다. 혼잡 지역에서 동시에 이동하는 비율, 봇당 이동 명령 빈도, AOI 내 평균 엔티티 수를 반영해 더 높은 피크 부하를 별도로 시험해야 한다.
이동 테스트에서 p95만 보면 되는가?
아니다. p95만으로는 지연 분포의 긴 꼬리를 놓칠 수 있으므로 p99 등 높은 백분위수도 함께 볼 수 있다. 최대값, 오류율, 위치 오차 분포를 같이 확인하되, 어느 지표를 운영 목표로 쓸지는 서비스의 사용자 여정과 표본 규모에 따라 정한다.
실제 클라이언트 대신 프로토콜 봇을 써도 되는가?
프로토콜 봇은 서버 이동 검증과 대규모 부하 시험에 유용할 수 있다. 다만 프레임 드롭, 애니메이션 상태, 클라이언트 예측 보정처럼 화면과 클라이언트 로직에 의존하는 문제는 실제 클라이언트 기반 테스트를 병행해야 한다.
정리
자동화 봇 이동 QA의 목표는 많은 봇을 접속시키는 데 있지 않다. 실제 플레이를 대표하는 이동 시나리오를 재현하고 서버 틱·이동 지연·위치 오차·AOI 전송량을 같은 실행 ID로 추적하는 데 있다. 계단식 부하 증가와 재현 가능한 시드는 테스트 결과를 분석하고 수정할 결함을 찾는 데 도움이 된다.
