효율적인 원격지 개발조직 관리를 위해 필요한 7가지 준비사항

0
1056

공공기관에서 사이트, 인프라 관리 업무를 담당한지도 3년 째이다. 최초 온라인 교육 플랫폼 구축할 때부터 지금 개발 유지보수 할 때까지 상주 개발을 강제하지 않고 있다. 중요 개발과 유지보수는 모두 원격지 개발을 하고 있다. 대부분의 공공기관에서는 상주가 당연한 것이고, 상주하는 개발조직이 꾸려지지 않으면 프로젝트가 큰 일 날 것처럼 생각하는 경우가 많은 문화 속에서 원격지 개발조직을 관리하는 것은 모험에 가까운 일이었다고 볼 수 있다. 결과적으로는 성공적이라고 자평하고 있으며, 앞으로도 적극적으로 원격지 개발조직을 유지할 예정이다. 대단하진 않지만 원격지 개발조직을 유지할 수 있는 이유를 간단히 공유해 본다.

1. 방향을 명확하게 설정한다.

조직이 원하는 시스템의 방향을 명확하게 설정하는 것이 중요하다. 가야할 길을 명확하게 알면 그 다음부터는 쉬운 일이다. ‘우리가 가야할 곳은 어디이며, 그곳에는 무엇이 기다리고 있을지’ 그림을 그리고 그것을 제대로 설정하는 것이다. 흔히 갑은 개발조직인 을에게 이런 것을 요구한다. “우리 시스템이 해야할 일이 무엇인지 나도 모르니, 을인 너희들이 분석해서 나를 설득해줘”라고. 이런 상황으로 시작하면 상주를 해도 망한다. 관리하는 자가 방향을 모르는데, 다른 누군가가 나를 위해 방향을 잡아줘야 하는 상황을 만드는 이상 프로젝트는 성공하기 어렵다고 보면 될 것이다.

2. 개발조직이 무엇을 할 것인지 구체적으로 작성한다.

방향이 정해지면 그 다음에는 요구사항명세서를 직접 만들어야 한다. 흔히 개발조직이 결정되면, 분석이라는 명목하에 짧게는 1개월 길게는 몇 개월씩 요구사항을 분석한다. 이해관계자들과 미팅을 하면서 그들이 원하는 내용을 모두 들어보고 그것을 정리하여 요구사항을 확정한다. 이것이 진짜 요구사항인지 확인하는데에만 상당한 시간이 소요된다. 이 과정을 발주자가 직접 하게 되면 분석 기간이 상당 부분 단축된다. 원하는 것을 발주조직이 직접 작성하는 것이 좋다. 그것도 아주 구체적으로 작성하는 것이 좋다. 기능단위로 필요한 사항을 구체적으로 나열만 하는 것으로도 충분하다. 개발조직과는 직접 작성한 요구사항을 어떻게 구현할 것인지를 중심으로 협의하기 때문에 빠르고 정확하게 일이 진행된다.

3. 투입 인력에 관여하지 않는다.

흔히 맨먼쓰(Man-Month)라고 부르는 산출근거로 개발비를 산정한다. 그렇기 때문에 몇 명의 기획자와 개발자가 투입되는지를 따지기 마련이다. 사람 머릿수를 세는 것이다. 이러한 방법이 표면적으로는 아주 편리할 수는 있지만, 경험상 개발 프로젝트에는 그다지 유용하지 못하다는 판단이다. 특급의 능력을 가진 개발자 1명이 일상적인 개발자 3~4명 역할을 할 수 있다는 것을 인정하고, 투입 인력 명수를 관여하지 않아야 한다. 몇 명이 투입되었는지 세기 보다는 산출물 중심으로 판단하는 것이 필요하다. 단, 개발조직이 믿을만 해야 한다. 믿음을 주어야 하고, 실제 믿을 수 있도록 일을 해야한다는 전제가 필요하다. 먹튀 개발조직도 많기 때문에 믿을 수 있는 곳과 일할 수 있다면 인력에 신경을 쓰지 않을 수 있다.

4. 오직 성과로만 판단한다.

성과로 판단하는 기준이 필요하다. ‘사람이 많이 들어 왔으니 일이 잘 되고 있군’이라고 판단하기 보다는 ‘산출물이 잘 나오고 있으니 일이 잘 되고 있군’이라고 생각해야 한다. 오직 산출물로, 오직 성과로만 프로젝트를 관리할 수 있어야 일 중심으로 돌아간다. 누가 언제 얼마나 일하고 있는지 관여하기 보다는 PM과의 의사소통을 통해 얼마나 일이 진척되고 있는지, 문제는 무엇인지를 소통하는 것으로 일이 돌아가야 한다. 프로젝트를 하는 이유는 일이 잘 되자고 하는 것이지, 인력을 관리하자고 하는 것이 아님을 기억할 필요가 있다.

5. 서로에게 이익이 되는 방법을 고민한다.

개발조직이 우리의 개발 프로젝트를 대신해 주는 이유는 무엇일까? 이익 때문이다. 매출을 올리고, 비용을 쓴 후 이익을 남겨 재투자를 하면서 개발조직이 꾸준하게 유지되길 원해 프로젝트를 대행하는 것이다. 우리는 프로젝트를 통해 얻으려는 이익이 무엇인가. 프로젝트의 성공을 통해 원하는 기능의 개발물을 얻기 위함이다. 상호 간의 이익을 중심으로 움직일 수 있는 환경을 조성하면 시너지가 발생할 수 있다. 발주기관에서는 개발조직이 ‘많이 남길 수 있는 방안’을 먼저 제시할 필요도 있다. 멋진 접근방법으로 투입량이 획기적으로 줄면서도 원하는 산출물을 얻게 되었다면, ‘시간과 인력이 남을 것 같으니 다른 것을 더 만들어서 뽑아 먹을까?’라고 생각하지 말고, 더 얻기를 그만두자. 개발조직도 많이 남겨야 우리의 프로젝트에 애정이 생길 것이고, 앞으로의 협력관계도 원활해 질 것이다. 개발조직이 많이 남기는 것을 아까워하지 말고, 투입한 예산대비 얻을 수 있는 기능만 얻도록 욕심을 버리자.

6. 끊임없이 공부한다.

개발조직과 말이 통해야 효율적으로 함께 일할 수 있다. 요구할 때에도 현실가능성을 염두에 두면서 제시하는 것과 허무맹랑한 요구를 하는 것에는 프로젝트 추진에 많은 차이가 있다. 의사소통 상의 비효율을 줄이고, 개발조직의 산출물을 제대로 관리하기 위해서는 스스로 공부하면서 역량을 향상시켜야 한다. 나 조금 편하자고 다른 사람 불편하게 하지 말고 공부하면서 서로 편할 수 있는 방법을 찾자. 그러한 노력이 쌓이고 쌓이면 언젠가는 멋진 평판과 성과로 보상받을 수 있을 것이다.

7. 도구를 사용한다.

원격지 개발을 위해 소통하기 위한 커뮤니케티션 도구를 사용한다. 업무소통을 위한 다양한 도구가 있으니 이러한 것들 중 적합한 도구를 선택하여 적극적으로 활용한다. 원격지에서 개발소스의 버전을 관리하고, 서버로 배포하기 위한 시스템을 준비해 놓아야 한다. 현재 내가 사용하는 버전관리 도구는 Git이고, 저장소는 Gitlab을, 배포관리 도구는 Gitlab 속에 있는 기능(Deployment)이다. 이렇게 준비한 후 이것들을 활용할 수 있도록 안내하고 관리한다. 처음에 익숙해지기 어려워서 그렇지 제대로 사용하면 유지보수에 유용하다.