[Developer] 개발자가 말하는 법

출처 : http://www.zdnet.co.kr/column/column_view.asp?artice_id=20170814090312

‘개발자의 생명은 커뮤니케이션 능력’이라는 글에서 나는 무엇이 개발자의 커뮤니케이션인지 정의한 바 있다. 무대에서 발표하는 능력, 논쟁에서 자기주장을 펼치는 능력, 상대를 설득하는 능력, 말을 또박또박 발음하는 능력, 이러한 능력이 있으면 좋지만 이런 건 개발자에게 반드시 요구되는 능력이 아니다.[칼럼 바로가기 '개발자의 생명은 커뮤니케이션 능력']

​

개발자의 커뮤니케이션은 (1) 잡음을 제거하고 본질을 파악하는 능력, (2) 다른 사람에게 추상적인 관념을 설명하는 능력, (3) 타인의 감정을 이해하는 공감능력, 이렇게 세 가지로 압축된다. 그럼 이런 커뮤니케이션을 제대로 하려면 어떻게 해야 할까. 이전 글에서 개발자의 커뮤니케이션이 무엇을 의미하는지 정의했으니 이번에는 개발자가 말로 자기표현을 할 때 기억할만한 디테일을 다룬다. 앞글의 속편이다.

​

1. 무조건 두괄식이다

​

이게 제일 중요하다. 매일 아침 스크럼 미팅을 하거나 누가 질문을 해서 대답할 때, 가장 중요한 핵심적인 내용을 첫 문장으로 말하는 습관을 들여야 한다. 코드를 생산하는 개발자의 마음 속에는 언제나 천갈래 만갈래로 뻗어 나가는 디테일이 존재한다. 그래서 상대방이 내 말을 이해하려면 그런 디테일을 다 알아야 할거라고 생각한다.

​

너무 짧게 말함으로써 불필요한 오해를 사거나 실력을 의심받는걸 두려워하는 심리도 있다. 그럴 필요 없다. 개발자는 두괄식이다. 두괄식이 아니면 상대에게 불필요한 말을 질질 끄는 느낌을 준다.

​

2. 대화와 강연을 혼동하지 마라

​

대화는 강연이 아니다. 이 항목은 주로 상급자에게 해당하는데, 혼자서 다섯 문장을 연달아 말했다면 상대방이 딴 생각을 하고 있을 확률이 95%이고, 열 문장 이상을 말했으면 확률이 99%이다. 혼잣말을 하는 것이다. 그럴 거면 거울이나 벽을 보고 이야기 하는 편이 낫다.

​

대화는 공명(resonance)이 핵심이다. 반드시 상대의 의견이나 생각을 묻고 경청하는 과정이 섞여야 하며 때로는 서로 마주보고 침묵하는 시간도 필요하다. 함께 생각에 잠기는 것이다. 대화와 강연을 혼동하지 마라. 대화를 원하는 사람 앞에서 강연을 하는 것은 언어폭력이다.

​

3. 단답식을 즐겨라

​

앞의 항목이 상급자를 위한 것이면, 이 항목은 주로 하급자를 위한 것이다. 업무상 자기보다 상급자의 위치에 있는 사람이 질문을 하면 최대한 단답식으로 대답하는게 좋다. 질문의 형식이 예, 아니오로 대답할 수 있는 것이면 예 혹은 아니오로 대답하고, 숫자를 묻는 거면 숫자로 대답한다.

​

예를 들어서 "현재 업무가 몇 퍼센트 정도나 진행되었나요?" 상급자가 이렇게 물었다고 하자. 이런 질문을 받으면 개발자의 머리 속에는 천갈래 만갈래의 디테일이 활짝 나래를 편다. 디테일의 갈래를 더듬는 개발자의 마음 속에는 이걸 어떻게 퍼센트로 대답하지? 회의가 밀려오고 입은 디테일을 설명하며 중언부언한다.

​

정확성에 대한 개발자의 강박 때문이다. 상급자의 질문은 실제 진행 정도를 정확하게 나타내는 숫자를 묻는게 아니다. 대화를 풀어가기 위한 출발점을 찾는 것이다. 그걸 모르니 강박에 사로잡힌다. ‘상식 밖의 경제학’에서 댄 애리얼리는 이런 숫자를 닻(anchor)에 비유했다.

​

사람의 심리는 항상 자기 생각을 비교하고 평가할 기준점을 필요로 한다. 구체적인 값은 큰 의미가 없다. 가게에 진열된 다른 핸드백의 가격이 1천만원이면 100만원짜리 핸드백이 싸다고 생각하고, 다른 백의 가격의 10만원이면 비싸다고 생각한다. 100만원짜리 핸드백에 대한 나의 생각을 가다듬으려면 1천만원이든 10만원이든 뭔가 비교할 기준점이 필요하다. 대개의 경우 상급자는 그런 기준을 찾는 것이다.

​

누가 질문을 하면 그가 원하는 것을 즉각적으로 대답해주고, 거기에서부터 대화를 풀어가라. 그럼 된다. 즉각적인 대답이 꼭 정답일 필요도 없다. 단답식을 즐기는 습관을 들이면 커뮤니케이션이 시원시원하다는 느낌을 줄 수 있다.

​

4. 스토리를 준비해라

​

이 항목은 주로 데이터 분석을 담당하는 친구들에게 하는 이야기다. 물론 개발자에게도 해당한다. 비즈니스 측에서 특정한 데이터에 대한 리포트를 요구한다. 데이터 분석팀에서 다양한 SQL문을 돌려서 리포트를 만들고 R, 액셀, 마이크로스트래티지, 태블로 등을 이용해서 작성한 깔끔한 차트도 첨부한다. 그래서 뭐? 풍성한 데이터와 화려한 그래프가 있어도 그 안에 스토리가 담기지 않으면 의미가 없다.

​

데이터를 분석하는 사람은 단순히 필요한 데이터를 뽑아서 장식하는 것으로 일을 그치면 안된다. 딱딱한 데이터를 딛고 일어서서 데이터가 말하는 스토리에 귀를 기울여야 한다. 핵심적인 메시지를 추출하는 것이다. 그리고 다른 사람에게 그 스토리를 들려 줘야 한다. 개발자도 마찬가지다. 스토리를 떠올릴 수 없으면, 생각이 부족한 것이다.

​

데이터든 코드든 그런걸 대상으로 하는 분석과 추상은 고도의 지적노동을 요구한다. 내가 그렇게 고된 노동을 이미 수행했으면, 내 노동의 결과를 소비하는 사람은 땀을 흘리지 않아야 정상이다. 커뮤니케이션을 잘 하는 사람은 자기 노동에서 핵심적인 메시지를 간추려서 하나의 스토리로 정리하고, 그걸 설명한다. 그래서 그의 설명을 듣는 사람은 땀을 흘리지 않는다. 유쾌하다. 커뮤니케이션을 못 하는 사람은 다른 사람에게 자기가 수행한 노동을 똑같이 수행하도록 강요한다. 말에 스토리가 없기 때문에 의미를 이해하려면 듣는 사람이 스스로 데이터를 들여다보거나 코드를 읽어야 한다. 그가 이미 건넌 디테일을 늪을 다시 건너야 하는 것이다. 불필요한 땀을 흘려야 하기 때문에 불쾌하다.

​

5. 감정을 통제하라

​

이 항목에 대해서는 할 말이 많지만 지면 관계상 간단히 말하겠다. 자기 감정을 통제하지 못하고 쉽게 발끈하는 사람은 C급이다. 자기 감정을 드러내지 않으면서 타인의 감정을 자극하는 사람은 B급이다. 스스로 감정에 휘둘리지 않고 타인의 감정도 배려하는 사람은 A급이다. 다시 말해서 감정도 실력이다. 개발자 커뮤니티에서는 기술적인 선호도를 가지고 감정싸움을 하는 경우가 많은데, 건강한 논쟁인 경우도 있지만 대부분 소모적인 시간낭비다. 회사에서는 자기 '성격'을 거침없이 드러내는 사람들이 있다. 신입사원에서 사장님까지 다양하다. 이런 분들은 아무리 사장님이라고 해도 자신이 C급임을 알아주시기 바란다. 감정을 통제하지 못하는 사람은 타이틀이 아무리 화려해도 허접한 삼류에 불과하다. 여기에 예외는 없다. 스티브 잡스 같은 사람은 통계적으로 의미가 없는 이상치(outlier)일 뿐이다.

​

글을 쓰다보니 언행일치가 되지 않아 스스로 부끄러워지는 부분이 있다. 다루고 싶은 항목도 많은데 다섯 개밖에 포함시키지 못해 아쉽다. 나중에 또 하나의 속편을 쓰는 것으로 하고 개발자의 커뮤니케이션에 대한 이번 글은 여기에서 마친다.

*본 칼럼 내용은 본지 편집방향과 다를 수 있습니다.

칼럼니스트 : 임백준

 baekjun.lim@gmail.com

한빛미디어에서 『폴리글랏 프로그래밍』(2014),『누워서 읽는 퍼즐북』(2010), 『프로그래밍은 상상이다』(2008), 『뉴욕의 프로그래머』(2007), 『소프트웨어산책』(2005), 『나는 프로그래머다』(2004), 『누워서 읽는 알고리즘』(2003), 『행복한 프로그래밍』(2003)을 출간했고, 로드북에서 『프로그래머 그 다음 이야기』(2011)를 출간했다. 삼성SDS, 루슨트 테크놀로지스, 도이치은행, 바클리스, 모건스탠리 등에서 근무했고 현재는 맨해튼에 있는 스타트업 회사에서 분산처리, 빅데이터, 머신러닝과 관계된 업무를 수행하고 있다.