월요일 온톨로지, Opencrab 특강을 듣고. 좀 더 공부해보고 싶어서..
관련 영상을 찾아보니 오픈크랩의 온톨로지 관련 영상이 있더군요.
보기 쉽게 잘 정리해서 공유드립니다.
채널: Alex AI
업로드일: 2026-03-10
길이: 36:34
분석일: 2026-07-28
자막: 한국어 자막 898개 구간 전체 확인
Source boundary
이 노트는 영상 자막과 metadata를 주된 근거로 정리했다. 자동 자막의 기술 용어는 문맥에 따라 LLM, RAG, SPARQL, Neo4j, Chroma, GraphRAG, RBAC, LangChain, LangGraph, CLIP, GPT-OSS로 정규화했다. 화자가 공개했다는 개인 프레임워크는 자막상 “랭젠트”로 들리지만 외부 검색 경로가 차단되어 정확 표기를 확인하지 못했다. 영상의 효율·정확도·시장 전망·수치·제품 비교는 외부 검증된 사실이 아니라 화자의 주장 또는 사례로 읽어야 한다.
【핵심 요약 】
한 문장 요약
이 영상은 에이전트가 실제 업무와 물리 세계에 영향을 미칠수록, 생성 능력보다 먼저 정제된 데이터·관계·규칙·권한을 담은 온톨로지가 필요하며, 그 위에 에이전트를 올려야 일관되고 통제 가능한 AI 시스템이 된다고 주장한다.
10초 브리프
질문
영상의 답
온톨로지는 무엇인가?
개념을 노드로, 개념 사이 관계와 의미를 엣지로 표현해 데이터가 어떤 세계를 구성하는지 정리한 규칙·설계 체계
왜 에이전트 다음인가?
LLM의 확률적 결과가 에이전트를 통해 결제·삭제·메일·로봇·자동차 같은 행동으로 이어지면 오류 비용이 커지기 때문
정적 온톨로지와 차이는?
고정된 분류표가 아니라 새 데이터와 관계가 들어오며 계속 바뀌는 Active Ontology가 필요하다는 주장
핵심 병목은?
멋진 그래프 도구보다 데이터의 품질·가공·출처·권한·관계 설계
작게 시작하는 법은?
작은 CSV·PDF·Excel 하나에서 필요한 필드를 추출하고 필터링한 뒤 관계가 맞는지 검증
구축 흐름은?
파싱 → 청킹 → 벡터/임베딩 → 그래프 → 메타온톨로지·메타엣지 → RBAC → 에이전트 오케스트레이션
지식 그래프와 차이는?
영상 설명 기준, 온톨로지는 전체 규칙과 설계도이고 지식 그래프는 그 규칙 위에서 데이터 관계를 표현한 결과물
기업 적용 대상은?
복잡한 공급망, 금융·의료·법률, 로봇·자율주행, 방대한 내부 데이터를 가진 조직
최종 비유는?
온톨로지는 두뇌와 세계관, 에이전트는 팔다리이며 둘 중 하나만으로는 완전한 AX가 되기 어렵다는 주 장
영상의 중심 명제
에이전트의 실행력을 키우기 전에, 에이전트가 어떤 데이터와 관계를 믿고 어디까지 행동할 수 있는지 정하는 세계를 먼저 만들어야 한다.
🎨 시각자료
*대표 인포그래픽 이미지
온로고
*풀보드 인포그래픽 페이지
한국 정부의 한국 사이버 보안 인포그래픽
📌 Highlight Timestamps
00:01 — “에이전트 다음은 온톨로지”라는 화자의 중심 주장
01:10 — 빠른 AI MVP와 실제 업무 활용 사이의 간극
02:16 — 철학 용어에서 공학적 데이터 모델로
03:19 — 정적 온톨로지와 Active Ontology
04:48 — LLM이 자동 생성한 그래프의 함정
05:43 — 공공데이터 품질 착시와 살아 있는 데이터
06:28 — 큰 데이터보다 작은 데이터로 시작
07:09 — 전기차 충전소 데이터 예시
09:33 — 기업에서 온톨로지가 필요하다고 보는 이유
12:12 — 데이터가 관계 있는 지식으로 바뀌는 과정
14:18 — 문자열 검색에서 의미·맥락 그래프로
16:22 — Palantir와 FDE 사례
17:47 — 도메인·클래스·속성·관계 설계
20:55 — 파싱부터 에이전트까지 전체 구축 파이프라인
24:32 — 노드·엣지·메타엣지
27:47 — RBAC와 에이전트 실행 계층
31:46 — 에이전트와 온톨로지의 결합
32:39 — 조경 이미지 데이터를 활용한 개인 구현 사례
【상세 정리 】
1부. 왜 에이전트 다음에 온톨로지인가
1. 에이전트 결과의 결핍을 메우는 층 · 00:01–01:09
화자는 사람들이 에이전트를 밤새 돌리더라도 결과가 항상 완벽하거나 만족스럽지는 않다고 문제를 제기한다. 그 부족함을 메워 줄 다음 주제가 온톨로지라는 것이 영상 전체의 중심 명제다.
현재 에이전트 생태계는 LLM을 기반으로 하므로 환각 가능성이 남는다. 화자는 정제된 데이터와 관계 체계가 준비된 온톨로지 위에 에이전트를 연결하면, 실행 결과의 품질과 안정성을 높일 수 있다고 본다.
여기서 온톨로지는 LLM을 대체하는 또 하나의 모델이 아니다. LLM과 에이전트가 참조할 데이터의 의미·관계·규칙·경계를 미리 조직하는 기반층으로 제시된다.
2. 화려한 MVP와 실제 업무 사이의 간극 · 01:10–02:15
생성형 AI는 개인의 아이디어를 빠르게 MVP로 만든다. 결과가 화려하고 제작 속도도 빠르지만, 기업이 그대로 업무에 활용할 수 있는지는 별개의 문제라고 설명한다.
화자는 대기업이 AI 사용을 제한하거나 결과를 다시 사람이 검수하게 되는 이유를 잘못된 결과에 대한 책임과 비용에서 찾는다. 생성형 AI 프로젝트가 기술 데모를 넘어 실제 프로세스로 들어갈 때 신뢰 문제가 병목이 된다는 주장이다.
그 대안으로 철학에서 존재의 범주를 다루던 온톨로지 개념을 공학으로 가져와, 조직의 데이터와 업무 세계를 명시적으로 모델링하는 접근을 제시한다.
2부. 온톨로지의 정의와 진화
3. 노드와 엣지로 만드는 지식의 설계 · 02:16–03:18
영상은 온톨로지를 개념을 노드로, 개념 사이 관계를 엣지로 연결하는 구조로 설명한다. 각 노드에 실제 데이터가 자리 잡고, 데이터가 어떤 개념에 속하며 다른 데이터와 어떤 관계를 갖는지 표현되면 지식 체계가 된다.
과거의 온톨로지는 비교적 고정된 분류 기준으로 작동했다. 영상은 “휘발유를 사용하면 자동차” 같은 단순 규칙을 예로 들지만, 오늘날에는 전기차·소프트웨어·자율주행 기능이 결합되면서 고정 분류만으로 현실을 설명하기 어렵다고 지적한다.
따라서 중요한 것은 노드와 엣지를 한 번 그리는 일이 아니라, 새로운 객체·속성·관계가 들어올 때 모델이 함께 변할 수 있게 만드는 것이다.
4. 정적 분류표에서 Active Ontology로 · 03:19–04:47
Active Ontology는 저장된 정보를 검색하는 정적 데이터베이스를 넘어, 정보가 이동하고 관계를 만들며 서로에게 영향을 주는 동적 모델로 설명된다. 새로운 AI·에이전트·데이터가 계속 등장하는 환경에서는 관계 변화가 반영되어야 경쟁력이 있다는 주장이다.
화자는 온톨로지가 데이터셋에 탑재되면 검색과 추론 비용이 줄고 응답 속도와 컴퓨팅 비용이 개선될 수 있다고 말한다. 또한 일반 비즈니스에서는 80~90% 수준의 온톨로지로도 돌아갈 수 있지만 의료·생명처럼 중요한 영역은 100%에 가까 운 완성도가 필요하다고 주장한다.
수치 해석
80~90%, 100%는 영상에서 제시된 화자의 설명이며 측정 방법이나 외부 근거가 제공된 수치는 아니다. 실제 품질 기준으로 그대로 사용하면 안 된다.
3부. 그래프보다 먼저 데이터 품질
5. LLM 자동 그래프의 함정과 Garbage In · 04:48–06:27
PDF나 CSV를 LLM에 넣고 자동으로 그래프를 만들었다고 해서 환각이 사라지는 것은 아니다. 데이터 사이 관계, 접근 권한, 분류 기준을 잘못 생성하면 온톨로지 자체가 오류를 구조화할 수 있다.
좋은 구조와 화려한 도구를 사용해도 입력 데이터가 나쁘면 결과가 좋아질 수 없다. 영상은 공공데이터 포털의 데이터가 겉으로는 완전해 보여도 실제로는 빈 필드나 결측·부족한 값이 많을 수 있다고 지적한다.
따라서 필요한 것은 “살아 있고”, 실제 활용 가능하며, 출처를 다시 확인할 수 있고, AI가 읽고 쓸 수 있게 가공된 데이터다. 온톨로지 구축의 병목은 그래프 그리기보다 데이터를 분별하고 정제하는 능력이라는 메시지다.
6. 작은 CSV에서 시작하는 구축 연습 · 06:28–09:31
데이터가 아주 많아야 시작할 수 있다는 생각은 오히려 해가 된다고 말한다. 작은 CSV·PDF·Excel 하나를 선택해 필요한 필드를 추출하고, 필터링하며, 결과가 실제 질문에 맞는지 검증하는 편이 좋다는 조언이다.
전기차 충전소 데이터를 예로 들면 위치·가격·규모를 추출하고, 지역이나 충전소 규모·가격대에 따라 필터링한 뒤 적합도를 분석한다. 관계형 질의에는 SQL 또는 SPARQL, 그래프 확장에는 Neo4j, 벡터화에는 Chroma 같은 도구를 거론한다.
화자는 도구 사용법을 모두 깊이 외우지 않아도 LLM에 데이터 처리 방향을 자연어로 지시하며 배울 수 있다고 본다. 영상·이미지·바이브 코딩에 편중된 시장에서 데이터 엔지니어링 역량을 더하면 차별화될 수 있다는 시장 전망으로 이어진다.
4부. 기업과 피지컬 AI에서 왜 더 중요한가
7. 확률적 답변이 실제 행동이 될 때 · 09:33–12:11
개인이 AI 답변을 참고하는 수준이라면 사람이 마지막에 고칠 수 있다. 그러나 기업 보고서·전략·업무 프로세스에 적용하면 매번 사람이 다시 조사하고 수정해야 하므로 자동화의 이점이 줄어든다.
에이전틱 AI는 답변을 넘어 결제·삭제·메일 처리 같은 행동으로 이어질 수 있고, 피지컬 AI는 공장 로봇·배달 로봇·자율주행처럼 물리 세계에 영향을 준다. 이때 잘못된 출력은 금전적 손실이나 안전사고로 연결될 수 있다는 것이 화자의 우려다.
그래서 에이전트가 헤엄칠 “데이터 레이크”를 사실과 관계에 기반한 온톨로지 또는 월드 모델로 만들어야 한다고 설명한다. 자동화 수준이 높아질수록 실행 전에 참조할 세계 모델과 경계가 중요하다는 논리다.
8. 나열된 데이터가 관계 있는 지식이 되는 과정 · 12:12–16:21
원본 데이터는 값들이 나열되어 있을 뿐 서로의 관계나 위계를 모른다. 영상은 정보를 작게 나누고 비슷한 것끼리 모은 뒤, A가 B에 영향을 주고 B가 C·D와 연결되는 인과 관계를 붙이는 과정을 설명한다.
온톨로지 없는 LLM은 확률에 기대므로 좋은 답과 나쁜 답이 모두 나올 수 있지만, 관계 그래프를 가진 시스템은 생성 결과를 그래프와 교차 검증하고 맞지 않는 것을 필터링·수정할 수 있다고 주장한다.
영상의 구분에 따르면 온톨로지는 전체 세계의 규칙과 설계도이고, 지식 그래프는 그 설계도 위에서 실제 데이터와 관계가 연결된 결과다. Apple이라는 단어가 회사·창업자·CEO·제품·과일 등의 관계와 맥락으로 연결되는 예시를 통해 문자열 검색과 의미 기반 관계의 차이를 설명한다.
5부. 기업 온톨로지의 대상과 설계
9. Palantir·FDE와 도입이 시급하다고 보는 산업 · 16:22–17:46
화자는 기업 온톨 로지의 대표 사례로 Palantir를 든다. FDE가 기업 현장에 들어가 여러 데이터베이스와 업무를 분석하고, 온톨로지화한 뒤 Foundry·AIP 같은 환경 위에서 의사결정과 운영을 하게 만든다고 설명한다.
복잡한 공급망에서 벤더·물류·인과 관계가 연결되는 기업, 정밀한 판단이 필요한 금융·의료·법률, 로봇·자율주행을 다루는 피지컬 AI 기업, 방대한 데이터를 보유한 조직을 주요 적용 대상으로 꼽는다.
이 대목 역시 Palantir의 전체 제품·구축 방식에 대한 공식 설명이 아니라 화자가 영상에서 사용하는 개괄적 사례다.
10. 도메인 → 클래스 → 속성 → 관계 · 17:47–19:54
구축의 첫 단계는 온톨로지가 설명할 도메인을 정의하는 것이다. 건설·데이터·디자인처럼 경계를 정한 뒤 생산·설계·마케팅·물류·CS 같은 클래스를 추출한다.
각 클래스에는 가격·수량·위치·인력·역량 같은 속성을 부여한다. 다음으로 설계가 생산으로, 생산이 마케팅과 물류로, 물류와 CS가 다시 전략 피드백으로 이어지는 관계를 설정한다.
데이터를 한곳에 쏟아붓는 것만으로는 온톨로지가 아니다. 어떤 데이터가 어디에서 생성되고, 언제 필요하며, 누구 책임이고, 어느 과정에 영향을 주는지 연결되어야 조직의 운영 세계가 된다.
6부. 프롬프트에서 지속 가능한 지식 기반으로
11. 휘발성 프롬프트와 지속성 온톨로지 · 19:55–20:54
프롬프트는 순간적이다. 같은 문장을 다시 사용해도 같은 결과가 보장되지 않고, 좋은 프롬프트를 매번 그대로 재사용하기도 어렵다.
화자는 온톨로지를 조직의 중요한 규칙과 지식을 지속적으로 축적한 창고에 비유한다. 프롬프트가 한 번의 요청이라면, 온톨로지는 여러 요청에서 반복 참조하는 구조와 법칙이다.
이를 월드 모델과 비교하면서, AI가 생성할 때 물리 법칙이나 세계의 구조처럼 작동하는 강한 규칙층으로 활용할 수 있다고 설명한다.
12. 파싱에서 에이전트까지의 전체 파이프라인 · 20:55–24:31
문서·CSV 같은 원천 데이터가 도착하면 먼저 필요한 정보를 추출하는 파싱을 수행한다. 너무 큰 단위는 모델이 끝까지 다루기 어렵기 때문에 의미 있는 작은 단위로 나누는 청킹이 이어진다.
청크는 설계·제조·물류·마케팅·HR처럼 비슷한 의미 공간에 배치된다. 이 과정을 벡터화·임베딩으로 설명하고, 이후 각 데이터가 어떤 관계를 갖는지 그래프로 연결한다. 영상에서는 이를 기본 RAG 또는 GraphRAG 과정과 연결한다.
그 다음부터가 온톨로지 운영의 핵심이다. 데이터 위계와 의미 규칙을 정하고, 누가 어디까지 접근할 수 있는지 권한을 부여하며, 데이터와 에이전트가 협업할 오케스트레이션을 설계해야 실제 실행 계층이 완성된다.
영상 순서 기반 파이프라인
파싱 → 청킹 → 벡터화·임베딩 → 그래프 → 메타온톨로지·메타엣지 → RBAC → 에이전트·오케스트레이션
7부. 노드·엣지·메타온톨로지
13. 관계의 의미를 담는 엣지 · 24:32–27:43
벡터 공간에서 관련 데이터가 모이는 결절점을 노드로 보고, 노드 사이를 연결하는 선을 엣지로 설명한다. 하지만 엣지는 단순히 “A와 B가 연결됐다”에서 끝나지 않는다.
참여한다, 관리한다, 중지시킨다, 영향을 준다, 좋아한다처럼 관계의 동작과 의미가 들어가야 한다. 같은 두 객체라도 관계가 무엇인지에 따라 AI가 취해야 할 행동이 달라진다.
영상은 다양한 관계 유형을 통합하고 관리하는 문법을 메타엣지라고 부른다. 산업마다 처음부터 전부 다시 만들지 않고 제조·건설·디자인 등 여러 도메인에 적용 가능한 상위 문법을 만드는 것을 메타온톨로지로 설명한다.
14. RBAC로 세계의 경계를 세우기 · 27:47–29:13
그래프와 메타온톨로지가 있어도 누구나 모든 데이터에 접근하고 모든 관계를 바꿀 수 있다면 에이전트는 안전하게 작동하기 어렵다. 데이터의 위계, 영향 범위, 접근 주체를 정해야 한다.
영상은 역할 기반 접근 제어인 RBAC을 통해 어떤 사용자가 어떤 데이터에 접근할 수 있고, 어떤 정보는 특정 관계에 영향을 주면 안 되는지 경계를 세워야 한다고 말한다.
그 위에 에이전트가 올라간다. 즉, 에이전트가 먼저 자유롭게 행동한 뒤 제한을 붙이는 것이 아니라, 데이터와 관계·권한이 정의된 세계 위에서 실행하도록 설계하는 순서다.
8부. 에이전트 오케스트레이션과 외부 도구
15. LangChain·LangGraph·MCP·CLI 연결 · 29:14–31:45
온톨로지의 데이터를 LangChain이나 LangGraph 워크플로우로 조직하면 LLM·외부 도구·멀티모달 모델·프롬프트·MCP를 연결한 다단계 작업을 만들 수 있다고 설명한다.
에이전트 아래에 서브에이전트와 스킬이 붙으면서 업무 위계가 생기고, 외부 시스템은 API·MCP·CLI 같은 인터페이스로 연결된다.
화자는 최근 CLI 연결이 MCP보다 컨텍스트 누수와 토큰 낭비를 줄일 수 있다고 평가한다. 이는 영상 속 개인적 기술 판단이며, 실제 효율은 도구의 구현·권한·호출 패턴에 따라 별도 검증이 필요하다.
16. 두뇌와 팔다리가 함께 있어야 한다 · 31:46–32:38
AI 도구를 제각각 사용하면 결과의 기준과 맥락이 분산되지만, 온톨로지 위에 업무 시스템을 만들면 일관된 결과와 자동화를 유지할 수 있다고 주장한다. 개인의 머릿속 절차도 조직의 구조화된 자산으로 남길 수 있다는 관점이다.
온톨로지만 있고 에이전트가 없으면 실행할 팔다리가 없고, 에이전트만 있고 온톨로지가 없으면 두뇌와 세계관이 부족하다는 비유를 사용한다.
따라서 AX는 더 많은 에이전트를 추가하는 것만으로 완성되지 않는다. 잘 설계된 데이터 세계와 그 안에서 행동하는 정교한 에이전트가 연결되어야 한다는 결론이다.
9부. 조경 이미지에 적용한 화자의 사례
17. 이미지 지식화에서 검색·생성·모델링까지 · 32:39–36:29
화자는 건설·조경 업무의 Notion 이미지를 내려받아 CLIP으로 분석하고, 분석 결과와 이미지 사이 관계를 온톨로지에 저장하는 개인 시스템을 소개한다.
에이전트에 특정 조건의 수경 시설이나 아이들이 좋아할 놀이터를 요청하면, 데이터베이스의 이미지와 관계 정보를 바탕으로 후보를 찾는다. 이어 이미지 생성 모델로 공간을 그리거나, MCP로 모델링·식재 작업을 연결하는 흐름을 보여준다.
그는 과거 회사 데이터에서 숲의 구성, 수경 시설 반사, 휴게 공간 재료 선호 등을 분석해 렌더링에 반영한다고 설명하며 88%, 95% 같은 예시 수치를 말한다. 이 수치는 데이터셋·계산법이 제시되지 않은 시연 설명이므로 검증된 설계 기준으로 사용하면 안 된다.
데이터 유출을 줄이기 위해 로컬 GPT-OSS 모델을 사용하고, GraphRAG 기반 분석 프레임워크를 개발했다고 말한다. 자막상 프레임워크 이름은 “랭젠트”로 들리지만 정확한 저장소 표기는 확인하지 못했다. 마지막에는 Agent Korea 커뮤니티에서 온톨로지·코딩·에이전트를 토론한다고 소개하며 영상을 마친다.
【전략적 인사이트 분석 】
보완 설명 — 영상 내용 기반
아래는 영상의 주장·구축 순서·사례를 독자가 재사용하기 쉽게 해석한 내용이다. 화자의 직접 발언이나 외부 검증 결과가 아니다.
1. 온톨로지는 “더 많은 데이터”보다 더 명확한 책임과 관계의 문제다
영상의 실질적인 포인트는 데이터를 그래프로 예쁘게 그리는 데 있지 않다. 무엇이 무엇에 영향을 주고, 누가 만들고, 언제 필요하며, 누가 접근할 수 있는지 명시하는 것이 조직 적용의 핵심이다.
2. 에이전트 안전은 모델 뒤가 아니라 데이터 설계 앞단에서 시작한다
실행 후 사람이 검수하는 방식은 에이전트가 물리적·재무적 행동으로 확장될수록 비용이 커진다. 데이터 품질·관계·권한을 먼저 설계하고, 그 경계 안에서만 에이전트가 움직이게 하는 것이 영상이 제안하는 순서다.
3. GraphRAG와 온톨로지는 동일어가 아니다
파싱·청킹·임베딩·그래프는 관련 정보를 찾고 연결하는 검색 기반을 만든다. 온톨로지는 그 위에 의미 규칙·위계·권한·행동 가능 범위를 더한다. 그래프가 있다고 자동으로 조직의 세계관과 거버넌스가 생기는 것은 아니다.
4. 개인도 하나의 작은 도메인에서 시작할 수 있다
화자의 조경 사례처럼 이미지 라이브러리 하나, 고객 상담 기록 하나, 제품 카탈로그 하나를 도메인으로 잡을 수 있다. 작게 시작하되 클래스·속성·관계·권한·검증 질문을 명확히 하면 확장 가능한 기반이 된다.
5. 기회는 도구 사용법보다 도메인 지식의 구조화에 있다
Neo4j나 Chroma를 실행하는 기술만으로는 차별화가 제한적이다. 특정 산업의 데이터가 어떤 의미를 갖고 어떤 의사결정으로 이어지는지 설계할 수 있어야 실전 가치가 생긴다.
🔧 실전 적용 체크리스트
보완 설명 — 영상 기반 실행 순서
온톨로지가 답해야 할 좁은 도메인과 질문 하나를 정한다.
작은 CSV·PDF·Excel·이미지 묶음 하나로 시작한다.
빈 값·중복·오류·출처·갱신일을 점검해 입력 데이터 품질을 확인한다.
핵심 클래스를 정의한다. 예: 고객·상품·상담·계약·조치.
클래스별 속성을 정한다. 예: 가격·위치·상태·담당자·생성일.
관계를 동사로 표현한다. 예:
담당한다,구매한다,영향을 준다.데이터가 만들어지는 시점과 책임자를 연결한다.
파싱 → 청킹 → 임베딩 → 그래프 결과를 샘플 질문으로 검증한다.
자동 생성된 노드·엣지를 사람이 검토하고 잘못된 관계를 수정한다.
역할별 읽기·쓰기·실행 권한을
RBAC으로 구분한다.에이전트가 호출할 도구와 금지할 행동을 명시한다.
실패 시 중단·승인·롤백 지점을 워크플로우에 넣는다.
작은 업무에서 정확도와 유지 비용을 확인한 뒤 데이터 범위를 넓힌다.
🧩 핵심 개념 정리
Ontology: 개념·속성·관계·규칙을 정의해 도메인의 세계를 설명하는 설계 체계.
Active Ontology: 새 데이터와 상황에 따라 관계와 상태가 갱신되는 동적 온톨로지.
Node: 사람·제품·프로젝트·문서 같은 개념이나 객체가 자리 잡는 지점.
Edge: 두 노드가 어떤 관계인지 나타내는 연결. 단순 연결보다 관계의 의미가 중요하다.
Knowledge Graph: 실제 객체와 관계가 그래프 형태로 연결된 데이터 표현.
Meta-edge: 여러 관계 유형을 일관되게 표현하고 관리하는 상위 관계 문법이라는 영상의 설명.
Meta-ontology: 여러 산업·도메인에 재사용할 수 있는 상위 온톨로지 규칙이라는 영상의 설명.
Parsing: 문서나 표에서 필요한 구조와 값을 추출하는 과정.
Chunking: 큰 데이터를 모 델이 다룰 수 있는 의미 단위로 나누는 과정.
Embedding: 데이터의 의미적 유사성을 벡터 공간의 위치로 표현하는 방식.
GraphRAG: 그래프의 관계를 활용해 관련 맥락을 검색·조합하는 RAG 접근.
RBAC: 역할에 따라 데이터와 기능의 접근 권한을 제어하는 방식.
Orchestration: 여러 에이전트·모델·도구·단계를 하나의 실행 흐름으로 조정하는 설계.
FDE: 영상에서 Palantir의 현장 엔지니어 역할을 설명할 때 사용한 명칭.
🧒 Feynman식 설명
보완 설명 — 영상 내용 기반 비유
온톨로지가 없는 에이전트를 처음 온 배달 기사라고 생각해 보자. 오토바이도 있고 속도도 빠르지만, 도시 지도가 없고 어느 길이 일방통행인지, 어느 건물에 누가 들어갈 수 있는지 모른다. 빨리 달릴수록 더 위험해질 수 있다.
데이터는 도시 안의 건물과 사람이다. 노드는 건물·창고·고객이고, 엣지는 “이 창고가 이 가게에 물건을 보낸다”, “이 직원이 이 구역을 담당한다” 같은 도로와 규칙이다.
지식 그래프는 실제 지도에 건물과 도로를 그린 모습이다. 온톨로지는 그보다 한 단계 위에서 “병원은 무엇이고, 응급차는 어느 길을 우선할 수 있으며, 누가 통제실에 들어갈 수 있는가”를 정한 도시 운영법이다.
RBAC은 출입증 체계다. 모든 기사가 모든 창고 문을 열 수 없게 한다. 오케스트레이션은 관제센터다. 어떤 기사가 어떤 주문을 맡고, 어느 도구를 쓰며, 문제가 생기면 누구에게 승인받을지 정한다.
에이전트는 빠른 기사이고 온톨로지는 지도·교통법·출입증·관제 규칙이다. 좋은 시스 템은 기사 수만 늘리는 것이 아니라, 기사들이 안전하게 움직일 도시를 먼저 만드는 것이다.
🔚 가장 중요한 마지막 인사이트
복습 공식
좋은 에이전트 시스템 = 정제된 데이터 × 명확한 관계 × 검증 가능한 규칙 × 최소 권한 × 실행 오케스트레이션
보완 설명 — 영상 내용 기반: “온톨로지 시대”라는 전망보다 실용적으로 남겨야 할 것은 에이전트를 도입하기 전에 작은 도메인의 데이터·관계·권한부터 명시하라는 구축 순서다. 온톨로지는 환각을 자동으로 없애는 마법이 아니라, 잘못된 입력과 관계를 더 빨리 발견하고 에이전트의 행동 범위를 통제하기 위한 운영 기반이다.
