좋은 지식베이스보다 중요한 것은 쓰임새가 명확한 온톨로지 설계
컨설팅 프로젝트, 회사 자료 100GB, 이미지 1000장 같은 사례가 이어졌지만 결론은 비슷했다. 자료를 한꺼번에 넣는 것보다 목적, 카테고리, 도메인 문법을 먼저 나누는 쪽이 실제 업무 가이드에 더 가깝다.
방 헤더 · 2026-06-04
OpenCrab 꽃게잡이 어선(커뮤니티)
오늘의 한 문장: 스킬은 절차와 행동을 알려주지만 온톨로지는 도메인 맥락을 깊게 제공한다. 다음 실험은 서로 다른 온톨로지 팩을 가진 에이전트들이 같은 문제를 병렬로 풀 때 답변 품질과 설명가능성이 어떻게 바뀌는지 보는 것이다.
350메시지
38참여자
2주요 주제
2짧은 기록
대화 타임라인
-
1
OpenCrab 데스크탑과 온톨로지 빌딩이 하루의 중심이 됐다
오전에는 Pro/Expert 플랜과 데스크탑 앱 출시, 오후에는 로컬크랩과 오픈크랩의 역할 차이, 밤에는 온톨로지 팩을 분리해 에이전트 토론과 병렬 분업에 쓰는 아이디어로 대화가 확장됐다.
핵심 논쟁
주제별 깊이 읽기
1
Ontology Tooling
OpenCrab Desktop과 로컬크랩의 역할 분리
왜 중요한가
데스크탑 앱이 나오면서 로컬크랩을 어려워하던 사용자를 위한 온톨로지 빌딩 진입로가 생겼다.
깊이 보기
OpenCrab 방의 6월 4일 대화는 제품 온보딩에서 실제 운영 질문으로 빠르게 넘어갔다.
- 오전 9시대 Alexai는 OpenCrab Desktop을 완성했고, 이제 팩 빌딩을 별도 로컬크랩 없이 데스크탑 앱에서 할 수 있다고 안내했다.
- 링크는 https://opencrab.sh/desktop 이다.
- 이어 Hermes desktop 설치파일과 비교가 나오면서, AI 하네스와 지식도구가 CLI에서 데스크탑 앱으로 내려오고 있다는 흐름도 확인됐다.
- 핵심은 로컬크랩과 오픈크랩의 역할 차이다.
- 로컬크랩은 원본 지식을 보존하면서 온톨로지를 깊게 만드는 쪽에 가깝고, 오픈크랩은 만든 팩을 클라우드에 올려 여러 AI와 기기에서 쓰기 쉽게 만드는 쪽에 가깝다.
Alexai는 오픈크랩의 장점을 로컬 파일이 아닌 클라우드 온톨로지, 역방향 인제스트, 토큰 걱정 없는 활용, 다른 사람의 온톨로지와 교류, 기업 단위 공유로 정리했다. 여기서 배울 점은 명확하다.
온톨로지 도구를 고를 때 로컬/클라우드의 우열을 묻기보다, 원본 보안, 재사용성, 팀 공유, 업데이트 감지 중 무엇이 중요한지를 먼저 정해야 한다. 웹서치로 확인할 자료는 OpenCrab guide https://crab-guide.pages.dev/ 와 OpenCrab service https://opencrab.sh/ 이다.
함께 보면 좋은 학습 키워드는 ontology engineering, knowledge graph, MCP server, local-first AI workflow다. 최신 용어로 보면 이 대화의 핵심은 온톨로지 팩을 로컬에서 만드는 일과 그것을 여러 AI 작업대에 연결하는 일을 분리했다는 점이다.
로컬크랩은 원본 자료를 손에 쥐고 깊게 가공하는 작업장이고, OpenCrab Desktop은 그 작업장을 덜 무섭게 만든 설치형 인터페이스다. Expert 플랜 이야기가 팩 판매, 역방향 인제스트, 기업 공유로 넘어간 것도 같은 맥락이다.
이것은 단순 기능 업그레이드가 아니라 개인 지식베이스가 팀과 시장으로 나가는 경로를 만드는 문제다. 초보자가 여기서 놓치기 쉬운 부분은 온톨로지를 그냥 폴더 정리나 태그 모음으로 이해하는 것이다.
대화에서 말한 온톨로지는 자료를 분류하는 표가 아니라 AI가 도메인 관계를 따라 추론하게 해주는 구조에 가깝다. 그래서 좋은 데이터만 있으면 된다는 말은 반만 맞다.
좋은 데이터에 더해 어떤 업무 질문에 답할 것인지, 어떤 개념들이 연결되어야 하는지, 어떤 업데이트를 감지해야 하는지가 같이 정해져야 한다.
최신 용어 풀이
- OpenCrab Desktop
- OpenCrab의 온톨로지 빌딩과 인제스트 과정을 CLI보다 쉽게 다루도록 만든 설치형 작업대.
- 로컬크랩
- 원본 자료를 로컬 환경에서 온톨로지로 빌드하는 도구 흐름. 보안이나 원본 보존이 중요한 작업에 유리하다.
- 역방향 인제스트
- 이미 만들어진 온톨로지나 결과물을 다시 읽어 변화, 버전, 관계를 감지하는 업데이트 흐름을 뜻하는 대화상 표현.
대화 근거
대화 장면 1이제 팩빌딩을 따로 로컬크랩 쓰시지 않고도 오픈크랩 데스크탑 앱에서 가능하십니다.
OpenCrab Desktop이 CLI 진입장벽을 낮추는 장면
대화 장면 2로컬 파일로 존재하는 온톨로지가 아니라 클라우드에 올라가 있어서 어느 컴퓨터 핸드폰 어떤 AI인지를 가리지 않고 쓸 수 있는 점
로컬크랩과 OpenCrab의 역할 차이를 설명한 장면
대화 장면 3회사 자료의 분량이 너무 많아서... 의미 있는 카테고리 단위로 분절을 해서 만들어야 될지 고민인데
실제 회사 자료를 온톨로지로 바꾸려는 운영 질문
무엇을 배워야 하나
이 항목은 "데스크탑 앱이 나오면서 로컬크랩을 어려워하던 사용자를 위한 온톨로지 빌딩 진입로가 생겼다"라는 오늘의 논의를 실제 행동 기준으로 바꾸는 부분입니다. 읽을 때는 이 문장을 그대로 외우기보다, 다음 대화나 작업에서 무엇을 먼저 확인하고 어떤 기준으로 성공/실패를 판단할지까지 연결해서 보면 좋습니다.
이 항목은 "데스크탑 앱이 나오면서 로컬크랩을 어려워하던 사용자를 위한 온톨로지 빌딩 진입로가 생겼다"라는 오늘의 논의를 실제 행동 기준으로 바꾸는 부분입니다. 읽을 때는 이 문장을 그대로 외우기보다, 다음 대화나 작업에서 무엇을 먼저 확인하고 어떤 기준으로 성공/실패를 판단할지까지 연결해서 보면 좋습니다.
이 항목은 "데스크탑 앱이 나오면서 로컬크랩을 어려워하던 사용자를 위한 온톨로지 빌딩 진입로가 생겼다"라는 오늘의 논의를 실제 행동 기준으로 바꾸는 부분입니다. 읽을 때는 이 문장을 그대로 외우기보다, 다음 대화나 작업에서 무엇을 먼저 확인하고 어떤 기준으로 성공/실패를 판단할지까지 연결해서 보면 좋습니다.
연결 링크
웹서치로 확인할 자료
실행 노트
따라갈 키워드
- Ontology Tooling
- OpenCrab Desktop과 로컬크랩의 역할 분리
- OpenCrab Desktop
- 로컬크랩
- 역방향 인제스트
다음 질문
- OpenCrab Desktop과 로컬크랩의 역할 분리를 다음 대화에서 더 확인하려면 어떤 실제 사례가 필요할까?
- OpenCrab Desktop과 로컬크랩의 역할 분리를 내 업무에 적용할 때 먼저 검증해야 할 위험은 무엇일까?
적용 아이디어
- 온톨로지를 만들기 전 먼저 어떤 업무 질문에 답할지 한 문장으로 쓴다.
- 원본 보안이 중요하면 로컬 빌드, 여러 기기와 팀 공유가 중요하면 클라우드 활용으로 경계를 나눈다.
- 큰 자료는 한 번에 넣지 말고 의미 있는 업무 단위로 쪼개어 팩 품질을 비교한다.
다시 확인할 링크
2
Agent Architecture
온톨로지 팩을 가진 에이전트들의 병렬 분업
왜 중요한가
밤에는 서로 다른 온톨로지 기반 에이전트가 토론하거나 병렬 분업할 수 있는지로 논의가 깊어졌다.
깊이 보기
밤 11시 이후 대화가 특히 중요했다.
- 한 참여자는 온톨로지 1개를 구축하고 다른 1개를 구축한 다음, 둘을 기반으로 한 에이전트들이 서로 토론할 수 있느냐고 물었다.
- Alexai는 재미있는 아이디어라며 바로 실험해보겠다고 했고, 이어 서브에이전트를 활용하면 순차적으로 한 팩을 쓰는 대신 병렬로 여러 팩을 활용할 수 있다고 답했다.
- 이 대화의 학습 포인트는 스킬과 온톨로지의 차이다.
- 스킬을 쓰는 에이전트는 절차를 잘 따른다.
- 그러나 화학 전문가와 분자 전문가가 같은 지식기반, 같은 모델, 같은 컨텍스트로만 움직이면 실제로는 서로 다른 뇌가 아니다.
온톨로지를 나눠서 상호작용시키면 각 에이전트가 다른 지식 구조를 갖고 문제를 바라볼 수 있다. 이것은 단순한 역할극보다 강한 분업 설계다.
다만 바로 제품화할 때는 검증 질문이 필요하다. 첫째, 서로 다른 팩을 가진 에이전트가 중복 답변을 줄이는가.
둘째, 충돌하는 결론을 발견하고 설명할 수 있는가. 셋째, 한 에이전트가 모르는 도메인을 다른 에이전트가 보완하는가.
넷째, 최종 합의문이 실제 전문가 검토에서 더 낫게 평가되는가. 이 네 가지를 보지 않으면 온톨로지 분업은 멋진 시연에 머물 수 있다.
최신 용어로 풀면 이것은 multi-agent roleplay가 아니라 retrieval boundary 설계에 가깝다. 같은 모델에게 화학 전문가와 분자 전문가 역할을 주는 것은 말투와 관점을 나누는 수준에 머물 수 있다.
반면 서로 다른 온톨로지 팩을 붙이면 각 에이전트가 참조하는 지식 구조 자체가 달라진다. 이때 토론의 품질은 모델이 얼마나 똑똑한가보다 어떤 지식 경계를 갖고 들어왔는가에 좌우된다.
따라서 이 아이디어를 실험하려면 답변이 멋있어졌는지보다 충돌과 보완이 생기는지를 봐야 한다. 화학 팩 에이전트와 분자 팩 에이전트가 같은 현상을 다르게 설명하는가, 서로의 누락을 지적하는가, 최종 조정자가 어떤 근거로 합의하는가를 기록해야 한다.
이것이 되면 온톨로지 팩은 자료 저장소가 아니라 에이전트 팀의 기억 경계가 된다.
최신 용어 풀이
- 서브에이전트
- 하나의 큰 작업을 나눠 맡는 보조 에이전트. 여기서는 서로 다른 온톨로지 팩을 가진 병렬 작업자로 상상됐다.
- 온톨로지 팩
- 특정 도메인의 개념, 관계, 자료를 AI가 참조할 수 있는 지식 구조로 묶은 단위.
- Retrieval boundary
- 에이전트가 어떤 자료와 지식 구조를 참조할 수 있는지 나누는 경계. 답변 다양성과 검증 가능성에 영향을 준다.
대화 근거
대화 장면 1온톨로지 1개를 구축하고 다른 1개를 구축한 다음에 둘을 기반으로한 에이전트들이 서로 토론/토의를 하는게 가능할까요?
온톨로지별 에이전트 토론 아이디어가 처음 제기된 장면
대화 장면 2서브에이전트를 활용하면 병렬로 한꺼번에 여러 팩을 활용할 수 있으니까 좋을 것 같아요
서브에이전트를 순차 검색이 아닌 병렬 분업으로 해석한 장면
대화 장면 3온톨로지로 나눠서 상호작용을 시키니 뇌를 나눠서 더 복잡한 문제를 해결할 수 있을 것도 같아요
역할극과 지식 경계 분리를 구분한 핵심 발화
무엇을 배워야 하나
이 항목은 "밤에는 서로 다른 온톨로지 기반 에이전트가 토론하거나 병렬 분업할 수 있는지로 논의가 깊어졌다"라는 오늘의 논의를 실제 행동 기준으로 바꾸는 부분입니다. 읽을 때는 이 문장을 그대로 외우기보다, 다음 대화나 작업에서 무엇을 먼저 확인하고 어떤 기준으로 성공/실패를 판단할지까지 연결해서 보면 좋습니다.
이 항목은 "밤에는 서로 다른 온톨로지 기반 에이전트가 토론하거나 병렬 분업할 수 있는지로 논의가 깊어졌다"라는 오늘의 논의를 실제 행동 기준으로 바꾸는 부분입니다. 읽을 때는 이 문장을 그대로 외우기보다, 다음 대화나 작업에서 무엇을 먼저 확인하고 어떤 기준으로 성공/실패를 판단할지까지 연결해서 보면 좋습니다.
이 항목은 "밤에는 서로 다른 온톨로지 기반 에이전트가 토론하거나 병렬 분업할 수 있는지로 논의가 깊어졌다"라는 오늘의 논의를 실제 행동 기준으로 바꾸는 부분입니다. 읽을 때는 이 문장을 그대로 외우기보다, 다음 대화나 작업에서 무엇을 먼저 확인하고 어떤 기준으로 성공/실패를 판단할지까지 연결해서 보면 좋습니다.
연결 링크
웹서치로 확인할 자료
실행 노트
따라갈 키워드
- Agent Architecture
- 온톨로지 팩을 가진 에이전트들의 병렬 분업
- 서브에이전트
- 온톨로지 팩
- Retrieval boundary
다음 질문
- 온톨로지 팩을 가진 에이전트들의 병렬 분업를 다음 대화에서 더 확인하려면 어떤 실제 사례가 필요할까?
- 온톨로지 팩을 가진 에이전트들의 병렬 분업를 내 업무에 적용할 때 먼저 검증해야 할 위험은 무엇일까?
적용 아이디어
- 역할만 나눈 에이전트와 지식 경계까지 나눈 에이전트를 구분한다.
- 서로 다른 팩을 붙였을 때 중복, 충돌, 보완, 최종 합의 품질을 비교한다.
- 에이전트 토론을 시연이 아니라 검증 가능한 실험으로 만들려면 평가 질문을 먼저 정한다.
다시 확인할 링크
짧은 기록
회사 자료 100GB 처리
자료가 너무 클 때는 한 번에 넣기보다 의미 있는 카테고리 단위로 분절해 온톨로지를 만드는 쪽이 권장됐다.
보안 환경의 로컬크랩
VDI나 보안이 강한 환경에서는 로컬크랩과 Qwen 조합처럼 API를 타지 않는 구성이 가능하다는 답변이 나왔다.
제외한 잡담
입장 인사, 봇 안내 반복, 설치 오류의 단발성 확인, 짧은 리액션과 잡담은 축약했다.