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

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년 공고 갱신이 되면 신규 공고 적용 시 변경점 추적 및 영향도 분석 등 온톨로지의 진짜 강점도 검증해 볼 수 있지 않을까요?