올해부터 엔지니어링 팀을 맡으면서, 성과 평가가 “받는 것"에서 “제가 운영해야 하는 것"으로 바뀌었습니다. 이 글은 제 생각을 정리하는 목적도 있으니, 정답이라기보다는 아직 배워가는 사람의 메모로 읽어주시면 좋겠습니다.

애초에 평가를 왜 하는가

#

직급이 무엇이든, 목적은 결국 두 가지입니다. 계속 배울 수 있게 하는 것, 그리고 역할의 기대치를 넘어서는 사람이 제대로 보상받게 하는 것.

“평가할 시간도 여력도 없다"는 작은 회사가 많습니다. 그런 회사는 결국 근속 연수 하나만 보고 누가 시니어가 될 준비가 됐는지 정하게 되죠. 저는 이게 실수라고 생각합니다. 근속이 게으른 지표라서만이 아닙니다. 평가를 생략하면 회사와 직원 사이의 양방향 채널이 사라지고, 일하는 관계 자체가 상하기 때문입니다.

이건 양쪽 모두에 해당합니다. 본인은 회사를 위해 최선이라고 진심으로 믿는 방식으로 일하고 있어도, 습관이나 방법론, 커뮤니케이션 스타일이 안 좋은 쪽으로 흘러갈 수 있습니다. 피드백이 없으면 아무도 그걸 잡아주지 못합니다. 반대로 구조화된 자리에서 직원들의 이야기를 듣지 않는 회사는, 직원들이 회사를 어떻게 생각하는지 모른 채 편안하게 지내게 됩니다.

서로 무엇을 기대하고 들어와야 하나

#

직원 입장에서 기대할 것은 복잡하지 않습니다. 내 일이 팀 목표와 어떻게 연결되는지, 뭘 잘하고 있고 어딜 고쳐야 하는지 알고 싶어 합니다. 그것도 “커뮤니케이션을 더 잘하세요"가 아니라 구체적으로요. 기여를 인정받고 싶고, 커리어와 교육에 대한 진짜 대화를 원하고, 사내 정치가 아니라 일 자체에 기반한 공정한 프로세스를 원합니다.

매니저인 제 입장에서는, 우선 자기 평가를 준비해 오길 기대합니다. 뭐가 잘됐고 뭐가 아쉬웠는지 본인의 시각을 듣고 싶거든요. 변호인의 모두진술이 아니라 피드백에 열린 자세를 바라고, 앞으로의 목표에 대한 진솔한 논의, 그리고 팀 안에서 본인이 어떻게 맞물려 있다고 느끼는지에 대한 솔직한 이야기를 기대합니다. 평가는 제 계획의 시간이기도 합니다. 팀 구성, 승진 후보, 누구에게 어떤 성장 기회가 필요한지.

하나의 틀이 모든 엔지니어에게 맞지는 않는다

#

엔지니어링 팀에는 문화적 배경도, 연차도, 전문 분야도 다른 사람들이 모여 있습니다. 같은 대본이 모두에게 통할 리 없죠. “똑같이 대하는 것"과 “공정하게 대하는 것"은 다른 얘기고, 방식은 각자의 필요, 커리어 단계, 기여에 맞춰 구부러져야 합니다. 기본은 각 엔지니어의 역할과 책임이 명확하고, 그것이 보상과 실제로 맞아떨어지게 하는 것입니다.

제일 꼬이기 쉬운 지점이 직급과 연봉입니다. 타이틀이 애매하다고 느끼거나 승진할 준비가 됐다고 생각하는 사람에게, 두루뭉술한 격려는 독입니다. 통하는 건 구체성입니다. 다음 직급의 기준이 될 구체적인 도전 과제나 프로젝트 목표에 합의해서, 승진이 ‘분위기’가 아니라 객관적 기준이 되게 하는 것. 보상도 마찬가지입니다. 연봉이 낮다고 느끼거나 더 큰 책임을 원하는 사람에게는, 다음 평가 전까지 무엇을 달성해야 그 변화가 정당화되는지 측정 가능한 목표를 플랜에 적어 넣습니다. 그리고 다음 평가에서는 양쪽 모두 그 약속 앞에 정직해져야 합니다.

개선 피드백도 같은 원칙입니다. 특정한 갭을 겨냥한 특정 교육 프로그램, 워크숍, 프로젝트는 도움이 됩니다. “계속 역량을 키우세요"는 도움이 안 됩니다.

기준선은 첫 미팅에서 시작된다

#

새 팀원과의 첫 평가 미팅은 거의 기준선을 잡는 시간입니다. 역할이 실제로 무엇을 포함하는지, 그게 팀과 회사 목표에 어떻게 이어지는지 같이 확인하고, 성과를 판단할 측정 가능한 결과에 합의하고, 단기와 장기 목표를 세웁니다. 컬처와 기대되는 행동, 피드백이 언제 어떻게 오는지, 쓸 수 있는 리소스와 멘토링, 그 자리에서 보이는 커리어 패스를 이야기하기에도 좋은 타이밍입니다. 어느 것도 짜릿하진 않지만, 이걸 해두면 이후의 모든 평가가 쉬워집니다.

그 이후에 쓰는 아젠다

#

1. 스몰토크. 사소해 보여도 이걸로 긴장이 풀리고, 이후 대화가 훨씬 솔직해집니다.
2. 아젠다 훑기. 어느 쪽도 주제에 기습당하지 않도록.
3. 지난 평가 이후의 성장. 발전은 명시적으로 짚어줍니다. 본인은 의외로 모르거든요.
4. 현재 성과. 강점부터.
5. 개선할 부분. 각각 구체적이고 현실적인 목표를 붙여서.
6. 커리어 계획. 지금 하는 일이 실제로 그 방향을 향하고 있는지도 함께.
7. 다음 평가까지의 타깃, 목표, 액션 아이템.

KPI는 개인 맞춤이어야 작동한다

#

프로덕트 팀 엔지니어의 KPI는 팀 목표와 개인 양쪽에 맞아야 합니다. 프론트엔드, 백엔드, 풀스택의 역할이 다르고, 주니어와 시니어의 차이는 더 큽니다. 커밋 수는 주니어 개발자에 대해 뭔가 말해줄 수 있을지 몰라도, 주요 산출물이 아키텍처 의사결정인 시니어 엔지니어에 대해서는 아무것도 말해주지 않습니다. 그래서 KPI는 템플릿을 복사하는 게 아니라 대화 속에서 정하는 겁니다.

제가 보는 영역은 이렇습니다.

• 코드 품질: 에러율, 코딩 표준 준수, 버그 수정이 필요해지는 빈도
• 프로젝트 딜리버리: 마일스톤과 마감 준수
• 혁신과 문제 해결: 효율 개선, 어려운 문제를 실제로 풀어냈는지
• 협업: 피어 리뷰, 팀 목표와 논의에 대한 기여
• 자기 계발: 학습 목표 달성, 자격증, 새로 익힌 기술
• 고객 임팩트: 사용자 피드백, 출시한 기능의 사용 지표

측정 가능한 지표 쪽에서는 요즘 유닛 테스트에 관심이 갑니다. InfoQ의 이 글은 유닛 테스트를 성과 평가에 녹이는 방법을 다루는데, 실무적인 구현과 팀 문화에 미치는 영향을 함께 짚습니다. 코드 건강도를 정성·정량 양쪽으로 보자는 주장이라, 엔지니어를 코드 줄 수로 환원하지 않는 KPI를 찾고 있다면 읽어볼 만합니다.

무엇을 고르든 평가나 1:1에서 함께 합의하고, 역할과 프로젝트와 기술이 바뀌는 만큼 다시 들여다봐야 합니다. 아무도 합의하지 않은 KPI는 그냥 몽둥이일 뿐입니다.

제가 채워 쓰는 템플릿

#

저는 사람마다 문서를 하나씩 두고 평가할 때마다 섹션을 추가합니다. 그러면 히스토리가 한곳에 모이죠. 뼈대는 이렇습니다.

## 성과 평가: [이름], [기간]

**역할과 직급:** [직함, 그리고 이 팀에서 그 직급이 뜻하는 것]
**지난 평가의 목표:** [이전 섹션에서 복사]

### 자기 평가 (엔지니어가 미리 작성)
- 잘된 것, 사례 한두 개와 함께
- 잘 안된 것, 그리고 다시 한다면 무엇을 다르게 할지
- 1년 뒤에 하고 있고 싶은 일

### 지난 평가 목표의 진척
- [목표]: 달성 / 일부 달성 / 미달성, 근거와 함께

### 강점 (구체적인 사례)
- [무엇을, 언제 했고, 그게 무엇을 바꿨는지]

### 개선할 부분 (각각 목표와 함께)
- [행동이나 스킬] → ["더 나아진" 모습] [날짜]까지

### 커리어와 직급
- 다음 직급 기준에 비춰 지금 어디쯤인지, 무엇이 부족한지

### 다음 평가까지의 목표
1. [측정 가능한 목표]
2. [측정 가능한 목표]

### 합의한 액션 아이템
- [누가] [무엇을] [언제까지] 한다

자기 평가는 미팅 하루이틀 전에 받고, 미팅 중에 쓰게 하는 일은 없습니다. 먼저 읽고 들어가면 대화가 달라집니다. 절반쯤은 제가 꺼내려던 얘기를 엔지니어가 이미 직접 적어 와서, 미팅 시간을 “그래서 어떻게 할지"에 쓸 수 있거든요.

자기 평가 질문

#

미리 보내는 질문들입니다. 일부러 열린 질문으로 만들었습니다. 그래야 무엇을 했는지뿐 아니라, 본인이 자기 일을 어떻게 보는지가 답에 드러나니까요.

• 지난 평가 이후 가장 뿌듯했던 일은 무엇이고, 왜 하필 그 일인가요?
• 어디서 막혔고, 무엇이 있었다면 더 빨리 풀렸을까요?
• 팀원이나 리뷰어에게 받은 피드백 중 마음에 남은 게 있나요?
• 지난 평가의 목표 중 달성했다고 생각하는 건 무엇이고, 빼거나 바꾸고 싶은 건 무엇인가요?
• 다음에 배우고 싶은 건 무엇이고, 지금 하는 일이 그럴 기회를 주고 있나요?
• 매니저로서 제가 다르게 해야 할 건 무엇인가요?

마지막 질문에서 가장 어색한 침묵이 흐르고, 가장 쓸모 있는 답이 나옵니다.

구체적인 피드백은 이렇게 들린다

#

나쁜 평가 피드백은 대부분 가혹해서가 아니라 두루뭉술해서 나쁩니다. 차이를 보여 드리면, 제가 쓰려고 애쓰는 피드백은 이런 식입니다.

구체적인 쪽은 모두 실제로 있었던 일을 짚고, 그게 무엇을 바꿨는지 말하고, 그 사람이 다음에 할 수 있는 행동을 가리킵니다. 쓰는 데 시간이 더 걸리죠. 그래서 저는 평가 전날 밤에 기억을 쥐어짜는 대신, 분기 내내 사례를 모아 두도록 스스로를 다그칩니다.

기록으로 남기기

#

미팅이 끝나면 요약을 씁니다. 논의한 핵심, 제기된 이슈, 액션 아이템, 서로 합의한 목표. 관료적으로 들리지만, 이 기록이 있어야 여섯 달 뒤의 “그런 약속 한 적 없는데요” 대화를 막을 수 있습니다. 문서화된 이슈는 증발하지 않고 추적되고, 액션 아이템은 다음 평가의 첫 아젠다가 되고, 문서에 적힌 목표는 훨씬 진지하게 다뤄집니다.

결국 시스템의 전부는 이겁니다. 첫날부터 기대치를 명확히 하고, KPI는 사람에 맞춰 만들고, 전부 기록하고, 모든 액션 아이템을 팔로업하는 것. 양방향 대화와 측정 가능한 결과가 없는 평가는 체크박스 놀음이고, 엔지니어들은 캘린더 초대만 봐도 체크박스 놀음 냄새를 맡습니다.

회의 자체는 쉽습니다

#

구조는 민망할 만큼 단순합니다. 스프린트나 프로젝트 단계가 끝나면 팀이 모여 세 가지 질문에 답하는 게 전부입니다.

1. 무엇이 잘 되었는가?
2. 무엇이 잘 안 되었는가?
3. 무엇을 개선할 수 있는가?

이게 답니다. 핵심은 피드백 루프에 있습니다. 주기적으로 멈춰 서서 실제로 무슨 일이 있었는지 돌아보고, 일하는 방식에 반영하는 것. 멈추지 않는 팀은 같은 일을 반복할 뿐입니다.

쓸모 있는 회고와 푸념 대회의 차이

#

우선 솔직함입니다. 진짜 문제를 입 밖에 낼 수 있는 건 그게 나에게 불리하게 돌아오지 않는다는 확신이 있을 때뿐입니다. 그래서 자리의 안전함이 어떤 포맷을 골랐는지보다 중요합니다. 그리고 가장 날카로운 관찰은 대개 조용한 팀원에게서 나오죠. 리드만 말하는 회고는 절차만 늘어난 스테이터스 미팅입니다.

나머지 절반은 논의 이후에 벌어지는 일입니다. 고칠 가치가 있는 문제라면 담당자와 기한이 붙은 액션 아이템이 되어 회의실을 나가야 합니다. 그리고 — 대부분의 팀이 건너뛰는 부분인데 — 다음 회고는 지난번 액션 아이템 점검으로 시작하세요. 액션 아이템이 장식품이라는 걸 모두가 조용히 깨닫는 순간만큼 회고를 빨리 죽이는 건 없습니다.

가능하면 숫자도 가져오세요. “이번 스프린트는 느린 느낌이었다” 같은 감상은 겉돌기만 하지만, 차트 한 장이면 대개 결론이 납니다.

자주 보이는 실패 패턴

#

가까이서 본 것만 세 가지입니다. 비난전으로 흐르는 회고(고칠 건 시스템이지 사람이 아닙니다), 일 년 내내 똑같은 포맷을 쓰다가 전원이 자동 조종 모드가 되는 회고(형식에 변화를 주세요), 그리고 팔로업이 아예 없는 회고. 위에서 말했듯 마지막이 치명타입니다.

참고로 이건 소프트웨어에만 해당하는 이야기가 아닙니다. 마케팅 캠페인, 행사 운영, 연구 프로젝트, 제조업까지, 사이클이 반복되는 일이라면 어디든 같은 루프가 통합니다. 다만 어디서 하든 판정 기준은 같습니다. 다음 회고 전까지 실제로 뭔가 바뀌었는가? 안 바뀌었다면, 그냥 수다를 떤 겁니다.

여기까지가 짧은 버전입니다. 긴 버전은 아래에 적었습니다. 피드백 대화가 똑같은 식으로 틀어진 적이 인정하기 싫을 만큼 많았거든요. 제가 뭔가를 꺼내면 상대의 어깨에 힘이 들어가고, 그 순간부터 둘 다 상대방 말을 제대로 안 듣게 됩니다.

사람은 애초에 왜 방어적이 될까

#

방어적인 태도는 고집이 아닙니다. 적어도 고집에서 시작하는 경우는 드뭅니다. 위협을 느꼈을 때 사람이 보이는 반응이고, 피드백은 우리가 생각하는 것보다 훨씬 많은 걸 위협합니다. 겉으로는 풀 리퀘스트나 놓친 마감 얘기를 하고 있죠. 하지만 상대에게는 ‘내가 일을 잘하는 사람인가, 이 팀에 있어도 되는 사람인가, 이 사람이 몇 달째 속으로 이렇게 생각해 온 건 아닐까’ 하는 질문으로 들립니다.

그렇게 느끼는 순간 상대의 신경은 제가 하려는 말이 아니라 자기를 지키는 쪽으로 갑니다. 더 세게 주장할수록 그 위협이 진짜라는 걸 확인시켜 줄 뿐입니다. 그래서 아래에 적은 방법 대부분은 먼저 부담을 낮추고, 그다음에야 본론으로 들어가는 이야기입니다.

어떤 사람들은 이미 상처를 안고 이런 대화에 들어온다는 것도 기억해 두면 좋습니다. 입을 열 때마다 비판만 하던 예전 매니저, 실수하면 밀려나던 조직 문화 같은 것들이요. 그 과거를 면담 한 번으로 바꿀 수는 없지만, 가벼운 한마디에 가끔 훨씬 큰 반응이 돌아오는 이유는 이걸로 설명이 됩니다.

대화 전에

#

피드백 대화는 대부분 시작하기 전에 결과가 정해집니다. 예전엔 안 했는데 지금은 하는 것들이 몇 가지 있습니다.

한 가지만 고릅니다. 다섯 가지를 쌓아 뒀다가 꺼내면 상대에게는 피드백이 아니라 죄목을 줄줄이 읽어 내려가는 것처럼 들립니다. 나머지 넷은 기다려도 되고, 알고 보면 첫 번째 문제의 증상인 경우도 많습니다.

빨리 합니다. 6주 전 일에 대한 피드백은 “왜 이제 와서 얘기하세요?“로 받아들여집니다. 타당한 질문인데 마땅한 답이 없죠. 일이 있고 하루 이틀 뒤가 적당합니다. 기억이 생생할 만큼 이르고, 둘 다 감정이 가라앉았을 만큼은 늦은 시점입니다.

따로 만나서 하고, 피할 수 있으면 채팅으로는 하지 않습니다. 글로 된 피드백은 어조가 빠지고, 방어적인 사람은 그 빈자리를 가장 나쁜 버전으로 채워서 읽습니다. 팀이 원격이거나 시간대가 달라서 꼭 글로 해야 한다면 짧게 쓰고 통화를 제안합니다.

그리고 제 상태를 점검합니다. 제가 짜증이 나 있으면 어떤 단어를 고르든 상대는 첫 문장에서 알아챕니다. 제가 했던 피드백 중에는 짜증이 가라앉을 때까지 기다렸다면 훨씬 잘 풀렸을 것들이 있습니다.

실제로 무슨 말을 할까

#

제가 결국 계속 돌아가는 구조는 흔히 상황-행동-영향(SBI)이라고 부르는 방식입니다. 언제 있었던 일인지, 상대가 무엇을 했는지, 그게 어떤 결과를 낳았는지. 핵심은 각 부분이 눈으로 확인할 수 있는 것이라는 점입니다. 상대가 어떤 사람인지는 하나도 들어가지 않고, 무슨 일이 있었는지만 들어갑니다.

실제로 어떻게 다른지 보죠. 어떤 개발자가 금요일 오후에 리뷰를 기다리지 않고 변경을 머지했고, 그 때문에 주말 동안 결제 기능이 깨졌다고 해 봅시다.

벽을 세우게 만드는 버전: “항상 일을 급하게 내보내시네요. 좀 더 신중하셔야 해요.”

그나마 가능성이 있는 버전: “금요일에 결제 관련 변경이 리뷰 없이 들어갔고, 토요일에 몇 시간 동안 결제가 안 됐습니다. 무슨 일이 있었는지 알고 싶어요. 부주의해서 그랬다고는 생각하지 않거든요.”

두 번째는 사건 하나를 짚고, 그 대가가 뭐였는지 담백하게 말하고, 선의를 전제하며 끝납니다. 가장 큰 상처를 내는 말은 “항상"과 “절대"입니다. 한 번의 일을 성격에 대한 판단으로 바꿔 버리고, 상대는 곧바로 제가 틀렸다는 걸 증명할 반례를 떠올립니다.

관찰의 주어를 저로 두려고도 합니다. “제가 보기에는”, “조금 걱정이 돼서요” 같은 말은 이게 어디까지나 제 쪽에서 본 시각이라는 걸 솔직하게 드러내고, 제가 놓친 게 있을 여지도 남겨 줍니다. 실제로 놓친 경우가 많고요.

그다음엔 말을 멈추고 묻습니다. “그쪽에서는 어떻게 보였어요?” 다른 사람이 정한 마감이라든가, 리뷰어가 병가 중이었다든가, 제가 몰랐던 맥락이 대개 있습니다. 설령 없더라도, 이 질문 하나가 이건 판결이 아니라 대화라는 걸 상대에게 알려 줍니다.

피드백은 앞으로의 방향이 붙어 있을 때 훨씬 잘 받아들여집니다. 문제 목록이 아니라 “다음번엔 이렇게 해 보면 어떨까요?” 같은 것이요. 그 방향이 상대 입에서 나오면 더 좋습니다.

그래도 반발할 때

#

다 제대로 해도 저항이 올 수 있습니다. 대개 알아볼 만한 몇 가지 형태로 오고, 형태마다 대응이 조금씩 다릅니다.

가장 흔한 건 부정입니다. “그런 일 없었는데요.” 이걸로 다투지 마세요. 커밋, 메시지, 날짜처럼 둘 다 볼 수 있는 것으로 돌아가서, 제가 뭘 놓치고 있는지 묻습니다. 사실관계 자체가 정말 엇갈린다면 “둘 다 한번 다시 확인해 보고 내일 이어서 얘기하죠"라고 해도 괜찮습니다.

다음은 화살 돌리기입니다. “요구사항이 계속 바뀌었잖아요"나 “누구누구도 그렇게 하는데요” 같은 거죠. 일리가 있는 경우가 많으니 무시하지 말고 인정합니다. “맞아요, 요구사항 문제도 고쳐야죠.” 그리고 부드럽게 다시 가져옵니다. “그거랑 별개로, 리뷰 단계 얘기를 하고 싶어요.”

“그쪽도 맨날 리뷰 없이 머지하잖아요” 같은 역공은 똑같이 받아치지 않기가 제일 어렵습니다. 숨을 한번 고르세요. 상대 말이 맞다면 맞다고 하세요. 분위기를 가라앉히는 가장 빠른 방법이고, 상대에게 바라는 열린 태도를 방금 제가 먼저 보여 준 셈이기도 합니다. 그런 다음 원래 얘기로 돌아옵니다.

입을 닫아 버리는 경우도 있습니다. 침묵이든 “네, 말씀대로 하죠"든, 동의처럼 보이지만 동의가 아닙니다. 저는 “이 얘기가 잘 안 와닿은 것 같네요. 괜찮아요” 정도로 부드럽게 짚고, 나중에 이어서 하자고 제안합니다. 마음을 닫은 사람에게서 억지로 대답을 받아 내면 가짜 대답만 돌아옵니다.

과하게 사과하는 것(“제가 이런 걸 진짜 못해요, 정말 죄송해요”)도 방어입니다. 방향이 안쪽을 향할 뿐이죠. 비판이 들어오기 전에 먼저 자기를 깎아내리면서 스스로를 지키는 겁니다. 이건 특정한 한 가지 얘기일 뿐 전체 성과에 대한 얘기가 아니라고 안심시키고, 앞으로 어떻게 할지로 넘어갑니다.

이 모든 경우에 제가 지키려는 원칙은 하나, 상대의 텐션에 말려들지 않는 것입니다. 상대가 방어적으로 나오면 제 본능도 똑같이 방어적으로 되받으려 하는데, 대화를 확실하게 망치는 수가 딱 그거 하나입니다. 제가 차분함을 유지하면 분위기는 대개 알아서 가라앉더군요. “이 얘기 듣기 답답하실 거 알아요"처럼 감정을 말로 꺼내 주는 것도 도움이 됩니다. 긴장이 없는 척하는 것보다 훨씬 낫습니다.

멈출 때를 알기

#

이 모든 게 안 통하고 벽이 안 내려올 때도 있습니다. 그 시점에서 더 밀어붙여 봐야 얻는 게 없습니다. 대화를 잠시 접어 두고, 상황이 좀 가라앉은 하루 이틀 뒤에 다시 꺼내면 됩니다. 피드백의 내용은 내일이 되어도 여전히 사실이고, 사람은 하룻밤 자고 나면 훨씬 차분하게 돌아보는 경우가 많습니다. 제가 했던 후속 대화 중 가장 좋았던 몇 번은 상대가 “그때 하신 말씀, 계속 생각해 봤는데요"라며 먼저 시작했습니다.

이걸 배우는 데 제일 오래 걸렸습니다.

대화가 끝난 뒤

#

그다음 일주일 동안 일어나는 일이 대화 자체만큼 중요합니다. 상대가 행동을 바꿨다면 알아챘다고, 분명하게, 빨리 말해 주세요. 그래야 저한테서 오는 피드백이 늘 나쁜 소식만은 아니라는 걸 상대가 알게 되고, 다음 대화도 쉬워집니다.

그리고 상황이 맞으면 피드백이 어떻게 받아들여졌는지 물어봅니다. “아까 얘기, 공정했나요?” 이 한마디가 대화의 균형을 잡아 주고, 상대에게 바라는 열린 태도를 먼저 보여 줍니다. 매니저가 되고 나서 이걸 습관처럼 하기 시작했는데, 제 머릿속에서는 분명했지만 입 밖으로는 그만큼 분명하지 않았던 경우를 몇 번 잡아냈습니다.

정리하면

#

문제를 꺼내기 전에 위협감부터 낮추세요. 한 가지를 골라 따로, 빨리 꺼내고, 사람이 아니라 행동과 그 영향을 말하고, 해결책을 내놓기 전에 상대 이야기를 먼저 들으세요. 상대가 반발하면 맞받아치지 마세요. 감정을 인정하고, 사실로 돌아가고, 멈췄다가 다른 날 이어 가도 된다는 여유를 가지세요. 그리고 꼭 후속으로 챙기세요. 신뢰는 대화 이후의 대화에서 쌓입니다.