커뮤니케이션 잘하는 개발자가 되려면..

개발자에게 있어서 프로그래밍 실력이 중요할까? 커뮤니케이션 능력이 중요할까?

당연히 개발자 역량에 있어서 프로그래밍능력, 커뮤니케이션능력이 2개다 좋으면 좋으나,
어떤사람이 2가지 측면에 있어서 모두 뛰어나다면 어느 조직에서 일하던지 잘할 가능성이 높을것이며, 둘 다 부족하다면 일을 하는데 있어서 어려움을 겪을 가능성이 크다.

커뮤니케이션에 대한 이야기를 하기 전에 프로그래머와 개발자의 차이에 대해 명확히 하려 한다.
먼저 프로그래머는 컴퓨터를 이용해서 프로그램을 만들거나 수정하는 일을 하는 사람이다. 프리랜서로 일하면서 외주 프로젝트를 맡거나 학교 과제를 하면서 프로그래밍을 하는 사람들 모두 프로그래머라 할 수 있겠다.

반면, 개발자는 회사나 조직에 소속이 돼서 다른 사람들과 함께 일하면서 개발을 하는 사람이다. 즉 어딘가에 소속이 돼서 규칙이나 규율 혹은 그 조직의 원칙을 가지고 일을 한다면 개발자로 볼 수 있는 것이다. 정리해 보자면 모든 개발자는 프로그래머지만 모든 프로그래머는 개발자는 아니다. 프로그래머와 개발자를 굳이 나누어서 말하는 이유는 개발자에게는 커뮤니케이션 능력이 절대적으로 필요하기 때문이다.

예컨대 프로그래머는 강호를 혼자 떠돌며 칼을 쓰는 무사라고 한다면, 개발자는 거대한 군사 조직에 속한 정규군이다. 외톨이 무사에게 생명은 칼솜씨이고 정규군의 생명은 규칙과 규율이다
칼 솜씨는 코딩 실력이 되겠고, 규칙과 규율은 다른 사람과의 커뮤니케이션 능력이라 볼 수 있겠다. 이것이 개발자에게 있어 코딩 실력이 중요하지 않다는 것은 아니다. 코딩 실력은 기본이요. 커뮤니케이션 능력도 반드시 필수적이라는 뜻이다.
군대에 속해서 전투를 치르기 위해서는 기본적인 전투능력이 필요하다. 즉, 개발자는 자기가 맡은 프로그래밍 업무를 성공적으로 수행할 수 있는 능력을 가져야 하고 이것은 기본이다!

많은 시니어 개발자들이나 개발 관련된 직종에서 오래 근무한 사람들이 가장 많이 하는 말 중 하나가 바로 커뮤니케이션에 대한 이야기다. 개발자를 뽑을 때 중요한 것이 커뮤니케이션 능력이라고 한다. 커뮤니케이션이 원활하지 않아 개발 업무에 차질이 생기는 일이 다반사며 원활한 커뮤니케이션은 막혔던 문제를 훨씬 더 빠른 속도로 풀릴 수 있게끔 만든다.

그럼 구체적으로 좋은 커뮤니케이션을 하기 위해 어떻게 해야 할까??

1. 상대방이 원하는것을 파악하자.
   상대방의 관점에서 생각하는 거다
   정말 원하는게 뭘까? 그게 모르면 솔직하게 물어보는것도 좋은 방법이다.

 

 

여기서 개발자가 잘못한 3가지가 있다. 무엇일까?

 

① 기한내에 할 수 있을지 모르면서 하겠다고 대답했다.
⇒ 이건 수락한거다. 한번해보겠다는 한번해보고 말지가 아니라 한번 해보겠다는 의미와 같은것이다.

 

② 말의 앞과뒤가 다르다.
⇒ 원래는 2주이상이 걸린다고 했는데 갑자기 된다? 이상하지 않는가?
최초에 일정 산출을 잘못했던지, 불가능한 일정인걸 알면서 얘기한것이다.

 

③ 기획자가 정말 필요한 것이 무엇인지 생략이 되었다.
⇒ 요청을 했는데 정말 필요한 기능이 뭔지 확인하는 과정이 생략이 되었다는것이다.

 

… 해결방안이 없을까?

 

개발자 : 보고서생성하고 출력하는 기능이 왜 필요한지 알 수 있을까요?

기획자 : 고객 사에 데모할 때 종이형태로 출력해서 거래현황을 보고 싶어 하거든요.

개발자 : 혹시 이번 데모보고서에 도표나 그래프 없이 숫자만 나와도 될까요?

기획자 : 이번에는 그렇게 출력해서 나와도 데모에는 지장이 없을 꺼 같아요.

개발자 : 간단한 출력기능은 이번 주 까지 구현 가능합니다. 보다 정교한 출력기능은 다음 패치 때 정식으로 반영하면 좋을 꺼 같네요.

 

 

개발자는 이런 절충안을 얘기할수 있다.
처음에는 기획이 요구했던 보고서를 생성해서 출력하는 기능은 일정안에 안되는 것이다. 그래서 거부를 했지만, 얘기를 하다보니 정말 이번데모 때 꼭 필요한 수치로 된 보고서를 출력해서 받아보는 내용은 가능한 여지가 있었던 것이다.
즉, 대화로 해결할 수 있었던 것이다.
애당초 일정이 부족하다면 방법이 2개밖에 없다. 일정이 늘리던지 아니면 기능을 축소해야한다.
기획자가 일정을 산출할수 없다. 원하는것과 가능한 것 사이에 타협점을 찾는게 필요하다.

‘보고서 생성하고 출력하는 기능이 왜 필요한지 알수있을까요?’ 하는 이 간단한 질문하나에 굉장히 많은것이 바뀔수 있다.

 

 

2. 상대방의 용어를 이해하자.
미국인과 내가 대화를 해야하는 상황이라 가정해보자.
내가 영어를 배우든지, 상대방이 한국어를 배우든지. 이게 안되면 대화를 할수가 없다.
그 사람과 친해지고 싶다고 하면 짧게 스몰토크라도 할 수 있게끔 뭔가 준비를 한다.
말이라도 한번 붙여본다던지… 이런 노력이 협업에는 중요한 포인트다.
나아가서 조금씩 서로의 용어를 배운다면 조금더 대화가 유용해질수 있다.
비개발직군이 개발직군이랑 대화를 할때, 이런 고충이 많이 있을 수 있다.

예를 들어 기획자가 뭔가 요청을 했는데, 개발자가 이런 얘기를 한다.

개발자 : 아..그거하려면 API 인터페이스 다 바꿔야 하구요 하위 호환성 문제가 있어서 절대 안돼요. 불가능합니다.

하고 단박에 거절햇다고 했을 때,

기획자 : (인터페이스?하위 호환성? 이게 무슨말이지? 그리고 바뀌면 왜 안되지?)

서로의 상황과 용어를 이해하지 못하다보니까 이런 간극이 발생하는것이다.
개발자입장에서는 당연하다고 넘어갈수 있는 이런 용어들을 알게 되면 대화가 한결 수월해지므로 비개발직군도 이런부분은 노력이 필요하다.

 

 

 

3. 상대방이 이해할수 있는 용어로 설명하자
상대방이 이해할수 있는 쉬운 일반적인 용어로 풀어서 설명하면 된다.
특히 개발자는 자기가 하는 말이 자기들의 동료 외에는 아무도 이해할 수 없다는 사실을 종종 까먹는다.
개발자끼리는 서로 아무 문제가 없는데.
전혀 개발용어를 모르는 사람이 들으면 하나도 이해할 수 없는 경우가 많다.
상대방이 모르니까 또 물어보게되면, 설명했는데 또 설명해달라고 하니 짜증이 날 수 밖에 없다.
그런데 문제는 또 설명해줘도 당연히 이해가 안된다. 똑같은말로 또 설명하기 때문인다.

 

 

이해가 안되는건데 똑같은 말로 설명해봤자 대화가 안된다.
진짜 전문가는 자기가 아는지식을 쉽게 설명 할 수 있어야 한다.
지식을 정확하게 알 수록 쉬운 비유나 그림 한장으로 설명이 가능 하다.
내가 쉽게 설명이 안된다면 그 지식을 정확히 아는건지 통찰할 필요가 있다.

아까나온 인터페이스부터 다 바꿔버려야 하는 상황의 예시를 들어보자.
인터페이스는 온수는 빨간색, 냉수는 파란색처럼 사전에 정한 약속같은것이다.
바꾸자는 요청은 이걸 바꾸는것과 같은것이다.(온수는 파란색, 냉수는 빨간색)

더워서 파란색으로 돌렸는데 갑자기 뜨거운물이 확 나오면 당황스럽다.
그 다음에 문제는 이미 설치된 샤워기도 다 바꿔야 하는 상황이다.
인터페이스라는게 사전에 정의된 약속들이기 때문에 보기에 단순해 보여도 이걸 바꾸는게 굉장히 어려움과 문제들이 많다. 그래서 바꾸는게 어렵다고 설명을 한다면, 상대방은 자기가 쉽게 떠올릴수 있는 개념으로 개발자가 원래 얘기했던 설명을 대입해서 이해할 수 있게 되고 요구사항을 만족하려면 어떤식으로 이 문제를 풀면 좋을까 얘기를 해볼 수 있다.
그러나 이게 안되다면 ‘그냥 개발자가 안된다는데요….?’ 이렇게 얘기할수 밖에 없다.

 

상대방이 원하는것을 파악해라.
상대방의 용어를 이해하라.
상대방의 용어로 설명해라.

 

커뮤니케이션도 기술이다. 시간이 흐르고 기술이 발전하여 먼 훗날 AI가 사람의 코딩을 대체하는 날이 와도 커뮤니케이션은 대체할 수 없다. 공감은 시뮬레이션 되는 것이 아니기 때문이다.