지난 글 요약
지난 글에서 AI 보안 하네스를 “AI의 자율성 수준에 비례하여 허용 범위와 보안 통제를 계층적으로 설계하고, AI 시스템의 진화에 맞춰 지속적으로 적응하는 운영 보안 프레임워크”로 정의했다. 5대 설계 원칙과 Level 1~4 자율성 등급 모델도 제시했다.
이번 글에서는 그 정의를 실체화한다. AI 보안 하네스의 전체 아키텍처를 구성도와 함께 그리고, 각 레이어의 역할, 레이어 간 관계, Level별 활성화 구성, 실제 데이터 흐름을 다룬다.
아키텍처 설계 철학
아키텍처를 보기 전에, 이 구조가 왜 이런 형태가 되었는지를 먼저 이해해야 한다.
전통적인 웹 애플리케이션 보안은 비교적 명확한 구조를 가진다. 클라이언트가 요청을 보내고, 서버가 처리하고, DB에서 데이터를 가져와 응답한다. 각 지점에 방화벽, WAF, API Gateway, DLP를 배치하면 된다. 요청-응답 패턴이 예측 가능하고, 처리 로직이 결정론적이다.
AI 시스템은 근본적으로 다르다.
첫째, 비결정적이다. 같은 입력에 대해 다른 출력을 낼 수 있다. 이것은 단순한 기술적 특성이 아니라 보안 설계의 근본을 흔드는 문제다. 전통적 보안은 “이 입력이 들어오면 이것을 차단한다”는 결정론적 규칙에 기반하는데, AI에서는 이 접근이 불완전할 수밖에 없다.
둘째, 에이전트는 루프를 돈다. 전통적인 요청-응답이 아니라, 계획(Plan) → 실행(Act) → 관찰(Observe) → 다시 계획의 반복 루프다. 한 번의 사용자 요청이 내부적으로 수십 번의 LLM 호출과 도구 실행으로 이어질 수 있다. 보안 통제는 이 루프의 매 단계에 개입해야 한다.
셋째, 공격 표면이 분산되어 있다. 프롬프트 인젝션은 사용자 입력뿐 아니라 웹페이지, 이메일, 문서 등 에이전트가 소비하는 모든 외부 콘텐츠에 숨겨질 수 있다. 단일 진입점이 아니라 수많은 진입점을 방어해야 한다.
이런 특성 때문에 AI 보안 하네스의 아키텍처는 단순한 직선형 파이프라인이 아니라, 다층적이고 순환적인 구조를 취한다.
4개 영역, 10개 레이어
AI 보안 하네스의 아키텍처는 4개 영역에 걸쳐 10개 레이어로 구성된다. 이 구조를 한 문장으로 요약하면 이렇다.
횡단 계층이 전체를 관통하고, 기반 계층이 아래에서 받치며, 코어 파이프라인이 중앙에서 데이터 흐름을 보호하고, 진화 계층이 전체를 지속적으로 개선한다.
각 영역의 성격을 먼저 잡고, 이후 편에서 레이어별 상세를 다룬다.
횡단 계층 (Cross-cutting)
포함 레이어: 거버넌스 & 정책, 관찰 가능성 & 감사
이 두 레이어는 다른 모든 레이어에 걸쳐 작동하는 공통 기반이다. 거버넌스는 “왜 이 통제를 하는가”의 근거를 제공하고, 관찰 가능성은 “실제로 무슨 일이 일어나고 있는가”를 보여준다.
구성도에서 이 계층이 맨 위에 위치하는 이유가 있다. 기술적 통제가 아무리 정교해도, 정책이 없으면 일관성이 없고, 관찰이 없으면 효과를 알 수 없다. 모든 기술적 판단의 근거(거버넌스)와 모든 기술적 행위의 기록(감사)이라는 점에서, 이 계층은 하네스 전체의 신경계에 해당한다.
흔히 거버넌스를 “문서 작업”으로, 관찰 가능성을 “로그 수집”으로 가볍게 보는 경향이 있다. 하지만 AI 시스템에서 이 둘의 중요성은 전통 시스템과 차원이 다르다. 모델이 왜 그런 판단을 했는지 추적할 수 없으면, 인시던트 발생 시 원인 분석이 불가능하다. AI 사용 정책이 합의되지 않으면, 현장에서 제각각인 판단이 내려진다. 이 계층에 대한 상세는 3편에서 다룬다.
기반 계층 (Foundation)
포함 레이어: ID & 접근제어, 데이터 보호, 공급망 보안
AI 여부와 무관하게 필요한 보안의 기초다. 기존 보안 인프라를 최대한 활용하면서, AI 특화 확장만 추가하는 것이 원칙이다.
“기반”이라는 이름이 붙은 이유는, 이 계층이 없으면 위에 아무리 정교한 AI 보안을 쌓아도 무너지기 때문이다. 인증 없이 AI Gateway를 구축해봤자 누구나 접근할 수 있고, 데이터 분류 없이 DLP를 적용해봤자 무엇을 보호할지 모른다. 공급망 검증 없이 오픈소스 모델을 사용하면 백도어가 삽입된 모델을 그대로 배포할 수 있다.
다만 이 레이어들이 “일반적인 보안”이라고 해서 AI 맥락에서 특별한 것이 없다는 뜻은 아니다. 에이전트에게 서비스 ID를 부여하고 컨텍스트별 동적 권한을 적용하는 것, AI 학습 데이터에서 PII를 살균하는 것, 오픈소스 모델의 무결성을 검증하는 것은 전통 보안에는 없던 과제다. 이 계층의 상세도 4편에서 다룬다.
코어 파이프라인 (Core Security Pipeline)
포함 레이어: AI Gateway, 입력 가드레일, 컨텍스트 & 지식 보안, 오케스트레이션 & 제어, 도구 & 실행 격리, 출력 가드레일 & DLP
하네스의 핵심이다. AI 시스템을 통과하는 데이터 흐름의 각 지점에 보안 통제를 배치하는 파이프라인이다.
사용자 요청이 들어오면 AI Gateway가 인증과 정책을 적용하고, 입력 가드레일이 프롬프트 인젝션을 탐지하며, LLM이 추론을 수행한다. LLM이 도구 호출을 결정하면 오케스트레이션 레이어가 권한을 검증하고 HITL 필요 여부를 판단한다. 도구는 격리된 환경에서 실행되고, RAG 검색은 정책 인식 필터링을 거친다. 최종 출력은 출력 가드레일에서 민감정보 유출, 환각, 부적절한 콘텐츠를 검사한 후 사용자에게 전달된다.
여기서 중요한 점은 이 파이프라인이 직선이 아니라 루프를 포함한다는 것이다. 에이전트가 도구를 호출하고 결과를 받으면 다시 LLM으로 돌아가 추론을 계속한다. 이 루프가 여러 번 반복될 수 있고, 매 반복마다 보안 통제가 작동해야 한다. 코어 파이프라인의 입력 측 레이어(AI Gateway, 입력 가드레일, 컨텍스트 보안)는 5편에서, 실행과 출력 측 레이어(오케스트레이션, 도구 격리, 출력 가드레일)는 6편에서 다룬다.
진화 계층 (Evolution)
포함 레이어: 피드백 루프 & 라이프사이클
하네스 자체의 지속적 개선을 담당하는 계층이다.
구성도에서 이 계층이 맨 아래에 위치하면서 위로 피드백 화살표를 보내는 이유가 있다. 진화 계층은 다른 모든 레이어의 운영 데이터를 수집하여 하네스 전체를 갱신한다. 가드레일의 오탐률이 높으면 규칙을 튜닝하고, 새로운 공격 기법이 발견되면 필터를 업데이트하며, 모델이 업데이트되면 기존 하네스 구성의 호환성을 검증한다.
1편에서 “지속 적응”을 5대 원칙의 하나로 제시한 바 있다. 진화 계층은 그 원칙의 기술적 구현이다. 이 계층이 없으면 하네스는 시간이 지남에 따라 점점 효과를 잃는다. 모델은 진화하는데 하네스가 멈춰 있으면, 어느 순간 가드레일이 허울이 된다. 이 계층의 상세는 7편에서 다룬다.
10개 레이어 요약
각 레이어의 역할과 핵심 구성요소를 간략히 정리한다. 상세 설명은 3편~7편에서 영역별로 다룬다.
레이어 1: 거버넌스 & 정책 [횡단]
모든 기술적 통제의 근거가 되는 조직적 프레임워크다. AI 사용 정책, 리스크 분류 기준, 합의선 문서, 인시던트 대응 계획, 벤더 관리 정책을 포함한다. 기술이 아무리 뛰어나도 정책 없이는 일관된 보안을 유지할 수 없다. “왜 이것을 차단하는가?”라는 질문에 답할 수 있어야 현장의 저항을 넘을 수 있고, 감사를 통과할 수 있다.
레이어 2: 관찰 가능성 & 감사 [횡단]
모든 레이어에서 발생하는 이벤트를 수집, 분석, 추적하는 체계다. 기존 APM/SIEM과 달리, AI 시스템에서는 의사결정 추적이 추가로 필요하다. 단순 “API 호출됨”이 아니라 “에이전트 X가 정책 Y에 따라 위험 점수 0.7로 도구 Z를 호출함” 수준의 의미론적 로깅이 핵심이다. 입출력 로깅, 모델 드리프트 탐지, 감사 추적, 실시간 대시보드를 포함한다.
레이어 3: ID & 접근제어 [기반]
사람과 AI 에이전트 모두에 대한 인증과 인가를 관리한다. 제로 트러스트 원칙하에 모든 접근을 지속적으로 검증한다. AI 특화 요소로는 에이전트 IAM(서비스 ID 부여, 추적 가능 자격증명), 컨텍스트별 동적 권한(같은 에이전트라도 워크플로우에 따라 권한 차등), API 키 자동 순환과 이상 패턴 탐지 등이 있다.
레이어 4: 데이터 보호 [기반]
AI 시스템은 비정형 컨텍스트에서 민감 데이터와 일반 데이터가 혼재되므로, 전통적 DB 수준의 접근제어로는 부족하다. 4단계 데이터 분류(공개/내부/기밀/극비)를 기반으로 각 등급별 AI 처리 허용 범위를 정의한다. 외부 AI 전송 차단, 학습 데이터 살균, 벤더 데이터 정책 명확화가 핵심이다.
레이어 5: 공급망 보안 [기반]
AI 시스템은 외부 모델, 라이브러리, 데이터셋, 프레임워크에 크게 의존한다. 모델 출처 검증(무결성 해시, 백도어 탐지), AI SBOM 관리, 의존성 스캐닝, 학습 데이터 무결성 검증을 수행한다. 오픈소스 모델의 급격한 확산으로 이 레이어의 중요성이 빠르게 높아지고 있다.
레이어 6: AI Gateway [코어 파이프라인]
모든 AI 트래픽이 통과하는 중앙 제어점이다. 전통적 API Gateway와의 가장 큰 차이는, HTTP 레벨이 아닌 프롬프트 수준에서 정책을 적용한다는 점이다. 프롬프트/도구 수준 정책 집행, 모델 라우팅, 테넌트 격리, 비용 관리, 감사 추적을 수행한다. 하네스의 정책 집행 지점(Policy Enforcement Point) 역할을 한다.
레이어 7: 입력 가드레일 [코어 파이프라인]
AI 시스템에 도달하는 모든 입력을 검증하고 필터링하는 첫 번째 방어선이다. 직접/간접 프롬프트 인젝션 탐지, 탈옥 시도 탐지, 입력 살균, 파일/형식 검증을 수행한다. 결정론적 필터링, 시맨틱 분석(LLM 기반 분류기), 컨텍스트 격리의 3단계 방어 전략으로 구성한다.
레이어 8: 컨텍스트 & 지식 보안 [코어 파이프라인]
RAG 시스템의 벡터 DB, 지식 베이스, 메모리에 대한 보안이다. 임베딩 포이즈닝 방어, 정책 인식 검색(사용자 권한에 따라 검색 범위 동적 제한), 출처 검증, 컨텍스트 윈도우 보안을 포함한다. OWASP LLM Top 10 2025에서 신규 추가된 “벡터 및 임베딩 취약점”이 이 레이어에 해당한다.
레이어 9: 오케스트레이션 & 제어 / 도구 & 실행 격리 [코어 파이프라인]
에이전트의 계획-실행-관찰 루프를 관리하고, 외부 도구 실행을 격리하는 레이어다. 오케스트레이션 측에서는 HITL 설계, 명령 체계(시스템 프롬프트 우선순위 보장), 상태 관리, 서킷 브레이커를 담당한다. 실행 격리 측에서는 도구 화이트리스트, 샌드박스 실행, 시크릿 인젝션 프록시, 입출력 스키마 검증을 수행한다. Level 3 이상에서 핵심적으로 작동한다.
레이어 10: 출력 가드레일 & DLP [코어 파이프라인]
AI 시스템의 최종 출력이 사용자에게 전달되기 전에 검증하는 마지막 방어선이다. 민감정보(PII, 기밀, 시스템 프롬프트) 탐지 및 마스킹, 콘텐츠 안전성 검사, 환각 탐지(팩트체크, 신뢰도 점수), AI 생성 코드의 정적 분석을 수행한다.
레이어 11: 피드백 루프 & 라이프사이클 [진화]
하네스 자체의 지속적 개선을 담당한다. 가드레일 효과성 검증(거부율, 오탐률, 미탐률 추적), 모델 업데이트 대응(호환성 테스트), 위협 인텔리전스 반영, Red Team 피드백 루프, 정책과 운영의 괴리를 방지하는 엔트로피 관리를 포함한다.
Level별 활성 레이어 매핑
10개 레이어를 모든 AI 시스템에 전부 적용할 필요는 없다. 1편에서 제시한 자율성 등급(Level 1~4)에 따라 활성화해야 하는 레이어가 달라진다. 이것이 “자율성 비례 통제” 원칙의 실체다.
Level 1 (LLM 챗봇)에서 필요한 것
거버넌스 정책은 필수다. AI 사용 정책 없이 챗봇을 배포하면, 직원들이 기밀 데이터를 입력하는 것을 막을 근거가 없다. 관찰 가능성은 기본 수준으로 입출력 로깅 정도면 된다. 접근제어는 기존 RBAC/MFA를 적용한다. 데이터 보호는 필수로, 외부 LLM에 전송되는 데이터의 분류와 필터링이 핵심이다.
코어 파이프라인에서는 AI Gateway(권장), 입력 가드레일(필수), 출력 가드레일(필수)이 해당된다. 컨텍스트 보안, 오케스트레이션, 도구 격리는 Level 1에서는 해당없다. 외부 시스템에 접근하지 않으므로 이 레이어들이 필요 없다.
피드백 루프는 권장 수준이다. 가드레일의 효과를 정기적으로 리뷰하는 정도면 충분하다.
Level 2 (RAG)에서 추가되는 것
Level 1의 모든 것에 더해, 컨텍스트 & 지식 보안이 필수로 추가된다. RAG 시스템이 참조하는 벡터 DB에 대한 접근제어와 정책 인식 검색이 핵심이다. 일반 직원이 임원 전용 문서를 RAG을 통해 검색할 수 있으면 심각한 정보 유출이다.
AI Gateway도 이 Level부터 필수가 된다. 여러 모델과 지식 소스를 오가는 트래픽을 중앙에서 관리해야 하기 때문이다. 공급망 보안은 권장 수준으로, 사용하는 임베딩 모델과 벡터 DB의 무결성을 검증한다.
Level 3 (도구 사용 에이전트)에서 추가되는 것
위험도가 급격히 올라가는 전환점이다. 에이전트가 외부 시스템에 쓰기 작업을 수행하므로, 오케스트레이션 & 제어와 도구 & 실행 격리가 필수로 활성화된다.
관찰 가능성도 강화 수준으로 올라간다. 단순 입출력 로깅이 아니라, 에이전트의 의사결정 체인 전체를 추적해야 한다. 접근제어도 강화되어, 에이전트별 서비스 ID와 동적 권한이 적용된다. 공급망 보안은 필수가 된다. 에이전트가 사용하는 도구와 라이브러리의 무결성을 검증해야 한다.
피드백 루프도 필수가 된다. 에이전트의 행동 패턴을 지속적으로 모니터링하고, 이상 행위를 탐지하며, 가드레일을 튜닝해야 한다.
Level 4 (자율 멀티에이전트)에서 추가되는 것
Level 3의 모든 것이 최대 강도로 적용되고, 추가로 에이전트간 상호 인증, 캐스케이딩 방어(한 에이전트의 타협이 전체로 전파되는 것을 방지), 행동 모니터링(장시간 자율 실행 중 드리프트 탐지), 서킷 브레이커(토큰 소모 제한, 재귀 루프 탐지, 타임아웃)가 필수가 된다.
이 Level에서는 사실상 모든 레이어가 필수이며, 각 레이어의 깊이도 최대다. Level 4 시스템을 배포하려면 하네스의 전체 스택이 성숙되어 있어야 한다. AWS도 Scope 4 구현에 대해 “하위 Scope의 리스크를 충분히 다룰 수 있는 역량이 확인된 후에 신중하게 접근하라”고 권고한다.
데이터 흐름으로 보는 하네스 동작
아키텍처를 정적으로 이해하는 것과, 실제 동작을 이해하는 것은 다르다. Level 3(도구 사용 에이전트) 기준으로 사용자 요청이 하네스를 통과하는 전체 흐름을 추적해 보자.
1단계: 사용자 요청 → AI Gateway
사용자가 “지난달 매출 보고서를 이메일로 보내줘”라고 요청한다. 이 요청은 먼저 AI Gateway에 도달한다. Gateway는 사용자의 인증 토큰을 검증하고, 이 사용자가 매출 데이터에 접근할 권한이 있는지 확인한다. 이 요청의 데이터 민감도에 따라 적절한 모델로 라우팅한다. 내부 데이터가 포함될 수 있으므로 온프레미스 모델로 라우팅하는 정책이 적용될 수 있다. 이 모든 과정이 로깅된다.
2단계: AI Gateway → 입력 가드레일
라우팅된 요청이 입력 가드레일에 도달한다. 결정론적 필터가 알려진 공격 패턴을 스캔하고, LLM 기반 분류기가 프롬프트 인젝션 시도 여부를 판단한다. 이 요청은 정상으로 판별되어 통과한다.
3단계: LLM 추론
모델이 요청을 분석하고, 두 가지 도구 호출이 필요하다고 판단한다. 첫째, 매출 데이터 조회 API를 호출하여 보고서를 생성한다. 둘째, 이메일 발송 API를 호출하여 보고서를 전송한다.
4단계: 오케스트레이션 & 제어
모델의 도구 호출 의도가 오케스트레이션 레이어로 전달된다. 오케스트레이션은 두 가지 확인을 수행한다. 매출 데이터 조회는 읽기(Read) 도구이고, 이 에이전트의 화이트리스트에 포함되어 있으며, 이 사용자의 권한 범위 내이므로 자동 승인된다. 이메일 발송은 쓰기(Write) 도구이고, HITL 정책에 따라 사용자 확인이 필요하다. 오케스트레이션은 실행을 일시 중지하고 사용자에게 확인을 요청한다. “다음 수신자에게 매출 보고서를 발송합니다: sales-team@company.com. 진행할까요?”
5단계: 도구 실행 격리
사용자가 승인하면, 도구 실행이 격리된 샌드박스에서 수행된다. 매출 데이터 조회 API는 시크릿 인젝션 프록시를 통해 호출된다. 에이전트는 실제 DB 자격증명을 볼 수 없고, 프록시가 아웃바운드 요청에 자격증명을 주입한다.
6단계: 컨텍스트 & 지식 보안
보고서 생성 과정에서 추가 컨텍스트가 필요하면 RAG 검색이 수행된다. 정책 인식 검색이 작동하여, 이 사용자의 접근 등급에 맞는 문서만 검색 결과에 포함된다.
7단계: 출력 가드레일 & DLP
생성된 보고서와 이메일 본문이 출력 가드레일을 통과한다. PII 스캐너가 개인정보 포함 여부를 검사하고, DLP 규칙이 기밀 데이터의 부적절한 포함을 탐지한다. 시스템 프롬프트 유출 검사도 수행된다.
8단계: 사용자 응답
모든 검사를 통과한 최종 결과가 사용자에게 전달된다. “매출 보고서를 생성하여 sales-team@company.com으로 발송했습니다.”
이 전체 흐름의 모든 단계에서 관찰 가능성 계층이 로그를 수집하고, 거버넌스 정책이 각 판단의 근거를 제공한다. 문제가 발생하면 감사 추적을 통해 어느 단계에서 무슨 판단이 내려졌는지 전체 리니지를 확인할 수 있다.
아키텍처의 실무적 함의
이 아키텍처를 보고 “이걸 다 구축해야 하나?”라는 생각이 드는 것은 자연스럽다. 몇 가지를 짚어두겠다.
한 번에 다 구축하지 않는다
8편에서 다룰 구축 로드맵의 핵심이지만, 여기서 미리 말해두자. Phase 1에서는 거버넌스 정책과 가시성(인벤토리)만 확보해도 충분하다. Phase 2에서 AI Gateway와 입출력 가드레일을 추가하고, Phase 3에서 에이전트 보안을 고도화한다. Level 1~2 시스템만 운영하는 조직이라면, 코어 파이프라인의 절반(오케스트레이션, 도구 격리)은 당장 필요 없다.
기존 인프라를 최대한 활용한다
AI Gateway는 기존 API Gateway(Kong, Envoy 등)에 플러그인을 추가하는 것으로 시작할 수 있다. DLP는 기존 DLP 솔루션에 AI 출력 스캐닝 규칙을 추가한다. SIEM 연동은 기존 로그 파이프라인에 AI 전용 로그 소스를 추가한다. 완전히 새로운 스택을 구축하는 것이 아니다.
Level을 먼저 분류한다
조직 내 AI 시스템의 인벤토리를 작성하고, 각 시스템의 Level을 분류하는 것이 모든 것의 출발점이다. Level이 정해져야 어떤 레이어가 필요한지, 어떤 깊이로 구현해야 하는지가 결정된다. Level 분류 없이 하네스를 구축하면, 과잉 통제와 과소 통제가 혼재하게 된다.
다음 편 예고
이번 글에서 아키텍처의 전체 그림을 그렸다. 다음 편부터 각 영역을 깊이 파고든다. 3편에서는 횡단 계층인 거버넌스와 관찰 가능성을 다룬다. AI 사용 정책의 합의선을 어떻게 설계하는지, Shadow AI를 어떻게 파악하는지, 에이전트의 의사결정을 어떻게 추적하는지, 기존 SIEM과 어떻게 연동하는지를 구체적으로 설명한다.