PO 데이터 입력: ERP 템플릿 vs AI 추출
각 방식의 한계점

ERP 템플릿 가져오기 — 좁고 예측 가능한 범위 내에서만 작동합니다

구매 주문이 ERP가 이미 이해하는 형식으로 도착하면 템플릿 기반 가져오기가 적합한 도구입니다. NetSuite의 CSV Import Assistant, SAP의 BAPI_PO_CREATE1 함수, Dynamics 365의 Data Management 작업 영역은 모두 동일한 전제로 작동합니다. 들어오는 데이터가 미리 정의된 열 구조와 일치해야 한다는 것입니다. 열을 한 번 매핑하고 매핑을 템플릿으로 저장하면 동일한 공급업체의 향후 가져오기도 동일한 경로를 따릅니다.

이 방식은 두 가지 시나리오에서 안정적으로 작동합니다. 첫 번째는 EDI 연결 거래 파트너입니다. 공급업체가 ANSI X12 850 문서를 ERP로 직접 전송하면 매핑이 통합에 포함됩니다. 두 번째는 내부 시스템 간 전송입니다. 동일한 ERP 제품군 내에서 요청 모듈에서 구매 모듈로 PO를 이동하는 경우입니다. 두 경우 모두 데이터 구조가 미리 결정되어 있고 안정적입니다.

Dynamics 365는 재사용 가능한 가져오기 매핑 템플릿도 지원합니다. "Invoice #"를 "Invoice Number"에 한 번 매핑하면 매핑이 향후 가져오기에서도 유지됩니다. 이는 실질적으로 유용합니다. 하지만 여기서부터 가정이 쌓이기 시작합니다.

템플릿이 깨지는 지점: 형식 변동, 필드명 불일치, 통제할 수 없는 공급업체

첫 번째 균열은 공급업체 다양성에서 시작됩니다. 40곳의 공급업체로부터 원자재를 구매하는 제조업체의 경우, 5곳은 EDI를 사용하고, 10곳은 조달 포털(Coupa, Ariba)을 통해 구매 주문서를 보내며, 나머지 25곳은 자체 형식의 PDF 구매 주문서를 이메일로 발송합니다. 문제는 바로 이 25곳입니다.

NetSuite의 가져오기 메커니즘은 특정 참조 키를 요구합니다. CSV의 공급업체 이름은 문자 인코딩까지 NetSuite 레코드와 정확히 일치해야 합니다. PDF에서 복사한 줄 바꿈 없는 공백, Windows-1252 인코딩(UTF-8 대신)을 사용하는 유럽 ERP에서 내보낸 악센트 문자가 포함된 이름, 또는 CSV에는 "Acme Corp"로 표시되었지만 NetSuite에는 "Acme Corporation"으로 등록된 공급업체 등 어떤 경우든 "잘못된 엔터티 참조 키" 오류가 발생합니다. 가져오기는 실패하고, 오류 메시지는 어떤 레코드가 실패했는지는 알려주지만 문자열이 일치하지 않은 이유는 알려주지 않습니다.

또한 구조적 불일치 문제도 있습니다. 한 공급업체의 구매 주문서에는 주문 날짜가 "Order Date"로 표시되어 있지만, ERP 템플릿에서는 "PO Date"를 기대할 수 있습니다. 다른 공급업체는 라인 항목을 별도의 테이블에 다른 열 헤더로 분할합니다. 또 다른 공급업체는 CSV로 변환할 수 없는 수기 메모나 도장을 포함하기도 합니다. 이러한 각각의 차이점은 가져오기 전에 수동으로 형식을 다시 지정하거나 별도의 가져오기 템플릿을 사용해야 합니다.

이는 가상의 이야기가 아닙니다. NetSuite 커뮤니티 포럼에서 한 사용자가 묻습니다: "구매 발주서를 CSV로 가져오기 위한 템플릿 예시를 알려주실 분 계신가요? 여러 방법을 시도했지만 성공적으로 가져오지 못했습니다." r/supplychain에서는 한 유통업체가 자사의 ERP를 이렇게 설명합니다: "매우 경직되어 있어서 IT 부서의 도움 없이는 CSV를 대량 업로드할 수 없습니다. 결국 구매팀이 수백 개의 부품 번호를 수동으로 입력하고 있습니다." 이들은 도구를 이해하지 못하는 사용자가 아닙니다. 도구를 정확히 이해하고 있으며, 다양한 공급업체 형식을 처리할 때 이 도구가 오히려 더 많은 불편을 초래한다고 결론 내린 것입니다.

템플릿 기반 가져오기의 구조적 한계는 다음과 같습니다: 새로운 공급업체 형식이 추가될 때마다 필요한 노력이 증가하지만, 이점은 단일 형식이 반복 사용될 때만 나타납니다. EDI를 사용하지 않는 25개 공급업체가 각각 다른 PO 형식을 사용한다면, 25개의 템플릿이 필요합니다. 다음 분기에 형식이 변경되면 업데이트가 필요합니다. 비용 곡선은 결코 평탄해지지 않습니다.

AI 추출은 패턴을 매칭하지 않습니다 — 의미를 읽습니다. 이것이 근본적인 아키텍처 차이입니다

템플릿 매칭은 "이 필드가 페이지 어디에 있나?"라는 질문에 답하고, AI 의미 추출은 "이 필드가 어디에 있든, 어떤 라벨을 달고 있든, 그 의미는 무엇인가?"라는 질문에 답합니다. 이는 서로 다른 메커니즘으로 해결되는 서로 다른 문제입니다.

템플릿 기반 시스템이 CSV를 가져올 때는 열 헤더를 문자 그대로 비교합니다. "PO_Number"는 "PO_Number"와만 일치하고 다른 것은 일치하지 않습니다. AI 기반 시스템이 동일한 문서(PDF, 스캔 이미지, 스크린샷 등)를 처리할 때는 문서를 전체적으로 읽습니다. "Order Ref", "PO #", "Purchase Order Number", "Document No."가 모두 동일한 개념을 가리킨다는 것을 인식합니다. 특정 공급업체가 어떤 라벨을 사용하는지 미리 알 필요가 없습니다.

이는 템플릿 매칭에 비해 미미한 개선이 아닙니다. 완전히 다른 범주의 솔루션입니다. 이를 가능하게 하는 메커니즘은 열 이름 추출입니다. 캡처하려는 데이터 필드("PO 번호", "공급업체명", "라인 합계", "납품일")를 지정하면 시스템이 미리 정의된 템플릿 그리드에 매칭하는 것이 아니라 필드 이름의 의미를 이해하여 문서 내 어디에서든 해당 값을 찾습니다. 공급업체 A의 PDF와 공급업체 B의 스캔 이미지가 각각 별도의 템플릿 없이 동일한 구조화된 출력을 생성합니다.

차이는 경계 지점에서 가장 두드러집니다. 다음 달에 공급업체가 PO 형식에 새 필드를 추가하면 템플릿은 열 매핑이 더 이상 일치하지 않아 깨집니다. AI 추출 시스템은 이를 인지하지도 못합니다. 애초에 위치나 라벨 일관성에 의존하지 않았기 때문입니다. PO가 깨끗한 디지털 파일 대신 창고 바닥에서 찍은 사진으로 도착하면 템플릿 기반 흐름은 먼저 이미지를 텍스트로 변환해야 합니다(보통 OCR을 통해, 비표준 레이아웃에서는 자체 오류율이 발생합니다). AI 시스템은 이미지를 직접 처리합니다.

격차가 벌어지는 다섯 가지 차원 — 그리고 그렇지 않은 경우

두 접근 방식을 추상적으로 비교하는 것보다 조달 워크플로에서 실제로 중요한 차원에서 비교하는 것이 더 유용합니다. 아래는 차원별 분석으로, 각 접근 방식이 유효한 시나리오와 그렇지 않은 시나리오를 설명합니다.

이 비교에서 드러나는 패턴은 "AI가 승리한다"는 것이 아닙니다. 각 접근 방식이 명확히 정의된 적합 영역을 가지고 있다는 것입니다. 템플릿 가져오기는 형식 안정성이 보장되는 곳에서 탁월합니다. EDI는 거래량이 통합 비용을 정당화하는 곳에서 탁월합니다. AI 추출은 형식 다양성으로 인해 템플릿 관리가 비경제적인 곳에서 탁월합니다. 조달 팀이 실제로 고려해야 할 질문은: 공급업체 구성이 실제로 어떤 모습인가입니다.

EDI 850 현실 격차 — 그리고 중견기업 조달에서 좁혀지지 않는 이유

EDI 850은 구매 주문 자동화를 위한 올바른 기술 솔루션입니다. ANSI X12 표준은 정확한 트랜잭션 세트를 정의합니다: PO 헤더용 BEG 세그먼트, 당사자 식별용 N1, 라인 항목용 PO1, 트랜잭션 합계용 CTT. 두 시스템이 동일한 언어를 사용할 때, 교환은 거의 즉각적이고 본질적으로 오류가 없습니다.

하지만 경제성은 규모에 따라 달라집니다. EDI 시장 데이터에 따르면 대기업이 시장 수익의 65.1%를 차지하고 있습니다(Mordor Intelligence, 2025). 중견기업 프로젝트는 맵핑 워크숍, 거래처 인증, 사용자 교육 등을 포함해 가동 전에 10만 달러를 초과하는 경우가 일반적입니다. 중소기업 부문은 12.5%의 연평균 성장률(CAGR)로 성장하고 있지만, 기반이 낮은 상태입니다. 매출 5,000만 달러에 200개 공급업체를 둔 제조업체의 경우, 20개 주요 공급업체에 EDI를 적용하려면 파트너당 750~2,000달러의 설정 비용이 들어 초기 투자액이 15,000~40,000달러에 달하며, 지속적인 유지보수 비용도 발생합니다.

이로 인해 구조적 격차가 발생합니다. 상위 20%의 공급업체는 EDI 투자 가치가 있습니다. 나머지 80%인 소규모 업체, 간헐적 공급업체, 지역 유통업체는 이메일, 포털 PDF, 팩스로 발주서(PO)를 보냅니다. 이 PO들은 현재 누군가의 책상에 도착해 수동으로 입력됩니다. 또한 템플릿 기반 가져오기로 처리하려 했지만, 각각 형식이 달라 실패한 PO들입니다.

Reddit의 한 제조업체 공급업체는 이렇게 말했습니다. "매주 다른 제조업체에서 5~8% 가격 인상을 알리는 40페이지 분량의 PDF나 지저분한 엑셀 시트가 날아옵니다. 당사 ERP는 매우 경직되어 있어 IT 부서의 개입 없이는 CSV를 대량 업로드할 수조차 없습니다." 이는 기술 격차가 아닌, EDI나 템플릿 가져오기로는 해결할 수 없었던 형식 다양성의 격차입니다.

대부분의 팀이 실제로 필요로 하는 하이브리드 접근법

최상의 결과를 얻는 조달 팀들은 한 가지 방법만 고르지 않습니다. 각 방법을 적합한 상황에 맞게 사용합니다:

• EDI 850 — 최상위 공급업체 대상. 이들은 거래량 대부분을 차지하며 이미 EDI 역량을 갖추고 있어 경제성이 맞습니다.
• ERP 템플릿 가져오기 — 내부 이전 및 출력 형식이 안정적이고 ERP 스키마와 일치하는 소수의 외부 공급업체에 사용합니다. 일반적으로 외부 공급업체의 30% 미만입니다.
• AI 추출 — 롱테일 공급업체 대상. PDF, 이메일, 포털 다운로드, 스캔 문서 등으로 발주서를 보내는 업체입니다. 각 PO 변형을 공급업체별 설정 없이 처리합니다. 출력은 "PO 번호", "공급업체", "품목", "수량", "단가" 등으로 컬럼화되어 원본 문서의 필드명과 관계없이 구조화됩니다.

이는 타협이 아닙니다. 각 방식의 비용 곡선과 가치 곡선이 교차하는 지점에 기반한 리소스 할당 결정입니다. EDI는 거래량이 많고 형식이 표준화된 경우 가치가 있습니다. 템플릿은 형식이 안정적인 경우 가치가 있습니다. AI 추출은 형식 다양성으로 인해 다른 두 방식이 비경제적인 경우 가치가 있습니다.

대부분의 중견 시장 조달팀에게 즉각적인 성과는 EDI를 대체하거나 CSV 가져오기를 없애는 것이 아닙니다. 템플릿에 맞지 않아 현재 수동 데이터 입력이 필요한 60-80%의 PO, 즉 공급업체 롱테일의 수동 재입력을 제거하는 것입니다. 이 수동 입력 비용은 분기마다 누적되며, 자동화하기 가장 쉬운 부분입니다.

자주 묻는 질문

AI 추출이 ERP 템플릿 가져오기를 완전히 대체할 수 있나요?

모든 상황에서 그런 것은 아닙니다. 공급업체가 깔끔하고 예측 가능한 CSV 형식으로 지속적으로 PO를 보낸다면, ERP에 저장된 템플릿 가져오기가 효율적이고 안정적입니다. AI 추출은 형식 일관성이 무너지는 곳에서 더 가치를 발휘합니다. 대부분의 조달팀에게 이는 EDI를 사용하지 않는 공급업체 기반의 대부분을 설명합니다. 두 방법은 상호 배타적이지 않고 보완적입니다.

AI 추출이 EDI 850 문서에서도 작동하나요?

EDI 850은 이미 구조화된 형식이므로 추출이 필요하지 않습니다. AI 추출은 EDI를 통해 도착하지 않는 PO(PDF, 스캔 문서, 포털 스크린샷, EDI 네트워크에 없는 공급업체의 이메일 첨부 파일)에 가장 적합합니다.

3방향 매칭은 어떻습니까? AI가 처리할 수 있나요?

AI 추출은 기존 3방향 매칭 워크플로(PO를 입고 및 공급업체 송장과 비교)에 공급할 수 있는 구조화된 데이터(PO 번호, 라인 항목, 수량, 가격)를 출력합니다. 추출 단계 자체가 매칭을 수행하지는 않지만, 추출된 데이터가 더 깔끔하고 일관될수록 AP팀이 수동으로 조사해야 하는 매칭 예외가 줄어듭니다.

AI 추출 시스템은 몇 가지의 다른 PO 형식을 처리할 수 있나요?

형식 수에 실질적인 제한은 없습니다. AI 의미 추출은 템플릿이나 레이아웃별 규칙에 의존하지 않고 각 문서를 독립적으로 처리하기 때문입니다. 10개의 다른 공급업체에서 10개의 다른 레이아웃으로 보낸 10개의 PO는 동일한 열 사양에 대해 동일한 구조화된 출력을 생성합니다. 제약 조건은 형식 다양성이 아니라 문서 품질입니다. 매우 낮은 해상도의 스캔이나 심각한 물리적 손상이 있는 문서는 특정 필드의 추출 신뢰도를 낮출 수 있습니다.

ERP 템플릿 설정과 비교하여 학습 곡선은 어떻습니까?

ERP 템플릿 설정은 ERP의 특정 필드명, 참조 키 유형(NetSuite의 내부 ID, 이름, 외부 ID) 및 종속 레코드의 올바른 가져오기 순서를 이해해야 합니다. AI 추출은 이를 "PO 번호", "공급업체명", "라인 합계" 등 원하는 열만 지정하는 단일 단계로 대체합니다. 공급업체별 구성, 필드 매핑, 가져오기 순서 지정이 필요 없습니다. 단점은 ERP 템플릿이 ERP의 검증 규칙과 직접 통합되는 반면, AI 추출은 로드 전 검토가 필요할 수 있는 데이터를 출력한다는 점입니다.

AI 추출로 수기 작성된 PO를 처리할 수 있나요?

네, 어느 정도 가능합니다. 비전 모델 기반의 AI 추출 시스템은 필기체를 포함한 손글씨 텍스트를 읽을 수 있습니다. 손글씨 인식 정확도는 인쇄된 텍스트보다 낮고 가독성에 따라 달라지지만, 가끔 수기 PO를 보내는 공급업체의 경우 수동 입력 대신 사용할 수 있는 실용적인 대안입니다. 시스템은 별도의 OCR 단계 없이 이미지를 직접 처리합니다.