[모아이는내려찍고싶다] 8. 벤치마크: 서버와 AI를 숫자로 검증하기
MoaiWannaSlam 개발기 시리즈
7편까지는 게임을 만드는 과정에서 만난 문제들을 클라이언트, 서버, AI, 모바일 트러블슈팅으로 나눠 정리했습니다.
그런데 실제로 서비스를 굴리려면 한 가지 질문이 더 남습니다.
이 구조가 어느 정도까지 버티는지 어떻게 알 수 있을까?
플레이테스트는 중요하지만, 사람 몇 명이 직접 눌러보는 것만으로는 서버 상태를 알기 어렵습니다. 매칭이 느린지, WebSocket 연결이 불안한지, 결과 저장이 막히는지, 인증 쪽이 먼저 터지는지 구분하기 어렵습니다.
그래서 별도의 벤치마크 도구를 만들었습니다. 이 글은 그 도구를 만들면서 서버와 AI를 어떻게 숫자로 확인했는지에 대한 기록입니다.
벤치마크는 서버 개발의 디버그 모드였다
게임 클라이언트에 충돌 기즈모와 컨트롤 모드가 있었다면, 서버에는 벤치마크가 필요했습니다.
멀티플레이 서버는 눈으로 바로 보이지 않습니다. 플레이어가 "매칭이 안 돼요"라고 말해도 원인은 여러 개일 수 있습니다.
- WebSocket 연결이 실패했는가
- 연결은 됐지만 WELCOME을 못 받았는가
- 매칭 큐에서 방을 못 찾았는가
- 방은 만들어졌지만 게임플레이가 시작되지 않았는가
- 결과 저장에서 막혔는가
- 인증 요청이 먼저 제한에 걸렸는가
이걸 한 번에 "서버가 느리다"로 묶으면 원인을 못 찾습니다. 그래서 벤치마크의 목표는 서버를 괴롭히는 것 자체가 아니라, 어느 단계에서 실패하는지 분리해서 보는 것이었습니다.
테스트를 시나리오로 나눴다
벤치마크 도구에는 여러 프리셋을 만들었습니다.
프리셋을 나눈 이유는 단순합니다. 한 번에 모든 흐름을 테스트하면 어디가 문제인지 흐려집니다.
| 프리셋 | 보고 싶었던 것 |
|---|---|
| 순수 매치 큐 성능 테스트 | WebSocket 연결과 매칭 큐 자체가 버티는지 |
| 실제 서비스 근접 테스트 | 실제 플레이 흐름에 가까운 조건에서 어느 단계가 느려지는지 |
| Auth 병목 테스트 | 신규 게스트/익명 유저 생성이 먼저 막히는지 |
| 홀수 유저 매칭 테스트 | 짝이 안 맞을 때 대기/매칭 처리가 안정적인지 |
| 봇 fallback 테스트 | 상대가 없을 때 봇 대전으로 자연스럽게 넘어갈 수 있는지 |
| 결과 저장 테스트 | 경기 종료 이후 저장 흐름이 안정적인지 |
저는 여기서 Auth 병목 테스트가 특히 중요했다고 봅니다. 겉으로는 "매칭이 안 된다"처럼 보였지만, 실제 원인은 WebSocket 연결이나 전투 서버가 아니라 신규 게스트 인증 요청이 먼저 제한에 걸리는 문제였습니다. 그래서 서버 판정 흐름과 별도로, 테스트 시나리오를 나눠서 확인해야 했습니다.
지표는 단계별로 봤다
벤치마크에서 본 지표는 "성공/실패" 하나가 아니었습니다.
- CONN%: WebSocket 연결 성공률
- WELCOME%: HELLO 이후 WELCOME을 받은 비율
- MATCH%: MATCH_FOUND를 받은 비율
- MATCH P95: 매칭 완료까지 걸린 시간의 95번째 백분위. 전체 매칭 중 95%가 이 시간 안에 끝났고, 나머지 느린 5%가 그보다 오래 걸렸다는 뜻입니다.
- RESULT%: 결과 저장 성공률
- SNAP/S: 초당 수신한 스냅샷 수
- RTT P50/P95/P99: 왕복 지연 시간 분포
- 끊김: 테스트 중 연결이 끊긴 수
- 클라이언트/방/오류: 생성된 클라이언트, 방, 에러 수
중요한 것은 평균만 보지 않는 것이었습니다. 평균이 괜찮아도 P95나 P99가 튀면 실제 플레이어 일부는 이미 불편함을 느낍니다. 특히 1v1 실시간 게임에서는 느린 꼬리 지연이 손맛을 바로 망칩니다.
성공한 테스트와 실패한 테스트를 같이 남겼다
성공한 결과만 남기면 보기에는 좋지만, 문제를 해결한 기록이 되지는 않습니다.
위 결과는 사용자 10, 30, 50 조건에서 연결과 매칭, 결과 저장이 100%로 통과한 케이스입니다. RTT도 낮게 유지됐고, 오류도 없었습니다.
하지만 다른 시나리오에서는 결과가 완전히 달랐습니다.
이 화면이 더 중요했습니다. CONN은 100%인데 WELCOME이나 MATCH가 떨어지면 TCP/WebSocket 연결 자체가 문제가 아니라, 그 다음 단계의 세션 확인이나 매칭 처리 쪽을 봐야 합니다.
즉 벤치마크는 "서버가 된다/안 된다"가 아니라, 어느 단계까지는 되고, 어느 단계부터 무너지는지를 보여주는 도구였습니다.
Supabase Auth rate limit은 서버 문제가 아니었다
처음에는 신규 게스트/익명 유저를 동시에 많이 만들면 서버가 불안한 것처럼 보였습니다.
그런데 지표를 나눠보니 전투 tick이나 WebSocket 메시지 처리보다 먼저 막히는 곳이 있었습니다. 바로 Supabase Auth rate limit이었습니다.
이건 3편의 서버 권위 모델 문제와 성격이 다릅니다. 서버가 판정을 못 하거나 매칭 큐가 느린 문제가 아니라, 테스트 방식이 인증 생성 요청을 한꺼번에 밀어 넣으면서 외부 인증 레이어의 제한을 먼저 밟은 것입니다.
그래서 벤치마크 도구에는 토큰 재사용 옵션을 넣었습니다.
토큰을 재사용하면 "인증 생성 병목"을 떼어내고 순수하게 매칭 큐와 게임플레이 흐름을 볼 수 있습니다. 반대로 Auth 병목 테스트에서는 의도적으로 신규 유저 생성을 많이 만들어서 인증 레이어가 어디서 막히는지 확인할 수 있습니다.
이 분리가 중요했습니다.
서버가 느린 것인지, 인증이 막힌 것인지, 결과 저장이 실패한 것인지를 구분해야 실제로 고칠 수 있습니다.
리포트를 남겨야 비교가 된다
벤치마크는 한 번 돌리고 끝나는 도구가 아니었습니다.
리포트를 저장해두면 같은 조건의 테스트를 나중에 다시 돌렸을 때 비교할 수 있습니다.
- 이전에는 match 40%였는데 지금은 100%인지
- conn은 항상 100%인데 welcome만 흔들리는지
- Auth rate limit 영향을 제외한 조건에서도 서버 흐름이 안정적인지
- 결과 저장 시나리오만 따로 실패하는지
- 서버 위치나 네트워크 조건이 바뀌었을 때 RTT가 어떻게 달라지는지
이런 기록이 쌓여야 "느낌상 나아졌다"가 아니라 이전보다 어떤 지표가 나아졌는지 말할 수 있습니다.
AI 난이도도 벤치마크가 필요했다
벤치마크는 서버에만 필요하지 않았습니다. AI 난이도도 결국 검증이 필요했습니다.
5편에서 말했듯이 AI의 목표는 최강 봇이 아니라, 난이도별로 그럴듯한 상대를 만드는 것이었습니다. 그런데 "Lv8이 Lv7보다 어려운가?"는 감으로만 판단하기 어렵습니다.
그래서 AI끼리 반복 대전시키고, 승률과 ELO로 난이도를 다시 정렬했습니다. 다만 이 결과는 같은 AI끼리 정해진 조건에서 리그를 돌린 결과입니다. 실제 플레이어가 체감하는 난이도와 100% 일치한다고 확신하기보다는, 난이도를 조정할 때 참고할 수 있는 근거로 보는 쪽이 맞았습니다.
흥미로웠던 점은 숫자 순서와 실제 강함이 항상 일치하지 않았다는 것입니다.
이건 실패라기보다 좋은 신호였습니다. "Lv8이 더 어려워야 한다"는 기획 의도가 실제 전투 결과와 어긋난 지점을 찾았기 때문입니다.
AI matchup heatmap을 보면 어떤 레벨이 어떤 레벨에게 강한지도 더 잘 보입니다.
결국 AI 벤치마크는 난이도를 확정하는 도구라기보다, 게임 규칙이 어떤 행동을 강하게 만드는지 보고 난이도 조정의 근거를 쌓는 도구였습니다.
벤치마크를 만들며 배운 것
벤치마크를 만들면서 가장 크게 배운 것은, 숫자가 많다고 자동으로 문제가 보이는 것은 아니라는 점입니다.
좋은 벤치마크는 지표를 많이 뿌리는 도구가 아니라, 실패를 단계별로 분리해주는 도구여야 했습니다.
- 연결이 문제인지
- 세션 확인이 문제인지
- 매칭이 문제인지
- 게임플레이가 문제인지
- 결과 저장이 문제인지
- 인증 레이어가 문제인지
- AI 난이도 설계가 실제 전투 결과와 맞는지
이런 식으로 나눠야 "렉 걸림", "매칭 안 됨", "AI가 이상함" 같은 막연한 문제를 실제 작업 단위로 바꿀 수 있었습니다.
마무리: 감각을 숫자로 다시 확인하기
모아이는내려찍고싶다는 손맛이 중요한 게임입니다. 하지만 손맛만으로 서비스를 운영할 수는 없었습니다.
클라이언트의 손맛은 사람이 직접 느껴야 하지만, 서버와 인프라와 AI 난이도는 숫자로 확인해야 하는 영역이 있었습니다.
그래서 벤치마크 도구는 이 시리즈의 마지막에 어울리는 작업이었습니다. 1편에서 시작한 Hook, Simple, Juicy는 결국 플레이어가 느끼는 감각이고, 8편의 벤치마크는 그 감각이 실제 서비스 구조 위에서 무너지지 않는지 확인하는 장치였습니다.