여분의 해마

[논문 리뷰] SPARQL-LLM: Real-Time SPARQL Query Generation from Natural Language Questions

송채채 — Thu, 16 Apr 2026 10:58:51 +0900

논문 요약: SPARQL-LLM

경량 메타데이터(질의 예시 + 스키마)를 활용해 자연어 질문을 실시간·저비용으로 정확한 SPARQL 질의로 변환하는, 오픈소스 및 트리플스토어 독립적 시스템

1. 연구 배경과 문제의식

SPARQL의 높은 진입장벽: 지식 그래프(KG)에서 SPARQL 질의 작성은 문법, 복잡한 스키마 이해, 연합 질의(Federated Query) 지식 등이 필요하여 어려운 작업임
기존 연구의 한계: 최신 LLM 접근법들은 주로 단일 소스에서의 정확도에만 치중하며, 실제 운영 환경에서 중요한 응답 시간(Runtime), 비용, 연합 질의 능력은 간과하는 경향이 있음
도메인 특수성: 특히 생명정보학(Bioinformatics) 도메인은 데이터가 방대하고 스키마가 복잡하며 빠르게 진화하여 기존 시스템들이 대응하기 어려움

Note: 파인튜닝을 하지 않고, 프롬프팅과 임베딩만으로 구성했다는 점에서 인상적이었음. 파인튜닝을 할 수 없는 환경이 많기때문에,,

2. 제안 방법: SPARQL-LLM의 아키텍처

SPARQL-LLM은 엔드포인트에서 직접 추출한 경량 메타데이터를 활용함

A. 제공되는 컨텍스트 (Provided Context)

질의 예시 (Query Examples): 사람이 작성한 실제 질문-질의 쌍을 활용하여 사용자 의도와 실제 쿼리 간의 간극을 메움
데이터 인지형 스키마 (Data-Aware Schema): VoID 기술서를 통해 클래스 간 관계를 파악하고, 이를 LLM이 이해하기 쉬운 ShEx(Shape Expressions) 형태로 변환하여 제공함

[cite_start]B. 시스템 구성 모듈 [cite: 45, 104]

Indexing Component: 엔드포인트에서 예시를 수집하고, 데이터 스키마 등을 임베딩하여 벡터 데이터베이스에 저장함 (최초 배포 시 1회 수행)

Indexing Component. This component is responsible for: i) automatically retrieving the aforementioned metadata (i.e., the query examples and the data schema) from each endpoint,ii)generating monolingualormultilingualembeddings for this metadata, and iii) index this metadata together with the generated embeddings into a vector database. Hence with this component, which is executed only on the initial deployment of our system, we enable the retrieval and semantic matching of the Prompt Building Component. We also index in the vector database general information about the content of each endpoint, which we retrieve from the schema.org metadata available on each endpoint, which we then provide when related questions are posed by the users (e.g., “Which resources are supported by the system?”).

Prompt Building Component: 질문을 하위 질문으로 분해하고, 벡터 검색을 통해 가장 관련성 높은 예시와 클래스 정보를 추출하여 프롬프트를 구성함
SPARQL Generation Component: LLM을 통해 쿼리를 생성하며, 생성된 쿼리가 스키마에 부합하는지 검증 및 수정 루프(최대 3회)를 거침
SPARQL Execution Component: 최종 쿼리를 실행하고, 결과값을 다시 LLM에 전달하여 사용자 친화적인 자연어 답변으로 변환함

Note: 임베딩 벡터를 사용해서 예시 쿼리나 데이터를 프롬프트에 동적으로 주입하는 전략이 유용해보임

3. 주요 평가 결과

A. TEXT2SPARQL 챌린지 성과 (일반 KG: DBpedia 등)

정확도: 기존 우승 시스템 대비 F1 Score가 24% 향상됨
속도: 타 시스템 대비 최대 36배 빠름 (중앙값 3.1초 vs 112.5초)
비용: 질문당 최대 $0.01 수준으로 매우 경제적임

B. BioKGQA 평가 (전문 도메인: UniProt, Bgee 등)

일반 쿼리보다 10배 더 많은 트리플 패턴을 가진 복잡한 연합 질의에서도 유효한 성능을 보임
데이터 규모가 수십억 개인 실제 공공 엔드포인트에서도 잘 확장(Scale)됨을 입증함

C. 하이퍼파라미터 인사이트

예시의 중요성: 예시(Few-shot)가 없을 때 성능이 가장 크게 하락함 (핵심 컴포넌트 중 1위)
스키마 정보: 미지의 KG(Corporate)에서는 전체 스키마를 넣으면 유리하지만, 이미 LLM이 잘 아는 KG(DBpedia)에서는 큰 차이가 없음
임베딩 모델: 다국어 지원 시에는 다국어 임베딩 모델(예: Jina, SBERT-M)이 필수적임

Note: 5~10개 정도의 적절한 예시만 있어도 성능이 포화(Plateau)된다고 함. 그 이상의 예시는 불필요할 수도

4. 결론 및 향후 과제

의의: 정확도, 지연 시간, 비용의 균형을 맞춘 운영 가능(Production-ready)한 시스템이며, 실제 생명정보학 포털(expasy.org/chat)에 배포됨
한계: 저자원 언어 및 더 넓은 범위의 SPARQL 기능 지원이 필요함
향후 계획: MCP(Model Context Protocol) 서비스 통합 및 데이터 분석 워크플로우 전반으로의 확장

2026-04-16 기준 실제로 데모 서비스에 접근이 되어 테스트 해보았음. 예시 질의 중 하나로 했더니 대략 20초 정도 소요됨

[논문 리뷰] GraphRAG, OntologyRAG, Multi Hop 추론 관련 논문

송채채 — Fri, 13 Mar 2026 15:36:31 +0900

서론: 인공지능 추론 아키텍처의 패러다임 전환

최근 대규모 언어 모델(LLM, Large Language Models)은 단순한 텍스트 생성을 넘어, 고도의 논리적 추론과 도메인 특화 지식 처리가 요구되는 복잡한 작업(Task)에 투입되고 있다. 초기 LLM의 한계인 환각 현상(Hallucination)과 지식의 정적 성질을 극복하기 위해 외부 지식 베이스를 활용하는 검색 증강 생성(RAG, Retrieval-Augmented Generation) 기법이 도입되었다. 그러나 전통적인 벡터 기반 RAG는 문서의 의미론적 조각(Chunk)을 독립적으로 검색하기 때문에, 문서 전체를 아우르는 전역적 맥락(Global Context)의 이해나 엔티티 간의 복잡한 관계망을 추적해야 하는 다중 홉 추론(Multi-hop Reasoning)에서 명확한 한계를 노출했다.

이러한 맥락에서 지식 그래프(KG, Knowledge Graph)의 위상수학적 구조와 LLM의 능력을 결합한 GraphRAG 아키텍처, 자율적 온톨로지 생성 기술, 그리고 이를 오케스트레이션(Orchestration)하는 멀티 에이전트 시스템이 새로운 표준으로 부상하고 있다. 본 보고서는 제공된 24편의 핵심 학술 논문들을 주제별로 묶어, 각 논문이 제시하는 요약(Summary), 방법론(Methodology), 그리고 파이썬(Python) 생태계 기반의 실제 구현 메커니즘(Implementation)을 심층적으로 분석한다.

1. GraphRAG의 진화와 기반 프레임워크 설계

지식 그래프를 RAG에 통합하는 과정은 단순한 데이터베이스 교체가 아닌, 검색 패러다임 자체의 변화를 의미한다. 이 섹션에서는 GraphRAG의 기틀을 마련한 핵심 연구들과 이를 집대성한 서베이 논문들을 분석한다.

전역적 맥락 이해를 위한 커뮤니티 요약 기법

"From Local to Global: A Graph RAG Approach to Query-Focused Summarization" (2024) 논문은 전체 코퍼스에 대한 전역적(Global)인 이해가 필요한 질의응답을 처리하기 위한 혁신적인 방법론을 제시한다. 벡터 기반 RAG가 문서의 국소적(Local) 정보만 검색하는 한계를 극복하기 위해, 이 연구는 텍스트에서 추출한 엔티티와 관계를 바탕으로 지식 그래프를 구축하고, 커뮤니티 탐지(Community Detection) 알고리즘을 통해 노드들을 논리적 그룹으로 클러스터링하는 방법론을 채택했다. 구축된 그래프 커뮤니티별로 요약(Community Summaries)을 사전 생성한 뒤, 실행 시간(Runtime)에 질의가 들어오면 이 요약본들을 바탕으로 답변을 통합 생성한다. 실제 구현 과정에서 이 연구는 다중 파트(Multipart) LLM 프롬프트를 사용하여 텍스트 내의 모든 엔티티(이름, 유형, 설명)와 이들 간의 관계를 단일 구분된 파이썬 튜플(Tuple) 리스트 형태로 반환하도록 설계했다. 파이썬 환경에서 그래프 커뮤니티 구조를 탐지하고 관리하기 위해 NetworkX 와 같은 라이브러리가 그래프 인스턴스화에 사용되며, 커뮤니티 요약 데이터를 체계적으로 관리하기 위해 JSON 포맷 구조의 딕셔너리를 적극 활용한다.

GraphRAG 기술의 체계적 분류 및 서베이

GraphRAG 방법론이 급증함에 따라 이를 체계화한 세 편의 서베이 논문이 등장했다. "A Survey of Graph Retrieval-Augmented Generation" (2025) 논문은 GraphRAG를 인덱싱(G-Indexing), 검색(G-Retrieval), 생성(G-Generation)의 세 가지 핵심 파이프라인으로 정형화했다. 이 연구는 지식의 조직 방식에 따라 세밀한 도메인 지식을 제공하는 ‘지식 기반(Knowledge-based) GraphRAG’와, 대규모 확장이 가능하도록 팩트 링킹(Fact Linking)을 활용하는 ‘인덱스 기반(Index-based) GraphRAG’로 아키텍처를 세분화하는 방법론을 제시한다. "Graph Retrieval-Augmented Generation: A Survey (ACM TIS)" (2025/2026) 역시 이러한 3단계 분류를 따르며, 지식 품질과 시스템 일반화 측면의 과제를 분석한다. 또한 "Graph-based Approaches and Functionalities in Retrieval-Augmented Generation" (2026) 논문은 그래프 기술이 단순히 검색을 넘어 RAG의 데이터베이스 구축 알고리즘과 파이프라인 전반에 어떻게 적용되는지 포괄적으로 다룬다. 이들 서베이 연구는 이론적 분석에 그치지 않고, 연구자들이 기술을 실증할 수 있도록 깃허브 리포지토리(pengboci/GraphRAG-Survey)를 통해 파이썬 기반 오픈소스 프로젝트와 벤치마크 데이터셋을 큐레이션하여 제공하는 구현 방식을 취한다.

연구 논문	핵심 방법론 (Methodology)	파이썬 라이브러리 및 구현 기술 (Implementation)
From Local to Global (2024)	그래프 커뮤니티 클러스터링 및 계층적 요약	Tuple 기반 엔티티 추출, JSON 파싱, NetworkX 그래프 커뮤니티 탐지
A Survey of Graph Retrieval-Augmented Generation (2025)	지식 기반 vs 인덱스 기반 아키텍처 분류 방법론	Python 기반 GraphRAG 생태계 오픈소스 리포지토리 큐레이션 제공

2. 멀티 에이전트 시스템과 동적 지식 추론 구조

정적인 지식 검색을 넘어, 외부 도구를 동적으로 사용하고 에이전트 간 협업을 통해 지식 그래프를 확장하는 메커니즘은 최신 AI 시스템의 핵심 동력이다.

사고 지식 그래프 (Knowledge Graph of Thoughts, KGoT)

"Affordable AI Assistants with Knowledge Graph of Thoughts" (2024/2025) 논문은 고비용 대형 모델에 의존하지 않고 경제적이고 효율적인 AI 어시스턴트를 개발하기 위한 KGoT 아키텍처를 제안한다. 이 방법론은 모델의 선형적인 프롬프트 의존성을 탈피하기 위해, 해결해야 할 과제와 관련된 지식을 동적 지식 그래프(Dynamic KG) 구조로 추출 및 정형화한다. 이후 수학 문제 해결기, 웹 크롤러, 파이썬 코드 실행 환경 등 외부 도구를 활용하여 지식 그래프를 반복적으로 보완하며 추론을 전개한다. 구현 측면에서 이 프로젝트는 파이썬 3.10 이상 환경에서 LangChain을 활용해 전체 도구 사용을 오케스트레이션하며, Ollama를 통해 로컬 모델을 구동한다. 지식 그래프의 논리적 관리를 위해 NetworkX 모듈을 기본으로 사용하고, Neo4j와 RDF4J 데이터베이스 백엔드를 통합하여 그래프를 쿼리한다. 웹 브라우징에는 Playwright와 SerpAPI가 채택되었으며, 보안이 중요한 파이썬 코드 도구 실행은 Docker 컨테이너 또는 Sarus를 통해 샌드박스 환경에서 안전하게 처리된다.

멀티 에이전트 기반 자율적 지식 그래프 강화 (KARMA)

"KARMA: Leveraging Multi-Agent LLMs for Automated Knowledge Graph Enrichment" (2025) 논문은 펍메드(PubMed)와 같은 방대한 비정형 과학 문헌에서 높은 정밀도로 지식을 추출해 기존 지식 그래프를 자율적으로 확장하는 프레임워크를 다룬다. 이 방법론은 단일 모델의 환각 현상을 억제하기 위해 IngestionAgent, Entity discovery, Relation extraction, Conflict resolution 등 특화된 역할을 부여받은 9개의 멀티 에이전트 파이프라인을 구축하고, 에이전트 간 상호 교차 검증(Cross-agent verification)을 수행하도록 설계되었다. 구현 시 문헌 병합 단계에서 파이썬 정규표현식 및 파서 모듈을 사용하여 OCR 오류를 보정하고 특수 문자를 정규화한 뒤, 추출된 메타데이터(DOI, 저자 등)와 본문을 JSON 구조로 포맷팅하여 에이전트 간 통신에 사용한다. 전체 오케스트레이션 로직 및 프롬프트 템플릿은 깃허브 리포지토리(YuxingLu613/KARMA 및 Fraunhofer-SCAI-Applied-Semantics/KG-Orchestra)에 파이썬 기반 오픈소스로 구현되어 접근 가능하다.

에이전트 라우팅을 위한 그래프 모델링 (Agent-as-a-Graph)

대규모 멀티 에이전트 시스템에서 어떤 도구나 에이전트를 호출할지 결정하는 것은 성능과 직결된다. "Agent-as-a-Graph Knowledge Graph-Based Tool" (2024/2025) 논문은 수많은 도구(Tools)와 에이전트(Agents)의 메타데이터 관계를 이분 그래프(Bipartite Graph)로 모델링하는 방법론을 제안한다. 구현 단계에서는 모델 컨텍스트 프로토콜(MCP, Model Context Protocol) 카탈로그를 기반으로, 초기에는 벡터 검색(Vector Search, BM25 등)을 통해 관련 노드를 빠르게 찾는다. 이후 파이썬 기반 스크립트를 통해 타입별 가중치가 적용된 상호 순위 융합(wRRF, weighted Reciprocal Rank Fusion) 알고리즘을 연산하여 순위를 재조정(Reranking)하고, 부모 에이전트 노드로 그래프를 탐색(Traversal)하여 최종 도구를 결정한다.

연구 논문	핵심 방법론 (Methodology)	파이썬 라이브러리 및 구현 기술 (Implementation)
KGoT (2024/2025)	동적 그래프 생성 및 외부 도구 반복 통합	LangChain, NetworkX, Ollama, Playwright, Neo4j, Docker
KARMA (2025)	9개 전문 에이전트 간 교차 검증 및 지식 추출	메타데이터 추출 정규표현식, JSON 데이터 포맷팅, 멀티 에이전트 오케스트레이션
Agent-as-a-Graph (2024/2025)	도구/에이전트 이분 그래프 기반 라우팅	MCP 프로토콜 파싱, Vector Search 임베딩, wRRF 가중치 융합 스크립트

3. 단계별 검색 및 다중 홉 추론 메커니즘의 고도화

LLM이 o1 모델과 같이 고도의 체인형 사고를 전개할 때, 검색 메커니즘 역시 정적 주입에서 동적 탐색으로 진화해야 한다.

실제 응용 분야의 하이브리드 에이전트 RAG (Agentic RAG with KGs)

"Agentic RAG with Knowledge Graphs for Complex Multi-Hop Reasoning in Real-World Applications" (2025) 논문은 벡터 데이터베이스의 유사도 검색과 지식 그래프의 구조적 탐색을 결합한 INRAExplorer 아키텍처를 제시한다. 이 방법론은 복잡한 질의가 주어졌을 때, 에이전트가 자체적으로 SearchPublications (출판물 검색), SearchConceptsKeywords (개념 검색), SearchGraph (그래프 순회) 등의 다중 도구를 상황에 맞게 호출하며 다중 홉(Multi-hop) 추론을 수행하도록 설계되었다. 실제 시스템 구현을 위해 파이썬 생태계의 다양한 도구가 융합되었다. 에이전트 오케스트레이션과 도구 호출은 Mirascope 프레임워크가 담당하며, 비정형 학술 PDF 문서의 텍스트 파싱을 위해 GROBID가 사용된다. 추출된 지식의 벡터 임베딩은 Qdrant에, 구조화된 관계 데이터는 Neo4j에 저장되며, 오픈소스 deepseek-r1-0528 모델이 추론 엔진으로 구동된다.

동적 하위 그래프 검색을 통한 추론 단계 진화 (Graph-Augmented Reasoning)

"Graph-Augmented Reasoning: Evolving Step-by-Step Knowledge Graph Retrieval for LLM Reasoning" (2025) 논문은 LLM이 중간 단계 추론에서 흔히 겪는 환각 현상을 억제하기 위한 방법론을 제안한다. 이 접근법(KG-RAR)은 전통적 RAG처럼 처음 한 번만 지식을 주입하는 것이 아니라, LLM이 사고의 사슬(CoT)을 전개하는 각 스텝마다 그 맥락에 부합하는 서브그래프(Sub-KGs)를 지식 그래프로부터 동적으로 재검색하고 투입하여 추론의 깊이와 일관성을 스케일링한다. 구현 환경에서는 Llama-3B 및 Qwen과 같은 오픈소스 모델들이 평가되었으며, 강화학습(RLHF) 파인튜닝과 보상 모델링을 효율적으로 수행하기 위해 파이썬 기반의 OpenRLHF 생태계를 기반으로 모듈이 확장 구성되었다.

연구 논문	핵심 방법론 (Methodology)	파이썬 라이브러리 및 구현 기술 (Implementation)
Agentic RAG with KGs (2025)	에이전트 도구 동적 호출 기반 다중 홉 탐색	Mirascope, GROBID, Qdrant, Neo4j 및 API 라우팅 설계
Graph-Augmented Reasoning (2025)	스텝별 CoT 동기화 및 서브그래프 동적 검색	OpenRLHF 프레임워크 연동, 상태 추적 기반 다중 프롬프팅 제어

4. 자율적 스키마 유도 및 온톨로지 생성 기술의 도약

사전 정의된 스키마에 데이터를 끼워 맞추던 전통적 지식 엔지니어링의 병목을 해소하기 위해, 데이터로부터 직접 구조를 도출해내는 자율적 파이프라인이 산업적 주목을 받고 있다.

동적 스키마 유도를 통한 자율적 KG 구축 (AutoSchemaKG)

"AutoSchemaKG: Autonomous Knowledge Graph Construction through Dynamic Schema Induction from Web-Scale Corpora" (2025) 논문은 전문가의 개입 없이 방대한 웹 텍스트로부터 지식 그래프를 자율 구축하는 혁신적 방법론을 제시한다. 이 프레임워크는 엔티티와 이벤트를 추출하는 단계와, 이를 상위 개념으로 추상화(Conceptualization)하여 동적으로 스키마를 유도하는 단계로 구성된다. 특히 사물(Entity)뿐만 아니라 사건(Event)을 그래프의 1급 객체로 취급하여 인과관계와 절차적 지식을 포착하는 것이 특징이다. 구현 측면에서 파이썬 비중이 매우 높은 독자적인 atlas-rag 패키지를 개발하여 파이프라인을 구동한다. 텍스트 임베딩을 위해 transformers 라이브러리의 NV-embed-v2 모델을 사용하며, 트리플 생성 시 openai 인터페이스를 호출한다. 문서 전처리를 위해 pdf_process가, 그래프 생성을 위해 NetworkX와 Neo4j가 묶여 단일 주피터 노트북(Jupyter Notebook) 파이프라인 내에서 전체 작업이 실행되도록 구성되었다.

인간 참여형 온톨로지 그라운딩 에이전트 (SCHEMA-MINERpro)

과학 문헌과 같이 고도의 정밀성이 요구되는 도메인을 위해 "SCHEMA-MINERpro: Agentic AI for Ontology Grounding over LLM-Discovered Scientific Schemas in a Human-in-the-Loop Workflow" (2025) 논문은 인간 검증을 파이프라인에 통합한 방법론을 제안한다. 초기 스키마 마이닝, 소규모 코퍼스 기반의 정제, 대규모 코퍼스 검증, 그리고 최종적으로 표준 온톨로지(QUDT 등)에 시맨틱 그라운딩(Semantic Grounding)을 수행하는 4단계의 체계적인 워크플로우를 따른다. 이 과정에서 에이전트는 어휘적 휴리스틱과 다중 단계 추론을 결합하여 매핑 정확도를 높인다. 구현체인 schema-miner 파이썬 패키지는 LangChain 프레임워크 위에서 에이전트의 사고 흐름을 제어한다. 데이터 저장과 조작을 위해 파이썬 표준 라이브러리인 json과 파일 시스템 관리를 위한 pathlib이 광범위하게 쓰이며, API 통신은 OpenAI를 비롯해 로컬 모델 실행기인 Ollama와 HuggingFace 허브 생태계와 상호 호환되도록 작성되었다.

비정형 웹 문서의 마크업 자동 생성 (LLM4Schema.org)

"LLM4Schema.org: Generating Schema.org Markups with Large Language Models" (2024/2025) 논문은 SEO(검색엔진 최적화) 마크업이 결여된 웹 문서를 대상으로 LLM을 이용해 자율적으로 Schema.org 표준 마크업을 생성하고 유효성을 평가하는 방법론을 제시한다. 이는 정해진 정답셋(Ground Truth)이 없는 상태에서도 LLM이 인간 생성 마크업 수준의 데이터를 도출해낼 수 있는지를 테스트하는 프레임워크다. 구현을 위해 웹 페이지의 DOM 트리를 파싱하고 데이터를 수집하는 파이썬 크롤링 프레임워크 Scrapy와 Selenium 라이브러리가 도입되었다. 정보 추출 프롬프트 설계 시 파이썬 클래스 구조를 텍스트 형태로 모델에 전달하고, 추출된 정보가 해당 클래스의 객체(Object) 인스턴스로 변환되어 반환되게 하는 기법이 사용되었다.

연구 논문	핵심 방법론 (Methodology)	파이썬 라이브러리 및 구현 기술 (Implementation)
AutoSchemaKG (2025)	2단계 동적 스키마 개념화 및 이벤트 모델링	atlas-rag, transformers, openai, NetworkX, Neo4j
SCHEMA-MINERpro (2025)	Human-in-the-Loop 기반 4단계 온톨로지 매핑	schema-miner, LangChain, json, pathlib, Ollama
LLM4Schema.org (2024/2025)	웹 콘텐츠 정답셋 없는 마크업 자동 생성	Scrapy, Selenium, 파이썬 클래스 기반 JSON 매핑

5. 도메인 특화 온톨로지 엔지니어링 및 메타인지 제어

정형화된 지식의 정수라 할 수 있는 '온톨로지'를 생성할 때, 대형 언어 모델의 추론 절차를 온톨로지 엔지니어링 방법론으로 어떻게 규제할 것인지에 대한 연구가 활발히 진행되고 있다.

메타인지 프롬프팅과 분해 기법 (Ontology Generation)

"Ontology Generation using Large Language Models" (2025) 논문은 LLM이 복잡한 온톨로지를 단번에 생성할 때 발생하는 오류를 방지하기 위한 메타인지 프롬프팅(Metacognitive Prompting) 'Ontogenia' 방법론을 상세히 제안한다. 이 방법론은 모델에게 온톨로지 엔지니어라는 명확한 페르소나를 부여하고, 전체 요구사항을 서브태스크로 분해(Subtask-decomposed)하여 한 번에 하나의 역량 질의(CQ, Competency Question)만 평가하도록 제한하는 체인형 프롬프팅(CoT)의 진화형 모델이다. 실제 구현 과정에서 생성된 온톨로지는 논리적 모순이나 빈 출력(Empty output) 오류를 확인하기 위해 파이썬 생태계와 연동된 OOPS!(Ontology Pitfall Scanner) 도구에 전송되며, 이를 통해 자동 피드백 루프를 형성하여 온톨로지 구조를 다듬어 나간다.

생명과학 분야 온톨로지 학습 파이프라인 (LLMs4Life)

특수 전문 지식이 집약된 생명과학 도메인을 타겟으로 한 "LLMs4Life: Large Language Models for Ontology Learning in Life Sciences" (2024) 논문은 기존의 복잡한 온톨로지 설계 표준인 NeOn 방법론을 프롬프트 파이프라인에 이식하는 방법론을 설계했다. 단순히 자연어를 Turtle 신택스로 변환하는 것을 넘어, 전문가의 컨텍스트 리치(Context-rich) 피드백이 모델 성능에 미치는 영향을 정량적으로 분석한다. 이 연구는 Python 3 환경에서 PyTorch 프레임워크를 기반으로 NeOn-GPT라는 파이프라인 코드를 작성하였다. 텍스트 처리와 추론 엔진 인터페이스를 통합한 해당 워크플로우 코드는 연구 재현을 위해 깃허브 리포지토리(andreamust/NEON-GPT)에 공개되었다.

특화 언어 모델을 통한 온톨로지 생성 방법론 탐구

"Methodological Exploration of Ontology Generation with a Dedicated Large Language Model" (2025) 논문은 자율주행차 인터페이스와 같이 고도로 제약된 산업 도메인의 온톨로지를 특화된 언어 모델을 이용해 자동으로 생성하기 위한 접근법을 다룬다. 이 방법론은 범용 LLM 대신 파인튜닝된 전용 언어 모델이 어떻게 더 엄격한 클래스 계층과 제약 조건을 학습하고 배출할 수 있는지를 탐구한다.

구현 관점에서는 파이썬 환경의 커스텀 모델 파인튜닝 스크립트와 검증 데이터셋 파싱 코드를 바탕으로, 생성된 온톨로지의 구문적 정확성과 구조적 일관성을 평가하는 검증 파이프라인을 운영한다.

연구 논문	핵심 방법론 (Methodology)	파이썬 라이브러리 및 구현 기술 (Implementation)
Ontology Generation (Lippolis, 2025)	Ontogenia 메타인지 프롬프팅 및 CQ 기반 태스크 분해	OOPS! API 통신 연동, 단계별 프롬프트 제어 스크립트
LLMs4Life (2024)	NeOn 방법론의 프롬프트 파이프라인 이식	Python 3, PyTorch, 깃허브 NeOn-GPT 파이프라인 구현
Methodological Exploration (2025)	특정 도메인 전용 모델을 통한 제약적 파인튜닝	모델 파인튜닝 스크립트 및 구문 평가 검증기

6. 온톨로지 그라운딩 기반의 응용 시스템 설계

생성된 온톨로지를 실제 산업용 RAG 시스템이나 시스템 엔지니어링 모델링 워크플로우에 접목하여 실질적인 추론 능력을 배가시키는 방법론들이 존재한다.

비정형 기술 문서의 자율적 온톨로지 도출 RAG (OntoRAG)

전기 릴레이와 같은 산업용 기술 매뉴얼의 비정형 문서에서 온톨로지를 자율적으로 도출하여 RAG 성능을 향상시키는 파이프라인이 "OntoRAG: Enhancing Question-Answering through Automated Ontology Derivation from Unstructured Knowledge Bases" (2025) 논문에 제안되었다. 이 방법론은 일반적인 길이 기반 청킹 대신 문서의 제목(Title)과 논리적 의미 단위를 결합한 하이브리드 청킹(Hybrid Chunking), 그리고 문장 간 임베딩의 코사인 유사도를 연산하여 인접 청크를 병합하는 시맨틱 청킹(Semantic Chunking) 기법을 사용한다. 이를 파이썬 코드로 구현하기 위해, PDF 문서 내의 레이아웃 요소를 식별하는 unstructured 라이브러리와 광학 문자 인식(OCR)을 위한 pytesseract가 도입되었다. 추출된 키 요소(이름, 정의 임베딩)들은 파이썬 scikit-learn 라이브러리의 K-means 기반 알고리즘을 통해 클러스터링되어 온톨로지 클래스를 형성하며, 커뮤니티 구조 분석에는 graspologic 네트워크 라이브러리가 활용된다.

지식 하이퍼그래프 결합 RAG (Ontology-grounded RAG)

"Ontology-grounded retrieval-augmented generation" (2024/2025) 연구는 단순한 노드-엣지 연결을 넘어 다중 관계를 표현할 수 있는 지식 하이퍼그래프(Knowledge Hypergraph)와 도메인 온톨로지를 결합하는 구조적 방법론을 제시한다. 이 모델(OG-RAG)은 문서 내 사실적 지식을 하이퍼엣지(Hyperedge) 클러스터로 캡슐화하고, 질의에 응답할 때 최적화 알고리즘을 통해 가장 의미 있는 최소한의 하이퍼엣지 집합을 검색해내는 메커니즘을 작동시킨다. 이 방법론은 한계가 명확한 기존 벡터 기반 검색을 대체하기 위해 파이썬 기반 오픈소스 라이브러리인 MIRAGE 환경 내에서 실험 환경을 구축하고, 다양한 모델의 컨텍스트 창 내 정보 보존율과 환각 검출력을 평가하는 방식을 채택했다.

도메인 온톨로지 기반의 LLM 보조 그래프 쿼리 생성 (OB-GRAG)

"OB-GRAG: LLM Assisted Graph Creation and Querying via Domain Specific Ontology" (2024/2025) 논문은 특정 도메인의 온톨로지를 사전에 모델에 주입하여 LLM이 그래프 데이터베이스와 직접 상호작용하는 방법론을 설계했다. 프레임워크는 자연어 질의가 입력되면 온톨로지 구조를 참조하여 문법적으로 유효한 Cypher 쿼리로 변환하고, 이를 그래프 DB에서 실행한 결과를 바탕으로 최종 답변을 합성한다.

구현 파이프라인에서는 파이썬 환경의 Neo4j 공식 드라이버와 LangChain의 그래프 쿼리 체인을 결합하여 LLM API와 데이터베이스 통신 모듈 사이의 미들웨어 역할을 수행하도록 구성된다.

시스템 엔지니어링을 위한 온톨로지 기반 프롬프팅 (Ontology-Driven LLM Assistance)

"Ontology-Driven LLM Assistance for Task-Oriented Systems" (2025) 논문은 모델 기반 시스템 엔지니어링(MBSE, Model-Based Systems Engineering) 환경에서 요구사항 문서로부터 시스템 구성 요소를 도출하는 방법론을 제안한다. LLM 프롬프트 생성 시 설계자가 사전에 정의한 텍스트 대 시스템 모델 온톨로지(요구사항, 기능, 모드, 구성 요소)를 강제 주입하여 출력의 포맷을 표준화한다. 이를 처리하기 위해 시스템에서 텍스트로 추출된 각 요소를 MBSE 모델 타입(예: SysML 블록)으로 변환하고 맵핑하는 NALMAGE와 같은 전용 파이썬 스크립트 패키지가 미들웨어로 작동하여 설계 자동화 툴과 인터페이스를 구성한다.

연구 논문	핵심 방법론 (Methodology)	파이썬 라이브러리 및 구현 기술 (Implementation)
OntoRAG (2025)	하이브리드 청킹, 임베딩 클러스터링을 통한 자동 온톨로지화	unstructured, pytesseract, scikit-learn, graspologic
Ontology-grounded RAG (2024/2025)	지식 하이퍼그래프 캡슐화 및 최소 엣지 최적화 검색	파이썬 오픈소스 라이브러리 MIRAGE 활용 아키텍처
Ontology-Driven LLM Assistance (2025)	텍스트 요구사항의 MBSE 모델 기반 매핑 프롬프팅	텍스트와 모델 타입 변환용 커스텀 파이썬 패키지 (NALMAGE) 연동

7. 지식의 추출 구조화 및 이기종 간 정렬 기술

지식 그래프를 구성하는 가장 말단 단위인 트리플(주어-동사-목적어) 구조를 얼마나 효과적으로 추출하고, 서로 다른 그래프 간의 이질적 노드를 어떻게 정렬할 것인가에 대한 연구는 데이터 품질을 결정하는 핵심이다.

제로샷 및 퓨샷 추론을 활용한 트리플 추출 (Zero- and Few-Shots KG Triplet Extraction)

"Zero- and Few-Shots Knowledge Graph Triplet Extraction with Large Language Models" (2024) 논문은 모델 파인튜닝 없이 프롬프팅만으로 문장 내 엔티티와 관계를 지식 그래프의 기초 단위인 트리플(Triplet) 구조로 안정적으로 추출하는 방법론을 분석한다. LLM에 전체 문장을 통째로 주입할 경우 발생하는 인지 부하와 환각을 줄이기 위해, 기반 지식 베이스(KB) 유무에 따른 성능을 교차 평가한다. 구현 환경에서는 파이프라인의 효율성을 높이기 위해, LLM에 데이터를 전송하기 전 파이썬의 대표적인 자연어 처리 라이브러리인 spaCy (특히 en-core-web- 모델)를 구동하여 명명된 개체 인식(NER)을 먼저 수행한다. 또한, 대화형 텍스트 기반 시나리오 생성을 위해 TextWorld 파이썬 라이브러리가 백엔드의 상태 추적용 도구로 통합되었다.

LLM을 활용한 지식 그래프 간 엔티티 정렬 (LLM-Align)

"LLM-Align: Utilizing Large Language Models for Entity Alignment in Knowledge Graphs" (2024) 연구는 서로 다른 지식 그래프 내의 이기종 엔티티들이 동일한 대상을 지칭하는지 병합, 판단(Entity Alignment)하기 위한 방법론이다. LLM-Align은 RAGAT 등 기존 모델을 이용해 1차 후보군을 추출한 후, 엔티티의 중요 속성과 관계를 식별하는 휴리스틱(Heuristic) 기반 규칙을 적용한다. 위치 편향(Positional bias)이나 환각을 제어하기 위해 여러 번 평가를 거치는 다중 라운드 투표(Multi-round voting) 매커니즘을 핵심 방법론으로 둔다. 가장 돋보이는 파이썬 기반 구현 기법은, 각기 다른 스키마 형식을 가진 여러 지식 데이터베이스의 출력을 통합하기 위해 데이터를 파이썬 클래스(Python classes) 형태로 균일하게 변환(Transform)한 후 프롬프팅을 진행한다는 점이다. 이 과정을 처리하는 함수와 매핑 로직은 순수 파이썬 스크립트로 구축되었다.

연구 논문	핵심 방법론 (Methodology)	파이썬 라이브러리 및 구현 기술 (Implementation)
Zero- and Few-Shots KG Triplet Extraction (2024)	지식 베이스 기반 제로/퓨샷 트리플 추출 평가	spaCy NER 전처리 모델 (en-core-web-), TextWorld 연동
LLM-Align (2024)	휴리스틱 후보군 필터링 및 다중 라운드 투표	이기종 스키마의 파이썬 클래스 인스턴스화 및 매핑 스크립트

8. 시간적 지식 그래프, 데이터 구조 벤치마킹과 최적화

지식 시스템이 장기적으로 구동되기 위해서는 시간에 따른 상태 변화를 저장하는 메모리 구조, 성능을 평가하는 벤치마크, 그리고 최적의 데이터베이스 모델링 스펙이 필수적이다.

에이전트 메모리를 위한 시간적 지식 그래프 (Zep)

AI 에이전트의 대화가 누적될수록, 과거에 참이었던 사실이 현재는 거짓이 되는 상황(예: 거주지 변경)이 발생한다. "Zep: A Temporal Knowledge Graph Architecture for Agent Memory" (2024/2025) 논문은 이러한 한계를 극복하기 위해 시간적 지식 그래프(Temporal Knowledge Graph)를 에이전트 메모리로 사용하는 방법론을 제안한다. 에이전트의 대화를 에피소드(Episodes) 단위로 분석하고, 엔티티와 사실을 추출한 뒤 시간에 따른 사실의 유효성 소멸(Edge Invalidation)을 관리하며, 관련 정보들을 커뮤니티로 클러스터링한다. 구현 아키텍처는 Zep의 코어 오픈소스 엔진인 Graphiti를 기반으로 구동되며, 깃허브 리포지토리(getzep/graphiti)에 공개되어 있다. 데이터 탐색은 코사인 의미론적 유사도(Cosine Semantic Similarity), Okapi BM25 텍스트 기반 검색, 넓이 우선 탐색(BFS) 방식을 결합한 하이브리드 리트리버 로직으로 구성된다. 이 파이썬 워크플로우는 내부적으로 Neo4j의 Lucene 인덱스 기능을 호출하여 수 밀리초 내에 응답하는 구조를 띤다.

텍스트화된 지식 그래프를 위한 LLM 벤치마크 (KG-LLM-Bench)

"KG-LLM-Bench: A Scalable Benchmark for Evaluating LLM Reasoning on Textualized Knowledge Graphs" (2024/2025) 논문은 복잡한 하이퍼그래프 형태의 지식을 LLM이 입력으로 받아들일 수 있는 1차원 선형 텍스트로 변환(Textualization)할 때, 어떤 전략이 가장 우수한 추론 성능을 담보하는지 5가지 인코딩 관점에서 분석하는 방법론을 다룬다. 실제 벤치마킹을 위해 연구진은 파이썬과 Jupyter Notebook 환경을 바탕으로 모듈화된 파이프라인 소프트웨어를 개발했다. 이를 통해 연구자는 Llama, Qwen, GPT 등 여러 로컬 및 클라우드 모델을 교체해가며 추론력을 쉽게 평가할 수 있다. 소스 코드는 깃허브 리포지토리(uclnlp/cqd 및 Elanmarkowitz/kg-llm-bench)에 공개되어 오픈 리서치를 지원한다.

스마트 홈의 연결형 데이터 관리를 위한 RDF와 LPG의 비교

지식 그래프를 구성하는 기저 데이터베이스의 논리적 구조는 탐색 효율성을 좌우한다. "Linked Data for Smart Homes: Comparing RDF and Labeled Property Graphs" (2020) 연구는 사물 인터넷(IoT) 환경을 위한 트리플 모델인 RDF(Resource Description Framework) 스토어와 속성 그래프(LPG, Labeled Property Graph) 모델을 정성적, 정량적으로 비교 분석하는 방법론을 다룬다. RDF는 글로벌 상호운용성(HTTP URI, 온톨로지 호환성 등)에서 매우 유리하지만, 데이터 구조가 원자적(Atomic)이어서 다중 도메인 질의 시 노드 수가 폭발적으로 증가해 복잡한 탐색에서 심각한 병목을 일으킨다. 반면 LPG(예: Neo4j)는 엣지와 노드 객체 자체에 직접 프로퍼티(Property)를 속성으로 기입할 수 있어 다중 홉 탐색 시 복잡성이 훨씬 적고 응답 속도가 빠르다. 구현 관점에서는 Restlet 프레임워크를 기반으로 스마트 홈 데이터를 수집한 후, Neo4j의 NSMTX RDF Import 플러그인을 파이썬 파이프라인에서 호출하여 RDF 그래프 구조를 LPG 환경으로 강제 변환, 임포트(Import)하고 질의 실행 속도를 벤치마킹한다.

연구 논문	핵심 방법론 (Methodology)	파이썬 라이브러리 및 구현 기술 (Implementation)
Zep (Temporal KG) (2024/2025)	에피소드 클러스터링 및 엣지 유효성(Edge Invalidation) 추적	Graphiti 오픈소스, Neo4j Lucene 통합, Cosine/BM25/BFS 하이브리드 검색 구현
KG-LLM-Bench (2024/2025)	그래프 텍스트화 인코딩 방식 비교 및 추론 평가 확장	Jupyter Notebook 기반 일괄 평가 파이프라인 (깃허브 공개)
Linked Data for Smart Homes (2020)	RDF 원자성과 LPG 속성 저장 구조의 쿼리 복잡도 벤치마킹	Restlet 연동, Neo4j NSMTX 플러그인 기반 RDF-LPG 변환 스크립트

결론 및 기술적 파급 효과

본 보고서에서 분석한 24편의 학술 문헌들은, 대규모 언어 모델이 어떻게 구조화되지 않은 텍스트 환경에서 벗어나 정교하게 오케스트레이션된 지식 처리 엔진(Cognitive Engine)으로 도약하고 있는지를 극명하게 보여준다. 분석된 문헌들을 종합할 때, 지식 시스템 설계의 패러다임은 다음과 같이 구조적인 변화를 겪고 있다.

첫째, 지식 엔지니어링의 병목이 톱다운(Top-down) 방식에서 바텀업(Bottom-up) 형태의 자율화로 역전되었다. 과거 도메인 전문가들이 엄격한 온톨로지를 설계한 후 데이터를 적재해야만 가능했던 지식 그래프 구축 작업이 이제는 AutoSchemaKG나 SCHEMA-MINERpro 등에서 입증되듯, LLM이 문헌을 읽고 동적으로 개념을 추상화하여 스스로 스키마를 유도(Dynamic Schema Induction)하는 자율적 프로세스로 전환되었다. 이 과정에서 메타인지 프롬프팅 기법들이 인간의 전문가적 사고 구조를 훌륭히 모사하며 오답을 제어하고 있다.

둘째, 단순 유사도 검색에 의존하던 전통적 RAG 시스템이 에이전트 기반의 다중 홉 탐색 구조(Agentic RAG)로 전면 고도화되었다. KGoT 아키텍처나 INRAExplorer 등의 시스템은 LLM을 단순한 응답 생성기가 아닌, 필요한 시점에 파이썬 코드를 실행하거나 Neo4j 그래프 데이터베이스에 Cypher 쿼리를 던져 스스로 지식의 빈틈을 채우는 주체적인 판단자로 기능하게 만든다. 에이전트들이 도구를 다루는 양태 자체가 그래프화(Agent-as-a-graph)됨으로써 복잡한 워크플로우 제어가 가능해졌다.

셋째, 시계열적 맥락을 흡수하는 메모리 인프라의 도입으로 인해 상호작용의 연속성이 극대화되었다. Zep과 같은 시간적 지식 그래프(Temporal KG) 구조의 출현은, 그래프 노드가 영구 불변의 사실이 아니라 사용자와의 교류 및 에피소드 진행에 따라 무효화되거나 갱신될 수 있는 유동적 상태 변수로 취급될 수 있음을 보여준다. 이는 AI 에이전트가 단기적 과제 수행을 넘어, 지속적 학습(Continual Learning)과 장기 기억력(Long-term memory)을 필요로 하는 광범위한 상호작용 시나리오에서 중심 역할을 수행하게 될 기반을 제공한다.

궁극적으로 이러한 이론적 도약들이 현실 세계의 소프트웨어 시스템으로 안착할 수 있었던 이면에는, LangChain, Mirascope, NetworkX, 그리고 HuggingFace 생태계로 대변되는 파이썬 중심의 오픈소스 파이프라인 생태계가 강력한 미들웨어 역할을 수행했기 때문이다. 향후 지능형 추론 시스템 설계자들은 단일 언어 모델의 파라미터 경쟁보다는, 이러한 지식 구조의 동적 유도와 멀티 에이전트 라우팅 최적화, 그리고 다양한 데이터 스토어(LPG, Vector DB) 간의 하이브리드 파이프라인 설계에 자원과 역량을 집중해야 할 것이다.

참고 자료

A Survey of Graph Retrieval-Augmented Generation for Customized Large Language Models - arXiv.org, 3월 13, 2026에 액세스, https://arxiv.org/html/2501.13958v1
Graph-Augmented Reasoning: Evolving Step-by-Step Knowledge Graph Retrieval for LLM Reasoning - arXiv, 3월 13, 2026에 액세스, https://arxiv.org/pdf/2503.01642
Agentic RAG with Knowledge Graphs for Complex Multi-Hop Reasoning in Real-World Applications - arXiv.org, 3월 13, 2026에 액세스, https://arxiv.org/html/2507.16507v1
From Local to Global: A Graph RAG Approach to Query-Focused Summarization - arXiv.org, 3월 13, 2026에 액세스, https://arxiv.org/abs/2404.16130
From Local to Global: A GraphRAG Approach to Query-Focused Summarization - arXiv, 3월 13, 2026에 액세스, https://arxiv.org/html/2404.16130v2
From Local to Global: A Graph RAG Approach to Query-Focused Summarization - jsDelivr, 3월 13, 2026에 액세스, https://cdn.jsdelivr.net/gh/yanfeng98/paper-is-all-you-need/papers/00046-GraphRAG.pdf
[PDF] Graph Retrieval-Augmented Generation: A Survey | Semantic Scholar, 3월 13, 2026에 액세스, https://www.semanticscholar.org/paper/Graph-Retrieval-Augmented-Generation%3A-A-Survey-Peng-Zhu/9ab45aa875b56335303398e84a59a3756cd9d530
(PDF) A Survey of Graph Retrieval-Augmented Generation for Customized Large Language Models - ResearchGate, 3월 13, 2026에 액세스, https://www.researchgate.net/publication/388401799_A_Survey_of_Graph_Retrieval-Augmented_Generation_for_Customized_Large_Language_Models
A Survey of Graph Retrieval-Augmented Generation for Customized Large Language Models - OpenReview, 3월 13, 2026에 액세스, https://openreview.net/pdf?id=9FJiOMuZkr
[2501.13958] A Survey of Graph Retrieval-Augmented Generation for Customized Large Language Models - arXiv.org, 3월 13, 2026에 액세스, https://arxiv.org/abs/2501.13958
(PDF) Graph-Based Agentic Retrieval-Augmented Generation: A Comprehensive Survey, 3월 13, 2026에 액세스, https://www.researchgate.net/publication/396209481_Graph-Based_Agentic_Retrieval-Augmented_Generation_A_Comprehensive_Survey
spcl/knowledge-graph-of-thoughts: Official Implementation ... - GitHub, 3월 13, 2026에 액세스, https://github.com/spcl/knowledge-graph-of-thoughts
Affordable AI Assistants with Knowledge Graph of Thoughts | by Ema Ilic | Medium, 3월 13, 2026에 액세스, https://medium.com/@ema.ilic9/affordable-ai-assistants-with-knowledge-graph-of-thoughts-1f3783e6482f
Affordable AI Assistants with Knowledge Graph of Thoughts - arXiv, 3월 13, 2026에 액세스, https://arxiv.org/html/2504.02670v6
AI-Powered Paper Summarization about the arXiv paper 2502.06472v1, 3월 13, 2026에 액세스, https://www.summarizepaper.com/en/arxiv-id/2502.06472v1/
KARMA: Leveraging Multi-Agent LLMs for Automated Knowledge Graph Enrichment, 3월 13, 2026에 액세스, https://arxiv.org/html/2502.06472v1
KARMA: Leveraging Multi-Agent LLMs for Automated Knowledge Graph Enrichment - arXiv, 3월 13, 2026에 액세스, https://arxiv.org/pdf/2502.06472
(PDF) KARMA: Leveraging Multi-Agent LLMs for Automated Knowledge Graph Enrichment, 3월 13, 2026에 액세스, https://www.researchgate.net/publication/388884012_KARMA_Leveraging_Multi-Agent_LLMs_for_Automated_Knowledge_Graph_Enrichment
KG-Orchestra: An Open-Source Multi-Agent Framework for Evidence-Based Biomedical Knowledge Graphs Enrichment | bioRxiv, 3월 13, 2026에 액세스, https://www.biorxiv.org/content/10.64898/2026.02.18.706536v1.full-text
Knowledge Graph-Based Tool and Agent Retrieval for LLM Multi-Agent Systems - arXiv.org, 3월 13, 2026에 액세스, https://www.arxiv.org/pdf/2511.18194
Tool and Agent Selection for Large Language Model Agents in Production: A Survey, 3월 13, 2026에 액세스, https://www.preprints.org/manuscript/202512.1050/v1
HybridRAG: Integrating Knowledge Graphs and Vector Retrieval Augmented Generation for Efficient Information Extraction | Request PDF - ResearchGate, 3월 13, 2026에 액세스, https://www.researchgate.net/publication/385821579_HybridRAG_Integrating_Knowledge_Graphs_and_Vector_Retrieval_Augmented_Generation_for_Efficient_Information_Extraction
Agentic RAG with Knowledge Graphs for Complex Multi-Hop Reasoning in Real-World Applications - ResearchGate, 3월 13, 2026에 액세스, https://www.researchgate.net/publication/393923781_Agentic_RAG_with_Knowledge_Graphs_for_Complex_Multi-Hop_Reasoning_in_Real-World_Applications
Evolving Step-by-Step Knowledge Graph Retrieval for LLM Reasoning - arXiv.org, 3월 13, 2026에 액세스, https://arxiv.org/html/2503.01642v1
UProp: Investigating the Uncertainty Propagation of LLMs in Multi-Step Agentic Decision-Making - arXiv.org, 3월 13, 2026에 액세스, https://arxiv.org/html/2506.17419v1
A Survey of Long Chain-of-Thought for Reasoning Large Language Models - arXiv, 3월 13, 2026에 액세스, https://arxiv.org/html/2503.09567v4
HKUST-KnowComp/AutoSchemaKG: This repository ... - GitHub, 3월 13, 2026에 액세스, https://github.com/HKUST-KnowComp/AutoSchemaKG
AutoSchemaKG Paper and Code Release - Jiaxin Bai, 3월 13, 2026에 액세스, https://bjx.fun/p/autoschemakg-paper-and-code-release/
sciknoworg/schema-miner: A Human-in-the-Loop Workflow ... - GitHub, 3월 13, 2026에 액세스, https://github.com/sciknoworg/schema-miner
Evaluation of LLM-Based Strategies for the Extraction of Food Product Information from Online Shops - SciTePress, 3월 13, 2026에 액세스, https://www.scitepress.org/Papers/2025/136473/136473.pdf
Testing the Feasibility of Schema.org Metadata Refinement Through the Use of a Large Language Model | Request PDF - ResearchGate, 3월 13, 2026에 액세스, https://www.researchgate.net/publication/383487144_Testing_the_Feasibility_of_Schemaorg_Metadata_Refinement_Through_the_Use_of_a_Large_Language_Model
arXiv:2503.05388v1 [cs.AI] 7 Mar 2025, 3월 13, 2026에 액세스, https://arxiv.org/pdf/2503.05388
LLM-empowered knowledge graph construction: A survey - arXiv.org, 3월 13, 2026에 액세스, https://arxiv.org/html/2510.20345v1
Ontology Generation Using Large Language Models | Request PDF - ResearchGate, 3월 13, 2026에 액세스, https://www.researchgate.net/publication/392242831_Ontology_Generation_Using_Large_Language_Models
Knowledge Engineering with Large Language Models: A Capability Assessment in Ontology Evaluation | Semantic Web Journal, 3월 13, 2026에 액세스, https://www.semantic-web-journal.net/system/files/swj3852.pdf
(PDF) LLMs4Life: Large Language Models for Ontology Learning in Life Sciences, 3월 13, 2026에 액세스, https://www.researchgate.net/publication/386419108_LLMs4Life_Large_Language_Models_for_Ontology_Learning_in_Life_Sciences
Leveraging Large Language Models for Generating Research Topic Ontologies: A Multi-Disciplinary Study - arXiv, 3월 13, 2026에 액세스, https://arxiv.org/html/2508.20693v1
Retrieval-Augmented Generation of Ontologies from Relational Databases - ResearchGate, 3월 13, 2026에 액세스, https://www.researchgate.net/publication/392334429_Retrieval-Augmented_Generation_of_Ontologies_from_Relational_Databases
Publications | Institute for Artificial Intelligence | University of Stuttgart, 3월 13, 2026에 액세스, https://www.ki.uni-stuttgart.de/departments/ac/research/publications/
[2506.00664] OntoRAG: Enhancing Question-Answering through Automated Ontology Derivation from Unstructured Knowledge Bases - arXiv.org, 3월 13, 2026에 액세스, https://arxiv.org/abs/2506.00664
OntoRAG: Enhancing Question-Answering through Automated Ontology Derivation from Unstructured Knowledge Bases - arXiv.org, 3월 13, 2026에 액세스, https://arxiv.org/pdf/2506.00664
OntoRAG: Enhancing Question-Answering through Automated Ontology Derivation from Unstructured Knowledge Bases - arXiv, 3월 13, 2026에 액세스, https://arxiv.org/html/2506.00664v1
(PDF) OntoRAG: Enhancing Question-Answering through Automated Ontology Derivation from Unstructured Knowledge Bases - ResearchGate, 3월 13, 2026에 액세스, https://www.researchgate.net/publication/392334005_OntoRAG_Enhancing_Question-Answering_through_Automated_Ontology_Derivation_from_Unstructured_Knowledge_Bases
Research Conference Spotlight - Georgia Institute of Technology, 3월 13, 2026에 액세스, https://sites.gatech.edu/research/spotlight/
LinearRAG: Linear Graph Retrieval Augmented Generation on Large-scale Corpora - arXiv.org, 3월 13, 2026에 액세스, https://arxiv.org/html/2510.10114v1
Paper Digest: CIKM 2025 Papers & Highlights, 3월 13, 2026에 액세스, https://www.paperdigest.org/2025/11/cikm-2025-papers-highlights/
SCIENCE AND TECHNOLOGY PUBLICATIONS - SciTePress, 3월 13, 2026에 액세스, https://www.scitepress.org/Papers/2025/
Ontology used for generated MBSE model elements. - ResearchGate, 3월 13, 2026에 액세스, https://www.researchgate.net/figure/Ontology-used-for-generated-MBSE-model-elements_fig3_388476324
Proceedings of the 13th International Conference on Model-Based Software and Systems Engineering, MODELSWARD 2025, Porto, Portugal, February 26-28, 2025 - Researchr, 3월 13, 2026에 액세스, https://researchr.org/publication/modelsward-2025
WESE: weak exploration to strong exploitation for LLM agents - ResearchGate, 3월 13, 2026에 액세스, https://www.researchgate.net/publication/400303273_WESE_weak_exploration_to_strong_exploitation_for_LLM_agents
Proceedings of the 1st Workshop on Knowledge Graphs and Large Language Models (KaLLM 2024) - ACL Anthology, 3월 13, 2026에 액세스, https://aclanthology.org/2024.kallm-1.pdf
IS2024 - SIKDD 2024 Paper 15 | PDF | Artificial Intelligence - Scribd, 3월 13, 2026에 액세스, https://www.scribd.com/document/909399369/IS2024-SIKDD-2024-paper-15
AutoAlign: Fully Automatic and Effective Knowledge Graph Alignment Enabled by Large Language Models | Request PDF - ResearchGate, 3월 13, 2026에 액세스, https://www.researchgate.net/publication/374864668_AutoAlign_Fully_Automatic_and_Effective_Knowledge_Graph_Alignment_Enabled_by_Large_Language_Models
Unlocking the Power of Large Language Models for Entity Alignment - ResearchGate, 3월 13, 2026에 액세스, https://www.researchgate.net/publication/384208316_Unlocking_the_Power_of_Large_Language_Models_for_Entity_Alignment
[PDF] Unlocking the Power of Large Language Models for Entity, 3월 13, 2026에 액세스, https://www.semanticscholar.org/paper/Unlocking-the-Power-of-Large-Language-Models-for-Jiang-Shen/a35c3321c48ff496bb6ef085829f2d488973a72e
Daily Papers - Hugging Face, 3월 13, 2026에 액세스, https://huggingface.co/papers?q=Entity-Relation%20Matching
[PDF] Zep: A Temporal Knowledge Graph Architecture for Agent Memory | Semantic Scholar, 3월 13, 2026에 액세스, https://www.semanticscholar.org/paper/Zep%3A-A-Temporal-Knowledge-Graph-Architecture-for-Rasmussen-Paliychuk/12407be490a4e4633da7f25a93af000be573a288
Rylan Talerico on Zep: A Temporal Knowledge Graph Architecture for Agent Memory [PWL NYC] | Papers We Love, 3월 13, 2026에 액세스, https://paperswelove.org/videos/rylan-talerico-on-zep-a-temporal-knowledge-graph-architecture-for-agent-memory-p/
Zep: A Temporal Knowledge Graph Architecture for Agent Memory - arXiv, 3월 13, 2026에 액세스, https://arxiv.org/html/2501.13956v1
GitHub - getzep/graphiti: Build Real-Time Knowledge Graphs for AI Agents, 3월 13, 2026에 액세스, https://github.com/getzep/graphiti
Knowledge Graphs in Agent Memory.md - GitHub, 3월 13, 2026에 액세스, https://github.com/heathersherry/Knowledge-Graph-Tutorials-and-Papers/blob/master/topics/Knowledge%20Graphs%20in%20Agent%20Memory.md
KG-LLM-Bench: A Scalable Benchmark for Evaluating LLM Reasoning on Textualized Knowledge Graphs | Request PDF - ResearchGate, 3월 13, 2026에 액세스, https://www.researchgate.net/publication/390639562_KG-LLM-Bench_A_Scalable_Benchmark_for_Evaluating_LLM_Reasoning_on_Textualized_Knowledge_Graphs
Krupa Galiya krupagaliya - GitHub, 3월 13, 2026에 액세스, https://github.com/krupagaliya
KG-LLM-Bench: A Scalable Benchmark for Evaluating LLM Reasoning on Textualized Knowledge Graphs - arXiv.org, 3월 13, 2026에 액세스, https://arxiv.org/html/2504.07087v1
Linked data for smart homes: comparing RDF and labeled property graphs, 3월 13, 2026에 액세스, https://www.semanticscholar.org/paper/Linked-data-for-smart-homes%3A-comparing-RDF-and-Donkers-Yang/652d03a3da1e188134d19b8386481801fe2a0ab5
Linked Data for Smart Homes: Comparing RDF and Labeled Property Graphs - CEUR-WS.org, 3월 13, 2026에 액세스, https://ceur-ws.org/Vol-2636/02paper.pdf

Linked Data for Smart Homes: Comparing RDF and Labeled Property Graphs, 3월 13, 2026에 액세스, https://www.researchgate.net/publication/342956606_Linked_Data_for_Smart_Homes_Comparing_RDF_and_Labeled_Property_Graphs

- 전체적인 스킴을 위해서 Deep Research를 활용했는데, 관심있는 논문들부터 하나씩 정리할 예정

[논문 리뷰] Linked Data for Smart Homes: Comparing RDF and Labeled Property Graphs

송채채 — Fri, 13 Mar 2026 14:06:03 +0900

Donkers, Alex & Yang, Dujuan & Baken, Nico. (2020). Linked Data for Smart Homes: Comparing RDF and Labeled Property Graphs.

https://linkedbuildingdata.net/ldac2020/files/papers/02paper.pdf

본 논문은 시맨틱 웹 표준인 RDF(Resource Description Framework)와 성능 중심의 LPG(Labeled Property Graphs)를 실증적으로 비교하여 각 모델의 적합성을 분석함.

1. 연구 배경 및 목적: 데이터 사일로 해결

스마트홈 환경은 건물 정보, IoT 센서, 사용자 활동 데이터가 각기 다른 시스템에 분산된 '데이터 사일로' 현상이 심각함. 이를 해결하기 위해 그래프 기반의 데이터 모델링이 필수적임. 본 연구는 Open Smart Home Dataset을 활용하여 주방(Kitchen) 사례를 RDF와 LPG로 각각 구현하고 정성·정량적 차이를 검증함.

Note: 단순히 데이터를 저장하는 것을 넘어, 서로 다른 도메인의 데이터를 '연결'한다는 점에서 그래프 모델의 선택은 스마트홈 서비스의 확장성을 결정짓는 매우 중요한 설계 요소라고 생각함.

2. 데이터 모델링 및 구조적 차이

연구에서는 동일한 데이터를 두 가지 방식으로 모델링함.

RDF: 모든 정보를 Subject-Predicate-Object의 트리플(Triple) 구조로 원자화함. 시맨틱 웹 표준을 따르며 온톨로지(RDFS, OWL)를 통해 데이터의 의미를 정의함.
LPG: 노드와 관계(Edge)에 직접 속성(Property)을 부여함. RDF보다 구조가 컴팩트하며 직관적임.

구분	RDF	LPG
데이터 단위	트리플 (Atomic)	노드, 관계, 속성 (Compact)
스키마	온톨로지 기반 (정형화)	스키마리스 (유연함)
질의 언어	SPARQL	Cypher

Note: RDF는 데이터 모델이 엄격하지만, LPG는 관계 자체에 '속성'을 넣을 수 있어 모델링 자유도가 높음

3. 정량적 성능 비교 결과

실제 주방 데이터셋을 적용한 결과, 데이터의 부피와 처리 속도에서 뚜렷한 차이를 보임.

저장 공간: RDF 모델은 약 7KB를 차지한 반면, 커스텀 LPG 모델은 약 2KB로 측정됨. RDF가 약 3.5배 더 많은 공간을 사용함.
그래프 밀도: RDF는 속성을 별도의 노드로 표현해야 하므로 노드와 엣지 수가 LPG에 비해 압도적으로 많음.
질의 성능: 단순 조회에서는 차이가 미미했으나, 복잡한 경로 탐색(Graph Traversal)에서는 LPG가 빠른 실행 속도를 기록함.

Note: 실시간으로 변하는 센서 데이터를 처리해야 하는 스마트홈 환경에서는 LPG의 성능적 우위가 큰 매력으로 다가옴. 하지만 데이터의 양이 기하급수적으로 늘어날 때 RDF의 표준화된 구조가 주는 관리 효율성도 무시할 수 없을 것임.

4. 핵심 분석: 상호운용성 vs 퍼포먼스

RDF의 강점: 의미적 추론과 표준

RDF는 자동 추론(Inference)이 가능하다는 독보적인 장점이 있음. 여러 기관의 데이터를 통합할 때 표준 온톨로지를 사용하므로 데이터 오염이나 오해의 소지가 적음.

LPG의 강점: 효율적인 관계 표현

LPG는 엣지에 가중치나 시간 정보를 직접 부여할 수 있어, 사용자 선호도나 시간 흐름에 따른 상태 변화를 표현하기에 매우 적합함.

Note: "누가 이 장치를 켰는가?"라는 질문에 대해, RDF는 Reification(재구체화)이라는 복잡한 과정을 거쳐야 하지만 LPG는 관계 속성으로 간단히 해결함. 이 지점이 개발자 입장에서 LPG를 선호하게 만드는 요인이라 판단됨.

5. 결론 및 향후 전망

본 논문은 서비스의 목적에 따라 모델을 선택할 것을 권장함.

LPG 추천: 실시간 응답이 중요하고 복잡한 탐색이 필요한 스마트홈 서비스.
RDF 추천: 다기관 협력이 필요하고 장기적인 데이터 통합 및 의미 기반 서비스가 중요한 환경.

연구 마지막에는 RDF-star와 같은 하이브리드 모델을 언급하며, RDF의 표준성과 LPG의 효율성을 결합하려는 시도가 미래의 대안이 될 수 있음을 시사함.

What Is RDF-star | Ontotext Fundamentals

What Is RDF-star?

A detailed definition with examples for RDF-star, which allows descriptions to be added to edges in a graph.

www.ontotext.com

기술적 우위를 가리기보다 서비스의 생애 주기를 고려한 선택이 필요함. 개인적으로는 초기 프로토타이핑은 LPG로 빠르게 진행하되, 공공 데이터나 타 플랫폼과의 연업이 필요한 시점에는 RDF 변환 계층을 두는 하이브리드 전략이 현실적이지 않을까 생각함.

Graph 기반 LLM(RAG, Agent)을 위한 RDF / LPG / JSON 비교 분석

송채채 — Thu, 19 Feb 2026 14:30:01 +0900

최근 GraphRAG가 AI 지식 추출의 핵심 기술로 부상하면서, 지식을 어떤 형태로 저장하고 관리해야 하는지에 대한 전략적 선택이 중요해졌다. 내가 공부했던 분야는 RDF 기반의 트리플 구조의 지식그래프와 온톨로지였지만, 최근의 LLM에서 사용되는 그래프는 다양한 구현체이다. RDF, LPG, JSON(-LD)와 같은 구현에 따라 논문이나 시스템의 이해도가 달라질 수 있어 이번 기회에 정리해보았다.

1. GraphRAG가 요구하는 그래프의 본질

GraphRAG 논문과 Microsoft GraphRAG, NebulaGraph GraphRAG 등의 실제 구현체를 살펴보면 공통적으로 강조하는 지점이 있다. 그것은 그래프가 반드시 엔티티(Node)와 관계(Edge) 구조를 가져야 한다는 것이다.

구조적 추론: 무엇(노드)과 무엇(노드)이 어떤 관계(엣지)로 연결되어 있는지 추론 가능한 형태로 존재해야 한다.
포맷의 비종속성: 데이터 저장 포맷은 목적을 달성하기 위한 방법일 뿐이다. GraphRAG의 진정한 목적은 LLM이 관계 기반의 추론(Reasoning)을 수행할 수 있도록 구조화된 컨텍스트를 제공하는 것이다.

Note: 실무에서는 흔히 "그래프 DB가 없으면 GraphRAG를 못 하는 것 아니냐"는 오해가 있다. 하지만 본질을 이해한다면, 텍스트 청크 간의 연결 고리를 논리적으로 증명할 수 있는 리스트만 있어도 그래프의 역할을 충분히 수행할 수 있다는 점을 깨닫게 된다.

2. 실제 구현에서 사용되는 그래프 형태 비교

현재 연구 및 산업 현장에서 활용되는 주요 그래프 타입의 특징은 다음과 같다.

그래프 타입	구성 요소	활용 및 특징
RDF (Resource Description Framework)	Subject–Predicate–Object (삼중 구조)	삼중 구조는 논리적 추론에 강점이 있다.
LPG (Labeled Property Graph)	노드/엣지에 속성(Property) 포함 가능	대부분의 상용 구현체가 채택하는 형태다.
JSON 기반 그래프	JSON으로 노드와 엣지 표현	구현이 매우 쉽고 유연하다.
LPG DB (Neo4j, TigerGraph 등)	산업용 그래프 데이터베이스	대규모 데이터를 다루는 기업용 GraphRAG 시스템에서 주로 선호된다.
Adjacency List (파이썬 Dict 등)	노드 간 인접 리스트	연구용 논문이나 가벼운 프로토타입에서 종종 사용되는 형태다.

Note: 데이터의 복잡도에 따라 선택지는 달라지겠지만, 결국 LLM에게 전달되는 최종 형태는 자연어와 유사한 구조적 텍스트다. 따라서 특정 DB 엔진의 성능보다 '얼마나 정확한 관계(Relation)를 추출했는가'가 성능을 좌우한다.

RDF vs LPG vs JSON

실제 구현체(Microsoft GraphRAG, Neo4j, LlamaIndex 등)에서 사용되는 세 가지 형식을 실무 관점에서 비교 분석한다.

구조	삼중(triple) 기반	노드·엣지·속성 자유도 ↑	구조는 자유 형식
표현력	관계 중심. 속성 모델링 제약	속성 표현 강력	완전 자유(스키마 없음)
그래프DB	Blazegraph, GraphDB, Stardog	Neo4j, NebulaGraph, JanusGraph	없음(JSON 파일 자체)
쿼리 언어	SPARQL	Cypher, GQL, Gremlin	없음(직접 탐색)
LLM 입력 용이성	triple → 자연어 변환 필요	텍스트화 쉽고 유연	JSON → 자연어 변환 필요
구축 난이도	높음 (스키마 강함)	중간 (직관적)	매우 쉬움
대규모 처리	우수 (표준화)	최고 (산업에서 검증)	대규모는 어려움
GraphRAG 적합성	★★★☆☆	★★★★★	★★★★☆
실제 GraphRAG 사례	학술/정부/의료 등 RDF 기반 데이터 활용	NebulaGraph, Neo4j 기반 GraphRAG 대부분	Microsoft GraphRAG 기본 저장 구조

1. RDF (Resource Description Framework)

✔ 장점

1) 구조가 엄격해 대규모·다중 출처 데이터를 병합하기 좋음

스키마(ontology) 기반 → 데이터 일관성 보장
상호운용성 높음 (Wikidata, DBpedia 등 외부 RDF 연결 용이)

2) 관계 중심 추론에 매우 강함

Triple 기반 → “주어-관계-객체” 구조가 명확
복잡한 관계 표현에 뛰어남
(GraphRAG의 multi-hop reasoning 과제에 적합)

3) SPARQL을 통한 정교한 질의

triple 패턴 매칭, 경로 질의 등 고급 쿼리 지원

✔ 단점

1) 노드/엣지 속성 표현이 불편

property graph처럼 자연스럽게 “노드에 여러 속성”을 붙이기 어려움
결국 reification 등 복잡한 패턴 필요

2) GraphRAG에서 LLM 입력으로 쓰기에 변환 과정이 번거로움

LLM은 자연어 이해 → RDF triple은 해석 필요
"RDF → 자연어 template or prompt→ LLM" 단계가 필요

3) 구축 난이도가 가장 높음

온톨로지 설계 필요
GraphRAG 실무팀에서는 무겁다고 느끼는 경우多

2. LPG (Property Graph: Neo4j, NebulaGraph)

✔ 장점

1) GraphRAG에 가장 적합한 구조

대다수 산업용 GraphRAG가 LPG 기반
(Neo4j GraphRAG, NebulaGraph GraphRAG 등)

2) 노드/엣지에 속성을 자유롭게 부여 가능

(node)-[edge {score: 0.85, timestamp: "2024"}]->(node)

→ RAG의 텍스트 chunk, 요약, 토픽, score 등을 쉽게 포함 가능

3) Cypher/GQL 등 인간 친화적 쿼리

직관적: MATCH (a)-[:friend]->(b)
LLM에게 쿼리 생성 시키기에도 쉬움

4) 대규모 그래프 처리에 최적화

실제 여러 GraphRAG 벤더가 LPG 기반 선택

✔ 단점

1) 표준화 부족

RDF처럼 웹 표준(global interoperability) 부족

2) 다른 그래프DB 간 호환성 떨어짐

Neo4j ↔ NebulaGraph ↔ JanusGraph 간 마이그레이션 난이도 있음

3. JSON 기반 그래프 (Microsoft GraphRAG 기본)

✔ 장점

1) 구축 쉬움 — JSON 배열 만들면 끝

{
  "nodes": [
    { "id": "n1", "name": "Alice", "type": "Person" }
  ],
  "edges": [
    { "source": "n1", "target": "n2", "relation": "works_at" }
  ]
}

2) LLM 입력에 가장 자연스럽게 변환됨

GraphRAG의 "edge table"이나 "natural language summary" 만들기 편함

3) GraphDB 없이도 GraphRAG 구현 가능

파일 기반으로 community detection, PageRank 등 수행 → Microsoft GraphRAG 방식

4) 소규모 프로젝트에 최적

비용 적음
관리 용이

✔ 단점

1) 대규모 그래프 처리에 부적합

JSON 파일이 커지면 탐색이 느려짐
온라인 서비스에는 부적합 (그래프DB 필요)

2) 표준 쿼리 언어 없음

직접 파이썬/JS로 탐색 로직 구현해야 함

3) 구조적 제약이 없어 데이터 품질 관리 어려움

LPG에서 스키마란?

개인적으로 궁금했던 부분은 "LPG에는 왜 .owl 같은 표준 스키마 파일이 없는가?"이다. 이는 두 시스템의 철학적 차이에서 기인한다. RDF는 'Schema-First' 방식을 택하여 스키마가 데이터를 정의하는 반면, LPG는 'Schema-Optional' 혹은 'Schema-Less' 방식을 취한다.

1. DB 내부의 제약 조건(Constraints)으로 관리

별도의 파일을 로딩하는 것이 아니라, 데이터베이스(예: Neo4j) 내부에 DDL(Data Definition Language) 명령어를 통해 제약 조건을 걸어 스키마처럼 작동하게 할 수 있다.

방식: "모든 User 노드는 반드시 email 속성을 가져야 하며, 이는 유일(Unique)해야 한다"와 같은 규칙을 DB에 직접 선언gks다.
파일 형태: 이 제약 조건들을 모아둔 .cypher 스크립트 파일이나 마이그레이션 스크립트(Python, Java 등)가 사실상의 스키마 파일 역할을 한다.

예시 (Cypher):

CREATE CONSTRAINT FOR (p:Person) REQUIRE p.name IS UNIQUE;
CREATE CONSTRAINT FOR (p:Person) REQUIRE p.age IS NOT NULL;

2. 메타데이터 그래프(Meta-Graph) 또는 온톨로지 레이어 구축

LPG에는 표준 스키마 파일이 없으므로, '데이터를 설명하는 데이터(메타데이터)'를 그래프의 일부로 저장하거나 별도의 레이어로 관리할 수 있다.

팔란티어(Palantir) 방식: 팔란티어는 '온톨로지 매니저(Ontology Manager)'라는 도구를 통해 객체(Object Types)와 링크(Link Types)를 정의한다. 이 정의는 시스템 내부의 독자적인 메타데이터 저장소에 관리되며, 사용자는 UI를 통해 이를 정의한다.
자체 메타 노드 생성: 그래프 내에 별도의 Class, Property라는 라벨을 가진 노드를 따로 만들어, 실제 데이터 노드들이 이 메타 노드를 참조하게 하는 방식으로 RDF의 온톨로지 구조를 LPG 안에서 유사하게 구현할 수 있다

3. 애플리케이션 레벨의 코드/설정 파일 (JSON/YAML)

LPG를 사용하는 애플리케이션(예: GraphRAG) 단에서 스키마를 정의하고, 데이터를 넣기 전에 검증(Validation)하는 방식이다.

JSON/YAML: GraphRAG와 같은 시스템은 entity_types나 relation_types를 정의한 JSON이나 YAML 파일을 스키마로 활용할 수 있다. 이는 DB가 강제하는 것이 아니라, 데이터를 생성하는 파이프라인이 참조하는 '가이드라인'으로 작용한다.
GraphQL: 최근에는 Neo4j 등에서 GraphQL Schema (.graphql) 파일을 사용하여 그래프의 타입과 관계를 정의하고, 이를 기반으로 API를 자동 생성하는 방식을 사용할 수 있다.

4. GQL (Graph Query Language) 표준화 흐름

현재 ISO 표준으로 제정 중인 GQL은 LPG에서도 RDF처럼 명시적인 스키마 정의(Graph Type Definition)를 표준화하려고 시도하고 있다. 향후에는 LPG도 표준화된 스키마 파일을 갖게 될 가능성이 있다.

요약: RDF vs LPG 스키마 관리 방식 비교

특징	RDF (Semantic Web)	LPG (Neo4j, Palantir 등)
스키마 파일	.owl, .rdf, .ttl (필수 및 표준화됨)	없음 (필요시 .cypher, .graphql, .json 등으로 관리)
성격	Prescriptive (규범적): 스키마가 데이터를 정의함	Descriptive (서술적): 데이터가 곧 스키마가 됨 (Schema-free)
관리 위치	파일 자체 (Import 방식)	DB 내부 제약조건(Constraints) 또는 애플리케이션 코드
강제성	추론(Reasoning)을 통해 논리적 모순 발견	애플리케이션 로직이나 DB 제약조건으로 입력 차단

결론: 프로젝트 성격에 따른 선택 전략

GraphRAG에서 그래프란 특정 포맷이 아닌 '구조' 그 자체다. RDF는 표준화와 논리적 추론에 강점이 있고, LPG는 실무적인 모델링과 성능에 강점이 있으며, JSON은 실제 구현의 편의성이 높다.

GraphRAG 시스템 구축 시, 포맷은 도구일 뿐 핵심은 '관계의 질'에 있다.

빠른 프로토타이핑: 구축 비용이 적은 JSON 기반 그래프를 추천
고성능 온라인 서비스: 대규모 데이터 처리와 Cypher 쿼리의 이점을 살릴 수 있는 LPG(Neo4j 등)가 사실상 표준이다.
지식 융합 및 표준 지식 베이스: 외부 온톨로지와의 결합 또는 복잡한 도메인의 규칙이 중요하다면 RDF가 유리하다.

결론적으로 GraphRAG는 특정 형식을 요구하지 않으며, 관계 기반의 구조적 정보를 요구한다. 개발자는 자신의 도메인 규모와 요구되는 추론의 깊이에 따라 적절한 관리 방식을 선택해야 한다.

[논문리뷰] Graph-based Approaches and Functionalities in Retrieval-Augmented Generation: A Comprehensive Survey

송채채 — Thu, 19 Feb 2026 10:02:11 +0900

https://arxiv.org/abs/2504.10499

Graph-based Approaches and Functionalities in Retrieval-Augmented Generation: A Comprehensive Survey

Large language models (LLMs) struggle with the factual error during inference due to the lack of sufficient training data and the most updated knowledge, leading to the hallucination problem. Retrieval-Augmented Generation (RAG) has gained attention as a p

arxiv.org

1. 서론: 왜 다시 '그래프'인가?

LLM은 최신 지식 부족과 학습 데이터의 한계로 인해 사실 관계 오류인 환각(Hallucination) 문제를 겪음.

이를 해결하기 위해 외부 지식을 검색하는 RAG가 등장했으나, 일반적인 텍스트 검색은 실제 세계에 존재하는 구조화된 정보나 멀티홉(Multi-hop) 추론을 처리하는 데 한계가 있음.

그래프는 엔티티 간의 복잡한 관계와 위상(Topology) 정보를 모델링할 수 있어, LLM의 사실적 신뢰도와 복잡한 구조적 추론 능력을 강화하는 핵심 도구가 됨.

2. 그래프 기반 데이터베이스: 전통과 생성의 조화

기존 지식 그래프(Existing KGs):* Freebase, Wikidata, T-REx처럼 이미 구축된 방대한 지식 창고를 활용하여 신뢰도 높은 데이터를 제공함

텍스트 생성 그래프(Graphs Generated from Texts): 비정형 텍스트에서 OpenIE 기법 등을 통해 엔티티와 관계를 추출하고 구조화된 트리플(Triplet)을 생성하여 도메인 적응성을 높임

산업용 DB 트렌드: Amazon Neptune, Neo4j, ArangoDB 등은 최근 벡터 인덱스를 내장하여 그래프 트래버설과 시맨틱 유사도 검색을 결합한 하이브리드 방식을 지원하는 추세임

Note: 기존 RDF 방식은 대응이 느렸던 반면, 최근 LPG(속성 그래프) 기반 DB들은 LLM과의 연동 및 스트리밍 확장에 훨씬 유연하게 대처하고 있는 것으로 보임

3. 그래프 검색 알고리즘: 어떻게 찾아낼 것인가?

비매개변수 알고리즘(Non-parameterized):
- 결정론적: 최단 경로 계산이나 그래프 탐색을 통해 질문과 관련된 정확한 연결 고리를 찾음
- 확률론적: HippoRAG처럼 페이지랭크(PageRank) 확률 확산을 사용하여 질문 엔티티 주변의 고확률 인접 구역을 찾아
- 휴리스틱 기반: K-hop 샘플링처럼 효율적인 근사 해법을 통해 대규모 지식 검색 속도를 유지함.

학습 기반 알고리즘(Learning-based):
- 컨볼루션 기반: GCN 등을 활용해 이웃 노드의 특징을 가중 합산하여 지역적 연결 패턴을 포착함.
- 어텐션 기반: GAT처럼 특정 작업에 중요한 관계에 더 높은 가중치를 할당하여 정밀한 검색을 수행함.

Note: 지시그래프가 아닌 그래프 알고리즘을 활용한 방식에 대한 것. 개인적으로 통계적 방식은 이해가 어렵지만, 결국 LLM이 모르는 위상 구조를 GNN 같은 모델이 먼저 학습해서 검색 정확도를 높여주는 과정임

4. 그래프 프롬프팅: LLM에게 그래프 전달하기

토폴로지 인식 프롬프트(Topology-Aware): 노드와 에지의 관계를 트리플 형식 (주어, 관계, 목적어)이나 경로 형태로 명시하여 LLM이 지식의 구조적 본질을 직접 이해하게 함.

텍스트 프롬프트: 그래프 구조를 LLM이 이해하기 어려운 경우, 언어 모델을 통해 구조화된 지식을 자연어 문장이나 설명 형식으로 변환하여 전달함.

Note: 관계 경로를 화살표 등으로 시각화하거나 구조를 명시해 주는 것이 LLM의 멀티홉 추론 능력을 비약적으로 향상시킨다는 점이 인상적

5. 그래프 구조 파이프라인과 컨트롤러

파이프라인 유형:
- Sequential: 질문에서 답변까지 각 단계가 일직선으로 이어지는 표준 방식
- Loop: 피드백 메커니즘을 통해 검색 결과가 부족하면 다시 검색하거나 답변을 정교화하는 반복 방식
- Tree: 여러 검색 또는 프롬프트 전략을 동시에 병렬로 실행하여 최적의 경로를 찾는 방식.

컨트롤러 계열: 강화 학습(RL), 시스템-2(추론형 검색), 검증자 안내형(Verifier-guided), 컨트롤러가 파이프라인의 실행 시점과 중단 여부를 결정함

Note: 단순한 질의응답을 넘어 LLM 모델이 스스로 검색 루프를 돌며 답변을 수정하는 과정은 실제 그래프 구조 파이프라인의 요구사항과 일치함

6. 도메인 특화 응용: 왜 효과적인가?

의료(Healthcare): MedGraphRAG는 방대한 의료 문헌에서 엔티티를 연결하고, HyKGE는 의료 상담 시 잡음을 제거하면서 관련 지식을 재랭킹하여 정확도를 높임

과학 문헌: DALK는 알츠하이머병 관련 학술 문헌에서 지식 그래프를 구축하고, KGP는 LLM 가이드 에이전트를 통해 문헌 그래프를 탐색하며 답변을 합성함

코드 완성: GraphCoder는 코드의 제어 흐름(Control Flow)과 데이터 의존성(Data Dependence) 그래프를 활용해 문맥에 맞는 코드를 추천함

Note: 그래프 기반 RAG는 멀티홉 경로를 명확한 증거로 반환하므로 전문 분야에서 필수적인 설명 가능성(Explainability)과 검증 가능성을 보장할 수 있다고 함. 단...지식그래프 구축은 결국 양질의 데이터를 만드는 과정이라는 생각에 가까움. 도메인 지식을 표현할수 있는 데이터.

7. 결론 및 미래 전망

기존의 단순한 트리플 기반 KG는 복잡한 현실 지식을 담기에 한계가 있음을 확인

향후에는 다중 노드 관계를 표현하는 하이퍼그래프(Hypergraphs)나 추상화 수준을 담는 계층적 그래프 구축 기술이 중요해질 전망 => 향후 연구가 궁금해짐. 계층적 그래프 이론에 공감하고 관련 논문을 찾아볼 예정

사용자 피드백 루프와 상호작용(HCI)을 통합하여 검색 과정을 동적으로 조정하는 시스템으로 발전할 것임.

후기: 지식그래프 구축 이후 '어떻게 추출하느냐'의 단계에서 단순 쿼리 외에도 GNN이나 페이지랭크 같은 알고리즘이 LLM의 위상적 무지를 보완해 준다는 점을 배움.

전통적인 온톨로지 기반의 RDF 지식그래프 외에도 알고리즘, LPG 등 다양한 관점을 볼 수 있어서 재밌었고, 특히 하이퍼그래프, 추상적수준의 계층적그래프에 대한 논점을 확인할 수 있었음

[논문리뷰]Agentic RAG with Knowledge Graphs for Complex Multi-Hop Reasoning in Real-World Applications

송채채 — Fri, 13 Feb 2026 16:22:31 +0900

https://arxiv.org/abs/2507.16507

Agentic RAG with Knowledge Graphs for Complex Multi-Hop Reasoning in Real-World Applications

Conventional Retrieval-Augmented Generation (RAG) systems enhance Large Language Models (LLMs) but often fall short on complex queries, delivering limited, extractive answers and struggling with multiple targeted retrievals or navigating intricate entity r

arxiv.org

1. 배경 및 문제 의식: 기존 RAG의 한계

Classical RAG의 단점: 단순히 유사도가 높은 상위 k개의 텍스트 조각(top-k snippets)만 가져오기 때문에, 전체 목록 추출이나 복잡한 관계(저자→논문→프로젝트)를 추적하는 데 한계가 있음.
해결책: 동적 추론을 수행하는 에이전트(Agentic) 기능과 구조화된 정보를 가진 지식 그래프(KG)를 통합한 'INRAExplorer'를 제안함.

Note: 기존 RAG가 단답형이나 요약에 강했다면, 이 시스템은 연구원처럼 조사를 수행하겠다는 의지로 보임. 데이터 간의 연결 고리를 놓치지 않으려는 시도가 인상적임.

2. 지식 베이스 구축 (Knowledge Base Construction)

데이터 소스: INRAE의 2019년~2024년 오픈 액세스 출판물 및 HAL, OpenAire 등의 메타데이터를 결합함.
하이브리드 저장 구조:
- Vector Database (Qdrant): 텍스트 청크를 저장하며, Jina v3(밀집 벡터)와 BM25(희소 벡터)를 모두 사용하는 하이브리드 검색 지원.
- Knowledge Graph (Neo4j): 417,030개의 노드와 100만 개 이상의 관계로 구성됨.
특이점: INRAE Thesaurus(유의어 사전)를 통합하여 'Domain'과 'Concept' 노드를 구축, 전문 용어에 대한 이해도를 높임.

Note: 이 논문은 그래프의 구조(Topology) 자체를 쿼리(Cypher)로 직접 탐색하는 방식에 집중하고 있음. 노드를 벡터화해서 유사도를 찾는 방식도 있겠지만, 여기선 '관계의 정확성'을 위해 직접적인 그래프 쿼리를 도구로 선택한 것으로 보임.

3. 에이전트 및 멀티 툴 오케스트레이션

핵심 모델로 deepseek-r1-0528을 사용하며, 에이전트는 다음의 4가지 도구를 동적으로 활용함.

도구명	주요 기능	비고
SearchGraph	Neo4j에 Cypher 쿼리를 보내 관계를 추적하고 전체 리스트를 확보함.	핵심 도구
SearchPublications	벡터 DB에서 하이브리드 검색을 통해 초기 진입점 논문을 찾음.	진입점 확보용
SearchConceptsKeywords	시소러스를 통해 모호한 쿼리를 명확하게 하고 관련 개념을 탐색함.	용어 정리 및 확장
IdentifyExperts	특정 주제의 전문가를 식별하기 위한 복합 도구(논문 수, 인용 수 등 계산)	도메인 특화 로직

Note: 결국 "지식 그래프를 어떻게 심층적으로 활용했는가?"에 대한 답은 에이전트가 직접 Cypher 쿼리를 생성하여 그래프를 넘나들게(Multi-hop) 설계했다는 것임. 사용자가 직접 설계해야 한다는 점은 여전하지만, 에이전트가 상황에 맞춰 툴을 골라 쓰는 '유연성'을 부여한 점이 포인트임.

4. 주요 수치 및 통계 데이터

논문에서 구축한 지식 그래프의 노드 분포는 다음과 같음.

총 노드 수: 417,030개
주요 구성:Keyword: 96,588 (23.2%)Concept: 13,591 (3.3%)
Project: 3,999 (1.0%)
Publication: 38,791 (9.3%)
Author: 233,728 (56.0%)

결론 및 시사점

INRAExplorer는 단순 요약을 넘어 인간 연구자처럼 조사하는 AI를 지향함. 특히 복잡한 질문에 대해 에이전트가 스스로 "먼저 논문을 찾고(Step 1), 그 논문을 지원한 프로젝트를 찾고(Step 2), 그 프로젝트의 다른 주제를 탐색(Step 3)"하는 식의 추론 과정을 성공적으로 보여줌.

Note: 에이전트라고 해도 아직은 결국 인간이 얼마나 정교하게 도구(Tool/MCP)를 설계했느냐에 크게 의존하는 것 아닌가? 논문에서도 IdentifyExperts 같은 도구는 도메인 지식을 캡슐화한 것이라고 명시함.

[스터디] Kafka와 Redis를 활용한 대규모 실시간 시청자 수(CCU) 집계 시스템 설계

송채채 — Wed, 7 Jan 2026 10:31:50 +0900

오늘은 스터디에서 "실시간 시청자 수를 어떻게 대규모 환경에서 안전하게 집계할 것인가"를 주제로 공부함. 개인적으로 분산 처리나 전문 용어에 익숙해지기 위해, 논의되었던 핵심 설계 포인트들을 기록용으로 정리

1. 단순 입/퇴장 로그 방식의 한계와 보완

처음엔 사용자가 들어올 때(Join)와 나갈 때(Leave) 로그를 남겨서 그 차이를 구하면 된다고 생각했음. 하지만 실무에서는 비정상 종료(앱 강제 종료, 네트워크 단절) 시 '퇴장' 로그가 남지 않는 문제가 치명적임.

이를 해결하기 위해 하트비트(Heartbeat) 개념을 도입함. 클라이언트가 주기적으로 "나 아직 보고 있어"라는 신호를 보내고, 서버는 이 신호가 끊기면 유효시간(TTL) 만료로 판단해 자동으로 인원수에서 제외함.

2. 고가용성을 위한 데이터 처리: 핫패스와 콜드패스

데이터의 목적에 따라 두 가지 경로로 나누어 처리하는 '람다 아키텍처'적 접근이 필요함.

핫패스(Hot Path): 실시간성이 최우선. 0.5~1초 간격으로 UI에 즉시 숫자를 업데이트함. 약간의 오차는 허용함.
콜드패스(Cold Path): 정확성과 기록이 최우선. 방송 종료 후 전체 로그를 대조하여 봇(Bot)이나 중복 데이터를 필터링하고 정밀한 통계를 산출함.

3. 부하 분산을 위한 핵심 기술 (샤딩, 폴딩, Lua)

시청자가 수십만 명일 때, 특정 데이터(Key) 하나에만 업데이트가 몰리면 병목 현상이 생김.

카운터 샤딩(Counter Sharding): 하나의 카운터를 여러 개의 '샤드(Shard)'로 쪼개어 쓰기 부하를 분산함.
폴딩(Folding): 쪼개진 샤드들의 값을 주기적으로 다시 합쳐서 최종 합계를 구하는 과정임.
Lua Script: Redis 내부에서 여러 샤드의 값을 읽고 합산하는 로직을 '원자적(Atomic)'으로 한 번에 처리하기 위해 사용함. 네트워크 지연을 줄이고 데이터 일관성을 보장함.

4. 웹소켓과 팬아웃 (실시간 전파)

업데이트된 숫자를 사용자에게 전달하는 과정임.

웹소켓(WebSocket): HTTP와 달리 한 번 연결하면 유지되는 양방향 통로임. 서버가 클라이언트에게 실시간으로 데이터를 밀어줄 수 있음(Push).
팬아웃(Fan-out): 하나의 메시지를 수많은 접속자에게 동시에 뿌려주는 구조를 말함.

5. 엔터프라이즈급 하이브리드 설계 (Kafka + Redis)

단순 구현을 넘어 대규모 서비스에서 사용하는 범용적인 구조는 아래와 같음.

Gateway → Kafka: 모든 사용자 이벤트를 Kafka로 던져서 완충 작용을 함.
Kafka Streams: 스트림 데이터를 실시간 집계함. 이때 EOS(Exactly-Once Semantics)를 활용해 중복 카운팅을 원천 차단함.
Redis & Fan-out: 집계된 최종 값은 초저지연 조회를 위해 Redis에 캐싱하고, 웹소켓을 통해 사용자들에게 팬아웃함.

6. 추가 정리: 파티셔닝 vs 샤딩

파티셔닝: 한 대의 서버 안에서 테이블을 쪼개는 것.
샤딩: 여러 대의 서버로 데이터를 나누어 저장하는 것. (수평적 확장)

학습 소감:

단순히 숫자를 세는 작업도 대규모 환경으로 가면 분산 처리와 데이터 정합성 보장을 위해 이렇게나 복잡한 아키텍처가 필요
특히 Kafka의 EOS나 Redis Lua Script 같은 도구들이 왜 필수적인지 이해할 수 있었음.

[Python] 동시성 프로그래밍 - 멀티스레딩 vs 멀티프로세싱 vs 비동기

송채채 — Fri, 19 Dec 2025 14:01:48 +0900

Lambda 함수 최적화 과정에서 배운 Python 동시성 개념 정리

배경

API 크롤링 Lambda 함수가 너무 오래 걸려서 최적화가 필요했다. 여러 데이터를 순차적으로 수집하는데 10분 이상 소요되었고, 이를 병렬 처리로 개선하려고 했다.

그런데 멀티스레딩, 멀티프로세싱, 비동기라는 용어가 나오면서 혼란스러웠다. 각각 언제 사용해야 하는지, 어떤 차이가 있는지 정리해보았다.

핵심 개념: I/O Bound vs CPU Bound

프로그램의 병목 지점이 어디인지에 따라 최적화 방법이 달라진다.

CPU Bound (CPU 집약적)

정의: CPU 연산이 병목인 작업

예시:

이미지/비디오 처리 (리사이징, 필터링)
데이터 암호화/복호화
복잡한 수학 연산 (머신러닝 학습)
대용량 데이터 변환

특징:

# CPU가 계속 일함 
for i in range(10_000_000):
    result = i ** 2  # CPU 연산

I/O Bound (I/O 집약적)

정의: 네트워크/디스크 대기 시간이 병목인 작업

예시:

HTTP API 요청
데이터베이스 쿼리
파일 읽기/쓰기
S3 업로드/다운로드

특징:

# CPU는 놀고 네트워크 응답만 기다림
response = requests.get("https://api.example.com")  # 대기...

방법 1: 멀티스레딩 (Threading)

개념

하나의 프로세스 안에서 여러 스레드가 동시에 실행되는 것처럼 보이게 하는 기법

from concurrent.futures import ThreadPoolExecutor

def fetch_data(url):
    response = requests.get(url)  # I/O 대기
    return response.json()

urls = ["https://api1.com", "https://api2.com", "https://api3.com"]

# 3개 URL을 동시에 요청
with ThreadPoolExecutor(max_workers=3) as executor:
    results = executor.map(fetch_data, urls)

장점

✅ I/O Bound 작업에 최적

네트워크 대기 중에는 다른 스레드가 실행됨
API 요청, DB 쿼리, 파일 I/O 등에 효과적

✅ 메모리 효율적

같은 프로세스 내에서 메모리 공유
프로세스보다 가벼움

✅ 구현 간단

ThreadPoolExecutor 사용하면 쉽게 적용 가능

단점

❌ CPU Bound 작업에는 비효율

Python GIL(Global Interpreter Lock) 때문
한 번에 하나의 스레드만 Python 코드 실행 가능

❌ 스레드 안전성 고려 필요

공유 변수 접근 시 Lock 필요

GIL(Global Interpreter Lock)이란?

Python 인터프리터는 한 번에 하나의 스레드만 Python 바이트코드를 실행할 수 있도록 제한한다.

# CPU 연산: GIL 때문에 병렬 처리 안 됨
def cpu_task():
    total = 0
    for i in range(10_000_000):
        total += i ** 2  # GIL 잡고 실행
    return total

# 멀티스레딩으로 실행해도 순차 실행과 비슷한 속도
with ThreadPoolExecutor(max_workers=4) as executor:
    results = executor.map(cpu_task, range(4))

하지만 I/O 작업은 GIL 문제 없음!

# I/O 작업: 네트워크 대기 중에는 GIL 해제됨
def io_task(url):
    response = requests.get(url)  # GIL 해제 → 다른 스레드 실행 가능
    return response.text

# 멀티스레딩으로 실행하면 훨씬 빠름
with ThreadPoolExecutor(max_workers=4) as executor:
    results = executor.map(io_task, urls)

방법 2: 멀티프로세싱 (Multiprocessing)

개념

여러 프로세스를 생성하여 각각 독립적인 Python 인터프리터에서 실행

from concurrent.futures import ProcessPoolExecutor

def cpu_intensive_task(n):
    total = 0
    for i in range(n):
        total += i ** 2
    return total

numbers = [10_000_000, 10_000_000, 10_000_000, 10_000_000]

# 4개 프로세스가 진짜 병렬로 실행
with ProcessPoolExecutor(max_workers=4) as executor:
    results = executor.map(cpu_intensive_task, numbers)

장점

✅ CPU Bound 작업에 최적

각 프로세스가 독립적인 GIL 보유
진짜 병렬 처리 가능 (멀티코어 활용)

✅ 완전한 격리

프로세스 간 메모리 공유 안 함 → 안전

단점

❌ 메모리 오버헤드

각 프로세스가 독립적인 메모리 공간 필요
Lambda 같은 메모리 제한 환경에서 부담

❌ 프로세스 생성 비용

프로세스 생성/종료에 시간 소요
스레드보다 무거움

❌ I/O Bound 작업에는 과도함

네트워크 대기가 병목이면 멀티스레딩으로 충분

방법 3: 비동기 (Asyncio)

개념

단일 스레드에서 여러 작업을 번갈아가며 실행 (협력적 멀티태스킹)

import asyncio
import aiohttp

async def fetch_data(session, url):
    async with session.get(url) as response:
        return await response.text()

async def main():
    urls = ["https://api1.com", "https://api2.com", "https://api3.com"]

    async with aiohttp.ClientSession() as session:
        tasks = [fetch_data(session, url) for url in urls]
        results = await asyncio.gather(*tasks)  # 동시 실행

    return results

# 실행
asyncio.run(main())

장점

✅ I/O Bound 작업에 매우 효율적

수천 개의 동시 연결 처리 가능
멀티스레딩보다 오버헤드 적음

✅ 메모리 효율

단일 스레드에서 실행
스레드/프로세스 생성 비용 없음

✅ 세밀한 제어

동시 실행 수, 타임아웃 등 제어 가능

단점

❌ 코드 복잡도 증가

async/await 문법 학습 필요
기존 동기 라이브러리 사용 불가 (aiohttp, aioboto3 등 필요)

❌ CPU Bound 작업에는 부적합

단일 스레드라서 CPU 연산 시 블로킹

❌ 디버깅 어려움

비동기 코드는 스택 트레이스 추적이 복잡

비교표

항목	멀티스레딩	멀티프로세싱	비동기
적합한 작업	I/O Bound	CPU Bound	I/O Bound
GIL 영향	있음 (I/O는 괜찮음)	없음 (독립 프로세스)	있음 (단일 스레드)
메모리 사용	낮음	높음	매우 낮음
생성 비용	낮음	높음	매우 낮음
동시 처리 수	수십 개	CPU 코어 수	수천 개
구현 복잡도	낮음	낮음	높음
예시	API 요청, DB 쿼리	이미지 처리, 암호화	웹 크롤링, 웹소켓

실전 예시: API 크롤링 최적화

문제 상황

# 순차 처리: 10개 × 각 20개 API 요청 = 200개 요청
# 각 요청 0.5초 → 총 100초 소요
for artist in artists:  # 10개
    for schedule_id in schedule_ids:  # 20개
        response = requests.get(f"https://api.com/{schedule_id}")
        process(response)

해결 방법 1: 멀티스레딩 (데이터 단위 병렬화)

from concurrent.futures import ThreadPoolExecutor

def process_artist(artist):
    for schedule_id in artist.schedule_ids:
        response = requests.get(f"https://api.com/{schedule_id}")
        process(response)

# 4개 동시에 처리
with ThreadPoolExecutor(max_workers=4) as executor:
    executor.map(process_artist, artists)

# 예상 시간: 100초 → 25초 (4배 개선)

장점: 안전하고 구현 간단

해결 방법 2: 비동기 (HTTP 요청 단위 병렬화)

import asyncio
import aiohttp

async def fetch_schedule(session, schedule_id):
    url = f"https://api.com/{schedule_id}"
    async with session.get(url) as response:
        return await response.json()

async def process_artist(session, artist):
    tasks = [fetch_schedule(session, sid) for sid in artist.schedule_ids]
    results = await asyncio.gather(*tasks)
    return results

async def main():
    async with aiohttp.ClientSession() as session:
        tasks = [process_artist(session, artist) for artist in artists]
        await asyncio.gather(*tasks)

asyncio.run(main())

# 예상 시간: 100초 → 1-2초 (50-100배 개선)

주의: Rate Limit 위험! 동시 요청 수 제어 필요

해결 방법 3: 비동기 + Rate Limiting (추천)

from asyncio import Semaphore

async def fetch_with_limit(session, schedule_id, semaphore):
    async with semaphore:  # 동시 요청 수 제한
        url = f"https://api.com/{schedule_id}"
        async with session.get(url) as response:
            return await response.json()

async def main():
    semaphore = Semaphore(10)  # 최대 10개만 동시 실행

    async with aiohttp.ClientSession() as session:
        tasks = []
        for artist in artists:
            for sid in artist.schedule_ids:
                task = fetch_with_limit(session, sid, semaphore)
                tasks.append(task)

        results = await asyncio.gather(*tasks)

# 예상 시간: 100초 → 10초 (10배 개선, 안전함)

어떤 방법을 선택해야 할까?

플로우차트

작업 유형이 뭐야?
│
├─ CPU 연산이 많음 (이미지 처리, 암호화 등)
│  └─> 멀티프로세싱 (ProcessPoolExecutor)
│
└─ 네트워크/파일 I/O가 많음 (API, DB, S3 등)
   │
   ├─ 구현 간단하게 하고 싶음
   │  └─> 멀티스레딩 (ThreadPoolExecutor)
   │
   └─ 최대 성능 필요 (수백~수천 개 동시 처리)
      └─> 비동기 (asyncio + aiohttp)

내 케이스: Lambda API 크롤링

선택: 멀티스레딩 (ThreadPoolExecutor)

이유:

I/O Bound: HTTP 요청이 병목
안전성: Rate Limit 회피 (아티스트 단위 병렬화)
간단함: 기존 코드 최소 수정
충분한 성능: 60-70% 개선 예상

나중에 고려: 비동기 (더 빠른 속도 필요 시)

핵심 정리

I/O Bound 작업 (API, DB, 파일)
- 멀티스레딩 또는 비동기 사용
- GIL은 I/O 대기 중에는 문제 없음
CPU Bound 작업 (연산, 변환)
- 멀티프로세싱 사용
- GIL 우회하여 진짜 병렬 처리
Lambda 환경
- 메모리 제한 고려 → 멀티스레딩 선호
- 프로세스 생성 비용 고려
Rate Limiting
- 비동기 사용 시 반드시 동시 요청 수 제어
- Semaphore 또는 asyncio.Queue 활용

참고 자료

[AWS] Strands Agent 실습 (AWS Community Day 2025)

송채채 — Mon, 10 Nov 2025 10:28:41 +0900

회사에서 AWS를 사용하고 있고, 최근 Agent에 관심도 생겼고 겸사겸사 모임을 참가했다.
알게된 경로는 트위터에서 연사님 중 한분이 홍보하셔서 신청했음

목적은 strands라는 프레임워크를 사용하여 Agent 구축을 실습하는 것!

내가 신청한 트랙은 Agentic AI였음

Agent란?

특정 목표를 달성하기 위해 스스로 계획하고 도구를 사용하며 환경과 상호작용하기 위한 툴

Q. 비결정적 프레임워크에서 어떻게 신뢰성 확보하고 중간에 컨트롤할 수 있으려나?

langgraph는 흐름 설계 및 상태 전환을 개발자가 비교적 많이 제어함
strands는 에이전트가 직접 판단하는 자율적 제어가 더 강조됨 -> 프로토타입이 빠르게 가능

실습

Github 코드와 설명서의 예제를 통해서 진행함. cursor 환경이라서 자동완성을 더 많이 해줌
https://github.com/aws-samples/sample-once-upon-agentic-ai

GitHub - aws-samples/sample-once-upon-agentic-ai

Contribute to aws-samples/sample-once-upon-agentic-ai development by creating an account on GitHub.

github.com

AWS의 깃헙을 클론하여 실습을 진행하였다.

TIL 개념

tools

strands_tools에서 기본적으로 제공하는 tools를 할수도 있고, 커스텀도 되고 MCP도 가져올 수 있음
Q.python_repl이란? python 코드를 실행하는 툴, file_write 툴은 파일을 쓰는 툴

docstring

메서드에 대한 설명글

FastMCP는 MCP 서버와 클라이언트를 간단하게 생성할 수 있도록 설계된 고수준의 Pythonic 프레임워크
- MCP를 만드는 클래스
lambda를 써서 만들었음 MCPClient는 필요할때마다 새로운 연결을 만드는 클래스이나 lambda로 감싸면 나중에 필요할 때 실행함
mcp서버를 띄우고 다른 터미널에 해야함!
awscli 매번 export하거나 .env만드는걸 해야함..
MCP 자체를 만드는 거라면 굳이 MCP를 만들어야할 이유가 뭐지..? 어떨때 MCP를 만드는가...MCP와 메서드의 차이점은? MCP 서버를 만드는 기준?
AI 답변: MCP(Model Context Protocol)을 활용하면 단순히 애플리케이션 내부에 함수 하나 추가하는 것과 비교해 다음과 같은 장점이 있습니다.
- 확장성 있는 연동: MCP 서버 하나에 여러 기능(도구)을 묶어 두고 클라이언트가 필요한 기능만 골라 쓰게 할 수 있습니다. 새로운 기능을 서버 쪽에만 추가하면 바로 클라이언트에서 활용 가능하므로 배포/확장이 쉽습니다.
- 기술 중립적 통합: 서로 다른 언어·프레임워크로 만든 여러 서비스나 유틸리티를 MCP 서버로 감싸 두면, 클라이언트는 공통 프로토콜로 호출할 수 있어 통합 비용이 줄어듭니다.
- 권한 제어와 격리: 기능을 네트워크 경계 밖으로 분리해 두면 접근 권한 관리, 로깅, 감시 등을 중앙에서 통제하기 쉬워집니다. 민감한 연산이나 리소스 접근을 서버 측에 두고 필요한 권한만 열어주는 식으로 구성할 수 있죠.
- 배포·운영 분리: 클라이언트와 서버를 분리하면 기능 수정 시 서버만 재배포하면 되고, 여러 클라이언트가 같은 MCP 서버를 공유할 수 있습니다. 함수 호출 기반 구조에서는 각 애플리케이션마다 함수를 복사·관리해야 하지만 MCP 서버는 재사용이 용이합니다. -> 이 부분을 읽고 이해함
- 상태·리소스 관리: 장기 실행 작업, 캐시, 연결 풀 등 상태ful 리소스를 서버에서 유지하면서 MCP를 통해 접근하게 하면 클라이언트는 단순한 프로토콜 호출만 처리하면 됩니다.
- 정리하면, MCP는 기능을 네트워크 서비스로 캡슐화해 여러 클라이언트에서 표준 방식으로 재사용하고 확장할 수 있게 해주는 점이 가장 큰 이점입니다. 함수 수준 통합이 간단할 때도 있지만, 규모가 커지면 MCP 같은 프로토콜 기반 서버 구성이 더 유연하고 유지보수가 쉬워지는 경우가 많습니다.

멀티 에이전트 시스템 & A2A(agent-to-agent)

여러 에이전트를 만들어서 각자의 일만 시키는 시스템
실습 예시
The Sage of Rules ⚔️ Character Chronicler Dice Oracle (Port 8000) (Port 8001) (Port 8080) │ │ │ └────────────────────────┼──────────────────────┘ │ The Grand Orchestrator (Port 8009) [The Master's Throne]
8080이 MCP이면, 8000, 8001도 MCP인가? 질문
- 아니었음. 에이전트를 메서드 기반으로 해도되고, 서버로 호출할 수도 있음
- MCP를 해야할때란??
  AI 답변: MCP는 “도구를 RPC 형태로 묶어 제공하는 중개층”, 에이전트 서버는 “대화형 모델이 외부에서 호출될 수 있도록 HTTP 등으로 노출된 LLM(orchestrator)”라고 보면 이해가 쉽습니다.

MCP vs. 에이전트 서버

MCP 서버 (http://127.0.0.1:8080/mcp)
- MCP(Multi-Tool Capability Protocol)는 여러 도구를 표준화된 방식으로 노출하는 프로토콜입니다.
- 클라이언트(여기서는 MCPClient)가 연결해 “제공 가능한 툴 목록”을 가져오고, 필요할 때 RPC처럼 호출합니다.
- 장점: 툴 등록/탐색/호출이 규격화되어 있고, 도구 제공자·소비자 간 결합도가 낮습니다. 도구가 늘어나도 프로토콜이 같으니 확장성이 좋습니다.
- 주 용도: “LLM이 다양한 툴(예: dice roll, 데이터 조회)을 일정한 인터페이스로 호출해야 할 때”.
에이전트 서버 (http://127.0.0.1:8000, http://127.0.0.1:8001)
- A2A(Agent-to-Agent) 프로토콜 등으로 HTTP API를 제공하는 별도 LLM/에이전트 서비스입니다.
- 예제에서는 Rules Agent, Character Agent가 각각 독립 서버로 떠 있고, orchestrator가 HTTP로 질문을 전달합니다.
- 장점: 각 에이전트가 고유한 문맥/프롬프트/기능을 갖고 독립적으로 운영되며, orchestrator는 해당 API를 호출해 협업을 조율합니다.

언제 MCP를 도입하는가?

많은 도구(roll dice, 외부 API, DB 연동 등)를 LLM이 “직접” 호출해야 하고, 이를 표준화·확장 가능한 방식으로 관리하고 싶을 때 MCP를 씁니다.
도구가 함수 단위(메서드 기반)로 존재하고, 동일한 프로토콜로 등록·발견·호출되어야 하는 상황.
반대로, 이미 독립적인 에이전트가 HTTP API로 잘 노출돼 있고, 그 에이전트 자체가 LLM과 대화하며 결과를 생성한다면 그냥 에이전트 서버 호출이 적절합니다.
결국 orchestrator는 “도구는 MCP로, 협업해야 하는 다른 대화형 에이전트는 HTTP(A2A)로” 섞어서 사용하는 패턴이 흔합니다.

REST Client라는 편한 extention을 알게 되었습니다.

후기

- hans-on 에 참여하는 건 처음이었는데, 간식이랑 텀블러까지 받아오고 짧은 시간내에 무료 계정으로 실습할 수 있는 경험이 좋았다.

- 해외의 던전앤드래곤은 뭘까? 많은 곳에서 TRPG로 실습하는 경우를 봤음

- 아무래도 실습만 2시간 하고 끝나다보니 기본적인 개념과 개발환경에 익숙하지 않으면 에러가 난다거나 하는 상황이 많이 보였음. 근데 이건 대학교든 어디든 실습하면서 진행하는 게 제일 어렵다 진짜..각자 환경도 다르고 ㅜㅜ

- 간단하게 Agent 책을 미리 읽어가서 다행

- 오후 6시까지인지 알아서 네트워킹도 포함된건가? 했는데 아니었음. 짧게 해서 좋은 사람도 있고 네트워킹을 원하는 사람도 보였다

- 내년엔 개발소모임에 더 많이 나가볼까 고민중

[Database] Alembic으로 Postgres 테이블 생성 및 스키마 수정

송채채 — Wed, 29 Oct 2025 18:56:09 +0900

TIL: Alembic으로 임베딩 차원 변경 마이그레이션, 인덱스 opclass, 권한 이슈 정리

오늘 한 것

기존 테이블 A, B를 각각 _bak으로 리네임해 백업.
동일 스키마와 제약·인덱스를 유지한 채 새 테이블을 생성하고 embedding 컬럼만 VECTOR(384)로 변경하는 마이그레이션 설계.
Alembic 실행 위치, downgrade 방법, 인덱스 opclass 의미, 권한 이슈 트러블슈팅 정리.

Alembic 마이그레이션 설계 포인트

대상 스키마: sample
변경 범위:
- 특정 테이블 백업 후 재생성.
백업 절차:
- A → A_bak
- B → B_bak
새 테이블 생성:
- 기존 정의 유지, 단 embedding만 VECTOR(384)로 변경.
인덱스/제약(동일 유지):
- HNSW 인덱스: embedding vector_cosine_ops with (m=16, ef_construction=64)

실행 위치와 리비전 생성

실행 위치: 레포 루트에서 실행하면 alembic.ini의 script_location = alembic 설정에 따라 자동으로 alembic/versions/ 아래 생성됨.

리비전 생성 예시:

cd /Users/sample
alembic revision -m "test"

새 리비전의 down_revision은 기존 버전으로 설정.

downgrade 사용법

현재/이력 확인:

alembic current
alembic history --verbose

한 단계 되돌리기:
```
alembic downgrade -1
```

인덱스 opclass(int4_ops, text_ops) 이해

핵심: 기본 B-Tree에서 정수/텍스트 컬럼은 opclass를 생략해도 동일 동작.
- INTEGER → int4_ops
- TEXT → text_ops
즉, 다음 두 정의는 기능·성능이 실질적으로 동일.
- 생략: CREATE INDEX ... ON table (document_id);
- 명시: CREATE INDEX ... ON table USING btree (document_id int4_ops);
opclass를 일부러 바꿀 때만 의미가 달라짐(예: text_pattern_ops, collation, 다른 인덱스 타입 등).

배운 점

기본 B-Tree 인덱스에서는 정수/텍스트 opclass를 명시하지 않아도 동작·성능은 동일.
Alembic는 루트에서 실행하면 설정 경로를 자동으로 따라가며, down_revision 체인을 정확히 유지해야 안전하게 롤백 가능.