특허 명세서 번역기는 왜 “범용 LLM”으로 한계가 있는가 — 직접 만들어 본 이진호 변리사의 기록
안녕하세요! AI 읽어주는 변리사 이진호입니다.
오늘의 핵심 팩트 하나로 시작하겠습니다.
특허 명세서 번역은, 세상의 그 어떤 번역과도 다릅니다.
소설도 아니고, 계약서도 아니고, 일반 기술 문서도 아닙니다. 여기에 필요한 도메인 지식과 클라이언트마다 다른 번역 스타일은, 단순히 “결과물의 품질”만 좌우하지 않습니다. 번역 도구의 설계 구조(architecture) 그 자체를 결정합니다.
저는 바로 그 원칙 위에서 제 번역기를 만들었습니다.
오늘은 제가 직접 특허 번역기를 만들면서 부딪힌 세 가지 벽과, 그것을 어떻게 넘었는지를 정리해 드리겠습니다.
PART 1. 첫 번째 벽 — “용어 일관성”이라는 함정
특허 번역의 가장 엄격한 규칙 중 하나는 용어 일관성(terminology consistency) 입니다.
같은 단어는 100페이지 어디에 나오든 똑같이 번역되어야 합니다. 60페이지 앞에서 “the unit”을 “유닛”이라고 옮겼다면, 마지막 페이지에서도 “유닛”이어야 합니다. “장치”로 바뀌는 순간, 그건 권리범위 해석의 문제가 됩니다.
그런데 여기서 진짜 문제가 시작됩니다.
LLM은 자기가 60페이지 앞에서 그 단어를 어떻게 옮겼는지 “기억하지 못합니다.”
100페이지짜리 명세서 전체에 걸쳐 용어를 일관되게 유지하는 일은, LLM에게 생각보다 훨씬 어려운 작업입니다. 모델은 그저 매 순간 가장 그럴듯한 단어를 새로 생성할 뿐이니까요.
그래서 저는 번역기를 이렇게 설계했습니다.
모델에게 원문 텍스트만 던지지 않습니다. 용어 테이블(glossary, 용어집)에서 가져온 승인된 번역어를 함께 보냅니다.
“이 용어는 반드시 이렇게 옮겨라”라고 못을 박아 두는 것이죠.
용어를 모델의 기억력에 맡기지 않고, 외부 데이터베이스를 통해 고정(locked-in) 시킨 겁니다.
PART 2. 두 번째 벽 — 그것만으로는 부족했다
용어집을 붙였으니 끝일까요?
아닙니다.
특정 청구항 표현(claim language)과 기술 용어를 강제하는 일은 여전히 한계에 부딪혔습니다. 이유는 단순합니다.
LLM은 본질적으로 확률적으로 텍스트를 생성하기 때문입니다.
“이렇게 써라”라고 아무리 지시해도, 모델은 결국 확률 분포 위에서 단어를 고릅니다.
90%는 맞아도, 나머지 10%에서 클라이언트가 싫어하는 표현이 새어 나옵니다.
그래서 저는 한 레이어를 더 얹었습니다.
번역 결과물 위에 각 클라이언트의 번역 스타일을 입히는 후처리(post-processing) 모듈을 추가한 것입니다.
모델이 만들어 낸 출력물을, 클라이언트가 합의한 표현 규칙으로 한 번 더 정제합니다.
결과는 명확합니다.
저는 이제 클라이언트가 선호하는 용어를 안정적으로 고정할 수 있습니다.
확률의 영역에 맡겨 두지 않고, 규칙의 영역으로 끌어내린 것입니다.
PART 3. 진짜 시간 도둑 — 수식, 첨자, 표
하지만, 특허 번역에서 가장 시간을 잡아먹는 작업은, 사실 용어 일관성이 아닙니다.
번역된 문서 안에 수식, 아래첨자(subscript), 표를 그대로 재현하는 일입니다.
전통적으로 번역가들은 이 모든 걸 손으로 일일이 타이핑했습니다.
명세서 한 건에 수백 개의 수식과 아래첨자가 들어 있다면, 그 시간은 무섭게 쌓여 갑니다.
번역 자체보다 “수식 옮겨 적기”에 더 오래 걸리는 일이 흔했죠.
제 번역기는 이 지점을 AI로 해결합니다.
- 수학 수식과 아래첨자를 AI로 인식하고
- 이를 OOXML로 변환한 뒤
- 결과물 DOCX에 수학식, 첨자, 표 등을 그대로 렌더링합니다.
특히 수학식의 경우 OOXML로 렌더링되므로, 수학식에 변수명의 번역이 필요하다면, 변수명도 번역하여 번역문에 수학식을 출력하게 됩니다.
표(table)도 마찬가지입니다. 서식이 그대로 살아 있는 채로 번역문에 옮겨집니다.
이 한 가지만으로 전체 작업 시간이 극적으로 단축됩니다.
PART 4. 그렇다면, 범용 모델이 다 해결해 주지 않을까?
당연히 나올 질문입니다.
“LLM이 계속 발전하는데, 이런 건 알아서 좋아지는 거 아닌가요?”
맞습니다. 상당 부분은 모델이 스스로 개선해 줄 것입니다.
하지만 두 가지는 모델 혼자 풀 수 없습니다.
첫째, 특허 명세서의 작성 스타일은 고객마다 다릅니다. 둘째, 고객마다 번역 스타일이 다릅니다.
그래서 범용 모델은 특허 명세서의 구조를 온전히 이해하지 못하고, 특정 클라이언트의 스타일을 반영해 번역하기도 어렵습니다.
범용 모델은 “평균적인 번역”을 잘합니다. 하지만 특허 번역은 평균이 아니라 특정 클라이언트의 규칙을 요구합니다.
마무리 — 결국, 누가 만드느냐의 문제
저는 이렇게 확신합니다.
특허 명세서 특유의 구조와 클라이언트의 번역 스타일을 둘 다 깊이 이해한 사람만이, 실무에 정말로 쓸 수 있는 특허 번역기를 만들 수 있습니다.
용어집을 붙이고, 후처리로 스타일을 고정하고, 수식을 OOXML로 옮기는 이 모든 설계는
명세서를 직접 써 보고, 클라이언트의 요구를 직접 들어 본 사람만이 떠올릴 수 있는 구조입니다.
그래서 저는 이렇게 생각합니다.
모든 특허법인, 로펌은 결국, 자기 클라이언트마다 맞춤화된 번역기가 필요해질 것입니다.
범용 번역기 하나로 모든 클라이언트를 상대하던 시대는 끝나갑니다.
클라이언트의 스타일을 아는 번역기, 그 법인, 클라이언트의 명세서 구조를 아는 번역기 — 그것이 다음 단계입니다.
특허 명세서 번역에 대해 궁금한 점이나 더 좋은 방법이 있다면 [email protected]으로 연락 부탁 드립니다.
AI 읽어주는 변리사였습니다.