제품의 중량은 자재 관리 시스템에 기록되어 있습니다. 재활용 재료 비율은 배합 시스템에 있습니다. 공급업체의 인증서는 네트워크 드라이브에 PDF 파일로 저장되어 있습니다. 제품 패스에는 이 세 가지 정보가 하나의 데이터 레코드에 모두 포함되어야 하며, 바로 여기에 통합 프로젝트의 핵심이 있습니다. 두 시스템의 연결 자체에 있는 것이 아닙니다.
“원활한 ERP 통합”은 흔히 듣게 되는 약속이지만, 실제로는 3개월간의 프로젝트가 뒤따르기 마련입니다. 귀사의 IT 부서가 계약 체결 전에 실제로 어떤 정보가 요구되는지 확인할 수 있도록 저희는 이 가이드를 공개합니다. 이 글에서는 제품 패스가 귀사의 시스템에서 어떤 데이터를 필요로 하는지, 해당 데이터가 세 가지 경로를 통해 당사에 전달되는 방식, 그리고 왜 2주 만에 완료 가능한지 설명합니다.
ERP가 실제로 제공해야 할 사항
제품 패스(DPP)를 생성하기 위해 당사는 제품당 다음 정보를 필요로 합니다:
- 마스터 데이터 - 품목 번호, 명칭, 변형, 중량, 치수, 이미지
- BOM(자재명세서) 데이터 - 수량 및 재활용 재료 비율이 포함된 구성품
- 원산지 데이터 - 생산지, 로트 번호, 생산일
- 환경 데이터 - 단위당 CO2eq, 물 소비량, 에너지 소비량
- 공급업체 데이터 - 누가 어떤 구성품을 공급하는지 (실사 의무 이행용)
이론적으로 귀사의 ERP에는 이러한 데이터가 모두 존재합니다. 하지만 실제로는 자재 관리, 생산, 품질, 공급업체 마스터 등 4~7개의 모듈에 분산되어 있으며, 때로는 환경 데이터를 위한 별도 모듈이 있거나, 조제법 및 부품표를 관리하는 독립된 시스템이 있기도 합니다.
통합에 관한 핵심 질문은 “귀사의 ERP가 DPP에 데이터를 제공합니까?”가 아닙니다. 오히려 “5개의 하위 시스템에 분산된 데이터를 어떻게 하나의 일관된 데이터 세트로 통합할 것인가?”입니다.
세 가지 검증된 방법
방법 1: ERP에서 데이터를 가져오기
최신 ERP(SAP S/4HANA Cloud, Dynamics 365, Odoo)에서는 잘 작동합니다. DPP 공급업체는 ERP의 인터페이스(기술적으로는 OData 또는 REST)를 통해 데이터를 가져옵니다. 일정대로 또는 특정 이벤트에 의해 트리거된 변경 사항만 가져옵니다.
장점: 고객사의 개발 부담이 적으며, 고객사는 읽기 권한만 제공하면 되고, 공급업체가 변환 기능을 구축합니다.
단점: 추가 인터페이스 계층이 없는 구형 SAP ECC 설치 환경에서는 작동하지 않습니다. 누가 어떤 데이터를 읽을 수 있는지에 대한 명확한 규칙이 필요합니다.
방법 2: 변경 사항 전달
귀사의 ERP가 모든 변경 사항을 이벤트로 알리고(SAP Event Mesh, Apache Kafka 또는 RabbitMQ를 통해), DPP 공급업체가 이를 수신합니다.
장점: 거의 실시간으로 처리되며, 시스템 확장성이 뛰어나고, 시스템 간 상호 의존성이 없습니다.
단점: 구성이 까다롭고, 모든 IT 부서가 갖추고 있는 것은 아닌 인프라가 필요합니다. 소규모 기업에는 대체로 과도한 사양입니다.
방법 3: 기존 통합 계층 활용
이미 ERP와 외부 시스템 사이에 ### 통합 계층(Mulesoft, Boomi, Informatica, Azure Data Factory)### 이구축되어 있습니다. 이 계층이 중개자 역할을 합니다. DPP 공급업체는 ERP와 직접 통신하지 않고 이 계층을 통해 통신합니다.
장점: 기존 투자를 활용할 수 있고, 규칙이 안정적이며, 제3자가 ERP에 직접 접근할 수 없습니다.
단점: 통합 계층에 대한 비용이 함께 증가합니다.
구체적인 프로젝트에서 우리가 다르게 접근하는 방식
많은 공급업체가 귀사의 ERP와 직접 연결되기를 원합니다. 저희는 원칙적으로 중간 단계를 추가합니다. 저희 인터페이스는 중립적인 데이터 형식 (JSON 스키마)을 받아들이며, 고객은 원하는 도구를 사용하여 이 형식에 데이터를 채울 수 있습니다. 즉:
- 고객 팀이 익숙한 도구를 사용하여 직접 데이터를 가공할 수 있습니다.
- 당사를 다른 업체로 교체할 수 있습니다. 중립적인 형식은 이식성이 뛰어나기 때문입니다.
- CSV, XLSX, JSON-LD, SQL 형식 및 REST API를 통해 언제든지 전체 데이터를 다시 가져올 수 있습니다.
- 업로드 전에 데이터를 검증하는 임포트 검증 도구를 제공합니다.
전체 형식과 모든 쿼리는 /apidocs에서 OpenAPI 표준에 따른 인터페이스 설명서로 공개되어 있습니다. 계약 체결 전에 귀사의 IT 부서에서 인터페이스를 검토할 수 있으며, 여기에는 예시 쿼리, 오류 응답 및 인증 세부 정보도 포함되어 있습니다.
이 접근 방식을 적용했을 때의 실제 소요 기간:
- 1~2일차: 매핑 워크숍. ERP의 어떤 필드가 DPP의 어떤 필드가 될지 결정합니다.
- 3~5일차: ERP에서 첫 번째 JSON 내보내기 수행, 당사 유효성 검사기를 통해 검증합니다.
- 6~8일차: 오류 수정(누락된 필드, 불일치하는 코딩).
- 9~10일차: 첫 번째 DPP가 가동됩니다.
3개월이 아닌 2주입니다. 핵심은 매핑 워크숍으로, 여기서 데이터 품질이 결정됩니다.
잘못되는 경우: 가장 흔한 함정
여러 시스템에 분산된 제품 마스터 데이터: SAP에는 품목 번호가, PIM에는 이미지와 마케팅 문구가, PLM에는 BOM(자재 명세서)이 있습니다. 어디에도 일관된 전체 그림이 없습니다. 해결책: 프로젝트 시작 전에 어떤 시스템이 어떤 필드에 대해 주 시스템인지 정의하십시오.
PDF 형식의 인증서: 공급업체가 GOTS, OEKO-TEX 또는 REACH 인증서를 PDF 스캔 파일로 제공합니다. 이는 구조화된 데이터 소스가 아닙니다. 해결책: 인증 기관들이 인터페이스를 통한 조회 서비스를 점점 더 많이 제공하고 있습니다(OEKO-TEX가 앞서고, GOTS는 뒤처지고 있습니다). 또는: 수동으로 입력하되, 유효 기간을 함께 기재하여 DPP에 만료된 인증서가 표시되지 않도록 합니다.
처방 비밀 유지: 특히 화장품, 식품 및 제약 분야에서 전체 처방은 영업 비밀입니다. DPP가 이를 공개해야 합니까? 해결책: ESPR의 3단계 모델. 제품 카테고리는 공개되고, 당국은 전체 성분 정보를 확인합니다. 거의 문제가 되지 않지만, 조기에 명확히 해야 합니다.
공급업체 기준 CO₂ 데이터: 귀사의 공급업체는 배치별이 아닌 전체 포트폴리오에 대한 평균값을 제공합니다. 해결책: 당분간은 이를 수용하고, 장기적으로는 공급업체 계약을 조정해야 합니다. ESPR은 특정 기준일 이후부터 제품별 수치를 요구하지만, 현재 관행은 타협안입니다.
현지 언어 버전: 귀사의 ERP에는 독일어와 영어로 된 제품명만 포함되어 있습니다. 27개 EU 국가를 위해서는 더 많은 언어가 필요합니다. 해결책: 용어 데이터베이스를 활용한 기계 번역. 이에 대해서는 별도의 기사가 있습니다.
프로젝트 시작 전에 물어봐야 할 질문들
세 곳의 공급업체에 RFP를 보내기 전에, 내부적으로 다음 질문에 답해 보십시오:
- DPP에 포함될 제품/품목 번호는 몇 개입니까? (10개, 10,000개, 100만 개?)
- 현재 어떤 시스템에 DPP 관련 데이터가 저장되어 있습니까?
- 각 시스템은 어느 부서에서 관리하고 있나요?
- 활용해야 할 통합 계층이 있나요?
- ERP를 통해 이미 작동 중인 인터페이스가 있나요?
이 답변들에 따라 세 가지 방법 중 어떤 것이 귀사에 적합한지 결정됩니다. 또한 프로젝트 기간이 2주일지 6개월일지도 이 답변들에 따라 결정됩니다.
이 게시물에 대한 질문
REST 인터페이스만으로도 충분한가요, 아니면 미들웨어가 필요한가요?
인터페이스만 있으면 충분합니다. 세 가지 패턴은 변환이 이루어지는 위치에서 차이가 있을 뿐, 우리가 받아들이는 데이터의 내용에서는 차이가 없습니다. 우리 인터페이스는 어떤 방식으로 생성되었든 중립적인 JSON 스키마를 받아들입니다. 최신 ERP 시스템에서 가져오는 데이터, 이벤트 스트림, 기존 통합 계층은 모두 동일한 엔드포인트로 연결됩니다. 이미 미들웨어를 운영 중이고, 이를 제3자와의 계약 조건으로 유지해야 할 경우 미들웨어를 사용하는 것이 좋습니다. 현재 미들웨어가 없다면, 제품 인증을 위해 굳이 새로 구매할 필요는 없습니다.
매핑 워크숍에서는 어떤 사항이 결정되나요?
어떤 ERP 필드가 어떤 패스 필드가 되는지, 그리고 여러 시스템이 동일한 값을 보유할 경우 어떤 시스템이 주 소스가 되는지 결정합니다. 이 워크숍은 1일차와 2일차에 진행되며, 데이터 품질에 대한 결정이 코드 개발 단계가 아닌 이 시점에서 이루어지기 때문에 전체 프로젝트의 핵심입니다. 프로젝트를 총괄하는 담당자뿐만 아니라 시스템을 관리하는 담당자들도 함께 참석시켜 주십시오. 마스터 데이터, 생산, 품질, 구매 부서는 한 부서에 속해 있는 경우가 드뭅니다. 그 이후의 모든 과정, 즉 데이터 내보내기, 유효성 검사, 오류 수정 등은 실무적인 작업에 불과합니다.
저희 인증서는 PDF 스캔 파일 형태로만 있습니다. 이걸로 어떻게 해야 할까요?
스캔본은 구조화된 데이터 소스가 아니므로 패스에 사용할 수 없습니다. 두 가지 방법이 있습니다. 인증 운영자가 API 조회 기능을 점점 더 많이 제공하고 있으며, 해당 기능이 없는 경우에는 수동으로 값을 입력하되, 만료된 인증서가 게시된 패스에 남아 있지 않도록 항상 유효 기간을 함께 기재해야 합니다. 수동 입력 작업을 일회성 업무가 아닌 반복적인 업무로 계획하십시오.
서명하기 전에 우리 IT 부서에서 해당 인터페이스를 확인해 줄 수 있을까요?
네. 전체 스키마와 모든 엔드포인트는 /apidocs에서 OpenAPI 사양 형태로 제공되며, 예제 요청, 오류 응답 및 인증 세부 정보도 포함되어 있습니다. 이 모든 정보는 영업 상담을 거치지 않고도 확인할 수 있으므로, 귀사의 통합 팀은 계약이 체결되기 전에 필요한 작업량을 미리 파악할 수 있습니다. 이 단계에서 공급업체가 API를 공개하지 않는다면, 그것 또한 하나의 답이 됩니다.
서비스 제공업체를 변경하면 우리의 데이터는 어떻게 되나요?
함께 진행합니다. 이 인터페이스는 독점 형식 대신 중립적인 JSON 스키마를 받아들이며, 귀하의 전체 데이터는 CSV, XLSX, JSON-LD, SQL 형식이나 REST API를 통해 출력됩니다. 이는 의도된 기능입니다. 데이터를 입력하는 형식은 이식성이 뛰어나므로, 형식을 변경할 때 새로 구축할 필요 없이 단순히 내보내기만 하면 됩니다. 매핑 워크숍에 앞서 각 공급업체에 동일한 질문을 던지십시오. 워크숍이 끝나면 귀하의 필드 이름이 해당 공급업체의 모델에 반영될 것이기 때문입니다.
연결하는 데 실제로 얼마나 걸릴까요?
저희가 지원하는 프로젝트의 경우, 2주 동안 매핑 작업 2일, 저희 검증 도구를 통한 첫 내보내기까지 3일, 오류 수정 3일, 첫 여권 발행까지 2일이 소요됩니다. 시간이 오래 걸리는 부분은 결코 코드가 아니라, 검증기가 발견하는 문제들 - 누락된 필드, 일관성 없는 코딩, 누구도 책임지지 않는 값들 - 입니다. 이 기간을 줄이려 하지 말고 계획에 반영하십시오. 이 단계를 생략하는 프로젝트는 결함까지 함께 공개하게 됩니다.
모든 제품을 한꺼번에 연동해야 하나요?
아니요. 먼저 패스가 필요한 제품들과 소스 시스템부터 시작하세요. 중립적인 스키마는 부분 카탈로그도 전체 카탈로그와 마찬가지로 처리하며, 가져오기 작업은 반복 가능하므로 이후 실행 시 재고가 업데이트됩니다. 이렇게 하면 매핑 워크숍의 규모도 2일 안에 완료할 수 있을 만큼 작게 유지됩니다. 그 이후의 확장은 새로운 프로젝트가 아닌, 단순한 매핑 작업에 해당합니다.
