Sasi Pallempati 작성 | N3XGEN 창립자 겸 CEO

공급망 기술 분야에서 일하고 있다면, 다음과 같은 제안을 들어본 적이 있을 것입니다: "EDI는 구식입니다. API로 교체하세요." 그리고 충분히 오래 이 분야에 있었다면, 왜 그 제안이 지난 15년 동안 반복적으로 실패했는지 알고 있을 것입니다. EDI는 단순한 기술이 아닙니다. 그것은 수만 명의 거래 파트너(trading partners) 간의 계약 관계에 내재된 네트워크 효과입니다. EDI를 교체하는 것이 아니라, 이를 처리하는 인프라를 현대화해야 합니다.

저는 23년 이상의 엔터프라이즈 통합(enterprise integration) 경력 중 상당 부분을 B2B 및 EDI 시스템과 함께하며 보냈습니다. 저는 메인프레임 시대의 배치 처리(batch processing), VAN 기반 중계 네트워크, 그리고 현재 세대의 온프레미스 (on-premises) EDI 플랫폼을 목격해 왔습니다. 그리고 저는 차세대 기술을 구축해 왔습니다: 블록체인 기반의 신뢰와 AI 기반 매핑 (AI-powered mapping)을 갖춘 클라우드 네이티브 (cloud-native) EDI 처리 기술입니다. 비즈니스를 유지하는 공급망을 중단시키지 않고 이를 수행하는 방법에 대해 제가 배운 점은 다음과 같습니다.

EDI 현대화가 계속 실패하는 이유

표준적인 현대화 플레이북인 "EDI를 실시간 API로 교체하자"가 실패하는 데에는 세 가지 이유가 있습니다:

거래 파트너의 관성 (Trading partner inertia). 귀사의 기업은 API 기반의 파트너 통합으로 이동할 준비가 되어 있을지 모르지만, 500개의 거래 파트너는 그렇지 않습니다. 그들은 이미 EDI 인프라에 투자했습니다. 그들의 ERP 시스템은 850 구매 주문서(purchase orders)와 810 송장(invoices)을 생성합니다. 귀사가 X12 대신 JSON을 받기를 원한다고 해서 그들이 아웃바운드(outbound) 시스템을 새로 작성하지는 않습니다.

규정 준수 요구사항 (Compliance requirements). 의료(HIPAA X12), 자동차(EDIFACT), 소매(GS1)와 같은 산업에서 EDI 형식은 선호 사항이 아니라 규제 및 계약 요구사항입니다. 이러한 형식을 처리하는 방식은 현대화할 수 있지만, 이를 지원하지 않기로 일방적으로 결정할 수는 없습니다.

배치 처리의 함정 (The batch processing trap). 많은 조직이 EDI를 야간 배치 (overnight batches)로 처리하는데, 이는 그들의 메인프레임 시대 시스템이 그렇게 설계되었기 때문입니다. 그들은 현대화란 이러한 배치 패러다임을 유지하면서 클라우드에서 실행하는 것이라고 가정합니다. 이는 핵심을 완전히 놓친 것입니다. 목표는 더 저렴한 배치 처리가 아니라, 실시간 공급망 가시성 (real-time supply chain visibility)입니다.

성공적인 EDI 현대화의 모습

이를 제대로 수행하고 있는 조직들은 계층적 접근 방식 (layered approach)을 취하고 있습니다. 즉, 외부 EDI 인터페이스를 중단시키지 않으면서 처리 인프라를 현대화하는 것입니다.

레이어 1: 클라우드 네이티브 (Cloud-Native) EDI 처리

EDI 변환 (translation), 검증 (validation), 라우팅 (routing)을 온프레미스 (on-premises) 서버에서 클라우드 네이티브 플랫폼으로 이동하십시오. 이는 다음을 의미합니다:

컨테이너화된 EDI 변환기 (Containerized EDI translators): X12, EDIFACT, TRADACOMS, VDA 형식을 모놀리식 (monolithic) 애플리케이션이 아닌 마이크로서비스 (microservices)로서 파싱할 수 있습니다. 각 변환기는 물량에 따라 독립적으로 확장(scale)됩니다. 예를 들어, 피크 주문 기간 동안 850 구매 주문 (purchase order) 처리는 856 ASN 생성에 영향을 주지 않고 독립적으로 확장될 수 있습니다.

배치 스케줄링 대신 이벤트 기반 라우팅 (Event-driven routing): AS2, SFTP 또는 VAN을 통해 EDI 문서가 도착하면, 즉시 처리 파이프라인을 통해 라우팅되는 이벤트가 트리거됩니다. 문서는 다음 배치 윈도우 (batch window)까지 큐 (queue)에서 대기하지 않습니다. 창고는 구매 주문을 몇 시간이 아닌 몇 초 만에 받게 됩니다.

현대적인 변환 엔진 (Modern transformation engines): 레거시 (legacy) EDI 플랫폼의 노후화가 가장 극명하게 드러나는 부분입니다. 전통적인 EDI 시스템에서 850을 ERP의 구매 주문 형식으로 매핑하는 것은 불투명한 설정 파일을 생성하는 독점적인 비주얼 매퍼 (proprietary visual mapper) 내에서 작업하는 것을 의미합니다. 클라우드 네이티브 플랫폼에서 매핑은 코드 (code)입니다. 즉, 테스트 가능하고, 버전 관리 (version-controlled)가 가능하며, 검토 가능한 코드입니다. 거래 파트너가 850 형식을 변경할 때 (반드시 변경하게 됩니다), 무엇이 변경되었는지 정확히 추적하고, 매핑을 업데이트하고, 과거 데이터를 통해 테스트한 후, 확신을 가지고 배포할 수 있습니다.

N3XGEN에서는 이러한 사용 사례를 위해 특별히 Rust 언어로 매핑 엔진 (mapping engine)을 구축했습니다. 이 엔진은 초당 수천 개의 문서를 처리하는 대용량 EDI 프로세싱 (EDI processing)의 성능 요구 사항을 충족하는 동시에, 루프 언와인딩 (loop unwinding), 조건부 세그먼트 생성 (conditional segment generation), 교차 참조 조회 (cross-reference lookups)와 같이 EDI 형식이 요구하는 복잡한 중첩 변환 (nested transformations)을 지원합니다.

레이어 2: 지능형 파트너 관리 (Intelligent Partner Management)

EDI는 근본적으로 파트너 간의 프로토콜이며, 수백 개의 거래 파트너 관계를 관리하는 것은 EDI 프로그램을 운영하는 데 있어 운영 비용이 가장 많이 드는 부분 중 하나입니다.

각 파트너는 X12 표준에 대한 자신들만의 구체적인 해석인 고유한 구현 가이드 (implementation guide)를 가지고 있습니다. 파트너 A는 856 문서의 REF 세그먼트 내 REF01에 PO 번호를 담기를 원하고, 파트너 B는 REF02에 담기를 원합니다. 파트너 C는 송장 하나당 하나의 ISA 인벨로프 (ISA envelope)를 포함한 810을 전송하는 반면, 파트너 D는 50개의 송장을 하나의 인터체인지 (interchange)로 배치 처리합니다.

AI는 이를 수동 설정 문제에서 패턴 인식 (pattern recognition) 문제로 변화시킵니다. 새로운 거래 파트너를 온보딩 (onboard)할 때, AI는 해당 파트너의 샘플 문서를 분석하고 이를 지식 베이스 (knowledge base)에 있는 기존 파트너 패턴과 비교하여 파트너별 매핑 설정 (mapping configuration)을 생성합니다. 과거에 파트너의 EDI 팀과 2~3주 동안 주고받으며 해결해야 했던 작업이 단 하루 만에 완료될 수 있습니다.

레이어 3: 실시간 공급망 가시성 (Real-Time Supply Chain Visibility)

이것이 바로 결실입니다. EDI 프로세싱이 배치 지향 (batch-oriented) 방식이 아닌 이벤트 드리븐 (event-driven) 방식으로 전환되면, 기존 레거시 인프라 (legacy infrastructure)로는 불가능했던 실시간 공급망 가시성을 확보할 수 있습니다.

구매 주문 (purchase order)이 도착하면 실시간으로 검증 및 변환되고, WMS (창고 관리 시스템)의 재고 할당을 트리거하며, 거래 파트너에게 기능적 확인 응답 (functional acknowledgment, 997)을 생성합니다. 이 모든 과정이 단 몇 초 만에 이루어집니다. 공급망 팀은 배치가 완료되는 다음 날 아침이 아니라, 주문이 도착하는 즉시 주문을 확인할 수 있습니다.

이를 준비가 된 파트너들을 위한 API 기반 통합 (API-based integration)과 결합하면, 프로토콜에 관계없이 일관된 가시성을 제공하는 단일 이벤트 백본 (event backbone)을 갖춘, EDI와 현대적인 API를 모두 지원하는 하이브리드 B2B 플랫폼을 구축할 수 있습니다.

Layer 4: 블록체인 기반 신뢰 (EDIX 프로토콜)

이 지점이 바로 다음의 주요 진화가 일어날 곳이라고 저는 믿습니다. EDI는 암묵적 신뢰 모델 (implicit trust model)을 바탕으로 설계되었습니다. 즉, VAN으로부터 받은 문서가 실제로 주장하는 거래 파트너로부터 온 것이 맞는지, 전송 과정에서 수정되지 않았는지, 그리고 전송 권한이 있는 사람이 보낸 것인지 신뢰하는 방식입니다.

이 신뢰 모델은 수십 년 동안 충분히 제 역할을 해왔습니다. 하지만 공급망이 더욱 복잡해지고 출처 (provenance)에 관한 규제가 엄격해짐에 따라 (특히 제약, 식품 안전, 분쟁 광물 분야에서), "충분히 괜찮은" 수준은 더 이상 충분하지 않게 됩니다.

우리가 Cosmos SDK를 기반으로 EVM 호환성을 갖춘 커스텀 Layer 1 블록체인으로 구축하고 있는 EDIX 프로토콜은 B2B 거래에 암호화 검증 (cryptographic verification)을 도입합니다. 모든 EDI 교환 (interchange)은 온체인 증명 (on-chain attestation)을 받게 됩니다: 누가, 언제, 어떤 콘텐츠 해시(hash)를 보냈는지, 그리고 검증을 통과했는지에 대한 정보입니다. 실제 문서 콘텐츠는 오프체인 (off-chain, 기존 시스템 내)에 머물지만, 신뢰 앵커 (trust anchors)는 불변하며 공개적으로 검증 가능합니다.

이는 거래 파트너들이 블록체인 노드를 운영하거나 기존의 EDI 인프라를 변경할 필요를 요구하지 않습니다. 증명은 처리 계층 (processing layer)에서 이루어집니다. 즉, 귀사의 클라우드 네이티브 EDI 플랫폼이 표준 처리 파이프라인의 일부로 온체인 기록을 생성합니다. 거래를 검증하고자 하는 파트너는 체인을 조회할 수 있고, 원하지 않는 파트너는 이를 완전히 무시할 수 있습니다. 신뢰 계층은 기존 시스템을 방해하는 것이 아니라 추가적인(additive) 요소입니다.

마이그레이션 플레이북 (The Migration Playbook)

현재 온프레미스 (on-premises)에서 EDI를 운영하고 있다면, 다음과 같은 실용적인 접근 방식이 있습니다:

1단계 (1~3개월 차): 기존 시스템과 병행하여 클라우드 네이티브 (cloud-native) EDI 프로세싱을 설정합니다. 저위험 거래처(관계가 원만한 파트너)의 일부를 새로운 플랫폼을 통해 라우팅합니다. 변환 (translation), 라우팅 (routing), 그리고 확인 응답 (acknowledgment) 생성이 올바르게 작동하는지 검증합니다.

2단계 (3~6개월 차): 거래처를 그룹별로 마이그레이션하며, 거래량이 가장 많은 파트너(실시간 프로세싱의 ROI가 가장 큰 파트너)부터 시작합니다. 소수의 나머지 파트너들을 위해 레거시 (legacy) 시스템은 계속 운영 상태를 유지합니다.

3단계 (6~12개월 차): 마지막 파트너들이 마이그레이션됨에 따라 레거시 플랫폼을 폐기합니다. 새로운 관계를 위해 AI 기반의 파트너 온보딩 (onboarding)을 구현합니다. 공급망 운영을 위한 실시간 가시성 대시보드를 배포합니다.

4단계 (12개월 차 이후): 블록체인 증명 (blockchain attestation), AI 기반 이상 탐지 (AI-driven anomaly detection, 예: '이 시기에 이 파트너의 PO 물량이 정상인가?'), 그리고 예측적 공급망 분석 (predictive supply chain analytics)과 같은 고급 기능을 추가합니다.

핵심 원칙: 거래처는 EDI를 송수신하는 방식에 대해 그 어떤 것도 변경할 필요가 없습니다. 모든 현대화 작업은 연결의 귀사 측(your side)에서 이루어집니다.

결론

EDI는 사라지지 않습니다. 형식은 표준화되어 있고, 네트워크 효과는 엄청나며, 규제 요구 사항은 실재합니다. 하지만 EDI를 처리하는 인프라 — 메인프레임 (mainframes), 온프레미스 (on-premises) 서버, 배치 스케줄러 (batch schedulers), 독점적인 매핑 도구 (proprietary mapping tools) — 이 인프라는 교체될 준비가 되었습니다.

EDI 인프라를 현대화하는 조직은 실시간 가시성, 낮은 운영 비용, 빠른 파트너 온보딩, 그리고 AI 및 블록체인 역량과 함께 진화할 수 있는 플랫폼을 확보하게 됩니다. 그렇지 않은 조직은 밤샘 배치 작업을 계속 돌리며 아침이 오기 전까지 아무것도 고장 나지 않기를 기도하게 될 것입니다.