[짧QA] 16장. 기능 QA에서 로그(Log)는 ‘개발자 도구’만은 아니다

QA가 로그를 보기 시작하면
종종 이런 말을 듣는다.

“그건 개발자 영역 아닌가요?”
“로그는 개발자가 보면 되죠.”

이 말이 나오는 순간,
QA는 또 하나의 중요한 무기를
스스로 내려놓게 된다.

로그는
개발자만을 위한 도구가 아니다.

로그는
시스템이 남긴 진술서다.

---

기능 QA를 하다 보면
반드시 이런 상황을 마주한다.

• 분명 문제가 발생했는데
• 다시 해보면 안 나온다
• 조건을 바꿔도 재현이 안 된다

이때 QA가 할 수 있는 선택은 두 가지다.

1. 재현 안 된다고 정리한다
2. 로그를 본다

이 선택이
QA의 수준을 가른다.

---

로그는
“무슨 일이 일어났는지”를
시간 순서대로 기록한 흔적이다.

QA가 로그를 본다는 것은
코드를 읽겠다는 뜻이 아니다.

QA가 로그를 본다는 것은
시스템이 어떤 판단을 했는지를
추적하겠다는 뜻이다.

• 어떤 트리거가 먼저 발생했는지
• 어떤 상태 값이 바뀌었는지
• 어떤 분기 로직을 탔는지

이걸 보지 않으면
QA는 항상 결과만 본다.

---

기능 QA에서
로그를 무서워하는 이유는 단순하다.

• 양이 많고
• 의미를 모르겠고
• 어디서 봐야 할지 모르겠다

그래서 로그는
“있긴 한데 잘 안 보는 것”이 된다.

하지만 숙련된 QA는
로그를 전부 보지 않는다.

봐야 할 지점만 본다.

---

QA가 로그에서
가장 먼저 봐야 할 것은
에러 메시지가 아니다.

QA가 먼저 봐야 할 것은
흐름이다.

• 이 기능이 호출된 시점
• 그 직전에 어떤 상태였는지
• 그 다음에 어떤 처리가 이어졌는지

에러는
흐름이 깨졌을 때의 결과다.

흐름을 보지 않고 에러만 보면
원인은 항상 엇나간다.

---

예를 들어 보자.

퀘스트 완료가
간헐적으로 실패한다.

QA는 로그를 열고
이렇게 본다.

• 완료 버튼 클릭 로그
• 보상 지급 처리 로그
• 퀘스트 상태 저장 로그

이 순서가
항상 같은가?

만약 순서가 바뀐다면,
그 순간이
문제가 발생하는 지점이다.

로그는
이 순서를 숨기지 않는다.

---

로그는
데이터가 언제, 어디서, 어떻게
변했는지를 보여준다.

그래서 로그는
데이터 QA의 연장선이다.

• 데이터가 꼬였다는 말은
  로그에 그 흔적이 남아 있다는 뜻이고
• 재현이 안 된다는 말은
  로그를 아직 못 봤다는 뜻일 가능성이 크다

QA가 로그를 본다는 것은
추측을 멈추겠다는 선언이다.

---

기능 QA에서
로그를 제대로 쓰는 QA는
보고 방식부터 다르다.

• “이상합니다”라고 말하지 않고
• “이 순서에서 상태가 달라집니다”라고 말한다

이 차이는 크다.

전자는
의견처럼 들리고,
후자는
사실처럼 들린다.

---

로그를 기반으로 한 QA 리포트는
개발자에게 질문을 던지지 않는다.

판단을 던진다.

• 이 트리거 이후
  상태 값이 의도와 다르게 바뀝니다
• 이 분기에서
  예외 처리가 빠져 있습니다

이 순간부터
QA는
“확인해 달라”는 사람이 아니라
**“지점을 특정한 사람”**이 된다.

---

물론
QA가 로그를 본다고 해서
모든 문제가 해결되지는 않는다.

하지만 로그를 보지 않는 QA는
문제를 설명할 수 없다.

QA의 신뢰는
결과가 아니라
근거에서 나온다.

로그는
그 근거를 만들어주는 도구다.

---

정리하자면 이렇다.

로그는
개발자의 영역이 아니다.

로그는
시스템의 판단 과정을
읽을 수 있는 유일한 기록이다.

기능 QA가 로그를 보기 시작하는 순간,
QA는
“왜 이런 문제가 생겼는지 모르겠다”는 말을
하지 않게 된다.

그리고 그 순간부터
QA는
한 단계 위의 역할을 맡게 된다.