[일기장] 커뮤니케이션을 잘하는 개발자

 

들어가며

개발자가 되기 위해 노력하면서 다양한 기업 공고를 살펴봤습니다. 그때마다 기업들은 타 직군과의 커뮤니케이션을 잘할 수 있는 사람을 채용하길 원했습니다. 그럼 나는 타 직군과의 커뮤니케이션을 잘하는 개발자일까 생각했습니다. 이번 기회에 나는 동료와 어떻게 커뮤니케이션하며, 커뮤니케이션을 할 때 내가 갖고 있는 차별점은 무엇인지 정리해보려 합니다.

 

 

 

 

 

 

---

 

 

 

 

 

 

 

일 잘하는 사람

창업학 복수전공을 선택하고 처음 들었던 전공 시간. 교수님은 제게 '일 잘하는 사람이란 무엇일까요'라는 질문을 한 적이 있습니다. 그 물음에 "동료가 일을 잘할 수 있도록 디테일까지 신경 쓰는 사람이 일을 잘하는 사람이라고 생각한다"라고 답한 적이 있습니다. 학교를 다니면서, 디테일을 신경 쓸 수 있는 기획자가 되고 싶다고 생각했습니다. 디테일을 신경 써야, 동료들의 소중한 시간을 뺏지 않을 수 있다고 생각했습니다. 그러기 위해서는 '문서화'를 잘해야 한다고 생각했습니다. 그동안 수많은 삽질을 해왔기에, 문서화의 중요성을 깨달을 수 있었습니다. 이와 관련된 작은 경험 하나를 공유하려 합니다.

 

 

 

 

 

 

---

 

 

 

 

 

 

 

기록한다는 것

한 번은, 창업동아리 PM으로 활동하며 특정 사업 및 서비스를 기획하고 있었습니다. 기획을 할 때 항상 팀원들에게 Why에 대해 집중해야 한다고 말했습니다. 이를 통해 팀은 항상 왜 이 기획을 해야 하는가, 왜 우리의 고객이 우리의 제품을 사용해야 하는가 등의 고민을 할 수 있었습니다.

 

Why에 대한 고민을 해결하기 위해 많은 회의를 해야 했습니다. 하지만 PM으로서 회의에 집중하느라 녹음도 하지 못한 채, 회의록을 작성하지 못했습니다. 그렇게 시간이 지나 다시 회의를 진행하려 할 때 문제가 생겼습니다. 시험이 끝난 후 팀원들이 다시 회의를 진행하려 모였는데, 당시 회의 내용을 문서화하지 않아 팀원들이 저번 회의에 어떤 이야기를 했는지 기억하지 못했습니다. 그래서 이미 논의한 내용을 다시 반복해서 이야기했습니다. 이때 기획자로서 일을 잘하려면 함께 일하는 동료들의 시간을 뺏지 않도록 문서화를 잘해야 하는구나 깨달았습니다.

 

문서화를 잘한다면, 팀원의 소중한 시간을 뺏지 않을 수 있고, 그런 디테일까지 신경 쓸 수 있는 사람이야 말로 일 잘하는 사람이 아닐까 생각했습니다. 문서화는 기획자뿐 아니라 개발자에게도 대단히 중요하다고 생각했습니다.

 

 

 

 

 

 

 

---

 

 

 

 

 

 

기록하는 개발자

개발자도 '문서화'에 신경 써야 하는 직군이라 생각합니다. 백엔드 개발자로서, 기획자, 디자이너, 프론트엔드 개발자 등의 팀원과 협업합니다. 그 과정에서 백엔드 개발자만이 생각할 수 있는 내용이 있습니다.

 

 

기획자와의 협업

백엔드 개발자는 기획자가 작성한 기능 명세서를 살펴보며 기능을 개발합니다. 기능 명세서를 살펴봤을 때 특정 문제가 발생할 수 있다는 것을 인지했음에도 기획서대로 처리해야 한다며, 개발했을 때 발생할 수 있는 문제를 기획자에게 전달하지 않는 개발자들을 종종 보곤 했습니다. 혹은 특정 문제 상황이 발생했을 때 어떻게 처리해야 할지를 더 상세하게 명세서에 작성하기를 요구하는 개발자들도 보곤 했습니다.

 

각 기업마다 협업하는 방식은 다르기에 이런 협업 방식이 틀린 것이 아닐지 모릅니다. 그럼에도 만약 저라면, 기획자가 빠르게 문제를 해결할 수 있도록 소통함으로써 팀 전체의 생산성을 올릴 것 같습니다.

 

기능 명세서대로 개발했을 경우 기획자에게 앞으로 발생할 수 있는 문제 상황에 대해 상세하게 설명하며, 문제에 관한 대안책으로는 어떤 것들이 있는지, 대안책으로 문제를 해결했을 때는 어떤 기대효과가 있을 수 있는지 문서화하거나 구두로 전달하며 소통할 것입니다.

 

기획자를 준비했던 입장에서, 특정 기능에서 문제가 발생했을 때, 특정 문제가 왜 발생했는지 파악하기가 대단히 어렵습니다. 심지어 문제의 원인을 파악하는 과정에서 많은 시간을 보내야 할 수 있습니다. 하지만 개발자가 이 부분을 명확하게 설명한다면 기획자는 다른 일을 처리할 수 있기에 보다 생산성이 올라갈 수 있지 않을까 생각했습니다. 

 

이런 문서화는 개발자와 협업할 때도 대단히 중요하다고 생각합니다. 

 

 

 

 

 

 

 

타 개발자와의 협업

자신이 작성한 코드는 금방 이해할 수 있는데, 타인이 작성한 코드는 어떻게 동작하는 것인지 이해하기 어려운 경우가 있습니다. 만약 타인의 코드를 이해해서, 수정해야 하는 상황이라면 타인의 코드를 이해하기 위해 많은 시간을 쏟아야 하는 경우가 발생합니다. 이때 개발자로서 문서화를 잘한다면 다른 개발자가 내가 작성한 코드를 이해하는데 있어 도움을 줄 수 있습니다.

 

저는 PR 시, 다른 개발자가 제가 개발한 내용을 보다 잘 이해할 수 있도록 정리합니다. 이를 통해 타 개발자가 제 코드를 이해하기 위해 사용하는 시간을 줄임으로써 다른 개발자의 생산성을 올리기 위해 노력했습니다. 또한 개발하면서 배운 내용을 블로그에 정리함으로써, 제가 어떻게 작업했는지를 자세하게 알고 싶은 개발자들에게 도움이 되려 노력했습니다.  

 

누군가에게 내가 한 작업을 설명하려면 치열하게 공부해야 했습니다. 특정 작업을 했다면, 작업을 왜 했는지, 작업을 통해 어떤 문제를 해결했는지 설명하려면 코드 한 줄을 작성하더라도 왜 그렇게 작성했는지 고민해야 했습니다. 다른 개발자의 생산성을 올리기 위해 노력하는 과정에서 성장할 수 있었습니다.  

 

 

 

 

 

 

---

 

 

 

 

 

 

 

 

마치며

이 글을 정리하면서, 커뮤니케이션을 잘하는 사람이란 단순히 말을 잘하는 사람이 아니라, 어쩌면 옆에 있는 동료가 일을 잘할 수 있도록 동료의 어려움을 이해하고 먼저 배려할 수 있는 사람이 아닐까 생각했습니다. 앞으로 커뮤니케이션할 동료를 만나게 된다면, 동료가 조금 더 일을 잘할 수 있도록, 동료의 생산성을 올릴 수 있도록 문서화를 더욱 신경 쓸 수 있는 개발자가 되고 싶습니다.