Salesforce 장애 2025: 주요 장애 사례 회고

2025년 세일즈포스 장애 기록에서 가장 중요한 결론은 한 해를 규정짓는 단 하나의 "전 세계적인 세일즈포스 장애"가 없었다는 것입니다. 대신 고객들은 여러 가지 다른 유형의 장애를 경험했습니다. 2월에는 광범위한 서비스 중단이 있었고, 6월에는 여러 클라우드에서 인증 오류가 발생했으며, 공급업체의 의도치 않은 업데이트로 인해 Heroku 플랫폼에서 대규모 장애가 발생했습니다. 또한 인디애나폴리스 데이터센터 네트워크 문제도 있었고, 이후에는 특정 인스턴스나 기능에 국한된 장애도 있었습니다. 이러한 구분은 매우 중요합니다. 왜냐하면 어떤 장애가 발생했는지에 따라 적절한 대응책이 달라지기 때문입니다.

사용자가 로그인할 수 없는 경우 브라우저를 새로 고침해도 문제가 해결되지 않습니다. 공개 상태 페이지가 지연되면 일반적인 장애 모니터링 기능도 불완전할 수 있습니다. Salesforce는 사용 가능하지만 통합 큐가 멈춰 있는 경우, CRM 자체는 정상으로 보일 수 있지만 비즈니스 프로세스는 여전히 실패할 수 있습니다. 2025년의 교훈은 테넌트별 상태 알림, 독립적인 모니터링, 검증된 수동 절차, 그리고 하위 시스템에 대한 복구 점검을 결합해야 한다는 것입니다.

2025년 세일즈포스의 주요 혁신은 무엇이었을까요?

다음 사례들은 다양한 실패 유형을 보여주기 때문에 회고에 유용합니다. 하지만 여기에 2025년에 발생할 모든 Salesforce 상태 이벤트가 나열되어 있다는 주장은 아닙니다.

2월 및 Salesforce Trust 관련 장애의 경우 날짜, 범위 및 복구 업데이트는 Salesforce의 장애 기록에서 가져온 것입니다. 2월 7일 서비스 중단 , 6월 10일 크로스 클라우드 인증 장애 , 6월 18일 인디애나폴리스 장애 , 11월 1일 인스턴스 장애 및 12월 31일 WhatsApp 장애가 여기에 해당합니다 .

6월 10일 사건은 서로 다른 두 가지 실패 요인을 드러냅니다.

6월 10일은 특히 중요한데, 그 이유는 "Salesforce 장애"라는 용어가 하나 이상의 사건을 지칭할 수 있기 때문입니다. Salesforce의 신뢰 기록에는 여러 클라우드에 영향을 미치는 다중 요소 인증 실패가 설명되어 있습니다. 이후 Heroku의 시정 조치 보고서에는 UTC 기준 오전 6시에 시작된 플랫폼 서비스 중단이 설명되어 있으며, 이는 공급업체가 프로덕션 인프라에 적용한 의도치 않은 시스템 업데이트로 인해 발생했습니다.

Heroku는 자사 상태 사이트가 영향을 받았음을 인정했습니다. Heroku의 시정 조치 업데이트 에 따르면 , 상태 페이지 디자인 결함과 API 지연으로 인해 타임아웃이 발생했고, 이로 인해 페이지에 활성 장애가 없는 것처럼 보일 수 있었습니다. Heroku는 이에 대한 대응으로 무인 운영 체제 업그레이드를 영구적으로 중단하고, 이미지 감사를 실시하고, 추가 모니터링을 강화하고, 상태 콘텐츠를 캐시하고, 독립적인 커뮤니케이션 계획을 수립하고, 더욱 강력한 장애 대응 절차를 마련했다고 밝혔습니다.

이는 관리자에게 매우 중요한 차이점입니다. 상태 페이지는 서비스 자체가 아니라, 고객이 기다릴지, 장애 조치를 취할지, 지원 사례를 개설할지, 또는 사용자와 소통할지를 결정하는 데 사용하는 페이지입니다. 상태 채널이 영향을 받는 플랫폼과 너무 많은 인프라를 공유하는 경우, 가장 필요한 순간에 안정적인 상태를 제공하지 못할 수 있습니다.

2025년 기록은 세일즈포스 고객들에게 무엇을 알려주었을까요?

1. 인증에는 별도의 지속성 계획이 필요합니다.

팀의 애플리케이션 데이터가 정상적이라 하더라도 로그인, 다단계 인증 또는 연결된 ID 경로에 실패하면 업무를 수행할 수 없습니다. 이는 Salesforce, Heroku, Commerce 및 Marketing Cloud를 함께 사용하는 기업에 특히 중요합니다. 어떤 사용자가 어떤 시스템에 접근해야 하는지 명확히 문서화하고, 공급업체 업데이트를 받을 수 있는 비상 연락처를 지정하며, 로그인에 실패하더라도 계속할 수 있는 업무를 정의해야 합니다.

소규모 영업팀의 경우, 임시방편으로 수동 통화 목록과 공유 장애 로그를 활용할 수 있습니다. 하지만 컨택센터나 의료기관과 같은 대규모 조직에서는 공식적인 시스템 다운 절차, 승인된 읽기 전용 데이터 내보내기, 그리고 검증된 에스컬레이션 트리가 필요할 수 있습니다. 시스템 다운 시 발생할 수 있는 비즈니스 손실 규모에 맞춰 백업 시스템의 규모를 충분히 확보해야 합니다.

2. 일반적인 상태 페이지만으로는 충분하지 않습니다.

Salesforce 자체 문서에 따르면 신뢰 상태는 가용성 및 성능 정보를 제공하며, 최신 My Trust Center 보기는 테넌트 및 지원 제품을 중심으로 설계되었습니다. 핵심은 간단합니다. 문제가 발생하기 전에 인스턴스 또는 테넌트 식별자를 알아두어야 합니다.

Salesforce는 My Trust Center 메시지 및 알림 구독 방법 에 대한 지침도 제공합니다 . 조직을 처음 생성한 관리자뿐만 아니라 조치를 취해야 하는 담당자에게도 알림을 설정하세요. 내부 상태 페이지나 승인된 메시지 그룹과 같은 독립적인 채널을 유지하여 공급업체 상태 사이트가 느리거나 접속이 불가능한 경우에도 회사에서 소통할 수 있도록 하세요.

3. 복구는 로그인 화면을 보는 것 이상의 의미를 지닙니다.

Salesforce에서 서비스 복구 완료를 보고하더라도 문제가 비즈니스에 영향을 미칠 수 있습니다. 예를 들어, 지연된 API 요청은 두 번 재시도될 수 있고, 대기 중인 메시지는 늦게 도착할 수 있으며, 배포 실패로 인해 레코드가 동기화되지 않을 수 있습니다. 복구 후에는 인증, API 호출, 예약된 작업, 통합 대기열, 이메일 또는 메시지 전송, 레코드 생성, 보고서 최신성 등 가장 중요한 워크플로를 확인해야 합니다.

예를 들어, 상담원들이 Salesforce 케이스를 사용하고 별도의 상거래 시스템에서 통합을 통해 업데이트를 전송하는 중간 규모의 지원팀을 생각해 보세요. Salesforce가 오전 10시에 다시 사용 가능해졌지만 통합 대기열에 장애 시간 동안 발생한 실패 메시지가 남아 있는 경우, 브라우저가 로드되었다는 이유만으로 해당 문제를 종결해서는 안 됩니다. 올바른 확인 방법은 새롭게 추가된 케이스 업데이트와 이전에 실패했던 업데이트가 중복 없이 전체 워크플로를 거쳐 처리되는지 여부를 확인하는 것입니다.

귀사에 적합한 비즈니스 연속성 확보 방안은 무엇입니까?

2026년 이후에 이 회고록을 활용하는 방법

한 페이지 분량의 종속성 맵부터 시작하세요. Salesforce 인스턴스 또는 테넌트, ID 공급자, 연결된 클라우드, 중요 통합, 상태 구독, 그리고 장애 발생 시 사용하는 수동 프로세스를 기록하세요. 그런 다음 각 중요 워크플로에 대한 객관적인 복구 점검을 정의합니다. "Salesforce가 복구되었습니다"는 너무 모호합니다. "새로운 사례, 발신 메시지, 주문 업데이트가 중복 없이 처리되고 있습니다"와 같이 구체적으로 테스트 가능한 상태를 정의하세요.

마지막으로, 가용성에 영향을 미칠 수 있는 변경 사항(벤더 업데이트, 운영 체제 변경, 릴리스, 구성 변경, 인스턴스 마이그레이션 등)을 검토하십시오. 6월 Heroku 장애는 무인 변경에 강력한 제어가 필요한 이유와 상태 메시지 전달에 자체적인 복원력이 요구되는 이유를 보여줍니다. 6월 18일 발생한 사건은 클라우드 서비스에서 물리적 용량과 데이터 센터 종속성이 여전히 중요한 이유를 보여줍니다. 12월 기능 저하 사태는 팀이 플랫폼의 최상위 가용성뿐만 아니라 실제로 사용하는 기능도 모니터링해야 하는 이유를 보여줍니다.

따라서 가장 적절한 대응은 상황에 따라 달라집니다. 소규모 조직은 알림과 명확한 수동 체크리스트가 필요할 수 있습니다. 판매나 지원을 중단할 수 없는 기업은 독립적인 모니터링, 대기열 인식 복구, 그리고 숙련된 다운타임 프로세스가 필요합니다. 엄격한 규제를 받는 조직은 검증된 복구, 증거, 그리고 거버넌스가 필요합니다. 2025년 Salesforce 장애 기록은 한 가지 일관된 결론을 뒷받침합니다. 바로 복원력은 단일한 정상 상태 표시기가 아니라 고객의 의존성 사슬을 중심으로 구축된다는 것입니다.

출처 및 범위

본 회고는 작성 시점을 기준으로 Salesforce Trust 인시던트 기록과 Salesforce 또는 Heroku 문서를 활용합니다. 인시던트 페이지는 해결 후 업데이트될 수 있으며, Salesforce의 제품별 지원 범위는 Trust Status와 My Trust Center 간에 차이가 있습니다. Salesforce에서 상세한 근본 원인 분석을 발표하지 않은 경우, 본 문서에서는 이를 추론하지 않습니다.