다교대 제조기업을 위한 EWA: 정확한 근무 시간 산정을 위해 어떻게 도입할까?

다교대 제조기업에서 EWA(조기 급여 지급)를 도입하려면, 시스템은 교대 스케줄과 실제 근무를 구분하고, 정상 근무와 연장 근무를 구분하며, 대기 중인 데이터와 승인된 데이터를 구분하고, 기간 내 거래와 컷오프 이후 조정을 구분해야 합니다. 모든 레코드에는 직원 코드, 근무일, 교대, 공장, 승인 상태, 업데이트 시점, 버전이 연결되어야 합니다. 기업은 데이터가 비교적 안정적인 공장 한 곳에서 파일럿을 진행하고, 제때 승인된 근무 비율, 한도 최신성, 거래 성공률, 페이롤 차이를 측정한 뒤 확대해야 합니다.

> 참고: 이 글은 업무 및 기술 참고 프레임워크입니다. 급여 공식, 한도에 포함되는 항목, 한도, 승인 절차, 정산 시점은 기업, EWA 공급업체, 페이롤, 법무, 회계가 실제 자료에 근거해 확인해야 합니다.

> 용어 설명: EWA(이미 근무한 일수에 따라 급여를 미리 받는 제도) · payroll(급여 계산) · HRIS(인사 정보 시스템) · ERP(전사적 자원 관리) · cutoff(급여 기간 마감) · pilot(시범 운영) · UAT(사용자 인수 테스트) · KPI(성과 지표) · workflow(업무 흐름) · wave(확대 단계) · dashboard(모니터링 대시보드) · go-live(정식 운영 전환).

왜 공장 환경은 별도의 EWA 과제인가?

제조기업은 대규모 노동력을 보유하고, 여러 교대로 운영하며, 주문에 따라 연장 근무가 발생하고, 데이터가 근태기 → 조장 → 감독자 → 인사 → 페이롤 → 회계 → 은행 등 여러 단계를 거칩니다. 교대 스케줄이 있다고 해서 그 교대를 모두 근무했다는 뜻은 아닙니다. 카드 태깅 기록이 있다고 해서 승인된 근무라는 뜻도 아닙니다. 등록된 연장 근무도 실제로 완료되고 승인된 연장 근무는 아닐 수 있습니다.

이러한 환경에서 가장 큰 과제는 '급여 받기' 버튼을 표시하는 것이 아니라 다음 질문에 정확히 답하는 것입니다:

• 근로자가 현재 근무 중이며 프로그램 대상에 해당하는가;

• 어떤 교대가 완료되었는가;

• 어떤 근무가 계산 대상에 해당하는가;

• 어떤 소득 항목이 충분히 확정되었는가;

• 정책에 따라 어떤 금액을 보류해야 하는가;

• 이전 거래가 어떻게 송금·정산되었는가.

위 질문 중 하나라도 잘못 답하면 한도가 실제보다 높거나 낮아져 민원과 기말 조정 업무가 늘어납니다.

1. 교대 근무부터 EWA 거래까지의 데이터 흐름 지도

```mermaid
flowchart TD
A["교대 스케줄"] --> B["출근/퇴근 기록"]
B --> C["예외 처리"]
C --> D["근무·연장 근무 승인"]
D --> E["지급 대상 급여 산정"]
E --> F["EWA 한도"]
F --> G["거래 및 지급"]
G --> H["페이롤·회계·대사"]
```

각 단계에는 표준 데이터 소스와 책임자가 있어야 합니다. 근태 처리 절차가 확인되지 않은 상태에서 EWA 플랫폼이 카드 태깅 한 번을 급여로 자동 해석하도록 두어서는 안 됩니다.

2. 교대 스케줄, 근태 데이터, 승인된 근무의 구분

(핵심 개념: 승인된 근무란 무엇인가? 참조.)

교대 스케줄

교대 스케줄은 근로자가 언제 근무할 예정인지를 보여줍니다. 지각, 조퇴, 휴무, 교대 변경, 교대 중복을 발견하는 데 사용되지만, 실제로 근무했다는 증명은 되지 않습니다.

출근–퇴근 기록 데이터

기기가 기록한 이벤트 데이터입니다. 태깅을 잊었거나, 기기 오류, 네트워크 단절, 잘못된 기기 태깅, 평소 위치가 아닌 곳에서 근무한 경우 등으로 누락될 수 있습니다.

승인된 근무

규칙 적용과 예외 처리를 거친 후의 업무 결과입니다. 정책에 따라 이 상태만 한도 산정 엔진에 포함될 수 있습니다.

왜 '임시 근무'라는 표현을 명확히 하지 않고 사용하면 안 되는가?

기업이 임시 데이터로 한도를 표시하려면, 위험 완화 장치, 상태 라벨, 보류 비율, 데이터 변경 시 재계산 방식을 갖춰야 합니다. 근로자는 가용 금액이 어떤 이유로 변동될 수 있는지 이해해야 합니다. 승인 대기 중인 소스로 확정된 것처럼 보이는 숫자를 표시해서는 안 됩니다.

3. 다교대 공장을 위한 최소 데이터 필드 세트

직원 프로필

교대 및 근무

페이롤 및 거래

• payperiodid;

• 지급 대상 소득 항목 코드;

• 공식 버전;

• 컷오프 시점;

• 급여 기간 상태;

• transaction_id;

• idempotency_key;

• 요청 금액, 수수료, 실제 송금액;

• EWA 및 지급 상태;

• payment_reference;

• 거래 전/후 한도;

• 산정에 사용된 데이터 버전.

4. 야간 근무는 어느 날짜에 귀속되어야 하는가?

자정 전에 시작해 다음 날 끝나는 교대는 흔한 오류 원인입니다. 근태 시스템은 이벤트를 달력 날짜로 기록하는 반면, 페이롤은 전체 교대를 시작일 또는 업무일로 귀속시킬 수 있습니다.

기업은 다음을 확정해야 합니다:

1. 야간 근무의 work_date는 시작일인지 종료일인지;

2. 근무 시간과 야간 수당을 어떻게 구분할지;

3. 교대 후 연장 근무는 어느 날짜에 속하는지;

4. 교대를 가로지르는 휴일/휴무일을 어떻게 처리할지;

5. 표준 시간대는 무엇인지;

6. 컷오프가 한 교대를 두 기간으로 나누는지;

7. 이후 도착하는 콜백/데이터에 대해 재계산하는지.

예시

어떤 교대가 10일 22:00에 시작해 11일 06:00에 끝난다고 가정합니다. 근태가 11일을, 페이롤이 10일을 사용한다면, shiftid와 workdate가 통일되지 않으면 EWA가 부족 또는 중복 계산할 수 있습니다.

월간 총 시간만 비교하는 방식으로 해결해서는 안 됩니다. EWA는 각 시점에서 어떤 근무가 지급 대상인지 알아야 하기 때문입니다.

5. 연장 근무는 언제 한도에 포함되는가?

연장 근무에는 보통 여러 상태가 있습니다:

1. 계획됨;

2. 근로자가 절차에 따라 등록 또는 동의;

3. 실제 출근;

4. 감독자 확인;

5. HR/페이롤 승인;

6. 급여 기간 잠금.

기업은 어떤 상태가 EWA 대상인지 정해야 합니다. 연장 근무는 한도를 더 매력적으로 만들 수 있지만 정상 근무보다 변동도 큽니다.

참고용 정책 3가지

어느 방안이든 페이롤, HR, 법무, 리스크 관리의 승인을 받아야 합니다. EWA가 모든 overtime_minutes를 확정된 금액으로 간주해서는 안 됩니다.

6. 유급 휴가, 무급 휴가, 근무 부족

이 상황들은 한도에 각각 다른 방식으로 영향을 줍니다:

• 유급 휴가는 승인 후 정책에 따라 계산될 수 있음;

• 무급 휴가는 해당 급여를 만들지 않음;

• 대체 휴무(보상 휴가)는 다른 기간 데이터와 관련될 수 있음;

• 출근/퇴근 기록 누락은 예외 처리가 필요함;

• 지각/조퇴에는 반올림 규칙이 있음;

• 작업 중단 또는 전환에는 별도 메커니즘이 있음;

• 출장/교육은 근태기에 나타나지 않을 수 있음.

기업은 공장마다 제각각 해석하지 않도록 상태 코드표를 만들어야 합니다.

표의 값은 기업이 확인해야 하며, 이것은 구조 예시일 뿐입니다.

7. 늦은 근무 수정과 한도 버전 관리

공장에서는 근로자가 거래한 이후에 근무가 수정될 수 있습니다. 시스템은 다음을 알아야 합니다:

• 어떤 레코드가 변경되었는지;

• 수정 전·후 값;

• 누가 수정하고 누가 승인했는지;

• 한도 계산에 사용된 버전;

• 영향을 받는 거래;

• 차액을 언제 처리하는지;

• 다음 거래를 일시 중지해야 하는지.

이전 레코드를 삭제하면 안 되는 이유

버전 또는 조정 이벤트를 생성해야 합니다. 직접 덮어쓰면 거래 시점의 한도가 왜 그 값이었는지 재현할 수 없습니다.

추적 필드 예시

```json
{
"employee_id": "EMP-000123",
"work_date": "2026-08-18",
"shift_id": "NIGHT-A",
"approvalstatus": "ADJUSTEDAPPROVED",
"regular_minutes": 480,
"overtime_minutes": 60,
"record_version": 4,
"sourceupdatedat": "2026-08-20T03:20:15Z"
}
```

이는 설명을 위한 가상 데이터이며 Lương Ngày의 공식 사양이 아닙니다.

8. 제때 근무 승인은 핵심 선행 KPI

프로젝트의 앱이 훌륭하더라도 근무 승인이 늦어지면 실패할 수 있습니다. 근로자가 한도를 보지 못하면 EWA가 작동하지 않는다고 생각합니다.

권장 KPI

$$
\text{제때 근무 승인율} = \frac{\text{마감 전에 승인된 승인 대상 레코드}}{\text{승인 대상 전체 레코드}} \times 100\%
$$

다음을 기준으로 추적해야 합니다:

• 공장;

• 작업장;

• 교대;

• 조장/감독자;

• 예외 유형;

• 기간 내 일자;

• 교대 종료부터 승인까지의 시간.

목표는 KPI를 감독자 징계 도구로 만드는 것이 아닙니다. 대시보드는 기기 오류, 잘못된 직원 목록, 너무 많은 예외, 승인 권한 부족, 부적합한 절차 등 원인을 보여줘야 합니다.

9. 이해하기 어렵지 않게 한도를 어떻게 산정할까?

개념적 공식은 다음과 같이 나타낼 수 있습니다:

$$
\text{가용 한도} = \text{승인된 지급 대상 소득} \times \text{허용 비율} - \text{보류 금액} - \text{기간 내 수령액}
$$

구성 요소를 정의해야 합니다:

• 어떤 소득이 지급 대상인지;

• 근무가 어떤 상태인지;

• 허용 비율이 누구/어떤 그룹 기준인지;

• 보류 금액의 목적;

• 처리 중인 거래가 한도를 차지하는지;

• 근무 조정이 한도를 어떻게 바꾸는지;

• 언제 한도가 급여 기간에 대해 잠기는지.

승인되지 않은 세부 공식이나 리스크 임계값을 공개해서는 안 됩니다. 근로자에게는 표시 금액을 이해할 만큼만 설명하면 되며, 내부 부정 방지 로직까지 알 필요는 없습니다.

10. 근태 시스템 및 페이롤과의 통합

(데이터 요구사항 및 아키텍처: 근태, 페이롤, ERP와의 EWA 통합 참조.)

근실시간 API

최신 시스템을 갖춘 공장에 적합하며 승인 후 빠른 갱신이 필요합니다. 인증, 버전, 재시도, 순서가 어긋난 데이터 도착, 오류 모니터링을 통제해야 합니다.

배치 파일/SFTP

레거시 시스템 또는 일정 기반 마감 절차에 적합합니다. 파일에는 배치 코드, 총 레코드 수, 체크섬, 버전, 명명 규칙, 중복 방지, 라인별 오류 보고가 필요합니다.

통제된 수동 동기화

소규모 파일럿에서 사용할 수 있습니다. 표준 템플릿, 작성/승인 담당자, 로그, 합계 확인, 안전한 파일 저장 영역, 확대 시 수동 작업 제거 계획이 필요합니다.

모든 포인트 시스템을 직접 연결하지 말 것

여러 공장을 둔 기업은 여러 근태기나 소프트웨어를 보유할 수 있습니다. 표준화된 통합 레이어를 두면 EWA가 기기별 로직을 따로 작성하는 대신 동일한 데이터 모델을 받을 수 있습니다.

11. 생산 환경에서의 4중 대사

(상세: 페이롤·회계와의 EWA 거래 대사 참조.)

대사는 다음을 연결해야 합니다:

1. 근무와 한도;

2. EWA 거래;

3. 지급 결과;

4. 페이롤/ERP.

자주 찾아야 할 차이

• 근무가 수정됐지만 한도가 갱신되지 않음;

• 거래는 성공했지만 페이롤에 누락;

• 지급은 성공했지만 EWA가 처리 중;

• 잘못된 기간에 입력된 거래;

• 한 거래가 두 번 나타남;

• 퇴직자가 여전히 거래 발생;

• 환급이 절차에 따라 복구되지 않음;

• 직원 코드는 맞지만 법인/공장이 틀림;

• 총액은 일치하지만 개별 거래는 과다·누락이 상쇄됨.

각 차이에는 케이스, 담당자, 내부 기한, 증거, 종결 승인자가 필요합니다.

12. 공장 내 근로자 지원 조직

교대 근무자는 업무시간 외에 문제를 겪을 수 있습니다. 지원 채널은 실제 사용 시간대에 맞춰야 합니다.

3단계 지원

티켓에 포함할 사항

• 통제된 직원 코드;

• 공장 및 교대;

• 문제 유형;

• 거래 코드(있는 경우);

• 시점;

• 근무/한도 상태;

• 수행된 조치;

• 다음 담당자;

• 기한 및 결과.

지원 직원은 근로자에게 비밀번호나 OTP를 요구해서는 안 됩니다.

13. 현장 커뮤니케이션은 단순하되 충분해야

메시지는 다음을 설명해야 합니다:

• EWA란 무엇인가;

• 어떤 금액을 받을 수 있는가;

• 한도가 왜 변하는가;

• 수수료(있는 경우);

• 거래가 어떻게 정산되는가;

• 근무가 승인되지 않았을 때 어떻게 해야 하는가;

• 전화번호/수령 계좌 변경 시 어떻게 해야 하는가;

• 이상 거래 신고 채널;

• EWA는 급여명세서 확인을 대체하지 않음.

커뮤니케이션 채널

• 온보딩;

• 교대 시작 회의;

• QR 코드가 있는 포스터;

• 짧은 동영상;

• 앱/SMS;

• 조장 또는 공장 내 HR;

• 노동력이 필요할 때 2개 국어 자료.

조장만 교육하고 모든 근로자가 이해했다고 가정해서는 안 됩니다. 도달률, 활성화율, 반복 질문을 측정해야 합니다.

14. 생산 현장에서의 보안과 개인정보 보호

(전체 프레임워크: EWA 도입 시 데이터 보안 및 개인정보 보호 참조.)

흔한 위험에는 전화 공유, SIM 변경, 창구 지원, 다른 사람의 데이터가 보이는 화면, 부적절한 채널로 전송되는 Excel 파일이 있습니다.

필요한 통제:

• 활성화 및 민감 거래 시 본인 확인;

• 계정 공유 금지;

• 공개 장소 표시 시 계좌번호·금액 마스킹;

• 채팅방으로 급여명세서 촬영/전송 금지;

• 공장 및 직무별 권한 분리;

• 지원 행위 로그;

• 기기/전화번호 변경 절차;

• 테스트 데이터는 가상 또는 마스킹;

• 중간 파일 보존 기간 및 삭제;

• 계정 분실 신고 채널.

개인정보 보호법 제91/2025/QH15호와 시행령 제356/2025/NĐ-CP호는 2026년 1월 1일부터 시행됩니다. 기업은 실제 아키텍처에서 역할, 목적, 처리 범위, 근로자 권리를 검토해야 합니다.

15. 한 공장에서의 EWA 파일럿은 어떻게 설계할까?

(표준 로드맵: 기업용 90일 EWA 파일럿 계획 참조.)

범위 선택

다음 조건을 갖춘 작업장 또는 교대 그룹을 선택해야 합니다:

• 확인된 수요;

• 비교적 양호한 데이터;

• 근무 승인에 응할 준비가 된 감독자;

• 대표적인 페이롤 절차;

• 충분한 현장 지원;

• 다음 확대 대상과 너무 다르지 않을 것.

최소한 중요한 라이프사이클은 모두 경유

파일럿은 다음을 검증해야 합니다:

• 활성화;

• 정상 근무 및 연장 근무;

• 야간 근무;

• 근무 조정;

• 성공/실패/미확인 거래;

• 일일 대사;

• 완전한 페이롤 기간 한 번;

• 민원 및 예외 처리.

파일럿 KPI

• 지급 대상자 중 유효 데이터 보유 비율;

• 제때 근무 승인율;

• 근무 승인부터 한도 갱신까지의 시간;

• 활성화율;

• 거래 성공률;

• 수령 시간;

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

• 자동 대사 비율;

• 원인별 차이;

• 미확인 거래;

• 오차단율;

• 사용자/거래당 운영 비용.

목표 수치는 다른 프로젝트에서 복사하지 말고 공장의 베이스라인과 역량에 근거해야 합니다.

16. 생산 교대를 위한 UAT 체크리스트

교대 및 근무

• [ ] 주간 교대 정상 출근.

• [ ] 이틀에 걸친 야간 교대.

• [ ] 컷오프 전후 교대 변경.

• [ ] 출근 기록 누락 또는 퇴근 기록 누락.

• [ ] 지각, 조퇴 및 반올림 규칙.

• [ ] 유급 휴가 및 무급 휴가.

• [ ] 근태기를 거치지 않는 출장/교육.

연장 근무

• [ ] 계획됐지만 실시되지 않은 OT.

• [ ] 실시됐지만 승인 대기 중인 OT.

• [ ] 승인된 OT.

• [ ] 승인 후 수정된 OT.

• [ ] 기업 절차에 따른 휴일 OT.

직원

• [ ] 효력일이 아직 되지 않은 신입.

• [ ] 휴직자.

• [ ] 기간 중 퇴직자.

• [ ] 공장/법인 이동자.

• [ ] 중복 또는 잘못 매핑된 직원 코드.

거래

• [ ] 한도 내 요청.

• [ ] 한도 초과 요청.

• [ ] 동일 멱등성 키로 중복 전송.

• [ ] 타임아웃 및 미확인 결과.

• [ ] 지급 실패.

• [ ] 환불 거래.

페이롤 및 대사

• [ ] 올바른 기간에 입력된 거래.

• [ ] 중복 입력 파일 차단.

• [ ] 늦은 근무 수정으로 추적 가능한 조정 생성.

• [ ] EWA–지급–페이롤–ERP 일치.

• [ ] 차이 케이스 생성 및 승인 종결.

17. 한 공장에서 여러 공장으로의 확대

교대, 기기, 페이롤 또는 법인이 다른 공장에 구성을 그대로 복사해서는 안 됩니다.

웨이브 분할

다음이 같은 공장을 그룹화합니다:

• 동일한 근태 시스템;

• 동일한 교대 코드 세트;

• 동일한 페이롤 정책;

• 동일한 법인;

• 동일한 지원 역량;

• 동일한 근무 승인 준비 수준.

각 웨이브 전 게이트

• 직원·교대 매핑 검증 완료;

• 근무/연장 근무 규칙 서명 승인;

• 공장별 UAT 실시;

• 감독자 교육 완료;

• 대시보드·대사가 새 범위를 커버;

• 접근 권한이 올바른 단위에 부여;

• 이전 웨이브 오류 처리 완료;

• 롤백 준비 완료.

확대 시 성능 저하를 감지하도록 공장별 KPI를 추적합니다.

18. 흔한 실수

교대 스케줄을 실제 근무로 사용

근무 증거가 생기기 전에 한도를 생성.

모든 카드 태깅을 유효한 근무로 간주

태깅 누락, 교대 중복, 타인 태깅, 예외를 무시.

승인되지 않은 연장 근무 전체를 계산

한도 변동을 키우고 기말 조정을 증가.

야간 근무 날짜 불일치

근무 누락/중복과 오기간 귀속 발생.

거래만 측정하고 근무 승인은 측정하지 않음

감독자 단계의 병목을 발견하지 못함.

HR이 모든 티켓 처리

HR 혼자 지급 오류, API, 대사, 부정을 해결할 수 없음.

수동 관리하던 파일럿을 확대

결과는 좋아 보이지만 규모 운영 능력을 반영하지 않음.

늦은 근무 수정을 덮어쓰기

거래 시점 한도 재현 불가.

결론

EWA는 다교대 제조기업에서 특히 잠재력이 크지만, 그 가치는 근무가 정확하고 제때 확인될 때만 나타납니다. 플랫폼은 교대 스케줄–근태–승인된 근무를 구분하고, 야간 근무와 연장 근무를 명확히 처리하며, 데이터 버전을 관리하고 거래 단위까지 대사해야 합니다.

기업은 데이터가 비교적 안정적인 공장 한 곳에서 시작해, 제때 근무 승인율을 선행 KPI로 삼고, 완전한 페이롤 기간을 한 번 통과한 후에만 웨이브 단위로 확대해야 합니다. 기업용 Lương Ngày을 살펴보고 공장 근태 데이터 조사와 Lương Ngày 파일럿 범위를 논의해 보세요.

참고 자료

• 노동법 제45/2019/QH14호

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

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

---

저자: Nguyễn Tấn Lộc — Công ty TNHH Cung Ứng Nhân Lực Nhân Kiệt 전략팀 전문가.

기업용 Lương Ngày 솔루션 문의: 핫라인 0937.022.655 · 이메일 info@nhankiet.vn · 기업용 Lương Ngày