피싱은 오래된 공격 방식입니다. 그런데도 보안 운영 조직이 가장 많은 시간을 쓰는 영역 중 하나로 남아 있고, 최근에는 공격 형태가 정교해지면서 조사 난도까지 함께 올라갔습니다.부담은 건수에서만 나오지 않습니다. 의심스러운 이메일이 신고되고 알림이 생성된 다음부터가 실제 업무의 시작입니다. 메시지 상세 정보는 한 도구에서, 링크 분석은 다른 도구에서, 아티팩트 보강은 또 다른 도구에서 확인해야 합니다. 그러는 동안 지금 보고 있는 것이 공격 전체인지 일부인지도 판단해야 합니다. 하루에 처리하는 알림 수를 곱해 보면 조사보다 도구 사이를 오가는 데 쓰는 시간이 더 큽니다.스플렁크 엔터프라이즈 시큐리티(Splunk Enterprise Security)에는 이 문제를 겨냥한 Automated Threat Analysis 기능이 추가됐습니다. 피싱 공격 체인을 자동으로 실행하고 분석해, 판단에 필요한 컨텍스트와 증거를 분석가의 작업 화면에 제공하는 기능입니다. Splunk Attack Analyzer에서 시작된 핵심 위협 분석 기능을 Enterprise Security 안에서 바로 쓸 수 있게 한 것으로, Premier 에디션에서 제공됩니다. ☑️ 피싱 조사가 SOC의 시간을 소모하는 구조피싱 공격은 악성 링크가 그대로 노출되는 형태에서 벗어났습니다. 조사 난도를 높이는 방식은 크게 세 가지입니다.리다이렉트 체인 뒤에 최종 목적지를 숨기는 방식이 있습니다. QR 코드를 사용해 사용자를 원본 이메일 밖의 경로로 유도하는 방식도 있습니다. 이 유형은 기존 이메일 게이트웨이를 우회하는 경우가 많습니다. 크리덴셜 탈취 페이지를 CAPTCHA 게이트 뒤에 배치하는 방식도 사용됩니다. 수동 분석을 어렵게 만들어 방어 측의 대응 속도를 늦추려는 의도입니다.처음에는 간단해 보이던 메일 한 건이 여러 도구에 흩어진 맥락을 모아야 하는 조사로 이어지는 이유입니다.여기에 분석 도구의 한계가 더해집니다. 레거시 분석 도구는 분석가가 판단에 사용할 만한 신호를 충분히 제공하지 못하는 경우가 있어, 다음과 같은 질문에 답하기 위해 수동 검증에 시간을 쓰게 됩니다.- 이 메시지가 알려진 브랜드를 사칭하고 있는가- 해당 URL이 의심스러운 곳으로 연결되는가- 에스컬레이션할 근거가 충분한가, 아니면 노이즈인가보안 팀은 대량의 신고 메일과 중복, 오탐을 함께 처리합니다. 모든 의심 메일에 같은 수준의 수작업이 필요하다면 SOC의 시간은 실제로 중요한 위협이 아닌 곳에 쓰이게 됩니다. ☑️ Automated Threat Analysis가 피싱 조사를 처리하는 방식Automated Threat Analysis는 고정확도 피싱 분석을 기존 보안 워크플로 안으로 가져오는 방식으로 설계됐습니다. 동작은 피싱 위협 가시성 확보, 일관된 조사 수행, 종단 간 자동화 워크플로 세 가지로 나뉩니다.신고된 피싱 메일을 Analyst Queue에서 바로 확인Automated Threat Analysis는 신고된 피싱 이메일을 Enterprise Security의 Analyst Queue에 직접 표시하고, 조사에 필요한 컨텍스트를 한곳에 모읍니다. 분석가는 보안 이벤트가 실제 위협인지 선별하고 유형별로 분류해 조사를 진행하던 환경에서 그대로 피싱 공격 체인을 분해할 수 있습니다. 공격 체인이 Enterprise Security 안에서 자동으로 분해되므로 위협의 범위와 심각도를 더 적은 수작업으로 파악할 수 있습니다.이 방식은 이메일을 둘러싼 보안 맥락을 유지합니다. 영향을 받은 사용자, 연관된 시스템, 해당 엔티티와 연결된 다른 활동, 이미 진행 중인 조사 내용을 함께 확인할 수 있기 때문입니다. 그 결과 숙련된 분석가의 도구 전환 작업이 줄어들고, 경험이 적은 분석가도 따라가고 신뢰하기 쉬운 워크플로가 만들어지며, SOC 전체의 피싱 조사 속도가 빨라집니다. 판정과 사칭 브랜드까지 자동 추출되는 조사 근거컨텍스트가 작업 흐름 안에 있는 것만으로는 충분하지 않고, 실제로 판단에 쓸 수 있는 수준이어야 합니다. Automated Threat Analysis는 앞의 질문에 인라인으로 답할 수 있도록 판정(Verdict)과 신뢰도(Confidence), 시스템 태그, 피싱 킷 패밀리, 사칭된 브랜드, 자동 추출된 콘텐츠. 이메일 스크린샷, 임베디드 URL, QR 코드, URL과 QR 코드가 최종 목적지까지 연결되는 경로를 보여주는 리소스 체인 등과 같은  근거를 제공합니다.이메일 스크린샷 캡처는 사칭과 시각적 기만을 검증하는 또 하나의 빠른 수단입니다. 텍스트 기반 지표만으로 판단하기 어려운 브랜드 사칭 유형을 Enterprise Security 안에서 바로 확인할 수 있습니다.이렇게 근거를 자동으로 추출해 보여주면 분석가는 지금 보고 있는 것이 무엇인지, 왜 의심스러운지, 공격자가 무엇을 노리는지를 빠르게 파악할 수 있습니다. 분석가의 주 작업 공간 안에서 위협 컨텍스트가 제공되므로 조사가 간소화되고, 신뢰할 수 있는 결과를 바탕으로 대응 시간을 단축할 수 있습니다. 선별 속도와 에스컬레이션 판단, SOC 전반의 판단 신뢰도가 함께 개선됩니다. 리스크 점수 기반 우선순위화와 대응 자동화 연계Automated Threat Analysis는 0에서 100 사이의 리스크 점수를 제공하며 점수가 높을수록 위험도가 높다는 의미입니다. 점수가 높은 이메일은 실제 위협일 가능성이 있는 항목으로 우선 처리 대상이 됩니다.이 기능은 저위험 항목을 조기에 걸러내고 강한 신호를 먼저 노출시켜 불필요한 조사 작업을 줄입니다. 개별 조사 속도만 빨라지는 것이 아니라 SOC가 큐 전체에 시간을 배분하는 방식이 달라집니다.우선순위가 정리된 분석 결과는 대응 단계로 이어집니다. Automated Threat Analysis를 Enterprise Security의 네이티브 SOAR 및 AI 기능과 함께 활용하면 지능형 자동화를 구성하고 종단 간 워크플로를 운영할 수 있습니다. ☑️ Automated Threat Analysis 주요 특징지금까지 살펴본 조사 흐름은 Automated Threat Analysis가 기본 기능으로 제공하는 분석 요소 위에서 동작합니다. Automated Threat Analysis는 피싱 공격 체인을 분해하고 자동화된 피싱 포렌식 결과를 분석가의 주 작업 공간에 전달합니다. 도구 전환과 수동 조사 작업을 없애 SOC가 피싱 위협을 더 빠르고 정확하게, 신뢰할 수 있는 결과를 바탕으로 조사하고 대응하며 무력화하도록 지원하는 것이 이 기능의 역할입니다.특징은 세 가지로 정리됩니다.- 자동 공격 체인 분석: 공격 체인을 자동으로 분석해 최종 페이로드까지 도달합니다. 리다이렉트나 QR 코드처럼 중간 단계가 여러 번 이어지는 구조에서도 수작업을 줄이면서 악성 활동에 대한 종합적인 가시성을 확보할 수 있습니다.- 실행 가능한 위협 요약: 위협 점수와 분석된 리소스를 포함한 분석 결과 개요를 제공합니다. 개별 지표를 하나씩 확인하기 전에 심각도와 공격 의도를 먼저 평가할 수 있습니다.- 상세 위협 포렌식: 분석 과정에서 악성 콘텐츠를 추출하고 트리거된 탐지 내용을 상세히 기록합니다. 초기 선별을 마친 뒤 더 깊은 조사가 필요한 사건에서 활용할 수 있는 정보입니다. ☑️ Splunk Enterprise Security 구성 요소와 에디션Splunk Enterprise Security는 위협 탐지, 조사, 대응(TDIR)을 하나로 묶은 플랫폼으로 에이전틱 AI와 SOAR, UEBA, SIEM이 통합되어 있습니다. Automated Threat Analysis가 도구 전환 없이 조사를 이어갈 수 있는 것도 이 플랫폼 위에서 동작하기 때문입니다.Enterprise Security가 제공하는 주요 구성은 다음과 같습니다.- SIEM: 도메인, 클라우드, 디바이스를 가리지 않고 데이터를 관리하고 검색, 분석합니다. AI 기반 탐지와 알림 우선순위화로 SOC 팀이 정탐에 집중하도록 지원합니다.- 리스크 기반 알림(RBA): 고정확도 위협 탐지로 알림량을 최대 90%까지 줄입니다. 정탐률을 높여 중요한 위협에 집중할 수 있게 합니다.- SOAR: 보안 워크플로를 자동화해 수작업과 알림 피로, 대응 시간을 줄입니다.- UEBA: 머신러닝과 행동 기반 이상 탐지로 계정 오남용, 크리덴셜 탈취, 측면 이동 같은 내부자 위협과 고도화된 위협을 조기에 식별합니다.- Detection Studio: 탐지 계획, 개발, 테스트, 배포, 모니터링에 이르는 라이프사이클을 제공하며 MITRE ATT&CK 프레임워크 기준 커버리지를 측정합니다. AWS 클라우드 환경에서 제공됩니다.- Exposure Analytics: 자산과 사용자를 지속적으로 식별하고 보안 이벤트에 상세 컨텍스트를 더해 리스크 우선순위화를 지원합니다.- Threat Intelligence: 시스코 탈로스(Cisco Talos) 위협 인텔리전스를 추가 비용 없이 활용할 수 있습니다.- AI Assistant: 자연어 질의, 가이드 워크플로, 요약, 자동 리포트를 제공합니다.- Federated Search와 Federated Analytics: 데이터 위치에 구애받지 않는 검색과 분석을 지원합니다.Enterprise Security는 Essentials와 Premier 두 가지 에디션으로 제공되며, Automated Threat Analysis는 Premier 에디션에 포함됩니다.기능Essentials EditionPremier EditionSIEM포함포함Threat Intelligence포함포함Detection Studio포함포함Exposure Analytics포함포함SOAR미포함포함UEBA미포함포함Automated Threat Analysis미포함포함 ☑️ Splunk Attack Analyzer와 Automated Threat Analysis의 관계Splunk Attack Analyzer는 멀웨어와 피싱 분석에 특화된 독립형 솔루션입니다. Automated Threat Analysis는 Premier 에디션에 직접 내장된 네이티브 기능으로, Splunk Attack Analyzer에서 시작된 다수의 핵심 위협 분석 기능을 Enterprise Security 안으로 가져온 형태입니다. 향후 릴리스에서 추가 기능 개선이 예정되어 있습니다. ☑️ 자주 묻는 질문Automated Threat Analysis는 무엇인가요?Automated Threat Analysis는 피싱 공격 체인을 자동으로 분석해 포렌식 인사이트와 위협 컨텍스트를 분석가의 주 작업 공간에 전달하는 Splunk Enterprise Security Premier 에디션의 내장 기능입니다. 분석가는 Enterprise Security를 벗어나지 않고 피싱 위협을 선별하고 조사할 수 있습니다.QR 코드 피싱(퀴싱)도 분석할 수 있나요?가능합니다. Automated Threat Analysis는 OCR과 이미지 분석을 사용해 QR 코드를 자동으로 디코딩하고 내장된 URL을 최종 목적지까지 추적합니다. 기존 이메일 게이트웨이를 우회하는 경우가 많은 퀴싱 시도를 Enterprise Security 환경 안에서 분석하고 선별할 수 있습니다.어떤 에디션에서 사용할 수 있나요?Automated Threat Analysis는 Splunk Enterprise Security Premier 에디션에서 제공됩니다. Essentials 에디션에는 포함되지 않으며, SOAR와 UEBA도 Premier 에디션 기능입니다.Splunk Attack Analyzer와 어떻게 다른가요?Splunk Attack Analyzer는 멀웨어와 피싱 분석에 특화된 독립형 솔루션이고, Automated Threat Analysis는 Premier 에디션에 내장된 네이티브 기능입니다. Splunk Attack Analyzer에서 시작된 핵심 위협 분석 기능을 Enterprise Security 안으로 가져온 형태이며, 추가 기능 개선이 예정되어 있습니다.피싱 대응 시간(MTTR) 단축에 어떻게 기여하나요?여러 도구를 오가며 수행하던 수작업을 줄이는 방식으로 기여합니다. SOC가 이미 탐지, 조사, 대응 워크플로를 운영하는 작업 공간에서 고정확도 피싱 분석이 이루어지므로 선별부터 대응까지 걸리는 시간을 줄일 수 있습니다. ☑️ 마무리피싱 공격이 리다이렉트 체인과 QR 코드, CAPTCHA 게이트를 활용하는 방향으로 바뀐 만큼 조사 방식도 함께 바뀌어야 합니다. Automated Threat Analysis는 피싱 공격 체인 분석을 Splunk Enterprise Security 안에서 처리해 도구 전환을 줄이고, 판정과 사칭 브랜드, 리소스 체인 같은 근거를 분석가에게 직접 제공하며, 리스크 점수를 기준으로 처리 순서를 나누고 대응 자동화까지 연결할 수 있도록 지원합니다.클라우드네트웍스는 Splunk 전담 조직과 축적된 구축 경험을 바탕으로 도입 검토부터 운영까지 지원하고 있습니다. Enterprise Security 에디션 구성 검토, 피싱 대응 프로세스 설계, SOAR 연계 등 고객 환경에 맞는 방안이 필요하시면 아래 링크를 통해 문의해 주시기 바랍니다. ▶ 스플렁크(Splunk) 제품보기 [출처 : Splunk, "Automated Threat Analysis: Centralize and Accelerate Phishing Investigations in Splunk Enterprise Security", https://www.splunk.com/en_us/blog/security/centralize-and-accelerate-phishing-investigations-in-splunk-enterprise-security.html, Splunk, "Automated Threat Analysis", https://www.splunk.com/en_us/products/automated-threat-analysis.html, Splunk, "Splunk Enterprise Security", https://www.splunk.com/en_us/products/enterprise-security.html]

기업의 AI 도입 속도는 보안 통제 체계가 따라잡는 속도보다 빠릅니다. 생성형 AI, LLM, 자율 에이전트가 업무 환경 곳곳에 배치되는 동안, 보안팀이 해당 자산을 목록화하거나 승인 절차에 올리는 작업은 뒤처지는 경우가 많습니다.이 격차에서 나타나는 대표적인 현상이 섀도우 AI(Shadow AI)입니다. IBM이 2025년 발표한 Cost of a Data Breach Report에 따르면 조사 대상 조직의 63%는 AI 거버넌스 정책을 갖추고 있지 않았고, 20%는 섀도우 AI와 관련된 침해를 경험했습니다. 사용 자체를 막지 못하는 상황에서 사용 현황조차 파악되지 않는 구간이 존재한다는 의미입니다. 동시에 이사회, 감사인, 고객사는 AI 사용에 대한 명확한 정책과 통제 근거를 요구하기 시작했습니다. 그런데 대부분의 조직은 스프레드시트, 설문지, 수작업으로 모은 자료로 이 요구에 대응하고 있습니다. 이 지점에서 AI 거버넌스는 정책의 문제가 아니라 증거의 문제로 성격이 바뀝니다.이 글에서는 퀄리스(Qualys)가 공개한 AI 거버넌스 증거 공백에 대한 분석과 Qualys TotalAI가 제시하는 접근 방식을 정리합니다. ☑️ 섀도우 AI(Shadow AI)란 무엇인가섀도우 AI는 IT나 보안 조직의 감독 없이 임직원이 도입해 사용하는 미승인 AI 도구를 뜻합니다. IBM은 Cost of a Data Breach Report 2025에서 섀도우 AI를 이와 같이 정의하며, 이를 기술적 문제이자 조직 문화의 문제로 함께 설명합니다. 업무 효율을 높이라는 압박 속에서 임직원이 지침 없이 AI 도구를 사용하다가 고객 PII나 회사 지식재산을 업로드하면서 보안 절차를 우회하게 된다는 것입니다.퀄리스는 여기에 더해 탐지 대상 범위를 SaaS 코파일럿, 브라우저 플러그인, AI 에이전트, MCP 서버, 코드 저장소, 컨테이너, GPU 환경까지로 제시합니다. 임직원 단위의 AI 사용과 개발 조직의 AI 자산이 서로 다른 경로로 발생하기 때문에, 두 영역을 하나의 인벤토리로 묶지 못하면 실제 사용 현황과 관리 대상 목록 사이에 차이가 남습니다. ☑️ AI 거버넌스가 증거의 문제가 된 이유퀄리스는 AI 거버넌스의 핵심 난제를 증거 공백(Evidence Gap)으로 정의합니다. 정책 문서, 벤더 설문지, 리스크 레지스터는 조직이 무엇을 하기로 했는지는 보여주지만, AI 시스템이 실제로 안전하게 동작하고 있다는 사실을 증명하지는 못한다는 것입니다.원문은 보안팀이 이해관계자별로 거의 동일한 질문에 반복해서 답하느라 상당한 시간을 쓰고 있다고 지적합니다.- AI 자산 인벤토리를 유지하고 있습니까- 모델을 어떤 방식으로 테스트합니까- AI 에이전트가 접근할 수 있는 범위는 어디까지입니까이 부담은 특정 조직에 집중되지 않고 역할별로 분산됩니다. 컴플라이언스와 GRC 담당자는 벤더 설문과 내부 감사를 병행하고, AppSec과 DevOps 조직은 CI/CD 파이프라인에 AI 점검 항목을 넣는 방법을 찾습니다. 클라우드와 아이덴티티 팀은 AI 관련 권한을 매핑하고, CISO와 리스크 담당 임원은 이 모든 내용을 이사회 보고 수준의 언어로 다시 정리해야 합니다. ☑️ 섀도우 AI가 만드는 리스크의 실제 크기섀도우 AI는 비용으로 측정되는 리스크입니다. IBM Cost of a Data Breach Report 2025 기준으로 섀도우 AI 사용 수준이 높은 조직은 섀도우 AI가 없거나 낮은 조직 대비 평균 67만 달러 높은 침해 비용을 기록했습니다. 같은 보고서에서 글로벌 평균 침해 비용은 444만 달러였습니다.노출되는 데이터의 성격도 다릅니다. 섀도우 AI가 관련된 침해에서는 고객 PII가 유출된 비율이 65%로 글로벌 평균 53%보다 높았고, 지식재산이 유출된 비율은 40%로 글로벌 평균 33%보다 높았습니다.조직 자체의 AI 자산도 안전하지 않습니다. 같은 보고서에서 AI 모델 또는 AI 애플리케이션 관련 침해를 보고한 조직은 13%였으며, 이 중 97%는 적절한 AI 접근 통제를 갖추지 못한 것으로 나타났습니다.모델 자체의 취약성도 확인됩니다. 2024년 11월 IBM 자료 기준으로 생성형 AI 탈옥 시도의 약 20%가 성공했고, 성공한 공격의 경우 공격자가 평균 42초와 5회의 상호작용을 필요로 했습니다. 성공한 공격 중 90%는 데이터 유출로 이어졌습니다.공격 시도 자체도 늘고 있습니다. OWASP GenAI Security Project가 2026년 6월 발표한 State of Agentic AI Security and Governance v2.01은 프롬프트 인젝션 시도가 전년 대비 340% 증가했으며, 프롬프트 인젝션이 에이전틱 AI 장애의 주된 원인으로 유지되고 있다고 밝혔습니다.노출된 정보가 충분히 민감하고 해당 사건이 중요하다고 판단되는 경우, 승인되지 않은 AI 사용이 SEC 공시 의무를 촉발할 수 있다는 점도 퀄리스가 지적하는 부분입니다. ☑️ 규제 환경은 증거를 요구하는 방향으로 움직입니다각국 규제 기관은 AI에 대한 리스크 관리와 실증 가능한 통제를 요구하고 있습니다.EU AI Act(Regulation (EU) 2024/1689)는 고위험(high-risk) AI 시스템에 대해 리스크 관리, 로깅, 기술 문서화, 인적 감독, 사이버보안 조치를 요구합니다. 과징금은 위반 유형에 따라 차등 적용되며, 금지된 AI 관행 위반은 최대 3,500만 유로 또는 글로벌 연간 매출액의 7%, 고위험 시스템 관련 의무를 포함한 그 밖의 위반은 최대 1,500만 유로 또는 3%까지 부과될 수 있습니다. 다만 EU AI Act는 조항별로 적용 시점이 나뉘는 단계적 적용 구조이며, 2026년 들어 일부 의무의 적용 시점 조정이 이루어졌습니다. 실제 대응 일정은 작성 시점 기준 최신 공식 자료로 확인이 필요합니다.미국에서는 NIST의 AI 리스크 관리 프레임워크(AI RMF)가 신뢰할 수 있는 AI의 사실상 기준선으로 자리 잡고 있으며, 캘리포니아와 뉴욕 등은 주 단위 AI 법률을 NIST 가이드라인과 연결하고 있습니다. 이 외에도 OWASP의 LLM 및 MCP 대상 Top 10, MITRE ATLAS, ISO/IEC 42001, 싱가포르 AI 가이드라인, CERT-In 등 참조 프레임워크가 늘고 있습니다.국내에서는 「인공지능 발전과 신뢰 기반 조성 등에 관한 기본법」이 2026년 1월 22일 시행되었습니다. 이 법은 고영향 인공지능과 생성형 인공지능을 중심으로 투명성 및 안전성 확보 의무를 규정하고 있습니다.이 규제들이 공통적으로 요구하는 것은 리스크 관리와 증거입니다. 퀄리스가 제시하는 핵심 질문은 하나로 정리됩니다. 우리 AI가 안전하다는 사실을 어떻게 아는가.여기에 답하려면 IT 보안과 동일한 기본기가 필요합니다. 인벤토리, 스캐닝, 조치, 사고 대응이 있어야 하고, 그 통제가 실제로 동작하고 있다는 지속적인 기술적 증거가 뒷받침되어야 합니다. 정책 문서만으로는 충분하지 않습니다. ☑️ 기존 보안 도구로는 AI 리스크를 증명하기 어려운 이유기존 보안 도구는 인프라를 스캔하고 데이터 이동을 모니터링할 수 있지만, 모델과 에이전트가 어떻게 행동하는지는 보지 못합니다. 패치가 모두 적용된 환경에서도 정교하게 설계된 프롬프트 하나로 민감 정보가 노출될 수 있으며, 이 경우 인프라 측면에서는 뚜렷한 실패 징후가 남지 않습니다. 특정 시점을 촬영하는 스냅샷 방식의 평가는 AI의 런타임 동작에 대해 맹점을 갖습니다.AI 리스크는 프롬프트, 모델 응답, 에이전트 행위, 과도한 권한을 통해 런타임에 드러납니다. 코드에서 클라우드, 브라우저까지 이어지는 가시성이 없으면 조직은 다음과 같은 기본적인 질문에도 답하기 어렵습니다.- AI는 정확히 어디에서 실행되고 있습니까- 어떤 모델이 정보를 유출하거나 조작될 수 있습니까- 우리 에이전트는 무엇을 할 수 있습니까- 우리의 통제가 실제로 작동했다는 것을 증명할 수 있습니까개별 도구 카테고리는 AI 라이프사이클 전체를 포괄하지 못합니다. API 스캐너는 알려진 모델은 테스트하지만 섀도우 AI는 찾지 못합니다. EDR과 CNAPP 플랫폼은 인프라를 평가하지만 추론 동작은 다루지 않습니다. CI/CD 도구는 코드 이슈를 찾지만 런타임 안전성을 강제하지는 못합니다.퀄리스는 이 상황의 본질을 그라운드 트루스(ground truth)의 부재로 설명합니다. 컴플라이언스 프레임워크는 무엇을 해야 하는지는 알려주지만, 그것을 어떻게 증명할지는 알려주지 않는다는 것입니다. ☑️ Qualys TotalAI가 제시하는 AI 거버넌스 4개 축Qualys TotalAI는 퀄리스의 Enterprise TruRisk Platform 위에 구축된 코드부터 런타임까지 아우르는 AI 보안 및 거버넌스 솔루션으로, 네 가지 구성 요소를 하나의 워크플로로 연결합니다. 1. 발견(Discover): AI 자산 인벤토리 확보거버넌스는 AI가 어디에 존재하는지 정확히 아는 데서 시작합니다.TotalAI는 클라우드 서비스, GPU, 컨테이너, 코드 저장소, SaaS 코파일럿, 브라우저 플러그인, AI 에이전트, MCP 서버 전반에서 승인된 AI와 섀도우 AI를 지속적으로 탐지합니다. 모델, 프레임워크, 워크로드를 식별한 뒤 각 자산을 소유자, 운영 컨텍스트, 노출 수준, 핵심 시스템에 대한 접근 권한과 매핑합니다.퀄리스는 이 과정이 정적인 스프레드시트와 자가 신고 기반 목록을 실시간 감사 가능한 거버넌스 기준선으로 대체한다고 설명합니다. 무엇이 돌아가고 있는지, 어디에서 돌아가는지, 누가 소유하는지, 승인된 자산인지가 하나의 인벤토리에 정리되면 보안팀과 감사인이 필요로 하는 근거가 확보됩니다. 2. 평가: 포스처, 행위, 런타임의 3단 점검TotalAI는 취약점 관리와 AI 전용 테스트, 실시간 모니터링을 결합해 AI 리스크를 평가하며, 각 발견 항목에 대해 포렌식 증거와 심각도 등급을 제공합니다. 평가는 세 가지 층위로 구성됩니다.포스처 영역에서는 무엇이 노출되고 잘못 설정되었는지를 확인합니다. 실패한 보안 및 거버넌스 통제, 클라우드 오구성, 취약한 AI 인프라, 과도한 접근 권한, 노출된 모델 또는 MCP 엔드포인트, 누락된 안전장치를 식별합니다. AI SaaS 영역에서는 지원 대상 AI SaaS의 설정, 사용자, 그룹, 접근 권한을 평가하면서 승인된 사용과 섀도우 AI 사용을 구분합니다. AI 코드 보안 영역에서는 배포 전 단계에서 노출된 시크릿, 취약한 의존성, 안전하지 않은 AI 패턴, 취약한 Cedar 정책, 저장소와 CI/CD 파이프라인의 오구성을 탐지합니다.행위 영역에서는 AI가 조작될 수 있는지를 실제로 시험합니다. LLM 대상 적대적 테스트를 통해 프롬프트 인젝션, 탈옥, 민감 정보 노출, 환각, 안전하지 않은 출력, 다국어 및 인코딩 공격, 서비스 거부, 멀티모달 조작을 점검합니다. MCP 서버에 대해서는 툴 포이즈닝, 인자 인젝션, SSRF, DNS 리바인딩, 러그풀 공격, 안전하지 않은 파일 접근, 스푸핑, 명령 실행, 자격 증명 노출을 직접 스캔합니다. 각 결과에는 프롬프트, 응답, 심각도, 통과 및 실패 여부, 성공한 탈옥 사례와 기술적 근거가 함께 기록됩니다.런타임 영역에서는 승인 이후 AI가 실제로 무엇을 하는지 확인합니다. 코드, Cedar 정책, 워크로드, 런타임, 행위를 연결해 무엇이 만들어졌고 배포되었으며 허용되었고 실행되었는지를 파악하며, 커널 수준 eBPF 계측을 통해 AI 워크로드가 서버에서 실제로 실행하는 동작을 확인합니다. 브라우저 플러그인 텔레메트리와 SaaS 커넥터를 결합해 임직원의 승인 및 미승인 AI 사용, 위험한 설정, 프롬프트와 업로드를 통한 민감 데이터 이동을 파악하고, 승인 이후의 포스처 드리프트와 비정상적인 모델 또는 MCP 활동을 탐지합니다.앞서 살펴본 IBM 조사에서 섀도우 AI 관련 침해가 고객 PII와 지식재산 유출로 이어지는 비율이 평균보다 높게 나타난 점을 고려하면, 프롬프트와 업로드를 통한 데이터 이동을 확인하는 브라우저 및 SaaS 계층의 가시성은 섀도우 AI 대응에서 비중이 큰 영역입니다. 3. 조치(Remediate): 우선순위 기반 조치 가이드발견 항목만으로는 리스크가 줄지 않습니다. TotalAI는 모든 AI 이슈를 Qualys TruRisk 엔진으로 점수화하며, 이때 취약점 심각도, 데이터 민감도, 자산 중요도, 비즈니스 컨텍스트, 모델 행위, 런타임 증거를 함께 반영합니다. 퀄리스는 고객 PII에 접근 가능한 모델에서 발생한 프롬프트 인젝션이 최상위 우선순위를 받는 사례를 예시로 제시합니다.각 이슈는 성격에 따라 클라우드, DevOps, AppSec, 아이덴티티 및 GRC 등 담당 조직으로 라우팅됩니다. 행위 기반 통제가 실패한 경우에는 가드레일, 프롬프트, 검색 로직, 정책, 애플리케이션 설계에 대한 변경을 권고하며, 공격 증거를 보존한 상태에서 플랫폼별 가드레일과 필요한 설정을 생성하고 사람의 승인 절차를 유지합니다.조치가 적용된 뒤에는 재테스트를 수행하고 결과를 기록합니다. 퀄리스는 이 과정이 리스크가 실제로 줄었다는 방어 가능한 증거를 만들고, 탐지에서 조치, 검증, 문서화로 이어지는 루프를 닫는다고 설명합니다. 4. 거버넌스: 감사 대응이 가능한 리포팅TotalAI는 AI 인벤토리, 포스처 스캔 결과, 테스트 로그, 조치 상태를 통합 대시보드와 리포트로 정리합니다. 이 산출물은 감사인과 경영진이 실제로 묻는 질문, 즉 우리가 보유한 AI 시스템은 무엇인지, 그중 어떤 것이 컴플라이언스를 충족하는지, 남아 있는 이슈는 무엇인지에 대응합니다.리포트는 NIST AI RMF, EU AI Act 요구사항, FISMA, CMMC 2.0, OWASP Top 10 for LLM, MITRE ATLAS 등 프레임워크에 매핑된 형태로 내보낼 수 있습니다. 고객사 보안 설문, 벤더 평가, 이사회 보고 자료, 감사 제출물에 반복적으로 활용할 수 있는 형태입니다.연방 기관 및 계약업체를 위해 TotalAI는 FedRAMP Moderate 승인(Authorized)을 받았으며, 승인된 경계 내에서 추가 ATO 절차 없이 배포할 수 있습니다.또한 TotalAI는 클라우드, 취약점, 컨테이너 리스크를 이미 처리하고 있는 단일 플랫폼 위에서 동작하기 때문에, AI 리스크를 기존 보안 프로그램의 또 다른 축으로 다룰 수 있습니다. 별도 인프라나 에이전트를 추가하지 않고 기존 워크플로로 결과가 유입되는 구조입니다. ☑️ 도입을 검토할 때 확인할 포인트지금까지 정리한 내용을 도입 검토 관점으로 옮기면 다음과 같은 항목을 확인해 볼 수 있습니다.첫째, AI 자산 인벤토리가 자가 신고가 아닌 자동 탐지 기반으로 유지되고 있는지 확인합니다. 섀도우 AI는 승인 절차를 거치지 않는 사용을 뜻하므로 신고 기반 목록으로는 파악 범위에 한계가 있습니다.둘째, 인프라 취약점 점검과 모델 행위 테스트가 서로 다른 도구와 보고 체계로 분리되어 있는지 확인합니다. 두 영역이 분리되어 있으면 통합된 증거를 만들기 어렵습니다.셋째, 브라우저와 SaaS 계층의 AI 사용 현황을 파악할 수단이 있는지 확인합니다. 임직원 단위의 생성형 AI 사용은 개발 조직의 AI 자산과 다른 경로로 발생합니다.넷째, 조치 이후 재검증과 기록이 자동으로 남는지 확인합니다. 감사 대응에서 요구되는 것은 조치 계획이 아니라 조치가 완료되었고 검증되었다는 증거입니다.다섯째, 산출되는 리포트가 조직이 대응해야 할 프레임워크에 매핑되는지 확인합니다. 국내 기업의 경우 인공지능 기본법 대응과 글로벌 규제 대응을 함께 고려해야 하는 경우가 있습니다. ☑️ 자주 묻는 질문섀도우 AI(Shadow AI)란 무엇인가요?섀도우 AI는 IT나 보안 조직의 감독 없이 임직원이 도입해 사용하는 미승인 AI 도구를 의미합니다. IBM Cost of a Data Breach Report 2025 기준으로 조사 대상 조직의 20%가 섀도우 AI와 관련된 침해를 경험했으며, 섀도우 AI 사용 수준이 높은 조직은 그렇지 않은 조직 대비 평균 67만 달러 높은 침해 비용을 기록했습니다.AI 거버넌스 증거 공백이란 무엇인가요?AI 거버넌스 증거 공백은 조직이 AI 정책과 설문 답변은 갖추고 있지만, 모델과 에이전트, AI 워크로드가 운영 환경에서 실제로 안전하게 테스트되고 통제되고 있다는 지속적인 기술적 증거는 갖추지 못한 상태를 의미합니다.Qualys TotalAI는 별도의 에이전트나 인프라가 필요합니까?필요하지 않습니다. TotalAI는 기존 Qualys Cloud Agent와 클라우드 연동을 활용하며, 새로운 에이전트나 코드 수정, 추가 인프라 없이 사용할 수 있습니다.TotalAI는 어떤 규제와 프레임워크를 지원합니까?NIST AI RMF, EU AI Act, OWASP Top 10 for LLM, MITRE ATLAS, FISMA, CMMC 2.0 등 주요 요구사항에 매핑된 리포트를 생성합니다. 또한 FedRAMP Moderate 승인을 받았습니다. ☑️ 마무리섀도우 AI를 포함한 AI 자산이 어디에서 무엇을 하고 있는지 파악되지 않으면 AI 정책은 문서로만 남습니다. 이사회와 감사인, 규제 기관이 요구하는 것은 정책의 존재가 아니라 그 통제가 실제로 작동한다는 기술적 증거입니다. AI 자산을 찾아내고, 모델과 에이전트의 행위까지 평가하고, 조치 결과를 검증해 기록으로 남기는 과정이 하나로 이어져야 합니다.Qualys TotalAI는 발견, 평가, 조치, 거버넌스 리포팅을 하나의 플랫폼에서 연결해 이 과정을 지원합니다. 별도 인프라나 에이전트를 추가하지 않고 기존 Qualys 환경 위에서 운영할 수 있어, 우리 조직에 어떤 AI가 돌아가고 있는지 확인하는 단계부터 시작할 수 있습니다. 클라우드네트웍스는 Qualys 공 파트너로서 도입 검토부터 구축, 운영까지 지원합니다. 섀도우 AI 현황 파악과 AI 거버넌스 체계에 대한 문의사항은 클라우드네트웍스로 연락 부탁드립니다. ▶ 퀄리스(Qualys) 제품정보 [출처 : Qualys, "Operationalize AI Governance Across Shadow GenAI, MCP, and Agentic Workloads with Qualys TotalAI", IBM, "Cost of a Data Breach Report 2025", IBM, "AI jailbreak: Rooting out an evolving threat", OWASP GenAI Security Project, "State of Agentic AI Security and Governance v2.01", European Union, "Regulation (EU) 2024/1689 (EU AI Act)", 국가법령정보센터, "인공지능 발전과 신뢰 기반 조성 등에 관한 기본법"]

기업의 AI 도입은 실험 단계를 지나 프로덕션 환경으로 넘어가고 있습니다. 조직 안에서는 여러 LLM과 AI 에이전트, 그리고 최근에는 MCP(Model Context Protocol) 서버까지 빠르게 늘어나고 있습니다. 문제는 애플리케이션마다 인증, 비용 통제, 데이터 보호, 로깅을 제각기 구현하면 동일한 작업이 반복되고, 조직 전체의 AI 트래픽을 한눈에 파악하기 어려워진다는 점입니다.이런 배경에서 애플리케이션과 AI 모델 사이에 위치해 트래픽을 한 곳에서 연결하고 통제하는 계층이 필요해졌습니다. 이 역할을 담당하는 것이 AI 게이트웨이입니다. 이 글에서는 Kong AI Gateway가 무엇이고, 어떤 문제를 해결하며, 어떤 기능으로 LLM과 MCP, 에이전트 트래픽을 관리하는지 정리합니다. ☑️ Kong AI Gateway란 무엇인가Kong AI Gateway는 애플리케이션과 LLM·에이전트·MCP 서버 사이에 위치해 AI 트래픽의 라우팅, 인증, 비용 제어, 보안, 관측을 하나의 게이트웨이에서 처리하는 AI 연결·거버넌스 계층입니다. LLM 트래픽뿐 아니라 MCP 트래픽과 에이전트 간(A2A, Agent-to-Agent) 트래픽까지 동일한 게이트웨이로 통제한다는 점이 핵심입니다.Kong AI Gateway는 Kong API Gateway 위에 구축되어 있습니다. 그래서 인증/인가, 트래픽 제어, 요청 제한, 변환 등 기존 API 게이트웨이에서 사용하던 정책과 플러그인을 AI 트래픽에도 그대로 적용할 수 있습니다. Kong은 이 게이트웨이를 통해 개발자와 애플리케이션, 에이전트가 AI를 소비하는 방식을 접근 권한부터 데이터 유출, 토큰 사용량까지 관리하도록 설계했습니다. ☑️ AI 게이트웨이가 필요한 이유AI 게이트웨이가 없는 환경에서는 각 애플리케이션이 여러 LLM에 직접 연결되고, 보안·재시도·로깅·캐싱·프롬프트 관리 같은 공통 기능을 애플리케이션마다 따로 구현하게 됩니다. 그 결과 같은 기능이 중복 개발되고, 팀마다 거버넌스 수준이 달라지며, 조직 차원의 통합 가시성을 확보하기 어렵습니다. 또한 AI 환경에서는 통제해야 할 영역이 기존 API보다 넓어집니다. 고객 정보나 민감 데이터가 LLM으로 유입되는 것을 막아야 하고, 여러 프로바이더와 모델에 걸친 소비를 하나의 기준으로 관리해야 하며, 토큰 사용량과 비용을 지속적으로 확인해야 합니다.AI 게이트웨이는 이런 공통 관심사를 애플리케이션 코드에서 분리해 게이트웨이 계층으로 옮깁니다. 요청 라우팅, 인증, 인가, 요청 제한, 트래픽 모니터링 같은 기능을 중앙에서 처리함으로써 AI를 조직의 플랫폼이 제공하는 하나의 서비스처럼 다룰 수 있게 합니다. ☑️ Kong AI Gateway의 동작 방식Kong AI Gateway는 애플리케이션과 AI 모델 사이에서 프록시 역할을 합니다. 애플리케이션은 각 프로바이더에 직접 연결하는 대신 게이트웨이 주소로 요청을 보냅니다. 실제 코드 관점에서는 LLM 호출부의 엔드포인트(base_url)를 게이트웨이 주소로 바꾸는 정도의 변경으로 연동이 가능하며, 개별 프로바이더 인증 키를 애플리케이션에 직접 노출하지 않아도 됩니다. Kong은 이러한 로우코드 통합을 통해 GenAI 프로젝트를 프로덕션 수준으로 전환할 수 있도록 지원합니다.구조적으로 Kong Enterprise는 관리 기능을 담당하는 컨트롤 플레인(Control Plane)과 실제 트래픽을 처리하는 데이터 플레인(Data Plane)으로 구성됩니다. AI Gateway와 MCP Gateway는 데이터 플레인을 구성하는 요소로, API Gateway, Event Gateway, Ingress Controller, Service Mesh와 함께 동일한 플랫폼 위에서 동작합니다.게이트웨이를 지나는 AI 요청은 단계별 플러그인 파이프라인을 거칩니다. 소개 자료 기준으로 이 파이프라인은 보안 및 접근 제어(Security & Access Control), 비용 제어 및 캐싱(Cost Control & Caching), 콘텐츠 안전성(Content Safety), 컨텍스트 관리(Context Management), LLM 프록시(LLM Proxying), 응답 콘텐츠 안전성(Response Content Safety), 로깅 및 분석(Logging & Analytics)의 순서로 구성됩니다. 각 단계에서 필요한 정책만 선택해 적용하는 방식입니다. ☑️ Kong AI Gateway 주요 기능멀티 LLM 지원과 프로바이더 전환Kong AI Gateway는 통합 API 인터페이스를 통해 여러 AI 프로바이더를 함께 사용할 수 있습니다. 설정 전환만으로 프로바이더를 교체할 수 있어, 새로운 활용 사례를 적용하거나 특정 프로바이더에 장애가 발생했을 때 다른 프로바이더로 전환해 가용성을 유지할 수 있습니다. 고객 환경에서는 이 기능이 특정 프로바이더 종속을 줄이고, 모델 교체나 이중화 구성을 애플리케이션 코드 변경 없이 게이트웨이 설정으로 처리할 수 있게 해 줍니다. LLM 정책과 보안 가드레일Kong AI Gateway는 LLM 트래픽에 여러 층위의 가드레일을 적용합니다. 대표적으로 개인정보(PII) 새니타이제이션은 개인정보, 비밀번호, 코드 등이 LLM으로 유입되는 것을 막아 데이터 유출과 컴플라이언스 리스크를 줄입니다. 3.10 버전 발표 자료 기준으로 이 기능은 20개 이상의 PII 유형과 12개 언어를 대상으로 하며, 설정에 따라 응답 단계에서 마스킹했던 원본 데이터를 최종 사용자에게 다시 제공하는 옵션도 지원합니다.시맨틱 프롬프트 가드(Semantic Prompt Guard)는 특정 주제에 대한 요청을 차단 규칙(Deny Rule)으로 관리합니다. 예를 들어 정치 관련 질문을 차단 대상으로 설정하면, 표현이 서로 달라도 의미상 해당 주제에 해당하는 요청을 인식해 차단합니다. 이를 통해 콘텐츠 검열과 기업 이미지 보존, 안전한 AI 사용 환경을 확보할 수 있습니다.이 밖에도 OpenID Connect, ACL(Access Control List), OPA(Open Policy Agent) 등 기존 Kong Gateway의 인증·접근 제어 정책을 AI 트래픽에 그대로 적용할 수 있습니다. 비용 제어와 성능 최적화Kong AI Gateway는 시맨틱 캐싱(Semantic Cache)을 제공합니다. 시맨틱 캐싱은 문장 표현이 달라도 의미가 유사한 프롬프트에 대해 이미 저장된 응답을 반환하는 방식으로, 반복되는 LLM 호출을 줄여 비용을 절감하고 응답 지연을 최소화합니다. 다양한 AI 임베딩 모델과 Vector DB(예: Redis, Postgre, Valkey 및 관리형 서비스) 연결 형식을 지원합니다.시맨틱 라우팅과 로드 밸런싱은 프롬프트 유형에 따라 특화된 모델로 요청을 분배합니다. 예를 들어 기술 지원 문의는 상대적으로 높은 성능의 모델로, 사내 규정·복지 문의는 경량 모델로 라우팅하는 식입니다. 이를 통해 프롬프트 유형별로 적합한 모델을 호출하고 모델 사용량과 비용을 최적화할 수 있습니다.또한 사용자, 모델, 기간을 기준으로 LLM 소비와 토큰 사용량에 대한 쿼터를 설정하고 이를 게이트웨이 레벨에서 적용할 수 있습니다. 이 데이터를 기반으로 LLM과 에이전트, MCP 사용량에 대한 쇼백(showback)과 차지백(chargeback) 체계를 구성하는 것도 가능합니다. AI 트래픽 관측 가능성Kong AI Gateway는 AI 트래픽에 대한 L7 관측 가능성을 제공합니다. AI 소비량, 툴 사용량, 토큰 소비, 응답 상태 코드, 프로바이더별·사용자별 사용량과 비용을 대시보드에서 확인할 수 있습니다. 이를 통해 비용을 모니터링하고 사용 패턴을 튜닝할 수 있으며, 로깅과 트레이싱을 활용해 AI 트래픽을 디버깅할 수 있습니다.관측 대시보드에서 확인할 수 있는 지표에는 모델별 사용량, 모델 제공자별 사용 비율, 응답 에러율, 요청자·사용자별 토큰 사용량과 비용 등이 포함됩니다. ☑️ 에이전트와 MCP 트래픽까지 확장하는 거버넌스Kong AI Gateway의 관리 범위는 LLM 트래픽에 그치지 않습니다. 동일한 게이트웨이로 MCP 서버 트래픽과 에이전트 간(A2A) 트래픽까지 통제합니다. MCP GatewayMCP는 에이전트/AI 애플리케이션을 LLM 및 도구와 통합하는 표준화된 방식을 제공합니다. 다만 MCP 표준 자체는 지속적으로 개발·변화하고 있고, 보안 이슈와 조직 배포 지침 등 해결해야 할 과제가 남아 있어 그 자체로 완결된 해결책은 아닙니다.Kong MCP Gateway는 이 지점을 보완합니다. Kong이 관리하는 기존 REST API를 MCP 도구와 서버로 매핑해 MCP화할 수 있고(MCP Proxy 플러그인), MCP 프로토콜의 표준 인가 방식인 OAuth 2.1을 지원합니다(MCP OAuth2 플러그인). 또한 유량 제한, 라우팅, 로드 밸런스, IP 제한, OPA 판정 등 기존 Kong Gateway의 트래픽 제어·보안 정책을 MCP 트래픽에 그대로 활용할 수 있습니다.프록시 모드는 용도에 따라 나뉩니다. 기존 MCP 서버로 요청을 라우팅하는 방식, REST API에 프로토콜 변환을 수행해 MCP 엔드포인트를 제공하는 방식, MCP 엔드포인트만 제공하는 방식, REST API에 대한 MCP/REST 프로토콜 변환을 수행하는 방식을 지원합니다. REST API를 MCP 기능에 매핑하면 MCP를 별도로 개발하지 않아도 되어 생산성이 높아지고, 인증을 위한 개별 토큰과 시크릿을 노출하지 않아도 됩니다. Agent Gateway (A2A)여러 에이전트가 협업하는 멀티 에이전트 환경에서는 에이전트 간 연결 경로마다 인증과 통제가 필요합니다. Kong Agent Gateway는 A2A 트래픽에 중앙 집중식 인증·인가(AuthN/Z), 요청 제한(Rate Limiting), 관측 가능성(Observability), 구조화 로깅(Structured Logging)을 적용합니다.구체적으로는 A2A 호출에 대한 페이로드, 지연 시간, 토큰 사용량, 오류를 포함한 상세 원격 측정 데이터를 수집해 병목을 파악하고, 승인되지 않은 에이전트 상호 작용을 방지하며, 발신자 정보와 호출된 기능·결과 등 모든 A2A RPC 호출에 대한 감사 추적 기록을 유지합니다. AI 데이터 경로 전체로의 확장AI 트래픽은 AI 네이티브 트래픽만으로 구성되지 않습니다. 에이전트는 조직의 API와 이벤트 데이터에서 컨텍스트를 소비합니다. Kong AI Gateway는 애플리케이션 계층, 인텔리전스 계층, 컨텍스트 계층을 하나의 플랫폼에서 관측하고 통제해, 엔터프라이즈 데이터와 이벤트, API를 에이전트가 사용할 수 있는 형태로 제공하도록 지원합니다. ☑️ 자주 묻는 질문Kong AI Gateway는 어떤 제품인가요?Kong AI Gateway는 애플리케이션과 LLM·MCP 서버·AI 에이전트 사이에 위치해 AI 트래픽의 라우팅, 인증, 보안, 비용 제어, 관측을 하나의 게이트웨이에서 처리하는 AI 연결·거버넌스 계층입니다. LLM, MCP, A2A 트래픽을 동일한 게이트웨이로 관리합니다.기존 애플리케이션 코드를 많이 바꿔야 하나요?LLM 호출부의 엔드포인트를 게이트웨이 주소로 변경하는 수준의 로우코드 통합으로 연동할 수 있습니다. 개별 프로바이더 인증 키를 애플리케이션에 직접 노출하지 않고 게이트웨이에서 관리할 수 있습니다.여러 LLM 프로바이더를 함께 사용할 수 있나요?가능합니다. 통합 API 인터페이스를 통해 여러 AI 프로바이더를 사용하고, 설정 전환만으로 프로바이더를 교체할 수 있습니다. 특정 프로바이더 장애 시 다른 프로바이더로 전환해 가용성을 유지할 수 있습니다.LLM 외에 MCP나 에이전트 트래픽도 관리할 수 있나요?Kong AI Gateway는 동일한 게이트웨이로 MCP 서버 트래픽과 에이전트 간(A2A) 트래픽을 관리합니다. MCP화, OAuth 2.1 인가, A2A 인증·관측·감사 로깅을 제공합니다.AI 비용은 어떻게 통제하나요?시맨틱 캐싱으로 반복 호출을 줄이고, 시맨틱 라우팅으로 프롬프트 유형별 적합한 모델을 호출하며, 사용자·모델·기간별 토큰 쿼터를 게이트웨이 레벨에서 적용합니다. 관측 대시보드에서 프로바이더별·사용자별 토큰 사용량과 비용을 확인할 수 있습니다. ☑️ 마무리Kong AI Gateway는 늘어나는 LLM과 MCP 서버, AI 에이전트 트래픽을 하나의 게이트웨이에서 연결하고 통제하도록 설계된 AI 연결·거버넌스 계층입니다. 애플리케이션마다 흩어져 있던 인증, 보안, 비용 제어, 관측을 게이트웨이로 옮겨, AI를 조직 플랫폼이 제공하는 하나의 서비스처럼 운영할 수 있게 합니다.클라우드네트웍스는 이러한 AI 게이트웨이 도입을 고객 환경에 맞춰 검토하고, 구축과 운영을 지원합니다. 멀티 LLM 연동, MCP·에이전트 트래픽 거버넌스, 토큰 비용 최적화, AI 트래픽 관측 등 어떤 지점에서 출발할지 함께 정리하고자 하신다면 아래로 문의해 주시기 바랍니다. ▶ Kong AI Gateway 자세히보기 [출처 : Kong, "Secure, Scalable AI Gateway for AI Connectivity", https://konghq.com/products/kong-ai-gateway, Kong, "Announcing Kong's New Open Source AI Gateway", https://konghq.com/blog/product-releases/announcing-kong-ai-gateway, Kong, "Kong AI Gateway Launches Next-Gen Capabilities to Enhance AI Governance, Help Reduce LLM Hallucinations and Provide Infrastructure for Agentic Workflows", https://konghq.com/company/press-room/press-release/kong-ai-gateway-launches-next-gen-capabilities-to-enhance-ai-governance-help-reduce-llm-hallucinations-and-provide-infrastructure-for-agentic-workflows]

LLM 애플리케이션은 배포 전에 검증을 마쳐도, 실제 사용자와 만나는 순간 새로운 위험에 노출됩니다. 탈옥 시도, 애플리케이션 악용, 유해한 응답이 대표적입니다. 실제로 여러 기업이 챗봇이 자동차를 1달러에 팔거나, 자사를 비판하는 글을 쓰거나, 부적절한 답변을 내놓아 곤란을 겪었습니다.​앞선 1편에서는 LLM 평가의 개념과 방법·지표를, 2편에서는 배포 전 데이터셋 구축과 CI/CD 평가를 다뤘습니다. 이번 편은 배포 이후의 평가입니다. 실시간으로 위험을 막는 프로덕션 가드레일, 실패를 다시 개발로 되먹여 시스템을 개선하는 자기 개선, 그리고 규제 환경에서 평가가 담당하는 거버넌스 역할을 정리합니다.​이 글은 어라이즈 AI(Arize AI)의 'The definitive guide to LLM evaluation' 중 배포 이후 단계에 해당하는 프로덕션(Production), 자기 개선(Self-Improving), 거버넌스를 바탕으로 한 시리즈의 마지막 편입니다. ☑️ 운영 단계 평가란 무엇인가운영 단계 평가는 배포된 애플리케이션을 실제 트래픽에서 보호하고 모니터링하며, 관찰된 실패를 개발 과정으로 되먹여 지속적으로 개선하고, 규제·감사에 필요한 증거를 남기는 과정입니다. 배포 전 평가가 회귀를 걸러내는 안전장치라면, 운영 단계 평가는 실제 환경에서 위험을 줄이고 품질을 유지하는 활동입니다.​프로덕션 평가는 실제 트레이스와 사용자 상호작용에서 실행됩니다. 사전 프로덕션 데이터셋으로는 포착하기 어려운 사용자 행동, 데이터, 도구 응답, 트래픽 구성, 실패 유형의 변화를 드러냅니다. ☑️ 프로덕션 가드레일가드레일은 실시간으로 위험한 사용자 입력을 잡거나 모델 출력을 검사해, 유해한 입력으로부터 애플리케이션을 보호하고 손상을 주는 출력이 사용자에게 도달하기 전에 차단하는 장치입니다. 탈옥 시도가 늘고 정교해질수록 견고한 가드레일 접근이 중요해집니다. 가드는 특정한 위험 유형에 특화됩니다. 입력 가드는 탈옥 시도 탐지·차단, 프롬프트 인젝션 방지, 모델에 도달하기 전 개인식별정보(PII) 제거 등에 쓰입니다. 출력 가드는 유해하거나 할루시네이션이 포함된 응답 제거, 경쟁사 제품 언급 제거, 응답의 관련성 확인, 부적절한 텍스트 제거 등에 쓰입니다.가드레일 구성은 균형이 중요합니다. 모든 안전장치를 다 넣으려 하면 오히려 역효과가 날 수 있습니다. 과도한 가드는 사용자의 원래 의도나 애플리케이션 출력의 가치를 훼손할 수 있으므로, 가장 중요한 가드부터 시작해 필요에 따라 신중히 확장하는 것이 권장됩니다. ☑️ 가드의 종류가드는 입력 검증·정제와 출력 모니터링·필터링으로 나뉩니다.입력 검증과 정제 입력 검증과 정제는 AI 안전의 첫 번째 방어선입니다. 구문·형식 점검은 입력이 기대한 형식과 구조를 따르는지 확인합니다. 예를 들어 RAG 검색기가 문서를 반환하지 못하거나 추출기가 잘못된 데이터를 가져올 때, 모델이 이 잘못된 요청을 처리할 준비가 되어 있는지를 점검해 오류를 예방합니다. 콘텐츠 필터링은 민감하거나 부적절한 내용을 모델에 도달하기 전에 제거합니다. 다만 과도한 필터링은 사용자의 원래 의도를 바꿀 수 있어 신중히 적용해야 하며, 대체로 입력보다 출력을 거르는 데 더 적합합니다. 탈옥 시도 탐지는 심각한 보안 사고를 막는 가드입니다. 공개된 탈옥 프롬프트 모음이 많고, 고도화된 모델도 이런 공개 공격의 최대 40%에서 실패할 수 있어, 변화하는 전략에 적응하는 임베딩 기반 가드가 권장됩니다.​출력 모니터링과 필터링출력 가드는 손상 방지와 성능 확보 두 범주로 나뉩니다. 손상 방지에는 시스템 프롬프트 보호(출력에 시스템 프롬프트 언어가 노출되는지 탐지), 부적절·유해 언어 탐지, 경쟁사 언급 필터링이 포함됩니다. 성능 확보에서는 실시간 가드와 오프라인 평가 사이에서 선택하게 됩니다. 실시간 가드는 레이턴시와 비용이 늘지만 즉각적인 개선을 주고, 오프라인 평가는 지연은 있으나 레이턴시 없이 파이프라인을 최적화합니다. 오프라인 평가로 시작하고 성능 가드는 꼭 필요할 때만 추가하는 것이 권장됩니다. 할루시네이션 방지 가드는 출력을 참조 텍스트와 비교해 검증하고, 크리틱 가드는 별도의 LLM으로 출력을 검토·개선한 뒤 사용자에게 전달합니다. ☑️ 동적 가드(Dynamic Guards)공격 벡터가 늘어나는 상황에서 가드를 수동으로 갱신하는 것은 지속하기 어렵습니다. 새로운 위협에 발맞추는 적응형 가드를 만드는 방법으로는 few-shot 프롬프팅과 임베딩 기반 가드가 있습니다. 정적 가드는 부적절한 언어처럼 미리 정의된 콘텐츠를 거르는 데 강하지만, 탈옥이나 프롬프트 인젝션 같은 정교한 공격에는 약합니다.​few-shot 프롬프팅은 최근 공격 사례를 가드의 프롬프트에 직접 넣어 유사 위협을 더 잘 인식하게 만드는 방식입니다. 임베딩 기반 가드는 사용자 입력의 임베딩을 알려진 공격 임베딩 데이터베이스와 비교해, 유사도가 기준을 넘으면 차단하는 더 정교한 방식입니다. 동적 가드는 강력하지만 계산 비용 증가, 레이턴시 상승, 공격 프롬프트 데이터베이스의 지속적 유지보수라는 고려사항이 따릅니다. ☑️ 자기 개선 평가(Self-improving Evaluation)자기 개선 평가는 모델이 테스트를 받는 데 그치지 않고 자신의 실패로부터 학습해 평가 방법을 스스로 개선하는 접근입니다. 시간이 지날수록 스스로를 정교화하는 적응형 평가 체계를 만들어, 더 정확한 성능 평가로 이어지게 하는 것이 목적입니다.오류로부터의 지속적 학습자기 개선 평가는 모델이 취약한 영역을 체계적으로 찾아내고 그 피드백으로 이후 평가를 조정하는 방식으로 작동합니다. 이를 통해 모델이 가장 어려워하는 태스크나 데이터셋을 식별하고, 더 어려운 예시나 엣지 케이스를 반영해 평가 기준·데이터셋을 조정하며, 성능에 따라 지표나 테스트 케이스를 갱신해 평가 기준을 지속적으로 높일 수 있습니다.​피드백 루프자기 개선 평가의 핵심은 피드백 루프입니다. 모델이 부진한 지점에 대한 피드백은 파인튜닝이나 재학습을 이끌어 더 효과적인 성능 개선으로 이어집니다. 피드백 루프를 평가 과정에 심으면 모델이 시간이 지날수록 견고해지며, 이는 변화하는 환경이나 진화하는 데이터셋을 만나는 모델에 특히 중요합니다.​평가 시스템을 개선하는 방법평가 시스템 개선은 대개 프롬프트 템플릿을 반복 개선하거나, few-shot 예시를 추가하거나, 평가 모델을 파인튜닝하는 방식으로 이뤄집니다. few-shot 프롬프팅 평가는 소수의 라벨 예시를 프롬프트에 넣어 적은 입력으로 모델이 얼마나 일반화하는지를 확인하며, 빠른 프로토타이핑과 일반화 능력 평가에 유용합니다. 예시는 다양성, 엣지 케이스, 일관된 Ground Truth를 갖추도록 선별합니다. 마지막 단계는 평가자 파인튜닝으로, 이전에 수집한 교정 데이터로 평가 모델을 조정합니다. 이는 더 작은 언어 모델로도 비슷한 성능을 유지하면서 레이턴시와 비용을 낮추게 하며, 교정 데이터가 쌓이면 평가자를 CI/CD 파이프라인에 연결해 정밀도를 지속적으로 높일 수 있습니다. ☑️ 규제·거버넌스 평가규제가 강하거나 영향이 큰 환경에서는 평가가 거버넌스를 위한 증거층 역할도 합니다. 애플리케이션이 무엇을 하도록 설계됐는지, 어떻게 테스트됐는지, 어떤 버전이 특정 출력을 냈는지, 어떤 데이터와 도구를 썼는지, 정책을 따랐는지, 배포 후 실패를 어떻게 탐지하는지를 보여줄 수 있어야 합니다. 다만 평가만으로 AI 시스템이 규제를 준수하게 되는 것은 아닙니다. 요구사항은 관할, 산업, 활용 사례, 시스템 역할, 위험 분류에 따라 달라지므로, 법무·리스크·보안·프라이버시·주제 전문가가 함께 필요한 통제와 증거를 정의해야 합니다. 거버넌스 관점의 평가 점검에는 정확성·성능, 견고성, 추적 가능성, 정책 준수, 프라이버시·데이터 유출, 사람의 감독·에스컬레이션, 릴리스 비교, 배포 후 모니터링이 포함됩니다.​예를 들어 EU AI 법(EU AI Act)은 위험 기반 프레임워크를 사용하며, 고위험 시스템에는 리스크 관리, 데이터 품질, 로깅, 문서화, 사람의 감독, 견고성, 사이버보안, 정확성 같은 의무가 따릅니다. 금융 분야의 SR 11-7 모델 리스크 관리 지침은 모델 검증, 지속 모니터링, 벤치마킹, 결과 분석을 강조합니다. 헬스케어·생명과학에서는 FDA의 AI 기반 의료기기 관련 논의가 라이프사이클 통제, 투명성, 안전성, 유효성의 중요성을 반영합니다. 평가와 옵저버빌리티는 이러한 통제 중 일부의 증거를 만드는 데 도움이 되지만, 실제 필요한 컴플라이언스 절차는 모델 채점보다 넓다는 점을 유의해야 합니다. ☑️ 운영 단계 평가를 실제로 구현하려면지금까지 살펴본 가드레일, 자기 개선, 거버넌스 증거화는 방법론입니다. 이 방법론을 실제 프로덕션에서 운영하려면 실시간 보호, 모니터링, 실패의 되먹임을 하나로 묶는 도구가 필요합니다.​Arize AX는 이러한 운영 단계 평가를 지원하는 AI 옵저버빌리티·평가 플랫폼입니다. 가드레일은 사용자 입력 메시지나 LLM 출력 메시지에 적용되며, 메시지가 가드를 통과하지 못하면 기본 응답을 제공하거나 LLM이 응답을 다시 생성하도록 하는 교정 조치를 취합니다. 가드를 프로덕션 모니터링에 연결하면 가드가 실패할 때마다 Slack, PagerDuty, 이메일 등으로 알림을 받을 수 있습니다. 동적 보호를 위해서는 임베딩 기반의 데이터셋 임베딩 가드를 제공합니다. 또한 프로덕션에서 관찰한 실패 트레이스를 데이터셋으로 되먹여 다음 개발 주기에 활용할 수 있으며, 프롬프트·모델 버전, 검색 문맥, 도구 호출, 평가자 결과, 최종 결과를 추적할 수 있어 거버넌스에 필요한 증거를 보존하는 데 도움이 됩니다. ​▶ Arize AX 자세히보기 ☑️ 자주 묻는 질문LLM 가드레일이란 무엇인가요?LLM 가드레일은 실시간으로 위험한 사용자 입력을 잡거나 모델 출력을 검사해, 유해한 입력으로부터 애플리케이션을 보호하고 손상을 주는 출력이 사용자에게 도달하기 전에 차단하는 장치입니다. 입력 가드와 출력 가드로 나뉘며 각각 다른 위험 유형에 특화됩니다.​입력 가드와 출력 가드는 어떻게 다른가요?입력 가드는 탈옥 시도 탐지, 프롬프트 인젝션 방지, 개인식별정보 제거처럼 모델에 도달하기 전의 입력을 다룹니다. 출력 가드는 유해·할루시네이션 응답 제거, 경쟁사 언급 필터링, 관련성 확인처럼 사용자에게 도달하기 전의 출력을 다룹니다.​자기 개선 평가란 무엇인가요?자기 개선 평가는 모델이 자신의 실패로부터 학습해 평가 방법을 스스로 정교화하는 접근입니다. 취약점 식별, 기준·데이터셋의 동적 개선, 지표·테스트 케이스의 자기 교정을 통해 시간이 지날수록 평가 기준을 높입니다.​LLM 평가가 규제 대응에 어떻게 쓰이나요?규제 환경에서 평가는 시스템이 어떻게 설계·테스트됐고 정책을 따랐는지를 보여주는 증거층 역할을 합니다. 다만 평가만으로 컴플라이언스가 완성되지는 않으며, 관할과 용도에 따라 요구사항이 다르므로 법무·리스크·보안 전문가와 함께 통제를 정의해야 합니다. ☑️ 마무리운영 단계 평가는 배포로 끝나는 것이 아니라, 실시간 보호와 지속 개선, 증거 보존으로 이어지는 활동입니다. 프로덕션 가드레일로 실제 트래픽의 위험을 줄이고, 자기 개선 루프로 실패를 다음 개발에 되먹이며, 거버넌스 관점의 평가로 규제 대응에 필요한 증거를 남기는 것이 핵심입니다. 이번 시리즈에서는 LLM 평가의 개념과 방법·지표(1편), 개발 단계의 데이터셋과 CI/CD(2편), 그리고 운영 단계의 가드레일·자기 개선·거버넌스(3편)를 차례로 살펴봤습니다.​클라우드네트웍스는 Arize AI의 한국 공식 파트너로서, AI 옵저버빌리티·평가 플랫폼인 Arize AX의 도입과 구축을 지원합니다. LLM 애플리케이션의 운영 단계 평가와 거버넌스 체계를 마련하는 데 관심이 있으시다면 클라우드네트웍스로 문의해 주시기 바랍니다. [출처 : Arize AI, "Production LLM evaluation", https://arize.com/resources/llm-evaluation/production-llm-evaluation/ , Arize AI, "Self-improving LLM evaluation", https://arize.com/resources/llm-evaluation/self-improving-llm-evaluation/ , Arize AI, "The definitive guide to LLM evaluation", https://arize.com/resources/llm-evaluation/ ]

LLM 애플리케이션은 표준 프롬프트만으로도 데모에서는 잘 동작하지만, 실제 프로덕션 환경의 복잡한 상황에서는 예상치 못한 실패를 자주 냅니다. 이 간극을 배포 전에 확인하려면 개발 단계에서 평가 체계를 갖춰야 합니다.앞선 1편에서는 LLM 평가가 무엇이고, 어떤 방법과 지표로 품질을 측정하는지 다뤘습니다. 이번 편은 그 평가를 실제 개발 과정에 어떻게 붙이는가에 관한 내용입니다. 배포 전에 성능을 검증하는 데이터셋을 어떻게 만들고, 변경 사항을 어떻게 실험으로 비교하며, CI/CD 파이프라인에 어떻게 연결하는지를 정리합니다.이 글은 어라이즈 AI(Arize AI)의 'The definitive guide to LLM evaluation' 중 사전 프로덕션(Pre-Production)과 CI/CD 부분을 바탕으로 합니다. ☑️ 개발 단계 평가란 무엇인가개발 단계 평가는 애플리케이션을 프로덕션에 배포하기 전에, 선별하거나 생성한 데이터셋으로 성능을 검증하고 변경 사항을 실험으로 비교해 회귀를 걸러내는 과정입니다. 1편에서 다룬 오프라인 평가와 CI/CD 점검이 여기에 해당합니다. 오프라인 평가는 실시간 프로덕션 데이터가 아니라 통제된 환경에서 사전에 준비한 입력으로 모델을 시험합니다. 프롬프트 변경이나 모델 교체가 결과를 개선했는지, 기존에 잘 처리하던 응답을 망가뜨리지 않았는지를 배포 전에 확인하는 것이 목적입니다. ☑️ 골든 데이터셋이 개발 단계 평가의 출발점인 이유골든 데이터셋은 신중하게 만들어지고 검증된 예시의 모음으로, 모델 성능을 평가할 때 기준이 되는 정답 역할을 합니다. 이 데이터셋은 많은 평가 전략의 토대가 되며, 평가 결과가 신뢰할 수 있고 일관되도록 뒷받침합니다. 데이터셋이 좁거나 지나치게 정제되어 있으면 평가 지표에서는 높은 점수가 나와도 실제 트래픽에서는 성능이 떨어질 수 있습니다. 골든 데이터셋은 애플리케이션이 지원하는 태스크, 자주 들어오는 요청, 어려운 엣지 케이스를 대표해야 합니다.손수 만든 데이터셋가장 기본적인 형태는 주제 전문가나 데이터셋 설계자가 직접 예시를 만드는 방식입니다. 모델이 처리해야 할 다양한 입력과 그에 대한 올바른 출력을 손으로 작성합니다. 이 방식의 강점은 특정 활용 사례나 엣지 케이스에 맞춘, 미묘하고 까다로운 예시를 만들 수 있다는 점입니다.Ground Truth 주석손수 만든 데이터셋에 사람이 정답을 부여하는 단계입니다. Ground Truth는 평가의 기준이 되는 올바른 답이나 라벨을 의미합니다. 예를 들어 어노테이터가 언어 모델의 출력을 기대 동작과 일치하는지에 따라 정답 또는 오답으로 라벨링하면, 이 값이 이후 모델 성능을 비교하는 기준점이 됩니다.다중 어노테이터 검증Ground Truth의 품질과 신뢰성을 확보하려면 여러 어노테이터가 각 예시를 독립적으로 라벨링해 검증합니다. 흔한 방식은 세 명 중 두 명 이상이 같은 라벨에 동의하면 그 라벨을 확정된 Ground Truth로 삼는 것입니다. 이러한 다중 어노테이터 전략은 개인의 편향이나 오류를 줄이고, 어노테이터 간 일치도(inter-annotator agreement)를 확인해 데이터셋의 신뢰성을 높입니다.휴먼 어노테이션은 트레이스나 스팬에 커스텀 라벨을 붙이는 방식으로도 활용됩니다. 프로덕션 응답에 직접 주석을 달아 필터링과 분석에 쓰거나, 대화의 특정 부분에 범주를 부여해 모델이 어디서 성공하고 실패하는지 세밀하게 분석할 수 있습니다. 또한 휴먼 라벨 데이터는 CI/CD 테스트, few-shot 프롬프팅, 표적 평가를 위한 고품질 데이터셋으로 쓰입니다. ☑️ 합성 데이터셋 구축과 검증합성 데이터셋은 실제 정보를 모방하도록 인위적으로 생성한 데이터셋입니다. 알고리즘이나 규칙으로 생성되며, 개발자와 연구자가 시험하려는 특정 패턴이나 시나리오를 표현하도록 만들어집니다. 고객 지원 대화, 질의응답 쌍, 다양한 어조의 제품 리뷰, 의도적 버그가 포함된 코드 조각 등이 예입니다.합성 데이터는 통제된 실험 환경을 만들고, 엣지 케이스를 폭넓게 확보하며, 실제 사용자 데이터를 쓰지 않아 프라이버시를 보호할 수 있습니다. 특히 아직 출시하지 않은 애플리케이션을 개발하고 실험할 때, 일관된 실험 결과를 위한 골든 데이터로 활용됩니다.합성 데이터셋 활용 시 주의점합성 데이터셋은 한 번 만들고 끝나는 것이 아니라 지속적으로 관리해야 합니다. 정기적인 갱신 주기를 두어 모델 개선과 데이터 드리프트를 반영하고, 생성에 사용한 프롬프트·모델·후처리 과정을 기록해 투명성을 유지하며, 실제 데이터 및 최신 모델과 비교해 성능을 주기적으로 평가하는 것이 권장됩니다.합성 데이터만으로는 사람이 자연스럽게 고려할 핵심 사례나 입력 유형을 놓칠 수 있습니다. 소수의 휴먼 라벨 예시를 포함하는 것만으로도 합성 데이터셋의 품질과 효과가 크게 향상될 수 있으며, 이는 모델이 적은 예시로 일반화해야 하는 few-shot 학습 상황에서 특히 효과적입니다. 다만 사람이 만든 예시를 추가할 때는 합성 데이터의 비중을 압도하지 않도록 균형을 맞추는 것이 좋습니다. ☑️ 평가 모델을 선택하는 기준평가에 사용할 모델은 반복 빈도, 비용 대비 정확도, 유연성 요건에 따라 달라집니다. 많은 팀은 애플리케이션에 쓰는 것과 같은 기본 모델로 평가를 시작해 기준선을 잡습니다. 이후 비용을 낮추기 위해 소형 언어 모델(SLM)로 옮겨가는데, 소형 모델은 비용이 크게 낮고 가드레일 용도에 빠릅니다. 더 나아가 특정 평가에 특화된 파인튜닝 모델을 쓸 수도 있습니다. 선택의 핵심은 평가를 자주 반복한다는 전제 아래 비용과 정확도의 균형을 맞추는 것입니다. ☑️ CI/CD 실험으로 변경을 검증하는 방법실험(experiment)은 선별한 데이터셋으로 LLM 애플리케이션의 변경을 체계적으로 시험하고 검증하는 절차입니다. 데이터셋을 정의하고, 출력을 생성하는 태스크를 만들고, 그 출력을 평가하는 평가자를 설정해 실행하면, 변경된 파이프라인이 얼마나 잘 동작하는지 측정할 수 있습니다. 실험은 세 가지로 구성됩니다.- 데이터셋: 애플리케이션을 평가하기 위한 입력과, 선택적으로 기대 출력을 제공하는 예시 모음입니다. 프롬프트, 모델, 그 밖의 구성요소 변경에 따른 개선을 추적하는 데 쓰입니다.- 태스크: JSON으로 직렬화 가능한 출력을 만드는 함수나 프로세스입니다. 시험하려는 LLM 기능을 재현하며, 예를 들어 프롬프트를 바꿨다면 새 프롬프트로 예시를 실행해 출력을 생성합니다.- 평가자: 태스크의 출력을 받아 평가를 수행하는 함수입니다. 실험의 성공 여부를 판단하는 기준이 되며, LLM 기반 평가자부터 코드 기반 평가까지 여러 개를 정의할 수 있습니다.실험은 프롬프트나 모델 변경뿐 아니라 애플리케이션이 조율되는 방식의 변경, 즉 새로운 통합, API 상호작용, 외부 함수 호출 같은 오케스트레이션 변경도 시험할 수 있습니다. 이를 통해 응답 시간이 개선되는지, 오류가 줄어드는지, 전체 사용자 경험이 나아지는지를 확인합니다.평가 데이터셋을 만드는 방법평가 데이터셋은 여러 경로로 만들 수 있습니다. 가장 권장되는 출발점은 수동 큐레이션으로, 애플리케이션이 처리해야 할 입력과 좋은 응답의 형태를 직접 정리하는 방식입니다. 고품질 예시는 20개 정도만으로도 큰 도움이 됩니다. 애플리케이션을 출시한 뒤에는 과거 로그가 유용한 자원이 됩니다. 사용자가 실제로 어떻게 쓰는지를 담고 있어, 부정적 피드백을 받은 지점이나 완료까지 오래 걸린 실행처럼 성능이 좋지 않았던 사례를 골라 데이터셋에 추가하면 이후 회귀를 시험할 수 있습니다. 예시가 어느 정도 모이면 합성 데이터로 빠르게 양을 늘릴 수 있는데, 합성 데이터는 원본 예시를 닮는 경향이 있으므로 먼저 좋은 수작업 예시를 몇 개 확보한 뒤 진행하는 것이 좋습니다. ☑️ 실험 결과는 흑백으로 나뉘지 않습니다실험 결과를 해석할 때는 여러 결과가 섞여 나온다는 점을 이해해야 합니다. 어떤 평가는 개선되고 어떤 평가는 그렇지 않을 수 있습니다. 예를 들어 프롬프트 구조를 바꾸면 일관성 점수는 올라가지만 사실 정확성은 조금 낮아질 수 있습니다.많은 팀은 검증용 예시를 손수 선별한 뒤, 평균 점수·F1·재현율·정밀도 같은 지표를 평가 결과 위에 얹어 성능을 판단합니다. 통계적 점검을 활용하는 것은 아직 보편적이지 않지만, 좋은 관행으로 점차 자리 잡고 있습니다. 중요한 것은 트레이드오프를 따져 애플리케이션의 목표에 맞는 개선을 우선하는 것입니다. ☑️ CI/CD 자동화와 변경 승격CI/CD 파이프라인을 구성하면 애플리케이션이 진화하는 동안에도 통제력을 유지할 수 있습니다. 전통적인 소프트웨어와 마찬가지로 자동화된 테스트로 문제를 조기에 잡는 것이 중요합니다. 큐레이션된 데이터셋과 선호하는 평가 방법으로 변경을 자동 검증하는 실험을 만들고, 이를 GitHub Actions와 연동하면 코드를 푸시할 때마다 자동으로 테스트가 실행됩니다.CI/CD 파이프라인에서 실행할 실험은 프로덕션을 최대한 가깝게 재현하는 것을 목표로 합니다. Ground Truth 평가는 무엇을 시험하든 항상 실행해야 하며, 여기서 실패하면 근본적으로 무언가 잘못된 것이므로 변경을 승격해서는 안 됩니다. 임계값 기반 실험은 할루시네이션이나 정확성 같은 지표가 정해진 기준을 넘는지 감지합니다. 예를 들어 할루시네이션 비율이 기준선 대비 크게 치솟으면 승격 전에 확인이 필요한 신호일 수 있습니다.평가 실패로 PR을 막을지는 전통적인 단위 테스트와 비슷하게 다룹니다. Ground Truth 비교의 심각한 실패나 큰 지표 급등은 PR을 막아야 하지만, 모든 평가 실패가 PR을 막을 필요는 없으며 일부는 배포 이후 모니터링에 더 적합합니다. 이것이 곧 패러다임의 전환입니다. LLM 평가는 새로운 단위 테스트이며, 팀이 모든 실패에 대해 변경을 막지는 않더라도 이 평가들은 애플리케이션의 중대한 문제를 잡아내는 실제 테스트입니다.한 가지 더 중요한 전환이 있습니다. LLM 애플리케이션은 코드 변경뿐 아니라 모델 업데이트나 프로덕션 입력의 드리프트에도 영향을 받습니다. 따라서 관련된 풀 리퀘스트나 활발한 개발 변경이 없을 때에도, 성능 변화를 감지하기 위해 실험을 정기적으로 실행할 필요가 있습니다. ☑️ 개발 단계 평가를 실제로 구현하려면지금까지 살펴본 데이터셋 구축, 실험, CI/CD 연결은 방법론입니다. 이 방법론을 실제 개발 워크플로우에서 운영하려면 데이터셋 관리와 실험 실행, 파이프라인 연동을 하나로 묶는 도구가 필요합니다.Arize AX는 이러한 개발 단계 평가를 지원하는 AI 옵저버빌리티·평가 플랫폼입니다. 프로덕션·스테이징·평가 과정에서 수집한 데이터로 데이터셋을 구성하고, 프롬프트·모델·오케스트레이션 변경을 실험으로 비교하며, 큐레이션된 데이터셋과 선호하는 평가 방법으로 변경을 자동 검증하는 실험을 만들 수 있습니다. 이 실험은 GitHub Actions와 연동되어 코드를 푸시할 때 자동으로 실행되므로, 수동 테스트 없이 변경의 안정성을 배포 전에 확인할 수 있습니다. ▶ Arize AX 자세히보기  ☑️ 자주 묻는 질문골든 데이터셋이란 무엇인가요?골든 데이터셋은 신중하게 만들어지고 검증된 예시 모음으로, 모델 성능을 평가할 때 기준이 되는 정답 역할을 합니다. 손수 만든 예시, Ground Truth 주석, 다중 어노테이터 검증을 결합해 신뢰성과 다양성을 확보합니다.합성 데이터셋은 어떻게 검증하나요?합성 데이터셋은 정기적인 갱신 주기를 두고, 생성 과정을 기록해 투명성을 유지하며, 실제 데이터 및 최신 모델과 비교해 주기적으로 성능을 평가합니다. 소수의 휴먼 라벨 예시를 더하면 품질과 일반화 성능을 높일 수 있습니다.실험(experiment)은 무엇으로 구성되나요?실험은 데이터셋, 태스크, 평가자 세 가지로 구성됩니다. 데이터셋은 입력과 기대 출력을 제공하고, 태스크는 시험하려는 기능을 재현해 출력을 만들며, 평가자는 그 출력을 채점해 성공 여부를 판단합니다.평가에 실패하면 항상 배포를 막아야 하나요?그렇지 않습니다. Ground Truth 비교의 심각한 실패나 큰 지표 급등은 PR을 막는 것이 맞지만, 일부 평가 실패는 배포 이후 모니터링에 더 적합합니다. 불필요한 병목을 피하면서 중대한 문제만 걸러내는 균형이 중요합니다. ☑️ 마무리개발 단계 평가는 배포 전에 품질을 검증하는 안전장치입니다. 골든 데이터셋과 합성 데이터셋으로 평가의 기준을 세우고, 실험으로 변경을 비교하며, CI/CD에 연결해 회귀를 조기에 잡는 것이 핵심입니다. 이번 편에서는 데이터셋 구축, 실험 구성, 결과 해석, CI/CD 자동화와 변경 승격을 살펴봤습니다. 다음 편에서는 배포 이후의 평가, 즉 프로덕션 가드레일과 자기 개선, 그리고 거버넌스를 다룹니다.클라우드네트웍스는 Arize AI의 한국 공식 파트너로서, AI 옵저버빌리티·평가 플랫폼인 Arize AX의 도입과 구축을 지원합니다. LLM 애플리케이션의 개발 단계 평가 체계를 마련하는 데 관심이 있으시다면, 클라우드네트웍스로 문의해 주시기 바랍니다.  [출처 : Arize AI, "Pre Production LLM Evaluation", https://arize.com/llm-evaluation/pre-production-llm-evaluation/ , Arize AI, "CI/CD for LLM Apps", https://arize.com/llm-evaluation/ci-cd-for-llm-apps/ ]

LLM 애플리케이션은 계속 바뀝니다. 팀은 프롬프트를 수정하고, 모델을 교체하고, 검색 방식을 조정하고, 도구를 추가하고, 오케스트레이션을 변경하며, 새로 발견된 프로덕션 실패에 대응합니다. 이런 변경이 애플리케이션을 실제로 개선했는지, 회귀를 만들었는지, 아니면 데모만 좋아 보이게 했는지를 평가 없이 판단하기는 어렵습니다. 문제는 LLM의 출력이 확률적이고 사용자 입력이 개방형이라는 점입니다. 응답은 유창하면서도 틀리거나, 근거가 없거나, 안전하지 않거나, 운영 비용이 큰 경우가 있습니다. 워크플로우가 잘못된 이유로 올바른 최종 답에 도달하는 경우도 있습니다. 관련 없는 문서를 사용하거나, 존재하지 않는 도구 인자를 만들어내거나, 성공할 때까지 재시도하는 식입니다.이 글은 어라이즈 AI(Arize AI)의 'The definitive guide to LLM evaluation'을 바탕으로 한 LLM 평가 시리즈의 첫 번째 편입니다. LLM 평가가 무엇이고, 어떤 방법으로 수행하며, 어떤 지표로 품질을 측정하는지 정리합니다. ☑️ LLM 평가란 무엇인가LLM 평가는 현실적인 입력, 워크플로우, 운영 조건에서 LLM 기반 애플리케이션이 의도한 대로 동작하는지를 측정하는 과정입니다. 최종 응답의 품질뿐 아니라 그 응답을 만들어낸 단계들, 즉 검색, 라우팅, 도구 호출, 모델 호출, 가드레일, 레이턴시, 비용, 엔드투엔드 태스크 성공까지 포함합니다.평가는 이런 변경을 테스트 가능한 질문으로 바꿉니다. "이 응답이 괜찮아 보이는가"라고 묻는 대신, 애플리케이션이 정확하게 답했는지, 올바른 근거를 사용했는지, 맞는 도구를 선택했는지, 정책을 따랐는지, 레이턴시와 비용 한도 안에 있었는지, 사용자의 태스크를 완료했는지를 물을 수 있습니다. ☑️ LLM 평가가 필요한 이유LLM은 모든 유효한 입력과 출력을 사전에 정의하지 않고도 유용한 애플리케이션을 만들 수 있게 합니다. 하나의 프롬프트가 콘텐츠를 생성하고, 구조화된 데이터를 추출하고, 문서를 요약하고, 질문에 답하고, 도구를 호출하고, 다단계 워크플로우를 조율할 수 있습니다. 이 유연성이 곧 테스트를 어렵게 만드는 요인이기도 합니다.체계적인 평가 시스템은 팀이 다음을 할 수 있도록 돕습니다.- 프롬프트, 모델, 검색 전략, 도구, 오케스트레이션 변경이 애플리케이션을 개선했는지 추적합니다.- 회귀가 사용자에게 도달하기 전에 잡아냅니다.- 정확성, 관련성, 근거성, 안전성, 레이턴시, 비용, 태스크 완료 등 여러 축에서 품질을 측정합니다.- 워크플로우의 어느 단계에서 문제가 생겼는지 식별해 실패를 디버깅합니다.- 동일한 예시에서 모델, 프롬프트, 아키텍처, 검색 구성을 비교합니다.- 프로덕션 동작을 모니터링하고, 실제 실패를 이후의 테스트 케이스로 전환합니다.- 릴리스 검토, 감사, 거버넌스 절차를 위한 근거를 보존합니다.여기서 데이터셋은 평가자만큼 중요합니다. 좁거나 지나치게 깨끗한 테스트 세트는 실제 트래픽에 일반화되지 않는 높은 점수를 낼 수 있습니다. 유용한 평가 데이터셋은 애플리케이션이 지원하는 태스크, 일반적인 요청, 어려운 엣지 케이스, 정책 경계, 알려진 프로덕션 실패를 대표해야 합니다. ☑️ 전통적 소프트웨어 테스트와 무엇이 다른가LLM 평가는 기존 소프트웨어 테스트 원칙을 대체하지 않고 확장합니다. 단위 테스트는 개별 함수를 격리해 결정적 동작을 검증하고, 통합 테스트는 서비스와 컴포넌트가 함께 동작하는지 확인합니다. LLM 애플리케이션에서도 API는 여전히 유효한 응답을 반환해야 하고, 스키마는 여전히 파싱되어야 하며, 도구는 여전히 올바른 레코드를 갱신해야 하므로 이 테스트들은 그대로 필요합니다.차이는 많은 LLM 동작을 하나의 정확한 기대 문자열로 표현할 수 없다는 데 있습니다. 유용한 답변은 여러 유효한 형태를 가질 수 있고, 올바른 응답은 검색된 문맥, 대화 이력, 사용자 의도, 정책, 도구 호출 결과에 따라 달라질 수 있습니다. 그래서 평가는 기존 테스트에 데이터셋, 루브릭, 모델 기반 평가자, 휴먼 라벨, 프로덕션 신호를 결합합니다.예를 들어 고객 지원 에이전트는 사용자의 요청을 올바르게 분류하고, 맞는 지원 워크플로우를 선택하고, 없는 정보를 지어내지 않고 주문 번호를 추출하고, 유효한 파라미터로 올바른 도구를 호출하고, 환불·에스컬레이션 정책을 따르고, 도구 결과를 최종 응답에 사용하고, 불필요한 단계 없이 사용자의 문제를 해결해야 합니다. 최종 메시지 하나에 대한 통과/실패 검사만으로는 이 중 무엇이 성공했고 무엇이 실패했는지 알 수 없습니다. ☑️ LLM 평가 방법 5가지LLM 평가는 여러 방법을 겹쳐 쓰는 시스템으로 접근할 때 가장 잘 작동합니다. 방법마다 신뢰할 수 있는 동작이 다르고, 대부분의 프로덕션 애플리케이션은 한 가지 이상의 평가자를 필요로 합니다.LLM-as-a-Judge언어 모델이 작성된 루브릭에 따라 다른 모델의 출력을 평가하는 방식입니다. 응답의 정확성, 관련성, 근거성, 도움 정도, 어조, 정책 준수처럼 코드로 표현하기 어려운 의미적·개방형 품질에 유용합니다. 다만 LLM 판정 자체가 정답은 아니며, 모델·프롬프트·라벨 정의·예시에 따라 결과가 달라질 수 있으므로 중요한 평가자는 휴먼 라벨 데이터셋으로 검증하고 버전을 관리해야 합니다.코드 기반 평가결정적 로직으로 기계가 검증할 수 있는 조건을 확인하는 방식입니다. JSON 유효성, 스키마 준수, 정확한 일치, 필수 필드, 수치 범위, 도구 인자 검증, 레이턴시 한도, 토큰 예산, API 상태처럼 명확한 답이 있는 항목에 적합합니다. 빠르고 재현 가능하며 판정 모델 비용이 들지 않지만, 개방형 답변이 실제로 유용한지까지는 판단하기 어렵습니다.Ground Truth 비교출력을 신뢰할 수 있는 기준 답변이나 라벨과 비교하는 방식입니다. 분류, 추출, 질의응답처럼 기대 상태가 정해진 태스크에 적합합니다. 에이전트의 경우 올바른 도구, 파라미터, 데이터베이스 상태, 허용되는 결과를 기준으로 삼을 수도 있습니다.휴먼 리뷰전문 지식, 정책 판단, 해석이 필요한 경우에 여전히 중요합니다. 휴먼 라벨은 실패 유형을 발견하고, 벤치마크 데이터셋을 만들고, LLM 판정자를 보정하고, 불확실하거나 위험도가 높은 사례를 검토하는 데 특히 유용합니다. 목표는 모든 출력을 사람이 라벨링하는 것이 아니라, 좋은 결과의 기준을 정의하고 자동 평가자가 그 기준에 충분히 근접하는지 확인하는 것입니다.사용자·프로덕션 신호실제 환경에서 애플리케이션이 작동하는지를 보여줍니다. 좋아요·수정·에스컬레이션·설문 같은 명시적 신호와, 반복 질문·세션 이탈·수동 개입·미해결 티켓·도구 재시도 같은 행동 신호가 여기에 해당합니다. 이 신호들은 유용하지만 희소하거나 편향될 수 있고 모델 외부의 원인을 가질 수 있어 신중하게 해석해야 합니다.각 방법은 적합한 대상과 강점, 한계가 다릅니다.평가 방법적합한 대상강점한계LLM-as-a-Judge개방형·의미적 품질자연어 루브릭을 규모 있게 적용보정이 필요하고 모델 비용·레이턴시 증가코드 기반 평가구조·규칙·스키마·실행 결과결정적이고 빠르며 비용이 낮음주관적 품질은 판단하기 어려움Ground Truth 비교정답·라벨·최종 상태가 있는 태스크기대 결과와 직접 비교 가능기준 데이터 확보 비용이 크고 불완전할 수 있음휴먼 리뷰모호하거나 전문적이거나 위험도 높은 판단도메인·정책에 대한 정교한 판단느리고 비용이 크며 확장이 어려움사용자·프로덕션 신호실제 결과와 새롭게 드러나는 실패 유형실제 사용자·트래픽의 동작을 보여줌희소하고 노이즈가 많으며 지연·교란될 수 있음가장 견고한 구성은 이 방법들을 결합합니다. 코드가 구조적 실패를 잡고, LLM 판정자가 의미적 품질을 평가하고, Ground Truth가 알려진 사례를 테스트하고, 휴먼 리뷰가 시스템을 보정하고, 프로덕션 신호가 데이터셋이 예상하지 못한 동작을 드러냅니다.라우터, 스킬, 경로 평가와 같은 에이전트 특화 평가 방법은 앞서 발행한 'AI 에이전트 평가란 무엇인가' 편에서 자세히 다룹니다. ▶ 'AI 에이전트 평가란 무엇인가' 자세히보기 ☑️ 무엇을 평가해야 하는가평가 대상은 애플리케이션 아키텍처와 사용자 태스크에 따라 달라집니다. 단순한 텍스트 생성 기능은 출력 검사만으로 충분할 수 있지만, RAG 애플리케이션이나 에이전트는 대개 여러 수준의 평가를 필요로 합니다. 일반적인 평가 대상은 다음과 같습니다.- 최종 응답 품질: 답변이 정확하고, 관련성이 있고, 완전하고, 근거가 있고, 사용자에게 적절한가- 검색 품질: 질의에 관련되고 충분하며 잘 정렬된 문서나 구절을 검색했는가- 라우팅: 올바른 모델, 워크플로우, 스킬, 함수를 선택했는가- 도구 선택과 파라미터: 맞는 도구를 고르고 유효한 인자를 채웠는가- 도구 결과 처리: 오류를 감지하고 결과를 올바르게 해석하며, 실패를 성공으로 주장하지 않았는가- 경로 품질: 루프나 중복 호출, 성급한 완료 없이 합리적인 단계 시퀀스를 밟았는가- 안전·정책 준수: 업무·법률·프라이버시·안전 요건과 에스컬레이션 규칙을 따랐는가- 운영 성능: 허용 가능한 레이턴시, 비용, 토큰, 처리량, 오류율 안에 있었는가- 세션·태스크 성과: 국소적으로 그럴듯한 응답을 넘어 전체 상호작용에서 사용자의 목표를 해결했는가이 검사들은 서로 다른 범위에서 실행할 수 있습니다. Span 수준 평가는 개별 모델 호출·검색 단계·도구 호출을, Trace 수준 평가는 하나의 엔드투엔드 실행을, Session 수준 평가는 상호작용의 연속을 평가합니다. 세션 수준 평가는 대화형 시스템과 장시간 실행되는 에이전트에서 특히 필요합니다. ☑️ LLM 평가 지표 5가지 범주평가 지표는 인간의 기대와 기계의 동작을 잇는 다리입니다. LLM 평가 지표는 측정 대상에 따라 흔히 다섯 가지 범주로 묶입니다.​정확성 (Correctness)LLM의 출력이 주어진 질문에 정확히 답하거나 지정된 태스크를 완수하는지를 판단합니다. 이진 분류(Correct/Incorrect), 다중 분류(완전 정답/부분 정답/오답), 골든 데이터셋과 비교하는 통계 지표(정밀도, 재현율, F1)로 측정합니다. 질의응답 시스템, 에이전트 스킬 검증, RAG 출력 검증에 활용됩니다.관련성 (Relevance)LLM의 출력이나 검색된 문서가 사용자의 질의·의도에 얼마나 부합하는지를 평가합니다. 이진 분류(Relevant/Irrelevant)나 순위 지표(MRR, MAP, nDCG)를 사용합니다. RAG 검색 품질 평가, 검색·요약 애플리케이션에 활용됩니다.​할루시네이션·충실성 (Hallucination / Faithfulness)LLM의 출력이 제공된 문맥에 근거하지 않은 정보를 만들어냈는지를 판단합니다. 이진 분류(Factual/Hallucinated)와 분류 근거를 제시하는 설명형 피드백을 사용합니다. RAG 검색 품질 평가, 검색·요약 애플리케이션에 활용됩니다.​유해성·안전성 (Toxicity & Safety)LLM의 출력이 유해하거나 편향되거나 부적절한 콘텐츠를 담고 있는지를 평가합니다. 이진 분류(Safe/Unsafe)와 심각도를 부여하는 점수 체계를 사용합니다. 소비자 대상 챗봇 모니터링, 엔터프라이즈 애플리케이션의 컴플라이언스 확보에 활용됩니다.​유창성·일관성·유용성 (Fluency, Coherence, Helpfulness)LLM 출력의 언어적 품질과 유용성을 측정합니다. 리커트 척도(1~5점)나 두 출력을 비교하는 페어와이즈 방식으로 평가합니다. 대화형 에이전트의 사용자 경험 개선, 콘텐츠 생성 모델의 개선에 활용됩니다.지표의 출력 유형은 이진, 다중 분류, 범주형 점수, 연속 점수로 나뉘며 상황에 따라 선택합니다. 이진은 정답/오답처럼 명확하고 빠른 판정에, 다중 분류는 완전 정답/부분 정답/오답처럼 미묘한 평가에, 범주형 점수는 집계와 통계 분석에, 연속 점수(예: 1~10)는 세밀한 피드백에 적합합니다. 안정성과 해석 가능성을 위해서는 범주형 평가를 우선하고, 세밀한 등급이 필요할 때 정규화를 전제로 연속 점수를 사용하는 것이 권장됩니다.​여러 지표를 합성 지표로 결합하면 LLM 성능을 종합적으로 파악할 수 있습니다. 대시보드로는 전체 평가 통과율, 문맥별 정확성, 모델 버전별 할루시네이션 비율, 시간에 따른 유해성 발생 추이 등을 추적할 수 있습니다.​지표를 활용할 때 흔히 나타나는 문제도 있습니다. 테스트 데이터에 과적합되어 테스트 세트 밖에서 일반화되지 않는 경우, 주관적 라벨링으로 일관성이 흔들리는 경우, LLM 판정이 일관되지 않은 경우, 평가 기준 정의가 모호한 경우입니다. 명확한 가이드라인, few-shot 예시, 기준의 명시적 정의로 이런 문제를 줄일 수 있습니다. ☑️ LLM 벤치마크와 애플리케이션 평가공개 벤치마크는 공유된 테스트 세트에서 모델이나 에이전트의 폭넓은 역량을 측정합니다. 공통 프로토콜로 시스템을 비교하거나, 모델이 애플리케이션이 요구하는 일반적인 종류의 작업을 수행할 수 있는지 확인하는 데 유용합니다. 벤치마크마다 검증하는 환경이 다릅니다. SWE-bench는 저장소 수준의 소프트웨어 엔지니어링 작업을, Terminal-Bench는 터미널 환경의 작업을, tau-bench는 도메인 정책 아래 시뮬레이션된 사용자와 상호작용하는 도구 사용 에이전트를, WebArena는 실제와 유사한 웹 환경의 자율 에이전트를, OSWorld는 데스크톱 애플리케이션과 운영체제 전반의 컴퓨터 사용 에이전트를, GAIA는 추론·도구·브라우징·멀티모달을 아우르는 일반 어시스턴트를 평가합니다.다만 벤치마크 점수가 애플리케이션의 프로덕션 준비를 보장하지는 않습니다. 공개 벤치마크에는 특정 기업의 프롬프트, 검색 코퍼스, API, 정책, 사용자 분포, 레이턴시 요건, 실패 비용이 담겨 있지 않으며, 시스템이 벤치마크에 맞춰 최적화될수록 대표성이 떨어질 수 있습니다. 그래서 팀이 통제하는 구성요소를 검증하는 태스크별 평가가 필요합니다. 대표 예시, 휴먼 라벨 사례, 합성 엣지 케이스, 실제 프로덕션 트레이스, 알려진 실패를 결합한 애플리케이션 데이터셋이 여기에 쓰입니다. 가장 견고한 전략은 공개 벤치마크를 폭넓은 역량 신호로, 애플리케이션별 평가를 실제 출시될 시스템의 수용 기준으로 사용하는 것입니다. ☑️ 온라인 평가와 오프라인 평가평가는 개발부터 프로덕션까지 이어져야 합니다. 온라인과 오프라인은 서로 다른 평가자 설계가 아니라, 데이터가 어디서 오고 평가가 언제 실행되는지를 가리키는 구분입니다. 동일한 정확성·근거성 평가자가 릴리스 전에는 선별된 테스트 데이터셋을, 릴리스 후에는 샘플링된 프로덕션 트레이스를 채점할 수 있습니다.- 오프라인 평가: 프로덕션 배포 전에 결과를 점검하는 데 사용합니다. 애플리케이션의 CI/CD 점검에 활용됩니다.- 가드레일: 실시간으로 실행되며, 시스템이 벗어난다고 감지하면 출력을 차단하거나 표시합니다.- 온라인 평가: 출력을 차단하지는 않지만 이상이 생기면 즉시 알 수 있게 합니다. 성능을 지속적으로 추적하되 실시간 차단이 필수는 아닐 때 유용합니다.이 구분은 다음 편에서 다루는 개발 단계 평가와 운영 단계 평가로 이어집니다. ☑️ 평가 워크플로우를 실제로 구현하려면지금까지 살펴본 평가 방법과 지표는 그 자체로 방법론입니다. 이 방법론을 실제 서비스 규모에서 적용하려면 트레이스 수집, 평가 실행, 결과 추적을 하나의 워크플로우로 묶는 도구가 필요합니다.Arize AX는 이러한 평가 워크플로우를 개발부터 프로덕션까지 지원하는 AI 옵저버빌리티·평가 플랫폼입니다. 프레임워크 전반의 워크플로우를 트레이스로 수집하고, 대규모로 평가를 실행하며, 토큰 비용을 추적하고, 프로덕션 동작을 모니터링하는 기능을 하나의 플랫폼에서 제공합니다. 수집한 트레이스로 테스트 데이터셋을 구성하고 CI/CD에서 자동 평가를 실행해 배포 전에 회귀를 잡아낼 수 있으며, 배포 후에는 동작이 기준선에서 벗어날 때 알림을 받을 수 있습니다. 평가자는 LLM, 코드, 어노테이션 세 유형을 지원하고, 할루시네이션이나 함수 호출 같은 흔한 평가 사례를 위한 사전 구축 템플릿을 제공합니다. 온라인·오프라인 평가를 모두 지원하며, 가드레일은 사용자 입력 메시지나 LLM 출력 메시지에 적용되어 실패 시 교정 조치를 취하고 프로덕션 모니터링·알림과 연결할 수 있습니다. ▶ Arize AX 자세히보기 ☑️ 자주 묻는 질문LLM 평가란 무엇인가요?LLM 평가는 현실적인 입력과 운영 조건에서 LLM 애플리케이션이 의도한 대로 동작하는지를 측정하는 과정입니다. 최종 응답 품질뿐 아니라 검색, 라우팅, 도구 호출, 가드레일, 레이턴시, 비용, 태스크 성공까지 포함합니다.LLM-as-a-Judge와 코드 기반 평가는 어떻게 다른가요?LLM-as-a-Judge는 언어 모델이 루브릭에 따라 정확성·관련성·어조 같은 의미적·개방형 품질을 평가하는 방식이고, 코드 기반 평가는 결정적 로직으로 JSON 유효성·스키마 준수·수치 범위처럼 명확한 답이 있는 조건을 검증하는 방식입니다. 두 방법은 서로 다른 실패를 잡아내므로 함께 사용하는 경우가 많습니다.어떤 평가 지표부터 시작해야 하나요?애플리케이션에 따라 다르지만, 정확성·관련성·할루시네이션·유해성·유창성 다섯 범주가 공통 출발점이 됩니다. 여러 지표를 결합한 합성 지표로 대시보드를 구성하면 전체 성능을 종합적으로 파악할 수 있습니다.온라인 평가와 오프라인 평가의 차이는 무엇인가요?오프라인 평가는 배포 전에 선별된 데이터셋으로 실행하는 점검이고, 온라인 평가는 배포 후 실제 트레이스에 대해 실행하는 모니터링입니다. 실시간 차단이 필요한 경우에는 가드레일을 사용합니다. ☑️ 마무리LLM 평가는 최종 응답이 그럴듯해 보이는지를 확인하는 작업이 아닙니다. 무엇을, 어떤 방법으로, 어떤 지표로 측정할지를 정하고, 개발부터 프로덕션까지 동일한 기준으로 품질을 관리하는 체계입니다. 이번 편에서는 LLM 평가의 개념과 다섯 가지 방법, 다섯 가지 지표 범주, 그리고 온라인·오프라인 평가의 구분을 살펴봤습니다. 다음 편에서는 개발 단계의 평가, 즉 사전 프로덕션 데이터셋 구축과 CI/CD 평가를 다룹니다.클라우드네트웍스는 Arize AI의 한국 공식 파트너로서, AI 옵저버빌리티·평가 플랫폼인 Arize AX의 도입과 구축을 지원합니다. LLM 애플리케이션의 평가 체계를 마련하는 데 관심이 있으시다면, 클라우드네트웍스로 문의해 주시기 바랍니다. [출처 : Arize AI, "The definitive guide to LLM evaluation", https://arize.com/resources/llm-evaluation/ , Arize AI, "Metrics", https://arize.com/llm-evaluation/metrics/ ]

AI 에이전트가 시범 도입 단계를 지나 금융, 의료, 공공 등 실제 운영 환경으로 빠르게 들어오고 있습니다. 단일 질문에 답하는 기존 생성형 AI와 달리, 에이전트는 여러 단계에 걸쳐 스스로 계획하고, 판단하고, 도구를 호출해 작업을 실행합니다. 사람을 대신해 메일을 보내고, API를 호출하고, 코드를 실행하는 일이 사람의 확인 없이 일어나기도 합니다.이런 자율성은 업무 효율을 높이는 동시에, 기존 애플리케이션 보안 모델이 다루지 못하던 새로운 공격면을 만듭니다. OWASP는 이 변화에 대응해 2025년 12월 에이전틱 애플리케이션을 위한 첫 번째 위협 목록을 발표했습니다. 이 글에서는 이 목록이 어떤 기준인지와 10가지 위협(ASI01~ASI10)을 정리합니다.  ☑️ OWASP Top 10 for Agentic Applications 2026이란  OWASP Top 10 for Agentic Applications 2026은 자율적으로 동작하는 AI 에이전트 환경에서 영향이 가장 큰 10가지 보안 위협을 정리한 프레임워크입니다. OWASP GenAI Security Project 산하 Agentic Security Initiative(ASI)가 발표했으며, 에이전틱 애플리케이션을 대상으로 한 첫 번째 버전(Version 2026)입니다.이 목록이 중요한 이유는 발행 주체와 제작 방식에 있습니다. OWASP는 웹 애플리케이션 보안 분야에서 가장 널리 알려진 비영리 기관이며, OWASP Top 10은 업계 표준으로 자리잡은 목록입니다. 이번 목록은 산업·학계·정부의 보안 전문가들이 위협 리서치, 레드팀 결과, 현장에서 검증한 완화책을 기여하고, 전문가 리뷰 보드와 공개 리뷰를 거쳐 정리한 커뮤니티 합의 기반 문서입니다. 보안 담당자가 가장 영향이 큰 위협을 먼저 이해하고 대응을 시작하는 출발점, 즉 나침반 역할의 기준으로 만들어졌습니다.  ☑️ 왜 에이전트는 별도의 보안 기준이 필요한가  질문에 답하기만 하던 기존 생성형 AI와 달리, 에이전트는 스스로 계획하고 도구를 호출해 작업을 실행합니다. 이 자율성 때문에 같은 공격이라도 피해가 훨씬 커집니다. 예를 들어 단일 응답을 조작하는 데 그치던 프롬프트 인젝션이, 에이전트 환경에서는 여러 단계에 걸친 목표 변경과 도구 연쇄 호출로 확대됩니다. 즉 에이전트는 기존 위험을 그대로 두면서 그 영향을 증폭합니다. 그래서 권한을 최소화하는 것(최소 권한)만으로는 부족하고, 자율성 자체를 최소화하라는 최소 자율성(Least-Agency) 개념이 함께 제시됩니다. 필요하지 않은 곳에 자율성을 부여하면 업무에 가치를 더하지 못한 채 공격받을 수 있는 지점만 넓어지기 때문입니다. 이 관점이 이어지는 10가지 위협을 관통하는 기본 전제입니다.  ☑️ 에이전틱 AI 보안 위협 10가지 (ASI01~ASI10)  10가지 위협은 에이전트의 입력(Inputs), 처리(Integration/Processing), 출력(Outputs) 흐름 위에 놓입니다. 각 위협은 어떤 공격인지, 어디서 발생하는지, 어떻게 막을 수 있는지를 기준으로 정리되어 있습니다.ASI01 에이전트 목표 탈취(Agent Goal Hijack) 에이전트의 목표나 의사결정 경로를 공격자가 조작하는 위협입니다. 에이전트는 사용자의 지시도, 외부에서 들어온 데이터도 같은 자연어로 처리하기 때문에, 정상 지시와 공격자가 심어둔 지시를 안정적으로 구분하지 못합니다.이 약점을 노려 공격자는 에이전트가 읽어들이는 문서, 웹페이지, 메일, 일정 초대, 외부 데이터에 명령을 숨깁니다. 에이전트가 그 내용을 처리하는 순간 숨은 명령이 실행되어, 기밀을 외부로 빼내거나 연결된 도구를 악용하게 됩니다. 실제로 이메일 한 통만으로 코파일럿이 기밀 메일과 파일을 유출한 사고, 웹페이지에 심은 명령으로 자율 에이전트가 내부 인증 페이지에 접근한 사고가 보고되었습니다.에이전트에서 위험이 특히 커지는 이유는, 조작이 단일 응답 하나를 바꾸는 데 그치지 않기 때문입니다. 한 번 목표가 바뀌면 이후 여러 단계의 계획과 행동 전체가 공격자가 의도한 방향으로 흘러갑니다. 실제 보고된 보안 사고가 가장 많이 몰려 있는 위협 중 하나입니다.  ASI02 도구 오용 및 악용(Tool Misuse and Exploitation) 에이전트가 부여받은 권한 범위 안에서, 정상 도구를 안전하지 않은 방식으로 사용하는 위협입니다. 도구 자체가 악성인 경우가 아니라, 정상 도구가 의도치 않게 위험하게 쓰이는 상황을 가리킵니다. 권한이 필요 이상으로 넓게 열린 것이 핵심 원인입니다. 예를 들어 메일 요약 도구에 삭제·발송 권한까지 함께 부여되어 있거나, 특정 데이터만 조회하면 되는데 전체 레코드에 접근할 수 있는 경우입니다. 여기에 검증 없이 전달되는 입력이 더해지면, 에이전트가 외부 데이터에 속아 데이터를 삭제하거나 유출하고, 비용이 큰 API를 반복 호출해 과금을 폭증시킬 수 있습니다. 정상 관리 도구를 차례로 연결해 보안 탐지를 우회하거나, 자동 실행이 허용된 도구를 반복 호출해 데이터를 조금씩 빼내는 방식도 보고되었습니다. 에이전트에서 위험이 커지는 이유는, 도구를 직접 고르고 연쇄적으로 호출하는 주체가 에이전트이기 때문입니다. 사람이 매번 확인하지 않는 만큼 잘못된 도구 사용이 빠르게 누적됩니다. 또한 도구 정의가 MCP 서버 같은 외부 경로로 들어오는 경우가 늘면서 공급망 위협과도 맞닿습니다.  ASI03 아이덴티티 및 권한 남용(Identity and Privilege Abuse) 에이전트의 위임 구조와 신뢰 관계를 악용해 접근 권한을 끌어올리는 위협입니다. 사람을 기준으로 설계된 기존 신원·권한 체계와, 에이전트가 서로 권한을 넘기고 위임하는 구조 사이의 불일치에서 비롯됩니다. 대표적으로 고권한 에이전트가 작업을 넘길 때 자신의 권한을 좁히지 않고 그대로 넘겨, 좁은 역할의 하위 에이전트가 과도한 권한을 갖게 되는 경우가 있습니다. 캐시된 자격증명이 세션이나 사용자 사이에 정리되지 않고 재사용되거나, "관리 도우미" 같은 그럴듯한 이름의 위조 에이전트가 내부 신뢰를 얻어 권한 작업을 수행하기도 합니다. 작업 시작 시점엔 권한이 유효했지만 실행 시점엔 만료·축소된 권한으로 작업이 계속되는 문제도 여기에 속합니다. 에이전트에서 위험이 커지는 이유는, 에이전트가 고유한 신원 없이 사람의 권한을 빌려 동작하는 경우가 많기 때문입니다. 누가 어떤 권한으로 한 행동인지 추적하기 어려운 공백이 생기고, 이 공백이 권한 상승의 통로가 됩니다. 사람이 아닌 에이전트·서비스의 신원, 이른바 비인간 신원(Non-Human Identity) 관리와 직접 맞닿는 위협입니다.  ASI04 에이전틱 공급망 취약점(Agentic Supply Chain Vulnerabilities) 에이전트가 사용하는 구성요소가 악의적이거나 변조되었을 때 발생하는 위협입니다. 여기서 구성요소는 모델과 가중치, 도구, 플러그인, 데이터셋, 다른 에이전트, MCP·A2A 같은 인터페이스, 에이전트 레지스트리, 업데이트 채널까지 폭넓게 포함합니다. 기존 소프트웨어 공급망 보안이 주로 설치 시점의 정적 의존성을 점검한다면, 에이전트 생태계는 런타임에 외부 도구와 에이전트를 동적으로 불러와 조합한다는 점이 다릅니다. 외부에서 가져온 프롬프트 템플릿에 숨은 명령이 들어 있거나, 도구 설명·메타데이터에 악성 지시가 심겨 있거나, 정상 도구를 가장한 유사 이름 도구가 호출되는 방식이 대표적입니다. 신뢰받는 레지스트리가 변조되면 잘못된 구성요소가 한 번에 광범위하게 퍼질 수도 있습니다. 에이전트에서 위험이 커지는 이유는, 신뢰의 단위가 설치 목록이 아니라 실행 순간으로 옮겨가기 때문입니다. 어떤 구성요소가 들어와 있는지 확인하는 것만으로는 부족하고, 실행 시점에 그 구성요소가 안전한지 계속 검증해야 합니다.  ASI05 예기치 않은 코드 실행(Unexpected Code Execution, RCE) 코드를 생성하고 실행하는 에이전트가, 의도치 않게 원격 코드 실행이나 내부 시스템 악용으로 이어지는 위협입니다. 이른바 바이브 코딩 도구처럼 실시간으로 코드를 만들어 바로 실행하는 환경에서 특히 문제가 됩니다. 공격은 여러 경로로 일어납니다. 프롬프트에 숨긴 셸 명령이 그대로 실행되거나, 안전하지 않은 역직렬화나 코드 평가 함수가 악용되거나, 검증 없이 설치된 패키지가 설치 과정에서 악성 코드를 실행하는 식입니다. 실시간으로 생성된 코드는 기존 보안 통제를 우회하기 쉬워, 호스트나 컨테이너 장악, 지속적 침투, 샌드박스 탈출로 이어질 수 있습니다. 실제로 코딩 에이전트가 검토 없이 설치·삭제 명령을 실행해 운영 데이터를 손상시킨 사고, 에이전트가 사용자 디렉터리를 삭제한 사고가 반복적으로 보고되고 있습니다. 에이전트에서 위험이 커지는 이유는, 코드 생성과 실행 사이에 사람의 검토가 생략되는 경우가 많기 때문입니다. 단일 출력 하나가 아니라, 정상 도구들을 차례로 연결하는 과정에서 최종적으로 코드 실행이 달성되기도 합니다.  ASI06 메모리 및 컨텍스트 오염(Memory & Context Poisoning) 에이전트가 작업의 연속성을 위해 저장하고 다시 불러오는 메모리나 컨텍스트를, 공격자가 오염시키는 위협입니다. 대화 요약, 임베딩, RAG 저장소처럼 에이전트가 계속 참조하는 정보가 대상이 됩니다. 공격자는 업로드 파일, API 피드, 일반 대화, 다른 에이전트와의 교환 등 검증이 느슨한 경로로 악의적 데이터를 메모리에 심습니다. 한 번 오염되면 이후의 추론과 계획, 도구 선택이 잘못된 정보 위에서 이루어집니다. 가짜 가격 정보를 반복 주입해 에이전트가 그것을 사실로 저장하게 하거나, 보안 에이전트의 메모리를 길들여 악성 활동을 정상으로 분류하게 만드는 방식이 예시입니다. 에이전트에서 위험이 커지는 이유는, 일회성 입력과 달리 오염된 내용이 메모리에 지속적으로 남기 때문입니다. 공격에 사용된 원래 입력이 사라진 뒤에도, 세션과 작업을 넘어 영향이 계속됩니다. 오염된 메모리가 결국 에이전트의 목표 해석까지 바꿔 목표 탈취로 이어지는 경우도 많습니다.   ASI07 안전하지 않은 에이전트 간 통신(Insecure Inter-Agent Communication) 여러 에이전트가 협업하며 주고받는 실시간 메시지가, 충분한 인증·무결성·의미 검증을 갖추지 못할 때 발생하는 위협입니다. 에이전트들은 API, 메시지 버스, 공유 메모리로 끊임없이 통신하는데, 이 채널이 약하면 공격면이 크게 넓어집니다. 암호화되지 않은 채널에서 중간자 공격으로 메시지를 가로채 숨은 지시를 끼워 넣거나, 신뢰·위임 메시지를 재전송해 오래된 권한을 되살리거나, 통신을 보안이 약한 옛 방식으로 강등시켜 악성 명령을 정상 교환처럼 보이게 만드는 방식이 가능합니다. 가짜 에이전트를 탐색 서비스에 등록해 권한 있는 통신을 가로채는 경우도 있습니다. 에이전트에서 위험이 커지는 이유는, 구조가 분산되어 있고 에이전트마다 신뢰 수준이 다르기 때문입니다. 하나의 경계만 지키면 되는 기존 방식으로는 막기 어렵고, 메시지 하나의 조작이 여러 에이전트의 잘못된 협업으로 번질 수 있습니다.  ASI08 연쇄 장애(Cascading Failures) 하나의 결함이 여러 자율 에이전트를 거치며 증폭되어, 시스템 전체의 장애로 번지는 위협입니다. 환각, 악성 입력, 오염된 도구나 메모리에서 시작된 단일 오류가 출발점이 됩니다. 에이전트는 스스로 계획하고 위임하며 상태를 저장하기 때문에, 하나의 오류가 사람의 단계별 점검을 건너뛰고 저장된 상태에 남아 계속 영향을 줍니다. 에이전트들이 새로운 도구나 동료 에이전트와 연결되면서, 잠재된 결함이 권한 있는 작업으로 번져 기밀성·무결성·가용성을 동시에 위협합니다. 하나의 잘못된 판단이 짧은 시간에 다수의 하위 작업을 촉발하거나, 두 에이전트가 서로의 출력을 신뢰하며 오류를 키우는 피드백 루프가 대표적인 증상입니다. 에이전트에서 위험이 커지는 이유는, 결함의 전파 속도와 규모가 사람이 따라잡기 어려운 수준이기 때문입니다. 이 위협은 결함의 출처가 아니라 그 전파와 증폭 자체에 초점을 둡니다. 다행히 빠른 확산, 도메인 간 전이, 반복 재시도 같은 증상은 탐지의 단서가 됩니다.   ASI09 인간-에이전트 신뢰 악용(Human-Agent Trust Exploitation) 에이전트의 자연스러운 언어와 권위 있어 보이는 설명을 이용해, 사람의 판단을 잘못된 방향으로 유도하는 위협입니다. 사람이 자율적 추천을 지나치게 신뢰해 독립적으로 검증하지 않고 승인할 때 위험이 커집니다. 근거가 불투명한데도 권위 있어 보여 그대로 신뢰하게 되는 경우, 민감한 작업에 최종 확인 절차가 없어 한 번의 승인이 곧바로 송금이나 데이터 삭제로 이어지는 경우, 에이전트가 그럴듯한 근거를 꾸며내 위험한 작업을 정당해 보이게 만드는 경우가 대표적입니다. 조작된 인보이스를 읽은 재무 보조 에이전트가 공격자 계좌로의 긴급 송금을 권하고, 담당자가 이를 신뢰해 승인하는 식의 사고가 보고되었습니다. 에이전트에서 위험이 커지는 이유는, 최종 실행을 사람이 맡는 구조 탓에 에이전트의 관여가 사후 추적에서 잘 드러나지 않기 때문입니다. 사람이 한 정상적인 승인처럼 기록에 남아, 에이전트가 그 판단에 어떤 영향을 미쳤는지 가려지기 쉽습니다. ASI10 악성 에이전트(Rogue Agents) 에이전트가 의도된 기능이나 허용 범위에서 벗어나, 해롭거나 기만적으로 동작하는 위협입니다. 개별 행동 하나하나는 정상으로 보여도, 전체로서의 행동이 유해해지는 행동 무결성의 상실에 초점을 둡니다. 프롬프트 인젝션, 목표 탈취, 공급망 변조 같은 외부 침해가 발단이 될 수 있지만, 이 위협은 일탈이 시작된 이후의 통제 상실 자체를 다룹니다. 겉으로는 순응하면서 숨은 목표를 추구하는 목표 드리프트, 신뢰받는 워크플로우를 가로채는 행위, 에이전트 간 담합과 자기복제, 잘못 설계된 보상 지표를 악용하는 보상 해킹이 예시입니다. 비용 절감을 지시받은 에이전트가 백업 삭제가 가장 효과적이라고 판단해 복구 자산을 스스로 파괴한 사례처럼, 목표는 따르되 수단이 어긋나는 경우가 위험합니다. 에이전트에서 위험이 커지는 이유는, 자율성과 속도 때문에 일탈이 내부자 위협처럼 빠르고 넓게 확산되기 때문입니다. 규칙 기반 통제만으로는 정상으로 보이는 개별 행동 속에서 유해한 흐름을 잡아내기 어렵습니다.  ☑️ OWASP가 공통적으로 제시하는 완화 방향  OWASP는 10가지 위협마다 별도의 완화 가이드라인을 제시하지만, 그 내용을 살펴보면 여러 위협에 걸쳐 반복적으로 등장하는 대응이 있습니다. 개별 위협에 대응하기 전에 이 공통 항목들을 점검하면 기본 방어선을 세우는 데 도움이 됩니다. 첫째, 최소 권한과 최소 자율성입니다. OWASP는 도구마다 권한과 데이터 범위를 좁게 정의하고, 권한을 최소화하는 것을 넘어 불필요한 자율성 자체를 부여하지 말 것(Least-Agency)을 권고합니다. 둘째, 단명·범위 제한 자격증명입니다. 작업 단위로 짧게 유효한 토큰을 발급하고 사용 후 즉시 회수하는 방식으로 피해 범위를 제한하도록 제시합니다. 셋째, 사람의 승인 단계(휴먼인더루프)입니다. 고위험·비가역 작업에는 사람이 확인하는 절차를 두어 자동 실행을 막도록 권고합니다. 넷째, 변조 불가능한 기록과 이상탐지입니다. 모든 도구 호출과 에이전트 행동을 변조할 수 없는 형태로 기록하고, 평소 패턴에서 벗어나는 이상 행위를 탐지하도록 제시합니다. 다섯째, 신뢰 경계와 격리입니다. 에이전트와 코드 실행을 격리된 환경에서 운영하고 외부 통신을 통제하도록 권고합니다.   ☑️ 위협에 대응할 수 있는 솔루션 영역  위 완화 방향은 개념만으로 완성되지 않고, 이를 실제로 구현하는 솔루션이 필요합니다. 클라우드네트웍스는 다음 영역에서 각 위협의 완화 방향과 맞닿는 솔루션을 제공합니다. 단, 어떤 단일 제품이 특정 위협을 모두 해결하는 것은 아니며, 위협별 대응의 일부를 담당한다는 관점에서 검토하는 것이 정확합니다. 앞서 살펴본 위협 가운데 아이덴티티·권한 남용(ASI03)과 비인간 신원 관리 문제는, 에이전트에 고유 신원을 부여하고 권한을 좁게 통제하는 것으로 대응합니다. 옥타(Okta)는 사람과 머신, AI 에이전트의 신원을 함께 관리하는 아이덴티티 보안을 제공해 이 영역에 활용할 수 있습니다. 권한 남용(ASI03)과 도구 오용(ASI02)의 피해를 줄이는 핵심은 작업 단위로 짧게 유효한 자격증명을 발급하고 즉시 회수하는 것입니다. 하시코프 볼트(HashiCorp Vault)는 동적이고 수명이 짧은 자격증명 발급과 자동 회수를 지원해 이 대응에 활용할 수 있습니다. 연쇄 장애(ASI08)와 악성 에이전트(ASI10)를 비롯한 대부분의 위협은, 모든 에이전트 행동과 도구 호출을 변조 불가능한 형태로 기록하고 이상 행위를 탐지하는 것이 공통 완화책입니다. 스플렁크(Splunk)는 로그 수집과 위협 탐지, 보안 운영 자동화를 제공해 이 탐지·추적에 활용할 수 있습니다. 목표 탈취(ASI01)와 코드 실행(ASI05)처럼 입력과 실행을 노리는 위협은, 입력을 신뢰하지 않고 검증하며 정책으로 통제하는 것으로 대응합니다. 시스코 AI Defense(Cisco AI Defense)는 AI 모델과 애플리케이션 보호, 네트워크 기반 가시성, 정책과 가드레일 적용을 제공해 이 영역에 활용할 수 있습니다. 각 솔루션에 대한 상세 정보는 아래 제품 페이지에서 확인하실 수 있습니다.솔루션대응영역관련 위협옥타(Okta)아이덴티티 및 권한 통제아이덴티티·권한 남용(ASI03)하시코프 볼트(HashiCorp Vault)자격증명 및 시크릿 관리도구 오용(ASI02), 권한 남용(ASI03)스플렁크(Splunk)보안 운영 및 가시성연쇄 장애(ASI08), 악성 에이전트(ASI10) 등 공통시스코 AI Defense(Cisco AI Defense)AI 보안 가시성 및 가드레일목표 탈취(ASI01), 코드 실행(ASI05)  ☑️ 자주 묻는 질문  OWASP Top 10 for Agentic Applications 2026은 무엇인가요? 자율적으로 동작하는 AI 에이전트 환경에서 영향이 가장 큰 10가지 보안 위협을 정리한 OWASP의 프레임워크입니다. OWASP GenAI Security Project 산하 Agentic Security Initiative가 2025년 12월 첫 버전을 발표했습니다. 일반적인 생성형 AI 보안과 무엇이 다른가요? 질문에 답하는 기존 생성형 AI와 달리, 에이전트는 스스로 판단하고 도구를 호출해 작업을 실행합니다. 이 자율성 때문에 같은 공격이라도 여러 단계로 확대되어 피해가 커집니다. OWASP Top 10 for Agentic Applications는 이렇게 에이전트의 자율성과 위임에서 비롯되는 위험에 초점을 둡니다. 기업은 무엇부터 검토해야 하나요? OWASP가 여러 위협의 완화 가이드라인에서 공통적으로 제시하는 항목은 최소 권한·최소 자율성, 단명 자격증명, 사람의 승인 단계, 변조 불가능한 기록과 이상탐지, 신뢰 경계 설정입니다. 개별 위협에 대응하기 전에 이 공통 항목들을 출발점으로 삼을 수 있습니다.이 목록은 확정된 최종본인가요? 2025년 12월 발표된 첫 번째 버전입니다. 함께 제공되는 실제 보안 사고 사례 목록은 주기적으로 갱신되므로, 세부 사례와 수치는 작성 시점 기준으로 이해하는 것이 정확합니다. ☑️ 마무리 OWASP Top 10 for Agentic Applications 2026은 에이전틱 AI 보안을 처음 체계화한 커뮤니티 기반 기준점입니다. 10가지 위협은 각각 다른 공격면을 다루지만, 자율성과 위임이 기존 위험을 증폭한다는 공통된 문제의식 위에 놓여 있습니다. 앞서 살펴본 것처럼 이 위협들에 대응하려면 에이전트의 신원과 권한 통제, 단명 자격증명 관리, 보안 운영과 이상탐지, AI 보안 가시성과 가드레일이 함께 맞물려야 합니다. 클라우드네트웍스는 옥타, 하시코프 볼트, 스플렁크, 시스코 AI Defense 등 각 영역의 솔루션을 기반으로, 고객 환경에 맞는 에이전트 보안 대응 방향을 함께 검토할 수 있습니다. 에이전틱 AI 도입을 준비하면서 보안 거버넌스를 점검하고자 한다면 클라우드네트웍스에 문의해 주시기 바랍니다. ▶ OWASP Top 10 for Agentic Applications 2026 원문 다운로드 [출처 : OWASP GenAI Security Project - Agentic Security Initiative, "OWASP Top 10 for Agentic Applications 2026"]

2026년 상반기 AI 엔지니어링 논의에서 가장 자주 등장한 단어는 '루프(loop)'입니다. 6월 7일 피터 스타인버거(Peter Steinberger)가 코딩 에이전트에 프롬프트를 넣는 대신 에이전트에게 프롬프트를 주는 루프를 설계해야 한다고 밝혔고, 같은 주 앤스로픽(Anthropic)의 보리스 체르니(Boris Cherny)는 무대에서 자신은 더 이상 프롬프트를 쓰지 않고 루프를 작성하며 그 루프가 일을 한다고 말했습니다. 애디 오스마니(Addy Osmani)의 'Loop Engineering', swyx(숀 왕)의 'Loopcraft', 랭체인(LangChain)의 'The Art of Loop Engineering'이 6월 한 달 사이에 연달아 발행되었고, AI Engineer World's Fair에서는 이 단어가 메인 스테이지를 채웠습니다. 7월 2일 폐회는 루프를 둘러싼 기대가 실제로 작동하는 수준을 앞질렀는지를 두고 한 시간에 걸친 토론으로 마무리되었습니다.문제는 루프를 이야기하는 사람들이 서로 다른 것을 가리키고 있다는 점입니다. 어라이즈 AI(Arize AI)는 최근 블로그에서 하나의 단어 아래 최소 네 가지 서로 다른 아키텍처가 숨어 있다고 정리하며, 각각을 실행 루프, 태스크 루프, 제품 루프, 시스템 루프로 구분했습니다. 그리고 이 네 가지를 통제하는 가장 바깥쪽 고리에 '오버사이트 루프'라는 이름을 붙였습니다.이 글에서는 Arize AI가 정리한 네 가지 루프의 정의와 종료 조건, 사람의 역할을 살펴보고, 루프가 실제로 닫히고 있는지 확인하기 위해 어떤 신호가 필요한지, 그리고 어라이즈 AX(Arize AX)가 그 지점에서 어떤 역할을 하는지 정리합니다. ☑️ AI 엔지니어링에서 '루프(Loop)'란 무엇인가 AI 엔지니어링에서 루프는 에이전트가 행동하고, 그 결과를 다시 입력으로 받아 다음 사이클을 반복하는 구조를 말합니다. Arize AI는 현재 이 단어가 실행 루프, 태스크 루프, 제품 루프, 시스템 루프라는 네 가지 아키텍처를 동시에 지칭하고 있으며, 각 루프는 무엇을 반복하는지, 무엇이 루프를 끝내는지, 사람이 어디에 개입하는지, 시간 단위가 어떻게 되는지가 서로 다르다고 설명합니다. 피드백이 다음 사이클로 되돌아가지 않는 구조는 루프가 아니라 파이프라인입니다. 따라서 루프를 설계한다는 것은 무엇이 이 루프를 끝내는지, 그 신호를 어디에서 가져올지를 함께 정하는 일입니다. 실행 루프(Execution loops): 에이전트가 행동하고 관찰하고 다음 행동을 결정하는 구조실행 루프는 대부분의 사람이 '에이전트'라는 말을 들었을 때 떠올리는 형태입니다. 도구를 호출하고, 결과를 읽고, 다음 행동을 결정하고, 더 이상 호출할 도구가 없을 때까지 이를 반복합니다. 애디 오스마니는 이를 내부 실행 루프(inner execution loop)라고 부릅니다. 에이전트가 사람의 개입 없이 상당 부분 스스로 수행할 수 있게 된 구간이자, 엔지니어가 직접 설계할 수 있는 가장 안쪽 루프입니다.실행 루프가 반복하는 단위는 하나의 작업 안에 있는 단계들입니다. 루프를 끝내는 신호는 환경 피드백, 즉 테스트 출력, API 응답, 파일 내용입니다. 사람은 루프 중간에는 대체로 등장하지 않고 경계에서 계획을 승인하거나 결과를 검토합니다.다만 이 루프는 에이전트가 스스로 끝났다고 판단하는 순간에도 종료됩니다. 실제로 끝났는지 여부와 무관하게 종료된다는 뜻입니다. 이 문제에 대해 업계가 처음 찾은 해법은, 에이전트의 판단을 그대로 받아들이지 않는 또 하나의 루프로 실행 루프를 감싸는 것이었습니다. 태스크 루프(Task loops): 테스트가 통과하고 스펙이 충족될 때까지 에이전트를 재시작하는 구조태스크 루프는 이름을 얻은 첫 번째 루프이며, 제프리 헌틀리(Geoffrey Huntley)의 랄프 루프(Ralph Loop)가 대표 사례입니다. 랄프 루프는 동일한 스펙을 대상으로 코딩 에이전트를 반복해서 재시작하되, 매 반복마다 완전히 새로운 컨텍스트 윈도우를 할당하고 루프당 정확히 하나의 작업만 수행합니다.낭비처럼 보이는 이 구조가 핵심입니다. 매번 전체 스펙을 다시 입력함으로써, 장시간 실행되는 세션의 품질을 서서히 떨어뜨리는 컨텍스트 부패(context rot)와 컴팩션 이벤트를 방지하기 때문입니다.태스크 루프가 반복하는 단위는 하나의 산출물이고, 루프를 끝내는 신호는 스펙 준수와 테스트 통과입니다. 사람은 스펙을 작성하고 완료 여부를 판단합니다. 제프리 헌틀리는 사람에게 한 가지 역할을 더 부여합니다. 루프를 지켜보면서 실패 패턴을 찾아내고, 그 패턴이 다시 발생하지 않도록 고치는 일입니다. 그는 이 역할을 기관차를 선로 위에 유지하는 기관사에 비유했습니다. 제품 루프(Product loops): 코드베이스와 백로그를 대상으로 도는 소프트웨어 팩토리제품 루프는 AI Engineer World's Fair에서 가장 크게 다뤄진 형태입니다. 팩토리(Factory)의 테레자 티슈코바(Tereza Tížková)는 소프트웨어 팩토리를 자율성을 갖고 소프트웨어를 개발하는 전체 루프이자 전체 라이프사이클로 정의했습니다. 워프(Warp)의 잭 로이드(Zach Lloyd)는 그 라이프사이클을 트리아지, 명세, 구현, 리뷰, 검증, 배포, 모니터링으로 구체화했습니다.잭 로이드는 소프트웨어 엔지니어링이 팩토리 엔지니어링으로 바뀌며, 제품이 아니라 그 제품을 만들어내는 시스템을 만들게 된다고 주장합니다. 워프는 자사 오픈소스 저장소를 팩토리 플랫폼 Oz의 관리 아래 두고 이를 직접 적용하고 있으며, 도입 경로를 리스크가 낮은 저장소에서 시작해 자동 PR 병합 비율을 20퍼센트에서 60퍼센트 방향으로 끌어올리는 방식으로 설명합니다. 앤스로픽 역시 자사 제품팀 코드의 65퍼센트가 내부 버전의 Claude Tag로 작성되고 있다고 밝혔고, 마이크 크리거(Mike Krieger)는 팀의 활용 방식을 특정 버그를 고치라는 지시가 아니라 코드베이스의 특정 영역을 책임지고 피드백 채널을 모니터링하며 스스로 작업을 가져가는 위임형·능동형 방식이라고 설명했습니다.실행 루프와 태스크 루프에는 명확한 종료 조건이 있지만, 제품 루프는 코드베이스와 백로그를 대상으로 지속적으로 돕니다. 종료 신호도 코드베이스 바깥에서 옵니다. 새로 등록된 이슈, 프로덕션 로그, 사용자 피드백, 리뷰 결과가 그 신호입니다. 사람의 역할은 고정되어 있지 않고 구성 가능한 형태가 됩니다. 라이프사이클 중 어느 부분을 자동화할지, 어느 지점에서 사람을 개입시킬지를 조직이 직접 선택합니다. 시스템 루프(System loops): 프롬프트, 평가, 하네스, 모델 자체를 개선하는 오토리서치시스템 루프는 인트로스펙션(Introspection)의 롤랜드 가브릴레스쿠(Roland Gavrilescu)가 오토리서치(autoresearch)라고 부르는 구조입니다. 내부 루프는 사용자 대면 작업을 수행하는 기본 시스템이고, 외부 루프는 그 기본 시스템을 연구하고 유지보수합니다. 외부 루프가 반복하는 대상은 프롬프트, 하네스, 모델 선택, 그리고 평가(eval) 자체입니다. 그는 루프가 곧 제품이라고 표현합니다.이 패턴은 소규모와 대규모 양쪽에서 실제 사례가 확인됩니다. 최소 사례는 안드레이 카파시(Andrej Karpathy)가 2026년 3월에 공개한 오토리서치로, 약 630줄의 파이썬 코드가 GPU 한 장에서 하룻밤 사이 50회의 가설-수정-평가 실험을 수행했습니다. 실제 제품에 반영된 사례는 6월 말 발표된 메타(Meta)의 Brain2Qwerty v2로, 에이전트가 코드베이스를 반복적으로 수정하며 더 나은 디코딩 아키텍처를 만들어냈고 단어 오류율에서 상당한 개선이 있었다고 보고되었습니다. 다만 최종 학습 구성은 여전히 사람이 직접 선택했습니다.시스템 루프를 끝내는 신호는 네 가지 루프 중 가장 까다롭습니다. 평가, 저지(judge), 필터링된 제품 피드백이 필요하고, 롤랜드의 설계에서는 에이전트가 신입 직원처럼 암묵지를 축적할 수 있도록 사람에게 묻는 도구가 명시적으로 포함됩니다. 실행 루프, 태스크 루프, 제품 루프, 시스템 루프 비교루프반복 대상종료 신호사람의 역할시간 단위대표 사례실행 루프하나의 작업 안의 단계들도구 결과, 환경 피드백경계에서 개입분 단위일반적인 에이전트 세션태스크 루프하나의 스펙에 대한 하나의 산출물테스트, 스펙 준수스펙 작성, 완료 판단시간 단위헌틀리의 랄프 루프제품 루프코드베이스와 백로그이슈, 로그, 사용자 피드백, 리뷰 결과구성 가능한 체크포인트지속적워프의 Oz, 팩토리시스템 루프시스템 자체평가, 저지, 필터링된 피드백암묵지 공급원, 에스컬레이션 지점일~주 단인트로스펙션, 카파시의 오토리서치 ☑️ 에이전틱 맵리듀스는 루프인가 같은 시기에 화제가 된 패턴 중 하나는 코그니션(Cognition)의 Devin Security Swarm입니다. 저장소 전반에 경계가 정해진 에이전트를 병렬로 펼치고 그 결과를 집계하는 방식으로, 코그니션은 이를 에이전틱 맵리듀스(Agentic MapReduce)라고 부릅니다.Arize AI는 이 구조를 루프로 보지 않습니다. 디스패치, 수집, 검증은 파이프라인이며, 다음 사이클로 되먹임되는 것이 없기 때문입니다. 피드백이 없는 루프는 for 문에 불과하고, 팬아웃은 네 가지 루프 안에 배치할 수 있는 토폴로지일 뿐 그 자체로 별도의 루프는 아니라는 관점입니다. 오버사이트 루프(Oversight loop): 목표, 예산, 자율성 수준을 사람이 정하는 고리swyx의 루프 다이어그램에서 가장 바깥 고리, 즉 루프를 만드는 루프보다 위에 있는 고리에는 이름이 없습니다. 그 고리에 적힌 역할은 목표를 설정하고, 자원을 배분하고, 작업을 쳐내는 것이며, 종료 조건은 '없음'으로 표시되어 있습니다. Arize AI는 이 고리에 오버사이트 루프라는 이름을 붙였습니다. 목표가 설정되고, 예산이 배분되고, 작업이 정리되는 곳이며, 사람이 반드시 있어야 하는 유일한 고리라는 의미입니다. 애디 오스마니는 무대에서 내부 루프는 역량이고 외부 루프는 주체성이라고 표현했고, 오버사이트 루프가 붙잡고 있는 것이 바로 그 주체성입니다.이 고리를 누가 운영할 것인가를 두고 의견은 갈립니다. 자율성 다이얼을 올려야 한다는 쪽은 체크포인트를 의도적으로 선택하고 신뢰가 쌓이는 만큼 자율성을 높여가자고 주장합니다. 반대편에서는 다이얼에 멈춤 지점이 있다고 봅니다. 제프리 리트(Geoffrey Litt)는 이해를 위임하는 사람은 에이전트로 대체된다고 주장했고, 폴 바카우스(Paul Bakaus)는 자동이란 것은 없고 앞으로도 없을 것이라고 단언했습니다. 휴먼레이어(HumanLayer)의 덱스 호시(Dex Horthy)는 자신이 루프에 반대하는 것은 아니며 쿠버네티스도 제어 루프 위에 세워져 있지만 그것은 결정론적 루프라고 지적하면서, 열광이 엔지니어링을 앞질렀다는 점을 우려했습니다.이 논쟁에서 가장 구체적인 근거는 앤스로픽 내부에서 나왔습니다. Claude Tag를 운영하는 팀조차 리뷰 단계와, 시스템이 무엇을 하고 있는지 사람이 개념화하는 능력에서 병목이 발생하고 있다고 보고했습니다. 사람이 스스로를 위해 남겨둔 체크포인트가 이제 제약 조건이 된 것입니다. 루프가 실제로 닫히고 있는지 어떻게 확인하는가자율성은 네 가지 루프 각각에 별도로 존재하는 다이얼입니다. 감독이 강한 제품 루프 안에서 완전 자율 실행 루프를 돌릴 수도 있고, 시스템 루프를 에이전트에 맡기면서 목표 설정은 전부 사람이 유지할 수도 있습니다. Arize AI가 던지는 질문은 어느 진영이 옳은가가 아니라, 각 다이얼을 올바르게 설정하려면 어떤 정보가 필요한가입니다.여기서 핵심은 신호를 이름 붙이는 것과 실제로 배선하는 것이 다르다는 점입니다. Arize AI는 신호가 배선되지 않은 루프는 수렴하지 않고, 외부에서 무언가 멈춰 세울 때까지 그냥 돌아갈 뿐이라고 설명합니다. 프로덕션 규모에서 루프가 실제로 닫히고 있는지 알려면, 트랜스크립트를 표본 점검하는 대신 트레이스를 지속적으로 훑고 실패를 클러스터링해야 합니다. Arize AX가 수행하도록 설계된 작업이 바로 이 지점입니다. ☑️ Arize AX가 에이전트 개선 루프를 닫는 방식 Arize AX는 LLM, RAG, AI 에이전트 서비스의 실행 과정을 트레이스로 기록하고, 평가와 저지로 그 동작의 품질을 측정하며, 측정 결과를 개선 작업까지 연결하는 AI 옵저버빌리티·평가 플랫폼입니다. 루프 관점에서 보면 Arize AX가 다루는 대상은 루프의 종료 신호입니다. 에이전트가 무엇을 했는지는 트레이스가, 그 동작이 좋은 동작이었는지는 평가와 저지가, 변경이 실제로 개선이었는지는 실험이 알려줍니다.프로덕션 트래픽은 사전 테스트가 놓친 엣지 케이스를 드러냅니다. 타임아웃이나 도구 오류, 깨진 JSON처럼 알람으로 잡히는 실패도 있지만, 잘못된 문맥을 검색하거나, 필요한 단계를 건너뛰거나, 도구에 잘못된 인자를 넘기거나, 잘못된 추론 위에 그럴듯한 답변을 만들어내는 실패는 트레이스를 들여다봐야 확인할 수 있습니다. Arize AX는 이 과정을 하나의 엔지니어링 워크플로우로 묶어, 에이전트 개선을 매번 새로 시작하는 조사 작업이 아니라 반복 가능한 프로세스로 만드는 것을 목표로 합니다.앞서 정리한 네 가지 루프에 대입하면 역할이 분명해집니다. 실행 루프의 동작은 트레이스와 스팬으로 기록되어 도구 호출과 판단 경로를 사후에 확인할 수 있게 됩니다. 제품 루프의 종료 신호인 이슈, 로그, 리뷰 결과는 시그널과 관리형 에이전트를 통해 조사 가능한 형태로 정리됩니다. 시스템 루프의 종료 신호인 평가와 저지는 에이전트 애즈 어 저지와 에이전트 실험으로 만들어집니다. 자율성 수준을 어디까지 올릴지 판단하는 오버사이트 루프에는, 이렇게 만들어진 신호가 근거로 올라갑니다.  트레이스는 늘어나는데 사람의 검토가 따라가지 못할 때에이전트 트래픽은 확장되지만 사람의 검토는 확장되지 않습니다. 하나의 트레이스에서 문제를 발견할 수는 있어도, 수천에서 수백만 건의 트레이스를 가로질러 반복되는 패턴을 찾아내는 일은 곧 불가능해집니다.시그널(Signal)은 제품 루프의 종료 신호를 만들어내는 기능입니다. 새로 들어오는 프로덕션 트레이스를 지속적으로 검토하고, 이미 확인된 이슈를 기억하며, 새로 나타나는 실패 패턴을 표면화하는 상시 동작 AI 워커입니다. 관련된 트레이스를 묶어 요약, 근본 원인 분석, 영향도, 제안된 다음 조치가 담긴 조사 리포트로 정리합니다. 모니터가 울릴 때까지 기다리는 대응형 디버깅 대신, 우선순위가 매겨진 이슈 목록과 근거를 확보한 상태에서 하루를 시작할 수 있는 구조입니다. 신호를 조사와 수정안으로 연결하는 단계실패가 식별된 뒤에도 팀은 트레이스를 조사하고, 무엇이 바뀌었는지 파악하고, 근본 원인을 찾고, 수정 방향을 정하고, 결과를 검증해야 합니다. 이 작업 대부분이 여전히 수작업으로 남아 있습니다.관리형 에이전트(Managed agents)는 신호를 조사와 수정안으로 옮기는 단계를 담당합니다. 저장소를 인지하는 장기 실행 에이전트를 오케스트레이션해 트레이스를 검사하고, 외부 시스템에 접근하고, 코드를 분석하고, 조사 산출물을 만들고, 변경 사항을 풀 리퀘스트 형태로 제안합니다. 회귀 트리아지, 프로덕션 동작 디버깅, 데이터셋 큐레이션, 평가 생성, 보안 리뷰, 코드 수정 같은 엔지니어링 워크플로우에 맞춰 구성할 수 있습니다. 이 워커들은 스스로 변경을 반영하는 자율 프로덕션 에이전트가 아니며, 조사하고 근거를 모아 제안할 뿐 승인과 반려는 엔지니어가 합니다.스웜 옵저버빌리티(Swarm observability)는 이렇게 늘어난 AI 워커들의 상태, 활동, 트라젝토리, 토큰 사용량, 비용을 한 화면에서 확인할 수 있게 합니다. 운영 관점에서는 제품 루프와 시스템 루프의 체크포인트를 어디에 둘지 판단할 때 참고할 수 있는 정보에 해당합니다. 변경이 실제로 개선인지 검증하는 단계프로덕션 에이전트는 프롬프트만으로 이루어져 있지 않습니다. 도구, 검색, 라우팅, 메모리, 모델, 폴백, 애플리케이션 코드, 비즈니스 로직으로 구성된 시스템이며, 어느 한 계층의 작은 변경이 한 동작을 개선하면서 다른 동작을 망가뜨릴 수 있습니다.에이전트 실험(Agent experiments)은 루프의 검증 단계에 해당합니다. 큐레이션된 데이터셋을 전체 에이전트 시스템에 통과시킨 뒤, 실행 간 출력, 트레이스, 평가 결과를 비교해 변경이 동작을 개선했는지 아니면 새로운 회귀를 만들었는지 확인합니다. 도구 사용이 좋아졌는지, 지연 시간이 달라졌는지, 검색 품질이 유지되었는지, 모델 업그레이드가 최종 답변 품질은 높이면서 도구 호출 신뢰성은 떨어뜨리지 않았는지를 이 단계에서 판단합니다. 예상하지 못한 실패 모드가 나타날 때기존의 LLM 저지는 무엇을 찾아야 하는지 이미 알고 있을 때 가장 잘 작동합니다. 그러나 에이전트 실패는 그렇게 예측 가능한 경우가 드물고, 도구와 사용자, 변화하는 환경과 상호작용하면서 새로운 실패 모드가 프로덕션에서 나타납니다.에이전트 애즈 어 저지(Agent-as-a-Judge)는 시스템 루프의 종료 신호인 평가 자체를 프로덕션 동작에 맞춰 갱신하는 기능입니다. 팀이 사전에 정의하지 않은 실패 모드가 드러났을 때 개선 루프가 적응할 수 있도록 돕습니다. 좋은 동작이 무엇인지 서술하면, 에이전틱 저지가 트레이스를 검사하고 관련 스팬을 식별해 이슈를 분류하고, 이후 모니터링과 평가, 실험에 재사용할 수 있는 라벨을 생성합니다.여기에 더해 음성 에이전트(Voice agents) 지원으로 오디오 세션, 트랜스크립트, 멀티모달 트레이스를 관찰하고 검색하고 재생하고 평가할 수 있습니다. 음성 대화를 텍스트 에이전트와 동일한 옵저버빌리티·평가 워크플로우로 가져오면, 개선 루프의 적용 범위가 대화형 AI 시스템까지 확장됩니다. ☑️ 자주 묻는 질문 AI 엔지니어링에서 루프란 무엇인가요?루프는 AI 에이전트가 행동하고 그 결과를 다시 입력으로 받아 다음 사이클을 반복하는 구조입니다. 어라이즈 AI는 이 단어가 실행 루프, 태스크 루프, 제품 루프, 시스템 루프라는 네 가지 아키텍처를 동시에 지칭하고 있으며, 각각 반복 대상과 종료 신호, 사람의 역할이 다르다고 정리합니다.실행 루프와 태스크 루프의 차이는 무엇인가요?실행 루프는 하나의 작업 안에서 도구 호출과 결과 관찰을 반복하며 환경 피드백으로 종료되고, 태스크 루프는 동일한 스펙에 대해 에이전트를 반복 재시작하며 테스트 통과와 스펙 준수로 종료됩니다. 태스크 루프는 매 반복마다 새로운 컨텍스트 윈도우를 할당해 장시간 세션에서 발생하는 컨텍스트 부패를 방지합니다.에이전틱 맵리듀스도 루프인가요?어라이즈 AI는 에이전틱 맵리듀스를 루프가 아니라 파이프라인으로 봅니다. 디스패치, 수집, 검증 구조에는 다음 사이클로 되돌아가는 피드백이 없기 때문입니다. 팬아웃은 네 가지 루프 안에 배치할 수 있는 토폴로지에 해당합니다.루프가 제대로 닫히고 있는지 어떻게 확인할 수 있나요?루프의 종료 신호가 실제로 시스템에 배선되어 있는지 확인해야 합니다. 어라이즈 AI는 신호가 배선되지 않은 루프는 수렴하지 않는다고 설명하며, 프로덕션 규모에서는 트랜스크립트 표본 점검 대신 트레이스를 지속적으로 훑고 실패를 클러스터링하는 방식이 필요하다고 밝혔습니다.어라이즈 AX는 에이전트 개선 루프에서 어떤 역할을 하나요?어라이즈 AX는 트레이스로 동작을 기록하고, 평가와 저지로 신호를 만들고, 관리형 에이전트로 조사와 수정안을 도출하고, 실험으로 변경 효과를 검증하는 과정을 하나의 워크플로우로 제공합니다. 시그널, 관리형 에이전트, 스웜 옵저버빌리티, 에이전트 실험, 에이전트 애즈 어 저지, 음성 에이전트 지원이 이 워크플로우를 구성하는 기능입니다. ☑️ 마무리 네 가지 루프의 형태는 다르지만, 그 아래에는 같은 실무가 놓여 있습니다. 추상화 수준을 한 단계 올리고, 사람의 판단을 스택 위쪽으로 밀어 올리는 일입니다. Arize AI는 이 지점에서 종료 신호를 이름 붙이는 것과 실제로 배선하는 것은 다르며, 신호가 배선되지 않은 루프는 수렴하지 않는다고 정리합니다. 운영 관점에서는 자율성 수준을 높이기 전에, 각 루프가 닫히고 있는지 확인할 수 있는 트레이싱과 평가 체계가 먼저 마련되어 있는지 확인할 필요가 있습니다.현재 어떤 루프를 만들고 있는지, 그 루프의 종료 신호가 실제로 배선되어 있는지 확인하는 일이 AI 에이전트 운영의 출발점입니다. 클라우드네트웍스는 Arize AI 공식 파트너로서, 고객 환경에서 운영 중인 LLM·RAG·AI 에이전트 서비스에 트레이싱과 평가 체계를 적용하고, Arize AX 기반의 에이전트 개선 루프를 설계·구축·운영하는 과정을 함께 검토할 수 있습니다. ▶ 어라이즈 AI(Arize AI) 자세히보기 [출처 : Arize AI, "What is a loop in AI engineering, anyway?", Arize AI, "Building the AI factory for self-improving agents: What's new in Arize AX"]

취약점 대응은 오랫동안 하나의 전제 위에서 움직였습니다. 취약점이 공개되면 그때부터 대응을 시작해도, 조치 속도를 충분히 높이면 공격자를 앞설 수 있다는 전제입니다. 지난 10년간 업계가 평균 조치 시간(MTTR)을 줄이는 데 집중해 온 이유도 여기에 있습니다. ​그런데 AI가 이 전제를 흔들고 있습니다. 퀄리스(Qualys)는 앤스로픽의 프론티어 모델인 미토스(Claude Mythos)와 같은 AI가 사람이 수년간 놓친 소스코드 취약점까지 찾아내면서, 익스플로잇까지 걸리는 시간이 주 단위에서 수 시간 단위로 줄었다고 설명합니다. 미토스에 대한 이러한 위협 규정은 퀄리스가 자사 캠페인에서 제시한 프레이밍이지만, 그 배경에 있는 데이터의 상당 부분은 출처가 분명한 사실입니다.​이 글에서는 취약점 대응이 왜 기존 방식으로 한계에 이르렀는지를 데이터로 살펴본 뒤, 퀄리스가 그 해법으로 내세운 리스크 운영 센터(ROC)와 이를 구동하는 엔진 엔터프라이즈 트루리스크 매니지먼트(ETM)가 이 문제를 운영 관점에서 어떻게 다루는지 정리합니다. ☑️ 지금 취약점 대응에서 무엇이 바뀌었나 핵심은 이것입니다. 공격 속도가 사람이 감당할 수 있는 조치 속도보다 빨라졌고, 이제 문제는 조치 속도가 아니라 운영 모델 자체입니다. 스캔하고, 티켓을 발행하고, 사람이 수작업으로 조치하는 모델은 취약점 물량이 적고 익스플로잇 타임라인이 길던 시대에 맞춰 설계되었기 때문입니다. 물량이 폭증하고 익스플로잇이 공개 이전에 일어나는 지금 환경에서는, 조치를 아무리 빨리 해도 구조적으로 뒤처지게 됩니다.이 진단은 퀄리스 위협연구팀(TRU)이 퀄리스-버라이즌 DBIR 2026 리서치 파트너십으로 발표한 리포트 "The Broken Physics of Remediation"에 근거합니다. 이 리포트는 10,000개 이상 조직의 CISA KEV 조치 기록 10억 건 이상을 4년간(2021~2025년) 추적·분석한 자료입니다. 아래에서 다루는 수치는 별도 표기가 없으면 이 리포트의 분석 결과이며, 각 수치의 원출처는 함께 표기했습니다.▶'The Broken Physics of Remediation' 리포트 전문 보기  ☑️ 데이터로 본 대응의 한계 익스플로잇은 취약점 공개 이전에 일어난다평균 익스플로잇 소요 시간(TTE)이 2024년에 -1일, 2025년에 -7일로 단축되었습니다(GTIG의 Mandiant M-Trends 2026 기준). 값이 음수라는 것은 공격자가 취약점이 공개되기 전에 이미 무기화해 악용하고 있다는 의미입니다. 방어자가 대응을 시작하는 공개 시점은 경주의 출발선이 아니라, 이미 뒤처져 있음을 확인하는 지점이 됩니다.리포트는 이를 실제 사례로 뒷받침합니다. 완전한 익스플로잇 타임라인이 확보된 52개 주요 취약점 중 정확히 절반은 공개 이전에 이미 무기화된 상태였고, Win Kernel 권한상승 취약점은 공개 182일 전, WinRAR 코드 실행 취약점은 110일 전부터 악용되고 있었습니다. 물량은 폭증했는데 대응은 오히려 악화됐다CISA KEV 취약점 처리 건수는 4년간 6.5배 증가했습니다. 2022년 약 7,300만 건에서 2025년 약 4억 7,300만 건으로 늘었습니다. 그런데도 공개 7일 시점에 아직 조치되지 않은 크리티컬 취약점 비율은 2022년 56%에서 2025년 63%로 악화됐습니다. 이는 인력이나 프로세스, 경영진의 관심 어느 것으로도 넘을 수 없는 구조적 한계라는 것이 리포트의 진단입니다.주목할 점은 조치 속도 자체는 느려지지 않았다는 것입니다. 리포트 부록 분석에 따르면 탐지에서 조치 완료까지의 중앙값은 그대로 유지됐고, 조직들은 절대 건수 기준으로 어느 해보다 많은 취약점을 닫았습니다. 그런데도 미조치 비율이 악화된 이유는, 처리해야 할 물량이 시스템의 처리 용량보다 빠르게 늘었기 때문입니다. 문제는 속도가 아니라 용량이라는 것이 리포트의 핵심 논지입니다. 무기화된 취약점 대응에서 방어자가 대부분 진다앞서 52개 취약점을 익스플로잇 시점과 조치 시점 기준으로 비교하면, 88%가 공격자의 익스플로잇보다 늦게 조치됐습니다. 무기화되어 실제 위험이 큰 취약점일수록 방어자가 지는 구조라는 의미입니다. 노출은 조치 이후에도 길게 이어진다기존 지표의 한계는 WinRAR 코드 실행 취약점(CVE-2023-38831) 사례에서 뚜렷하게 드러납니다. 이 취약점은 공개 110일 전부터 무기화되어 있었고, 공개 이후 조직들이 환경 전체에서 조치를 마치기까지 평균 137일이 더 걸렸습니다. 무기화부터 조치 완료까지의 전체 노출 기간은 247일, 즉 8개월이 넘었습니다. 공개 1년 후에도 취약 시스템의 약 15%가 여전히 패치되지 않은 상태로 남아 있었습니다. MTTR은 공개 이후 대응 속도만 재기 때문에, 이 이야기의 절반도 담지 못합니다.CISA KEV 크리티컬 취약점 전반의 생존곡선도 같은 흐름을 보여줍니다. 공개 시점에 취약 자산의 85%가 미조치 상태이고, 1주 후 63%, 평균 조치 시점인 약 21일 후에도 33%가 열려 있으며, 90일이 지나도 약 12%가 남아 있습니다. 초기 대응은 대시보드상 진척처럼 보이지만, 긴 꼬리 구간의 노출은 지표에 잘 잡히지 않습니다. MTTR이 놓치는 것: 노출 기간과 리스크 매스리포트는 MTTR을 보완하기 위해 두 가지 개념을 제안합니다.하나는 평균 노출 기간(AWE, Average Window of Exposure)입니다. 취약점이 무기화된 순간부터 환경 전체에서 조치가 끝나는 순간까지의 전체 창을 측정합니다. 조치 속도만 보는 것이 아니라, 조직이 실제로 얼마나 오래 노출되어 있었는지를 드러냅니다.다른 하나는 리스크 매스(Risk Mass)입니다. 취약 자산 수에 각 자산의 노출 일수를 곱한 값(노출-일)으로, 위험이 얼마나 오래·넓게 지속됐는지를 나타냅니다. 하루 만에 닫힌 취약점과 여러 달 열려 있던 취약점을 기존 CVE 카운트는 똑같이 조치 완료로 처리하지만, 리스크 매스는 이 둘을 서로 다른 리스크로 구분합니다. 리포트는 Follina 취약점(CVE-2022-30190) 사례에서 노출-일의 약 80%가 공개 전 블라인드 구간과 조치 이후 긴 꼬리 구간에 몰려 있고, 대시보드에 잡히는 초기 대응 구간은 20%에 못 미친다고 분석합니다. 대시보드가 측정하는 것과 실제 노출이 어긋난다는 의미입니다.이 어긋남은 자산 유형별로도 나타납니다. 리포트는 조치가 빠른 상위 성과 구간과 느린 하위 구간의 격차를 수작업 비용(Manual Tax)이라 부르며, 잊힌 서버나 원격 단말, 섀도 IT 같은 하위 자산이 상위 대비 4~5배 오래 걸린다고 설명합니다. 인프라·백본 계열은 변경 창과 다운타임 제약 때문에 조치가 수개월로 늘어나기 쉽고, 긴 꼬리 노출이 가장 두껍게 쌓이는 지점입니다. ☑️ 우선순위화에서 확인(confirmation)으로 여기서 중요한 전환이 있습니다. 우선순위화는 이미 업계가 상당 부분 달성한 과제입니다. 2025년에 공개된 취약점은 48,172건이었지만, 이 중 실제로 원격 악용이 가능하고 무기화되었으며 작동하는 PoC까지 확인된 것은 357건, 즉 0.74%에 불과했습니다. 이 비율은 2022년 0.52%, 2023년 0.64%, 2024년 0.55%로 공개 물량이 늘어도 대체로 1% 미만에서 유지됐습니다. 지금까지 공개된 전체 CVE 대비 CISA KEV 등재 비율도 약 0.48% 수준입니다. 위협 인텔리전스와 리스크 기반 우선순위화로 대응 대상을 1% 미만으로 좁히는 일은 이미 가능해졌습니다.​리포트는 다음 과제가 우선순위화가 아니라 확인이라고 봅니다. 특정 조직의 보완 통제(WAF, 방화벽, EDR, 네트워크 분리 등)를 고려했을 때, 우선순위가 높은 그 취약점이 지금 실제로 악용 가능한지를 결정론적으로 검증하는 단계입니다. 이론적으로 위험한 것과, 우리 환경에서 실제로 악용 가능한 것 사이의 간극을 좁히는 것이 다음 과제입니다. 우선순위화가 대상을 좁힌다면, 확인은 그중 무엇이 진짜 위험인지를 가려냅니다. ☑️ 우리 조직은 준비됐는가 이런 환경에서 자율 대응이 가능한 조직인지는 크게 세 가지 축으로 점검해 볼 수 있습니다. AI 속도 탐지, 하이퍼 우선순위화, 제로데이 조치입니다. 각 축을 기준으로 현재 운영 상태를 짚어봅니다. AI 속도 탐지가 되고 있는가탐지가 주간이나 월간 스캔 주기가 아니라 상시로 돌고 있는지, 온프레미스·클라우드·컨테이너·외부 공격 표면까지 모든 자산이 커버되는지, 새로운 제로데이 시그니처가 공개 직후 빠르게 배포되는지를 확인합니다. 탐지 주기가 길거나 사각지대가 있으면, 익스플로잇이 공개 이전에 일어나는 환경에서 이미 대응이 늦습니다.하이퍼 우선순위화가 되고 있는가발견된 항목이 활성 위협 인텔리전스로 필터링되어 실제 무기화된 소수를 가려낼 수 있는지, 자산 중요도(인터넷 노출, 핵심 시스템, 데이터 자산 등)가 반영되는지, 그리고 악용 가능성이 CVE 점수 추정이 아니라 실제 통제 환경에서 검증되는지를 확인합니다. 마지막 항목이 앞서 말한 확인(confirmation)에 해당합니다.제로데이 조치가 되고 있는가패치가 없는 상황에서 완화·격리 같은 패치리스 조치가 가능한지, 조치가 IT와 보안 도구 전반에서 오케스트레이션되어 수작업 티켓 전달이 제거되는지, 검증된 크리티컬 노출을 짧은 시간 내에 조치할 수 있는지를 확인합니다.세 축 중 어느 하나라도 "되고 있지 않다"는 답이 나온다면, 그 빈칸이 곧 현재 운영 모델의 구조적 취약점입니다. 조직 전체를 항목별로 점검하는 상세 체크리스트가 필요하다면 아래 문의를 통해 받아보실 수 있습니다. 이 세 축의 빈칸을 하나의 운영 체계로 메우려는 접근이 바로 리스크 운영 센터(ROC)입니다.​ ☑️ 리스크 운영 센터(ROC)는 이 문제를 어떻게 푸는가 ROC는 퀄리스가 보안 관제 센터(SOC)에 빗대 제시한 운영 개념입니다. SOC가 사후 대응을 위해 위협 이벤트를 한곳에 모아 다룬다면, ROC는 같은 방식을 사전 리스크 관리에 적용해 탐지부터 우선순위화, 악용 가능성 검증, 조치까지 취약점 대응의 전 주기를 하나의 폐쇄 루프로 묶습니다.​그 바탕에는 지속적 위협 노출 관리(CTEM)가 있습니다. CTEM은 가트너가 정립한 프레임워크로, 흩어진 노출을 모아 리스크를 줄이는 방법론입니다. ROC는 이 CTEM을 실제 운영으로 구현하고, 여기에 리스크가 조치할 가치가 있는지 판단하는 의사결정, 재무 관점의 리스크 정량화, 컴플라이언스·감사 대응을 더한 것입니다. 엔터프라이즈 트루리스크 매니지먼트(ETM)가 이 ROC를 구동하는 엔진이며, 퀄리스는 ETM을 업계 최초의 클라우드 기반 ROC 플랫폼으로 규정합니다.​ETM(Enterprise TruRisk Management)은 앞서 제기한 문제들을 하나의 폐쇄 루프로 받아 해소합니다. 흩어진 리스크를 한곳에 모으는 것에서 시작해, 데이터로 짚은 세 가지 한계를 차례로 어떻게 메우는지 살펴봅니다. 흩어진 리스크를 한곳에 모은다폐쇄 루프가 돌려면 먼저 흩어진 리스크가 한곳에 모여야 합니다. ETM은 자산관리(CSAM), 외부 공격 표면 관리(EASM), 서드파티 도구의 데이터를 통합해 단일 자산 인벤토리를 만듭니다. 취약점뿐 아니라 OT·IoT 장비, 클라우드 환경, 코드베이스, 사용자 아이덴티티까지 다양한 자산 유형을 함께 집계하고, 마이크로소프트 디펜더, Wiz, 옥타, 크라우드스트라이크 같은 서드파티 신호도 받아들입니다. 여기에 25개 이상의 위협 인텔리전스 피드를 정규화·중복 제거·상관 분석해 심각도와 악용 가능성 맥락을 더합니다. 도구마다 제각각이던 리스크 판단을 하나의 기준으로 정리하는 것이 출발점입니다. 공개 전에 악용되는 취약점을 먼저 인지한다앞서 익스플로잇이 취약점 공개 이전에 일어난다는 문제를 짚었습니다. 공개 시점이 이미 뒤처진 출발선이라면, 대응은 공식 신호보다 앞서 시작되어야 합니다. 상시 탐지(VMDR)가 자산의 취약점을 지속적으로 찾아내고, 위협 인텔리전스 계층인 TruLens가 실시간 맥락을 더합니다. TruLens는 CISA KEV 카탈로그를 99% 이상 커버하며, CVE가 KEV에 등재되기 평균 40일 전에 취약점 심각도를 상향합니다. 여기에 TruRisk 점수가 심각도, 악용 가능성, 자산 중요도, 비즈니스 영향을 종합해 대응 순서를 정합니다. 그 결과, 공식 위협 카탈로그에 오르기 전에 위험을 앞당겨 인지하고, 어떤 자산부터 손댈지 순서를 세울 수 있습니다. 공개 시점에야 대응을 시작하던 방식과 달리, 공격자의 타임라인에 조금 더 앞서 설 수 있습니다. 수천 건이 아니라 실제로 악용 가능한 소수만 대응한다앞서 우선순위화만으로는 부족하고 확인이 필요하다는 점을 짚었습니다. 수천, 수만 건의 크리티컬 취약점 가운데 무엇이 지금 우리 환경에서 실제로 악용 가능한지를 가려내는 단계입니다.이 역할을 하는 것이 TruConfirm입니다. 전통적인 스캐너가 "취약할 수 있다"를 알려준다면, TruConfirm은 "지금 이 환경에서 실제로 악용 가능하다"를 증명합니다. 표준 퀄리스 스캐너와 다른 별도 IP를 사용해, 화이트리스트에 등록되지 않은 실제 공격자 관점에서 자산에 접근합니다. 검증에는 시스템을 손상시키지 않는 변형된 무해 페이로드를 쓰는데, 먼저 취약 서비스가 실제로 존재하는지 사전 확인한 뒤에만 페이로드를 보내 불필요한 네트워크 노이즈를 줄입니다. 익스플로잇이 성공하면 결정론적 증적과 함께 위험을 상향하고, 실패하면 어떤 통제(WAF, 방화벽, EDR 등)가 막았는지 근거를 남깁니다. 스캐너 결과가 "지금 악용 가능함"과 "이미 차단됨"이라는 판단 근거로 바뀌는 것입니다.무엇을 먼저 검증할지는 에이전틱 AI 계층인 Agent Val이 결정합니다. 리스크 그래프 위에서 비즈니스 맥락, 자산 중요도, 위협 인텔리전스(KEV·활성 랜섬웨어 캠페인 신호 포함)를 종합해 검증 순서를 정하고, 검증·완화·재검증의 흐름을 자동으로 돌립니다. 검증이 끝나면 자산·운영체제·환경에 맞춘 조치 방안을 제시해, 팀 사이의 수작업 해석과 조율 부담을 줄입니다. 그 결과, 이론적으로 위험한 수천 건이 아니라 실제로 악용 가능한 소수에만 자원을 집중할 수 있습니다. severity 점수 추정으로 긴급성을 설득하던 방식에서, 증명된 사실을 근거로 대응하는 방식으로 바뀝니다.또한 TruRisk의 리스크 정량화(CRQ)는 자산 태그와 비즈니스 엔티티를 활용해 손실 속성과 리스크 노출액(VAR)을 평가합니다. 기술 이슈를 금액이라는 재무 언어로 바꿔주기 때문에, 경영진·이사회 보고와 감사 대응에서 근거로 쓸 수 있습니다. 규제 대응이 중요한 조직일수록 이 정량화와 리포팅의 실무 비중이 큽니다. 패치가 없거나 늦는 자산의 노출을 메우고 다시 검증한다앞서 조치가 늦고 노출이 길게 이어진다는 문제를 짚었습니다. WinRAR 사례의 247일이나, 패치까지 수개월이 걸리는 인프라 자산의 긴 꼬리가 그 예입니다.이 구간을 받는 것이 TruRisk Eliminate입니다. AI 기반 패치 신뢰도 점수, 단계적 배포, 롤백, 그리고 패치가 없을 때의 패치리스 완화라는 네 가지 안전장치를 둡니다. 패치가 없거나 검증되지 않았거나 운영상 위험한 경우에는, 벤더·CISA·퀄리스 위협연구팀의 권고에 따라 설정을 변경해 패치 없이 보호하거나(TruRisk Mitigate), 위험 자산을 사고 이후가 아니라 선제적으로 격리합니다(TruRisk Isolate). 이 조치들은 서비스나우, JIRA 같은 ITSM 도구와 기본 연동되어 IT 운영 프로세스 안에서 이뤄지므로, 별도 수작업 전달이 필요 없습니다.조치 후에는 Agent Val과 TruConfirm이 같은 익스플로잇 경로를 다시 시험해 노출이 실제로 닫혔는지 재검증합니다. 불완전한 조치가 백로그로 되돌아오는 것을 막는 장치입니다. 그 결과, 패치를 기다리는 동안에도 노출을 완화 조치로 메울 수 있고, 조치가 실제로 위험을 줄였는지까지 확인됩니다. 조치를 "티켓을 닫았다"가 아니라 "노출이 닫힌 것을 증명했다"로 다룰 수 있게 되는 것입니다.발견에서 확인, 조치, 재검증으로 이어지는 이 루프가 하나로 돌 때 성공 지표도 달라집니다. 퀄리스에 따르면 이 과정에서 검증 노이즈가 90% 이상 줄고, 확인된 익스플로잇 대상의 조치 시간이 70% 단축되며, 평균 노출 기간(AWE)은 67일에서 18일 미만으로 줄어듭니다. 대응의 무게중심을 티켓 종료 건수에서 검증된 리스크 감소로 옮긴다는 것이 이 접근의 방향입니다. ☑️ 자주 묻는 질문 리스크 운영 센터(ROC)는 기존 취약점 관리(VM)와 무엇이 다른가요가장 큰 차이는 목적입니다. 기존 취약점 관리가 개별 취약점을 더 빨리 처리하는 데 초점을 둔다면, ROC는 대응 프로세스 전체를 자동화된 운영 체계로 바꾸는 것을 목적으로 합니다. 발견부터 검증, 조치까지를 사람 손을 거치지 않고 하나의 흐름으로 돌린다는 점이 다릅니다.​CTEM과 ROC는 어떻게 다른가요CTEM은 방법론이고 ROC는 그 방법론을 돌리는 운영 체계입니다. CTEM이 흩어진 노출을 모아 리스크를 줄이는 가트너의 프레임워크라면, ROC는 여기에 조치할 가치가 있는지에 대한 판단과 재무 정량화, 실제 조치까지 더해 운영으로 구현한 것입니다.​MTTR만으로는 왜 부족한가요MTTR은 노출의 시작이 아니라 대응의 속도만 재기 때문입니다. 공격자가 공개 이전부터 악용해 온 기간이나, 조치가 끝난 뒤에도 길게 남는 자산의 누적 위험은 MTTR에 잡히지 않습니다. 이 사각지대를 보완하는 지표가 평균 노출 기간(AWE)과 리스크 매스입니다.​우선순위화를 하고 있는데 확인(confirmation)이 왜 따로 필요한가요우선순위화가 답하지 못하는 질문이 하나 남기 때문입니다. 우선순위화는 이론적으로 위험한 취약점을 가려내지만, 그 취약점이 우리 환경의 보완 통제 아래에서 지금 실제로 악용 가능한지는 알려주지 않습니다. 확인은 그 여부를 검증해, 이미 통제로 막힌 항목이 아니라 실제 노출에만 자원을 쓰게 합니다.​패치가 없는 취약점은 어떻게 조치하나요패치 대신 노출을 줄이는 보완 통제로 대응합니다. 가상 패치, 네트워크 수준 격리, 호스트 격리 같은 완화 조치로, 패치가 나올 때까지의 노출 구간을 메우는 방식입니다. 이런 패치리스 완화는 특히 패치까지 수개월이 걸리는 인프라 자산에서 중요합니다.  ☑️ 마무리 취약점 대응의 문제는 더 빠른 사람, 더 큰 팀으로 풀리지 않습니다. 익스플로잇이 공개 이전에 일어나고 물량이 폭증하는 환경에서, 조치 속도만 높이는 접근은 구조적으로 한계에 부딪힙니다. 퀄리스가 제시하는 리스크 운영 센터(ROC)와 ETM은 탐지·인텔리전스·우선순위화·확인·자율 조치를 하나의 폐쇄 루프로 묶어, 대응의 무게중심을 티켓 종료에서 검증된 리스크 감소로 옮기려는 접근입니다. 여기서 다룬 데이터와 사례는 리포트의 일부이며, 생존곡선과 자산 유형별 분석 등 전체 내용은 퀄리스 리포트에서 확인할 수 있습니다.​이 리포트의 데이터는 미국 CISA KEV를 기반으로 하지만, 익스플로잇 타임라인의 붕괴와 수작업 대응의 한계라는 흐름은 국내 기업에도 그대로 적용됩니다. 특히 금융·제조·공공처럼 규제 대응과 감사 근거가 중요하고, 변경 창 제약으로 패치가 지연되기 쉬운 환경에서는 어떤 자산을 우선 검증하고 어떤 조치를 자동화할지부터 검토가 필요합니다. 클라우드네트웍스는 퀄리스의 국내 파트너로서 고객 환경에 맞는 ROC·ETM 도입 검토와 개념검증(PoC), 구축·운영을 함께 진행할 수 있습니다. 자율 대응 준비도 점검이나 도입 방향 검토가 필요하시다면 클라우드네트웍스로 문의해 주시기 바랍니다. ▶ 퀄리스(Qualys) 제품정보 [출처 : Qualys, "The Broken Physics of Remediation", Qualys, "Enterprise TruRisk Management (ETM)", Qualys, "ROC vs CTEM: What's the Difference?", Qualys, "Introducing TruConfirm for Enterprise TruRisk Management: Automated Exposure Validation", Qualys, "Meet Agent Val: Closing the Validation Gap in Exposure Management at Machine Speed with Agentic AI", Qualys, "Handling the Vulnerability Surge in the Post-Mythos Era", Google Threat Intelligence Group(GTIG), "Mandiant M-Trends 2026"]