인력 공급 및 근로자 파견 기업을 위한 일당 선지급: 여러 고객사에 걸친 근태를 어떻게 관리할 것인가?

인력 공급 또는 근로자 파견 기업에서 일당 선지급을 도입하려면, 각 근로자를 사용자(고용) 법인, 고객사, 사업장, 계약/업무, 급여 기간, 승인된 근태 데이터와 정확하게 연결해야 합니다. 기업은 어느 고객사가 근태를 기록하는지, 누가 승인 권한을 갖는지, 언제 근태가 한도를 생성할 요건을 충족하는지, 그리고 어느 주체가 결제·급여 처리·정산을 담당하는지를 명확히 규정해야 합니다. 근로자가 배치 전환되거나 업무를 종료하면, 일당 선지급 권한은 월말까지 기다리지 않고 효력 발생일에 따라 변경되어야 합니다.

> 참고: "인력 공급", "인사 서비스", "아웃소싱", "근로자 파견"은 당연히 동일한 법적 관계인 것이 아닙니다. 책임 범위, 사용자(고용) 주체, 임금 지급 방식은 계약과 적용 법률에 따라 규정되어야 합니다. 이 글은 일반적인 업무·기술 프레임워크이며, 각 모델에 대한 법률 자문을 대체하지 않습니다.

> 용어 설명: 일당 선지급(이미 근무한 일수의 임금 수령) · payroll(급여 처리) · assignment(고객사에서의 업무/배치) · SLA(서비스 수준 약정) · HRIS(인사정보시스템) · ERP(전사적 자원 관리) · cutoff(기간 마감 시점) · pilot(시범 도입) · UAT(인수 테스트) · KPI(성과 측정 지표).

왜 여러 고객사 모델이 단일 공장보다 더 복잡한가?

일반적인 제조 기업에서는 근로자, 근태 기록기, 근태를 승인하는 관리자, 급여 처리가 대개 동일한 조직 시스템에 속합니다. 인력 공급 또는 근로자 파견 기업의 경우, 근로자는 다음과 같을 수 있습니다.

• 한 법인과 근로 관계를 맺지만 고객사의 사업장에서 근무하고;

• 고객사로부터 근무조를 배정받고 출근을 확인받으며;

• 인력 기업이 근태를 집계하고 급여를 계산하여 지급하고;

• 동일 기간 내에 고객사나 사업장을 옮겨 다니며;

• 여러 수당, 초과근무, 또는 서로 다른 확인 규칙을 가지고;

• 고객사에서의 업무는 종료했지만 근로 관계는 아직 끝나지 않았거나;

• 또는 업무와 근로 관계를 서로 다른 두 시점에 종료할 수 있습니다.

일당 선지급은 시스템이 그 전체 맥락을 이해할 때에만 정확하게 계산됩니다. 직원 코드가 올바르더라도 고객사, 업무, 또는 기간이 잘못 연결되면 여전히 잘못된 한도가 생성될 수 있습니다.

1. 통합에 앞서 업무 모델을 명확히 구분하기

인력 공급/채용

서비스 기업은 후보자를 소개하거나 인력 소스를 제공하고, 고객사가 직접 근로 관계를 체결하고 관리하도록 할 수 있습니다. 이 경우 임금과 일당 선지급에 대한 책임 주체는 후보자를 공급한 기업이 아닐 수 있습니다.

근로자 파견

이것은 조건부 활동이며 노동 관련 법률의 규율을 받습니다. 파견 기업, 사용 기업, 파견 근로자, 업무 범위, 계약 및 각 당사자의 책임을 정확히 규정해야 합니다.

노동력을 사용하는 서비스 아웃소싱

고객사는 하나의 결과물이나 서비스를 구매하고, 공급 기업이 그 실행을 조직합니다. 관리, 근태 기록, 임금 지급 방식은 서비스 계약과 실제 근로 관계에 따라 달라집니다.

왜 분류가 일당 선지급에 중요한가?

이는 다음을 결정합니다.

• 누가 사용자(고용주)인지;

• 누가 임금을 확정하고 지급하는지;

• 누가 신뢰할 수 있는 근태 데이터를 보유하는지;

• 누가 승인 권한을 갖는지;

• 누가 자금 원천을 제공하는지;

• 거래가 누구와 정산되는지;

• 실제 역할에 따라 누가 데이터 관리자 또는 처리자인지;

• 누가 이의와 분쟁을 해결하는지.

모두 근로자가 고객사에서 근무한다는 이유만으로 모든 계약에 단일한 일당 선지급 프로세스를 사용해서는 안 됩니다.

2. 다자 데이터 아키텍처

(데이터 및 통합 요구사항: 일당 선지급과 근태·급여·ERP 통합 참조.)

flowchart TD
    A["인력 기업 HRIS"] --> E["표준 데이터 계층"]
    B["고객사의 근무조 및 근태"] --> E
    C["감독자 확인"] --> E
    D["급여 및 계약"] --> E
    E --> F["일당 선지급 한도 엔진"]
    F --> G["결제"]
    G --> H["급여, ERP 및 고객사 정산"]

각 도메인별 단일 표준 원천 원칙

3. "사람 – 업무 – 고객사 – 급여 기간" 데이터 모델

employee_id만으로는 충분하지 않습니다. 한 사람이 동일 기간 내에 여러 번 배치될 수 있습니다.

중요한 키

• employee_id: 근로자 코드;

• employerid 또는 legalentity_id: 근로 관계를 체결한 법인;

• client_id: 고객사;

• site_id: 근무 사업장;

• assignment_id: 구체적인 업무/배치;

• contract_id: 서비스 계약 또는 필요한 참조;

• payroll_group: 급여 규칙/기간 그룹;

• payperiodid: 급여 기간;

• effectivefrom, effectiveto: 효력 발생일;

• transaction_id: 일당 선지급 거래;

• payment_reference: 결제 참조.

왜 `assignment_id`가 중요한가?

한 직원이 고객사 A에서 10일, 고객사 B에서 12일 근무한다면, 시스템은 각 근태 기록이 어느 업무에 속하는지, 누가 승인했는지, 어떤 규칙이 적용되는지를 알아야 합니다. 직원 프로필에 현재 고객사만 유지하면서 이력을 덮어써서는 안 됩니다.

배치 데이터 예시

{
  "employee_id": "EMP-000123",
  "employer_id": "NK-DEMO",
  "client_id": "CLIENT-DEMO-B",
  "site_id": "SITE-B02",
  "assignment_id": "ASN-2026-00871",
  "payroll_group": "MONTHLY-B",
  "effective_from": "2026-08-12",
  "effective_to": null,
  "status": "ACTIVE",
  "record_version": 3
}

이것은 예시용 가상 데이터이며, 일당 선지급의 공식 API 구조가 아닙니다.

4. 누가 근태를 기록하고 누가 근태를 승인하는가?

(기초 개념: 승인된 근태란 무엇인가? 참조.)

세 가지 역할이 다를 수 있습니다.

1. 기록자: 근태 기록기, 애플리케이션, 근태표 또는 현장 감독자.

2. 출근/업무 확인자: 조장 또는 고객사 관리자.

3. 급여 산정을 위한 승인자: 절차에 따른 인력 기업의 권한 있는 담당자.

자주 나타나는 네 가지 승인 모델

일당 선지급은 정책상 승인된 정확한 상태를 사용해야 합니다. "고객사가 열람함"이 당연히 "급여 지급을 위해 승인된 근태"인 것은 아닙니다.

5. 근태 승인 SLA는 고객사와 함께 설계해야 한다

고객사가 근태를 늦게 확인하면, 플랫폼이 정상 작동하더라도 근로자는 한도를 볼 수 없습니다. 따라서 근태 승인 SLA는 HR 내부 업무만이 아니라 협업 프로세스의 일부여야 합니다.

권장 KPI

기한 내 승인된 근태 비율 (%) = 마감 전 승인된 기록 ÷ 승인 대상 전체 기록 × 100%

다음 기준으로 추적합니다.

• 고객사별;

• 사업장별;

• 근무조별;

• 승인자별;

• 예외 유형별;

• 미승인 근태의 경과 기간별;

• 지연 사유별.

전사 단일 비율 하나만 보고해서는 안 됩니다. 승인이 잘되는 여러 고객사에 가려져 승인이 느린 한 고객사가 보이지 않을 수 있습니다.

알림 및 에스컬레이션 메커니즘

• 마감 전후 알림;

• 처리가 필요한 예외 목록;

• 승인자가 부재 시 대체 위임;

• 기록 경과 기간에 따른 에스컬레이션;

• 어느 근무지에 데이터가 없을 때의 경고;

• 고객사 및 기업 담당자에게의 보고;

• 늦은 승인 시 사유 기록.

6. 고객사 근태에 어떤 필드가 필요한가?

고객사가 파일을 전송하는 경우 batch_id, 레코드 수, 체크섬, 생성 시각, 파일 버전을 추가로 넣어야 합니다.

7. 동일 기간 내 고객사 간 배치 전환

이는 중복 근태나 누락 근태가 발생하기 쉬운 상황입니다.

갖추어야 할 프로세스

1. 효력 발생 일시로 기존 배치를 종료하고;

2. 새 배치를 개설하고;

3. 규칙에 어긋나는 중첩 구간이 없는지 확인하고;

4. 기존 고객사에 미처리로 남은 근태를 확인하고;

5. 새 급여 그룹과 일당 선지급 정책을 확정하고;

6. 규칙이 바뀌었으면 한도를 재산정하고;

7. 한도가 영향을 받으면 근로자에게 통지하고;

8. 새 사업장에 따라 관리/승인 권한을 부여하고;

9. 이미 발생한 거래를 올바른 급여 기간과 정산합니다.

기존 고객사를 덮어쓰지 말 것

프로필에는 assignmentid 이력이 필요합니다. 현재의 clientid만 바꾸면, 과거 보고서가 모든 근태와 거래를 새 고객사에 귀속시킬 수 있습니다.

8. 업무 종료는 퇴직과 다르다

한 사람은 고객사 A에서 종료하고 고객사 B로의 전환을 기다릴 수 있고; 또는 완전히 퇴직할 수도 있습니다.

기업에는 최소한 두 개의 독립적인 상태가 필요합니다.

• 근로 관계 상태;

• 배치/업무 상태.

참고용 처리 매트릭스

공식 규칙은 HR, Payroll 및 법무의 승인을 받아야 합니다. 고객사 파일 하나만으로 자동 잠금 또는 해제해서는 안 됩니다.

9. 여러 고객사에서의 다수 급여 기간과 정책

인력 기업은 같은 기간에 급여를 지급할 수 있지만, 고객사 데이터는 서로 다른 날에 마감됩니다. 일부 고객사는 수당, 초과근무, 개근 상여 또는 고유한 반올림 규칙을 가지고 있습니다.

버전 관리가 필요한 설정 테이블

소스 코드에 고객사 이름으로 정책을 하드코딩해서는 안 됩니다. 설정에는 효력 발생일, 승인자, 변경 이력이 있어야 합니다.

10. 초과근무와 변동 소득 항목

고객사에서의 초과근무는 여러 단계를 거칠 수 있습니다: 신청, 실행, 고객사 확인, 기업 승인, 급여 잠금.

근무조 수당, 개근, 생산량 또는 상여 같은 항목은 기간 말에만 확정될 수 있습니다. 기업은 다음과 같이 분류해야 합니다.

• 이미 확정되고 승인된 부분;

• 잠정 산정되었으나 조정 가능성이 있는 부분;

• 기간 말에만 확정되는 부분;

• 일당 선지급에 포함하지 않는 부분.

변동 항목을 한도에 산입하는 경우, 예비 메커니즘, 버전 관리, 그리고 근로자를 위한 설명이 필요합니다. 고객사로부터의 예상 매출을 각 개인의 임금 수령 권한에 대한 직접적 근거로 사용해서는 안 됩니다.

11. 고객사가 근태를 늦게 수정할 때의 책임

일당 선지급 거래가 이미 발생한 후에 근태가 수정될 수 있습니다. 프로세스는 다음에 답해야 합니다.

1. 고객사가 어느 기간 내에 수정할 수 있는지;

2. 누가 변경을 승인하는지;

3. 변경 전/후 값을 저장하는지;

4. 어느 거래가 이전 버전을 사용했는지;

5. 현재 한도를 어떻게 재산정하는지;

6. 차액을 어느 기간에 처리하는지;

7. 누가 근로자에게 연락하는지;

8. 고객사와 기업이 어떻게 정산하는지;

9. 반복되는 오류를 어떻게 시정하는지.

기존 레코드를 삭제해서는 안 됩니다. 거래 시점의 한도를 재현할 수 있도록 조정 이벤트 또는 버전이 필요합니다.

12. 다자 모델에서의 자금 원천과 현금흐름

도입 전에 다음을 확정해야 합니다.

• 어느 주체가 근로자에게 자금을 이체하는지;

• 원천 계좌가 누구의 것인지;

• 언제 거래가 당사자 간 채무로 인정되는지;

• 인력 기업과 고객사가 언제 정산하는지;

• 수수료를 누가 부담하는지;

• 실패, 불확실, 또는 환불 거래를 어떻게 처리하는지;

• 고객사가 결제를 지연할 때 근로자의 권익과 각 당사자의 의무가 어떻게 되는지;

• 채권·채무와 회계 분개를 어느 계약에 따라 반영하는지.

계약과 실제 현금흐름이 이를 보장하지 않는다면, 고객사가 반드시 제날짜에 결제한다는 가정에 근거해 일당 선지급을 설계해서는 안 됩니다. Finance 부서는 현금흐름 시나리오와 프로그램 한도를 수립해야 합니다.

13. 5방향 정산

(정산 세부: 일당 선지급 거래와 급여·회계 정산 참조.)

여러 고객사 모델에서 정산은 다섯 방향이 필요할 수 있습니다.

1. 확인/승인된 근태;

2. 일당 선지급 한도 및 거래;

3. 결제 결과;

4. 급여/ERP;

5. 관련 시 고객사와의 확인/정산 기록.

flowchart TD
    A["고객사 근태"] --> F["정산"]
    B["일당 선지급 거래"] --> F
    C["결제 결과"] --> F
    D["급여 및 ERP"] --> F
    E["고객사 기록"] --> F
    F --> G["일치 또는 차액 케이스"]

자주 발생하는 차이

• 고객사는 확인했으나 기업이 아직 승인하지 않음;

• 근태가 잘못된 assignment_id에 있음;

• 이미 전환한 사람이 기존 사업장에 여전히 근태가 있음;

• 일당 선지급은 성공했으나 급여에 누락됨;

• 결제는 성공했으나 일당 선지급이 콜백을 아직 받지 못함;

• 거래가 잘못된 법인 또는 기간에 들어감;

• 고객사가 cutoff 이후에 근태를 수정함;

• 고객사별 총액은 맞지만 직원별로는 틀림;

• 수수료 또는 정산 항목이 잘못된 계약에 연결됨.

14. 불필요한 데이터를 노출하지 않으면서 고객사에 권한 부여하기

(보안 프레임워크: 일당 선지급 도입 시 데이터 보안과 개인정보 보호 참조.)

고객사 측 사용자는 자신이 확인해야 하는 범위에 속하는 근로자와 데이터만 보아야 합니다. 다음을 고객사에 기본으로 열람하게 해서는 안 됩니다.

• 선지급 수령의 전체 이력;

• 개인 거래 금액;

• 다른 고객사에서의 데이터;

• 전체 은행 계좌 정보;

• 책임 범위 밖의 급여 기록;

• 상세 사기 경보;

• 근태에 불필요한 인사 데이터.

권한 통제

• clientid, siteid, 역할에 따른 권한 부여;

• 만료일이 있는 권한;

• 계약 또는 담당자가 바뀔 때의 재검토;

• 승인자에 대한 MFA;

• 공용 계정 사용 금지;

• 열람, 수정, 승인 및 데이터 내보내기 로깅;

• 대량 데이터 다운로드 시 별도 승인;

• 고객사 사용자가 퇴직/전환하면 즉시 통지 및 권한 회수.

15. 삼자 지원 채널

근로자가 오류가 고객사, 인력 기업, 일당 선지급 제공자 중 누구에게 있는지 스스로 추측하게 해서는 안 됩니다.

문제 유형별 분류

티켓에는 전 과정을 관통하는 코드와 근로자가 추적할 수 있는 상태가 있어야 합니다. 근로자에게 각 주체마다 처음부터 다시 연락하도록 요구해서는 안 됩니다.

16. 인력 공급 기업을 위한 KPI

선행 KPI

• 유효한 assignment를 가진 근로자 비율;

• 고객사가 기한 내 근태를 전송한 비율;

• 기한 내 승인된 근태 비율;

• 승인 대기 근태의 평균/중앙값 경과 기간;

• 기한 내 반영된 assignment 변경 비율;

• 한도 데이터의 최신성.

경험 및 운영 KPI

• 고객사별 활성화 비율;

• 거래 성공률;

• 자금 수령 시간;

• 거래 1,000건당 티켓 수;

• 자동 처리 비율;

• 자동 정산 비율;

• 고객사/원인별 차이;

• cutoff 이후 근태 조정.

인사 및 상업 KPI

• 초기 단계의 입사 및 출근율;

• 코호트별 퇴직;

• 인력 충족률;

• 수동 가불 요청;

• 인지도 및 만족도;

• 고객사당 운영 업무량.

전후 비교만으로 일당 선지급이 인력 변화를 야기했다고 결론지어서는 안 됩니다. 계절성, 수주량, 임금 수준, 관리, 사업장 및 기타 정책을 살펴봐야 합니다.

17. 시범 도입 시 어느 고객사를 선택해야 하는가?

(표준 로드맵: 기업용 90일 일당 선지급 시범 도입 계획 참조.)

적합한 시범 고객사는 대개 다음을 갖추고 있습니다.

• 명확한 니즈와 합의;

• 권한 있는 담당자;

• 비교적 안정적인 근태 데이터;

• 대표성 있는 근무조 및 초과근무 프로세스;

• 테스트에 충분한 인원/거래 수;

• 기한 내 근태 승인에 대한 준비;

• 커뮤니케이션 및 지원 협력;

• 대규모 근태 시스템을 동시에 교체하지 않음.

관계가 편하다는 이유만으로, 프로세스가 나머지와 너무 다른 고객사를 선택해서는 안 됩니다.

시범 범위가 다루어야 할 것

• 한 차례의 온보딩/활성화 사이클;

• 정규 근무조, 초과근무 및 예외 근태;

• assignment 전환 또는 종료;

• 성공, 실패, 불확실, 환불 거래;

• 일일 정산;

• 완전한 한 급여 기간;

• 범위에 해당하면 고객사 확인/정산;

• 이의 제기 및 사고.

18. 여러 고객사 UAT 체크리스트

근로자 및 assignment

• [ ] 한 사람이 하나의 활성 assignment를 가짐.

• [ ] 한 사람이 기간 내 두 개의 유효한 assignment를 가짐.

• [ ] 고객사 간 배치 전환.

• [ ] 업무는 종료했으나 아직 퇴직하지 않음.

• [ ] 퇴직했으나 고객사 파일에 여전히 근태가 있음.

• [ ] 잘못된 법인 또는 고객사 코드.

근태 및 승인

• [ ] 고객사가 기한 내 근태를 전송함.

• [ ] 확인 대기 근태와 승인된 근태.

• [ ] 거부된 근태.

• [ ] 승인 후 수정된 근태.

• [ ] 중복, 누락 또는 잘못된 순서로 도착한 파일.

• [ ] 승인자가 부재하고 대체 위임이 있음.

한도 및 거래

• [ ] 요건을 충족하는 데이터만 한도를 생성함.

• [ ] assignment 변경이 정확한 날짜에 적용됨.

• [ ] 동일 키로 재전송해도 중복 거래를 생성하지 않음.

• [ ] Timeout이 불확실 상태를 생성함.

• [ ] 환불 거래가 올바르게 처리됨.

급여 및 정산

• [ ] 거래가 올바른 사람, 법인, 고객사 및 기간에 들어감.

• [ ] 급여가 중복 거래를 차단함.

• [ ] 총액만이 아니라 각 거래별로 정산함.

• [ ] 차이가 담당자가 있는 케이스를 생성함.

• [ ] 조정에 변경 전/후 값과 승인이 있음.

권한 및 보안

• [ ] 고객사 사용자가 자신의 범위만 봄.

• [ ] 고객사가 불필요한 개인 일당 선지급 이력을 열람하지 못함.

• [ ] 권한이 올바르게 만료되고 회수됨.

• [ ] 데이터 내보내기가 로깅됨.

• [ ] 파일 유출 또는 계정 도용 시나리오를 훈련함.

19. 유의해야 할 법률 프레임워크

노동법 제45/2019/QH14호는 2021년 1월 1일부터 시행되었습니다. 시행령 제145/2020/NĐ-CP호는 2021년 2월 1일부터 시행되었으며, 노동 조건 및 근로 관계에 관한 노동법의 일부 조항을 상세히 규정하고 지침을 제공하는데, 여기에는 근로자 파견 관련 내용이 포함됩니다.

기업은 법적 모델, 활동 조건, 각 당사자의 권리와 의무, 임금 지급 책임 및 적용 서류를 정확히 규정해야 합니다. "인력 공급"이라는 용어로 실제 관계의 분류를 대체해서는 안 됩니다.

데이터와 관련하여, 개인정보 보호법 제91/2025/QH15호와 시행령 제356/2025/NĐ-CP호는 2026년 1월 1일부터 시행됩니다. 인력 기업, 고객사, 일당 선지급 제공자, 결제 파트너 간의 데이터 공유는 역할, 목적, 범위 및 실제 보호 조치에 따라 재검토되어야 합니다.

상품, 가불, 정산 및 공제에 관한 구체적인 법적 결론은 EWA라는 명칭만으로 추정하지 말고, 계약, 규정 및 실제 자금흐름에 근거해야 합니다.

결론

일당 선지급은 분산된 노동력의 니즈를 해결하고 가불의 디지털화를 돕기 때문에 인력 공급 및 근로자 파견 기업에서 큰 잠재력을 가집니다. 그러나 복잡성 또한 더 높습니다: 근태 데이터는 고객사에서 발생하고, 급여는 인력 기업에 속하며, 거래는 일당 선지급 제공자를 통하고, 결제는 일관되게 연결되어야 합니다.

성공의 조건은 사람 – assignment – 고객사 – 급여 기간 모델을 올바르게 관리하고, 기한 내 근태를 승인하며, 업무 종료를 퇴직과 분리하고, 최소 권한을 부여하며, 각 거래까지 정산하는 것입니다. 여러 고객사와 사업장에서 근무하는 노동력을 위한 일당 선지급 모델을 논의하려면 기업용 일당 선지급을 알아보세요.

참고 자료

• 노동법 제45/2019/QH14호

• 노동법 시행령 제145/2020/NĐ-CP호

• 개인정보 보호법 제91/2025/QH15호

• 개인정보 보호법 시행령 제356/2025/NĐ-CP호

---

저자: Nguyen Minh Khang — 전략팀 전문위원, Nhan Kiet Manpower Supply Co., Ltd.

기업용 일당 선지급 솔루션 상담: Hotline 0937.022.655 · Email info@nhankiet.vn · 기업용 일당 선지급