라이브러리로 돌아가기
활용 사례

에이전트가 주문을 낼 때: 에이전트 결제가 B2B 조달 루프를 닫는 방법

최종 업데이트: 2026年7月30日

직원 500명의 산업 유통업체가 RFQ 수락에서 지급 조정까지 5번의 수동 인계를 거쳐 14일이 걸린다. procurement 팀은 이 사이클의 전반——RFQ 생성, 견적 비교, should-cost 분석 실행——을 잘 다루게 되었다. 사이클의 후반이 시간과 오류가 축적되는 곳이다: 주문 발행, 지불 승인, 인보이스 조정, 각 인계가 지연과 새로운 장애 표면을 추가한다. 결제 API는 버튼을 클릭하는 인간을 위해 만들어졌지 의사결정을 내리는 에이전트를 위해 만들어지지 않았으므로, 전반이 자동화되어도 후반은 수동으로 남아 있었다. 이 격차는 좁혀지고 있다——Mastercard, Stripe, x402 프로토콜이 agent-native 결제 레일을 구축 중——자사 에이전트를 이 레일에 연결하는 팀은 sourcing 절반뿐 아니라 전체 procure-to-pay 사이클을 압축할 수 있다.

핵심 요점

  • x402는 첫 해에 590,000명의 구매자와 100,000명의 판매자를 아울러 1억 6,900만 건의 결제를 처리했다——에이전트 결제의 첫 생산 규모 데이터 포인트로, 에이전트 개시 거래가 데모가 아닌 볼륨에서 작동함을 증명(Stripe, 2026).
  • Mastercard는 Adyen, Stripe, Cloudflare, Coinbase를 포함한 30개 이상의 산업 파트너와 Agent Pay를 출시——결제 네트워크는 인간 대면 API를 개조하는 것이 아니라 에이전트 네이티브 레일을 구축하고 있다(Mastercard, 2026년 6월).
  • 1,200개 활성 SKU와 85개 공급업체를 보유한 중견 산업 유통업체는 RFQ 수락부터 결제 조정까지 14일이 소요된다——조달, 재무, 미지급금 간 5개의 수동 핸드오프가 각각 지연과 오류 표면을 추가.
  • 조달 리더의 90%가 12개월 이내에 AI 에이전트를 구현하거나 계획 중——하지만 대부분의 조달 AI는 견적 비교에서 멈추고 주문과 결제 절반은 수동으로 남겨둔다(Suplari, 2026).
  • 에이전트 결제 프로토콜을 통해 주문을 내고 결제를 승인하는 에이전트——결제 단계에서 인간의 승인 유지——는 조달-결제 주기를 14일에서 3일로 단축하고 조정 예외를 68% 감소시킨다.
  • x402 영수증 확장은 결제가 정산되었음을 증명하지만 어떤 스크리닝 버전이 실행되었는지는 증명하지 않는다 — IETF의 action_refx402-retention-chain 드래프트가 Settlement-Action Binding(binding_ref)과 Policy Binding(policy_bound_ref)으로 실행 증명 격차를 닫는다. 모든 감사자가 재계산 가능. 두 영수증을 조합하여 규제된 조달의 완전한 감사 체인을 제공.

500인 산업 유통업체의 운영 VP는 조달 문제가 소싱이 아님을 안다. 팀은 RFQ 생성과 견적 비교에 능숙해졌다——도구가 존재하고 프로세스가 정의되어 있다. 문제는 그 다음에 일어나는 것이다. 견적이 수락된 후, 주문을 내고, 결제를 승인하고, 청구서를 수령하고, 조정을 완료해야 한다. 조달-결제 주기의 이 후반이 시간이 가고 오류가 누적되는 곳이다.

에이전트에 대한 대화는 주기의 전면에 집중해왔다: RFQ 생성, 공급업체 비교, 목표 원가 분석. 주기의 후면——주문 배치, 결제 승인, 청구서 조정——는 결제 API가 버튼을 클릭하는 인간을 위해 설계되었고 의사결정을 내리는 에이전트를 위해 설계되지 않았기에 수동으로 남아있었다. 그 격차는 닫히고 있다. Mastercard는 2026년 6월 30개 이상의 파트너와 Agent Pay를 출시했다. x402는 첫 해에 1억 6,900만 건의 결제를 처리했다. Stripe는 Mastercard와 Visa 양쪽에서 에이전트 결제 네트워크 토큰을 프로비저닝하고 있다. 결제 네트워크는 에이전트 네이티브 레일을 구축하고 있으며, 에이전트를 그 레일에 연결하는 B2B 조달 팀은 소싱 절반뿐 아니라 전체 조달-결제 주기를 압축할 수 있다.

이 글은 AI 에이전트 스택——NetSuite와 BigCommerce에 대한 MCP 커넥터 모듈, 병렬 서브태스크용 A2A 태스크 위임, 주문 배치와 결제 승인용 에이전트 결제 프로토콜——이 중견 유통업체의 조달 루프를 어떻게 닫는지 정리한다. 인간이 결제 승인 결정을 유지한다. 에이전트는 그 결정을 빠르고 충분히 정보에 기반하게 만드는 작업을 수행한다.

문제: 14일, 5개 핸드오프, 23% 조정 예외

이 유통업체는 ERP에 NetSuite, B2B 이커머스에 BigCommerce, 청구서 매칭에 NetSuite 내 수동 미지급금 프로세스를 운영한다. 전형적 보충 주문의 조달-결제 주기는 다음과 같이 작동한다:

  1. RFQ 수락(0일차). 조달이 낙찰 공급업체 견적을 선택한다. 구매자가 NetSuite에서 구매 주문을 생성하고 공급업체에 이메일로 보내며 확인을 기다린다. 시간: 1일. 핸드오프: 조달에서 공급업체로.

  2. 공급업체 확인(1-2일차). 공급업체가 구매 주문을 확인하고 상품을 출하하며 이메일 또는 EDI로 청구서를 보낸다. 청구서는 구매 주문과 다른 형식으로 도착한다——다른 품목 설명, 다른 측정 단위 코드, 백오더 분할로 인한 다른 수량. AP 담당자가 수동으로 청구서를 NetSuite에 입력한다. 시간: 1-2일. 핸드오프: 공급업체에서 AP로.

  3. 쓰리웨이 매치(3-5일차). AP가 쓰리웨이 매치를 실행한다: 구매 주문 대 수령 영수증 대 청구서. 1,200개 활성 SKU와 85개 공급업체에서 23%의 청구서가 매치에 실패한다——보통 청구서의 측정 단위가 구매 주문과 일치하지 않거나 공급업체가 한 품목을 두 출하로 분할했기 때문. 각 예외는 AP가 공급업체에 연락하고 차이를 확인하고 기록을 수동으로 조정해야 한다. 시간: 2-3일. 핸드오프: AP에서 공급업체로 그리고 돌아옴.

  4. 결제 승인(6-8일차). 컨트롤러가 매치된 청구서를 검토하고 결제 조건(net 30, net 45, 조기 결제 할인)을 확인하며 결제를 승인한다. 10,000달러를 초과하는 청구서에는 운영 VP의 2차 서명이 필요하다. 컨트롤러가 결제 배치를 인쇄하고 VP가 서명하며 AP가 ACH 또는 송금으로 NetSuite에서 결제를 처리한다. 시간: 2-3일. 핸드오프: AP에서 컨트롤러에서 VP로.

  5. 조정(9-14일차). AP가 결제를 청구서와 조정하고 NetSuite에서 기록을 닫는다. 예외——결제 금액 불일치, 누락된 조기 결제 할인, 공급업체 주소 변경——는 해결에 2-5일이 더 걸린다. 시간: 3-5일. 핸드오프: AP에서 재무로.

전체 주기: 14일, 5개 핸드오프, 23% 예외율. 월 400건의 보충 주문을 처리하는 유통업체에게 그것은 92건의 예외 청구서이며 각각 30-60분의 AP 시간을 소비한다. AP 팀은 예외 해결에 주당 46시간을 보낸다——풀타임 직위의 절반 이상.

Suplari의 90% 도입 수치는 실제지만, Art of Procurement 2026 조사의 4% 규모 배포 수치가 여기서 중요하다. 팀에는 소싱과 비교를 수행하는 에이전트가 있다. 주문과 결제를 수행하는 에이전트는 없다. 결제 측이 인간 승인 워크플로를 위해 구축된 승인 제어를 갖춘 재무 시스템에 연결을 요구하기 때문이다. 에이전트 개시 거래가 아닌.

에이전트 오케스트레이션 해결책: 에이전트 결제로 루프 닫기

루프를 닫는 패턴에는 네 가지 구성 요소가 있다: 에이전트를 NetSuite(ERP), BigCommerce(이커머스), 공급업체 커머스 API에 연결하는 MCP 커넥터 모듈, 하나의 오케스트레이팅 에이전트가 서브태스크를 병렬로 디스패치할 수 있는 A2A 태스크 위임, 에이전트가 에이전트 네이티브 레일을 통해 주문을 내고 결제를 승인할 수 있는 에이전트 결제 프로토콜, 그리고 결제 단계에서의 휴먼 인 더 루프 승인.

워크플로, 단계별:

  1. 커머스 API를 통한 주문 배치. RFQ가 수락된 후, 오케스트레이팅 에이전트가 MCP 모듈을 통해 NetSuite에서 구매 주문을 생성하고 공급업체의 커머스 API로 보낸다. BigCommerce ACP(Agent Commerce Protocol, OpenAI/Stripe Apache 2.0 표준)상의 공급업체에는 에이전트가 구조화된 주문 메시지를 보내고 공급업체의 에이전트가 자동으로 수신하여 처리한다. ACP를 지원하지 않는 공급업체에는 에이전트가 EDI 850 또는 구조화된 PDF 첨부가 있는 이메일로 폴백한다. 에이전트는 공급업체 확인을 기다리지 않는다——커머스 API를 통해 주문 상태를 추적하고 24시간 후 미확인을 플래그한다.

  2. 수령 및 청구서 캡처. 상품이 도착하면 에이전트가 NetSuite에서 수령 영수증을 읽고(창고 관리 MCP 모듈을 통해) 공급업체의 커머스 API 또는 EDI 피드에서 청구서를 캡처한다. 에이전트는 청구서를 구매 주문과 동일한 스키마로 정규화한다——품목, 측정 단위, 수량을 매핑. 수동 쓰리웨이 매치의 23% 예외율은 하락한다. 에이전트가 공급업체에 이메일을 보내는 대신 측정 단위 변환과 백오더 분할을 프로그래밍 방식으로 처리하기 때문.

  3. 자동화된 쓰리웨이 매치. 에이전트가 쓰리웨이 매치를 실행한다: 구매 주문 품목 대 수령 영수증 대 청구서. 프로그래밍적 차이——측정 단위 변환, 백오더 분할, 가격 층 조정——는 자동으로 해결된다. 판단을 요하는 차이——무단 대체, 5% 초과 수량 부족, 계약 범위 외 가격 변경——는 AP 검토를 위해 플래그되고 차이의 구조화된 요약과 에이전트의 권장 해결책이 첨부된다. 인간은 전체 매치가 아닌 플래그된 예외를 검토한다.

  4. 인간 승인을伴는 결제 승인. 에이전트가 결제 배치를 준비한다: 매치된 청구서, 결제 조건, 조기 결제 할인 자격, 총 결제 금액. 승인 임계값(이 예에서 10,000달러) 미만의 청구서에는 컨트롤러가 원클릭 승인 프롬프트를 받는다——에이전트는 이미 매치를 검증하고 조건을 확인하며 조기 결제 할인을 계산했다. 임계값 초과 청구서에는 운영 VP가 전체 증거 체인이 첨부된 동일한 프롬프트를 받는다. 인간이 승인한다. 에이전트가 적절한 레일을 통해 결제를 실행한다:

    • Mastercard Agent Pay: 카드 기반 B2B 결제용. 에이전트는 Mastercard에서 프로비저닝된 에이전트 결제 네트워크 토큰을 보유한다.
    • x402: 스테이블코인 기반 결제용. 특히 ACH를 사용할 수 없고 송금 수수료가 높은 국제 공급업체용. Coinbase Base상의 x402 결제는 약 200ms.
    • Stripe 에이전트 결제 토큰: Stripe상의 공급업체용. 에이전트는 Stripe의 에이전트 결제 커머스 인프라를 통해 프로비저닝된 Visa 또는 Mastercard 에이전트 결제 토큰을 보유한다.
    • ACH 또는 송금: 아직 에이전트 결제 레일에 없는 공급업체용. NetSuite의 결제 모듈을 통해. 에이전트는 AP가 실행할 결제 파일을 준비한다.
  5. 조정. 에이전트가 결제를 청구서와 조정하고 NetSuite에서 기록을 닫는다. 결제 금액, 획득된 조기 결제 할인, 공급업체 주소 확인——모두 프로그래밍 방식으로 검증된다. 조정 예외는 청구서의 7%로 하락한다(이전 23%). 남는 예외는 형식 불일치가 아닌 진짜 차이(공급업체 가격 변경, 누락된 크레딧 메모).

A2A 프로토콜이 병렬성을 가능하게 한다. 오케스트레이팅 에이전트가 주문 배치, 청구서 캡처, 쓰리웨이 매치, 결제 준비를 전문 에이전트에 위임한다——각각 하나의 도메인을 소유. 컨트롤러와 VP는 4개의 에이전트를 보는 것이 아니라, 전체 증거 체인을 동반한 하나의 결제 승인 프롬프트를 본다.

수동 조달-결제 주기 대 에이전트 결제를 동반한 에이전트 오케스트레이션:

수동 조달-결제 대 에이전트 결제를 동반한 에이전트 오케스트레이션 수동: 14일, 5개 핸드오프 0-1일차 구매자가 구매 주문 생성, 공급업체에 이메일 1-2일차 공급업체 출하, AP가 수동으로 청구서 입력 3-5일차 쓰리웨이 매치(23% 예외율) 6-8일차 컨트롤러 검토, VP 서명, AP 처리 9-14일차 조정, 예외 해결 14일 23% 예외 · 주당 46시간 AP 예외 시간 에이전트: 3일, 인간이 결제에서 서명 1 에이전트가 커머스 API로 구매 주문 생성(ACP) MCP 모듈에서 NetSuite + 공급업체 API 2 에이전트가 청구서 캡처, 스키마 정규화 자동 측정 단위 + 백오더 해결 3 자동 쓰리웨이 매치(7% 예외) 판단 예외는 AP 검토에 플래그 4 인간이 결제 승인(원클릭) Agent Pay / x402 / Stripe 에이전트 결제 토큰 5 에이전트가 조정, 기록 닫기 자동 결제 + 할인 검증 3일 7% 예외 · 주당 14시간 AP 예외 시간 79% 더 빠른 주기(14일에서 3일) 70% 더 적은 예외(23%에서 7%) 32시간 주당 절약된 AP 시간 5개 핸드오프가 1개 승인으로 · ideabosque.com/library

에이전트 결제 환경: 레일이 실제로 하는 일

결제 네트워크는 하나의 에이전트 결제 표준을 구축하는 것이 아니다. 세 개를 구축하고 있으며 경쟁하고 있다. 차이를 이해하는 것은 어떤 레일에 먼저 연결할지 선택하는 조달 팀에게 중요하다.

Mastercard Agent Pay. 2026년 6월 Adyen, Stripe, Cloudflare, Coinbase, Braintree, Checkout.com 등 30개 이상의 산업 파트너와 출시. Agent Pay는 AI 에이전트가 프로비저닝된 에이전트 결제 네트워크 토큰을 보유할 수 있게 한다——카드 소유자의 은행이 설정한 한도와 제한에 따라 Mastercard 레일상에서 결제를 개시하도록 에이전트를 인가하는 자격 증명. 에이전트는 카드 번호를 보유하지 않는다. 발행 은행이 취소할 수 있는 토큰을 보유한다. B2B 조달에서 이것은 이미 카드 결제를 수용하는 공급업체에 맞는 레일——유통업체의 에이전트가 컨트롤러가 수동 카드 결제에 사용할 것과 동일한 Mastercard 네트워크를 통해 지불하지만 수동 단계 없이.

x402. 에이전트 커머스용 개방 결제 프로토콜로, 스테이블코인 결제상에 구축. x402는 첫 해에 590,000명의 구매자와 100,000명의 판매자를 아울러 1억 6,900만 건의 결제를 처리했다——에이전트 개시 거래의 첫 생산 규모 데이터 포인트. Amazon은 x402를 Bedrock AgentCore Payments에 통합했고, Coinbase Base상의 결제는 약 200ms. B2B 조달에서 x402는 ACH를 사용할 수 없고 송금 수수료(거당 25-50달러)가 마진을 침식하는 국제 공급업체에 맞는다. x402를 통한 스테이블코인 결제는 가스비로 센트의几分の一.

Stripe 에이전트 결제 토큰. Stripe는 Mastercard와 Visa 양쪽에서 에이전트 결제 네트워크 토큰을 프로비저닝하고 있으며, Stripe에 연결된 유통업체가 어느 카드 네트워크를 통해서든 에이전트 개시 결제를 라우팅할 수 있음을 의미. Stripe의 에이전트 결제 커머스 인프라는 ACP(Agent Commerce Protocol)도 지원하며, BigCommerce가 채택한 OpenAI/Stripe Apache 2.0 표준. BigCommerce ACP상의 공급업체는 동일한 프로토콜을 통해 에이전트 개시 주문과 결제를 수신할 수 있어, 하나의 거래에서 주문과 결제의 루프를 닫는다.

Forbes는 3자 경쟁을 보도한다: Visa Trusted Agent, Mastercard Agent Pay, Coinbase x402. 조달 팀은 하나를 고를 필요가 없다. 에이전트는 공급업체가 수용하는 결제 방법, 거래 금액, 각 레일의 비용에 기반해 적절한 레일로 결제를 라우팅한다. 인간이 라우팅 규칙을 설정한다——카드 결제의 최소 거래 금액, 국제 공급업체의 우선 레일, 조기 결제 할인 임계값. 에이전트는 그 규칙 내에서 실행한다.

결과: 비즈니스에 무엇이 바뀌는가

지표 수동 워크플로 에이전트 결제를 동반한 에이전트 오케스트레이션
조달-결제 주기 시간 14일 3일
수동 핸드오프 5 1(결제 승인)
쓰리웨이 매치 예외율 23% 7%
AP 예외 해결 시간 주당 46시간 주당 14시간
조기 결제 할인 획득 적격 청구서의 41% 적격 청구서의 94%
청구서 데이터 입력 수동(AP 담당자) 자동화(에이전트가 커머스 API를 통해)
결제 승인 인쇄, 서명, 처리(2-3일) 증거 체인을 동반한 원클릭 프롬프트(분)

14일에서 3일로의 압축이 헤드라인 숫자. 그 아래의 운영 변화가 더 중요하다.

23% 예외율은 7%로 하락한다. 대부분의 예외가 판단이 아닌 형식 불일치, 측정 단위 변환, 백오더 분할이며 에이전트가 프로그래밍 방식으로 해결하기 때문. 남는 7%는 진짜 차이: 무단 대체, 계약 외 가격 변경, 누락된 크레딧 메모. 이들은 형식 오류 대기열에 묻히는 대신 AP의 전면적 주의를 받는다.

조기 결제 할인 획득은 41%에서 94%로 도약한다. 에이전트가 각 청구서의 할인 마감일을 추적하고 마감 전에 결제 승인을 준비하기 때문. 월 800만 달러의 조달-결제 볼륨에 평균 1.5% net-10 할인에서 41%와 94% 획득의 차이는 잃는 것이 아닌 획득하는 할인으로 월 약 64,000달러. 연간 768,000달러——에이전트 스택 비용을 여러 번 지불하는 숫자.

AP 팀의 예외 해결 시간은 주당 46시간에서 14시간으로 하락. 32시간 해방——직위를 제거하기 위해서가 아니라 AP를 공급업체 관계 관리, 크레딧 메모 회수, 계약 컴플라이언스 감사로 재지향하기 위해. 팀이 형식 불일치에 묻혀 보이지 않았던 작업이 가시화된다.

인간은 결제 승인 지점에 남는다. 컨트롤러와 VP는 전체 증거 체인을 동반한 원클릭 프롬프트를 본다: 구매 주문, 수령 영수증, 청구서, 쓰리웨이 매치 결과, 조기 결제 할인 계산, 결제 레일 추천. 그들은 승인하거나 질문한다. 에이전트는 그 승인 없이 결제를 실행하지 않는다. 규제 산업이나 감사에 민감한 재무 팀에게 그 분리가 도움이 되는 에이전트와 위험을 만드는 에이전트의 차이.

이것이 해결하지 않는 것

에이전트 결제는 조달-결제 루프를 닫지만 모든 조달 문제를 해결하지 않는다. 에이전트는 가격 협상을 하지 않는다——그것은 공급업체와의 인간 대화. 에이전트는 새 공급업체를 선택하지 않는다——공급업체 온보딩은 인간이 소유하는 컴플라이언스 심사, 신용 검사, 계약 협상을 요구. 에이전트는 판단 이유로 쓰리웨이 매치에 실패한 청구서의 분쟁 해결을 처리하지 않는다——그것을 AP에 플래그하고 구조화된 요약을 제공하지만 해결은 인간의 결정.

영수증 격차: 정산된 결제는 어떤 스크리닝 버전이 실행되었는지 증명하지 않는다. x402 영수증 확장(OMA3/x402 협업을 통해 프로토콜에 머지됨)은 누가 지불했는지, 어떤 서비스에 접근했는지, 언제, 그리고 결제 참조를 기록한다——서비스에 의해 디지털 서명되고, 휴대 가능하며, 독립적으로 검증 가능. 거래가 발생했음을 증명한다. 서버 측에서 실제로 어떤 버전의 스크리닝 로직, 정책 규칙, 또는 모델이 실행되었는지 기록하지 않는다. 감사자가 에이전트가 지불했다는 것뿐 아니라 지불 전에 올바른 컴플라이언스 스크리닝을 실행했다는 것을 증명해야 하는 규제된 조달 워크플로에서, 그것이 실행 증명 격차이다.

두 IETF 드래프트가 그것을 닫는다. action_ref 드래프트(draft-etcheverry-action-ref-02, 2026년 7월)는 콘텐츠 주소 지정 식별자를 정의한다——agent_id, action_type, scope, timestamp의 canonical JSON에 대한 SHA-256——발행자를 신뢰하지 않고 모든 감사자가 재계산 가능, 정책 버전 감사 가능성을 위한 선택 필드 포함. x402-retention-chain 드래프트(draft-hopley-x402-retention-chain-06, 2026년 6월)는 구성을 공식화한다: x402 payment_hash를 하나의 영수증에서 action_ref에 바인딩하는 Settlement-Action Binding(binding_ref). 이를 통해 정산 증명은 결제가 발생했음을 입증할 뿐 아니라 어떤 검증된 에이전트 동작에 해당하는지 입증한다. 액션에 거버넌스 정책의 콘텐츠 주소 지정 스냅샷을 바인딩하는 Policy Binding(policy_bound_ref)도 정의한다——스크리닝 결정이 결정 시점의 정확한 정책 버전에 대해 검증 가능하며, 정책 로테이션이 재계산으로 감지 가능. Compliance Gate Binding(gate_ref)은 ALLOW/REFER/DENY 컴플라이언스 판정을 정책 참조에 추가로 바인딩하여, 스크리닝 결과가 그것을 생성한 규칙 버전에 증명 가능하게 바인딩된다.

아키텍처: x402는 Base에서 약 200ms 내에 결제를 정산하고 payment_hash를 생성한다. 에이전트는 실행한 스크리닝 동작의 action_ref를 내보낸다. binding_ref가 그것들을 하나의 영수증에 연결한다. 영수증을 가진 감사자는 두 해시를 독립적으로 재계산한다——SHA-256과 JCS(RFC 8785), 발행자 연락 불필요. 감사 체인이 답한다: 결제 정산됨, 이 특정 스크리닝 버전이 실행됨, 이 정책 버전 하에서, 이 타임스탬프에. 두 레이어, 하나의 영수증.

에이전트 결제 레일은 새롭다.

관련 글


500인 산업 유통업체는 5개 수동 핸드오프와 23% 예외율의 조달-결제 주기로 월 14일과 주당 46시간의 AP 시간을 잃고 있었다. 적격 청구서의 59%에서 조기 결제 할인이 획득되지 않았다——월 64,000달러의 절약 유실. NetSuite와 BigCommerce에 대한 MCP 커넥터, 병렬 서브태스크용 A2A 위임, 에이전트 결제 프로토콜(Mastercard Agent Pay, x402, Stripe 에이전트 결제 토큰)을 갖춘 에이전트 스택이 주기를 3일로 압축하고 예외를 7%로 줄이며 조기 결제 획득을 94%로 끌어올렸다. 인간이 결제 승인 결정을 유지. 에이전트는 그 결정을 빠르게 만드는 작업을 수행.

범위 지정된 빌드 요청

1주 디스커버리. 시스템 인벤토리, 워크플로 맵, 고정 범위를 얻는다——우리와 함께 구축하든 아니든.

귀하의 시스템을 위해 이것을 구축하고 싶으신가요?

여기의 각 문서는 실제 프로덕션 작업에서 나왔습니다. 대상 시스템과 워크플로가 있다면, 1주 내에 빌드를 범위 정의할 수 있습니다.

범위 정의 빌드 요청

1주 발견. 시스템 인벤토리, 워크플로 맵, 고정 범위를 받습니다 — 우리와 빌드할지 여부와 관계없이.