연동 장애가 전체 장애가 되는 경로
택배 송장 발급, 결제 승인, 공공 API 조회, ERP 전표 전송처럼 업무 시스템이 의존하는 외부 서비스는 계속 늘어나고 있습니다. 문제는 외부 API가 멈추는 것보다 느려질 때 더 위험하다는 점입니다.
예를 들어 요청 처리 스레드가 200개인 서버에서 초당 20건씩 호출하는 택배 API가 응답 없이 30초씩 붙잡혀 있다고 가정해 보겠습니다. 스레드는 약 10초 만에 모두 대기 상태가 되고, 그 뒤로는 택배와 무관한 로그인·조회 요청까지 처리되지 못합니다. DB 커넥션을 쥔 채로 외부 호출을 기다리는 코드라면 커넥션 풀도 함께 고갈됩니다. 연동 하나의 지연이 시스템 전체 장애로 번지는 전형적인 경로입니다.
기본기: 타임아웃과 재시도
업무 허용 시간에서 거꾸로 정하는 타임아웃
타임아웃은 라이브러리 기본값이 아니라 사용자가 기다릴 수 있는 시간에서 거꾸로 정해야 합니다. 주문 완료 화면을 3초 안에 보여줘야 한다면 연결 타임아웃 1초, 응답 타임아웃 1.5초처럼 나누고, 재시도까지 포함한 전체 시간이 3초를 넘지 않도록 설계합니다. 기본값이 무한대이거나 수십 초인 HTTP 클라이언트가 여전히 많으므로 반드시 명시적으로 설정해야 합니다.
재시도해도 되는 요청과 안 되는 요청
재시도는 지수 백오프와 지터를 함께 적용합니다. 200ms, 400ms, 800ms처럼 간격을 늘리되 무작위 편차를 섞어야 여러 서버가 같은 순간에 몰려드는 현상을 피할 수 있습니다. 횟수는 2~3회로 제한합니다.
중복 처리를 막는 멱등성 설계
응답 타임아웃은 "실패"가 아니라 "결과를 모름"입니다. 상대 시스템에서는 결제가 이미 승인됐을 수도 있습니다. 그래서 생성 요청에는 주문번호 기반의 멱등 키를 함께 보내고, 우리 쪽에도 요청 이력 테이블을 두어 같은 키로 이중 등록되지 않게 합니다.
응답을 받지 못한 요청은 곧바로 재전송하지 말고 상태 조회 API로 결과를 먼저 확인하는 절차를 둡니다. 조회 API가 없는 연동이라면 "확인 필요" 상태로 따로 관리해 담당자가 대사(對査)할 수 있게 해야 합니다.
장애 격리 패턴
서킷 브레이커
최근 50건 중 실패율이 50%를 넘으면 회로를 개방해 30초 동안 호출을 즉시 실패시키는 식으로 설정합니다. 이후 반개방 상태에서 시험 호출 5건을 허용하고, 성공하면 정상으로 복구합니다. 응답을 기다리지 않으니 스레드가 붙잡히지 않습니다.
벌크헤드
연동 대상별로 스레드 풀이나 동시 호출 수를 분리합니다. 택배 API에 최대 20개만 배정해 두면 그쪽이 막혀도 결제와 ERP 연동은 영향을 받지 않습니다.
비동기 큐 전환
ERP 전표 전송처럼 즉시 응답이 필요 없는 연동은 큐로 넘깁니다. 실패한 메시지는 데드레터 큐에 보관했다가, 상대 시스템이 복구되면 재처리합니다.
운영과 관측
POLYGLOTSOFT SM 연동 장애 점검 항목으로는 외부 호출별 타임아웃 명시 여부, 생성 요청의 멱등 키 적용, 서킷 브레이커·벌크헤드 설정값, 데드레터 큐 적재 현황, 연동 대상별 대시보드와 알림 임계값을 정기적으로 확인합니다.
외부 연동이 많은 업무 시스템에서 장애를 한 지점에 가두는 설계는 선택이 아니라 기본 요건입니다. POLYGLOTSOFT는 구독형 개발과 SM 서비스를 통해 기존 시스템의 연동 구간을 진단하고, 타임아웃·멱등성·서킷 브레이커 적용부터 모니터링 구성까지 함께 개선해 드립니다. 연동 장애로 고민이 있으시다면 언제든 문의해 주십시오.