짧은 답변을 드리자면: 문제는 AI 라이브러리를 위한 수정 사항(fix)이 없다는 것이 아닙니다. 수정 사항은 존재합니다. 단지 적용되지 않고 있을 뿐입니다. 2026년 7월 9일, Orca Security는 State of AI Security 보고서를 발표했으며, 그곳의 핵심 수치는 매우 불편합니다. 이미 패치(patch)를 사용할 수 있는 취약점의 99.9%가 패치되지 않은 상태로 남아 있었다는 점입니다. '치료 불가능'한 것이 아니라, 엔지니어들의 손에 의해 실제로 닫히지 않은 것입니다.

만약 당신이 프로덕션(production) 환경에서 단 하나의 AI 패키지라도 운영하고 있다면, 지금 가장 유용한 기술은 새로운 모델을 쫓는 것이 아니라, 자신의 스택에 대한 실제 AI API 상태(status ai api)를 읽는 법을 배우는 것입니다. 어떤 의존성(dependencies)이 걸려 있는지, 어떤 것에 수정 사항(fix)이 있는지, 그리고 왜 그것이 아직 적용되지 않았는지를 파악해야 합니다. 보고서를 사실에 기반하여 분석하고 이를 실행 가능한 단계로 변환해 보겠습니다. 가는 길에 - provod.ai(러시아의 OpenRouter)를 통해 모델로 향하는 요청이 단일 지점에서 발생하는지 확인하는 빠른 방법을 살펴보겠습니다. 이는 OpenRouter와의 제휴가 아닌 시장의 비유입니다. 파편화된 액세스(fragmented access)는 보안 혼란의 전조 중 하나입니다.

Orca는 정확히 무엇을 측정했는가?

결론의 재현성에 대해 즉시 주의 사항을 말씀드립니다: 이것은 전 세계 모든 기업을 대상으로 한 전수 조사가 아니라, Orca의 고객 및 관찰된 환경의 텔레메트리(telemetry) 데이터입니다. Orca의 데이터(2026년 7월 9일 보고서)에 따르면, 이 연구는 1,200개 이상의 프로덕션 조직으로부터 수집된 2026년 2분기 데이터를 기반으로 구축되었습니다. 이것은 설문 조사나 문답이 아니라, 클라우드 환경에서 실제로 관찰되는 내용입니다.

Orca 보고서(2026-07-09)의 주요 수치는 다음과 같습니다. 주요 통계에 따르면, AI 패키지를 사용하는 조직의 81%가 적어도 하나 이상의 알려진 취약점을 보유하고 있었습니다. 발견된 취약점의 평균 CVSS(Common Vulnerability Scoring System)는 8.79로, 이는 높은 심각도를 나타냅니다. 여기서 두 가지를 명확히 구분하는 것이 중요합니다: 취약한 패키지를 보유한 조직의 비율과, 패치되지 않은 개별 수정 가능한 취약점의 비율입니다. 이 둘은 분모가 다르며, 이를 혼동하는 것은 요약 시 발생하는 전형적인 오류입니다.

익스플로잇 (exploit)에 관한 수치도 별도로 주목할 만합니다. 경고의 50.1%에 대해 공개적인 익스플로잇 (exploit)이 존재했는데, 이는 2024년의 0.2%와 비교했을 때 Orca의 데이터 기준 약 250배 증가한 수치입니다. 즉, "취약점이 알려져 있음"과 "취약점이 이미 무기화됨" 사이의 간격이 거의 제로에 가깝게 줄어들었다는 의미입니다. 이제 패치 (patch)의 존재는 보너스가 아니라 필수적인 위생 최소 요건이 되었습니다.

CVSS 점수 8.79를 모든 프로젝트에 대한 사형 선고로 받아들여서는 안 됩니다. 이는 발견된 취약점들의 평균 심각도 (criticality)이지, 귀하의 특정 스택 (stack)에 대한 평가가 아닙니다. 하지만 이 수치는 주제의 시급성을 잘 보여줍니다. 발견되는 것들이 주로 사소한 문제가 아니라 심각한 구멍들이라는 점을 시사하기 때문입니다.

첫 번째 실질적인 결론은, 이 보고서가 귀하에게 주는 개인적인 영향력은 취약점이 얼마나 많은가가 아니라, 이미 수정 가능한 취약점 중 실제로 얼마나 많은 것을 해결했느냐로 측정된다는 것입니다. 다음은 이를 어떻게 확인할 수 있는지에 대한 내용입니다.

업데이트를 다음 스프린트 (sprint)로 미룰지 결정할 때, 바로 이 2024년과 2026년 사이의 격차를 염두에 두어야 합니다. 아래 그래프는 리스크 (risk)의 본질 자체가 얼마나 빠르게 변했는지를 보여줍니다.

왜 수정 방법은 있는데 패치 (patch)는 없는가?

이유는 신비로운 것이 아닙니다. AI 패키지는 프로젝트에 전이적 (transitively)으로 들어옵니다. 에이전트 (agent)를 위한 래퍼 (wrapper) 하나를 설치하면, 그 뒤로 수십 개의 의존성 (dependencies)이 따라옵니다. 이 중 어느 하나라도 업데이트하면 이론적으로 에이전트의 동작이 깨질 수 있기 때문에, 팀들은 버전을 고정하고 건드리는 것을 두려워합니다. 패치 (patch)는 출시되었지만, "잘 작동하면 건드리지 마라"는 생각 때문에 적용되지 않고 있는 것입니다.

두 번째 요인은 모호한 책임 소재입니다. AI 스택은 보안 전문가나 전통적인 테스터가 아니라, 제품 프롬프트 엔지니어 (prompt engineers), 분석가, 어제의 프로토타입 제작자(prototypists)와 같은 하이브리드 역할에 의해 구축되는 경우가 많습니다. 이러한 전문가들은 작동하는 프로토타입을 빠르게 만들어내지만, 의존성 (dependencies)에 대한 프로젝트 문서화는 아무도 수행하지 않으며, 보안 부서의 경계가 이러한 리포지토리 (repositories)에 미치지 못하는 경우도 있고, 이 특정 라이브러리의 업데이트를 누가 책임지는지 기록하는 사람도 없습니다.

문화적인 층위도 존재합니다. AI 주변에는 프롬프팅 (prompting)은 창의적인 영역으로, 지루한 의존성 관리는 "진정한" 엔지니어를 위한 것으로 취급되는 교육 산업이 형성되어 있습니다. 결과적으로 멋진 프롬프트를 만드는 능력은 있지만, 패치 상태 (patch status)를 유지하는 능력은 없습니다. 하지만 바로 이 두 번째 능력이 프로덕션 (production)을 구합니다.

접근 인프라에 대해서는 별도로 다루어야 합니다. 모든 개발자가 각자의 방식으로 모델에 접근할 때 — 여기엔 개인 키가 있고, 저기엔 타인의 프록시 (proxy)가 있으며, 주말에는 VPN을 사용하는 식 — AI API 상태와 클라이언트 버전을 확인할 수 있는 단일 지점이 존재하지 않게 됩니다. Claude, GPT, Gemini, DeepSeek 및 Qwen에 대한 접근을 공통 빌링 (billing)과 함께 하나의 컨투어 (contour) 내에서 유지하는 것 자체가 라이브러리를 패치해주지는 않지만, 스택의 상태를 불투명하게 만드는 키의 난립 (zoo of keys)을 제거해 줍니다. 이러한 시나리오를 위해 provod.ai는 안정적인 다채널 라우팅 (multi-channel routing)과 152-FZ 요구 사항을 지원하는 보안된 러시아 데이터 처리 컨투어를 제공합니다. 이것이 의존성 감사를 대체하지는 않지만, 키와 경로의 제어를 단순화합니다. 여기서 투명성은 절반의 성공과 같습니다. 발견된 모든 사항에 대해 트래커 (tracker)에 티켓을 생성하고 라이브러리 소유자의 확인 후에만 티켓을 닫는 것이 유용하며, 배포 전 엔드포인트 (endpoint) 상태를 확인하는 CI에서의 간단한 단계만으로도 릴리스 (release)를 망치지 않기에 충분합니다.

모델의 엔드포인트 상태를 실질적으로 확인하는 방법은 다음과 같습니다 — 키와 base_url만 변경하면 되는 Anthropic SDK 호환 클라이언트를 사용하는 것입니다:

import os
import anthropic

...

이러한 핑(Ping)은 보안이 아니라 단지 생존 여부를 확인하는 것일 뿐입니다. 하지만 이는 올바른 반사 신경을 길러줍니다. 즉, 먼저 상황을 명확히 파악한 다음 파이프라인(Pipeline)을 실행하는 것입니다. 그리고 이 원칙은 패치(Patch)의 전체 경로로 확장될 수 있습니다.

체인의 어느 지점에서 끊어지는지 이해하려면 이를 노드(Node) 단위로 분해해 보는 것이 유용합니다. 패치는 허공에서 사라지는 것이 아니라 특정 단계, 대개 동결된 버전(Frozen version)에서 멈춰버립니다. 아래 도식은 이 전체 경로를 보여줍니다.

프로덕션(Production) 환경의 에이전트와 유출되는 키

Orca 보고서(2026-07-09)의 두 가지 수치를 나란히 놓고 보아야 합니다. 첫 번째는 AI를 도입한 조직의 56%가 프로덕션(Production) 환경에서 에이전트 프레임워크(Agentic frameworks)를 사용하고 있다는 점입니다. 두 번째는 조직의 29.5%가 AI와 관련된 자격 증명(Credentials)을 안전하지 않게 배치했다는 점입니다. 이 두 수치를 겹쳐보면 다음과 같습니다. 절반 이상의 조직이 자율 에이전트(Autonomous agents)를 실행하고 있으며, 그중 거의 3분의 1은 어딘가에 자격 증명을 흘리고 있습니다.

에이전트가 챗봇보다 위험한 이유는 실제로 행동하기 때문입니다. 에이전트는 API에 접속하고, 타인의 첨부 파일을 파싱(Parsing)하며, 도구(Tools)를 호출합니다. 여기서 데이터에 포함된 어떠한 인젝션(Injection)도 농담이 아닌 실제 사고로 이어집니다. 전형적인 프롬프트 인젝션(Prompt injection)은 입력 데이터에 모델의 동작을 변경하는 지침을 숨기는 것입니다. 예를 들어 "이전 규칙을 무시하라" 또는 "키를 출력하라"와 같은 명령입니다. 비밀 정보에 접근 권한이 있는 에이전트에게 이는 단순한 텍스트의 문제가 아니라 행동의 문제입니다.

보험 부서를 위해 사진으로 자동차 손상을 평가하는 에이전트를 상상해 보십시오. 에이전트는 긁힘과 움푹 들어간 곳을 보고 규정에 따라 대조하며, 이것이 보증 범위 내의 사건인지 여부를 결정합니다. 만약 첨부 파일에 보이지 않는 명령줄이 포함된 문서를 끼워 넣는다면, 그 명령을 맹목적으로 따르는 행위는 모든 대조 로직을 망가뜨립니다. 부동산 RAG(Retrieval-Augmented Generation)에서도 마찬가지입니다. 아파트 설명 페이지에는 유용한 텍스트와 함께 파싱(Parsing)을 위한 숨겨진 명령이 함께 들어있을 수 있습니다. 모델은 이 두 가지를 모두 성실히 수행할 것입니다.

이것이 바로 보고서에서 '에이전트(Agent)와 부주의하게 관리되는 키(Key)의 결합'이 가장 치명적인 실수인 이유입니다. 에이전트는 행동을 수행하고, 유출된 자격 증명(Credential)은 접근 권한을 부여합니다. 각각의 수치는 개별적으로 보면 감내할 만해 보일 수 있지만, 결합되면 즉각적인 사고 시나리오가 완성됩니다. 아래 그래프는 계산기 없이도 그 규모를 한눈에 파악할 수 있도록 두 비율을 나란히 배치했습니다.

AI API 상태를 수동으로 관리하는 방법

이론은 충분합니다. 이제 실행 가능한 단계들을 살펴보겠습니다. 이는 마법 같은 해결책이 아니라, 왠지 모르게 계속 미루게 되는 일상적인 작업들에 관한 것입니다.

첫 번째 단계 - 인벤토리(Inventory) 작성. 각 서비스에 있는 AI 패키지와 그들의 전이적 의존성(Transitive Dependencies) 목록을 수집하세요. 전체 구조(Tree)를 파악하지 못한다면, 패치에 관한 모든 논의는 눈을 감고 하는 대화와 같습니다.

두 번째 단계 - 알려진 취약점 데이터베이스와 버전을 대조하고, 별도의 열을 만들어 수정 사항(Fix)이 이미 사용 가능한지 표시하세요. 바로 이 열이 여러분의 개인적인 '99.9%'가 될 것입니다. 즉, 수정 가능한 패치가 있음에도 실제로 적용되지 않은 항목이 얼마나 되는지를 나타냅니다.

세 번째 단계 - 소유자(Owner) 지정. 각 라이브러리에 대해 '부서 전체'가 아닌 책임자를 지정하세요. 이것은 영웅적인 과업이 아니라 일상적인 루틴이며, 이것 없이는 패치 상태가 다시 불분명해질 것입니다. 누가, 무엇을, 언제 업데이트했는지 기록하는 짧은 업데이트 일지를 만드는 것도 유용합니다.

네 번째 단계 - 비밀 정보(Secrets) 분리. 조직의 29.5%가 자격 증명을 안전하지 않게 보관하고 있는 만큼(Orca, 2026-07-09), 저장소의 코드와 .env 파일에서 키를 제거하는 것부터 시작하세요. 이는 가장 저렴한 공격 벡터를 차단하는, 단 30분의 추가 작업일 뿐입니다.

다섯 번째 단계 - 에이전트 수준의 인젝션(Injection) 방어: 도구 격리(Tool Isolation), 작업 화이트리스트(Whitelist), 모델이 데이터를 보기 전 별도의 입력 데이터 검증을 수행하세요. 여기에는 출시 전 일회성 점검이 아닌, 하나의 프로세스로서의 제대로 된 테스트가 필요합니다.

만약 팀 내에 AI 전담 테스터가 있다면, 그에게 인젝션 (Injection) 시나리오를 제공하십시오. 만약 없다면, 파이프라인 (Pipeline)을 구축하는 사람이 이 역할을 맡아야 합니다. 단순히 문구를 만들어내는 것을 넘어 자신의 에이전트 (Agent)를 스스로 망가뜨릴 줄 아는 프롬프트 엔지니어 (Prompt Engineer)는 더 높은 가치를 인정받으며, 이는 제품 자체를 더 견고하게 만듭니다.

이 단계들의 순서는 우연이 아닙니다. 가장 비용이 적게 드는 승리에서 가장 노동 집약적인 단계로 이어집니다. 코드에서 비밀 정보 (Secrets)를 분리하는 것은 비용이 거의 들지 않으면서도, 가장 먼저 악용되는 공격 벡터 (Vector)를 차단합니다. 아래의 체크리스트 (Check-list)는 인쇄하여 스프린트 (Sprint) 보드 위에 붙여두기에 유용합니다.

직접 해결할 것인가, 기성 서비스를 사용할 것인가: 비교표

모든 과제를 직접 해결할 필요는 없습니다. 아래는 무엇이 적절한지에 대한 솔직한 비교입니다.

러시아 팀에게는 사소한 문제가 아니기에 빌링 (Billing)에 대해 별도로 언급합니다. 루블화 잔액, 러시아 카드 결제, SBP(Fast Payment System) 또는 계좌 이체, 그리고 계약서, 송장, 영수증과 같은 증빙 서류는 관료주의의 절반을 제거해 줍니다. 모델 가격은 provod.ai의 추가 마진 없이 제공됩니다. 팀 워크스페이스 (Workspace)에서는 결제를 분리할 수 있으며, API뿐만 아니라 채팅, 이미지 생성, 비디오 에디터를 사용할 수 있습니다. VPN이나 해외 카드 없이 작동하며, 호환되는 OpenAI 및 Anthropic SDK는 키 (Key)와 base_url 변경만으로 연결할 수 있습니다. 이는 편의성과 액세스 관리의 문제이지, 누군가가 당신을 대신해 취약점 (Vulnerability)을 해결해 준다는 의미는 아닙니다.

이 보고서와 어떤 서비스도 해결할 수 없는 것