
"AI가 특허를 읽기 전에 알아야 할 특허 데이터 구조"
지난 글에서는 특허를 기술기업의 재무제표처럼 볼 수 있는지에 대해 이야기했다. 재무제표가 기업의 과거 경영성과를 보여준다면, 특허는 기업이 어떤 기술문제를 해결하려고 하는지, 어떤 기술영역에 연구개발 자원을 투입하고 있는지, 그리고 어떤 방식으로 경쟁우위를 확보하려는지를 보여주는 기술정보 데이터가 될 수 있다.
하지만 특허를 AI로 분석하기 위해서는 먼저 특허 문서를 하나의 긴 텍스트로만 보면 안 된다.
특허는 제목, 초록, 청구항, 상세한 설명, 기술분류, 출원인, 출원일, 인용관계 등 여러 층위의 정보로 구성되어 있다. 각각의 필드는 서로 다른 의미를 갖고 있으며, 분석 목적에 따라 활용 방식도 달라진다.
이번 글에서는 Patent Intelligence Agent를 만들기 위한 첫 단계로, 특허 문서를 어떤 데이터 구조로 바라봐야 하는지 정리해본다.
1. 특허는 단순 문서가 아니라 구조화된 기술 데이터다
일반적인 뉴스 기사나 블로그 글과 달리 특허 문서는 일정한 형식을 갖는다. 기술적 문제, 해결수단, 권리범위, 적용 분야, 기존 기술과의 차별점이 비교적 정형화된 방식으로 기록된다.
특허 문서를 데이터 관점에서 보면 다음과 같이 분해할 수 있다.
┌──────────────────────────────────────────────┐
│ Patent Document │
├──────────────────────────────────────────────┤
│ 1. Bibliographic Data │
│ - Patent ID │
│ - Applicant │
│ - Inventor │
│ - Filing Date │
│ - Publication Date │
│ │
│ 2. Technical Text │
│ - Title │
│ - Abstract │
│ - Claims │
│ - Description │
│ │
│ 3. Classification Data │
│ - IPC │
│ - CPC │
│ │
│ 4. Network Data │
│ - Backward Citation │
│ - Forward Citation │
│ │
│ 5. Legal Data │
│ - Legal Status │
│ - Expiration │
│ - Patent Family │
└──────────────────────────────────────────────┘
이 구조를 이해하는 것이 중요한 이유는 간단하다. AI 모델은 문서를 “이해”하는 것이 아니라, 입력된 데이터를 벡터나 토큰 형태로 변환해 패턴을 학습한다. 따라서 어떤 필드를 입력으로 사용할지, 어떤 필드를 검증 기준으로 둘지, 어떤 필드를 나중에 그래프 분석으로 확장할지 미리 정의해야 한다.
처음 프로젝트에 필요한 핵심 데이터는 다음 정도다.
| 데이터 필드 | 의미 | 분석 활용 |
| Title | 발명의 제목 | 기술 주제 파악 |
| Abstract | 발명의 요약 | 임베딩, 유사 특허 검색 |
| Applicant | 출원인 | 기업별 포트폴리오 분석 |
| Filing Date | 출원일 | 기술 변화 시계열 분석 |
| IPC/CPC | 기술분류코드 | 클러스터 검증 기준 |
| Claims | 권리범위 | 보호범위, 차별성 분석 |
| Citation | 인용관계 | 기술 영향력, 네트워크 분석 |
처음부터 모든 필드를 다 쓰려고 하면 프로젝트가 복잡해진다. 그래서 초기 MVP에서는 Title과 Abstract를 중심으로 시작하고, 이후 Claims, Citation, Description으로 확장하는 방식이 적절하다.
2. Title: 기술 주제를 가장 압축적으로 표현한 필드
Title은 발명의 제목이다. 특허의 기술 주제를 가장 짧고 압축적으로 보여준다.
예를 들어 다음과 같은 제목이 있다고 하자.
Method for detecting anomaly in manufacturing equipment
이 제목만 보더라도 해당 특허가 제조장비의 이상탐지 방법과 관련되어 있다는 것을 빠르게 파악할 수 있다.
Title은 짧고 노이즈가 적기 때문에 검색 키워드 추출에는 유용하다. 하지만 정보량이 부족하다는 한계가 있다. 제목만으로는 기술적 차별성, 구체적인 알고리즘, 적용 환경, 문제 해결 방식까지 파악하기 어렵다.
따라서 Title은 단독으로 쓰기보다 Abstract와 결합해서 사용하는 것이 좋다.
| Title 장점 | Title 단점 |
| - 짧고 명확하다 - 핵심 키워드가 들어있다. - 1차 검색과 라벨링에 유용하다 |
- 정보량이 적다 - 기술적 차별성을 알기 어렵다 - 알고리즘, 적용 환경, 효과가 생략될 수 있다. |
초기 분석에서는 Title만 사용하기보다 Title + Abstract 조합을 하나의 분석 텍스트로 구성하는 것이 현실적이다.
3. Abstract: AI가 읽기 가장 좋은 기술 요약문
Abstract, 즉 초록은 특허의 핵심 내용을 요약한 부분이다. 일반적으로 발명이 해결하려는 문제, 주요 구성, 작동 방식, 기대 효과가 압축적으로 들어간다.
AI 기반 특허 분석에서 Abstract는 매우 중요하다. 너무 짧은 Title보다 정보량이 많고, 너무 긴 Description보다 노이즈가 적다. 그래서 처음 특허 텍스트 임베딩을 만들 때는 Abstract를 가장 먼저 사용하는 것이 좋다.
이상탐지 관련 특허의 Abstract에는 보통 다음과 같은 정보가 들어갈 수 있다.
Abstract에서 볼 수 있는 정보
- 어떤 데이터를 수집하는가
- 어떤 모델이나 알고리즘을 사용하는가
- 정상 상태와 비정상 상태를 어떻게 구분하는가
- 어느 산업이나 장비에 적용되는가
- 기존 방식 대비 어떤 장점이 있는가
Abstract 기반 임베딩을 만들면 다음과 같은 분석이 가능하다.
┌────────────────────┐
│ Abstract │
└─────────┬──────────┘
│
▼
┌────────────────────┐
│ Text Embedding │
│ TF-IDF / SBERT │
└─────────┬──────────┘
│
▼
┌────────────────────┐
│ Similarity Search │
│ 유사 특허 Top-K 검색│
└─────────┬──────────┘
│
▼
┌────────────────────┐
│ Technology Cluster │
│ 기술군 자동 분류 │
└────────────────────┘
즉, Abstract는 Patent Intelligence Agent의 첫 번째 입력 데이터로 적합하다.
4. Claims: 중요하지만 처음부터 다루기 어려운 데이터
Claims, 즉 청구항은 특허에서 가장 중요한 부분이다. 특허의 기술적 설명이 “무엇을 발명했는가”를 말한다면, 청구항은 “어디까지 권리로 보호받을 것인가”를 정의한다.
기술분석 관점에서 Claims는 매우 가치가 높다. 기업이 실제로 보호하고 싶은 핵심 기술요소가 청구항에 들어가기 때문이다. 하지만 동시에 분석 난이도도 높다.
청구항은 문장이 길고, 법률적 표현이 많고, 독립항과 종속항 구조를 가진다. 예를 들어 “제1항에 있어서…”와 같은 표현이 반복되며, 기술적 구성요소가 복잡하게 연결된다.
그래서 초기 프로젝트에서는 Claims 전체를 바로 분석 대상으로 삼기보다, Title과 Abstract 중심으로 시작한 뒤 고도화 단계에서 Claims를 추가하는 것이 좋다.
Claims로 확장했을 때 가능한 분석
- 권리범위 유사도 분석
- Claim Element Extraction
- 독립항/종속항 구조 분석
- 선행기술과의 차이점 분석
- 침해 가능성 탐색 보조
Claims는 가장 중요하지만 가장 어렵다.
따라서 초기 단계에서는 Abstract 중심으로 시작하고, Claims는 고도화 단계에서 다루는 것이 현실적이다.
5. Description: RAG 단계에서 활용할 수 있는 장문 기술 데이터
Description, 즉 발명의 상세한 설명에는 기술 배경, 기존 기술의 문제점, 발명의 목적, 구체적인 실시예가 들어간다.
이 부분은 정보량이 가장 많다. 따라서 기술문제를 추출하거나, TRIZ 기반 기술모순을 찾거나, RAG 기반 기술분석 리포트를 만들 때 유용하다.
하지만 상세 설명은 너무 길다. 그대로 임베딩하면 문서 길이 제한에 걸리거나, 핵심 정보가 희석될 수 있다. 그래서 Description을 분석하려면 문단 단위로 쪼개는 Chunking 전략이 필요하다.
RAG 시스템에서는 보통 다음과 같은 구조가 필요하다.
Description 원문
↓
문단 단위 Chunking
↓
Embedding 생성
↓
Vector Database 저장
↓
Query와 유사한 Chunk 검색
↓
LLM 기반 답변 생성
즉, Description은 초기 유사도 분석보다는 RAG 단계에서 본격적으로 활용할 데이터다.
6. IPC/CPC: 임베딩 결과를 검증하는 기술분류 기준
IPC와 CPC는 특허가 어떤 기술분야에 속하는지를 나타내는 분류체계다.
IPC = International Patent Classification
CPC = Cooperative Patent Classification
이 분류코드는 특허를 기술영역별로 정리하기 위한 기준이다. 예를 들어 AI, 반도체, 배터리, 의료기기, 로봇 등 각 기술은 특정 IPC/CPC 코드 아래에 분류된다.
IPC/CPC는 AI 모델 평가에서 중요한 기준점이 될 수 있다. 예를 들어 특허 텍스트 임베딩으로 클러스터링을 했을 때, 같은 클러스터에 속한 특허들이 실제로 유사한 IPC/CPC 코드를 공유하는지 확인할 수 있다.
IPC/CPC의 활용
- 특정 기술분야 특허 필터링
- 임베딩 기반 클러스터 검증
- 기업별 기술 다양성 측정
- 동일 기술분류 내 경쟁기업 비교
- 융합기술 영역 탐색
하지만 IPC/CPC에도 한계가 있다. 기술분류코드는 사람이 정의한 분류체계이기 때문에, 최신 융합기술이나 경계 영역 기술을 충분히 반영하지 못할 수 있다.
예를 들어 AI 기반 의료영상 분석 기술은 AI, 의료기기, 영상처리라는 여러 영역이 결합되어 있다. 하나의 코드만으로 기술의 의미적 위치를 설명하기 어렵다.
그래서 이 프로젝트에서는 IPC/CPC를 절대 기준으로 보기보다, 임베딩 기반 분석 결과를 검증하고 해석하는 보조 기준으로 사용할 예정이다.
7. Citation: 특허를 그래프로 확장시키는 데이터
Citation, 즉 인용정보는 특허 간의 연결관계를 보여준다. 어떤 특허가 다른 특허를 인용한다는 것은, 해당 기술이 선행기술로 참고되었거나 기술적으로 연관되어 있다는 의미다.
인용정보를 활용하면 특허를 그래프로 모델링할 수 있다.
Patent A → Patent B → Patent C
↘ Patent D
여기서 각 특허는 Node가 되고, 인용관계는 Edge가 된다.
이 구조를 사용하면 다음과 같은 분석이 가능하다.
Citation 기반 분석
- 피인용 수 기반 기술 영향력 분석
- PageRank 기반 핵심 특허 탐색
- Community Detection 기반 기술군 탐색
- Citation Path 기반 기술 확산 경로 분석
- Link Prediction 기반 향후 인용관계 예측
- GNN 기반 고영향 특허 예측
이 단계까지 가면 프로젝트는 단순 NLP를 넘어 Graph ML로 확장된다. 다만 처음부터 인용 네트워크까지 구축하려고 하면 난이도가 올라간다. 따라서 Citation 분석은 Phase 2 이후로 두는 것이 좋다.
8. Applicant: 기업의 기술 포트폴리오를 구성하는 기준
Applicant, 즉 출원인은 특허를 누가 보유하고 있는지를 나타낸다. 이 필드는 기업 단위 분석에서 핵심이다.
특허 하나하나를 분석하는 것도 중요하지만, 기술기업 평가에서는 결국 기업 단위로 기술 포트폴리오를 봐야 한다.
기업별로 특허를 묶으면 다음과 같은 분석이 가능하다.
Applicant 기반 기업 분석
- 출원 수: R&D 활동 규모
- 등록률: 특허 확보 효율
- 기술분야 분포: 기술 포트폴리오 구성
- 평균 임베딩 벡터: 기업의 기술적 중심 위치
- 클러스터 다양성: 기술 다각화 정도
- 유사 기업: 기술적으로 가까운 경쟁사 또는 협력 후보
- 공백 영역: 아직 진입하지 않은 기술영역
이 프로젝트에서 최종적으로 만들고 싶은 기술경쟁지도는 특허 단위 분석에서 끝나지 않는다. 특허 임베딩을 기업 단위로 집계하여 기업별 기술 포지션을 계산하는 것이 목표다.
기업 A의 특허 100건
↓
각 특허 Abstract Embedding 생성
↓
100개 벡터의 평균 또는 가중평균 계산
↓
기업 A의 Technology Portfolio Vector 생성
↓
기업 B, C, D와 Cosine Similarity 비교
이렇게 하면 기업 간 기술 유사도를 정량화할 수 있다.
9. 초기 MVP는 어디까지 가져갈 것인가
첫 번째 MVP에서는 모든 데이터를 다 쓰지 않는다. 처음부터 복잡하게 가면 데이터 수집 단계에서 막힐 가능성이 높다.
따라서 초기 데이터셋은 아래 필드만 사용한다.
| 필드 | 사용 여부 | 이유 |
| Patent ID | 사용 | 특허별 고유 식별자 |
| Title | 사용 | 기술 주제 파악 |
| Abstract | 사용 | 텍스트 임베딩 핵심 데이터 |
| Applicant | 사용 | 기업 단위 분석 |
| Filing Date | 사용 | 시계열 분석 확장 가능 |
| IPC/CPC | 사용 | 기술분류 및 클러스터 검증 |
| Claims | 선택 | 중요하지만 초기 난이도 높음 |
| Description | 제외 | RAG 단계에서 활용 |
| Citation | 제외 | Graph 분석 단계에서 활용 |
초기 목표는 다음과 같다.
Title + Abstract 기반으로 특허 텍스트를 벡터화하고, 유사 특허 검색과 기술 클러스터링을 수행한다.
이 정도면 첫 번째 구현 목표로 충분하다.
10. 분석 텍스트는 Title + Abstract로 구성한다
초기 CSV 또는 Excel 데이터셋은 아래와 같은 형태로 만들 예정이다.
| patent_id | title | abstract | applicant | filing_date | ipc_cpc |
| P001 | Method for anomaly detection ... | A method includes... | Company A | 2021-03-01 | G06N |
| P002 | System for fault diagnosis ... | The invention relates... | Company B | 2020-07-04 | G05B |
| P003 | Predictive maintenace method .... | Provided is a system... | Company C | 2022-11-20 | G06Q |
여기서 핵심 분석 텍스트는 다음과 같이 구성한다.
analysis_text = title + " " + abstract
초기 MVP에서는 Title + Abstract 조합이 가장 적합하다.
Title only
- 장점: 간단하고 노이즈가 적음
- 단점: 정보량 부족
Abstract only
- 장점: 기술 내용이 비교적 풍부함
- 단점: 제목의 핵심 키워드가 빠질 수 있음
Title + Abstract
- 장점: 주제와 기술 내용을 함께 반영
- 단점: 텍스트 길이가 조금 증가
Title + Abstract + Claims
- 장점: 권리범위까지 반영 가능
- 단점: 초기 분석에는 복잡함
11. 프로젝트 단계별 로드맵
Patent Intelligence Agent는 한 번에 완성되는 시스템이 아니다. 초기에는 간단한 텍스트 유사도 분석으로 시작하고, 이후 Semantic Search, RAG, Graph ML, XAI로 확장하는 구조가 적절하다.
| Phase | 주제 | 방법론 |
| Phase 1 | 데이터 수집 | Title, Abstract 정리 |
| Phase 2 | 기본 유사도 분석 | TF-IDF, Cosine Similarity |
| Phase 3 | 의미 기반 검색 | Sentence-BERT, FAISS |
| Phase 4 | 기술지도 구축 | UMAP, HDBSCAN |
| Phase 5 | 기업 경쟁구도 분석 | Portfolio Vector |
| Phase 6 | RAG 분석 | Chunking, Vector DB, LLM |
| Phase 7 | 네트워크 분석 | Citation, PageRank |
| Phase 8 | GNN 확장 | GraphSAGE, GAT |
| Phase 9 | 설명가능성 분석 | SHAP, Feature Attribution |
이 로드맵에서 중요한 것은 처음부터 고급 모델을 쓰는 것이 아니다. 먼저 특허 문서를 데이터 구조로 이해하고, 각 필드가 어떤 분석 목적에 적합한지 정의하는 것이다.
12. 정리: AI가 특허를 읽는다는 것의 의미
AI가 특허를 읽는다는 것은 단순히 특허 문서를 요약한다는 의미가 아니다. 특허 문서를 데이터 필드로 분해하고, 각 필드가 가진 의미를 모델이 사용할 수 있는 형태로 변환하는 과정이다.
| 핵심 요약 |
| 1. 특허는 단순 문서가 아니라 구조화된 기술 데이터다. 2. 초기 분석에는 Title + Abstract 조합이 가장 현실적이다. 3. Claims는 권리범위 분석에 중요하지만 초기 난이도가 높다. 4. IPC/CPC는 임베딩 기반 클러스터의 검증 기준으로 활용할 수 있다. 5. Citation은 특허를 그래프로 확장시키는 핵심 데이터다. 6. Applicant는 기업별 기술 포트폴리오 분석의 기준이 된다. 7. Patent Intelligence Agent의 첫 단계는 모델 구현이 아니라 데이터 구조 정의다. |
Title은 기술 주제를 빠르게 보여준다.
Abstract는 기술 내용을 압축적으로 담고 있어 임베딩에 적합하다.
Claims는 권리범위를 정의하지만 분석 난이도가 높다.
Description은 RAG 기반 질의응답에 적합하다.
IPC/CPC는 기술분류 기준으로 활용할 수 있다.
Citation은 기술 영향력과 지식흐름을 그래프로 표현할 수 있게 해준다.
Applicant는 기업별 기술 포트폴리오 분석의 기준이 된다.
따라서 Patent Intelligence Agent의 첫 단계는 모델을 만드는 것이 아니라, 특허 문서를 어떤 데이터 구조로 해석할 것인지 정의하는 것이다.
다음 글에서는 실제로 분석할 기술 도메인을 선정하고, 특허 검색 키워드를 설계해본다. 첫 번째 실험 도메인은 “Anomaly Detection”으로 설정하고, 관련 특허를 수집하기 위한 검색 전략을 정리할 예정이다.
다음 글 예고
다음 글의 제목은 다음과 같이 잡을 예정이다.
"Anomaly Detection 특허를 어떻게 수집할 것인가"
다음 글에서는 왜 첫 실험 도메인으로 Anomaly Detection을 선택했는지, 어떤 검색 키워드를 사용할 것인지, 동의어를 어떻게 확장할 것인지, 그리고 특허 데이터셋의 포함/제외 기준을 어떻게 설정할 것인지 정리해볼 예정이다.
'Project > Patent Intelligent Agent' 카테고리의 다른 글
| Patent Intelligence Agent #6 (0) | 2026.06.22 |
|---|---|
| Patent Intelligence Agent #5 (0) | 2026.06.16 |
| Patent Intelligence Agent #4 (0) | 2026.06.16 |
| Patent Intelligence Agent #3 (0) | 2026.06.16 |
| Patent Intelligence Agent #1 (0) | 2026.06.14 |