[짧QA] 20장. 안정성 QA는 ‘안 터지는지’ 보는 일이 아니다

― 그리고 왜 최적화는 QA의 언어가 되어야 하는가

안정성 QA를 설명할 때
가장 흔히 나오는 표현이 있다.

“안 터지면 되는 거 아닌가요?”

이 질문은
겉으로 보면 합리적이다.
하지만 QA 관점에서는
가장 위험한 질문이기도 하다.

안 터진다는 말은
지금 당장은 문제 없다는 뜻일 뿐이다.

안정성 QA는
현재가 아니라
미래를 검증하는 영역이다.

---

안정성 문제는
대부분 한 번에 터지지 않는다.

• 서서히 느려지고
• 점점 불안해지고
• 어느 순간 한계를 넘는다

그래서 안정성 이슈에는
항상 이런 말이 따라온다.

“예전에는 괜찮았어요.”

이 말은
버그가 없었다는 뜻이 아니다.

문제가 쌓이고 있었다는 뜻이다.

---

여기서
최적화(Optimization)라는 개념이 등장한다.

많은 사람들이
최적화를 이렇게 이해한다.

• 더 빠르게 만드는 것
• 더 가볍게 만드는 것
• 성능을 끌어올리는 것

틀린 말은 아니다.
하지만 QA에게 최적화는
조금 다른 의미를 가진다.

QA에게 최적화란
시스템이 오래 버틸 수 있도록
구조를 정리하는 일이다.

---

성능 QA가
“지금 느리다”를 다룬다면,
안정성 QA는
“왜 시간이 지나면 망가지는가”를 다룬다.

그리고 이 질문의 답은
대부분 최적화 여부에 있다.

• 불필요한 연산이 누적되고 있는가
• 정리되지 않은 데이터가 남아 있는가
• 해제되지 않는 리소스가 있는가

이 문제들은
당장 터지지 않는다.

그래서 더 위험하다.

---

안정성 QA에서
가장 자주 놓치는 착각이 있다.

“이건 성능 문제지, 안정성 문제는 아니다.”

하지만 실제 현장에서는
성능 문제와 안정성 문제는
같은 뿌리를 가진 경우가 많다.

• 성능 저하 → 누적 → 크래시
• 메모리 사용 증가 → 누수 → 장시간 플레이 불가
• 연산 증가 → 프레임 드랍 → 입력 지연 → 플레이 포기

최적화되지 않은 구조는
시간을 적으로 만든다.

---

QA가 최적화를 이해해야 하는 이유는
개발을 대신하기 위해서가 아니다.

QA가 봐야 할 것은
최적화가 안 된 상태에서
시스템이 어떻게 무너지는지다.

• 이 연산은
  플레이 시간이 늘어날수록 부담이 되는가
• 이 구조는
  반복될수록 회복이 되는가, 쌓이는가
• 이 상태는
  유저가 빠져나올 수 있는가

이 질문을 던질 수 있어야
QA는 안정성을 이야기할 수 있다.

---

안정성 QA에서
“안 터진다”는 말은
아무 의미가 없다.

QA가 던져야 할 질문은 이것이다.

• 얼마나 오래 버틸 수 있는가
• 어떤 조건에서 한계에 도달하는가
• 그 한계는 예측 가능한가

최적화는
이 질문들에 대한
가장 현실적인 해답이다.

---

예를 들어 보자.

게임을 30분 플레이하면
아무 문제 없다.

1시간을 넘기면
미묘하게 느려진다.

2시간을 넘기면
프레임 드랍이 잦아진다.

3시간을 넘기면
강제 종료가 발생한다.

이건
우연이 아니다.

최적화되지 않은 구조가
시간을 먹고 있는 상태다.

QA는
이 시간을 기준으로
안정성을 판단해야 한다.

---

안정성 QA에서
최적화는
“지금 고쳐야 할 일”이 아닐 수도 있다.

하지만 QA는
반드시 이렇게 말할 수 있어야 한다.

• 이 구조는
  장시간 플레이에 취약하다
• 이 시스템은
  업데이트가 반복될수록 위험해진다
• 이 상태는
  유저 수가 늘어나면 버티지 못한다

이 말은
개선을 요구하는 말이 아니라
미래를 설명하는 말이다.

---

정리하자면 이렇다.

안정성 QA는
안 터지는지를 보는 일이 아니다.

안정성 QA는
언제, 왜, 어떻게 터질지를
예상하는 일이다.

그리고 최적화는
그 예상을 가능하게 만드는
핵심 개념이다.

QA가 최적화를 이해하는 순간,
QA는 더 이상
“지금은 괜찮다”는 말에
속지 않는다.

시간을 기준으로
품질을 판단할 수 있게 된다.