한국어 프롬프트 인젝션, 영어권 연구가 놓치는 것들
프롬프트 인젝션 방어 논의는 대부분 영어 페이로드를 전제로 한다. 한국어 토크나이징, 조사 변형, 한글 유니코드 트릭, 그리고 한국형 PII 정규식 설계라는 국내 실무의 사각지대를 정리한다.
프롬프트 인젝션은 이제 새로운 위협이 아니다. Simon Willison이 2022년 9월에 이름을 붙인 뒤로, OWASP는 LLM Top 10에서 이 문제를 줄곧 1위에 올려두고 있다. Johann Rehberger(embracethered.com)는 지난 몇 년간 ChatGPT 메모리 오염, M365 Copilot 데이터 유출, 코딩 에이전트 RCE까지 실제 동작하는 공격을 매달 쏟아냈다.
그런데 이 훌륭한 연구들에는 공통점이 하나 있다. 거의 전부 영어 페이로드를 전제로 한다는 것. 국내에서 LLM 보안 솔루션을 운영하다 보면, 영어 기준으로 검증된 탐지 정책이 한국어 트래픽 앞에서 다르게 동작하는 지점을 반복해서 마주친다. 이 글은 그 사각지대를 정리한 것이다.
결론 먼저
- 토크나이저가 한국어를 잘게 쪼갠다. 영어 문자열 매칭 기반 필터는 한국어에서 경계가 흐려진다.
- 조사·띄어쓰기·자모 분리가 우회 변형을 쉽게 만든다. “무시해”와 “무 시 해”와 “ㅁㅜㅅㅣㅎㅐ”는 사람에겐 같지만 필터에겐 다르다.
- 한국형 PII 정규식은 오탐과 미탐이 둘 다 심하다. 주민등록번호·전화번호·사업자번호는 형식이 겹치거나 체크섬 구조를 갖고 있어, 단순 패턴만으로는 잡히지 않거나 엉뚱한 숫자를 잡는다.
영어권 벤더 솔루션을 그대로 들여오면 이 세 가지가 조용히 뚫린다. 반드시 한국어 기준으로 재검증하고, 로컬 정책을 얹어야 한다.
1. 토크나이저 문제 — 필터가 보는 것과 사람이 읽는 것이 다르다
대부분의 상용 LLM은 BPE(Byte Pair Encoding) 계열 토크나이저를 쓴다. 영어는 단어 하나가 토큰 하나에 가깝게 떨어지지만, 한국어는 사정이 다르다. 상대적으로 학습 빈도가 낮은 한글 조합은 바이트 단위까지 잘게 쪼개지는 경우가 많다.
이게 왜 보안 문제냐면, 키워드 기반 차단 룰이 토큰 경계나 문자열 경계에 의존할 때 한국어에서는 그 경계가 불안정해지기 때문이다. “이전 지시를 무시하고”를 차단하려고 무시 문자열을 룰에 넣어두면, 공격자는 무^시, 무(0)시, 자모를 분리한 ㅁㅜㅅㅣ 같은 변형으로 사람 눈에는 읽히면서 정확 매칭은 피하는 입력을 만든다.
추측: 토크나이저가 한국어를 잘게 쪼개는 특성이 인젝션 성공률 자체를 “높인다”고 단정할 근거는 아직 부족하다. 다만 문자열/토큰 매칭 기반 방어의 신뢰도를 떨어뜨린다는 것은 실무에서 반복 관찰되는 현상이다. 방어는 문자열 매칭이 아니라 의미 기반(분류 모델) 탐지로 가야 한다는 방향성만큼은 분명하다.
2. 한국어 특유의 우회 변형
영어권 자료에 나오는 우회 기법(대소문자 섞기, 유니코드 homoglyph, Base64 인코딩)은 한국어에도 그대로 통한다. 여기에 한국어만의 변형이 더 붙는다.
- 조사·어미 변형: “지시를 무시해라 / 무시하라 / 무시해줘 / 무시 좀”처럼 같은 명령이 어미만 바꿔 무수히 파생된다. 영어의 “ignore the instructions”보다 표면형이 훨씬 다양하다.
- 띄어쓰기 삽입: 한국어는 띄어쓰기 오류에 관대하다. “무 시 해”를 사람은 자연히 읽지만 정규식은 놓친다.
- 자모 분리·결합:
한글→ㅎㅏㄴㄱㅡㄹ. NFC/NFD 정규화를 안 하면 완성형과 조합형이 다른 바이트열이 된다. - 전각/반각·유사 문자: 라틴 O와 한글 ㅇ, 전각 숫자(０１２)와 반각 숫자(012)는 시각적으로 비슷하거나 같지만 코드포인트가 다르다.
방어 측 실무 시사점은 하나로 모인다. 입력을 탐지 전에 정규화(normalize)하라. 유니코드 NFKC 정규화, 공백 압축, 자모 완성형 변환을 전처리로 넣지 않으면, 위 변형들이 그대로 룰을 우회한다.
3. 한국형 PII 탐지 — 오탐과 미탐의 이중고
프롬프트 인젝션의 목적 중 하나는 PII 유출이다. 그런데 한국형 개인정보는 정규식 설계가 까다롭다.
| 항목 | 형식 | 함정 |
|---|---|---|
| 주민등록번호 | YYMMDD-SXXXXXX (13자리) | 뒷자리에 체크섬 존재. 형식만 맞고 체크섬 틀린 임의 숫자를 잡으면 오탐. 하이픈 없는 표기, 마스킹 표기(901231-1******)도 고려해야 함 |
| 전화번호 | 010-XXXX-XXXX 등 | 계좌번호·주문번호와 자릿수가 겹쳐 오탐. 지역번호·국제표기(+82) 변형 다수 |
| 사업자등록번호 | XXX-XX-XXXXX (10자리) | 역시 체크섬 구조. 다른 10자리 숫자와 혼동 |
| 계좌번호 | 은행별 자릿수 상이 | 표준 형식이 없어 정규식 일반화가 어려움 |
여기서 흔한 실수가 “형식만 맞으면 잡는” 정규식이다. 주민등록번호는 체크섬 검증까지 넣어야 오탐이 줄고, 반대로 마스킹·하이픈 제거 변형까지 커버하지 않으면 미탐이 난다. 오탐이 많으면 사용자가 차단에 지쳐 정책을 무력화하려 들고, 미탐이 많으면 애초에 도입한 의미가 없다. 이 균형점을 찾는 게 국내 LLM 보안 운영의 핵심 실무다.
참고: 정규식만으로 완결하려 하지 말 것. 체크섬 검증 로직을 정규식 뒤에 붙여 2단계로 판정하면 오탐이 크게 줄어든다. 문맥(주변 텍스트에 “주민번호”, “생년월일” 등이 있는지)을 함께 보는 접근도 효과적이다.
그래서, 국내 실무자는 무엇을 해야 하나
- 영어 기준으로 검증된 솔루션의 한국어 커버리지를 반드시 재검증하라. 벤더 데모는 대개 영어다.
- 입력 정규화를 방어의 1단계로 두라. 유니코드 정규화 없이는 위 변형이 그대로 통과한다.
- PII 정규식은 체크섬·문맥 검증과 결합하라. 단순 패턴 매칭은 오탐과 미탐을 동시에 만든다.
- 문자열 매칭에서 의미 기반 탐지로 무게중심을 옮겨라. 한국어 변형의 조합은 룰로 다 막을 수 없다.
프롬프트 인젝션은 “완전히 막을 수 없는” 문제라는 게 지금까지의 업계 합의다. 한국어 환경에서는 여기에 언어적 사각지대가 한 겹 더 얹힌다. 완벽한 차단이 아니라, 탐지율을 유지하면서 오탐을 관리 가능한 수준으로 낮추는 운영이 현실적인 목표다.
참고
- Simon Willison — simonwillison.net (프롬프트 인젝션 개념·방어)
- Johann Rehberger — embracethered.com (실전 공격 연구)
- OWASP GenAI Security Project — LLM Top 10
이 글은 공개 가능한 일반론만 다룬다. 특정 고객사 환경이나 내부 정책 수치는 포함하지 않는다.