API 연동 업체 비교, 연결 개수보다 예외 업무를 봐야 하는 이유

쇼핑몰 주문을 고객관리 도구와 ERP에 옮기고 배송 상태를 알리는 일을 생각해 보겠습니다. 처음에는 “주문 API를 연결할 수 있나요?”라는 질문으로 충분해 보입니다. 그러나 재고 부족으로 주문을 보류하고, 부분 취소 뒤 환불과 재고를 함께 고치며, 야간 장애 뒤 누락 건을 찾아야 한다면 이야기가 달라집니다.

API는 서로 다른 소프트웨어가 정보를 주고받는 접점입니다. 데이터를 보낼 길이 있다는 뜻이지, 우리 회사의 업무 순서와 예외 상황까지 알아서 처리한다는 뜻은 아닙니다. 연동은 시작일 뿐입니다. 업체를 비교할 때는 연결 대상의 숫자보다 그 뒤에 남는 업무를 누가 처리하는지 봐야 합니다.

기본 기능, 자동화 도구, 맞춤 개발의 쓰임은 다르다

첫 선택지는 사용 중인 업무 시스템이 제공하는 기본 연결 기능입니다. 쇼핑몰 주문을 고객관리 도구에 등록하거나 문의가 오면 담당자에게 알리는 것처럼 흐름이 표준적이라면 빠르게 시작할 수 있습니다. 대신 제공된 설정 범위 밖의 조건, 예를 들어 특정 상품만 승인 후 출고하는 규칙은 담기 어려울 수 있습니다.

두 번째는 여러 SaaS 서비스를 조합하는 자동화 도구입니다. 새 주문을 스프레드시트에 기록하고 담당 채널에 알림을 보내는 반복 업무에는 잘 맞을 수 있습니다. 다만 주문, 결제, 재고처럼 한 번의 실행이 거래 결과를 바꾸는 업무라면 중복 실행과 실패 뒤 재처리 방식을 따로 살펴야 합니다.

세 번째는 맞춤 개발입니다. 사내 ERP처럼 문서가 충분하지 않은 시스템을 연결하거나, 승인·정산·취소 규칙이 복잡한 경우에 검토할 수 있습니다. 필요한 범위와 비용, 일정은 기존 시스템 상태, 데이터 정리 수준, 운영 절차에 따라 달라집니다. 맞춤 개발의 가치는 기능을 많이 만드는 데만 있지 않습니다. 어느 시스템의 값을 기준으로 볼지, 문제가 난 건을 어디서 확인할지까지 업무에 맞춰 정할 수 있다는 데 있습니다.

연결 성공보다 실패한 주문을 어떻게 다루는지가 중요하다

주문은 ERP에 등록됐지만 고객관리 도구 등록 단계에서 실패했다고 가정해 보겠습니다. 담당자가 주문을 다시 보내면 ERP에 같은 주문이 두 번 들어갈 수 있습니다. 반대로 아무 조치도 하지 않으면 고객 응대 기록이 빠집니다. 이 장면에서 필요한 것은 “재시도한다”는 짧은 답이 아니라, 실패 건을 표시하고 중복 없이 다시 처리하며 담당자가 확인할 방법입니다.

상담에서는 아래 다섯 가지를 물어보면 제안의 범위를 가늠하기 좋습니다.

1. 이 연결은 정보를 조회하나요, 아니면 주문·결제·승인 결과를 바꾸나요?
2. 두 시스템의 값이 다를 때 어느 쪽을 맞는 값으로 보나요?
3. 취소, 부분 변경, 중복 실행, 통신 실패는 각각 어떻게 처리하나요?
4. 문제가 생긴 건을 운영 담당자는 어디에서 확인하고 다시 처리하나요?
5. 연동 계정, 접속 권한, 문서, 장애 알림은 구축 뒤 누가 관리하나요?

답이 구체적일수록 비교도 쉬워집니다. 반대로 “연동 가능합니다”라는 설명만 있고 실패 상황이나 확인 방법이 빠져 있다면, 나중에 사람이 수작업으로 메워야 할 구간이 남을 수 있습니다.

업체 경험은 서비스 이름보다 제안 자료에서 확인한다

포트폴리오에 결제, 로그인, CRM, ERP 이름이 많아도 우리 업무를 그대로 처리한다는 보장은 없습니다. 같은 종류의 시스템이라도 데이터 항목, 권한 설정, 승인 절차, 기존 데이터 상태가 다르기 때문입니다. 유명한 API를 연결한 경험보다 우리 업무 흐름의 예외를 이해했는지가 더 중요한 이유입니다.

상담 전에는 연결할 시스템 이름과 함께 현재 업무 순서를 짧게 적어 두는 편이 좋습니다. 누가 주문을 확인하는지, 바뀌면 안 되는 값은 무엇인지, 사람이 판단해야 하는 순간은 언제인지 정도면 충분합니다. 처리량의 대략적인 규모와 장애가 났을 때 업무가 멈춰도 되는 시간도 알려주면 업체가 운영 조건을 놓치지 않고 제안하기 쉽습니다.

업체에는 흐름도, 데이터 항목 대응표, 대표적인 실패 상황의 처리 방식, 구축 뒤 관리 범위를 요청해 보십시오. OpenAPI처럼 요청과 응답의 약속을 문서로 표현한 자료가 있다면, 무엇을 보내고 무엇을 받는지 함께 확인하는 데 도움이 됩니다. 다만 문서가 있다고 운영 문제가 사라지지는 않습니다. 가장 자주 틀어질 업무 한 가지를 먼저 꺼내고, 그 상황을 끝까지 처리하는 답을 내놓는지 보십시오. 그 답이 기존 솔루션으로 충분한지, 별도 개발이 필요한지를 가르는 기준이 됩니다.