AI 출처 증명이 없을 때 생기는 벤더 리스크

AI 응답이 "정말 그 모델에서 나왔는지" 확인할 방법이 없다면, 그 AI를 쓰는 팀은 지금 무엇에 의존하고 있는 걸까.

Anthropic이 FlashProve라는 프로젝트를 공개했다. 핵심은 간단하다 — AI 응답이 특정 모델에서 실제로 생성됐음을 암호학적으로 증명하는 시스템. 누구나 응답 하나를 집어다가 "이게 Claude 3.5 Sonnet에서 나온 게 맞나?" 하고 외부 검증을 돌릴 수 있게 하겠다는 것이다.

뉴스 자체는 짧고 기술적이다. 그런데 보안·규제·벤더 리스크라는 렌즈를 대면, 이 짧은 발표가 작은 팀에게 던지는 함의가 꽤 무겁다. 단, 그 함의를 올바로 읽으려면 먼저 왜 지금까지 이 문제가 묻혀 있었는지를 짚어야 한다 — 거기서 함정이 나온다.

---

왜 지금 이 문제가 불거졌나

AI API를 호출하는 쪽은 사실 아무것도 보장받지 못한다. OpenAI나 Anthropic 서버가 "gpt-4o 응답입니다"라고 돌려줬을 때, 그게 정말 gpt-4o인지 확인할 수단이 없다. HTTP 응답 본문에 모델명이 적혀 있지만, 그건 그냥 JSON 필드에 쓰인 문자열이다.

대형 벤더가 대규모로 모델을 위조할 동기는 없다. 문제는 다른 곳에서 온다.

첫째, 프록시 레이어. 많은 중소팀이 Anthropic이나 OpenAI를 직접 치지 않고 LiteLLM, OpenRouter, 사내 게이트웨이 같은 미들레이어를 경유한다. 이 미들레이어가 오래된 캐시를 돌려주거나, 비용 절감을 위해 몰래 cheaper 모델로 라우팅해도 클라이언트는 모른다. 2025년에 여러 LLM 프록시 서비스가 "GPT-4를 쓰면서 실제로는 3.5를 돌렸다"는 의혹을 받았고, 일부는 커뮤니티 역공학으로 사실로 확인됐다.

둘째, 공급망 공격. 모델 웨이트를 직접 호스팅하거나 오픈소스 모델을 배포하는 경우, 체크포인트가 변조됐는지 알 방법이 없다. npm 패키지 공급망 공격이 수십만 프로젝트에 백도어를 심은 것처럼, 모델 파일에서도 충분히 가능한 경로다.

셋째, 그리고 작은 팀이 가장 흘려듣는 쪽인데 — 규제 책임 추적 문제.

---

규제가 "어떤 모델이었나"를 묻기 시작한다

EU AI Act는 2025년 8월부터 단계적으로 적용되고 있다. 고위험 AI 시스템(채용·신용평가·의료 보조 등)에 해당할 경우, 사용한 AI 모델과 버전을 로그로 남기고 감사 추적이 가능해야 한다. 한국도 2025년 AI 기본법이 국회를 통과하면서, 고위험 AI 사용에 대한 사후 추적 의무가 명시되기 시작했다.

이건 "어떤 API를 호출했나" 로그를 남기는 것과 다른 얘기다. 감사 시점에 "이 응답이 정말 그 모델에서 나왔음"을 사후 검증할 수 있어야 한다. 내가 Claude 3 Sonnet를 썼다고 기록해뒀어도, 그게 사실인지 사후 검증이 불가능하면 그 기록은 증거 능력이 없다.

FlashProve가 하려는 게 바로 이 지점이다. 응답과 함께 암호학적 증명을 붙여서, 나중에 규제 당국이든 고객이든 그 증명을 직접 검증할 수 있게 하는 것. 기술적으로는 영지식 증명(ZK Proof) 계열일 가능성이 높다. 흥미로운 맥락이 있는데 — 최근 AI가 50년 된 수학 난제들을 풀어내면서 ZK proof의 계산 복잡도 경계가 급속히 재정의되고 있다. FlashProve가 얼마나 현실적인 레이턴시로 작동할지는, 이런 수학적 진보와 직접 연결된다.

---

작은 팀에게 더 무거운 이유

대형 팀은 AI 거버넌스 담당자가 별도로 있고, 벤더 계약서에 모델 버전 고정 조항을 넣는다. 작은 팀은 그런 거 없이 API 키 하나로 돌린다. 이 차이가 세 가지 취약점으로 나타난다.

벤더 버전 드리프트. 대형 벤더들은 같은 모델 alias로 조용히 버전을 교체한다. gpt-4o라고 불러도 6개월 전과 지금 행동이 다를 수 있다. 자동화 파이프라인이 모델 출력 형식에 의존하고 있다면, 어느 날 갑자기 형식이 달라지거나 톤이 바뀐다. 대형 팀은 모델 버전을 핀해놓고 업그레이드를 의도적으로 통제하지만, 소규모 팀은 이걸 발견하는 데 며칠 혹은 몇 주가 걸린다.

벤더 협상력 제로. 증명할 수 없다는 건 협상력도 없다는 뜻이다. "이 품질을 보장하라"고 계약서에 쓸 수도 없고, 품질이 떨어졌다는 주장을 뒷받침할 증거도 없다. FlashProve 같은 시스템이 보편화되면 오히려 소규모 팀이 벤더에게 "이 버전이 맞는지 증명하라"고 요구할 근거가 생긴다.

내부 로그 위조 가능성. 오픈소스 모델(llama, mistral 계열)을 직접 호스팅하는 경우, 내부 개발자가 모델을 교체해도 외부에서 알 수 없다. 사고 발생 시 "어떤 모델이 그 출력을 냈나"를 역추적하는 포렌식 체계가 없다면, 감사는 말 그대로 불가능해진다.

우리 팀에서 블로그 봇을 운영하면서 처음엔 모델 버전을 그냥 claude-haiku로만 로그에 남겼는데, 나중에 같은 프롬프트 품질이 왜 달라졌는지 역추적하려다 로그만으로는 어떤 하위 버전이었는지 특정이 안 됐다. 사소해 보이지만, 출력 품질 감사를 해야 하는 상황이 되면 꽤 답답하다.

---

모델 출처 증명이 없을 때 실제로 생기는 일

가상이지만 현실적인 시나리오. 의료 정보를 보조하는 소규모 B2B SaaS가 있다. "Claude 3.5 Sonnet 기반으로 응답을 생성한다"고 고객사에 고지했다. 비용 절감 압박으로 운영팀이 미들레이어 캐시 TTL을 72시간으로 늘렸다. 72시간 된 캐시 응답이 최신 의학 정보와 달라진 경우, "어떤 시점의 어떤 모델이 그 응답을 냈나"를 증명할 방법이 없다.

규제 감사가 들어오면? 로그에 "Claude 3.5 Sonnet"이라고 적혀 있어도, 그게 실시간 생성이었는지 캐시였는지, 버전이 정확히 맞는지 확인 불가. 그 로그는 "우리가 그렇게 적었다"는 주장일 뿐, 증거가 아니다.

의료 도메인만의 얘기가 아니다. 금융 보조, 채용 필터, 법률 초안 보조 — AI를 쓴다고 명시하고 특정 모델을 근거로 고객에게 서비스를 파는 순간, 모델 출처 증명은 계약 이행 문제가 된다. 작은 팀일수록 이런 계약을 맺을 때 이 리스크를 인지하지 못한 채 사인하는 경우가 많다.

---

지금 당장 쓸 수 있는 대응

FlashProve는 연구 단계다. 프로덕션에서 쓸 수 있으려면 최소 1~2년은 걸릴 것이다. 그게 "지금은 아무것도 안 해도 된다"는 뜻이 아니라는 건 말할 필요도 없다.

모델 버전을 정확하게 로그에 박아라. claude-haiku가 아니라 claude-haiku-4-5-20251001처럼 날짜 붙은 정확한 모델 ID를 남겨야 한다. API 응답 헤더나 본문에 모델 ID가 대부분 포함돼 있으니, 그걸 그대로 저장하면 된다. 이건 비용 0, 코드 한 줄이다.

프록시 미들레이어를 거친다면, 모델 ID 일치 여부를 주기적으로 검증해라. OpenRouter 같은 서비스는 실제로 호출된 모델명을 응답에 포함한다. 요청 시 지정한 모델명과 응답의 모델명이 일치하는지 assertion 하나를 붙여두면, 무언가 어긋날 때 즉시 감지된다.

고객 계약서에 "어떤 모델을 쓴다"고 명시했다면, 날짜 ID로 버전을 고정(pin)해라. Anthropic과 OpenAI 모두 날짜 ID가 붙은 버전은 일정 기간 고정 지원한다. 자동 업데이트되는 alias(예: claude-3-5-sonnet-latest) 대신 버전 고정 ID를 쓰면 버전 드리프트 위험이 사라진다.

자동화 출력에 대해 최소한의 해시라도 남겨라. FlashProve 수준의 암호학적 증명은 아니어도, sha256(모델_id + 타임스탬프 + 응답_앞100자)를 함께 저장해두면 나중에 "이 응답이 이 조건에서 나왔다"는 내부 감사 추적 정도는 가능해진다. 완전하지 않지만, 아예 없는 것과는 차원이 다르다.

FlashProve가 표준이 되는 세상은, AI 출력이 소프트웨어 빌드 아티팩트처럼 서명되고 검증되는 세상이다. 그 세상이 오기 전에, 작은 팀이 할 수 있는 가장 싸고 빠른 준비는 로그 정확도다. "어떤 모델이 그 말을 했나"를 물어볼 사람은 반드시 나타난다 — 고객사 감사팀일 수도 있고, 규제 당국일 수도 있고, 사고가 났을 때 우리 자신일 수도 있다.

---

원문: AI News & Artificial Intelligence | TechCrunch