세미나
지그재그 세미나 3회 - 12/12
장소: 그랑서울 타워2 15층 (서울 종로구 종로 33)
일시: 2025-12-12 오후 7시
진행 방식
1.
기술 세션과 토의 세션으로 구분하여 진행
a.
기술세션 주제 : AI에이전트와 지식표현
b.
토의세션 주제 : 온톨로지 기반 운영모델
순서표
시간 | 내용 | 진행 | |
19:00 ~ 19:10 | 인사 및 소개 | ||
19:10 ~ 19:30 | 오픈 소스로 구성하는 지식그래프 엔진 - 그 가능성에 대한 보고서 | 김정석 | |
19:30 ~ 19:50 | 대화형 검색에서 다양한 RAG기반 검색 방식 성능 비교 | 김수진 | soongtunes_공유용.pdf5.77MB |
19:50 ~ 20:00 | 휴식 | ||
20:00 ~ 21:30 | 토의 - 온톨로지 기반 운영 모델 |
내용 요약
오픈 소스로 구성하는 지식그래프 엔진
요약
발표자는 **지식 표현(온톨로지)**을 실제로 활용하려 했으나, 막상 바로 사용할 수 있는 엔진이나 기술이 거의 없다는 문제에 직면했고, 그 결과 직접 조사하고 프로토타입까지 제작한 과정을 공유하였다.
1.
문제 인식
•
온톨로지는 주목받고 있으나, 예산 없이 PoC를 수행할 수 있는 실용적 도구가 부족함
•
상용 솔루션은 초기 비용·절차 부담이 커서 배제하고, 오픈소스 중심으로 조사 진행
2.
온톨로지 저장소 조사 결과
•
레거시 / 표준 / 차세대 프로젝트로 분류
•
레거시 계열은 기술적으로 우수했으나 유지보수·최신 표준(SPARQL 1.1 등) 미지원 문제로 제외
Knowledge_Graphs_AI_Operating_System.pdf12.45MB
•
표준 계열(예: Apache Jena, Eclipse RDF4J)은 여전히 대체 불가하지만
Knowledge_Graphs_AI_Operating_System.pdf12.45MB
◦
Java 버전 의존성
◦
메모리 사용량
◦
로컬 PoC에 과도한 운영 부담이라는 한계 존재
•
차세대 후보 중 일부(예: Oxigraph)는 성능·라이선스·WASM 지원 등 장점이 있으나
◦
메인테이너가 1인이라는 지속성 리스크 존재
3.
추론(Reasoning) 관점의 한계
•
기존 RDF 추론 엔진은 **증분 추론(incremental reasoning)**이 어려워 데이터 추가 시 전체 재계산이 필요한 구조적 문제 존재
•
이를 해결하기 위해 Datalog 기반 추론 엔진들이 등장
◦
인메모리 고속 추론
◦
신규 데이터에 대해서만 델타 추론 수행
◦
온톨로지 + 벡터 DB 결합 시도 등 다양한 접근 확인
•
라이선스 검토 결과 상업적 사용에도 큰 제약은 없음
4.
중간 결론
•
"엔진은 새로 만들 필요 없다. 쓸 만한 것은 이미 있다."
•
그러나 가장 큰 공백은 '데이터 적재' 영역
◦
RDF/SPO 온톨로지는 받지만 PDF, 이미지, 이메일, 비정형·정형 파일을 어떻게 온톨로지로 변환할지에 대한 해법이 없음
5.
자체 프로토타이핑
•
이 공백을 해결하기 위해 비정형 데이터 → 온톨로지(SPO) 변환 파이프라인을 직접 구현
•
핵심 아이디어:
◦
이미지·텍스트 등 입력 데이터 타입 자동 판별
◦
OCR이 아닌 **"이미지를 설명하라"**는 방식으로 의미 추출
◦
설명 결과를 중간 표현으로 삼아 온톨로지화
•
영수증, 생성형 이미지 등 다양한 사례에서 의미 있는 개체·관계가 온톨로지로 변환됨을 시연
6.
흥미로운 관찰
•
LLM이 매번 동일하지 않은 온톨로지를 생성하지만
→ 온톨로지는 누적 구조이므로 오히려 정보 확장의 장점이 될 수 있음
→ 온톨로지는 누적 구조이므로 오히려 정보 확장의 장점이 될 수 있음
7.
결과물 및 향후 계획
•
Python 기반 프로토타입을 GitHub에 공개
•
빠른 실험을 위해 Python을 사용했으며, 아키텍처 확정 후 컴파일 언어로 재구현 예정
•
라이선스는 GPL + Commercial 이중 라이선스로 설정하여 커뮤니티 기여와 아이디어 환원을 유도
•
관심 있는 사람들의 컨트리뷰션을 요청하며 발표 마무리
대화형 검색에서 다양한 RAG기반 검색 방식 성능 비교
요약
연구는 음악 검색·추천 RAG 시스템에서 그래프 기반 검색 방식들을 비교 평가하는 것이 목적이며, 특히 **대화 맥락(누적 조건)**을 얼마나 정확히 반영하는지가 핵심 쟁점이다.
1.배경: 기존 검색/추천의 한계
•
키워드 검색: 문자 매칭 중심이라 동의어/유의어 처리와 맥락 반영이 약하고, 정확한 곡명·아티스트명을 알아야 검색이 잘 됨.
•
순수 벡터 검색: 의미 유사도 검색은 가능하지만 정보가 임베딩으로 "통합"되며, 아티스트/장르/조건을 구조적으로 제어하기 어렵고 조건이 많아질수록 추적이 힘듦.
•
대화 길이(숏텀 메모리·질문 재작성): 대화가 길어지고 조건이 누적될수록 질문 재작성 과정에서 맥락 왜곡·조건 누락 위험이 커짐.
2.
연구 목표
•
단순 메모리 버퍼/질문 재작성 방식의 한계를 보완하기 위해, **구조화된 맥락 표현(그래프)**의 효과를 검증하고자 함.
•
사용자 대화 흐름 속에서 의도와 누적 조건을 안정적으로 유지하는 검색·추천 방식을 구축하고 성능 비교.
3.
비교한 4가지 검색 방법
•
(1) Contextual RAG(버추얼 노드 방식): 대화 맥락을 "가상 쿼리 노드"로 그래프에 저장하고, 누적 상태를 참조해 검색.
•
(2) Graph RAG: 그래프 구조 + 커뮤니티/연결 패턴(루뱅 알고리즘 기반 커뮤니티 등)을 활용한 검색/랭킹.
•
(3) Vector RAG: 임베딩 기반 벡터 검색.
•
(4) Keyword/Text-to-Cypher 기반: 자연어를 Cypher 쿼리로 변환해 조건 조합 검색(입력 불명확 시 실패 가능).
4.
시스템/데이터 구성
•
멜론 플레이리스트 데이터셋의 메타데이터를 활용해 음악 지식그래프 구축(노래-아티스트-앨범-장르(세부장르 포함)-태그(분위기 등)-플레이리스트 관계).
•
모든 노드에 OpenAI 임베딩을 부여.
•
Graph RAG는 Neo4j 기능을 사용하고, 커뮤니티는 루뱅 알고리즘으로 생성.
5.
평가 설계
•
별도 정답 데이터가 없어 평가셋을 생성:
◦
인기곡 1,000곡을 샘플링
◦
곡 메타데이터를 바탕으로 LLM이 자연어 질의·대화 시나리오를 생성
◦
각 질의에 대한 기대 정답(곡 ID)을 그래프 쿼리로 생성해 정답 셋 구성
•
지표: MRR, nDCG, Recall, Precision, F1 등.
•
RAG 평가 라이브러리(예: RAGAS류)를 연동해 측정.
6.
결과 및 결론
•
버추얼 노드(맥락을 그래프에 구조화·영속 저장) 방식이 모든 지표에서 최고 성능.
•
Graph RAG는 기대보다 낮았는데, 커뮤니티 기반 확장 과정에서 사용자 조건과 무관한 곡이 섞일 가능성이 원인으로 해석.
•
핵심 이점은 맥락의 구조화: 임베딩/질문 재작성 대신, 세션-조건-의도를 그래프로 남겨 복잡한 다중 조건(예: "이전 곡과 비슷하지만 빠른 템포, 2010년대")을 더 정확히 포착.
7.
향후 과제
•
Graph RAG의 "다양성" 측면을 더 평가할 수 있도록 지표 확장.
•
숏텀 메모리 누적을 **롱텀 메모리(사용자 프로필/취향)**로 확장.
•
버추얼 쿼리 노드의 생명주기(세션 관리/만료/갱신) 설계 중요.
토론 내용
요약
1.
모임 목적과 오늘의 화두
•
지난달 "AI-Ready Data, 데이터웨어하우스/데이터레이크의 역할과 한계"를 논의하다가 온톨로지 기반 운영모델 주제로 확장되었고, 이를 오늘 공개 토의로 이어감.
•
오늘의 큰 질문은 "에이전트 AI 시대(자동화 → 자율화)에서 온톨로지가 어떤 역할을 할 수 있는가", 더 구체히는
"온톨로지는 지식표현 체계로서 운영모델/운영체제로 진화할 수 있는가".
"온톨로지는 지식표현 체계로서 운영모델/운영체제로 진화할 수 있는가".
2.
"운영모델" 정의 정리
•
공학 관점: 데이터–모델(엔진)–애플리케이션의 3층 구조로 이해 가능.
•
현업 관점: 문서화되지 않은 경험·노하우·해석이 발현되는 지점을 시스템화/정규화해 담는 체계를 운영모델로 인식.
•
현실에서는 온톨로지/지식그래프/Graph RAG 등이 혼용되며, 개념 구분 자체가 높은 전문성을 요구한다는 공감대가 있음.
3.
RDF/OWL로 "현실 비즈니스"를 충분히 표현할 수 있나?
•
이론적으로 가능하더라도 현업에서의 핵심 병목은 '사람이 해야 하는 모델링 비용':
•
심볼릭 AI가 과거 "예외 처리·지식 입력 비용" 때문에 벽을 겪었던 역사와 유사하다는 시각.
•
"사람이 전부 정의해야 하는데 도구/프로세스가 없다"는 문제 제기.
•
추가 관점: 세상을 전부 표현하려는 전제가 위험할 수 있고(철학적 비유), 사람마다 의미 이해가 달라 공통 의미/언어 합의 자체가 난제라는 지적.
•
대안적 합의:
◦
모든 데이터를 RDF로 만들 필요는 없고, "공리(axiom)/핵심 팩트" 수준은 RDF/OWL이,
더 넓은 연결성/실무 유연성은 LPG(프로퍼티 그래프) 등 혼합이 현실적일 수 있음.
더 넓은 연결성/실무 유연성은 LPG(프로퍼티 그래프) 등 혼합이 현실적일 수 있음.
•
결국 "문제(유스케이스)에 맞는 데이터/모델 적합성"이 선행되어야 한다는 결론으로 수렴.
4.
데이터는 '결과물'이 아니라 '트리거/브리지'인가?
•
데이터는 단순 저장 대상이 아니라 **운영을 촉발(트리거)하거나 연결(브리지)**하는 매개가 될 수 있다는 논의.
•
다만 트리거는 단독으로 의미가 없고, 관련 객체/관계 설계가 되어야 인사이트로 연결된다.
•
의료 비유로, 사람은 "목적을 먼저 깔고" 데이터를 읽는다 →
온톨로지화도 **목적성(무엇을 트리거로 삼고, 무엇을 하이라이트할지)**이 핵심이라는 정리.
온톨로지화도 **목적성(무엇을 트리거로 삼고, 무엇을 하이라이트할지)**이 핵심이라는 정리.
5.
오픈월드/비단조 추론과 '운영체제화'의 난제
•
현실 세계는 예외가 많고(오픈월드), 온톨로지의 단조 추론만으로는 운영에서 생기는 충돌/변경/예외를 다루기 어렵다.
•
컴퓨터 운영체제도 "오류 0"이 아니라 오류 허용/격리/우회 메커니즘으로 동작한다는 비유 제시.
•
결론적으로:
◦
"온톨로지/지식그래프만으로 운영을 완결"하기보다,
◦
어떤 데이터는 고정(팩트)으로 두고, **의사결정 경로/프로토콜(볼 순서·판단 로직)**을 조정하는 접근이 더 현실적일 수 있다는 관점이 나옴.
•
LLM은 온톨로지 결과가 부족해도 유사도 기반으로 보완 생성하는 등 "혼합 사용"이 오히려 실용적이라는 평가도 있음.
6.
자율화(Agentic AI)는 어디까지 가능하나
•
"완전 자율(인간 개입 0)"은 비현실적이며 Human-in-the-loop는 필수라는 견해.
•
반면 업무 단축/효율화 수준의 자율은 비교적 단기간(수년) 내 가능할 수 있음.
•
그러나 "데이터는 그대로인데, 프레임 자체를 바꿔 재해석하는 수준의 자율(관점 전환)"은 더 먼 이야기.
•
실제 기업 업무는 수천~수만 단위 태스크로 쪼개지고 협업·우선순위·스케줄링이 필요해, "운영체제처럼" 만들기엔 아직 갈 길이 멀다는 정리.
7.
마무리
•
충분히 결론을 내기보다는, 온톨로지 운영체제화 논의가 결국 "유스케이스 적합성, 모델링 비용, 검증, 예외 처리, 프로토콜/운영 메커니즘"으로 귀결된다는 점을 확인하고 토의를 종료.
정리 영상
Knowledge_Graphs_AI_Operating_System.pdf12.45MB
준비
토의 세션
주제
온톨로지 기반 운영 모델
온톨로지는 지식 표현 체계로서 운영모델 또는 운영체제로 진화할 수 있을까?
온톨로지는 지식 표현 체계로서 운영모델 또는 운영체제로 진화할 수 있을까?
질문들
온톨로지의 본질과 역할에 대한 질문
1.
RDF/OWL 기반 온톨로지가 현실 세계의 복잡한 비즈니스 운영을 충분히 표현할 수 있는가?
2.
온톨로지의 범위는 어디까지 확장 가능한가? (데이터 → 프로세스 → 행동 → 의사결정)
운영 모델/운영 체제와 온톨로지의 접점에 대한 질문
1.
운영체제(Operating System)를 구성하는 핵심 요소는 무엇이며, 온톨로지는 그 요소들을 어떤 방식으로 대체할 수 있을까?
2.
온톨로지가 운영모델이 되는 순간, “데이터”는 어떤 형태로 역할이 변하는가?
자동화에서 자율화로의 전환 관점
“무엇을 할지 사람이 정하고, 어떻게 할지는 기계가 스스로 찾는다.”
1.
자동화와 자율화의 본질적 차이는 무엇이며, 온톨로지는 어느 지점에서 자율화를 가능하게 하는가?
2.
온톨로지는 계획(Planning)과 의사결정(Decision-making)이 가능한가?
기술적/ 조직적 관점의 질문
1.
현실 시스템에 필요한 비단조 의사결정은 어떻게 처리가 가능할 것인가?
2.
온톨로지가 운영체제화될 때 조직의 역할 체계(업무 역할/자원 역할)는 어떻게 재편되는가?
마무리
10년 후 기업 운영에서 온톨로지는 어떤 위치에 있을까?