[뉴비들을 위한 업무 팁 #3] 개발자에게 문과역량이란

개발자들에게도 비개발직군 역량은 필요하다!

 

나는 SW개발프로젝트의 PM 업무를 하고 있다. 개발팀을 포함한 기획/영업/UX 등의 유관부서들과 협업을 통해 개발 요구사항들을 정리하여 목표하는 일정까지 서비스 론칭을 하는 것이 나의 역할이다. 따라서, 하루에도 수차례 회의를 주관하고, 회의에 참석하고, 회의록을 쓰고, 이메일을 작성하는 것이 일상이다.

그런데, 요즘 회의에 들어가면 이상하리 만큼 저연차 개발자들이 회의록을 작성하는 모습을 보지 못한다. 고연차들이 회의를 주관하고 회의를 주관한 사람이 회의록까지 작성하는 것이 당연하다고 생각할 수도 있겠지만, 내가 신입일 때는 고연차가 회의를 주관하고 회의에서 유관부서와 협의/논의를 하면, 항상 저연차가 옆에서 회의록을 작성하는 분위기였다. 가벼운 회의라면 모를까, 순간순간 많은 생각을 해야 되고 신중히 협의해야 하는 회의자리라면 회의를 주관하는 동시에 실시간으로 회의록까지 작성하기는 버거울 수 있기 때문에 팀 내 다른 사람에게 회의록을 작성 업무를 부탁하는 모습이 이상하지도 않다. 문득, "요즘 저연차 개발직군들은 코딩 이외 업무를 하지 않으려는 건 아닐까?"라는 생각이 들었다.

요즘 신입 개발자들은 여러 SW개발 도메인 중에서도 본인의 커리어에 도움이 된다고 생각되는 특정 도메인만을 하려는 경향이 뚜렷하다. 일례로, 엠베디드나 플랫폼 개발보다는 나중에 이직이 용이한 벡엔드 서버개발을 더 선호하여 모든 신입 개발자들이 서버개발부서에 배정해 달라고 아우성이라 서버개발부서는 항상 인력이 넘쳐나는 반면, 비서버개발부서는 인력난에 시달리는 악순환이 반복되는 걸 보면, 요즘 신입 개발자들이 회의록을 쓴다거나 발표자료 작성 등의 "비개발" 업무는 철저히 자신의 업무 scope에서 배제시키겠구나라고 어느 정도 예상이 되기도 하다.

  

이런 "비개발직군 업무를 배척"하는 신입 개발자들을 향해 "잘못된 태도"라는 식의 날 선 발언을 하고 싶지는 않다. 왜냐면, 정말 치열하게 준비해서 취업한 이후에도 불확실한 미래에 불안해하는 요즘 20대들의 마음을 30대 후반인 나로서는 매우 공감이 되기 때문이다. 오히려, 본인의 커리어를 신경 쓰며 열심히 자기 계발을 하는 것은 칭찬받아 마땅하다고 생각한다. 다만, 우리가 흔히 생각하는 "비개발직군 업무역량은 개발자 커리어에 도움이 되지 않는다"라는 믿음은 현실과는 다른, 잘못된 생각이라는 것은 알려주고 싶다.

비개발직군 업무역량은 개발 커리어에 필수이다  

---

먼저, 비개발직군 업무역량이란 무엇인지 세분화해서 보자. 회사에서 쓰이는 비개발직군 역량은 크게 1) 글쓰기 역량과 2) 프레젠테이션 역량, 2개로 나눌 수 있다.

글쓰기 역량

개발문서 작성

개발프로젝트의 업무 중 개발문서 작성은 많은 개발자들이 기피하는 업무지만 꼭 필요한 업무이다. 요즘 개발을 Agile, DevOps, Sprint 방식으로 해서 문서 작성이 필요 없다고 말하는 잘못 배운 개발자들이 종종 있기도 하다. 하지만 개발문서작성을 하지 않는다면, 추후 신규인력이 개발된 소스 코드를 이해하는데 많은 시간과 노력을 들여야 하는 비효율이 발생한다. 또한, 서비스 개발 후 유지보수 팀에게 서비스 운영을 넘기는 경우 인수인계를 위해서라도 개발문서 작성은 필수이다.  (참고로, Agile방식의 하나인 Sprint는 1주/2주 등 상대적으로 짧은 텀을 두고 개발을 빠르게 진행하는 방식이며, DevOps는 주단위로 사용자의 피드백을 서비스를 수정/개선/배포하는 운영 방식의 일환이지, 개발문서 작성 필요여부와는 전혀 상관이 없다.)

개발문서 또한 문서이기에 개발용어를 쓸 뿐이지 명백한 글쓰기 작업이다. 하여, 논리적으로 잘 쓰인 문서는 읽는 신규인력이나 인수인계받는 인력 입장에서 이해하기 쉽고 향후 기존 개발 코드를 수정할 경우, 특히나 신경 써야 되는 부분이 어디인지를 명확하게 알 수 있다. 하지만, 문서상 글 자체가 이해가 어려운 경우 "문서에서 뭐라는지 하나도 모르겠고 코드부터 보자"라는 상황이 벌어지곤 한다.

이메일 작성

개발문서 작성 이외 개발자의 글쓰기 역량이 필요한 업무로는 이메일 작성이 있다. 이메일 작성은 개발자 여부를 막론하고 회사에서 글쓰기 역량이 제일 필요되는 업무이다. 당연하게도 유관부서와의 모든 소통은 전화나 대면으로 할 수가 없다. 상대방이 시간대가 다른 나라에 있거나, 다른 업무로 인해 당일에 업무 관련 소통을 할 수 없는 경우가 태반이기 때문이다. 이때, 잘 작성된 이메일은 때로는 대화로 소통하는 것보다 효율적으로 유관부서와의 의견을 주고받을 수 있다.

일반적으로 개발자들은 이메일 작성에 있어 미숙한 경우가 많다. 이메일에 상대방이 원하는 내용을 담아낼 수 있어야 하는데 개발자들의 이메일에서는 그렇지 못한 경우를 종종 본다. 일례로, 내가 PM으로써 일정을 챙기는 사람이기에 개발자에게 "~~ 님, A기능 관련하여 지난번에 발생한 디펙 언제까지 수정 가능하나요?"라는 질문을 많이 하곤 한다. 이때 내가 개발자로부터 원하는 정보는 "예상 해결 일자"이다. 하지만, 많은 경우 개발자들은 이렇게 이메일에 대답한다.

"해당 디펙 재현하여 로그 분석 결과, 옆 A파트에서 수정해야 주는 것이라 관련하여 A파트에게 수정 요청 하였습니다."

해당 대답은 상대방이 물어본 "일정"에 관한 정보가 없기에, 다시 한번 "그래서 A파트는 언제까지 수정이 된다고 하던가요?"라고 다시 이메일을 보낼 수밖에 없게 된다. 같은 시간대의 개발자와 협업을 한다면 큰 문제가 되지 않으나 혹여 시간차가 많이 나는 미국/유럽에 있는 개발자와 이메일을 통해 협업하는 경우, 이런 식의 대화는 프로젝트 일정을 수일 지연시키는 결과를 초래한다. 반면, 아래와 같은 답변은 상대방이 원하는 정보뿐만 아니라 상대방의 입장에서 앞으로 예상되는 내용까지 전달하여 수차례 이메일을 쓰는 수고를 덜어준다.

"해당 디펙 재현하여 로그 분석 결과, 옆 A파트에서 수정해야 주는 것이라 관련하여 A파트에게 수정 요청 하였습니다. A파트에서 차주 금요일(11/22)까지 수정완료한다고 하고, 시간이 더 필요한 경우 차주 초에 노티 준다고 합니다. A파트 패치 11/22에 받으면 내부 테스트 후 차차주 화요일(11/26)에 서비스 배포 가능 할 것으로 예상됩니다."

개발지식이 있는 개발자나 개발 PM 간 이메일을 주고받기도 하지만, 개발지식이 상대적으로 적은 유관부서와 이메일을 통해 소통하는 경우도 있다. 이메일을 쓸 때는 상대방을 배려하여 이해하기 쉽도록 쓰는 것이 중요하다. 따라서, 비개발부서인 기획/디자인/영업 부서에게 이메일을 쓸 때는 개발용어를 최대한 줄이고 개발비전공자들도 이해할 수 있게 적는 자세가 필요하다. "아니 요즘 시대에 이 정도의 개발지식도 없이 서비스 기획/디자인 업무를 한다고?"라는 식의 생각은 절대 금물이다. 아무리 이메일이라도 자신의 감정이 글에서 나타나는 법. 개발자가 자신을 무시한다는 것을 이메일을 받는 유관부서가 모를 일이 없고, 이는 불협화음으로 인해 성공적인 서비스 론칭과는 거리가 멀어질 뿐만 아니라, 개발자 본인의 평판에도 좋지 않다.    

---

프레젠테이션 역량 

ppt 보고자료 작성

"PPT 작성하는 건 기획부서가 개발자들 의견 취합해서 적는 거 아닌가요?" 기획부서가 기획한 서비스를 개발한다면 그럴 수 있다. 하지만, 기획부서가 기획한 서비스라고 한들 보고자료 중 개발 관련은 통상적으로 개발팀이 작성을 할 수밖에 없다. 또한, 개발팀 내부적으로 기획해서 론칭되는 서비스도 있고 개발인프라 개선 관련 프로젝트는 별도의 기획이 필요 없는 경우도 종종 있다. 이럴 경우, 해당 개발프로젝트를 추진하려 하는 파트 담당자는 개발팀장에게 재가를 받아야 하는데, 이를 위해서는 상사에게 "해당 프로젝트의 필요성과 당위성"을 어필해야 한다.

만약 개발팀장을 설득하지 못한다면 어떻게 되냐고? 열심히 자신의 파트원들이 날밤새가며 만든 PoC (aka 프로토타입)은 물거품이 되는 것이다. 수익을 내야 되는 사기업에서 자신의 개발프로젝트의 수익성을 PPT 보고자료에서 증명하지 못한다면 개발자로서 자신만의 프로젝트를 개발하는 기회는 앞으로 얻기 힘들 것이다. 이토록 개발자에게 설득력 있는 PPT를 작성하는 것은 실제 개발을 얼마나 잘하느냐 보다도 더 중요한 일이라는 것을 명심하길 바란다.   

발표

정작 보고자료는 잘 작성했는데 개발팀장 앞에서 긴장해서 발표를 잘하지 못하는 개발팀 부장님들을 수없이 봐왔다. 없는 시간 쪼개가며 설명 들으러 온 임원들은 잔뜩 짜증 내며, "지금 도대체 무슨 얘기를 하려는 건지 도통 알 수가 없네요. 다른 분이 대신 설명 가능하실까요?" 라며 발표자를 바꿔달라는 요청까지 하는 경우도 있다. 당시 발표자의 당혹감 서린 표정을 나는 아직도 잊을 수가 없다.

회사에서는 선행개발을 통해 신기술을 확보하는 방법 중 하나로 대학연구팀과 협업하는 산학과제라는 제도가 있다. 6개월에서 1년 간의 연구를 통해 얻은 결과물을 연말에 임원에게 보고 하고 평가를 받는데, 이때 발표는 해당 대학연구팀의 담당 교수가 맡는다. 해서, 여러 번의 산학과제 진행 경험이 있던 회사선배가 나한테 이런 조언을 해준 적이 있다. "결과물 잘 뽑아내는 교수보다 마지막 발표 때 말 잘하는 교수를 선정하는 게 좋아".

회사 내에서 본인이 하고자 하는 업무를 추진하려면 설득력 있는 보고자료와 발표를 통해 당위성을 입증해야 하며, 이는 개발자도 마찬가지다.  

---

앞으로  AI로 인해 많은 개발 업무들이 자동화될 것으로 예측되고 있다. IT업계에 종사하는 나 또한 이런 변화 속에서 AI나 데이터사이언스 관련 지식을 틈틈이 쌓으면 뒤처지지 않으려고 노력 중이다. 하지만, 동시에 AI가 대체하지 못하는 분야의 능력을 키워야 되지 않을까라는 생각도 동시에 갖는다. 사람을 설득하고 호감을 쌓는 커뮤니케이션 능력이야 말로 AI가 대체하지 못하는 영역이라 생각한다. 그리고 그런 커뮤니케이션 능력이 기획/영업 부서가 하는 업무의 대부분이기도 하다. 따라서, 더 좋은 개발자가 되기 위해, 그리고 유관부서 사람들이 같이 일하고 싶어 하는 동료가 되기 위해 비개발직군 업무능력을 한껏 증진시키길 바란다.

---

Chapter. 뉴비들을 위한 업무 팁

[뉴비들을 위한 업무 팁 #1]  고과 잘 받기 전략 : https://brunch.co.kr/@d722bd92c9cc4e3/8

[뉴비들을 위한 업무 팁 #2] 회의록 쓰는 법 : https://brunch.co.kr/@d722bd92c9cc4e3/5

[뉴비들을 위한 업무 팁 #3] 개발자에게 문과역량이란 : https://brunch.co.kr/@d722bd92c9cc4e3/7