개발 외주를 주면서 개발자 두세 명을 우리 사무실 빈자리에 앉히는 그림은 흔합니다. 아침 스탠드업에 함께 들어오게 하고, 슬랙으로 바로 기능을 요청하고, 출퇴근 시간도 우리 규정에 맞춥니다. 발주사 입장에서는 진행 상황이 눈에 보이니 가장 안심되는 방식입니다.
그런데 이 방식은 계약서 제목이 '소프트웨어 개발 도급계약서'여도 근로자파견으로 뒤집힐 수 있습니다. 뒤집히면 그 개발자를 직접 고용해야 할 의무가 생기고 과태료가 따라붙습니다. 상주 자체가 문제인지, 상주 중 무엇이 문제인지를 나눠서 봐야 합니다.
상주 자체는 금지되지 않지만 지시 방식이 선을 넘습니다
파견근로자 보호 등에 관한 법률에는 도급과 파견을 가르는 조문이 따로 없습니다. 그래서 고용노동부 지침과 대법원 판례가 계약의 형식이 아니라 실질을 보고 판단합니다. 개발자가 우리 층에 앉아 있다는 사실 하나로 파견이 되지는 않습니다.
발주사 사무실에서 일하는 것, 발주사 장비와 망을 쓰는 것, 발주사 담당자와 매일 얼굴을 보는 것까지는 도급으로도 설명이 됩니다. 갈리는 지점은 그 자리에서 누가 무엇을 어떤 경로로 지시하느냐입니다.
계약서에 무엇이라고 적었는지는 판단에 거의 영향을 주지 않습니다. 남는 것은 슬랙 대화 기록, 근태 기록, 좌석 배치와 조직도입니다.
고용노동부 지침은 두 단계로 나눠서 봅니다
고용노동부는 2019년 12월 30일 「근로자파견의 판단기준에 관한 지침」을 개정했습니다. 2007년 지침 이후 12년 만의 개정이고, 2015년 대법원 판결의 기준을 그대로 담았습니다. 지금도 이 지침이 현행 기준입니다.
1단계는 외주사가 사업주로서 실체가 있는지입니다. 소속 직원의 채용과 해고를 스스로 결정하는지, 사무실과 운영 자금을 독자적으로 마련하는지, 4대보험과 원천징수 같은 사업주 책임을 지는지, 장비를 갖추고 있는지를 봅니다. 실체가 없으면 발주사와 직접 근로계약관계가 있다고 판단합니다.
2단계는 실체가 인정되는 외주사를 상대로, 발주사가 그 직원을 실제로 지휘·명령해 사용했는지를 봅니다. 상주 계약에서 문제가 되는 것은 대부분 이 2단계입니다.
대법원이 보는 다섯 가지는 이렇게 나뉩니다
기준이 된 판결은 대법원 2015년 2월 26일 선고 2010다106436 판결입니다. 이 판결은 발주사가 업무 수행 자체에 구속력 있는 지시를 하는지, 그 인력이 발주사 사업에 실질적으로 편입되었는지, 외주사가 인력 선발과 근무 관리 권한을 독자적으로 행사하는지, 계약 목적이 범위가 한정된 업무로 확정되고 전문성이 있는지, 외주사가 독립적인 조직과 설비를 갖췄는지를 봅니다.
다섯 개를 모두 충족해야 도급이 되는 것은 아니고 종합해서 판단합니다. 다만 상주 개발 인력 계약에서는 지시, 근무 관리, 계약 목적의 특정성 세 가지가 거의 항상 쟁점이 됩니다. 아래에서 이 셋을 나눠서 봅니다.
업무 지시를 누가 어떤 경로로 하는지가 첫 번째 갈림길입니다
지침은 작업 배치와 변경, 작업량, 작업 방법처럼 업무 수행의 구체적인 사항에 관해 구속력 있는 지시를 하는지를 봅니다. 판단할 때는 과업지시서와 실제로 쓰는 업무 시스템까지 함께 확인합니다. 지라 티켓을 발주사 직원이 개발자 개인에게 직접 배정하는 구조도 여기에 들어갑니다.
발주사 PM이 개발자에게 슬랙 다이렉트 메시지로 "이건 오늘까지 해 주세요"라고 보내는 순간부터 증거가 쌓입니다. 지시는 외주사 관리자에게 하고 그 관리자가 소속 인력에게 배분하는 구조를 지켜야 합니다. 다만 긴급 상황 대응이나 안전 관련 지시는 지침도 파견의 징표로 보지 않습니다.
근태 관리는 가장 먼저 드러나는 지점입니다
지침과 판례 모두 작업 시간, 휴게 시간, 휴가를 누가 정하고 관리하는지를 봅니다. 발주사가 출근 시간을 정하고 연차와 병가를 승인하면 그 자체로 인사·노무 권한을 행사한 것으로 읽힙니다. 근태 시스템에 외주 인력을 등록해 두었다면 더 분명해집니다.
출입카드 기록으로 상주 시간을 집계해 그 시간으로 대금을 정산하는 방식도 위험합니다. 보안 목적의 출입 통제와 근태 관리는 다른 일이니 기록의 용도를 분리하세요. 휴가 통보는 외주사가 발주사에 하는 것이지, 개발자가 발주사에 결재를 올리는 것이 아닙니다.
인력 선발과 교체를 발주사가 정하면 도급이 아닙니다
대법원은 외주사가 투입 인력의 선발, 인원수, 교육과 훈련, 근무 태도 점검을 독자적으로 행사하는지를 봅니다. 발주사가 이력서를 받아 면접해서 사람을 고르고, 마음에 들지 않으면 특정 인원의 교체를 요구하고, 자사 신입 교육에 함께 넣는 운영은 인사권 행사로 판단됩니다.
광주고등법원은 2026년 1월 22일 선고 2023나23653 판결에서 장기 아웃소싱 계약을 불법파견으로 인정했습니다. 계약 규모와 서류 형식이 갖춰져 있었는데도, 원청이 인력 충원과 배치에 관여하고 개별 근로자에게 인사·징계 권한을 행사한 실태가 근거가 됐습니다.
도급 목적이 특정되지 않으면 나머지를 지켜도 무너집니다
대법원이 보는 네 번째 요소는 계약 목적이 구체적으로 범위가 한정된 업무의 이행으로 확정되었는지입니다. 맡은 일이 발주사 직원의 업무와 구별되는지, 그 업무에 전문성과 기술성이 있는지도 함께 봅니다.
"개발 인력 3명을 12개월간 투입한다"처럼 사람 수와 기간으로만 적힌 계약은 목적이 특정되지 않은 것입니다. 투입 인월을 대금 산정의 기준으로 쓰는 순간 일의 완성이 아니라 인력 공급을 산 것이 됩니다. 산출물 목록, 완료 기준, 검수 절차로 계약서를 다시 쓰세요.
파견으로 판단되면 2년을 못 채워도 직접고용 의무가 생깁니다
컴퓨터 관련 전문가의 업무는 한국표준직업분류 120으로, 파견법 시행령 별표 1의 파견 허용 업무입니다. 업무 자체가 금지된 것은 아니라는 뜻입니다. 실제 문제는 허가입니다.
일반 개발 외주사는 근로자파견사업 허가를 받지 않았습니다. 허가 없는 사업주로부터 파견 역무를 제공받으면 파견법 제6조의2 제1항 제5호에 따라 기간과 관계없이 즉시 직접고용 의무가 발생합니다. 2년을 기다릴 필요도 없습니다.
직접고용 의무를 이행하지 않으면 3천만원 이하의 과태료가 부과됩니다. 허가 없이 파견사업을 하거나 그 역무를 제공받은 경우에는 3년 이하의 징역 또는 3천만원 이하의 벌금이 따로 규정돼 있습니다. 허가받은 파견업체를 썼더라도 2년을 넘겨 계속 사용하면 역시 직접고용 의무가 생깁니다.
상주 인력을 쓸 때 지켜야 할 선은 이렇습니다
계약서 문구만 고쳐서는 소용이 없습니다. 계약서와 실제 운영이 같은 이야기를 해야 합니다. 다음 항목은 분쟁이 생겼을 때 실제로 확인되는 것들입니다.
- 계약 대상을 인원수와 기간이 아니라 산출물과 검수 기준으로 적습니다.
- 대금은 투입 인월이 아니라 산출물 단위나 마일스톤으로 지급합니다.
- 모든 요청은 외주사의 지정 관리자 한 명을 거치게 하고, 그 창구를 문서로 못 박습니다.
- 개발자 개인에게 직접 티켓을 배정하거나 다이렉트 메시지로 업무를 지시하지 않습니다.
- 출퇴근, 연차, 병가는 외주사가 관리하고 발주사는 결재에 관여하지 않습니다.
- 특정 인원의 교체나 징계를 요구하지 않고, 필요하면 산출물 품질을 근거로 외주사에 시정을 요구합니다.
- 발주사 조직도와 좌석표, 메신저 채널, 사내 행사 명단에 외주 인력을 발주사 직원처럼 올리지 않습니다.
상주 자체를 없앨 필요는 없습니다. 자리를 구분하고, 지시 경로를 하나로 만들고, 근태를 넘겨주는 것만으로도 위험은 크게 줄어듭니다.
이럴 때는 도급으로 가지 마세요
요구사항이 매일 바뀌고 우선순위를 발주사가 그때그때 정해야 하는 일이라면 도급 형식을 유지할 수 없습니다. 발주사 기획자가 백로그를 직접 관리하고 스프린트마다 할 일을 다시 정하는 방식이 대표적입니다. 이런 일은 실질이 이미 파견입니다.
그때는 형식을 억지로 맞추지 말고 허가받은 근로자파견업체를 통해 파견으로 계약하거나, 직접 채용하는 편이 낫습니다. 파견으로 가면 2년 제한을 지켜야 하고 그만큼 비용도 올라가지만, 뒤늦게 직접고용 의무와 과태료를 맞는 것보다 예측 가능합니다. 판단이 애매하면 계약 전에 노무사 검토를 받는 것이 가장 싼 방법입니다.
관련 글은 실무 가이드에서 볼 수 있고, 원문은 고용노동부 근로자파견의 판단기준에 관한 지침과 국가법령정보센터의 파견근로자 보호 등에 관한 법률에서 확인하세요. 외주 개발 계약 구조가 고민이라면 Codeforest에 문의하셔도 좋습니다.
결론: 자리보다 지시 경로와 계약 목적을 먼저 고치세요
개발자를 우리 사무실에 앉히는 것 자체는 막혀 있지 않습니다. 문제가 되는 것은 그 개발자에게 직접 업무를 지시하고, 근태를 관리하고, 사람을 골라 배치하는 운영입니다. 여기에 계약서가 인원과 기간으로만 적혀 있으면 도급이라고 주장할 근거가 남지 않습니다.
바꿔야 할 것은 세 가지입니다. 계약서를 산출물과 검수 기준으로 다시 쓰고, 모든 지시를 외주사 관리자 한 명을 거치게 하고, 근태 관리 권한을 외주사에 넘기세요. 이 셋이 지켜지지 않는 일이라면 처음부터 도급이 아니라 파견이나 직접 채용으로 가는 것이 맞습니다.
