[짧QA] 31장. QA는 ‘모든 문제를 고치자’고 말하지 않는다

 

QA를 오래 하다 보면
이런 말을 듣게 된다.

“QA는 왜 맨날 다 고치자고 해요?”
“현실적으로 그건 불가능하잖아요.”

이 말은
QA를 공격하는 말처럼 들리지만,
사실은
QA 역할에 대한 오해다.

QA는
모든 문제를 고치자고 말하는 사람이 아니다.

QA는
무엇을 고치지 않을지를
명확히 말해야 하는 사람이다.

---

완벽한 품질은
존재하지 않는다.

이건
핑계가 아니라
현실이다.

• 시간은 한정되어 있고
• 인력은 부족하고
• 일정은 이미 정해져 있다

이 조건에서
“전부 고치자”는 말은
아무 결정도 하지 않겠다는 말과 같다.

QA의 역할은
이 현실을 외면하지 않는 데 있다.

---

QA가
우선순위를 말하지 못하면
조직은
가장 쉬운 선택을 한다.

• 눈에 보이는 문제만 고치고
• 당장 안 터지는 건 넘기고
• 나중에 감당하기로 한다

이 선택은
거의 항상
QA에게 돌아온다.

“왜 이건 말 안 했죠?”

---

그래서 QA는
문제를 나열하는 순간부터
이미 실패한 상태다.

• 버그 A
• 버그 B
• 버그 C

이 목록은
결정을 도와주지 않는다.

QA는
이렇게 말해야 한다.

• 이 문제는 지금 고쳐야 한다
• 이 문제는 넘겨도 된다
• 이 문제는 기록만 남겨야 한다

이 구분이
QA 판단의 핵심이다.

---

QA가
모든 문제를 고치자고 말하지 않는 이유는
타협해서가 아니다.

문제의 무게를 알기 때문이다.

• 이 문제는
  유저를 잃는다
• 이 문제는
  운영 비용을 키운다
• 이 문제는
  회복이 불가능하다

이 문제들만큼은
넘기면 안 된다.

QA는
이 선을 그어야 한다.

---

QA가
우선순위를 정할 때
반드시 봐야 할 기준이 있다.

1️⃣ 되돌릴 수 있는가

• 발생해도 복구 가능한가

2️⃣ 반복되는가

• 한 번이 아니라 구조적인가

3️⃣ 확산되는가

• 다른 시스템으로 번지는가

이 세 가지 중
하나라도 해당되면
QA는
강하게 말해야 한다.

---

반대로
이런 문제도 있다.

• 체감은 있지만
• 대체 경로가 있고
• 영향 범위가 제한적이다

이 문제를
모두 막으려 하면
QA는
아무 말도 통하지 않게 된다.

QA는
“지금은 넘기자”라고
말할 수 있어야 한다.

이 말은
패배가 아니다.

전략이다.

---

여기서
QA가 가장 많이 흔들리는 지점이 있다.

“이걸 넘겼다가
나중에 터지면 어떡하지?”

그래서 QA는
이걸 반드시 남겨야 한다.

• 어떤 조건에서
• 어떤 리스크를 인지했고
• 어떤 이유로
  지금은 넘기기로 했는지

이 기록은
면피용 문서가 아니다.

미래의 판단을 지키는 장치다.

---

숙련된 QA는
우선순위를 이렇게 만든다.

• 문제를 줄 세우지 않는다
• 문제를 묶는다
• 문제를 선택지로 바꾼다

그리고 이렇게 말한다.

“이 묶음은
같이 가면 위험합니다.”
“이 묶음은
나중에 처리해도 됩니다.”

이 말은
조직을 움직인다.

---

QA가
모든 문제를 고치자고 말하지 않을 때,
QA의 말은
오히려 더 무게를 가진다.

왜냐하면
조직은
이렇게 느끼기 때문이다.

“QA가
정말 중요한 것만
지금 꺼내는구나.”

이 신뢰가 쌓이면
QA의 경고는
훨씬 빨리 받아들여진다.

---

정리하자면 이렇다.

QA는
모든 문제를 고치자고 말하지 않는다.

QA는
지금 고치지 않으면
감당할 수 없는 문제를
구분해서 말하는 사람이다.

이 판단을 할 수 있을 때
QA는
조직 안에서
결정의 마지막 문턱을 지킨다.

---

일의 우선순위와 BTS의 우선순위는 다르다

― QA가 이 둘을 엮지 못하면 아무도 움직이지 않는다

QA가
우선순위를 이야기할 때
가장 자주 부딪히는 벽이 있다.

“이슈 우선순위는
BTS에 이미 적혀 있잖아요.”

맞다.
하지만 그 우선순위는
일의 우선순위가 아니다.

BTS에 적힌 우선순위는
관리 도구의 값이고,
QA가 말해야 하는 우선순위는
결정의 근거다.

이 둘을 연결하지 못하면
BTS는
그저 정리된 목록에 불과해진다.

---

BTS에서 말하는 우선순위는
대개 이런 기준을 따른다.

• Severity (심각도)
• Priority (처리 우선순위)
• Reproducibility (재현성)

이 기준들은
필요하다.
하지만 충분하지 않다.

왜냐하면
이 값들은
일을 어떻게 처리할지는 말해도,
왜 지금 해야 하는지는 설명하지 않기 때문이다.

---

그래서 현장에서
이런 장면이 반복된다.

• BTS에서는 High
• 하지만 일정에서는 뒤로 밀림
• QA는 답답해지고
• 조직은 무시당한다고 느낀다

이 갈등의 원인은 단순하다.

BTS 우선순위와
일의 우선순위가 분리되어 있기 때문이다.

---

QA가 해야 할 일은
BTS의 우선순위를
일의 우선순위로 번역하는 것이다.

QA는
이렇게 말할 수 있어야 한다.

• 이 이슈가 High인 이유는
  지금 안 고치면
  롤백이 불가능하기 때문이다
• 이 이슈가 Medium인 이유는
  대체 경로가 있기 때문이다
• 이 이슈를 지금 넘기는 건
  기술적 선택이 아니라
  운영 리스크를 감수하는 결정이다

이 설명이 붙는 순간,
BTS의 숫자는
의미를 갖는다.

---

여기서
QA가 자주 하는 실수가 있다.

“BTS에 적어놨는데요.”

BTS는
기억 장치다.
결정 장치가 아니다.

QA가
BTS에 우선순위를 적는 순간은
설득의 끝이 아니라 시작이다.

---

일의 우선순위는
항상 맥락을 포함한다.

• 지금 단계가 어디인지
• 다음 단계에서 무엇이 바뀌는지
• 이 이슈가 다음 결정에
  어떤 영향을 주는지

BTS는
이 맥락을 자동으로 담아주지 않는다.

QA가
직접 붙여야 한다.

---

숙련된 QA는
BTS를 이렇게 사용한다.

• 단순히 이슈를 쌓지 않는다
• 이슈를 묶고
• 그 묶음이 의미하는 리스크를 설명한다

그리고 회의에서
이렇게 말한다.

“이 묶음은
지금 처리하지 않으면
다음 스프린트에서
더 비싸집니다.”

이 말은
툴이 아니라
판단에서 나온 말이다.

---

BTS 우선순위는
절대적인 기준이 아니다.

현재 선택을 기록한 흔적이다.

• 왜 이 우선순위를 줬는지
• 어떤 조건에서 바뀔 수 있는지
• 언제 다시 봐야 하는지

이게 남아 있어야
우선순위는
시간이 지나도 설득력을 가진다.

---

그래서 QA에게
BTS는
단순 관리 도구가 아니다.

BTS는
QA의 판단을
조직에 남기는 장소다.

여기에
판단의 맥락이 없으면
QA의 생각도
같이 사라진다.

---

정리하자면 이렇다.

• BTS의 우선순위는
  작업 정렬을 위한 값이고
• QA의 우선순위는
  결정을 위한 논리다

QA가 이 둘을
하나로 엮을 수 있을 때
우선순위는
진짜 힘을 가진다.