모름지기 회사에서 가장 중요한 사람은 회사의 임직원일 것이다.
하지만, 은근 알게 모르게 회사보다 프리랜서가 더 대우 받는 경우가 있다.
프로젝트를 수주하게 되어 새로운 프로그램을 처음부터 만든다고 하자.
그러면 프로젝트 시작 할 때에 프로젝트의 특성이나 개발 기간 등을 고려하여 인력 구성을 어떻게 할 것인지 생각 할 것이다.
이 때에 프로젝트가 얼마나 높은 완성도로 성공적으로 마무리 되는지는 이 프로젝트를 수행하는 팀의 업무 특성에 따라 크게 갈린다.
프로젝트 수주를 위해서 신규 인력을 채용하고, 새로운 팀을 구성하여 기존에 회사 업무와 격리된 환경에서 신규 프로젝트에 전념할 수 있는 것이 가장 좋다.
그러나 회사에서 운영 중인 프로그램을 유지보수를 주력으로 하는 팀이 새로운 프로젝트 까지 맡게 되면 일이 대단히 복잡해진다.
단순히 유지보수도 해야 하고 신규 개발도 해야 하기 때문에 일거리가 많아진다는 문제가 아니다. 핵심은 인원충원을 어떻게 하느냐다.
첫 번째 경우의 수는 팀 내 인원의 경력 분포를 고려하여 신규 인원을 채용하거나, 기존 회사 업무에 영향을 받지 않는 타 부서 인원의 지원을 받는 것이다. 이렇게 할 경우에는 팀이 가지고 있던 기존의 기술력이나 노하우를 신규 프로젝트에 녹여낼 수 있기 때문에 가장 좋은 경우의 수다.
두 번째 경우의 수는 프리랜서를 쓰는 것이다. 사업 기간이 1년 미만인 프로젝트라 하면 프리랜서를 고용하는 것은 큰 도움이 된다. 하지만, 프리랜서를 쓰는 것은 큰 위험부담을 가진다.
사업 기간 내에 프리랜서가 여러번 교체된다면 프로젝트 일정에 큰 타격을 주는 것은 말 할 것도 없다. 그리고, 간과하기 쉬운 프리랜서의 가장 큰 취약점은 프로젝트가 마무리 될 때 쯤에 드러난다.
지금 당장은 신규 사업을 수행하는 데에 집중을 하고 있지만, 언젠간 이 사업이 종료되고 유지 보수 할 것도 생각 해야 한다. 그런데 프리랜서가 사업을 마치고 회사를 떠나게 되면 프리랜서가 개발 담당한 부분은 회사의 그 누구도 알 수 없는 영역이 된다. 게다가 유지보수 경험이 적고 신규 개발 위주의 업무만 수행한 프리랜서가 유지보수가 수월하도록 코드를 작성했을 지도 미지수다.
게다가 프로젝트가 종료 단계에 가까워지면 사업 종료감리에 대처해야 한다.
특히 공공기관의 사업을 수행하다 보면 평상시에는 절대 열어 볼 일이 없는 온갖 ~~설계서, ~~정의서, ~~보고서 같은것을 감리가 집요하게 요구한다. 이 감리를 통과하지 못하면 프로젝트가 무기한 연장 될 수 있는 상황이므로 당연하게도 프로젝트의 모든 구성원은 감리를 위한 문서작성에 집중하게 된다. 단 프리랜서는 보통 문서작업에서 제외된다.
프로젝트를 시작하게 되면, 바로 IDE를 열어서 프로젝트를 만들지 않는다.
소프트웨어 개발은 일반적으로 요구사항 분석, 설계, 구현, 테스트, 이행, 유지보수 의 절차를 따르는데, 프리랜서는 정직원보다 단가가 높기 때문에 설계 단계까지는 기존 팀 구성원으로 해결하고 구현 단계부터 고용하여 개발에 투입된다. 그러다 보니 프리랜서는 사업 내용을 거의 모르는 채로 PM, PL이 지시하는 업무 위주로 수행한다. 그러다 보니 프리랜서는 사업내용을 잘 모르기 때문에 문서 작업에 투입시키기 어렵다. 만약에 은행 관련된 업무를 하던 팀이었다 치면 프리랜서는 은행 업무가 어떻게 돌아가는지 모르기 때문에 프로그램의 핵심 업무를 건드릴 수 없으며, 마찬가지로 은행 업무 관련된 내용이 자세히 묘사된 문서를 작성할 수도 없는 것이다.
본래 프리랜서의 도입 의도는, 핵심 영역은 정직원들 위주로 해결하고, 회사의 도메인을 잘 몰라도 할 수 있을 만한 업무는 프리랜서에게 맡김으로써 정직원을 추가 고용하는 것보다 장기적인 맥락에서의 비용 절감을 시도하며 프로젝트 완성도를 높이는 것에 목적이 있을 것이다. 하지만 감리가 길어질수록, 정직원들은 감리문서 작성에 집중을 하며, 그 공백을 프리랜서가 많이 채울 수록 프로젝트의 완성도는 낮아진다.
아무리 재주가 좋은 PM이라고 할 지라도 막상 새로운 프로젝트를 맡게 되면 항상 마감기한에 쫓기기 마련이다. 게다가 감리라고 하는 허들은 프로젝트 마감단계에 이르러서 “어떻게든 감리만 통과하자”라는 목표에 매달리게 하는데 큰 역할을 한다. 정직원 개발자 입장에서도 지금 프로젝트가 어느정도의 결함이 있는 것을 알고는 있지만, 지금 당장 감리를 넘어가는 것 보다 중요한 것은 없기에 허들을 넘는 것에 집중한다.
감리가 끝나고 나면 본격적인 문제가 시작된다. 가장 중요한 감리를 무사히 끝낸다면 모두가 행복해질까? 정답은 프리랜서만 행복해 진다는 것이다.
감리에 매달릴 때에 PM, PL은 일단 감리만 넘기고 나서 나중에 시간이 날 때에 프로젝트의 결함을 수정하자고 얘기한다. 하지만, 감리가 끝나고 프로젝트가 종료되면 프리랜서들은 정산받아 떠난다. 그러면 지친 정직원들과 미처 신경쓰지 못한 기존프로젝트의 유지보수 이슈와, 결함투성이의 신규프로젝트만이 남는다.
어쨌든 프로젝트가 종료되었으니, 일부는 휴가를 가기도 하고, 남은 사람들은 밀려있는 유지보수를 처리하는데 다시 집중하게 된다. 예전에 업무로 복귀하게 되어 몇 개월간 일 하다보면 결함 투성이의 신규 프로젝트는 완벽히 잊혀진다.
여기서 화룡점정을 찍는 두 가지 요소가 있다. 첫 번째는 프로젝트 종료 1~2년 후에 실제 서비스 되는 사업인 경우. 두 번째는 신규 프로젝트에 참여했던 정직원이 퇴사하는 경우다.
프로젝트에 결함이 있을지라도 시간을 들여서 보완하면 크게 문제 될 것은 없다. 하지만 프로젝트 종료하고 3개월만 지나도 어떤 이슈가 있었는지 까먹기에는 충분한데, 1~2년 후에 사용한다고 하면 실제 사용을 시작할 때에 눈에 보이지 않는 세균이나 바이러스를 상대하듯이, 있을 지 없을 지 모르는 결함에 대응해야 한다. 주로 사업규모가 커서 1차 사업 때에는 관리자 페이지만 만들고 2차 사업 때에 이용자 페이지를 만든다고 하면, 1차 사업자가 만든 결함에 2차 사업자나 유지보수 사업자가 봉변을 당하게 될 가능성이 높다.
1차 사업도 끝냈고, 2차 사업도 수주하는데에 성공했다고 치자, 근데 1차 사업에 참여했던 직원이 퇴사했다면? 서류상으로는 1차 사업을 수주했던 회사가 2차 사업까지 수주했으니까 1차 사업때의 내용과 잘 연계되는 시스템을 만들어 줄 것이라고 기대할 수 있지만, 2차 사업자의 입장에서는 아무것도 모르는데, 물어볼 사람도 없다. 1차 사업당시에 작성했다는 문서를 보고 어떻게든 맨 땅에 헤딩해가며 사업을 이어나가는 수 밖에 없다. 만약에 2차 사업을 수행하는 팀이 또 유지보수를 주력으로 하는 팀이고, 또다시 프리랜서를 고용한다면 높은 확률로 1차 사업과 같은 일이 벌어질 가능성이 높고, 그 모든 스노우볼은 유지보수 사업에게로 굴러갈 확률이 높다.
인터넷에 우스개 소리로 돌아다니는 말 중에 이런 말이 있다.
인간의 욕심은 끝이 없고 같은 실수를 반복한다.
회사가 업력이 짧고 규모가 작다면 신규 인원을 채용하는데에 당연히 부담스러울 것이다. 대한민국처럼 해고가 어려운 나라에서 정직원을 채용하는 것은 위험을 감수하는 일이기 때문에 프리랜서처럼 쉽게 쓰고 내보낼 인원을 선호하는 것은 크게 이상한 일이 아니다. 다만 신규 인력을 채용하는 데에 위험을 감수하지 않는다면 이런 일은 계속 일어날 것이다. 서류 작업하기를 좋아하는 사람은 없다. 사업을 수행할 당시에 정직원의 머리속에 ‘ 프리랜서는 나보다 훨씬 돈도 많이 받으면서 서류작업도 안하네? 유지보수도 신경쓰지 않아도 된다고? 나도 프리랜서나 할까? ‘ 라는 생각이 들기 시작한다면 회사의 인재유출은 더이상 막을 수 없을 것이다.