이 글은 인프콘 2023 다시보기 영상을 시청하고 기록을 남기기 위한 목적으로 작성되었습니다.
커뮤니케이션 잘하는 개발자의 4가지 습관 - 송범근
최근 취업 준비를 하면서 채용 공고를 읽는 작업이 많았습니다. 요즘 개발자 채용 시장에서 신입 개발자에게 요구하는 역량 중, 기술 역량 못지않게 많이 요구하는 능력이 ‘이것’임을 알 수 있었는데요
바로 “커뮤니케이션을 능력”, “협업 능력” 입니다.
혼자서 잘하는 개발자
혼자만 잘하는 개발자
이제 이런 개발자는 어디서든 환영받지 못합니다.
좋은 개발자가 되려면 다른 직군과의 커뮤니케이션 능력이 필수입니다. 개발 프로젝트의 성공은 기술적인 역량 뿐만 아니라 팀 간의 원활한 커뮤니케이션에 크게 영향을 받습니다.
그렇다면 커뮤니케이션을 잘하는 개발자는 어떤 습관을 가지고 있을까요?
그 전에 커뮤니케이션을 못하는 개발자의 특징을 한 가지 예시를 들어 설명하겠습니다.
기획자 💁🏻♀️: 음.. 이 버튼을 누르면 화면에 추천 상품 목록이 뜨는 기능이 추가되면 좋겠어요. 다음주까지 가능할까요?
개발자 🧑🏻💻: 지금 API 스펙 구조상 그 기능은 다음주까지 구현 못해요.
기획자 💁🏻♀️: 아.. 그럼 어느정도 기간이면 구현할 수 있나요?
개발자 🧑🏻💻: 전체 구조를 다 바꿔야 해서 오래 걸립니다. 그 기능은 구현하기 힘들어요.
커뮤니케이션 못 하는 개발자의 특징은 바로 주어진 스펙을 구현하는데만 집중하는 개발자 입니다. 기획자나 디자이너가 개발자에게 어떤 요구사항을 했을 때, “그건 안 돼요” 라고 통보하며 의사 전달을 제대로 하지 못하는 경우가 있습니다.
이들은 왜 안 되는지 설명을 하지 않습니다.
왜 일까요? 바로 이 개발자는 기획자가 요구하는 스펙에만 집중을 했기 때문입니다. 기획자가 추천 상품 목록이 뜨는 기능이 어떤 목적에서 필요한지 궁금해하지 않습니다.
단지, 이 스펙 자체를 ‘구현’하는 데만 초점을 두고, 이 기능이 왜 필요한지 생각하고 있지 않습니다.
위의 상황에서 개발자는 추천 상품 목록이 뜨는 기능이 왜 필요한지 목적에 집중했다면 다음과 같이 답했을 것 입니다.
기획자 💁🏻♀️: 음.. 이 버튼을 누르면 화면에 추천 상품 목록이 뜨는 기능이 추가되면 좋겠어요. 다음주까지 가능할까요?
개발자 🧑🏻💻: 그 기능이 어떤 목적으로 필요한지 알 수 있을까요?
기획자 💁🏻♀️: 사용자의 검색 기록을 분석해서 이와 연관된 상품을 추천 상품 목록으로 보여준다면, 사용자의 서비스 만족도가 올라갈 것 같아요.
개발자 🧑🏻💻: 그렇군요, 그 기능을 추가하게 된다면 현재 API 구조를 전체적으로 수정하는 작업이 필요할 것 같아서 다음주까지는 힘들 것 같아요. 하지만 서비스 만족도를 높이기 위해서는 추가하면 좋긴 하겠네요. 혹시 구체적으로 생각하시는 구조를 말씀해주실 수 있나요?
기획자 💁🏻♀️: 어떤 어떤 구조가 좋겠어요
개발자 🧑🏻💻: 빠른 시일 안에 반영하기에는 조금 무리일 수 있겠네요. 급한 상황이라면, 일단 검색 기록 데이터를 기반으로 분석하는 작업부터 다음주까지 해보고, 데모 버전으로 간단하게 기능을 구현하도록 해보겠습니다.
개발자는 기획의 의도를 파악하며 서로간의 배려와 이해를 바탕으로 현실적인 대안을 제시하고 있습니다. 커뮤니케이션을 잘하는 개발자는, 주어진 스펙 구현에 집중하는 것이 아닌 문제 해결형 개발자입니다.
전에 살펴봤던 예시에서 개발자는 기획의 의도를 물어보며 목적을 이해하고, 현실적으로 그에 맞게 정말 필요한 것이 무엇인지 파악하고 있습니다. 이에 따라 기능을 축소하거나 추가 일정을 확보하는 방법 등 다양한 대안을 제시하여 합리적인 의사 결정을 할 수 있게 됩니다.
이제 커뮤니케이션을 잘하는 문제 해결형 개발자의 4가지 습관에 대해 알아보겠습니다.
개발 스펙과 관련된 질문/요청이 들어왔을 때 바로 된다/안 된다 답을 하는 대신에 해당 스펙이 해결하려는 문제, 상대방의 의도/상황을 먼저 물어본다.
분명 같은 말을 하고 있는데 저 사람 다르게 이해한 것 같다는 느낌을 들었던 분들이 많을거라고 생각합니다.
남들도 나처럼 이해한다고 가정하지 말고, 내가 이해한 바를 상대방에게 요약해 확인하는 습관을 들이면 훨씬 효율적으로 소통할 수 있을 것입니다.
상대방의 말을 듣고, 내가 이해한 바로 요약해서 상대방에게 전달한다.
흔히 왜 이 기능은 안되냐는 질문은 기술적으로 왜 어려운지 이해하는 것이 아닙니다.
상대방이 궁극적으로 원하는 것은 안 되는 상황을 해결하기 위해 다른 대안을 알고 싶어 하는 것입니다.
문제가 있을 때, 안 되는 이유를 기술적으로 길게 설명하는 대신에 제약을 덜 받는 다른 방향성이나 대안을 제시한다.
단순히 된다/안 된다의 흑백 논리에 갇히지 않는 것
하느냐 안 하느냐 딜레마 상황이라고 느껴질 때, 혼자 안 된다고 단정하는 대신에 혹시 다른 방법은 없을까? 한번 더 고민해본다.
문제가 발생했을 때, 이건 현실적으로 불가능하다는 결론을 섣불리 판단하지 말고, 한 번 더 다른 대안에 대해 고민해보는 것이 중요합니다. 해당 서비스가 사용자에게 미치는 영향에 대해 생각하고, 이를 다른 방식으로 구현하면 어떨까? 고민하며 적극적으로 문제를 해결하려는 마인드를 가지는 것이 좋습니다.