채용 제안서 및 계약서를 일괄 추출하여
하나의 직원 데이터베이스로

채용 물결은 채용 위기가 아닌 데이터 위기를 만든다

미국 노동통계국에 따르면 미국에는 944,300명의 HR 전문가가 있습니다. 2024년 기준 이들의 연봉 중앙값은 $72,910 — 시간당 약 $35입니다. HR 코디네이터가 서명된 계약서의 데이터를 Workday, BambooHR 또는 ADP에 다시 입력하는 데 쓰는 매 시간은 급여로 약 $35에 복리후생비를 더한 비용이 들며, 전략적 가치는 전혀 창출하지 못합니다. 신규 채용 1건에 데이터 입력 1시간은 반올림 오차에 불과합니다. 하지만 50건이라면 순수 전사 비용만 $1,750에 달합니다 — 게다가 금요일 오후 4시 30분에 급여 숫자를 잘못 입력해 HRIS에 오류가 스며들 가능성은 아직 계산에 넣지도 않았습니다.

하지만 수동 입력의 비용은 더 작은 문제입니다. 더 큰 문제는 규정 준수입니다. 연방법에 따라 모든 신규 채용자는 시작일로부터 3영업일 이내에 I-9 양식(고용자격 확인서)을 완료해야 합니다. 고용주는 신분증을 검토하고, 문서 정보를 기록하고, 진위를 증명해야 합니다. 이 기록 단계는 축소판 문서 추출 작업이며, 완성된 I-9 양식을 Excel로 변환하면 List A/B/C 문서 번호와 만료일이 파일 캐비닛 조회 대신 스프레드시트 열이 됩니다. 또한 공정근로기준법(FLSA)은 고용주가 각 직원의 이름, 주소, 직업, 급여율, 근무 시간 기록을 유지하도록 요구합니다. 이는 선택 사항이 아닙니다. 민사 처벌이 수반되는 연방 의무입니다.

채용이 꾸준히 소량으로 이루어질 때 — 한 달에 한두 명 — 규정 준수 부담은 감당할 수 있습니다. HR 코디네이터는 계약서 PDF를 열고, 1페이지에서 직원 이름을 찾고, 3페이지로 스크롤해 급여를 확인하고, 5.2조에 묻혀 있는 수습 기간을 찾아내 각 값을 HRIS에 입력합니다. 채용 1건당 20분이면 끝납니다. 하지만 채용이 가속화되면 계산은 완전히 달라집니다. 새 고객을 확보했거나, 두 번째 지점을 열었거나, 성수기 인력을 충원하는 회사는 한 번에 한 명씩 채용하지 않습니다. 20명, 50명, 100명을 채용합니다. 그리고 오퍼가 발송된 다음 날 아침, HR은 서명된 PDF 폴더와 볼륨이 늘어났다고 해서 줄어들지 않는 3일 마감 기한을 마주합니다.

계약 1건과 50건 사이에 무엇이 달라지는가

문서량 문제에 대한 본능적인 대응은 "더 빨리 작업하면 된다"입니다. 그러나 일괄 처리는 단일 문서 처리를 50번 반복하는 것이 아닙니다. 이는 고유한 과제를 지닌 별개의 작업입니다. 즉, 계약서를 한 번에 한 건씩 처리할 때는 드러나지 않는 과제입니다. 문서량이 "머릿속으로 관리할 수 있는 수준"에서 "시스템이 필요한 수준"으로 넘어갈 때 무너지는 것들이 있습니다.

첫째, 파일 이름 지정입니다. 계약서 3건(Alice_Contract.pdf, Bob_Offer_Letter_signed.pdf, Contract_Chen_v2.pdf)이 도착하면 각 파일을 해당 인물과 쉽게 매핑할 수 있습니다. 하지만 50건이 공유 받은 편지함이나 Google Drive 폴더에 쌓이고, 파일명의 절반이 자동 생성된 경우("Scan_Dec_05_2025_001.pdf") 정신적 매핑은 붕괴됩니다. 파일명만으로는 어떤 문서가 어떤 신입사원의 것인지 더 이상 알 수 없습니다. 이름을 확인하려면 파일을 열어야 합니다. 식별을 위해 50개 파일을 여는 것은 단일 문서 규모에서는 존재하지 않았던 추가적인 부담입니다.

둘째, 구조적 차이입니다. 단일 회사는 표준 고용 계약서 템플릿을 사용할 수 있습니다. 그러나 일괄 채용에서는 서명된 계약서와 함께 오퍼 레터를 처리하는 경우가 많으며, 두 문서는 동일한 필드를 포함하지 않습니다. 오퍼 레터는 급여와 시작일을 명시하지만, 통지 기간은 생략할 수 있습니다. 서명된 계약서에는 오퍼 레터에 언급되지 않은 경업 금지 조항이 포함될 수 있습니다. 일부 계약서는 2절에 수습 기간을, 다른 계약서는 6.3절에 명시합니다. 일부는 "Commencement Date"를 사용하고, 다른 일부는 "Effective Date"라고 합니다. 단일 문서 규모에서는 HR 코디네이터가 이러한 차이를 정신적으로 해석합니다. 일괄 규모에서는 정신적 해석이 오류를 발생하기 쉽습니다.

셋째, 결과 통합입니다. 50건의 계약서에서 데이터를 성공적으로 추출하더라도, 이제 50세트의 추출 값이 있습니다. 필요한 것은 하나의 직원 데이터베이스, 즉 행이 직원에 해당하고 열이 HRIS에 입력해야 하는 필드에 해당하는 단일 스프레드시트입니다. 병합 단계(50개의 추출 결과를 하나의 테이블로 정렬하고, 모든 행에서 열이 일치하는지 확인하고, 누락된 필드를 조정)는 일괄 워크플로우가 수동 대체로 전환되는 지점입니다.

이 세 가지 문제 — 파일명, 구조 차이, 통합 — 는 일괄 처리가 속도 문제가 아니라 설계 문제인 이유입니다. 이를 해결하면 입력 작업은 저절로 해결됩니다. 해결하지 않으면, 아무리 빠른 키 입력 효율성으로도 격차를 좁힐 수 없습니다.

아무도 쓰지 않는 파일 명명 문제

일괄 온보딩 프로세스의 모든 순간에 HR 코디네이터는 파일 이름만으로는 어떤 계약서가 누구의 것인지 알 수 없다는 것을 깨닫게 됩니다. Maria Gonzalez의 고용 계약서는 이전 고용주의 HR 포털이 자동으로 이름을 지정했기 때문에 "Final_Signed.pdf"로 도착했습니다. Jamal Williams는 개인 이메일에서 제안서를 전달했고 첨부 파일은 "Scan0001.pdf"로 읽힙니다. 다른 세 명의 후보자는 DocuSign을 사용했으며 해당 파일은 모두 "Completed — Employment Agreement.pdf"라고 불립니다.

단일 채용 시나리오에서는 이는 사소한 불편일 뿐입니다. 파일 이름을 바꾸고 진행하면 됩니다. 50명 채용 배치에서는 파일 탐색기에서 2시간을 소모하게 됩니다. 더 나쁜 것은: 각 파일에 의미 기반 열 이름 추출을 사용하는 경우, 출력에 직원 식별자(이름 또는 후보자 ID)가 포함되어야 스프레드시트에 결과가 들어갈 때 모든 행을 올바른 사람에게 추적할 수 있습니다. 일반적인 파일 이름으로는 이러한 추적 가능성을 얻을 수 없습니다.

워크플로우는 매우 특정한 지점에서 무너집니다: 파일 수신과 데이터 추출 사이의 핸드오프입니다. 명명 시스템이 그 지점에서 끊기면 병합된 출력 스프레드시트에서 HRIS 가져오기에 이르기까지 모든 다운스트림이 모호성을 물려받습니다. 17행이 Alice Chen일 수도 있고 Alice Kim일 수도 있는 데이터베이스를 신뢰할 수 없으며, 알아내는 유일한 방법은 원본 PDF를 수동으로 교차 참조하는 것입니다. 그 교차 참조가 명명 문제의 비용이며, 배치 규모에서만 나타납니다.

50개 추출 결과를 하나의 직원 데이터베이스로 병합

대부분의 문서 추출 튜토리얼은 출력이 나타나는 순간에 끝납니다. 그러나 배치 온보딩 워크플로우에서 출력은 끝이 아니라 중간입니다. 50개의 추출 결과는 50개의 출력을 생성합니다. HR에 필요한 것은 하나의 테이블입니다: 각 행이 직원이고 각 열이 HRIS 가져오기에 준비된 데이터 필드인 단일 스프레드시트입니다.

이것이 맞춤 열 추출이 산술을 바꾸는 지점입니다. 각 개별 계약서에 나타나는 필드를 추출하여 일관되지 않은 열 구조를 가진 50개의 출력을 생성하는 대신, 추출이 시작되기 전에 열을 한 번 정의합니다. 원하는 필드 이름을 입력합니다: 직원 이름, 직위, 시작 날짜, 연봉, 수습 기간, 통지 기간, 근무 시간, 보고 관리자, 보너스 자격, 복리후생 자격 날짜. 이러한 열 이름은 단일 출력 테이블의 헤더가 됩니다. AI는 각 계약서를 읽고 페이지의 고정된 위치를 일치시키는 것이 아니라 필드의 의미를 이해하여 각 값을 찾습니다. 열 정의가 배치의 모든 문서에 대해 동일하므로 출력은 이미 병합되어 있습니다 — 하나의 스프레드시트, 50개의 행, 추출 후 조립이 필요 없습니다.

이것이 작동하게 만드는 것은 변동성 문제를 처리하는 것과 동일한 메커니즘입니다: AI는 사람이 읽는 방식으로 계약서를 읽어 "시작 날짜"가 섹션 1의 "개시" 아래에 있든 "근무 조건"이라는 부록에 있든 찾아냅니다. 이 의미론적 접근 방식 — 필드가 어디에 있는지가 아니라 무엇을 의미하는지 이해하는 것 — 은 표준화된 양식을 처리하는 도구와 귀사의 계약서를 귀사가 작성하는 방식대로 처리하는 도구의 차이입니다.

템플릿 기반 추출과의 대비를 이해하는 것이 중요한 이유는 대부분의 문서 도구가 인보이스는 잘 처리하면서 계약서는 제대로 처리하지 못하는 이유를 설명하기 때문입니다. 템플릿 기반 도구는 고정된 레이아웃(예: "인보이스 번호는 항상 (x=200, y=145)에 있습니다")을 학습하고 모든 문서에 그 레이아웃을 적용합니다. 이는 배치의 모든 문서가 동일한 템플릿에서 나온 경우에만 작동하며, 단일 공급업체의 인보이스에는 해당되지만 50명의 서로 다른 지원자의 고용 계약서에는 절대 해당되지 않습니다. 각 계약서는 고유한 구조, 고유한 섹션 번호 매기기, 고유한 필드 레이블을 사용합니다. 위치 기반 접근 방식은 급여가 다른 페이지로 이동한 첫 번째 문서에서 실패합니다. 의미 기반 접근 방식은 급여가 어디에 있는지 신경 쓰지 않습니다. 의미로 찾기 때문입니다.

계약서가 템플릿과 일치하지 않는 경우

단일 배치 채용에서도 한 가지 유형의 문서만 다루는 경우는 드뭅니다. 폴더에는 다음이 포함될 수 있습니다:

• 회사 자체 템플릿에서 서명된 고용 계약서 — 가장 간단한 경우
• 후보자가 이메일로 회신한 카운터 서명된 제안서로, 여백에 손으로 쓴 주석이 있는 경우가 많습니다
• 사무실 스캐너에서 나온 스테이플 자국과 기울어진 텍스트가 있는 종이 계약서의 스캔 PDF
• 문서 끝에 첨부된 DocuSign 또는 Adobe Sign 완료 인증서로, AI가 건너뛰어야 할 페이지가 추가됩니다

단일 문서 워크플로우에서 HR 코디네이터는 문서 유형을 식별하고, 해당 유형에 맞게 필드 검색 전략을 정신적으로 조정한 후 값을 입력합니다. 배치 워크플로우에서는 코디네이터가 이 작업을 50번 반복하면서 I-9 마감을 맞출 수 없습니다. 추출 시스템이 변동을 자체적으로 처리해야 합니다. 이것이 고용 계약 데이터를 Excel로 추출하는 작업을 문서 하나씩 수행하는 것과 배치 규모에 맞게 설계된 추출의 핵심 차이점입니다. 후자는 모든 파일에서 인간의 개입 없이 문서 유형 변동을 흡수해야 합니다. HR 계약 추출이 무엇이고 팀이 언제 도입하는지에 대한 더 넓은 그림은 HR 계약 관리 추출이란 무엇인가를 참조하십시오.

여기서 추출 도구의 설계가 배치 워크플로우의 성공 여부를 결정합니다. 어떤 문서 유형에 어떤 필드가 있는지 지정해야 하는 시스템 — "제안서의 경우 이 6개 필드를 추출하고, 계약서의 경우 이 12개를 추출" — 은 처리를 위해 문서를 먼저 분류해야 하므로 배치 자동화의 목적을 무너뜨립니다. 의미론적 이해를 사용하는 시스템은 동일한 배치에서 모든 문서 유형을 처리합니다: 열의 상위 집합을 정의하면 AI는 각 문서에서 찾은 내용을 추출하고, 필드가 없는 곳은 셀을 비워 둡니다. 통지 기간을 생략한 제안서는 해당 열에 빈 셀만 생성합니다 — 오류도, 수동 재정의도, 사전 분류도 필요 없습니다. 그리고 서명된 제안서만 책상 위에 있는 경우, 제안서를 Excel로 변환은 배치 메커니즘 없이 동일한 열 이름 지정 방식을 적용합니다.

변동 문제에는 배치 규모에서만 드러나는 두 번째 차원이 있습니다: 문서 간 필드 이름 불일치. 한 계약서는 시작 날짜를 "Commencement Date"로 표시합니다. 다른 계약서는 "Effective Date"라고 부릅니다. 세 번째 계약서는 "본 계약에 따른 고용은 ...에 시작됩니다"로 시작하는 문단에 이를 묻어 둡니다. 단일 문서 규모에서는 인간 독자가 이러한 변형을 본능적으로 해석합니다. 배치에서는 추출 시스템이 동일한 작업을 수행해야 합니다. 의미론적 추출은 이를 자연스럽게 처리합니다 — "Start Date"는 위치가 아닌 개념이며, AI는 계약서가 사용하는 라벨과 관계없이 그 표현을 인식합니다. 반면 템플릿 기반 추출은 모든 라벨 변형에 대해 별도의 템플릿이 필요하므로, 배치의 문서 변형 수만큼 설정 비용이 배가됩니다.

원격 및 하이브리드 근무 제도는 이 집합에 또 하나의 변형을 추가합니다 — 원격 근무 계약서를 Excel로 변환은 표준 계약서에 포함되지 않은 근무 위치, 원격 근무일, 장비 조항을 추출합니다.

규정 준수: "대충 맞는" 데이터 입력으로는 충분하지 않은 이유

단 한 명의 신규 채용자의 계약 데이터에 오타가 있을 때 — 급여가 $57,000 대신 $75,000으로 입력된 경우 — 오류는 발견됩니다. 급여 부서가 불일치를 인지하고, HR이 수정하며, 직원은 이를 인지하지 못합니다. 50명의 채용자가 짧은 기간에 처리될 때, 최소한 하나의 오류가 감지되지 않을 확률은 배치의 행이 늘어날수록 증가합니다. 그리고 고용 계약에서 가장 중요한 오류는 급여 경고를 발생시키지 않는 오류입니다: 수습 기간이 90일 대신 60일로 입력되면 복리후생이 한 달 늦게 적용됩니다. 통지 기간이 1개월 대신 2주로 복사되면 계약을 위반하는 해고 절차가 발생합니다. 이러한 오류는 누군가 이의를 제기할 때까지 표면화되지 않습니다 — 몇 달 후에, 데이터 입력 단계로 거슬러 올라가는 문서 기록과 함께 말입니다.

공정근로기준법(FLSA)은 고용주가 직원 보상에 대한 "적절하고 정확한" 기록을 유지하도록 요구합니다. I-9 양식은 고용주가 원본 신분 증명서를 검토하고 문서 제목, 발급 기관, 문서 번호, 만료 날짜를 기록하도록 요구합니다. 어느 규정도 데이터가 수동으로 입력되었는지 기계로 입력되었는지에 관심이 없습니다 — 오직 정확성에만 관심이 있습니다. 잘못된 데이터가 포함된 HRIS는 단순한 행정적 불편이 아니라 규정 준수 위험입니다. 그리고 그 위험은 시간적 압박 속에 입력된 기록 수에 따라 확대됩니다.

일괄 추출이 변화시키는 것은 오류 프로필입니다. 대규모 수동 입력은 무작위 오류 — 오타, 전위, 누락된 필드 — 를 행 전체에 걸쳐 예측 불가능하게 분포시킵니다. 의미론적 추출은 체계적인 행동을 생성합니다: AI가 50개 계약 중 49개에서 "시작 날짜"를 올바르게 식별하면, 단일 누락은 건초 더미 속의 바늘이 아니라 검토 가능한 예외입니다. HR 코디네이터의 역할은 "모든 필드 입력"에서 "예외 검토"로 전환됩니다 — 계약당 몇 분이 아닌 배치당 몇 분이 걸리는 작업입니다. 데이터 입력 운영자에서 예외 검토자로의 전환 — 이것이 일괄 워크플로우를 규모에 맞게 규정 준수 지속 가능하게 만드는 요소입니다.

FAQ

일괄 추출이 디지털 PDF뿐만 아니라 스캔된 종이 계약서에서도 작동하나요?

네. AI는 디지털 PDF와 동일한 방식으로 스캔된 문서를 읽습니다. 페이지의 시각적 레이아웃과 텍스트 내용을 이해하는 방식입니다. 인쇄되고 펜으로 서명된 후 사무실에서 다시 스캔된 계약서는 Word에서 생성되어 PDF로 저장된 계약서와 동일하게 처리됩니다. 스테이플 자국, 기울어진 텍스트, 여백의 손글씨 서명은 추출을 방해하지 않지만, 심하게 손상된 스캔(흐릿한 잉크, 극심한 기울기)은 정확도를 떨어뜨릴 수 있습니다.

같은 배치에 입사 제안서와 고용 계약서를 섞어서 넣을 수 있나요?

네. 열 이름을 한 번만 정의하면 됩니다. 예를 들어, 직원 이름, 직위, 시작 날짜, 급여, 수습 기간, 통지 기간, 보너스 자격 등이 있으며, AI는 각 문서에 포함된 내용을 추출합니다. 입사 제안서에 통지 기간이 없으면 해당 셀은 출력에서 비어 있습니다. 계약서에 요청하지 않은 필드가 포함된 경우 무시됩니다. 문서 유형별 사전 분류가 필요 없습니다.

계약서에서 같은 필드에 다른 표현을 사용하면 어떻게 되나요? 예를 들어 "Start Date" 대신 "Commencement Date"를 사용하는 경우입니다.

AI는 정확한 라벨을 일치시키는 것이 아니라 의미적 의미로 필드를 식별합니다. 계약서에 "Commencement Date," "Effective Date," "Start Date," 또는 "Employment shall begin on"이라고 되어 있어도 AI는 이를 동일한 데이터 포인트로 인식하고 "Start Date" 열로 추출합니다. 특정 위치에서 특정 라벨을 찾는 템플릿 기반 도구는 이러한 변형에서 실패하지만, 의미적 추출은 실패하지 않습니다.

각 추출 행이 올바른 직원에게 추적 가능하도록 하려면 어떻게 해야 하나요?

추출 열에 "직원 이름"을 포함하면 AI가 계약서에서 이를 채우고 해당 이름이 출력 행에 나타나 추적 가능성을 제공합니다. 추가적인 중복성을 위해 일부 팀은 업로드 전에 파일 이름에 지원자 ID를 포함하도록 변경합니다. 그러나 이름 필드만으로도 일반적으로 충분합니다. 고용 계약서는 거의 항상 첫 페이지에 직원의 이름을 눈에 띄게 명시하므로 가장 안정적으로 추출되는 필드 중 하나입니다.

출력물을 Workday, BambooHR, ADP 등 제 HRIS에 직접 넣을 수 있나요?

추출 출력물은 직원당 한 행, 필드당 한 열로 구성된 표 형식의 Excel 또는 CSV 파일입니다. 대부분의 HRIS 플랫폼은 직원 기록에 대한 대량 CSV 가져오기를 지원합니다. 추출 기능은 특정 HRIS와 직접 통합되지는 않지만, 출력 형식은 해당 플랫폼이 기대하는 구조(이름, 직함, 시작일, 급여 및 기타 기록 필드 열)에 맞게 설계되었습니다. 스프레드시트를 다운로드하여 가져오기만 하면 됩니다. 이 과정은 몇 시간이 아닌 몇 초면 충분합니다.

출력물은 파일이 아닙니다. 데이터베이스입니다.

단일 계약 처리를 일괄 처리로 전환하는 것은 정도의 차이가 아니라 종류의 차이입니다. 단일 문서 수준에서 데이터 입력은 회의 사이에 처리하거나 점심 전에 끝낼 수 있는 작업입니다. 그러나 배치 수준에서는 프로젝트가 됩니다. PDF 한 장 두께의 작업에는 존재하지 않는 의존성, 마감일, 규정 준수 위험 및 실패 모드가 수반됩니다. 단일 문서 작업용으로 설계된 도구는 볼륨으로 인해 무너지지 않습니다. 다만 볼륨이 커졌을 때, 애초에 그런 처리를 염두에 두고 설계되지 않았음을 드러낼 뿐입니다.

배치 추출이 바꾸는 것은 작업 자체의 성격입니다. AI가 50개 행을 채우고 여러분이 직접 입력하지 않아도 된다면, HR 코디네이터에게 남는 것은 "더 빠른 타이핑"이 아니라 검토입니다. 예외 사항을 표본 점검하고, 빈칸이 실제로 빈칸인지 누락인지 확인하고, 스프레드시트를 가져온 다음, 실제로 사람이 필요한 업무(온보딩 대화, 복리후생 설명, 문화 소개 등)로 넘어가십시오. 이러한 업무가 처음에 HR에 발을 들이게 한 이유이며, 어떤 AI도 대신할 수 없는 일입니다.

자사 고용 계약서에 직접 사용해 보기