10장. QA의 커뮤니케이션은 기술이다

QA 업무에서 가장 자주 오해받는 능력은 커뮤니케이션입니다. 말만 잘하면 되는 일처럼 보이지만, 실제로 QA의 커뮤니케이션은 감정 표현이 아니라 정보 전달의 정확도에 관한 문제입니다.

QA는 문제를 발견하는 사람인 동시에, 그 문제를 이해시키는 사람입니다. 발견만 하고 설명하지 못하면, 문제는 존재하지 않는 것과 다르지 않습니다.

---

좋은 리포트는 감정을 배제한다

QA 리포트에서 가장 피해야 할 것은 판단의 단정입니다.

“너무 불편합니다.” “완성도가 낮아 보입니다.”

이런 문장은 공감을 얻을 수는 있지만, 수정으로 이어지기 어렵습니다. 좋은 리포트는 감정을 배제하고 현상을 재현 가능하게 설명합니다.

• 어떤 조건에서
• 어떤 행동을 했을 때
• 어떤 결과가 발생했는지

이 세 가지가 명확하면, 문제는 이미 절반 해결된 셈입니다.

---

문제는 현상으로, 제안은 선택지로

QA는 해결책을 강요하지 않습니다. 대신 선택지를 제시합니다.

“이렇게 고쳐야 합니다”가 아니라, “현재 구조에서는 이런 리스크가 발생합니다”라고 말해야 합니다.

이 차이는 중요합니다. QA가 설계를 대신하려 들면, 협업은 곧바로 충돌로 바뀝니다.

QA의 언어는 항상 설명형이어야 합니다.

---

타이밍은 내용만큼 중요하다

같은 문제라도 언제 이야기하느냐에 따라 결과는 달라집니다.

개발 막바지에 구조적 문제를 제기하면, 현실적인 선택지는 줄어듭니다. 반대로 초기 단계에서 사소해 보이는 문제를 공유하면, 큰 비용을 들이지 않고 방향을 조정할 수 있습니다.

QA는 문제의 크기뿐 아니라 문제를 꺼내는 시점까지 고려해야 합니다.

---

개발자와의 대화에서 중요한 것

QA와 개발자의 대화가 어려워지는 순간은 대부분 의도가 오해될 때입니다.

QA는 지적하려는 사람이 아니라, 돕는 사람입니다. 이 전제가 공유되지 않으면 어떤 말도 공격처럼 들립니다.

• 사람을 평가하지 않는다
• 결과를 단정하지 않는다
• 구조와 현상에 집중한다

이 세 가지 원칙만 지켜도 대화의 온도는 달라집니다.

---

유저의 말을 그대로 옮기지 않는다

운영 단계에서 QA는 유저의 목소리를 자주 접합니다. 하지만 QA의 역할은 전달자가 아닙니다.

유저의 불만을 그대로 옮기면, 그것은 감정의 전달일 뿐입니다. QA는 이 감정을 분석해 문제의 형태로 재구성해야 합니다.

• 어떤 상황에서 불만이 발생했는가
• 반복되는 패턴이 있는가
• 실제로 시스템 문제로 이어지는가

이 과정을 거쳐야, 유저의 목소리는 개발에 반영될 수 있습니다.

---

이 장을 마치며

QA의 커뮤니케이션은 말솜씨가 아닙니다. 문제를 구조화하고, 오해 없이 전달하는 기술입니다.

이 기술이 쌓일수록, QA는 단순한 검사자가 아니라 팀의 판단을 돕는 역할로 자리 잡게 됩니다.