[짧QA] 18장. 비기능 QA는 왜 항상 “문제 터지고 나서” 주목받을까

비기능 QA 이야기를 꺼내면
대부분 이런 반응이 나온다.

“그건 나중에 봐도 되지 않나요?”
“지금은 기능부터 완성해야죠.”
“유저가 늘어나면 그때 보면 되잖아요.”

이 말들은
틀리지 않았다.

하지만 정확하지도 않다.

비기능 QA는
항상 문제가 터지고 나서야
중요해진다.

그리고 그때는
이미 늦은 경우가 많다.

---

기능 QA는
눈에 보인다.

• 버튼이 안 눌린다
• 화면이 깨진다
• 진행이 막힌다

그래서 누구나
문제라고 인식한다.

비기능 QA는
눈에 잘 보이지 않는다.

• 로딩이 조금 느리다
• 반응이 묘하게 답답하다
• 오래 하면 불안해진다

이 차이 때문에
비기능 QA는
항상 우선순위에서 밀린다.

---

비기능 QA의 가장 큰 특징은
**“기능은 정상처럼 보인다”**는 점이다.

• 로그인은 된다
• 플레이는 가능하다
• 보상도 나온다

하지만 어딘가 불편하다.

QA가 이 불편함을
명확한 언어로 설명하지 못하면
이건 곧 이렇게 번역된다.

“개인차 아닌가요?”
“기분 탓 아닐까요?”

비기능 QA가 어려운 이유는
여기에 있다.

---

비기능 문제는
단일 사건으로 터지지 않는다.

• 누적되고
• 겹치고
• 특정 조건에서만 드러난다

그래서 항상
이런 식으로 시작한다.

“처음엔 괜찮았는데요…”

이 문장이 나온 시점이면
이미 시스템은
안쪽부터 무너지고 있다.

---

QA 입장에서
가장 무서운 상황은 이것이다.

• 기능 QA는 다 끝났고
• 큰 버그도 없고
• 출시도 했다

그런데
유저 반응이 나쁘다.

• 이탈이 빠르다
• 플레이 시간이 짧다
• 평가는 애매하다

이때 기능 QA를 다시 보면
문제는 없다.

문제는
비기능 영역에 숨어 있다.

---

비기능 QA는
“안 되는 것”을 찾지 않는다.

비기능 QA는
**“계속 써도 괜찮은가”**를 묻는다.

• 오래 플레이해도 버틸 수 있는가
• 유저가 늘어나도 감당 가능한가
• 업데이트가 반복돼도 무너지지 않는가

이 질문들은
기능 QA로는
절대 답할 수 없다.

---

그래서 비기능 QA는
항상 오해를 받는다.

• 문제를 만드는 사람처럼 보이고
• 일정에 태클 거는 사람처럼 보이며
• 추상적인 말을 하는 사람처럼 보인다

하지만 이건
비기능 QA가 추상적인 게 아니다.

비기능 QA의 결과가
아직 눈앞에 없을 뿐이다.

---

비기능 QA의 진짜 역할은
사고를 막는 것이 아니다.

비기능 QA의 역할은
사고가 날 구조를
미리 알아보는 것이다.

• 이 구조는
  유저가 늘면 버틸 수 있는가
• 이 시스템은
  장시간 사용을 전제로 설계되었는가
• 이 흐름은
  반복될수록 부담이 쌓이지 않는가

이 질문을 하지 않으면
프로젝트는
조용히 한계를 향해 간다.

---

비기능 QA가
가장 큰 가치를 만드는 순간은
문제가 발생했을 때가 아니다.

비기능 QA의 가치는
“아직 문제 없을 때” 나타난다.

• 아직 서버는 안 터졌지만
• 아직 렉은 심하지 않지만
• 아직 유저는 불만을 말하지 않지만

QA가 이 시점에서
위험을 언어로 만들 수 있느냐가
비기능 QA의 전부다.

---

정리하자면 이렇다.

비기능 QA는
나중에 하는 QA가 아니다.

비기능 QA는
늦게 보이면 반드시 사고가 나는 QA다.

그래서 비기능 QA는
항상 불편하고,
항상 귀찮고,
항상 설득해야 한다.

그리고 그럼에도 불구하고
반드시 필요하다.