고용 계약서 필드를 Excel로 추출하기,
HR을 위한 단계별 가이드
서명된 고용 계약서가 이메일 첨부 파일로 HR 부서에 도착합니다. 시작일은 다음 주 월요일이고, 세 개의 시스템이 데이터를 기다리고 있습니다. Workday는 직원 프로필을, BambooHR은 보상 기록을, ADP는 급여 설정을 필요로 합니다. 필요한 정보는 모두 우리 회사 자체 계약 템플릿을 사용하는 PDF 1~7페이지에 들어 있습니다. 하지만 그 안의 텍스트는 데이터가 필요한 소프트웨어에는 보이지 않습니다. 그래서 누군가 PDF를 열어 1페이지에서 직원 이름을 찾고, 3페이지로 스크롤해 급여를 확인하고, 5.2조에 묻혀 있는 수습 기간을 찾아낸 다음, 각 플랫폼에 모든 필드를 하나씩 직접 입력합니다. 미국 노동통계국에 따르면, 미국의 944,300명의 HR 전문가가 매일 이런 작업을 수행하고 있습니다. 그리고 그 어느 것도 청구 가능하거나 자동화되어 있지 않으며, 누구에게도 흥미로운 일이 아닙니다.
핵심 요점
- 일반적인 고용 계약서에는 이름, 직책, 급여, 시작일, 수습 기간, 통보 기간, 복리후생 등 10~14개의 필드가 들어 있으며, HR 코디네이터가 이를 Workday, BambooHR 또는 ADP에 수작업으로 다시 입력합니다. 신규 채용 1건당 20~30분이 소요되며 효율성 향상 없이 그대로 확장됩니다.
- HRIS는 입력한 내용을 저장하지만, 고용 계약서는 HRIS가 읽을 수 없는 PDF입니다. 또한 회사의 계약 템플릿이 신입사원이 이전 직장에서 서명한 템플릿과 일치하지 않기 때문에, 표준화된 인보이스에서 작동하는 템플릿 기반 추출 방식은 가장 많이 다루는 문서에서는 완전히 실패합니다.
- 원하는 열(직원 이름, 시작일, 급여, 수습 기간)을 지정하고 AI가 팀처럼 고용 계약서를 읽게 하는 것 — 각 필드가 페이지의 어느 위치에 있는지가 아니라 무엇을 의미하는지 이해하는 방식 — 계약서당 30분이던 작업을 약 10초로 단축합니다.
HRIS는 입력한 내용만 저장합니다 — 문서에 있는 내용은 저장하지 않습니다
Workday, BambooHR, ADP, SAP SuccessFactors, UKG는 수천만 명의 직원 기록을 공동으로 관리합니다. 이들 시스템은 급여, 복리후생 관리, 근태 추적, 성과 검토, 규정 준수 보고를 처리합니다. 하지만 그중 어느 것도 PDF를 읽지 못합니다.
이것은 누락된 기능이 아닙니다. 범주의 차이입니다. HRIS는 데이터베이스입니다 — 구조화된 기록을 저장하고 정리합니다. 자연어를 구문 분석하지 않으며, 여러 페이지에 걸쳐 흩어진 값을 찾지 못하고, 사람이 이미 올바른 필드에 값을 입력하지 않는 한 같은 문서 안의 "시작일"과 "발효일"의 차이를 알지 못합니다. HRIS는 목적지입니다. 서명된 고용 계약서는 출처입니다. 그 사이에는 두 개의 화면을 열어두고, 파일 캐비닛이 디지털로 전환된 이후로 변하지 않은 업무를 수행하는 사람이 있습니다.
이 격차는 온보딩 과정에서 드러납니다. 신입 사원의 고용 계약서는 PDF로 도착하며, 종종 서명된 종이 원본의 스캔입니다. 계약서에는 합의된 내용의 확정 기록이 포함되어 있습니다: 급여, 직위, 수습 기간, 퇴사 통보 기간, 근무 시간, 보너스 자격, 경업 금지 범위, 복리후생 가입 기간. 이 모든 값은 첫 급여 지급 전에 HRIS에 존재해야 합니다. 하지만 HRIS는 그중 어떤 것도 추출할 수 없습니다. 누군가 — 보통 HR 코디네이터 또는 담당자 — PDF를 열고 각 필드를 찾아 시스템에 입력한 후에만 값을 받아들일 수 있습니다.
HRIS는 저장 엔진이지 읽기 엔진이 아닙니다. 서명된 계약서를 받은 순간부터 그 데이터가 직원 데이터베이스에 나타나기까지의 시간은 수동 입력으로 채워집니다 — 그리고 그 시간은 비용을 발생시키고, 오류를 유발하며, 고용 인원이 늘어날 때마다 선형적으로 증가합니다.
한 달에 신규 직원 15명을 채용하는 회사 — 성장 단계의 중견 기업에게는 일상적인 속도 — 의 경우, 순수 재입력 시간이 약 7시간입니다. BLS 기준 HR 전문가 중간 임금인 연간 $72,910을 기준으로 하면, 이 단일 워크플로우의 연간 비용은 누구도 인지하지 못하는 사이에 다섯 자리 수에 도달합니다.
고용 계약서, 10~14개 필드, 그리고 왜 두 계약서도 같은 위치에 필드를 두지 않는가
HR 일반 담당자에게 서명된 고용 계약서에서 어떤 필드를 추출하는지 물어보면 주저 없이 나열할 것이다. 그 목록은 거의 변하지 않는다:
| 필드 | 계약서 내 일반적인 위치 | 중요한 이유 |
|---|---|---|
| 직원 이름 | 첫 페이지, 보통 상단 근처, 때로는 "당사자" 섹션에 있음 | 모든 HR 시스템 조회의 기본 키 |
| 직위 | 보통 서두 문단 또는 "역할" 섹션에 있음 | 조직도 배치와 보상 등급 결정 |
| 시작일 | 종종 "발효" 조항에 있으며, 때로는 1~2조에 있음 | 급여 지급 개시, 복리후생 가입 기간, 수습 기간 카운트다운을 촉발 |
| 연봉 | 위치가 다양함 — "보상" 섹션 또는 부록에 있는 경우도 있음 | 오퍼 레터와 정확히 일치해야 함; 불일치는 규정 준수 위험을 초래 |
| 수습 기간 | 종종 독립 조항으로, 예: "첫 90일은 수습 기간으로 간주한다" | 전체 복리후생 자격 시점 결정; 추적 누락 = 평가 마감일 놓침 |
| 사직 통보 기간 | 보통 "계약 종료" 섹션에 있으며, 2주에서 3개월까지 다양 | 퇴사 절차 일정을 규율; 인력 계획에 중요 |
| 근무 시간 / 일정 | "근로 시간", "일정" 또는 "고용 조건" 아래에 있을 수 있음 | FLSA 분류 기준(면제 vs. 비면제); 초과 근무 자격 |
| 복리후생 요약 | 종종 별도 섹션이나 일정에 있으며, 때로는 언급만 되고 상세는 분리됨 | 복리후생 등록 워크플로우를 구동; 오류는 공개 등록 기간에 표면화 |
| 경업 금지 범위 | 일반적으로 해지 또는 경업 제한 조항 근처에 위치 | 법적 집행 가능성은 주마다 다르며, 규정 준수를 위해 추적해야 함 |
| 임의 고용 명시 | 종종 첫 번째 섹션이나 고용 관계 조항에 포함 | 몬태나주를 제외한 모든 미국 주에서 적용; 명시적 문구는 해지 분쟁에서 고용주를 보호함 |
복잡한 점은 필드 목록이 아니라, 두 고용 계약서가 같은 방식으로 필드를 정리하지 않는다는 것이다. 회사는 자체 템플릿을 작성했다. 후보자의 이전 고용주는 다른 템플릿을 사용했다. 다국적 기업의 계약서를 처리한다면, 영국 법인의 템플릿은 급여를 별표 1에 두는 반면 싱가포르 사무소는 3페이지 "보수" 항목 아래에 둔다. 미국의 자유 고용(at-will) 진술은 한 계약서의 서두 문단에 나타나고, 다른 계약서에서는 서명란 앞에 굵은 글씨의 면책 조항으로 나타난다.
이러한 구조적 차이 때문에 템플릿 기반 추출 도구 — 페이지에 영역을 그리고 "급여는 항상 여기 있다"고 소프트웨어에 알려주는 방식 — 는 표준화된 청구서에서는 실패하지 않는 방식으로 고용 계약서에서 실패한다. 어떤 공급업체의 청구서든 대략 같은 레이아웃을 따른다: 헤더, 품목, 합계. 두 회사의 고용 계약서는 공유된 레이아웃 규칙이 전혀 없다. 중요한 필드는 작성자가 둔 곳에 있다.
고용 계약서는 어휘는 공유하지만 레이아웃은 공유하지 않는다. "수습 기간"은 한 계약서의 5.2조에 나타날 수 있고, 다른 계약서에서는 "고용 조건" 아래 불릿 포인트로, 또 다른 계약서에서는 직급이 충분히 높아 면제되었기 때문에 전혀 나타나지 않을 수 있다. 템플릿 기반 도구는 필드가 매번 같은 위치에 있기를 기대한다 — 고용 계약서가 절대 제공하지 않는 것이다.
이것이 HRIS가 스스로 문제를 해결할 수 없는 이유이기도 하다. HRIS가 필드 추출 기능이 있는 문서 업로드를 제공한다 해도 — 대부분은 제공하지 않지만 — 내부적으로 템플릿 매칭을 사용할 것이다. 받는 모든 계약서 형식에 대해 별도의 템플릿이 필요할 것이다. 시스템에 각 필드가 어디에 있는지 가르치는 데 현재 직접 입력하는 시간보다 더 많은 시간을 쓰게 될 것이다.
단계별: 서명된 PDF에서 HRIS 준비 스프레드시트까지 한 번에
템플릿 기반 추출의 대안은 의미 기반 추출입니다. AI는 계약서를 읽으며 위치가 아닌 의미를 찾습니다. 페이지에 영역을 정의하는 대신 출력 스프레드시트에 원하는 열을 정의하면 — "직원 이름," "시작 날짜," "급여," "수습 기간" — AI는 각 값을 찾아 해당 필드가 무엇을 나타내는지, 계약서에서 어떻게 표현될 가능성이 높은지 이해하여 위치에 관계없이 추출합니다. 이 접근 방식을 맞춤 열 추출이라고 합니다: 원하는 열을 지정하면 AI가 픽셀 좌표 대신 의미 이해를 사용하여 값을 채웁니다. 이 도구가 팀에 적합한지 아직 결정 중이라면, HR 계약 관리 추출 가이드에서 이 기능이 무엇인지, HR 팀이 언제 사용하는지 설명합니다.
다음은 문서당 20-30분의 수동 재입력을 10초 처리로 대체하는 워크플로우입니다.
서명된 근로계약서 업로드
PDF, 스캔본, 또는 서명된 종이 계약서 사진을 끌어다 놓으세요. 계약서 1개 또는 전체 배치(신규 채용 10명, 오퍼 레터 50건)를 하나의 처리 대기열에 업로드할 수 있습니다. 이 도구는 PDF, JPG, PNG, WebP를 지원하므로, 후보자가 전자 서명을 했든 종이에 펜으로 서명한 뒤 스캔했든 입력 형식은 중요하지 않습니다.
필요한 열 이름 지정
일반 언어로 필드 이름을 입력하세요 — "직원 이름", "직위", "시작일", "연봉", "수습 기간", "퇴직 통보 기간", "근무 시간", "복리후생 요약", "경업 금지 범위". 이 이름들이 출력 스프레드시트의 열 머리글이 됩니다. 각 필드가 계약서의 어디에 있는지 지정할 필요는 없습니다. AI가 문서를 의미적으로 읽어, 한 계약서 2페이지의 "근무 개시일"과 다른 계약서 1페이지의 "발효일"이 모두 "시작일" 아래에 필요한 동일한 의미임을 인식합니다.
스프레드시트를 다운로드하여 HRIS에 입력하세요
출력물은 Excel 스프레드시트(또는 원하는 경우 CSV)로, 각 행은 하나의 고용 계약서이고 각 열은 사용자가 지정한 필드 중 하나입니다. 10개 계약서의 14개 필드가 모두 하나의 테이블에 담깁니다. 여기에서 각 플랫폼의 일괄 가져오기 기능을 사용하여 Workday, BambooHR 또는 ADP에 직접 가져올 수 있는 구조화된 데이터셋이 만들어지며, 또는 전체 인력의 핵심 계약 조건을 추적하는 상시 참조 문서로 유지할 수도 있습니다. 고용 계약서 Excel 변환기는 이 동일한 열 이름 지정 워크플로우를 드롭 앤 추출 한 단계로 통합합니다.
실제 작동하는 워크플로우입니다. 고용 계약서를 업로드하고 열 이름을 지정하면 AI가 직접 해야 할 읽기를 수행합니다.
파일은 안전하게 처리되며 저장되지 않습니다.
AI가 필드를 찾지 못할 때 발생하는 상황에 대한 참고 사항: 수습 기간이 면제된 임원 계약서에 존재하지 않는 경우 해당 셀은 비워 둡니다. AI는 값을 만들지 않습니다. 추측하지 않습니다. 필드를 찾아 추출하거나 아무것도 반환하지 않습니다. 이 동작은 HR 데이터에 필수적입니다 — 빈 셀은 스프레드시트에서 쉽게 식별할 수 있지만, 잘못된 항목은 급여 오류나 규정 준수 기한을 놓칠 때까지 발견되지 않을 수 있습니다.
출력 결과를 Workday, BambooHR, ADP에 연동하기
추출된 스프레드시트는 최종 목적지가 아닙니다. 서명된 계약서와 HRIS를 연결하는 다리입니다. 모든 주요 HR 플랫폼은 Excel 또는 CSV 벌크 가져오기를 지원하며, 추출 중 사용한 열 이름은 HRIS가 기대하는 필드에 직접 매핑됩니다.
예를 들어 Workday는 EIB(Enterprise Interface Builder) 가져오기를 통해 직원 데이터를 수락합니다. BambooHR은 템플릿 스프레드시트를 사용한 벌크 직원 데이터 가져오기를 제공합니다 — 추출된 열을 BambooHR의 필드 이름에 맞춘 후 업로드하면 됩니다. ADP Workforce Now도 신규 채용 데이터에 대해 유사한 벌크 가져오기 워크플로우를 제공합니다. 핵심은 다음과 같습니다: 계약서 데이터가 구조화된 테이블에 들어가면 HRIS 가져오기 단계는 모든 플랫폼에서 직원당 시간이 아닌 분 단위로 완료됩니다.
이 방식이 확장되는 지점이기도 합니다. 계약서 10건을 추출했다면 10행짜리 스프레드시트 하나가 생깁니다. 팀을 확장 중이고 이번 분기에 50명을 채용했다면 50행짜리 스프레드시트 하나가 생깁니다. HRIS 가져오기 프로세스는 볼륨과 관계없이 동일합니다 — 즉 직원당 절약되는 시간이 정체되지 않고 누적됩니다. 배치 자체가 과제가 될 때 — 혼합 형식의 오퍼레터 50건이 같은 주에 도착하는 경우 — 배치 오퍼레터 및 계약서 추출 워크플로우가 그 규모에서만 나타나는 명명, 변동, 통합 문제를 해결합니다.
한 가지 주의할 점: 추출 후 HRIS 가져오기 전에 Start Date와 Salary 열을 원본 오퍼레터와 대조하세요. 이 두 필드는 불일치 시 가장 즉각적인 결과를 초래합니다 — 잘못된 시작일은 급여 활성화를 지연시키고, 잘못된 급여 금액은 Benefits Summary 필드의 오타보다 훨씬 되돌리기 어려운 법적·신뢰 문제를 만듭니다. 50행에 걸쳐 두 열을 30초간 스캔하는 것은 14개 필드를 모두 다시 입력하는 것보다 50배 빠릅니다. 전체 계약서보다 오퍼레터가 대부분이라면 서명된 오퍼레터를 Excel로 동일한 워크플로우를 가장 중요한 보상 및 시작일 필드에 한정합니다.
오퍼레터와 계약서와 함께 W-2 세금 양식 같은 표준 고용 문서도 처리한다면 계약서 데이터를 Excel로 추출이 문서 유형 전반에 걸쳐 작동합니다 — 정의한 열 이름은 원본 문서가 고용 계약서든, 독립 계약자 계약서든, 신규 채용자와의 NDA든 동일하게 적용됩니다. 열 세트 하나, 내보내기 하나, 가져오기 하나.
유연근무 서류도 그 테이블에 포함되어야 합니다 — 재택근무 계약서를 Excel로 변환하면 일반 사무실 계약서에는 절대 명시되지 않는 하이브리드 근무 일정, 재택근무 수당, 장비 조건이 포착됩니다.
FAQ
DocuSign의 데이터 필드나 HRIS 온보딩 모듈을 사용하면 안 되나요?
DocuSign은 서명을 위해 계약서를 보낼 때 서명 과정에서 필드를 태그할 수 있습니다. 이는 직접 작성한 발신 계약서에 적용됩니다. 하지만 고용 계약서는 종종 수신 형태로 도착합니다. 예를 들어 이전 고용주의 서명된 PDF(배경 확인용), 후보자가 반송한 카운터서명본, 또는 스캔된 종이 원본이 그렇습니다. 이런 경우에는 추출할 사전 태그 필드가 없습니다. HRIS 온보딩 모듈의 경우, 일반적으로 직원이 작성하는 디지털 양식을 제공하여 데이터를 사전에 수집하지만, 이미 실행된 PDF를 읽어 다른 사람이 다른 템플릿에서 작성한 조항을 소급해서 추출하지는 않습니다.
디지털 PDF가 아닌 스캔된 종이 문서 계약서도 작동하나요?
네. AI는 디지털 PDF에 내장된 텍스트 레이어에 의존하지 않고 페이지의 시각적 콘텐츠(인쇄된 텍스트, 스캔된 텍스트, 일부 손글씨 주석까지)를 읽습니다. 휴대폰으로 촬영한 종이 계약서도 Word에서 생성된 디지털 PDF와 동일하게 작동합니다. 이미지 품질은 읽을 수 있을 정도면 충분하며 완벽할 필요는 없습니다.
미국 외 형식의 계약서(영국 고용 계약서, 유럽 근로 협약)는 어떻게 처리하나요?
이 방식은 언어에 적응하고 형식에 구애받지 않습니다. "Remuneration"이라고 표기한 영국 계약서와 "Salary"라고 표기한 미국 계약서는 모두 "연봉"이라는 동일한 열로 매핑됩니다. AI가 관할권별 보상 표현을 이해하기 때문입니다. "Probation Period"(영국), "Introductory Period"(미국), 독일어 계약서의 "Probezeit"에도 동일한 논리가 적용됩니다. AI는 키워드 일치가 아닌 의미를 읽습니다.
미국 각 주의 at-will 고용 조항은 어떻게 처리하나요?
공정근로기준법(FLSA)은 연방 임금 및 근로시간 기준을 규율하지만, at-will 고용(어느 당사자든 합법적인 사유로 언제든지 고용 관계를 종료할 수 있다는 원칙)은 주법에 따라 규율됩니다. 몬태나주를 제외한 50개 주 모두 at-will을 따르며, 몬태나주는 수습 기간 후 종료 시 정당한 사유를 요구합니다. "At-Will 진술"을 열로 추출하면 AI는 서명란과 몇 단락이 떨어져 있든 관계없이 계약서에 명시적인 at-will 조항이 포함되어 있는지 식별합니다. 대부분의 미국 고용 계약서는 종료 분쟁에서 고용주의 법적 지위를 강화하기 위해 이 조항을 포함합니다. 몬태나주에서의 역할에 대한 계약서라면 표준 at-will 조항의 부재 자체가 플래그할 가치가 있는 데이터 포인트입니다.
이것과 계약 수명주기 관리(CLM) 시스템의 차이점은 무엇인가요?
CLM — Ironclad, LinkSquares, Sirion 같은 플랫폼 — 은 초안 작성, 협상, 승인, 전자 서명, 보관, 의무 추적, 갱신 알림 등 계약 전체 워크플로우를 관리합니다. 이는 8~10가지 기능입니다. 대부분의 HR 팀은 정확히 하나만 필요합니다: 체결된 근로계약에서 구조화된 데이터를 추출하는 것. 이 접근 방식은 구현 주기, 사용자당 라이선스, 또는 기능의 10%만 사용할 플랫폼 교육 없이 그 한 가지를 수행합니다. 전체 수명주기 관리가 필요한 기업에서 CLM을 대체하는 것은 아닙니다. 계약 문제가 "데이터를 HRIS에 넣는 것"으로 시작하고 끝나는 HR 팀에게 적합한 도구입니다.
데이터는 이미 문서에 있습니다. 꺼내는 것이 어려운 부분이 되어서는 안 됩니다.
근로계약서는 복잡한 법적 문서이지만, HR이 필요로 하는 데이터는 한정적이고 예측 가능합니다: 누가, 어떤 역할, 얼마나, 언제 시작, 어떤 조건, 어떤 제한. 그 목록은 수십 년 동안 변하지 않았습니다. 변한 것은 문서를 읽는 도구가 데이터를 저장하는 도구를 따라잡았다는 점 — 그리고 수년 동안 HR 코디네이터가 PDF를 하나씩 열어서 채웠던 그 두 도구 사이의 격차가 더 이상 수동으로 채울 필요가 없다는 점입니다.
미국 노동력의 944,300명의 HR 전문가들은 한 형식에서 다른 형식으로 정보를 다시 입력하기 위해 돈을 받지 않습니다. 그들은 사람을 고용하고, 개발하고, 유지하기 위해 돈을 받습니다. 서명된 계약과 HRIS 준비 스프레드시트 사이의 격차를 줄이는 것은 되돌리기 비용이 없고, 볼륨에 따라 즉시 가속화되며, HR 팀이 실제 직함이 설명하는 일에 시간을 쓸 수 있게 하는 몇 안 되는 운영 변화 중 하나입니다.
추출 워크플로우를 통해 샘플 근무계약서를 실행해 보세요. 위의 미리보기는 계약 프리셋을 사용합니다 — 팀이 실제로 필요한 열 이름을 입력하고, 30분의 교차 참조가 10초의 스프레드시트 대기로 바뀌는지 확인해 보세요.