내 의견이 맞는데 다른 분들이 몰라준다
내가 너무 대단한 것을 알려줘서 남들이 이해를 못 한다.
Ralph Johnson taught me an important lesson about research: if someone (a reviewer of a paper, an attendee at a talk) comments, “I don’t understand” or just doesn’t get it, it’s our fault. It is our responsibility to work hard to develop and communicate our ideas.
(랄프 존슨은 연구에 대한 중요한 교훈을 알려줬다: 만약 누군가(논문 리뷰어, 발표 참가자 등) "이해가 안 돼"라고 말하거나 이해를 못 하면 그것은 연구자의 잘못이다. 열심히 개발하고, 아이디를 커뮤니케이션하는 것도 우리의 책임이다)
위 문구는 1999년에 출간된 "Refactoring: Improving the Design of Existing Code 1st Edition"의 13장에 나오는 문장으로 저자가 리팩터링을 설명했는데 설명을 들은 개발자들의 긍정적인 반응을 이끌어 내지 못했을 때 Ralph Johnson(Design Patterns: Elements of Reusable Object-Oriented Software의 저자 중 한 명)이 조언한 내용이다.
평소 개발자 분들과 얘기를 하다 보면 위와 같은 상황을 겪어서 힘들다는 분들이 많다. 나 또한 그런 경험을 몇 차례 겪었다. 개발자 콘퍼런스에서 발표, 중요한 회사의 개발 방향에 대한 공유 및 설득, 아키텍처/개발 방법 등에 대한 논의 등 다양한 경험이 있었다.
먼저 예전 Daum을 다닐 때가 개발자 콘퍼런스에서 발표를 했었던 경험을 살펴보자.
내가 참여한 첫 번째 개발자 콘퍼런스에서 그때는 생소한 개념(Staged Event Driven Architecture)에 대한 발표였다. 나도 간신히 이해한 수준에서 설명을 하니 장황하고 이해하기 어렵게 설명을 했었던 것 같다. 거기다 입사 후 첫 번째 콘퍼런스여서 너무 잘하고 싶은 마음에 너무 많은 것을 배경 지식이 없는 분들에게 빠르게 전달하려고 했었다. 그때 백여 명이 해당 프레젠테이션을 들었는데 한두 분을 제외하고는 재미없어하는 것이 역력했다. 이때는 내가 너무 대단한 것을 발표해서 참여자들이 이해를 못 하는 것이라고 생각했다. 지금 생각하면 참 바보 같은 생각이다. 내가 발표를 잘 못해서 참여자들이 이해하고 집중하기 어려웠던 것이 문제인데 말이다.
그다음 언젠가는 "레거시 코드 활용 전략"이라는 주제로 발표를 했다. 팀에서 세미나를 했던 "Working Effectively with Legacy Code" 내용을 팀에서 적용했던 사례 위주의 발표로 이론적인 내용은 적었고, 활용(IDE, Hotkey, Plugin 등)을 중심으로 라이브 코딩으로 진행했고 아주 반응이 좋았다. 콘퍼런스 종료 후 우수 발표로 선정되기도 했다. 그런데 이 발표를 들은 많은 개발자들은 "무슨 플러그인을 쓴 것이냐", "어떤 기능을 수행할 때 핫키는 무엇이냐" 등을 물었다. 좀 실망스러운 질문이었다. 프레젠테이션에 포함된 리팩터링, 의존성 제거 기법 등에 관심을 가지길 바랬기 때문이다. 하지만 어느 정도 시간이 지난 후 플러그인, 핫키 등에 관심을 가졌던 개발자들이 프레젠테이션에서 참조했던 책들을 보며 공부하고 질문이나 의견도 주는 분들이 있었다. 감동스러운 순간이었다. 만일 내가 1시간 동안 이론적인 내용을 최대한 많이 전달하려고 했다면 이런 반응을 이끌어 내지 못 했을 것이다.
TDD도 마찬가지였던 것 같다. 라이브 코딩이나 실제적인 예제로 매력적으로 설명을 했을 때 하고자 하는 분들이 많이 생기는 것 같았다.
랄프 존슨의 말대로 잘하는 것도 중요하지만 이걸 잘 전달(communication)하는 것도 못지않게 중요한 것이다. 잘하지만 전달을 잘 못하면서 남들이 못 알아준다고 생각하는 것은 자신의 전달 노력/역력 부족인 것이다.
과학자들은 자신이 생각해 낸 이론이 맞다는 확신을 갖는데 20% 정도의 시간을 소요하고 다른 과학자들의 동의를 얻어내는데 80%의 시간을 들인다고 한다.
아무리 좋은 것이라도 새로운 것을 다른 분들에게 설명하고 동의를 이끌어 내고, 이를 실행으로까지 이끌어 내는 것은 너무나 어려운 일이다. 하지만 그런 변화를 이끌어 내면 그만큼의 가치를 얻을 수도 있고, 만족감도 얻을 수 있는 것 같다.
Robert C. Martin의 "Clean Architecture" 4장에 다음과 같은 내용이 나온다.
Science is fundamentally different from mathematics, in that scientific theories and laws cannot be proven correct. I cannot prove to you that Newton’s second law of motion. That is the nature of scientific theories and laws: They are falsifiable but not provable.
참이라는 것을 증명할 수 있는 수학과 달리 과학은 틀리지 않았음을 증명하여 맞다고 인정을 받는 것이라는 내용으로 여겨진다. 그래서 80% 노력이 설득에 소요된다는 점이 더 와닿는 것 같다.
조직 이동을 하면 기존 조직에 있던 분들이 장문의 메일이나 면담을 요청하면서 자신이 맞는데 다른 분들이 자기를 지원하지 않아 어려우니 도와달라는 분들이 있었다.
TDD, Refactoring 등을 공부한 후 팀에서 동의가 일어나지 않은 상태에서 진행하다가 다른 분들과 갈등이 생겨서 어려움을 겪은 분들도 있었다.
코드 리뷰를 하다가 서로 맞다고 갈등하다가 어려운 상황(이직 등)을 겪는 분들도 있었다.
특히 소프트웨어 개발은 학교에서 배울 수 있는 부분도 많지만, 학교에서는 절대 배울 수 없고 현업에서 훌륭한 선배 개발자들과 협업을 통해서 배울 수 있는 부분이 있다. 학교에서는 개발을 할 때는 운영(요구사항 변경, 기능 추가, 성능 대응 등)에 대해서 배우기 어렵기 때문이다.
"능력 있는 개발자를 어떻게 알아보나"이라는 글을 보면 슈퍼 개발자는 빨리 만드는 사람이 아니라, 다른 사람의 실수 / 삽질을 사전에 막아내는 사람이고, 본인 생산성도 좋지만, 타인의 학습 속도/생산성을 올려줄 수 있는 개발자이고, 주니어 개발자는 모방을 통해서 성장하고 성장을 위해서는 주변에 실력자(소프트웨어 장인)가 있어야 한다는 내용이 있는데 매우 공감이 간다.
개발자가 슈퍼 개발자/소프트웨어 장인으로 성장하기 위해서는 랄프 존슨의 말대로 "work hard to develop"만 해서는 안되고 "work hard to communicate"도 해야 하는 것 같다.
이 글을 작성하고 시간이 좀 지난 후에 "Delivery Skill"이라는 교육을 받게 되었아. 코치, 컨설턴트로서 자신의 의견을 상대에게 효과적으로 전달하는 것에 관련된 교육이었다. 이 교육 중에 강사님께서 모 정치인은 정치 초기 때 "맞는 말을 싸가지 없이 한다"는 말을 많이 들었다고 예를 들어 설명해 주셨다.
실상에서 이런 경우를 종종 경험한다. 맞는 말인데 이상하게 그 말한 한 분 의견에 따르기보단 반대하고 싶은 경우 말이다. 또, 이 글 위에서 언급한 대로 자신의 의견이 맞는데 사람들이 몰라준다고 말하는 분들도 많이 본다. 이 교육에서 강사님은 "아리스토텔레스의 설득의 3요소"에 대해서 알려주셨다.
| 비중 | 요소 | 설명 |
| 60% | Ethos | 말하는 사람의 신뢰성 |
| 30% | Pathos | 듣는 사람의 감정, 욕구, 정서, 공감 |
| 10% | Logos | 이성적 논리, 논증, 논거 |
맞는 것에 해당하는 Logos는 10% 비중만 차지한다. 그래서 아무리 맞는 말을 하더라도 "싸가지" 없게 하거나, 듣는 사람이 거부감이 들게 말하면 통하지 않는 것 같다. 평소에 신뢰를 많이 쌓아두어야 설득이 가능해지는 것이다. 신뢰가 없다면 "아기 발걸음"(https://brunch.co.kr/@cleancode/44) 전략이 필요할 것이다. 작은 성공의 반복으로 빠른 신뢰를 구축할 수 있지 않을까?
"맞는 말을 싸가지 없이 한다"... 참 아쉬운 결과인 것 같다.
