Solomon
피드백을 전할 때 무엇을 말하고 무엇을 말하지 않을 것인가
사람이 아니라 행동과 결과를 다루면 방어가 줄어든다. 전달 구조와 흔한 실패.
사람이 아니라 행동
피드백이 방어를 부르는 대부분의 경우는 사람에 대한 판정으로 전달되기 때문이다.
| 사람 평가 | 행동·결과 서술 |
|---|---|
| "꼼꼼하지 않으시네요" | "PR에 디버그 로그가 세 번 남아 있었습니다" |
| "소통이 부족합니다" | "일정이 이틀 밀린 걸 마감일에 알게 됐습니다" |
| "적극성이 없어요" | "회의에서 의견을 안 내셔서 동의하신 걸로 봤는데, 나중에 다른 의견이 있으셨더군요" |
오른쪽은 반박할 여지가 사실 확인 수준으로 좁혀진다. 왼쪽은 성격에 대한 판정이라 방어할 수밖에 없다.
구조
전달 순서는 세 부분이면 충분하다.
```
- 관찰한 사실 (언제, 무엇이)
- 그로 인한 영향 (무엇이 어려웠는지)
- 요청 (앞으로 무엇을 바라는지)
```
예:
```
지난 PR 세 건에 디버그 로그가 남아 있었습니다. (사실)
리뷰에서 매번 지적하느라 병합이 하루씩 늦어졌어요. (영향)
올리기 전에 diff를 한 번 훑어주시면 좋겠습니다. (요청)
```
2번(영향)이 자주 빠진다. 영향이 없으면 왜 고쳐야 하는지 설득력이 없고, 취향 문제로 들린다.
칭찬을 앞에 붙이는 방식
좋은 말 → 지적 → 좋은 말 구조가 널리 알려져 있지만, 반복되면 역효과가 난다. 칭찬이 나오는 순간 "이제 지적이 오겠구나"로 읽히고, 그러면 칭찬 자체의 신뢰가 사라진다.
대안은 분리다.
- 잘한 것은 그 자리에서 그것만 말한다
- 개선 요청은 별도로 사안만 다룬다
시점
사실 확인이 끝났다면 이를수록 낫다. 시간이 지나면:
- 세부가 흐려져 "그때 그랬잖아요" 수준이 된다
- 여러 건이 쌓여 한꺼번에 전달되며 강도가 커진다
- 받는 쪽은 "왜 진작 말 안 했나"를 먼저 느낀다
예외는 감정이 격한 경우다. 이때는 반나절 정도 두는 편이 낫다.
자리 선택
| 유형 | 자리 |
|---|---|
| 긍정 피드백 | 공개 (팀 채널·회의) |
| 개선 요청 | 1:1 |
| 절차·규칙 문제 | 팀 전체 (개인 지목 없이) |
세 번째가 유용하다. 여러 사람이 같은 문제를 보이면 개인 피드백보다 규칙을 다시 정하는 편이 효율적이다.
받는 쪽에서
피드백을 받을 때 즉시 반박하거나 즉시 수긍하는 것 둘 다 좋지 않다.
- 사실관계가 다르면 그 부분만 확인한다
- 해석이 다르면 어떤 상황이었는지 설명한다
- 맞다면 무엇을 어떻게 바꿀지 구체적으로 답한다
"알겠습니다"만으로 끝내면 무엇이 달라질지 서로 모른 채 끝난다.
이어지는 확인
피드백 후 변화가 있었는지 확인하는 절차가 없으면, 같은 피드백이 반복되거나 아예 포기하게 된다.
몇 주 뒤 짧게 언급하는 정도면 된다.
```
"요즘 PR 정리돼서 리뷰가 빨라졌어요."
```
개선을 알아차렸다는 신호가 다음 피드백의 수용도를 높인다.
최종 수정 2026-08-28