이 시리즈는 2024년에 Anthropic이 공개한 개방형 표준인 모델 컨텍스트 프로토콜이 화물 API에 어떻게 적용되는지로 시작하여 2026년에 출시된 프레이트 MCP 서버를 철거했습니다., 그리고 하나를 확보하는 방법를 다루었습니다. 이전 3개 부분 모두 에이전트가 화물을 예약하는 시점에서 끝납니다. 이 부분은 그 이후에 일어나는 일이며, 기업들이 실제로 어려움을 겪는 부분입니다. 기록 시스템에 전혀 입력되지 않은 예약은 재무팀이 신뢰할 수 있는 예약이 아닙니다. 따라서 진정한 통합 질문은 "에이전트가 예약할 수 있는가"가 아니라, "에이전트가 장부를 손상시키지 않고 예약을 SAP, Oracle 또는 NetSuite에 다시 기록할 수 있는가"입니다.
마켓플레이스 측에서 이 글을 쓰고 있습니다. 저희는 API를 통해 예약을 노출하고 고객들이 이를 백오피스에 어떻게 연동하는지 지켜봅니다. 예약 호출은 쉬운 절반입니다. 예약 피드백에 엔지니어링 시간이 소요됩니다.
왜 쓰기 환류가 어려운 절반인가
짐 예약은 단 한 번의 만족스러운 행동입니다. 이를 조정하는 것은 적어도 4가지 별도의 의무에 대한 긴 과정입니다. 운송 기록은 재무 부서의 누군가가 인식할 수 있는 기록으로 나타나야 합니다. 해당 비용은 올바른 계정에 게시되어야 합니다. 트럭이 이동함에 따라 상태가 계속 업데이트되어야 합니다. 운송업체 송장이 도착하면 최종 금액이 원래 예상 금액과 맞춰져야 합니다. 이 모든 것은 AI 에이전트가 펜을 쥐고 있을 것이라고 상상하기 훨씬 전에 설계된 시스템에 대한 별도의 기록입니다.
이것을 잘못하면 피해는 조용하지만 실질적입니다. 중복 화물 주문은 발생액을 부풀립니다. 동기화되지 않은 예약은 비용이 부과되지 않은 채로 화물이 이동하게 만듭니다. 업데이트가 중단된 상태는 배차 담당자를 수동 확인 전화로 되돌아가게 만듭니다. 이는 정확히 담당자가 제거해야 할 작업입니다. 담당자는 데모에서는 인상적으로 보이지만 실제 업무에서는 조정 지연을 발생시킵니다.
참조 흐름, 종단 간
벤더 이름을 제외하면 모든 작동 방식은 동일한 경로를 따릅니다. 에이전트는 Claude 또는 Copilot과 같은 어시스턴트 내에서 실행됩니다. 견적을 위해 마켓플레이스 MCP를 호출한 다음 예약을 진행합니다. 예약 호출은 예약 식별자와 구조화된 비용을 반환합니다. 에이전트 또는 그 뒤에 있는 씬 서비스는 해당 결과를 ERP에 운송 기록으로 기록하고, 그 이후부터 ERP는 진실의 원천이 되며 마켓플레이스는 업데이트를 공급합니다.
- MCP 마켓플레이스를 통한 견적 및 예약. 도서 응답에는 총계뿐만 아니라 안정적인 예약 ID와 비용 명세가 포함됩니다.
- ERP에 해당 예약 ID를 스탬핑하여 **화물 기록을 생성**해야 링크가 유지됩니다.
- 배송이 움직임에 따라, 이상적으로는 API를 반복적으로 호출하는 폴링 루프가 아닌 이벤트로부터 동기화 상태를 가져옵니다.
- 비용 정산: 운송업체 청구서가 도착하면 원래 추정치와 최종 금액을 대조하여 정산합니다.
예약 ID는 전체 흐름의 핵심입니다. 이것이 나중에 모든 단계가 속한 레코드를 찾을 수 있게 해주는 값이자, 재시도를 위험 대신 안전하게 만드는 값입니다.
ERP 객체 모델에 운송 예약 매핑
3개의 화물팀이 사용하는 주요 시스템은 눈에 띄게 다른 형식으로 동일한 예약을 처리하므로, 매핑은 통합 계획이 성공하거나 실패하는 곳입니다. 아래의 교차 테이블은 고객이 어떤 필드가 어디로 가는지 물어볼 때 제공하는 것입니다.
| 마켓플레이스 필드 | SAP TM | **넷스위트 / 오라클** |
| 예약 ID | 화물 주문 번호 | 아이템 수령증(Item Receipt) 또는 PO(Purchase Order)의 키 |
| 견적 비용 | 화물 주문 예상 비용 | 예상 도착 비용 |
| 운송장 | 운임 정산 서류 | 실제 도착 원가 (수취 회계) |
| 상태 마일스톤 | 화물 주문 이벤트 | 상품 수령 및 처리 상태 |
비용은 거의 숫자로만 표시되지 않으므로, 세부 내역도 마찬가지입니다. 운송료와 유류비는 예약 시점에 파악되어 예상 운송 비용으로 기록됩니다. 구치, 럼퍼 수수료와 같은 부대 비용은 일반적으로 운송업체 송장에만 표시되므로, 원래 운송 주문이 아닌 정산 시 운송 정산 문서에 기재됩니다.
SAP 운송 관리
SAP TM은 여정을 운송 주문으로, 금전은 별도의 운송 정산 문서로 모델링합니다. 이 분리는 예약 시 운영 기록을 생성하고 송장이 처리될 때 나중에 재정적인 측면을 게시할 수 있도록 해주기 때문에 유용합니다. SAP TM에 기록하는 담당자는 아직 비용이 확정되지 않은 기록에 최종 비용을 강제하기보다는, 예약 시 운송 주문을 생성하고 운송업체 송장을 위해 정산을 남겨두어야 합니다.
오라클과 넷스위트
Oracle과 NetSuite은 구매 및 입고 주기에서 운송비가 운송한 상품에 분산되는 도착 원가로 나타나는 경향이 있습니다. 여기서 에이전트의 역할은 예약과 그 비용을 올바른 구매 주문 또는 품목 입고에 연결하여, 운송 비용이 고아된 비용으로 떠다니는 대신 재고를 따르도록 하는 것입니다. 추정치는 예약 시 게시되고, 실제 비용은 정산 시 업데이트되며, 도착 원가는 그때부터 다시 계산됩니다.
세 가지 모두에서 얻을 수 있는 교훈은 작성하려는 모델을 존중해야 한다는 것입니다. 마켓플레이스 예약은 저희 쪽에서는 하나의 객체입니다. ERP 쪽에서는 운영 기록 하나와 재무 기록 하나, 이렇게 두 개의 레코드가 됩니다. 가장 깔끔한 통합은 이 두 가지를 분리해서 유지합니다.
멱등성: 이중 예약을 유발하는 함정
네트워크 통신이 통화 중에 끊길 수 있습니다. 상담원이 재시도합니다. 보호 장치가 없다면, 해당 재시도는 이미 배송 주문이 있는 화물에 대해 두 번째 화물 주문을 생성하여, 아무도 월말까지 알아차리지 못하는 방식으로 누적이 잘못됩니다. 멱등성이 해결책이며, 금전이 관련된 이상 선택 사항이 아닙니다.
패턴은 간단합니다. 레코드를 생성하거나 확정하는 모든 쓰기 작업에는 멱등성 키가 포함되며, 예약 ID가 자연스러운 값입니다. ERP 연동 서비스는 쓰기를 수행하기 전에 해당 키에 대한 레코드가 이미 존재하는지 확인합니다. 레코드가 존재하면 삽입 대신 업데이트하거나 단순히 기존 레코드를 반환합니다. 재시도는 중복이 아니라 안전한 no-op이 됩니다. MCP를 통해 예약을 노출할 때 이러한 이유로 안정적인 ID를 반환하여, 백오피스가 멱등성 쓰기를 구축하기 위한 신뢰할 수 있는 앵커를 가질 수 있도록 합니다. 패턴은 쓰기 전에 예약 ID를 키로 하여 기존 레코드의 존재 여부를 확인하는 것입니다. 레코드가 존재하면 업데이트하고, 존재하지 않으면 운송 주문을 생성합니다. 첫 번째 실행은 생성하고, 타임아웃 후의 모든 재시도는 동일한 레코드를 업데이트하며, 불안정한 네트워크는 중복 조회 이상의 비용을 발생시키지 않습니다.
경계를 넘나드는 정체성
단독으로 작동하는 에이전트는 사람이 아니며, ERP는 누가 무엇을 변경했는지 알고 싶어합니다. 깔끔한 접근 방식은 통합을 위한 전용 서비스 ID를 사용하는 것이며, 이는 실제 수행하는 몇 가지 작업으로 범위를 제한하는 것입니다. 인간 사용자의 광범위한 권한을 빌리는 에이전트가 아닌, 통합 전용 서비스 ID를 사용하는 것이 더 깔끔한 접근 방식입니다. 적재 주문 생성 및 정산 게시만 가능한 서비스 계정은 공격 범위를 작게 유지하고 감사 추적을 정직하게 만듭니다. 이는 이 시리즈의 보안 부분의 동일한 범위 지정, 최소 권한 사고방식을 ERP 측면으로 가져온 것입니다.
MCP가 깔끔한 쓰기 작업을 위해 제공해야 할 마켓플레이스 기능
단일 통신사 서버는 학습할 모양이 하나뿐이므로 예약 객체에 대해 모호할 수 있습니다. 고객이 여러 통신사를 하나의 원장에 통합하고 있기 때문에 마켓플레이스 서버는 그렇게 할 수 없습니다. 3가지 점이 차이를 만듭니다.
- 안정적인 예약 ID는 주문의 전체 수명 주기 동안 변경되지 않으므로 ERP 레코드가 모든 업데이트를 통해 계속 연결됩니다.
- 구조화된 비용 명세, 단일 총액이 아닌, 그래서 운송비, 유류비, 부대 비용을 올바른 계정에 연결할 수 있고 정산 단계에서 대조할 수 있는 근거가 있습니다.
- 상태를 이벤트로, ERP가 몇 시간 동안 발생하지 않을 수 있는 변경 사항을 폴링하는 대신 마일스톤이 발생하면 이를 알 수 있도록 합니다.
이 세 가지 요소가 존재할 때 ERP 쓰기 백은 대부분 결정론적입니다. 이들이 누락되면 모든 고객이 동일한 취약한 접착제를 재구축하게 되고, 상담원의 예약은 편리한 위장으로 둔갑한 조정 문제가 됩니다.
원장에 에이전트를 연결하기 전 최종 점검표
- 마켓플레이스 예약 ID를 모든 ERP 쓰기에 연결하고 해당 ID를 멱등성 키로 사용하십시오.
- 예약 시간에 운영 기록을 생성하고, 송장이 처리된 후에만 재정 결산을 게시하십시오.
- 비용 분석 결과를 한 줄에 총액으로 합쳐서 넣기보다는 각 계정에 신중하게 연결하세요.
- 가능하다면 이벤트를 통해 드라이브 상태를 가져오고, 합리적인 간격으로 폴링으로 대체합니다.
- 통합에 사람의 광범위한 로그인이 아닌 자체 범위 지정된 서비스 ID를 부여하십시오.
- 정산 시 추정치를 실제치와 대사하고, 이를 조용히 덮어쓰는 대신 차이를 표시하세요.
이 중 어느 것도 에이전트만의 고유한 특징은 아닙니다. 이미 시스템 간 화물 통합에 필요한 규율입니다. 에이전트는 단순히 예약을 더 빠르게 할 뿐이며, 이는 백워드도 그에 맞춰 똑같이 안정적이어야 함을 의미합니다.
자주 묻는 질문
AI 에이전트가 SAP 또는 NetSuite에 직접 화물 예약을 작성할 수 있나요?
네, ERP 자체 API와 scoped service identity를 통해, marketplace booking id를 idempotency key로 사용하여 재시도 시 중복 생성을 방지할 수 있습니다. 에이전트가 쓰기를 제안하지만, 얇은 서비스가 ERP에 대해 이를 수행해야 논리가 테스트 가능하게 유지되고 권한이 제한적으로 유지됩니다.
ERP 쓰기 환류에서 가장 자주 발생하는 오류는 무엇인가요?
중복 레코드의 경우 가드되지 않은 재시도를 통해 발생하며, 통제되지 않는 비용은 통합이 추정치를 게시하고 항공사 송장과 대사하는 것을 잊기 때문에 발생합니다. 이 두 가지 모두 안정적인 예약 ID에 쓰기를 고정하고 운영 및 재무 단계를 분리하여 해결됩니다.
예약 ID가 왜 그렇게 중요할까요?
마켓플레이스와 원장의 연결고리입니다. 모든 상태 업데이트, 문서, 정산이 해당 ID를 통해 기록되며, 재시도를 안전하게 만드는 멱등성 키 역할도 겸합니다. 안정적인 ID가 없는 예약 객체는 백오피스에서 추측하게 만들며, 이는 중복 및 미정산 비용 발생의 원인이 됩니다.
상태 업데이트는 폴링 방식을 사용해야 할까요, 아니면 푸시 방식을 사용해야 할까요?
이벤트가 지원되는 마켓플레이스로 푸시하면, 폴링이 실제 마일스톤보다 뒤처지거나 API를 과도하게 호출하여 최신 상태를 유지하게 됩니다. 실용적인 통합은 중요한 순간에 이벤트를 사용하고, 폴링 간격은 대체 수단으로만 사용합니다.
이것으로 2026년 현재 MCP 4부작 시리즈가 완성되었습니다. 만약 이 페이지에 처음 오셨다면 프로토콜 총람로 시작하여, 해체에서 출하된 서버를 확인하고, 보안 안내로 마무리하세요.