지난해 성수기 1주 전, 리알토에 있는 한 3PL 물류센터를 둘러보던 중 IT 책임자가 자랑스럽게 새로 연동한 택배사 라벨 발행 API를 보여주었다. 「초당 2,000건의 요청을 처리합니다」라고 그는 말했다. 나는 단 한 가지를 물었다. 「이 API가 새벽 2시에 죽으면, 가장 먼저 알게 되는 사람은 누구죠?」 그는 얼어붙었다.
그는 한참을 생각하더니 대답했다. 「아마… 새벽 6시에 라벨 프린터 담당자가요.」
이 한마디가 모든 걸 말해준다. 연동이 얼마나 견고한지는 기술의 문제다. 깨졌을 때 누가 가장 먼저 알게 되는지는 관리의 문제다. 대부분의 창고는 사실상 연동 모니터링을 갖추지 못하고 있다. 구축하지 않아서가 아니라, 구축해 놓은 게 있으나 마나다. 말도 안 되는 임계값 설정, 아무도 읽지 않는 메일함으로 향하는 알림, 새벽 3시에 온 팀을 깨우는 문자——결국 모두가 채널을 음소거한다.
20년 현장에서 나는 연동이 죽는 모습을 스무 가지가 넘는 방식으로 봤다. 여기 내 모니터링·알림 체크리스트를 있는 그대로 적는다. 이것만 따르면, 장애를 가장 먼저 알게 되는 건 고객이 아니라 우리 팀이 된다.
다섯 가지 시그널. 나머지는 전부 보너스다.
화려한 옵저버빌리티 대시보드부터 만들지 마라. 창고에서는 다섯 가지 시그널이면 충분하다. 하나라도 놓치면 성수기에 당한다.
첫째, 하트비트. 엔드포인트가 살아 있는가? 가장 단순하고 가장 자주 생략되는 것. 5분마다 헬스체크 엔드포인트에 핑을 보내거나, 프로브 메시지를 보낸다. 택배사 라벨 API, 주소 검증, 관세 계산——외부 연동은 모두 자체 하트비트가 필요하다. 2023년, 온타리오의 한 3PL은 택배사 TLS 인증서가 만료되는 바람에 라벨 출력이 네 시간 멈췄다. 하트비트 프로브가 없으니 경고도 없었다. 9,000건의 주문이 쌓인 뒤에야 누군가 알아챘다. 하트비트 점검 비용은 사실상 제로다. 건너뛰는 건 순전한 게으름이다.
둘째, 오류율. 5분 구간 내 전체 대비 실패 요청의 비율. 비율이다. 절대 건수가 아니다——성수기에는 물량이 열 배로 늘기 때문에 절대 건수는 자연스럽게 늘어난다. 비율이 올라가는 게 진짜 문제의 징후다.
셋째, 지연시간. P99 지연시간이다. 평균이 아니다. 평균 200ms는 아름답게 들리지만 P99가 8초가 되면——요청의 1%가 멈추고, 대개 가장 바쁜 시간대에 몰리며, 그게 바로 포장 라인을 멈춘다.
넷째, 백로그 깊이. 큐 길이, 미처리 파일 수, 재시도 풀 깊이. 「느리지만 죽지는 않았다」는 가장 잔인한 장애 모드다. 겉으로는 멀쩡해 보이는데 큐는 점점 깊어지고, 알아챘을 때는 30,000건의 메시지가 묻혀 있어 파낼 수가 없다.
다섯째, 정합성 차이. 정기 리컨실리얼: 우리가 보낸 주문과 상대가 받은 주문을 대조한다. 택배사 라벨, EDI 850/856 문서, 재고 동기화——최소 매일 대조한다. 리컨실리얼은 최후의 방어선이다. 앞의 네 시그널이 모두 놓쳤을 때, 이것이 잡는다.
임계값 설정: 세 단계, 만능 해법은 없다
고전적인 실수는 하나뿐인 임계값이다. 매일 「늑대다!」를 외치거나, 진짜 장애를 아무도 모르는 둘 중 하나가 된다. 나는 비즈니스 임팩트 기준으로 세 단계를 나눈다.
P1——전화 호출, 5분 이내 대응. 트리거: 핵심 연동(라벨 출력, 출하 확정, 재고 동기화)의 하트비트가 두 번 연속 실패, 5분 구간 오류율이 5% 초과, P99 지연시간이 10초 초과를 10분 연속. P1은 당번 엔지니어에게 거는 실제 전화다. 문자가 아니다, 메일이 아니다. 5분 내 응답이 없으면 자동으로 두 번째 연락처로 에스컬레이션된다.
P2——문자+그룹 메시지, 30분 이내 대응. 트리거: 비핵심 연동(주소 검증, 추적 콜백)의 오류율이 3% 초과, 큐 백로그가 5,000건 초과하고 15분 뒤에도 계속 증가, 같은 배치에서 50건을 초과하는 재시도 실패. P2는 당번 채널로 보내고, 「확인」 답글이 곧 승인이다.
P3——메일+일일 다이제스트, 업무 시간 내 대응. 트리거: 정합성 차이가 0.5% 미만, 아직 기준선을 넘지 않은 P99의 완만한 상승, 30일 이내 만료 예정인 인증서. 아침 IT 스탠드업 보고서에 실린다.
중요한 디테일 하나: 임계값은 연동별로 튜닝하고, 성수기 2주 전에는 임계값 변경을 동결하라. 내가 본 최악의 설정은 모든 연동이 오류율 1% 임계값을 공유하고 있었다. 성수기에는 주소 검증 API가 종일 2–3% 오류였다——쇼퍼들이 쓰레기 주소를 입력하기 때문이다. 알림은 끊임없이 울렸고 모두 무시했고, 그날 밤 진짜 P1 장애가 또 하나의 오보로 취급되어 무시당했다. 성수기 전에 각 연동의 과거 P95에 맞춰 임계값을 캘리브레이션하라. 반나절이면 된다. 건너뛰면, 그 중요한 알림 하나를 놓치는 대가를 치른다.
누가 알림을 받나: 당번표가 기술보다 중요하다
기술이 완벽해도, 알림이 전부 음소거한 사람에게 가면 무용지물이다. 내가 강요하는 세 가지 규칙.
하나, 당번표가 있어야 한다——「팀」이 아니라 이름 있는 한 사람. 그룹채팅의 알림은 모두 「누군가 하겠지」라고 생각한다. P1 알림은 1대1로 간다. 먼저 당번 엔지니어, 5분 내 응답 없으면 IT 매니저로 자동 에스컬레이션, 그다음 운영 디렉터로. 운영 디렉터에게는 백업 택배사로 전환 같은 비즈니스 판단을 내릴 권한이 있다. 당번은 주 단위로 순환하고 일주일 전에 공개되며, 휴일 근무는 대체 휴가가 나온다. 대체 휴가 없는 당번표는 한 달을 못 버틴다.
둘, 심각도별로 채널을 분리하라. P1은 전화, P2는 문자와 그룹채팅, P3는 메일. P3 다이제스트를 P1과 같은 채널에 절대 흘리지 마라——노이즈가 충분해지면 사람은 모든 걸 무시하게 된다. 한때 200명 채널에서 하루 300건의 알림이 흐르는 걸 봤다. 거기에 묻힌 P1은 가망이 제로였다.
셋, 오보를 월 단위로 리뷰하라. 지난달 알림을 뽑는다. 실제 인시던트는 어떤 건지, 오탐은 어떤 건지, 울렸는데 무시된 건 어떤 건지. 오탐률이 30%를 넘는 임계값은 재조정한다. 무시된 알림은 조사한다. 알림 시스템도 사람과 같아서, 리뷰 없이는 썩는다.
그리고 피로 산 교훈: 성수기 전에 「네트워크 끊기」 드릴을 하라. 조용한 주말 아침, 스테이징 환경의 택배사 API를 끊고 모든 걸 측정한다——알림이 울리기까지 얼마나 빠른지, 당번이 얼마나 빨리 응답하는지, 폴백 플랜이 얼마나 빨리 가동되는지. 종이 위에서만 논의한 계획은 첫 실전에서 반드시 실패한다. 드릴을 하는 창고와 안 하는 창고는 성수기 밤에 완전히 다른 종처럼 움직인다.
비용은 얼마인가? 계산해보자.
구축 비용은 비싸지 않다. 기성 APM(Datadog, New Relic, 또는 오픈소스 Prometheus+Alertmanager)으로 하트비트 프로브와 오류율 추적을 세우는 데 약 일주일. 진짜 비용은 당번 수당이다. 이 동네 시세로는 평일 야간 시프트가 $50–80, 주말이 $100–150이다. 당번표 전체로 한 달에 수천 달러다.
이제 안 했을 때의 비용. 가장 흔한 시나리오: 라벨 API가 밤새 죽고 새벽 6시까지 아무도 모르고, 8,000건 주문이 밀린다. 주문이 하루씩 밀릴 때마다——택배사 마감 시간을 놓치고, 지원 티켓, 마켓플레이스 패널티(아마존 OTDR이 0.5포인트 떨어지고 Buy Box 가중치가 타격을 받는다), 따라잡기 위한 잔업. 이런 사고 한 번에 $20,000–50,000, 보수적으로 잡아도. 일 년에 한 번의 사고로 모니터링 비용의 열 배를 치른 셈이다.
그래서 내 결론은 직설적이다. 연동 모니터링은 IT의 선택 과목이 아니다. 창고 운영의 필수 과목이다. 화려한 대시보드와 옵저버빌리티 유행어는 건너뛰어도 좋다. 하지만 다섯 가지 시그널, 세 단계 임계값, 하나의 당번표——이 세 가지는 오늘 밤까지 갖춰야 한다.
내일 아침 가장 먼저: IT 리더에게 물어보라. 「새벽 2시에 연동이 죽으면 누가 가장 먼저 알게 되는 거죠?」라고. 대답 못 하면, 뭘 해야 할지 알 것이다.
영어판 번역본입니다. 내용이 다를 경우 영어판을 우선합니다.
