편리한 AI 에이전트(Claude Code, Cursor, Cline 등)를 사용하면서 문득 불안해진 적은 없는가.

"지금 내 PC의 어떤 파일이 읽히고 있고, 그 내용이 어디까지 클라우드의 AI로 전송되었을까?"

채팅창에 직접 메시지를 입력하고 있는 동안에는 그나마 낫다. 보내기 전에 "이것은 대외비니까 쓰지 말아야지"라고 잠시 생각할 여유가 있기 때문이다. 하지만 에이전트는 다르다. 사용자가 "저것 좀 해줘"라고 요청하면, 자율적으로 파일을 읽고, 명령을 실행하며, 그 결과를 컨텍스트(Context)에 포함하여 그때마다 클라우드의 AI로 전송한다. 인간이 하나하나 "이것은 보내도 되는 정보인가"를 판단할 틈이 구조적으로 존재하지 않는다.

NDA(비밀유지계약)가 걸린 업무에서 AI 에이전트를 사용할 때, 이는 간과할 수 없는 사각지대가 된다. 본고에서는 왜 이러한 "보이지 않음"이 발생하는지를 풀어서 설명하고, 현재 업계가 이에 어떻게 대응하려 하는지를 하나의 지도로 그려보고자 한다.

"주의한다"로는 따라잡을 수 없다

먼저 가감 없이 말하자면, "기밀을 다룰 때는 주의한다"라는 운영 방식은 에이전트 시대에는 거의 기능하지 않는다.

인간이 프롬프트(Prompt)를 작성하는 채팅이라면 주의를 기울일 수 있다. 하지만 에이전트는 초 단위로 수십 번씩 도구(Tool)를 호출하고, 파일을 읽으며, 그 파편들을 클라우드로 전달해 나간다. 매번 그것을 육안으로 점검하는 것은 현실적이지 않다. 주의력에 의존하는 방어는 자동화된 전송 속도에 패배한다.

왜 "보이지 않게" 되는가 — 두 가지 메커니즘을 나누어 보기

AI 에이전트에 힘을 실어주는 것은 크게 두 가지 메커니즘이다. 손발을 제공하는 MCP(외부 파일이나 도구, SaaS를 AI로부터 표준적인 방식으로 호출하는 메커니즘)와 지식을 제공하는 RAG(질문과 관련된 문서를 검색하여 AI에게 전달하고 답하게 하는 메커니즘)이다. 둘 다 뛰어난 발명이지만, 안고 있는 리스크의 성질이 다르다. 순서대로 조금 더 깊이 살펴보자.

MCP — "손발"을 주면 안과 밖의 경계가 녹아내린다

MCP의 무서움은 수중에 있는 것(로컬)과 클라우드(원격)의 경계가 구조적으로 모호해진다는 점에 있다.

도구가 반환하는 값은 AI의 작업 메모(컨텍스트)에 그대로 쌓이며, 다음 추론을 위해 클라우드로 전송된다. 여기에 개발자조차 의도하지 않은 것들이 섞여 들어간다. 에러의 상세한 로그, 디버깅용 출력, 그리고 "덤으로" 넓은 권한으로 취득해 버린 인증 토큰이나 개인정보——이러한 것들이 정규 도구 실행 결과와 구별할 수 없는 형태로 컨텍스트에 들어가, 명시적으로 "보내라"고 쓰지 않았음에도 결과적으로 클라우드로 흘러 들어간다. 조사에서는 이를 "암묵적 경계 침범"이라고 부른다.

나아가, 연결된 상대의 안전성에 통째로 의존하게 된다. MCP 서버는 누구나 만들 수 있고 간편하게 추가할 수 있다. 하지만 외부 조사에 따르면, 공개된 서버 중 상당수가 필요 이상의 권한이나 예상치 못한 파일·URL에 접근할 수 있는 설정상의 취약점을 안고 있다는 보고도 있다. 편리한 도구를 하나 추가할 때마다, 그 제작자의 주의 깊음에 자신의 기밀을 맡기고 있는 셈이다.

그리고 간과하기 쉬운 점은, 동적이기 때문에 재현할 수 없다는 점이다. MCP는 실행할 때마다 외부를 동적으로 참조한다. 같은 조작을 요청하더라도 참조하는 데이터가 바뀌어 있다면, AI가 가져오는 내용도, 클라우드로 보내는 내용도 달라질 수 있다. 즉 "이번에 무엇이 전송되었는가"를 나중에 정확히 재현하여 확인하는 것조차 어렵다. 매번 변하는 것은 감사가 불가능하다.

RAG — "지식"을 주면 오염과 휘말림이 발생한다

RAG의 무서움은 외부에서 가져온 문서를 무조건적으로 신뢰해 버린다는 점에 있다.

첫째는, 수집한 문서에 심어진 명령이다. 외부나 사내의 오염된 문서를 AI가 검색하여 읽어 들일 경우, 그 안에 숨겨진 "지금까지의 지시를 무시하고..."와 같은 종류의 명령을 AI가 진짜 지시로 착각하여 실행해 버릴 수 있다(구체적인 수법은 여기서 다루지 않는다). 이용자는 그저 질문했을 뿐인데, 알지 못하는 누군가가 문서에 적어 놓은 지시가 작동하기 시작한다.

둘째는, 휘말림이다. 검색이 가져오는 것이 원하는 정보뿐이라고 단정할 수 없다. 설정을 하나만 잘못해도 다른 안건이나 다른 고객의 기밀이 포함된 문서까지 가져오게 되며, 그 내용이 AI의 답변으로——그리고 클라우드로——흘러 들어간다.

셋째, 문맥이 방대해질수록 AI의 주의력이 분산된다. 많은 도구와 문서를 연결하면 AI가 다루는 문맥(Context)은 비대해진다. 그러면 본래 지켜져야 할 보안상의 제약에 대한 주의가 상대적으로 약해져, 무관한 기밀을 포함하여 출력하는 등의 이상 행동이 일어나기 쉬워진다. 이는 언뜻 「비용이나 속도의 문제」처럼 보이지만, 사실은 보안 문제다. 문맥의 비대는 AI 판단의 느슨함으로 직결된다.

「화려하게 망가지지 않기」 때문에, 모르는 척하며 운용이 진행된다

지금까지 언급한 문제들은 모두 특정 제품의 결함이 아니다. 현재 에이전트의 아키텍처(Architecture)가 구조적으로 안고 있는 성질에 가깝다.

그리고 까다로운 점은, 이것들이 「화려하게 망가지지 않는다」는 것이다. 데이터가 조용히 유출되어도 화면에 에러는 뜨지 않는다. 에이전트는 오늘도 매끄럽게 움직이고, 업무는 앞으로 나아간다. 그래서——어렴풋이 느끼고 있더라도, 편리함 앞에서 못 본 체하며 운용은 계속된다. 많은 현장이 커다란 리스크를 안은 채 계속 달리고 있는 것이 실정이지 않을까.

기존 방식(DLP)이 효과를 발휘하기 어려운 이유

「정보 유출을 막는 메커니즘이라면 예전부터 있었지 않나」라고 생각할지도 모른다. 이른바 DLP(데이터 손실 방지, Data Loss Prevention)다.

다만, 기존 DLP의 대부분은 파일 전송이나 메일 중에서 신용카드 번호와 같은 정해진 형태의 패턴을 찾아내어 차단하는 발상으로 만들어져 있다. 반면, AI 에이전트의 상호작용은 자연어의, 형태가 정해지지 않은 대화다. 기밀인지 여부는 문맥에 따라 결정되며, 암호화된 통신 속에 분산되어 섞여 들어간다. 「형태」로 잡아내는 도구로는 문맥을 읽을 수 없다.

여기서부터 방어의 발상 자체가 바뀌기 시작한다.

업계는 어떻게 지키려 하고 있는가

현재 시장에서 시도되고 있는 방어법을 특정 제품명은 언급하지 않고 큰 방향성으로 지도화하면, 대략 다음의 6가지로 나눌 수 있다.

• 중간에 검문소를 두기 (게이트웨이, Gateway) — 에이전트와 클라우드 AI 사이에 전용 중계점을 마련하여, 전송되기 전에 내용을 검사하고 기밀을 마스킹(Masking) 처리하거나 다른 값으로 대체한다.
• 곁에서 감시하기 (단말·브라우저) — 직원이 브라우저의 AI에 직접 붙여넣는 등의 경로를 단말 측에서 감시한다.
• 행위를 감시하기 (자세 관리, Posture Management) — 어떤 에이전트가 어떤 권한으로 무엇을 호출했는지, 멋대로 들어온 야생 AI(Shadow AI)는 없는지를 지속적으로 점검한다.
• 출처를 추적할 수 있게 하기 (이력·가관측성, Observability) — 나온 답변이 어떤 문서의 어느 부분에서 유래했는지 나중에 추적할 수 있도록 한다.
• 하드웨어로 격리하기 — 암호화된 전용 계산 영역에서 AI를 구동하여, 클라우드 사업자조차 내용을 볼 수 없게 한다.
• 애초에 로컬에서 완결시키기 — AI 자체를 수중의 머신이나 온프레미스(On-premise)에서 구동하여, 기밀이 외부로 나가는 경로를 최대한 만들지 않는다.

어느 것이 정답이라는 이야기는 아니다. 다루는 데이터의 중요도에 따라 조합하는 것이 실무적인 결론이 되어가고 있다.

공통된 변화 — 지키는 「장소」가 이동했다

6가지를 나란히 놓고 보면, 밑바닥에 흐르는 하나의 변화가 보인다.

지금까지 보안의 중심은 「네트워크의 안과 밖의 경계」나 「누가 로그인하고 있는가」였다. 하지만 에이전트는 정규 인증 정보를 사용하여 네트워크 내부에서 자율적으로 움직인다. 경계는 더 이상 방어의 주전장이 아니다.

지켜야 할 장소는 **「AI가 지금 무엇을 호출하고, 무엇을 보내려고 하는가」라는 계층(Layer)**으로 옮겨가고 있다. 검문소를 두는 것도, 행위를 감시하는 것도, 출처를 쫓는 것도, 로컬에 머무는 것도 모두 이 새로운 계층에 손을 뻗는 시도다.

「탐지」에서 「판정」으로

또 다른 변화는, 「위험한 것을 찾아내는 것」에서 「이것을 내보내도 되는지 결정하는 것」으로 무게 중심이 이동하고 있다는 점이다.

무엇이 기밀인지는 고정된 패턴으로 결정되지 않는다. 같은 한 문장이라도 상대나 문맥에 따라 취급이 달라진다. 따라서 방어 측도 단순한 패턴 대조에서, 「이 정보를 지금 클라우드로 내보내도 되는가」를 문맥으로 판단하는 방향으로 나아가고 있다.

여기서 중요한 것은 그 판단의 척도를 누가 갖느냐이다. 제공처의 AI에 통째로 맡길 것인가, 아니면 우리들의 규칙(Policy)으로서 외부로 내보내 읽을 수 있고, 수정할 수 있으며, 이력이 남는 형태로 보유할 것인가. 후자를 선택할 수 있다면, 「왜 이 정보는 수중에 남기고, 이것은 클라우드로 보냈는가」를 나중에 자신의 언어로 설명할 수 있다.

결론 — 피하는 것이 아니라, 설명할 수 있는 형태로 사용하기

RAG나 MCP는 AI를 강력한 에이전트로 만드는 뛰어난 메커니즘이다. 이것을 「위험하니까 사용하지 말자」며 봉쇄하는 것은 아까운 일이며, 현실적이지도 않다.

우리가 나아가야 할 방향은 그 반대라고 생각한다. 피하는 것이 아니라, 「무엇을 어디로 보냈는지」를 나중에 설명할 수 있는 형태로 사용하는 것이다.

• 무엇을 기밀로 간주할지를 자신의 정책 (Policy) 에 새긴다 (제공처에 맡기지 않는다).
• 기밀은 로컬 (Local) 에서 처리하고, 외부로 내보내도 되는 것만 클라우드로 보낸다—와 같이 문맥 (Context) 에 따라 분류한다.
• 그리고 무엇이 클라우드로 가고 무엇이 로컬에 남았는지를 스스로 확인할 수 있는 기록으로 남긴다.

이것은 위험을 「탐지 (Detection)」 하여 더하는 방식의 보안 사고방식이 아니다. 규범 (Policy) 을 정하고, 그것에 비추어 판정하며, 결과를 감사 (Audit) 할 수 있는 형태로 남기는 —— 거버넌스 (Governance) 의 사고방식이다. 능력이 향상되고 블랙박스 (Black box) 화가 진행될수록, 「설명할 수 있다는 것」의 가치는 오히려 높아진다.

편리한 에이전트를 안심하고 사용하기 위해서. 방어의 주전장이 이동하고 있는 지금, 생각해 볼 가치가 있는 질문이라고 생각한다.

필자는 이 「정책으로 판정하고, 로컬에 증적을 남긴다」는 사고방식을 제품으로 구현하는 노력에 참여하고 있습니다. 관심이 있다면 exapolicy.com 도 방문해 주세요. 본 글은 특정 제품이나 벤더를 평가하거나 권장하는 것이 아니라, 업계의 방향성을 정리한 것입니다.

Discussion