"온톨로지를 말로 풀어서 쓰면 됩니다" 딥러닝 10년 CTO가 만든 방법 (제네시스랩 유대훈 CTO님)

빌더 조쉬 Builder Josh · 2026-10-20 17:08 · 48:10

제품·창업 프롬프트·스펙 작성

YouTube에서 보기

한 줄 핵심

온톨로지를 그래프 중심으로만 보지 말고 말과 마크다운으로 풀어 LLM이 컴파일하게 만들면, 흩어진 기업 시스템과 데이터를 현업이 직접 다루는 실용적인 에이전트 플랫폼을 빠르게 만들 수 있다.

시간별 요약

0:00
하이라이트 온톨로지는 반드시 거대한 그래프로 만들 필요가 없고, 관계를 말로 설명하면 LLM이 이를 해석해 컴파일할 수 있다. 슬립박스는 현업이 페이지를 보며 용어와 관계를 직접 수정하고, 에이전트가 이를 바탕으로 판단하는 구조로 동작한다.
0:38
오프닝: 온톨로지, 대체 어떻게 만들까 온톨로지를 실제로 어떻게 만들고 운영하는지에 대한 감이 부족하다는 문제의식에서 대화가 시작된다. 영상은 그 구조와 구현 방식을 실무 관점에서 풀어내는 데 초점을 둔다.
1:05
게스트 소개: 제네시스랩 유대훈 CTO 제네시스랩은 10년 가까이 딥러닝을 연구하며 면접 분석, 음성 인식, 음성 합성, AI 휴먼 등 다양한 모델을 만들어 왔다. 지금은 그 경험을 모아 기업용 에이전트 빌더를 개발하는 데 집중하고 있다.
2:37
에이전트 빌더 에이전트리아를 만든 이유 기존 서비스들은 현업 전문가와 AI 연구원, 개발팀이 분리된 채로 운영돼 배포 후 수정에 긴 시간이 걸렸다. 현업이 직접 설정하고 바로 테스트하는 환경이 필요했고, 그 필요가 범용 에이전트 빌더로 이어졌다.
4:18
세 팀이 2주 걸리던 일을 하루 만에 AI 서비스는 배포가 끝이 아니라 시작이며, 실제 사용 후 불확실성 때문에 계속 손봐야 한다. 현업, AI 연구, 개발이 따로 움직이는 구조에서는 작은 수정도 1주 이상 걸릴 수 있어, 한 화면에서 함께 수정·검증하는 방식이 필요해졌다.
6:34
n8n 대신 직접 만든 이유: 버전 관리와 API 배포 기존 툴들도 검토했지만 모듈별 버전 관리와 API 배포, 스테이징·개발 환경 분리, 보안 키 관리까지 충족하지 못했다. 결국 내부에서 쓰기 위해 직접 만들기 시작한 것이 현재의 에이전트 빌더다.
7:54
슬립박스와 어빌리티란? 워크플로우를 단순한 흐름이 아니라 에이전트의 능력 단위인 어빌리티로 본다. 어빌리티를 모듈화하고 다시 다른 어빌리티의 노드로 재사용할 수 있게 하여, 에이전트가 툴처럼 조합되는 구조를 만든다.
9:33
온톨로지는 흩어진 시스템과 API의 지도 온톨로지는 고객사의 분산된 데이터 시스템과 API가 어디에 있고 어떻게 접근해야 하는지를 설명하는 지도처럼 정의된다. 에이전트는 이 지도를 보고 필요한 데이터와 접근 경로를 찾아간다.
10:48
팔란티어식 Data Lake 대신, 기존 시스템 그대로 팔란티어식 접근은 모든 데이터를 데이터 레이크로 모은 뒤 그 위에 온톨로지를 올리는 방식이지만, 중견기업에는 인프라와 자산 이전 부담이 크다. 그래서 기존 시스템을 최대한 그대로 쓰는 방향이 현실적이라고 본다.
11:51
왜 마크다운인가: Claude Skills와 LLM Wiki 기계 친화적 구조보다 사람이 읽고 수정하기 쉬운 마크다운이 실무에 더 적합하다는 판단이 나온다. 파일 시스템과 문서를 LLM이 잘 다루는 방식을 보며, 마크다운을 DB와 함께 쓰는 구조로 옮겨간다.
13:33
목차가 200개를 넘으면: 트리와 DB로 관리 목차가 커지면 트리 구조만으로는 성능과 정합성 문제가 생기므로 DB로 관리하는 쪽이 유리하다. 다만 에이전트 입력을 위해서는 다시 마크다운 형태로 렌더링해 주는 방식이 필요하다.
14:55
온톨로지를 말로 쓰면 LLM이 컴파일한다 = 슬립박스 복잡한 온톨로지 규칙을 그대로 강제하기보다, 업무를 설명하듯 글로 쓰면 LLM이 이를 컴파일해 이해하도록 만든다. 슬립박스는 이런 방식으로 관계 페이지를 구성한 결과물이다.
16:07
슬립박스 화면: 인제스트부터 용어 정의까지 슬립박스는 파일뿐 아니라 DB, 디스크 등 다양한 소스를 인제스트하고, 테이블 스키마와 샘플 데이터를 보고 구조를 추론한다. 용어 정의와 관계를 명시적으로 적어두면, 같은 단어가 도메인마다 다르게 쓰이는 문제도 줄일 수 있다.
19:42
쿼리 금칙과 사람이 고치는 페이지 대용량 누적 데이터에는 기간 필터 같은 조회 금칙이 필요하며, 그렇지 않으면 메모리와 모델이 감당하지 못한다. 자동 생성된 규칙도 사람이 페이지에서 직접 수정할 수 있어야 운영이 가능하다.
21:33
모든 걸 그래프로 만들 필요는 없다 관계와 절차를 모두 그래프로 만들 필요는 없고, 페이지 단위의 서술만으로도 충분히 온톨로지 역할을 할 수 있다. 핵심은 사람이 이해 가능한 방식으로 관계를 풀어내는 데 있다.
22:34
변환 품질 검증: 원문 보전·합성 인제스트 법률처럼 원문 훼손이 치명적인 경우에는 원문 보전 인제스트를 사용해 내용과 위치를 최대한 유지한다. 목차가 불완전하거나 틀린 문서는 합성 인제스트로 주제를 다시 뽑아 목차를 재구성한다.
24:16
로펌이라면 평가는? Validation Dataset과 벌크 테스트 인제스트 결과를 검증하려면 Validation Dataset이 필요하고, 질문 기반 점검과 벌크 테스트로 정답 일치 여부를 확인해야 한다. AI 작업은 결국 데이터셋을 만들어 비교하는 과정이 핵심이다.
25:58
제로클릭: 에이전트가 스스로 하는 채팅 테스트 제로클릭 기능은 입력 데이터를 합성해 에이전트가 스스로 채팅 테스트를 수행하도록 돕는다. 비개발자도 초기 구축 단계에서 대화형 시나리오를 빠르게 검증할 수 있다.
28:36
RAG·임베딩 대신 슬립박스를 쓴 이유 RAG와 임베딩은 데이터가 바뀌지 않을 때는 좋지만, 모델이나 문서가 자주 바뀌면 전면 재처리가 필요해 운영 부담이 커진다. 슬립박스는 정적인 부분은 데이터 스토리지와 임베딩을 쓰고, 자주 바뀌는 부분은 문서 기반 구조로 풀어 하이브리드로 운영한다.
30:54
자주 바뀌는 지식은? 하이브리드 구조 정적 데이터는 임베딩과 RAG가 효율적이지만, 주 단위나 월 단위로 바뀌는 지식은 모델 교체와 재인덱싱 비용이 크다. 그래서 슬립박스로 풀 수 있는 영역과 기존 시스템을 함께 쓰는 하이브리드 전략이 현실적이다.
32:09
시연 ①: DB 그래프에서 에이전트 구성·딜 현황 보고까지 DB를 인제스트하면 자동으로 노드와 그래프가 생성되고, 에이전트는 목차부터 탐색해 필요한 어빌리티를 실행한다. 진행 중인 딜 현황 같은 요청도 페이지 탐색과 DB 조회를 거쳐 결과를 출력할 수 있다.
36:03
시연 ②: DB 인제스트·품질 질문·Text-to-SQL DB 크레덴셜과 어빌리티를 선택해 인제스트하면 페이지가 자동 생성되고, 그 구조를 바탕으로 품질 질문과 설명 확인을 할 수 있다. Text-to-SQL이 잘 되려면 페이지 단위의 맥락 정보와 용어 정의가 충분히 주입돼야 한다.
40:26
어떤 도메인에 쓰면 좋을까 이미 범용 AI 앱이 잘하는 영역보다, 조직 내부에 흩어진 데이터와 도메인 지식이 많은데 정리되지 않은 곳에서 가치가 크다. 특히 AI 도입은 했지만 ROI가 안 나오고, 개인별 프롬프트가 자산화되지 않는 조직이 주요 대상이다.
42:19
다음 화두는 자산화: 슬립박스와 MCP 서버 핵심은 개인의 AI 활용이 아니라 회사 전체의 자산화와 시스템화다. 슬립박스를 MCP 서버로도 제공해 Claude 같은 외부 도구와 연결하고, 툴·에이전트 양쪽에서 재사용할 수 있게 한다.
44:20
마지막 한마디: 책임은 결국 사람이 진다 AI가 아무리 발전해도 중요한 결정의 책임은 사람과 기업이 져야 한다. 따라서 결과를 블랙박스로 두지 말고, 사람이 이해하고 수정할 수 있는 구조를 유지해야 한다.
46:44
도입 문의와 마무리 에이전트리아 AI에서 도입 문의와 안내를 확인할 수 있다. 슬립박스를 활용하면 흩어진 비정형 데이터를 빠르게 자산화하고, 기업용 온톨로지를 실무적으로 구성할 수 있다.

실무 인사이트

온톨로지를 거대한 그래프 모델로만 보지 말고, 현업이 쓰는 언어와 문서 구조로 풀어야 실제 운영과 수정이 가능하다.
AI 시스템의 성공 조건은 모델 성능만이 아니라, 현업이 직접 검증하고 고칠 수 있는 버전 관리·테스트·설명 가능성까지 포함한다.
자주 바뀌는 도메인에서는 RAG 하나로 밀기보다, 정적 지식과 동적 지식을 나누는 하이브리드 설계가 운영 부담을 크게 줄인다.