개발자와 협업 잘하는 법? 개발자를 이해하는 것 부터!
[일하는 책읽기] 육각형 개발자 - 최범균
개발자는 우리와 다른 종족이 아닐까?
올해 프로덕트 매니저 직무로 전환하면서, 처음으로 풀스택이 갖춰진 조직에서 개발자와 밀접하게 협업을 해보았다. 처음 협업하면서 개발과 개발자에 대한 무지에서 비롯한 어려움이 무척 컸다.
클라이언트? 서버? json? 막연하게 들어보기만 하고 '대충 이런 것이겠거니' 라고 생각했던 개발용어들을 보다 명료한 개념으로 알고 있어야 했다. '개발자는 그냥 다 똑같은 개발자 아닌가?' 하는 생각으로 백엔드 개발자에게 요청해야하는 것을 앱 개발자에게 물어보는 경우 (또는 그 반대의 경우)도 부지기수였다. 지금 생각하면 그때의 내가 얼마나 무지했는지 부끄러워진다.
이렇게 이론적 지식의 한계에서 오는 것은 금방 극복했지만, '협업' 을 잘 하는 데에는 개발자에 대한 다양한 각도의 이해가 필요했다. 평소 일하면서 문제상황에 대한 액션 아이템을 직접 세우는 것에 익숙했는데, 개발자와 협업을 잘 하기 위해서는 액션 아이템을 내가 생각해내는 것이 아니라, 문제 상황을 잘 정의하고, 원하는 기대효과를 어떻게 구조화해서 잘 설명하느냐가 중요했다. 해결할 수 있는 방법의 다양성은 개발자가 더 잘 알고있기 때문이다.
또한 가장 어려운 프로젝트였던 소셜 로그인을 도입하는 프로젝트를 통해, '내가 왜 이 경우의 수를 미리 생각하지 못했지?' 하며 스스로 자책했었는데, 그렇기 때문에 개발자와의 싱크가 무엇보다 중요함을 배웠다.
그래, 개발자도 우리 종족이었어!
개발자와의 협업에 대한 감이 어느정도 잡히고 나서, <육각형 개발자> 라는 책을 읽을 기회가 생겼다. <육각형 개발자> 는 주니어 개발자가 시니어로 성장하기까지 필요한 요소들을 실무와 조직 관점에서 6가지 구성요소로 정리한 책이다. 리팩토링, 아키텍쳐 파트와 같이 구체적인 기술구현 내용을 온전히 이해하긴 어려웠지만, '좋은 개발자' 가 갖춰야 하는 요소를 하나씩 짚어보며, 다른 종족이라 여겼던 '개발자' 를 좀더 깊이있게 이해할 수 있게 되었다.
코딩 구현 기술은 개발의 일부이지
개발의 전부는 아니다
<육각형 개발자> 22p
개발자와 4개월 정도 협업을 해보면서 다시 개발자에 대해 다시 생각하게 된건, '개발자도 결국은 커리어를 개발해나가는 관점에서는 다른 직무와 같다' 는 것이었다. 내가 수많은 웨비나를 듣고 솔루션사의 자료를 읽어가며며 디지털 마케팅을 익힌 것처럼, 개발자들도 직접 코딩을 하는 시간보다는 API 문서를 읽고, 구글링하며 지식을 습득하는 시간이 많았다. 뿐만 아니라, 개발자가 업무를 관리하고 공유하는 방식에 따라 서비스 개발의 속도와 방향성이 빠르게 바뀔 수 있음을 느꼈다.
좋은 개발자는 말하기와 글쓰기를 잘한다
개발자일수록 말하기와 글쓰기 능력이 생각보다 더 중요하다. <육각형 개발자> 에서도, 조직에서 살아남기 위해서는 개발자도 글과 말을 잘 활용해야함을 강조한다.
글쓰기가어렵다면, 일단 글을 읽는 노력을 한다.
주제와 내용 흐름부터 잡는다.
정확하게 전달하려고 노력한다.
문장을 짧게 쓴다.
그림과 시각적 효과를 활용한다.
글쓰기와 말하기는 직무와 상관없이 중요한 소프트 스킬이지만, 개발자는 특히나 쉽게 풀어쓰는 능력 이 중요하다고 생각한다. 기획에서 개발단계로 넘어가는 과정에서 개발자가 어려운 용어와 기술구현에 대한 내용을 쉽게 풀어서 글과 말로 공유해줄수록, 기획에서 생각치 못한 부분과 개발구현에 대한 이해도가 빠르게 올라갔다. 또한 함께 일했던 개발자들 모두가 화이트보드에 그림을 그려서 설명해주는 방법을 많이 썼는데, 책을 읽으며 시각화만큼 효과적인 설명 방법이 없다는 데에 격하게 공감했다.
<육각형 개발자> 에서 소개한 동시성 문제에 대한 시각화 예시. 개발자가 화이트보드를 자주 사용할수록 협업이 잘 풀리는 이유를 잘 설명해준다.일잘러 개발자의 업무관리법
<육각형 개발자> 에서는 개발자의 업무관리 실패 사례와 효과적인 업무관리 방법 또한 제시한다. 프로젝트 매니징을 하는 입장에서도 개발자가 이렇게 일해주면 더할 나위 없겠다는 생각이 드는 내용이었다.
일의 규모를 파악한다. 아무리 큰 프로젝트라도 나누고 쪼개면 작은 단위의 업무가 되고, 작은 단위의 업무가 되어야 일정/리소스를 파악할 수 있다.
개발에서의 '완료' 의 의미는 개발 구현 + [스스로 검증] 까지를 의미한다.
요구사항은 바뀐다. 일정과 비용을 처음부터 언급하지는 말자. 왜 그런 요구를 하게 되었는가? 를 파악하는 것이 우선이다.
점진적이고 반복적으로 개발해야한다. 작업을 분할해서 빠르게 가치를 제공하고, 점진적으로 개선해나간다.
안된다고 말할 수 있어야 하지만, 대안과 함께 가능한 방안을 고민한다. 늘 안된다고만 하는 개발자는 되지말자.
이유와 목적을 생각하자. 업무지시를 받으면 어떤 이유 / 목적으로 그 일을 줬는지 알아내야 한다.
책의 저자가 남긴 노트 중에서 '일 잘하는 방법도 공부하기' 라는 내용이 있었다. [개발 역시 일이기에, 개발을 잘하려면 다른 역량도 키워야 한다] 는 것이다. 페이지를 넘기며, 저자가 주니어 개발자에서부터 육각형의 역량 그래프를 고르게 넓히기 위해 스스로 얼마나 많이 회고했는지 느껴지는 대목이 많았다.
좋은 개발자가 되기 위한 여섯가지 역량. 개발자 뿐만 아니라, 육각형 기획자, 육각형 마케터 등 모든 직무에 적용할수 있는 개념이라고 생각했다.
책을 읽으며, 역시 일잘러 선배로부터 듣는 일하기 방법론만큼 주니어들에게 소중한 건 없다는 생각이 들었다. 주니어 개발자에게는 막막한 개발과 조직생활에 대한 고민을 해결해줄 수 있고, 비개발자에게도 개발자를 다각도로 이해하고, 나와 협업하는 개발자가 어떤 어려움을 겪고 있는지 함께 고민하기 좋은 책으로 추천한다.
