LLM 위키 vs 온톨로지: 채용 프로세스 개선방안 테스트

앞선 포스트에서 카파시의 LLM 위키를 이용해 간단한 테스트를 하고, LLM 위키의 유용성을 확인해 봤습니다.

- https://www.clien.net/service/board/lecture/19182891

LLM 위키는  설정과 사용이 복잡한 RAG 같은 기술이 없더라도 LLM 만으로 지식 베이스 구축이 가능하다는 점에서 상당히 유용해 보였습니다. 특히 개인적, 실험적으로 에이전트를 운용하는 상황이라면 LLM 위키의 활용법이 많아 보였습니다.

하지만 좀 더 전문적이고 업무 용도로 지식 베이스를 구축하는 경우라면 상황이 다르다고 생각됩니다. 다양한 부서에서 수행하는 복잡한 업무와 정보가 지식 베이스로 구축되어야 하는데, 일관성과 효율성을 유지할 수 있어야 합니다. 그래서 요즘 "온톨로지"라는 개념이 다시 주목받고 있는 게 아닌가 싶습니다. 

LLM 위키가 자유롭게 적어두는 메모장에 담긴 내용들을 자유롭게 상호 연결한 형태라면, 온톨로지는 사전 정의한 규칙에 따라 항목들의 카테고리와 관계를 정의한 구조화된 데이터베이스에 가깝습니다. 

LLM 이 알려주는 보다 사전적인 차이점은 아래와 같습니다.

# Wiki 방식

자유 형식의 하이퍼텍스트 지식 베이스. Wikipedia처럼 인간이 읽고 쓰는 자연어 문서들을 `[[링크]]`로 연결한 네트워크다. 스키마(schema) 없이 Claude가 문서를 읽고 자동으로 엔티티·개념을 추출하여 페이지를 생성한다.

# Ontology 방식

형식 논리에 기반한 구조화된 지식 표현. 클래스(class), 속성(property), 관계(relation)를 명시적으로 정의한 스키마(`ontology.yaml`)를 먼저 설계하고, 모든 페이지가 그 스키마를 따르게 강제한다. 기계(AI)가 추론할 수 있는 형태를 목표로 한다.

그럼 실제로 LLM 위키와 온톨로지로 만든 지식 베이스는 어떤 차이가 있을까? 이게 궁금해서 테스트를 해봤습니다. 그리고 테스트가 보다 실질적인 의미를 가질 수 있도록 지식 베이스를 채용 프로세스에 적용해 봤습니다.

테스트 준비

우선 도어락과 보안 솔루션을 개발하는 가상의 IT 회사에서 SW 개발 분야의 채용을 진행한다고 가정했습니다. 이때 회사의 채용팀은 채용 공고를 작성하고 지원자 이력서를 바탕으로 1차 평가를 수행할 것입니다. 이후 지원자 인터뷰를 위한 코딩 테스트, 질문지 준비 등의 작업을 할 것입니다. 

이 과정을 테스트하기 위해서 분야별 "채용 공고" 스크립트를 작성하고, 여기에 지원하는 지원자 이력서를 분야별로 5개씩 작성했습니다. 

채용 공고와 지원자 이력서를 분석하기 위해서는 채용과 관련된 지식 베이스를 만들어야 합니다. 이를 위해 아래와 같이 데이터를 작성하였습니다. (일정 부분 LLM 활용해서 데이터 생성)

- 회사가 만드는 product 와 여기에 사용되는 세부 기술 정보

- SW 개발에 사용되는 사용되는 구체적인 기술 및 기술 간의 상관관계 확보 

  - SW Developer Roadmap, https://github.com/nilbuild/developer-roadmap

  - 80+개 언어, framework, 기술들에 대한 로드맵 정보를 md 파일 작성

- 채용 분야 설정(frontend/backend/devops/enbedded) 및 채용 요구사항 작성

- (지원자의 필수/우대 기술 요구사항을 정의)

이렇게 만들어진 데이터를 LLM 위키와 온톨로지 2가지 방식으로 저장했습니다. 두 가지 방식의 지식 베이스 변환을 위해 llm-wiki 스킬을 사용했습니다.

- https://github.com/godstale/LLM-WiKi

그리고 테스트는 아래 3가지 조건을 차례대로 적용하게 됩니다.

1) LLM 단독: 지식 베이스 없이 LLM 자체 판단만으로 진행

2) LLM 위키: SW 개발자 로드맵 정보를 위키 형태로 구축한 지식 베이스 활용

3) 온톨로지: 동일한 로드맵 정보를 온톨로지 구조로 구축한 지식 베이스 활용

여기까지 준비된 지식 베이스를 가지고 아래 테스트를 수행했습니다.

- 지원자 이력서를 1차 평가하여 채용 적합도를 점수로 환산.

- 평가 결과와 상세 사유를 리포트로 작성

- 지원자 인터뷰를 위한 코딩 테스트, 질문지 준비

  - 채용 공고와 지원자의 기술 스택을 비교해서 지원자의 업무 일치도 파악

  - 지원자의 기술 스택에 대한 이해도를 평가할 수 있는 코딩 테스트, 질문지 작성

테스트 결과

테스트는 gemini 를 이용해서 진행했습니다. 테스트 결과는 아래에서 확인할 수 있습니다.

- https://github.com/godstale/Ontology-SW-Developer-Skills/tree/main/test

+ test

- APPLICANT : 지원자의 이력서 모음 (총 20개)

- JD : 채용 공고 (4개 분야)

- LLM_TEST : 지원자 평가(evaluation-*.md), 지원자 검증 항목 추출(varification-*.md). 지식 베이스 구축 없이 진행

- ONTOLOGY_TEST : 지원자 평가(evaluation-*.md), 지원자 검증 항목 추출(varification-*.md)

- WIKI_TEST : 지원자 평가(evaluation-*.md), 지원자 검증 항목 추출(varification-*.md) 

3가지 방식으로 나온 결과를 Gemini, Claude 를 이용해서 비교했습니다. 비교 결과는 아래와 같습니다.

- https://github.com/godstale/Ontology-SW-Developer-Skills/blob/main/test/TEST_EVALUATION_GEMINI.md

- https://github.com/godstale/Ontology-SW-Developer-Skills/blob/main/test/TEST_EVALUATION_CLAUDE.md

클로드가 자세하게 비교 분석한 결과를 만들었는데, 축약하면 아래와 같습니다.

1. 후보자 순위는 대체로 일치

세 방식 모두 1위 후보는 거의 같았습니다. 실력 차이가 명확한 지원자는 방식에 관계없이 동일하게 높은 평가를 받았습니다.

차이가 생긴 건 중간 순위였습니다. 예를 들어 임베디드 직군에서는 LLM과 온톨로지가 RTOS·저전력 최적화 전문가를 1위로 뽑은 반면, 위키는 보안 칩 전문가를 1위로 평가했습니다. 

위키가 보안 관련 로드맵 노드에 더 큰 가중치를 둔 결과로 보였습니다.

2. 평가 근거의 투명성이 다름

LLM 단독 방식은 왜 이 점수가 나왔는지 추적하기가 어렵습니다. "종합적으로 판단했다"는 식의 설명이라서, 평가 결과를 검증하거나 이의를 제기하기가 쉽지 않습니다.

위키 방식은 [[java]], [[react]] 같은 위키 노드를 명시하면서 평가 근거를 제시합니다. 어떤 기술 항목을 참조했는지는 알 수 있었습니다.

온톨로지 방식은 여기서 한 발 더 나아갑니다. 단순히 기술 키워드를 매칭하는 게 아니라, 해당 기술이 전체 아키텍처에서 어떤 도메인에 속하는지(예: Real-time Communication, Infrastructure, RTOS 등)를 기준으로 평가합니다. "이 사람을 왜 뽑아야 하는가"를 구조적으로 설명할 수 있다는 게 가장 큰 차이였습니다.

3. 인터뷰 질문의 깊이가 다름

코딩 테스트 과제는 세 방식 모두 실무 시나리오 기반으로 만들었고 품질 차이는 크지 않았습니다. 

하지만 인터뷰 질문에서는 차이가 있었습니다. LLM은 "왜 이 기술을 선택했나요?" 같은 직관적인 질문을 잘 만들었고, 위키는 이론적 배경을 강조하는 질문이 많았습니다. 온톨로지는 최신 기술 표준에 대한 질문이 더 구체적이었고, 하드웨어와 소프트웨어의 경계를 파고드는 질문이 날카로웠습니다. 실무 시니어 면접에 더 가까운 느낌이었습니다.

하지만 이 결과를 그대로 받악들이기는 힘든 면이 있습니다.

테스트 결과에 대한 단상

Gemini와 Claude 모두 온톨로지 방식이 가장 좋다고 분석했습니다. 

그런데 막상 실제 생성된 결과 파일들을 직접 보면, 그렇게 큰 차이가 있나 싶습니다. Gemini와 Claude  는 결과의 차이점을 확대 해석한 것이 아닌가 싶었습니다.

이유를 생각해보면, 이번 테스트가 가진 한계 때문인것 같습니다. 채용 공고와 이력서, 로드맵 정보가 주요 데이터였는데, 이 정도 정보만으로는 세 방식의 차이가 충분히 드러나지 않는 것 같습니다. 실제 업무에서 온톨로지가 진가를 발휘하려면 회사가 어떤 기술 스택을 중심으로 돌아가는지, 팀마다 어떤 역량이 필요한지, 내부 프로젝트와 기술적 선택의 맥락 같은 풍부한 컨텍스트가 지식 베이스에 쌓여 있어야 할 것 같습니다.

그래야 채용 공고와 이력서에서 부족했던 부분을 지식 베이스 기반으로 채울 수 있을겁니다.

■ 실제로 쓰실 분들께 드리는 말씀

채용에 LLM을 이미 활용하고 계신 분들도 있을 텐데, 이번 테스트를 참고하실 때 주의하실 점이 있습니다. 테스트 과정에서 실제 채용 공고에 제 이력서를 넣어봤더니, 전반적으로 점수를 굉장히 후하게 주는 경향이 있었습니다. 기술 로드맵 파일에 해당 키워드가 있기만 하면, 지원자가 그 기술의 숙련자라고 간주해버리는 것 같았습니다.

제대로 된 평가를 위해서는 아래 내용들이 고려되어야 할 것 같습니다.

1. 채용 공고 자체에 기술 요구사항이 상세히 기술되어야 합니다. 

  막연하게 "Java 가능자"가 아니라 어떤 수준, 어떤 용도로 필요한지가 명시되어야 합니다.

2. 지원자의 경력 기술서도 마찬가지입니다. 단순히 기술 목록을 나열하는 이력서로는 LLM도 깊이 있는 평가를 하기 어렵습니다.

  어떤 규모의 프로젝트에서 어떤 역할을 맡았고, 어떤 기술 스택/라이브러리/프레임워크를 사용했는지가 있어야 합니다.

3. 지식 베이스도 회사의 실제 업무 맥락으로 채워져야 합니다. 일반적인 기술 로드맵만으로는 회사에 맞는 평가를 기대하기 어렵습니다.

■ 결론

1. LLM 위키, 온톨로지 보다 중요한 것은 회사의 구체적 업무 정보가 지식 베이스로 구축되는 것이다.

2. 지식 베이스 규모가 클 수록 규격화/정형화 된 형식을 제공하는 온톨로지가 더 좋을 것 같다.