*이 장을 다 읽고 나면 알게 될 것: 데이터와 지식이 왜 다른 것인지, Graflo가 데이터 흐름을 어떻게 관리하는지, OntoCast가 지식을 어떻게 구조화하는지, GraphRAG가 일반 RAG와 어떻게 다른지, 그리고 나의 시스템가 ArangoDB와 pgvector를 왜 함께 쓰는지*
도입: 쏟아지는 자료, 움직이지 않는 시스템
2024년 초, 한 중견 제조업체의 디지털 전환 프로젝트에 참여한 적이 있다. 그 회사는 AI Agent를 도입하고 싶었다. 목표는 명확했다. 생산 현장의 품질 데이터, 공급업체 실적, 고객 클레임을 통합해서 의사결정을 지원하는 시스템을 만들겠다는 것이었다.
데이터가 없는 회사는 아니었다. 오히려 넘쳤다. ERP, MES, CRM, 이메일, SharePoint에 수년치 데이터가 쌓여 있었다.
그런데 Agent가 작동하지 않았다.
LLM은 잘 작동했다. 질문을 던지면 답을 했다. 그러나 답이 틀렸다. 2021년 보고서를 참조해서 2024년 질문에 답했다. A 공급업체의 데이터를 B 공급업체의 것으로 착각했다. 품질 기준이 바뀐 것을 모르고 옛 기준으로 판단했다.
문제는 LLM이 아니었다. 데이터가 지식이 되지 못한 것이 문제였다.
나는 그때 확신했다. 좋은 Agent는 좋은 모델에서 오지 않는다. 좋은 맥락에서 온다. 데이터가 구조화되어 관계를 갖추고, 시점과 범위가 명확해질 때 비로소 맥락이 된다. 그 맥락이 지식이다.
이 장은 Agent의 먹이에 관한 이야기다. 아홉 개 노드가 아무리 정교해도, 먹이가 나쁘면 결과도 나쁘다.
22.1 데이터와 지식은 다르다
먼저 구분해야 할 것이 있다. 데이터와 지식은 다르다.
낡은 이야기처럼 들릴 수 있다. DIKW 피라미드는 1980년대부터 있었다. 그러나 지금 다시 중요해진 이유가 있다. Agent 시스템에서 이 구분이 아키텍처의 차이로 직결되기 때문이다.
데이터는 기록이다. 숫자, 텍스트, 이미지, 로그. 그 자체로는 의미가 없다. "23.5"라는 숫자는 데이터다. 그것이 온도인지, 가격인지, 불량률인지 모른다.
정보는 맥락을 가진 데이터다. "2024년 3분기 A 공급업체의 불량률이 23.5%다"는 정보다. 누구의, 언제의, 무엇에 대한 것인지가 붙었다.
지식은 구조화된 맥락이다. "A 공급업체의 불량률은 3분기 연속 상승 추세이며, 이는 2024년 초 원자재 변경과 관련이 있고, 같은 원자재를 쓰는 B 공급업체에서도 유사한 패턴이 관찰된다"는 지식이다. 관계, 추세, 인과가 들어갔다.
Agent 시스템에서 이 구분이 중요한 이유는 간단하다. LLM에게 데이터를 던져주면 데이터 수준의 답이 나온다. 정보를 던져주면 정보 수준의 답이 나온다. 지식을 던져주면 지식 수준의 답이 나온다. 입력의 수준이 출력의 수준을 결정한다.
그래서 Agent를 잘 만들려면, 데이터를 지식으로 변환하는 파이프라인이 필요하다. 이것이 이 장의 핵심이다.
잠시 멈추고 생각해보자
당신이 속한 조직에서 "데이터가 많다"와 "지식이 풍부하다"는 같은 의미인가? 데이터는 있지만 지식은 부족한 영역이 있다면, 그 간극은 어디서 생기는가?
22.2 Graflo — 데이터 흐름을 설계한다
데이터를 지식으로 바꾸려면, 먼저 데이터가 어디서 와서 어디로 가는지를 알아야 한다. 이것이 데이터 흐름이다.
기업 현장에서 데이터 흐름은 대개 혼란스럽다. ERP에서 나온 데이터가 엑셀로 가공되어 이메일로 전달된다. CRM의 데이터가 BI 대시보드에 올라가지만, 그 사이에 누군가 수동으로 정제한다. 문서 서버에 있는 보고서는 검색이 안 되니 각자 로컬에 복사해둔다. 같은 숫자가 세 곳에 서로 다른 값으로 존재한다.
Graflo는 이 혼란을 정리하기 위한 데이터 흐름 관리 프레임워크다. 내가 나의 시스템에서 여러 프로젝트를 거치면서 정리한 것이다. 이름은 Graph + Flow의 합성어다. 데이터의 흐름을 그래프로 시각화하고 관리한다는 뜻이다.
Graflo의 핵심 개념은 세 가지다.
첫째, 소스 등록. 데이터가 발생하는 원천을 명확히 정의한다. ERP, CRM, MES, 이메일, 문서 서버, 외부 API. 각 소스의 데이터 유형, 갱신 주기, 신뢰도 등급을 기록한다. 이것이 없으면 "이 숫자가 어디서 왔는지" 아무도 모르는 상태가 된다.
둘째, 흐름 매핑. 데이터가 소스에서 출발해 어떤 경로를 거쳐 최종 소비 지점에 도달하는지를 그래프로 그린다. 노드는 데이터 처리 단계이고, 엣지는 데이터 이동이다. 이 그래프를 그리면 놀라운 것을 발견한다. 대부분의 기업에서 데이터는 직선으로 흐르지 않는다. 분기하고, 합류하고, 순환한다. 그리고 그 중간에 사람의 수작업이 끼어 있다.
셋째, 품질 게이트. 흐름의 각 단계에 품질 검증 지점을 둔다. 데이터가 다음 단계로 넘어가기 전에, 형식이 맞는지, 범위가 적정한지, 최신인지를 확인한다. 이 게이트가 없으면 오류가 파이프라인 끝까지 전파된다. Agent가 참조할 때는 이미 손쓸 수 없다.
Graflo는 본질적으로 데이터 리니지와 품질 관리의 결합이다. 새로운 이론이라고 주장하지 않겠다. 그러나 Agent 시스템의 관점에서 재구성한 것은 의미가 있다. 사람은 숫자가 좀 이상해도 직관으로 걸러낸다. Agent는 그대로 삼킨다. 그래서 품질 게이트가 더 엄격해야 한다.
삼성SDS의 "Data Fabric for AI", Databricks의 Unity Catalog, Snowflake의 Cortex가 모두 이 방향으로 움직인다. 데이터 인프라의 설계 기준이 "사람이 보기 좋은 것"에서 "Agent가 먹기 좋은 것"으로 바뀌고 있다.
잠시 멈추고 생각해보자
당신의 조직에서 같은 숫자가 두 곳 이상에 서로 다른 값으로 존재하는 사례를 본 적이 있는가? 그 불일치가 의사결정에 영향을 미친 적은 없는가?
22.3 OntoCast — 지식을 구조화한다
데이터 흐름을 정리했다면, 다음은 그 데이터에 구조를 입히는 것이다. 이것이 OntoCast의 역할이다.
OntoCast는 Ontology + Broadcast의 합성어다. 온톨로지를 만들고, 그것을 시스템 전체에 방송한다는 뜻이다.
온톨로지라는 말이 어렵게 들릴 수 있다. 원래는 철학 용어다. 존재론. 무엇이 존재하는가를 따지는 학문이다. 그러나 정보 기술에서의 온톨로지는 훨씬 실용적이다. 어떤 도메인에 어떤 개념이 있고, 그 개념들이 서로 어떤 관계를 맺는지를 명시적으로 정의한 것이다.
자동차 산업을 예로 들어보자. 개념으로는 완성차 업체, 1차 공급업체, 부품, 원자재, 공장이 있다. 관계로는 "조달받는다", "공급받는다", "보유한다"가 있다. 속성으로는 국가, 신용등급, 불량률, 규격, 리드타임이 있다. 이 세 가지 — 개념, 관계, 속성 — 가 온톨로지의 삼위일체다.
OntoCast는 이 온톨로지를 만드는 과정 자체를 체계화한다. 세 단계로 진행된다.
첫째, 도메인 모델링. 해당 산업이나 업무 영역의 핵심 개념을 추출한다. 이 작업은 도메인 전문가와 함께 해야 한다. LLM에게 시킬 수도 있다. 그러나 도메인 전문가의 검증 없이는 위험하다. LLM은 일반적인 개념은 잘 뽑지만, 특정 산업의 미묘한 구분을 놓친다. 예를 들어 반도체 산업에서 "후공정"과 "패키징"은 겹치는 부분이 있지만 같은 개념이 아니다. LLM은 이 구분을 흐리게 처리할 수 있다.
둘째, 관계 정의. 개념 사이의 관계를 명시적으로 정의한다. 관계에는 방향이 있고, 다중성이 있고, 때로는 시간 축도 있다. "A가 B에 부품을 공급한다"는 관계가 2023년에는 참이었지만 2024년에는 아닐 수 있다. 이 시간 차원을 놓치면 Agent가 과거의 관계를 현재로 착각한다.
셋째, 속성 표준화. 각 개념에 어떤 속성이 붙는지, 그 속성의 데이터 타입과 단위와 범위는 무엇인지를 정의한다. 불량률이 퍼센트인지 PPM인지, 가격이 원화인지 달러인지, 리드타임이 일 단위인지 주 단위인지. 이런 것을 미리 정하지 않으면, 나중에 데이터를 합칠 때 혼란이 생긴다.
OntoCast의 핵심 가치는 Agent가 세상을 이해하는 틀을 제공한다는 것이다. 온톨로지 없이 Agent에게 데이터를 주면, Agent는 단어의 의미를 맥락에서 추론해야 한다. 온톨로지가 있으면, Agent는 명확한 정의와 관계를 참조할 수 있다. 환각이 줄어든다. 답의 정확도가 올라간다.
구글의 Knowledge Graph가 바로 이 원리다. 2012년 이후 구글 검색이 키워드 매칭에서 의미 기반으로 진화한 것은 온톨로지 덕분이다. "이순신"을 검색하면 단어가 포함된 페이지가 아니라, 인물의 생몰년과 업적과 관련 인물이 구조화되어 나온다.
잠시 멈추고 생각해보자
당신이 일하는 도메인의 핵심 개념을 열 개만 뽑아보라. 그 열 개 사이의 관계를 그림으로 그릴 수 있는가? 그 그림이 바로 당신의 도메인 온톨로지의 시작이다.
22.4 GraphRAG — 그래프 기반 검색의 힘
이제 핵심에 왔다. GraphRAG다.
RAG는 이미 익숙할 것이다. 문서를 잘게 잘라 벡터로 변환하고, 질문과 가장 가까운 조각을 찾아 LLM에게 넘기는 기법이다. 잘 작동한다. 대부분의 경우에는. 그러나 한계가 있다.
첫째, 관계를 모른다. 벡터 검색은 의미적 유사성에 기반한다. "현대자동차"와 "자동차 산업"은 가깝다. 그러나 "현대자동차"와 "SK이노베이션"의 관계 — 배터리 공급 계약이 있다는 사실 — 는 유사성만으로 찾을 수 없다. 두 단어가 의미적으로 가까운 것이 아니기 때문이다.
둘째, 멀티홉 추론이 안 된다. "현대자동차의 배터리 공급업체가 사용하는 양극재의 주요 원산지는 어디인가?" 이 질문에 답하려면 세 단계를 거쳐야 한다. 현대자동차 → 배터리 공급업체(SK온) → 양극재 공급업체 → 원산지(칠레, 호주). 일반 RAG는 이 연쇄를 따라가지 못한다. 한 번의 검색으로 관련 문서를 찾을 뿐이다.
셋째, 전역적 이해가 부족하다. 일반 RAG는 검색된 몇 개의 조각만 본다. 전체 데이터셋에 걸친 패턴이나 구조를 파악하지 못한다. "이 산업에서 가장 취약한 공급망 병목은 어디인가?" 같은 질문은 전체를 조감해야 답할 수 있다.
GraphRAG는 이 한계를 극복한다. 마이크로소프트 연구팀이 2024년에 발표한 핵심 아이디어는 단순하다. 문서를 벡터로만 저장하지 말고, 그래프로도 저장하자. 네 단계를 거친다.
1단계: 엔티티 추출. 문서에서 핵심 개체를 뽑아낸다. 회사명, 인물명, 제품명, 기술명, 장소명. LLM이 이 작업을 잘한다. "현대자동차가 SK온과 배터리 공급 계약을 체결했다"는 문장에서 '현대자동차', 'SK온', '배터리 공급 계약'이라는 세 개의 엔티티를 추출한다.
2단계: 관계 매핑. 추출된 엔티티 사이의 관계를 정의한다. 현대자동차 →[공급 계약]→ SK온. 이것도 LLM이 할 수 있다. 관계의 유형, 방향, 시점을 함께 기록한다.
3단계: 그래프 구축. 엔티티를 노드로, 관계를 엣지로 하는 그래프를 만들어 그래프 데이터베이스에 저장한다. 문서가 늘어날수록 그래프가 커지고, 노드 사이의 연결이 촘촘해진다.
4단계: 그래프 기반 검색. 사용자의 질문이 들어오면, 벡터 검색과 그래프 탐색을 함께 수행한다. 벡터 검색으로 관련 노드를 찾고, 그래프 탐색으로 그 노드와 연결된 이웃 노드를 따라간다. 멀티홉 추론이 가능해진다.
나의 시스템의 KVIC 시스템이 이 방식으로 작동한다. 그래프 데이터베이스로 ArangoDB를 선택했다. ArangoDB는 문서 저장소와 그래프 저장소를 하나의 엔진에서 지원한다. 엔티티는 document collection에, 관계는 edge collection에 저장하고, AQL로 "현대자동차에서 출발해서 공급 관계를 3단계까지 따라가라" 같은 쿼리를 날린다. 한 줄이면 멀티홉 탐색이 된다.
잠시 멈추고 생각해보자
당신이 최근에 답하기 어려웠던 업무상의 질문을 하나 떠올려보라. 그 질문이 어려웠던 이유가 "관련 문서를 못 찾아서"인가, "여러 정보를 연결하지 못해서"인가? 후자라면 GraphRAG가 답일 수 있다.
22.5 기업 데이터의 현실 — 네 가지 병
좋은 프레임워크가 있어도, 현실의 데이터가 엉망이면 소용이 없다. 기업 데이터의 현실을 직시해야 한다.
수십 개 기업의 데이터를 봤다. 놀라울 정도로 비슷한 문제가 반복된다. 나는 이것을 네 가지 병이라고 부른다.
첫째, 사일로 병. 부서마다 데이터가 따로 논다. 영업팀의 고객 데이터와 서비스팀의 고객 데이터가 연결되지 않는다. 생산팀의 불량 데이터와 품질팀의 불량 데이터가 다른 기준으로 집계된다. 각 부서는 자기 데이터를 잘 관리한다. 그러나 부서 경계를 넘는 순간 데이터가 끊긴다. Agent는 부서 경계를 모른다. 전체를 보려 하는데, 전체가 연결되어 있지 않다.
둘째, 비정형 병. 기업 데이터의 약 80%는 비정형이라는 추정이 있다. 보고서, 이메일, 회의록, 프레젠테이션, 이미지, 도면. 이 데이터는 데이터베이스에 들어 있지 않다. 파일 서버 어딘가에 흩어져 있다. 검색이 어렵고, 구조화가 안 되어 있다. Agent에게 가장 어려운 먹이다.
셋째, 중복 병. 같은 보고서가 이메일 첨부, SharePoint, 로컬 드라이브, 카카오톡 대화방에 각각 존재한다. 어떤 것이 최신 버전인지 아무도 모른다. 누군가 수정한 버전이 공유되지 않아 옛 버전이 계속 돌아다닌다. Agent가 검색하면 다섯 개 버전 중 어떤 것을 참조해야 하는지 판단해야 한다. 판단 기준이 없으면 임의로 하나를 고른다. 그것이 틀린 버전일 확률이 높다.
넷째, 최신성 병. 데이터가 낡았다. 2023년에 만든 시장 보고서가 2025년에도 참조된다. 퇴사한 직원의 분석이 아직도 "최신 분석"으로 공유된다. 특히 빠르게 변하는 영역 — 시장 점유율, 기술 트렌드, 규제 현황 — 에서 이 문제가 심각하다.
이 네 가지 병을 한꺼번에 고칠 마법은 없다. 그러나 Agent 시스템을 도입할 때, 이 문제를 무시하면 실패한다. 많은 기업이 "AI를 도입하면 데이터 문제가 해결될 것"이라고 기대한다. 정반대다. 데이터 문제를 먼저 어느 정도 해결해야 AI가 작동한다.
"어느 정도"라고 한 이유가 있다. 완벽을 기다리면 영원히 시작하지 못한다. 핵심 데이터만 먼저 정리하고, 나머지는 운영하면서 점진적으로 개선한다.
22.6 지식 구조화 파이프라인 — 다섯 단계
데이터를 지식으로 바꾸는 파이프라인은 다섯 단계로 구성된다. 수집, 정제, 구조화, 저장, 검색이다.
1단계: 수집. 데이터 소스에서 원본 데이터를 가져온다. API 연동, 파일 수집, 웹 크롤링, 이메일 파싱. 이 단계의 핵심은 빠뜨리지 않는 것이다. 그리고 각 데이터의 출처와 수집 시점을 반드시 기록하는 것이다. 출처 없는 데이터는 나중에 검증할 수 없다.
2단계: 정제. 노이즈를 제거한다. 중복 제거, 형식 통일, 결측값 처리. 비정형 데이터는 PDF에서 텍스트를 뽑고, 이미지에서 OCR을 돌린다. 가장 지루하지만 가장 중요한 단계다. 정제를 소홀히 하면 이후 모든 단계가 오염된다.
3단계: 구조화. OntoCast의 온톨로지에 따라 엔티티를 추출하고, 관계를 매핑하고, 속성을 채운다. LLM이 자동 추출을 잘하지만, 정확도가 완벽하지는 않다. 도메인 전문가의 검증이 필요하다. 적어도 초기에는.
4단계: 저장. 구조화된 지식을 적절한 저장소에 넣는다. 여기서 아키텍처의 선택이 갈린다. 벡터 데이터베이스만 쓸 것인가, 그래프 데이터베이스를 함께 쓸 것인가, 관계형 데이터베이스도 유지할 것인가. 이 선택은 다음 절에서 자세히 다룬다.
5단계: 검색. Agent가 필요한 지식을 찾는다. 벡터 유사성, 그래프 탐색, 필터링, 랭킹이 복합적으로 작동한다. 관련도 높은 것을 위에, 최신 것을 우선으로, 신뢰도 높은 것을 먼저. 이 우선순위 설계가 검색 품질을 결정한다.
이 다섯 단계는 한 번 하고 끝나는 것이 아니다. 지속적으로 순환한다. 새로운 데이터가 매일 들어온다. 기존 데이터가 갱신된다. 온톨로지도 진화한다. 새로운 개념이 등장하고, 관계가 바뀐다. 그래서 이 파이프라인은 자동화되어야 한다. 수동으로 돌리면 한 달도 못 간다.
잠시 멈추고 생각해보자
이 다섯 단계 중에서 당신의 조직이 가장 취약한 단계는 어디인가? 수집은 잘하지만 정제가 안 되는가? 저장은 잘하지만 검색이 안 되는가? 그 병목이 Agent 도입의 첫 번째 해결 과제다.
22.7 이중 저장소 — ArangoDB와 pgvector
저장 단계에서 나의 시스템가 선택한 구조를 공유한다. ArangoDB와 pgvector의 이중 저장소다.
왜 두 개를 쓰는가. 한마디로 말하면, 각각이 잘하는 것이 다르기 때문이다.
pgvector는 벡터 검색에 강하다. PostgreSQL의 확장 기능으로, 기존 관계형 데이터베이스에 벡터 인덱스를 추가한 것이다. 문서를 임베딩 벡터로 변환해 저장하고, 코사인 유사도로 검색한다. 일반 RAG의 핵심 엔진이다. 장점은 PostgreSQL 생태계를 그대로 쓸 수 있다는 것이다. 트랜잭션, 인덱스, SQL 쿼리. 이미 PostgreSQL을 쓰는 조직이라면 추가 인프라 없이 벡터 검색을 붙일 수 있다.
ArangoDB는 그래프 탐색에 강하다. 멀티모델 데이터베이스로, 문서 저장소와 그래프 저장소를 하나의 엔진에서 지원한다. 엔티티를 노드로, 관계를 엣지로 저장하고, AQL로 복잡한 그래프 쿼리를 실행한다. "이 노드에서 출발해 3홉 이내의 모든 연결 노드를 찾아라" 같은 쿼리가 자연스럽다. GraphRAG의 핵심 엔진이다.
실제 작동 방식은 이렇다.
사용자가 "현대자동차 배터리 공급망의 리스크 요인을 분석해줘"라고 요청한다. 시스템은 두 갈래로 검색한다.
한쪽에서는 pgvector가 의미적으로 가까운 문서 조각을 찾는다. 관련 보고서와 뉴스 기사가 올라온다. 다른 한쪽에서는 ArangoDB가 현대자동차 노드에서 출발해 공급 관계 엣지를 따라간다. SK온, LG에너지솔루션을 찾고, 거기서 양극재, 분리막 공급업체로 이어간다. 각 노드의 속성 — 국가, 점유율, 최근 이슈 — 도 함께 가져온다.
두 결과를 합치면, 텍스트적 맥락과 구조적 맥락이 결합된다. 이것을 LLM에게 넘기면 공급망 구조를 이해한 분석이 나온다.
단점도 있다. 두 시스템의 운영 복잡도와 데이터 동기화 부담이다. 같은 엔티티가 양쪽에 존재하므로 일치를 유지해야 한다. 이 동기화를 Graflo의 흐름 매핑으로 관리한다. 결국 Graflo, OntoCast, 이중 저장소가 하나의 체계로 작동하는 것이다.
솔직히 말하면, 소규모 프로젝트에서는 pgvector만으로 충분한 경우가 많다. 그러나 엔티티 간 관계가 중요한 도메인 — 공급망, 금융, 의료, 법률 — 에서는 그래프 저장소가 결정적인 차이를 만든다.
22.8 권한 설계 — 먹이에도 경계가 있다
마지막으로, 데이터에 대한 권한 설계를 다루지 않을 수 없다.
Agent가 강력해질수록 위험도 커진다. Agent가 모든 데이터에 접근할 수 있다면, Agent를 통해 민감한 정보가 유출될 수 있다. 인사 데이터, 급여 정보, 미공개 재무 데이터, 법적 분쟁 자료. 이런 것에 Agent가 무분별하게 접근하면 안 된다.
권한 설계의 원칙은 "최소 권한"이다. Agent는 주어진 과제를 수행하는 데 필요한 최소한의 데이터에만 접근해야 한다. 이것은 정보 보안의 오래된 원칙이지만, Agent 시대에 새로운 의미를 갖는다.
전통적 시스템에서는 사람이 데이터에 접근한다. 사람은 민감한 정보를 봤다면 함부로 외부에 말하지 않을 것이라는 사회적 계약이 있다. Agent는 다르다. 인사 데이터를 참조해서 생성한 보고서에 특정 직원의 급여 정보가 슬쩍 들어갈 수 있다. 관련 있다고 판단해서 넣은 것이다. 그러나 그 보고서를 받는 사람이 볼 권한이 있는가? 이 질문을 시스템적으로 풀어야 한다.
실무에서의 권한 설계는 세 겹으로 구성된다.
첫째, 데이터 레벨 권한. 어떤 데이터 소스에 접근 가능한가. ArangoDB의 컬렉션별, pgvector의 네임스페이스별로 접근 제어를 건다. Agent의 역할에 따라 다른 범위를 부여한다. 재무 분석 Agent는 재무 데이터에 접근하되 인사 데이터에는 접근하지 못한다.
둘째, 필터 레벨 권한. 접근 가능한 데이터 안에서도 특정 조건의 레코드만 볼 수 있게 한다. 예를 들어 특정 부서의 Agent는 해당 부서의 데이터만 볼 수 있다.
셋째, 출력 레벨 검증. Agent가 생성한 결과물에 민감한 정보가 포함되어 있지 않은지 생성 후에 검증한다. 이것은 20장에서 다룬 Critic 노드의 역할이기도 하다. 내용의 정확성뿐 아니라 정보 보안까지 검증하는 것이다.
이 세 겹이 모두 갖춰져야 기업에서 Agent를 안심하고 쓸 수 있다. 하나라도 빠지면 구멍이 생긴다.
핵심 정리
데이터와 지식은 다르다. 데이터는 기록이고, 지식은 구조화된 맥락이다. Agent의 성능은 모델의 능력만큼이나 입력되는 지식의 품질에 달려 있다. Garbage in, garbage out은 Agent 시대에도 유효하다.
Graflo는 소스 등록, 흐름 매핑, 품질 게이트로 데이터의 경로를 통제한다. OntoCast는 개념, 관계, 속성의 삼위일체로 도메인 지식을 구조화한다. GraphRAG는 벡터 검색에 그래프 탐색을 결합해 관계와 멀티홉 추론을 가능하게 한다.
기업 데이터의 현실은 사일로, 비정형, 중복, 최신성 부족이라는 네 가지 병을 안고 있다. 지식 구조화 파이프라인은 수집, 정제, 구조화, 저장, 검색의 다섯 단계로 순환하며, 나의 시스템는 ArangoDB와 pgvector의 이중 저장소로 이를 운영한다. 권한 설계는 데이터 레벨, 필터 레벨, 출력 레벨의 세 겹이다.
반드시 답해봐야 할 질문 5가지
질문 1. 당신의 조직에서 데이터는 풍부하지만 지식은 부족한 영역이 있는가? 그 간극의 원인은 무엇인가 — 구조화의 부재인가, 연결의 부재인가, 최신성의 부재인가?
질문 2. 당신이 만들려는 Agent에게 가장 필요한 것은 벡터 검색인가, 그래프 탐색인가? 그 판단의 기준은 "엔티티 간 관계가 답에 얼마나 중요한가"다. 당신의 도메인에서 관계는 얼마나 중요한가?
질문 3. 당신의 조직의 데이터 사일로는 기술적 문제인가, 조직적 문제인가? 기술적으로 연결할 수 있지만 부서가 공유를 원하지 않는 경우는 없는가?
질문 4. 권한 설계에서 "Agent가 알아도 되는 것"과 "Agent가 알면 안 되는 것"의 경계를 당신의 업무에서 구체적으로 그어보라. 그 경계가 명확한가, 모호한가?
질문 5. 지식 구조화 파이프라인의 다섯 단계 중 내일 당장 시작할 수 있는 한 단계는 무엇인가? 완벽한 파이프라인을 기다리는 것과 한 단계부터 시작하는 것, 어느 쪽이 낫겠는가?
더 깊이 탐구하기
Microsoft Research, "From Local to Global: A Graph RAG Approach to Query-Focused Summarization" (2024). GraphRAG 개념을 본격적으로 정립한 논문.
ArangoDB 공식 문서 — Graph Traversal (https://www.arangodb.com/docs/). 멀티모델 데이터베이스에서 그래프 쿼리를 어떻게 작성하는지에 대한 실무 가이드.
pgvector GitHub 리포지토리 (https://github.com/pgvector/pgvector). PostgreSQL에 벡터 검색을 추가하는 확장 기능의 설치와 사용법.
가트너, "Composite AI" 보고서 (2024). 여러 AI 기법을 결합하는 접근법에 대한 산업 분석.
나의 시스템 KVIC 시스템 기술 백서 (2025). ArangoDB + pgvector 이중 저장소 구조의 실제 구현 사례와 운영 경험.
다음 장에서는 이 데이터와 지식 구조 위에 올라가는 기술 스택과 환경 설계를 다룬다. LangGraph, RunPod, MLflow, Qwen3. 도구의 선택은 결국 아키텍처의 선택이다.