눈에 보이는 글자와 실제 글자가 다르다면? 폰트로 위장한 법률 사기와 Rust 방어 도구

폰트가 거짓말을 한다는 게 무슨 말이냐면

PDF 문서를 받았는데, 화면에는 "Roboto"라고 적혀 있어요. 그런데 그 PDF 안에 진짜 들어 있는 글자는 "Robot0"이에요. 사람 눈에는 똑같아 보이지만, 컴퓨터가 텍스트를 검색하거나 복사하면 전혀 다른 글자가 튀어나오는 거죠. Tritium이라는 법률 기술 회사가 최근 블로그에 공개한 "Noroboto" 사건은 바로 이런 폰트 속임수가 실제 법률 문서에서 발견된 사례를 다루고 있어요. 그리고 이걸 막기 위한 Rust 기반 검증 도구도 함께 공개했고요.

이게 왜 문제가 되냐면, 법률 문서나 계약서는 텍스트의 정확성이 생명이거든요. 변호사가 "이 조항에 'shall not'이라고 적혀 있죠?"라고 확인했는데, 실제 PDF 안의 텍스트는 "shall"이고 "not"은 폰트로만 그려진 거라면? 자동화된 계약 검토 시스템, 전자 서명 시스템, 검색 시스템이 모두 속을 수 있어요. 더 무서운 건 이게 단순한 버그가 아니라 의도적인 공격으로도 쓸 수 있다는 점이에요.

PDF 폰트의 구조, 이게 어떻게 가능할까

PDF에서 텍스트는 "글리프"라는 그림 조각과 "문자 코드"의 매핑으로 표현돼요. 예를 들어 코드 0x41이 들어오면 "A 모양의 글리프를 그려라"라고 약속하는 거죠. 그런데 PDF는 이 매핑을 폰트 안에 자유롭게 정의할 수 있어요. 즉, 코드 0x41을 받아서 "B 모양 글리프"를 그리도록 만들 수 있다는 뜻이에요.

악의적인 폰트는 이 자유도를 악용해요. 텍스트 스트림에는 "이 계약은 무효다"라고 적어놓고, 폰트의 글리프 매핑은 "이 계약은 유효하다"처럼 보이게 그리는 거죠. 사람이 PDF를 열면 "유효하다"가 보이지만, 검색하거나 복사하면 "무효다"가 나와요. 또 반대로도 가능해요. 사람 눈에는 정상으로 보이지만, 검색 엔진이나 OCR이 추출하는 텍스트는 완전히 다른 내용이 되는 거죠.

Rust로 만든 방어 도구, 어떻게 동작하나

Tritium이 공개한 도구는 PDF를 파싱해서 폰트의 글리프 매핑을 직접 검사해요. 핵심 아이디어는 "폰트가 주장하는 문자"와 "실제 그려지는 모양"이 일치하는지 확인하는 거예요. 표준 폰트(Roboto, Arial 같은)와 비교해서 모양이 크게 다르면 경고를 띄우는 방식이고요. 또 ToUnicode 매핑이라는 PDF 표준 기능을 활용해서, 텍스트 추출 시 쓰이는 매핑과 화면 표시용 매핑이 일치하는지도 검증해요.

Rust로 만든 이유는 명확해요. PDF 파싱은 메모리 안전성이 정말 중요한 영역이거든요. 악의적으로 조작된 PDF가 파서를 공격하는 사례가 역사적으로 정말 많았어요. C나 C++로 짠 파서는 버퍼 오버플로우 같은 취약점이 자주 발견됐고요. Rust는 컴파일 타임에 이런 메모리 오류를 막아주니까, 신뢰할 수 없는 PDF를 다루기에 적합한 선택이에요. 게다가 성능도 빠르고, 단일 바이너리로 배포하기도 편하고요.

비슷한 위협들과 업계의 대응

폰트 속임수는 사실 새로운 개념은 아니에요. 유니코드 동형 문자 공격(homograph attack)이라는 게 오래전부터 있었어요. 키릴 문자 'а'와 라틴 문자 'a'가 모양이 똑같이 생긴 걸 이용해서 가짜 도메인을 만드는 피싱 기법이죠. 'аpple.com'처럼요. 브라우저들은 이걸 막기 위해 Punycode 표시를 도입했고요.

PDF 폰트 공격은 여기서 한 단계 더 나아간 거예요. 문서 내부에서 "보이는 것"과 "읽히는 것"을 완전히 분리할 수 있으니까요. Adobe Acrobat이나 Foxit 같은 상용 뷰어들도 이런 공격을 완벽하게 막진 못해요. 결국 자동화된 문서 처리 파이프라인에서는 별도의 검증 단계가 필수가 되고 있어요. 특히 LegalTech, FinTech, 그리고 AI로 계약서를 자동 분석하는 회사들이 이 문제에 민감해지고 있고요.

한국 개발자가 알아두면 좋을 점

한국에서도 전자 계약, 전자 세금계산서, 공문서 디지털화가 빠르게 진행되고 있어요. PDF 기반 워크플로우를 다루는 분이라면 이런 폰트 레벨 공격이 가능하다는 사실을 꼭 알아두셔야 해요. 특히 LLM에게 PDF를 던져서 요약하거나 검토시키는 서비스를 만드시는 분들은 더더욱이요. LLM은 추출된 텍스트만 보고 판단하니까, 화면에 보이는 것과 다른 결과를 내놓을 수 있거든요.

실무에서는 PDF에서 텍스트를 추출한 후 OCR로도 한 번 더 추출해서 두 결과를 비교하는 방법이 가장 확실해요. 둘이 크게 다르면 의심해봐야 하고요. 오픈소스로는 pdfplumber, PyMuPDF 같은 도구가 글리프 정보까지 접근할 수 있어서 검증 로직을 짤 때 유용해요.

마무리

"보이는 게 전부가 아니다"라는 말이 PDF 세계에서는 글자 그대로 사실이에요. 자동화된 문서 처리 시스템을 만든다면 텍스트 추출 결과를 한 번쯤은 의심해보세요. 여러분이 다루는 문서 파이프라인은 이런 폰트 공격에 얼마나 견딜 수 있을까요?