좋은 개발자의 조건 <커뮤니케이션을 잘하는 개발자>

 

INFCON 2023 송범근님의 커뮤니케이션 잘하는 개발자의 4가지 조건 발표영상을 보고 정리한 (+ 제 개인 생각도 한스푼 첨가한.. ☕️) 게시글 입니다. 너무나 좋은 영상이니, 꼭 직접 영상을 보셨으면 좋겠어요. 😀

---

 

🤔 들어가기 앞서, 좋은 개발자는 어떤 개발자일까?

좋은 개발자란 어떤 조건을 가지고 있을까요 ?

• 병아리 개발자 시절, 전 좋은 개발자는 당연히 개발을 잘해야 좋은 개발자라 생각했어요.
• 개발자의 목표는 주어진 요구사항을 완벽하게 구현해내는 것이라 생각했죠.
• 하지만, 여러 스프린트를 거치며, 다양한 직군들과 만나고, 시니어 직급들을 바라보며, 생각이 바뀌었어요.
• 좋은 개발자란, 소통이 잘 되는 개발자구나 !

그런 저의 깨달음과 상통하는 발표영상을 보게되어 정리해보려해요.

 

💬 소통을 잘하는 개발자란 ?

좋은 커뮤니케이션이 무엇일까요?

상대방에게 말을 잘하는 것, 상대방의 의견에 공감을 잘하는 것일 수도 있지만, 너무 추상적이죠.

좀 더 구체화 해볼 수 없을까요?

 

발표자는 다양한 사람들에게 커뮤니케이션이 잘 되는 개발자와 못하는 개발자에 대해 물어보았고,

잘하는 개발자의 조건의 답변엔 다양하지만, 못하는 개발자의 조건엔 공통점이 보였다고 해요.

 

소통을 못하는 개발자는 공통점이 있어요.

그냥 "안된다" 라고 말하는 개발자

우리는 이런 개발자를 스펙 구현형 개발자 라고 이름을 붙였어요.

좋게 설명하자면, 주어진 스펙을 구현하는 것에 집중하는 개발자 라고 볼 수 있죠.

여기 예시 대화가 있어요. 저 긴 답변을 받은 질문자는 어떤 마음이었을까요?

😥: 안된다고만 하니까 힘들어요.당연한듯이 말하니까 물어보기도 힘들어요.

 

반대로, 그 개발자의 심리는 무엇이였을까요?

🥸: 나는 엔지니어. 주어진 스펙을 만들어내고 구현해내는 것이 나의 임무.
      개발자는 스펙을 주면 잘 구현해내는 사람.
      디자인하거나 기획하는 건 당신들의 임무. 나는 그것을 구현하는 사람.

 

개발자가 이기적이고 빌런처럼 보이나요?

그 보단, 다만 시야가 좁은 개발자라고 볼 수 있어요.

왜냐면, 구현에만 집중하면 일의 시야가 좁아지기 때문이에요.

 

내게 주어진 임무만 하려다 보니, 상대방의 입장이나 문제는 생각하지 못하는 거죠.

이러한 개발자들이 안된다라고만 하는이유는, 스펙을 구현하는데 집중하기 때문이에요.

 

반대로, 소통을 잘하는 개발자는요?

문제 해결형 개발자라고 말할 수 있어요.

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

그럼 안된다는 말을 무조건 하지 말아야 하나요?

예스맨을 하라는 말은 아니에요.

 

예시를 보며 정리해봅시다.

 

풀려는 문제가 무엇인지 일단 다시 물어보고 제안을 하고 있어요.

기획/디자인의 의도와 맥락을 이해해서 더 좋은 스펙을 만들어내려는 거죠.

그래서, 문제 해결형 개발자 라고 이름을 붙였어요.

 

말을 유려하게 잘하거나, 성격이 외향적이든 중요하지 않아요.

문제해결에 집중하는 그 특징이 소통을 잘하는 개발자의 공통점이에요.

 

즉, 이러한 개발자들이 안된다라고 말하지 않는 이유는 문제 해결에 집중하기 때문이에요.

 

😌 그래서 어떻게 해야하나요?

• 누구나 스펙구현형 개발자에서 시작합니다.
• 주니어입장에선 누구나 경험할 것이라 생각해요.
• 말이 스펙구현이지 엔지니어링이라는 것이 쉬운일은 아니죠.

그래도, 연차와 숙련도가 쌓이면 관점을 바꿔 문제해결형 개발자로 진화하고자 하는 노력을 해보는 것이 어떨까요?

 

본론, 소통을 잘하기 위해 4가지 습관을 들이자.

첫째, 요구사항을 들으면 해결하려는 문제와 의도에 대해 묻는다.

대부분의 스펙구현형 개발자가 많이하는 실수가 문제해결을 생각하지 않는 다는 것이에요.

 

일하다가 개발관련하여 질문/요청이 들어왔을 때,

안된다/된다 답하기 전, 상대방의 의도와 상황을 먼저 물어보고 파악합시다.

 

 

둘째, 상대방의 말을 듣고 내가 이해한 바를 공유하자.

같은 단어를 써서 이해하고 있는데 상대방이 다르게 이해하는 것 같을 때가 있죠.

 

남들도 나처럼 이해할 것이라 가정하는데 대부분 아니에요.

상대방의 말을 듣고 중간에 끊거나 바로 답을 얘기하기 전, 자기가 이해한 바를 요약해서 공유합시다.

 

셋째, 안된다고 말할땐 상대방의 관점에서 대안을 제시하자

 

상대방이 궁극적으로 원하는 것은 왜 기술적으로 어려운지 이해하는 게 아니에요.

알파와 라이브가 뭐가 다른건지 -> 가 궁금한게 아니라 -> 제휴사에 어떻게 액션을 취해야할 지가 궁금한 것이죠.

 

안되는 이유를 납득시키기 보단 상대방에게 대안을 제시합시다.

대안이 즉 문제해결 이니까요.

 

넷째, 문제를 해결할 또 다른 방법은 없을지 고민해보자.

예시 상황이 있어요,

로그인을 할 때 폰을 점유하고 있다는 인증이 필요한데, 이 인증이 14초나 걸렸어요.

즉, 가입을 하는데 14초의 로딩이 발생하는 거죠.

 

해결하려면, 외부 인증업체를 바꿔야 하는데, 6개월이나 걸린다고 해요.

6개월을 기다리고 14초의 로딩으로 이탈율을 냅둘 것인가, 6개월동안 새로 개발할 것인가 고민을 했죠.

 

결국 솔루션은, 둘 중 하나를 고르지 않았어요.

더 좋은 방안을 찾았던 거죠.

 

즉, 된다/안된다의 흑백 논리에 갇히지 않는 것이에요.

버튼이 추가되는게 사용자에게 좋은 UX를 줄 것 같은데, 다만 개발하는 것이 공수가 많이 들 것 같아요.

버튼을 추가하면서 공수가 안들 방법을 고민해보는거죠.

 

즉, 하느냐 안하느냐의 딜레마 상황이라고 느껴질 때,

혼자 안된다고 단정하지 않고,

다른 방법이 없을 지 더 생각해보자구요.

 

🥰 요약정리

다른 직군과의 커뮤니케이션 능력이 필수 !

문제해결에 집중해보자!