개발자 채용 외주, 유리한 쪽을 가르는 4가지 기준

정규직으로 개발자를 뽑을지, 외주에 맡길지는 회사 사정이 정한다. 서비스를 오래 직접 굴리면서 자주 고칠 예정이면 채용이 유리하고, 한 번 만들어 넘기는 프로젝트이거나 특정 기술만 잠깐 필요하면 외주가 낫다. 판단을 가르는 축은 기간, 유지보수 빈도, 기술 난도, 예산 네 가지로 좁혀진다.

핵심 요약

• 프로젝트가 6개월 안에 끝나고 이후 손댈 일이 적으면 외주가 비용과 속도 양쪽에서 앞선다.
• 매주 기능을 고치고 새로 붙이는 제품이라면 내부 개발자를 두는 편이 장기 비용을 낮춘다.
• 회사에 없는 기술이 잠깐만 필요할 때는 그 분야 외주 팀을 쓰는 쪽이 학습에 드는 시간을 아낀다.
• 월 고정비를 꾸준히 감당하기 어렵다면 프로젝트 단위로 지출하는 외주가 현금 흐름에 안전하다.
• 초기 구축은 외주로 맡기고 운영만 내부에서 이어받는 절충안도 현장에서 흔하게 쓰인다.

채용과 외주는 무엇이 다른가

정규직 채용은 사람을 조직 안에 두는 결정이고, 외주는 정해진 결과물을 사는 결정이다. 개발자를 뽑으면 급여 말고도 4대 보험, 장비, 채용 비용, 교육 시간이 따라붙지만, 그만큼 우리 제품을 속속들이 아는 사람이 회사에 남는다. 외주는 계약한 범위의 결과물을 약속한 기간에 받는 대신, 프로젝트가 끝나면 그 지식도 대체로 같이 빠져나간다.

둘의 갈림은 결국 시간축의 문제다. 코드가 회사에 오래 쌓여야 하는 자산이라면 그 자산을 다룰 사람도 안에 있어야 하고, 코드가 한 번 완성하면 크게 건드릴 일 없는 도구에 가깝다면 굳이 사람을 상시 붙들 이유가 줄어든다.

기간·유지보수·난도·예산으로 갈라보기

같은 개발 일이라도 아래 네 기준에 어디쯤 놓이느냐에 따라 답이 갈린다. 한 칸이라도 오른쪽에 크게 쏠리면 외주를, 왼쪽에 쏠리면 채용을 먼저 검토하는 식으로 읽으면 된다.

기준	정규직 채용이 유리	외주가 유리
기간	서비스를 1년 이상 운영하고 확장할 때	3~6개월짜리 단발 프로젝트일 때
유지보수 빈도	매주 수정과 배포가 이어질 때	출시 뒤 간헐적으로만 손볼 때
기술 난도	자사 핵심 기술을 계속 쌓아야 할 때	특정 분야 전문성이 잠깐 필요할 때
예산	월 급여를 안정적으로 감당할 때	프로젝트 단위 지출이 맞을 때

네 기준이 늘 한 방향을 가리키지는 않는다. 기간은 길지만 예산은 빠듯한 경우처럼 신호가 엇갈릴 때는, 지금 가장 아픈 항목을 우선순위에 두고 저울질하는 편이 현실적이다.

결정 전 체크리스트

감으로 정하기 전에 아래 순서대로 종이에 적어 보면 판단이 한결 또렷해진다. 특히 3번과 4번에서 막연했던 비용이 숫자로 드러나는 경우가 많다.

1. 이 서비스를 1년 뒤에도 우리가 직접 고치고 있을지 예/아니오로 적는다.
2. 출시 후 한 달에 기능을 몇 번쯤 바꿀지 예상 횟수를 센다.
3. 필요한 기술이 회사의 핵심 역량인지, 한 번 쓰고 말 도구인지 구분한다.
4. 개발자 한 명의 연봉에 4대 보험과 장비를 더한 실제 월 고정비를 계산한다.
5. 같은 결과물을 외주로 맡겼을 때의 견적과 위 고정비를 나란히 비교한다.
6. 코드와 문서를 넘겨받는 조건을 계약서에 넣을 수 있는지 확인한다.

6번을 빠뜨리면 외주가 끝난 뒤 유지보수가 막히기 쉬우니, 인수인계 범위는 계약 단계에서 못 박아 두는 편이 좋다. 출시 이후 흐름은 웹사이트 출시 다음 단계 글에서 더 자세히 다뤘다.

채용과 외주를 둘러싼 흔한 오해

외주 상담을 하다 보면 채용과 외주를 두고 굳어진 선입견을 자주 만난다. 그중 세 가지가 특히 잦다.

• "외주가 무조건 싸다"는 오해. 단발 프로젝트라면 대체로 맞다. 다만 수정 요청이 계약 범위를 넘기 시작하면 건마다 추가 견적이 붙어 장기 운영에서는 채용보다 비싸지기도 한다.
• "개발자 한 명만 뽑으면 다 해결된다"는 오해. 기획과 디자인, 서버 운영까지 한 사람이 감당하기는 어려워서 채용 뒤에도 일부 작업을 외주로 보완하는 회사가 많다.
• "맡기면 발주자는 기다리기만 하면 된다"는 오해. 요구사항 정리와 중간 검수는 끝까지 발주자 몫으로 남는다. 이 역할을 비워 두면 결과물이 처음 그림과 어긋난다.

가상 예시로 보는 판단

가상 예시를 하나 들어 보자. 대구의 한 교육 스타트업이 수강 신청 사이트를 3개월 안에 열어야 하는데, 개발자는 아직 한 명도 없고 초기 예산도 넉넉하지 않다. 출시 뒤에는 결제 오류나 문구 수정 정도만 이따금 손보면 된다. 이 조건이라면 기간은 짧고 유지보수는 뜸하며 고정비 부담이 크니, 사이트 구축은 외주로 맡기는 쪽이 합리적이다. 단발 구축을 외주로 맡길 때 견적이 어떤 범위로 짜이는지는 웹앱 개발 서비스 안내에서 미리 볼 수 있다.

반대로 같은 회사가 반년 뒤 학습 관리 기능을 매주 추가하며 자체 플랫폼으로 키우기로 했다면 이야기가 달라진다. 수정이 잦고 서비스 수명이 길어지는 만큼, 이 시점부터는 내부 개발자를 뽑아 지식을 회사에 쌓는 편이 낫다. 어떤 방식으로 시작할지 견적부터 잡아 보고 싶다면 견적 문의로 조건을 정리해 상담하면 된다.