LLM으로 온톨로지를 확장하다: 인간-LLM 협업 프레임워크 설계 (TU Delft 석사 학위논문)

논문 개요와 전체 구조

지식을 기계가 해석할 수 있는 형태로 표준화하는 일, 즉 온톨로지 공학(Ontology Engineering, OE) 은 인공지능의 오래된 숙제입니다. 온톨로지(ontology)는 "개념과 개념 사이의 관계를 명시적으로 규정한 공유된 세계 모델"로, 서로 다른 시스템이 같은 언어로 데이터를 주고받게 해 주는 일종의 사전입니다. 그런데 이 사전을 만들고 확장(extension) 하는 작업은 여전히 거의 전적으로 수작업이며, 다분야 전문 지식과 여러 이해관계자의 합의를 요구하는 길고 까다로운 과정입니다.

이 논문은 바로 이 지점에 대규모 언어 모델(Large Language Models, LLMs) 을 어떻게 끼워 넣을지를 다룹니다. 다만 흔한 "완전 자동화"가 아니라, 인간 전문가를 루프 안에 두는(expert-in-the-loop) 반자동·도메인 독립적 프레임워크를 제안한다는 점이 핵심입니다. 저자는 LLM이 온톨로지 엔지니어를 대체하는 것이 아니라 보완해야 한다는 입장을 일관되게 견지하며, 이를 하이브리드 AI(Hybrid AI) 라는 큰 흐름 안에 위치시킵니다.

이 연구는 네덜란드 델프트 공과대학교(TU Delft)의 복잡시스템공학·경영(Complex Systems Engineering and Management, CoSEM) 석사 학위논문으로, 네덜란드 응용과학연구기구(TNO)의 데이터사이언스 부서와 협업해 진행됐습니다. 따라서 순수한 기술 논문이 아니라 사회기술 시스템(socio-technical system) 관점의 설계 연구(Design Science Research, DSR) 라는 성격을 갖습니다. 연구 전체를 관통하는 주 연구 질문은 다음과 같습니다.

기존 온톨로지의 확장을 위한 반자동·도메인 독립적 프로세스에 LLM을 어떻게 통합할 수 있는가?

이 질문은 다시 4개의 하위 질문(SQ1~SQ4)으로 분해되며, 각 하위 질문이 한 챕터씩을 차지하면서 DSR의 한 단계(문제 이해 → 요구사항 도출 → 설계 → 시연·평가)에 대응합니다. 전체 구조를 먼저 지도로 펼쳐 보겠습니다.

부록(A~E)에는 문헌 리뷰 표, 인터뷰 프로토콜·요약, 요구사항 코딩, 프로토타입 설계 상세, 그리고 각 LLM 보조 과제별 프롬프트 템플릿과 GPT 출력 결과가 담겨 있습니다. 본 리뷰에서는 본문 7개 챕터를 중심으로, 논문의 논리 전개를 그대로 따라가며 정리하겠습니다.

핵심 기여와 혁신성

해결하려는 문제의 중요성. 온톨로지는 데이터 공유·품질·상호운용성(interoperability)의 핵심 인프라입니다. 사회와 기술이 빠르게 바뀌면서 기존 온톨로지에 새 개념을 더하는 "확장"은 일상적인 작업이 되었지만, OE 분야는 소프트웨어 공학 같은 인접 분야에 비해 도구 지원이 빈약하고, 표준 방법론(Ontology Engineering Methodology, OEM)도 없으며, 고도의 전문성을 요구합니다. ICT 인력난까지 겹쳐, 진입 장벽을 낮출 방법이 절실합니다.

기존 접근법의 한계. 저자는 문헌 리뷰를 통해 LLM/NLP를 OE에 적용한 16편의 연구를 분석하고, 다음과 같은 공통적 공백을 짚어냅니다.

• 대부분이 NLP 기반이며 LLM을 본격 활용한 사례는 매우 적음(주제의 신생성).
• 제안된 솔루션 대부분이 현재 워크플로에 통합하는 방법(methodology for integration)을 제시하지 않음 — 기능 수준에서 멈춤.
• 결과물의 평가는 대부분 수작업이거나 아예 누락됨.
• 솔루션이 대체로 쓰기 어렵고, 이해하기 어렵고, 다른 도메인에 적용하기 어려움.

제안 해결책의 독창성. 이 논문의 차별점은 세 가지로 요약됩니다.

1. 단일 과제가 아니라 전체 프로세스를 다룸. 기존 연구가 "관계 추출" 같은 한 과제의 성능에 집중한 반면, 이 연구는 준비→개념화→구현→검증으로 이어지는 온톨로지 확장 프로세스 전체를 시스템 공학 관점에서 조망하고, 각 다운스트림 과제에 어떤 LLM/도구가 붙을 수 있는지를 매핑합니다.
2. 성능이 아니라 채택(adoption)을 설계함. 사용자(온톨로지 엔지니어)의 실제 워크플로를 인터뷰로 모델링하고, 그들의 우려(환경·윤리·기밀·할루시네이션)와 기회를 요구사항으로 환원합니다. EU AI Act와의 정합성까지 검토합니다.
3. 생성이 아니라 확장에 집중함. 새 온톨로지를 만드는 대신 기존 표준을 확장함으로써 재사용성·준수·상호운용성을 높이고 "바퀴의 재발명"을 피합니다. 또한 특정 모델에 묶이지 않도록 프롬프트 엔지니어링 기반으로 설계해 도메인 독립성과 벤더 독립성을 확보합니다.

예상 파급효과. 결과물은 종이 위의 프로토타입(개념 증명)이지만, REPRO 핸드북·Protégé·VS Code 같은 기존 도구·방법론에 LLM 보조 기능을 끼워 넣는 실용적 구현 로드맵까지 제시합니다. 이는 OE의 진입 장벽을 낮춰 도메인 전문가 등 더 다양한 참여자를 끌어들이고, 궁극적으로 온톨로지의 더 넓은 채택에 기여할 수 있습니다.

기술적 세부사항

본 연구의 방법론적 골격은 Johannesson & Perjons(2021)의 설계 과학 연구(DSR) 프레임워크입니다. DSR은 (1) 문제 이해·설명 → (2) 요구사항 정의 → (3) 아티팩트 설계·개발 → (4)(5) 시연·평가의 순환으로 구성되며, 각 단계의 산출물이 다음 단계의 입력이 됩니다. 본 논문은 이 순환을 4개의 하위 질문(SQ1~SQ4)에 그대로 매핑합니다.

데이터 수집·분석 측면에서는 정성적·경험적 방법이 중심입니다.

• 반구조화 인터뷰(semi-structured interviews): TNO의 온톨로지 엔지니어·LLM 전문가 11명을 대상으로, 확장 프로세스의 단계·이해관계자·도구, 그리고 LLM에 대한 우려와 기회를 청취.
• 내용 분석(content analysis): Erlingsson & Brysiewicz(2017) 방식으로, 발화에서 의미 단위(meaning unit) → 압축 의미 단위(Condensed Meaning Unit, CMU) → 범주(category)로 귀납적으로 코딩.
• 시각화 도구: 복잡성의 원인은 이시카와 다이어그램(Ishikawa/fishbone diagram), 우려·기회는 네트워크 이론 기반 시각화, 프로세스는 플로차트 다이어그램으로 표현.
• 포커스 그룹: REPRO 그룹 세션에서 Mentimeter 실시간 투표로 요구사항을 브레인스토밍·검증.

핵심 용어를 한 번 정리하고 가겠습니다.

평가 방법론에서 저자가 의도적으로 내린 중요한 결정 하나는, LLM 출력을 ML 지표(Precision/Recall)나 구조 지표(클래스 수)로 재지 않는다는 것입니다. 그 이유는 "지식을 모델링하는 올바른 방법은 하나가 아니"기 때문입니다(Noy & McGuinness, 2001). 클래스 개수가 많다고 더 좋은 온톨로지가 아니며, 정적 지표는 확장의 품질을 제대로 포착하지 못합니다. 따라서 평가는 골드 스탠더드와의 정성적 비교, 그리고 실제 사용자(엔드유저)의 점수·피드백으로 수행됩니다. 이 판단은 논문 전체의 일관된 철학("서로 다른 여러 정답이 존재한다")과 맞닿아 있습니다.

이제 논문의 챕터 순서를 그대로 따라가며 상세히 살펴보겠습니다.

챕터별 상세 리뷰

📖 Chapter 1: Introduction

챕터의 위치와 역할. 문제를 식별하고, 체계적 문헌 리뷰로 연구 공백을 찾아내며, 주 연구 질문과 4개 하위 질문을 정립합니다. 연구 전체의 출발점이자 지도입니다.

1.1 문제 식별

온톨로지는 정보 시스템에서 데이터를 사람뿐 아니라 기계가 해석하도록 돕는 형식 모델입니다. OE는 새로운 개념이 끊임없이 추가되는 거대하고 빠르게 진화하는 지식 영역에서 특히 복잡하며, 도메인과 온톨로지 양쪽에 대한 깊은 이해를 요구합니다. Kotis et al.(2020)은 도구 지원을 포함한 맞춤형 OEM이 온톨로지의 생명력·진화·재사용에 가장 큰 영향을 미친다고 보고합니다. 한편 LLM은 Transformer 기반의 수십억 파라미터 모델로, 정보 추출 같은 NLP 능력이 OE 과제와 자연스럽게 겹칩니다. 그러나 이를 OE 워크플로에 통합하는 표준 방법도, 자동 생성된 온톨로지의 품질을 검증하는 객관적 메커니즘도 없습니다.

1.2 학술적 맥락과 주 연구 질문

저자는 2023년 11~12월 Scopus·Web of Science에서 (extension AND automa*) AND (ontology OR ontologies) AND (llm* OR "large language models" OR nlp* OR ...) 질의로 검색해, 중복 제거·스크리닝 후 최종 16편을 분석합니다. 흥미롭게도 nlp* 문자열을 빼면 관련 결과가 거의 사라져, 주제의 신생성을 단적으로 보여 줍니다. 다섯 가지 기준(NLP/LLM 사용 여부, 자동화 범위, 입력 방식, 워크플로 통합 방법론 포함 여부, 한계)으로 분석한 결과, 위 "핵심 기여" 절에서 정리한 공백들이 드러납니다. 여기서 주 연구 질문이 도출되며, 초점은 의도적으로 생성이 아닌 기존 온톨로지의 확장에 맞춰집니다(TNO의 일상 업무이자, 상호운용성·재사용·표준화에 더 부합하기 때문).

1.3 연구 접근법

저자는 DSR을 선택한 이유(IS 분야의 풍부한 프레임워크, 유연성·반복성)와 한계(설계자의 주관 개입, 고수준 측면 누락 위험 — 이를 EU AI Act 검토로 보완)를 논합니다. 그리고 4개 하위 질문을 제시합니다.

1. SQ1: 현재 수작업 확장 프로세스는 어떻게 생겼고, 엔지니어들은 어떤 어려움을 겪는가?
2. SQ2: 인간-LLM 협업 프레임워크의 요구사항은 무엇인가?
3. SQ3: 통합 프로세스 프레임워크의 설계는 어떤 모습인가?
4. SQ4: 실사례로 어떻게 시연·평가하며, 현 상태(status quo)를 얼마나 개선하는가?

1.4 석사 프로그램과의 연결

저자는 이 주제가 순수 기술 문제가 아니라 사회기술 문제임을 강조합니다. 온톨로지는 합의된 지식 표현이므로, LLM 도입은 편향·공정성·설명가능성·규제 같은 사회적 차원을 동반합니다. 이는 기술을 사회적 맥락 안에서 설계하는 CoSEM 프로그램의 전형적 과제입니다.

챕터의 핵심 기여: 문헌 기반으로 "LLM을 OE 워크플로에 통합하는 방법"이라는 공백을 명확히 하고, 사용자 중심·인간 참여 접근을 연구의 축으로 세웠습니다. 다음 챕터로의 연결: 본격적 분석에 앞서 필요한 개념·용어·기관 맥락을 Chapter 2에서 정리합니다.

📖 Chapter 2: Background

챕터의 위치와 역할. 온톨로지, OEM, TNO, 그리고 LLM이라는 네 축의 기본 개념을 짧게 정리해 이후 논의의 토대를 놓습니다.

• 2.1 온톨로지: Gruber(1995)의 고전적 정의 "개념화의 명시적 명세"에서 출발해, 참조 온톨로지(reference) vs 운영 온톨로지(operational) 를 구분합니다. 본 연구의 대상은 정보 시스템에 통합되어 확장이 필요한 운영(도메인) 온톨로지입니다. 온톨로지는 개념(노드)과 관계(링크)로 이뤄진 그래프이며, 기술 논리(Description Logics)로 형식화되어 추론(reasoning)이 가능합니다. RDF·OWL·Turtle의 관계도 여기서 설명됩니다.
• 2.2 OEM: 표준 방법론은 없고, 팀·프로젝트마다 다른 방법론을 부분적으로 사용합니다. 여러 OEM의 공통 요소로 CQ(Competency Question) 가 강조됩니다 — "온톨로지가 답해야 할 질문"으로, 범위를 정하고 검증의 기준이 됩니다(시스템 공학의 요구사항에 대응).
• 2.3 TNO와 REPRO: TNO 데이터사이언스 부서는 하이브리드 AI·NLP·시맨틱 기술을 다루며, 자체 OE 모범사례 핸드북 REPRO(Recommended Engineering PRactices for Ontologies) 를 운영합니다. REPRO는 고정된 단계를 강제하지 않고 모범사례를 안내하는 살아있는 문서입니다.
• 2.4 OE와 LLM: "온톨로지=세계 지식, 인간 지식=언어, LLM=언어 처리"라는 연결을 제시하고, 프롬프트 엔지니어링 기법(Zero-shot, Few-shot, Chain-of-Thought, Prompt Chaining, RAG)을 소개합니다. 프롬프트 품질이 출력 품질에 큰 영향을 미치지만, 길다고 더 좋은 것은 아니라는 점을 명시합니다.

챕터의 핵심 기여: 이후 모든 논의에 필요한 공통 어휘와 TNO의 실제 작업 맥락(REPRO)을 확보했습니다. 다음 챕터로의 연결: 이 어휘를 들고, 실제 엔지니어들이 겪는 문제를 인터뷰로 파헤치는 SQ1으로 들어갑니다.

📖 Chapter 3: Analyzing the problem of ontology extension (SQ1)

챕터의 위치와 역할. 연구의 경험적 토대입니다. 11명의 반구조화 인터뷰를 내용 분석해 (1) 현재 프로세스를 모델링하고, (2) 복잡성의 원인, (3) LLM에 대한 우려, (4) LLM의 기회를 세 가지 주제로 정리합니다.

3.2 확장 프로세스의 이해

저자는 인터뷰와 REPRO·SABiO·HCOME 방법론을 종합해 현재 프로세스(As-Is)를 플로차트 다이어그램으로 모델링합니다. 프로세스는 정적이지도 선형적이지도 않으며, 다음 6단계로 틀을 잡습니다.

엔지니어의 능동적 참여가 없는 5·6단계는 플로차트 범위에서 제외됩니다. 흥미로운 발견은 의사결정이 집중된 곳이 준비·개념화 단계라는 점 — 이는 초기 단계가 가장 복잡함을 시사합니다. 이해관계자는 온톨로지 엔지니어, 도메인 전문가, 지식 작업자(Knowledge Worker) 로 정리되며, 도구는 Protégé·TopBraid·VS Code, 협업은 GitHub/GitLab, 검증 시각화는 draw.io·PowerPoint 등을 사용합니다(자동 시각화 도구는 유연성 부족으로 외면).

3.3 세 가지 주제 분석

Theme 1 — 확장의 복잡성: 모두가 복잡하다고 느끼진 않으며, 복잡성은 엔지니어의 경험·도메인 친숙도·온톨로지 규모/품질에 좌우됩니다. 이시카와 다이어그램으로 7개 범주(Stakeholders, Process, Governance, Status quo, Expertise, Domain, Tools)를 식별하는데, Stakeholders와 Process가 가장 큰 가지를 이룹니다. 도메인 전문가와의 합의 도출에 드는 긴 논의, 높은 추상화 요구, "애플리케이션 특화 데이터를 온톨로지에 얼마나 넣을 것인가"라는 거버넌스 딜레마가 부각됩니다.

Theme 2 — LLM 사용에 대한 우려: 6개 범주(Impact, OE expertise, Performance, Regulation, Skills, Academic Rigour)를 네트워크 시각화로 표현합니다. 가장 자주 언급된 우려는 의외로 환경 영향(에너지 소비), 풍부한 인간 협업 과정의 상실, 기밀 데이터 보안, 블랙박스 투명성 부족이었습니다. 기술적으로는 할루시네이션(hallucination) 이 최다 언급. 한 인터뷰이의 말이 인상적입니다 — "LLM은 세계의 모델이 아니라 우리 언어의 모델일 뿐이다."

Theme 3 — LLM의 기회: 확장 프로세스의 단계별로 5개 범주(Preparation, Conceptualization, Implementation, Verification, Supporting/Approach)로 묶입니다. 엔지니어들은 특히 창의·영감이 필요한 초기 단계, 구현 단계의 "제안 머신"·문법 검사기, 그리고 무엇보다 SPARQL 쿼리 생성에서 기회를 봅니다. TNO 선행 연구(Bouter et al., 2024)에 따르면 자연어→SPARQL 번역은 기술 성숙도(TRL) 7로 가장 높으며, 경험이 적은 사용자일수록 LLM의 도움을 유용하게 느꼈습니다(단, 평균적으로 응답은 부정확해 전문 지식은 여전히 필수). 작고 반복적인 과제(키워드·관계 추출)에 대한 기대도 큽니다 — "과제가 구체적이고 작을수록 성능이 좋다."

챕터의 핵심 기여: 표준 프로세스가 없는 현실을 As-Is 플로차트로 가시화하고, 복잡성·우려·기회를 경험적 데이터로 구조화했습니다. 특히 환경·윤리 우려가 성능 문제만큼 채택을 가로막는다는 발견이 중요합니다. 다음 챕터로의 연결: 이 문제·우려·기회를 그대로 요구사항으로 환원하는 SQ2로 이어집니다.

📖 Chapter 4: Requirements for a framework for ontology extension (SQ2)

챕터의 위치와 역할. 설계할 아티팩트("온톨로지 확장을 위한 인간-LLM 협업 프로세스 프레임워크")의 요구사항을 도출합니다. 핵심 성격은 처방적(prescriptive)이 아니라 서술적(descriptive) — "무엇을 하라"가 아니라 "LLM을 어떻게 쓸 수 있는지"를 보여 주며, 사용 여부의 결정권은 엔지니어에게 남깁니다.

요구사항은 세 가지 방법을 결합해 도출됩니다.

1. 문헌 검색(Method 1): 유사 설계의 요구사항을 찾되 거의 없어, 6개 소스에서 설계 원칙만 추출(반복적·문서화·도메인 독립·반자동·최신 도구 활용·재사용 촉진·플러그인 방식).
2. 인터뷰(Method 2): Theme 1의 각 CMU에서 요구사항을 생성하고, 그것이 Theme 2(우려)를 줄이고 Theme 3(기회)를 살리는지 점검. 예: "수작업 유지보수" 문제 → "OE 특화 도구 포함" 요구사항, 이는 동시에 LLM 사용을 줄여 환경·윤리 우려도 완화. 단, "정확성 vs 단순성 트레이드오프", "모호성 축소", "애플리케이션 독립성" 같은 3개 CMU는 복잡한 인간 판단이 필요해 요구사항으로 환원되지 않음.
3. 포커스 그룹(Method 3): 7명 참가, Mentimeter 브레인스토밍으로 기존 요구사항을 검증하고 신규 추가(예: "LLM이 CQ로 SPARQL 생성" → "CQ 형식화 지원").

4.2.4 EU AI Act 정합성: 제안 설계는 엔지니어가 결정권을 쥔 expert-in-the-loop 반자동 방식이므로 위험이 낮아, AI Act상 "제한적 위험" 또는 "최소 위험"으로 분류될 가능성이 큽니다. 다만 투명성 의무 차원에서, 프레임워크 사용자가 LLM과의 상호작용과 그 함의를 인지하도록 TNO가 보장해야 한다고 봅니다.

결과적으로 22개의 고수준 요구사항이 기능적(Functional)·비기능적/구조적(Structural)·비기능적/환경적(Environmental)으로 분류됩니다. 저자는 고수준 요구사항의 한계(설계-구현 간 간극)를 인정하면서도, 그것이 진정한 사용자 니즈를 반영하고 혁신적 설계의 여지를 준다고 옹호합니다.

챕터의 핵심 기여: 사용자의 문제·우려·기회를 직접 요구사항으로 번역하는 귀납적 방법으로, "성능"이 아니라 "채택"을 겨냥한 22개 요구사항을 도출했습니다. 다음 챕터로의 연결: 이 요구사항을 만족하는 실제 프레임워크를 설계하는 SQ3로 들어갑니다.

📖 Chapter 5: Designing a human-LLM collaboration process framework (SQ3)

챕터의 위치와 역할. 논문의 설계 심장부입니다. As-Is 플로차트를 To-Be 플로차트로 증강하는 방식으로, 어떤 OE 과제에 LLM/도구를 붙일지를 결정합니다.

5.1 설계 구조의 선택

저자는 Chapter 3의 As-Is 플로차트를 템플릿으로 삼아, 각 과제 옆에 (a) LLM 보조 가능 여부, (b) 새 OE 도구 사용 가능 여부를 표시하고, FAIR 정렬 스캔 같은 새 과제와 새 이해관계자를 추가합니다. 이 선택만으로 구조적 요구사항(과제 시퀀스 제시, 하이브리드 접근, 유연성)이 충족됩니다.

5.2 NLP 과제 ↔ OE 과제 매핑

LLM은 미세조정 없이도 다양한 과제를 수행하는 창발적 능력(emergent abilities) 을 갖습니다. 저자는 Kalyan(2024)의 NLP 과제 분류를 빌려, OE 확장 과제와 다음과 같이 연결합니다.

5.3 LLM의 OE 적용 현황(문헌)

두 영역으로 나눠 정밀하게 리뷰합니다.

Area 1 — OE 과제 일반: NeOn-GPT(Fathallah et al.), GPT-4+고급 프롬프트가 초보 엔지니어를 능가(Saeedizade & Blomqvist), 대화형 프레임워크 OntoChat(Zhang et al. — 요구사항 추출·CQ·테스트에 집중), GPT-4가 미세조정 SOTA에 필적하며 역할극 시스템 AutoKG 제안(Zhu et al.), CQ 생성에서 오픈소스 Zephyr가 GPT를 능가(Rebboud et al.), 9개 LLM을 3개 OL 과제로 평가한 LLMs4OL(Giglou et al.), ChatGPT vs REBEL 지식그래프 비교(Trajanoska et al.), 복잡 IE를 작은 하위과제로 쪼개면 성능이 오른다(X. Wei et al.) 등.

Area 2 — 온톨로지 매칭/정렬: 모듈화+CoT로 GPT-4가 정렬 후보를 잘 찾음(Amini et al.), ChatGPT는 높은 Recall·낮은 Precision이며 컨텍스트 길이 한계가 병목(Norouzi et al.), RAG로 후보 선택해 한계를 보완(Giglou et al.), 오픈소스 기반 OLaLa는 SBERT 번역+프롬프트+후처리 필터로 우수하나 지연(latency)이 큼(Hertling & Paulheim).

문헌 종합(takeaways): ① 즉시 쓸 OE 전용 LLM 도구는 OntoChat 정도로 희소 → 범용 LLM+프롬프트 엔지니어링으로 간다. ② GPT가 대체로 최고지만 미세조정 소형 모델도 경쟁력 있음 → 설계는 특정 모델/벤더에 독립적이되 시연엔 GPT 사용. ③ "garbage in, garbage out" — 프롬프트 품질이 결정적. ④ 정량·구조 지표는 모델링 다양성을 못 담음 → 정성 평가로 간다.

5.4 OE 도구

LLM이 못 하거나 엔지니어가 원치 않는 과제를 위해 즉시 쓸 수 있는 OE 도구들을 검증·선별합니다: 시각적 그래프 작성 Grafo, 문법·구조 오류 스캐너 OOPS!, FAIR 준수 스캐너 FOOPS!, 정량 지표 OntoMetrics/NEOntometrics, 문서 자동화 WIDOCO/OnToology. 특히 NEOntometrics는 버전 간 지표 변화를 추적해 "확장 전후 비교"라는 동적 검증을 가능케 하지만, 저자는 이마저도 "빠른 초기 검증"일 뿐 수작업 정성 검토는 대체 불가임을 분명히 합니다.

5.5 프레임워크 설계

최종 산출물은 To-Be 플로차트(Figure 5.1)입니다. 각 과제는 단계별 배경색으로 구분되고, 육각형 아이콘=OE 도구, 빨간 별 아이콘=LLM 보조 가능으로 표시됩니다. 새 이해관계자 지식 사용자(Knowledge User) — 확장된 온톨로지가 통합된 시스템의 최종 사용자 — 가 초기 단계부터 추가되어 "다양한 관점 포함" 요구사항을 충족합니다.

핵심은 각 LLM 보조 과제마다 (a) 사용할 LLM 유형, (b) 대응 NLP 과제, (c) LLM의 역할(엔지니어/도메인 전문가), (d) 출력 형식, (e) LLM 엔지니어 필요 여부를 표(Table 5.4)로 정리하고, (f) 커스터마이즈 가능한 프롬프트 템플릿(부록 D.2)을 제공한다는 점입니다. 사용자는 플레이스홀더만 도메인·유스케이스에 맞게 바꾸면 되므로, LLM 엔지니어링 지식 없이도 쓸 수 있습니다. 이로써 "사용자 친화성"·"expert-in-the-loop" 같은 환경적 요구사항이 충족됩니다.

챕터의 핵심 기여: As-Is를 To-Be로 증강하는 방식으로, 전체 확장 프로세스에 LLM·도구·이해관계자를 매핑한 구체적·실행 가능한 프레임워크와 과제별 프롬프트 템플릿을 산출했습니다. 다음 챕터로의 연결: 이 종이 위 설계를 실제 유스케이스로 시연·평가하는 SQ4로 이어집니다.

📖 Chapter 6: Demonstrating and Evaluating (SQ4)

챕터의 위치와 역할. DSR 순환을 닫는 단계로, 설계를 실사례로 시연하고 골드 스탠더드·엔드유저·요구사항의 세 층위로 평가합니다.

6.1~6.2 유스케이스와 골드 스탠더드

선택된 사례는 TNO가 2023년 수행한 SENS(Semantic Explanation and Navigation System) — 온실 환경에서 서로 다른 제조사의 자율 로봇과 인간 작업자가 의미 기반으로 소통하게 하는 시스템입니다. 로봇이 장애물을 만나면 단순히 멈추는 대신, 장애물 유형과 긴급도를 인간 운영자에게 설명하도록 합니다. 이를 위해 공개 도메인 온톨로지 CGO(Common Greenhouse Ontology) — 수천 개 클래스·인스턴스, 수백 개 관계의 대형 온톨로지 — 를 확장합니다. CGO는 이미 SENS용으로 수작업 확장된 적이 있어, 이 수동 확장본이 골드 스탠더드가 됩니다(공개라 기밀 문제도 없음).

6.3 시연(walk-through)

저자가 직접 "초보 온톨로지 엔지니어" 역할로 모든 LLM 보조 과제를 수행합니다. 모델은 GPT-4 Omni(GPT-4o), 구현은 OpenAI의 GPT Assistant — 파일 스토어에 CGO 정보·Turtle 코드를 올려 컨텍스트 한계를 우회하고 출처를 통제합니다(SENS 데이터가 없는 이전 버전 CGO 사용). 어시스턴트에는 "온실 도메인 전문 온톨로지 엔지니어" 역할과 "제공된 파일의 엔티티만 사용, 새 데이터 생성 금지, 문법적으로 정확한 코드" 등의 지시를 부여합니다.

과제별 관찰 결과(Table 6.1)의 핵심을 정리하면 다음과 같습니다.

• 준비 — 도메인/온톨로지 파악(T-1.1~1.3): 관련성 있는 유용한 출력. 단, Protégé 등으로 검증 필요(보완은 되나 대체는 불가).
• 준비 — 표준 수집(T-1.4): 완전히 할루시네이션 → 이 과제는 LLM 대신 일반 검색엔진을 써야 함.
• 준비 — 시나리오·용어집·개념 추출(T-1.5~1.7): Few-shot+구체적 지시로 관련성 있는 제안.
• 개념화 — CQ 정식화(T-2.1): 선행 연구 대비 기대 이상으로 우수. 골드 스탠더드와 유사한 CQ는 물론, 미처 생각 못한 유용한 CQ까지 제안.
• 개념화 — 재사용·모듈화(T-2.2~2.3): 재사용 온톨로지는 2개 중 1개만 식별(누락 위험). 모듈화는 일관되나 작은 확장에선 유용성 불분명.
• 개념화 — 서브온톨로지 구축·정렬(T-2.4~2.5): Few-shot+프롬프트 체이닝과 여러 수정이 필요했지만, 문법적으로 정확한 Turtle/OWL 코드를 생성하고 스스로 오류를 수정. 지시 없이도 상황별 심각도(severity) 수준을 논리적으로 부여 — 골드 스탠더드와 유사. 코드 한 줄 안 쓰고 초기 온톨로지를 얻을 수 있어 초보 엔지니어에게 특히 유용.
• 구현 — CQ→SPARQL(T-3.1): Zero-shot인데도 기대 밖 고품질. 16개 CQ 모두 문법적으로 정확, 8개가 결과 산출. "왜 그 결정을 내렸는가" 같은 추론적 CQ도 필요한 정보를 정확히 식별.
• 검증 — 인스턴스 채우기·CQ 검증(T-4.1~4.2): 개체 자동 생성 후 16개 중 14개 SPARQL이 결과 산출. CQ 답변 가능 여부도 16개 중 14개 정확 — SPARQL 없이 검증 가능해 도메인 전문가에게 유용.

6.4 평가

(1) 골드 스탠더드 대비 정성 비교(Table 6.2): SENS-GPT는 골드 스탠더드보다 분류 체계가 덜 풍부하고(상황 5 vs 7 서브클래스), 재사용 온톨로지를 덜 식별(1 vs 2)하며, 일부 모델링 결정이 다릅니다(심각도를 object property 대신 data property로). 반면 SENS-GPT는 더 완전한 CQ·SPARQL 목록, 모든 클래스/속성에 주석(annotation) 자동 생성(다국어 번역 가능), REPRO 기반이라 문서화에 바로 쓸 콘텐츠를 제공합니다. 결론: 수작업은 풍부·깊이에서, LLM은 자동화·초기 토대에서 강하므로 expert-in-the-loop가 정답.

(2) 엔드유저 평가(Table 6.3~6.4): TNO의 초보 엔지니어 1명이 동일 사례로 2.5시간 세션 수행, 1~3점 척도(1=혼란만 줌 ~ 3=거의 수작업 불필요)로 채점. 추가 프롬프트 없이 템플릿만 사용해 인간 개입을 줄였습니다. 최고점(3점) 은 용어집 생성(T-1.6)·CQ 정식화(T-2.1), 최저점(1점) 은 표준/문서 수집(T-1.3·1.4)·재사용 온톨로지 탐색(T-2.2) — 할루시네이션(존재하지 않는 "ROBOT 온톨로지" 추천) 때문. 워크스루와 점수가 갈린 과제는 T-1.5·T-2.4로, 입력 전·후처리에 들인 노력 차이가 원인입니다. 엔드유저는 "초보뿐 아니라 숙련 엔지니어에게도 번거로운 과제 자동화로 가치가 있다"고 평가했습니다.

(3) 요구사항 평가(Table 6.5): 22개 중 21개 충족. 유일한 미충족은 1.5 "온톨로지 변경의 하위 호환성(backward compatibility) 지원" — 현 OE 도구·방법론으로도 어렵고, LLM이 버전 관리·호환성에 어떻게 기여할지 불분명해 범위에서 제외(TNO 내에서도 진행 중인 논쟁).

챕터의 핵심 기여: 실사례로 프레임워크의 기능성과 유용성을 입증하고, 어떤 LLM 보조 과제가 실제로 통하는지(CQ·SPARQL·초기 형식화는 강함, 표준/재사용 탐색은 할루시네이션으로 약함)를 구체적으로 드러냈습니다. 다음 챕터로의 연결: 결과를 종합해 구현 로드맵·연구 질문 답변·기여·한계로 마무리하는 Chapter 7로 이어집니다.

📖 Chapter 7: Conclusion

챕터의 위치와 역할. 전체 DSR 순환을 회고하고, 구현 방안·연구 질문 답변·사회적/이론적 기여·한계·향후 연구를 정리합니다.

7.1 구현 로드맵

시연·평가 점수를 근거로 구현 가능성이 가장 높은 과제를 선별합니다(T-1.5·1.6·2.1·2.4, 그리고 워크스루에서 우수했던 T-3.1·4.1·4.2). 이를 세 영역으로 묶습니다.

흥미롭게도 이 결과는 OntoChat(Zhang et al.)이 사용자 설문으로 뽑은 우선 과제와 수렴합니다. 구현 경로로는 ① REPRO 핸드북에 프롬프트 입력 UI를 붙이는 웹 도구, ② Protégé 플러그인이나 VS Code 확장으로 기존 OE 도구에 통합하는 방안을 제시합니다. 다만 환경·윤리 우려와 사용 편의성이 선결 조건임을 거듭 강조합니다.

7.2 연구 질문 답변

4개 하위 질문의 답을 요약한 뒤, 주 질문에 답합니다 — "기존 확장 프로세스를 증강한 인간-LLM 협업 프레임워크" 로 통합하며, LLM은 툴킷의 새 도구로서 엔지니어가 채택·검토·수정할 재량을 갖습니다. 완전 자동화는 성능 한계뿐 아니라 엔지니어들이 원치 않기 때문에도 불가능하다는 점이 핵심 통찰입니다.

7.3~7.4 사회적·이론적 기여

사회적으로는 OE 진입 장벽을 낮춰 ICT 인력난 완화, 더 다양한 참여자 유입, 일관·고품질 온톨로지를 통한 헬스케어·농업 등으로의 간접 파급을 논합니다. 이론적으로는 인간-기계 시너지(책임 있는 AI) 담론에 기여하며, 연구를 두 IS 이론 — 과제-기술 적합(Task-Technology Fit, TTF) 과 비즈니스 프로세스 재설계(BPR) — 의 사례로 재해석합니다. TTF 관점에서 기술=LLM, 과제=확장 프로세스, 개인=엔지니어, 활용의 선행조건=환경·윤리 우려로 매핑됩니다.

7.5~7.6 한계와 향후 연구

저자는 한계를 명시적으로 나열합니다(추측으로 지어내지 않음).

• 단일 유스케이스(CGO+SENS) 로만 평가 → 도메인 독립성 미검증.
• LLM 보조 과제에만 집중 → 수작업·비AI 도구 과제는 미평가.
• 엔드유저 1명·단일 모델(GPT-4o) → 일반화·벤더 종속 위험.
• 수작업 절감량·필요 전문성의 정량화 곤란.

향후 연구로는 다도메인 평가, 전체 프레임워크 적용, 여러 LLM(특히 오픈소스·미세조정) 비교 및 지속가능성(에너지·비용) 평가, 더 넓은 참가자(도메인 전문가 포함) 평가, 온톨로지·LLM 출력의 표준 평가 지표 개발, 그리고 에너지 라벨·보증 씰 같은 윤리적·규제적 장치를 제안합니다.

챕터의 핵심 기여: "LLM은 보완하되 대체하지 않는다"는 철학을, 실행 가능한 구현 로드맵과 정직한 한계·후속 과제로 마무리했습니다.

실험 결과 심층 분석

이 논문의 "실험"은 벤치마크 점수가 아니라 단일 실사례(CGO+SENS)에 대한 정성적 시연·평가입니다. 그럼에도 과제별로 LLM이 어디서 강하고 어디서 무너지는지가 선명하게 드러납니다. 핵심 수치를 정리하면 다음과 같습니다.

골드 스탠더드 대비 트레이드오프. SENS-GPT는 개념의 풍부함·표준 통합에서 수작업본에 뒤졌습니다(상황 분류 5 vs 7, 재사용 1 vs 2, 인간 위치 구분·Hazardousness 클래스·PossibleRecognition 클래스 누락). 반대로 CQ·SPARQL의 완전성, 전 요소 주석 자동 생성(다국어 가능), 문서화 토대에서는 앞섰습니다. 저자의 결론은 "둘 다 옳은 모델링이며, 시너지를 극대화하는 sweet spot은 expert-in-the-loop"입니다.

통계적 신뢰도의 한계. 저자 스스로 인정하듯 엔드유저 1명·모델 1종·사례 1건이므로 일반화는 제한적입니다. 게다가 시연(저자 수행, 추가 프롬프트·전후처리 다수)과 엔드유저 평가(템플릿만, 시간 제약)의 결과가 갈렸다는 사실 자체가, 출력 품질이 입력 품질과 사용자 숙련도에 크게 의존함을 보여 줍니다("garbage in, garbage out"). 이는 단점이 아니라 오히려 expert-in-the-loop 설계 철학을 실증적으로 뒷받침합니다.

재현성. 프롬프트 템플릿(부록 D.2)과 GPT 출력(부록 E)이 논문에 포함되어 있고, CGO와 SENS 확장 코드는 공개 GitLab 저장소에 있습니다. 다만 GPT-4o라는 폐쇄형 모델과 GPT Assistant 설정에 의존하므로, 모델 버전이 바뀌면 동일 출력의 재현은 보장되지 않습니다(엔드유저 세션에서 시연과 미묘히 다른 응답이 나온 점이 이를 방증).

기술적 함의와 응용

분야에 대한 함의. 이 논문이 던지는 가장 중요한 메시지는, LLM을 OE에 들이는 일이 성능 최적화 문제가 아니라 채택(adoption)과 워크플로 통합 문제라는 재정의입니다. 아무리 성능이 좋아도 수작업보다 번거롭거나, 환경·기밀 우려를 해소하지 못하면 엔지니어는 쓰지 않습니다. 따라서 (1) 기존 도구·방법론(REPRO·Protégé·VS Code)에 매끄럽게 끼워 넣고, (2) 사용 여부의 결정권을 인간에게 남기며, (3) 특정 벤더에 묶이지 않는 프롬프트 기반 설계가 합리적이라는 결론은, 다른 지식 공학·표준화 영역에도 그대로 적용됩니다.

다른 연구 영역으로의 확장. CQ 생성·SPARQL 번역·인스턴스 채우기처럼 검증이 쉽고 구체적인 과제에서 LLM이 강하다는 발견은, 지식 그래프 구축 일반으로 확장 가능합니다. 반대로 재사용 표준 탐색처럼 사실성(factuality)이 결정적인 과제는 할루시네이션 탓에 여전히 인간·전통 도구의 몫입니다. 이 "강점/약점 지도"는 다른 도메인의 LLM 도입 설계에도 유용한 휴리스틱입니다.

산업 적용 시 고려사항. 폐쇄형 대형 모델(GPT)의 편의성과, 오픈소스·온프레미스 배포의 기밀성·환경성 사이의 균형, 그리고 "에너지 라벨"·데이터 출처 투명성 같은 규제 정합성이 실제 도입의 관건입니다. 저자는 소형·미세조정 오픈소스 모델이 머지않아 범용 모델을 따라잡을 것으로 전망합니다.

TrendHacker와의 접점. 이 블로그를 운영하는 TrendHacker 프로젝트 자체가 결정론적 태그 파이프라인(폐쇄형 승격)으로 노드(키워드)를 채우고, 무료 LLM으로 타입드(방향성) 관계(엣지)를 분류해 지식 DB를 키우는 구조를 갖고 있습니다. 이는 본 논문이 강조하는 두 가지 원칙과 정확히 공명합니다 — ① 표는 결정론적으로, 서사·분류만 LLM에게(본 논문의 "표는 골드 스탠더드처럼 다루되 LLM은 창의·정식화에"), ② 자동 승격 금지·인간 큐레이션(본 논문의 expert-in-the-loop). 특히 "키워드 LLM은 추천만, 결정은 사람이"라는 우리 프로젝트의 큐레이션 루프는, 이 논문의 "LLM은 보완하되 대체하지 않는다"는 결론의 작은 실천 사례라 할 수 있습니다. 관계를 닫힌 타입 집합(made_by/is_a/part_of/...)으로 분류하는 방식 또한, 논문이 인용한 Giglou et al.의 Taxonomy Discovery·Non-Taxonomic Relation Extraction과 같은 계보에 있습니다.

요컨대 이 학위논문은, 화려한 자동화 데모 대신 현장 엔지니어의 목소리에서 출발해 LLM을 기존 워크플로에 책임 있게 통합하는 길을 설계 과학의 엄밀함으로 보여 준, 보기 드물게 균형 잡힌 연구입니다.