목차9개 항목
출처와 참고
Evan Smith의 「Kind Engineering: How To Engineer Kindness」를 바탕으로 재구성한 노트다. 「기술 업계의 독성 말투 문제, 고칩시다!」의 내용을 더해 보강했다.
친절이란
친절(kind)은 상대에게 관심을 쏟고, 그가 있는 자리에서 그를 돕는 것이다. 상대의 입장과 감정, 배경을 고려해 무엇이 실제로 도움이 되는지 찾는다. 공감, 좋은 소통, 자신과 동료에게 정직한 태도로 이뤄진다.
| 다정함(nice) | 친절함(kind) | |
|---|---|---|
| 무엇 | 겉으로 드러나는 예의, 상냥함 | 상대의 성장과 성공에 적극적으로 관여 |
| 예 | 팀에 케이크를 사 온다 | 매니저에게 "이 사람 일 잘한다, 다음 리드로 고려해 달라"고 말한다. 당사자는 모를 수도 있다 |
| 피드백 | 듣기 좋은 말만 한다 | 불편해도 성장에 필요한 말을 한다 |
친절은 한 번에 모든 문제를 푸는 도구가 아니다. 사람마다 다르게 적용되고, 신뢰가 쌓여야 가능하다. 애덤 그랜트의 『기브 앤 테이크』가 말하는 기버(giver), 즉 받는 것보다 더 주는 사람이 지속 가능한 방식으로 줄 때 더 생산적이고 도움도 더 많이 받는다는 관찰과 같은 맥락이다.
1. 정직: 신뢰를 쌓고 직접 말한다
- "그냥 프로페셔널"을 넘어선다. 일 바깥의 관심사와 이야기를 적당히 나누면 서로를 사람으로 이해하게 되고, 동료가 힘들 때 알아차릴 수 있다. 다만 어디까지 말할지 경계는 스스로 정한다. 회사에 나를 다 바치라는 뜻이 아니다.
- 개인적으로 신경 쓰면서 직접 말한다. 킴 스콧의 『실리콘밸리의 팀장들(Radical Candor)』이 말하는 두 축이다. 정직이 빠지면 피드백이 쓸모없고, 공감이 빠지면 상대가 받아들이지 못한다. "가차 없는 솔직함"과는 다르다.
- 선의의 거짓말은 성장을 막는다. 설득에 실패한 회의 뒤에 "잘했어"라고 하면, 나중에 결과를 안 상대는 내 피드백 전체를 의심한다. 잘된 점, 안된 점, 다음에 해 볼 것을 함께 말한다.
"질문에 답이 길어져서 설득할 기회를 놓쳤어. 아이디어는 좋으니까 엘리베이터 피치를 연습하면 다음엔 될 거야."
2. 비동기 소통: 코드 리뷰
PR은 변화를 다루는 가장 강력한 비동기 도구다. 체크박스 채우기가 아니라 변경과 그 맥락을 이해할 때까지 파고든다. 코멘트 쓰는 요령(이유와 대안, 질문형, must·suggestion·nit 표시)은 코드 리뷰 커뮤니케이션에 있다. 여기서는 태도만 정리한다.
| 원칙 | 내용 |
|---|---|
| 무엇·어떻게보다 왜를 이해한다 | 취조가 아니라 호기심의 어조로. 왜 이걸 지웠는지, 왜 여기에 유틸 함수를 뒀는지 상대 입장에서 생각한다 |
| 악의나 무능을 가정하지 않는다 | 내가 뭔가 놓쳤을 수 있다고 보고, 정정 대신 설명을 청한다. "이건 틀렸어요", "우리는 이렇게 해요"로 시작하지 않는다 |
| 열린 질문을 쓴다 | 단정 대신 질문하면 상대가 빠진 맥락을 채울 기회를 얻는다 |
| 사소한 지적은 표시한다 | nit:을 붙이면 바쁜 사람이 건너뛸 수 있다. 같은 nit을 반복한다면 사람이 아니라 린터·포매터가 할 일이다. 사람은 동료의 지적엔 서운해도 도구의 지적엔 그러지 않는다 |
| 코멘트가 많아지면 대화로 바꾼다 | 핑퐁이 길어지면 빠진 맥락이 있다는 신호다. 공개된 PR에 비판이 쌓이면 망신처럼 느껴진다. 실시간으로, 비공개로 이야기하는 쪽을 기본값으로 둔다 |
3. 심리적 안전감
문제를 발견했을 때 말하고 고칠 수 있다고 느끼는가. 기술 문제만이 아니라 포용, 불편함, 책임 추궁까지 포함한다. 안전하지 않으면 회의에서 말을 아끼고, 다가오는 실수를 보고도 침묵한다. 협업에서의 정의는 협업을 잘하는 개발자에 있다.
| 실천 | 방법 |
|---|---|
| 피드백을 먼저 청한다 | 특히 부정적인 피드백을. 내가 먼저 취약해지면 나중에 내가 주는 피드백도 받아들여진다. 회고처럼 "계속할 것·그만할 것·새로 할 것"으로 묻고, 말해 준 사람에게 고맙다고 한다 |
| 포용한다 | 회의에서 말이 적은 사람에게 발언 기회를 주거나, 자료를 미리 공유하고 익명 의견 창구를 두어 각자 편한 방식으로 말하게 한다. "중간에서 만나자"가 아니라 상대가 있는 자리로 간다 |
| 비난하지 않는다 | 개인의 실수는 대개 프로세스·환경·워크플로의 실패다. "그 실수를 할 수 있는 자리에 둔 것은 팀"이다. 탓하면 보고서가 축소되고 왜곡된다. 비난이 없다는 것이 반복되는 문제에 책임이 없다는 뜻은 아니다 |
| 실패를 배움으로 바꾼다 | 장애는 배울 기회다. 같은 세 질문으로 원인을 뜯어보고 포스트모템으로 공유한다. 실험과 위험 감수가 안전해야 혁신이 나온다 |
4. 피드백을 받는 법과 주는 법
공통 원칙은 네 가지다.
- 비판은 주기 전에 먼저 청한다. 양방향이어야 신뢰가 생긴다.
- 사람이 아니라 일과 행동을 말한다. 실수는 인격의 결함이 아니다.
- 구체적으로 말한다. 비판은 분석하기 쉬워지고, 칭찬은 진심으로 들린다.
- 비판에는 가능하면 해결책이나 첫걸음을 붙인다.
받을 때
| 단계 | 내용 |
|---|---|
| 내 선호를 안다 | 공개·비공개, 글·대면 중 어떤 방식이 편한지 알고 동료에게도 알린다 |
| 듣고, 이해하고, 고맙다고 한다 | 부정적인 피드백을 주는 일은 어렵다. 결국 동의하지 않더라도 끝까지 듣는다 |
| 그 자리에서 반응하지 않는다 | 방어적인 감정은 자연스럽다. 15분이라도 산책하거나 차를 마시며 정리한 뒤 판단한다 |
| 구체적인 예를 묻는다 | 들은 말만으로 고칠 수 없으면 다시 묻는다. 듣고 있다는 신호가 되어 관계도 좋아진다 |
줄 때: 감정, 신뢰, 논리
| 요소 | 내용 |
|---|---|
| 감정(Emotion) | 내 감정이 아니라 듣는 사람의 감정을 고려한다. 그 일로 화가 났다면 감정이 가라앉은 뒤에 말한다 |
| 신뢰(Credibility) | 전문성과 겸손을 함께 보인다. 구체적인 조언과 함께 잘된 점도 짚는다 |
| 논리(Logic) | 어떻게 그 결론에 이르렀는지 보여 준다. 상대가 빠진 맥락이나 허점을 찾을 수 있게 한다 |
5. 독성 말투 세 가지
친절의 반대편에는 기술 업계에 흔한 독성 말투가 있다. 질문·답변·리뷰·오픈소스 기여를 위축시켜 팀 생산성과 커뮤니티를 함께 깎는다.
| 유형 | 모습 | 바꾸는 법 |
|---|---|---|
| 거들먹거림 | 초보 질문에 짜증 내기, 비전공·부트캠프 출신 깎아내리기, 「비개발자」로 다른 직군 낮추기, 설명 대신 검색 링크만 던지기 | 처음 배울 때를 떠올려 쉬운 말과 자료로 설명한다. 상대가 더 잘 아는 영역이 있음을 인정한다. 리더는 이런 행동에 보상하지 않는다 |
| 기계적 말투 | 감정과 맥락 없이 결함만 짚기, 장애·서비스 종료 소식을 공감 없이 전하기 | 강점을 먼저 인정하고, 단정 대신 질문으로 묻는다(「이 제목을 고른 이유를 설명해 줄 수 있나요?」). 신뢰 관계에 맞춰 전달 방식을 고른다 |
| 비관적 말투 | 검토 없이 「안 될 거야」, 「확장 안 돼」, 한 번의 실패를 모든 시도에 일반화, 습관적 반대 | 확신 대신 우려와 근거를 나눈다. 「맞아요, 그리고…」로 장점을 먼저 보고 보완점을 더한다. 과거 실패가 도구 탓인지 당시 맥락 탓인지 따져 본다 |
사람은 위협을 느끼면 분석력과 창의성이 떨어진다. 말투를 고치는 것은 예의의 문제가 아니라 팀이 생각하는 능력의 문제다. 자기 피로나 불안이 말투에 섞이고 있지 않은지도 점검한다.
정리
- 친절은 예의가 아니라 관여다. 상대가 있는 자리에서 그를 돕는다.
- 정직하되 개인적으로 신경 쓴다. 선의의 거짓말 대신 잘된 점·안된 점·다음 걸음을 말한다.
- 리뷰에서는 왜를 묻고, nit은 표시하거나 도구에 맡기고, 길어지면 비공개 대화로 옮긴다.
- 심리적 안전감은 피드백을 먼저 청하고, 포용하고, 탓하지 않고, 실패에서 배우는 데서 나온다.
- 피드백은 받을 땐 듣고 고마워하고 시간을 두며, 줄 땐 감정·신뢰·논리를 챙긴다.
관련 노트: 협업을 잘하는 개발자, 코드 리뷰 커뮤니케이션, 페어 프로그래밍, 회사에서 빠르게 성장하는 법, 개발자에서 리더로