개발자의 소통 능력.

갓 2년차 개발자가 되던 해에 HR팀에서 회사 신입 채용 홍보 인터뷰를 촬영하기 위한 인원을 요청해 참여할 기회가 있었습니다. 그때 FE 개발자 채용에 대한 인터뷰로 제가 참여하게되었어요. 사실 당시 저연차이고 경험이 부족하다 생각해서 굉장히 그 인터뷰에 참여하는게 부담스러웠습니다. 긴장하며 여러 가지 질문에 대답하는데, 지나고나니 꽤 오래 기억에 남는 질문이 하나 있었습니다. '개발 능력' vs '소통 능력' 사실 당연히 둘다 중요하지만 그때 제게는 당시에 맡은 기능 개발을 충실히 수행해야하고 일정 내 처리할 수 있어야한다는 마음이 업무에 있어서 앞선 터라 망설임없이 '개발 능력'을 선택했습니다. 함께 인터뷰에 참여했던 개발자 동기도 저와 같이 '개발 능력'을 선택했더군요. 옆에 계셨던 시니어 개발자 분은 '소통 능력'을 선택하셨어요. 저도 연차가 조금 오르고 한 서비스를 개편하고 고도화해나가는 경험이 조금은 쌓이면서 지나고 보니 여전히 두가지가 모두 중요하지만 '소통'이란 것의 중요함을 점점 더 많이 느낍니다. 개발자의 산출물은 단순하게는 코드이므로 그 산출물의 퀄리티를 높이는 것은 당연히 중요합니다. 구조와 설계, 클린 코드... 하지만, 그 개발자의 코드가 서비스로 구현되기위해 작성되는 것이라면 조금 이야기가 다른 것 같습니다. 서비스의 비즈니스 요건, 문제 해결을 위해 개발자가 가진 기술을 통한 코드 작성 만으로 해결되기는 비효율적인 경우가 많은 것 같습니다. 오히려 기획 및 디자인 의도를 파악하고 적극적으로 의견을 전달하거나 운영 차원의 대응을 고민하는 것이 당연하게도 효율적이고 효과적입니다. 다만, 어려운 것은 항상 우리가 이것을 완벽하게 해내기란 쉽지 않은 것 같습니다.(사실 제 얘기입니다.) 한정된 일정 속에서 더 면밀하게 전달 받은 신규 기획과 디자인이 서비스에 미치는 가치를 고민하기 어려울 수 있고, 신규 기능이 유저에게 전달하는 가치를 위해 그대로 코드로 구현하는 것 이외에 다른 방향으로 동일한 가치를 만드는 방법에 대해 고민하기 어려울 수 있습니다. (잘해내는 분들이 부럽습니다.) 여기서 '소통 능력'이 큰 도움이 되는 것 같습니다. 사실 '소통하려는 태도'가 더 맞는 것 같습니다. 기획자, 디자이너로 예를 든다면, 개발자와는 다른 직군이기에 서비스를 바라보는 관점이나 방식이 조금씩 다를 수 있습니다. 신규 기획안이나 디자인 시안이 전달되었을때 항상 '질문'할 거리가 발생합니다. 이때 넘겨짚지 않고 적극적으로 질문해서 이해의 간극을 서로 줄입니다. 넘겨짚는 것은 위험할 수 있어요. 당장의 소통으로 인한 초기 시간 비용이 발생하지만 그 소통 속에서 새로운 문제 해결 방식이 발생하기도하고 기존에 기획된 기능이 더 구체화되고 명확해졌던 것 같습니다. 이는 개발 후 검증 기간, 배포 이후 기능 고도화 협의까지 긍정적으로 작용하는 것 같아요. 매번 서비스 버전을 거듭해나가면서 스스로 아쉬웠던 점을 되돌아볼때 기획이나 디자인의 의도, 컨셉이나 하나의 요건이 우리 서비스에서 어떤 가치로 녹여지고자 내게 전달되었는지 내가 놓친 부분이 어느정도는 있었던 점 같습니다. 이런 부분을 조금 더 보완하고 더 완성도 있게 개발하는데 '소통'은 참 좋은 도구입니다. 함께 일하는 사람들과 점점 더 호흡을 맞춰가며 손발이 맞아가는 느낌을 받는 것도 즐거운 일이구요. 버전 배포를 앞두고 돌아보며 떠올랐던 반성으로 시작해서 끄적이다보니 길어졌네요..