핵심 논쟁
데이터를 많이 넣으면 되는가, 좋은 기준과 좋은 선택을 사람이 넣어야 하는가가 반복해서 부딪혔다.
방 헤더 · 2026-06-05
오늘의 한 문장: 팀별·프로젝트별 팩을 나누고 같은 사안을 서로 다른 팩으로 토론시키는 실험부터 해볼 만하다.
온톨로지 팩을 단순 지식 묶음이 아니라 전문가 페르소나와 시뮬레이터로 보는 관점이 열렸다.
OpenCrab 사용법, 팀별 팩, UI/UX 팩, 연구 자료 팩으로 논의가 확장됐다.
데이터를 많이 넣으면 되는가, 좋은 기준과 좋은 선택을 사람이 넣어야 하는가가 반복해서 부딪혔다.
온톨로지는 에이전트에게 역할을 주는 방식이지만 품질은 팩을 나누는 기준과 검증 루프에서 갈린다.
연구 자동화
논문, PPT, 이미지 자료를 팩으로 만들고 GPT·Claude·Codex·Antigravity에 연결해 쓰는 연구 활용법이 구체화됐다.
밤에는 공부와 연구에 OpenCrab을 어떻게 쓸 수 있는지 질문이 나왔다.
글과 그림으로 되어있는 것이 가장 좋죠. " / 오후 8:25 박유진의 "논문 가지고 물어보거나 ppt자료들이나 그런게 많습니다.
이거를 mcp 붙혀서 채팅에서 대화하는거죠? " / 오후 8:25 Alexai @alexai_mcp의 "논문들 쫚 팩으로 만들어 놓고 GPT나 클로드 클코 코덱스 안티그래비티 등과 연결해서 쓰시면 됩니다.
" 순서로 이어지며, 처음에는 체감이나 질문으로 시작했지만 곧 운영 기준과 다음 행동의 문제로 바뀌었다. 그래서 이 항목은 짧은 키워드 요약보다 “누가 무엇을 물었고, 다른 사람이 어떤 기준으로 받아쳤는지”를 읽어야 한다.
핵심은 자료를 GPT 웹에 한 번 올리고 끝내는 흐름이 아니라, 자료를 지속적으로 업데이트하고 인제스트하는 관리 흐름이다. 모델이 바뀌어도 팩이 source of truth가 되는 방향이다.
특히 이 흐름은 AI 도구를 잘 쓰는 일이 모델명 선택만으로 끝나지 않는다는 점을 보여준다. 맥락을 어디에 적어둘지, 어떤 권한을 열어둘지, 어떤 자료를 신뢰할지, 비용과 사람의 집중력을 어떻게 나눌지 같은 운영 질문이 같이 따라붙었다.
다음에 같은 주제를 다시 볼 때는 세 가지를 확인하면 좋다. 첫째, 오늘 나온 말이 단순 의견인지 실제 작업 사례인지 구분한다.
둘째, 링크나 도구 이름보다 그 도구를 왜 꺼냈는지 본다. 셋째, 내 작업에 옮길 때 필요한 선행 조건, 실패 기준, 보안 경계를 함께 적어둔다.
연구자는 요약보다 더 자주 이 논문이 내 문제와 어떤 관계인지, 다른 논문과 충돌하는 지점은 어디인지 묻기 때문에 팩 구조가 중요해진다.
지식 구조
전문가를 프롬프트로 흉내 내는 방식에서, 자료와 관계를 묶은 팩 자체가 말하는 주체가 될 수 있다는 논의가 이어졌다.
새벽의 출발점은 온톨로지를 '자료 묶음'이 아니라 '사고하는 페르소나'로 보는 감각이었다.
논문초안써넣고 참조한 논문팩들 기반 토론 붙여서 논문 수준을 높이는것도 가능하겠네요. " / 오전 6:36 logotekton/건축의 "같은 데이터로 방향을 다르게 잡아서 팩을 2개 이상 만든 다음 토론 시키면 더 딥한 개념이 도출될 수도 있을거 같아요.
" 순서로 이어지며, 처음에는 체감이나 질문으로 시작했지만 곧 운영 기준과 다음 행동의 문제로 바뀌었다. 그래서 이 항목은 짧은 키워드 요약보다 “누가 무엇을 물었고, 다른 사람이 어떤 기준으로 받아쳤는지”를 읽어야 한다.
논문팩, 편집자팩, 리뷰어팩, 대가들의 논문을 긁어 만든 토론 주체 같은 예시가 이어지며, 좋은 팩은 말투가 아니라 어떤 논거를 중요하게 보고 어떤 반례를 떠올리는지를 담아야 한다는 쪽으로 논의가 깊어졌다. 특히 이 흐름은 AI 도구를 잘 쓰는 일이 모델명 선택만으로 끝나지 않는다는 점을 보여준다.
맥락을 어디에 적어둘지, 어떤 권한을 열어둘지, 어떤 자료를 신뢰할지, 비용과 사람의 집중력을 어떻게 나눌지 같은 운영 질문이 같이 따라붙었다. 다음에 같은 주제를 다시 볼 때는 세 가지를 확인하면 좋다.
첫째, 오늘 나온 말이 단순 의견인지 실제 작업 사례인지 구분한다. 둘째, 링크나 도구 이름보다 그 도구를 왜 꺼냈는지 본다.
셋째, 내 작업에 옮길 때 필요한 선행 조건, 실패 기준, 보안 경계를 함께 적어둔다. 온톨로지는 AI에게 먹일 자료가 아니라, 누가 어떤 기준으로 수집했고 어떤 상황에서 믿어도 되는지까지 포함한 작업 단위로 다루어야 한다.
디자인 지식화
OpenCrab 자체의 UI 개선 요구가 디자인 감각, 좋은 데이터, 사람이 선택하는 기준의 문제로 이어졌다.
오후에는 OpenCrab 제품 자체의 화면과 메뉴 흐름 이야기가 열렸다.
상단 메뉴에 따라 페이지 세팅이 왓다갓다하는게 좀잇어서요. " / 오후 4:25 읽기쓰기 /반도체연구원의 "아 ui ux는 아직 온톨로지로 안되는건가요ㅠ" / 오후 4:26 ziteun_vin / 사유ing.
의 "온톨로지로 되지만 ui ux를. 좋은 데이터는 사람이 넣거나 사람이 선택하거나 해야하니까요.
" / 오후 8:07 Alexai @alexai_mcp의 "일단 팩부터 만들어보겠습니다. DATA, GRAPH, UI 온톨로지 팩.
" 순서로 이어지며, 처음에는 체감이나 질문으로 시작했지만 곧 운영 기준과 다음 행동의 문제로 바뀌었다. 그래서 이 항목은 짧은 키워드 요약보다 “누가 무엇을 물었고, 다른 사람이 어떤 기준으로 받아쳤는지”를 읽어야 한다.
UI는 버튼, 그래프, 화면 구조처럼 자료화하기 쉽지만 UX는 사용자가 어디서 헷갈리고 어떤 선택을 편하게 느끼는지까지 포함한다. 그래서 좋은 데이터와 사람이 고르는 기준이 분리되어야 한다는 말이 중요했다.
특히 이 흐름은 AI 도구를 잘 쓰는 일이 모델명 선택만으로 끝나지 않는다는 점을 보여준다. 맥락을 어디에 적어둘지, 어떤 권한을 열어둘지, 어떤 자료를 신뢰할지, 비용과 사람의 집중력을 어떻게 나눌지 같은 운영 질문이 같이 따라붙었다.
다음에 같은 주제를 다시 볼 때는 세 가지를 확인하면 좋다. 첫째, 오늘 나온 말이 단순 의견인지 실제 작업 사례인지 구분한다.
둘째, 링크나 도구 이름보다 그 도구를 왜 꺼냈는지 본다. 셋째, 내 작업에 옮길 때 필요한 선행 조건, 실패 기준, 보안 경계를 함께 적어둔다.
UI/UX 온톨로지는 감각을 대신하는 마법이 아니라 좋은 예시와 나쁜 예시를 분류해 감각을 검증 가능한 자료로 바꾸는 과정이다.
엔터프라이즈 운영
팀별 지식과 목표를 팩으로 나누고 에이전트에게 프로젝트 단위로 부여하면 조직 회의와 업무 배정을 흉내낼 수 있다는 논의가 나왔다.
개인 실험처럼 보였던 온톨로지 이야기는 곧바로 엔터프라이즈 운영 그림으로 넘어갔다.
s_jake의 "프로젝트 기능이 잇으니 온톨로지 프로젝트로 묶어서 프로젝트단위로 에이젼트에게 부여하고작업하면될거같아요. " / 오전 7:32 logotekton/건축의 "팀별 온톨로지가 충분히 구축되고 추구하는 바가 명확히 있으면 진짜 좋을거 같아요.
" 순서로 이어지며, 처음에는 체감이나 질문으로 시작했지만 곧 운영 기준과 다음 행동의 문제로 바뀌었다. 그래서 이 항목은 짧은 키워드 요약보다 “누가 무엇을 물었고, 다른 사람이 어떤 기준으로 받아쳤는지”를 읽어야 한다.
영업팀, 보안팀, 제품팀, 고객지원팀이 서로 다른 팩을 가진다면 에이전트는 단일 답을 내는 대신 부서별 이해관계를 드러내는 회의체처럼 작동할 수 있다. 특히 이 흐름은 AI 도구를 잘 쓰는 일이 모델명 선택만으로 끝나지 않는다는 점을 보여준다.
맥락을 어디에 적어둘지, 어떤 권한을 열어둘지, 어떤 자료를 신뢰할지, 비용과 사람의 집중력을 어떻게 나눌지 같은 운영 질문이 같이 따라붙었다. 다음에 같은 주제를 다시 볼 때는 세 가지를 확인하면 좋다.
첫째, 오늘 나온 말이 단순 의견인지 실제 작업 사례인지 구분한다. 둘째, 링크나 도구 이름보다 그 도구를 왜 꺼냈는지 본다.
셋째, 내 작업에 옮길 때 필요한 선행 조건, 실패 기준, 보안 경계를 함께 적어둔다. 팀별 팩은 부서별 암묵지를 꺼내는 방법이지만, 어느 팀의 팩이 어떤 사안에서 우선권을 갖는지까지 정해야 실제 조직 의사결정에 쓸 수 있다.
OpenCrab 링크와 가이드 링크가 반복 공유되며 신규 참여자 온보딩이 이어졌다.
커뮤니티 578명, 가입자 640명 언급처럼 베타 단계에서도 사용자가 빠르게 늘고 있음을 공유했다.
입장 인사, 사진 반응, 짧은 농담, 모임 잡담은 핵심 흐름에서 제외했다.