Presidio + KLUE-BERT로 한국어 PII 탐지 고도화하기 — spaCy NER의 한계를 넘는 실전 가이드

목차

• 핵심 개념
• 사전 준비
• 실전 적용
• spaCy 단독 vs. Transformer 교체 — Before/After 비교
• 장단점 분석
• 실무에서 가장 흔한 실수
• 마치며
• 참고 자료

솔직히 고백하면, 저도 처음에는 spaCy의 ko_core_news 모델만으로 한국어 개인정보 탐지가 충분할 거라 생각했습니다. "서울시 강남구에 거주하는 홍길동"이라는 문장 하나 던져보고 결과가 괜찮길래 안심했죠. 그런데 실제 서비스 데이터를 흘려보내기 시작하니 이야기가 달라졌습니다. "서울에서"라고 쓰면 조사 "에서"까지 엔티티로 잡히고, 문맥이 조금만 복잡해져도 사람 이름을 놓치는 일이 비일비재했습니다. 내부 QA에서 미탐(false negative) 건수를 집계해봤더니 테스트 문서 200건 중 23건에서 이름이나 주소를 놓치고 있었습니다. 2025년 개인정보보호법(PIPA) 개정안이 전면 시행되면서 미탐 하나가 법적 리스크로 직결되는 상황에서, 이 정도 정확도는 받아들이기 어려웠습니다.

이 글에서는 Microsoft Presidio의 TransformersNlpEngine에 KLUE-BERT 기반 NER 모델을 연결해서 한국어 PII 탐지 정확도를 끌어올리는 방법을 다룹니다. spaCy의 전처리 기능은 유지하면서 NER 엔진만 Transformer로 교체하는 하이브리드 구조가 핵심이고, 이 글을 읽고 나면 YAML 설정 하나로 Transformer 기반 한국어 PII 탐지 파이프라인을 구성하고, 정규표현식 Recognizer와 조합하여 정형·비정형 PII를 모두 커버하는 파이프라인을 완성할 수 있습니다. 설정 파일 하나 바꾸는 수준부터 실무에서 마주치는 함정들까지, 제가 겪은 시행착오를 함께 풀어보겠습니다.

잠깐, 용어부터 짚고 넘어가겠습니다. Presidio는 Microsoft가 만든 오픈소스 PII 탐지·익명화 프레임워크이고, **NER(Named Entity Recognition)**은 텍스트에서 사람 이름, 장소, 기관명 같은 고유명사를 찾아내는 기술입니다. Hugging Face는 Transformer 모델들을 공유하고 사용할 수 있는 플랫폼이고요. 이 세 가지를 조합해서 한국어 개인정보를 자동으로 탐지하는 게 이 글의 목표입니다.

핵심 개념

spaCy 한국어 NER, 어디서 한계에 부딪히는가

spaCy는 텍스트를 토큰(단어 단위)으로 쪼개고, 각 토큰의 품사를 분석하고, 문장 내에서 고유명사를 찾아내는 일련의 과정을 하나의 파이프라인으로 제공하는 NLP 라이브러리입니다. ko_core_news 모델은 이 파이프라인의 한국어 버전인데, 나쁜 모델은 아닙니다. 가벼운 파이프라인 덕에 속도도 빠르고요. 문제는 한국어라는 언어의 특성과 CNN 기반 아키텍처의 조합에서 발생합니다.

첫 번째 이슈는 토큰 경계 불일치입니다. 한국어는 "서울에서", "홍길동이", "삼성전자의"처럼 단어 뒤에 조사가 공백 없이 바로 붙습니다 — 이런 언어를 교착어라고 하는데, 이게 토큰화를 까다롭게 만드는 원인입니다. spaCy의 한국어 파이프라인은 이 조사까지 엔티티에 포함시키는 경우가 빈번해서, "서울"만 잡아야 할 장소 엔티티가 "서울에서"로 잡히곤 합니다. 실제로 spaCy GitHub에 관련 이슈(#13705)가 올라와 있을 정도로 알려진 문제입니다.

두 번째는 문맥 이해력의 한계입니다. spaCy의 CNN 기반 파이프라인은 좁은 윈도우 안에서만 문맥을 파악하기 때문에, 긴 문장이나 복잡한 구조에서 엔티티를 놓치거나 잘못 분류하는 일이 잦습니다. PII 탐지에서 미탐은 곧 개인정보 유출 리스크이니, 이건 꽤 치명적인 약점입니다.

TransformersNlpEngine — spaCy와 Transformer의 하이브리드

그래서 Presidio가 제공하는 TransformersNlpEngine이 의미가 있습니다. spaCy 파이프라인의 토큰화, 레마타이제이션 같은 전처리 기능은 그대로 쓰면서, NER 컴포넌트만 Hugging Face Transformers 모델로 교체하는 구조입니다. 왜 이게 좋냐면, spaCy가 잘하는 전처리는 살리면서 못하는 NER만 갈아끼우는 거라 기존 Presidio 파이프라인을 갈아엎을 필요가 없기 때문입니다.

데이터 흐름을 정리하면 이렇습니다:

입력 텍스트
  │
  ▼
┌─────────────────────────────────┐
│  spaCy (ko_core_news_sm)        │  ← 토큰화, 레마타이제이션
│  전처리 파이프라인               │
└──────────────┬──────────────────┘
               │
               ▼
┌─────────────────────────────────┐
│  Transformer NER 모델            │  ← KLUE-BERT 등 Hugging Face 모델
│  (서브워드 토큰 → 엔티티 예측)    │
└──────────────┬──────────────────┘
               │
               ▼
┌─────────────────────────────────┐
│  Presidio Recognizer Registry    │  ← NER 결과 + 정규표현식 Recognizer
│  + 컨텍스트 분석 + 점수 보정      │     + 커스텀 Recognizer 통합
└──────────────┬──────────────────┘
               │
               ▼
          PII 탐지 결과

핵심 인사이트: spaCy는 전처리 담당, Transformer는 NER 담당. 각자 잘하는 일만 하는 분업 구조입니다. 기존 Presidio의 정규표현식 Recognizer나 커스텀 Recognizer도 그대로 동작합니다.

이 구조 덕분에 모델 교체가 간단합니다 — YAML 설정이나 Python 코드에서 모델 이름만 바꿔주면 KLUE-BERT든, KoELECTRA든 바로 적용할 수 있습니다. 기존 파이프라인에 투자한 정규표현식 패턴이나 커스텀 Recognizer를 버리지 않아도 되는 게 실무에서 굉장히 큰 이점입니다.

KLUE-BERT — 한국어를 제대로 이해하는 Transformer

KLUE-BERT는 Korean Language Understanding Evaluation(KLUE) 벤치마크 개발 과정에서 공개된 한국어 사전학습 BERT 모델입니다. 핵심 스펙을 정리하면 이렇습니다.

여기서 주목할 점은 토크나이저입니다. KLUE-BERT는 사전학습 과정에서 Mecab-ko 형태소 분석기와 BPE를 결합한 토크나이제이션을 사용했는데, 이 덕분에 모델이 한국어의 교착어적 특성을 더 잘 학습하게 됩니다. 다만 한 가지 명확히 짚어야 할 점이 있습니다 — Presidio의 TransformersNlpEngine을 통해 추론할 때 Mecab-ko가 자동으로 호출되는 것은 아닙니다. Hugging Face의 klue/bert-base 토크나이저가 내부적으로 학습된 BPE 어휘를 기반으로 서브워드 분할을 수행하는 것이고, 형태소 분석은 사전학습 시 학습 데이터 전처리에 사용된 것입니다. 그래도 형태소 경계를 반영한 어휘로 학습되었기 때문에 "서울에서"를 처리할 때 spaCy보다 자연스러운 분리가 이뤄지는 효과가 있습니다.

한편, Entity F1 83.97%라는 수치는 KLUE 벤치마크 논문에서 보고된 KLUE-BERT base 모델의 결과입니다. 실무 환경에서 90% 이상의 F1이 필요하다면, KLUE-NER 벤치마크에서 Entity F1 92.6%를 기록한 KoELECTRA-base-v3(KLUE 리더보드 기준)나 도메인 특화 파인튜닝 모델을 검토하는 것이 현실적입니다.

사전 준비

코드를 따라해보기 전에 환경부터 갖춰야 합니다. Python 3.8 이상 환경에서 아래 패키지들을 설치하면 됩니다.

# Presidio 핵심 패키지
pip install presidio-analyzer presidio-anonymizer
 
# spaCy 한국어 모델 (전처리용)
python -m spacy download ko_core_news_sm
 
# Transformer 런타임
pip install torch transformers

GPU가 없어도 동작하지만, 실무에서 대량 문서를 처리한다면 CUDA 지원 GPU 환경을 권장합니다. CPU 환경에서는 문서 한 건 처리에 수 초가 걸릴 수 있습니다.

실전 적용

예시 1: YAML 설정으로 5분 만에 구성하기

실무에서 가장 빠르게 적용하는 방법은 Presidio의 YAML 설정 파일을 활용하는 것입니다. 저도 처음엔 Python 코드로 이것저것 삽질하다가, YAML 설정이 있다는 걸 알고 허탈했던 기억이 있습니다.

nlp_engine_name: transformers
models:
  - lang_code: ko
    model_name:
      spacy: ko_core_news_sm
      transformers: klue/bert-base
 
ner_model_configuration:
  labels_to_ignore:
    - O
  aggregation_strategy: max
  stride: 16
  alignment_mode: expand
  model_to_presidio_entity_mapping:
    PER: PERSON
    PS: PERSON
    LC: LOCATION
    OG: ORGANIZATION
    DT: DATE_TIME
    TI: DATE_TIME
    QT: QUANTITY
  low_confidence_score_multiplier: 0.4
  low_score_entity_names:
    - QUANTITY

⚠️ 중요: klue/bert-base는 범용 사전학습 모델이지 NER 파인튜닝 모델이 아닙니다. 이 YAML은 파이프라인 구조를 설명하기 위한 것이며, 실무에서는 transformers 필드에 KLUE-NER로 파인튜닝된 모델(Hugging Face에서 klue ner로 검색)을 넣어야 유의미한 NER 결과를 얻을 수 있습니다.

이 설정에서 각 항목이 하는 역할을 짚어보겠습니다.

aggregation_strategy 보충: Transformer는 텍스트를 서브워드 단위로 쪼개서 처리하는데, 예를 들어 "홍길동"이 "홍", "##길", "##동" 세 토큰으로 나뉠 수 있습니다. 이 세 토큰이 각각 다른 레이블을 예측했을 때 이를 하나의 엔티티로 합쳐야 하는데, max는 가장 높은 확률의 레이블을 선택하고, first는 첫 토큰의 레이블을 따릅니다. 한국어에서는 max가 일반적으로 더 안정적입니다.

alignment_mode 보충: Transformer가 예측한 엔티티 범위와 spaCy가 분절한 토큰 경계가 딱 맞아떨어지지 않을 때, expand는 부분적으로 겹치는 토큰도 엔티티에 포함시키고, strict는 완전히 포함되는 토큰만 인정합니다. PII 탐지에서는 놓치는 것보다 넓게 잡는 게 나으니 expand가 적합합니다.

예시 2: Python 코드로 파이프라인 구성하기

YAML보다 세밀한 제어가 필요하거나, 커스텀 Recognizer를 함께 등록해야 할 때는 Python 코드로 직접 구성하는 편이 낫습니다.

from presidio_analyzer import AnalyzerEngine
from presidio_analyzer.nlp_engine import TransformersNlpEngine
 
# 1. Transformer NLP 엔진 초기화
transformer_engine = TransformersNlpEngine(
    models=[{
        "lang_code": "ko",
        "model_name": {
            "spacy": "ko_core_news_sm",
            "transformers": "klue/bert-base"  # ⚠️ 아래 주의사항 참고
        }
    }]
)
 
# 2. Analyzer 엔진 구성
analyzer = AnalyzerEngine(
    nlp_engine=transformer_engine,
    supported_languages=["ko"]
)
 
# 3. PII 탐지 실행
text = "홍길동의 전화번호는 010-1234-5678이고 서울시 강남구에 거주합니다."
results = analyzer.analyze(text=text, language="ko")
 
for result in results:
    print(f"  {result.entity_type}: '{text[result.start:result.end]}' "
          f"(신뢰도: {result.score:.2f})")

⚠️ 주의: 이 코드는 파이프라인 구조 설명용입니다. klue/bert-base는 사전학습 모델이지 NER 파인튜닝 모델이 아니므로, 그대로 실행하면 유의미한 NER 결과가 나오지 않을 가능성이 높습니다. 실무에서는 Hugging Face 모델 허브에서 klue ner로 검색하여 커뮤니티에서 파인튜닝한 모델(예: klue/bert-base를 KLUE-NER 데이터셋으로 파인튜닝한 모델)을 찾아서 transformers 필드에 해당 모델 ID를 넣어야 합니다.

NER 파인튜닝 모델을 적용했을 때의 예상 출력:

  PERSON: '홍길동' (신뢰도: 0.92)
  PHONE_NUMBER: '010-1234-5678' (신뢰도: 0.95)
  LOCATION: '서울시 강남구' (신뢰도: 0.88)

예시 3: 정규표현식 Recognizer와 조합하는 하이브리드 전략

실무에서 자주 맞닥뜨리는 상황인데, 한국어 PII는 크게 두 가지로 나뉩니다. 주민등록번호, 전화번호, 계좌번호처럼 패턴이 명확한 정형 PII와 사람 이름, 주소, 기관명처럼 문맥 파악이 필요한 비정형 PII입니다. Transformer NER이 아무리 좋아도 주민등록번호 패턴은 정규표현식이 더 정확하고 빠릅니다.

from presidio_analyzer import PatternRecognizer, Pattern
 
# 주민등록번호 패턴 Recognizer
rrn_pattern = Pattern(
    name="korean_rrn",
    regex=r"(?<!\d)(\d{6}[-–]\d{7})(?!\d)",
    score=0.9
)
 
rrn_recognizer = PatternRecognizer(
    supported_entity="KR_RRN",
    supported_language="ko",
    patterns=[rrn_pattern],
    context=["주민등록번호", "주민번호", "생년월일"]
)
 
# Analyzer에 커스텀 Recognizer 추가
analyzer.registry.add_recognizer(rrn_recognizer)

정규표현식에서 \b 대신 (?<!\d)와 (?!\d) (부정 전후방 탐색)를 사용한 것을 눈여겨봐 주세요. \b는 단어 경계를 인식하는 앵커인데, 한국어 텍스트에서는 기대대로 동작하지 않는 경우가 많습니다. "주민번호는123456-1234567입니다"처럼 공백 없이 이어지는 경우 \b가 매칭에 실패할 수 있어서, 숫자가 아닌 문자 경계를 명시적으로 지정하는 편이 안전합니다.

context 파라미터도 중요합니다. Presidio는 패턴이 매칭된 주변 텍스트에서 context에 지정된 단어(여기서는 "주민등록번호", "주민번호", "생년월일")가 발견되면 해당 결과의 신뢰도 점수를 높여줍니다. 즉 "주민번호는 123456-1234567"이라는 텍스트에서는 패턴 매칭(0.9)에 컨텍스트 보정이 더해져서 최종 신뢰도가 올라가는 식입니다. 단순 정규표현식으로는 주민등록번호와 형식이 비슷한 다른 숫자열을 구분하기 어려운데, 이 컨텍스트 분석이 오탐(false positive)을 효과적으로 줄여줍니다.

Presidio의 아키텍처가 빛나는 지점이 바로 여기입니다. Transformer NER이 이름·주소·기관명을 잡고, 정규표현식 Recognizer가 주민등록번호·전화번호·계좌번호를 잡고, 컨텍스트 분석이 신뢰도 점수를 보정하는 — 이 세 계층이 자연스럽게 합쳐지는 구조입니다.

핵심 인사이트: 단일 모델에 모든 걸 맡기지 않는 것이 핵심입니다. 2025년 Scientific Reports에 게재된 연구에서도 규칙 기반 + 머신러닝 하이브리드 방식이 금융 문서 PII 탐지에서 단일 모델 대비 높은 성과를 보였습니다. Presidio는 이 하이브리드 전략을 프레임워크 차원에서 지원하는 셈입니다.

spaCy 단독 vs. Transformer 교체 — Before/After 비교

말로만 "정확도가 올라간다"고 하면 와닿지 않으니, 실제 문장들로 비교해보겠습니다. 아래는 spaCy ko_core_news_sm 단독과, NER 파인튜닝된 Transformer 모델을 적용한 Presidio 파이프라인의 탐지 결과를 정성적으로 비교한 것입니다.

두 가지 패턴이 뚜렷하게 보입니다. 첫째, spaCy의 조사 포함 문제("서울에서", "삼성전자의")가 Transformer에서는 깔끔하게 해소됩니다. 둘째, spaCy가 놓치던 인물명이나 날짜 엔티티를 Transformer가 잡아냅니다. 특히 인물명 미탐이 줄어드는 건 PII 탐지에서 결정적인 차이입니다.

물론 이건 정성적 비교이고, 실무에서는 자체 테스트셋을 만들어서 정량적으로 Precision/Recall/F1을 측정하는 것을 권장합니다. 참고로 한국어 EMR 비식별화 연구(npj Health Systems, 2025)에서는 KLUE-BERT 기반 NER이 퇴원 요약문에서 F1 94.30%를 달성했다는 보고가 있습니다.

장단점 분석

장점

단점 및 주의사항

실무에서 가장 흔한 실수

이 부분은 제가 직접 겪었거나 주변에서 자주 본 케이스들입니다. 북마크해두시면 나중에 도움이 될 겁니다.

1. 사전학습 모델을 NER 파인튜닝 모델로 착각하기 — klue/bert-base는 범용 사전학습 모델입니다. NER 태스크에 바로 쓰면 엔티티를 거의 잡아내지 못합니다. 저희 팀에서도 처음에 이걸 모르고 klue/bert-base를 그대로 넣었다가, 분명히 "홍길동"이 있는 텍스트인데 빈 결과만 돌아와서 한참을 디버깅한 적이 있습니다. Hugging Face에서 KLUE-NER로 파인튜닝된 모델을 찾아 사용하거나, 직접 파인튜닝하는 과정이 필요합니다.

2. 한국어 전용 PII 패턴을 Transformer에만 의존하기 — 주민등록번호(XXXXXX-XXXXXXX), 사업자등록번호(XXX-XX-XXXXX) 같은 한국 고유 식별자는 정규표현식 Recognizer를 별도로 만들어야 합니다. 이런 패턴은 NER 모델의 학습 데이터에 충분히 포함되어 있지 않은 경우가 많고, 패턴이 정형화되어 있어서 정규표현식이 훨씬 정확합니다.

3. 평가 시 Entity F1과 Character F1을 혼동하기 — 한국어 NER에서는 조사 포함 여부에 따라 두 메트릭의 차이가 클 수 있습니다. 예를 들어 "서울에서"를 "서울"로 잡았을 때, Entity F1에서는 틀린 것으로 처리되지만 Character F1에서는 부분 점수를 받을 수 있습니다. PII 탐지 맥락에서는 "개인정보가 포함된 텍스트 범위를 빠뜨리지 않았는가"가 가장 중요하므로, recall 위주의 평가 기준을 잡는 것이 적절합니다.

마치며

spaCy의 한국어 NER 한계는 구조적인 문제이고, Presidio의 TransformersNlpEngine은 기존 파이프라인을 유지하면서 Transformer 모델로 교체할 수 있는 현실적인 경로입니다. 2025년 PIPA 개정으로 자동화된 PII 탐지의 중요성이 더욱 커진 지금, 이 조합은 한국어 개인정보 보호 파이프라인에서 가장 유력한 선택지 중 하나입니다.

지금 바로 시작해볼 수 있는 3단계:

1. 환경 구성: Python 환경에서 pip install presidio-analyzer presidio-anonymizer && python -m spacy download ko_core_news_sm && pip install torch transformers로 기본 의존성을 설치합니다.

2. 빠른 검증: 위의 YAML 설정 또는 Python 코드 예시에서 transformers 필드를 NER 파인튜닝 모델로 교체한 뒤, "홍길동의 전화번호는 010-1234-5678이고 서울시 강남구에 거주합니다." 문장으로 결과를 확인해볼 수 있습니다.

3. 실무 확장: model_to_presidio_entity_mapping을 추가하고, 주민등록번호·전화번호용 커스텀 PatternRecognizer를 등록해서 하이브리드 파이프라인을 완성해볼 수 있습니다. KoELECTRA-base-v3(monologg/koelectra-base-v3-discriminator)로 모델만 교체해보는 것도 성능 비교에 좋은 출발점이 됩니다.

다음 글: Presidio 커스텀 Recognizer 딥다이브 — 주민등록번호, 사업자등록번호, 여권번호까지, 한국형 PII 패턴을 정규표현식과 컨텍스트 분석으로 완벽하게 잡는 방법을 다뤄보겠습니다.

참고 자료

본문 인용

• KLUE: Korean Language Understanding Evaluation 논문 | arXiv
• spaCy 한국어 NER 조사 처리 이슈 #13705 | GitHub
• 한국어 EMR 비식별화 연구 | npj Health Systems (2025)
• 하이브리드 PII 탐지 연구 | Scientific Reports (2025)
• Microsoft Presidio - Transformers NLP Engine 공식 문서
• Microsoft Presidio - NER 모델 설정 가이드
• KLUE-BERT base | Hugging Face
• KLUE 벤치마크 | GitHub

추가 읽을거리

• Microsoft Presidio - 다국어 지원 문서
• Microsoft Presidio | GitHub
• spaCy 한국어 모델 문서
• NER 모델 PII 비교 분석 | Protecto
• 한국어 NER 데이터셋 총정리 | Letr.ai
• 네이버 x 창원대 NER 데이터 | Korpora
• KoBERT | GitHub
• KPF-BERT-NER | Hugging Face
• Presidio TransformersNlpEngine 소스코드 | GitHub