[관점]
이 사안이 국내에서 실제로 걸리는 지점은 기술이 아니라 책임 소재다. 제품이 외부 모델을 호출한다는 사실은 대개 계약서 어디에도 적혀 있지 않다. 장애가 발생하면 보안 벤더는 모델 제공자를 가리키고, 모델 제공자는 이용약관을 가리킨다. 그 사이에 남는 것은 우리 조직의 설명 책임과 신고 의무뿐이다.
몇 해 전 클라우드가 지나온 경로를 AI 기능이 그대로 반복하고 있다. 처음에는 부가 기능으로 취급되어 심사 항목에 들어가지 않다가, 사고 한 건을 겪은 뒤에야 별도 항목이 된다. 그 사이에 도입한 제품은 소급해서 다시 심사해야 한다.
그래서 도입 심사에서 물어야 할 질문은 「AI 를 쓰는가」가 아니다. 「그 AI 가 멈추면 무엇이 남고, 누가 무엇을 책임지는가」다. 이 질문에 답하지 못하는 제안은 기능 목록이 아무리 길어도 평가를 통과시킬 이유가 없다.
2026년 6월 9일 출시된 프런티어 모델 하나가 사흘 뒤인 6월 12일 전 세계에서 차단되었다. 미국 수출통제 지침에 따른 조치였다. 모델의 성능이나 안전성이 문제가 된 것이 아니다. 제품과 무관한 외부 결정 하나로 모델이 사라졌다.
그 모델 위에 제품을 올려 둔 벤더에게 이 사흘은 일정 지연이 아니라 기능의 소멸이었다.
「AI-native」의 실체는 「AI-dependent」
시장에서 「AI 네이티브」로 표방되는 보안 제품의 상당수는 실제로는 「AI 의존」 제품이다. Pentera 는 이 명명의 간극을 문제의 출발점으로 삼는다.
개발 속도 자체는 실재한다. 외부 모델을 호출하는 구조 덕분에 기능 반복이 빠르고, 자체 모델을 학습시키는 부담 없이 신규 기능을 붙일 수 있다. 문제는 그 속도가 어디에서 나오는가에 있다. 속도를 만드는 지점이 곧 의존이 발생하는 지점이다.
이 구조에서 제품의 가용성은 벤더가 통제하지 못한다. 모델 제공자의 정책, 상위 규제 기관의 결정, 요금 체계 변경, 버전 폐기 일정이 모두 제품 바깥에 있다. 구매자 관점에서 보면 계약 상대는 보안 벤더 한 곳인데 실제 의존 대상은 두 곳이고, 두 번째 상대와는 아무 계약 관계가 없다.
제품의 실체 — 모델이 아니라 하네스
모델 자체보다 그 주변의 오케스트레이션·검증·폴백 구조, 즉 하네스(harness)가 실제 제품이다.
모델은 누구나 같은 것을 호출한다. 경쟁 제품 셋이 동일한 모델을 쓰고 있다면 모델은 변별 요소가 아니다. 차이는 그 위에 무엇을 얹었는가에서 발생한다. 입력을 어떻게 구성하는지, 출력을 어떻게 검증하는지, 모델이 응답하지 않을 때 무엇으로 대체하는지, 모델을 교체할 때 무엇을 다시 만들어야 하는지가 제품의 실체다.
이 관점은 구매 평가에 그대로 적용된다. 「어떤 모델을 씁니까」는 절반의 질문이고, 「모델을 바꿀 수 있습니까」가 나머지 절반이다. 교체가 불가능하다면 하네스 없이 모델을 감싼 껍데기만 있다는 뜻이 된다.
네 가지 위험
외부 모델 의존이 만드는 위험은 네 갈래다.
| 위험 | 내용 |
|---|---|
| Availability · 가용성 | 모델 단종, 정기적 버전 폐기, 잦은 API 중단이 제품 기능의 가용성을 벤더 통제 밖에 둔다 |
| Concentration · 집중 | 여러 벤더가 동일 기반 모델을 사용하면 다양화 효과가 사라지고 동시 장애가 발생한다 |
| Reliability · 신뢰성 | 비결정적 출력과 사전 고지 없는 모델 갱신으로 감사 추적이 성립하지 않는다 |
| Data confidentiality · 데이터 기밀성 | 민감 데이터가 외부 API 로 전송되고 제공자 측에 로그로 보관된다 |
국내 구매 검토에서 가장 과소평가되는 것은 두 번째다. 조직은 벤더를 나누면 위험도 나뉜다고 전제하지만, 기반 모델이 같으면 그 전제가 성립하지 않는다.
세 번째 위험은 국내에서 조금 다른 형태로 나타난다. 감사 추적 문제는 규제 대응 문서보다 사고 조사에서 먼저 드러난다. 같은 입력에 대해 지난달과 이번 달의 판정이 다르면, 그 사이에 무엇이 바뀌었는지 조직이 설명하지 못한다. 모델 갱신이 고지 없이 이루어졌다면 로그를 아무리 뒤져도 원인이 나오지 않는다.
벤더 선정 시 확인 항목
- 사용 중인 모델을 다른 모델로 전환할 수 있는가?
- 모델이 불가용 상태가 되면 제품은 어떻게 동작하는가?
- 모델 버전이 변경될 때 사전 고지가 있는가?
- 민감 데이터가 외부 API 로 전송되는가, 그 처리는 약관 어디에 규정되어 있는가?
국내 적용 관점
AI 기능의 외부 API 호출은 국내 금융권에서 「클라우드 서비스 이용」에 해당할 수 있으므로, 제품 도입 심사와 클라우드 이용 절차를 같은 트랙에 놓아야 한다. 국내 금융회사는 클라우드 이용 시 중요업무 해당 여부 판단, 안전성 평가, 업무 위·수탁 처리를 거친다. 그런데 보안 제품 도입은 통상 정보보호 부서의 솔루션 심사 트랙으로, 클라우드 이용은 IT기획·준법 트랙으로 각각 진행된다. 제품의 AI 기능이 외부 API 를 호출한다는 사실이 계약 직전에 확인되면 절차를 처음부터 다시 밟게 된다. 네 가지 위험 중 1·2번은 기술 위험이지만, 국내에서 실제로 도입을 지연시키는 것은 이 절차 충돌이다.
**「로그만 전송한다」는 벤더 설명을 그대로 수용하지 않고 실제 전송 payload 샘플을 요구해야 한다.** 네 번째 위험은 국내에서 개인정보 국외이전 요건으로 직결된다. 실무에서 반복되는 장면은 이렇다. 벤더는 「개인정보는 보내지 않고 로그만 보낸다」고 설명하고, 심사자는 그 설명을 전제로 국외이전 검토를 생략한다. 그러나 국내 환경의 보안 로그에는 사번 기반 계정명, 임직원 실명이 포함된 AD 표시 이름, 단말 자산번호, 내부 IP 가 통상 함께 담긴다. 이 조합은 개인 식별이 가능한 정보로 판단될 여지가 있다. 설명이 아니라 실제 전송 데이터를 필드 단위로 확인하는 절차를 PoC 요구사항에 명시해 두면 이 쟁점이 계약 이후로 넘어가지 않는다.
망분리 환경이라면 제품소개서의 기능 목록이 아니라 자사 환경에서 실제로 활성화되는 기능 목록으로 비교표를 다시 만들어야 한다. 외부 API 호출을 전제한 기능은 망분리 구간에서 쓸 수 없다. 그런데 국내 조달 평가표는 벤더가 제출한 기능 목록을 기준으로 배점하는 경우가 많아, 실사용이 불가능한 기능에 점수가 배분된다. 결과적으로 자사 환경에서 동작하지 않는 항목이 선정 근거가 된다. 평가표를 만들 때 각 기능에 「외부 통신 필요 여부」 열을 하나 추가하면 이 문제의 상당 부분이 해소된다. 폴백 구조 요구는 국내 맥락에서 「외부 API 없이 축소 동작하는 모드가 있는가」라는 질문으로 옮겨진다.
도입 심사 질문지
질문 1 어떤 모델을 사용하는가? 교체가 가능한가?
교체 시 기능 저하의 범위는 어디까지인가?
질문 2 외부 API 장애 시 제품은 어떤 상태가 되는가?
기능 정지인가, 축소 동작인가?
질문 3 전송되는 데이터의 실제 payload 샘플을 제출할 수 있는가?
마스킹·비식별 처리는 어느 시점에 수행되는가?
질문 4 전송 데이터가 모델 학습에 재사용되는가?
계약서 어느 조항에 규정되어 있는가?
질문 5 API 처리 리전은 어디인가? 국내 처리 옵션이 있는가?
질문 6 동일 입력에 대한 출력 로그가 보존되는가?
사고 조사 시 재현 절차가 있는가?
질문 7 모델 제공자의 정책 변경 시 고지 의무가 계약에 있는가?출처 · Pentera, When Someone Pulls the AI Plug (2026-06-17, Erez Yalon)