외부 서비스 간 장애 전파

Microsoft 서비스 장애 가 생각보다 오랫동안 지속되고 있다. 이에 따라 Microsoft 365와 Outlook 커넥터 이상으로 OpenAI와 Claude 서비스 에도 영향이 이어진 것으로 보인다.

한 곳의 장애가 연쇄적으로 번지는 구조

이제는 내부 마이크로서비스에서의 서비스 간 장애 전파(Cascading Failure)를 넘어 외부 서비스와의 연계 가 훨씬 많아진 상황이다. 한 서비스의 장애가 그곳을 이용하는 다른 서비스로 고스란히 전파되면서, 메일 인프라가 멈추면 그에 묶여 있던 2단계 인증이나 자동화 훅까지 함께 작동하지 않는 상황으로 이어진다.

요즘 SaaS 제품 하나를 운영하려 해도 AI 모델 API, 결제(PG), 본인인증, 외부 데이터 연동 등 수많은 외부 시스템이 필요하다. 여기에 사용자가 구독 중인 AI 에이전트가 서비스 데이터를 활용할 수 있도록 MCP(Model Context Protocol)까지 제공하는 흐름이 겹치면서 양방향 연계는 더 복잡해질 수 있다.

연동 지점이 늘어날수록 외부 API 지연이 본 서비스의 자원 고갈로 번지거나, 인증 사업자·메일 인프라 하나의 장애로 서비스 접속 자체가 막힐 위험이 커진다. MCP와 같은 외부 서비스 커넥터처럼 외부 에이전트에 데이터를 열어 둔 구조에서는 반대로 에이전트 측 장애와 재시도 폭주가 서비스 부하로 되돌아오거나, 외부의 의심스러운 요청들을 받아내는 취약한 경로 가 될 여지도 있다.

기능 확장보다 보안 점검부터

외부 연동을 피할 수는 없지만, 연결된 상대가 언제든 멈출 수 있다는 전제 위에서 타임아웃·서킷 브레이커로 연동 경로를 격리하고 인증 수단을 분산 해 두어야 한다.

개인적으로도 최근 잇따르는 침해 사고와 이번 연쇄 장애를 보면서, 서비스 데이터를 외부 AI 에이전트에 열어 주는 MCP 기능을 안정적으로 제공할 수 있을지 의문이 들어 도입을 보류하고 있다. 얼마 전에도 레거시 코어의 취약한 경로 를 통해 외부 공격자가 의심스러운 계정을 만들고 여러 백엔드 경로에 IDOR 요청을 시도한 이력을 확인했다. AI 에이전트가 없던 시절에 귀찮다는 이유로 보안을 대충 넘기던 과거의 개발 패턴부터 되돌아봐야 한다. 내부 API의 인증과 권한 경계도 완벽히 통제하기 쉽지 않은 상황에서, 지금은 무리하게 새 연동 기능을 열기보다 기본적인 공격 표면의 인증과 권한 관리 취약점을 먼저 점검 하는 편이 우선이다.

사용하지 않는 도메인과 주소는 제발 좀 정리하자...