[짧QA] 19장. 성능 QA는 숫자를 재는 일이 아니다

성능 QA라고 하면
가장 먼저 떠오르는 것이 있다.

• FPS
• 응답 시간
• 로딩 시간
• 메모리 사용량

그리고 그 다음에 나오는 말은 보통 이렇다.

“몇 FPS면 괜찮은 건가요?”
“몇 초 이하면 문제 없는 건가요?”

이 질문은
자연스럽다.

하지만 이 질문에
숫자만으로 답하려는 순간,
성능 QA는 길을 잃는다.

---

성능 QA는
숫자를 재는 일이 아니다.

성능 QA는
그 숫자가 유저 경험을
어떻게 바꾸는지를 판단하는 일이다.

같은 30FPS라도
어떤 게임에서는 충분하고,
어떤 게임에서는 치명적이다.

숫자는 결과지,
판단이 아니다.

---

성능 QA에서
가장 위험한 착각은 이것이다.

“기준치를 넘겼으니 문제 없다.”

이 말은
QA의 판단을
숫자 뒤로 숨긴다.

• 평균 FPS는 기준 이상인데
  특정 구간에서 급락한다
• 로딩 시간은 허용 범위인데
  반복될수록 체감이 나빠진다

이 문제들은
리포트에서 잘 드러나지 않는다.

하지만 유저는
즉시 느낀다.

---

성능 QA는
항상 질문에서 시작해야 한다.

• 이 성능 저하는
  언제 체감되는가
• 어느 상황에서
  가장 크게 느껴지는가
• 이 지연이
  플레이 판단에 영향을 주는가

이 질문이 빠진 성능 테스트는
측정은 했지만
QA는 아니다.

---

예를 들어 보자.

전투 중 FPS가
평균 55로 유지된다.

숫자만 보면
문제 없어 보인다.

하지만 QA는
이걸로 끝내지 않는다.

• 스킬 이펙트가 몰릴 때
  순간적으로 끊기지 않는가
• 회피 타이밍이 중요한 구간에서
  입력 지연이 발생하지 않는가

FPS 55라는 숫자보다
회피가 한 박자 늦어지는지가
훨씬 중요하다.

---

성능 QA에서
평균값은
가장 위험한 수치다.

평균은
문제를 숨긴다.

QA가 봐야 할 것은
항상 이쪽이다.

• 최저값
• 급락 구간
• 반복 시 누적 변화

유저는
평균을 플레이하지 않는다.

문제가 발생하는 순간을 플레이한다.

---

성능 QA는
단발성 테스트로 끝나지 않는다.

• 오래 플레이했을 때
• 여러 기능을 오간 뒤
• 업데이트 이후

성능 문제의 상당수는
누적형이다.

그래서
“처음엔 괜찮았어요”라는 말이
반드시 따라온다.

QA가 이 말을 듣기 전에
먼저 봐야 한다.

---

성능 QA는
기능 QA와 분리되지 않는다.

• 특정 기능이
  성능을 급격히 떨어뜨리는가
• 특정 상태에서만
  성능 문제가 발생하는가

성능 문제는
항상 기능·상태·데이터와 엮여 있다.

성능을
독립된 영역으로 보는 순간,
원인은 끝까지 안 잡힌다.

---

그래서 성능 QA에서
가장 중요한 것은
측정 도구가 아니다.

• 어떤 구간을
  성능 리스크로 보는지
• 어떤 상황을
  재현해야 의미가 있는지

이 판단이 먼저다.

도구는
그 다음이다.

---

정리하자면 이렇다.

성능 QA는
숫자를 맞추는 일이 아니다.

성능 QA는
유저가 ‘불편하다’고 느끼는 순간을
숫자로 설명하는 일이다.

• 평균이 아니라 최악을 보고
• 기준이 아니라 체감을 보고
• 결과가 아니라 원인을 본다

이 관점이 잡히는 순간,
성능 QA는
측정 작업이 아니라
품질 판단이 된다.

---

성능 문제의 정체는 대부분 ‘연산’이다

― 느려지는 이유는 거의 항상 계산에서 시작된다

성능이 떨어진다고 하면
많은 사람들이 이렇게 생각한다.

• 서버가 느린가?
• 네트워크가 문제인가?
• 기기 사양이 낮은가?

물론 맞는 말이다.
하지만 QA 입장에서
가장 먼저 봐야 할 것은 이것이다.

이 장면에서 연산이 얼마나 발생하는가.

---

성능 문제의 상당수는
그래픽도, 네트워크도 아니다.

연산량이 많아졌기 때문에 발생한다.

• 반복되는 계산
• 불필요한 조건 체크
• 중첩된 로직
• 프레임마다 실행되는 처리

이 연산들이
눈에 보이지 않게 쌓인다.

QA가 성능을 본다는 것은
결국 이 질문으로 귀결된다.

“지금 이 순간,
시스템은 무엇을 얼마나 계산하고 있는가?”

---

예를 들어 보자.

전투 중
몬스터 수가 늘어날수록
프레임이 떨어진다.

이때 단순한 설명은 이렇다.

“몬스터가 많아서요.”

QA의 설명은 여기서 멈추지 않는다.

• 몬스터 하나당
  어떤 연산이 발생하는가
• 이 연산은
  프레임마다 실행되는가
• 몬스터 수에 비례해
  선형으로 늘어나는가,
  아니면 기하급수적으로 늘어나는가

이 질문을 하지 않으면
성능 문제는
항상 막연해진다.

---

연산 관점에서 보면
성능 문제는
패턴을 가진다.

• 몬스터 수 증가 → 연산량 증가 → FPS 하락
• 이펙트 중첩 → 계산량 폭증 → 순간 프레임 드랍
• 버프·디버프 누적 → 조건 체크 증가 → 입력 지연

QA가 이 패턴을 인식하는 순간,
성능 QA는
재현 가능한 테스트가 된다.

---

성능 QA에서
연산을 본다는 것은
코드를 분석하겠다는 말이 아니다.

QA는
코드를 몰라도
연산의 형태는 볼 수 있다.

• 반복되는가
• 누적되는가
• 프레임 단위로 발생하는가
• 특정 트리거에서만 발생하는가

이 정도만 구분해도
성능 리포트의 질은
완전히 달라진다.

---

연산을 보지 않는 성능 QA는
이렇게 말하게 된다.

“많이 몰리면 느려집니다.”

연산을 보는 성능 QA는
이렇게 말한다.

“몬스터 수가 15를 넘어가면
타겟 탐색 연산이
프레임마다 중첩되면서
입력 지연이 발생합니다.”

이 차이는
체감 보고와 구조 보고의 차이다.

---

성능 QA에서
가장 위험한 테스트는 이것이다.

• 한 번 실행해 보고
• 잠깐 확인하고
• 괜찮다고 판단하는 것

연산 문제는
대부분 누적형이다.

• 오래 플레이할수록
• 반복할수록
• 조건이 겹칠수록

QA는
“처음엔 괜찮다”는 말을
절대 신뢰하면 안 된다.

그 말은 곧
연산이 쌓이고 있다는 신호다.

---

그래서 성능 QA에서
연산 관점은
시간과 반드시 함께 간다.

• 이 연산은
  플레이 시간이 늘어날수록
  줄어드는가, 늘어나는가
• 이 연산은
  초기화되는가, 남아 있는가

이 질문을 하지 않으면
성능 문제는
항상 늦게 터진다.

---

정리하자면 이렇다.

성능 문제의 대부분은
“느리다”가 아니라
**“연산이 쌓였다”**는 문제다.

성능 QA는
숫자를 재는 일이 아니라,
연산이 언제, 어디서, 얼마나 발생하는지를
의심하는 일이다.

이 관점이 잡히면
성능 QA는
기기 차이 탓을 하지 않는다.

구조를 본다.