캐스트 AI(Cast AI)가 2026년 4월 발표한 쿠버네티스(Kubernetes) 최적화 보고서에 따르면, 수만 개 클러스터를 분석한 결과 2025년 평균 CPU 사용률은 8%, 메모리 사용률은 20%였습니다. GPU 사용률은 평균 5%였습니다. 쿠버네티스 비용 최적화는 노드가 제공하는 용량, 워크로드가 요청한 자원, 실제 사용량 사이의 차이를 줄이는 데서 출발합니다. AI를 업무에 쓰기 시작하면 관리 대상은 모델과 토큰 사용까지 넓어집니다. AI 비용을 어떤 기준으로 측정할지에 대한 논의도 시작됐습니다. 리눅스 재단(Linux Foundation)은 AI 활용의 경제성과 투자 대비 효과를 정의하기 위해 토크노믹스 재단(Tokenomics Foundation)을 출범시켰고, Cast AI는 2026년 8월 창립 프리미어 회원으로 참여했습니다.Cast AI는 이 두 영역을 함께 다룹니다. 쿠버네티스 최적화(Kubernetes Optimization)는 실사용량에 맞춰 쿠버네티스 자원을 자동으로 조정하고, 김치(Kimchi)는 AI 모델과 토큰 사용, 비용과 예산을 관리합니다.지난 10월 21일 클라우드네트웍스와 Cast AI가 공동 주최한 AI Leaders' Forum에서는 Cast AI가 'Cloud Native에서 AI Native까지'를 주제로 이 내용을 발표했습니다. 이 글에서는 두 영역이 각각 비용을 어떻게 관리하는지, 그 효과를 어떤 기준으로 평가하는지 살펴봅니다.☑️ 인프라와 AI 사용, 두 영역에서 비용을 관리하는 Cast AICast AI는 비용을 두 영역에서 관리합니다. 하나는 쿠버네티스 인프라로, 실사용량에 맞춰 자원을 자동으로 조정해 쓰지 않는 용량을 줄입니다. 다른 하나는 AI 사용으로, Kimchi가 작업에 맞는 모델을 배정하고 팀별 사용량과 예산, 데이터를 둘 위치를 관리합니다. 두 영역을 함께 적용하면 품질 기준을 충족한 업무 하나에 드는 비용을 낮출 수 있습니다.두 영역은 같은 기반 위에서 이어집니다. Kimchi는 Cast AI가 쿠버네티스와 GPU 인프라 최적화에 쓰는 엔진 위에서 동작하고, 고객 환경에서 모델을 직접 실행할 때도 Cast AI가 노드 단위까지 최적화한 GPU 인프라에서 추론이 이뤄집니다. 그래서 인프라 쪽 효율과 모델·토큰 쪽 효율을 품질 기준을 충족한 업무당 비용이라는 하나의 지표로 함께 평가합니다.적용 범위는 인프라와 자동화에서 시작해 정책과 통제, 모델과 에이전트까지 이어집니다. 두 영역에 공통으로 적용되는 기준은 세 가지입니다. 수요에 맞는 컴퓨팅과 업무에 맞는 모델로 높이는 비용 효율성, 변화에 대응하는 자원 조정과 정책에 따른 지속적인 최적화로 지키는 운영 안정성, 사용과 예산의 기준, 데이터 경계를 기업이 직접 정하는 통제권입니다.☑️ 인프라와 AI 사용에서 관리가 필요한 지점인프라: 요청한 자원과 실제 사용량의 차이쿠버네티스 클러스터의 상태는 노드 제공 용량, 워크로드 요청량, 실사용량 세 가지로 나눠 볼 수 있습니다. 요청량이 실사용량보다 크면 자원이 과다 할당된 상태이고, 이 격차를 줄여 남는 용량을 회수하면 인프라 비용이 줄어듭니다. 반대로 수요가 늘거나 인프라 상황이 바뀌면 부족한 자원을 보강하고 대체 용량을 확보해야 합니다. 자원 회수와 보강을 함께 다뤄 비용 효율성과 운영 안정성을 동시에 확보하는 것이 인프라 자동화의 과제입니다.AI 사용: 여러 팀으로 나뉜 사용량과 작업별 모델 선택AI 사용은 조직 안의 여러 주체에서 발생합니다. 제품 개발팀은 코딩 에이전트를, 플랫폼팀은 배포 파이프라인용 API 키를, 데이터팀은 분석용 API 키를 쓰는 식입니다. 이렇게 나뉜 사용량을 사용자, 팀, 모델별로 파악하고 사용 주체별로 비용을 귀속해야 예산 한도를 관리할 수 있습니다. 모델 선택도 관리 대상입니다. 개발 작업은 간단한 코드 수정부터 설계와 검증이 필요한 개발까지 난도가 다르고, 계획·설계, 구현, 검토처럼 역할도 나뉩니다. 그래서 Kimchi는 모든 작업을 하나의 모델로 처리하지 않고, 작업의 난도와 역할에 맞춰 모델을 배정합니다.데이터: AI 플랫폼 배포 위치와 데이터 경계AI 요청과 모델 추론을 어디에서 처리할지도 기업이 정해야 하는 부분입니다. AI 사용에 대한 통제권은 사용과 예산의 기준, 플랫폼 배포 위치, 허용 통신, 데이터 경계를 기업이 직접 정하는 데서 나옵니다.☑️ 품질 기준을 충족한 업무당 비용으로 보는 AI 토크노믹스(AI Tokenomics)AI 토크노믹스는 인프라 최적화를 AI 활용의 경제성으로 확장한 관점입니다. 인프라 효율과 AI 사용 효율을 하나의 지표로 묶어 평가합니다.AI 비용에는 두 가지 효율이 함께 작용합니다. 실행 자원의 효율은 Cast AI 쿠버네티스 최적화가 자원 크기 조정, 배치 최적화, 컴퓨팅 구성으로 높이고, 모델과 토큰의 효율은 Kimchi가 작업별 모델 배정, 토큰 사용 최적화, 사용 통제로 높입니다. 두 효율을 결합한 결과는 품질 기준을 충족한 업무당 비용으로 평가합니다. 업무에 배분된 AI 총비용을 검증을 마친 업무 수로 나눈 값입니다. 이 지표로 같은 품질 기준에서 비용 대비 업무 성과를 비교할 수 있습니다. 평가할 때는 품질 기준, 비용 귀속, 예산 한도, 데이터 경계를 공통 기준으로 삼고, 배포 방식에 따라 API 이용료와 자체 인프라 비용이 중복으로 계산되지 않도록 합니다.☑️ Cast AI 쿠버네티스 최적화와 Kimchi의 주요 활용 포인트실사용량에 맞춘 쿠버네티스 자원 자동 조정Cast AI 쿠버네티스 최적화는 실사용량을 관측하고, 자원을 조정하고, 결과를 다시 평가하는 과정을 계속 반복합니다. 이 과정은 세 가지 기능이 나눠 맡습니다. Workload Autoscaler는 실사용량에 맞춰 워크로드의 자원 요청량을 자동으로 늘리거나 줄여 성능과 비용 효율을 함께 맞춥니다. Node Autoscaler는 실시간 수요에 맞춰 비용 효율이 높은 자원을 자동으로 프로비저닝하고, 워크로드를 더 적은 노드로 안전하게 모은 뒤 빈 노드를 제거합니다. Rebalancer는 CPU와 메모리 비율에 맞춰 워크로드를 재배치하고 각 워크로드에 맞는 컴퓨팅으로 구성을 바꿉니다. Rebalancer는 예약 실행과 즉시 실행을 모두 지원합니다. 일상적인 클러스터 운영에서 생기는 자원 단편화를 정리하고, 비용 효율이 낮거나 노드 설정이 오래된 노드를 교체할 때 쓰입니다. 실행 전에는 리밸런싱 계획을 먼저 만들어 검토하고, 예약 실행에 절감 기준값을 설정하면 오히려 비용이 늘어나는 작업은 실행되지 않습니다. 어떤 컴퓨팅을 선택할지는 자원 수요, 가격, 가용성, 정책에 따라 정해집니다. 효과는 요청량 조정, 노드 용량 회수, 컴퓨팅 구성 최적화 순서로 쌓입니다. 필요한 용량은 확보하면서 인프라 비용을 줄일 수 있고, 조직 전체와 클러스터 단위의 자원 지출도 함께 모니터링할 수 있습니다. Cast AI가 공개한 아카마이(Akamai) 사례에 따르면 쿠버네티스 워크로드 비용이 워크로드에 따라 40~70% 줄었습니다. 도입 전 비용을 100으로 보면 도입 후 비용은 30~60 수준입니다.비용 절감과 운영 안정성을 함께 지키는 용량 확보수요가 변하면 실사용량을 기준으로 자원 크기를 조정하고, 인프라가 변동하면 가용 용량을 탐색해 대체 용량을 확보합니다. 스팟(Spot) 인스턴스를 쓸 때는 중단 이벤트 대응, 스팟 다양성 확보, 온디맨드(On-Demand) 인스턴스로의 폴백(Fallback)을 자동으로 처리합니다. 약정(Commitments)과 스팟 인스턴스 사용량의 균형도 자동으로 맞춥니다. 자원 조정은 과다 할당된 자원은 회수하고 부족한 자원은 보강하는 양방향으로 이루어집니다. 덕분에 비용 효율성과 운영 안정성을 동시에 확보할 수 있습니다. 조정 범위는 조직의 정책과 워크로드 특성에 맞춰 설정합니다. 지원 환경은 AWS, GCP, Azure입니다.작업에 맞는 모델 배정으로 관리하는 AI 코딩 비용Kimchi Coding의 오케스트레이터(Orchestrator)는 작업을 분류해 단계로 나누고, 하위 작업마다 적합한 모델을 배정합니다. 사용자가 모델을 직접 고를 필요가 없으며, 이 멀티 모델 방식이 기본값입니다. 하위 작업을 맡는 역할은 네 가지입니다. Planner는 접근 방식을 설계하고 명세를 쓰며, Builder는 코드를 구현하고, Reviewer는 코드를 리뷰하며, Explorer는 코드베이스를 탐색하고 조사합니다. Builder는 복잡한 작업에 더 무거운 모델을, Reviewer는 등급 기준으로 가장 강한 모델을 쓰고, Explorer는 단순 탐색에는 가벼운 모델을, 분석에는 무거운 모델을 씁니다. 각 요청에는 작업 단계 정보가 태그로 붙어 비용 보고에 활용됩니다. 자동 모델 배정은 Kimchi의 코딩 기능에 적용되고, API를 직접 호출할 때는 지정한 모델 경로를 따릅니다. VS Code 확장, MCP 서버 연결, AWS Bedrock 연결을 지원하며, Claude Code와 Cursor에서도 Kimchi Router를 쓸 수 있습니다. Cast AI는 2026년 7월 15일 Kimchi Coding을 정식 출시하면서 섀도우 모드(Shadow-mode) 평가 결과를 공개했습니다. 상용 모델로만 구성한 기준과 비교해 Kimchi의 비용은 2.5분의 1 수준이었고, 요구사항 일치율과 테스트 통과율 기준의 품질은 같거나 더 높았습니다. 비용 차이는 작업 대부분을 오픈 웨이트(Open-weight) 모델로 보내는 라우팅과, Cast AI가 최적화한 GPU 인프라에서 직접 실행하는 추론에서 나옵니다. 이를 AI 코딩 비용 절감률로 환산하면 60%이며(1 − 1/2.5), 토큰 단가 절감률과는 다른 값입니다. 앞의 Akamai 사례와는 다른 평가에서 나온 수치이므로 두 절감률을 더해서 볼 수 없습니다.팀별 AI 사용량 가시성과 예산 한도Kimchi는 개발자가 통합 개발 환경에서 보내는 코드와 프롬프트, 애플리케이션이 API로 보내는 업무 요청, AI 에이전트가 반복 실행하며 보내는 요청을 한 플랫폼으로 모아 처리합니다. 플랫폼 안에서 키와 접근 관리, 토큰과 비용 집계, 예산 한도 적용이 함께 이루어집니다. 사용량이 한곳에서 집계되므로 AI 사용 비용을 개발자, 팀, 모델, 태그별로 실시간 확인하고 사용 주체별로 귀속할 수 있습니다. 지출 한도는 사용자, 팀, API 키, 모델 단위로 설정하고, 배포 파이프라인, 봇, 외주 인력이 쓰는 API 키에도 각각 한도를 둘 수 있습니다. 요청은 한도를 넘긴 뒤가 아니라 한도에 도달하는 시점에 멈춥니다. 그래서 AI 사용을 정해 둔 예산 범위 안에서 운영할 수 있습니다. 예산 통제는 플랫폼을 거쳐 처리된 사용량에 적용됩니다.기업이 정하는 배포 위치와 데이터 경계Kimchi는 같은 플랫폼을 고객 환경이나 관리형 환경에 배포할 수 있습니다. 셀프 호스팅(Self-hosted) 방식에서는 AWS, GCP, Azure 또는 온프레미스의 쿠버네티스처럼 고객이 운영하는 격리된 환경에 플랫폼을 두고, 개발자와 애플리케이션, AI 에이전트가 내부 엔드포인트로 접근합니다. 에어갭(Air-gap) 환경도 지원합니다. 서버리스(Serverless) 방식에서는 관리형 환경의 플랫폼을 API 엔드포인트로 사용합니다. 모델 추론 경로도 고를 수 있습니다. 관리형 모델의 서버리스 추론, 고객 환경 안 격리된 쿠버네티스에서 실행하는 추론, 지원되는 외부 공급자 모델 가운데에서 구성하며, 외부 공급자 모델은 고객이 보유한 키를 연결해 쓸 수도 있습니다. 프롬프트, 코드, 출력물은 모델 학습에서 제외됩니다. 기업은 배포 위치를 고르고, 조직 정책에 따라 접근을 관리하며, 허용할 통신과 데이터 경계를 직접 정합니다. 실제 격리 범위와 허용 연결은 배포 정책에 따라 구성됩니다. Kimchi는 ISO 27001, AICPA SOC 2, GDPR 관련 보안·컴플라이언스 요건을 갖추고 있습니다.☑️ 자주 묻는 질문Cast AI 쿠버네티스 최적화와 Kimchi는 각각 무엇을 관리하나요?Cast AI 쿠버네티스 최적화는 인프라를, Kimchi는 AI 사용을 관리합니다. Cast AI 쿠버네티스 최적화는 실사용량에 맞춰 쿠버네티스 워크로드 자원, 노드, 컴퓨팅 구성을 계속 최적화하고, Kimchi는 작업별 모델 배정, 토큰 사용 최적화, 사용자·팀·모델별 비용과 예산, 데이터 경계를 관리합니다.품질 기준을 충족한 업무당 비용은 어떻게 계산하나요?업무에 배분된 AI 총비용을 검증을 마친 업무 수로 나눠 계산합니다. 같은 품질 기준에서 비용 대비 업무 성과를 비교하는 지표이며, 배포 방식에 따라 API 이용료와 자체 인프라 비용이 중복으로 계산되지 않도록 합니다.Cast AI로 쿠버네티스 비용을 줄이면 서비스 안정성은 어떻게 유지하나요?자원 회수와 보강을 함께 자동화해 안정성을 유지합니다. 수요가 변하면 실사용량에 맞춰 자원 크기를 조정하고, 인프라가 변동하면 대체 용량을 확보합니다. 스팟 인스턴스의 중단 이벤트 대응과 온디맨드 폴백도 자동으로 처리하며, 조정 범위는 정책과 워크로드 특성에 맞춰 설정할 수 있습니다.Kimchi는 모든 작업에 같은 모델을 쓰나요?아닙니다. 오케스트레이터가 작업을 단계로 나눈 뒤 역할에 맞는 모델을 배정합니다. 설계와 명세는 Planner, 구현은 Builder, 리뷰는 Reviewer, 코드베이스 탐색은 Explorer가 맡으며, 이 멀티 모델 방식이 기본값입니다.AI 플랫폼을 우리 회사 환경 안에 둘 수 있나요?네, 셀프 호스팅 방식으로 AWS, GCP, Azure 또는 온프레미스의 쿠버네티스 환경에 배포할 수 있고 에어갭 환경도 지원합니다. 관리형 환경을 쓰는 서버리스 방식도 선택할 수 있으며, 실제 격리 범위와 허용 연결은 배포 정책에 따라 구성됩니다.☑️ 마무리쿠버네티스 자원의 사용률을 높이는 일과 AI 사용 비용을 통제하는 일은 하나의 질문으로 모입니다. 품질 기준을 충족한 업무 하나에 비용이 얼마나 드느냐입니다. Cast AI 쿠버네티스 최적화는 실사용량에 맞춘 자원 조정으로 인프라 쪽 비용을 줄이고, Kimchi는 작업별 모델 배정과 예산 한도, 배포 위치 선택으로 AI 사용 비용과 통제권을 관리합니다.클라우드네트웍스는 Cast AI 국내 공식 파트너로서 고객이 자사 환경에 Cast AI를 직접 적용해 절감 효과를 먼저 확인할 수 있도록 지원하고, 도입 이후 운영 단계까지 기술지원을 이어 갑니다. 쿠버네티스 인프라 비용이나 조직의 AI 사용 비용 관리를 검토하고 계시다면 클라우드네트웍스에 문의해 주시기 바랍니다.▶ Cast AI 자세히보기[출처 : Cast AI, "Cloud Native에서 AI Native까지 - CAST AI Core + Kimchi", "Cast AI's 2026 State of Kubernetes Optimization Report Reveals GPU Utilization at 5%", "Cast AI Joins the Tokenomics Foundation as Founding Premier Member", "Automated Kubernetes Cost Optimization", "Rebalancing", "Akamai achieves 40-70% cloud savings", "Cast AI's Kimchi Coding Hits General Availability", "Cast AI's Kimchi Coding Becomes the First Autonomous Coding Agent to Offer MiniMax M3", Linux Foundation, "Linux Foundation Launches the Tokenomics Foundation", Kimchi, "Kimchi 공식 홈페이지", "Coding overview"]

2026년 10월 21일 PHP 개발팀은 웹 요청을 처리하는 PHP에서 인증 없이 원격 코드 실행이 가능한 취약점 2건(CVE-2026-109618, CVE-2026-109619)을 수정한 버전을 배포했습니다. 두 취약점은 CVSS v4.0 기준 9.2점이며 PHP2Shell이라는 이름으로 불립니다. 한국인터넷진흥원(KISA)은 다음 날인 22일 기업 보안 대응 수칙을 공개했습니다.해결 방법은 수정 버전으로 업데이트하는 것이지만, KISA가 제시한 점검 범위는 넓습니다. 외주로 제작한 사이트, 오래돼 관리하지 않는 사이트, 이벤트·테스트 서버, 관리자 페이지, PHP가 내장된 장비와 솔루션, 외부에서 가져온 컨테이너 이미지까지 확인 대상이며, 자산 관리 목록이 아니라 실제 동작 중인 서버를 기준으로 살펴봐야 합니다. 업데이트 후에는 PHP를 실행하는 서비스를 재시작해야 하고, 공식 보안 업데이트가 없는 PHP 8.1 이하는 지원 버전으로 전환해야 합니다. 보안 업체 안랩은 지원 기간이 끝난 취약한 PHP가 설치된 것으로 추정되는 국내 서버가 약 11만 건으로, 세계에서 6번째로 많다고 집계했습니다.이 글에서는 PHP2Shell이 무엇이고 대응이 어디서 어려워지는지 정리한 뒤, 퀄리스(Qualys) Enterprise TruRisk Platform으로 PHP 자산을 찾고, 실제 공격 가능성을 검증하고, 패치 전까지 위험을 줄이고, 패치가 끝났는지 확인하는 과정을 단계별로 설명합니다.☑️ PHP2Shell이란 무엇인가PHP2Shell은 PHP 자체에서 발견된 두 건의 치명적 취약점 CVE-2026-109618과 CVE-2026-109619를 함께 부르는 이름으로, 웹 요청을 처리하는 PHP 환경에서 인증 없이 원격 코드 실행을 허용합니다. 결함이 애플리케이션 코드가 아니라 PHP에 있기 때문에 웹사이트를 안전하게 개발했더라도 영향을 받을 수 있습니다. 완전한 해결책은 수정 버전으로 업데이트하는 것이며, 업데이트 전까지는 노출된 자산을 찾아 실제 공격 가능성을 확인하고 완화 조치를 적용해야 합니다.두 취약점의 원인CVE-2026-109618은 메모리 부족 오류가 처리 중인 작업을 중단시킬 때 발생합니다. 요청 데이터가 일부만 초기화된 상태로 남고, 정리 과정이 이 잘못된 상태를 정상 데이터처럼 처리하면서 원격 코드 실행 경로가 생깁니다. CVE-2026-109619는 요청 데이터를 담은 메모리가 해제된 뒤에도 PHP가 그 데이터에 대한 참조를 유지하는 문제입니다. 같은 워커가 처리하는 다음 요청이 초기화 전에 이 참조에 접근하면서 해제 후 사용(use-after-free)이 발생하며, 연구진은 이 과정을 통한 원격 코드 실행을 시연했습니다. 코드 실행 외에 인증 없이 PHP 워커 메모리를 열람하는 방식도 시연됐습니다. 노출된 메모리에는 비밀번호, 인증 토큰, API 키가 포함될 수 있어, KISA는 이상 징후가 없더라도 업데이트와 함께 DB 비밀번호, 외부 서비스 연동용 API 키, 관리자 계정 비밀번호를 교체할 것을 권고했습니다.영향받는 환경과 수정 버전PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed 등 웹 요청을 처리하는 PHP 설치 환경이 대상이며, 실제 공격 가능성은 설정과 애플리케이션 동작에 따라 달라집니다. 가장 시급한 환경은 Apache mod_php로, 애플리케이션 코드가 실행되기 전에 동작하는 공격이 시연됐습니다. PHP-FPM은 시작 방식 덕분에 특정 메모리 부족 공격 경로는 막히지만, 애플리케이션 조건에 따라 세션 처리 과정을 통한 원격 코드 실행이 검증됐기 때문에 역시 패치가 필요합니다.PHP 브랜치수정 버전PHP 8.58.5.12PHP 8.48.4.27PHP 8.38.3.36PHP 8.28.2.35배포판 패키지는 이전 버전 번호를 유지한 채 수정 사항이 백포트될 수 있어, 배포판 제공업체의 권고문을 기준으로 확인해야 합니다. PHP 8.1 이하는 정기 지원 대상이 아니며, 7.4·8.0·8.1에는 제한적인 소스 백포트만 제공됩니다. 이 버전들을 운영 중이라면 배포판이나 지원 업체의 수정 빌드를 확보하거나 지원 버전으로 업그레이드해야 합니다. KISA는 PHP 8.2도 2026년 12월 31일 보안 지원이 종료될 예정이어서 8.3 이상으로 전환할 것을 권고했습니다.☑️ PHP2Shell 대응이 어려운 이유PHP2Shell 대응에서는 패치해야 할 대상을 빠짐없이 찾는 일, 패치가 어려운 자산의 위험을 줄이는 일, 조치가 실제로 반영됐는지 확인하는 일이 함께 요구됩니다. 세 가지 모두 운영 환경의 규모와 구성에 따라 난도가 달라집니다.자산 목록에 드러나지 않는 PHPPHP는 웹 서버 한 곳에만 있지 않습니다. 한 자산에 여러 PHP 브랜치가 함께 설치돼 있거나, 컨테이너·호스팅 패널 패키지·어플라이언스·다른 소프트웨어 안에 번들로 들어간 경우도 있습니다. php -v 명령이 보여주는 버전이 실제로 웹 요청을 처리하는 설치본과 다를 수 있고, 배포판 백포트로 이전 버전 번호가 유지되는 경우도 있어 버전 번호만으로는 안전 여부를 판단하기 어렵습니다. 한 자산에 PHP 사본이 여럿이라면 기본 설치본만 업데이트하면 다른 사본은 취약한 상태로 남습니다. KISA가 자산 관리 목록이 아니라 실제 동작 중인 서버를 기준으로 살피라고 권고한 것도 같은 이유입니다. 점검 대상에는 네트워크 장비 관리 화면처럼 PHP가 내장된 장비·솔루션과 도커 등 외부에서 가져온 컨테이너 이미지가 포함됩니다.패치가 나오지 않는 버전과 손이 닿지 않는 서버Qualys Threat Research Unit(TRU)이 1만 곳 이상 고객사의 익명 데이터를 분석한 결과, PHP 패키지 설치 1억 6,700만 건이 확인됐고 그중 73%가 인터넷에 노출된 자산에 있었습니다. 버전이 확인된 1억 5,600만 건 가운데 수정 버전이 있는 지원 브랜치(8.2~8.5)는 28%(4,400만 건)였고, 71%(1억 1,000만 건)는 지원이 종료된 5.4~8.1 버전이었습니다. 이 가운데 대부분은 PHP 프로젝트가 수정 버전을 내지 않는 버전이고, PHP가 업무상 중요한 애플리케이션을 구동하는 경우가 많아 패치를 빠르게 진행하기도 어렵습니다. 인터넷에 노출된 PHP 서버 상당수는 어플라이언스, DMZ 서버, 레거시 호스트, 다른 팀이 관리하는 시스템에 있습니다. 이런 시스템은 에이전트를 설치하기 어려운 경우가 많아, 네트워크 스캔으로 노출을 확인하더라도 완화 조치는 서버마다 담당자가 접속해 설정을 바꾸는 방식으로 진행돼 왔습니다.설치로 끝나지 않는 패치패키지를 설치해도 실행 중인 프로세스는 재시작하기 전까지 취약한 코드를 메모리에 그대로 유지합니다. 컨테이너 환경에서는 실행 중인 컨테이너만 패치하면 이미지가 취약한 상태로 남기 때문에 이미지를 다시 빌드해 배포해야 합니다. 적용 속도도 느립니다. Qualys 데이터 기준으로 공개 후 12시간 동안 패치가 적용된 설치본은 버전이 확인된 1억 5,600만 건 중 19만 9,000건(약 0.13%)이었습니다.운영 서버에서 공개 PoC를 실행하는 위험공개 직후 깃허브에는 개념 증명(PoC) 스크립트가 빠르게 퍼졌지만, 이를 운영 서버의 노출 여부 확인에 쓰는 방식은 안전하지 않습니다. 일부 스크립트는 업로드 요청을 1분 가까이 열어두거나 큰 요청으로 메모리 부족을 일으켜 PHP 워커를 묶어두고, 코드가 담긴 데이터를 서버의 세션 파일에 기록합니다. 메모리 손상을 직접 일으키는 방식이어서 패치되지 않은 빌드에서는 워커가 중단될 수 있고, 악성코드가 숨겨진 가짜 PoC일 가능성도 있습니다. KISA 역시 출처가 불분명한 PoC를 직접 실행해 취약 여부를 확인하는 방식을 피하라고 안내했습니다.☑️ Qualys가 PHP2Shell에 대응하는 방식Qualys는 PHP2Shell 대응을 노출 탐지와 평가, 패치 전 완화, 조치와 검증의 세 단계로 구성하고, 각 단계를 Enterprise TruRisk Platform의 앱으로 처리합니다. 보안팀이 답해야 하는 질문으로 바꾸면 무엇이 노출됐는지, 무엇부터 고칠지, 패치 전까지 무엇을 할지, 고쳐졌는지 어떻게 확인할지의 순서입니다.보안팀의 질문확인하는 내용관련 Qualys 앱무엇이 노출됐는가PHP가 설치된 서버·컨테이너·클라우드 워크로드, 외부에서 접근 가능한 웹 애플리케이션과 APICSAM, VMDR, TotalCloud, Container Security, TotalAppSec무엇부터 고칠 것인가인터넷 노출, 지원 종료 여부, 실제 공격 가능성ETM(TruConfirm)패치 전까지 무엇을 할 것인가설정 단위 완화 적용, PHP 권장 설정 적용 여부Qualys 완화 조치, TruRisk Eliminate, Policy Audit고쳐졌는지 어떻게 아는가패치 배포, 서비스 재시작, 실행 중인 런타임 확인, 재검증TruRisk Eliminate, VMDR, TotalCloud, TotalAppSec, TruConfirm이 구성에서 눈여겨볼 점은 노출을 찾은 플랫폼에서 완화와 재검증까지 이어진다는 것입니다. 에이전트를 설치하기 어려운 서버도 스캐너를 통해 완화 스크립트를 실행할 수 있어, 서버마다 접속해 설정을 바꾸던 작업을 줄일 수 있습니다.☑️ 단계별 Qualys 활용 포인트PHP 설치 위치 파악: CSAM, VMDR, InstaScan, Deep Scan대응의 출발점은 PHP가 어디에서 실행되는지 아는 것입니다. Qualys에서는 QID 45110(PHP Server Detected)으로 PHP 설치를 식별하고, 이어서 PHP2Shell 탐지 QID로 취약 여부를 평가합니다. QID 45110은 설치 여부만 식별하고 취약 여부는 판정하지 않기 때문에 두 단계를 함께 쓰는 구조입니다. CyberSecurity Asset Management(CSAM)은 PHP가 설치된 자산 전체, 지원이 종료된 PHP 8.1 이하를 쓰는 자산, 중요도가 높은 자산에 설치된 PHP를 조회 쿼리로 보여줍니다. 고객 환경에서는 조치 범위를 산정하고 지원 종료 버전과 인터넷 노출 자산을 먼저 추려내는 데 쓰입니다. InstaScan은 Agent Insta 기반의 스캔리스 탐지 기능입니다. 배포판 보안 권고가 나오면 환경에서 이미 수집된 소프트웨어 인벤토리와 대조해, 새 스캔 없이 보통 권고 처리 후 몇 분 안에 탐지 결과를 냅니다. Red Hat, Ubuntu, Debian, Oracle Linux 권고를 지원하며, Qualys가 공개한 사례에서는 고객이 이미 보유한 인벤토리를 기준으로 두 CVE가 공개 10분 만에 탐지됐습니다. 배포판별 패치가 순차적으로 나오는 상황에서 다음 정기 스캔을 기다리지 않고 확인과 우선순위 작업을 시작할 수 있습니다. Deep Scan은 Windows 자산의 사용자 지정 애플리케이션 폴더, 보조 드라이브 등 비표준 경로에 있는 비관리 PHP 바이너리까지 찾습니다. 결과는 VMDR에 전체 경로, 설치 버전, 권장 수정 버전과 함께 표시되어, 기본 설치본만 업데이트하고 다른 사본을 놓치는 상황을 줄입니다. Deep Scan은 VMDR에 포함돼 있으며 Cloud Agent 6.2 이상이 설치된 Windows 자산에서 동작합니다.클라우드·컨테이너·웹 애플리케이션으로 범위 확장: TotalCloud, Container Security, TotalAppSecTotalCloud와 Container Security는 클라우드 이미지, 컨테이너 레지스트리, 빌드 산출물, 배포된 워크로드에서 취약한 PHP 구성 요소를 찾습니다. 컨테이너 이미지를 실행 중인 컨테이너, 쿠버네티스·서버리스 워크로드와 연결해 보여주기 때문에, 레지스트리에 저장만 된 이미지와 운영 환경에 배포된 이미지를 구분할 수 있습니다. Runtime Vulnerability Reachability는 eBPF 기반 Container Runtime Sensor로 실행 중인 컨테이너에서 실제로 사용되는 취약 패키지를 식별하고, 인터넷 노출과 워크로드 맥락을 더해 우선순위를 정합니다. 영향받는 워크로드를 이미지까지 역추적할 수 있어 의존성 업데이트, 이미지 재빌드, 재배포로 이어지는 조치 경로가 분명해집니다. KISA가 컨테이너 이미지를 점검 대상에 포함하고 컨테이너 환경은 새 이미지를 다시 배포하라고 안내한 부분과 연결되는 기능입니다. TotalAppSec은 공격자가 접근할 수 있는 웹 애플리케이션과 API 단위로 노출 범위를 확인합니다. 노출된 PHP 버전 정보를 통해 영향 가능성이 있는 애플리케이션을 표시하며, 호스트 인벤토리에 충분히 반영되지 않은 런타임도 대상에 포함됩니다. 노출된 버전 정보는 참고 지표이기 때문에, 실제 런타임 버전과 패치 상태는 VMDR과 TotalCloud 결과와 함께 확인합니다.실제 공격 가능한 자산 선별: ETM과 TruConfirm버전 대조는 수정되지 않은 빌드를 찾아주지만, 지금 공격이 가능한 자산이 어디인지는 알려주지 않습니다. Enterprise TruRisk Management(ETM)의 TruConfirm은 운영 자산에서 공격 가능성을 검증합니다. 대상 서버가 PHP를 실행하는지 확인한 뒤 공격자의 초기 동작을 본뜬 무해한 업로드 요청을 보내고, PHP 시작 경고를 통해 공격 진입점에 도달할 수 있는지와 권장 완화 설정(session.upload_progress.enabled=0)이 빠져 있는지를 확인합니다. 이 과정에서 파일을 만들거나 코드를 실행하거나 메모리 부하를 주지 않습니다. 노출이 확인된 자산은 TruRisk 점수가 상향되고, 근거와 함께 조치 대기열 상위로 올라갑니다. ETM은 이 검증 결과를 버전 기반 탐지와 함께 보여주기 때문에 진입점이 열려 있는지와 빌드가 패치됐는지를 한 번에 확인할 수 있고, 조치 후 다시 검증해 진입점이 닫혔다는 근거를 감사 대응에 활용할 수 있습니다. Qualys가 공개한 한 고객 환경에서는 PHP를 실행하는 자산 1,539개 중 TruConfirm에서 양성 결과가 나온 자산이 25개였습니다. 검증 결과는 인터넷 노출, 업무 중요도와 함께 판단해야 하며, 음성 결과가 모든 공격 경로가 닫혔다는 뜻은 아닙니다.Qualys는 PHP2Shell 전용 Fightback 대시보드도 다운로드로 제공합니다. PHP를 실행하는 자산 전체와 발견 경로, 인터넷 노출 인스턴스, 지원 종료·미패치 버전, Apache mod_php 위험, 운영체제별 고위험 자산, 탐지 상태(활성·수정·재발생)를 한 화면에서 보여줍니다.패치 전 위험 완화: Qualys 완화 조치, TruRisk Eliminate, Policy AuditQualys 완화 조치는 PHP의 완화 지침과 Qualys TRU의 분석을 바탕으로 한 설정 단위 변경입니다. 호스트에서 웹 요청을 처리하는 모든 PHP 런타임의 세션 업로드 진행률 기능을 끄고 관련 세션 처리 설정을 강화하며, 애플리케이션 코드는 바꾸지 않습니다. 적용 후 PHP 서비스를 자동으로 재시작하고, 재시작 뒤에는 설정이 실제로 적용됐는지, 다른 곳에서 덮어쓰지 않았는지를 확인합니다. 로그에 재시작이 필요하다고 표시되면 수동으로 재시작합니다. 이 조치는 확인된 세션 처리 공격 경로에 대한 노출을 줄이지만 두 CVE의 모든 공격 경로를 제거하지는 않습니다. 업로드 진행률 기능을 사용하는 애플리케이션은 적용 후 동작을 테스트해야 합니다. 적용 방식은 에이전트 설치 여부에 따라 나뉩니다. 취약 탐지 결과가 있는 고객은 대시보드에서 Mitigate Now를 선택합니다. Cloud Agent를 설치할 수 없는 어플라이언스, DMZ 서버, 레거시 호스트는 TruRisk Eliminate의 Custom Assessment and Remediation(CAR) 라이브러리에 있는 완화 스크립트를 스캐너 기반 호스트에 직접 실행합니다. 대상은 QID 389102와 비인증 점검 QID 39033으로 외부 경계 구간부터 식별합니다.Policy Audit은 기본 제공 정책 "Assess PHP Secure Configuration Baseline"으로 PHP가 권장한 완화 설정이 모든 PHP 호스트에 적용됐는지 확인합니다. php.ini의 memory_limit, post_max_size, session.upload_progress.enabled, fatal_error_backtraces와 PHP-FPM 풀 설정의 pm.max_requests 등이 점검 항목입니다. Linux는 Qualys 스캐너와 Cloud Agent로, Windows는 Cloud Agent로 점검합니다. 이미 운영 중인 웹방화벽(WAF), 침입방지시스템(IPS), 엔드포인트 탐지·대응(EDR)도 추가 방어 계층으로 함께 쓸 수 있습니다. 패치도 완화도 어려운 시스템은 공개 접근을 제한하거나 일시적으로 격리하고, PHP 8.1 이하는 운영체제 벤더의 백포트를 적용하거나 격리 후 폐기를 계획합니다.패치 적용과 완료 확인: TruRisk Eliminate와 재검증벤더 패치가 나온 환경에서는 TruRisk Eliminate로 패치를 배포합니다. 2026년 10월 29일 업데이트된 Qualys 자료 기준으로 Ubuntu PHP 보안 업데이트가 배포 대상에 포함되며, Qualys는 이 업데이트의 패치 신뢰도를 High로 평가했습니다. 해당 업데이트(USN-8948-1)는 사용자 영역 PHP 패키지만 변경해 운영체제 재부팅이 필요하지 않습니다.패치 후에는 PHP를 불러오는 모든 서비스를 재시작해야 합니다. 특히 CVE-2026-109619는 재사용되는 PHP 워커에 남은 요청 상태를 악용하기 때문에 재시작 여부가 중요합니다. 완료 여부는 다음 순서로 확인합니다.1. 병렬 브랜치, 컨테이너, 호스팅 패널 패키지, 어플라이언스 번들을 포함해 모든 PHP 설치를 찾습니다.2. 올바른 패키지, 바이너리, 이미지를 업데이트합니다. 배포판 패키지는 전체 패키지 버전을 벤더 권고문과 대조하고, 컨테이너는 패치된 이미지를 받거나 다시 빌드합니다.3. 서비스를 재시작하거나 컨테이너를 재배포하고, 이전 빌드로 남아 있는 워커가 없는지 확인합니다.4. 패치 적용을 확인한 뒤 긴급 조치로 바꾼 memory_limit, 업로드 제한, 워커 재사용 설정을 운영 기준에 맞게 되돌립니다.5. TotalAppSec으로 웹 애플리케이션과 API를 다시 스캔하고, VMDR과 TotalCloud로 런타임의 버전과 패치 상태를 확인하며, TruConfirm 검증을 반복합니다.재스캔에 쓰는 QID 533068은 패치되지 않은 애플리케이션을 중단시킬 수 있는 침투형 점검이므로, 운영 환경이 아닌 시스템이나 패치가 확인된 시스템에서 사용하는 것이 권장됩니다.☑️ 자주 묻는 질문PHP2Shell은 무엇인가요?PHP2Shell은 PHP에서 발견된 취약점 CVE-2026-109618과 CVE-2026-109619를 함께 부르는 이름입니다. 두 취약점 모두 CVSS v4.0 기준 9.2점이며, 웹 요청을 처리하는 PHP 환경에서 인증 없이 원격 코드 실행을 허용합니다. 애플리케이션 코드가 아니라 PHP 자체의 결함입니다.어떤 PHP 버전으로 업데이트해야 하나요?PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 이상으로 업데이트해야 합니다. PHP 8.1 이하는 정기 지원 대상이 아니므로 배포판이나 지원 업체의 수정 빌드를 확인하거나 지원 버전으로 업그레이드해야 합니다. KISA는 PHP 8.2도 2026년 12월 31일 보안 지원이 종료되므로 8.3 이상으로 전환할 것을 권고했습니다.PHP 버전만 확인하면 취약 여부를 알 수 있나요?버전만으로는 판단하기 어렵습니다. 배포판 패키지는 이전 버전 번호를 유지한 채 수정 사항이 포함될 수 있고, 한 자산에 PHP 사본이 여럿이거나 php -v가 보여주는 버전이 웹 요청을 처리하는 설치본과 다를 수 있습니다. 버전 탐지와 함께 실행 중인 런타임과 공격 진입점의 노출 여부를 확인해야 합니다.패치 전에 적용할 수 있는 조치가 있나요?있지만 업데이트를 대신하지는 못합니다. PHP는 세션 업로드 진행률 기능 비활성화, 요청 크기 제한 등 임시 설정을 권고하며, 적용 후에는 모든 PHP 워커를 재시작해야 합니다. Qualys 완화 조치는 이 설정을 에이전트 설치 여부와 관계없이 적용하고 실제 적용 여부까지 확인하지만, 두 CVE의 모든 공격 경로를 막지는 않습니다.Qualys를 쓰지 않는 조직도 PHP2Shell 노출 여부를 확인할 수 있나요?Qualys는 PHP2Shell 무료 서비스를 활성화 시점부터 15일간, 최대 1,000개 자산을 대상으로 제공합니다. Qualys 클라우드에서 에이전트 없이 인터넷 노출 자산을 스캔하고, TruConfirm으로 공격 가능성을 확인하며, 스캐너를 통해 완화 조치를 적용하는 범위입니다.☑️ 마무리PHP2Shell에 대응하려면 업데이트와 함께 네 가지를 해야 합니다. 운영 중인 PHP를 빠짐없이 찾고, 그중 실제로 공격받을 수 있는 자산을 가려내고, 패치가 어려운 자산은 완화 조치로 위험을 줄이고, 패치 후에는 실행 중인 런타임까지 확인하는 것입니다. 이 글에서 살펴본 CSAM, VMDR, TotalCloud, Container Security, TotalAppSec, ETM, TruRisk Eliminate, Policy Audit은 모두 Qualys Enterprise TruRisk Platform을 구성하는 앱으로, 자산 가시성과 취약점 우선순위화, 조치를 하나의 플랫폼에서 다룹니다.클라우드네트웍스는 Qualys 파트너사로서 Enterprise TruRisk Platform 도입 검토부터 구축, 운영까지 지원합니다. 운영 중인 PHP 자산 현황 파악, 지원 종료 버전 관리, 패치 전 완화와 패치 후 검증 체계를 어디서부터 갖출지 함께 검토하고자 하신다면 아래로 문의해 주시기 바랍니다.▶ 퀄리스(Qualys) 자세히보기[출처 : Qualys, "PHP2Shell: Find, Mitigate, and Patch Now", Qualys, "Can't Patch PHP2Shell Yet?", Qualys, "PHP2Shell Risk Assessment", 바이라인네트워크, "KISA, 'PHP2Shell' 보안 취약점 긴급 대응 수칙 공개", "'프로그래밍 언어' PHP 보안 위험의 실체…대책은?"]

개발자와 현업 부서는 이미 여러 LLM과 코딩 에이전트를 업무에 쓰고 있습니다. 이 확산을 막으면 경쟁력을 잃지만, 애플리케이션이 어떤 모델을, 누가, 어떤 데이터로 호출하는지 통제하지 못하면 AI 트래픽은 관리할 수 없는 상태가 됩니다. 개인정보보호법과 금융권 망분리 규제, 감사 요건은 누가 무엇을 호출했는지를 증적으로 남길 것을 요구합니다.국내 기업의 AI 도입은 이처럼 속도와 통제라는 두 요구를 함께 안고 있습니다. 콩(Kong)은 2026년 8월 발간한 AI Gateway 백서에서 국내 통신·금융·제조·플랫폼 기업이 Kong AI Gateway 도입을 검토하며 실제로 제기한 요구사항을 정리했습니다. 근본적인 요건은 업종과 관계없이 겹쳤고, 백서는 이를 여덟 개 영역으로 나눠 어느 업종에서 나온 요구인지와 Kong의 대응 기능을 함께 담았습니다.이 글에서는 국내 기업이 AI 게이트웨이를 검토하며 마주한 과제, 여덟 개 영역별 요구사항과 Kong AI Gateway의 대응 방식, 개인정보보호법·ISMS-P 통제 항목과의 연결, 도입 시 고려사항을 정리합니다.✅ 국내 기업은 AI 게이트웨이에 무엇을 요구하는가AI 게이트웨이는 애플리케이션과 AI 에이전트가 LLM과 MCP(Model Context Protocol) 서버를 호출하는 트래픽의 길목에서 인증, 정책, 민감정보 마스킹, 로깅, 라우팅을 일괄 적용하는 운영 계층입니다. 국내 기업이 이 계층에 제기한 요구사항은 접근 통제, 라우팅과 표준화, 보안과 가드레일, 가용성, 트래픽과 성능, 비용 최적화, 에이전트와 MCP, 아키텍처와 컴플라이언스의 여덟 개 영역에 걸쳐 있습니다. 그중 주민등록번호 같은 한국어 민감정보 마스킹, 망분리 환경의 온프레미스 배포, 개인정보보호법과 ISMS-P 통제 항목 대응은 국내 규제 환경에서 나온 요구입니다.✅ 요구사항의 배경이 된 6가지 과제AI 게이트웨이를 검토하고 도입하는 과정에서 반복적으로 확인된 과제는 여섯 가지입니다.첫째는 섀도우 AI(Shadow AI)입니다. 구성원이 쓰는 다양한 AI 서비스와 API, 개인 API 키에 대한 통제력이 사라진 상태여서, 권한을 가진 사용자만 접근하도록 강제하는 거버넌스가 통신과 제조를 포함한 산업 전반에서 요구되고 있습니다.둘째는 흩어진 모델과 계정입니다. Amazon Bedrock, Claude, Azure OpenAI 같은 외부 모델과 사내 구축형 LLM을 하나의 표준 인터페이스로 통합하고, 승인된 주체만 특정 모델에 접근하도록 호출 경로를 중앙에서 제어하려는 수요가 높습니다.셋째는 국내 기준에 맞춘 데이터 보안입니다. 주민등록번호나 계좌번호 같은 민감정보를 실시간으로 탐지하고 마스킹해 외부로 나가지 않도록 하는 것은 개인정보보호법과 금융권 가이드라인을 충족하기 위한 핵심 요건이며, 이 보안 처리는 모두 기업 내부 인프라 안에서 완결되어야 합니다. 보험 증권 정보나 도면 같은 이미지 분석에 필요한 분야별 요건도 있습니다.넷째는 망분리 환경입니다. 금융, 제조, 공공 부문은 외부 인터넷 연결이 완전히 차단된 온프레미스 구동을 기본 전제로 합니다. 설정 제어와 실제 트래픽 처리가 논리적으로 분리되어, 폐쇄망 안에서도 독자적으로 배포하고 운영할 수 있는 구조가 뒷받침되어야 합니다.다섯째는 상용 서비스 수준의 가용성과 비용입니다. 서비스 장애 시 자동 우회와 계정별 토큰 할당량 제어는 안정적인 상용 서비스의 전제 조건이며, 대량의 스트리밍 트래픽을 처리하면서 예산 범위 안에서 AI 자원을 통제하는 운영 역량이 요구됩니다.여섯째는 에이전트와 MCP입니다. Claude Code 같은 코딩 에이전트와 MCP 도구가 내부 API에 무분별하게 접근하는 것을 막고, 에이전트 사이의 상호작용을 추적하며 트래픽을 통제하는 일이 새로운 운영 과제로 떠오르고 있습니다.✅ 요구사항 8개 영역별 Kong AI Gateway 대응Kong AI Gateway는 AI 트래픽이 지나는 길목에서 통제합니다. 개별 AI 클라이언트가 호출하던 엔드포인트를 Kong으로 전환하면, 애플리케이션 로직과 구현된 코드를 바꾸지 않고 인증과 권한, 민감정보 처리, 요청 제한, 로깅, 모델 라우팅을 게이트웨이에서 일괄 적용할 수 있습니다. 구성은 설정과 정책을 관리하는 컨트롤 플레인과 실제 트래픽을 처리하는 데이터 플레인으로 나뉩니다.아래는 국내 기업이 제기한 요구사항을 여덟 개 영역으로 나눈 것입니다. 영역마다 어떤 요구가 있었고 그 요구가 어느 업종에서 나왔는지, Kong AI Gateway가 이에 어떻게 대응하는지를 함께 정리했습니다.1. 접근 통제 ─ 미승인 LLM과 개인 계정 사용 차단접근 통제 영역에서는 사내 표준 인증과의 연동, 사용자·부서·환경별 세부 권한, 실제 LLM API 키 노출 방지가 주로 요구됐습니다. 통신, 금융, 플랫폼 업종에서 제기됐으며, 공통된 목적은 검증된 사용자에게만 접근 권한을 주고 부서 단위의 세밀한 거버넌스를 세우며 미승인 개인 계정 사용을 통제하는 것이었습니다.Kong AI Gateway는 SAML, OIDC(OpenID Connect), OAuth2 같은 표준 프로토콜로 기존 인증 체계를 그대로 통합하며, Azure Entra ID, 옥타(Okta), AD 연동을 지원합니다. 권한은 인증 서버가 전달하는 사용자 ID와 그룹 정보, 접속 IP 같은 조건을 기준으로 엔드포인트별로 다르게 부여합니다. 이미 운영 중인 사내 계정 체계를 AI 사용 권한 관리에 그대로 활용하는 방식입니다.OpenAI나 Amazon Bedrock 같은 실제 프로바이더의 인증 키는 Kong이 보관하고, 사용자에게는 가상 키를 발급해 인증을 대행합니다. 사용자는 항상 Kong을 거쳐야 모델에 접근할 수 있으므로 실제 키가 사용자에게 노출되지 않습니다. 데이터 플레인이 AWS나 Azure 같은 클라우드에서 실행될 때는 IAM 역할 기반 인증을 지원하고, 관리자 콘솔인 Kong Manager 로그인에는 OIDC 매핑과 역할 기반 접근 제어(RBAC), IP 제한을 적용합니다.2. 라우팅과 표준화 ─ 다중 모델을 단일 엔드포인트로 통합통신, 금융, 제조 업종에서 주로 제기된 영역이며, 공통된 목적은 이식성입니다. 클라이언트는 Kong 엔드포인트 하나로 연결하고, 모델 교체와 정책은 게이트웨이에서 일괄 관리하는 구조가 요구됐습니다.Kong AI Gateway는 OpenAI 호환 규격을 제공하므로, 모델이나 벤더가 바뀌어도 애플리케이션을 수정할 필요가 없습니다. vLLM 기반 서버처럼 호환 인터페이스를 쓰는 온프레미스 모델도 같은 방식으로 연결됩니다.모델 선택은 게이트웨이에서 제한합니다. 팀이나 사용자별로 허용 모델 목록을 지정해 그 안에서만 선택하도록 강제하고, 요청 본문의 model 값을 읽어 등록되지 않은 모델 요청은 거절합니다. 여기에 시맨틱 라우팅을 더하면 질의의 의미를 분석해 간단한 질의는 저비용 모델로, 중요한 질의는 고성능 모델로 자동 분기하고 분기된 모델마다 다른 정책과 가드레일을 적용할 수 있습니다.3. 보안과 가드레일 ─ 한국어 민감정보 탐지와 마스킹금융, 제조, 플랫폼 업종이 제기한 영역입니다. 특히 금융 업종에서는 고객명과 계약정보가 결합된 문장, 표와 첨부파일, 긴 프롬프트 같은 문맥 단위의 탐지가 요구됐습니다. 정해진 패턴을 찾는 방식만으로는 부족하고 의미 기반 탐지가 필요한 지점입니다.민감정보 처리는 개인 식별 정보(PII) 새니타이저가 담당합니다. 기본 탐지 항목에 더해 정규식 커스텀 규칙으로 주민등록번호, 휴대폰 번호, 계좌번호, 보험계약번호 같은 국내 항목을 탐지하고, 걸러낸 값은 플레이스홀더로 치환해 원문이 외부 모델로 나가지 않게 합니다.프롬프트 자체에 대한 통제도 함께 적용됩니다. 악성 프롬프트 차단에는 키워드 필터와 의미 기반 탐지를 함께 쓰고, AWS Bedrock Guardrails나 Azure Content Safety 같은 외부 가드레일과 연계할 수 있습니다. 민감한 요청을 관리자 승인 후에 호출하도록 하는 절차처럼 사내 고유의 보안 프로세스가 필요한 경우에는 커스텀 플러그인으로 확장해 구현합니다.4. 가용성 ─ 모델 장애 시 다단계 자동 전환금융 업종에서 제기된 영역으로, 다단계 폴백은 금융권의 상용 운영 전제 조건으로 반복해서 등장했습니다. 특히 외부 모델과 온프레미스 내부 LLM을 조합하는 구성이 구체적으로 요구됐습니다.Kong AI Gateway는 대체 모델, 대체 계정, 온프레미스 순으로 이어지는 다단계 자동 전환을 구성합니다. 외부 모델에 장애가 생기면 내부망의 온프레미스 모델로 요청을 넘기고, 장애 노드는 헬스 체크로 격리한 뒤 정상 노드로 재시도해 장애가 연쇄적으로 번지는 것을 막습니다.계정 단위의 한도 문제에도 같은 방식으로 대응합니다. 동일 모델에 대한 여러 자격 증명을 하나의 풀로 묶어 부하를 분산하면, 토큰 한도를 모두 쓴 계정 대신 가용한 계정으로 요청이 넘어가 한도 초과에 따른 차단을 피할 수 있습니다. 컨트롤 플레인에 장애가 생겨도 데이터 플레인은 설정 캐시로 트래픽을 계속 처리합니다.5. 트래픽과 성능 ─ 장시간 스트리밍과 대량 동시 요청통신, 금융 업종이 제기한 영역입니다. 금융권에서는 서비스 수준의 대규모 동시 요청을 지연 없이 처리하는 것과 콜드 스타트 없는 안정적인 처리량이 성능 요건의 핵심이었습니다.Kong AI Gateway는 라우트와 구간별 타임아웃을 세밀하게 설정해 긴 스트리밍 응답을 처리합니다. 일반적인 API 게이트웨이에서 응답 도중 연결이 끊기는 문제를 피하기 위한 구성이며, 서버 전송 이벤트(Server-Sent Events) 스트림도 모델과 유형별로 개별 구성할 수 있습니다.처리량은 무상태 설계로 확보합니다. 상태를 게이트웨이에 두지 않기 때문에 컨테이너를 늘리는 것만으로 수평 확장할 수 있고, Kubernetes의 파드 자동 확장이나 가상머신 오토스케일링 그룹을 그대로 활용합니다.6. 비용 최적화 ─ 조직·팀·개인별 토큰 사용량 통제통신, 금융, 제조 업종에서 주로 제기됐으며, 토큰 사용량을 조직·팀·개인 단위로 가시화하고 예산을 통제하는 것은 도입을 검토한 기업 대부분의 공통 관심사였습니다.Kong AI Gateway는 호출 건수가 아니라 LLM 토큰 수량이나 산정 비용을 기준으로 부서와 사용자별 상한을 둡니다. 예산을 기준으로 사용량을 통제할 수 있는 구조입니다. 여기에 시맨틱 캐싱을 적용하면 벡터 DB와 연동해 프롬프트의 의미적 유사성을 판별하고 캐시된 응답을 반환해, 반복되는 질의에서 토큰 비용과 응답 지연을 줄입니다.사용량은 Prometheus와 Grafana로 수집해 조직, 팀, 개인 단위의 대시보드로 구성합니다. 어느 조직이 얼마를 쓰고 있는지 확인한 뒤 상한을 조정하는 운영이 가능해집니다.7. 에이전트와 MCP ─ 에이전트의 내부 API 호출 통제제조, 플랫폼, 금융 업종이 제기한 영역입니다. 제조 업종에서는 AI 에이전트가 사내 시스템에 접근하거나 내부 API를 무제한으로 호출하는 것을 정보보안 관점에서 통제하려는 요구가 제기됐습니다.Kong AI Gateway는 REST API를 MCP 형식으로 자동 전환해, 별도 개발 없이 내부 도구를 MCP로 연결합니다. 이때 개별 도구마다 사용자 접근 권한을 다르게 정의할 수 있어, 에이전트가 쓸 수 있는 도구의 범위가 권한에 따라 정해집니다. 인증에 쓰이는 개인 액세스 토큰은 Kong이 관리하며 하시코프 볼트(HashiCorp Vault) 같은 외부 시크릿 관리 도구와 연계합니다.에이전트가 외부로 나가는 경로도 통제 대상입니다. 호출 주체와 조건에 따라 외부 호출 가능 여부를 판별해 무단 반출을 차단하고, 검색 증강 생성 시스템과 에이전트, MCP 도구 서버 사이의 통신은 게이트웨이를 거치게 해 통제하고 추적합니다.8. 아키텍처와 컴플라이언스 ─ 망분리 환경 배포와 감사 대응금융, 공공 업종이 제기한 영역이며, 망분리는 이 업종들에서 도입의 전제 조건이었습니다. 컨트롤 플레인과 데이터 플레인을 분리하는 구조와 온프레미스 배포가 이 요건에 대응합니다.두 플레인을 분리하면 폐쇄망 안에 데이터 플레인만 단독으로 배포할 수 있고, 고객의 요청과 응답 데이터는 고객 네트워크 안에 머뭅니다. 인터넷이 차단된 환경에서는 이미지와 패키지를 오프라인으로 설치하고 플러그인은 사내 프라이빗 레지스트리나 미러로 배포합니다. 배포 대상은 AWS EKS, Azure AKS, 가상머신, 물리 서버 가운데 선택할 수 있습니다.감사 대응은 기록에서 시작합니다. 모든 AI 요청과 응답을 페이로드까지 포함해 외부 보안 정보 및 이벤트 관리(SIEM) 시스템으로 전송하고, 관리자 설정 변경 이력은 별도로 저장해 조회합니다. OpenTelemetry를 연동하면 개별 호출 단위의 지연과 트랜잭션을 추적해 에이전트 워크플로의 병목을 확인할 수 있습니다. 게이트웨이 구성 자체는 decK CLI와 테라폼(Terraform)으로 코드화해 CI/CD 파이프라인에서 관리합니다.✅ 개인정보보호법·ISMS-P 통제 항목과의 연결국내 기업의 AI·API 거버넌스는 특정 규제 조항에 직접 대응해야 합니다. Kong AI Gateway의 기능은 개인정보보호법, ISMS-P, ISO 27001, GDPR의 요구와 다음과 같이 연결됩니다.개인정보 최소화와 접근통제통제 영역Kong AI Gateway 대응대응 규제개인정보 최소화응답에서 불필요하거나 민감한 필드를 제거·마스킹개인정보보호법 제3조·제16조(최소 처리)대량 조회·응답량 제한요청 제한, 요청 크기 제한, 봇 탐지로 대규모 조회와 반복 호출 제한개인정보보호법 제29조(안전조치의무)최소 권한 기반 접근통제RBAC, ACL, 컨슈머 그룹으로 주체별 접근 범위를 최소 권한으로 차등 부여개인정보보호법 제29조, 안전성 확보조치 기준기본 차단인증과 인가 강제, 정책을 충족하지 않는 요청은 기본 거부안전성 확보조치 기준(접근통제)서버 계층 권한 검사게이트웨이 계층에서 요청별 접근 권한 검증, 외부 정책 엔진 연동안전성 확보조치 기준암호화와 로깅·감사통제 영역Kong AI Gateway 대응대응 규제전송 구간 암호화클라이언트와 게이트웨이, 컨트롤 플레인과 데이터 플레인 간 TLS/mTLS 통신개인정보보호법(전송 시 암호화), GDPR 제32조, ISO 27001 A.8.24저장 민감데이터 암호화민감데이터 암호화, 고객 관리형 암호화 키, FIPS 140-2개인정보보호법(암호화·키 관리), 공공·금융 암호모듈 요건감사 로그관리 API 요청과 설정 변경 이력 기록개인정보보호법(접속기록 보관·점검), ISMS-P 2.9·2.11SIEM 연동외부 SIEM으로 로그를 전송해 상관분석·경보개인정보보호법(접속기록), ISO 27001 A.8.15·A.8.16이상징후 탐지업무 외 시간 접근, 대량 조회, 해외 IP 등 비정상 패턴 탐지ISMS-P 2.11자격 증명 회수·교체자격 증명 관리, 시크릿 주기적 교체, 토큰 수명 관리와 폐기안전성 확보조치 기준✅ AI 게이트웨이 도입을 검토할 때 고려할 사항단계적으로 적용하는 방식이 현실적입니다. 통합 라우팅과 인증부터 시작해 개인정보 탐지와 가드레일, 비용 통제, MCP와 에이전트 통제로 범위를 넓혀 가는 순서가 자연스럽습니다. 처음부터 모든 정책을 켜기보다 트래픽을 게이트웨이로 모으는 것이 먼저입니다.게이트웨이 경유를 전제로 설계해야 합니다. 게이트웨이는 트래픽이 지나는 길목에서 통제하므로, 모든 AI 트래픽이 게이트웨이를 경유한다는 전제를 아키텍처와 배포 단계에서 함께 세워야 통제가 완성됩니다. 엔드포인트 설정을 강제하고, 외부로 나가는 네트워크 트래픽 정책을 함께 적용하는 것이 여기에 해당합니다.일부 시나리오는 사전 설계가 필요합니다. 장시간 스트리밍과 동시에 동작하는 가드레일 조합, 사람이 개입하는 승인 워크플로는 표준 기능과 커스텀 확장을 함께 쓰는 구성입니다. 실제 구축 단계로 넘어가기 전에 시나리오별로 검증하는 것이 권장됩니다.규제 대응은 매핑에서 시작합니다. 앞서 정리한 규제 매핑을 ISMS-P 인증이나 개인정보보호위원회 점검 같은 조직의 실제 통제 항목과 연결하면, 게이트웨이 설정을 규제 증적으로 활용할 수 있습니다.이 글에서 다룬 요구사항의 전체 카탈로그와 참조 아키텍처, 업종별 적용 사례는 Kong AI Gateway 백서에 정리되어 있습니다. 아래 링크에서 신청하시면 백서를 받아 보실 수 있습니다.▶ Kong AI Gateway 백서 다운로드✅ 자주 묻는 질문AI 게이트웨이는 어떤 역할을 하나요?AI 트래픽이 지나는 길목에서 인증과 권한, 민감정보 마스킹, 요청 제한, 로깅, 모델 라우팅을 일괄 적용하는 운영 계층입니다. 애플리케이션 로직과 구현된 코드를 바꾸지 않고 적용하며, 클라이언트는 게이트웨이 엔드포인트 하나로 연결됩니다.망분리된 폐쇄망에서도 Kong AI Gateway를 운영할 수 있나요?운영할 수 있습니다. 컨트롤 플레인과 데이터 플레인을 분리해 폐쇄망 안에 데이터 플레인을 단독으로 배포하고, 인터넷이 차단된 환경에서는 이미지와 패키지를 오프라인으로 설치합니다. 고객의 요청·응답 데이터는 고객 네트워크 안에 머물며, 컨트롤 플레인 장애 시에도 데이터 플레인이 설정 캐시로 트래픽을 처리합니다.주민등록번호 같은 국내 개인정보도 탐지할 수 있나요?탐지할 수 있습니다. 기본 개인정보 탐지에 더해 정규식 커스텀 규칙으로 주민등록번호, 휴대폰 번호, 계좌번호, 보험계약번호 같은 국내 항목을 탐지하고 플레이스홀더로 치환합니다. 고객명과 계약정보가 결합된 문장처럼 문맥 단위 탐지가 필요한 경우는 정해진 패턴을 찾는 방식만으로는 부족해 의미 기반 탐지가 필요합니다.섀도우 AI는 게이트웨이에서 어떻게 차단하나요?사내 인증 체계와 연동해 승인된 사용자만 통과시키는 방식으로 차단합니다. SAML, OIDC, OAuth2로 기존 인증을 통합하고 사용자 그룹에 따라 권한을 나누며, 그룹이 없는 개인 계정의 요청은 차단합니다. 실제 LLM API 키는 게이트웨이가 보관하고 사용자에게는 가상 키를 발급하므로, 사용자는 게이트웨이를 거쳐야만 모델에 접근할 수 있습니다.AI 게이트웨이 도입은 어디서부터 시작하나요?트래픽을 게이트웨이로 모으는 것부터 시작합니다. 통합 라우팅과 인증을 먼저 적용한 뒤 개인정보 탐지와 가드레일, 비용 통제, MCP와 에이전트 통제로 넓혀 가는 순서가 자연스럽습니다. 장시간 스트리밍과 가드레일 조합, 승인 워크플로처럼 커스텀 확장이 필요한 시나리오는 실제 구축으로 넘어가기 전에 시나리오별로 검증하는 것이 권장됩니다.✅ 마무리국내 기업이 AI 게이트웨이에 제기한 요구사항은 섀도우 AI 차단과 한국어 민감정보 마스킹부터 다단계 폴백, 토큰 사용량 통제, 망분리 환경 배포까지 여덟 개 영역에 걸쳐 있습니다. 모두 AI 트래픽이 지나는 길목에서 적용하는 정책이며, Kong AI Gateway는 이 요구사항들을 하나의 게이트웨이 구조 위에서 함께 적용합니다. 조직 안에서 누가 어떤 데이터로 무엇을 호출하는지 추적하고 통제하지 못하면 AI 확산에 따른 위험을 관리하기 어렵습니다.클라우드네트웍스는 고객 환경의 AI 트래픽 구성과 인증 체계, 보안·규제 요건을 확인하고, Kong AI Gateway 기준으로 적용 범위와 배포 형태를 검토하는 과정부터 구축까지 지원합니다. 국내 규제 환경에 맞춘 AI 게이트웨이 도입을 검토하고 계시다면 클라우드네트웍스로 문의해 주시기 바랍니다.▶ Kong AI Gateway 자세히보기

클라우드네트웍스는 2026년 9월 18일 한국정보보호학회가 개최한 WISE 2026(정보보호 교육 및 거버넌스 워크숍)에 퀄리스(Qualys)의 파트너사로 참여했습니다. 이날 Qualys의 김주형 상무는 "AI가 바꾸는 사이버 리스크 관리: 자동화와 보안 거버넌스의 새로운 패러다임"을 주제로 발표했습니다.발표가 주목한 변화는 프런티어 AI의 등장입니다. 2026년 4월 7일 앤트로픽(Anthropic)이 차세대 AI 모델인 Claude Mythos의 프리뷰를 공개했고, Qualys는 프런티어 AI가 사이버 공격의 도구로 부상한 지금을 사이버 보안의 변곡점으로 봅니다. Qualys는 Mythos를 비롯한 프런티어 AI 모델의 영향으로 취약점이 기하급수적으로 늘고, 취약점이 악용되기까지 걸리는 시간이 수개월·수주에서 수시간으로 줄었다고 설명합니다. 침해 사고 통계에서도 취약점 악용의 비중이 가장 높게 나타났습니다. Qualys가 인용한 버라이즌(Verizon)의 2026 데이터 침해 조사 보고서(Data Breach Investigations Report)에 따르면, 오류와 내부 오남용을 제외한 침해 사고의 알려진 최초 침투 경로 가운데 취약점 악용이 31%로 가장 높았고 피싱 16%, 자격 증명 악용 13%, 프리텍스팅 6%가 뒤를 이었습니다.취약점은 늘고 대응할 시간은 짧아진 상황에서 Qualys가 제시하는 해법은 리스크 운영 센터(ROC)입니다. 이 글에서는 발표 내용을 바탕으로 ROC가 무엇이고, 취약점 리스크를 어떻게 모으고 줄여 나가는지 살펴봅니다.☑️ 리스크 운영 센터(ROC)란 무엇인가?리스크 운영 센터(Risk Operations Center, ROC)는 Qualys가 공격 표면 관리에서 리스크 표면 관리로의 전환을 위해 제시하는 개념입니다. 자산과 보안 발견 항목을 통합하고, 위협 인텔리전스와 비즈니스 맥락을 반영해 리스크 우선순위를 정한 뒤, 대응 조치와 컴플라이언스·경영진 보고까지 연결합니다. ROC는 Qualys ETM(Enterprise TruRisk Management)을 기반으로 동작합니다. ETM은 Qualys와 타사 보안 도구의 발견 항목, 위협 인텔리전스, 비즈니스 맥락을 한곳에 모아 이 흐름을 수행하는 Qualys의 솔루션으로, 이를 통해 ROC는 사이버 리스크를 비즈니스와 연계합니다.☑️ 취약점 대응 방식을 다시 점검해야 하는 이유Qualys는 경영진과 최고정보보호책임자가 알고 싶어 하는 것으로 두 가지를 꼽습니다. AI로 인해 생기는 위험에 어떻게 대응하고 있는지, 그리고 더 빠른 대응을 위해 인력을 늘리는 것이 답인지입니다. 그리고 경영진이 듣고 싶어 하는 답은 AI가 주도하는 자율형 공격에 맞서 AI 기반의 자율형 대응·복구 체계를 갖추고 있다는 것이라고 설명합니다.Qualys는 초우선순위 설정이 필요한 이유로, 대부분의 조직이 실제 위험이 아닌 이론적 위험을 평가하고 대응하는 데 많은 시간과 자원을 쓰고 있다는 점을 제시합니다.악용이 가능한 취약점이라고 해서 모두 실제로 악용될 수 있는 것은 아닙니다. Qualys에 따르면 우선순위가 지정된 노출 가운데 보완 통제(Compensating Controls)를 우회해 실제로 악용 가능한 것은 20% 미만이며, 자사 환경에서 실제 악용 가능성을 검증하면 대응해야 할 조치의 수를 줄일 수 있습니다.Qualys는 오늘날의 리스크 관리를 끝없이 튀어나오는 위험을 하나씩 쳐내는 두더지 잡기 게임에 비유하고, 공격 표면 관리에서 리스크 표면 관리로의 전환을 제시합니다.☑️ 자율형 복구를 구성하는 세 가지 요소Qualys는 자율형 복구(Autonomous Remediation)를 운영에 적용하기 위한 요소로 초고속 탐지, 초우선순위화, 제로데이 취약점 조치의 세 가지를 제시합니다.첫째, 초고속 탐지는 취약점이 공개되는 즉시 탐지하는 것으로, 온프레미스, 클라우드, 애플리케이션, 컨테이너 전 영역에 대한 가시성과 보호를 제공합니다.둘째, 초우선순위화는 위협 수준, 비즈니스 영향도, 자산 중요도를 기준으로 우선순위를 정하고, 기존 보안 통제를 고려해 실제 악용 가능성을 검증하는 것입니다.셋째, 제로데이 취약점 조치는 패치와 설정 변경을 통한 대응 방안을 제공하고, 운영 안정성을 보장하는 자동화 기능을 갖추는 것입니다. 안정적인 운영 복원력을 위해서는 패치 신뢰도 점수, 패치 없이 적용하는 복구·완화 조치, 단계적 배포, 롤백 기능이 필요합니다.☑️ ROC로 취약점 리스크를 줄이는 과정ROC의 흐름은 통합 자산 인벤토리, 리스크 요인 취합, 위협 인텔리전스, 비즈니스 맥락, 리스크 우선순위화, 리스크 대응 오케스트레이션, 컴플라이언스 및 경영진 보고로 이어집니다. 이 흐름은 사이버 리스크를 비즈니스 관점에서 정량화하는 측정, 경영진 보고와 티켓 처리를 담당하는 소통, 패치·완화 조치와 추적을 수행하는 제거의 세 가지 역할로 묶입니다. 이 글에서는 이를 발견 항목 통합, 우선순위화, 위험 제거, 보고의 네 단계로 나누어 살펴봅니다.1단계. Qualys와 타사 도구의 발견 항목 통합ROC는 먼저 흩어진 발견 항목을 한곳에 모읍니다. Qualys가 수집한 취약점, 설정, 컴플라이언스, 클라우드 보안, 애플리케이션 보안, 자산 관리, 공격 표면, AI 보안 관련 발견 항목과 함께, 타사 취약점 관리, 컴플라이언스, 런타임 보안, 애플리케이션 보안 도구의 결과도 취합합니다. 여기에 자체 취약점 연구로 보강한 위협 인텔리전스 피드와, 구성 관리 데이터베이스 및 사용자 정의 데이터 소스에서 가져온 비즈니스 맥락을 더합니다.Qualys가 제시한 예시에서는 여러 보안 도구에 각각 수백만 건씩 쌓인 발견 항목이 모여 총 6,250만 건이 됩니다. 수백만 개의 파편화된 노출이 하나로 모이는 단계입니다.2단계. 우선순위화와 실제 악용 가능성 검증같은 예시에서 6,250만 건은 세 단계를 거쳐 줄어듭니다. 먼저 다크웹에서 언급이 늘고 있는지, 위협 행위자가 무기화했는지, 업계를 겨냥한 악성코드·랜섬웨어 공격에 쓰이는지 같은 위협 맥락을 반영하면 217만 건(4%)이 남습니다. 여기에 결제카드 산업 데이터 보안 표준 대상 자산, 인터넷에 노출된 자산, 데이터베이스, 매출을 창출하는 애플리케이션 등 비즈니스 핵심 자산인지를 반영하면 30만 4천 건(1% 미만)으로 줄어듭니다.마지막으로 트루컨펌(TruConfirm)이 보완 통제를 고려해 실제 악용 가능성을 검증합니다. 변형된 무해한 네트워크 페이로드로 악용 가능 여부를 확인하는 방식이며, 이 단계를 거치면 최종 조치 대상은 6만 건(0.1% 미만)이 됩니다. 예시에서 조치 비용도 312만 달러에서 61만 2천 달러, 31만 1천 달러를 거쳐 3만 1천 달러로 줄어듭니다.3단계. 패치 적용 여부와 관계없는 위험 제거조치 대상이 정해지면 트루리스크 엘리미네이트(TruRisk Eliminate)로 위험을 제거합니다. 트루리스크 엘리미네이트는 패치 적용 여부와 관계없이 위험을 제거하는 것을 목표로 합니다. 조치 방식은 SCCM·Intune과 연동한 패치 배포, 패치 없이 적용하는 완화 조치, 클라우드 악용 방지, 비준수 자산 격리, 사용하지 않는 소프트웨어 제거로 나뉩니다.앞서 제로데이 취약점 조치에 필요한 요소로 꼽은 패치 신뢰도 점수와 단계적 배포도 여기에 포함되며, 배포는 1단계에서 4단계까지 나누어 적용합니다. Qualys가 밝힌 자체 수치로는 1억 5천만 건 이상의 패치 배포, 4천만 건 이상의 무인 자동 패치, 0.1% 미만의 롤백률, 98.2%의 첫 배포 성공률이 있습니다.4단계. 사업 단위별 사이버 리스크 보고Qualys는 리스크 관리를 기업이 직면할 수 있는 막대한 재정적 손실의 가능성을 줄여가는 과정으로 봅니다. ROC는 사업 단위별 비즈니스 가치와 트루리스크 점수(TruRisk Score)를 함께 보여주고, 리스크 허용 수준을 기준선으로 표시합니다.이 화면에서는 어느 사업 단위의 리스크가 허용 수준을 넘었는지, 그 사업 단위의 비즈니스 가치는 얼마인지를 함께 비교할 수 있습니다. 사이버 리스크를 비즈니스 관점에서 정량화하고, 경영진 보고와 티켓 처리로 전달하는 단계입니다.☑️ 에이전트형 AI ROC와 다중 모델 전략Qualys는 에이전트형 AI ROC를 자율형 리스크 관리를 위한 디지털 인력으로 소개합니다. 앞서 살펴본 자율형 복구의 세 가지 요소, 즉 초고속 탐지, 초우선순위화, 제로데이 취약점 조치를 Qualys AI-ROC 기반의 취약점 자율 해결로 구현하며, 이를 위한 에이전트로 Agent Sara, Agent Val, Agent Insta를 소개했습니다.AI 모델은 추론 성능과 비용 효율을 함께 고려해 용도별로 나누어 씁니다. 플랫폼의 에이전트형 AI 작업에는 라마(Llama), 미스트랄(Mistral) 같은 오픈소스 모델, 마이크로소프트(Microsoft)의 Phi-4 Mini 기반 맞춤형 소형 언어 모델, Anthropic의 Claude Haiku·Sonnet·Opus를 통합합니다. 내부 위협 연구와 방어에는 Anthropic의 Glasswing 및 사이버 검증 프로그램(Cyber Verification Program), 오픈AI(OpenAI)의 Trusted Access for Cyber를 활용하고, 다른 연구소의 프런티어 모델도 평가하고 있습니다. 정적 애플리케이션 보안 테스트 영역에서는 고객 소스코드의 발견 항목을 Qualys ETM으로 가져와 런타임 맥락으로 우선순위를 정한 뒤 패치하거나 완화합니다.☑️ 자주 묻는 질문리스크 운영 센터(ROC)는 무엇인가요? Qualys가 공격 표면 관리에서 리스크 표면 관리로의 전환을 위해 제시하는 개념입니다. 자산과 보안 발견 항목을 통합하고 위협 인텔리전스와 비즈니스 맥락으로 우선순위를 정한 뒤, 대응 조치와 경영진 보고까지 연결합니다.취약점 우선순위는 어떤 기준으로 정하나요? 위협 수준, 비즈니스 영향도, 자산 중요도가 기준입니다. 여기에 트루컨펌으로 보완 통제를 고려한 실제 악용 가능성을 검증해 조치 대상을 좁힙니다.패치를 바로 적용할 수 없는 시스템은 어떻게 대응하나요? 트루리스크 엘리미네이트로 패치 없이 적용하는 완화 조치, 비준수 자산 격리, 사용하지 않는 소프트웨어 제거 같은 방식을 선택할 수 있습니다. 패치를 적용할 때는 패치 신뢰도 점수와 단계적 배포, 롤백 기능으로 운영 안정성을 확보합니다.다른 보안 도구의 결과도 함께 관리할 수 있나요? 가능합니다. ROC는 Qualys 발견 항목과 함께 타사 취약점 관리, 컴플라이언스, 런타임 보안, 애플리케이션 보안 도구의 결과를 취합합니다.경영진 보고에는 어떻게 활용할 수 있나요? 사업 단위별 비즈니스 가치와 트루리스크 점수를 리스크 허용 수준과 함께 보여주는 방식으로 활용할 수 있습니다. 사이버 리스크를 재무적 손실 가능성과 연결해 설명할 수 있습니다.☑️ 실제 위험 중심의 AI 시대 취약점 대응Qualys는 프런티어 AI의 등장으로 취약점은 늘고 악용까지 걸리는 시간은 수시간으로 짧아졌다고 보고, 이에 대한 해법으로 리스크 운영 센터를 제시합니다. 흩어진 발견 항목을 한곳에 모으고, 위협과 비즈니스 맥락, 보완 통제로 실제 위험을 가려내고, 패치 여부와 관계없이 위험을 제거한 뒤, 결과를 사업 단위별 리스크로 보고하는 방식입니다. 여기에 에이전트형 AI를 더해 탐지부터 조치까지의 과정을 자동화하는 방향을 제시하고 있습니다. 클라우드네트웍스는 Qualys 공식 파트너로서 기업 환경에 맞는 Qualys 솔루션 도입을 지원하고 있습니다. 취약점 우선순위화와 조치 자동화를 검토하고 있다면 클라우드네트웍스로 문의해 주시기 바랍니다.▶ 퀄리스(Qualys) 자세히보기

AI 도입과 활용이 본격화되면서 기업의 IT 인프라 투자도 빠르게 확대되고 있습니다. 새로운 AI 인프라에 대한 투자가 늘어날수록 기존 IT 인프라의 비용 구조를 함께 점검하는 것도 중요해지고 있습니다. 특히 운영체제(OS)와 가상화 환경은 서버 인프라의 기반이면서 라이선스와 기술지원 비용이 지속적으로 발생하는 영역입니다. 그렇다면 기존 인프라의 안정적인 운영을 유지하면서 OS와 가상화 비용을 효율화할 수 있는 방법은 무엇일까요?클라우드네트웍스와 오라클은 오는 10월 22일(목) 오후 2시, 데이터넷TV를 통해 ‘AI 시대의 인프라 경제학’ 웨비나를 진행합니다. 이번 웨비나에서는 Oracle Linux와 Oracle Linux Virtualization Manager(OLVM)를 중심으로 기업의 OS·가상화 비용을 절감하고 전체 IT TCO를 최적화할 수 있는 방안을 살펴봅니다.☑️ Oracle Linux와 OLVM, 왜 지금 살펴봐야 할까요?Oracle Linux는 엔터프라이즈 환경을 위한 Linux 운영체제로, 가상화와 자동화, 관리, 고가용성 및 클라우드 네이티브 환경을 함께 지원합니다.OLVM(Oracle Linux Virtualization Manager)은 KVM 기반의 서버 가상화 환경을 구성하고 모니터링·관리할 수 있는 플랫폼으로, 기존 가상화 인프라의 비용과 운영 구조를 재검토하고 있는 기업에서 대안으로 검토할 수 있습니다.이번 웨비나에서는 단순한 제품 소개보다 AI 시대의 IT 인프라 비용 최적화라는 관점에서 다음 내용을 중심으로 살펴볼 예정입니다.· OS·가상화 영역의 비용 효율화 방안· 기존 가상화 환경의 대안을 검토할 때 고려해야 할 사항· Oracle Linux·OLVM 기반 인프라 구성 방안· 전체 IT TCO 관점에서의 도입 전략☑️ AI 시대의 인프라 경제학 웨비나 안내일시 2026년 10월 22일(목) 14:00~15:00주제 AI 시대의 인프라 경제학 - Oracle Linux·OLVM으로 OS·가상화 비용과 IT TCO 최적화하기AI 도입과 활용이 본격화되면서 기업의 IT 투자는 빠르게 확대되고 있습니다. 새로운 AI 인프라에 재원을 투입하려면 기존 IT 인프라의 비용 구조를 함께 들여다봐야 합니다. OS와 가상화는 서버 인프라 운영의 기반이자, 라이선스와 지원 계약에 따라 매년 고정적으로 비용이 발생하는 영역입니다. Oracle Linux와 Oracle Linux Virtualization Manager(OLVM)는 오픈소스 기반의 Linux와 KVM 가상화로 서버 인프라를 구축하고 운영할 수 있도록 지원하며, 기존 상용 OS·가상화 환경을 대체하거나 병행하는 선택지가 됩니다.이번 웨비나에서는 AI 시대의 IT 인프라 비용 최적화라는 관점에서 Oracle Linux와 OLVM을 살펴봅니다. OS와 가상화 영역에서 비용을 효율화할 수 있는 방법과 기존 가상화 환경의 대안을 검토할 때 고려할 사항, 전체 IT TCO 관점의 도입 전략을 소개합니다.발표자  임상현 과장 | 클라우드네트웍스 Oracle 영업대표이창원 상무 | Oracle Sales Director참가비무료웨비나 참여 이벤트웨비나에 참여해 주시는 분들을 위한 이벤트도 마련되어 있습니다.AI 인프라 투자 확대에 따라 기존 서버 인프라의 OS·가상화 비용을 점검하고 있거나, 기존 가상화 환경의 대안을 검토하고 있다면 이번 웨비나에서 Oracle Linux와 OLVM의 활용 방안을 확인해 보시기 바랍니다. 10월 22일, 온라인에서 만나보세요.▶ 웨비나 자세히 보기 및 사전 등록※ 사전등록 후 등록한 이메일을 통해 참여 링크가 전달되며, 웨비나 당일 해당 링크를 통해 접속할 수 있습니다.

디지서트(DigiCert)가 2026년 9월 발표한 인증서 관리 전망 조사(Certificate Management Outlook)에서 응답 기업의 34%는 최근 1년 사이 인증서 만료로 서비스 중단을 겪었다고 답했습니다. 가장 심각했던 인증서 사고의 비용이 25만 달러를 초과했다는 응답은 23%로, 1년 전 18.5%보다 높아졌습니다. 부담은 앞으로 더 커질 수 있습니다. 응답 기업의 72%는 향후 2년간 관리할 인증서 수가 늘어날 것으로 예상했고, 2029년부터는 공개 TLS 인증서의 유효기간이 47일로 제한됩니다. 인증서 수가 늘고 수명이 짧아지면 인증서 발급과 도메인 검증 작업도 더 잦아집니다.이 글에서는 조사에 나타난 인증서 장애 비용과 다운타임 현황을 정리하고, 포레스터 컨설팅(Forrester Consulting)의 총경제효과(Total Economic Impact, TEI) 분석을 바탕으로 인증서 관리 솔루션 도입에 드는 비용과 그 효과를 살펴봅니다.☑️ 인증서 장애가 인프라 리스크로 분류되는 이유인증서 장애는 만료되거나 제대로 관리되지 않은 인증서 때문에 서비스가 중단되는 문제입니다. DigiCert 2026 조사에서 응답 기업의 57%는 인증서로 인한 서비스 중단을 IT 인프라 문제로 분류했고, 보안 사고로 분류한 기업은 17%였습니다. 장애가 발생하면 핵심 서비스와 생산성, 매출, 고객 경험, 평판까지 영향을 받을 수 있습니다.인증서는 애플리케이션과 서비스, 기술 환경 전반에 깊이 연결되어 있습니다. 그래서 인증서 장애의 영향은 공개 키 기반 구조(PKI)나 보안팀의 범위에 머물지 않고 기업 운영 전반으로 이어집니다.☑️ 2026 인증서 관리 전망 조사로 본 장애 비용과 자동화 현황이번 조사는 프로펠러 인사이트(Propeller Insights)가 DigiCert 의뢰로 2026년 5월에 수행한 독립 온라인 조사입니다. 미국 500명, 영국 251명, 호주 250명으로 모두 1,001명의 IT 및 사이버보안 의사결정자가 응답했으며, 응답자는 다양한 산업과 기업 규모에 걸쳐 있습니다.인증서 사고 비용가장 심각했던 인증서 사고의 비용이 25만 달러를 초과했다고 답한 기업은 23%입니다. 1년 전 18.5%에서 4.5%포인트 높아졌습니다. 반면 인증서 만료로 인한 서비스 중단 비율은 1년 전과 비교적 비슷한 수준이었습니다. 장애 빈도는 크게 달라지지 않았지만, 장애가 났을 때 치르는 비용은 커지고 있다는 의미입니다.서비스 중단 시간최근 1년 동안 응답 기업의 34%가 인증서 만료로 인한 서비스 중단을 겪었습니다. 인증서 관리 부실로 서비스 다운타임을 겪었다는 응답은 40%였습니다. 최근 1년간 인증서 문제로 인한 다운타임이 5시간 이상이었던 기업은 약 4분의 3이었고, 21%는 25시간 이상이었습니다. 만료는 여전히 흔한 장애 원인이며, 인증서 추적과 갱신을 수작업에 의존하면 이 위험에 그대로 노출됩니다. 응답 기업의 56%는 인증서 만료를 매우 또는 극도로 우려한다고 답했습니다.우선순위와 실제 도입 사이의 차이이런 상황에서 자동화된 인증서 라이프사이클 관리를 우선순위로 꼽은 기업은 46%로, 사이버보안 우선순위 가운데 3위였습니다. AI 기반 보안 운영(65%)과 소프트웨어 위협 탐지·대응(61%) 다음이며, 컴플라이언스 간소화, 사물인터넷(IoT) 보안 표준화, 제로 트러스트 확대보다 앞선 순위입니다. 다만 실제 도입은 우선순위만큼 진행되지 않았습니다. 자동화 도입의 장애요인을 묻는 질문에서 "이미 자동화를 갖추고 있다"고 답한 비율은 10%에 그쳤습니다. 자동화의 가장 큰 장애요인은 레거시 시스템과의 호환 문제(25%)였고, 예산 제약(21%)이 두 번째였습니다. 기술 인력 부족을 꼽은 비율은 14%였습니다.인증서 관리 예산과 투자 근거기업은 이미 인증서 관리에 적지 않은 예산을 쓰고 있습니다. 응답 기업의 53%는 보안 예산의 10% 이상을 인증서 관리와 관련 솔루션에 배정하고 있습니다. 한편 29%는 경영진의 동의를 얻지 못하거나 투자수익률(ROI)과 투자 근거가 불명확한 점을 자동화의 걸림돌로 꼽았습니다. 이미 예산이 투입되고 있는 만큼, 자동화를 확대하려면 장애 감소와 수작업 절감, 운영 복원력 강화처럼 인증서 관리 투자가 가져오는 효과를 보여줄 근거가 필요합니다.☑️ 인증서 수명 단축에 따른 발급·검증 업무량 증가인증서 관리는 이미 반복적인 업무입니다. 조사 대상 기업의 56%가 1,000개가 넘는 인증서를 관리하고 있고, 49%는 인증서 관리와 관련 보안 작업을 연 12회 이상 수행합니다. 발급, 갱신, 배포, 조치에 사람이 개입해야 하는 구조라면 이 규모는 IT 인력에 대한 지속적인 수요로 이어집니다. 관리 대상도 늘어날 전망입니다. 응답 기업의 72%가 향후 2년간 인증서 수가 늘어날 것으로 예상했습니다. 여기에 인증서 수명 단축이 더해집니다. CA/Browser Forum이 도입한 단계적 단축 규정에 따라 2029년부터 공개 TLS 인증서의 유효기간은 47일, 도메인 검증 정보의 재사용 기간은 10일로 제한됩니다. 인증서와 검증 정보를 더 자주 갱신하도록 해, 오래되었거나 유출됐을 수 있는 인증 정보가 유효한 상태로 남는 기간을 줄이려는 조치입니다.이 규정이 적용되면 공개 TLS 인증서 1,000개를 관리하는 기업은 연간 약 8,000회의 인증서 발급과 40,000회의 도메인 검증을 처리해야 할 수 있습니다. 인증서 수가 늘고 수명이 짧아질수록 이 작업 부담은 더 커집니다. 응답 기업의 70%는 짧아지는 인증서 수명에 적극적으로 대비하고 있지만, 22%는 변화를 알고 있으면서도 아직 준비를 시작하지 않았습니다.☑️ 수작업과 분산 도구 기반 인증서 관리의 과제조사에서 기업이 인증서 관리와 관련해 매우 또는 극도로 우려한다고 답한 항목은 고객 신뢰 유지가 58%로 가장 많았습니다. 인증서 만료일 추적(56%), 산업 규제 준수(55%), 여러 클라우드와 플랫폼에 걸친 인증서 관리(55%), 내부와 외부 시스템의 동시 관리(52%)가 뒤를 이었습니다. 기업은 만료 문제와 함께 컴플라이언스, 고객 신뢰, 여러 환경에 흩어진 인증서 관리에도 대응하고 있습니다.수작업과 분산 도구에 의존하는 인증서 관리에는 네 가지 과제가 있습니다.첫째, 레거시 시스템은 짧아지는 인증서 수명과 높아지는 보안 요구, 바뀌는 컴플라이언스 요건을 따라가기 어렵습니다. 둘째, 수동 갱신은 IT 인력의 시간을 소모하고 인증서 만료 위험을 높입니다. 셋째, 도구와 조직이 분리되어 있으면 정책이 일관되지 않고 가시성이 떨어지며 같은 작업을 중복하게 됩니다. 넷째, 인증서가 무분별하게 늘어나면 표준을 적용하거나 향후 증가에 대비한 계획을 세우기 어렵습니다.인증서가 클라우드, 디바이스, CI/CD 파이프라인으로 퍼지면 기존 방식으로는 관리가 따라가기 어렵습니다. 그 결과 드러나지 않은 리스크, 만료 직전의 급한 갱신, 감사 대응 부담, 비용 증가가 함께 나타납니다.☑️ Forrester TEI로 본 DigiCert ONE 도입 효과디지서트 원(DigiCert ONE)은 인증서 라이프사이클 관리와 공개·사설 인증서 서비스를 결합한 DigiCert의 PKI·DNS 플랫폼입니다. 앞서 살펴본 분산 도구와 수작업 중심의 인증서 관리를 이 플랫폼으로 중앙화했을 때 비용과 효과가 어떻게 달라지는지를 분석한 자료가 Forrester의 DigiCert ONE TEI 분석입니다. 앞서 조사에서 자동화의 걸림돌로 꼽힌 투자 근거를 수치로 확인할 수 있는 자료이기도 합니다.조사 방법과 전제이 분석은 DigiCert가 의뢰해 Forrester Consulting이 작성했고, 2025년 7월에 발행됐습니다. Forrester는 DigiCert ONE을 사용하는 기업 5곳의 의사결정자 5명을 인터뷰하고, 그 결과를 하나의 가상 종합 기업으로 묶어 3년간의 편익과 비용을 위험 조정 기준으로 산출했습니다. 할인율은 연 10%를 적용했습니다. 종합 기업은 인증서 20만 개를 관리하는 대기업으로 설정됐습니다. 인증서 관리 중앙 팀이 있지만 상당수 인증서를 다른 부서가 표준 정책 없이 관리하고 있어 중앙 팀이 이를 파악하지 못합니다. 여러 벤더 도구와 자체 개발 도구를 함께 쓰고, 인증서의 20%는 수작업으로 관리하며, 인증서 사용량은 제품과 IoT 기기, 소프트웨어 수요로 매년 20%씩 늘어납니다.따라서 아래 수치는 특정 고객사의 실제 성과가 아니라 인터뷰를 종합한 모델 기업 기준입니다. 이 분석은 다른 조직이 같은 ROI를 얻는다고 가정하지 않으며, 자사 추정치를 분석 틀에 적용해 투자 적정성을 판단하도록 권고합니다. Forrester는 DigiCert와 그 제품을 보증하지 않습니다.편익 항목별 효과3년 위험 조정 기준 편익은 모두 1,330만 달러이며, 여섯 개 항목으로 구성됩니다. 가장 큰 항목은 DigiCert ONE 도입 시점에 이미 운영 중이던 인증서의 갱신 인건비 절감으로 790만 달러입니다. 종합 기업은 기존 인증서의 80%를 레거시 도구로, 나머지 20%를 수작업으로 갱신해 왔고, 이 갱신 작업이 DigiCert ONE으로 옮겨가면서 줄어드는 인건비를 산출한 값입니다.인증서 관련 사고 비용 감소는 280만 달러입니다. 도입 전 연 24건에서 28건이던 인증서 관련 사고가 도입 후 연 1건으로 줄고, 사고당 비용이 평균 5만 달러 줄어든다는 전제로 산출됐습니다. 파트너나 고객사의 엄격한 보안 기준을 충족하면서 발생한 매출 증가 효과는 130만 달러입니다. 보안 기준 충족에 따른 매출 증가분 가운데 50%를 DigiCert ONE의 기여로 보고, 순이익률 10%를 적용한 값입니다. 레거시 도구 폐기에 따른 절감은 99만 2,500달러입니다. 벤더 도구와 자체 개발 도구를 정리하면서 라이선스, 호스팅, 유지보수 비용이 줄어든 효과입니다.나머지 두 항목은 신규 인증서 발급·갱신과 관련된 인건비 절감입니다. 수작업 발급·갱신을 없앤 효과가 39만 5,900달러, 레거시 도구 사용을 없앤 효과가 3만 500달러입니다.정량화하지 않은 편익도 있습니다. DigiCert ONE의 단일 클라우드 기반 플랫폼은 조직 전체의 인증서 가시성을 제공하고 정책과 절차를 표준화해, 종합 기업의 시간과 인건비 절감, 보안 강화, 사고 감소, 변화 대응력 향상으로 이어졌습니다.발급·갱신 시간 변화종합 기업 기준으로 인증서 한 개당 작업 시간은 다음과 같이 줄어드는 것으로 산정됐습니다. 신규 발급은 수작업 120분에서 3분으로 97.5%, 레거시 도구 5분에서 3분으로 40% 줄었습니다. 갱신은 수작업 40분에서 0.5분으로 98.75%, 레거시 도구 2분에서 0.5분으로 75% 줄었습니다. 도입 후 수작업으로 관리하는 인증서 비중은 0%가 됩니다.투자 비용과 3년 재무 지표3년간 비용은 위험 조정 기준 320만 달러입니다. DigiCert ONE 라이선스와 프리미엄 지원, 구축 비용이 210만 달러, 기존 인증서를 DigiCert ONE으로 옮기는 데 필요한 탐색·목록화·검토·발급 작업 비용이 110만 달러, 도입 시 인증서 정책과 템플릿을 설정하는 인건비가 4만 9,500달러입니다. 편익 1,330만 달러에서 비용 320만 달러를 뺀 순현재가치는 1,010만 달러이고, 순편익을 비용으로 나눈 ROI는 312%입니다. 투자 회수 기간은 6개월 미만입니다.☑️ DigiCert ONE과 TLM 기반 인증서 관리 활용 포인트DigiCert ONE 플랫폼 제품군 가운데 트러스트 라이프사이클 매니저(Trust Lifecycle Manager, TLM)는 공개 인증서와 사설 인증서를 대규모로 관리하기 위한 가시성, 거버넌스, 자동화를 제공해, 인증서 관리 문제로 생기는 장애를 예방하고 짧아지는 인증서 수명에 대응하도록 돕는 제품입니다. 앞서 살펴본 조사 결과와 TEI 분석을 바탕으로 인증서 관리에서 활용할 수 있는 지점을 네 가지로 정리합니다.전체 인증서 현황과 소유자 파악TLM은 인증서 가시성을 제공합니다. DigiCert ONE을 도입한 TEI 인터뷰 기업들은 도입 전 중앙에서 인증서를 파악하고 통제할 수 없어 관리 방식이 제각각이었고, 소유자가 불분명했으며, 모니터링에도 공백이 있었습니다. 도입 후에는 조직 전체의 인증서 가시성을 확보하고 인증서 소유자와 책임을 명확히 파악할 수 있게 됐습니다.발급·갱신 자동화TLM은 인증서 자동화를 제공합니다. 앞서 살펴본 것처럼 47일 인증서 규정이 적용되면 발급과 도메인 검증 횟수가 크게 늘어납니다. 이 작업을 수작업에 의존하면 IT 인력의 시간이 소모되고 만료 위험이 높아집니다. TEI 종합 기업은 DigiCert ONE 도입 후 수작업으로 관리하는 인증서를 없앴고, 인증서 관련 사고는 연 24건에서 28건 수준에서 연 1건으로 줄었습니다. 사고 감소의 이유로는 모니터링과 알림, 자동 갱신 기능이 꼽혔습니다.정책 표준화와 감사 대응TLM은 인증서 거버넌스를 제공합니다. 조사 응답 기업의 44%는 최근 1년간 인증서 관리와 관련된 컴플라이언스 문제를 겪었습니다. 도구와 조직이 분리된 환경에서는 정책이 일관되지 않고 감사 대응 부담이 커집니다.DigiCert ONE을 도입한 TEI 인터뷰 기업들은 도입 전 분산된 시스템 때문에 환경을 검증하고 규정 준수를 입증하기 어려워 감사에 많은 비용과 시간을 들였습니다. 도입 후에는 중앙화된 가시성, 표준화된 정책, 기본 제공 리포트가 감사 업무량과 후속 작업 부담을 줄였고, 기한에 임박해 급하게 대응하던 방식에서 예측 가능하고 문서화된 컴플라이언스 절차로 전환했습니다.분산 도구와 레거시 시스템 정리DigiCert ONE 도입 기업들은 여러 도구와 수작업을 조합하던 방식을 하나의 중앙 플랫폼으로 대체하고, 오래된 시스템을 정리했습니다. 분산된 도구는 정책 불일치와 중복 작업의 원인이 됩니다. TEI 종합 기업은 벤더 도구와 자체 개발 도구를 정리해 라이선스, 호스팅, 유지보수 비용을 줄였고, 이 효과는 3년간 99만 2,500달러로 산출됐습니다.☑️ 자주 묻는 질문인증서 장애 비용은 어느 정도인가요?DigiCert 2026 인증서 관리 전망 조사에서 응답 기업의 23%는 가장 심각했던 인증서 사고의 비용이 25만 달러를 초과했다고 답했습니다. 1년 전 18.5%에서 4.5%포인트 높아진 수치입니다. 다운타임 기준으로는 21%가 최근 1년간 25시간 이상의 인증서 관련 장애를 겪었습니다.인증서 자동화 도입이 늦어지는 이유는 무엇인가요?가장 큰 장애요인은 레거시 시스템과의 호환 문제(25%)이고, 두 번째는 예산 제약(21%)입니다. 자동화된 인증서 라이프사이클 관리는 사이버보안 우선순위 3위에 올랐지만, 장애요인 질문에서 이미 자동화를 갖췄다고 답한 비율은 10%였습니다.47일 인증서가 적용되면 관리 업무량은 얼마나 늘어나나요?공개 TLS 인증서 1,000개를 관리하는 기업이라면 연간 약 8,000회의 인증서 발급과 40,000회의 도메인 검증을 처리해야 할 수 있습니다. 이는 2029년부터 공개 TLS 인증서 유효기간 47일, 도메인 검증 정보 재사용 기간 10일이 적용되는 것을 전제로 한 추산입니다.Forrester TEI 수치는 어떤 기준으로 산출됐나요?인증서 20만 개를 관리하는 가상의 종합 기업을 기준으로 3년간의 편익과 비용을 위험 조정해 산출한 값입니다. DigiCert가 의뢰하고 Forrester Consulting이 DigiCert ONE 사용 기업 5곳의 인터뷰를 바탕으로 작성했습니다. 편익 1,330만 달러, 비용 320만 달러로 ROI 312%, 순현재가치 1,010만 달러, 투자 회수 기간 6개월 미만이 산출됐으며, Forrester는 다른 조직이 같은 ROI를 얻는다고 가정하지 않습니다.DigiCert TLM은 어떤 인증서를 관리하나요?TLM은 공개 인증서와 사설 인증서를 모두 대상으로, 대규모 인증서 관리에 필요한 가시성, 거버넌스, 자동화를 제공합니다. DigiCert ONE 플랫폼 제품군에 속한 인증서 라이프사이클 관리 제품입니다.☑️ 마무리인증서 장애는 비용과 다운타임 양쪽에서 부담이 커지고 있는 인프라 리스크입니다. DigiCert 2026 조사에서 25만 달러를 초과하는 사고를 겪은 기업 비율은 1년 사이 4.5%포인트 높아졌고, 인증서 라이프사이클 자동화는 사이버보안 우선순위 3위에 올랐지만 실제 도입은 그만큼 진행되지 않았습니다. 인증서 수가 늘고 2029년 47일 인증서 규정이 적용되면 발급과 검증 작업은 더 잦아집니다. Forrester TEI 분석에서는 인증서 20만 개를 관리하는 종합 기업이 3년간 320만 달러를 투자해 1,330만 달러의 편익을 얻는 것으로 산출됐습니다.두 리포트의 전체 내용은 아래 링크에서 확인할 수 있습니다.▶ DigiCert Certificate Management Outlook 리포트 받기 ▶ Forrester TEI 리포트 받기 클라우드네트웍스는 고객 환경의 인증서 현황과 관리 방식을 확인하고, DigiCert TLM 기준으로 가시성 확보와 자동화 적용 범위를 검토하는 과정부터 구축까지 지원합니다. 인증서 장애 대응이나 47일 인증서 전환을 앞두고 인증서 관리 솔루션 도입을 검토하고 계시다면 아래 링크를 통해 문의해 주시기 바랍니다.▶ 디지서트(DigiCert) TLM 자세히보기 [출처 : DigiCert, "DigiCert Research Finds Certificate Failures Are a Six-Figure Infrastructure Risk", https://www.digicert.com/news/digicert-research-finds-certificate-failures-are-a-six-figure-infrastructure-risk, DigiCert, "Certificate Management at 47-day Speed: Key findings from DigiCert's Certificate Management Outlook", https://www.digicert.com/campaigns/certificate-management-outlook-report, Forrester Consulting, "The Total Economic Impact™ Of DigiCert ONE", https://www.digicert.com/campaigns/total-economic-impact-of-digicert-one-report]

기업의 AI 사용은 한두 가지 형태로 정리되지 않습니다. 클라우드 AI 서비스와 GPU, 컨테이너에서 실행되는 모델, 코드 저장소와 개발 파이프라인에 들어간 AI 코드, SaaS에 내장된 생성형 AI 기능, 브라우저에서 사용하는 AI 도구, 그리고 AI 에이전트와 MCP 서버가 함께 늘어나고 있습니다. 보안 책임자와 규제 담당자가 마주하는 질문은 네 가지입니다. AI는 어디에서 실행되고 있는가, 데이터 유출로부터 안전한가, AI 에이전트는 무엇에 접근할 수 있는가, 통제가 작동하고 있다는 사실을 증명할 수 있는가입니다.Qualys TotalAI는 이 네 가지 질문에 답하기 위한 솔루션입니다. 이 글에서는 TotalAI가 AI 리스크를 어떤 순서로 처리하는지, 어떤 기능을 제공하는지, 기존 리스크 관리 체계와 어떻게 연결되는지를 정리합니다.☑️ Qualys TotalAI가 다루는 영역Qualys TotalAI는 AI 자산의 발견, 평가, 조치, 거버넌스를 하나의 솔루션으로 통합한 AI 거버넌스 및 리스크 관리 솔루션입니다. Qualys Enterprise TruRisk Platform 위에서 동작하며, 코드 단계부터 런타임까지 이어지는 AI 리스크 텔레메트리를 통제가 작동하고 있다는 증거로 전환합니다.빠른 AI 도입 과정에서 생긴 거버넌스 공백을 다루는 것이 이 솔루션의 목적입니다. 기업 전반의 신뢰할 수 있는 AI 인벤토리를 구축하고, 포스처와 행위를 평가하고, 조치 우선순위를 정하고, 감사에 사용할 수 있는 증거를 산출하는 과정이 하나로 연결됩니다. 이 증거는 일회성 점검 결과가 아니라 반복 가능한 형태의 AI 거버넌스로 축적됩니다.☑️ Qualys TotalAI가 AI 리스크를 처리하는 네 단계TotalAI는 발견, 평가, 조치, 보고의 네 단계로 AI 리스크를 다룹니다.발견 : 기업 전반의 섀도우 AI 제거승인된 AI와 섀도우 AI(Shadow AI)를 함께 발견합니다. 대상 범위는 클라우드 서비스, SaaS, GPU, AI 에이전트, 모델, MCP 서버, 호스트, 컨테이너, AI 코드, 개발 파이프라인, 브라우저 기반 AI입니다. 발견에서 그치지 않고 모델과 프레임워크, 워크로드를 핑거프린팅한 뒤 각 자산을 소유자, 운영 맥락, 노출 상태, 핵심 시스템에 대한 접근 권한에 매핑합니다. 그 결과 무엇이 실행 중이고, 어디에서 실행되며, 누가 소유하고 있고, 승인된 자산인지가 정리된 인벤토리 기준선을 확보하게 됩니다.평가 : 포스처 점검과 적대적 테스트AI-SPM과 적대적 테스트를 함께 사용해 AI 스택 전반을 점검합니다. LLM과 MCP 서버를 대상으로 프롬프트 인젝션, 탈옥, 툴 포이즈닝, 통제 실패 여부를 테스트하고, 여기에 eBPF 런타임 활동 관찰과 배포 이전 단계의 시프트 레프트 스캔이 더해져 파이프라인 코드 단계의 리스크를 배포 전에 확인합니다. 취약점 관리와 포스처 관리를 AI 자산까지 확장하고 AI 전용 테스트와 실시간 모니터링을 결합해 360도 리스크 관점을 제공하며, 각 발견 항목에는 포렌식 증거와 심각도 등급이 함께 붙습니다.조치 : 먼저 처리할 항목의 선별TruRisk 기반으로 우선순위가 정해진 조치와 가드레일 권고를 제공합니다. 실제로 악용 가능한 항목을 먼저 처리하되, 왜 그 항목이 우선인지에 대한 근거가 함께 제시됩니다. 점수 산정에는 취약점 심각도, 데이터 민감도, 자산 중요도, 비즈니스 맥락, 모델 행위, 런타임 증거가 함께 반영되며, 모델 노출과 아이덴티티 권한, 데이터 민감도를 상호 연관 분석해 유해 조합을 드러냅니다. 정리된 항목은 설정 오류든 노출된 시크릿이든 취약한 접근 정책이든 실패한 모델 테스트든 클라우드, DevOps, AppSec, 아이덴티티 및 GRC 담당 조직으로 라우팅됩니다. 영향도가 큰 AI 리스크에 대해서는 조치 절차를 안내하는 가이드가 제공되며 SecOps와 MLOps 양쪽에서 사용할 수 있습니다. 조치가 적용되면 재테스트를 수행하고 결과를 기록해, 탐지에서 조치와 검증, 문서화까지 이어지는 순환이 닫히면서 리스크가 줄었다는 사실이 증거로 남습니다.보고 : 보안 통제의 컴플라이언스 리포트화보안 통제 결과를 자동화된 컴플라이언스 증거와 공급업체 리스크 증거로 전환합니다. 별도의 정리 작업 없이 NIST, EU AI Act, FISMA, OWASP LLM Top 10, MITRE ATLAS, CMMC 2.0 프레임워크 기준에 맞춰 정렬되며, 이 과정에서 보안 질의서 대응이 간소화되고 적용한 AI 가드레일이 작동하고 있다는 사실을 제시하는 감사 대응용 경영진 대시보드가 생성됩니다.☑️ AI 라이프사이클 단계별 주요 기능TotalAI는 AI 라이프사이클 전반에서 수집한 리스크 텔레메트리를 통제 유효성과 거버넌스의 증거로 전환합니다. 제공되는 기능은 다음 여섯 가지입니다.AI 보안 포스처 관리(AI-SPM)취약점, 설정 오류, 과도한 접근 권한을 포함한 AI 포스처 전반을 확인합니다. 모델, 에이전트, 클라우드 서비스, 통제 항목 사이의 리스크를 상호 연관 분석해 비즈니스 영향이 큰 노출과 유해 조합을 우선순위가 정해진 형태로 제시합니다. 확인 결과는 통제 단위로 정리됩니다. 실패한 보안 및 거버넌스 통제, 클라우드 설정 오류, 취약한 AI 인프라, 과도한 접근 권한, 노출된 모델 또는 MCP 엔드포인트, 누락된 보호 장치를 항목별로 확인할 수 있습니다. 권한과 민감 데이터, 노출 상태, 취약한 통제가 겹치는 유해 조합도 함께 드러납니다.임직원 생성형 AI와 AI SaaS 사용 관리임직원 브라우저와 내장형 SaaS 애플리케이션에서 발생하는 섀도우 AI와 데이터 유출 리스크를 확인합니다. 프롬프트 활동을 모니터링하고, 민감 데이터의 이동을 추적하며, SaaS 설정 상태를 평가해 거버넌스 공백을 제거합니다. 위험 소지가 있는 브라우저 기반 AI 활동을 식별하고, 기업이 사용하는 AI SaaS 서비스를 평가합니다.LLM 레드팀 테스트프롬프트 인젝션, 탈옥, 민감 정보 노출, 환각, 안전하지 않은 출력, 다국어 및 인코딩 공격, 서비스 거부, 멀티모달 조작에 대해 LLM을 직접 테스트합니다. 스캔 리포트는 OWASP, MITRE ATLAS, EU AI Act에 매핑되어 제공되며, 모델이 운영 환경에 반영되기 전에 적용할 수 있는 가드레일 권고가 함께 제시됩니다. 공격자가 시도하기 전에 같은 방식의 테스트를 먼저 수행하는 것이 이 기능의 목적입니다. 결과는 판정만 남지 않습니다. 사용된 프롬프트와 모델 응답, 심각도, 통과와 실패 판정, 성공한 탈옥 사례, 그리고 통제가 실패한 기술적 근거를 함께 확인할 수 있습니다.MCP와 에이전틱 AI(Agentic AI) 보안MCP 서버를 발견하고 스캔해 AI 에이전트와 기업 시스템 사이의 연결을 점검합니다. 툴 포이즈닝, 인자 인젝션, SSRF, DNS 리바인딩, 러그풀 공격, 안전하지 않은 파일 접근, 스푸핑, 명령 실행, 자격 증명 노출을 탐지해 에이전트가 안전하지 않은 동작을 수행하지 않도록 가시성을 제공합니다. 어떤 MCP 서버가 존재하고 무엇을 노출하고 있는지, 그중 어떤 항목이 에이전트의 위험한 행동으로 이어질 수 있는지를 구분해 확인할 수 있습니다.에이전틱 애플리케이션 거버넌스코드와 인가 정책부터 워크로드와 런타임까지, 에이전틱 AI의 전체 라이프사이클을 관리 대상으로 삼습니다. AI 코드를 스캔하고 Cedar 정책을 검증하며, 호스트와 컨테이너에 걸쳐 에이전틱 워크로드와 에이전트를 추적합니다. eBPF 커널 가시성과 MCP 모니터링을 결합해 에이전트의 행위를 추적하고 권한을 검증합니다. 코드, 컨테이너, 정책이 운영 환경에 반영되기 전 단계에서 AI 리스크를 확인하는 시프트 레프트 적용도 같은 흐름 안에 포함됩니다.승인 이후 모니터링AI 리스크는 배포 시점에 끝나지 않습니다. 호스트와 컨테이너, MCP 서버, 브라우저 기반 AI 사용에 걸쳐 모델의 활동과 런타임 활동을 지속적으로 모니터링하고, 포스처 드리프트와 의심스러운 활동, 데이터 유출 징후를 탐지합니다. 테스트 단계부터 운영 단계까지 AI가 승인된 범위 안에서 동작하고 있다는 사실을 실시간 증거로 산출합니다.컴플라이언스와 감사 대응TotalAI는 산출된 증거를 세 가지 용도로 활용할 수 있도록 구성되어 있습니다. 규제 대응 측면에서는 감사에 제출할 수 있는 형태의 AI 증거를 NIST AI RMF, EU AI Act, OWASP Top 10 for LLM, MITRE ATLAS에 맞춰 정렬합니다. 내부 감사 측면에서는 이사회에 보고할 수 있는 수준의 리포트와 AI 리스크 및 통제에 대한 추적 가능한 GRC 감사 기록을 제공합니다. 고객 대응 측면에서는 보안 질의서 작성 부담을 줄이고, 공급업체의 AI 리스크를 기술적 증거를 근거로 평가할 수 있게 합니다. 이렇게 산출된 증거는 고객 보안 질의서, 공급업체 평가, 이사회 보고, 규제 검토에 사용됩니다. 리포트는 감사와 경영진이 확인하는 질문에 그대로 대응합니다. 어떤 AI 시스템을 보유하고 있는지, 그중 무엇이 규정을 준수하는지, 어떤 문제가 아직 해결되지 않았는지입니다.☑️ AI 리스크를 다른 엔터프라이즈 리스크와 함께 관리TotalAI는 Qualys Enterprise TruRisk Platform 위에서 동작합니다. 따라서 AI 리스크를 취약점, 클라우드, 컨테이너, 애플리케이션, 인프라 리스크와 함께 평가할 수 있습니다.배포는 이미 운영 중인 Cloud Agent로 이루어집니다. 신규 에이전트나 코드 변경, 추가 인프라가 필요하지 않으며 발견된 항목은 기존에 사용하던 워크플로로 그대로 전달됩니다.☑️ 자주 묻는 질문TotalAI는 LLM 스캐너나 프롬프트 방화벽과 어떻게 다른가요?스캐너와 방화벽은 프롬프트나 클라우드 서비스를 개별 단위로 확인합니다. TotalAI는 발견된 항목을 자산, 워크로드, 소유자, 통제, 비즈니스 리스크와 연결하며, 발견과 포스처, 적대적 테스트, MCP와 런타임, 코드 보안을 하나의 리스크 운영 모델 안에서 다룹니다.신규 에이전트를 배포해야 하나요?필요하지 않습니다. 기존 Qualys Cloud Agent와 커넥터, 스캐너를 그대로 사용하며 호스트, 클라우드, 네트워크, SaaS에 대한 발견이 곧바로 시작됩니다.외부로 반출할 수 없는 모델도 테스트할 수 있나요?가능합니다. 내부 온프레미스 스캐너가 방화벽 내부에서 동일한 테스트를 수행하므로 민감하거나 비공개로 운영되는 모델에도 적용할 수 있습니다.산출된 증거는 어떤 프레임워크에 매핑되나요?모든 탐지 항목이 OWASP Top 10 for LLM, MITRE ATLAS, EU AI Act 조항, NIST AI RMF 등에 매핑됩니다. 프롬프트와 응답, 분석 기록이 함께 남기 때문에 감사, 도입 심사, 모델 검토 절차의 근거 자료로 사용할 수 있습니다.☑️ 마무리AI 도입 범위가 넓어질수록 확인해야 할 것은 AI를 얼마나 쓰고 있는지가 아니라, 사용 중인 AI가 어떤 상태이고 그 통제가 작동하고 있는지입니다. Qualys TotalAI는 이 확인을 발견과 평가, 조치, 리포트라는 하나의 흐름으로 처리하고, 그 결과를 감사와 규제 대응에 사용할 수 있는 증거로 남깁니다. Enterprise TruRisk Platform 위에서 동작하므로 AI 리스크를 기존 취약점 및 클라우드 리스크와 같은 기준으로 관리할 수 있습니다.클라우드네트웍스는 Qualys 공식 파트너로서 고객사 환경에 맞는 적용 범위 검토와 도입, 도입 이후 운영을 지원하고 있습니다. TotalAI 검토를 계획하고 계시다면 아래 링크를 통해 문의해 주시기 바랍니다.▶ Qualys TotalAI 자세히보기 [출처 : Qualys, "Qualys TotalAI | AI Governance & Risk Management", https://www.qualys.com/apps/totalai, Qualys, "Qualys TotalAI Trial | AI Governance and Risk Management", https://www.qualys.com/free-trial-new/totalai, Qualys, "Operationalize AI Governance Across Shadow GenAI, MCP, and Agentic Workloads with Qualys TotalAI", [출처 : Qualys, "Qualys TotalAI | AI Governance & Risk Management", https://www.qualys.com/apps/totalai, Qualys, "Qualys TotalAI Trial | AI Governance and Risk Management", https://www.qualys.com/free-trial-new/totalai, Qualys, "Operationalize AI Governance Across Shadow GenAI, MCP, and Agentic Workloads with Qualys TotalAI", https://blog.qualys.com/product-tech/2026/07/29/ai-governance-evidence-gap-totalai]

기업의 AI 트래픽은 LLM 호출 한 가지로 구성되지 않습니다. 여러 프로바이더의 모델을 함께 쓰고, MCP(Model Context Protocol) 서버를 통해 사내 도구와 데이터를 연결하며, 에이전트가 다른 에이전트를 호출하는 흐름까지 더해집니다. 연결 대상이 늘어날수록 인증, 접근 통제, 비용 귀속, 로깅을 어디에서 처리할지가 운영의 과제로 남습니다.콩(Kong)은 2026년 7월 16일 AI Gateway 2.0을 비공개 베타로 공개했고, 9월 1일 정식 출시를 발표했습니다. 이번 릴리스로 AI 게이트웨이는 Kong API Gateway 안의 기능 집합이 아니라 자체 런타임과 컨트롤 플레인, 자체 관리 API를 갖는 별도 제품이 됐습니다. 이 글에서는 Kong AI Gateway가 어떤 제품이고, 2.0에서 설정 방식이 어떻게 바뀌었으며, 새로 추가된 기능이 무엇인지, 기존 환경에서 전환을 검토할 때 확인해야 할 조건은 무엇인지 정리합니다. ☑️ Kong AI Gateway 2.0은 무엇인가Kong AI Gateway는 애플리케이션과 LLM, MCP 서버, AI 에이전트 사이에 위치해 AI 트래픽의 라우팅, 인증, 접근 통제, 비용 관리, 관측을 하나의 계층에서 처리하는 AI 연결·거버넌스 제품입니다. AI Gateway 2.0은 이 제품이 Kong API Gateway의 플러그인 묶음에서 벗어나 전용 런타임과 전용 컨트롤 플레인, 자체 관리 API와 자체 버전 체계를 갖게 된 릴리스이며, 2026년 9월 1일 정식 출시되어 Kong Konnect에서 별도의 베타 활성화 없이 사용할 수 있습니다.기존과 달라진 지점은 관리 단위입니다. 모델과 MCP 서버, 에이전트를 설정 화면과 관리 API에서 각각 독립된 관리 대상으로 다룹니다. 서비스와 라우트를 만들고 플러그인을 붙여 AI 동작을 구성하는 방식이 아니라, 필요한 AI 리소스를 선언하면 컨트롤 플레인이 하위 구성을 대신 생성하는 방식입니다. ☑️ AI 게이트웨이가 별도 제품으로 분리된 이유Kong AI Gateway는 출시 이후 Kong API Gateway의 일부로 배포되어 왔습니다. LLM 라우팅, 프롬프트 가드, 시맨틱 캐싱, 토큰 기반 요청 제한 같은 기능이 모두 API 게이트웨이와 같은 릴리스 일정을 따랐습니다.분리의 배경은 두 워크로드의 변화 속도 차이입니다. 미션 크리티컬한 API 인프라는 안정성을 우선한 보수적인 릴리스 주기가 요구되는 반면, 새로운 모델 프로바이더가 계속 등장하고 MCP나 A2A 같은 프로토콜이 진행 중에 바뀌는 AI 환경은 주 단위로 움직입니다. 하나의 코드베이스로 두 주기를 모두 맞추기는 어렵다는 것이 분리의 이유입니다.그 결과 AI Gateway는 자체 런타임과 컨트롤 플레인, 자체 관리 API를 갖고 2.0부터 독립된 버전 체계로 이동했습니다. Kong Gateway는 검증된 안정성 중심의 주기를 그대로 유지하고, AI Gateway는 AI 생태계 속도에 맞춰 별도로 배포됩니다. 거버넌스 운영 모델은 하나로 유지하면서 릴리스 주기만 워크로드에 맞게 나눈 구조입니다. ☑️ 플러그인에서 AI 엔티티로 바뀐 설정 방식Kong AI Gateway 2.0에서 달라진 부분은 설정 방식입니다.Kong Gateway 위에서 동작하던 방식에서는 AI 기능이 세 개의 프록시 플러그인으로 제공됐습니다. AI Proxy Advanced가 모델 프록시와 변환, 프로바이더·모델 간 로드 밸런싱을 담당하고, AI MCP Proxy가 Kong이 관리하는 서비스를 MCP로 연결하거나 상위 MCP 서버 앞단에 위치했으며, AI A2A Proxy가 에이전트 간 프로토콜 트래픽에 대한 관측과 통제를 맡았습니다. 이 구조에서는 서비스와 라우트를 먼저 만들고 플러그인을 붙여야 했고, 논리적으로 모델 하나를 정의하는 데 서비스와 라우트, AI Proxy Advanced 플러그인, 여러 보조 플러그인이 함께 필요했습니다. AI 관련 설정이 여러 개체에 나뉘어 들어가는 구조였습니다.AI Gateway 2.0은 이 플러그인들을 전용 엔티티 모델로 추상화했습니다. 서비스나 라우트에 붙이던 AI Proxy Advanced는 AI Model 엔티티가 되어, 가상 모델 하나당 하나의 엔티티를 두고 그 안에 하나 이상의 타깃을 정의합니다. 플러그인 설정에 인라인으로 넣던 프로바이더 자격 증명은 AI Model Provider라는 재사용 가능한 엔티티로 분리되어, 프로바이더를 한 번 선언해 두고 여러 AI Model에서 이름으로 참조하게 됩니다. 기존의 route_type 설정은 capabilities 배열과 formats의 type으로 나뉩니다.AI MCP Proxy는 AI MCP Server 엔티티가 됩니다. 플러그인의 각 모드가 그대로 type 값으로 대응되며 upstream-server라는 새 유형이 추가됐고, 플러그인 설정에 있던 default_acl과 tools.acl은 AI MCP Server의 access 또는 tools.access 필드로 올라와 접근 제어 목록이 엔티티의 기본 설정 항목이 됩니다. AI A2A Proxy는 AI Agent 엔티티가 되며 URL 재작성과 A2A 분석이 기본 제공됩니다.플러그인 자체는 AI Policy로 대체됩니다. 각 정책에는 type 필드가 있고 이 값이 기존 플러그인에 대응하며 설정 내용은 동일합니다. 컨슈머와 컨슈머 그룹은 AI Consumer와 AI Consumer Group으로, Vault는 AI Vault와 AI Data Plane Certificates로 컨트롤 플레인에서 관리되고, 볼트 참조 문법은 기존과 같은 형식을 유지합니다.기존에 쓰던 기능은 그대로 이어집니다. 로드 밸런싱 알고리즘은 동일하게 제공되고, 시맨틱 캐싱의 Redis와 pgvector 전략도 같은 방식으로 유지됩니다. 달라진 것은 이를 선언하는 단위입니다. ☑️ Kong AI Gateway 2.0에 새로 추가된 5가지 기능AI 트래픽 전용 런타임과 컨트롤 플레인, Konnect 사용 환경에 더해 이번 정식 출시에는 다음 다섯 가지가 새로 포함됐습니다. 1. MCP 서버 번들링에이전트를 운영 환경에 올리면 에이전트마다, LLM 애플리케이션마다, MCP 클라이언트마다 늘어나는 MCP 서버를 각각 설정해야 하는 문제가 생깁니다. 서버마다 엔드포인트가 다르고 핸드셰이크가 다르며 접근 권한 체계도 제각각입니다. 팀 단위로 늘어나면 MCP 연결 자체가 플랫폼 팀의 상시 업무가 됩니다.MCP Server Bundling은 이 구성을 하나의 접점으로 모읍니다. 사용자나 LLM, 에이전트가 Kong 라우트 하나에 연결하면 MCP 도구 호출에 사용되는 JSON-RPC 전체가 그 경로를 지나고, Kong이 해당 라우트 뒤에서 MCP 핸드셰이크를 처리한 뒤 매핑된 상위 MCP 서버 전체에 tools/list를 실행한 결과를 하나의 통합 도구 카탈로그로 제시합니다.여기서 중요한 부분은 카탈로그에 무엇이 담기는가입니다. 번들링은 MCP ACL 플러그인과 연동되어 있어 게이트웨이는 각 호출자가 조회하고 실행할 권한이 있는 도구만 노출합니다. 같은 번들 라우트에 연결해도 호출자가 다르면 서로 다른 도구 목록을 받습니다. 인가되지 않은 도구는 실행 단계에서 차단되는 것이 아니라 도구 목록을 조회하는 단계에서부터 보이지 않으므로, 에이전트가 인식하고 판단 대상으로 삼을 수 있는 범위 자체가 줄어듭니다. 에이전트가 침해된 경우에도 마찬가지입니다.플랫폼 팀 관점에서 이 구조는 MCP 거버넌스를 API 거버넌스와 같은 방식으로 다룰 수 있게 합니다. 게시할 엔드포인트가 하나이고, 정책을 적용하는 지점이 하나이며, 호출자별 접근 통제가 클라이언트마다의 설정 상태에 좌우되지 않습니다. 2. 모달리티 단위 비용 관리AI 비용 관리는 게이트웨이가 인식하는 과금 모델이 실제 프로바이더의 과금 모델보다 단순할 때 무너집니다. 최근 모델은 토큰 단위로만 과금하지 않습니다. 텍스트와 오디오, 이미지, 비디오의 단가가 다르고, 캐시 읽기와 캐시 쓰기의 단가가 다르며, 실시간 요청과 표준 요청의 단가도 다릅니다. 게이트웨이가 입력과 출력 비용만 단일하게 추적한다면 비용 귀속 결과는 실제와 어긋납니다.이번 릴리스에서 ai-proxy-advanced에 동적 모달리티 인식 LLM 프라이싱이 추가됐습니다. 가격 정보를 한 번 정의해 두고 Konnect 프라이싱 카탈로그를 통해 여러 설정에서 재사용하는 방식으로, 카탈로그는 텍스트와 오디오, 이미지, 비디오의 가격 항목과 캐시 읽기, 캐시 쓰기 항목을 지원하며 동일한 카탈로그 항목이 실시간 요청과 표준 멀티모달 요청에 함께 적용됩니다.우선순위는 기본값이 정해져 있습니다. 카탈로그가 공통 기준선 역할을 하고, 타깃별로 설정한 model.options의 input_cost와 output_cost가 기본적으로 우선하며, 카탈로그 항목별로 이 순서를 뒤집는 재정의 옵션을 선택적으로 켤 수 있습니다. 중앙 플랫폼 팀이 가격 기준을 관리하면서도 개별 팀이 자기 배포 환경에 맞게 값을 조정할 수 있는 구조입니다.이 구성은 게이트웨이의 비용 분석과 토큰 기반 정책이 참조하는 가격 정보를 하나의 기준으로 관리하게 합니다. 3. 모델과 프로바이더 지원 확대AI 게이트웨이의 활용 범위는 연결할 수 있는 모델과 플랫폼의 범위에 따라 결정됩니다. 이번 릴리스에서는 Kimi와 Microsoft Foundry, Amazon SageMaker가 지원 대상에 추가됐습니다.Kimi는 네이티브로 지원되며, AI Gateway의 정책은 다른 프로바이더와 마찬가지로 Kimi 트래픽에도 동일하게 적용됩니다.Microsoft Foundry는 마이크로소프트가 Azure OpenAI Service와 Azure AI Studio, Azure AI Services를 통합한 플랫폼으로, services.ai.azure.com 엔드포인트에서 경로 프리픽스 라우팅으로 여러 모델 계열을 제공합니다. OpenAI 호환 배포는 /openai/v1/ 경로를, Claude 배포는 /anthropic/v1/messages 경로를 사용합니다. Kong의 Azure 프로바이더는 기존 Azure OpenAI URL 구조를 기준으로 만들어져 있었고 Foundry 엔드포인트는 임시 우회 방식으로 연결됐는데, 이 방식은 모델 이름에서 형식을 유추하는 구조여서 오설정이 발생하기 쉬웠습니다. 이번 릴리스는 이를 스키마 검증이 적용된 azure_service 셀렉터로 대체하고 전송 형식을 설정된 경로 프리픽스에서 결정하도록 바꿨으며, Foundry를 통해 제공되는 Claude 모델도 지원 대상에 포함됩니다.AWS 환경을 중심으로 구성된 조직 다수는 Amazon SageMaker에서 파운데이션 모델을 서빙합니다. TGI와 TEI, HuggingFace Inference, LMI(vLLM/DJL)를 포함한 ECR 추론 컨테이너 전반이 지원 대상입니다. SageMaker 전용 포맷을 새로 만드는 대신 애플리케이션이 보내는 요청을 OpenAI 형식으로 표준화하고 대상 컨테이너가 지원하는 경우 내부적으로 HuggingFace 형식으로 변환하는 방식이어서, 애플리케이션을 OpenAI 호환 호출로 구성해 둔 환경이라면 코드 변경 없이 SageMaker에서 서빙되는 모델에 연결할 수 있고 다른 프로바이더와 동일한 거버넌스가 적용됩니다. 4. Kong Identity Principal 기반 정책Kong Identity는 여러 게이트웨이에서 공유되고 자체 메타데이터를 갖는 인증 주체로 Principal을 도입했습니다. Principal은 개별 게이트웨이가 아니라 중앙에서 정의합니다. 이번 릴리스에서 이 개념이 AI Gateway에 적용됩니다.기존에는 AI Gateway 정책이 호출자를 컨슈머로만 식별했습니다. 컨슈머는 게이트웨이 단위 개념이어서 조직 전체에 걸친 아이덴티티를 담지 못했습니다. 이제 AI Gateway는 Principal을 인식하며, 요청 제한과 분석, 비용 귀속, 모델과 라우트 접근 제어를 컨슈머가 아니라 인증된 Principal 기준으로 적용할 수 있습니다.에이전트 환경에서는 이 구분의 의미가 커집니다. 호출 주체가 사용자나 팀, 다른 시스템을 대신해 동작하는 에이전트일 때 누가 이 호출을 하고 있는가는 비용 쇼백과 접근 판단, 감사 추적 모두에서 기준이 되는 정보이기 때문입니다. Principal을 기준으로 삼으면 Kong 환경 전체에서 동일한 아이덴티티 정의를 사용해 이 질문에 답할 수 있습니다.이 기능은 기존 설정에 더해지는 방식이며 기본적으로 비활성 상태입니다. 기존의 컨슈머 기반 설정은 그대로 동작하고, 필요한 지점부터 Principal을 적용하는 방식으로 도입할 수 있습니다. 5. Bedrock AgentCore 대상 AWS IAM 인증ai-a2a-proxy와 ai-mcp-proxy 플러그인에는 AWS에서 호스팅되는 Bedrock AgentCore 에이전트나 MCP 서버로 나가는 요청을 인증하는 내장 수단이 없었습니다. 그래서 요청 서명을 위해 pre-function을 직접 작성하는 방식이 사용됐습니다.이번 릴리스는 플러그인에 종속되지 않는 업스트림 인증 프레임워크를 도입하고, AgentCore 엔드포인트를 대상으로 AWS SigV4(IAM) 인증을 두 플러그인에 연결했습니다. 운영자는 AgentCore 에이전트와 MCP 서버에 대한 인증을 선언적으로 구성할 수 있으며, 자격 증명은 플랫폼의 다른 자격 증명과 동일한 방식으로 처리됩니다. ☑️ 기존 환경에서 전환을 검토할 때 확인할 조건정식 출시는 Kong AI Gateway 2.0이 프로덕션 지원 대상이 되었다는 의미이며, Kong이 제공하는 컴플라이언스 및 지원 체계가 적용됩니다.현재 Kong Gateway에서 AI Gateway 플러그인을 운영하고 있다면 기존 구현은 그대로 동작합니다. AI 플러그인은 LTS 릴리스인 Kong Gateway 3.14에서 계속 지원되며, 기준이 되는 시점은 Kong Gateway 3.18입니다. 이 릴리스부터 AI 플러그인이 기본 번들에서 제외되고 필요한 경우 선택해 사용하는 방식으로 바뀌므로, 그 이전에 마이그레이션을 계획하는 것이 권고되고 있습니다.마이그레이션 도구는 이미 제공되고 있습니다. kongctl이 기존 decK 설정을 AI Gateway 2.0 네이티브 설정으로 변환하며, kongctl을 통해 2.0 설정을 선언적으로 관리할 수 있어 기존 GitOps 워크플로에 그대로 연결됩니다. 환경의 decK 덤프를 기준으로 Kong 계정 팀이 마이그레이션을 직접 수행하는 방식도 함께 제공됩니다. ☑️ 자주 묻는 질문Kong AI Gateway 2.0은 무엇인가요? Kong AI Gateway 2.0은 AI 트래픽을 위한 전용 런타임과 컨트롤 플레인, 자체 관리 API를 갖춘 AI 게이트웨이 제품입니다. 2026년 9월 1일 정식 출시됐으며 Kong Konnect에서 별도의 베타 활성화 없이 사용할 수 있습니다. 모델과 MCP 서버, 에이전트를 각각 독립된 관리 대상으로 다룹니다.기존 AI Gateway 플러그인을 쓰고 있으면 지금 바로 옮겨야 하나요? 그렇지 않습니다. Kong Gateway에서 운영 중인 구현은 그대로 동작하며, AI 플러그인은 LTS 릴리스인 3.14에서 계속 지원됩니다. 다만 3.18부터 AI 플러그인이 기본 번들에서 제외되고 선택 적용 방식으로 바뀌므로 그 이전에 전환을 계획하는 것이 권고되고 있습니다.MCP Server Bundling은 어떤 문제를 해결하나요? 여러 MCP 서버를 클라이언트마다 개별 설정해야 하는 문제를 해결합니다. 하나의 Kong 라우트로 연결하면 Kong이 상위 MCP 서버 전체의 도구 목록을 조회해 통합 카탈로그로 제시하며, MCP ACL과 연동되어 호출자가 인가받은 도구만 목록에 나타납니다.컨슈머와 Principal은 무엇이 다른가요? 컨슈머는 게이트웨이 단위 개념이고 Principal은 중앙에서 정의해 여러 게이트웨이가 함께 사용하는 인증 주체입니다. Principal을 기준으로 하면 요청 제한과 비용 귀속, 접근 제어를 조직 전체에 걸쳐 동일한 아이덴티티 정의로 적용할 수 있습니다. 기본은 비활성 상태이며 기존 컨슈머 기반 설정은 그대로 유지됩니다.AI Gateway 2.0 설정은 어떻게 관리하나요?kongctl을 통해 선언적으로 관리할 수 있어 기존 GitOps 워크플로에 그대로 연결됩니다. kongctl은 마이그레이션 도구이기도 해서, 기존 decK 설정을 AI Gateway 2.0 네이티브 설정으로 변환합니다. ☑️ 마무리Kong AI Gateway 2.0은 AI 게이트웨이를 API 게이트웨이의 기능 집합에서 분리해 자체 런타임과 릴리스 주기를 갖는 제품으로 재정의한 릴리스입니다. 설정 단위가 플러그인에서 AI Model, AI Model Provider, AI MCP Server, AI Agent 같은 엔티티로 바뀌었고, 정식 출시와 함께 MCP 서버 번들링과 모달리티 단위 비용 관리, 프로바이더 지원 확대, Principal 기반 정책, AgentCore 대상 IAM 인증이 추가됐습니다.도입이나 전환을 검토한다면 확인할 항목은 다음과 같습니다. 현재 사용 중인 모델과 프로바이더, MCP 서버가 어디까지 지원 범위에 들어오는지, 호출자별 도구 접근 통제를 어떤 아이덴티티 기준으로 설계할지, 기존 Kong Gateway 환경에서 운영 중인 AI 플러그인 구성을 언제 전환할지가 출발점이 됩니다.클라우드네트웍스는 고객 환경의 AI 트래픽 구성과 MCP 서버 현황을 확인하고, Kong AI Gateway 기준으로 적용 범위와 배포 형태를 검토하는 과정부터 구축까지 지원합니다. AI 게이트웨이 도입이나 기존 환경의 전환을 검토하고 계시다면 클라우드네트웍스로 문의해 주시기 바랍니다. ▶ Kong AI Gateway 자세히보기 [출처 : Kong, "Kong AI Gateway 2.0 Is Now GA — And It's Already Moving Faster", https://konghq.com/blog/product-releases/kong-ai-gateway-2-0-ga, Kong, "Announcing Kong AI Gateway 2.0: Built for the Pace of Agentic AI", https://konghq.com/blog/product-releases/kong-ai-gateway-2-0-agentic-ai, Kong, "AI Gateway 2.x concepts", https://developer.konghq.com/ai-gateway/ai-gateway-v2-concepts/]

기업이 생성형 AI를 시범 단계에서 실제 서비스 운영 단계로 옮기면서, 클라우드 비용에서 GPU가 차지하는 비중이 빠르게 커지고 있습니다. 모델을 고르고 서빙 환경을 구성하는 일까지 마쳤는데, 청구서를 열어보면 예상보다 큰 금액이 찍혀 있는 상황이 반복됩니다.문제는 GPU를 얼마나 많이 샀느냐가 아니라, 확보한 GPU를 얼마나 쓰고 있느냐에 있습니다. Cast AI가 AWS, Azure, GCP에 걸친 수천 개 클러스터를 분석한 2026 State of Kubernetes Optimization Report에 따르면 프로덕션 쿠버네티스 클러스터의 평균 GPU 사용률은 5퍼센트입니다. GPU는 실제로 얼마나 일했는지와 관계없이 시간당 요금 전액이 청구되므로, 나머지 95퍼센트는 비용만 발생시키고 있는 용량입니다.이 격차는 하드웨어를 새로 늘리지 않고도 좁힐 수 있습니다. 쿠버네티스 환경의 LLM 추론 비용을 줄이는 방법은 다섯 가지로 정리됩니다. GPU 공유와 연속 배칭, 양자화, 라이트사이징, 오토스케일링이며, 각 방법이 해결하는 문제와 운영 환경에서 확인해야 할 지점, Cast AI의 자동화 방식까지 순서대로 정리했습니다. ☑️ LLM 추론 비용 최적화란 무엇인가LLM 추론 비용 최적화는 쿠버네티스에서 대규모 언어 모델을 서빙하는 데 드는 GPU 연산과 메모리 비용을 줄이는 방법을 말합니다. GPU 공유와 배칭으로 사용 효율을 높이고, GPU 요청을 실제 사용량에 맞게 조정하며, 추론 엔드포인트를 수요에 맞춰 자동으로 늘리고 줄이는 방식이 포함됩니다. 유휴 상태일 때 레플리카를 0으로 내리는 scale-to-zero도 여기에 해당합니다.핵심은 추론 지출의 대부분이 실제 연산이 아니라 놀고 있는 용량에 쓰인다는 점입니다. 따라서 비용을 줄이는 출발점은 모델을 바꾸는 것이 아니라, 이미 확보한 GPU가 요청과 요청 사이에 멈춰 있는 시간을 줄이는 데 있습니다. ☑️ GPU 사용률이 추론 비용을 결정하는 이유같은 하드웨어에서 처리 방식만 바꿔도 토큰당 비용이 크게 달라집니다. Llama 3.1 70B를 H100 한 장에서 단일 스트림 방식으로 실행하면 백만 토큰당 약 0.60~0.80달러가 듭니다. 배치 크기 8의 연속 배칭을 적용하면 같은 조건에서 백만 토큰당 0.15~0.25달러로 내려갑니다. GPU가 빨라진 것이 아니라, 요청 사이에 GPU를 놀리지 않게 된 결과입니다.이 수치는 Cast AI 벤치마크 조건에서 측정된 값입니다. Llama 3.1 70B FP8, H100 80GB SXM5, vLLM 0.5 이상, 512토큰 프롬프트와 256토큰 출력, AWS eu-west-1 리전의 H100 스팟 가격 시간당 약 2~4달러(2025년) 기준입니다. 절감폭은 약 2K 토큰 이하의 짧은 컨텍스트에서 확인되며, 컨텍스트가 길어지면 KV 캐시가 가중치 메모리와 경쟁하면서 유지할 수 있는 배치 크기가 줄어듭니다.사용률 격차는 클라우드별로도 나타납니다. Cast AI 측정 기준 Azure AKS는 2퍼센트, Amazon EKS는 5퍼센트, Google GKE는 6퍼센트였습니다. 같은 데이터셋에서 가장 높은 사용률을 기록한 클러스터는 136노드 H200 구성으로 49퍼센트에 도달했습니다. 5퍼센트와 49퍼센트의 차이는 하드웨어를 교체하지 않고도 좁힐 수 있는 폭입니다.유휴 자원의 비용은 계산해 보면 더 분명해집니다. H100 스팟 가격은 클라우드와 리전에 따라 시간당 2~6달러 범위이며, 시간당 3달러로 잡아도 유휴 레플리카 한 개가 월 2,160달러를 소모합니다. 주요 클라우드의 온디맨드 가격인 시간당 8~12달러 기준으로는 월 5,760~8,640달러입니다. 레플리카 한 개 기준의 금액입니다. ☑️ GPU 사용률을 높이는 다섯 가지 접근 방식1. GPU 공유 : MIG와 타임슬라이싱A100 80GB 한 장은 여러 개의 독립적인 추론 워크로드를 동시에 수용할 수 있습니다. NVIDIA MIG(Multi-Instance GPU)는 물리 GPU 하나를 하드웨어 수준에서 격리된 파티션으로 나누며, 각 파티션은 전용 메모리와 연산 자원, L2 캐시를 갖습니다. 가상화가 아니라 독립된 물리 디바이스처럼 동작하는 방식입니다.A100 80GB의 MIG 프로파일은 다음과 같이 구분됩니다.프로파일메모리수용 가능한 모델1g.10gb10GBINT4/GPTQ 7B 모델(약 4~5GB) 또는 소형 임베딩 모델2g.20gb20GB7B INT8(약 7GB), 13B INT8(약 13GB)에 KV 캐시 여유 확보3g.40gb40GB약 30GB까지의 INT4/AWQ 모델. INT4 70B(약 35GB)는 파티션 한계에 근접7g.80gb80GB 전체AWQ 정밀도의 70B 모델 또는 34B 이상 FP16/BF16 모델주의할 제약이 하나 있습니다. 각 MIG 파티션은 독립된 모델 인스턴스를 실행하며, 하드웨어 격리 때문에 파티션 사이의 NVLink와 P2P CUDA 통신이 비활성화됩니다. 동일한 A100의 두 MIG 슬라이스에 걸쳐 텐서 병렬 처리를 구성하는 것은 구조적으로 불가능하므로, 70B 모델을 여러 장에 분할해야 한다면 MIG 파티션이 아니라 NVLink로 연결된 물리 GPU를 사용해야 합니다. 쿠버네티스에서는 nvidia-device-plugin이 MIG 파티션을 스케줄링 가능한 자원으로 노출하며, 3g.40gb 파티션을 대상으로 하는 배포는 리소스 스펙에 nvidia.com/mig-3g.40gb 자원을 요청하는 방식으로 구성합니다.MIG를 지원하지 않는 T4, A10G, 구형 Ampere 카드에서는 타임슬라이싱이 대안이 됩니다. 타임슬라이싱은 하드웨어 분할이 아니라 스케줄링 수준에서 GPU 접근을 다중화하므로 여러 파드가 동일한 GPU 컨텍스트를 공유합니다. 테넌트 간 메모리 격리가 없어 노이지 네이버 영향이 실제로 발생하기 때문에, 지연에 민감한 프로덕션 추론보다는 개발 워크로드나 우선순위가 낮은 배치 작업에 적합합니다. 2. 연속 배칭, 추측 디코딩, 프리픽스 캐싱정적 배칭은 배치가 다 찰 때까지 기다렸다가 요청을 한꺼번에 처리합니다. 오프라인 작업에는 맞는 방식이지만 온라인 추론에서는 짧은 요청이 긴 요청이 끝나기를 기다리게 만들어 처리량이 떨어지고 테일 레이턴시가 튑니다. 연속 배칭은 생성 과정을 개별 이터레이션의 흐름으로 다뤄 이 문제를 해결합니다. 배치 전체가 끝나기를 기다리지 않고 슬롯이 비는 즉시 새 요청이 배치에 합류하며, vLLM은 이 방식을 기본값으로 사용합니다. 동일한 하드웨어 예산에서 정적 배칭 대비 3~5배 높은 처리량을 내며, 길이가 섞인 워크로드에서 P99 레이턴시도 낮아집니다.추측 디코딩은 작은 드래프트 모델이 여러 토큰을 미리 제안하고 메인 모델이 한 번의 포워드 패스로 검증하는 방식입니다. 자기회귀 LLM의 토큰 생성은 연산이 아니라 메모리 대역폭에 묶여 있기 때문에, 드래프트 토큰 여러 개를 검증하는 비용이 하나를 검증하는 비용과 거의 같습니다. 제안이 맞으면 한 번의 포워드 패스에서 여러 토큰을 얻습니다. 배치 크기 1~2의 채팅 인터페이스나 코파일럿 도구처럼 요청당 지연이 중요한 환경에서 생성 레이턴시를 30~50퍼센트까지 줄일 수 있습니다. 동시성이 높아지거나 배치 크기가 커지면 드래프트 모델을 병렬로 돌리는 부담 때문에 순이익이 줄어들므로, 실제 요청 동시성 수준에서 효과를 측정한 뒤 적용해야 합니다.프리픽스 캐싱은 반복되는 프롬프트 앞부분의 KV 상태를 GPU 메모리에 저장해 재사용합니다. 대부분의 채팅과 RAG 워크로드는 모든 요청에 동일한 시스템 프롬프트를 함께 보내는데, 캐싱이 없으면 모델이 매 호출마다 그 프리픽스의 KV 상태를 다시 계산합니다. 70B 모델에 512토큰 시스템 프롬프트를 사용하는 환경이라면 프리필 연산 낭비가 상당합니다. 긴 공통 시스템 프롬프트를 쓰는 채팅이나 RAG 배포에서 프리픽스 캐싱은 반복 질의의 프리필 연산을 60~80퍼센트까지 제거합니다. 첫 토큰까지의 시간이 줄고 같은 하드웨어에서 실효 처리량이 올라갑니다. 3. 양자화와 토큰당 비용양자화는 모델 가중치를 저장하는 수치 정밀도를 낮추는 방식입니다. 파라미터당 비트 수가 줄면 VRAM 사용량이 작아지고 메모리 처리량이 올라가며, 하드웨어에 따라서는 연산 가속까지 받습니다. 대신 정밀도가 낮아지면서 생기는 반올림 오차가 레이어를 거치며 누적됩니다.어떤 포맷이 적합한지는 GPU 아키텍처에 따라 달라집니다.GPU아키텍처권장 포맷특징H100 80GB, H200HopperFP8네이티브 FP8 텐서 코어 지원. BF16 대비 VRAM 절반, 처리량 1.5~1.8배A100 80GB (프로덕션 70B)AmpereAWQ / INT4AWQ 4비트로 70B를 약 35~37GB로 축소, 80GB 중 약 40GB를 KV 캐시에 확보A100 80GB (소형 모델 또는 정확도 우선)AmpereINT8파라미터당 1바이트 유지. 70B INT8은 약 70GB로 KV 캐시 여유가 거의 없음T4, L4, A10GTuring / AmpereINT4 / GPTQ / GGUFVRAM 16~24GB 제약. 소형 모델 위주, 정확도 손실이 더 큼VRAM 계산이 중요합니다. 70B 모델을 FP16/BF16으로 실행하면 가중치만 약 140GB가 필요하지만, A100 80GB에서 AWQ 4비트를 적용하면 약 35~37GB로 줄어 KV 캐시와 활성값에 약 40GB가 남습니다. FP8 추론을 하려면 네이티브 FP8 하드웨어 지원이 있는 H100 80GB나 H200이 필요하며, A100에서 소프트웨어 에뮬레이션으로 FP8을 돌리면 처리량 이점 없이 출력 품질만 떨어집니다. 정확도 손실 폭은 포맷과 모델 계열, 작업 유형에 따라 달라집니다. H100/H200의 FP8은 BF16 대비 MMLU 정확도 하락이 대체로 1퍼센트 미만이고, A100의 AWQ는 1~3퍼센트, INT4(GPTQ/GGUF)는 3~6퍼센트 수준입니다. AWQ는 가장 민감한 가중치 채널을 식별해 보호하기 때문에 단순 INT8보다 정확도를 잘 유지합니다. 어느 포맷이든 프로덕션 배포 전에 실제 모델과 과제로 벤치마크를 거쳐야 합니다. 4. GPU 요청 라이트사이징쿠버네티스 GPU 배포에서 과다 프로비저닝은 기본 동작에 가깝습니다. 9GB를 사용하는 워크로드에 H100 80GB를 요청하면 GPU는 8퍼센트 사용률로 돌아가고 요금은 100퍼센트로 청구됩니다. 이 패턴은 규모가 커질수록 플릿 전반에서 반복됩니다.라이트사이징은 자원 선언을 최악의 가정이 아니라 실제 피크 사용량에 맞추는 작업입니다. 추론 워크로드에서 확인해야 할 지표는 세 가지입니다.GPU 메모리 사용률은 nvidia-smi나 DCGM exporter로 컨테이너 단위로 측정합니다. 40GB를 요청했지만 피크가 18GB인 파드는 더 작은 파티션이나 인스턴스 타입으로 옮기는 것이 맞습니다. SM 사용률은 모델이 연산에 묶여 있는지 메모리 대역폭에 묶여 있는지를 보여줍니다. 대부분의 추론 워크로드는 연산이 아니라 메모리 대역폭에 묶이기 때문에, SM 사용률이 낮은데 메모리 대역폭 사용률이 높은 상태는 낭비가 아니라 정상 동작입니다. 이 지표만 보고 자원을 줄이면 판단을 그르칠 수 있습니다. 토큰 처리량과 SLO 대비 수준은 오토스케일러 임계값 설정의 기준이 됩니다. 레플리카당 최소 초당 토큰 목표를 정의하고, 목표 아래로 떨어지면 레플리카를 늘리고 목표를 크게 웃돌면 인스턴스 크기를 줄이는 방식입니다.흔한 실수 하나는 MIG 프로파일이나 인스턴스 타입을 지정하지 않고 nvidia.com/gpu 자원 하나만 요청하는 경우입니다. 이렇게 두면 스케줄러가 가용한 아무 GPU에나 파드를 배치할 수 있어, 7B INT4 모델이 H100 80GB에 올라가는 상황이 생깁니다. 명시적인 자원 라벨과 노드 셀렉터, 노드 어피니티 규칙으로 워크로드를 올바른 GPU 등급에 묶어야 합니다. 5. 오토스케일링과 scale-to-zero유휴 GPU 레플리카는 추론 예산에서 가장 비싼 항목입니다. 축소되지 않는 정적 배포는 쓰지 않는 용량에 대해 계속 과금됩니다. 쿠버네티스 HPA는 기본적으로 CPU와 메모리를 기준으로 스케일링하는데, 두 지표 모두 GPU 추론 워크로드에서는 의미 있는 신호가 아닙니다. LLM 추론에 맞는 오토스케일링은 추론 고유의 신호를 사용합니다.큐 깊이는 슬롯을 기다리는 추론 요청의 수로, 큐가 길어지는 것은 레이턴시가 나빠지기 전에 용량 부족을 알려주는 선행 신호입니다. 레플리카당 초당 토큰은 SLO 목표 아래로 지속적으로 떨어지면 스케일 아웃을, 목표를 지속적으로 웃돌면 스케일 인을 유발하는 기준이 됩니다. GPU 메모리 압박은 KV 캐시 사용률로 확인하며, 80퍼센트를 넘으면 OOM으로 인한 축출이나 KV 캐시 축출 정책에 따른 품질 저하가 다가오고 있다는 신호입니다. KEDA(Kubernetes Event-Driven Autoscaler)는 Prometheus 기반 커스텀 메트릭을 지원하기 때문에 추론 인지형 오토스케일링의 표준 선택지로 쓰입니다.가장 강한 형태의 비용 통제는 scale-to-zero입니다. 개발 엔드포인트나 내부 도구, 트래픽이 적은 모델은 유휴 상태에서 레플리카를 0으로 내리면 유지 비용이 사라집니다. 대가는 콜드 스타트 지연입니다. A100 80GB에서 70B AWQ 모델을 오브젝트 스토리지에서 GPU 메모리로 로드하는 데 스토리지 대역폭에 따라 30~90초가 걸립니다. 지연에 민감한 워크로드는 워밍 레플리카를 최소 하나 유지하고, 배치나 비동기 워크로드는 scale-to-zero를 기본값으로 두는 편이 합리적입니다. ☑️ Cast AI는 이 다섯 가지를 어떻게 지원하는가다섯 가지 접근 방식을 수동으로 구현하면 관리해야 할 도구와 설정, 대응 경로가 각각 다섯 개로 늘어납니다. Cast AI는 이 작업들을 하나의 제어 평면에서 동시에 자동화합니다. GPU 공유 : 세 가지 분할 방식과 자동 배치Cast AI는 타임슬라이싱과 MIG 두 가지 방식으로 GPU를 공유하고 분할합니다. 타임슬라이싱은 모든 NVIDIA GPU에서 사용할 수 있으며 GPU당 1개에서 48개까지 레플리카를 구성하고, 워크로드 밀도에 맞춰 공유 비율을 GPU 타입별로 다르게 설정할 수 있습니다. MIG는 A100, A30, H100에서 하드웨어 격리 파티션을 만들며, 각 파티션이 전용 연산 코어와 메모리를 갖기 때문에 노이지 네이버 문제가 발생하지 않습니다. 두 방식은 조합할 수도 있습니다. 7개 MIG 파티션 각각에 4-way 타임슬라이싱을 적용하면 A100 한 장에서 28개 워크로드를 동시에 운영할 수 있어, 모델 버전을 여러 개 서빙하거나 A/B 테스트를 돌리는 추론 환경처럼 파티션 하나도 다 채우지 못하는 워크로드에 유효합니다.클라우드별 지원 범위에는 차이가 있습니다. 타임슬라이싱은 AWS EKS와 GCP GKE에서 지원되며 EKS는 Amazon Linux 2023 또는 Bottlerocket이 필요하고, MIG는 EKS와 GKE에서 지원되며 EKS는 Bottlerocket을 요구합니다. AWS G6 인스턴스에서는 사전 분할된 Fractional GPU를 사용할 수 있습니다. 설정은 노드 템플릿에서 이뤄지므로 워크로드 매니페스트를 수정할 필요가 없습니다. 애플리케이션은 평소처럼 자원을 요청하고, 공유 구성은 인프라 계층에서 관리됩니다.여기에 배치 엔진이 붙습니다. Cast AI는 공유되고 분할된 GPU 전반에 워크로드를 자동으로 빈패킹하며, 새 노드를 늘리기 전에 기존 노드의 사용률을 먼저 채웁니다. MIG 파티션과 공유 설정, 워크로드 요구사항을 함께 고려하는 배치 알고리즘이므로 매니페스트에 스케줄링 로직을 넣지 않아도 됩니다. 자원 요청 라이트사이징 : 재시작 없이 적용수동 라이트사이징은 느리고 위험 부담이 있어, 팀은 안전한 쪽을 택해 자원을 여유 있게 잡아두게 됩니다. Cast AI 워크로드 오토스케일러는 과거 지표와 실시간 지표를 함께 분석해 CPU와 메모리 요청을 실제 사용 패턴에 맞춥니다. 실행 중인 파드의 자원 할당을 재시작 없이 변경하는 in-place 파드 리사이징을 지원하기 때문에 조정 과정에서 서비스가 끊기지 않으며, 변경을 바로 적용하는 즉시 모드와 유지보수 시간대나 트래픽이 적은 시간에 적용하는 지연 스케일링 모드를 선택할 수 있습니다. 예상치 못한 트래픽 급증에는 자동으로 자원을 확대해 대응합니다.수직 스케일링과 수평 스케일링은 함께 쓰면 충돌하기 쉬운 조합입니다. 워크로드 오토스케일러는 HPA와 VPA를 결합하면서 둘 사이의 충돌을 조정해 단기 수요 급증과 장기 추세를 함께 반영하고, 메모리 부족으로 인한 크래시는 적응형 메모리 조정으로 사전에 방지합니다. 적용 대상은 Deployment, StatefulSet, Job, CronJob이며 라벨 기반 선택으로 커스텀 워크로드까지 포함합니다. 퍼시스턴트 스토리지를 사용해 이동이 어려웠던 워크로드는 컨테이너 라이브 마이그레이션으로 노드 간 이동이 가능해지며, 이는 노드 조각화를 줄여 빈패킹 여지를 넓히는 역할도 합니다.Cast AI가 공개한 수치 기준으로 최적화 전 평균 CPU 사용률은 8퍼센트이며, 자동 라이트사이징 적용 이후 OOM kill은 거의 발생하지 않았습니다. 고객들이 확인하는 클라우드 비용 절감폭은 30~70퍼센트 범위이며, 이 수치는 Cast AI 2026 State of Kubernetes Optimization Report와 Akamai, Wio Bank 등 고객 사례를 근거로 합니다. GPU 자원에 대해서는 DCGM 메트릭을 지속적으로 읽어 관측된 워크로드 동작을 근거로 권고를 만듭니다. 정적 규칙이 아니라 실제 측정값에 기반하므로, 여러 모델 크기가 섞인 공유 클러스터에서도 수동 프로파일링 주기를 돌리지 않고 프로비저닝 용량과 실제 소비량의 격차를 줄일 수 있습니다. 노드 라이프사이클 : 파드가 아니라 노드를 내린다오토스케일링에서 HPA와 갈리는 지점은 노드입니다. HPA는 파드를 축소하지만 하단 노드는 과금을 계속합니다. Cast AI 워크로드 오토스케일링은 GPU 노드 라이프사이클 관리와 직접 연동되어, 마지막 추론 레플리카가 내려가면 하단 GPU 노드를 해제해 과금을 멈추고 수요가 돌아오면 새 노드를 프로비저닝하면서 파드 스케줄링을 병렬로 진행합니다. scale-to-zero가 비용 절감으로 실제로 이어지려면 파드 축소가 노드 해제까지 닿아야 한다는 점에서 이 연동이 핵심입니다.노드를 새로 띄울 때는 워크로드의 자원 요청을 읽어 스팟과 온디맨드 풀 전반에서 적합한 인스턴스 타입에 매칭합니다. 스팟 인스턴스를 우선 사용하되 회수 상황에서는 자동으로 폴백하는 구조이므로, 지연에 민감하지 않은 추론 작업에 스팟을 적용하면서도 운영 안정성을 유지할 수 있습니다. AI 수요는 튀는 성격이 강한데, GPU 용량 자체를 실제 워크로드 수요에 맞춰 지속적으로 늘리고 줄입니다. 배포 스펙에 MIG 자원 라벨을 선언하면 해당 파티션을 제공하는 노드 타입을 자동으로 프로비저닝하므로, 인스턴스를 수동으로 고르는 과정도 필요하지 않습니다. GPU 용량 확보 : OMNI Compute for AI앞의 세 가지가 이미 확보한 GPU를 얼마나 잘 쓰느냐의 문제라면, 그 앞에 놓인 문제가 하나 더 있습니다. 필요한 시점에 필요한 리전에 GPU가 없는 상황입니다. Cast AI는 이 경우를 비용 최적화가 아니라 용량 조달과 조정의 문제로 구분합니다.OMNI Compute for AI는 기존 쿠버네티스 클러스터를 여러 클라우드와 리전의 GPU 용량으로 확장합니다. 원격 GPU 노드는 클러스터의 네이티브 노드로 합류하므로 애플리케이션 코드를 바꿀 필요가 없습니다. 연결은 Crossplane과 CRD 기반 프로비저닝을 통해 WireGuard 보안 연결 위에서 이뤄지고 설정에는 Terraform을 사용할 수 있으며, GPU 드라이버 설치는 노드가 올라오는 시점에 자동으로 처리됩니다. 오토스케일러는 노드를 프로비저닝하기 전에 메인 클러스터 리전과 연결된 모든 엣지 로케이션의 스팟 및 온디맨드 가격을 비교하고, 용량이 있으면서 비용이 가장 낮은 곳에 노드를 띄웁니다. 비용, 성능, 컴플라이언스 조건을 워크로드별로 설정할 수 있어 어디에서 실행할지에 대한 통제권은 유지됩니다.이미 확보한 용량이 있는 조직이라면 조달 없이도 사용할 수 있습니다. 다른 계정의 예약 용량, 프라이빗 클라우드 노드, 자체 인프라를 기존 클러스터에 연결하고 배치와 공유, 가시성 관리만 맡기는 구성이 가능합니다. 기존 계약과 공급자를 유지한 상태에서 운영 방식만 바꾸는 방식입니다. 다만 워크로드 성격에 따라 적합도는 갈립니다. GPU 집약적 워크로드와 배치 처리, 데이터 처리 파이프라인, 스테이트리스 애플리케이션은 적합한 반면, 지연에 민감한 ML 학습 작업이나 퍼시스턴트 볼륨이 필요한 데이터베이스 워크로드는 적합하지 않습니다. 추론과 배치 워크로드가 OMNI의 주 대상인 이유입니다. 가시성 : 어디서 새고 있는지 먼저 확인최적화를 이제 시작하는 단계라면 순서가 있습니다. 워크로드별 GPU 사용률과 메모리 사용량, 성능을 실시간으로 확인하고, 그 사용량을 워크로드와 팀, 애플리케이션 단위로 배분해 누가 무엇에 쓰고 있는지 파악하는 단계입니다. 유휴 용량을 찾아내고 최적화 권고를 제시하는 기능이 여기에 함께 붙습니다. 대부분의 팀은 이 단계에서 2~3개 워크로드가 GPU 지출의 대부분을 차지한다는 사실을 발견하며, 그 워크로드를 먼저 처리하면 이후 최적화 작업에 쓸 재원이 확보됩니다.실제 적용 사례도 확인됩니다. 쿠버네티스에서 프로덕션 LLM 추론을 운영하는 생성형 AI 기업 Fairgen은 Cast AI 도입 후 모델 스택이나 서빙 프레임워크를 바꾸지 않고 GPU 인프라 비용을 70퍼센트 줄였습니다. 절감 요인은 노드 라이트사이징, 오토스케일링에 따른 노드 해제, 지연에 민감하지 않은 추론 작업에 대한 스팟 인스턴스 적용이었습니다. ☑️ 자주 묻는 질문Q. LLM 추론 비용이 높아지는 가장 큰 원인은 무엇인가요?유휴 GPU 용량입니다. Cast AI 2026 State of Kubernetes Optimization Report 기준 대부분의 프로덕션 쿠버네티스 클러스터는 GPU를 평균 5퍼센트 사용률로 운영합니다. GPU는 실제 사용률과 무관하게 시간당 요금 전액이 청구되므로, 배칭과 공유, 오토스케일링으로 이 격차를 줄일 때 가장 큰 절감이 발생합니다.Q. 양자화를 적용하면 모델 출력 품질이 떨어지나요?떨어집니다. 정밀도를 낮추면 반올림 오차가 생깁니다. H100의 FP8은 BF16 대비 MMLU 정확도 하락이 대체로 1퍼센트 미만이고, A100의 AWQ는 1~3퍼센트, INT4(GPTQ/GGUF)는 3~6퍼센트 수준입니다. 프로덕션 배포 전에 실제 모델과 과제로 벤치마크를 거치는 과정이 필요합니다.Q. A100 80GB 한 장에서 70B 모델을 운영할 수 있나요?AWQ 4비트 양자화를 적용하면 가능합니다. 가중치가 약 35~37GB로 줄어 80GB 디바이스에서 KV 캐시와 활성값에 약 40GB가 남습니다. INT8은 파라미터당 1바이트를 유지하므로 70B 모델이 약 70GB가 되어 KV 캐시 여유가 거의 없습니다. 네이티브 하드웨어 가속을 받는 FP8 추론이 필요하면 H100 80GB나 H200이 필요합니다.Q. MIG 파티션으로 70B 모델의 텐서 병렬 처리를 구성할 수 있나요?불가능합니다. MIG 파티션은 하드웨어 수준에서 격리되어 있어 동일 물리 GPU의 MIG 인스턴스 간 NVLink와 P2P CUDA 통신이 비활성화됩니다. 텐서 병렬 처리는 GPU 간 고속 통신을 전제로 하므로, TP-2 이상이 필요하다면 MIG 파티션이 아니라 NVLink로 연결된 물리 GPU를 사용해야 합니다.Q. HPA만으로 GPU 비용을 줄일 수 있나요?한계가 있습니다. HPA는 파드를 축소하지만 하단 노드는 과금을 계속합니다. GPU 비용을 실제로 줄이려면 파드 축소가 노드 해제까지 이어져야 합니다. Cast AI 워크로드 오토스케일링은 마지막 레플리카가 내려갈 때 하단 GPU 노드를 해제해 과금을 중단합니다. ☑️ 마무리LLM 추론 비용은 GPU를 얼마나 확보했는지가 아니라 확보한 GPU를 요청 사이에 얼마나 놀리지 않는지에서 갈립니다. GPU 공유로 한 장에 여러 워크로드를 태우고, 연속 배칭으로 요청 간 공백을 없애고, 양자화로 메모리 요구량을 줄이고, 라이트사이징으로 요청과 실사용의 간격을 좁히고, 오토스케일링으로 유휴 노드를 해제하는 다섯 가지가 모두 같은 방향을 향합니다. 평균 5퍼센트와 최고 49퍼센트의 격차는 하드웨어를 바꾸지 않고도 좁힐 수 있는 폭입니다.다만 이 다섯 가지를 각각의 도구와 설정으로 나눠 운영하면 관리 부담이 그만큼 늘어납니다. Cast AI는 GPU 공유와 배치, 라이트사이징, 노드 라이프사이클 관리를 하나의 제어 평면에서 자동으로 처리하며, 비용을 보여주는 데서 그치지 않고 실제 조치까지 수행합니다. 클라우드네트웍스는 Cast AI의 국내 파트너로서 고객 환경에 맞춘 도입 검토부터 구축, 운영까지 함께합니다. AI 워크로드 확대와 함께 GPU 비용 관리를 고민중이시라면 클라우드네트웍스로 문의해 주세요. ▶ Cast AI 자세히보기 [출처 : CAST AI, "LLM Inference Cost Optimization: Run AI Inference for Less", https://cast.ai/blog/llm-inference-cost-optimization/, CAST AI, "GPU Optimization for AI Infrastructure", https://cast.ai/gpu-optimization/, CAST AI, "GPU Sharing", https://cast.ai/gpu-sharing/, CAST AI, "Cross-Cloud GPU Access", https://cast.ai/cross-cloud-gpu-access/, CAST AI, "Kubernetes Workload Optimization & Rightsizing", https://cast.ai/workload-optimization/, CAST AI, "Multi-Cloud and Cross-Region GPU Capacity for Kubernetes AI", https://cast.ai/blog/multi-cloud-gpu-kubernetes/, CAST AI, "GPU sharing methods", https://docs.cast.ai/docs/gpu-sharing, CAST AI, "Multi-Instance GPU (MIG)", https://docs.cast.ai/docs/gpu-sharing-mig, CAST AI, "What is OMNI?", https://docs.cast.ai/docs/omni-overview, CAST AI, "2026 State of Kubernetes Optimization Report", https://cast.ai/reports/state-of-kubernetes-optimization/]