leangnews
Command Palette
Search for a command to run...
2026년 03월 05일 12:12
펜타곤 벤더 차단이 드러낸 기업의 숨은 AI 의존성 지도
기사 요약
- 미 정부의 ‘Anthropic 사용 중단’ 지침은 6개월 유예를 줬지만, 다수 조직은 자사 워크플로에서 해당 모델 위치조차 파악 못 하고 있다.
- 조직이 승인했다고 믿는 것과 실제 프로덕션에서 돌아가는 것 사이의 간극이 크며, AI 벤더 의존성은 계약을 넘어 다단계 공급망 전반으로 확산된다.
- 지금 당장 실행 경로 맵핑·통제 지점 확보·킬 테스트·하위 처리자 공개 요구를 30일 내 수행하라.
배경: 6개월 유예가 전제하는 ‘보이지 않는 지도’
미 연방 정부가 모든 기관에 Anthropic 기술 사용 중단을 지시하며 6개월의 전환 기간을 제시했다. 이는 각 기관이 이미 자사 워크플로 어디에 Anthropic 모델이 들어와 있는지 알고 있다는 전제를 깔지만, 현실에서 그 지도를 갖춘 곳은 드물다. 기업도 사정은 같다. 많은 조직이 승인했다고 믿는 것과 실제 프로덕션에서 돌아가는 것 사이의 간극이 크며, AI 벤더 의존성은 1차 계약을 넘어 협력사와 그들의 협력사, 그리고 조달 검토 없이 도입된 SaaS 기능 속으로 연쇄 확산된다.
숫자로 본 가시성 격차
2026년 1월 Panorays의 미국 CISO 200명 조사에서 소프트웨어 공급망을 ‘완전 가시화’했다고 답한 비율은 15%에 그쳤다(전년 3%에서 증가). BlackFog 조사에 따르면 500인 이상 기업 근로자의 49%가 승인 없이 AI 도구를 사용했고, 임원진의 69%는 이를 문제 삼지 않았다. 보안팀 레이더에 잡히지 않는 AI 벤더 의존성이 쌓이다가, 강제 마이그레이션이 촉발되는 순간 모두의 문제가 된다. Enkrypt AI의 CSO이자 AWS 전 부 CISO인 Merritt Baer는 “보안 프로그램은 정적 자산에 맞춰 설계됐지만, AI는 동적·조합적이며 점점 더 간접적”이라고 말했다.
벤더 관계가 하룻밤에 끊길 때
이번 지침은 정부가 특정 AI 공급자를 대상으로 시도한 전례 없는 강제 전환이다. 단일 AI 벤더에 핵심 업무를 의존하는 모든 기업도 같은 위험을 안고 있다. IBM의 2025 데이터 유출 비용 보고서는 섀도우 AI 사고가 전체 침해의 20%를 차지하고 평균 유출 비용을 최대 67만 달러까지 높인다고 지적한다. 재고조차 없는 인프라에 전환 계획을 실행할 수는 없다.
당신의 회사가 Anthropic과 직접 계약하지 않았더라도, 협력사는 그럴 수 있다. 예컨대 CRM의 분석 엔진에 Claude가 내장돼 있거나, 고객지원 티켓 처리마다 모델 호출이 일어날 수 있다. 상류에서 벤더 차단이 발생하면 노출은 하류로 급속히 전파된다. Anthropic은 미국 상위 10대 기업 중 8곳이 Claude를 사용한다고 밝힌 바 있으며, 이들의 공급망에 속한 조직은 계약 여부와 무관하게 간접 노출된다. 국방부 대형 계약을 보유한 AWS와 Palantir 역시 펜타곤 비즈니스를 유지하려면 Anthropic과의 상업적 관계를 재평가해야 할 수 있다. 공급망 위험 지정은 국방부와 거래하는 모든 기업이 자사 워크플로가 Anthropic과 접점이 없음을 입증해야 함을 의미한다.
모델은 호환 부품이 아니다
Baer는 “모델은 상호 교체 가능하지 않다. 벤더를 바꾸면 출력 형식, 지연 특성, 안전 필터, 환각 프로파일이 달라진다. 기능만이 아니라 통제를 재검증해야 한다”고 강조한다. 그녀는 트리아지와 영향 범위 평가로 시작해 행동 드리프트 분석을 거쳐 자격증명·통합 교체로 끝나는 절차를 제시했다. “키 교체는 쉽다. 하드코딩된 의존성, 벤더 SDK 전제, 에이전트 워크플로를 풀어내는 과정에서 시스템이 흔들린다.”
로그로는 보이지 않는 AI 벤더 의존성
한 국방 고위 관계자는 Claude 분리를 “엄청난 골칫거리”라고 표현했다. 세계에서 가장 자원이 풍부한 보안 조직조차 그렇다면, 귀사의 CISO는 얼마나 걸릴까? 과거 SaaS 확산기에는 섀도우 IT가 로그인·데이터 저장소·로그 항목 등 ‘가시적 흔적’을 남겼고, 보안팀은 CASB·SSO·지출 분석으로 따라잡을 수 있었다. 하지만 AI 벤더 의존성은 다른 양상이다. 다른 벤더의 기능 속에 파묻혀 동적으로 호출되고, 비결정적으로 동작하며, 불투명하다. 어떤 모델과 공급자가 실제로 쓰이는지조차 모를 때가 많다.
월요일 아침에 당장 할 4가지
1) 벤더 목록이 아닌 실행 경로를 맵핑하라
게이트웨이·프록시·애플리케이션 계층에서 어떤 서비스가 어떤 엔드포인트로 어떤 데이터 등급을 담아 모델 호출을 하는지 기록하라. 정적 목록이 아닌 실시간 사용 지도를 만든다. 이 과정을 통해 AI 벤더 의존성의 실제 흐름을 드러낼 수 있다.
2) 내가 소유한 통제 지점을 확보하라
벤더 경계만 통제하면 이미 게임은 끝났다. 입력(모델로 유입되는 데이터), 출력(하류로 허용되는 결과), 오케스트레이션(에이전트·파이프라인이 동작하는 층)에서 정책을 강제하라.
3) 최상위 의존성에 ‘킬 테스트’를 시행하라
가장 중요한 AI 벤더를 골라 스테이징 환경에서 제거를 가정한다. API 키를 차단하고 48시간 모니터링하며, 무엇이 끊기고, 조용히 성능이 저하되며, 기존 사고 대응 체계에 없는 오류가 무엇인지 문서화하라. 숨은 의존성이 표면화된다.
4) 하위 처리자와 모델 공개를 요구하라
AI 공급사는 의존 모델, 호스팅 위치, 폴백 경로를 답할 수 있어야 한다. 그렇지 못하면 ‘4차 벤더’ 블라인드 스폿이다. 관계가 안정적일 때 질문하라. 차단이 시작되면 협상력이 급격히 이동하고 답은 너무 늦게 온다.
통제의 착각을 걷어내기
기업은 특정 AI 벤더를 ‘승인’했다고 여기지만, 실제로 승인한 것은 인터페이스일 뿐이고, 진짜 의존성은 한두 층 더 아래에 있다. 스트레스 상황에서 무너지는 것도 그 지점이다. 이번 조치는 한 조직의 기상 이변에 불과하다. 규제·계약·운영·지정학 등 어떤 촉발 요인이든, 모든 기업은 언젠가 비슷한 상황을 맞는다. AI 벤더 의존성을 하위 티어까지 맵핑하고, 킬 테스트를 돌리고, 공개를 받아내라. 30일을 스스로에게 부여하라. 다음 강제 마이그레이션은 6개월의 경고를 주지 않을 수 있다.