프롤로그 : 서문

기획자를 위한 개발자 이해 튜토리얼

책 제목처럼 이 책은 기획자들이 많이 협업하는 개발자들에 대한 이해를 높이고자 썼다. 필자는 컴퓨터공학과를 졸업하고 서버 개발자로 커리어를 시작해  8년간 프론트엔드, 백엔드 등 여러 분야에서 개발자로 일했다. 이후 사업/기획 업무로 직무를 변경해 5년동안 일했다. 바뀐 기획직군에서 바라본 개발자들은 기획자 동료들에게는 미지의 세계였고, 이해할 수 없는것 들로 가득차있었다. 프로그래머로 일했던 경력 덕분에 나는 개발자의 행동양식과 그들의 입장을 이해했고 주변 동료들에게 그들의 입장을 이해하며 프로젝트를 이끌어갈 수 있는 방법에 대해 많이 이야기했다. 나는 이 책에서 동료들에게 도움이 된 개발자들과의 다양한 갈등상황에서 그들이 생각하는 사고방식에 대해 기획자의 시선으로 풀어 적었다. 그들을 이해하고 나면 앞으로의 업무에 이해하지 못해 발생하는 스트레스를 상당수 줄일 수 있을 것이다.

개발자를 포함해 협업부서와 갈등이 생기는 주요한 이유중 하나는 서로에대한 이해가 부족한 것이다. 각 부서의 입장이 다른일이 태반이고 구성원들의 출신에 따른 사고방식도 다르기 마련이다. 특히나 문과출신이 많은 사업/기획부서와 대부분이 컴퓨터공학을 전공했을것으로 예상되는 개발팀은 생각하는 방식과 입장이 많이 다르다. 이는 금융권 회사나 IT기술을 원천기술로하는 테크회사나 별반 다르지 않았다.

기획자로 일할때 사업팀과 개발팀 사이에 갈등이 생긴 사례이다. 외부 협력사에서 특정 기능을 제공하는데 기존 업체를 타 업체로 변경가능한지 알아보기 위해 공개된 API로 우리가 원하는 기능이 구현 가능한지 알아보는 일이었다. 내가 살펴보기 시작한 시점은 이미 갈등이 발생한 뒤였고 파악한 내용은 이랬다.

기술적인 내용을 모르는 사업팀은 그저 업체를 교체하는것이 가능한지 알아보고 결과를 알려달라는 요청을 했다. 요청을 받은 개발팀은 API 스펙을 보니 기존 업체와 요청방식이 판이하게 달라 의사결정을 하지 못하고, 우선 기존 스펙에 얼추 비슷하게 샘플로 테스트 가능한 페이지를 제공했다. 일단 여기까지 해봤으니 사업팀에서 코드로 작성가능한 수준으로 상세 스펙을 정해달라는 뜻이었다. 이걸 받은 사업팀은 API문서를 읽을 줄 모르니 뭘 더 해달라는건지 전혀 이해하지 못했고, 상세스펙을 제공하기보다는 얼른 가능여부를 달라고 재촉했다. 원하는 답변을 받지못한 개발팀은 여기까지했는데 내가 뭘 더 해줘야하냐며 불만을 토로했다. 이 시점에 사업팀은 개발팀이 일 하기 싫어한다고 느끼며 서로 감정이 상하는 상황이었다.

문제를 파악하고 해결을 위해 API문서 스펙을 검토하니 정말 많은 선택지가 있어서 우리가 원하는 내용과 매칭되도록 몇 가지를 초안으로 선택했다. 그리고 개발팀에서 준 샘플에 들어간 선택지를 비교했다. 내 선택과 다른 것들을 고른 이유에 대해 물었고 여러 실험을 한 결과에 따른걸 확인했다. 개발팀에서 정하지 못한 몇가지 요소들을 검토하고 최종 상세를 정해 개발팀에 다시 요청하니 일은 간단하게 해결됐다.

위 사례에서 내 판단으로 개발팀은 이해 못하는 사업팀을 이해시키기 위해 상당한 노력을 들인것으로 보였다. 그렇지만 사업팀이 이해할 수 있는 수준에 도달하지 못했고 갈등이 발생하는 단초가 되었다. 이 때 기획자가 개발자들의 이야기를 받아들이기 위해 마중나가듯 대화했다면 상황은 이렇게 발전되지는 않았을것이라 생각든다.

신입 개발자를 갓 벗어나 내 책임의 프로젝트를 맡아 서비스 오픈을 앞두고 있었을때 일이다. 뉴스에도 나오는 ‘크런치 모드’라는 단어가 있는 게임업계인 만큼 매우 바쁜 일정을 소화하고 있었고 많은 일이 개발자인 나에게 몰리는 상황이었다. 여러 부서가 요청하고 한정된 시간에 모두 수용할 수 없는 상황에 심지어 새치기하는 부서도 있었다. 그때 모든 부서가 모인 회의에서 새로운 기능을 추가해달라는 요청을 해왔다. 가능한 일정을 물어왔을 때 나는 답변을 하기 곤란했다.

일정은 이미 포화상태라서 새 일정을 넣을 틈이 없을 뿐만 아니라 만약 나에게 초능력이 있어 시간을 창조해낸다고 해도 지난 일주일을 돌이켜보면 회의 참석자중 반은 나에게 또 다른 요청을 할 것이 뻔히 예상됐다. 내가 말한 일정을 지킬 수 없는게 예상됐고 그래서 지킬수 없는 일정을 이야기하는게 의미가 없을뿐더러 거짓말이라는 생각이 들었기 때문이다. 프로젝트가 잘되길 바라는 마음으로 야근불사하며 최선을 다했는데 일정도 말 못한다는 협업부서의 비판에 억울한 마음이 들었다.

이 상황을 파악한 개발팀 리더는 모든 요청을 개발자에게 직접 하지 못하도록 통제하고 리더에게 오도록 수정했다. 또한 요청하기 전에 그들끼리의 우선순위를 먼저 정해서 오도록 교통정리를 진행했다. 이런 조치 이후 개발에 집중할 수 있었고 모든 요청을 수용한 것은 아니지만 안정적으로 QA를 통과하고 서비스를 오픈할 수 있었다.

위 사례에서 개발자를 최대한 활용하려면 부하를 분산해 줄 필요가 있었다. 수많은 회의와 요청들을 듣는데 사용되는 시간을 줄이고 우선순위도 미리 정해서 온전히 개발에만 집중하도록 환경을 조성하는것은 집중하는데 큰 도움이 된다. 개발팀 안에서 이를 해결해서 다행이지만, 이런 역량이 안 되는 경우 PM이나 PO역할을 하는 부서, 보통은 기획자가 이 부분을 미리 해결해주는것이 필요하다.

개발팀을 이해하는것은 갈등을 예방하는것을 포함해 프로젝트 전체 진행에 큰 도움이 된다. 이를 위해 기술적 역량을 키우는것은 큰 도움이 된다. 이와 더불어 서로에 대한 이해를 높이는 것은 기획자로 업무하는데 큰 도움이 될 것이라 확신한다. 이 책에서 현업에서 발생한 여러 문제상황에 대해 각 부서의 입장을 상세히 풀어서 설명하고 이를 이해하기 위한 기술적인 내용도 이해하기 쉽게 설명했다. 이 책을 읽는 독자는 서비스 기획자로 막 발을 들이거나 들이고 싶어할 것으로 생각된다. 이 경험들이 스트레스를 줄이고 협업하는데 도움이 되길 바란다.