50명 채용은 쉬운 일입니다.
문제는 그들의 데이터를 온보딩하는 거죠.

채용 물결이 불러온 위기는 채용 부족이 아닌 데이터 위기입니다

미국 노동통계국에 따르면 미국에는 944,300명의 HR 전문가가 있습니다. 2024년 기준 그들의 중간 연봉은 72,910달러로, 시간당 약 35달러입니다. HR 코디네이터가 서명된 계약서의 데이터를 Workday, BambooHR 또는 ADP에 다시 입력하는 데 한 시간을 소비할 때마다, 조직은 급여로 약 35달러에 복리후생 비용을 더한 금액을 지출하면서 전략적 가치는 전혀 창출하지 못합니다. 신규 채용 한 명에게 한 시간의 데이터 입력은 반올림 오류에 불과합니다. 하지만 50명이라면 순수 전사 비용만 1,750달러이며, 금요일 오후 4시 30분에 누군가 급여 숫자를 잘못 입력하여 HRIS에 오류가 발생할 위험은 아직 고려하지도 않은 것입니다.

하지만 수동 입력의 비용은 더 작은 문제입니다. 더 큰 문제는 규정 준수입니다. 연방법에 따라 모든 신규 채용은 시작일로부터 3영업일 이내에 I-9 양식(고용 자격 확인)을 완료해야 합니다. 고용주는 신분 증명서를 검토하고, 문서 정보를 기록하며, 진위 여부를 증명해야 합니다. 또한 공정근로기준법에 따라 고용주는 각 직원의 이름, 주소, 직업, 임금 및 근무 시간 기록을 유지해야 합니다. 이는 선택 사항이 아닙니다. 민사 처벌이 따르는 연방 의무 사항입니다.

채용이 한 달에 한두 명씩 꾸준히 이뤄질 때는 규정 준수 부담이 감당할 만한 수준입니다. HR 코디네이터가 계약서 PDF를 열고 1페이지에서 직원 이름을 찾고, 3페이지로 스크롤해 급여를 확인하고, 5.2조항에 숨겨진 수습 기간을 찾아 각 값을 HRIS에 입력합니다. 채용 한 건당 20분이면 끝납니다. 하지만 채용 속도가 빨라지면 상황이 완전히 달라집니다. 신규 고객을 확보하거나, 두 번째 지점을 열거나, 성수기를 맞아 인력을 충원하는 회사는 한 번에 한 명씩 채용하지 않습니다. 20명, 50명, 혹은 100명을 채용합니다. 그리고 입사 제안이 발송된 다음 날 아침, HR은 서명된 PDF 파일이 가득한 폴더와 3일의 마감 기한을 마주합니다. 업무량이 늘어났다고 마감 기한이 줄어들지는 않습니다.

계약 1건과 50건의 차이점

업무량 증가에 대한 본능적인 대응은 "그냥 더 빨리 하자"입니다. 하지만 일괄 처리는 단일 문서 처리를 50번 반복하는 것과 다릅니다. 이는 고유한 과제를 가진 전혀 다른 작업이며, 한 번에 한 건씩 처리할 때는 드러나지 않는 문제점들이 있습니다. "머릿속으로 관리할 수 있는" 수준에서 "시스템이 필요하다"는 임계점을 넘으면 어떤 일이 벌어지는지 살펴보겠습니다.

첫째, 파일 명명 규칙. 세 개의 계약서(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항에 있습니다. 어떤 계약서는 "근무 시작일"을 사용하는 반면, 다른 계약서는 "발효일"이라고 표기합니다. 단일 문서 규모에서는 HR 코디네이터가 이러한 차이를 정신적으로 변환합니다. 일괄 규모에서는 정신적 변환이 오류 발생 가능성이 높아집니다.

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

이 세 가지 문제 — 명명, 변동성, 통합 — 은 배치 처리가 속도 문제가 아니라 설계 문제인 이유입니다. 이를 해결하면 타이핑은 저절로 해결됩니다. 해결하지 않으면 아무리 키 입력 효율을 높여도 격차를 좁힐 수 없습니다.

아무도 쓰지 않는 명명 문제

모든 배치 온보딩 과정에서 HR 코디네이터가 파일 이름만으로는 누구의 계약서인지 알 수 없다는 사실을 깨닫는 순간이 있습니다. Maria Gonzalez의 고용 계약서는 "Final_Signed.pdf"로 도착했는데, 이전 고용주의 HR 포털이 자동으로 이름을 붙였기 때문입니다. 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 마감일을 맞출 수 없습니다. 추출 시스템이 스스로 이러한 차이를 처리해야 합니다. 이것이 계약 데이터 추출을 문서 하나씩 수행하는 방식과 배치 규모에 맞게 설계된 추출 방식의 핵심 차이입니다. 후자는 모든 파일에 사람이 개입하지 않고도 문서 유형의 차이를 흡수할 수 있어야 합니다.

바로 이 지점에서 추출 도구의 설계가 배치 워크플로의 성공 여부를 결정합니다. 어떤 문서 유형에 어떤 필드가 있는지 — "제안서는 이 6개 필드, 계약서는 이 12개 필드를 추출" — 일일이 지정해야 하는 시스템은 처리를 시작하기 전에 문서를 분류하도록 강제하며, 이는 배치 자동화의 목적을 무색하게 만듭니다. 반면, 의미 기반 이해를 사용하는 시스템은 모든 문서 유형을 동일한 배치에서 처리합니다. 사용자가 열의 상위 집합을 정의하면 AI가 각 문서에서 찾은 내용을 추출하고, 해당 필드가 없는 문서의 셀은 비워둡니다. 통지 기간이 없는 제안서는 해당 열에 빈 셀만 생성될 뿐 — 오류도, 수동 재정의도, 사전 분류도 필요하지 않습니다.

분산 문제에는 배치 규모에서만 드러나는 두 번째 차원이 있습니다: 문서 간 필드명 불일치입니다. 한 계약서는 시작일을 "Commencement Date"로 표기하고, 다른 계약서는 "Effective Date"라고 부릅니다. 또 다른 계약서는 "본 계약에 따른 고용은 ...부터 시작된다"는 문단에 이를 숨겨 놓습니다. 단일 문서 규모에서는 사람이 읽으면서 이러한 변형을 직관적으로 해석합니다. 배치에서는 추출 시스템이 동일한 작업을 수행해야 합니다. 의미 기반 추출은 이를 자연스럽게 처리합니다. "시작일"은 위치가 아닌 개념이며, AI는 계약서가 사용하는 레이블과 관계없이 그 표현을 인식합니다. 반면 템플릿 기반 추출은 모든 레이블 변형에 대해 별도의 템플릿이 필요하므로, 배치 내 문서 변형 수만큼 설정 비용이 배가됩니다.

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

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

FLSA는 사용자가 직원 보상에 대한 "적절하고 정확한" 기록을 유지하도록 요구합니다. I-9 양식은 사용자가 원본 신분증을 검토하고 문서 제목, 발급 기관, 문서 번호 및 만료일을 기록하도록 요구합니다. 두 규정 모두 데이터가 수동으로 입력되었는지 기계로 입력되었는지는 중요하지 않습니다. 중요한 것은 정확성입니다. 부정확한 데이터가 포함된 HRIS는 단순한 관리상의 번거로움이 아니라 규정 준수 위험이며, 이러한 위험은 시간적 압박 속에 입력된 기록 수에 비례하여 증가합니다.

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

FAQ

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

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

같은 배치에 제안서와 근로 계약서를 혼합할 수 있나요?

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

계약서에서 동일한 필드에 대해 "Commencement Date" 대신 "Start Date"처럼 다른 표현을 사용하면 어떻게 되나요?

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

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

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

출력물을 Workday, BambooHR 또는 ADP와 같은 제 HRIS에 직접 넣을 수 있나요?

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

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

단일 계약 처리에서 일괄 처리로의 전환은 정도의 차이가 아닙니다. 범주의 차이입니다. 단일 문서 수준에서 데이터 입력은 작업(task)입니다. 회의 사이에 처리하거나 점심 전에 끝낼 수 있는 일입니다. 그러나 일괄 수준에서는 프로젝트가 됩니다. 종속성, 마감일, 규정 준수 위험이 따르며, PDF 한 장 수준에서는 존재하지 않았던 실패 모드가 발생합니다. 단일 문서 작업용으로 설계된 도구는 볼륨 때문에 무너지지 않습니다. 다만 볼륨이 커졌을 때, 애초에 이를 처리하도록 설계되지 않았음을 드러낼 뿐입니다.

일괄 추출이 바꾸는 것은 작업 자체의 본질입니다. AI가 직접 입력하는 대신 50개의 행을 채울 때, HR 코디네이터에게 남는 것은 '더 빠른 타이핑'이 아닙니다. 검토입니다. 예외 사항을 점검하고, 빈칸이 실제 빈칸인지 누락인지 확인합니다. 스프레드시트를 가져옵니다. 그리고 실제로 사람이 필요한 작업, 즉 온보딩 대화, 복리후생 설명, 문화 소개 등 원래 HR을 시작하게 했고 AI가 할 수 없는 일로 넘어갑니다.

내 근로계약서에서 직접 사용해보기