Presidio와 NeMo Guardrails, AI DLP라고 불러도 될까?

AI DLP는 AI 서비스가 민감한 데이터를 부적절한 곳으로 보내지 않도록 통제하는 체계다. DLP는 Data Loss Prevention, 즉 데이터 유출 방지를 뜻한다. 챗봇에 붙여 넣은 고객 정보, 검색으로 가져온 내부 문서, AI가 작성한 답변이 모두 보호 대상이 될 수 있다.

 

이런 서비스를 만들 때 자주 함께 등장하는 도구가 Presidio와 NVIDIA NeMo Guardrails다. Presidio는 민감정보를 찾고 가리는 역할을, NeMo Guardrails는 검사와 정책을 대화·처리 흐름에 연결하는 역할을 맡는다. 두 도구를 애플리케이션의 실제 차단 기능과 결합한 구성은 AI DLP 파이프라인이라고 설명할 수 있다.

 

이 글에서는 두 도구의 역할을 나누어 살펴보고, 고객 상담 내용을 요약하는 AI 서비스를 예로 들어 데이터가 어디에서 검사되고 어디에서 멈춰야 하는지 정리한다. 설명 범위는 주로 텍스트를 처리하는 LLM 애플리케이션이다.

AI DLP의 중심에는 데이터와 목적지가 있다

DLP의 기본 질문은 간단하다. “이 데이터를 이 사람이 이 목적지로 보내도 되는가?” 같은 문서라도 사내 승인된 저장소에 보관하는 경우와 외부 서비스에 업로드하는 경우의 정책이 달라질 수 있다.

 

기업용 DLP는 이 질문을 이메일, 파일 공유, 단말, 클라우드 앱 등 여러 경로에 적용한다. 예를 들어 Microsoft Purview DLP는 민감정보와 사용자 활동을 정책 조건으로 평가하고, 조건에 따라 공유를 제한하거나 경고·감사 기록을 남기는 기능을 제공한다. 보호 범위와 적용 방식은 제품과 배포 구성에 따라 달라진다. Microsoft의 DLP 개요

 

LLM, 즉 대규모 언어 모델을 사용하는 서비스에서는 데이터 이동 경로가 더 늘어난다. 사용자 입력을 모델 제공자에게 전송하고, 사내 문서를 검색해 모델의 참고 자료로 넣으며, 도구를 호출해 업무 시스템의 데이터를 가져온다. 생성된 답변은 사용자에게 전달되고 운영 로그에도 남을 수 있다.

 

여기서는 이 경로에 민감정보 식별, 목적지별 정책, 마스킹 또는 차단, 검증 기록을 연결한 구성을 AI DLP라고 부른다. “AI DLP”는 문맥에 따라 AI를 활용한 DLP라는 뜻으로도 쓰이므로, 문서나 강의에서는 보호 대상이 LLM의 입력·검색·출력 경로임을 함께 밝히면 범위가 분명해진다.

구성 요소	주된 역할	함께 연결할 기능
Presidio	개인정보 등 설정된 민감정보 유형의 탐지와 변환	보호할 정보의 정의, 언어별 인식기, 후속 정책
NeMo Guardrails	입력·검색·대화·도구·출력의 검사와 흐름 제어	검사 모델·액션, 업무 정책, 애플리케이션 연동
애플리케이션·게이트웨이	실제 요청 전달·응답 반환·도구 실행의 허용과 중단	인증·권한, 전송 목적지, 오류 처리, 감사 기록
기업용 DLP	여러 업무 채널에 걸친 데이터 이동 통제	제품이 지원하는 채널의 연결과 조직 정책

이 표는 각 구성 요소의 주된 책임을 정리한 것이다. 기능에는 겹치는 부분이 있다. NeMo 안에서 Presidio를 호출할 수 있고, 게이트웨이가 자체 검사 기능을 제공할 수도 있다. 핵심은 도구의 개수보다 데이터가 실제로 지나가는 경로에 통제가 연결되어 있는지다.

Presidio: 민감한 부분을 찾고 필요한 방식으로 바꾼다

Presidio의 텍스트 처리 구조는 두 단계로 이해하면 쉽다. Analyzer는 “어디에 어떤 민감정보가 있는가”를 찾고, Anonymizer는 “찾은 부분을 어떻게 바꿀 것인가”를 처리한다.

 

Analyzer는 인식기라는 탐지 단위를 사용한다. 인식기는 정규표현식, 규칙, 문맥, 개체명 인식 모델 등을 활용할 수 있다. 개체명 인식은 문장 속에서 사람 이름이나 장소처럼 특정 종류의 표현을 찾아내는 작업이다. 탐지 결과에는 정보 유형, 시작·끝 위치, 점수 등이 포함된다. Presidio Analyzer 문서

 

Anonymizer는 이 위치 정보를 받아 문자열을 삭제하거나, 다른 값으로 치환하거나, 일부 문자를 가리거나, 암호화하는 등의 처리를 수행한다. 예를 들어 상담 내용을 외부 모델로 요약할 때 고객의 연락처가 요약에 필요하지 않다면 해당 부분만 제거한 문장을 보낼 수 있다. Presidio Anonymizer 문서

 

다음은 처리 개념을 보여 주는 예시다. 중괄호 안의 값은 실제 개인정보 대신 사용한 설명용 표기이며, Presidio를 실행해 얻은 탐지 결과는 아니다.

처리 전
고객 {고객 이름}의 연락처는 {고객 이메일}이다.
배송 지연에 대한 문의를 한 문장으로 요약해 줘.

필요한 항목을 탐지·치환한 뒤
고객 [PERSON]의 연락처는 [EMAIL_ADDRESS]이다.
배송 지연에 대한 문의를 한 문장으로 요약해 줘.

요약에 필요한 “배송 지연 문의”는 남기고, 이름과 연락처의 노출을 줄이는 구성이다. 반대로 본인 확인이나 연락처 수정이 목적이라면 필요한 데이터와 허용된 처리 환경이 달라진다. 마스킹 범위는 업무 목적과 수신자의 권한에 맞춰 정한다.

그림 1. 탐지·변환, 정책 연결, 실제 집행의 역할 관계. Presidio Analyzer, Anonymizer, NeMo의 Guardrail Types 공식 문서를 바탕으로 재구성했다. 애플리케이션 집행 영역은 이 글의 설계 예시다.

여기서 “익명화”라는 이름은 처리 방식과 함께 읽어야 한다. Presidio의 Anonymizer에는 암호화처럼 되돌릴 수 있는 연산도 있다. 이름을 가렸더라도 다른 정보와 결합해 개인을 알아볼 수 있다면 재식별 가능성이 남는다. 따라서 처리 결과를 설명할 때는 “연락처를 마스킹했다”, “식별자를 치환했다”처럼 실제 수행한 동작을 쓰는 편이 정확하다.

한국어와 사내 정보는 어떻게 다룰까?

2026년 9월 15일 확인한 공식 지원 목록에는 한국 주민등록번호인 KR_RRN, 운전면허번호인 KR_DRIVER_LICENSE 등 한국 관련 유형이 포함되어 있다. 실제 서비스에서는 사용하는 패키지 버전에 해당 인식기가 들어 있는지, 설정에서 로드되고 검사 대상으로 선택되는지 확인해야 한다. Presidio 지원 유형

 

한국어 이름과 주소, 문장 속 문맥은 별도의 문제다. Presidio의 다국어 문서는 기본 구성이 영어 모델과 인식기를 포함하며, 추가 언어를 위해 NLP 엔진과 인식기·문맥 단어를 맞추도록 설명한다. 한국 관련 번호 유형의 지원과 한국어 문장 전체의 탐지 품질을 나누어 검증하는 이유다. Presidio 다국어 지원

 

개인정보 외에도 보호할 정보는 많다. 사내 프로젝트 코드, 비공개 계약 조건, 설계 문서는 개인정보 탐지만으로 충분히 분류되지 않을 수 있다. 이런 정보에는 업무별 인식기, 문서의 보안 등급, 분류 규칙 등을 함께 적용할 수 있다. Presidio는 사용자 정의 인식기를 추가할 수 있지만, 보호할 정보의 의미와 정책은 서비스가 구체적으로 정의해야 한다.

 

참고로 “Microsoft Presidio”로 알려진 프로젝트는 현재 Data Privacy Stack의 독립적인 커뮤니티 프로젝트로 전환 중이라는 안내가 게시되어 있다. 이 글의 Presidio 링크는 현재 공식 문서를 기준으로 연결했다. 프로젝트 전환 안내

NeMo Guardrails: 검사를 필요한 지점에 연결한다

NeMo Guardrails에서 rail은 요청 처리 중 정책을 적용하는 검사·제어 흐름을 뜻한다. 검사 지점을 입력과 출력에만 두지 않고, 검색한 문서나 도구 호출, 여러 차례 이어지는 대화에도 배치할 수 있다.

Rail 종류	적용 지점	이 글의 데이터 보호 사례
Input rails	사용자 입력	모델에 전달하기 전 민감정보 검사·마스킹
Retrieval rails	검색된 문서와 문서 조각	모델의 참고 자료에 들어갈 내용 검사
Dialog rails	여러 차례 이어지는 대화	허용된 상담·확인 절차 유지
Execution rails	도구 호출의 인수와 결과	허용된 작업인지, 전달할 값이 적절한지 검사
Output rails	모델이 생성한 응답	사용자에게 반환하기 전 검사·수정·차단

이 구분은 NeMo 공식 문서의 기능 설명에 따른다. 실제 지원 범위는 사용하는 엔진과 통합 방식에 따라 확인해야 한다. 모든 종류의 rail이 모든 실행 환경에서 같은 방식으로 동작하는 것은 아니다. NeMo Guardrail Types

 

두 도구를 함께 쓰는 구성도 공식적으로 제공된다. NeMo의 Presidio 연동에는 입력, 출력, 검색된 문서 조각에서 민감정보를 탐지하거나 마스킹하는 흐름이 있다. 따라서 “NeMo를 거친 다음 별도의 Presidio 서버를 반드시 한 번 더 거친다”라는 고정된 배치 대신, NeMo의 해당 rail이 Presidio 검사를 호출하는 구조로도 구현할 수 있다. NeMo PII Detection

 

이때 탐지와 마스킹은 서로 다른 정책 동작이다. “민감정보가 있으면 요청을 거부한다”와 “민감정보를 치환한 뒤 요청을 계속한다”는 사용자 경험도 다르다. 어떤 유형을 검사할지, 어느 단계에서 적용할지, 어떤 동작을 선택할지는 구성에 담아야 한다. NeMo의 Presidio 연동 안내

 

예를 들어 “모든 고객의 정보를 보여 줘”라는 요청을 제한하는 정책을 만들 수 있다. 여기에는 요청의 의미를 판단하는 규칙이나 모델, 그 결과에 따라 처리를 멈추는 액션이 필요하다. NeMo를 설치했다는 사실만으로 사내 업무 정책이나 고객 데이터 접근 권한이 자동으로 정의되지는 않는다.

하나의 요청을 따라가 보면 AI DLP의 범위가 보인다

고객 상담을 요약하는 서비스를 가정해 보자. 사용자는 상담 내용을 입력하고, 서비스는 필요한 업무 문서를 검색한 뒤 LLM에 요약을 요청한다. RAG는 Retrieval-Augmented Generation의 약자로, 검색한 자료를 모델의 참고 문맥에 넣어 답변을 생성하는 방식이다.

 

다음 그림은 이 서비스를 위한 설계 예시다. NeMo의 실제 내부 호출 순서를 그대로 묘사한 그림은 아니며, 데이터가 다음 목적지로 이동하기 전에 충족할 조건을 중심으로 그렸다.

그림 2. LLM 서비스의 데이터 이동과 검사 위치. NeMo PII Detection, Guardrail Types, Microsoft DLP 개요 공식 문서를 바탕으로 재구성한 설계 예시다. 권한 검사와 전송·응답 집행은 애플리케이션의 책임으로 표시했다.

첫째, 애플리케이션이 사용자의 신원과 허용된 업무 범위를 확인한다. 어떤 문서를 검색할 수 있는지, 어떤 고객의 기록을 볼 수 있는지, 어떤 도구를 실행할 수 있는지를 서버에서 제한한다. 이 범위가 정해져야 이후 데이터 검사가 의미 있는 정책으로 이어진다.

 

둘째, 사용자 입력을 다음 수신자에게 보내기 전에 필요한 검사를 마친다. 외부 모델에 원문 개인정보를 보내지 않는 것이 목표라면, 그 경계를 넘기 전에 탐지·마스킹이 완료되어야 한다. 여기서 외부 모델에는 답변을 만드는 주 모델뿐 아니라 요청을 분류하는 보조 모델도 포함된다.

 

이 순서는 설계상의 조건이다. 예를 들어 입력 정책을 판단하는 외부 LLM에 원문을 먼저 보내고 나중에 Presidio로 가리면, 그 보조 모델에는 이미 원문이 전달된다. 따라서 개인정보를 처리할 수 있도록 승인된 환경 안에서 먼저 검사하거나, 승인된 검사 서비스와 데이터 처리 경로를 사용하도록 구성한다.

 

검사와 생성을 병렬로 실행하는 설정도 같은 기준으로 판단한다. NeMo에는 입력 검사 중 생성을 시작하는 방식이 있으므로, 전송 전에 검사 완료가 필수인 경로는 실제 설정과 호출 순서를 확인한다. 마스킹한 내용을 검사해야 하는 후속 rail은 마스킹 뒤에 순서대로 실행한다. NeMo 런타임 보안 FAQ

 

셋째, 검색과 도구를 통해 새로 들어온 데이터도 검사한다. 사용자 입력에 개인정보가 없어도 검색된 상담 기록에는 연락처가 있을 수 있다. 권한이 허용한 문서만 검색 대상으로 제한하고, 모델에 넣기 전에는 목적지 정책에 맞춰 필요한 항목을 가린다. 도구 결과가 모델 문맥에 들어가는 경우에도 같은 관점으로 다룬다.

 

넷째, 생성된 답변을 검사한 뒤 실제 응답을 반환한다. 애플리케이션은 rail의 결과를 받아 승인된 답변을 전송하거나, 수정된 답변을 전송하거나, 요청을 종료한다. 라이브러리가 “차단”을 반환하더라도 별도의 코드 경로가 원문 응답을 그대로 보내면 해당 경로에는 통제가 적용되지 않는다.

 

이처럼 입력과 출력의 Presidio 검사, NeMo의 정책 흐름, 애플리케이션의 집행을 연결하면 데이터 보호 동작을 끝에서 끝까지 설명할 수 있다. 보안 아키텍처 문서에서도 각 단계의 이름 옆에 “무엇을 검사하고, 실패하면 무엇을 멈추는가”를 적으면 구현 범위가 명확해진다.

마스킹과 접근 권한은 서로 다른 질문에 답한다

민감정보 탐지는 “이 내용에 보호할 정보가 있는가”를 판단한다. 접근 권한 검사는 “이 사용자가 이 정보에 접근할 수 있는가”를 판단한다. 두 판단은 함께 필요하다.

 

예를 들어 상담 직원에게 담당 고객 한 명의 기록을 요약할 권한이 있다고 하자. 외부 모델에 넘길 연락처는 가릴 수 있지만, 그 사실이 다른 부서 고객의 기록까지 검색할 권한을 주지는 않는다. 반대로 접근 권한이 있는 직원의 요청이라도, 데이터를 전달할 외부 서비스가 승인된 목적지인지 확인해야 한다.

 

따라서 이 설계에서는 문서 검색과 업무 API의 권한을 서버에서 집행하고, 가드레일을 통해 요청·결과의 적절성을 추가로 검사한다. 데이터 소유자, 사용자 역할, 문서 등급, 전송 목적지 같은 업무 정보가 정책 판단에 연결되어야 한다. 이 부분은 두 라이브러리의 기능 설명에서 확장한 애플리케이션 설계 원칙이다.

운영에서는 검사 순서와 기록 경로까지 확인한다

AI DLP의 효과를 확인할 때는 탐지 결과와 실제 전달 결과를 함께 본다. 다음 세 가지는 특히 설계 단계에서 결정해 두면 좋다.

스트리밍: 검사된 범위만 내보내기

스트리밍은 모델이 만드는 답변을 조금씩 사용자에게 전송하는 방식이다. 이미 전송한 내용은 뒤늦은 출력 차단으로 회수할 수 없다. 민감정보 노출을 막는 것이 목표라면 전체 답변을 모아 검사하거나, 검사한 범위만 전송하도록 버퍼와 출력 정책을 구성한다.

 

NeMo는 스트리밍과 출력 rail 설정을 제공한다. 공식 FAQ는 노출 전에 검사가 필요한 경우 stream_first: False로 구간을 먼저 검사하도록 안내한다. 적용 시에는 검사 단위, 버퍼 처리, 중단 동작을 실제 통합 환경에서 확인한다. 전체 응답 검사와 구간별 검사는 지연 시간과 문맥 확보 측면에서 서로 다른 특성이 있다. NeMo 스트리밍 설정, 런타임 보안 FAQ

오류: 검사 실패를 어떤 결과로 처리할지 정하기

탐지기나 정책 서비스가 시간 초과를 일으킬 수 있다. 이때 요청을 중단할지, 기능을 제한할지, 다른 승인된 처리 경로로 보낼지를 정한다. 예를 들어 원문 개인정보의 외부 전송을 금지한 경로라면 필수 검사를 완료하지 못한 요청은 외부로 전달하지 않는 방식으로 설계할 수 있다.

 

이는 모든 서비스에 같은 중단 규칙을 적용한다는 뜻은 아니다. 보호할 데이터와 업무 영향에 따라 정책을 나누되, “검사를 수행하지 못한 상태”와 “검사를 통과한 상태”를 기록에서 구분하는 것이 핵심이다.

로그: 보호 결과를 관찰하되 원문 저장을 줄이기

사용자에게 반환한 답변을 마스킹했더라도, 입력 원문이 추적 시스템에 먼저 저장될 수 있다. NeMo 공식 문서도 PII rail이 모든 애플리케이션 로그와 외부 관측 시스템을 자동으로 정제하지는 않는다고 설명한다. 로그, 캐시, 오류 보고, 재시도 기록도 데이터의 별도 목적지로 보고 저장 전 처리와 접근·보존 정책을 적용한다. NeMo 런타임 보안 FAQ

 

운영 지표는 원문 전체 없이도 상당 부분 수집할 수 있다. 어떤 정책 버전이 적용되었는지, 어떤 정보 유형이 탐지되었는지, 어떤 동작을 수행했는지, 처리 시간이 얼마나 걸렸는지를 요청 식별자와 연결하는 방식이다. 원문 확인이 필요한 제한된 조사 경로는 별도로 권한과 보존 기간을 정한다. 이 절의 항목들은 앞에서 정의한 데이터 이동 범위를 운영 경로까지 확장한 설계 예시다.

도입 효과는 탐지 품질과 업무 결과로 평가한다

Presidio 공식 문서는 자동 탐지가 모든 민감정보를 찾는다고 보장하지 않으며, 사용 사례에 맞춘 평가가 필요하다고 설명한다. 평가에서는 정상 데이터가 잘못 차단되는 경우와 민감정보를 놓치는 경우를 함께 측정한다. Presidio 프로젝트 안내, PII 탐지 평가 문서

 

먼저 합성 데이터 등 통제된 평가 자료에서 정밀도와 재현율을 확인할 수 있다. 정밀도는 민감정보라고 탐지한 것 중 실제 민감정보의 비율이고, 재현율은 실제 민감정보 중 찾아낸 비율이다. 이름, 연락처, 식별번호처럼 유형별로 나누고 한국어·영어가 섞인 자료도 구분하면 개선할 위치가 드러난다.

 

그다음 애플리케이션 전체의 결과를 확인한다. 아래 항목은 이 글의 상담 요약 서비스를 위한 평가 예시다.

• 전달 결과: 외부 모델에 전달된 값과 사용자에게 반환된 값이 해당 정책에 맞는가?
• 업무 품질: 마스킹 후에도 배송 지연의 원인과 고객 요청을 올바르게 요약하는가?
• 정상 처리: 민감정보가 없는 상담까지 불필요하게 거부하지 않는가?
• 실패 처리: 필수 검사에 실패하면 정해 둔 중단·제한 동작이 실행되는가?
• 운영 비용: 검사 추가로 생기는 지연과 비용이 서비스 목표 안에 들어오는가?

특히 마스킹 뒤에는 정보 관계가 바뀔 수 있다. 서로 다른 두 사람을 모두 같은 표기로 치환하면 “누가 누구에게 요청했는지”가 흐려진다. 구분이 필요한 업무라면 서로 다른 대체 식별자를 사용하는 설계를 검토하고, 원문과 대체값의 대응표를 보관한다면 그 표도 보호 대상으로 관리한다.

정리: 두 도구를 AI DLP의 구성 요소로 설명하면 된다

Presidio와 NeMo Guardrails를 사용해 LLM 서비스의 민감정보를 보호하는 과정은 AI DLP 구현이라는 주제로 설명할 수 있다. 각 도구의 역할과 보호 범위를 함께 적으면 기술적인 의미도 명확해진다.

• Presidio: 민감정보를 탐지하고 마스킹·치환하는 데이터 보호 엔진.
• NeMo Guardrails: AI DLP 정책을 포함한 검사와 처리 흐름을 구성하는 가드레일 엔진.
• 애플리케이션·게이트웨이: 권한과 목적지 정책에 따라 데이터 전달과 작업 실행을 실제로 허용하거나 중단하는 집행 계층.

이 구성을 소개하는 강의나 설계 문서에는 “LLM 환경의 AI DLP 구현: Presidio와 NeMo Guardrails”라는 이름을 사용할 수 있다. 그 안에 입력·검색·도구 결과·출력·로그의 처리 범위와 검증 기준을 함께 담으면, 독자는 도구의 기능과 시스템이 제공하는 보호를 연결해 이해할 수 있다.

 

AI DLP의 실질적인 보호 범위는 어떤 도구를 설치했는지에 더해, 어떤 데이터가 어느 목적지로 이동하며 그 전에 어떤 검사와 집행을 거치는지로 결정된다.