결함 커뮤니케이션 원칙: 비난이 아니라 정보 전달

개념

결함 리포트는 사람이 읽는다

레슨 2에서 배운 5가지 구성 요소를 다 갖춰도, 표현 방식에 따라 전혀 다른 반응을 만들어낼 수 있다. 결함 리포트는 결국 개발자라는 사람이 읽는 글이다 — 같은 사실이라도 "이거 왜 이렇게 만드셨어요?"와 "이 케이스에서는 이런 결과가 나옵니다"는 완전히 다른 대화를 시작한다.

비난형 언어 vs 정보형 언어

정보형 언어의 공통점은 "사람"이 아니라 "현상"을 주어로 삼는다는 것이다. "당신이 잘못했다"가 아니라 "이런 입력에서 이런 결과가 나온다"는 사실만 전달한다.

결함은 개인의 실수가 아니라 시스템의 결과다

버그는 대체로 한 사람의 부주의가 아니라, 요구사항이 불명확했거나, 시간이 부족했거나, 테스트 환경이 실제와 달랐거나 하는 여러 원인이 겹친 결과다. 결함 하나를 특정 개발자 개인의 실수로 몰아가는 언어는 사실관계와도 맞지 않을 때가 많고, 팀 분위기만 방어적으로 만든다.

톤이 만드는 결과의 차이

비난형으로 리포트를 받은 개발자는 방어적으로 반응하기 쉽다 — 결함 자체보다 "내 잘못이 아니다"를 증명하는 데 에너지를 쓰게 된다. 정보형으로 리포트를 받으면, 개발자는 곧바로 "이 현상이 왜 발생하는지" 원인 분석에 집중할 수 있다.

같은 결함을 놓고도, 리포트의 톤 하나가 그 결함이 얼마나 빨리 고쳐지는지에 실질적인 영향을 준다.

구두 커뮤니케이션에서도 동일하다

이 원칙은 텍스트 리포트뿐 아니라 스탠드업 미팅이나 슬랙 대화에서도 똑같이 적용된다. "그거 아직도 안 고쳐졌던데요?"보다 "그 이슈 진행 상황 여쭤봐도 될까요?"가 같은 정보를 전달하면서도 협업을 이어가는 언어다.

실무에서 왜 필요한가

QA와 개발은 매일 함께 일하는 관계다. 결함 리포트마다 비난조로 쓰면 단기적으로는 문제가 지적되겠지만, 장기적으로는 개발자가 QA를 "트집 잡는 사람"으로 인식하게 되고, 협업 자체가 힘들어진다. 반대로 정보형 커뮤니케이션이 습관이 된 QA는 개발자에게 신뢰받는 동료가 되고, 그 신뢰는 결함이 더 빨리, 더 정확하게 논의되는 실질적인 효율로 돌아온다. 이건 모듈 1(레슨 6)과 모듈 2(레슨 6)에서 이미 살짝 다룬 원칙을, 결함 리포트라는 QA의 가장 빈번한 커뮤니케이션 상황에 구체적으로 적용하는 것이다.

실습 과제

과제 1 — 비난형을 정보형으로 바꾸기 (10분)

다음 세 문장을 정보형 언어로 바꿔 쓴다.

1. "이 폼 검증 로직 완전히 빠뜨리셨네요."
2. "테스트도 안 해보고 배포하신 거 아니에요?"
3. "이런 말도 안 되는 케이스가 왜 아직도 안 고쳐졌죠?"

과제 2 — 나의 언어 습관 점검 (5분)

최근에 작성했던(또는 앞으로 작성할) 결함 리포트나 이슈 코멘트를 하나 떠올려, "사람"이 주어인 문장이 있는지 찾아보고 "현상"이 주어인 문장으로 바꿔본다.

자가 체크리스트

• 비난형 언어와 정보형 언어의 차이를 예시로 설명할 수 있다
• "사람이 아니라 현상을 주어로 삼는다"는 원칙을 적용해 문장을 고쳐 쓸 수 있다
• 결함이 개인의 실수가 아니라 시스템적 결과인 경우가 많은 이유를 설명할 수 있다
• 커뮤니케이션 톤이 결함 수정 속도에 실질적으로 영향을 준다는 것을 설명할 수 있다

흔한 실수

• 사실을 정확히 전달하는 것과 비난하지 않는 것을 대립되는 것으로 착각한다. 정보형 언어도 사실은 똑같이, 오히려 더 명확하게 전달한다 — 다만 사람을 지목하지 않을 뿐이다.
• 텍스트 리포트만 신경 쓰고 구두 대화에서는 비난조를 쓴다. 원칙은 매체와 상관없이 동일하게 적용해야 한다.
• 문제를 부드럽게 포장하려다 정작 심각성이 흐려진다. 정보형 언어는 완곡어법이 아니다 — 사실과 심각도는 명확히, 어조만 비난이 아니게 전달하는 것이 핵심이다.

참고 자료

• Lisa Crispin & Janet Gregory, Agile Testing — QA와 개발의 협업 문화를 다룬 장
• Nonviolent Communication (비폭력대화) 개요 — 관찰과 평가를 구분하는 커뮤니케이션 원칙(결함 리포트에 응용 가능)