무슨 일이 있었나요
세일즈포스가 전 세계적인 장애를 겪었어요. 공식 상태 페이지에 전체 제품군이 영향을 받는 것으로 표시됐고, 세일즈포스를 업무 시스템으로 쓰는 회사들은 영업, 고객지원, 마케팅 업무가 한꺼번에 멈춘 상황이었죠. 정확한 원인은 세일즈포스가 공식 포스트모템을 내놓기 전까지는 단정하기 어려워요. 하지만 원인이 뭐든, 이 사건이 우리에게 던지는 질문은 분명해요. '우리 서비스는 남의 회사가 멈췄을 때 얼마나 버틸 수 있나?'
세일즈포스가 어떤 회사인지 잠깐 짚고 가면요. 전 세계 1위 CRM(고객관계관리) 서비스이고, 슬랙, 뮬소프트, 태블로, 히로쿠까지 다 세일즈포스 산하예요. 그러니까 '세일즈포스 장애'는 영업팀 대시보드가 안 열리는 정도가 아니라, 회사 메신저부터 데이터 파이프라인, 호스팅까지 한 번에 흔들릴 수 있는 사건이에요.
글로벌 장애는 왜 생길까요
'멀티 리전으로 운영하면 한 곳이 죽어도 괜찮은 거 아니야?'라고 생각하실 수 있어요. 맞아요, 데이터 저장이나 애플리케이션 서버는 그렇게 분산돼 있어요. 그런데 어떤 서비스든 전 세계가 공유하는 '컨트롤 플레인'이 있어요. 이게 뭐냐면, 실제 서비스를 돌리는 서버들 위에서 그 서버들을 관리하는 층이에요. DNS(도메인 이름을 IP로 바꿔주는 전화번호부), 인증 시스템, 설정 배포 시스템 같은 것들이죠. 이 층에서 잘못된 변경이 한 번에 전 세계로 퍼지면 리전이 백 개여도 다 같이 죽어요.
실제로 세일즈포스의 과거 큰 장애가 딱 그랬어요. 2021년 5월에는 DNS 설정 변경을 긴급 절차로 전 세계에 한꺼번에 배포했다가 몇 시간 동안 전 제품이 마비됐어요. 원래는 리전별로 조금씩 배포하면서 이상이 있는지 지켜봐야 하는데, 그 단계를 건너뛴 게 문제였죠. 2019년 5월에는 데이터베이스 스크립트 오류로 사용자 권한이 잘못 부여되는 바람에, 데이터를 보호하려고 세일즈포스가 일부러 서비스 접근을 차단해서 15시간 넘게 멈춘 적도 있어요. 두 사건의 교훈은 같아요. 사고는 대부분 '누군가의 변경'에서 시작되고, 그 변경이 전 세계에 동시에 적용될 때 글로벌 장애가 돼요.
우리 서비스에 미치는 영향
'우리는 세일즈포스 안 쓰는데'라고 하실 수 있는데, 직접 안 써도 간접적으로 엮여 있는 경우가 많아요. 리드 정보를 세일즈포스로 동기화하는 웹훅, 고객 문의를 세일즈포스 케이스로 만드는 연동, 슬랙 알림, 히로쿠에 올려둔 사이드 프로젝트까지요. 이런 연동이 하나라도 '동기 호출'로 되어 있으면, 세일즈포스가 느려지거나 죽었을 때 우리 API 응답까지 같이 느려지거나 타임아웃이 나요. 남의 장애가 우리 장애가 되는 순간이죠.
그래서 뭘 해야 하나요
이런 사건이 터질 때마다 다시 꺼내 봐야 하는 체크리스트가 있어요. 하나씩 풀어볼게요.
먼저 외부 의존성 목록을 만들어 두세요. 우리 서비스가 호출하는 외부 서비스가 뭐고, 각각이 죽으면 어떤 기능이 영향을 받는지 표로 정리하는 거예요. 의외로 이걸 안 해둔 팀이 많아요.
다음은 타임아웃과 서킷 브레이커예요. 서킷 브레이커가 뭐냐면, 집의 두꺼비집이랑 똑같아요. 외부 호출이 연속으로 실패하면 일정 시간 동안 아예 호출을 시도하지 않고 바로 실패 처리해서, 우리 서버의 스레드와 커넥션이 죽은 서비스를 기다리다 고갈되는 걸 막아요. Resilience4j, Polly, 혹은 서비스 메시 레벨에서 설정할 수 있어요.
그리고 우아한 성능 저하(graceful degradation)예요. CRM 동기화가 안 되더라도 사용자가 회원가입은 할 수 있어야 하잖아요. 핵심 기능과 부가 기능을 분리해서, 부가 기능이 죽어도 핵심은 살아 있게 만드는 거죠.
마지막으로 쓰기 작업은 큐에 쌓기예요. 외부로 보내야 하는 데이터를 바로 호출하지 말고 큐나 아웃박스 테이블에 넣어두고, 별도 워커가 재시도하면서 보내게 하면 외부 서비스가 복구됐을 때 자동으로 따라잡아요. 이때 재시도에는 백오프(점점 간격을 늘리는 것)를 꼭 넣어야 해요. 복구 직후 모두가 한꺼번에 재시도하면 상대를 다시 쓰러뜨리거든요.
업계 흐름에서 보면
최근 몇 년 사이 대형 장애가 유난히 잦았어요. 2024년 7월 크라우드스트라이크 업데이트로 전 세계 윈도우 PC가 멈췄고, 2025년 10월에는 AWS 버지니아 리전의 DNS 문제로 수많은 서비스가 도미노처럼 넘어졌고, 그다음 달에는 클라우드플레어 장애로 인터넷 곳곳이 에러 페이지를 띄웠죠. 공통점은 다 '중앙에서 관리하는 무언가의 변경'이었다는 거예요. 인프라가 소수의 거대 플랫폼에 집중될수록 한 번의 실수가 미치는 반경은 넓어져요. 이건 세일즈포스만의 문제가 아니라 SaaS 시대의 구조적인 특징이에요.
한국 개발자에게 주는 시사점
국내에서도 B2B 스타트업부터 대기업까지 세일즈포스 도입이 꽤 많아요. 특히 슬랙은 거의 기본 도구가 됐죠. 이번 기회에 우리 팀의 알림, 온콜 호출, 배포 승인 같은 운영 프로세스가 슬랙 하나에 얼마나 묶여 있는지 확인해보세요. 슬랙이 죽으면 장애 대응 자체를 못 하는 팀이 생각보다 많거든요. 최소한 온콜 호출은 슬랙과 별도 채널(전화, SMS)로 이중화해두는 게 좋아요.
그리고 이런 사건은 공식 포스트모템이 나오면 꼭 읽어보세요. 세일즈포스, AWS, 클라우드플레어의 장애 보고서는 대규모 시스템이 어떻게 실패하는지 배우는 최고의 교재예요. 우리 시스템은 훨씬 작지만, 실패 패턴은 놀랍도록 비슷하거든요.
마무리
한 줄로 정리하면, 세일즈포스 글로벌 장애는 '우리가 통제할 수 없는 외부 서비스가 멈췄을 때 우리 서비스는 어떻게 되는가'를 점검하라는 신호예요. 여러분 서비스에서 지금 당장 죽으면 가장 아픈 외부 의존성은 뭔가요? 그리고 그 서비스가 죽었을 때를 실제로 테스트해본 적이 있으신가요?
🔗 출처: Hacker News