한 시스템이 작업을 마쳤어도 완료를 알리는 응답은 전송 중 사라질 수 있습니다. 시스템 연동을 승인하기 전에, 같은 내용을 다시 전달해도 청구서나 출고 요청이 중복 생성되지 않는지, 결과가 불확실하면 누가 확인하는지 물어보세요.
주문, 창고 또는 회계 시스템 간 연동을 승인하기 전에 같은 업데이트가 두 번 도착하면 어떻게 되는지 물어보세요. 업데이트는 다시 전달해야 할 수 있습니다. 하지만 청구서, 출고 요청 또는 고객 메시지는 이미 생성되어 있을 수 있습니다.
한 시스템이 업데이트를 보내고 수신 시스템이 작업을 마쳤다고 가정해 보세요. 성공을 알리는 응답이 돌아오는 도중 사라집니다. 송신 시스템은 기다리다가 제한 시간이 지나면 다시 시도합니다.
시간 초과는 왜 재전송이 이루어졌는지 설명해 줍니다. 첫 번째 시도가 완료되었는지는 알려주지 않습니다. 재시도를 끄면 작업이 미완료로 남을 수 있고, 업무 처리를 매번 반복하면 중복 작업이 생길 수 있습니다.
Malcolm Featonby는 Amazon Builders’ Library의 안전한 재시도에 관한 글에서 이런 불확실성을 설명합니다. Stripe와 Shopify도 웹훅이 반복 전달되는 경우를 문서로 설명합니다. 웹훅은 한 시스템이 다른 시스템으로 자동으로 보내는 업데이트입니다. 연동을 실제로 사용하기 전에 이 동작을 논의해 둘 필요가 있습니다.
결제가 완료되었다는 주문 업데이트를 받으면 주문 이행 요청 하나를 생성하는 가상의 쇼핑몰을 생각해 보세요. 다음 세 가지 상황은 각각 다르게 처리해야 합니다.
주문 이행 요청이 이미 존재할 수 있습니다. 합의한 범위 안에서 같은 업무 처리를 위한 업데이트가 다시 전달되어도 요청이 하나 더 생성되어서는 안 됩니다.
주소 변경이나 취소에는 다른 처리가 필요할 수 있습니다. 주문 번호가 같다고 해서 모든 업데이트가 중복인 것은 아닙니다.
고객, 상품, 총액이 같아 보여도 새 주문은 정상적으로 처리되어야 합니다. 세부 정보가 비슷하다는 이유만으로 중복이라고 판단할 수는 없습니다.
의도한 업무 처리를 무엇으로 식별하며, 같은 업데이트가 다시 전달되어도 그 식별 정보가 어떻게 유지되는지 공급업체에 물어보세요. 기술적인 방식을 직접 선택할 필요는 없습니다. 다만 실제로 새로운 작업은 허용하면서 중복 전달을 어떻게 알아보는지 설명을 들어야 합니다.
제공업체마다 세부 동작은 다릅니다. Stripe 문서는 같은 이벤트가 반복되는 경우와 같은 객체에 관해 별도의 이벤트가 발생하는 경우를 설명합니다. Shopify는 개별 전송과 그 전송의 원인이 된 판매자의 행위를 구분합니다. 한 용도에 유용한 식별자가 모든 업무 처리에 적합한 기준이 되는 것은 아닙니다.
관련 사례는 Stripe 웹훅 문서와 Shopify 전송 검증 가이드에서 볼 수 있습니다. 공급업체는 실제로 연결할 시스템의 현재 동작을 확인해야 합니다.
주문 이행 요청은 생성되었지만 완료 사실을 기록하기 전에 연동이 멈췄다고 가정해 보세요. 다음 시도에서 기존 요청을 어떻게 찾을까요? 같은 업데이트 두 개가 동시에 도착하면 어떻게 될까요? 이미 받은 업데이트 목록만으로는 어느 질문에도 충분히 답할 수 없습니다.
세 가지를 각각 확인할 수 있게 해 달라고 요청하세요. 업데이트가 도착했다는 증거, 연동의 처리 상태, 수신 시스템에서 실제 업무 처리가 이루어졌다는 증거입니다. 수신 확인만으로는 택배 발송 요청이나 청구서가 실제로 존재한다고 단정할 수 없습니다.
결과가 여전히 불확실하면 재시도를 허용하기 전에 누가 조사하고 무엇을 확인할지 정하세요. 직원이 직접 재개할 수 있는 작업, 공급업체의 도움이 필요한 작업, 중복 처리를 피하기 위해 중단해야 할 시점을 명확히 하세요. 어떤 문제는 여러 시스템의 기록을 대조한 뒤 사람이 다음 조치를 결정해야 합니다.
“다시 시도”가 유용하려면 재시도에서 허용되는 처리가 무엇인지, 결과가 불확실할 때 누가 맡을지 알아야 합니다.
시스템이 지원하는 테스트 환경에서 가상 데이터를 사용하고 외부에 실제 업무 처리가 발생하지 않도록 설정하세요. 시연에는 같은 업데이트를 두 번 전달하는 경우, 실제로 새로운 두 번째 주문, 한 단계가 성공한 뒤 실패하는 경우를 포함해야 합니다. 전송 로그와 함께 실제로 생성된 기록도 확인하세요. 동작을 알아보기 위해 실제 결제나 주문을 다시 실행해서는 안 됩니다.
무엇이 처리를 시작하는지, 어떤 업무 처리를 의도하는지, 중복을 어떻게 식별하는지, 직원이 어디서 결과를 볼 수 있는지 간단한 문서로 요청하세요. 이전 작업을 얼마나 오래 기억하는지, 늦게 도착한 업데이트는 어떻게 처리하는지, 결과가 불확실하거나 일부만 완료된 작업은 누가 맡는지도 포함하세요.
특정 실패 상황을 안전하게 시연할 수 없는 시스템이라면 그 한계를 기록하고 공급업체와 검토 범위를 좁혀 합의하세요. 테스트 성공은 해당 조건에서 확인한 동작의 근거가 됩니다. 연결된 모든 서비스에서 처리가 정확히 한 번만 이루어진다고 보장하거나, 전체 단계가 나눌 수 없는 하나의 작업으로 완료된다는 사실을 입증하지는 않습니다.
저희는 시스템 연동과 맞춤형 업무 소프트웨어를 개발합니다. 연동을 계획하고 있다면 연결할 시스템, 실행하려는 업무 처리, 반복 전달 시 동작에 관해 아직 설명이 필요한 부분을 알려주세요. 해당 연동에 필요한 작업을 함께 논의할 수 있습니다.
아닙니다. 작업은 완료되었지만 응답이 사라졌을 수 있습니다. 재시도에서 무엇을 할지 결정하기 전에 처리 결과와 수신 시스템을 확인하세요.
네. 고객이 같은 상품과 총액으로 두 번째 주문을 의도적으로 할 수 있습니다. 연동은 새로운 주문 의도와 반복 전달을 구분해야 합니다. 세부 정보가 같다는 사실만으로는 판단할 수 없습니다.
시스템이 지원하는 테스트 환경에서 가상 데이터를 사용하고 외부에 실제 업무 처리가 발생하지 않도록 설정해 달라고 요청하세요. 중복 전달, 실제로 새로운 업무 처리, 일부 작업이 성공한 뒤 실패하는 경우를 포함하세요. 실제 주문이나 결제로 실험하는 대신 테스트하지 못한 부분을 기록하세요.
운영을 시작하기 전에 담당자나 책임 팀을 정하세요. 직원은 직접 확인하거나 재개할 수 있는 범위와, 추가 처리를 허용하기 전에 공급업체가 조사해야 하는 상황을 알아야 합니다.
지난 뉴스레터: 이미 보유한 구독형 사이트나 앱에서 더 많은 수익을 내는 법.
그 전 편: 진짜 성공 사례에서 AI 헛소리를 가려내는 법.
관심 있으세요?
매주 또는 알려 주시면 원하시는 대로 맞춰 드립니다. 괜찮으시죠?
