it-sue

클라우드는 절대 멈추지 않는다는 믿음이 있다. 적어도 지금까지는 그렇게 믿어온 기업이 많았다. 그런데 지난주 세일즈포스에서 벌어진 대규모 장애는 이 믿음이 얼마나 허술한 전제였는지를 다시 보여줬다.

이번 사고는 하필 세일즈포스의 연례 행사인 드림포스 2026 기간에 터졌다. 전 세계 다수 인스턴스에서 서비스가 동시에 멈췄다. 영업, 고객관리, 마케팅 자동화까지 한 번에 마비된 기업이 적지 않았다. 필자가 보기엔 이 사건의 진짜 의미는 장애 시간 자체가 아니다. 클라우드 의존성이라는 구조적 문제가 다시 수면 위로 올라왔다는 점이 핵심이다.

클라우드 의존성이란 무엇이 문제인가

클라우드 의존성은 한 회사의 핵심 업무 시스템이 특정 클라우드·SaaS 공급자 하나에 지나치게 몰려 있는 상태를 말한다. 도입 초기엔 효율적으로 보인다. 인프라를 직접 운영할 필요가 없고 비용도 예측 가능하기 때문이다.

문제는 그 공급자가 멈추는 순간이다. ITWorld 보도에 따르면 이번 장애로 다수 기업의 영업·고객대응 프로세스가 동시에 멈춰 섰다고 알려졌다. 세일즈포스는 장애 원인에 대해 아직 세부 기술 설명을 공식적으로 내놓지 않은 상태다. 다만 업계에서는 특정 리전 인프라 문제로 추정하는 분석이 나온다.

개인적으로는 이 대목이 흥미롭다. SaaS는 원래 ‘믿고 맡기는’ 구조다. 그런데 그 신뢰가 한 번 흔들리면 대안이 마땅치 않다는 게 SaaS의 근본적인 약점이다.

왜 지금 클라우드 의존성이 다시 논쟁거리가 됐나

사실 클라우드 장애는 새로운 이슈가 아니다. 다만 이번 사고가 유독 눈에 띄는 이유는 규모다. 세일즈포스처럼 영업 조직의 뼈대 역할을 하는 SaaS가 멈추면 파급 범위가 다르다.

필자가 보기엔 여기서 짚어야 할 지점은 세 가지다. 첫째, 기업들이 단일 공급자에 얼마나 몰려 있는지. 둘째, 장애 발생 시 대체 프로세스가 준비돼 있는지. 셋째, 복구 시간에 대한 서비스 수준 계약, 즉 SLA가 현실적으로 지켜지는지 여부다.

구분	단일 SaaS 집중 구조	멀티벤더·하이브리드 구조
초기 비용	낮음	상대적으로 높음
운영 복잡도	낮음	높음
장애 시 파급력	전사적으로 확산	부분적으로 제한 가능
복구 유연성	공급자 대응에 의존	자체 우회 경로 확보 가능

표로 정리하면 선택이 쉬워 보인다. 하지만 현실에서 멀티벤더 구조를 택하는 기업은 소수다. 비용과 관리 부담이 만만치 않기 때문이다.

기업들의 전략적 대응, 그리고 한계

이번 사고 이후 일부 대기업은 핵심 업무의 로컬 백업 체계를 다시 점검하고 나섰다고 전해진다. 완전한 이중화는 비용 문제로 쉽지 않다. 그래서 등장하는 절충안이 ‘핵심 기능만 이중화’하는 전략이다.

• 고객 데이터베이스는 별도로 정기 백업해 자체 서버에 보관
• 영업 프로세스 중 결제·계약 단계만 대체 시스템을 마련
• 장애 발생 시 수동 프로세스로 전환하는 매뉴얼 사전 구축

필자가 보기엔 이 흐름은 결국 ‘클라우드를 버리자’가 아니라 ‘클라우드를 맹신하지 말자’는 방향으로 가고 있다. 이미 AI 데이터센터 전력난을 다룬 글에서도 짚었듯, 인프라 리스크는 AI 시대에 더 커지고 있다. 클라우드 의존성 문제도 같은 맥락에서 봐야 한다는 게 필자의 생각이다.

IT-SUE의 시각

이번 세일즈포스 장애를 두고 ‘일회성 사고’로 넘기는 시선도 있다. 하지만 필자는 다르게 본다. 이 사고는 클라우드 의존성이라는 오래된 숙제를 다시 꺼내놓은 계기라고 본다.

기업들이 SaaS를 버릴 수는 없다. 그럴 이유도 없다. 다만 ‘멈추지 않는다’는 전제 위에 모든 업무를 쌓아 올리는 방식은 이제 재검토가 필요하다.

결국 클라우드 의존성을 관리한다는 건 완벽한 대안을 마련하는 게 아니다. 멈췄을 때 얼마나 빨리, 얼마나 적은 피해로 돌아올 수 있는지를 미리 설계해두는 일이다. 이 관점이 앞으로 기업 IT 전략의 새로운 기본값이 될 것이라는 게 필자의 전망이다.