의사소통이 즐거운 개발자의 3가지 능력
의사소통이 즐거운 개발자의 3가지 능력 관련
몇 년 지난 일입니다. 회사 CTO님이 판교에서 개발자를 구하는 창업자를 만나고 와서 했던 질문이 꽤 인상 깊게 남았습니다. 그는 “코딩 실력만 있는 것이 아니라 대화가 통하는 동시에 일도 믿고 맡길 수 있는 개발자가 한국에 몇 명이나 있을 것 같냐”고 내게 물었습니다. ‘누구와의 대화’가 통해야 하는 지는 불분명했지만, 제 추측으로는 창업자를 만나고 온 직후이니 고용주가 개발자와 나누고 싶은 이야기들이 그 대상일 듯했습니다.
생각해 본 일이 없어서 대답을 망설이자 그가 먼저 숫자를 제시했습니다. 충격적으로 적은 숫자였습니다. 정말 우리나라에 의사소통이 능통한 개발자가 그렇게 부족할까요? 돌아보면 저 역시 의사소통의 중요성을 깨달은 것은 오래되지 않은 듯도 합니다.
개발자에게 의사소통 능력이 역량의 전부는 아니지만, 적어도 흔치 않은 개발자가 될 가능성을 매우 높이기 때문에 이에 대해 글을 써 봅니다. 추려 보니 세 가지 방향으로 의사소통을 기를 수 있다는 생각을 합니다.
첫 번째는 ‘대화 상대와 맥락을 나누고 공감을 끌어내는 능력’입니다. 두 번째는 ‘갈등을 꺼내어 공론화하는 능력’입니다. 마지막 세 번째는 ‘자신이 속한 업무 영역을 구체화하는 능력’입니다.
맥락을 나누고 공감을 끌어낼 수 있는 능력
대화에 앞서 먼저 대화를 시작하는 나의 믿음을 돌아볼 필요가 있습니다. 그리고 상대가 아주 막역한 사람이 아니라면 우리는 가치관이 다르고 같은 현상에 대해서도 다른 인식을 가질 수 있다는 점을 분명히 해야 합니다. 그래야 소통 오류를 줄일 수 있습니다.
내가 어떤 말을 할 때, 상대가 정확히 알아듣지 못할 수 있습니다. 어쩌면 이는 너무나도 당연한 일입니다. 심지어 나에게 아무리 중요한 주제라고 해도 상대는 관심이 없을 수 있죠. 이 사실을 받아들이면 상대적으로 평온한 감정으로 여유 있게 대화에 임할 수 있습니다.
하지만 제 경험에 따르면 많은 경우 사전에 아무런 준비도 없이, 상대가 내가 말하는 주제에 관심을 기울여 정확하게 이해할 것을 기대하는 현상을 관찰할 수 있었습니다. 사실 바로 이런 상태가 의사소통에 서툰 전형이라고 말할 수 있습니다.
제가 의사소통 기술을 개발한 배경을 생각해 봤습니다. 반복적인 회의에 지치고, 쟁점이 제때 다뤄지지 않는 문제를 해결하기 위한 노력이었던 것 같습니다. 그래서 매번 회의 전에 주제를 분명하게 했고, 꼭 필요한 사람들 위주로 참여를 시켰으며, 이를 사전에 고지했습니다. 해당 주제와 무관한 사람을 참여시키면, 그들은 부담에서 자유롭기 때문에 실현 불가능한 이야기를 하며 쟁점을 흐리는 경우가 많았습니다. 따라서 가급적 참여자는 최소로 유지하는 편이었습니다. 회의가 끝나고 나서도 쟁점에 대한 결과와 이후 필요 활동을 언급한 후에 회의를 주관한 제가 반드시 회의록을 썼습니다.
당시에는 회의록을 위임하는 경우가 많았습니다. 그러나 맥락을 제대로 모르는 다른 사람에게 업무를 익힌다는 명목으로 회의록을 쓰게 한다면 소탐대실할 수 있다 느꼈습니다. 회의하며 어렵게 결론을 이끈 다음, 회의록의 모호함 때문에 일을 그르칠 수도 있으니까요.
일대일 대화도 훈련했습니다. 그러나 일대일 대화의 경우는 회의록을 쓰고 하지는 않아서 경험으로만 익혔죠. 그러한 경험을 바탕으로 동료에게 노하우를 전하려다 보니 말과 그림으로 표현하게 되었습니다. 마음에 들어서 다른 이들에게도 여러 번 소개한 후에 인터넷에 글을 쓰면서 다음과 같은 그림을 만들어냈습니다.
그림에서 교집합은 소통이 가능한 범위를 표현합니다. 교집합이 늘어나려면 말하는 이와 듣는 이 모두의 노력이 필요합니다. 내가 말하는 이라면 사전에 대화 주제를 공유하는 편이 유리합니다. 상대방도 미리 생각하고 왔을 경우라면 대응 속도가 빠르니까요. 낯선 주제를 처음 듣고 생소해 하고 있는데, 이미 아는 주제라고 가정하고 이야기를 하게 되면 상대는 당황하거나 불편해질 수 있습니다.
준비된 자료를 같이 보면서 말하면 각자가 다른 생각을 할 여지가 줄어듭니다. 또한 상대가 모르는 말을 하면 바로 물어야 합니다. 듣는 사람 입장에서도 가급적 상대의 말을 끊지 않고 듣는 것이 좋습니다. 그 다음에 내가 이해한 내용이 상대가 전하려는 내용인지 확인하는 습관을 들인다면 의사소통 능력이 향상됩니다. 반대로 내가 하는 말이 잘 전달되었는지 질문을 통해 확인하는 방법도 익히면 효과적이겠죠.
그림에 표현하지는 않았지만, 우리는 같은 언어를 쓰더라도 기본적으로 다른 의미를 담을 수 있다는 전제를 해야 오해를 줄일 수 있습니다. 그래서 조심스럽게 각자의 해석을 허용하고 교집합을 만들어가야 합니다. 그런 내용을 어릴 적 수학 교과서에서 봤던 벤 다이어그램을 이용해 표현한 것입니다.
그림에 붙인 소제목처럼 먼저 맥락을 나누어 서로의 자유를 명료하게 인식하고 인정해야 합니다. 서로 같은 말에 대해 다르게 이해해도 모두 괜찮다고 전제하는 것입니다. 그래야 불필요한 감정 소모가 발생하지 않습니다. 그러고 나서 조심스럽게 교집합을 만들며 공감을 만들어가야 합니다. 이렇게 하면, 누구와 어떤 조건에서 대화하더라도 내 노력과 훈련 여하에 따라 의사소통 능력을 향상할 수 있습니다.
갈등을 꺼내어 공론화할 수 있는가?
예전에 다른 곳에 기고했던 글 <함께 성장하며 함께 일하기 위한 3가지 필수 조건>에서 다음 세 가지 덕목을 강조한 바 있습니다.
- 투명하게 논의할 수 있는 환경 (민주적일 것)
- 나부터 실천할 것 (구호보다 행동)
- 서로의 다름을 인정하기
협업 과정에서 대화가 필요할 때면, 매번 민주적인 업무 환경과 직장 문화에 대해 지인들에게 강조합니다. 제가 말하는 민주적 업무 환경의 단위 활동은 바로 의사소통이며, 앞서 그림으로 설명한 대화 방식은 그 핵심 역량 중 하나라고 할 수 있습니다.
인터넷 공간에 쓴 다른 글 <트레이드오프와 아키텍트 그리고 개발자의 소통 문제>에서 저는 개발자와 아키텍트를 비교하며, 상충 관계에 대해 설명하는 역량이 아키텍트에게는 필수적이라 주장한 바 있습니다. 개발자가 시니어 개발자로 인정을 받거나 기술 리더가 되기 위해 꼭 갖출 역량은 “기술 문제를 둘러싼 갈등에 대해서 언제고 말할 수 있는 능력”이라 할 수 있습니다.
지난 몇 년간, 경력은 풍부하지만 성장하지 못하는 개발자들을 보면서 공통점을 한 가지 발견했습니다. 그들은 자기 주장을 공개적으로 말하지 못하거나, 누군가 자기 의견을 반박하면 화를 냅니다. 또는 위축되어서 토론을 잘 전개하지 못했습니다. 비교적 최근 태어난 사람들은 분명 달라질 테지만, 과거에는 집안이고 학교고 자신의 의견을 자신 있게 말할 수 없는 환경에서 자라고 성장한 분들이 많습니다. 그래서 모두 의견이 다를 수 있는데, 그 당연한 사실을 대화 과정에서 받아들이지 못하고 갈등 국면을 회피하는 분들이 종종 있습니다.
하지만 훌륭한 개발자라면 당연하게도 사용자에게 좋은 경험을 줄 수 있는 사용자 가치와 상호작용을 만들기 위한 의견 ‘충돌’을 즐겨야 합니다. 그리고 끊임없는 토론을 거치며 해당 상황에 가장 적합한 알고리즘을 만들어서 팀이 함께 최적의 해답을 구하는 여정을 즐겨야 합니다. 그 과정에서 설사 나의 의견에 오류가 드러나고 더러 민망한 감정이 들더라도 팀을 믿고 소통할 수 있어야 합니다. 내 감정의 안전과 편안함을 포기하고 사회적 가치를 만들어내는 점이 바로 개발자를 훌륭하게 만드는 것입니다.
우리들의 이야기를 구체화하기
마지막으로 의사소통할 때는 프로그래밍 언어나 특정 기법이 아니라 사람을 중심에 두어야 합니다. 우리가 만드는 시스템과 서비스를 이용하고 만드는 바로 그 사람들 말입니다. 쉽게 말해 팀으로 일할 수 있어야 합니다. 왜냐하면 그들의 이야기를 풍성하게 다루고 구체화하는 과정에서, 인간과 프로그램이 유기적으로 엮이는 사회적인 시스템이 만들어질 수 있기 때문입니다.
고도 성장기를 지났고, 빠른 성장에 대해 프라이드를 가진 절대다수의 국민이 사는 나라인지라, 뭔가를 만들어가는 즐거움을 누리는 일이 대체로 저평가받는다는 생각이 들 때가 있습니다. 직업은 우리 삶을 구성하는 소중한 순간을 만들어 냅니다. 개발자가 만드는 결과물도 중요하지만 직업 일상이라는 과정을 정성스럽게 밟아갈 때 지속가능성은 더욱 강화된다고 생각합니다.
다음 그림은 우리 회사에서 동료들과 사용하는 ‘도메인 스토리텔링’이라는 표기법입니다. 우리는 디지털 기기나 기술 용어에 익숙하지 않은 많은 사람과도 소통해야 합니다. 그들의 어려움을 들어가며, 그들의 문제를 해결해 줄 때, 우리 서비스가 비로소 쓰이게 되기 때문입니다.
이러한 비전의 구체화 역시 의사소통의 일환이기도 하고, 의사소통을 통해 구현되는 일이라 할 수 있습니다. 위 작품(?)은 개발자는 아니지만 생소한 표기법을 바로 익혀서, 서로 인식이 달라 소통이 안되는 이들을 돕는 역할을 맡은 회사 동료가 만든 것입니다. 그의 노력으로 인해 많은 사람이 한 팀으로 작동하는 것을 보고 저는 다시 한번 의사소통의 힘을 느낄 수 있었습니다. 또한, 외국인을 만나면 당연히 그들의 언어를 배려하는 것처럼, 표기법 역시 상대를 배려하여 결정해야 한다는 점도 더불어 배울 수 있었습니다.
마치며
지금까지 의사소통을 즐기기 위한 세 가지 능력에 대해 썼습니다. 이들을 각각의 능력으로 나눌 수도 있지만, 사실은 서로 밀접하게 관련이 있습니다. 대화 상대와 맥락을 나누기 위해서는 제시한 문제에 대해 상대가 어떻게 느끼는지 공감할 수 있어야 합니다. 그리고, 이러한 능력이 갖춰져 있을 때 자신이 속한 업무 영역을 균형감 있게 구체화할 수도 있습니다.
한편, 사람들은 서로 이해관계가 다를 수 있고, 동일한 문제에 대해서도 다른 가치관과 선호도로 판단하기 마련입니다. 갈등이 너무 커지기 전에 이를 포착하고 끄집어 내어 공론화 하기 위해서도 공감 능력과 상황 판단 능력이 중요합니다.
개발자로 일한다는 것은 무언가 다른 사람이 사용해서 가치를 낼 수 있는 프로그램을 만든다는 것을 뜻합니다. 이는 사용자와 동료 개발자를 포함한 다수의 사람들과 의사소통 하는 일을 바탕에 두고 있습니다. 의사소통을 개발의 일부로 받아들이고 즐기는 일이 무엇보다 필요하지 않을까요?
