IBM 쇼크가 드러낸 벤더 리스크, 작은 팀의 맹점

IBM 주가가 지난주 급락했다. 메인프레임 판매가 예상을 크게 밑돌았다는 경고 하나에. 그런데 이유가 독특하다 — 메인프레임 기술이 구식이 돼서가 아니라, 기업들이 AI 투자에 예산을 몰아넣느라 정기 하드웨어 갱신을 미뤘다는 것.

IBM CEO는 "일시적"이라고 했다. 이 말을 곧이곧대로 믿어도 되는지가 오늘의 핵심이다. 그리고 이 판단이 우리 같은 작은 팀에게 왜 중요한지. 단, 주의가 필요하다. "대기업 문제니까 우리랑 무관하다"고 넘기는 순간, 정작 챙겨야 할 리스크를 흘리게 된다.

AI 예산이 인프라를 밀어낸다

IBM 메인프레임은 전 세계 신용카드 거래의 상당 비중과 ATM 처리, 글로벌 금융 메시징의 핵심 경로를 담당한다. 숫자 자체를 논쟁하더라도, 글로벌 금융 인프라의 기반이 이 하드웨어 위에 올라가 있다는 건 부인하기 어렵다.

메인프레임 교체 사이클은 보통 3~5년이다. 기업들이 AI 인프라 투자에 집중하면서 이 사이클을 한 번씩 건너뛰기 시작했다. 당장 쓰러지지 않으니까. IBM이 메인프레임에 AI 기능을 통합하며 "AI와 메인프레임은 공존한다"고 항변해도, 투자자들은 숫자가 빠지면 스토리를 보지 않는다.

이게 IBM만의 이야기가 아니라는 점이 문제다. 가트너 2025 조사에서 기업 CIO의 68%가 AI 투자를 위해 다른 IT 예산을 줄였다고 응답했는데, 가장 먼저 희생된 항목이 인프라 갱신과 보안 도구였다. 큰 회사도 이러는데 작은 팀이라고 다를까.

인프라가 늙으면 무슨 일이 생기나

하드웨어 갱신이 미뤄지면 오래된 시스템 위에서 보안 패치로만 버텨야 한다. 단기에는 안 보인다. 장기에는 취약점이 쌓인다.

더 직접적인 건 규제 노출이다. 국내 기준으로 금융보안원 전자금융 취약점 점검, 금감원 IT 부문 검사는 금융사 인프라를 정기적으로 들여다본다. 직접 검사를 받는 금융사의 업스트림 인프라가 노화되면, 그 위에 붙은 API 파트너나 핀테크 서비스도 간접 영향권에 들어올 수 있다.

작은 팀이 "우리는 클라우드 위에 있으니 괜찮다"고 생각하기 쉬운 지점이 여기다. 클라우드는 레이어 중 하나일 뿐이다. PG사, 은행 오픈뱅킹, 결제망 — 이것들은 여전히 전통 금융 인프라 위에 얹혀 있다.

작은 팀이 놓치는 2차·3차 벤더 리스크

직접 거래하는 벤더의 건강은 어느 정도 모니터링한다. 계약 갱신 때쯤 확인하거나, 뉴스에 크게 나면 챙겨본다. 문제는 그 아래층이다.

우리 팀이 쓰는 PG사 — 그 PG사가 의존하는 처리 인프라 — 그 인프라를 제공하는 하드웨어 벤더. 이 사슬 어딘가가 흔들리면 우리는 뒤늦게 안다. 아니, 어쩌면 영원히 모른다. 장애가 나기 전까지는.

직접 해보니 — 우리 서비스의 핵심 의존성을 처음 지도로 그렸을 때, 예상보다 두 단계 더 깊이 들어간 곳에서 단일 벤더 집중 구간이 나왔다. 그때 처음 "만약 여기가 흔들리면 우리는 뭘 할 수 있나?"를 진지하게 생각하게 됐다.

대형 벤더가 재무 압박을 받을 때 나타나는 패턴이 있다. 지원 인력 감소, 보안 패치 주기 연장, 제품 EOL 가속화, 수익성 낮은 고객 방치. IBM이 지금 그렇다는 게 아니다. 다만 어떤 벤더든 실적이 크게 흔들리면 이 패턴이 따라온다. IBM 같은 주가 급락 이벤트는 "우리 벤더 의존성을 한 번 다시 보자"는 트리거로 쓸 수 있다.

"임시적"이라는 말의 두 가지 시나리오

IBM CEO의 "일시적" 발언, 투자자 입장에서는 안심 멘트다. 벤더 의존성을 관리하는 팀 입장에서는 다르게 읽어야 한다.

만약 진짜 임시적이라면 문제없다. 내년에 메인프레임 갱신 사이클이 돌아오면서 실적도 회복된다.

만약 구조적 변화라면? 대형 금융기관들이 AI 인프라 투자를 계속 우선시하고 메인프레임 갱신을 반복적으로 미루면, 금융 인프라 전반이 서서히 노화된다. 이건 5~10년 뒤에 대형 장애나 보안 사고로 표면화된다. IBM이 메인프레임에 AI 개발 기능을 통합하는 방향으로 가는 것도 이 맥락에서 읽어야 한다. AI 레이어가 새로운 공격 표면이 될 수 있다는 점까지 포함해서.

어느 쪽이 맞는지는 지금 모른다. 벤더 CEO의 낙관적 전망은 언제나 낙관적이다. 우리가 할 수 있는 건 두 시나리오를 모두 열어두고 준비하는 것뿐이다.

우리 팀이라면 어떻게 대응했을까

구체적인 시나리오를 하나 그려보자. 우리가 연동한 국내 PG사가 특정 하드웨어 벤더에 핵심 처리 시스템을 의존하고 있고, 그 벤더가 IBM처럼 실적 쇼크를 받는 상황.

첫 번째 행동은 계약서 재검토다. PG 계약에는 SLA 조항이 있다. 99.9% 가용성 보장, 장애 시 통보 의무, 연속 장애 시 크레딧 또는 해지권. 이게 실제로 어떻게 정의돼 있는지 마지막으로 읽어본 게 언제인지 기억하는 팀이 많지 않다.

두 번째는 fallback 경로 확인이다. 메인 PG가 30분 이상 다운됐을 때 우리 서비스가 어떻게 반응하는지 — 에러 메시지가 뜨는지, 대기열에 쌓이는지, 조용히 거래가 소실되는지. 직접 테스트해본 팀이 생각보다 드물다. "SLA가 있으니 괜찮겠지"만 믿다가 실제 장애 때 허둥대는 경우가 많다.

세 번째가 AI 예산 vs 보안·인프라 예산의 균형 문제다. IBM 고객사들이 AI에 예산을 몰아넣다가 인프라 갱신을 미룬 것과 똑같은 선택을 우리도 한다. "AI 도구 쓰면 인력 줄일 수 있어"라는 계산으로 보안 도구나 모니터링 투자를 조용히 미루는 것. 단기 계산은 맞아 보여도 뒤에 따라오는 비용이 있다.

지금 바로 써먹을 수 있는 것

벤더 의존성 지도를 그려라. 우리 서비스가 직접 호출하는 API와 서비스 목록부터 시작해서, 각각이 의존하는 인프라를 한 레이어씩 더 파고들어가는 것. 30분이면 초안이 나온다. 화이트보드에 박스와 화살표로.

그 지도에서 "단일 벤더가 막고 있는 경로"를 찾아라. 이 경로 중 하나가 막히면 서비스 전체가 어떻게 되는지, 다운인지 속도 저하인지 데이터 유실인지.

계약서 SLA 조항은 지금 꺼내 읽어라. 특히 "장애 통보 의무"와 "해지권 발동 조건". 이걸 모르면 피해를 입고도 어떤 권리가 있는지 모른 채 넘어간다.

IBM 같은 대형 벤더의 실적 발표를 "저 회사 주가 빠졌네" 하고 넘기지 말고, "내 서비스와 연결된 사슬 어딘가에 이 여파가 닿지 않는지" 한 번 짚는 습관. 이게 작은 팀이 가질 수 있는 가장 현실적인 리스크 관리다.

원문: AI News & Artificial Intelligence | TechCrunch