on-call 없는 회사는 가능한가

"결제팀인데 on-call이 없다"는 말이 이상하게 들리는 이유

우리는 결제·정산·자동화를 운영한다. 외부에서 보면 이 조합은 on-call의 교과서 케이스처럼 들린다. 카드 승인이 새벽 2시에 막히면? 정산 배치가 새벽 3시에 터지면? 일반적인 대형 PG사나 핀테크 회사라면 당연히 24시간 대기조가 있을 것이다. 그런데 우리는 없다. 그리고 그게 나쁜 선택이 아니라고 믿는다 — 단, 이유가 명확할 때만.

사실 on-call 없이 운영한다는 말은 두 가지 중 하나를 의미한다. 장애가 거의 안 난다는 뜻이거나, 장애가 나도 즉시 대응하지 않아도 손해가 작다는 뜻이다. 첫 번째는 시스템 설계로 달성한다. 두 번째는 서비스 정의와 계약으로 달성한다. 우리는 두 가지를 동시에 추구하되, 어느 쪽이 더 현실적인 투자인지를 서비스별로 다르게 판단한다. 이 판단이 명확하지 않으면 on-call을 없앤 게 아니라 숨긴 것이다 — 누군가가 암묵적으로 짊어지는 구조가 되기 때문이다.

서비스 중요도를 숫자로 정의하지 않으면 on-call 논의가 시작될 수 없다

on-call 도입 여부를 결정하기 전에 먼저 해야 할 일은 SLA를 계약 언어가 아닌 장애 비용으로 표현하는 것이다. "99.9% 가용성"이라는 숫자는 한 달에 약 43분의 다운타임을 허용한다. 새벽 3시에 40분짜리 정산 배치 오류가 나도, 아침 9시에 재실행하면 결과가 같다면 — 이 서비스는 99.9% SLA를 새벽에 지킬 이유가 없다.

우리 정산 파이프라인의 경우, 실제로 이 계산을 해봤다. 새벽 배치가 실패했을 때 발생하는 최악의 시나리오는 "당일 오전 정산 확인이 2~3시간 지연"이다. 이 지연이 파트너사에 금전적 손해를 주는가? 현재 계약 구조에서는 아니다. 그렇다면 이 배치 실패는 on-call을 정당화하지 않는다. 반면 실시간 결제 승인 요청은 다르다. 1분 다운타임이 실제 거래 손실로 이어지므로, 이 부분만큼은 구조적으로 단일 장애점을 제거하는 데 훨씬 많은 투자를 한다 — on-call 대신 장애 자체가 안 나는 쪽으로.

우리가 실제로 하는 세 가지: 수치와 함께

배포 후 5분 모니터링은 단순해 보이지만 실제 운영에서 효과가 크다. 우리 배포 사고의 약 80%는 배포 직후 3분 이내에 에러율 스파이크나 레이턴시 이상으로 감지됐다. 5분을 보는 건 경험칙이 아니라 데이터다. 배포 후 5분을 넘기면 문제는 코드가 아닌 외부 의존성(외부 API, DB 쿼리 플랜 변경)에서 오는 경우가 대부분이다.

알림 임계값은 "사용자가 에러를 체감할 수 있는 수준"으로 설정한다. 구체적으로는 에러율 1% 미만이면 알림 없음, 1~5%는 Slack 알림(비동기), 5% 초과는 즉시 알림 + 자동 롤백 트리거다. 이전에는 에러율 0.1%에도 알림을 보냈는데, 한 달에 수십 개의 알림이 쌓이자 팀 전체가 알림을 무시하기 시작했다. 알림 임계값을 높인 뒤 오히려 실제 대응 속도는 빨라졌다.

롤백 5분 이내 원칙은 장애 예방보다 복구 속도에 집중한다는 선언이다. 우리는 블루-그린 배포와 기능 플래그를 조합해, 어떤 배포든 5분 이내에 직전 상태로 되돌릴 수 있다. 이 구조를 만드는 데 초기에 약 2주의 엔지니어링 시간이 들었다. 그 이후로 on-call 로테이션을 유지하는 데 들었을 월별 비용(팀원의 주말 대기 부담, 번아웃, 이직률)과 비교하면 명백히 이득이다.

우리 팀이라면 이렇게 한다: 새벽 정산 배치 실패 시나리오

실제 시나리오로 구체화해보자. 새벽 2시 30분, 정산 집계 배치가 외부 세금계산서 API 타임아웃으로 절반만 처리된 채 멈췄다. 아무도 깨어 있지 않다.

우리의 대응 순서는 이렇다. 첫째, 배치 실패 알림은 Slack에 쌓인다 — 아무도 즉시 보지 않는다. 둘째, 배치는 멱등성(idempotency)을 보장하도록 설계되어 있으므로, 아침 9시에 팀원이 확인 후 수동 재실행하면 된다. 셋째, 파트너사에는 정산 완료 예상 시각을 자동 알림으로 1시간 단위 업데이트하도록 되어 있어, 오전 10시 완료 예정이라면 그게 SLA 내다.

이 구조가 작동하는 전제는 두 가지다. 배치 작업이 멱등하게 설계되어 있어야 하고, 파트너사와 "새벽 배치 지연은 오전 중 해소"라는 암묵적 합의가 아닌 명시적 계약이 있어야 한다. 전자는 엔지니어링 문제고, 후자는 비즈니스 문제다. on-call 없이 운영하려면 이 두 가지가 모두 갖춰져야 한다. 하나라도 없으면 on-call을 없앤 게 아니라 리스크를 숨긴 것이다.

솔직한 한계: 우리가 on-call을 도입해야 하는 시점

현재 구조가 통하는 건 서비스의 다운타임 비용이 새벽 대기 비용보다 낮기 때문이다. 이 등식이 바뀌는 시점이 있다. 세 가지 트리거를 실제로 정의해두고 있다.

하나, 실시간 B2C 결제 볼륨이 월 10억 원을 넘는 경우. 이 시점부터는 1분 다운타임의 기대 손실이 on-call 운영 비용(월 인건비 환산 기준 약 50~80만 원/인)을 초과한다. 둘, SLA 계약에 새벽 시간대 응답 의무가 명시되는 경우. 계약서에 들어가는 순간 암묵적 합의가 법적 의무가 된다. 셋, 장애 감지부터 롤백까지 5분을 넘기는 경우가 월 2회 이상 발생하는 경우. 이는 현재 파이프라인 설계가 깨졌다는 신호다.

이 트리거 중 하나라도 발동하면 on-call 도입을 재검토한다. 중요한 건 이 기준을 미리 숫자로 정의해두는 것이다. 감각이나 느낌으로 판단하면 항상 "아직은 괜찮겠지"가 된다.

바로 써먹을 수 있는 시사점

on-call 구조를 검토하는 팀이라면 아래 순서로 판단하라.

1. 서비스별 다운타임 비용을 시간당 금액으로 계산하라. 추정이어도 좋다. 새벽 1시간 다운이 "불편"인지 "수십만 원 손실"인지 "계약 위반"인지를 숫자로 표현해야 on-call 논의가 구체화된다.

2. 배치·파이프라인 작업은 반드시 멱등하게 설계하라. 재실행이 가능한 구조라면 실패 시점이 새벽이든 낮이든 복구 결과가 같다. 이것만으로 야간 on-call의 절반 이상을 제거할 수 있다.

3. 알림 임계값을 에러율 기준으로 3단계로 나눠라. 무음 구간 / 비동기 알림 구간 / 즉시 대응 구간. 무음 구간 없이 모든 이상을 알리면 알림 피로로 실제 장애를 놓친다.

4. 롤백 타임을 측정하고 5분 이내로 유지하라. 현재 롤백에 얼마나 걸리는지 모른다면 지금 측정하라. 10분이 넘는다면 on-call 도입보다 이 숫자를 줄이는 것이 먼저다.

5. on-call 도입 트리거를 숫자로 미리 정의하라. 지금 당장 on-call이 필요 없더라도, 어떤 조건에서 필요해지는지를 팀 문서에 명시해두라. 그 시점이 왔을 때 논의가 빠르고, 누군가가 암묵적으로 짊어지는 상황을 막는다.

on-call 없는 팀은 가능하다. 단, 그 상태를 의식적으로 선택한 팀만 그렇다. 모르고 없는 팀은 누군가가 혼자 짊어지고 있는 것이다.

— by slecs, HEDVION