<div id="readability-page-1" class="page"><div><blockquote>feedback — helpful information or criticism that is given to someone to say what can be done to improve a performance, product, etc. (출처 — 네이버 사전)</blockquote>동료에게 피드백을 주는 목적은 피드백을 받는 사람이 일을 더 잘해서, 결국 우리가 함께 성과를 내고 성장하기 위함이다. 그러기 위해 동료가 목표를 향해 올바른 방향으로 가고 있지 않다면, 정확하고 유용한 정보를 제공해서 방향을 재정비할 수 있도록 도와야 한다. 이미 피드백을 주고/받는 방법에 대해서 이야기하는 좋은 책들이 많다. 나 역시 ‘실리콘밸리의 팀장들’, ‘함께 자라기’ 등 책의 도움을 많이 받았다.그런데 결국, 피드백을 주고받는 사람 간의 ‘신뢰’ 가 없다면 그 피드백의 쓸모는 0에 가까워진다. 피드백에 진짜 귀를 기울이게 될 때는 본인이 하고 싶은 말을 하는 게 아니라, 온전히 피드백을 받는 사람을 위함이 느껴질 때다. 이것은 많은 부분 ‘태도’ 에서 시작된다고 생각한다.<h2 id="3314">상대방을 온전히 이해하려는 시도</h2>옛 동료들과 <a href="https://youtu.be/iiXDssiA_Ts?si=09qsKnk9TUh15wAH" rel="noopener ugc nofollow" target="_blank">문해력 이슈 | 문제는 영상 때문이다</a> 라는 유튜브 영상을 보고 ‘비난’ 과 ‘비판’ 에 대해 이야기를 나눈 기억이 있다. 해당 영상에서 조병영 교수는 비난은 ‘상대의 잘못된 점을 끄집어내서 물고 늘어지는 것’, 비판은 ‘상대의 행동을 정확히 이해한 뒤 개선점을 찾는 것’ 이라고 이야기한다. 우리가 익히 알고 있는 정의이며, 동료에게 향하는 피드백은 비난이 아닌 비판에 가까워야 한다는 것에 대해 이견이 없을 것이다.즉, 동료에게 향하는 피드백은 비판의 정의처럼 ‘상대의 행동을 정확히 이해하는 것’ 이 선행되어야 한다. 주니어 개발자가 API 평균 latency를 1초에서 0.1초로 개선한 행동을 보고 ‘지금 그게 중요해?’ 혹은 ‘제대로 측정한 거 맞아?’ 라는 의심이 아니라, ‘왜 API 평균 latency 1초가 문제라고 판단했을까?’ ‘평균 latency 측정은 어떻게 했을까?’ 라는 호기심을 가져야 한다.호기심을 기반으로 상대방을 온전히 이해하려 노력했을 때 피드백에 대한 수용으로 이어질 수 있다. 가끔은 잘 듣기만 하는 일로도 상대방의 마음이 열려, 이후 피드백에 대한 쓸모가 높아지는 일이 많다.<figure><figcaption>출처 — 유 퀴즈 온 더 튜브 유튜브</figcaption></figure><h2 id="869f">나는 다 알고 있다는 생각 버리기</h2>사실 피드백을 주는 사람이 (절대적인 혹은 특정 분야에 대한)경험이 더 많은 경우, 상대방에게 호기심이 아닌 의심으로 다가가기 쉬운 것 같다. ‘내가 해봐서 아는데..’ 의 꼰대력이 튀어나오기 좋다. 이 생각은 상대방에게 들키기 쉬워(?) 피드백을 듣는 사람이 귀를 여는데 방해가 된다. 당연하다. 어차피 나를 이해할 마음이 없는(= 내 경험이 답이야) 사람의 ‘피드백을 가장한 하고 싶은 말’ 을 듣고자 하는 사람이 얼마나 될까? 이 경우 아무리 의미있는 내용이라도 묘하게 감정이 더 크게남아 온전히 가닿지 않게 된다.‘내가 해봐서 아는데..’ 의 경험 자체는 분명 가치를 지니고 있다. 다만 ‘그래서 너는 틀렸다’ 는 생각이 아닌 ‘내 경험이 도움이 될 수 있을까’ 의 방향으로 가야한다. 그래야 피드백의 쓸모가 생기고, 그 과정에서 내가 틀렸을 수도 있는 성장 가능성을 놓치지 않을 수 있다. 생각의 방향을 고치는 일은 쉽지 않지만 분명 노력해야 하는 부분이다.또한, ‘내가 해봐서 아는데..’ 를 놓음으로써 상대방의 문제를 지적하는 것에서 끝나지 않고, 상황에 맞는 개선에 대한 이야기가 가능하다.<blockquote>많은 상사가 무의식적인 차원에서 직원을 무시해도 되거나 자신보다 열등한 사람으로 바라보곤 한다. 반대로 직원은 이러한 상사를 맞서 싸워야 할 폭군으로 바라본다. (…) 이러한 분위기가 조직문화로 자리 잡으면 지적은 개선을 위한 도구가 아니라 상대를 해치는 무기가 된다. 지적을 할 수 있는 사람은 스스로를 힘 있는 존재로 느끼고, 당하는 사람은 위축감을 느낀다.출처 — 책 ‘실리콘밸리의 팀장들’</blockquote></div><div>그냥 지나칠 수 있는 SNS 상의 짧은 글이었지만, 피드백을 받는 입장과 피드백을 주는 입장 모두 충분히 겪다보니 다양한 기억이 떠올랐다. 그 기억에는 기분이 나쁜 감정만 남았던 일도, 분명 도움되는 말이었지만 무시당한 일도, 상대를 고려하지 않고 너무 내 말만 넘치지 않았나 하는 후회도, 안해도 될 말로 상대에게 무례했던 경험도 모두 포함된다. 그래서 이렇게 단상을 남긴다.매니저 역할을 해오면서 내가 가장 에너지를 쏟는 부분은 ‘각 동료에게 적합한 피드백 방식을 찾는 일’ 이다. 절대로 좋은 사람이 되기 위해 하는 일이 아니다. 어떤 문제에 대한 개선 방법이 정해져 있을지라도, 이 방법이 수용되기까지는 사람을 놓을 수 없기 때문이다.다시 언급하자면 피드백을 주는 목적은 피드백을 받는 사람이 일을 더 잘해서, 결국 우리가 함께 성과를 내고 성장하기 위함이다. 상대방에게 피드백이 온전히 전달되어 진짜 변화를 이끌어내고 함께 성과를 내기 위해서라도, 피드백을 전하는 우리의 태도에는 고찰이 필요하다. 나에게 상대방을 온전히 이해하려는 시도와 내 경험이 항상 정답은 아니라는 생각은 의식적으로 놓지 않아야 하는 중요한 일이다.</div></div>

Stories by Mijeong (Rachel) on Medium

얼마 전 페이스북과 트위터에서 공유되는 한 글을 봤다. ‘주니어 개발자가 API의 평균 latency를 1초에서 0.1초로 개선’ 했을 때 사람들의 반응을 볼 수 있는 글이었다. 그 반응은 대기업과 스타트업 환경의 차이, 시니어 개발자가 주니어 개발자를 바라보는 관점 등에 관한 것이었다.
나는 원글과 원글을 인용하며 작성된 글들을 보며 불편함이 떠나질 않았다. 이 불편함의 근원이 무엇일까 생각하다가 알아챘다. 단 한 분을 제외하고 누구도 그 주니어 개발자 입장을 고려해서 반응하는 사람이 없다는 것을. 그 한 분의 반응은 “저라면 왜 개선했는지부터 들어보고 적절한 피드백을 하겠습니다” 였고, 나는 좋아요를 꾹 눌렀다.
‘왜 주니어 개발자가 하지 않아도 될 일을 했다는 확신이 전제에 깔려있는 거지?’ 라는 의구심이 계기가 되어 피드백을 주는 사람의 태도에 대해 이야기하고 싶었다.
feedback — helpful information or criticism that is given to someone to say what can be done to improve a performance, product, etc. (출처 — 네이버 사전)
동료에게 피드백을 주는 목적은 피드백을 받는 사람이 일을 더 잘해서, 결국 우리가 함께 성과를 내고 성장하기 위함이다. 그러기 위해 동료가 목표를 향해 올바른 방향으로 가고 있지 않다면, 정확하고 유용한 정보를 제공해서 방향을 재정비할 수 있도록 도와야 한다. 이미 피드백을 주고/받는 방법에 대해서 이야기하는 좋은 책들이 많다. 나 역시 ‘실리콘밸리의 팀장들’, ‘함께 자라기’ 등 책의 도움을 많이 받았다.
그런데 결국, 피드백을 주고받는 사람 간의 ‘신뢰’ 가 없다면 그 피드백의 쓸모는 0에 가까워진다. 피드백에 진짜 귀를 기울이게 될 때는 본인이 하고 싶은 말을 하는 게 아니라, 온전히 피드백을 받는 사람을 위함이 느껴질 때다. 이것은 많은 부분 ‘태도’ 에서 시작된다고 생각한다.
상대방을 온전히 이해하려는 시도
옛 동료들과 문해력 이슈 | 문제는 영상 때문이다 라는 유튜브 영상을 보고 ‘비난’ 과 ‘비판’ 에 대해 이야기를 나눈 기억이 있다. 해당 영상에서 조병영 교수는 비난은 ‘상대의 잘못된 점을 끄집어내서 물고 늘어지는 것’, 비판은 ‘상대의 행동을 정확히 이해한 뒤 개선점을 찾는 것’ 이라고 이야기한다. 우리가 익히 알고 있는 정의이며, 동료에게 향하는 피드백은 비난이 아닌 비판에 가까워야 한다는 것에 대해 이견이 없을 것이다.
즉, 동료에게 향하는 피드백은 비판의 정의처럼 ‘상대의 행동을 정확히 이해하는 것’ 이 선행되어야 한다. 주니어 개발자가 API 평균 latency를 1초에서 0.1초로 개선한 행동을 보고 ‘지금 그게 중요해?’ 혹은 ‘제대로 측정한 거 맞아?’ 라는 의심이 아니라, ‘왜 API 평균 latency 1초가 문제라고 판단했을까?’ ‘평균 latency 측정은 어떻게 했을까?’ 라는 호기심을 가져야 한다.
호기심을 기반으로 상대방을 온전히 이해하려 노력했을 때 피드백에 대한 수용으로 이어질 수 있다. 가끔은 잘 듣기만 하는 일로도 상대방의 마음이 열려, 이후 피드백에 대한 쓸모가 높아지는 일이 많다.
나는 다 알고 있다는 생각 버리기
사실 피드백을 주는 사람이 (절대적인 혹은 특정 분야에 대한)경험이 더 많은 경우, 상대방에게 호기심이 아닌 의심으로 다가가기 쉬운 것 같다. ‘내가 해봐서 아는데..’ 의 꼰대력이 튀어나오기 좋다. 이 생각은 상대방에게 들키기 쉬워(?) 피드백을 듣는 사람이 귀를 여는데 방해가 된다. 당연하다. 어차피 나를 이해할 마음이 없는(= 내 경험이 답이야) 사람의 ‘피드백을 가장한 하고 싶은 말’ 을 듣고자 하는 사람이 얼마나 될까? 이 경우 아무리 의미있는 내용이라도 묘하게 감정이 더 크게남아 온전히 가닿지 않게 된다.
‘내가 해봐서 아는데..’ 의 경험 자체는 분명 가치를 지니고 있다. 다만 ‘그래서 너는 틀렸다’ 는 생각이 아닌 ‘내 경험이 도움이 될 수 있을까’ 의 방향으로 가야한다. 그래야 피드백의 쓸모가 생기고, 그 과정에서 내가 틀렸을 수도 있는 성장 가능성을 놓치지 않을 수 있다. 생각의 방향을 고치는 일은 쉽지 않지만 분명 노력해야 하는 부분이다.
또한, ‘내가 해봐서 아는데..’ 를 놓음으로써 상대방의 문제를 지적하는 것에서 끝나지 않고, 상황에 맞는 개선에 대한 이야기가 가능하다.
많은 상사가 무의식적인 차원에서 직원을 무시해도 되거나 자신보다 열등한 사람으로 바라보곤 한다. 반대로 직원은 이러한 상사를 맞서 싸워야 할 폭군으로 바라본다. (…) 이러한 분위기가 조직문화로 자리 잡으면 지적은 개선을 위한 도구가 아니라 상대를 해치는 무기가 된다. 지적을 할 수 있는 사람은 스스로를 힘 있는 존재로 느끼고, 당하는 사람은 위축감을 느낀다.
출처 — 책 ‘실리콘밸리의 팀장들’
그냥 지나칠 수 있는 SNS 상의 짧은 글이었지만, 피드백을 받는 입장과 피드백을 주는 입장 모두 충분히 겪다보니 다양한 기억이 떠올랐다. 그 기억에는 기분이 나쁜 감정만 남았던 일도, 분명 도움되는 말이었지만 무시당한 일도, 상대를 고려하지 않고 너무 내 말만 넘치지 않았나 하는 후회도, 안해도 될 말로 상대에게 무례했던 경험도 모두 포함된다. 그래서 이렇게 단상을 남긴다.
매니저 역할을 해오면서 내가 가장 에너지를 쏟는 부분은 ‘각 동료에게 적합한 피드백 방식을 찾는 일’ 이다. 절대로 좋은 사람이 되기 위해 하는 일이 아니다. 어떤 문제에 대한 개선 방법이 정해져 있을지라도, 이 방법이 수용되기까지는 사람을 놓을 수 없기 때문이다.
다시 언급하자면 피드백을 주는 목적은 피드백을 받는 사람이 일을 더 잘해서, 결국 우리가 함께 성과를 내고 성장하기 위함이다. 상대방에게 피드백이 온전히 전달되어 진짜 변화를 이끌어내고 함께 성과를 내기 위해서라도, 피드백을 전하는 우리의 태도에는 고찰이 필요하다. 나에게 상대방을 온전히 이해하려는 시도와 내 경험이 항상 정답은 아니라는 생각은 의식적으로 놓지 않아야 하는 중요한 일이다.

피드백을 주는 태도에 대하여

댓글