AI에게 열어주기 전에, 민감정보는 숨기셨나요?

MCP(Model Context Protocol)가 빠르게 자리잡으면서 AI가 사내 데이터베이스와 문서 저장소에 직접 연결되는 풍경이 낯설지 않게 됐습니다. MCP는 AI 모델이 외부 도구와 데이터에 표준화된 방식으로 접근하도록 연결해 주는 규약입니다. 쉽게 말해 AI에게 우리 데이터로 통하는 문을 열어 주는 규격인 셈입니다. 과거에는 사람이 직접 쿼리를 짜고 조회 결과를 눈으로 훑어 필요한 부분만 골라 썼습니다. 이제는 에이전트가 스스로 데이터를 끌어와 답을 만들어 냅니다.

편리해진 만큼 예전 같으면 사람의 눈을 거쳤을 정보가 사람 손을 타지 않고 흘러 다니게 됐습니다. 가령 고객 상담 에이전트에게 "이 고객 최근 이력 좀 요약해 줘"라고 시켰다고 해 보겠습니다. 에이전트가 주민등록번호와 병력, 계좌번호가 뒤섞인 원본 레코드를 통째로 끌어와, 그대로 외부 LLM에 실어 보낸다면 어떻게 될까요?

편의의 이면에서 민감정보 노출이라는 오래된 숙제가 새로운 얼굴로 돌아왔습니다. 그래서 이번 글에서는 하나의 질문을 던지려 합니다. AI에게 데이터를 열어 주기 전에, 민감정보는 가려 두셨습니까? 유능한 신입 직원에게 창고 마스터키를 통째로 넘길지, 필요한 구역의 출입증만 쥐여 줄지의 문제입니다.

'사람의 눈'이라는 안전판이 사라집니다

기존 데이터 활용에는 좀처럼 드러나지 않던 안전판이 하나 있었습니다. 바로 사람입니다. 담당자가 데이터를 조회하고 필요한 만큼만 화면에 띄우고, 이건 내보내도 되는지 스스로 판단해 걸렀습니다. 완벽하진 않았지만 사람의 상식과 망설임이 마지막 여과 장치 역할을 했습니다.

BI(Business Intelligence) 대시보드나 수작업 조회의 시대에는 데이터에 손대는 주체가 통제된 소수였습니다. 접근 권한을 받은 분석가 몇 명이 정해진 범위 안에서 움직였습니다. 반면 Agentic AI 시대에는 접근 주체가 자동화된 다수 호출로 바뀝니다. 에이전트는 하루에도 수천 번씩 데이터를 조회하고, 그 과정에서 지치지도 망설이지도 않습니다. 이 자동 조회 과정에는 사람의 판단이라는 중간 검열 단계가 없습니다.

민감정보 문제는 갑자기 새로 생긴 게 아닙니다. 민감정보는 예전부터 그 자리에 있었습니다. 달라진 것은 노출 표면적입니다. 사람의 눈이라는 병목이 사라지면서 민감정보가 밖으로 나갈 수 있는 경로가 급격히 넓어졌고, 한 번 노출된 민감정보가 퍼져나가는 속도도 빨라졌습니다. AI는 데이터를 '학습하고, 전송하고, 재생성'합니다. 한 번 프롬프트에 실려 모델 쪽으로 흘러 나간 정보는 어디에 어떤 형태로 남는지 알기 어렵고 회수는 사실상 불가능합니다. 저장의 문제였던 것이 이제 흐름의 문제가 된 셈입니다.

MCP와 Agentic AI가 위험을 키우는 세 지점

에이전트가 데이터를 직접 다루기 시작하면 위험은 세 갈래에서 커집니다.

먼저 과다 조회(over-fetching)입니다. 잘 설계된 애플리케이션이라면 개발자가 필요한 컬럼만 골라 조회하도록 쿼리를 다듬습니다. 하지만 에이전트는 "고객 정보를 가져와"라는 지시를 받으면 고객 테이블을 통째로 끌어오기 쉽습니다. 이름 하나만 필요한 상황에서 주민번호와 계좌번호까지 딸려 나옵니다. 정작 답에는 쓰이지 않아도, 그 데이터는 이미 모델 쪽으로 넘어간 뒤입니다.

다음은 목적 외 결합입니다. 에이전트는 여러 데이터 소스를 자동으로 조인해 답을 만듭니다. 문제는 개별적으로 존재할 떄는 안전한 정보가, 같이 결합되면 개인을 특정하는 재식별 위험을 만든다는 데 있습니다. 예를 들어 A사가 가진 데이터에 우편번호, 생년월일, 성별이 따로따로 흩어져 있다고 해 보겠습니다. 하나하나는 익명 통계처럼 보입니다. 그런데 이 셋을 한자리에 모으면 단 한 명으로 좁혀집니다. 사람이 조회할 때는 굳이 이 셋을 붙일 이유가 없지만, 에이전트는 답을 채우기 위해 스스럼없이 붙입니다.

마지막은 경로의 불투명성입니다. 에이전트가 어떤 데이터를 언제 어디로 보냈는지 기록이 남지 않으면 사고가 나도 무엇이 새어 나갔는지 추적할 수 없습니다. 사람의 조회는 그나마 시스템 로그와 기억에 흔적이 남지만, 자율적으로 움직이는 에이전트의 데이터 흐름은 별도로 모니터링하지 않으면 그대로 보이지 않게 됩니다.

세 지점의 공통점은 분명합니다. 모두 AI에게 데이터를 열어 준 다음에 벌어지는 일입니다. 그래서 통제의 무게 중심을 열기 전으로 당겨 와야 합니다.

퍼블릭 LLM을 쓸 때 문제는 더 커집니다

퍼블릭 LLM에는 분명한 장점이 있습니다. 최고 수준의 성능을 별도 인프라 투자 없이 쓸 수 있고 비용 효율도 좋습니다. 많은 조직이 자체 모델 대신 상용 API를 택하는 데는 그럴 만한 이유가 있습니다.

그러나 데이터가 조직의 경계를 넘는 순간 통제권을 잃습니다. 한 번 열어 준 다음에는 가릴 수 없습니다. 프롬프트에 실린 민감정보가 상대 서비스의 로그나 캐시에 얼마간 남을 수 있고 학습에 재사용될 여지도 완전히 배제하기 어렵습니다. 데이터가 국외 서버로 이전되면 어느 나라 법의 관할을 받는지도 따져야 합니다. 한 번 경계를 넘은 데이터를 다시 불러오는 일은 현실적으로 어렵습니다.

물론 완화책이 없는 것은 아닙니다. 주요 사업자들은 엔터프라이즈 플랜에서 입력 데이터를 학습에 쓰지 않겠다는 약정을 제공합니다. 프라이빗 배치나 온프레미스 설치로 데이터가 외부로 나가지 않게 막는 선택지도 있습니다. 그러나 계약 문구와 설정에만 기대는 통제에는 한계가 있습니다. 약정은 운영 실수나 설정 오류를 되돌려 주지 않고 이미 흘러 나간 데이터를 회수해 주지도 않습니다. 계약은 사고가 났을 때의 책임을 정리해 줄 뿐, 사고 자체를 막아 주지는 않습니다.

데이터 쪽에서 '가려서 여는' 접근

그렇다면 무엇을 할 수 있을까요? 핵심은 통제를 모델과 네트워크에만 맡기지 않는 것입니다. 보안을 흔히 AI 앞단에 방화벽을 세우는 문제로만 생각합니다. 입구를 잘 지키면 된다는 발상입니다. 그러나 에이전트가 데이터를 직접 만지는 환경에서는, 무엇이 어디에 어떤 형태로 있는지 아는 것 자체가 곧 보안이 됩니다. 가릴 대상을 모르면 가릴 수 없기 때문입니다. 통제는 앞단이 아니라 데이터 자체에 심어야 합니다.

구체적으로는 네 가지 축으로 접근할 수 있습니다.

• 분류·식별: 어떤 데이터가 어디에 민감한 형태로 있는지 먼저 파악합니다. 데이터 카탈로그와 메타데이터를 기반으로 민감 항목에 태그를 붙여 두면, 이후 모든 통제의 출발점이 됩니다.
• 최소 노출: 컬럼 단위 마스킹, 토큰화, 비식별을 적용하고 목적별 뷰를 제공합니다.
• 접근 제어의 세분화: 에이전트와 역할별로 권한을 나누고 "무슨 목적으로 접근하는가"에 따라 접근 범위를 다르게 부여합니다.
• 관측·감사: 어떤 에이전트가 무엇을 언제 조회하고 어디로 보냈는지 리니지(데이터 흐름 이력)와 로그로 남깁니다.

두 번째 축을 조금 더 구체화해 보겠습니다. 상담 에이전트가 접근하는 것을 원본 테이블이 아니라 마스킹된 뷰로 한정하는 방식입니다.

  -- 상담 에이전트 전용 뷰: 식별정보는 가리고, 필요한 항목만 노출  CREATE VIEW v_customer_for_agent AS  SELECT    customer_id,    CONCAT(LEFT(name, 1), '**')            AS name_masked,    CONCAT('******-', RIGHT(rrn, 1), '******') AS rrn_masked,    grade,    last_contact_date  FROM customer;

에이전트가 아무리 테이블을 통째로 끌어오려 해도, 애초에 원본이 아니라 가려진 뷰만 볼 수 있다면 과다 조회는 무해해집니다. 이 모든 것은 '어떤 컬럼이 민감한가'를 아는 데서 출발합니다. 결국 데이터를 잘 아는 것이 통제의 전제입니다.

프라이빗 LLM도 해결책이 되지 않습니다

몇 가지 오해를 짚어 두겠습니다. 먼저 "프라이빗 LLM을 쓰면 끝"이라는 생각입니다. 데이터가 외부로 나가지 않으니 안심해도 될 것 같지만 앞서 본 과다 조회와 목적 외 결합은 내부에서도 그대로 일어납니다. 권한 없는 부서의 에이전트가 인사 데이터를 끌어오는 일은 조직의 경계 안에서도 벌어집니다. 범위를 안으로 옮겼을 뿐, 가리는 일을 대신해 주지는 않습니다.

반대로 "일단 다 막으면 안전하다"는 생각도 곤란합니다. 지나친 차단은 AI 활용 자체를 무력화합니다. 데이터를 하나도 못 보게 하면 에이전트는 아무 일도 못 합니다. 그러면 애초에 AI를 도입할 이유가 사라집니다. 전부 여는 것도, 전부 가리는 것도 답이 아닙니다. 필요한 만큼 열고 나머지를 가리는 균형점을 데이터 단위로 찾아내는 일이 관리의 실체입니다.

아울러 민감정보 관리는 한 번 세팅하면 끝나는 완벽한 방어벽이 아닙니다. 새로운 데이터가 계속 쌓이고 규제가 바뀌며, 에이전트의 행동 양식도 진화합니다. 완벽한 차단은 애초에 목표가 될 수 없습니다. 민감정보 관리는 위험을 0으로 만드는 활동이 아니라, 감당할 수 있는 수준으로 관리하며 계속 손보는 지속적인 활동입니다.

어디서부터 시작할까요

제목에서 던졌던 "열기 전에 가렸는가"라는 질문은 AI 도입을 다 마친 뒤에 붙이는 마지막 점검이 아닙니다. 오히려 가장 먼저 채워야 할 첫 단추입니다. 유능한 직원에게 창고 마스터키를 통째로 넘기는 오늘 필요한 구역의 출입증만 쥐여 주듯, AI의 능력을 죽이지 않으면서 노출을 줄이는 균형을 찾는 일. 그것이 민감정보 관리의 핵심입니다.

민감정보 관리는 AI 도입을 가로막는 걸림돌이 아니라, 안전하게 AI를 활용하기 위한 전제 조건입니다. 어떤 데이터를 숨겨야 할 지 알면 오히려 안심하고 열 수 있게 됩니다. 통제가 활용의 발목을 잡는 것이 아니라, 통제가 있어야 비로소 마음 놓고 활용할 수 있습니다. 무엇을 가려야 하는지 아는 조직은 나머지를 과감하게 열 수 있습니다.

그리고 그 전제는 결국 데이터가 어디에 무슨 의미로 있는지 아는 데서 출발합니다. 민감정보를 가리는 일은 데이터를 분류하고 메타데이터로 정돈하며 흐름을 추적하는 데이터 거버넌스의 연장선 위에 있습니다. 자기 데이터를 제대로 아는 조직만이 무엇을 가리고 무엇을 열지 판단할 수 있고 그런 데이터라야 AI가 믿고 쓸 수 있습니다.

다만 이것으로 모든 숙제가 끝나지는 않습니다. 규제는 계속 바뀌고 에이전트 기술도 빠르게 진화하는 만큼, 한 번의 정비로 안심하기보다 꾸준히 점검하고 손보는 자세가 필요합니다. 지금 우리 데이터부터, 무엇을 가려야 하는지 다시 들여다보는 데서 시작하면 됩니다.