저는 회사에 입사하고 나서 주변에 이런 질문을 되게 많이 했어요.

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

궁금하잖아요.

근데 디자이너나 PM이나 QA나 이런 분들한테 물어보면 다들 비슷한 포인트를 얘기하시더라고요

'바로 커뮤니케이션이 잘 된다', '말이 잘 통한다'라는 거였어요

제가 생각했을 때 훌륭한 개발자, 슈퍼 개발자라고 하면 진짜 한 달에 걸릴 기능을 하루 만에 해내고, 되게 Low-level까지 아는 그런 이미지였거든요.

근데 같이 일하는 팀원들의 관점에서는 그게 아니더라고요.

사실 그분들한테는 제일 중요한 게 커뮤니케이션 능력이에요.

말이 잘 통하고 협업이 잘되는 사람이 그들한테 훌륭한 개발자인 거죠.

어떤 분은 '이 회사에 그런 (커뮤니케이션 잘하는) 개발자가 많아서 자기는 이 회사에서 계속 일하고 있다' 라는 말까지 하시더라고요.

생각보다 개발자들 본인들한테 물어도, 다른 개발자가 좋은 개발자일지를 판단할 때 다른 직군과 커뮤니케이션 능력을 거의 1순위로 뽑으시더라고요

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

그런데 말이죠. 저는 여기서 약간의 의문을 가졌습니다.

사실 '커뮤니케이션'이라는 건 굉장히 넓잖아요. 다들 커뮤니케이션이라고 퉁쳐서 말을 하는데 서로 다 다른 걸 얘기하고 있는 건 아닐까?

말을 잘 하는 것부터 해서, 정보 수집을 잘하는 것, 다른 사람들한테 공감을 잘해주는 것, 복잡한 내용을 정리하는 것 등등 '커뮤니케이션'이라는 말이 굉장히 다양한 상황과 능력을 다 포함한단 말이죠.

나름 제가 전직 기자로서 커뮤니케이션에 대한 관심이 많은 사람이거든요.

근데 개발자로서 커뮤니케이션을 잘한다는 것이 도대체 무엇인가, 좀 더 구체화할 수는 없을까?

갑자기 기자 정신이 올라오더라고요. 회사를 돌아다니면서 물어보기 시작했어요

대표부터 해서 디자인 리드, 프로덕트 리드 데이터 분석가, 사업개발 QA 엔지니어 등등..

다들 연차가 꽤 있으시고 개발자하고 긴밀하게 일한 경험들이 있는 분이었어요.

어떤 사람이 커뮤니케이션을 잘하는 개발자예요? 개발자랑 일하기 진짜 힘들었을 때가 언제예요?

다들 개발자하고 일하면서 힘들었던 경험이 다 하나씩은 있으시더라고요.

이분들이 일하고 싶은 개발자와 아닌 개발자의 얘기를 들어본 결과 어떤 공통점이 보였어요. 어떤 기본 전제가 있더라고요.

그게 뭐였을까요?

문제 해결형 개발자

커뮤니케이션을 잘하는 개발자의 공통점은 '안 된다'라는 말을 그냥 하지 않는다는 거예요.

디자이너가 버튼을 이쪽에서 이쪽으로 '옮기고 싶다'라고 말했을 때 '아 그거는 구조상 안 돼요' 이렇게 말하지 않아요.

"그럼 뭐 개떡 같은 요구사항이 와도 된다고 해야 되는 거야?" 라고 오해할 수가 있는데요. 그들이 예스맨이라는 얘기가 아닙니다. 이상한 요구를 다 받아준다는 얘기가 아니에요.

다만 그 실제로 버튼을 옮기는 게 말도 안 되게 어렵다고 해도 그들은 안 된다고 말하는 게 아니라 다시 물어보는 거죠.

이게 풀려고 하는 문제가 무엇인지? 아 그렇다면 지금 버튼은 이런 이유로 어려우니까 그 문제를 해결하기 위해서
이런 이런 솔루션 어때요? 라고 제안한다고 하더라고요

그들이 안 된다는 말을 안 하는 이유는 '안 되는 그것'이 핵심이 아니라는 거죠.

요구받은 그 상황을 구현 하는 게 쉽냐 어렵냐, 이게 아니라 그걸 가지고 정말 고객과 사업의 문제를 풀 수 있느냐 집중을 하는 거죠.

그래서 어떤 스펙을 받았을 때 된다 안 된다보다는 그 의도와 맥락을 이해해서 더 좋은 스펙을 만들어 내려고 합니다.

이런 특징을 가진 개발자를 저는 '문제해결형 개발자' 라고 부르려고 해요.

스펙 구현형 개발자

'문제 해결형'의 반대는 무엇일까요. 이거는 '스펙 구현형' 개발자 라고 이름을 붙여 봤어요.

말 그대로 주어지는 스펙을 구현하는 것에 초점을 맞추는 게 스펙 구현형 개발자예요.

저희 QA님이 얘기를 해 주신 사례인데요.
이 분이 이제 입사한지 얼마 안 됐을 상태였는데 로그를 심어야 되는 상황이었어요

이 분이 로그랑 파라미터를 정의해 가지고 개발자한테 전달했는데 개발자가 댓글로

아 그거는 스트림에서 비동기로 받아 온 거라서 서버 api 구조를 바꾸지 않으면 이 화면에서 찍는 거는 안 된다

이런 식으로 답을 딱 한 거예요. 거기서 그냥 쓰레드가 끝났대요.

이 분이 멘붕이 온 거예요.

비동기? 스트림? API?
아니 나는 이거 로그 분석할 때 필요한 데 그럼 이거 어떻게 해야 되지?

그냥 안 된다고만 하니까 되게 힘들었다고 하시더라고요. 너무 당연한 듯이 말하니까 이게 물어보기도 힘들었대요.

저는 이걸 듣고 그 개발자의 심리는 뭐였을까, 그런 생각을 해봤어요. 근데 아마 이런 이런 거지 않을까 싶어요.

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

은연중에 요구사항은 구체화시켜서 가져와야지. 요구사항을 제대로 만드는 거는 기획자나 디자이너가 할 일이고 나는 구현할 사람이잖아. 라는 생각을 갖고 있는 거죠

그러다 보니까 버튼 옮기는 게 그렇게 쉬운 게 아니다, 그거는 비동기 스트림에서 받아오는 거라 안 된다, 하고 그냥 끝나버리는 일이 발생하는 거죠.

저는 그 개발자가 정말로 이기적이고 빌런이라기 보다는 그냥 시야가 좁은 경우가 많지 않을까 해요.

일단 지금 많은 일이 밀려 있는데 빨리 그걸 내가 쳐내야 되는 게 내 문제고 그걸 잘 구현하는데 집중을 하려 하니까, 상대방의 문제나 입장까지는 생각을 못하는 거죠

저도 생각해 보면은 아직 스펙 구현형 개발자에 가까운 거 같아요. 일단 제가 구현을 어떻게 해야 될까 에 대한 고민을 많이 하다 보니까 진짜로 이게 해결하고자 하는 어떤 문제에 대해서는 생각을 잘 못하더라고요.

아직 좀 시야가 좁은 거죠.

되게 만들려는 태도

근데 문제해결형 개발자는 초점이 다릅니다.

디자인 리드 분이 해주신 얘긴데 그대로 옮겨 볼게요

소통이 안 되는 개발자는 목표가 아닌 수단에 집중하시는 분들이었던 기억이에요.
예를 들어서 '사용자가 구매를 편하게 하기 위해 버튼 위치를 여기로 옮기려고 하는데 어떨까요?' 라고 하면
'그 코드는 고치기 어려워요' 대답을 하는 거죠
이런 대답을 들으면 디자이너는 힘이 빠지게 돼요. 상대방이 버튼이라는 수단에 집중하고 있으니까요.

근데 소통이 잘 되는 개발자는 '구매를 더 편하게 한다' 라는 목표에 집중을 해서 '여기 코드는 바꾸기 어려운데
대신 이건 어떨까요?' 라고 논의가 이어져요. 실제로 그 제안이 맞고 틀리고를 떠나서 안 된다 어렵다 바쁘다 등의 부정적인 태도가 아닌 어떻게든 되게 만들려는 태도가 중요한 거 같아요.

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

이렇게 말을 해 주셨는데, 저는 커뮤니케이션 잘하는 개발자는 구현을 잘 못하거나 일이 잘 안 되더라도 결국에는 신뢰를 쌓게 된다는 말이 되게 인상 깊더라고요.

문제를 보는 '시야'

또 다른 얘기가 있는데 지금 제품팀 리더로 일하는 분이 해주신 얘기예요.

그런 (스펙 구현형) 개발자와 일하면 어려운 점이 내가 일을 다 구체화해서 갖다 줘야 된다는 압박이 있어요. 팀을 끌어가는데 있어서 상당한 부담이죠. 내가 정말 스펙을 아랫단계까지 정의하지 않으면 그분들은 어떤 것이 문제이고
어떤 것이 우선순위인지 판단해서 일하는 능력이 아직 없으니까.

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

개발로만 문제를 푸는 게 아니예요. 자기가 하기 좀 그렇다면 다른 팀한테 도움을 요청 하기도 하고요. 중요하지 않다면 그냥 안 할 수도 있고요. 그런 걸 보면 '헛일을 하지 않을 사람이구나' 라는 생각이 들고, 그런 개발자 한 명이
팀에 있고 없고가 엄청난 차이를 만들어요.

요런 말을 해 주셨는데, 저는 요 얘기를 들으면서 딱 떠오르는 게 있었는데요.

혹시 유튜브에서 배달의 민족 김범준 전 대표가 인터뷰한 영상 보셨나요?
안 보셨으면 꼭 한번 보세요. 아니 두번 보세요.

거기 이런 말이 나와요.

• 개발자는 코딩 실력도 굉장히 중요하지만 그보다 더 중요한 것은 문제 해결력이다
• 가장 좋은 방법은 프로그래밍 하는 것이 아니라 정책을 바꾸는 것일 수도 있다.
• 문제를 해결하기 위한 노력 중 80%는 우리가 풀고자 하는 문제가 무엇인지 정확히 이해하는데 투자해야 한다.

저는 그 인터뷰가 제가 인터뷰했던 리더들의 생각하고 너무 맞닿아 있어서 되게 신기하더라고요

개발자는 코딩하는 기술자가 아니라 문제를 해결하는 사람이라는 거.
그렇기 때문에 그냥 '안 돼요'라는 말을 하지 않는다는 거.

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

물론 주니어 개발자로서는 솔직히 스펙 구현형 개발자에서 시작하게 될 수밖에 없다고 생각을 해요.

말이 스펙 구현이지, 개발이라는 게 뭐 쉬운 일이 아니잖아요.

하지만 점점 더 연차가 쌓이고 숙련도가 쌓이게 되면, 관점을 바꿔서 문제 해결형 개발자로 가려는 노력을 해야 되는 거 같아요.

내가 새로 나온 스택을 사용할 줄 알고, 코드를 클린하게 짜는 것도 좋지만 결국에 가치있고 희소한 개발자는 회사의 문제를 고민하고 해결하는 사람이라는 거죠.

그래야 단순히 연차만 높은 개발자가 아닌 진짜 시니어 개발자, 테크 리드가 되는 거 같아요.

근데 저도 아직은 햇병아리라서, 그저 스펙을 구현하기에 벅찬 개발자인데요.

이런 말을 들으면 맞는 말이고, 공감은 되는데 실제로 내가 문제 해결형 개발자로 성장하려면 어떻게 해야돼? 라고 하면 사실 저도 잘 모르겠더라고요.

여러분이 생각하기에 스펙 구현형 개발자에서 문제 해결형 개발자로 진화하려면 어떻게 해야한다고 생각하시는지 댓글로 달아주시면 큰 도움이 될 거 같습니다.

좀 더 고민해서 다음번에는 구체적인 실천 아이템들을 정리해서 가지고 와볼게요.

https://youtu.be/fe6_wCixJwE