50페이지 넘는 특허 명세서, AI에 그냥 넣으면 안 되는 이유

특허 명세서는 짧지 않다. 반도체 분야는 80~150페이지가 일상이고, 바이오·제약 분야는 200페이지를 넘기는 경우도 드물지 않다. 최근 LLM의 컨텍스트 윈도우가 급격히 확대되면서, 이 방대한 문서를 AI 번역 도구에 통째로 넣고 결과를 받아쓰는 실무자가 늘고 있다.

결론부터 말하면, 이 방식은 특허 문서에서는 위험하다. 일반 기술 문서라면 모를까, 특허 명세서에는 한 단어의 불일치가 거절 사유가 되고, 한 문장의 누락이 권리 포기로 이어질 수 있는 구조적 특수성이 있기 때문이다.

이 글에서는 특허 문서가 일반 문서와 근본적으로 어떻게 다른지, 2026년 최신 AI 모델이 실제로 어디까지 처리할 수 있고 어디서 한계를 보이는지, 그리고 이 한계를 전제로 AI를 효과적으로 활용하는 실전 워크플로우를 정리한다.

특허 문서가 일반 문서와 다른 3가지 구조적 특성

AI 번역 도구에 논문이나 매뉴얼을 넣는 것과 특허 명세서를 넣는 것은 완전히 다른 작업이다. 그 이유는 특허 문서만의 구조에 있다.

청구항과 명세서의 법적 교차 참조

특허 문서에서 청구항(Claims)은 권리범위를 정의하고, 명세서(Description)는 그 청구항을 뒷받침한다. 이 둘은 독립된 문서가 아니라 법적으로 서로를 참조하는 하나의 체계다. 한국 특허법 제42조 제4항은 "청구범위는 발명의 상세한 설명에 의하여 뒷받침되어야" 한다고 명시하며, KIPO 심사기준은 명세서 전체에서 용어를 통일적으로 사용할 것을 요구한다. 미국 특허법 35 U.S.C. §112(a), 유럽 특허조약 Article 84, 일본 特許法 제36조 제6항 제1호, 중국 专利法 제26조 제4항도 모두 동일한 원칙을 규정한다. 청구항에서 "signal processing unit"이라고 썼는데 명세서 전체에서 "signal processor"만 사용했다면, 어느 나라에서든 거절 사유가 된다.

번역에서 이것이 의미하는 바는 명확하다. 청구항의 핵심 용어와 명세서의 용어가 100% 동일해야 한다. 이것은 "의미가 통하면 된다"는 일반 번역의 기준과 근본적으로 다르다.

선행사(Antecedent Basis) 체인

특허 문서에서 "상기(said/the/前記/所述)"는 단순한 지시어가 아니라, 앞서 도입된 특정 구성요소를 법적으로 가리키는 표지다. 독립항 1에서 도입된 "제어 유닛"은 종속항 5에서도, 명세서 80페이지에서도 정확히 같은 "제어 유닛"이어야 한다. 이 참조 체인이 한 번이라도 끊기면, 청구항의 명확성(definiteness) 요건에 문제가 생긴다.

번역 누락의 법적 결과

일반 문서에서 한 문장이 빠지면 의미 전달에 문제가 생기는 정도지만, 특허 명세서에서 한 문장이 빠지면 해당 기술 내용에 대한 권리를 주장할 근거 자체가 사라질 수 있다. 명세서에 기재되지 않은 사항은 청구항으로 보호받을 수 없다는 원칙(한국 특허법 제42조 제4항, 35 U.S.C. §112(a), EPC Article 84)은 원문에도 번역문에도 동일하게 적용된다. 번역 과정에서 누락된 문장이 있다면, 원문에는 존재하는 권리 근거가 번역문에서는 사라지는 셈이다.

"100페이지도 다 들어가는데요?" — 컨텍스트 윈도우의 진실

2026년 4월 현재, 주요 LLM의 컨텍스트 윈도우는 급격히 확대됐다. GPT-5.4는 API에서 최대 100만 토큰을 지원하고, Google Gemini 3.1 Pro도 100만 토큰의 컨텍스트 윈도우를 제공한다. Claude Opus 4.6은 20만 토큰이다. 특허 명세서 50페이지가 대략 5~8만 토큰, 200페이지가 20~30만 토큰이니, 숫자만 보면 "다 들어가는" 것처럼 보인다.

하지만 "들어간다"와 "제대로 처리한다"는 전혀 다른 이야기다.

Lost in the Middle: AI는 중간을 잊는다

2023년 Stanford와 UC Berkeley 연구팀(Liu et al.)이 실증한 "Lost in the Middle" 현상은 2026년 현재까지 주요 모델에서 여전히 관찰된다. 핵심은 이렇다: LLM은 입력 텍스트의 처음과 끝에 위치한 정보는 잘 기억하지만, 중간에 위치한 정보의 회수 정확도는 유의미하게 떨어진다.

업계 벤치마크에 따르면, 공식 컨텍스트 윈도우와 실제 성능 사이에는 격차가 있다. 입력이 길어질수록 문서 중간부의 정보 회수 정확도가 떨어지는 현상은 모델과 태스크에 따라 정도의 차이는 있지만, 완전히 해소되지는 않았다. 특허 번역처럼 문서 전체에 걸쳐 용어의 완벽한 일관성이 요구되는 작업에서는, 이 성능 저하가 실질적인 위험으로 작용한다.

특허 번역에서 이것이 특히 위험한 이유

100페이지짜리 명세서를 통째로 넣으면, 문서 중간부에 위치한 용어가 가장 불안정해진다. 청구항에서 확정된 용어가 명세서 50페이지 부근에서 다른 표현으로 바뀌고, 후반부에서 또 다른 표현이 등장하는 식이다. 이 현상을 **용어 드리프트(terminology drift)**라고 하며, 다음 섹션에서 구체적인 예시와 함께 살펴본다.

AI가 장문 특허에서 실제로 실패하는 패턴 4가지

컨텍스트 윈도우의 구조적 한계를 넘어, 특허 문서 번역에서 AI가 보이는 구체적인 실패 패턴을 살펴보자. 실무에서 가장 괴로운 점은, 이 오류들이 "틀린 티"가 잘 나지 않는다는 것이다. 문장 단위로 읽으면 매끄럽고 자연스러운데, 문서 전체를 대조해야 비로소 드러나는 오류들이다. 그래서 사후에 고치는 데 드는 시간이 처음부터 제대로 번역하는 시간보다 오히려 더 걸리는 경우가 빈번하다.

패턴 1: 용어 드리프트 — AI는 "용어 통일"이라는 개념 자체를 모른다

근본적인 문제부터 짚어야 한다. AI는 특허 번역에서 용어 일관성을 유지해야 한다는 것을 아예 모른다. 일반 번역에서는 같은 단어를 반복하지 않고 다양하게 바꿔 쓰는 것이 좋은 글쓰기로 평가된다. AI는 바로 그렇게 학습돼 있다. "회전 부재"를 처음에는 "rotating member"로, 다음에는 "rotation component"로, 또 다음에는 "rotational element"로 바꿔 쓰는 것이 AI 입장에서는 더 "자연스러운" 번역이다.

하지만 특허에서 이것은 치명적이다. 세 표현이 같은 부품을 가리키는지, 서로 다른 부품인지 심사관은 판단할 수 없다.

Before (AI 번역 — 용어 불일치)

청구항: "A rotating member is connected to a drive shaft..."

명세서 [0015]: "The rotation component is formed in a circular disk shape..."

명세서 [0023]: "The rotational element rotates clockwise..."

After (전문가 검수 후)

청구항: "A rotating member is connected to a drive shaft..."

명세서 [0015]: "The rotating member is formed in a circular disk shape..."

명세서 [0023]: "The rotating member rotates clockwise..."

이 오류가 미국 출원에서 실제 거절로 이어진 패턴이 있다. 심사관은 "Claim 1 recites 'signal processing unit', but the specification only describes a 'signal processor'. The term is not found in the specification, therefore the claim lacks written description support under 35 U.S.C. §112(a)."와 같은 이유로 거절한다. 일본(特許法第36条第6項第1号)과 유럽(Article 84 EPC)에서도 동일한 유형의 거절이 발생한다.

패턴 2: 종속항 참조 체인 붕괴

독립항과 종속항은 법적인 참조 관계로 연결돼 있다. 종속항 3번이 "제1항에 있어서(The apparatus of claim 1)"로 시작한다면, 이 참조 관계가 번역에서도 정확히 유지돼야 한다. 장문 특허에서 종속항이 20~30개 이상일 때, AI는 참조 번호를 잘못 매핑하거나, 종속 관계 자체를 누락하는 경우가 발생한다.

특히 종속항이 다른 종속항을 인용하는 체인 구조(claim 5 → claim 3 → claim 1)에서는, AI가 중간 인용을 건너뛰어 원래의 인용 체계와 다른 구조를 만들어내기도 한다.

패턴 3: 청구항을 일반 문장으로 번역해 버린다

실무에서 체감하는 가장 고질적인 문제다. 청구항은 독특한 문법 구조를 갖는다. 하나의 청구항이 하나의 문장이고, 전제부(preamble)–전환구(comprising/consisting of)–본문부(body)라는 정해진 형식을 따르며, 구성요소를 세미콜론으로 나열하고, "상기(said/the)"로 선행사를 추적한다. 이것은 일반 기술 문서의 문장과 완전히 다른 체계다.

AI는 이 구조를 인식하지 못하고, 청구항을 일반적인 기술 설명문처럼 번역하는 경우가 많다. 하나의 문장이어야 할 청구항이 여러 문장으로 분리되거나, 세미콜론 대신 마침표가 찍히거나, "~을 포함하는(comprising)" 대신 "~이 있다(there is)"와 같은 서술형 표현이 사용된다. 이렇게 되면 청구항의 법적 구조 자체가 무너진다.

문제는 이런 오류를 고치는 작업이 단순한 수정이 아니라 사실상 재번역에 가깝다는 점이다. 문장 구조를 다시 세우고, 전환구를 복원하고, 선행사 관계를 재설정해야 한다. AI 출력물을 교정하는 데 걸리는 시간이 전문 번역가가 처음부터 번역하는 시간을 초과하는 경우가, 특히 청구항에서 빈번하게 발생한다.

패턴 4: 수치·단위의 조용한 변환

50~200페이지에 걸쳐 수치와 범위가 반복적으로 등장하는 화학·제약 특허에서 특히 위험한 패턴이다. 청구항에서 "10 nm to 100 nm"으로 한정한 범위가 명세서 후반부에서 "10 μm to 100 μm"으로 단위가 바뀌거나, "100°C or more"가 "more than 100°C"로 번역되어 경계값 포함 여부가 달라지는 경우가 있다. 특허에서 "이상(or more)"과 "초과(more than)"는 법적으로 다른 범위를 의미한다.

실전 워크플로우: 특허 문서를 AI로 번역하는 올바른 순서

위의 문제들을 인식한 상태에서 AI를 활용하면, 효율성과 정확성을 동시에 확보할 수 있다. 핵심은 문서를 통째로 넣지 않고, 특허 문서의 구조에 맞게 단계적으로 처리하는 것이다.

Step 1: 명세서를 먼저 읽고, 청구항부터 번역한다

원칙적으로 청구항은 특허의 골격이고, 여기서 확정된 용어가 문서 전체의 기준이 된다. 그래서 청구항을 먼저 번역하는 것이 이상적이다.

하지만 실무에서는 모순이 있다. 청구항에 등장하는 기술 용어를 정확히 번역하려면, 상세한 설명을 먼저 이해해야 하는 경우가 빈번하다. 청구항에 "결합 수단"이라고만 적혀 있을 때, 이것이 볼트 체결인지, 접착인지, 용접인지는 명세서의 실시예를 봐야 판단할 수 있다. 기술 맥락을 모른 채 청구항만 보고 번역하면 오히려 부정확한 용어를 확정하게 되는 위험이 있다.

실전에서의 해법은 이렇다: 명세서 전체를 먼저 통독하여 발명의 기술 내용을 파악한 후, 청구항을 번역한다. 이 통독 단계에서는 번역을 하지 않는다. 기술 맥락을 이해하는 데만 집중한다. 이 과정에서 AI를 활용할 수 있다. 명세서를 AI에 넣어 기술 내용의 요약을 받는 것은 용어 일관성 문제가 발생하지 않으므로 안전하다. 기술 맥락이 파악된 상태에서 청구항을 번역하면, 용어 선택의 정확도가 올라간다.

Step 2: 청구항 기준으로 용어집을 확정한다

청구항에서 확정된 핵심 용어를 기반으로 문서 전체에 적용할 용어집(Glossary)을 만든다. "rotating member = 회전 부재", "control unit = 제어 유닛"처럼 원문-번역문 대응을 확정하고, 이 용어집이 이후 명세서 번역의 기준선이 된다.

Step 3: 명세서를 논리적 단위로 분할하여 번역한다

명세서를 AI에 넣을 때는 문서의 논리적 구조에 따라 분할한다. 발명의 배경, 발명의 요약, 도면의 간단한 설명, 상세한 설명(실시예별)을 각각 별도로 처리하되, 매번 Step 2에서 확정한 용어집을 함께 제공한다. 이렇게 하면 AI가 각 섹션을 독립적으로 번역하더라도 용어의 일관성이 유지된다.

Step 4: 교차 검증 — 청구항과 명세서의 용어 정합성 확인

번역이 완료된 후, 청구항에 사용된 모든 핵심 용어가 명세서 전체에서 동일하게 유지됐는지 확인한다. 이 단계는 AI로 자동화할 수 있는 부분이기도 하다. 동일 원문 용어가 번역문에서 서로 다르게 번역된 곳을 검출하는 것은 AI가 오히려 잘하는 작업이다. 최종적으로는 특허 번역 전문가가 선행사 추적, 인용 번호 정확성, 수치 범위의 경계값 처리를 검수한다.

용어 일관성이 깨지면 실제로 무슨 일이 벌어지나

용어 불일치가 "그냥 표현의 차이" 수준이 아님을 보여주는 실제 거절 패턴이 있다.

한국 KIPO에서는 특허법 제42조 제4항 위반으로 거절된다. 청구항에서 "제어 유닛"이라고 기재했는데 명세서 전체에서 "제어부"로만 설명되어 있으면, 심사관은 청구범위가 발명의 상세한 설명에 의해 뒷받침되지 않는다고 판단한다. 미국에서는 Written Description Rejection으로 나타난다. 청구항의 "control circuit"이 명세서에서는 "control module"로만 기재되어 있을 때, 심사관은 §112(a) 위반으로 거절한다. 일본 JPO에서는 サポート要件違反(서포트 요건 위반)으로, 청구항의 "駆動機構(구동 기구)"가 명세서에서 "駆動装置(구동 장치)"와 불일치할 때 特許法第36条第6項第1号 위반이 된다. 중국 CNIPA에서는 专利法 제26조 제4항 위반으로, 청구항의 "传感器模块(센서 모듈)"이 명세서에서 "感应装置(감응 장치)"로 기재되어 있으면 청구범위가 설명서의 뒷받침을 받지 못한다고 거절한다. 유럽 EPO에서는 Article 84 EPC 위반으로, 청구항과 명세서 간 용어 불일치가 청구항의 명확성을 해친다고 판단한다.

다섯 관할 모두, 해결 방법은 동일하다: 용어를 통일하거나, 두 용어가 동일한 개념임을 명세서에서 명시적으로 설명하는 보정을 해야 한다. 이 보정은 추가 비용과 시간을 의미하고, 국내단계 진입 기한이 촉박한 경우 치명적인 지연을 초래할 수 있다.

FAQ

Q: AI 번역 도구에 특허 명세서를 통째로 넣어도 되나요?

A: 내부 참고용 초벌 번역이라면 시도해 볼 수 있지만, 출원용 번역이라면 권장하지 않는다. 용어 드리프트, 종속항 참조 오류, 수치 변환 오류가 발생할 확률이 높고, 이를 사후에 잡아내는 비용이 처음부터 단계별로 번역하는 비용보다 오히려 클 수 있다.

Q: 컨텍스트 윈도우가 100만 토큰이면 200페이지도 처리되지 않나요?

A: 물리적으로는 입력 가능하다. 하지만 "Lost in the Middle" 현상으로 인해 문서가 길어질수록 중간부의 정보 처리 정확도가 떨어진다. 컨텍스트 윈도우의 숫자가 크다고 해서 그 전체 구간에서 동일한 품질이 보장되는 것은 아니며, 특허 번역에서 요구되는 용어 일관성 수준을 유지하기는 어렵다.

Q: 어떤 AI 도구가 특허 번역에 가장 적합한가요?

A: 특정 도구보다 사용 방법이 더 중요하다. 어떤 도구를 쓰든 핵심은 동일하다: 청구항을 먼저 번역하고, 용어집을 확정하고, 명세서를 분할 처리하고, 교차 검증하는 워크플로우를 지키는 것이다. 도구 자체의 성능 차이보다 이 프로세스의 유무가 결과물 품질을 결정한다.

Q: 용어집은 몇 개 단어 수준으로 만들어야 하나요?

A: 문서의 기술 분야와 복잡도에 따라 다르지만, 보통 청구항의 핵심 구성요소 용어 30~80개 수준이다. 양보다 중요한 것은 청구항에 등장하는 모든 구성요소 용어가 빠짐없이 포함되는 것이다.

Q: 청구항과 명세서를 다른 사람이 번역해도 되나요?

A: 실무적으로는 가능하지만, 반드시 동일한 용어집을 공유하고 교차 검증 단계를 거쳐야 한다. 서로 다른 번역자가 같은 용어를 다르게 번역하는 것이 용어 불일치의 가장 흔한 원인 중 하나다.

참고 자료

• Liu, N. F., et al. (2023). Lost in the Middle: How Language Models Use Long Contexts. arXiv:2307.03172.
• 특허법 제42조 제4항 — 청구범위의 기재요건. KIPO.
• 35 U.S.C. §112(a) — Written Description Requirement. USPTO.
• EPC Article 84 — Claims must be supported by the description. EPO.
• 特許法第36条第6項第1号 — 청구항의 서포트 요건. JPO.
• 专利法第26条第4款 — 권리요구서는 설명서에 의해 뒷받침되어야 함. CNIPA.
• ISO 17100:2015 — Translation services — Requirements for translation services.
• Morph LLM (2026). LLM Token Limits: Every Model's Context Window Compared. morphllm.com.
• Elvex (2026). Context Length Comparison: Leading AI Models in 2026. elvex.com.
• OpenAI (2026). Introducing GPT-5.4. openai.com.