커뮤니케이션 잘 하는 개발자가 하지 않는 말

개발자가 커뮤니케이션 능력을 키워야 하는 이유

훌륭한 개발자란

같이 일하는 사람들이 생각하기에, 훌륭한 개발자는 어떤 사람일까요?

저는 이게 궁금했습니다. 훌륭한 개발자는 이래야 한다, 라고 개발자들이 얘기하는 경우는 많아요. 하지만 같이 일하는 다른 사람들의 기준은 어떨까요?  

회사에 입사하고 나서 주변에 이런 질문을 많이 했습니다.

00님이 보시기에 '이 사람 진짜 훌륭한 개발자다' 이런 사람이 있었나요?

당연히 같이 일하기 좋은, 일하고 싶은 개발자가 훌륭한 개발자겠죠? 그분들에게 같이 일하고 싶은 개발자의 사례를 묻자 대부분 공통점이 있었어요.

'커뮤니케이션이 잘 된다' 

'말이 잘 통한다' 

'시야가 넓다'

개발자인 제가 생각했을 때 훌륭한 개발자라고 하면, 막 OS와 컴퓨터 구조까지 꿰고 있고, 심심할 때 알고리즘 문제 풀고, 라이브러리가 마음에 안 들면 1달만에 뚝딱 만들고. 뭐 이런 이미지였거든요.

하지만 같이 일하는 팀원분들은, 가장 중요한 것으로 커뮤니케이션 능력을 뽑았습니다. 생각해보면 당연합니다. 그분들에게는 기술 수준이 중요한 게 아닙니다. 말이 잘 통하고, 협업이 잘 되는 사람인지가 중요하죠.

그런 사람은 누군가가 회사에 다니는 이유가 되기까지 합니다. 제가 얘기를 나눴던 분은 '그런 커뮤니케이션 잘하는 개발자가 많아서 이 회사에서 계속 일하고 있다'라는 말까지 하셨거든요.

뿐만 아니라 생각보다 시니어 개발자들에게 물어봐도 비슷한 대답이 나옵니다. 다른 개발자가 좋은 개발자일지 판단할 때 '이 사람이 다른 직군과 커뮤니케이션할 수 있는 능력이 있는가'를 가장 먼저 고려하시더라고요.

'커뮤니케이션 잘하는 개발자'가 뭔데?

그런데 말이죠. 그 얘기를 들으며 저는 의문이 생겼습니다.

커뮤니케이션이 중요하다. 는 말은 맞는 말이지만 너무나 추상적입니다. 마치 '아는 것이 힘이다' '인사가 만사다' 같은 느낌이잖아요. 

'커뮤니케이션'의 의미는 매우 넓습니다. 

논리적으로 말하는 것,

맥락을 잘 파악하는 것,

다른 사람에게 공감을 잘하는 것,

복잡한 내용을 단순하게 정리하는 것 등등

잠깐만 생각해봐도, 다양한 상황과 능력을 포괄합니다. 하지만 다들 커뮤니케이션이라고 퉁쳐서 말하죠. 혹시 우리는 서로 다 다른 걸 얘기하고 있는 것은 아닐까요?

저는 이 주제를 좀 더 탐구해보고 싶었습니다. 

개발자로서 커뮤니케이션을 잘한다는 게 도대체 무엇일까?

좀 더 구체화할 수는 없을까?

그래서 회사를 다니면서 물어보기 시작했습니다.

PM, 디자인 리드, 데이터 분석가, 사업개발 담당자, QA 엔지니어 등등.

다들 개발자와 가까이서 일한 경험이 풍부한 문들이었어요.

이 분들에게 물었습니다.

00님이 보기에 어떤 사람이 커뮤니케이션을 잘하는 개발자예요?

그럼 반대로, 개발자랑 일하기 힘들었을 때가 언제예요?

정말 다양한 답들이 나왔습니다. 사람들마다 보는 관점이 다 달랐는데요. 그럼에도 어떤 공통점이 보였습니다. 

특히 '이런 개발자랑은 일하기 힘들다'라고 말하는 부분에서 많은 분들이 비슷한 얘기를 해주셨어요. 그게 뭐였을까요?

오늘도 개발자가 안 된다고 말했다

여러분 이 책 아시나요?

개발자들이 안 된다는 말을 정말 많이 하나봐요. 얼마나 유명하면 이런 책까지 나왔을까요.

흔히 이런 대화를 밈처럼 많이 말하더라고요.

- 이거 1px 옮겨주세요. 
- 안 돼요. 그건 건물을 1cm만 옮겨달라는 거랑 똑같은 거예요.

제가 이 책 얘기를 꺼낸 이유는, 이 '안 돼요'라는 말 때문입니다.

인터뷰를 해보니까, 진짜로 '이런 개발자랑은 일하기 힘들다' 1위가 '그건 안 된다라고 딱 잘라말하는 개발자'였거든요.

잘 들어보니 '안 된다'라는 말 자체는 사실 더 근본적 문제의 현상이었습니다. 

그 근본적인 문제를 저는 '스펙 구현형 개발자'라고 이름을 붙여봤어요.

스펙 구현형 개발자

예시를 한번 들어볼게요.

저희 데이터 분석 담당자님이 얘기해주신 사례인데요. 이 분이 입사한지 얼마 안되었을 때였습니다. 로그를 심어야 하는 상황이었습니다. 그래서 이 분이 로그와 파라미터를 정의해서 개발자에게 전달했어요.

화면 로그 정의 전달드립니다.

그런데 한참 뒤에 개발자가 이렇게 말했습니다.

여기 보면 button_title이 들어있잖아요? 이건 스트림에서 비동기로 받아오는 거라서, 서버 API 구조를 바꾸지 않으면 이렇게는 안 돼요.

그리고 메시지는 끝나버렸습니다.

데이터 분석 담당자는 멘붕이 왔대요. 입사한지도 얼마 안 된 상태였는데 위기가 온 겁니다. 

내가 뭔가 실수한 건가? 
비동기? 스트림? API? 이게 다 무슨 말이지?
그냥 나는 분석에 필요해서 로그를 심어달라고 요청했을 뿐인데...
그럼 이걸 뭐라고 해야하지?

왜 안 되는지 이해도 안 되는데, 딱 잘라 안된다고만 하니까 상당히 스트레스를 받았다고 하시더라고요. 당연한 것처럼 말하니까 물어보기도 힘들었대요.

저는 그 개발자의 심리는 뭐였을까? 생각을 해봤어요. 확실하게 알수 없지만 근데 아마 이런 거지 않을까 싶어요.

'나는 엔지니어니까, 나한테 주어진 스펙을 만들어내고, 디버깅하고 테스트해서 버그가 없도록 하는게 임무다.'

'요구사항은 구체화시켜서 가져와야지... 요구사항을 제대로 만드는 건 기획자나 디자이너가 할일이지. 나는 구현하는 사람이잖아.'

이런 생각을 하고 있는 개발자라면 당연하게도 '뭐 아 버튼 하나 옮기는 게 그렇게 쉬운 게 아니다'라든지, '그거는 비동기 스트림에서 받아오는 거라 안된다' 말하고 그냥 끝나버릴 수밖에요.

저는 뭐 그 개발자가 정말로 이기적이고 빌런이라고 생각하진 않습니다. 다만 시야가 좁은 경우가 많지 않을까 해요.

'스펙은 주어지는 것이고, 나는 그것을 구현한다'에 집중하기 때문이죠. 거의 모든 개발자가 그렇겠지만 그 일 말고도 지금 많은 일이 밀려있거든요. 빨리 그걸 구현해내야 하는게 내 문제인 거예요. 그거에만 집중을 하면 당연히 상대방의 문제와 입장까지는 생각을 못하는 거죠.

저도 사실 이렇습니다. 저는 일단 내가 구현을 어떻게 할까에 대한 고민을 많이 하다보니, 진짜로 이게 해결하고자 하는 문제에 대해서 생각해보지 못할 때가 많거든요.

그렇다면 커뮤니케이션을 잘하는 개발자는 어떨까요? 

스펙 구현형이 아닌, 반대의 개발자는 무엇일까요?

저는 이 분들을 '문제 해결형' 개발자라고 정의해보았습니다.

문제 해결형 개발자

인터뷰 해본 바에 따르면, 커뮤니케이션을 잘하는 개발자는 이 스펙 구현형의 개발자와 반대의 모습을 보인다고 합니다.

'그냥 안 된다'라는 말을 하지 않아요. 

이렇게 말하면 오해하실 수 있는데요.

그럼 개떡같은 요구사항이 와도 다 된다고 말하라는 거야?' 라고 오해하실 수가 있는데요.

그들이 예스맨이라는 이야기는 아닙니다. 이상한 요구를 다 받아준다는 얘기가 아니에요.

디자인 리드분이 해주신 얘기를 그대로 옮겨볼게요.

소통이 안 되는 개발자는 목표가 아닌 수단에 집중하시는 분들이었던 기억이에요.

예를 들어서 '사용자가 구매를 편하게 하기 위해 버튼 위치를 여기로 옮기려고 하는데 어떨까요?' 라고 하면, 소통이 잘 되는 개발자는 '구매를 더 편하게 한다' 라는 목표에 집중을 해서 '여기 코드는 바꾸기 어려운데, 대신 이건 어떨까요?' 라고 논의가 이어져요.

실제로 그 제안이 맞고 틀리고를 떠나서, 안 된다 어렵다 바쁘다 등의 부정적인 태도가 아닌 어떻게든 되게 만들려는 태도가 중요한 거 같아요.

그런 태도가 느껴지는 분들은 실제로 일이 잘 안 되거나 구현이 오래 걸리더라도 '아 이 사람과 함께라면 어떻게든 문제를 해결할 수 있겠다' 라는 상호신뢰가 쌓이게 돼요.

이 말을 풀어볼까요? 

커뮤니케이션 잘하는 개발자들이 '안 돼요'라고 말하지 않는 이유는 단순합니다. 안 되는 '그것'이 핵심이 아니라는 거죠. 

문제 해결형 개발자는 '내가 요구받은 그 사항을 구현하는게 쉽냐 어렵냐'가 아니라, 그걸 가지고 '정말 고객과 사업의 문제를 풀 수 있느냐'에 집중합니다.

어떻게든 되게 만들려는 태도만 있다면 구현을 잘 못하거나, 일이 잘 안되어도 결국은 신뢰를 쌓게 된다. 저는 이 말이 가장 인상 깊었습니다. 

커뮤니케이션 잘하는 개발자들은 의도와 맥락을 이해해서, 더 좋은 스펙을 만들어내려고 해요. 그런 사람들은 리더 입장에서도 너무 소중합니다. 

제품팀 리더 분이 해주신 얘기를 옮겨볼게요.

(스펙 구현형) 개발자와 일하면 어려운 점이, 내가 일을 다 구체화해서 갖다 줘야 된다는 압박이 있어요. 

팀을 끌어가는데 있어서 상당한 부담이죠. 내가 정말 스펙을 아랫단계까지 정의해야 되는 거니까요. 그분들은 어떤 것이 문제이고, 어떤 것이 우선순위인지 판단해서 일하는 능력이 아직 없기 때문이죠.

그런데 믿을만한 (문제 해결형) 개발자는 그 '시야'란 게 있어요. 불확실한 문제와 맥락을 전달을 해도 돼요. 우리 팀의 우선순위, 리소스 같은 걸 직접 볼 수 있거든요. 그리고 문제를 해결할 수 있는 스펙을 직접 만들어 내는 사람인 거예요. 그렇게 해주면 리더는 너무나 편하죠.

또 개발로만 문제를 푸는 게 아니거든요. 자기가 하기 좀 그렇다면, 다른 팀한테 도움을 요청하기도 하고요. 중요하지 않다면 그냥 안 할 수도 있고요. 

그런 걸 보면 '헛일을 하지 않을 사람이구나' 라는 생각이 들고, 그런 개발자 한 명이 팀에 있고 없고가 엄청난 차이를 만들어요.

저는 이 얘기를 들으면서 딱 떠오르는 영상이 하나 있었습니다. 

유튜브에서 배달의 민족 김범준 전 대표가 인터뷰한 영상이예요. 안 보셨다면 꼭 한번 보시길.

https://www.youtube.com/watch?v=3H4umWD5bwI

거기 이런 말이 나와요.

- 개발자는 코딩 실력도 굉장히 중요하지만 그보다 더 중요한 것은 문제 해결력이다.

- 가장 좋은 방법은 프로그래밍 하는 것이 아니라 정책을 바꾸는 것일 수도 있다.

- 문제를 해결하기 위한 노력 중 80%는, 우리가 풀고자 하는 문제가 무엇인지 정확히 이해하는데 투자해야 한다.

- 개발자라면 본인을 코딩하는 사람으로 정의하지 않았으면 좋겠다.

김범준 대표님이 하는 얘기가, 제가 인터뷰했던 리더들의 생각과 맞닿아있어서 신기했습니다. 

커뮤니케이션 잘하는 개발자는 말을 유려하게 하는 것도, 아는 게 특별히 많은 것도 아닙니다. 

그저 문제를 해결하는데 집중합니다. 

그렇기 때문에 그냥 '안 돼요'라는 말을 하지 않는 거죠.

문제 해결형 개발자로 성장하기

물론 주니어 개발자로서는 사실 스펙 구현형 개발자에서 시작하게 될 수밖에 없다고 생각해요. 말이 스펙 구현이지, 그 엔지니어링이라는 게 뭐 쉬운 일이 아니잖아요.

하지만 연차가 쌓이고 기술적 숙련도가 올라가면, 우리는 관점을 바꿔볼 필요가 있습니다. 

새로 나온 기술 스택을 다룰 줄 알고, 클린하게 코드를 짜는 것도 중요합니다. 하지만 정말 직장인으로서 가치있는 개발자는 '회사의 문제를 고민하고 해결하는', '커뮤니케이션 잘하는 개발자'라는 거죠. 

개발자들이 좋은 코딩 스킬뿐 아니라 좋은 커뮤니케이션 스킬도 반드시 익혀야 한다고 생각합니다. 

하지만 좋은 코딩 스킬은 많이 강조하고 공부도 하지만, 반대로 커뮤니케이션 스킬은 어디서부터 어떻게 개선해야할지 잘 모르는 게 현실인 거 같아요.

그래서 앞으로 이 매거진에서는,

어떻게 하면 좋은 커뮤니케이션과 협업을 할 수 있는지, 

어떻게 문제 해결에 초점을 맞출 수 있는지, 

어떻게 팀을 승리하도록 만드는 개발자가 될 수 있는지, 에 대해 얘기해보려 합니다. 

그리고 실전에서 써먹을 수 있는 유용한 팁들을 다룰 거예요.

이 글을 읽고 계신 당신이 한 단계 성장하고 싶은 개발자이거나, 개발자와 더 잘 협업하고 싶은 기획자, 디자이, 혹은 팀장이라면 구독 및 댓글로 알려주세요! :-)