급격하게 발전한 한국 IT 산업의 특성상, 우리는 어떠한 프로세스를 설정하는 것 대신에 능력있는 몇몇의 사람의 맨파워에 의존하는 경향이 있다. 명확한 프로세스를 설정하고 실행하는 것보다 그때마다 사람의 능력과 경험에 의존할 경우, 특정 사람이 과도하게 많은 일을 수행하게 되고 번아웃으로 회사를 떠나는 경우를 흔하게 볼 수 있다. 또한 프로젝트마다 대처하거나 관리하는 방식이 명확하지 않은 것은 프로젝트의 생산성이나 진척도를 측정하기도 어려워 관리자 측면에서도 좋지 않다.
우리는 경력이 쌓일 수록 작업자의 능력이 발전하기를 기대한다. 그러나 우리는 시간이 지날 수록, 프로젝트를 거듭할 수록, 내부의 프로세스를 정립하고 발전시켜 왔는지 고민 할 필요가 있다.
내가 만나온 많은 고객들은 해외에 IT 개발센터를 구축하길 원했다. 그들이 원하는 것은 쉽게 말해 모든 고객이 그렇듯이 그들이 가진 모든 문제를 해결하는 것이 그들의 궁극적인 목표이다.
"합리적인 비용으로, 좋은 기술력으로, 뛰어난 품질, 인력난 해소 ...."
사실 해외에 개발센터(Overseas Development Center)를 구축할 때, 그 시작에서 가장 중요한 것은 바로 현재 회사의 내부 프로세스 점검이다.
내부 프로세스를 점검하고 어떠한 문제가 있는지, 우리가 가진 내부 프로세스의 장단점은 무엇인지 명확하게 알아야 그 후에 그에 맞는 해결책을 만날 수 있다.
어떤 방법론으로 프로젝트를 진행할것인가, 어떤 워킹모델을 사용할 것인가, 프로젝트 구성원은 어떻게 구성할 것인가는 내부 현황을 정확하게 파악한 이후에 이루어질 수 있는 것이다.
나는 이것을 국내의 프로젝트를 해외로 이전하고 싶어하는 관리자와 회사만의 문제로 한정하고 싶지 않다.
내부 프로젝트를 외부 프리렌서와 수행할 때도 동일하다. 우리는 외부와 일하기 위해서 혹은 새로운 해결책을 찾고 싶을때, 먼저 내부의 상황을 먼저 확인해야 한다.
자, 많은 고객들이 해외개발센터를 구축할 때, 실패할 가능성이 큰 한가지 유형의 요청을 소개하겠다.
"네, 저희가 프로젝트가 500% 확장할 예정이기 때문에, 해외 개발자를 4명 부탁드립니다. 저희 회사에 근무중인 국내개발자인 김과장이 A프로젝트를 하고 해외개발자가 B,C,D,E 4가지 프로젝트를 수행하게 하고 싶습니다."
고객의 요청 :
- 국내개발자 김과장 : A 프로젝트 수행중
- A 프로젝트와 유사한 프로젝트를 수행할 해외 개발자 4명 추가
단순히 이런 요청으로는 제대로 해외개발센터(ODC)를 구축하기 힘들다.
그 이유는 다음과 같다.
첫째. 프로젝트 산정이 정확한 것인지 확인해야한다. 즉, 500% 확장된다는 의미를 확인해볼 필요가 있다.
기존에 진행한 프로젝트는 어떤 프로젝트인가? 추가로 진행되는 프로젝트는 그와 비교하여 어떤 특징의 프로젝트인가? 이전 프로젝트와 앞으로 진행할 프로젝트가 유사한가 완전히 다른것인가, 환경은 어떠한가?
만일, 유사한 프로젝트이고 참고할 자료가 충분하다면 그것은 사실 500%가 아닌 100%~200% 일 수 있다.
반대로 환경구현이 더 복잡하고 로직이 단순하지 않다면 그것은 산정한 500%의 몇배가 넘는 공수(effort)가 필요할 수도 있는것이다. 정확한 프로젝트 산정(estimation)은 비용, 시간, 품질 모든 것을 좌우하기 때문에 계약에 앞서 신중해야한다.
둘째. 500% 확장 할 프로젝트에 4명의 개발자가 더 필요하다고 정의할 수 없다.
500% 확장할 프로젝트에서 몇명의 개발자가 필요하다고는 어떻게 산정할 수 있을까?
우선 해당 업무에 대한 분석이 필요하다. 그리고 어떤 업무를 해외에 이전할 것인가를 먼저 논의해야한다.
아무리 해외로 프로젝트를 이전한다고 할지라도, 결국 해당 프로젝트를 관리하는 주체는 개발센터를 의뢰한 국내회사이다. 해외개발센터(ODC)의 관리인력(PM, ODC Manager)과 해외개발센터와 연결을 도와주는 국내에 상주 매니저(Delivery Manager, Onsite PM)가 어느정도 컨설팅적인 요소를 제공하지만 결국 의뢰자가 단기간, 장기간의 목표를 가지고 어떠한 개발센터를 수립하고 싶은지, 그리고 그 씨앗이 되는 최초의 워킹모델은 어떻게 수립하고 그 안의 자원(Resource)은 어떻게 구성하고 싶은지에 대한 계획을 가지고 있어야한다.
셋째. 초기 구축단계에서 국내인력의 생산성과 동일한 기준으로 업무를 산정하는 것은 무리가 있다.
초반에 500% 확장할 프로젝트이기 때문에 4명의 개발자를 더 투입해서 기존의 김과장과 같은 동일한 생산성을 원한다면 어려울 수도 있음을 감안하는 것도 필요하다.
기존에 A회사에 김과장이 3년동안 IT 부서에 근무하며 필수적인 프로그램을 직접 설계, 개발, 테스트, 버그수정, 유지보수 업무까지 해왔다고 하자. 이에 해외 개발자 4명이 투입될 경우 김과장과 동일한 생산성으로 일할 수 있을까?
신규 인력 투입의 경우 초기 환경셋팅과 해당 프로그램을 숙지하고 이해하는 과정이 필요하다. 게다가 해당 기간에 업무 또한 동시에 수행해야 한다. 초반에는 당연히 김과장보다 해외팀 개발자가 생산성이 낮을 수 밖에 없다. 특히 해외 개발센터 특성상 설계문서와 시스템과 관련한 통번역의 시간 또한 소요된다.
이것은 프로젝트 시작에 앞서 초기 준비과정이 중요한 이유중에 하나이다. 프로젝트 초기 준비 과정이 얼마나 잘 이루어졌느냐에 따라서 이후의 생산성에서 많이 차이가 날 수 있다. 프로젝트 투입에 앞서 업무관련 프로그램과 상황들, 히스토리 확인, 환경셋팅이 먼저 진행된다면 해당 단계에서의 생산성 관련 문제를 크게 줄일 수 있다.
자, 그렇다면 앞서 말한 세가지를 고려하면 어떠한 방식으로 ODC를 구축할지 다시 생각해볼 수 있다.
A 회사의 김과장의 경우 현재 시스템에 대한 이해가 높고 모든 업무를 회사에서 처리할 수 있는 인력이다.
해당 인력에게 단순한 업무부터 복잡한 업무까지 모든 업무를 맡기는 것은 회사 입장에서는 합리적인 일 분배가 아니다.
이런 경우에는, 이미 품질을 보증할 수 있는 자원이 회사 내부에 있으므로, 프로젝트 초기에는 김과장에게 설계와 검수, 통합테스트를 맡기고 해외 개발센터에는 코딩, 단위테스트, 버그수정을 전담하게 하는 것을 추천한다. 그 후에 점차적으로 프로세스를 구축하고 발전해나가 안정이 된다면 더 많은 업무를 점차적으로 해외팀에 전달 할 수 있다.
김과장을 주축으로 설계, 검수, 통합테스트 업무를 맡길 예정이기 때문에 김과장이 한개의 프로젝트에서 설계 할때 몇명의 개발자가 코딩에 필요한지를 고려한다. 테스터가 필요하다면 테스터를 자원계획에 추가한다. 커뮤니케이션 플랜을 수립하여 통역이 필요하다면 통역도 자원계획에 추가한다. 이러한 방식으로 실제 필요한 자원을 점검하면서 계획을 수립할 수 있다.
일단, 코딩, 단위테스트, 버그수정이 안정화 되었다면 그 이후에는 이전에 국내회사에서 전달했던 설계서 형식과 동일하게 개발건이 있을때 마다 설계서 작성을 해외에 의뢰할 수 있다. 그렇게 된다면 그 이후에 국내업체는 설계서를 직접 작성하던 것에서 설계서를 검수하는 것으로 업무가 바뀌게 된다.
운영업무를 이전하는 것은 CICD 환경이나 근무시간(해외와 국내가 업무시간이 다르다.)도 고려하여야 한다. DevOps 개념으로 운영하기 위해서는 국내와 해외 작업자 간의 명확한 프로세스 구축이 필요하다. 사실 이것을 해외개발센터와 진행하고자 한다면, 특히나 내부 정책들이나 보안관련한 것들의 프로세스를 업데이트하거나 새로 만들어야 하기때문에 어느정도 기간을 가지고 점차적으로 해외로 이전하는 것이 더 적합하다.
