# 정책자금 공고로 온톨로지를 만들어 RAG·LLM 위키와 겨뤄봤습니다. 남은 건 결국 데이터 구축 방법이었습니다.

- 작성자: [바닐라](https://community.clauders.ai/member/imported-member-O7hOyhyS0y)
- 공간: [LLM Wiki로 지식관리 시스템](https://community.clauders.ai/llm-ontology)
- 게시: 2026-10-06
- 연재: [LLM Wiki로 지식관리 시스템 시즌 2](https://community.clauders.ai/series/llm-ontology-season-2) 1/6편
- 태그: #AI지식관리
- 주소: https://community.clauders.ai/llm-ontology/post/%EC%A0%95%EC%B1%85%EC%9E%90%EA%B8%88-%EA%B3%B5%EA%B3%A0%EB%A1%9C-%EC%98%A8%ED%86%A8%EB%A1%9C%EC%A7%80%EB%A5%BC-%EB%A7%8C%EB%93%A4%EC%96%B4-rag-llm-%EC%9C%84%ED%82%A4%EC%99%80-%EA%B2%A8%EB%A4%84%EB%B4%A4%EC%8A%B5%EB%8B%88%EB%8B%A4-%EB%82%A8%EC%9D%80-%EA%B1%B4-%EA%B2%B0%EA%B5%AD-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EA%B5%AC%EC%B6%95-%EB%B0%A9%EB%B2%95%EC%9D%B4%EC%97%88%EC%8A%B5%EB%8B%88%EB%8B%A4-0fbf6630-7106-8ae2-84fc-d1cad976fa44

---

**1. 시작하며: 시도하려 했던 것과 이유**

온톨로지를 공부하며 단순 개념 정리로 끝내기보다 실제로 작동하는 서비스를 만들어보고 싶었습니다. 주제는 중소기업·소상공인 정책자금으로 잡았습니다. 지자체, 중진공, 신보, 기보, 소진공, 관광기금 등 운영 기관이 다양하고, 공고마다 자격 조건, 제외 업종, 한도, 중복 지원 제한이 제각각입니다. 사업자 입장에서는 "내가 받을 수 있는 자금이 무엇이고, 얼마까지 언제 되는지" 한눈에 파악하기 어렵습니다. 조건과 관계를 온톨로지로 구조화하기에 적합한 주제라고 판단했습니다.

일단 만들어보고 **"같은 공고 원문을 두고 일반 LLM, RAG, LLM 위키, 온톨로지 네 방식을 비교하면, 온톨로지는 어디까지 정의하고 활용해야 가장 효과적일까?"** 를 비교해보며 감을 익히고자 했습니다.

**2. 진행 방법**

**데이터 및 온톨로지 구축**

- **원문 수집:** 정책금융기관(신보·기보·중진공·소진공), 17개 광역시도, 지역신용보증재단, 정부 부처(문체부/농식품부/해수부 등) 약 60개 기관 공식 사이트에서 공고 첨부파일(HWP, HWPX, PDF) 및 웹페이지 397개를 수집했습니다.
- **텍스트 정제:** 100개 텍스트로 가공했으며, 변경 공고가 있는 자금은 본공고와 함께 통합 저장했습니다.
- **규칙화 및 엔진 연동:** 94종 자금은 AI 1차 분석 결과를 직접 확인하며 규칙 파일로 옮겼습니다(총 2,187개 조건). 이 규칙 파일 하나를 판정 엔진(가능/조건부/불가 계산)과 그래프 컴파일러(클래스 18개, 관계 37종, 개체 2,456개, 관계 7,294개 생성)가 함께 활용합니다.

**질문 설계 (Competency Questions)**

- 설계 전, 서비스가 답해야 할 30개 역량 질문을 선제 정의했습니다.
- 유형: 자격, 조건, 시점, 조합, 순서, 대안, 영향, 공백 등

**질의 파이프라인 (Graph Query Flow)**

- LLM 질문 해석 → 그래프 조회 명세 작성 → 명세 검증 → 그래프 탐색 및 판정 엔진 호출 → 결과 부족 시 재계획 → 원문 근거 첨부 후 최종 답변 작성

**비교 대상 3가지**

- **일반 LLM:** 사전 지식 없이 모델 단독 답변
- **RAG:** BM25로 원문 조각(14개 또는 30개) 추출 후 전달
- **LLM 위키:** 원문을 분석해 자금별 위키 512쪽 사전 작성 (소요 시간 23분, AI 호출 149회)

**측정 및 검증 방식**

- **답변 및 채점:** Claude Sonnet이 답변을 작성하고, Claude Opus가 어떤 방식인지 모른 채 정답표와 대조 채점(블라인드 테스트)했습니다.
- **인용 검증:** 답변에 포함된 인용문은 코드 실행을 통해 원문과 100% 일치하는지 대조했습니다.
- **편향 방지:** 측정 전 예상 결과를 문서화했고, 출제자와 검증자를 분리하여 측정 종료 시까지 정답을 확인하지 않았습니다.

**측정 결과 (정답 수)**

**측정 항목**

**일반 LLM**

**RAG**

**LLM 위키**

**온톨로지**

**규칙 파일 기준 15문항 × 3회**

0

24

25

**27**

**원문 기준 50문항**

0

**34 / 38**

34

10~13

**계산 문제 30문항**

3

**25 / 24**

22

5~9

**94종 범위 내 계산 문제 30문항**

0

19 / 23

**24**

5~6

_(RAG 칸의 숫자는 조각 14개 / 30개 추출 시 결과입니다.)_

**온톨로지 자동 확장 시도**

- 데이터 부족 여부를 확인하기 위해 LLM 위키에서 규칙 초안을 자동 추출했습니다 (174종 추가, 9분 소요, 총 268종 확장).
- 수동 작성 10종과 비교한 결과 조건 일치율은 56%였습니다. (단순 지자체 자금: 87% / 예외가 많은 중진공 자금: 22%)
- 규모를 늘려도 정답률 상승은 미미했습니다.

**3. 인사이트 및 아쉬운 점**

**온톨로지 성적은 문제 출제 방식에 크게 좌우되었습니다.**

규칙 파일 기반 문제에서는 온톨로지가 가장 높은 성적(27/45)을 냈지만, 원문 기반 문제에서는 정답률(10/50)이 크게 떨어졌습니다. 초기 결과만 확인했다면 잘못된 결론을 내릴 뻔했습니다.

**실패의 주된 원인은 '스키마 밖의 정보'였습니다.**

온톨로지 스키마는 "지원 가능 여부 판정"에 집중하여 접수 기간, 한도, 기본 조건 위주로 구성했습니다. 하지만 실제 질문은 분기별 일정, 한도 구간, 금리·상환 조건, 중복 시 환수 등 세부 사항을 다수 포함했습니다.

그 결과 결론은 맞혀도 근거나 세부 설명이 누락된 경우가 절반을 넘었습니다. "자료에 없음"으로 응답한 문항도 RAG는 5개인 반면 온톨로지는 20개에 달했습니다.

**"계산은 온톨로지가 우수할 것"이라는 가설은 틀렸습니다.**

날짜, 만 나이, 잔액 합산 같은 계산은 RAG로 원문을 읽은 LLM도 대부분 accurate하게 처리했습니다 (필수 항목 충족률 84~90%).

**자동 확장은 비용이 저렴하지만 품질 유지가 어려웠습니다.**

자금 수를 3배 확장해도 정답률은 거의 오르지 않았고, 오히려 원문과 불일치하는 인용이 증가했습니다.

**가장 값진 성과는 구축 과정 자체에 있었습니다.**

규칙을 정리하고 그래프와 대조하는 과정에서 데이터 오류를 대부분 잡아낼 수 있었습니다.

또한 "업력 N년 이내"가 기준 당일을 포함하는지 등의 해석 원칙을 확립했고, 판정 엔진의 "확인 필요" 상태도 입력 부족, 본인 확인, 기관 심사, 문의 등 4가지로 세분화하여 모호성을 줄였습니다.

**아쉬운 점**

- 측정 횟수가 대부분 1회에 그쳤습니다.
- 출제와 검증을 AI가 진행하여 원문 문장 검색에 유리한 RAG 방식에 편향되었을 가능성이 있습니다.
- 실사용자 테스트가 없어 판정 화면의 실제 효용성을 측정하지 못했습니다.
- 온톨로지의 본래 강점 영역(조항 변경 시 영향 받는 자금 추적, 데이터 정합성 검증)은 테스트하지 못했습니다.

**4. 향후 계획**

이번 프로젝트를 통해 관심사가 "온톨로지로 답을 잘하는 방법"에서 "믿을 수 있는 데이터를 구축하고 검증하는 방법"으로 이동했습니다. 정답률에서는 뒤처졌지만, 원문을 규칙으로 변환하고 그래프와 대조하며 오류를 정제하는 과정이 실제 가장 유용한 작업이었기 때문입니다.

앞으로는 데이터 구축 및 검증 기술 정립에 집중할 계획입니다.

- **구조화 데이터 추출 정확도 향상:** 수동 작업의 정확도와 자동 추출의 속도 사이의 접점을 찾고자 합니다. 추출용 스키마 설계, 표·별첨 처리, 예외 조항의 판정식 변환 구조를 연구합니다.
- **데이터 검증 체계화:** 원문 인용 100% 대조, 수동/자동 데이터 단위 비교, 경계 사례 테스트 고정 등 현재 검증법을 정리하여 자동 검증과 수동 검수의 기준을 마련합니다.
- **해석 원칙의 데이터화:** "업력 계산 기준"이나 "확인 필요 분류"처럼 정의한 해석 원칙을 기록·관리하여 다음 추출과 검수에 지속 적용하는 시스템을 마련합니다.
- **판정 엔진과 RAG의 결합:** 판정 엔진이 결론을 내리면, RAG가 원문 조각을 찾아 세부 근거를 보완하는 하이브리드 방식을 검토합니다.

(그리고, 할수있다면....)

- **표준 형식 및 제약 검증 도입:** 규칙 파일과 그래프를 RDF/OWL로 변환하고, SHACL을 활용해 "한도 누락 자금"이나 "근거 미첨부 조건" 같은 데이터 제약 조건을 자동 검사
- 추후, 2027년 공고 갱신이 되면 신규 공고 적용 시 변경점 추적 및 영향도 분석 등 온톨로지의 진짜 강점도 검증해 볼 수 있지 않을까요?