Claude Skill, Schedule, Artifact, Code를 이용한 특허 리서치 및 워크플로우 자동화
KIPRIS 고급 검색은 사람이 정한 조건에 맞는 문헌을 찾아 주는 데까지.
문헌 내용 파악, 비교, 검색식 수정, 변화 모니터링은 연구자의 부담 >> Claude API로 자동화 수준 제고
1. 청구항 요소 대응표 자동 작성
고급 검색으로는 안 되는 것: 청구항을 읽고 우리 제품 구성과 하나씩 맞대어 보는 일.
- KIPRIS API: 서지 상세 API로 후보 특허의 청구항 전문을 가져옵니다.
- Claude: 독립항을 구성요소로 쪼갭니다. 요소마다 우리 제품 사양과 일치·부분·없음을 판정하고, 판정 근거 문장을 원문 그대로 붙입니다. 서버는 그 근거가 원문에 실제로 있는지 다시 확인합니다.
- 결과물: 특허 × 청구 요소 대응표, 그리고 “우리에게만 있는 구성” 목록. 연구개발형 보고서와 변리사 검토 자료로 바로 쓸 수 있습니다.
- 검토: 침해 판단이 아니라 검토 대상을 좁히는 단계입니다. 최종 판단은 변리사가 합니다.
2. 검색식 자동 정제 에이전트
고급 검색으로는 안 되는 것: 검색 결과가 얼마나 맞는지 읽어 보고 검색식을 다시 고치는 반복.
- KIPRIS API: 건수만 조회하는 호출(pageSize=1)로 후보 검색식의 결과 수를 싸게 잽니다. 상위 20건의 제목과 요약도 가져옵니다.
- Claude: 동의어와 영문 용어, IPC 후보를 제안합니다. 상위 20건이 우리 주제와 관련 있는지 하나씩 표시해 정밀도를 추정하고, 정밀도가 낮으면 제외어를 넣거나 IPC를 좁혀 다시 돌립니다. 4.4의 Tool Use 루프 그대로입니다.
- 결과물: 검색식마다 “건수 74 · 관련 17/20” 같은 기록과 버전별 변경 이유. 보고서의 조사 범위 근거가 됩니다.
- BCR 근거: 브레이크를 F16D로 찾으면 1,893건(자동차 브레이크 포함)이었고, B25J 19로 좁히자 74건이 됐습니다. 이 판단을 사람 대신 반복해 주는 에이전트입니다.
3. 기술 주제 지도 (IPC보다 세밀한 랜드스케이프)
고급 검색으로는 안 되는 것: IPC 분류는 너무 넓어서 “누가 정확히 어떤 접근을 하는지”는 안 보입니다.
- KIPRIS API: 한 분야의 수집 결과 수백 건(제목, 요약, 출원인, 출원일).
- Claude: 요약을 읽고 기술 주제를 5–10개로 묶어 이름을 붙입니다. 예를 들면 “중공축 일체형 관절”, “이중 엔코더 안전 감시” 같은 식입니다. 특허마다 주제를 배정하고, 배정 근거 문장도 남깁니다.
- 결과물: 출원인 × 주제 매트릭스, 주제별 연도 추이, 출원이 거의 없는 빈 영역 후보. 기술기획형·사업전략형 보고서의 핵심 표가 됩니다.
- 검토: 주제 이름과 배정은 연구개발팀이 확정합니다. 실행할 때마다 묶음이 조금씩 달라질 수 있으니 확정한 주제 목록을 저장해 두고 다음 실행 때 다시 씁니다.
4. 특허 워치 자동화 (신규 공개 + 권리 변동)
고급 검색으로는 안 되는 것: 지난번 결과와 비교해 바뀐 것만 골라 알려 주는 일.
- KIPRIS API: 저장해 둔 검색식을 정해진 주기(예: 매주)에 다시 돌려 새로 공개된 건을 찾습니다. 관심 특허는 법적 상태 이력(ST.27)과 등록사항 API로 등록, 소멸, 권리자 변경, 연차료 납부 연차를 확인합니다. 둘 다 BCR에서 실제 호출로 확인했습니다.
- Claude: 새로 공개된 건이 우리 기술과 관련 있는지 판단해 걸러 냅니다. 바뀐 점은 3줄로 요약하고, 누가 무엇을 확인해야 하는지 붙인 주간 브리핑을 씁니다.
- 결과물: 주간 IP 워치 메일 또는 메신저 알림. 4.6의 예약 작업 + MCP 실습으로 바로 이어집니다.
- 주의: 등록사항 API는 무료 호출이 월 1,000건 수준(BCR 조사)이라 감시 대상을 수십 건으로 묶어야 합니다. 검색 API 한도(S6)도 먼저 확인이 필요합니다.
한눈에 비교
| 업무 | 고급 검색의 한계 | Claude가 더하는 것 | 연결 |
|---|---|---|---|
| 청구항 대응표 | 청구항을 읽지 않음 | 요소 분해, 근거 인용 비교 | 연구개발형 보고서 |
| 검색식 정제 | 결과가 맞는지 모름 | 정밀도 측정, 반복 수정 | 모든 리서치의 기반 |
| 기술 주제 지도 | IPC 단위로만 묶임 | 요약 기반 주제 분류 | 기획형·전략형 보고서 |
| 특허 워치 | 이전 결과와 비교하지 않음 | 변화 감지, 관련성 판단, 요약 | 4.6 예약 작업 |
추천 순서: 2번 검색식 정제부터 만드시길 권합니다. 나머지 셋이 모두 “좋은 검색식으로 모은 특허 묶음”을 입력으로 쓰기 때문입니다. Next Patent Scout에는 이미 1번의 기초(요소별 유사성 평가, 근거 검증)가 있으니, 2번과 4번을 붙이면 고급 검색과 확실히 다른 앱이 됩니다.
Next Patent Scout 프로젝트에 구현된 것과 향후 구현 과제
두 앱이 이미 하는 일, 이번 Next Patent Scout 화면에서 보인 품질 문제, 앞으로 만들 기능 순서로 정리했습니다. BCR 앱은 저장소 README와 실측 기록을, Next 앱은 보내 주신 화면 5장을 근거로 판단했습니다. Next 앱 코드는 직접 보지 않았으니 “화면에서 확인”은 그 범위로 읽어 주세요.
1. KIPRIS 고급 검색과 다른 점 (이미 구현된 것)
| 기능 | KIPRIS 고급 검색 | BCR Patent Scout | Next Patent Scout |
|---|---|---|---|
| 입력에서 검색식 자동 생성 | 사람이 조건 입력 | ✓ 고정 제품 카탈로그에서 | ✓ 문서·키워드 → AI 기술 프로필 |
| 검색식별 건수 미리보기 | 한 번에 하나씩 | ✓ IPC 후보별 실측 칩 | △ 버튼은 있으나 IPC 보정이 안 보임 |
| 여러 검색식 수집, 중복 제거, 걸린 검색식 기록 | – | ✓ | ✓ (53건) |
| 동향 집계 + 18개월 미공개 표시 | 통계 화면 별도 | ✓ | ✓ 기술 요소별 건수 차트 추가 |
| 기술 요소별 유사성 판정 | – | ✓ (근거 17/17 원문 확인) | ✓ 3건씩 평가 |
| 근거 원문 검증 | – | ✓ | ✓ |
| 목적별 보고서 + 자동 검증 | – | ✓ 3유형 | ✓ 4유형, 없는 출원번호를 경고로 잡음 |
| 특허 문서 업로드와 구조 인식 | – | – | △ 업로드·추출은 됨, 구조 인식은 실패 |
| 권리 현황 (법적 상태, 등록사항) | 건별 조회 | ✓ 존속기간 만료일, 연차료 납부 연차 | 화면에서 확인 못 함 (이식 필요) |
| 활동 기록, 단계 상태, 횟수 관리 | – | 공용 접근 코드 | ✓ 바우처, 활동 기록 |
KIPRIS 고급 검색과 확실히 다른 점은 다섯 가지입니다.
- 문서에서 시작합니다. 검색식을 몰라도 카탈로그나 특허 문서만 있으면 시작할 수 있습니다.
- 여러 검색식을 한 묶음으로 다룹니다. 수집, 중복 제거, 집계까지 한 번에 합니다.
- 기술 요소 단위로 비교합니다. 특허 전체가 아니라 요소 하나하나를 맞대어 봅니다.
- AI 판정을 서버가 다시 확인합니다. 근거 문장이 원문에 실제로 있는지 검사합니다.
- 결과가 보고서로 끝납니다. 목적에 맞는 보고서 형식으로 정리되어 나옵니다.
2. 화면에서 보인 품질 과제 (출시 전에 고칠 것)
- 검색식이 너무 좁습니다. 모든 검색식의 요약 칸에 3단어(“모터 감속기 엔코더”)가 들어가 있고, IPC도 전부
B25J 9/06으로 같습니다. BCR 실측에서 한 칸의 여러 단어는 AND로 처리됐습니다. 파동기어 232건, 브레이크 28,834건이 둘을 함께 넣자 3건이 됐습니다. 요소마다 대표어를 1–2개로 줄이고, IPC는 요소별로 건수 보정을 해야 합니다. - 구조 인식이 실패했습니다. 올린 PDF가 출원서 양식이 아니라 KIPRIS 상세 화면 인쇄본(Application No., Applicant 같은 영문 표지)입니다. 이 양식용 해석기를 추가하고, 문서 안의 출원번호(1020130119441)는 “입력 문서 자신”으로 인식해 결과에서 빼야 합니다.
- 종합 판정 기준이 맞지 않습니다. 부분 일치(◐) 1개, 나머지는 해당 없음인데 종합이 “보통”입니다. 명세 기준으로는 “낮음”입니다. 종합 판정은 AI 답을 그대로 쓰지 말고, 서버가 일치·부분 비율로 다시 계산하게 하는 편이 안전합니다.
- 보고서에 지어낸 출원번호가 들어갑니다. 2023001234567 같은 번호가 본문에 들어갔고 검증이 잡아냈습니다. 검증은 제 역할을 했지만, 생성 단계에서 입력 목록에 있는 번호만 쓰도록 프롬프트를 고치고 경고가 남은 채로 내려받을 때는 표시를 붙여야 합니다.
- “JSON 없음” 실패가 있습니다. BCR에서 고친 “파싱 실패 시 오류를 붙여 1회 재요청”이 이식됐는지 확인이 필요합니다.
- 매트릭스 열 제목이 너무 깁니다. 요소 라벨이 길어 열 제목이 세 줄로 접히고, 종합 열의 “보통”도 세로로 끊깁니다. 기술 프로필에 짧은 이름(
short_label) 필드를 두면 해결됩니다.
3. 향후 구현 과제 (우선순위)
선정 기준은 세 가지입니다. KIPRIS 고급 검색과 얼마나 다른가, 지금 코드로 얼마나 빨리 붙는가, API 한도에 얼마나 의존하는가.
| 우선순위 | 과제 | 왜 | 필요한 것 |
|---|---|---|---|
| P1 | 검색식 정제 에이전트 | 2번 문제를 근본적으로 해결. 상위 20건의 관련성을 읽어 정밀도를 재고 검색식을 고침 | 건수 조회(pageSize=1), Tool Use 루프 |
| P1 | 권리 현황 이식 | BCR에 이미 있음. 살아 있는 등록 특허를 걸러 내는 사전 검토의 기반 | BCR rights.js, 데이터 상품 16·17번 |
| P1 | 공개 체험 경로 | Product Hunt 방문자가 바로 써 볼 수 있어야 함 | 공개 바우처, 하루 비용 상한 |
| P2 | 청구항 요소 대응표 | 독립항을 구성요소로 쪼개 제품과 대응. 연구개발형 보고서의 핵심 | 서지 상세의 청구항 전문, 근거 검증 재사용 |
| P2 | 특허 워치 | 저장한 검색식의 신규 공개와 관심 특허의 권리 변동을 주기적으로 비교해 알림 | 예약 작업, 이전 결과 저장, 등록사항 API 한도 관리 |
| P2 | MCP 서버 | 같은 기능을 Claude Code·Desktop에서 쓰게 함 (4.5 실습) | lib/server 모듈 재사용 |
| P3 | 기술 주제 지도 | IPC보다 세밀한 주제로 묶어 출원인 × 주제 표와 빈 영역을 찾음 | 수백 건 요약 일괄 처리, 확정한 주제 목록 저장 |
| P3 | 해외 패밀리·영문 초록 | 해외 고객에게 설명할 자료 | 우선권 정보, KPA |
| P3 | 판정 정확도 측정 | “근거가 실재한다”를 넘어 “판정이 맞다”를 수치로 보여 줌 | 전문가가 표시한 기준 데이터 30건 |
추천 순서: 출시 전에는 2절의 1·3·4번과 P1의 공개 체험 경로까지만 하시길 권합니다. 출시 뒤 첫 업데이트는 검색식 정제 에이전트와 권리 현황으로 하면, “KIPRIS를 대신 검색해 주는 앱”에서 “검색을 더 잘하게 만드는 앱”으로 소개 문구를 바꿀 수 있습니다.
원하시면 이 내용을 Next Patent Scout 로드맵 문서(.md)로 정리해 프로젝트에 저장해 두겠습니다.
KIPRIS 고급 검색 기능 최적화
KIPRIS 고급 검색 기능을 최대치로 활용한다면 아래 특허 리서치 작업을 수행할 수 있습니다.
1. 출원 전 선행기술 조사
우리 아이디어와 비슷한 공개 문헌이 이미 있는지 확인하는 작업입니다.
- 설정: Full Text에 핵심 구성을 문장으로 입력하고 Keyword Extension을 켭니다. Status는 All로 둡니다. 거절·포기된 출원도 선행기술이 되기 때문입니다.
- 결과물: 가장 가까운 문헌 5–10건과 구성요소별 대응표. Next Patent Scout의 “선행기술 탐색 메모”가 이 작업입니다.
2. 기술 분야 동향 파악
어떤 기술 분류에서 출원이 늘거나 주는지를 봅니다.
- 설정: IPC/CPC + Date(출원일 범위), Category는 Patent·Utility 모두.
- 주의: 최근 18개월 출원은 아직 공개되지 않아 적게 잡힙니다. “감소”로 읽으면 안 됩니다.
3. 경쟁사 특허 포트폴리오 분석
특정 회사가 어떤 기술에 얼마나 출원하는지, 핵심 발명자가 누구인지 파악합니다.
- 설정: 출원인 필드에 회사명(표기 변형까지), Status는 Registered와 Unexamined를 나눠서 봅니다.
- 결과물: 회사별 기술 분류 분포, 최근 3년에 출원이 늘어난 분야, 반복해서 나오는 발명자.
4. 살아 있는 등록 특허 사전 스크리닝
제품 출시 전에, 우리 제품 구성과 겹칠 수 있는 유효한 등록 특허를 먼저 걸러 봅니다.
- 설정: Status를 Registered만, 청구항 검색어 중심으로 찾습니다.
- 주의: 이것은 변리사 검토 대상을 고르는 1차 선별입니다. 침해 여부(FTO)를 판단하는 단계가 아닙니다.
5. 소멸·포기 특허에서 쓸 수 있는 기술 찾기
연차료 미납이나 포기로 권리가 사라진 특허는 그 기술을 참고하기 좋은 출발점입니다.
- 설정: Status의 Fullview에서 소멸·포기 같은 세부 상태를 고릅니다. Set Search Fields의 Patent Term Extension으로 존속기간 연장 여부도 확인합니다.
- 주의: 같은 기술의 다른 유효 특허가 있을 수 있으니 실제로 쓰기 전에는 전문가 확인이 필요합니다.
6. 해외 출원(패밀리)과 우선권 추적
경쟁 기술이 해외에도 출원됐는지, 어느 나라 출원이 원조인지 확인합니다.
- 설정: Priority info로 우선권 국가·번호를 보고, Search Type을 Foreign 또는 KPA로 바꿔 교차 확인합니다. KPA는 한국 특허의 영문 초록입니다.
- BCR 예시: 북유럽 고객에게 설명 자료를 보낼 때 KPA 영문 초록을 그대로 인용할 수 있습니다.
7. 국가 R&D 과제 특허로 협력 파트너 찾기
정부 연구비로 나온 특허를 찾아, 기술이전이나 공동연구를 함께할 대학·연구소를 찾습니다.
- 설정: Set Search Fields의 National R&D Project + 관심 기술 IPC.
- 결과물: 기관별 특허 목록과 담당 연구책임자. 사업전략형 보고서의 후속 조사 항목으로 이어집니다.
8. 한영 용어 교차 검색으로 누락 줄이기
같은 기술을 다른 말로 쓴 특허를 놓치지 않게 합니다.
- 설정: Full Text의 English-Korean과 Keyword Extension을 켜고, 연산자는 AND/OR를 바꿔 가며 건수를 비교합니다.
- BCR 예시: “하모닉 드라이브 / 파동기어 / strain wave gear”를 모두 잡아야 감속기 관련 특허가 빠지지 않습니다.
추가로 볼 만한 것: 고급 검색의 Judgment 탭에서는 핵심 특허가 무효심판을 받은 이력을 볼 수 있습니다. 경쟁사 특허가 얼마나 튼튼한지 가늠할 때 씁니다.
우선순위: BCR처럼 제품을 만드는 회사라면 4 → 3 → 2 → 1 순서가 실무에서 가장 자주 쓰입니다. 이 중 1·2·3은 Next Patent Scout이 이미 자동화하는 범위입니다. 4·5·6은 앞서 BCR 앱에서 연결해 본 권리 현황 API(등록사항, 법적 상태)를 붙이면 앱의 다음 기능 후보가 됩니다.
