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

개념

먼저 오해 하나를 치우자. 이 레슨은 예절에 관한 것이 아니다. 목표는 "부드럽게 말하기" 가 아니라 결함이 빨리 고쳐지게 만들기다. 비난을 없애는 이유도 착해서가 아니라, 비난이 원인 분석을 늦추기 때문이다.

그래서 이 레슨의 원칙은 심각성을 깎는 것과 정반대다. 정보형 언어는 완곡어법이 아니다. 사실과 심각도는 더 선명하게 전하고, 사람을 겨누는 부분만 뺀다.

QA 일의 성격 자체가 이 기술을 요구한다. QA는 매일 남의 결과물에서 문제를 찾아 알리는 직무다. 같은 일을 1년에 수백 번 하므로, 전하는 방식이 조금 어긋나도 그 어긋남이 누적된다.

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

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

비난형 언어 vs 정보형 언어

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

비난형이 되는 네 가지 패턴

의도 없이 비난형이 되는 경로가 정해져 있다. 네 가지만 피하면 대부분 해결된다.

세 번째가 가장 쉽게 빠뜨린다. "기본적인 것도" 같은 말은 사실을 하나도 더하지 않고 상대를 평가만 한다. 지워도 정보는 그대로다.

네 번째는 한국어 특유의 함정이다. "~던데요", "~네요", "~는데" 로 끝나는 문장은 지적의 어조를 띤다. 같은 내용이라도 요청형으로 끝내면 대화가 이어진다.

관찰과 평가를 나눈다

사람은 본 것과 거기서 내린 판단을 한 문장에 섞어 말한다. 섞인 문장은 반박이 쉽고, 나뉜 문장은 반박할 것이 없다.

오른쪽 칸을 지우고 가운데만 전하면 상대가 그 사실을 부정할 수 없다. 그리고 사실이 선명하면 평가는 상대가 스스로 내린다 — 그게 훨씬 강하다.

세 번째 줄은 평가를 숫자로 바꾼 예다. "늘 문제가 많다" 는 감정이고, "이번 스프린트에 같은 영역 결함 4건" 은 다음 행동으로 이어지는 정보다.

"왜"를 "무엇"으로 바꾼다

"왜" 로 시작하는 질문은 거의 항상 해명을 요구하는 말로 들린다. 묻고 싶은 것이 정말 이유일 때조차 그렇다.

세 번째가 특히 효과가 다르다. "도울 게 있나요" 한 마디가 붙으면 질문이 추궁에서 협업으로 바뀐다. 그리고 실제로 답이 온다 — "기획 확인을 기다리는 중" 같은 진짜 병목이 드러난다.

완곡어법과 혼동하지 않기

여기서 방향을 잃는 사람이 많다. 비난을 피하려다 심각성을 흐리는 것은 더 나쁜 실패다.

왼쪽은 읽는 사람이 심각도를 오판하게 만든다. 특히 첫 줄처럼 긴급한 것을 부드럽게 쓰면, 상대가 급하지 않은 줄 알고 넘긴다. 그러면 사고가 난 뒤에 "말은 했는데" 가 되고, 그것은 전달에 실패한 것이다.

세 번째 줄이 정답의 모습이다. 작은 것은 작다고 분명히 적는다. 그것도 정보다.

상황별 문장 — 그대로 꺼내 쓸 수 있게

실무에서 반복되는 다섯 상황이다. 처음에는 외워서 쓰는 편이 낫다.

네 번째가 QA에게 가장 어렵고 가장 중요하다. 판단을 대신 내리려 하지 않고, 사실과 영향을 주고 기록을 남긴다. 이것이 모듈 4 레슨 5의 Go/No-Go 에서 QA가 서는 자리다.

다섯 번째를 잘하는 사람이 신뢰를 가장 많이 얻는다. 틀렸을 때 빠르게 인정하는 사람의 "이건 문제입니다" 는 무게가 다르다.

채널을 고른다

같은 말이라도 어디서 하느냐가 톤의 절반이다.

세 번째 줄을 지키는 것만으로 많은 갈등이 사라진다. 공개 채널에서 개인을 두 번 지목하면, 그 뒤로 그 사람은 QA를 감시자로 본다.

비동기 채널은 톤이 없다

이슈 코멘트와 메신저에는 표정과 목소리가 없다. 그래서 짧은 글이 차갑게 읽힌다.

• "재현됩니다." → 한 줄이면 반박처럼 읽힌다
• "다시 확인해 봤는데 같은 조건에서 재현됩니다. 환경 정보 추가해 두었습니다." → 같은 사실인데 협업으로 읽힌다

과하게 길 필요는 없다. 한 문장을 더 붙이는 것만으로 충분하다. 특히 부정하는 내용일 때 이 한 문장이 중요하다.

반대로 이모지와 느낌표로 부드럽게 만들려는 시도는 심각한 건에서는 역효과다. 긴급 결함에 웃는 표정이 붙어 있으면 상대가 심각도를 오판한다.

왜 개인 탓하기가 품질을 떨어뜨리나

가장 실질적인 이유는 분위기가 아니다. 정보가 숨기 때문이다.

세 번째 줄이 핵심이다. 사고 원인을 "누가 부주의했다" 로 적으면 고칠 것이 없다. 사람을 조심시키는 것은 대책이 아니다. 같은 사고를 막는 것은 "그 시점에 아무도 그것을 볼 수 없었다" 는 구조를 찾아 고치는 일이다(모듈 10).

사례 — 같은 사실, 다른 결과

릴리즈 전날 결제 모듈에서 S1을 찾았다. 두 가지 방식으로 전했을 때의 차이가 실제로 남아 있다.

첫 번째 (비난형)

"결제 또 터졌습니다. 이번에도 쿠폰 쪽이에요. 왜 이 부분은 매번 이렇게 되는지 모르겠네요. 릴리즈 못 나갑니다."

받은 쪽의 첫 반응은 "쿠폰 쪽은 이번 스프린트에 안 건드렸습니다" 였다. 그 뒤 40분 동안 누가 무엇을 바꿨는지를 두고 대화가 돌았다. 원인 조사는 그 40분 뒤에 시작됐다.

두 번째 (정보형)

"[결제] 쿠폰 적용 후 수량 변경 시 할인액이 재계산되지 않습니다.

재현 5/5. 영향: 쿠폰 사용자 전체, 실제보다 높은 금액이 청구됩니다. 우회로 없음.

네트워크 탭에 /cart/recalculate 호출이 없습니다(참고·추측).

릴리즈 판단에 필요한 정보가 더 있으면 정리해 드리겠습니다."

첫 반응은 "지금 로그 보겠습니다" 였다. 20분 뒤 원인이 나왔고, 쿠폰 모듈이 아니라 장바구니 수량 핸들러였다.

두 리포트에 담긴 사실은 같다. 차이는 세 가지였다 — "또 터졌다" 가 없고, "왜 매번" 이 없고, 원인 추정이 추측으로 표시됐다. 그리고 릴리즈를 QA가 막지 않고 판단 재료를 준 것이 마지막 문장이다.

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

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

톤이 만드는 결과의 차이

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

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

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

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

실무에서 왜 필요한가

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

발언권은 이 지점에서 생긴다

QA가 조직에서 영향력을 갖는 경로는 둘뿐이다. 정확한 리포트(레슨 2)와 전달 방식(이 레슨)이다. 둘 중 하나가 빠지면 나머지가 힘을 못 쓴다.

두 번째 칸이 아깝다. 실력 있는 QA가 조직에서 고립되는 전형적인 경로이고, 고치는 데 큰 노력이 들지 않는 부분이기도 하다.

비난을 받는 쪽이 될 때

반대 상황도 온다. "그건 QA가 왜 못 잡았죠" 라는 말이다. 같은 원칙을 자신에게 적용한다.

• 사실을 먼저 확인한다 — 테스트 범위에 있었나, 환경에서 재현 가능했나
• 범위에 없었다면 그 사실을 적는다 — "해당 조건은 테스트 범위에 없었습니다. 범위를 어떻게 정했는지 공유하겠습니다"
• 놓쳤다면 인정하고 구조로 넘긴다 — "놓쳤습니다. 어떤 질문이 없었는지 정리해 체크리스트에 더하겠습니다"(모듈 5 레슨 14)

세 번째가 가장 강하다. 변명하지 않고, 동시에 개인의 반성으로 끝내지 않고 다음을 막는 장치로 바꾼다. 이 답을 하는 사람에게는 같은 질문이 다시 오지 않는다.

채용시장에서의 위치

면접에서 이 레슨은 기술 질문이 아니라 상황 질문으로 나온다. 그리고 거의 모든 QA 면접에 한 번은 들어온다.

세 번째가 가장 변별력이 크다. "제가 릴리즈를 막았다" 는 답은 권한을 오해한 것으로 읽힌다. QA의 일은 판단을 대신하는 것이 아니라 판단이 가능하게 만드는 것이고, 이 구분을 아는 지원자는 많지 않다.

네 번째도 함정이다. "틀린 적 없다" 는 답은 기록을 안 남긴다는 뜻으로 읽힐 수 있다. 틀렸던 일을 어떻게 수습했는지가 실제 평가 대상이다.

공고 표현으로는 "협업 능력", "커뮤니케이션 역량", "크로스 펑셔널 협업" 이 이 레슨에 해당한다. 추상적으로 보이지만 면접에서는 구체적인 상황과 문장으로 평가되므로, 위 다섯 줄은 자기 경험으로 바꿔 미리 정리해 둘 가치가 있다.

실습 과제

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

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

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

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

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

과제 3 — 긴급 결함 1차 알림 쓰기 (10분)

운영에서 결제가 전면 실패하는 것을 발견했다. 팀 채널에 올릴 첫 메시지를 3~5줄로 쓴다. 조건은 셋이다 — 영향을 맨 앞에, 사람을 지목하지 않고, 지금 알고 있는 것과 모르는 것을 구분해서.

[긴급] 운영 결제 전면 실패 — 11:42부터 확인
 
· 영향: 모든 결제 수단에서 결제 실패. 우회로 없음
· 재현: 5/5. 일반 계정·관리자 계정 모두
· 확인된 것: 결제 요청에 500 응답. 11:40 배포 직후부터
· 아직 모르는 것: 원인, 실패한 주문의 데이터 상태
 
로그 확인 가능한 분 계실까요? 추가 정보는 이 스레드에 이어 올립니다.

자가 체크리스트

• 비난형 언어와 정보형 언어의 차이를 예시로 설명할 수 있다
• "사람이 아니라 현상을 주어로 삼는다"는 원칙을 적용해 문장을 고쳐 쓸 수 있다
• 결함이 개인의 실수가 아니라 시스템적 결과인 경우가 많은 이유를 설명할 수 있다
• 커뮤니케이션 톤이 결함 수정 속도에 실질적으로 영향을 준다는 것을 설명할 수 있다
• 비난형이 되는 네 가지 패턴(사람 주어·"왜"·평가 부사·되묻는 어미)을 안다
• 한 문장에 섞인 관찰과 평가를 나눌 수 있다
• 평가를 숫자로 바꿔 적을 수 있다("늘 문제가 많다" → "같은 영역 4건")
• 정보형 언어가 완곡어법이 아닌 이유를, 긴급 결함의 예로 설명할 수 있다
• 반려·재현 불가·장기 미수정 상황에서 쓸 문장을 각각 말할 수 있다
• 릴리즈 판단에서 QA가 서는 자리를 설명할 수 있다
• 같은 내용을 공개 채널과 개인 대화 중 어디서 말할지 판단할 수 있다
• 비동기 채널에서 짧은 부정이 차갑게 읽히는 이유를 설명할 수 있다
• 비난이 품질을 떨어뜨리는 이유를 정보가 숨는다로 설명할 수 있다
• 자기 리포트가 틀렸을 때의 수습 방식을 말할 수 있다

흔한 실수

• 사실을 정확히 전달하는 것과 비난하지 않는 것을 대립되는 것으로 착각한다. 정보형 언어도 사실은 똑같이, 오히려 더 명확하게 전달한다 — 다만 사람을 지목하지 않을 뿐이다.
• 텍스트 리포트만 신경 쓰고 구두 대화에서는 비난조를 쓴다. 원칙은 매체와 상관없이 동일하게 적용해야 한다.
• 문제를 부드럽게 포장하려다 정작 심각성이 흐려진다. 정보형 언어는 완곡어법이 아니다 — 사실과 심각도는 명확히, 어조만 비난이 아니게 전달하는 것이 핵심이다.
• 긴급한 것을 부드럽게 쓴다. "시간 되실 때 한번…" 으로 쓰면 상대가 급하지 않은 줄 안다. 사고가 난 뒤 "말은 했는데" 는 전달 실패다.
• 평가 부사를 남긴다. "완전히·기본적인·말도 안 되는·또" 는 사실을 하나도 더하지 않고 상대를 평가만 한다.
• "왜"로 묻는다. 이유를 알고 싶을 때조차 해명 요구로 들린다. "무엇이 막혀 있나요"로 바꾼다.
• 같은 실수를 공개 채널에서 두 번 지목한다. 그 뒤로 상대는 QA를 감시자로 본다. 반복되는 건은 개인 대화로 먼저 간다.
• 부정하는 내용을 한 줄로 던진다. "재현됩니다." 는 반박처럼 읽힌다. 한 문장을 더 붙인다.
• 긴급 건에 이모지와 느낌표로 부드러움을 더한다. 상대가 심각도를 오판한다.
• QA가 릴리즈를 막으려 한다. 사실과 영향을 주고 기록을 남기는 것이 QA의 자리다. 판단은 팀이 한다.
• 자기 리포트가 틀렸을 때 조용히 닫는다. 빠르게 정정하는 사람의 "이건 문제입니다"가 무게를 갖는다.
• 사고 원인을 "부주의"로 적는다. 그러면 고칠 것이 없다. 그 시점에 아무도 그것을 볼 수 없었던 구조를 찾는다.

참고 자료

• Lisa Crispin & Janet Gregory, Agile Testing — QA와 개발의 협업 문화를 다룬 장
• Nonviolent Communication (비폭력대화) 개요 — 관찰과 평가를 구분하는 커뮤니케이션 원칙(결함 리포트에 응용 가능)
• Google re:Work — 심리적 안전 — 비난 없는 환경이 팀 성과로 이어지는 근거

이 커리큘럼 안에서

• 모듈 6 레슨 1 — 심각도·우선순위. "협상 가능한 것"을 구분해 말하는 근거
• 모듈 6 레슨 2 — 결함 리포트. 정확함과 전달 방식은 둘 다 필요하다
• 모듈 6 레슨 4 — 이슈 추적 도구. 어디에 기록이 남는가
• 모듈 4 레슨 5 — Go/No-Go. 릴리즈 판단에서 QA가 서는 자리
• 모듈 5 레슨 13 — 짝 탐험. "같은 화면에서 함께 보기"의 실제 방법
• 모듈 5 레슨 14 — 치트시트. "어떤 질문이 없었나"를 다음으로 넘기는 장치
• 모듈 10 — 결함 분석. 사고 원인을 구조로 적는 절차
• 모듈 1 레슨 6 · 모듈 2 레슨 6 — 이 원칙이 처음 등장한 자리

한 줄 정리 — 비난을 없애는 이유는 착해서가 아니라 비난이 원인 분석을 늦추기 때문이다. 사람을 주어로 쓰지 않고, "왜"를 "무엇"으로 바꾸고, 평가 부사를 지우고, 평가는 숫자로 바꾼다. 그리고 심각성은 절대 깎지 않는다 — 정보형은 완곡어법이 아니다.