세일즈포스가 2026년 9월 16일 오전(태평양시 기준 12시 50분경 시작) 전 리전에 걸친 서비스 장애를 겪었다. 회사 설명에 따르면 요청이 내부 로그인 서비스의 응답을 기다리며 정체됐고, 그 대기가 가용 서버 자원을 소진시키면서 핵심 구성요소로 부하가 번졌다.
복구는 함대 전체에 대한 단계적 수정 배포와, 자동 수정이 완료되지 않은 인스턴스에 대한 수동 재시작을 병행해 이뤄졌다. 하필 연례 행사인 드림포스 개막과 시점이 겹쳤다.
이 장애가 기술적으로 흥미로운 이유는 원인이 특별하지 않다는 데 있다. 디스크가 터지거나 데이터센터가 불탄 게 아니다. 한 의존 서비스가 느려졌고, 그걸 기다리는 요청이 쌓였을 뿐이다. 분산 시스템에서 가장 흔하고 가장 자주 과소평가되는 실패 모드다.
무슨 일이 있었나
왜 "느려짐"이 "전면 장애"가 되나
요청 처리 스레드(또는 커넥션·고루틴)는 유한한 자원이다. 의존 서비스가 응답하지 않으면 그 요청은 자원을 점유한 채 기다린다. 초당 유입이 일정한데 처리 시간만 10배로 늘면, 동시 점유 수도 10배가 된다. 리틀의 법칙이 그대로 작동한다.
# 리틀의 법칙: 동시 처리 수 L = 도착률 λ × 평균 체류시간 W
#
# 평상시: λ=500 req/s, W=0.05s → L = 25 (스레드 25개면 충분)
# 지연 시: λ=500 req/s, W=5s → L = 2500 (스레드 풀 200개는 즉시 고갈)
#
# 고갈되면 로그인과 무관한 요청까지 대기열에서 굶어 죽는다.
# 이게 "로그인 하나 느려졌는데 전체가 죽는" 메커니즘이다.같은 실패를 막는 네 가지 장치
| 장치 | 하는 일 | 설정 감각 |
|---|---|---|
| 타임아웃 | 대기 상한을 강제 | p99 응답시간의 2~3배. 상위 요청 예산보다 짧게 |
| 격벽(bulkhead) | 의존별로 자원 풀 분리 | 로그인용 커넥션 풀과 일반 조회용 풀을 분리 |
| 서킷 브레이커 | 실패율 임계 초과 시 즉시 실패 | 열림 상태에서도 소량 탐색 요청으로 회복 감지 |
| 부하 제한(load shedding) | 한계 넘으면 일부 요청 거절 | 큐 대기시간 기반. 대기 오래된 요청은 버리는 편이 낫다 |
네 가지 중 실무에서 가장 자주 빠지는 건 격벽이다. 타임아웃과 서킷 브레이커는 라이브러리가 챙겨 주지만, "로그인 호출용 자원과 그 외 자원을 나눈다"는 결정은 아키텍처 차원의 의도가 있어야 생긴다. 이번 사례처럼 인증 경로 하나가 전체를 끌어내리는 구조에서는 이 분리가 가장 큰 차이를 만든다.
복구 방식에서 읽을 것 — 왜 수동 재시작이 필요했나
공지에서 눈에 띄는 대목은 자동 수정이 완료되지 않은 인스턴스를 수동으로 재시작했다는 부분이다. 자원이 완전히 고갈된 프로세스는 스스로 회복하지 못하는 경우가 많다. 수정 코드가 배포돼도, 이미 잠긴 스레드가 풀리지 않으면 상태가 그대로다. 그래서 대형 장애의 마지막 단계는 거의 항상 재시작이다.
마지막 항목은 농담이 아니다. 상태 페이지가 같은 인프라 위에 있어서 장애 때 함께 죽는 사례는 매년 반복된다.
출처
- The Register, "Salesforce staggers back to feet after global outage" (2026-09-16) — https://www.theregister.com/saas/2026/09/16/salesforce-staggers-back-to-feet-after-global-outage/
- Salesforce Ben, "Salesforce Hit by Global Service Disruption During Dreamforce 2026" — https://www.salesforceben.com/salesforce-hit-by-global-service-disruption-during-dreamforce-2026/
- IsDown, Salesforce Service Disruption 인시던트 기록 (2026-09) — https://isdown.app/status/salesforce/incidents/655252-service-disruption
자주 묻는 질문
이번 세일즈포스 장애의 원인은 무엇인가요?
내부 로그인 서비스의 응답을 기다리는 요청이 쌓이면서 가용 서버 자원이 소진된 것이 원인으로 설명됐습니다. 회사는 레거시 로그인 서버에 영향을 준 외부 의존성 실패를 지목했습니다. 데이터 유실이나 침해로 인한 장애는 아니었습니다.
얼마나 오래 지속됐나요?
태평양시 기준 9월 16일 0시 50분경 시작돼 같은 날 오전 중 단계적으로 복구됐습니다. 함대 단위 수정 배포와 일부 인스턴스의 수동 재시작을 거쳐 텔레메트리로 정상화가 확인됐습니다.
왜 로그인 문제 하나가 전체 서비스를 멈추나요?
요청 처리 자원이 유한하기 때문입니다. 한 의존 서비스가 느려지면 그것을 기다리는 요청이 스레드와 커넥션을 점유한 채 쌓이고, 결국 무관한 요청까지 처리하지 못하게 됩니다. 타임아웃과 자원 풀 분리가 없으면 이 전파를 막지 못합니다.
우리 서비스에서 같은 문제를 어떻게 예방하나요?
모든 외부 호출에 타임아웃을 걸고, 인증 같은 핵심 의존성에 별도 커넥션 풀(격벽)을 두며, 서킷 브레이커와 부하 제한을 함께 적용하세요. 그리고 헬스체크가 실제 처리 가능 여부를 반영하도록 만들어 고갈된 인스턴스가 자동 교체되게 하는 것이 중요합니다.
SaaS 장애에 대비해 고객사가 할 수 있는 일이 있나요?
핵심 업무 흐름에 대해 저하 모드를 정의해 두는 것입니다. 예를 들어 CRM이 멈췄을 때 영업 활동을 임시 기록할 경로, 주문 처리를 큐에 쌓아 두는 방식 등입니다. 또한 SaaS API 호출에도 타임아웃과 재시도 상한을 두어 자사 시스템으로 장애가 전파되지 않게 해야 합니다.
댓글 0