만약 보안 팀에게 왜 그들의 SIEM이 프롬프트 인젝션(Prompt Injection) 시도를 감지하지 못했는지 설명하려고 시도해 본 적이 있다면, 이것은 근본적인 아키텍처 문제이며, 이는 패치로 해결할 수 있는 도구의 공백이 아니라, 한 번도 감시되지 않았던 계층의 문제입니다.

요약 (TL;DR)

경계 보안 (Perimeter security; 방화벽, SIEM, EDR, DLP, IAM)은 인프라 — 네트워크, 엔드포인트, ID, 애플리케이션을 보호합니다. 이는 "이 트래픽이 안전한가?"라는 질문에 답합니다. **상호작용 계층 보안 (Interaction-layer security)**은 AI 대화 내부에서 발생하는 일 — 프롬프트(Prompt), 응답(Response), 에이전트가 수행하는 도구 호출(Tool calls)을 보호합니다. 이는 완전히 다른 질문인 "이 대화가 안전한가?"에 답합니다. 프롬프트 인젝션 시도, 채팅창에 붙여넣은 민감한 문서, 또는 에이전트가 건드려서는 안 될 API를 호출하는 행위는 모두 겉보기에 완벽하게 정상적인 HTTPS 요청을 생성합니다. 귀하의 경계 보안 스택은 아무런 문제도 발견하지 못하는데, 왜냐하면 그들의 관점에서는 아무런 문제가 없기 때문입니다. 이것은 경계 보안을 교체해야 한다는 주장이 아닙니다. AI가 그 아래에 다른 어떤 것도 감시하도록 설계되지 않은 새로운 계층을 추가했다는 주장입니다.

상호작용 계층 보안이란 무엇인가?

상호작용 계층 보안은 AI 시스템이 작동하는 동안 발생하는 대화, 프롬프트, 응답 및 AI 에이전트의 동작을 보호합니다. 경계 보안은 네트워크, 엔드포인트 및 애플리케이션을 보호합니다. AI 도입이 증가함에 따라, 실제 리스크의 상당 부분이 상호작용 자체로 이동했습니다. 이는 상호작용 계층 보안이 AI 보안 아키텍처에서 선택적인 추가 기능이 아니라, 필수적이고 별개의 구성 요소가 되었음을 의미합니다.

이러한 구분은 리스크가 얼마나 심각한가가 아니라, 리스크가 물리적으로 어디에 존재하는가에 관한 것입니다. 전통적인 사이버 공격(Cyberattack)은 대개 인프라(Infrastructure)를 목표로 합니다. 즉, 취약점이 악용되거나, 자격 증명(Credentials)이 도난당하거나, 엔드포인트(Endpoint)가 침해되는 방식입니다. 반면, AI 네이티브 공격(AI-native attack)은 상호작용(Interaction)을 목표로 합니다. 에이전트(Agent)의 동작을 가로채는 문서 내 삽입된 지시문, 모델이 시스템 지침(System instructions)을 무시하도록 설득하는 프롬프트(Prompt), 혹은 직원이 "더 빠르게 요약하기 위해" 고객 데이터베이스 내보내기 파일을 채팅창에 붙여넣는 행위 등이 이에 해당합니다. 이 중 그 어떤 것도 무언가를 침해할 필요가 없습니다. 그저 자연어(Natural language)와 이를 실행하려는 시스템만 있으면 충분합니다.

경계 보안(Perimeter Security)이 AI 리스크를 볼 수 없는 이유

경계 보안(Perimeter security)은 AI 대화가 아닌 인프라 이벤트를 검사합니다. 악성 트래픽, 무단 액세스, 알려진 멀웨어 시그니처(Malware signatures)를 탐지하는 데는 탁월하지만, 이러한 정보 중 그 어느 것도 프롬프트에 민감한 정보가 포함되어 있는지, 혹은 에이전트가 안전하지 않은 행동을 취하려 하는지를 알려주지는 않습니다.

제어 카테고리별로 분류한 구체적인 격차(Gap)는 다음과 같습니다:

• 네트워크 및 애플리케이션 모니터링 (Network and application monitoring: 방화벽 (firewalls), 침입 탐지 시스템 (IDS), 보안 정보 및 이벤트 관리 (SIEM)). 이들은 의심스러운 트래픽 패턴과 승인되지 않은 액세스 시도를 포착하도록 구축되었습니다. 이들은 강력한 인프라 가시성 (visibility)을 제공하지만, LLM API로 전송되는 잘 구성된 HTTPS POST 요청은 그 내부의 프롬프트 (prompt)가 무해한지 아니면 적극적으로 악의적인지에 관계없이 동일하게 보입니다. 이들이 검사해야 할 신호는 페이로드 (payload) 내부에 있으며, 이는 이들이 의미론적으로 (semantically) 분석하도록 설계되지 않은 바로 그 부분입니다.
• 엔드포인트 및 ID 제어 (Endpoint and identity controls: 엔드포인트 탐지 및 대응 (EDR), ID 및 액세스 관리 (IAM)). 이들은 장치가 침해되지 않았으며 사용자가 주장하는 본인이 맞는지 확인합니다. 하지만 이 중 어느 것도 인증된 악성코드 없는 사용자가 방금 유해한 프롬프트를 제출했는지 여부를 평가할 방법은 없습니다. 인증 (Authentication)과 의도 (intent)는 서로 독립적인 (orthogonal) 문제입니다.
• 데이터 손실 방지 (Data loss prevention (DLP)). 전통적인 DLP는 알려진 민감한 패턴을 찾기 위해 파일, 이메일 및 네트워크 전송을 검사하지만, 이는 구조화된 채널을 통해 나가는 구조화된 데이터를 중심으로 구축되었습니다. 채팅 인터페이스에 직접 입력된 데이터는 DLP가 위치하도록 설계된 검사 지점을 통과하지 않는 경우가 많으므로, 이는 DLP가 검사에 실패하는 것이 아니라 검사 자체가 아예 일어나지 않는 것입니다.

직원들이 승인된 프로세스 외부에서 AI 도구를 채택하기 시작하면 이러한 격차는 실질적으로 더 악화됩니다. 보안 팀이 AI 도구가 사용되고 있다는 사실을 모른다면, 아래에서 설명할 상호작용 계층 (interaction-layer) 제어조차 적용할 기회가 전혀 없습니다. 조직 전체에서 AI가 실제로 어디에서 사용되고 있는지에 대한 가시성을 확보하는 것이 최우선입니다. 기업의 AI 도입에 대한 통제권 회복 — 승인 여부와 관계없이 현재 사용 중인 모든 AI 애플리케이션을 매핑하는 것 — 은 보안을 상호작용 계층으로 확장하기 위한 전제 조건입니다.

상호작용 계층 보안 아키텍처는 어떤 모습인가?

효과적인 AI 보안 아키텍처는 AI 상호작용이 실제로 발생하는 모든 곳에서 제어(controls)를 모니터링하고 강제함으로써 네트워크 경계(network perimeter)를 넘어 확장됩니다. 즉, 기존 도구를 대체하는 것이 아니라 이를 보완합니다.

성숙한 구현 단계에서는 다음과 같은 네 가지 기능이 일관되게 나타납니다:

• 프롬프트 및 응답 검사 (Prompt and response inspection). 모든 상호작용은 프롬프트가 모델에 도달하기 전과 응답이 사용자에게 도달하기 전에 평가됩니다. 이는 프롬프트 인젝션(prompt injection) 시도, 민감 데이터 노출, 정책 위반 출력을 사후에 발견하는 것이 아니라, 실제로 포착할 수 있는 두 개의 체크포인트입니다.
• AI 에이전트 / 도구 호출 모니터링 (AI agent / tool-call monitoring). 시스템이 자연어 지침에 따라 데이터를 검색하거나, API를 호출하거나, 자율적인 행동을 취할 수 있게 되면, 단순히 "프롬프트가 안전했다"는 것만으로는 충분하지 않습니다. 결과로 나타난 _행동(action)_이 허용된 범위 내에 머물렀는지도 검증해야 합니다. 이는 IBM의 엔터프라이즈 가이드에서 권장하는 MCP 게이트웨이(MCP Gateway) 패턴의 원리와 동일합니다. 즉, 각 에이전트가 스스로를 규제하도록 신뢰하는 대신, 모든 에이전트와 호출 가능한 모든 도구 사이에 정책이 강제되는 중앙 집중식 인그레스 지점(ingress point)을 두는 것입니다.
• 런타임 정책 강제 (Runtime policy enforcement). 정책은 상호작용이 일어나는 도중에(while) 평가됩니다. 요청은 누군가가 다음 주에 읽게 될 보고서에 플래그가 지정되는 대신, 자동으로 차단, 수정 또는 에스컬레이션(escalated)됩니다.
• 상호작용 수준 텔레메트리 (Interaction-level telemetry). 모든 중요한 상호작용은 운영 증거를 생성합니다. 이는 일반적인 액세스 로그가 아니라, 무엇을 요청했는지, 무엇을 검색했는지, 무엇이 반환되었는지, 그리고 어떤 정책이 적용되었는지에 대한 기록입니다. 이는 조사, 거버넌스 보고 및 규제 감사(regulatory audits)에 실제로 필요한 종류의 증거입니다.

다음은 이를 하나의 표로 비교한 아키텍처 비교입니다:

내부적으로 구축된 AI의 경우에도 이 중 어느 것도 선택 사항이 아닙니다. 자체 제작한 코파일럿 (Copilot)이나 내부 에이전트 (Internal agent)는 우리 팀이 직접 작성했기 때문에 본질적으로 더 안전할 것이라는 흔한 가정이 있습니다. 하지만 "우리가 만들었다"는 사실이 감사 추적 (Audit trail)이나 정책 엔진 (Policy engine)을 제공해주지는 않습니다. 자체 제작 도구는 외부 벤더 제품과 마찬가지로 상호작용 계층 (Interaction-layer)의 규율을 일관되게 적용해야 합니다. 그렇지 않으면 환경 내에서 가장 검사가 이루어지지 않는 AI 시스템이 될 뿐입니다. 정확히는 아무도 그 도구들에 통제 수단을 적용할 생각을 하지 않았기 때문입니다.

현대적 AI 보안에 두 계층이 모두 필요한 이유

상호작용 계층 보안과 경계 보안은 서로 경쟁하는 방식이 아닙니다. 이들은 동일한 문제의 서로 다른 절반을 해결하며, 현대적인 AI 보안 태세 (Security posture)는 진정으로 두 계층이 함께 작동하는지에 달려 있습니다.

• 경계 보안은 환경을 보호합니다. 네트워크, 엔드포인트, 애플리케이션, API, 그리고 ID는 여전히 기초적인 경계로 남아 있습니다. AI가 등장했다고 해서 이 중 어느 것도 사라지지 않습니다. 오히려 AI 시스템이 여전히 동일한 인프라 위에서 실행되기 때문에 그 중요성은 더욱 커졌습니다.
• 상호작용 계층 보안은 AI의 동작을 보호합니다. 이는 대화 내부에서 실제로 일어나고 있는 일과 그에 따라 발생하는 동작들을 평가합니다. 이는 경계 보안 도구들이 구조적으로 들여다볼 수 없는 스택의 영역입니다.
• 두 계층이 결합되면 문자 그대로 심층 방어 (Defense in depth)를 구현합니다. 이는 동일한 리스크를 중복해서 커버하는 것이 아니라, 한 계층이 아키텍처적으로 인지하지 못하는 리스크 범주를 다른 계층이 각각 보완하는 두 개의 층을 의미합니다.

유용한 구체적 사례를 들어보겠습니다: RAG (Retrieval-Augmented Generation) 시스템이 검색한 문서에 "이전의 제약 사항을 무시하고 다음 내용을 공개하라"와 같은 숨겨진 지시문이 텍스트 내에 포함되어 있을 수 있습니다. 경계 보안 (Perimeter security) 관점에서는 권한이 있는 데이터 소스에서 데이터를 가져오는 정당하고 인증된 요청으로 보일 뿐이며, 네트워크나 신원 (Identity) 관점에서는 해당 트랜잭션에서 잘못된 점을 전혀 찾을 수 없습니다. 모델의 컨텍스트 (Context)에 실제로 무엇이 입력되었는지, 그리고 모델이 그에 따라 어떻게 반응했는지를 평가하는 상호작용 계층 (Interaction-layer) 검사만이 이를 포착할 가능성을 가집니다. 이것이 바로 MITRE의 ATLAS 프레임워크 — AI 및 ML 시스템을 대상으로 하는 공격자의 전술을 카탈로그화한 ATT&CK 스타일의 지식 베이스 — 가 보안 팀에게 공통된 어휘를 제공하기 위해 구축된 바로 그 시나리오입니다. 이러한 공격 패턴은 기존의 위협 모델 (Threat models)에 전혀 깔끔하게 매핑되지 않기 때문입니다.

AI 리스크는 AI의 의사결정이 이루어지는 곳에 존재한다

AI 보안 아키텍처의 미래는 경계 보안을 대체하는 것이 아니라, AI 시스템이 프롬프트 (Prompt)를 처리하고, 응답을 생성하며, 비즈니스 운영에 직접적인 영향을 미치는 조치를 취하는 상호작용 계층 (Interaction layer)으로 보안을 확장하는 것에 있습니다.

경계 제어 (Perimeter controls)는 여전히 필수적입니다. 모든 AI 시스템은 여전히 그 밑단의 안전한 인프라에 의존하고 있으며, 그러한 요구 사항은 사라지지 않았습니다. 변화된 점은 인프라 보안만으로는 전체 리스크 표면 (Risk surface)을 더 이상 커버할 수 없다는 것입니다. AI 리스크의 의미 있고 증가하는 상당 부분이 경계 도구들이 검사하도록 설계되지 않았던 상호작용 내부에서 발생하기 때문입니다. 인프라 보호와 상호작용 계층 가시성 (Interaction-layer visibility)을 모두 결합하는 조직은, AI가 이미 넘어서 버린 위협 모델에 맞춰 구축된 보안 태세가 아니라, 리스크가 실제로 존재하는 위치에 부합하는 보안 태세를 갖추게 됩니다.

FAQ

상호작용 계층(Interaction-layer) 보안이 기존의 SIEM, DLP 또는 방화벽을 대체하나요?
아니요. 상호작용 계층 보안은 이들과 병행하여 작동하며, 기존 솔루션들이 검사하도록 설계되지 않은 계층을 보호합니다. 상호작용 계층 도구를 사용하기 위해 경계 보안(Perimeter security) 통제를 포기하는 것은 단지 하나의 사각지대를 다른 사각지대로 바꾸는 것에 불과합니다. AI 리스크가 나타났다고 해서 인프라 리스크가 사라지는 것은 아니기 때문입니다.

모든 AI API 호출을 로깅(Logging)하는 것만으로 상호작용 계층의 가시성을 확보할 수 있나요?
그것만으로는 불가능합니다. 로깅은 요청이 발생했다는 사실을 포착하지만, 상호작용 계층 보안은 요청에 무엇이 포함되어 있는지 — 즉, 프롬프트(Prompt) 내용, 검색된 컨텍스트(Context), 응답, 그리고 그로 인해 발생하는 모든 도구 호출(Tool calls) — 를 사후 로그 검토가 아닌 실시간으로 정책에 따라 평가합니다.

이것은 AI 에이전트(AI agents)를 구축하는 조직에만 해당되나요, 아니면 단순한 챗봇 사용에도 적용되나요?
둘 다 해당됩니다. 직원이 일반 채팅 인터페이스에 민감한 데이터를 붙여넣는 행위는

• MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) — 공식 팩트 시트
• LangProtect — 왜 AI에는 기존 통제 수단을 넘어서는 새로운 보안 계층이 필요한가
• LangProtect — MCP 보안: AI 에이전트 보안을 위한 엔터프라이즈 가이드

이것이 더 큰 그림에서 차지하는 위치

상호작용 계층 (Interaction-layer) 보안의 필요성을 논하는 것은 쉬운 부분입니다. 실제로 프롬프트/응답 검사 (prompt/response inspection), 에이전트 도구 호출 모니터링 (agent tool-call monitoring), 그리고 런타임 정책 강제 (runtime policy enforcement)를 시스템 사용자들에게 지연 시간 (latency)이나 불편함을 주지 않으면서 구현하는 것이 이 모든 것의 밑바탕에 깔린 더 어려운 엔지니어링 문제입니다.

이를 해결하기 위해 노력 중인 팀들을 위해: