보안담당자의 딜레마
보안담당자라면 한 번쯤 이런 상황을 겪어봤을 것이다.
사업부에서 “우리도 AI 에이전트를 도입하겠다”고 선언한다. 개발팀은 이미 프로토타입을 만들어 데모를 돌리고 있다. CISO에게 보고가 올라오고, 보안팀에 리뷰 요청이 떨어진다. 이때 보안팀 앞에는 두 개의 선택지가 놓인다.
“안 됩니다.” 라고 말하면 사업부는 우회한다. Shadow AI가 확산된다. 직원들은 개인 계정으로 ChatGPT에 내부 문서를 붙여넣기 시작한다. 보안팀이 모르는 곳에서 AI가 이미 돌아가고 있다.
“됩니다.” 라고 말하면 어디까지 허용할 것인가? LLM 챗봇은 괜찮은데 에이전트가 DB에 쿼리를 날리는 건? 에이전트가 이메일을 보내는 건? 에이전트가 다른 에이전트를 호출하는 건? 경계가 모호해지고, 사고가 터진 다음에야 정책이 만들어진다.
Harness사의 2025년 조사에 따르면, 보안 실무자의 75%가 Shadow AI가 Shadow IT보다 더 큰 위험이 될 것이라고 답했고, 이미 과반수의 조직에서 AI 사용과 관련된 보안 인시던트가 발생했다. Gartner는 2027년까지 에이전틱 AI 프로젝트의 40% 이상이 부적절한 리스크 통제를 이유로 중단될 것이라 전망했다.
“막으면 뒤처지고, 풀면 사고 난다.”
이 딜레마에 대한 답이 AI 보안 하네스다.
AI 보안 하네스란 무엇인가
먼저 명확히 해두자. AI 보안 하네스(AI Security Harness)는 OWASP, NIST, ISO 등에서 공식 정의한 표준 용어가 아니다. 2025년 말부터 업계에서 “Agent Harness”라는 개념이 급격히 확산되었고, Salesforce, OpenAI, Vercel 등이 각자의 맥락에서 이 용어를 사용하기 시작했지만, 아직 통일된 정의는 없다.
본 시리즈에서는 AI 보안 하네스를 다음과 같이 정의한다.
AI 보안 하네스(AI Security Harness)란, AI의 활용을 보장하면서도 AI 고유의 위험을 관리하기 위해, AI의 자율성 수준에 비례하여 허용 범위와 보안 통제를 계층적으로 설계하고, AI 시스템의 진화에 맞춰 지속적으로 적응하는 운영 보안 프레임워크이다.
한 문장이지만 모든 단어에 의도가 담겨 있다. 하나씩 분해해 보자.
“AI의 활용을 보장하면서도” — 출발점이 “금지”가 아니라 “활용”이라는 점이 중요하다. 보안의 목적은 AI를 차단하는 것이 아니라, 안전하게 사용할 수 있는 경계를 설계하는 것이다. 보안팀이 “안 됩니다”만 반복하면 Shadow AI가 확산되고, 결국 보안팀의 통제 밖에서 더 큰 위험이 발생한다. 합의선을 도출하는 것이 본질이다.
“AI 고유의 위험을 관리하기 위해” — 비결정성, 프롬프트 인젝션, 환각(Hallucination), 과도한 자율성(Excessive Agency) 등은 전통적인 IT 보안 프레임워크로는 커버되지 않는 AI 특화 위협이다. 방화벽과 IDS로는 프롬프트 인젝션을 막을 수 없다. AI만의 새로운 공격 표면(Attack Surface)에 대응하는 프레임워크가 필요하다.
“자율성 수준에 비례하여” — 단순 LLM 챗봇과 자율 멀티에이전트 시스템은 위험도가 완전히 다르다. 모든 AI 시스템에 동일한 통제를 적용하는 것은 비효율적이고, 사업부의 불필요한 저항을 유발한다. 자율성이 높을수록 더 깊은 보안 통제가 필요하고, 낮을수록 가벼운 통제로 충분하다.
“허용 범위와 보안 통제를” — “무엇을 허용하고 무엇을 통제할지”의 양면을 모두 설계한다. 승인된 도구 목록, 데이터 분류별 AI 처리 허용 범위, 자율성 등급별 배포 기준 등을 정의한다. 통제만 이야기하면 사업부가 따라오지 않는다. “이렇게 하면 됩니다”를 함께 제시해야 한다.
“계층적으로 설계하고” — 단일 솔루션이 아닌 다층 방어(Defense-in-Depth)로 구성한다. AI Gateway에서 못 잡은 프롬프트 인젝션을 입력 가드레일이 잡고, 그것도 통과하면 출력 가드레일이 민감정보 유출을 차단한다. 단일 실패 지점(Single Point of Failure)을 만들지 않는다.
“지속적으로 적응하는” — AI 시스템은 모델이 업데이트되면 행동이 바뀐다. 새로운 공격 기법이 등장하고, 규제가 변한다. 어제 효과적이었던 가드레일이 오늘은 무용지물이 될 수 있다. 하네스는 한 번 구축하고 끝나는 것이 아니라, 피드백 루프를 통해 지속적으로 진화해야 한다.
“운영 보안 프레임워크” — 일회성 프로젝트가 아닌, 지속적으로 운영하는 체계다. 구축보다 운영이 더 어렵고 더 중요하다.
왜 “하네스”인가
하네스(Harness)는 원래 말(馬)을 마차에 연결하는 장구를 뜻한다. 말을 묶어두는 것이 아니라, 말의 힘을 올바른 방향으로 전달하기 위한 도구다.
이 비유는 AI 보안에 정확히 들어맞는다.
말(Horse)은 AI 모델이다. 강력하지만 방향을 모른다. 하네스(Harness)는 보안 프레임워크다. 힘을 올바른 방향으로 채널링한다. 기수(Rider)는 보안담당자이자 운영자다. 방향을 제시하고 판단한다. 도로와 울타리는 정책과 가드레일이다. 허용 범위를 정의한다.
핵심은 하네스가 말을 “묶어두는” 도구가 아니라 “힘을 전달하는” 도구라는 점이다. 말을 마구간에 가두면 마차는 움직이지 않는다. 하네스 없이 말을 풀어놓으면 마차가 전복된다. 하네스는 그 사이에서 균형을 잡는다.
업계에서 사용되는 유사한 개념들이 있다. 혼동하기 쉬우므로 차이를 명확히 해두자.
**가드레일(Guardrails)**은 AI 시스템의 입출력을 필터링하는 구성요소다. 프롬프트 인젝션 차단, 콘텐츠 안전성 검사 등을 수행한다. 중요하지만, 이것만으로는 전체 보안을 담보할 수 없다. 하네스의 구성요소 중 하나일 뿐이다.
AI Gateway는 모든 AI 트래픽이 통과하는 중앙 제어점이다. 인증, 정책 적용, 모델 라우팅 등을 수행한다. 역시 하네스의 핵심 구성요소이지만, Gateway만으로 에이전트의 도구 실행 격리나 피드백 루프까지 커버할 수는 없다.
Agent Framework는 LangChain, CrewAI, AutoGen 같은 에이전트 개발용 라이브러리다. 에이전트를 만드는 도구이지, 보안하는 도구가 아니다. 하네스가 감싸는 대상이다.
Agent Harness는 Salesforce, OpenAI 등이 사용하는 개념으로, 에이전트의 신뢰성 있는 운영 인프라 전체를 의미한다. 상태 관리, 도구 오케스트레이션, 장애 복구 등을 포함한다. AI 보안 하네스는 이것의 보안 측면에 집중하는 프레임워크다.
AI 거버넌스는 조직적 정책, 규제 준수, 윤리적 AI 사용 등을 다루는 상위 개념이다. 기술적 통제보다 조직적 통제에 가깝다. 하네스에서는 이것을 횡단 계층으로 포함한다.
5대 설계 원칙
AI 보안 하네스를 설계할 때 관통해야 하는 5가지 원칙이 있다. 이 원칙들은 개별 레이어의 구현 지침이 아니라, 전체 하네스의 철학적 기반이다. 이후 시리즈에서 다룰 모든 기술적 내용은 이 원칙 위에 세워진다.
원칙 1: 자율성 비례 통제 (Proportional Control)
AI 시스템의 자율성이 높을수록 더 깊은 보안 통제를 적용한다.
사내 챗봇에 풀 하네스를 적용하는 것은 과잉이다. 개발 속도가 느려지고, 사업부가 저항하며, 결국 우회 경로가 생긴다. 반대로 자율 에이전트에 가드레일만 적용하는 것은 과소다. 에이전트가 DB를 삭제하거나 대외 커뮤니케이션을 보내는 것을 가드레일만으로는 막을 수 없다.
AWS가 제시한 Agentic AI Security Scoping Matrix도 같은 맥락이다. 4가지 아키텍처 범위(Scope)를 정의하고, 각 범위에 적합한 보안 통제를 매핑한다. “모든 것에 최고 수준의 보안을 적용하라”가 아니라 “자율성에 비례하여 적정한 수준을 적용하라”는 것이다.
원칙 2: 허용과 통제의 양면 설계 (Enable & Control)
보안팀이 “안 됩니다”만 말하면 Shadow AI가 확산된다. “이렇게 하면 됩니다”를 함께 제시해야 한다.
실무적으로 이것은 합의선(Agreement Line)을 만드는 작업이다. 보안팀, 개발팀, 사업부가 함께 “여기까지는 OK, 여기부터는 승인 필요, 여기부터는 금지”를 정하고 문서화한다. 예를 들면 이런 식이다. 공개 데이터를 외부 LLM에 입력하는 것은 허용한다. 내부 데이터는 온프레미스 모델에서만 처리한다. 기밀 데이터를 AI로 처리하려면 보안팀 사전 승인이 필요하다. 에이전트의 쓰기(Write) 도구는 HITL 승인 후에만 실행 가능하다.
이런 합의선이 없으면, 현장에서는 “일단 해보고 문제 생기면 대응하자”가 된다. 문제가 생긴 다음에는 이미 늦다.
원칙 3: 계층 방어 (Defense-in-Depth)
하나의 통제가 뚫려도 다음 계층이 방어한다.
이것은 보안의 가장 기본적인 원칙이지만, AI 시스템에서는 더욱 중요하다. AI 모델은 본질적으로 비결정적(non-deterministic)이다. 같은 입력에 대해 다른 출력을 낼 수 있다. 이 말은 어떤 단일 방어 수단도 100%를 보장할 수 없다는 뜻이다. 프롬프트 인젝션 방어를 예로 들면, 규칙 기반 필터가 알려진 패턴을 차단하고, LLM 기반 분류기가 미묘한 공격을 탐지하며, 컨텍스트 격리가 근본적으로 신뢰 경계를 분리하고, 출력 가드레일이 마지막으로 민감정보 유출을 차단한다. 이 네 계층 중 하나가 실패해도 나머지가 방어한다.
원칙 4: 기존 인프라 위에 구축 (Overlay, Not Replace)
AI 보안 하네스는 기존 보안 인프라를 대체하는 것이 아니라, 그 위에 AI 특화 계층을 얹는 것이다.
이미 구축된 IAM, DLP, SIEM, API Gateway, 네트워크 보안은 AI 시스템에도 여전히 유효하다. 이것들을 버리고 새로 구축하는 것은 비효율적이고 비현실적이다. 필요한 것은 기존 인프라에 AI 특화 기능을 추가하는 것이다. 기존 API Gateway에 프롬프트 수준 정책 검사를 추가하고, 기존 DLP에 AI 출력 스캐닝 규칙을 추가하며, 기존 SIEM에 AI 의사결정 추적 로그를 연동하는 식이다.
조직 입장에서도 이 접근이 현실적이다. 보안 예산은 유한하고, 기존 투자를 활용하면서 AI 고유 위험에 대한 통제만 점진적으로 추가할 수 있다.
원칙 5: 지속 적응 (Continuous Adaptation)
AI 시스템은 모델이 업데이트되면 행동이 바뀐다. 새로운 공격 기법이 등장하고, 규제가 변한다. 하네스는 한 번 구축하고 끝나는 것이 아니라, 피드백 루프를 통해 지속적으로 진화해야 한다.
전통적인 보안 시스템은 업데이트 주기가 비교적 길다. 방화벽 규칙은 몇 달간 유효하고, IDS 시그니처도 정기적으로 업데이트하면 된다. 그러나 AI 모델의 공급업체가 새 버전을 배포하면, 기존 가드레일이 의도한 대로 작동하지 않을 수 있다. 새로운 프롬프트 인젝션 변종이 발견되면, 기존 필터를 즉시 업데이트해야 한다. EU AI Act 같은 규제가 시행되면, 정책과 기술 통제를 함께 조정해야 한다.
이를 위해서는 가드레일의 효과를 지속적으로 측정하고(거부율, 오탐률, 미탐률), Red Team 테스트를 정기적으로 수행하며, 위협 인텔리전스를 반영하여 규칙을 갱신하는 피드백 루프가 필요하다. 구축보다 운영이 더 어렵고 더 중요한 이유다.
자율성 등급 모델 (Level 1~4)
AI 보안 하네스의 핵심은 “자율성 수준에 비례한 통제”다. 이를 구현하려면 먼저 AI 시스템의 자율성을 분류하는 기준이 필요하다.
AWS의 Agentic AI Security Scoping Matrix, OWASP의 Agentic AI Top 10, 그리고 업계 관행을 참고하여 4단계 자율성 등급 모델을 정의한다.
Level 1: LLM 챗봇 / Q&A
텍스트를 입력하면 텍스트를 출력한다. 외부 시스템에 접근하지 않는다. 사내 Q&A 봇, 고객 서비스 챗봇, 문서 요약 도구 등이 여기에 해당한다. 위험도는 상대적으로 낮다. 주요 위협은 프롬프트 인젝션을 통한 시스템 프롬프트 유출, 부적절한 콘텐츠 생성, 민감정보가 포함된 입력의 외부 전송 정도다. 필요한 보안 통제는 입출력 가드레일, 콘텐츠 안전성 검사, 기본 접근제어 수준이다.
Level 2: RAG / 검색 증강
LLM이 외부 지식 소스(벡터 DB, 문서 저장소 등)를 참조하여 답변한다. 읽기 전용 도구를 사용한다. 사내 지식 검색 시스템, 문서 기반 Q&A, 기술 지원 봇 등이 해당한다. Level 1에 비해 위험도가 올라간다. 벡터 DB에 저장된 기밀 문서를 비인가 사용자가 검색할 수 있고, 임베딩 포이즈닝으로 검색 결과가 조작될 수 있으며, AI가 참조한 정보의 출처를 신뢰할 수 있는지의 문제도 생긴다. Level 1의 통제에 더해 지식 계층 보안, 벡터 DB 접근제어, 출처 검증이 추가로 필요하다.
Level 3: 도구 사용 에이전트
외부 시스템에 쓰기(Write) 작업을 수행하는 단일 에이전트다. 이메일 발송, DB 업데이트, 코드 실행, API 호출 등을 한다. CRM 업데이트 에이전트, 코딩 어시스턴트, 데이터 분석 에이전트 등이 해당한다. 위험도가 급격히 높아진다. 에이전트가 의도하지 않은 시스템 변경을 수행할 수 있고, 간접 프롬프트 인젝션으로 에이전트가 조작될 수 있으며, 에이전트가 접근하는 시크릿(API 키, DB 자격증명)이 유출될 수 있다. Level 2의 통제에 더해 도구 화이트리스트, 실행 격리(샌드박스), Human-in-the-Loop(HITL), 시크릿 관리가 필수적으로 추가된다.
Level 4: 자율 멀티에이전트
복수의 에이전트가 협업하여 장시간 자율적으로 실행된다. 에이전트가 다른 에이전트를 호출하고, 계획을 수립하며, 독립적으로 판단한다. 자동화된 보안 운영(SecOps), 복잡한 워크플로우 자동화, 연구 에이전트 시스템 등이 해당한다. 위험도가 가장 높다. 에이전트 간 메시지가 새로운 공격 경로가 되고, 한 에이전트의 타협이 전체 시스템으로 전파되는 캐스케이딩 위험이 있으며, 장시간 자율 실행 중 행동 드리프트가 발생할 수 있다. Level 3의 통제에 더해 에이전트간 상호 인증, 캐스케이딩 방어, 행동 모니터링, 서킷브레이커가 추가된다.
이 Level 모델의 핵심 메시지는 간단하다. 모든 AI 시스템에 동일한 보안을 적용하지 말라. Level을 먼저 분류하고, 그에 맞는 적정 수준의 통제를 적용하라. Level 1에 풀 하네스를 적용하면 과잉이고, Level 4에 가드레일만 적용하면 재앙이다.
기존 표준과의 관계
AI 보안 하네스는 기존 표준을 대체하지 않는다. 이들을 실무에서 통합 적용하기 위한 운영 프레임워크다.
**OWASP LLM Top 10 (2025)**은 LLM 애플리케이션의 10대 취약점을 정의한다. 프롬프트 인젝션(LLM01), 민감정보 노출(LLM02), 공급망 취약점(LLM03) 등이 포함된다. 하네스에서는 이것이 입출력 가드레일과 데이터 보호 레이어의 설계 기준이 된다.
**OWASP Agentic AI Top 10 (2026)**은 에이전트 AI 시스템의 10대 위험을 다룬다. 과도한 자율성, 도구 오용, 에이전트간 신뢰 문제 등 LLM Top 10이 커버하지 못하는 에이전트 특화 위험을 정의한다. 하네스의 오케스트레이션, 도구 격리, HITL 설계의 근거가 된다.
NIST AI RMF는 AI 리스크의 전체 생애주기 관리 프레임워크를 제공한다. Govern, Map, Measure, Manage의 4대 기능으로 구성된다. 하네스에서는 거버넌스 계층의 뼈대로 활용한다.
MITRE ATLAS는 AI 시스템을 대상으로 하는 공격 전술과 기법을 분류한다. 전통적인 MITRE ATT&CK의 AI 버전이라고 이해하면 된다. 하네스에서는 위협 모델링과 Red Team 테스트의 참조 체계로 활용한다.
SANS Critical AI Security Guidelines v1.1은 AI 보안 통제를 6대 카테고리로 정리한 실무 지침이다. 하네스에서 접근제어, 데이터 보호, 모니터링의 상세 구현 지침으로 참고한다.
EU AI Act와 ISO/IEC 42001은 규제와 인증 측면에서 하네스의 거버넌스 계층에 요구사항을 부과한다. 특히 EU AI Act의 위험 등급별 요구사항은 하네스의 Level 모델과 자연스럽게 매핑된다.
이들 표준은 각각 AI 보안의 특정 측면을 깊이 있게 다루지만, 개별적으로는 전체 그림을 제공하지 못한다. OWASP는 취약점을 정의하지만 조직적 운영 방법은 다루지 않는다. NIST는 거버넌스를 다루지만 기술적 구현 상세는 제공하지 않는다. MITRE는 공격을 분류하지만 방어 아키텍처를 제시하지 않는다. AI 보안 하네스는 이들을 하나의 운영 프레임워크 안에서 통합하는 역할을 한다.
다음 편 예고
이번 글에서는 AI 보안 하네스의 정의, 설계 원칙, 자율성 등급 모델을 다뤘다. 하지만 아직 “그래서 구체적으로 어떤 구조인가?”에 대한 답은 하지 않았다. 다음 편에서는 AI 보안 하네스의 전체 아키텍처를 다룬다. 4개 영역, 10개 레이어로 구성된 아키텍처의 전체 그림을 그리고, 각 레이어의 역할과 레이어 간 관계를 설명한다. Level별로 어떤 레이어가 활성화되는지, 실제 데이터 흐름에서 하네스가 어떻게 동작하는지를 구성도와 함께 보여줄 것이다.