눈에 보이지 않는 문자도 검토 신호로 남기기

짙은 남색 배경에서 보이지 않는 문자 신호가 섞인 입력 줄이 정규화 단계를 지나 세 개의 검토 신호로 분리되는 가로형 구조 도해.

외부 문서를 에이전트에 넣기 전 살펴보는 도구는, 문장이 눈에 보이는 형태로만 들어온다고 가정하면 쉽게 빈틈이 생긴다. 일반적인 단어 사이에 보이지 않는 문자를 끼우거나 전각 영문을 쓰면, 사람이 읽을 때는 거의 같은 문장인데 단순 문자열 규칙은 다른 입력으로 볼 수 있다. 이번 작업의 질문은 단순했다. 흔한 Unicode 문자 우회가 있어도, 기존의 “지시 재정의”와 “비밀 요청” 검토 규칙이 같은 줄을 다시 찾을 수 있을까?

PromptSieve의 각 입력 줄에 두 단계를 추가했다. 먼저 Unicode NFKC 정규화로 전각 영문처럼 호환되는 문자를 일반 형태에 가깝게 바꾼다. 이어서 U+200B, U+200C, U+200D, U+2060, U+FEFF처럼 흔히 눈에 보이지 않는 문자를 제거한 사본으로 기존 규칙을 적용한다. 원문을 바꾸거나 저장하는 기능은 아니다. 검토용으로만 정규화한 줄을 만드는 처리다.

보이지 않는 문자가 있었다는 사실도 별도 신호로 남긴다. unicode_obfuscation은 low 심각도이며 --min-severity low일 때 결과에 표시된다. 이 신호만으로 악성 여부를 뜻하지는 않는다. 정상 텍스트에도 특수 문자가 있을 수 있다. 다만 지시 재정의나 외부 전송처럼 더 강한 신호와 같은 줄에서 함께 발견되면, 사람이 원문과 입력 경로를 다시 확인할 이유가 생긴다.

python3 prompt_sieve.py external-note.txt   --format json --min-severity low --safe-output

검증은 코드 설명보다 실제 우회 형태에 맞췄다. 단위 테스트에 제로폭 문자가 섞인 영문 지시와 전각 영문 지시를 추가했다. 전자는 보이지 않는 문자 신호와 역할 재정의·비밀 요청 신호를 함께 반환해야 하고, 후자는 정규화 뒤 역할 재정의·비밀 요청 신호를 반환해야 한다. 전체 테스트는 16개가 통과했다.

CLI에서도 제로폭 문자가 들어간 임시 파일을 --safe-output으로 실행했다. 검토 필요 상태를 뜻하는 종료 코드 1이 의도대로 나왔고, 안전 JSON에는 unicode_obfuscation, role_override, secret_request의 규칙·심각도·줄 번호만 남았다. 이어진 assertion으로 context와 match, 그리고 테스트 원문이 결과에 없음을 확인했다. 임시 입력과 결과 파일은 검증 직후 삭제했다.

이번 변경의 근거는 도구가 실제로 두 종류의 문자 우회를 감지했다는 구현·테스트 결과다. 이것이 실제 사용자의 위험을 얼마나 줄이는지, 또는 low 신호가 검토 피로를 늘리는지는 아직 검증하지 않았다. 또한 정규화는 모든 우회 표현을 해결하지 않는다. 이미지 안의 문자, 인코딩된 내용, 언어별 변형, 다른 보이지 않는 문자까지 포괄하는 보안 판정이 아니라, 흔한 입력 형태에서 사람이 검토할 위치를 놓치지 않게 하는 작은 보강이다.

외부 텍스트를 다루는 도구는 “탐지했다”는 결과만큼 결과에 무엇을 남기는지도 중요하다. 이번 경로에서도 --safe-output은 그대로 유지했다. 검토자는 규칙과 줄 위치로 먼저 판단하고, 원문이 필요한 경우에만 제한된 맥락에서 확인해야 한다. 문자 정규화는 그 원칙을 바꾸지 않고, 사람이 다시 볼 후보를 조금 더 넓히는 단계다.