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

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

제네시스랩 유대훈 CTO가 제안하는 슬립박스는 온톨로지를 자연어 페이지로 풀어 쓰고 연결 구조는 DB로 관리해, 현업 전문가가 AI의 업무 지식을 직접 이해하고 수정하게 하는 접근이다.

📌 핵심 요점

1. 개발 병목은 조직 간 인계에서 발생했다. 현업 전문가·AI 연구원·서비스 개발팀을 거치면서 운영 배포에 약 2주, 간단한 프롬프트 수정에도 약 1주가 걸렸다. 현업 담당자가 직접 설정하고 연구팀과 함께 수정하는 환경에서는 일부 작업을 하루 만에 테스트할 수 있었다.
2. 사람에게는 자연어 페이지를, 구조 관리에는 DB를 사용한다. 업무 관계와 규칙은 문서처럼 작성하고, 목차·계층·연결은 DB가 관리한다. 에이전트에는 이를 마크다운으로 렌더링해 전달하며, LLM이 자연어 설명을 해석하도록 한다.
3. 기존 데이터를 옮기기보다 접근할 지도를 만든다. DB 스키마와 샘플 데이터를 바탕으로 테이블의 의미와 의존 관계를 정리한다. 현업 담당자는 조직별 용어 정의, 기간 필터, 조회 금칙 등을 페이지에 보완할 수 있다.
4. 지식 조회와 실행을 연결하고 수정 지점을 드러낸다. 모듈·버전 단위로 관리하는 워크플로인 ‘어빌리티’를 페이지에 연결하면 DB 조회 같은 작업을 실행할 수 있다. 단계별 입출력과 참조 페이지를 확인해 잘못된 업무 맥락을 수정하는 방식이다.
5. 자동 생성 이후의 검증과 운영이 핵심이다. 업무 질문과 정답 데이터셋으로 결과를 확인하고 벌크 테스트를 반복해야 한다. 임베딩과 RAG도 유지하며, 데이터 변화 주기와 형식화 필요성에 따라 슬립박스 및 기존 시스템과 병행한다.

🧩 배경과 문제 정의

• 제네시스랩은 채용, 인터랙티브 AI, 정신 건강 자가 평가 등의 서비스를 개발하면서 여러 AI 모델과 고객별 업무 흐름을 함께 운영해 왔다.
• AI 서비스는 배포 이후에도 예상하지 못한 사용 방식에 맞춰 수정해야 한다. 도메인 전문가, AI 연구원, 서비스 개발팀을 차례로 거치는 구조에서는 작은 변경에도 시간이 오래 걸렸다.
• 기업의 기존 데이터 시스템을 유지하면서 현업 전문가가 지식과 업무 관계를 직접 이해하고 수정할 방법이 필요했다. 슬립박스는 이를 자연어 페이지와 DB 기반 구조 관리로 해결하려는 접근이다.

🕒 시간순 섹션별 상세정리

1. AI 서비스의 수정 속도를 늦추는 세 조직의 인계 구조

• 도메인 전문가가 요구사항을 정리하고 AI 연구원이 프로토타입을 만들면, 서비스 개발팀이 확장성과 트래픽 처리를 갖춘 운영용 서비스로 다시 구현했다. 이 운영 배포 과정에 약 2주가 걸렸다. [04:07]
• AI는 불확실성이 있고 사용자가 예상대로 사용하지 않기 때문에, QA 통과와 배포만으로 개발이 끝나지 않는다. 운영 이후에 드러난 문제는 현업 전문가의 판단을 다시 필요로 한다. [04:26]

2. 현업 전문가의 직접 수정이 범용 에이전트 빌더로 이어지다

• 크리에이터 에이전트용 스튜디오에서는 현업 담당자가 프롬프트와 지식 체계를 설정하고, 연구팀과 같은 화면을 보면서 수정할 수 있게 했다. 일부 작업은 하루 만에 테스트할 수 있었다. [05:33]
• 에이전트는 지속적으로 수정되는 워크플로이며 LLM 교체에도 대응해야 한다. 여러 서비스의 공통 기반을 범용 에이전트 빌더로 만들 필요가 생겼다. [06:00]

3. 모듈별 버전 관리와 API 배포가 자체 개발의 기준이 되다

• 기존 도구를 검토했지만, 당시에는 버전을 구분해 API로 배포하는 기능이 요구사항을 충족하지 못했다. 재사용할 기능을 모듈로 나누는 것도 필수였다. [06:35]
• 한곳에서 작업하더라도 모듈별 버전을 달리해 개발·스테이징 환경에 각각 배포하고, API 키까지 관리할 수 있어야 했다. [07:06]

4. 어빌리티와 에이전트 계층을 나누고 데이터 계층을 보완하다

• 워크플로를 에이전트의 능력이라는 의미의 ‘어빌리티’로 정의했다. 어빌리티는 모듈과 버전으로 관리하고, 다른 어빌리티 안에서 하나의 노드로 재사용할 수 있다. [08:14]
• 에이전트 계층에서는 에이전트 노드에 어빌리티나 일반 노드를 연결해 도구로 사용한다. 기능을 만드는 계층과 그 기능을 활용하는 계층을 구분한 구조다. [09:13]

5. 데이터를 옮기기보다 기존 시스템에 접근할 지도를 만들다

• 초기 온톨로지 구상은 파편화된 DB와 API의 사용법을 모은 지도였다. 필요한 데이터가 어느 테이블에 있는지, 어떤 API를 호출해야 하는지 알려주면 에이전트가 이를 따라 접근하는 방식이다. [10:07]
• CTO가 이후 공개 자료를 통해 이해한 팔란티어 방식은 데이터를 데이터 레이크로 모으고 그 위에 온톨로지를 구축하는 구조였다. 이를 실시간에 가깝게 동기화하려면 큰 인프라와 기술적 부담이 필요하다고 판단했다. [10:54]

6. 마크다운의 가독성과 DB의 정합성을 결합하다

• 기계가 이해할 구조와 쿼리를 직접 작성하는 온톨로지 문법은 개발자에게도 어려웠다. 반면 클로드 스킬과 파일 접근 방식에서는 사람이 이해하기 쉬운 텍스트를 AI도 효과적으로 활용할 수 있다는 가능성을 봤다. [11:55]
• 파일 검색 대신 DB 검색을 활용하는 구상에 위키형 지식 관리 방식을 결합했다. 검토한 방식에서는 목차가 200개를 넘을 때의 성능 저하, 제목 변경이나 중복에 따른 연결 오류, 이를 검사하는 린트의 토큰 사용량이 문제였다. [12:38]

7. 관계와 업무 규칙을 자연어로 쓰는 슬립박스

• 슬립박스는 관계를 설명하는 페이지를 연결하는 방식으로 구성됐다. 복잡한 온톨로지 표준을 고객에게 설명하는 부담을 줄이려는 선택이다. [14:55]
• 계약 관계나 업무상의 관계를 평소 업무 문서처럼 글로 쓰면, LLM이 이를 해석하도록 한다. CTO는 이 역할을 LLM이 ‘컴파일’해 주는 것으로 표현했다. [15:18]

8. DB 스키마와 샘플 데이터로 탐색의 출발점을 만들다

• 인제스트 대상을 파일뿐 아니라 DB와 외부 서비스로 넓혔다. DB에서는 테이블 스키마를 먼저 확인해 데이터 구조를 파악한다. [16:53]
• 테이블명·컬럼명·코멘트만으로 의미가 명확하지 않으면 데이터를 일부 샘플링해 의미를 추정한다. 약어 등으로 불명확한 컬럼명을 보완하기 위한 절차다. [17:25]

9. 업무 용어의 정의로 같은 단어의 다른 의미를 구분하다

• 같은 용어도 분야나 조직에 따라 의미가 달라질 수 있다. ‘파리’라는 지명이 여러 나라에 존재하듯, 실제 업무에서 어떤 대상을 뜻하는지 명시해야 한다. [18:18]
• 합성 데모 데이터를 인제스트한 사례에서는 내부 용어와 설명을 함께 정리했다. LLM에 “이 용어는 이렇게 쓰인다”는 정의를 주어, 현업 사용자가 쓰는 표현을 해당 맥락으로 해석하게 한다. [19:02]

10. 대용량 조회의 금칙과 용어 오류를 사람이 수정하다

• 센서 데이터처럼 계속 누적되는 테이블을 잘못 전수 조회하면 메모리와 LLM이 처리할 수 있는 범위를 넘을 수 있다. [19:42]
• 이런 테이블에는 기간 필터를 적용해야 한다는 조건이나 조회 금칙, 허용하지 않는 연산을 지식으로 남긴다. [20:01]

11. 사람은 페이지를 읽고 DB는 연결의 정합성을 관리하다

• 위키처럼 관계를 따라가며 읽을 수 있으면 사람이 전체 구조를 이해하기 쉽다. 지식의 연결을 사람이 검토할 수 있다는 점이 페이지 방식의 장점이다. [20:43]
• 계층과 연결 블록은 DB에서 관리하고 에이전트에 전달할 때 마크다운으로 자동 렌더링한다. 구조를 DB로 관리해 연결의 정합성을 확보하고 오류를 줄이려는 방식이다. [21:04]

12. 원문 보존과 토픽 기반 목차 생성으로 문서를 인제스트하다

• 원문 보존 방식은 내용을 다시 쓰기보다 원문을 나누고 적절한 위치에 넣는 역할에 집중한다. 글자 하나의 변경도 문제가 될 수 있는 법률 문서 등을 고려한 방식이며, 마크다운의 모양은 덜 정돈될 수 있다. [23:09]
• 내용을 합성하는 방식도 제공하며, 문서를 토픽별로 나누고 그에 맞는 트리형 목차를 만든다. 긴 PDF 안의 다양한 주제를 구조화하기 위한 처리다. [23:35]

13. 도메인 질문과 검증 데이터셋으로 품질을 평가하다

• 인제스트 결과와 에이전트를 검증하려면 검증용 데이터셋이 필요하다. 자동으로 구조화됐다는 사실만으로 정확성을 보장할 수는 없다. [24:56]
• 도메인 전문가는 중요한 업무 질문을 던져 필요한 정보나 절차를 제대로 찾아내는지 먼저 확인할 수 있다. [25:03]

14. 제로 클릭으로 초기 테스트를 돕고 반복 검증으로 안정성을 높이다

• ‘제로 클릭’ 기능에서는 도움을 주는 에이전트에 합성 입력 생성과 테스트를 요청할 수 있다. 채팅 테스트에서 에이전트끼리 대화를 주고받도록 구성하는 것도 가능하다. [26:13]
• 테스트 입력은 대상 에이전트를 분석해 생성한다. 심리 상담 에이전트라면 건강한 사람 등 특정 페르소나로 대화를 진행하고, 종료 후 수정 방향을 안내하는 식이다. [27:37]

15. 임베딩을 유지하면서도 모델 변경에 따른 부담을 고민하다

• 슬립박스와 별개로 데이터 스토리지에는 임베딩 기능이 있다. 특정 텍스트 컬럼을 임베딩 필드로 지정하고 모델을 선택해 처리할 수 있으므로, 임베딩을 전면 포기한 구조는 아니다. [29:20]
• 기존 RAG 프로젝트에서는 데이터가 바뀌지 않을 때보다 임베딩 모델을 바꾸려 할 때 운영상의 고민이 커졌다. [29:36]

16. 데이터 변화 주기에 따라 임베딩과 슬립박스를 병행한다

• 임베딩 모델을 바꾸면 기존 이력까지 고려해야 하고, 전체 동작에 대한 회귀 테스트도 어렵다. 데이터 수정 때마다 임베딩이 필요한 구조에서는 변경을 지속적으로 감당하는 부담도 생긴다. [30:28]
• 데이터가 거의 정적이고 1년에 한 번 정도 바뀐다면 임베딩은 속도와 적합성 면에서 유리하지만, 일주일이나 한 달 단위로 바뀌면 운영 부담을 감당할 수 있을지 의문이 제기된다. GPU 서버와 고객 측 모델 관리도 선택의 제약이다. [30:54]

17. 자동 생성한 지식 그래프를 목차와 키워드로 탐색한다

• DB에서 인제스트한 데이터는 슬립박스 노드로 구성되며, 노드 사이의 연결과 그래프도 자동으로 만들어진다. 에이전트는 이 구조를 목차부터 탐색한다. [32:29]
• 목차의 깊이가 깊으면 호출 횟수가 늘어나 초기 탐색 속도가 느려진다. 이를 보완하기 위해 검색 노드에서 키워드로 찾는 도구도 제공한다. [33:01]

18. 지식 페이지에 실행 기능을 연결하고 입출력을 추적한다

• 슬립박스 페이지에 어빌리티를 연결하면 지식 조회에 이어 실행까지 가능하다. 진행 중인 딜 현황을 요청한 예시에서는 관련 페이지를 찾아 실행하고, 연결된 DB 조회 워크플로의 결과를 받아 출력한다. [34:26]
• 전략 고객을 표 맨 위에 모아 달라는 추가 요청에 따라 다시 탐색해 결과를 구성한다. 각 단계의 입력과 출력을 확인하면 에이전트나 슬립박스의 어느 부분을 수정해야 하는지 판단할 수 있다. [35:26]

19. DB를 인제스트한 뒤 업무 질문으로 구조와 연결을 검증한다

• DB 접속 자격 증명을 별도로 관리하고, 대상 DB와 사용할 어빌리티 등을 선택해 인제스트한다. 별도 스키마를 미리 준비하지 않아도 동작하며, 생성된 페이지에서 구조를 확인할 수 있다. [36:11]
• 생성 결과를 일일이 확인하기 어려울 때는 슬립박스 에이전트에 업무 질문을 던져 페이지의 내용과 관계를 점검한다. 도메인을 아는 사람이 구체적으로 질문하면 무엇을 할 수 있고 제대로 동작하는지 확인하는 데 도움이 된다. [36:45]

20. Text-to-SQL 오류는 관련 페이지의 업무 맥락을 보완해 교정한다

• DB를 직접 활용하려는 Text-to-SQL 수요는 크지만, 쿼리가 잘못 생성됐을 때 사용자가 취할 수 있는 조치는 제한적이다. DB 정보가 개발 문서나 코드에 묶여 있고 시스템 프롬프트에 크게 의존하는 점이 문제로 지적된다. [38:31]
• 같은 ‘사업자 번호’라도 테이블별 의미가 다를 수 있다. 관련 테이블의 설명을 모두 프롬프트에 넣기에는 양이 많으므로, 인제스트로 생성된 각 슬립박스 페이지에 해당 의미를 한두 줄씩 보완하는 방식을 제안한다. [39:00]

21. 개인의 AI 활용을 회사의 지식 자산으로 축적한다

• 기업은 AI 사용 과정에서 정보가 학습에 쓰일 수 있다는 우려를 겪고, 도입 이후에는 체감 생산성과 전 직원의 이용 비용을 비교하며 투자 대비 효과를 고민한다. [41:04]
• 개인이 만든 프롬프트를 회사에 공유하지 않겠다는 사례는 활용 성과의 소유와 공유 규칙이 필요함을 드러낸다. 기업의 역량을 높이려면 개인의 AI 숙련도에만 의존하지 않고, 성과를 시스템과 자산으로 축적해야 한다는 관점이다. [41:57]

22. MCP로 개인 도구와 조직의 공유 자산을 연결한다

• 슬립박스 노드를 어빌리티로 만들면 MCP 서버의 도구로 제공할 수 있다. 이를 개인 클로드에 연결해 사용하고, 슬립박스에 쓰는 도구도 활용할 수 있다. [43:06]
• 개인 작업을 정리할 때 개인용 스킬로 남기는 동시에 조직의 슬립박스 자산에도 연결하는 활용을 구상한다. 같은 기능을 도구나 에이전트로 사용할 수 있도록 여러 연결 방식을 고려한다. [43:29]

23. AI가 발전해도 책임과 수정 가능성은 사람에게 남는다

• AI의 성능이 높아져도 책임은 사람이나 기업이 져야 할 것으로 본다. 중요한 의사결정에서는 사람이 승인하는 역할이 남을 수 있으며, 그러려면 AI가 만든 결과를 이해할 수 있어야 한다. [45:03]
• 문제가 발생하면 사후에라도 내부 과정을 살펴 원인을 찾고, 어떻게 바꿀지 사람이 결정할 수 있어야 한다. 결과의 이해와 원인 파악은 AI가 뛰어나져도 필요한 조건이다. [45:39]

24. 흩어진 업무 자료를 AI가 활용하는 자산으로 모은다

• 에이전트리아 웹사이트에는 메일과 연결을 통한 문의 경로가 안내돼 있으며, 서비스를 직접 확인하거나 설명을 요청할 수 있다. [46:51]
• 슬립박스의 최종 활용 방향은 흩어진 PPT·엑셀 등 비정형 자료를 모아 AI가 활용할 수 있는 자산으로 만드는 것이다. 글로 온톨로지를 구성하는 접근이 이러한 기업 지식의 정리와 활용 수단으로 드러난다. [47:24]

🧾 결론

• 슬립박스의 핵심은 업무 지식을 사람이 읽고 고칠 수 있는 페이지로 표현하면서, 연결 구조의 정합성을 DB로 관리하는 데 있다.
• 자연어 온톨로지는 제네시스랩이 제안하는 접근이다. 엄밀한 형식화가 필요한 부분은 기존 시스템과 연결하고 별도로 다룬다.
• 지식을 자동으로 정리하는 것만으로 정확성이 보장되지는 않는다. 현업 전문가의 검토와 반복 테스트가 운영의 필수 조건이다.
• 개인의 프롬프트와 업무 노하우를 조직의 공유 자산으로 축적하고, 문제가 생겼을 때 사람이 원인을 파악하고 수정할 수 있어야 한다.

📈 투자·시사 포인트

• 기업용 AI 도입을 평가할 때 모델 성능과 함께 현업 담당자의 수정 가능성, 변경 배포 시간, 검증 비용을 살펴볼 필요가 있다.
• 기존 시스템을 활용하는 방식은 데이터 이전과 데이터 주권에 대한 기업의 부담을 고려한 선택이다. 실제 도입에서는 연결·운영에 필요한 부담까지 확인해야 한다.
• 임베딩과 슬립박스의 선택에는 데이터 변경 주기와 모델 교체 부담이 영향을 준다. 정적인 자료와 자주 바뀌는 업무 지식을 구분해 운영 방식을 검토할 수 있다.
• 조직의 AI 활용 성과를 축적하려면 이용 비용과 체감 생산성뿐 아니라 지식 공유 규칙, 지속적인 관리, 책임 소재도 함께 다뤄야 한다.

⚠️ 불확실하거나 확인이 필요한 부분

• 약 2주·약 1주·하루라는 기간은 소개된 내부 경험이다. 동일한 개선 폭이 다른 업무나 기업에서도 나타나는지는 확인되지 않았다.
• 자연어 페이지 방식과 다른 온톨로지·검색 방식의 정확도, 응답 속도, 운영 비용을 비교한 정량 결과는 제시되지 않았다. 깊은 목차에서는 탐색 호출이 늘어나는 한계도 언급됐다.
• 팔란티어의 구조에 관한 설명은 CTO가 공개 자료를 통해 이해한 내용이다. 해당 제품의 전체 구현이나 적용 방식을 확정하는 근거로 삼기에는 제한이 있다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 실제 업무에서 중요한 질문과 기대 결과를 모아 검증용 데이터셋을 만든다.
• 대상 DB의 스키마와 샘플 데이터를 확인하고, 모호한 컬럼명·내부 용어·테이블별 의미를 페이지에 명시한다.
• 대용량 테이블의 기간 필터, 금지 연산, 조회 시 주의사항을 업무 지식에 기록한다.
• 잘못된 답변이 나오면 참조 페이지·생성 쿼리·단계별 입출력을 확인하고 누락된 맥락을 수정한 뒤 재검증한다.

❓ 열린 질문

• 자연어로 설명한 관계와 규칙은 어느 수준까지 안정적으로 해석되며, 어떤 업무부터 엄밀한 형식화가 필요할까?
• 페이지와 연결이 늘어날 때 목차 탐색·키워드 검색의 속도와 정확도는 어떻게 달라질까?
• 여러 현업 담당자가 지식을 수정할 때 승인 책임과 검증 기준을 어떻게 운영해야 할까?