QArchive

[짧QA] 27장. QA 리포트는 보고서가 아니라 결정서다 본문

QA적 사고

[짧QA] 27장. QA 리포트는 보고서가 아니라 결정서다

Mastering 2026. 1. 15. 20:46

QA 리포트를 떠올리면
대부분 이런 이미지를 생각한다.

  • 버그 목록
  • 재현 절차
  • 스크린샷
  • 로그

물론 필요하다.
하지만 이건
리포트의 절반이다.

QA 리포트의 진짜 목적은
정보 전달이 아니다.

결정을 끌어내는 것이다.


조직에서
리포트가 소비되는 방식은 단순하다.

  • 다 읽지 않는다
  • 핵심만 본다
  • 결국 “그래서?”를 묻는다

QA 리포트가
이 질문에 답하지 못하면
그 리포트는
읽혔어도 작동하지 않는다.


QA가 자주 빠지는 함정이 있다.

“팩트는 다 적어놨습니다.”

팩트는 중요하다.
하지만 팩트는
결정을 대신 내려주지 않는다.

조직은
팩트 다음을 원한다.

  • 이걸 지금 고쳐야 하나
  • 넘겨도 되는가
  • 나중에 하면 안 되는 이유는 무엇인가

QA 리포트는
이 질문에 답하는 문서여야 한다.


그래서
QA 리포트는
구조부터 달라야 한다.

❌ 현상 중심 리포트

  • 어떤 오류가 발생한다
  • 이런 조건에서 재현된다

⭕ 결정 중심 리포트

  • 이 문제는
    어떤 유저에게 영향을 주고
  • 어떤 리스크로 이어지며
  • 지금 대응하지 않으면
    어떤 비용이 발생하는가

이 차이는
문서의 길이가 아니라
사고의 방향이다.


좋은 QA 리포트에는
항상 세 가지가 들어간다.

1️⃣ 영향 범위

  • 누구에게 영향을 주는가
  • 일부인가, 다수인가
  • 특정 조건인가, 일반 상황인가

2️⃣ 발생 가능성

  • 항상 발생하는가
  • 특정 조건에서만 발생하는가
  • 시간이 쌓이면 심해지는가

3️⃣ 대응 선택지

  • 지금 수정
  • 임시 우회
  • 릴리즈 후 대응

이 세 가지가 없으면
리포트는
결정 불가능한 정보가 된다.


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의 모든 커뮤니케이션은
이 기준 위에서만
힘을 가진다.