왜 이 계층을 먼저 다루는가
기술적으로 화려한 AI Gateway나 프롬프트 인젝션 방어를 먼저 다루고 싶은 유혹이 있다. 하지만 횡단 계층을 먼저 다루는 데는 이유가 있다.
거버넌스 없이 기술을 구축하면 이런 일이 벌어진다. 개발팀이 가드레일을 구축했는데, 사업부에서 “왜 내 요청이 차단되느냐”고 항의한다. 차단 근거를 설명하려 하지만 합의된 정책이 없다. 결국 예외를 허용하고, 예외가 쌓이면서 가드레일은 구멍투성이가 된다. 관찰 가능성 없이 기술을 구축하면 또 다른 일이 벌어진다. 에이전트가 의도하지 않은 행동을 했는데, 로그를 뒤져봐도 “API 호출 성공”만 남아 있다. 에이전트가 왜 그 판단을 했는지, 어떤 컨텍스트를 참조했는지, 어떤 도구를 어떤 순서로 호출했는지 추적할 수 없다.
거버넌스는 “왜 이 통제를 하는가”의 근거를 제공하고, 관찰 가능성은 “실제로 무슨 일이 일어났는가”를 보여준다. 이 두 가지 없이 구축된 기술은 근거 없는 통제이거나, 검증 불가능한 통제다.
거버넌스 & 정책
AI 사용 정책의 본질: 합의선 설계
AI 보안 거버넌스의 핵심은 기술이 아니다. 합의다.
보안팀 혼자 정책을 만들어 내려보내면 실패한다. “외부 AI 사용 금지”라고 선언해봤자, 직원들은 개인 계정으로 ChatGPT를 쓴다. Harness사의 2025년 조사에서 보안 실무자의 75%가 Shadow AI를 Shadow IT보다 더 큰 위험으로 꼽은 것은 이미 그런 현실이 확산되었다는 뜻이다.
합의선(Agreement Line)이란 보안팀, 개발팀, 사업부가 함께 정의한 “여기까지는 OK, 여기부터는 승인 필요, 여기부터는 금지”의 경계다. 이것을 만드는 과정이 AI 거버넌스의 시작이자 가장 어려운 부분이다.
합의선 설계에서 반드시 정의해야 하는 항목들이 있다.
승인된 AI 도구 목록. 조직에서 공식적으로 사용이 허가된 AI 서비스와 모델의 목록이다. “목록에 없는 것은 사용 금지”가 원칙이지만, 동시에 새로운 도구를 요청하고 승인받는 절차도 함께 정의해야 한다. 목록만 있고 추가 절차가 없으면, 목록 자체가 무시된다.
데이터 분류별 AI 처리 허용 범위. 4단계 분류(공개/내부/기밀/극비)를 기준으로 각 등급의 데이터가 어떤 AI 시스템에서 처리될 수 있는지를 매핑한다. 예를 들어, 공개 데이터는 외부 LLM에 전송 가능하다. 내부 데이터는 기업용 계약이 체결된 외부 LLM에서만 처리 가능하다. 기밀 데이터는 온프레미스 모델에서만 처리 가능하며, 외부 전송은 금지된다. 극비 데이터는 AI 처리 자체가 금지되거나 CISO 직접 승인이 필요하다. 이 매핑이 없으면 현장에서는 “이 데이터를 AI에 넣어도 되나?”에 대한 답을 매번 즉흥적으로 내리게 된다.
Level별 배포 기준. 1편에서 정의한 Level 1~4 자율성 등급에 따라 AI 시스템의 배포 승인 기준을 차등 적용한다. Level 1(챗봇)은 보안팀 가이드라인 충족 확인 후 팀 리더 승인으로 배포 가능하다. Level 2(RAG)는 보안팀 리뷰를 거쳐 배포한다. Level 3(도구 에이전트)는 보안팀 심층 리뷰와 HITL 설계 확인 후 CISO 승인을 받는다. Level 4(자율 멀티에이전트)는 보안 아키텍처 리뷰, Red Team 테스트, 경영진 승인까지 거친다. Level이 올라갈수록 승인 절차가 엄격해지는 것은 자연스럽지만, 절차가 지나치게 무거우면 우회 동기가 생긴다. 적정 수준을 찾는 것이 합의선의 핵심이다.
금지 행위 목록. 어떤 상황에서도 허용되지 않는 AI 사용 행위를 명시한다. 고객 개인정보를 비인가 AI에 입력하는 것, AI 생성 결과를 검증 없이 대외 커뮤니케이션에 사용하는 것, 보안 통제를 우회하기 위해 개인 계정으로 AI를 사용하는 것 등이다. 금지 목록은 짧고 명확해야 한다. 목록이 길어지면 아무도 읽지 않는다.
AI 보안 위원회
합의선은 누군가가 한 번 만들고 끝나는 문서가 아니다. AI 기술이 빠르게 변하고, 새로운 사용 사례가 계속 등장하므로, 합의선을 지속적으로 갱신하는 조직 구조가 필요하다.
AI 보안 위원회(또는 AI 거버넌스 위원회)는 이 역할을 담당하는 cross-functional 그룹이다. 구성은 CISO 또는 보안 리더, AI/ML 엔지니어링 리더, 사업부 대표, 법무/컴플라이언스, 데이터 프라이버시 담당자 정도가 적절하다. 보안팀만으로 구성하면 사업부의 현실을 반영하지 못하고, 사업부만으로 구성하면 보안이 후순위로 밀린다.
위원회의 핵심 역할은 세 가지다. 새로운 AI 사용 사례에 대한 Level 분류와 배포 승인, 합의선의 정기적 리뷰와 갱신(분기별 권장), AI 보안 인시던트 발생 시 대응 방향 결정이다. 위원회가 효과적으로 작동하려면 의사결정 권한이 명확해야 한다. 자문 기구에 그치면 존재 의미가 없다.
인시던트 대응: AI만의 시나리오
AI 보안 인시던트는 전통적 보안 사고와 다른 시나리오를 포함한다.
프롬프트 인젝션 성공. 공격자가 에이전트를 조작하여 시스템 프롬프트를 유출시켰거나, 비인가 행동을 수행하게 했다. 이 경우 즉시 해당 에이전트를 비활성화하고, 감사 로그를 통해 에이전트가 수행한 모든 행동을 추적하며, 영향 범위를 파악해야 한다.
데이터 유출 via AI. 직원이 기밀 데이터를 외부 AI에 입력했거나, AI 시스템이 출력에 민감정보를 포함시켜 비인가 수신자에게 전달했다. 유출된 데이터의 범위와 민감도를 파악하고, 해당 AI 벤더의 데이터 보유/삭제 정책에 따라 조치를 요청해야 한다.
에이전트 폭주. 에이전트가 의도하지 않은 반복 루프에 빠져 대량의 API 호출, 이메일 발송, 데이터 수정 등을 수행했다. 서킷 브레이커가 작동하지 않았다면 수동으로 에이전트를 중단하고, 변경된 데이터를 롤백하며, 서킷 브레이커의 설정을 재검토해야 한다.
모델 타협(Model Compromise). 사용 중인 모델이 공급망 공격으로 백도어가 삽입되었거나, 모델 업데이트 후 비정상적 행동이 관찰되었다. 해당 모델 사용을 즉시 중단하고, 대체 모델로 전환하며, 해당 모델이 처리한 데이터의 무결성을 검증해야 한다.
각 시나리오에 대해 탐지 → 초기 대응 → 격리 → 분석 → 복구 → 사후 리뷰의 절차를 사전에 정의하고, 정기적으로 테이블탑 훈련을 수행해야 한다. 전통적 인시던트 대응 체계에 AI 시나리오를 추가하는 것이 현실적인 접근이다.
규제 대응: EU AI Act와 그 너머
규제 환경도 거버넌스의 중요한 입력이다.
EU AI Act는 AI 시스템을 위험 등급별로 분류하고, 등급에 따라 차등화된 요구사항을 부과한다. 이 등급 체계는 하네스의 Level 모델과 자연스럽게 매핑된다. 높은 위험 등급의 AI 시스템일수록 더 엄격한 투명성, 문서화, 인간 감독 요구사항이 적용된다.
ISO/IEC 42001은 AI 관리 시스템에 대한 국제 표준으로, AI 거버넌스의 조직적 프레임워크를 제공한다. 인증을 목표로 하는 조직이라면 이 표준을 거버넌스 계층의 뼈대로 활용할 수 있다.
중요한 것은 규제를 “준수해야 할 부담”이 아니라 “하네스 설계의 가이드”로 활용하는 관점이다. 규제가 요구하는 투명성, 문서화, 인간 감독은 어차피 좋은 보안 실무에서도 필요한 것들이다. 규제 준수를 별도의 작업으로 분리하면 이중 부담이 되지만, 하네스 설계에 녹여넣으면 한 번의 노력으로 보안과 컴플라이언스를 동시에 달성할 수 있다.
관찰 가능성 & 감사
AI 시스템의 관찰 가능성은 왜 다른가
기존 시스템의 관찰 가능성은 비교적 단순하다. 요청이 들어오고, 처리 로직이 실행되고, 응답이 나간다. 각 단계에서 로그를 남기고, 메트릭을 수집하고, 분산 추적으로 연결하면 된다. 로직이 결정론적이므로 입력과 출력만 알면 중간 과정을 재현할 수 있다.
AI 시스템은 세 가지 점에서 근본적으로 다르다.
비결정성. 같은 입력에 대해 다른 출력이 나올 수 있다. 입력과 출력만 로깅해서는 “왜 이런 출력이 나왔는가”를 설명할 수 없다. 모델의 추론 과정, 참조한 컨텍스트, 적용된 가드레일의 판단까지 기록해야 한다.
다단계 의사결정. 에이전트는 한 번의 요청으로 여러 단계의 추론과 도구 호출을 수행한다. “매출 보고서를 이메일로 보내줘”라는 단일 요청이 내부적으로 계획 수립 → 데이터 조회 → 보고서 생성 → 이메일 발송의 4단계로 분해된다. 각 단계의 입력, 출력, 판단 근거를 모두 추적해야 전체 그림이 보인다.
확률적 판단. 가드레일 자체도 확률적으로 작동한다. LLM 기반 분류기가 “이 입력이 프롬프트 인젝션일 확률이 0.7″이라고 판단해서 차단했다면, 이 판단의 근거와 임계치까지 기록해야 오탐/미탐 분석이 가능하다.
의미론적 로깅 (Semantic Logging)
전통적 로깅이 “무엇이 일어났는가”를 기록한다면, 의미론적 로깅은 “왜 그렇게 판단했는가”까지 기록한다.
전통적 로그는 이런 식이다. “2026-03-04 10:23:45 | POST /api/chat | 200 OK | 1,234ms | user: alice” 이것만으로는 AI 보안 관점에서 알 수 있는 것이 거의 없다.
의미론적 로그는 이런 정보를 담는다. 요청 메타데이터로 사용자 ID, 세션 ID, 에이전트 ID, Level 분류, 적용 정책이 있다. 입력 분석으로 원본 프롬프트(민감정보는 마스킹 처리), 입력 가드레일 판단 결과(통과/차단/경고, 위험 점수)가 있다. 추론 과정으로 모델 ID, 온도(temperature) 설정, 참조된 컨텍스트 문서 목록, 도구 호출 결정 사유가 있다. 도구 실행으로 호출된 도구, 파라미터(시크릿 마스킹), HITL 승인 여부, 실행 결과가 있다. 출력 분석으로 출력 가드레일 판단 결과, DLP 스캔 결과, 최종 응답(민감정보 마스킹)이 있다.
이 수준의 로깅은 당연히 비용이 든다. 저장 공간, 처리 시간, 그리고 민감정보 마스킹 파이프라인이 필요하다. 모든 요청에 대해 최대 상세 로깅을 하는 것은 비현실적일 수 있다. 실무적으로는 Level에 따라 로깅 깊이를 차등화한다. Level 1~2는 입출력 요약과 가드레일 판단 결과 정도, Level 3~4는 도구 호출 체인과 추론 과정까지 전체 기록하는 식이다.
민감정보 마스킹의 딜레마
로깅에서 가장 까다로운 문제가 민감정보 마스킹이다. AI 시스템의 입출력을 로깅해야 하는데, 그 입출력에 민감정보가 포함되어 있을 수 있다. 민감정보를 그대로 로깅하면 로그 자체가 데이터 유출 경로가 된다. 반면 모든 것을 마스킹하면 인시던트 분석이 불가능해진다.
균형점은 이렇다. 로깅 파이프라인에 실시간 마스킹 처리를 적용한다. PII(이름, 이메일, 전화번호, 주민번호 등)는 자동 탐지하여 마스킹한다. 시스템 프롬프트와 시크릿은 절대 로깅하지 않는다. 원본 데이터는 암호화된 별도 저장소에 보관하고, 인시던트 발생 시에만 권한 있는 담당자가 접근할 수 있도록 한다. 보존 기간과 접근 권한을 거버넌스 정책으로 명확히 정의한다.
Shadow AI 탐지
관찰 가능성의 중요한 역할 중 하나가 Shadow AI 탐지다. 조직에서 공식적으로 승인하지 않은 AI 서비스를 직원들이 사용하고 있는지 파악하는 것이다.
접근 방법은 기존 Shadow IT 탐지와 유사하지만 대상이 다르다. 네트워크 트래픽에서 주요 AI 서비스(api.openai.com, api.anthropic.com, generativelanguage.googleapis.com 등)로의 아웃바운드 트래픽을 모니터링한다. 기존 DLP/CASB가 있다면, AI 서비스 관련 카테고리를 활성화하여 사용 현황을 추적한다. 엔드포인트에서 AI 관련 애플리케이션(ChatGPT 데스크톱 앱, Copilot 확장 등)의 설치 현황을 파악한다.
목적은 처벌이 아니라 가시성이다. Shadow AI의 규모와 용도를 파악하면, 합의선 설계의 현실적 근거가 된다. 직원들이 주로 어떤 AI를 어떤 용도로 사용하는지 알면, 어떤 도구를 공식 승인하고, 어떤 데이터에 대해 어떤 경계를 설정할지 합리적으로 판단할 수 있다.
모델 드리프트 탐지
AI 시스템 특유의 관찰 과제가 모델 드리프트 탐지다. 모델의 행동이 시간이 지남에 따라 점진적으로 변하는 것을 감지하는 것이다.
드리프트가 발생하는 원인은 여러 가지다. AI 공급업체가 모델을 업데이트하면, 동일한 프롬프트에 대한 응답 패턴이 달라질 수 있다. 파인튜닝된 모델이 새로운 데이터로 재학습되면 행동이 변할 수 있다. 적대적 공격이 모델의 행동을 점진적으로 조작할 수도 있다.
탐지 방법으로는 주요 시나리오에 대한 골든 테스트 세트를 유지하고 정기적으로 실행하여 응답 변화를 추적하는 것이 있다. 가드레일의 거부율 변화를 모니터링하는 것도 중요하다. 갑자기 거부율이 올라가면 모델이 변했거나 공격이 변한 것이고, 거부율이 내려가면 가드레일이 우회되고 있을 수 있다. 출력의 품질 지표(환각률, 응답 일관성 등)를 추적하는 것도 드리프트의 간접 지표가 된다.
기존 SIEM과의 연동
대부분의 조직은 이미 SIEM(Splunk, Sentinel, QRadar 등)을 운영하고 있다. AI 보안 로그를 별도 시스템에서 관리하면 운영 부담이 늘어나고, 기존 보안 이벤트와의 상관 분석이 어려워진다.
현실적인 접근은 AI 전용 로그를 기존 SIEM에 연동하되, AI 특화 대시보드와 알림 규칙을 추가하는 것이다. AI 보안 전용 로그 소스를 정의하고, 기존 SIEM의 수집 파이프라인에 연결한다. AI 보안 전용 상관 규칙을 작성한다. 예를 들어 “동일 사용자가 5분 내 가드레일 차단 10회 이상” 같은 규칙이 있다. 또한 “에이전트가 HITL 승인 없이 쓰기 도구 호출 시도”처럼 에이전트 행동 기반 규칙을 추가한다. AI 보안 대시보드에는 가드레일 거부율, 에이전트 활동 현황, Shadow AI 탐지 현황, 모델 드리프트 지표 등을 시각화한다.
이렇게 하면 AI 보안 이벤트가 기존 보안 운영 워크플로우에 자연스럽게 통합되고, 별도의 관제 체계를 만들 필요가 없다.
감사 추적: 누가, 언제, 무엇을, 왜
규제 준수와 인시던트 대응 모두에서 핵심이 되는 것이 감사 추적(Audit Trail)이다. AI 시스템에서 감사 추적은 전통 시스템보다 더 복잡하다.
전통 시스템에서는 “사용자 A가 시간 T에 데이터 D에 접근했다”를 기록하면 된다. AI 시스템에서는 여기에 “AI 시스템 M을 통해, 프롬프트 P를 입력하여, 모델이 도구 T를 호출하기로 판단하여, HITL 승인을 받아, 데이터 D에 접근하고, 결과를 가공하여 사용자에게 전달했다”까지 기록해야 한다. 접근 경로가 AI를 경유함으로써 크게 길어지고 복잡해진다.
감사 추적에서 반드시 기록해야 하는 항목은 다음과 같다. 요청자(사용자 및 에이전트) 식별 정보, 시점, 사용된 AI 시스템과 모델, 입력 요약(민감정보 마스킹), 모델의 판단과 도구 호출 결정, 가드레일의 판단 결과, HITL 승인 여부와 승인자, 접근된 데이터와 시스템, 최종 출력 요약(민감정보 마스킹), 적용된 정책과 그 버전이다.
이 추적 정보를 변조 불가능한 형태로 보존하고, 필요 시 전체 리니지를 재구성할 수 있어야 한다. 인시던트 발생 시 “에이전트가 왜 이런 행동을 했는가?”에 대한 답을 제공할 수 있어야 하고, 감사 시 “이 데이터에 누가 AI를 통해 접근했는가?”에 대한 답을 제공할 수 있어야 한다.
실무 접근: 어디서부터 시작할 것인가
횡단 계층은 다른 모든 레이어의 기반이므로 가장 먼저 구축해야 하지만, 처음부터 완벽할 필요는 없다.
최소 시작 세트 (1~2주)
AI 자산 인벤토리 작성이 첫 번째다. 조직에서 사용 중인 AI 시스템을 전수 파악한다. 공식 승인된 것과 Shadow AI 모두 포함한다. DLP/CASB 로그, 네트워크 트래픽, 직원 설문 등을 활용한다. 완벽하지 않아도 된다. 80%만 파악해도 출발점으로 충분하다.
초기 AI 사용 정책 초안도 필요하다. 완벽한 문서가 아니라, 최소한 “승인된 도구 목록”, “금지 행위 목록”, “데이터 분류별 허용 범위” 세 가지만 포함하면 된다. 한 페이지로 충분하다. 합의를 위해 사업부와 개발팀의 리뷰를 반드시 거친다.
기본 로깅 파이프라인도 있어야 한다. AI 시스템의 입출력 로그를 기존 SIEM에 연동한다. 처음에는 가드레일 판단 결과와 에이전트의 도구 호출 로그 정도만 수집해도 된다. 의미론적 로깅의 전체 스택은 이후에 점진적으로 확장한다.
성숙 단계 (1~3개월)
합의선의 정교화가 이루어진다. 초기 정책의 운영 경험을 바탕으로, Level별 배포 기준, HITL 정책, 인시던트 대응 시나리오 등을 구체화한다. AI 보안 위원회를 공식 출범시키고, 분기별 리뷰 주기를 설정한다.
관찰 가능성도 강화된다. 의미론적 로깅 파이프라인을 구축하고, AI 전용 대시보드와 알림 규칙을 추가한다. 모델 드리프트 탐지를 위한 골든 테스트 세트를 작성하고 자동 실행을 설정한다.
Shadow AI 대응도 체계화된다. 탐지에서 나아가, Shadow AI 사용자에 대한 안내와 공식 도구로의 전환 지원을 수행한다. 처벌이 아닌 유도 전략이 효과적이다. “지금 쓰시는 것보다 공식 도구가 이런 점에서 낫습니다”가 “금지입니다”보다 잘 먹힌다.
다음 편 예고
횡단 계층이 “왜”와 “무엇이 일어나고 있는가”를 다뤘다면, 다음 편은 “어떤 기반 위에 세울 것인가”를 다룬다. 4편에서는 기반 계층인 ID & 접근제어, 데이터 보호, 공급망 보안을 다룬다. 에이전트에게 서비스 ID를 어떻게 부여하는지, 컨텍스트별 동적 권한은 어떻게 설계하는지, AI 학습 데이터 살균은 어떻게 하는지, 오픈소스 모델의 무결성을 어떻게 검증하는지를 구체적으로 설명한다.