서버 내부를 리팩토링한 뒤 로그인부터 요청·응답까지 기존 동작이 유지되는지 CI에서 확인하려 합니다. 더미 클라이언트는 무엇을 검증해야 하며 부하 테스트와는 어떻게 다른가요?

부하 도구는 처리량과 지연을 측정하는 목적이 크고, 더미 클라이언트 기반 통합 테스트는 실제 프로토콜과 상태 전이가 이전 계약을 유지하는지 확인하는 데 쓸 수 있습니다. 많은 접속을 만든다는 공통점은 있지만 성공 기준은 다릅니다.

로그인·캐릭터 생성·이동·전투·재접속을 일정한 시나리오로 실행하고 서버 응답과 최종 상태의 불변식을 검사하겠습니다. 단순히 연결이 끊기지 않았다는 것보다 중복 보상이나 세션 유실이 없는지가 중요합니다. 테스트 데이터와 난수 시드, 시간 의존성을 통제해 실패를 재현할 수 있게 해야 합니다.

실제 클라이언트와 프로토콜 구현을 일부 공유하면 편하지만 같은 버그를 양쪽이 함께 갖고 통과할 수 있습니다. 중요한 직렬화와 경계 조건은 독립적인 계약 테스트도 두겠습니다. CI에서는 짧고 결정적인 핵심 시나리오를 먼저 실행하고 긴 부하·장애 테스트를 별도 단계로 나눌 수 있습니다. 리팩토링 전후 성능뿐 아니라 관찰 가능한 행동이 유지되는지를 기준으로 검증하겠습니다.

외부 계약과 상태를 함께 검사합니다

더미 클라이언트는 서버 내부 객체를 직접 읽지 않고 실제 연결·직렬화·인증 흐름을 사용해야 합니다. 로그인 응답의 토큰을 다음 요청에 넣고, 중복 요청·잘못된 인증·재접속·패킷 지연을 실행합니다. 최종 상태만 비교하면 두 번 지급한 뒤 한 번의 값만 남기는 오류를 놓칠 수 있으므로, 이벤트 ID·보상 원장·세션 버전과 필수 응답 필드를 함께 검사합니다. 메시지 순서가 계약이 아니면 집합이나 상태 조건으로 기대값을 쓰고, 순서가 중요한 이벤트만 순서 목록으로 고정합니다.

CI 범위와 부하 범위를 나눕니다

매 커밋에서는 난수 시드·시간·초기 월드를 고정한 짧은 로그인-행동-재접속 시나리오를 실행합니다. 서버와 클라이언트가 같은 직렬화 코드를 공유하면 같은 버그가 함께 통과할 수 있으므로 경계 패킷은 독립 구현이나 스키마 기반 계약 테스트를 추가합니다. 별도 부하 시험은 운영과 비슷한 데이터 분포·캐시 적중률·세션 지속 시간·요청 비율을 사용해 TPS와 p99를 측정합니다. 통합 실패가 나면 최초로 계약이 어긋난 요청과 그 앞의 최소 상태를 추출해 재현하고, 불안정한 테스트를 재시도 횟수로 숨기지 않겠습니다.

구체적인 경계 사례

예를 들어 보상 요청을 서버에 보낸 뒤 응답만 버리고 같은 요청 ID로 재접속해 다시 보냅니다. 두 번 모두 응답을 받는지보다 권리 원장이 한 건이고 잔액 증가가 정확히 한 번인지를 확인합니다. 네트워크 단절 직전 서버가 커밋했는지 모르는 상황을 이 방식으로 의도적으로 만듭니다. 테스트마다 고유 계정·방·이벤트 영역을 사용해 병렬 CI 간 데이터 충돌도 막겠습니다.

실패 시에는 비밀 토큰을 제외한 패킷 종류·순번·서버 버전·초기 상태·난수 시드를 보존합니다. 일정 시간 안에 상태 조건이 충족되기를 기다리되 고정 sleep으로 성공을 가정하지 않습니다. 재연결이나 시간 경계에 문제가 있으면 이벤트 수를 줄여도 실패가 남는 최소 시나리오를 회귀 테스트로 고정하겠습니다.