EDI(전자 데이터 교환)이란 무엇인가요?

역사적으로, 비즈니스 파트너 간에 비즈니스 문서를 교환하려면 종이 문서를 수동으로 전달해야 했습니다. EDI는 문서를 표준화된 디지털 형식으로 변환하고 중개자를 없애 프로세스를 간소화하고 단순화합니다. 문서를 보내거나 받는 데 사람이 필요하지 않고 시스템 간에 자동으로 문서가 오갑니다.

EDI 트랜잭션에서 정보는 한 조직의 컴퓨터 애플리케이션에서 다른 조직의 컴퓨터 애플리케이션으로 직접 이동합니다. EDI 표준은 각 문서의 정보 위치와 순서를 정의합니다. 조직은 EDI를 사용하여 견적 요청서, 대출 신청서, 사전 선적 통지서 등 다양한 문서 및 데이터 유형을 공유합니다.

최근 EDI 시스템에 인공 지능(AI) 툴이 추가되면서 향상된 확장성, 처리 속도 증가, 사전 오류 처리 등 새로운 이점과 기능이 제공되었습니다.

EDI 프로세스는 비즈니스 문서의 생성, 변환, 전송, 검색 및 통합을 포함합니다. 예를 들어, 해당 문서가 자동차 부품 송장이라고 가정해 보겠습니다. 먼저 해당 송장을 만들어야 합니다.

송장 생성에는 스프레드시트, 이메일, PDF 등 다양한 소스에서 데이터를 가져오는 작업이 포함될 수 있습니다. EDI에서는 이러한 작업이 수동 데이터 입력 프로세스가 아닙니다. 일반적으로 타사 애플리케이션인 EDI 변환기는 내부 시스템 및 데이터베이스에서 이러한 데이터를 자동으로 가져올 수 있습니다. 송장 예시에서 EDI 변환기는 내부 스프레드시트를 살펴보고 해당 자동차 부품에 대한 데이터(제품 번호, 가격, 수량 등)를 가져올 수 있습니다.

많은 기업에서 전사적 자원 관리(ERP) 시스템에서 이 데이터를 관리합니다. ERP 시스템은 EDI 번역기와 통합되어 이 데이터를 선택한 표준으로 변환하고 구조화합니다. Cleo, TrueCommerce, MuleSoft와 같이 번역을 처리하는 타사 EDI 서비스 제공업체가 이 프로세스를 지원합니다. (수동 변환은 기술적으로 가능하지만 어렵고 오류가 발생할 수 있습니다.) 인보이스 예시에서, 이러한 자동차 부품 데이터는 인보이스 수신자가 읽을 수 있는 표준 형식으로 변환됩니다.

그런 다음, 다음의 두 가지 일반적인 EDI 문서 교환 유형 중 하나를 사용하여 문서를 전송합니다.

직접 EDI는 일반적으로 보안 통신 프로토콜을 사용하는 인터넷을 통한 컴퓨터 간 연결입니다. 예를 들어, 보안 파일 전송 프로토콜(SFTP)은 암호화뿐만 아니라 다양한 인증 방법을 지원합니다.

부가 가치 네트워크(VAN)에서는 타사 네트워크가 데이터 전송을 관리합니다. VAN 방식은 수신자가 문서를 가져오기 전에 문서를 임시로 저장하는 일종의 파일 스토리지 영역인 메일함을 사용하는 경우가 많습니다. 오늘날 이러한 메일함은 종종 VAN 제공업체가 제공하는 서비스 패키지의 일부인 클라우드에 있습니다. VAN 제공업체는 문서의 변환 및 유효성 검사도 처리할 때가 많습니다.

EDI를 사용하면 여러 가지 프로토콜을 통해 문서를 전송할 수 있습니다. 이러한 프로토콜에는 다음이 포함됩니다.

• AS2(Applicability Statement 2): 암호화뿐만 아니라 디지털 서명 및 전송 알림 등의 기능도 지원하는 일반적인 HTTP 프로토콜입니다. HIPAA를 준수합니다.  
  
  
• SFTP(Secure File Transfer): 보안 셸(SSH) 암호화를 사용하고 사용이 간편하지만 AS2와 동일한 라이프사이클 추적 및 수신 증명을 제공하지 않습니다.
  
  
• FTP(파일 전송 프로토콜): 간단하고 기본적이지만 안전하지 않습니다. 보안상의 한계로 인해 EDI에는 널리 사용되지 않습니다.
  
  
• MFT(Managed File Transfer): FTP의 진화된 버전인 MFT는 엔드투엔드 보안, 감사 추적 및 예약 기능을 제공합니다. 또한 HIPAA와 같은 규정을 준수할 수도 있습니다.
  
  
• SOAP(단순 객체 액세스 프로토콜): XML 기반 메시징 플랫폼인 SOAP는 플랫폼에 구애받지 않지만 레거시 시스템에서 더 오래되고 더 일반적으로 사용됩니다.

각 프로토콜에는 다양한 애플리케이션과 산업에 적합한 장단점이 있습니다. 예를 들어 AS2는 HIPAA를 준수합니다. SFTP에는 중요한 보안 및 인증 기능이 있지만, 이러한 기능은 비전문가에게는 까다로울 수 있습니다.

EDI는 1960년대 대규모 인프라, 자동차 및 군사 프로젝트에 뿌리를 두고 있습니다. 조직과 기관들은 문서를 송수신하는 프로세스를 자동화할 뿐만 아니라, 어쩌면 그보다 더 중요하게 그것들을 표준화하고자 했습니다.

그 이후로 표준 형식은 EDI 관행의 근간이 되어 왔습니다. 발신자와 수신자의 컴퓨터 시스템 모두 문서를 읽고 이해할 수 있어야 하며, 그렇지 않으면 전체 시스템이 무너지게 됩니다.

여러 곳의 조직에서 널리 사용되는 EDI 표준을 만들었습니다. 일부는 특정 산업 전용 표준이고, 일부는 범용 표준입니다. 가장 일반적인 표준은 다음과 같습니다.

미국 국립표준협회에서 만든 범용 표준으로 북미에서 가장 많이 사용됩니다. ASC는 공인 표준 위원회(Accredited Standards Committee)의 약자입니다.

1996년 건강 보험 양도 및 책임에 관한 법률(HIPAA)의 일부로 제정된 이 미국 표준은 의료 데이터 교환에 특별히 초점을 맞춘 ANSI ASC X12의 하위 집합입니다.

Odette는 “자동차 공급망을 위한 유럽 표준화, 서비스 및 네트워킹 플랫폼"입니다. 이 이름은 "유럽에서 원격 전송을 통한 데이터 교환을 위한 기구"의 약자입니다.

UN에서 개발한 EDIFACT(전자 데이터 교환을 위한 행정, 상업 및 운송을 위한 국제 표준)는 산업이나 지역에 관계없이 비즈니스 문서 교환을 용이하게 하기 위한 일련의 국제 표준입니다. 이는 일반적으로 국제 무역에 사용됩니다.

RosettaNet은 하이테크 산업, 특히 글로벌 반도체 산업에서 주로 사용되는 XML 기반 표준 세트입니다.

EDI 트랜잭션은 대규모 전자 상거래 플랫폼에서 소규모 상점에 이르기까지 크고 작은 기업 간에 비즈니스 문서를 교환하는 데 선호되는 수단입니다. EDI 기술은 자동화 및 B2B(Business-to-Business) 통합을 통해 주요 비즈니스 이점을 제공합니다.

EDI는 수작업 프로세스에 의존하던 워크플로를 자동화하여 시간을 절약합니다. EDI는 데이터 검색을 위해 스프레드시트를 뒤지는 반복적이고 지루한 작업과 이메일을 주고받는 과정을 없애줍니다.

부품 회사가 자사 공급망에 있는 부품에 대한 정보를 제조업체에 제공해야 한다고 가정해 보겠습니다. 해당 정보를 수동으로 찾고, 취합하고, 전송한 뒤 제조업체가 이메일을 수신하고 그 데이터를 자체 데이터베이스에 통합하기를 기대하는 대신, 부품 회사는 EDI를 사용하여 이 모든 데이터 교환 프로세스를 자동화할 수 있습니다.

공급망 데이터는 부품 업체의 기록에서 가져와 제조업체로 안전하게 자동 전송되고, 제조업체의 자체 테이블에 추가됩니다. 이 모든 과정은 인력 개입 없이 이루어집니다.

EDI는 자동화를 통해 인건비를 절감하고, 비용이 많이 드는 인적 오류의 빈도를 줄이며, 종이 및 종이 기반 비용의 필요성을 줄이거나 제거할 수 있습니다. 

EDI 데이터 전송은 엄격한 표준화를 통해 오류를 줄여 정보가 비즈니스 프로세스나 애플리케이션에 적용되기 전에 올바른 형식을 갖출 수 있도록 도와줍니다. EDI를 구현하면 오타, 구문 분석이 어려운 필기체, 잊어버린 데이터 필드 또는 잘못 해석된 카테고리와 같은 인적 오류를 제거할 수 있습니다.

EDI 통합은 전자 문서를 다양한 IT 시스템에 통합함으로써 추적성, 관측 가능성 및 보고 기능을 개선합니다. 이러한 통합은 데이터 수집, 가시성 및 분석을 용이하게 합니다.

대규모 조직의 경우 EDI는 다양한 부서와 비즈니스 파트너가 어디에 있든 일관된 표준을 장려합니다. 소규모 조직의 경우 EDI를 준수하면 대기업과 더욱 긴밀하게 데이터를 통합할 수 있습니다. 규모와 형태에 관계없이 모든 기업에서 EDI는 일관된 교환 수단을 제공하며, 조직이 전체 수명 기간 동안 트랜잭션을 추적하고, 각 단계에 걸리는 시간을 측정하고, 오류 없는 감사 추적을 생성하고, 관련 당사자에게 변경 사항이나 문제를 알릴 수 있도록 지원합니다.

EDI 구현은 복잡할 수 있습니다. 정부 규정 및 업계 표준은 위치에 따라 다르고 시간이 지남에 따라 변경될 수 있으며 EDI 네트워크의 각 거래 파트너는 고유한 개별 요구 사항을 가질 수 있습니다.

사내 구축이든 아웃소싱이든, EDI 솔루션을 효과적으로 구현하려면 몇 가지 기본 조건, 기능 및 리소스가 필요합니다. EDI 구현 시 고려 사항은 다음과 같습니다.

이해관계자들은 협력하여 EDI 구현의 목표를 결정해야 합니다. 이러한 협업에는 확장성, 비용, 보안 기능 등 비즈니스 요구 사항에 대해 논의하고 거래 파트너의 EDI 구조를 파악하여 커뮤니케이션의 편의성을 보장하는 것이 포함됩니다.

이러한 유형의 변환 소프트웨어는 이름, 주소, 통화 금액, 부품 번호 및 수량과 같은 필드를 가져와 비즈니스 애플리케이션 형식에서 표준화된 문서로 또는 그 반대로 매핑합니다. 자동차 부품 예시에서 이 소프트웨어는 특정 부품 이름과 모델 번호는 물론 가격, 구매 날짜 등을 포함한 모든 판매를 모니터링합니다.

이러한 기능은 발신자와 수신자가 여러 개의 EDI 트랜잭션을 하나의 “봉투”에 포함시켜 더 효율적으로 전송할 수 있도록 함으로써, 대량의 EDI 메시지 배치를 지원합니다. 이는 여러 통의 편지를 하나의 봉투에 넣어 보내는 것과 비슷합니다. 디엔벨로핑은 수신 측에서 이러한 대량 배치에서 개별 트랜잭션을 추출하는 것을 의미합니다.

배치 봉투를 사용하면 대량의 데이터를 보다 효율적으로 전송할 수 있으며 EDI 프로세스를 간소화할 수 있습니다. 이는 간접비와 비용을 줄여 소매업과 같이 거래량이 많은 조직에 필수적인 이점입니다.  

메시지가 디엔벨로핑된 후에는 여러 그룹에 대해 메시지를 분류하고 적절한 대상에게 전달하기 위한 라우팅 메커니즘이 필요합니다. 메시지를 수신 대상에 맞는 올바른 EDI 형식으로 변환하려면 메시지 변환이 필요할 수도 있습니다.

예를 들어, 자동차 부품 인보이스를 위한 배치 봉투에는 엔진 부품, 내비게이션 소프트웨어, 인테리어 업그레이드 등 서로 다른 유형의 문서를 포함한 여러 부서의 영수증이 들어 있을 수 있습니다. 그러면 수신자의 EDI 소프트웨어는 유형과 대상에 따라 이러한 문서를 분리하여 적절한 목적지로 라우팅할 수 있습니다.

TPA는 약관(예: 규정 준수 및 책임 조항, 계약 기간, 연락처 정보)을 명확히 하고, 비즈니스 문서에 대한 표준을 설정하고, 거래 파트너 간의 커뮤니케이션 및 비즈니스 프로토콜을 정의하는 계약입니다. 공급업체는 데이터 전송에 대한 특정 보안 요구 사항, 기술 사양 또는 기타 세부 사항이 있을 수 있으며, TPA에는 이러한 정보가 상세히 설명되어 있습니다.

AI는 EDI 소프트웨어 분야에서 새로운 가능성을 제시하고 있습니다. 예를 들어, AI는 사기 탐지 및 오류 방지를 강화하고, 과거 비즈니스 거래를 기반으로 실시간으로 학습 및 조정하며, 과거 선례를 기반으로 추세와 잠재적 문제를 모두 예측할 수 있습니다.

자동차 부품 인보이스 예시에서 인보이스에는 일반적으로 한 달에 100~200개의 점화 플러그 판매량이 기록될 수 있습니다. 그 숫자가 갑자기 10,000개로 증가하면 AI가 해당 이상 징후를 감지하고 비정상적인 일이 발생하고 있음을 고객과 판매자에게 자동으로 경고할 수 있습니다. 그리고 그 수치가 꾸준히 300까지 증가한다면, AI 툴은 보안 경보까지는 필요하지 않지만 공급 증가가 필요할 경우를 대비해 판매자에게 알림을 보내야 한다고 판단할 수 있습니다.

일반적으로 대규모 언어 모델과 자연어 처리가 점점 더 정교해지면서 인간의 커뮤니케이션을 분석하고 비즈니스 텍스트 및 이메일과 같은 곳에서 관련 데이터를 추출할 수 있는 잠재력이 커지고 있습니다.

에이전틱 AI는 인간 개입 없이 작동하고 의사 결정을 내리도록 설계된 인공지능의 한 형태로, EDI에 유망한 혁신을 제공합니다. 에이전틱 EDI 시스템은 공급망에서 사기나 오류를 나타낼 수 있는 이상 현상을 모니터링하고 대응하며, 인보이스를 교차 확인하고 문제를 독립적으로 해결할 수 있습니다. AI 에이전트는 반품 승인과 같은 특정 기능도 자동화할 수 있습니다.

애플리케이션 프로그래밍 인터페이스(API)는 소프트웨어 애플리케이션 간에 실시간 데이터를 교환하는 또 다른 방법을 제공합니다. 하지만 EDI와 API 사이에는 주요한 차이점이 있으며, 일반적으로 사용되는 시점도 다릅니다.