Nemotron 9B와 RTX 5090으로 만든 무료 특허 검색 엔진

특허 검색이라는 틈새시장

2026년 3월, Reddit r/LocalLLaMA에 특이한 포스트가 하나 올라왔다. RTX 5090 한 장으로 미국 특허 354만 건을 Nemotron 9B로 분류하고, 그 위에 무료 검색 엔진을 얹었다는 내용이다. 로그인도, 클라우드 API 호출도, 검색 이력 저장도 없는 완전한 로컬 AI 기반 특허 검색 서비스 patentllm.org의 탄생기다.

특허 검색은 전통적으로 진입 장벽이 높은 영역이다. 상용 특허 데이터베이스(LexisNexis PatentAdvisor, Derwent Innovation 등)는 연간 구독료가 상당하고, USPTO의 공식 검색 도구는 기능이 제한적이다. 선행 기술 조사(prior art search)나 경쟁사 특허 모니터링이 필요한 스타트업과 개인 발명가에게 이 비용 장벽은 실질적이다.

이 프로젝트가 겨냥한 지점은 세 가지였다. 완전 무료·로그인 없는 접근성, 자연어로 개념적 쿼리를 던질 수 있는 검색 품질, 그리고 검색 이력이 서버에 남지 않는 프라이버시. 동시에 "클라우드 API 없이도 이 정도 규모의 AI 작업을 해낼 수 있다"는 것을 증명하는 레퍼런스 구현이기도 했다.

데이터: USPTO PatentsView 354만 건

데이터 소스는 미국 특허청이 Creative Commons 라이선스로 공개하는 USPTO PatentsView다. 특허 제목, 초록, 청구항, CPC(Cooperative Patent Classification) 분류 코드가 포함된 이 데이터셋에서 총 3,540,000건의 레코드를 로컬로 받아 SQLite 데이터베이스로 구성하는 것이 첫 작업이었다. 참고로 2026년 3월 기준 PatentsView는 USPTO Open Data Portal로 이관 중이며 데이터 접근 경로가 일부 바뀌었다.

기술 스택을 고른 근거

분류 모델로 Nemotron-Nano-9B-v2를 택한 이유는 세 가지로 정리된다. 32GB VRAM인 RTX 5090에서 양자화 없이 BF16으로 로드할 수 있다는 점(9B 모델 BF16 가중치는 약 18GB, 실사용 시 30.6GB VRAM을 점유하며 안정적으로 동작한다), 특허를 100개 태그 중 하나로 분류하는 JSON 구조화 출력에서 신뢰도가 높다는 점, 그리고 2025년 12월 vLLM 블로그가 공식 지원을 발표하며 배치 처리 최적화가 잘 되어 있다는 점이다.

RTX 5090은 32GB GDDR7 VRAM과 1.8TB/s 메모리 대역폭을 갖췄다. LLM 추론 성능은 메모리 대역폭에 직결되는데, 이 수치는 RTX 4090(1.0TB/s)의 1.8배다.

검색 백엔드로는 벡터 데이터베이스(LanceDB, Chroma, Milvus 등) 대신 SQLite FTS5를 선택했다. 이유는 네 가지다. LanceDB 같은 신흥 벡터 DB에서 예측 불가능한 동작을 겪은 반면 SQLite는 프로덕션에서 오래 검증된 기술이라는 점, 단일 파일 DB로 별도 서버 프로세스가 필요 없다는 운영 단순성, FTS5의 BM25 랭킹이 키워드 정밀도가 중요한 특허 검색 도메인에서 의외로 강력하다는 점, 그리고 LLM이 생성한 키워드를 사전 인덱스 안에서만 선택하게 제한하면 할루시네이션을 원천 차단할 수 있다는 점이다.

전체 아키텍처

⤢✕

파이프라인은 오프라인 단계(데이터 수집 → 분류 → DB 구축)와 온라인 단계(사용자 쿼리 → LLM 변환 → FTS5 검색 → 결과 반환)로 나뉜다. 오프라인 단계는 한 번만 돌리면 되고, 온라인 단계가 실제 서비스를 구성한다.

100개 태그로 354만 건을 분류하기까지

무작정 Nemotron으로 354만 건을 분류하기 전에 "어떤 100개 카테고리로 나눌 것인가"부터 정해야 했다. 이 단계에서는 Gemini API를 활용했다. 수만 건의 특허 샘플에 자유 형식으로 태그를 붙이게 한 다음, 결과를 집계해 의미 있는 상위 100개 카테고리로 정리했다. 도메인 전문가가 수작업으로 분류 체계를 설계하는 것보다 빠르고, 실제 데이터 분포를 반영한 카테고리가 나온다는 것이 이 접근의 장점이다. 결과적으로 나온 100개 태그는 반도체, 의료기기, 자율주행, 배터리, 통신 프로토콜 같은 기술 도메인을 포괄한다.

카테고리가 확정된 후에는 Nemotron-Nano-9B를 vLLM으로 서빙해 배치 분류를 돌렸다. 각 특허의 제목과 초록을 프롬프트에 넣고 100개 태그 중 해당하는 것을 JSON으로 출력하게 했다. 분류 정확도를 타협하지 않기 위해 양자화 없이 BF16 풀 정밀도로 실행했다.

CPC는 특허를 A(생활필수품)부터 H(전기)까지 8개 섹션으로 나눈다. 전기(H)와 물리(G) 섹션에 IT/전자 특허가 몰려 있어 레코드 수가 많은데, 이 두 섹션만 처리하는 데 RTX 5090으로 약 30시간이 걸렸다. 전체 354만 건 처리에는 며칠이 소요된 것으로 추정된다.

RAG 대신 FTS5 + LLM 쿼리 확장

일반적인 RAG(Retrieval-Augmented Generation)는 사용자 쿼리를 임베딩 벡터로 바꾸고 유사 벡터를 검색하는 방식이다. 이 프로젝트는 다른 길을 택했다. LLM이 자연어 쿼리를 FTS5 쿼리 문법으로 변환하는 것이다. 사용자가 "자율주행 장애물 감지"라고 입력하면 로컬 Nemotron 9B가 이를 "autonomous driving" AND "obstacle detection" 같은 FTS5 쿼리로 바꾸고, 이 쿼리가 SQLite FTS5 인덱스에서 실행되어 BM25 알고리즘으로 랭킹된 결과를 돌려준다.

이 구조에서 가장 위험한 지점은 LLM이 실제 데이터베이스에 없는 용어를 만들어내는 할루시네이션이다. 검색 대상을 사전에 추출된 키워드 인덱스로만 제한해서 이 문제를 막았다 — LLM은 이 인덱스 밖의 단어를 FTS5 쿼리에 넣을 수 없다. 단순하지만 효과적인 가드레일이다.

vLLM으로 뽑은 RTX 5090 실측 성능

지표	수치
VRAM 사용량	30.6 / 32 GB
정밀도	BF16 (양자화 없음)
단일 요청 처리 속도	~83 tokens/s
10개 동시 요청 배치	~630 tokens/s
첫 토큰 출력 시간 (TTFT)	45~60 ms
RTX 4090 대비 성능 향상	28~50%

vLLM을 택한 이유는 continuous batching과 PagedAttention 덕분에 단순 Ollama나 llama.cpp보다 배치 처리량이 압도적으로 높기 때문이다. 동일한 RTX 5090에서 vLLM과 Ollama를 비교하면 배치 처리 시나리오에서 vLLM이 3~5배 더 높은 처리량을 보인다. TensorRT-LLM은 단일 요청 레이턴시에서는 vLLM을 앞서지만 설정 복잡도와 빌드 시간이 상당해서, 배치 처리 위주인 이 분류 작업에는 vLLM이 더 현실적이었다.

검색 이력을 남기지 않는 구조

patentllm.org의 설계에서 가장 눈에 띄는 원칙은 프라이버시다. 서버는 어떤 쿼리도 기록하지 않고, 브라우저 localStorage에도 이력을 남기지 않는다. 데이터베이스는 읽기 전용으로 연결되어 SQL injection으로도 데이터를 수정할 수 없고, 검색 대상 자체가 USPTO 공개 데이터 전체이므로 기밀 유출 우려가 없다. 쿼리 처리도 외부 클라우드 API를 거치지 않아 쿼리 내용이 제3자 서버로 전송되지 않는다.

특허 검색에서 프라이버시는 실질적인 문제다. 경쟁사가 어떤 특허를 조사하는지, 어떤 기술 영역에 관심을 두는지는 그 자체로 경쟁 정보(competitive intelligence)가 될 수 있기 때문이다.

r/LocalLLaMA가 던진 질문들

포스트는 65개 업보트와 20개 이상의 질문을 받았다. 커뮤니티가 물은 것들을 정리하면 이렇다.

왜 벡터 DB 대신 FTS5인가 — LanceDB를 먼저 시도했으나 안정성 문제가 있었고, SQLite FTS5는 354만 건 규모에서도 예측 가능하게 동작했으며 BM25 랭킹이 특허 검색에 충분히 좋았다는 답이 돌아왔다.

분류 정확도는 어느 정도인가 — 정량적 평가 수치는 공개되지 않았지만, 샘플 검토 결과 100개 카테고리 분류는 대체로 합리적이었고, 9B 모델의 한계로 일부 복합 기술 특허에서 단일 태그 선택이 아쉬운 경우가 있었다고 한다.

RTX 5090이 없으면 재현할 수 없나 — RTX 4090(24GB)으로는 BF16 풀 정밀도 로드가 불가능하지만, Q4_K_M 양자화를 쓰면 9B 모델이 ~5.5GB로 줄어 24GB VRAM에서도 가능하다. 다만 분류 품질은 떨어질 수 있다.

전체 파이프라인을 오픈소스로 공개할 계획인가 — 데이터 파이프라인과 분류 코드 공개를 검토 중이라는 답이었다.

이 프로젝트가 보여주는 판단들

시스템을 설계하고 운영해 본 사람 입장에서 이 프로젝트의 기술적 결정들을 짚어보면 몇 가지가 눈에 띈다.

벡터 DB, 임베딩 모델, 시맨틱 검색 같은 트렌디한 기술 대신 잘 검증된 FTS5를 고른 것은 경험에서 나오는 판단이다. 신기술이 무조건 좋은 게 아니라 문제에 맞는 기술이 좋은 것이다. 100개 카테고리를 먼저 Gemini로 설계하고 Nemotron으로 전체 적용한 2단계 접근은 전형적인 프로토타입-검증-스케일 패턴이고, 복잡한 검증 로직 대신 "키워드 인덱스 밖의 단어는 쓸 수 없다"는 단순한 제약으로 할루시네이션 문제를 해결한 것도 인상적이다. 그리고 "우리는 당신의 쿼리를 보지 않는다"는 프라이버시 원칙이 클라우드 기반 경쟁 서비스 대비 명확한 차별점이 된다는 것도, 로컬 LLM의 기술적 특성이 비즈니스적 장점으로 자연스럽게 연결되는 사례다.

직접 만들어 보려면

같은 프로젝트를 재현하거나 변형하려는 경우 하드웨어 요구사항은 대략 이렇다.

풀 정밀도(BF16)로 재현하려면 RTX 5090(32GB VRAM)이나 RTX 6000 Ada(48GB VRAM) 급 GPU, RAM 64GB 이상, SSD 1TB 이상(원본 데이터 + SQLite DB)이 필요하다. 절충안으로는 RTX 4090(24GB, Q4_K_M 양자화 시 로드 가능)이나 RTX 3090(24GB, 느리지만 가능)을 쓸 수 있고, Qwen2.5-7B나 Llama-3.1-8B 같은 대안 모델도 분류 작업에 활용할 수 있다. 소프트웨어 스택은 추론 엔진으로 vLLM(배치 처리 최적화) 또는 Ollama(편의성), 데이터베이스는 SQLite + FTS5, 웹 프레임워크는 FastAPI + 정적 프론트엔드 구성이다. 처리 시간을 줄이려면 GPU를 늘려 멀티-GPU vLLM 서빙을 하거나, 더 작은 3B급 모델로 정확도를 일부 포기하는 트레이드오프를 고려해야 한다.