LLM 프롬프트 로그 개인정보 마스킹과 비식별화 가이드

LLM(대규모 언어 모델)을 불러 쓰는 서비스는 대개 호출 기록을 남깁니다. 답변이 이상하다는 문의가 들어왔을 때 사용자가 무엇을 물었고 모델이 어떻게 답했는지 다시 확인해야 하기 때문입니다. 호출 시각과 모델 이름, 토큰 수를 기본으로 남기고, 원인까지 확인하려면 프롬프트와 응답 원문을 함께 저장합니다.

원문을 저장하기 시작하면 사용자가 입력한 내용이 그대로 들어옵니다. 이름과 연락처가 섞인 문장이 로그 테이블에 남고, 같은 내용을 모델이 답변에서 다시 언급하면 한 번 더 저장됩니다. 운영을 위해 만든 기록이 개인정보를 담은 데이터베이스가 됩니다.

개인정보(PII, Personally Identifiable Information)는 이름이나 연락처처럼 특정 개인을 알아볼 수 있는 정보를 말합니다. 마스킹은 개인정보에 해당하는 부분을 별표 같은 다른 문자로 바꿔 원래 값을 알아볼 수 없게 만드는 처리이고, 비식별화는 데이터와 특정 개인의 연결을 끊는 처리 전체를 말합니다. 두 말을 섞어 쓰기 쉬운데, 마스킹은 비식별화에 속하는 기법 하나입니다. 비식별화를 거쳐도 남은 데이터가 개인을 가리킬 수 있어, 처리했다는 사실만으로 안전해지지는 않습니다.

국내 법령이 쓰는 용어는 가명정보와 익명정보입니다. 개인정보보호위원회는 2024년 2월 「가명정보 처리 가이드라인」을 내면서, 2016년 「개인정보 비식별 조치 가이드라인」은 현행법에 맞지 않아 더 이상 활용하지 않는다고 밝혔습니다. 비식별화는 국제 표준(ISO/IEC 20889)과 실무에서 이 처리들을 아우르는 말로 남아 있어, 이 글에서도 여러 기법을 통틀어 가리킬 때만 씁니다.

어디까지를 개인정보로 볼지, 얼마나 지워야 충분한지는 서비스가 다루는 데이터와 적용받는 규제에 따라 달라집니다. 판단이 필요한 지점은 법무·보안 담당자와 함께 정합니다. 이 글에서는 로그를 만들고 저장하는 과정에서 개발자가 할 수 있는 처리만 정리합니다.

‍

프롬프트 로그에 개인정보가 섞여 들어오는 이유

일반 애플리케이션 로그는 어떤 값이 어디에 들어갈지 미리 정해져 있습니다. 주문 로그의 주문 번호 필드, 결제 로그의 카드 번호 필드처럼 이름이 붙은 칸에 값이 들어갑니다. 지워야 할 값이 있으면 해당 칸만 처리하면 됩니다.

프롬프트에는 사용자가 쓴 문장 전체가 하나의 값으로 들어옵니다. 어느 위치에 무엇이 적혀 있는지는 저장하고 나서야 알 수 있습니다. 상담 문의에는 이름과 전화번호가 함께 적히고, 문서 요약을 요청하는 사용자는 계약서나 진단서 전체를 붙여 넣습니다. 사내 도구라면 사번과 부서, 평가 내용이 들어옵니다.

사용자가 직접 입력하지 않아도 개인정보가 들어오는 통로가 있습니다. 검색 증강 생성(RAG)처럼 검색해 온 문서가 프롬프트에 그대로 실리는 구조에서는 문서에 적힌 고객 정보가 프롬프트로 옮겨 갑니다. 모델이 답변에서 사용자 이름을 다시 부르거나 문서 내용을 인용하면 응답에도 같은 정보가 실립니다. 호출 한 번에 저장되는 곳이 늘어납니다. 에이전트형 서비스에서는 프롬프트와 응답뿐 아니라 도구 호출 인자와 결과, 검색해 온 문서, 첨부 이미지에서 뽑은 텍스트에도 같은 정보가 들어갈 수 있습니다.

표준을 만드는 쪽도 같은 문제를 명시해 두었습니다. OpenTelemetry는 관측 데이터의 항목 이름을 표준으로 정해 둔 시맨틱 컨벤션(semantic conventions)에서 프롬프트와 응답 내용을 담는 항목 gen_ai.input.messages와 gen_ai.output.messages를 옵트인(opt-in)으로 지정했습니다. 옵트인은 기본값이 꺼져 있고 쓰는 쪽이 명시적으로 켜야 동작하는 방식입니다. 규격 문서는 두 항목에 "사용자 개인정보를 포함한 민감한 정보가 들어 있을 가능성이 높다"는 경고를 붙였습니다. OpenTelemetry 블로그도 기본값으로는 프롬프트 내용과 도구 인자를 수집하지 않으며 민감한 데이터가 들어 있을 수 있기 때문이라고 설명합니다.

‍

프롬프트 로그 마스킹 위치와 아키텍처 단계별 장단점

프롬프트 로그 마스킹은 애플리케이션, 중간 수집 서버(여러 곳의 관측 데이터를 모아 저장소로 보내는 서버), 저장한 뒤 일괄 처리 세 단계에서 할 수 있습니다. 앞단에서 처리할수록 민감한 원문이 지나가는 구간이 줄고, 중간 수집 서버에서 처리하면 마스킹 규칙을 한곳에서 관리할 수 있습니다.

애플리케이션에서 로그를 만들기 전에 처리하면 원문이 중간 수집 서버나 로그 저장소로 전달되지 않습니다. 대신 언어와 서비스마다 같은 규칙을 따로 넣어야 하고, 규칙을 고칠 때마다 배포가 필요합니다. 사용자 요청을 처리하는 시간에 마스킹 탐지 시간이 더해집니다.

중간 수집 서버에서 처리하면 규칙을 한곳에서 관리합니다. OpenTelemetry Collector Contrib에는 redaction processor가 있어, 허용 목록에 없는 속성을 지우고 차단 패턴에 맞는 값을 별표나 되돌릴 수 없게 계산한 값(해시)으로 바꿉니다. 공식 문서의 예시 설정에는 카드 번호처럼 자릿수가 정해진 값을 찾는 규칙(정규식)이 들어 있습니다. 다만 redaction processor가 처리하는 대상은 관측 데이터 속성과 구조화된 로그 본문입니다. 쓰고 있는 SDK가 프롬프트를 어떤 필드와 자료형으로 내보내는지 먼저 살펴봅니다. 서버에 도착하기 전까지는 원문이 그대로 이동하므로 그 구간을 신뢰할 수 있는지도 확인합니다.

‍

‍

저장한 뒤 일괄 처리하는 방식은 애플리케이션 단계나 중간 수집 서버 단계와 성격이 다릅니다. 이미 저장한 로그를 대상으로 하므로 소급 적용이 가능하다는 장점이 있지만, 삭제 전까지 원문이 저장소에 노출되었던 기간은 되돌릴 수 없습니다. 백업본이나 데이터 복제본, 검색 색인까지 동일하게 마스킹을 적용하지 않으면 원문이 그대로 남습니다.

어느 단계에 적용하든, 규칙을 배포한 뒤에는 실제 로그 표본을 직접 열어 값이 가려졌는지 확인해 둡니다. 마스킹 정규식에 오타가 있어도 로그 시스템은 정상 작동하므로, 민감 정보가 가려지지 않은 채 계속 쌓여도 한동안 알아채기 어렵습니다.

민감 정보를 지우지 않고 다른 값으로 대체하는 방법도 있습니다. 대표적인 비식별화 기법인 가명처리는 원래 값을 임의의 식별자로 변경하여 그 자체로는 특정 개인을 알아볼 수 없게 만듭니다. 대신 별도로 보관된 대조 테이블을 결합하면 원문 복원이 가능합니다. 복원이 가능하다는 점은 장점인 동시에 유출 시 위험 요소이므로, 대조 테이블을 어디에 분리해 보관할지를 따로 정해야 합니다.

‍

개인정보 마스킹 방법과 기술적 한계점

방법을 고르기 전에 무엇을 찾을지 목록부터 정합니다. 서비스가 실제로 받는 값을 기준으로 적습니다. 상담 서비스라면 이름과 연락처, 주소가 먼저 올라오고, 사내 도구라면 사번과 인사 정보가 들어옵니다. 목록 없이 시작하면 카드 번호처럼 널리 알려진 값만 처리하고 정작 그 서비스에 자주 들어오는 값을 놓칩니다.

개인정보를 가리거나 줄이는 기법은 정규식 처리, 개체명 인식(NER, Named Entity Recognition), 원문 미저장, 표본 저장, 보관 기간 단축으로 나뉩니다. 한 가지 방법으로 모든 개인정보를 가려내기는 어렵습니다. 각 기법이 잘 찾아내는 값과 놓치는 값이 서로 다르므로, 여러 방법을 같이 적용해야 안전합니다.

정규식 마스킹으로 패턴이 정해진 데이터를 찾습니다. 정규식은 문자열에서 특정 규칙에 맞는 형태를 찾아내는 표기법입니다. 카드 번호, 전화번호, 이메일 주소, 계좌번호처럼 자릿수와 구분 기호가 정해진 값은 정규식으로 잘 잡아냅니다. 탐지 규칙이 분명해서 결과가 늘 같고, 개체명 인식보다 연산 자원과 처리 비용을 적게 씁니다.

정규식이 놓치는 값도 분명합니다. 형태가 일정하지 않은 비정형 데이터는 정규식으로 걸러내지 못합니다. 이름과 주소는 정규식으로 표현할 규칙이 없고, 사내 식별자는 조직마다 체계가 달라 기본 규칙에 걸리지 않습니다. 그렇다고 탐지 범위를 넓히면 주문 번호나 오류 코드까지 가려져 오류 원인을 확인할 수 없습니다.

개체명 인식으로 문장 맥락을 보고 민감 정보를 찾습니다. 개체명 인식은 문장 맥락을 파악해 사람 이름, 지명, 기관명 같은 대상을 식별하는 기법입니다. 오픈소스 도구 Presidio는 정규식과 NER, 규칙 기반 판정을 조합해 다국어 민감 정보를 찾아냅니다. 다만 Presidio 공식 문서에서도 명시하듯, 자동 탐지 기술이 모든 민감 정보를 찾아낸다고 보장하지는 못하므로 탐지 외에 저장 범위 축소와 접근 권한 제어를 함께 적용합니다.

NER은 비용도 함께 늘립니다. 모델 추론 과정이 더해지면서 처리 시간과 연산 비용이 늘고, 학습 범위를 벗어난 표현에서는 정확도가 떨어집니다. 특히 한국어 인명과 주소, 조직 고유 식별자는 기본 탐지 기능만 믿지 말고 실제 로그 표본을 넣어 재현율(실제 민감 정보를 찾아낸 비율)과 오탐률(민감 정보가 아닌 값을 잘못 잡은 비율)을 직접 확인합니다.

민감 정보를 하나씩 찾아 마스킹하는 것 외에, 위험 요소가 될 데이터를 수집 단계에서 줄이는 방법도 있습니다.

원문 자체를 저장하지 않는 방법입니다. 프롬프트와 응답 원문은 빼고 모델 이름과 세부 버전, 토큰 수, 응답 시간, 오류 여부, 품질 점수만 저장합니다. 로그 저장소에 원문을 남기지 않으므로 저장소를 통한 유출 위험은 사라지고 저장 비용도 줄어듭니다. 대신 특정 답변에 이상이 생겼을 때 원인을 추적할 재료도 함께 사라집니다. 모델 API로 보내는 원문은 이 방법으로도 남으므로 전송 구간은 따로 검토합니다.

표본만 골라 저장하면 데이터 총량을 줄일 수 있습니다. 전체 호출 가운데 일정 비율만 추려 원문을 남기는 방식입니다. 저장 공간과 마스킹 처리 비용을 동시에 낮춥니다. 원문 수량은 줄지만, 저장 대상이 된 표본에 들어간 개인정보의 위험까지 사라지지는 않습니다.

항목별 보관 기간을 달리해 노출 기간을 단축합니다. 프롬프트 원문은 며칠만 보관하고 토큰 수나 응답 지표는 수개월간 유지하는 방식입니다. 노출 기간을 줄일 수 있지만, 과거 데이터와 현재 상태를 길게 비교하기 어려워집니다. 예컨대 모델 변경 전후의 응답 차이를 원문으로 대조하는 작업은 원문이 아직 남아 있는 기간 안에서만 수행할 수 있습니다.

방법장점단점/한계정규식 처리정형화된 패턴을 빠르게 마스킹합니다이름·주소 같은 비정형 데이터는 남습니다개체명 인식문맥을 분석해 인명·지명을 탐지합니다추론 비용이 늘고 잘못 잡거나 놓치는 값이 생깁니다원문 미저장로그 저장소 쪽 유출 위험이 없어집니다문제 발생 시 답변 원문을 다시 볼 수 없습니다표본 저장저장 공간과 처리 비용을 낮춥니다선택된 표본의 유출 위험은 동일하게 남습니다보관 기간 단축민감 정보의 노출 기간을 줄입니다과거 시점과의 이력 비교 분석이 어려워집니다

마스킹을 적용해도 개인정보 위험이 모두 사라지지는 않습니다. 이름 하나를 별표로 가려도 사번, 부서명, 상세 문의 내용이 로그에 함께 남으면 해당 개인을 식별할 수 있기 때문입니다.

필드값 하나를 가리는 처리와, 여러 데이터를 조합해도 특정 개인을 추정할 수 없도록 전체 맥락을 다시 구성하는 처리는 다루는 범위가 다릅니다. 다른 정보와 결합해도 개인을 알아볼 수 없게 만드는 처리를 '익명처리'라고 부릅니다.

‍

마스킹한 로그로도 원인을 확인할 수 있을지

앞선 글에서는 문제 원인을 추적하려면 프롬프트 원문을 남겨야 한다고 설명했습니다. 모델 변경 전후의 응답 변화를 파악하려면 당시 오간 실제 대화가 필요하기 때문입니다. 사람이 직접 점수를 매긴 기준 표본으로 답변 품질을 검증할 때도 원문이 필요합니다. 그런데 마스킹은 그 원문을 지우거나 줄이는 처리이므로 두 요구가 서로 부딪힙니다. 이름을 별표로 가린 문장은 사람이 읽어도 맥락이 끊기고, 그 문장을 채점 모델(LLM-as-a-Judge)에 넣으면 평가 점수도 신뢰하기 어려워집니다.

그래서 모든 원문을 저장하거나 일률적으로 지우는 대신 조건을 나누어 관리합니다. 답변 품질 평가에는 원문이 필요하므로, 마스킹을 적용하기 전 메모리나 격리된 임시 영역에서 원문으로 평가를 먼저 수행합니다. 이후 보존 조건을 만족한 호출만 선택해 짧은 기간 저장하는 아키텍처를 구성합니다. 처리 중 오류가 발생한 호출이나 품질 점수가 기준치 미달인 호출만 원문 저장 대상으로 삼고, 정상 처리된 나머지 호출은 지표만 남깁니다.

원문을 남기기로 결정했다면 저장소 마스킹과 별개로 누가 이 원문을 열람할 수 있는지, 열람 기록을 어떻게 남길지도 함께 설계해야 합니다. 마스킹은 저장 데이터 자체를 가리는 기술적 처리이고, 접근 권한 제어는 마스킹으로 지우지 않고 남긴 데이터를 누구에게 어디까지 보여줄지 정하는 보안 영역입니다.

‍

자주 묻는 질문

‍

마스킹한 값을 나중에 원래대로 되돌릴 수 있나요?

별표(*)로 치환한 마스킹 데이터는 원문 정보가 남아 있지 않아 복원이 불가능합니다. 해시(hash) 처리 역시 역산은 불가능하지만, 전화번호나 주민등록번호처럼 입력값 후보군이 적다면 후보별 해시를 미리 계산해 둔 대조표(레인보우 테이블)로 원문을 알아낼 수 있습니다. 해시는 같은 입력에 항상 같은 결괏값을 내므로 식별자 대조 용도로 쓰고, 복원 위험을 막으려면 비밀 키나 솔트(salt)를 함께 넣어 계산하는 해시 기반 메시지 인증 코드(HMAC) 방식을 씁니다. 무엇보다 원문 복원이 실제로 필요한 요구사항인지 설계 단계에서 먼저 검토하는 편이 좋습니다.

‍

이미 쌓인 로그에 개인정보가 들어 있으면 어떻게 하나요?

가장 먼저 민감 정보가 퍼진 범위를 파악해야 합니다. 주 로그 저장소뿐만 아니라 백업본, 분석용 데이터 레이크, 검색 색인, 개발자가 로컬 환경에 내려받은 사본까지 모두 점검 대상입니다. 실제로 데이터를 지우는 작업보다 전체 노출 목록을 작성하는 데 시간이 더 걸리는 경우가 많습니다. 데이터 삭제 범위와 처리 절차는 법무·보안 담당자와 협의하여 결정합니다.

‍

사용자에게 개인정보를 입력하지 말라고 안내하면 되지 않나요?

화면 안내만으로는 입력 발생을 막기 어렵습니다. 사용자는 자신의 문의 사항이나 맥락을 정확히 설명하려고 이름, 연락처, 사번 등을 자연스럽게 적기 때문입니다. 클라이언트 입력 폼에서 민감 정보를 탐지해 경고 팝업을 띄우는 방법도 있지만, 클라이언트 탐지 규칙 역시 서버 단 마스킹과 같은 탐지 한계(오탐·미탐)가 그대로 있습니다. 사용자 안내는 보조 수단일 뿐, 서버 파이프라인의 마스킹 처리를 대체할 수 없습니다.

‍

AI 모델 제공사도 프롬프트 로그를 저장하나요?

제공사와 계약 형태(API, 웹 인터페이스, Enterprise 등)에 따라 정책이 다르고 자주 바뀝니다. OpenAI는 서비스 오남용 감시를 위해 API 호출 로그를 기본 최대 30일간 보관하며, 보안 점검이나 법적 요구가 있을 시 더 연장할 수 있다고 안내합니다. Enterprise 계약이나 별도 Zero Data Retention(ZDR) 승인을 받은 고객은 이 로그 보관 대상에서 제외할 수 있습니다. Anthropic은 대화 내용을 기본적으로 보관하지 않고, 예외로 지정한 일부 모델(Covered Models)에만 30일 보관을 적용한다고 안내합니다. 쓰고 있는 제공사의 공식 데이터 처리 방침과 계약서를 정기적으로 확인해 둡니다.

‍

프롬프트를 마스킹해서 모델에 보내면 답변이 달라지나요?

네, 답변 품질이 달라집니다. 이름이나 핵심 키워드가 별표로 바뀐 프롬프트를 받으면 모델도 대화 맥락을 정확히 이해하기 어렵습니다. 따라서 로그 저장소에 남길 때 가리는 처리와 모델로 보내기 전에 가리는 처리를 명확히 구분해야 합니다. 답변 품질에 직접 영향을 주는 쪽은 모델로 보내기 전에 가리는 처리입니다. 보호해야 할 자산과 서비스 품질 가운데 무엇을 앞에 둘지에 따라 적용 위치를 정합니다.

‍

개발 환경에서 운영 로그를 그대로 써도 되나요?

운영 데이터를 개발이나 스테이징 환경으로 옮기는 순간 같은 개인정보 사본이 하나 더 생깁니다. 개발 환경은 상대적으로 접근 권한이 느슨하고 보관 기간 정책을 엄격하게 적용하지 않는 경우가 많아 보안 사고에 취약합니다. 버그 재현이나 테스트가 필요하다면 마스킹 처리를 완료한 사본을 활용하거나, 원문 형태만 모방한 합성 데이터(synthetic data)를 생성해 사용하는 것이 안전합니다.

‍

마치며

프롬프트와 응답 원문은 LLM 서비스의 문제를 진단하는 핵심 재료인 동시에 엄격히 보호해야 할 민감 데이터입니다. 자릿수가 정해진 값은 정규식으로 걸러내고, 인명이나 지명처럼 형태가 일정하지 않은 비정형 데이터는 개체명 인식으로 보완하고, 남아 있는 위험은 저장 범위 축소와 보관 기간 단축으로 최소화합니다. 한 가지 방법으로는 놓치는 값이 남으므로 여러 방법을 함께 씁니다. 무엇을 민감 정보로 볼지, 어느 수준까지 지울지는 법무·보안 담당자와 함께 정합니다.

원문 데이터를 일부 보관하기로 정했다면, 어떤 항목이 어떤 형태로 저장되는지 파이프라인 전반을 미리 점검해 두는 편이 좋습니다. 와탭 LLM Observability는 시스템 메시지, 프롬프트, 모델 응답, 도구 호출(tool calling) 내역을 LLM 호출 한 건 단위로 함께 기록하고, 프롬프트 원문이 담긴 화면은 로그 조회 권한이 있는 멤버만 볼 수 있습니다.

‍

더 읽을거리

• ‍프롬프트 및 응답 검색 (와탭 공식 문서)
• ‍Log 개인정보 비식별화 설정 (와탭 공식 문서)
• ‍AI 모델 드리프트란? LLM 성능 저하 원인과 탐지 방법
• ‍LLM API 비용이 급증하는 3가지 원인과 토큰 비용 절감 방법
• ‍LLM 답변 품질 평가 방법과 LLM-as-a-Judge 활용법
• ‍LLM 옵저버빌리티(관찰 가능성)란? LLM 모니터링이 필요한 이유
• ‍Semantic Conventions for Generative AI Spans (OpenTelemetry)
• ‍Redaction Processor (OpenTelemetry Collector Contrib)
• ‍Your data (OpenAI 공식 문서)
• ‍API and data retention (Anthropic 공식 문서)