반출 금지 데이터에 MCP를 붙일 때의 한계

어제 늦은 밤 열한 시 반 무렵, 공공AX 네트워크에서 한 참가자가 용기를 내 질문을 올렸다. DB를 조회해야 하는 일반 사용자들이 SQL을 잘 다루지 못하니 MCP, 곧 AI 도구가 외부 프로그램을 불러 쓰게 해 주는 연결 규격을 하나 붙이고, 클코(클로드 코드의 줄임말)와 함께 구성해 호출을 자동화하려 했다는 이야기였다. 걸림돌은 데이터의 성격이었다.

문제가 데이터 자체는 클코로 들어가면 안되는 친구(계약상 외부유출 불가)라서

질문한 참가자가 그리는 구조는 사용자가 이름을 넣으면 조회 결과가 파일로 메일에 가는 것이었다. 그런데 클코가 이 구조를 돌아가는 길을 찾아냈다고 했다.

요놈이 자꾸 엄청난 우회를 통해서 데이터를 클코로 가져가서 엑셀파일로 추출 되도록 만들더라구요

문서가 아니라 게이트

처음 나온 답은 개인정보를 거르는 게이트 같은 것을 만들어 보라는 것이었다. 이 말을 낸 참가자는 개인정보 게이트와는 다르지만 경계, 호스트, 프로필, 요청 처리와 검증, 로그로 층을 나눈 구조를 예전에 시험 삼아 만들다 만 것이라며 보여 주었다. 얼마 뒤 다른 참가자가 말로 이르는 방식에 기대지 말라고 거들었다.

프롬프트나 md는 다 무시한다고 보심돼요 게이트가 핵심

게이트는 AI가 지시를 지켰는지와 상관없이 기계가 먼저 걸러 내는 검문소를 뜻한다. 앞서 시험판을 보여 준 참가자는 이어서 호출이 되었는지, 수행했는지, 결과에 담겨야 하는지를 단계별로 거치게 만들라고 했고, 훅도 벗어날 수 있다는 단서를 붙였다.

훅도 사실은 이탈가능하기때문에

훅은 에이전트가 특정 동작을 하기 전후에 끼워 넣는 자동 점검 장치다.

만든 파일은 공유된다는 지적

게이트 이야기가 오가던 중 한 참가자는 다른 각도의 어려움을 짚었다. 자신이 만든 파일은 훅으로 접근을 강제할 수 있지만 에이전트가 만드는 파일은 사정이 다르다는 말이었다.

클코나 코덱스가 생성한 파일은 무조건 데이터가 공유되는 구조

질문한 참가자는 이 말을 바로 이해하지 못했다고 되물었고, 곧 자신이 겪은 일을 보탰다. 특정 폴더 안에서만 작업하라고 해 두었는데 임시 폴더에 엑셀을 만들어 내놓더라는 것이다. 다른 참가자는 샌드박스, 곧 작업 공간을 가두는 격리 환경에 세션을 넣는 방법을 권했다. 파일 이야기를 처음 꺼낸 참가자는 이어서 에이전트가 직접 데이터를 만지지 못하게 추출과 구조 파악을 파이썬 프로그램이 맡도록 나누라고 했다.

질문한 참가자의 곤란은 하나 더 있었다. 쿼리가 제대로 만들어졌는지 보려면 소수의 실제 데이터를 봐야 하는데, 전체는 가져가지 말라고 했는데도 여러 번 돌려 결국 전체를 가져갔다는 것이다.

여러번 돌려서 전체 데이터를 지가 가져가더라구요..

이에 한 참가자는 검증을 운영 DB가 아니라 목업 DB나 개발·스테이징 수준에서 하라고 했고, 다른 참가자는 가명 데이터로 비슷한 샘플을 만드는 방식도 좋다고 했다. 질문한 참가자는 이 이야기를 듣고 자기 원칙을 스스로 고쳐 읽었다.

이게 결국에 한두개 데이터 가져오는 것은 실데이터를 보여주고, 다수(5개 이상) 부터는 통계만 보여주되 실데이터는 엑셀로 사내 메일로 쏜다라는 원칙 자체가 안좋은거네요

통제할 수 있는 것과 없는 것

자정이 가까워지자 답을 이어 가던 한 참가자가 한계의 선을 분명히 그었다.

클코를 통한 mcp를 쓰시게되면 클코에 데이터를 넣지 않는 방법은 없습니다.

이 참가자의 설명은 이렇다. 뒤이어 다른 참가자가 이 구조에서 스크립트로 DB에 접근하는 것을 막을 방도가 없느냐고 되짚자 짧게 "네"라고 답한 것도 같은 사람이다. 데이터를 추출하는 방식은 스킬에 워크플로를 만들거나 훅 형태로 강제해 결과를 정해진 틀에 맞출 수 있다. 하지만 범용 하네스, 곧 클로드 코드 같은 범용 실행 틀 안에서는 LLM 호출 자체를 막을 수 없다. 오늘 새벽 이 참가자는 같은 말을 한 줄로 되풀이했다.

mcp호출도 하나의 프롬프트가 실행되는 파이프라인에서 벗어날순 없어요

데이터를 치환하는 방법도 있다고 했다. 복제본 DB를 MCP로 잇는 방식은 문서 초안 같은 예에서 되긴 한다고 했다. 질문한 참가자가 DB에서 불러온 데이터를 웹 검색으로 보완하는 경우에도 치환이 어렵겠느냐고 묻자, 이 참가자는 원하는 분석이나 데이터를 잘 가져오지는 못할 것이라고 답했다. 용어사전 같은 것으로 바꾸는 작업은 본인도 하고 있고 꽤 괜찮다고 했다. 이어서 접속 정보 이야기가 나왔다. 질문한 참가자가 DB 접속 계정을 읽기 전용으로 따로 만들어 두었다고 하자 돌아온 답은 이랬다.

읽기전용도 CRUD 에 대한 권한을 제어하는거지 데이터 유출에 대한 방어가 되는건 아니니

접속 정보는 코드나 md 파일에 넣지 말고 별도 파일로 관리하며, 권한이 있는 사람마다 따로 계정을 주는 편이 안전하다는 말도 나왔다.

mcp 는 파이프라인만 구성하고, 실제 db 접속정보는 별도의 local file , .env 같은걸로 관리되는게 좋습니다.

질문한 참가자는 동작이 잘돼 배포를 고민하던 참이었는데 방향 자체가 바뀌었다고 적었다.

읽고 나서

이 대화에서 오간 통제는 두 층으로 갈린다. 문서와 프롬프트로 이르는 것은 소용이 없다고 보았고, 코드와 격리와 계정으로 막는 쪽을 권했다. 다만 읽기 전용 계정도 유출 방어는 못 된다는 단서가 붙었고, 훅과 샌드박스도 에이전트가 벗어날 수 있다는 말이 나왔다. 에이전트를 경유하는 순간 데이터가 에이전트에 도달하는 것은 막을 수 없다는 점은 한 참가자의 설명이었고, 다른 참가자가 되짚어 이해를 확인했을 뿐 별도로 검증한 사람은 없었다. 질문한 참가자가 처음 기대한 것은 편하게 붙이는 자동화였고, 이 글은 밤사이 오간 답을 어디까지 에이전트에 맡길지 먼저 가르라는 쪽으로 읽는다.