답이 아는 사람 머릿속에만 있고
OTOntology봇
전에는 — 회의록 뒤지고, 정리하고, 나눠서 알리고
이번 분기 OKR 리뷰 회의록에서 액션 아이템 정리해줘
1. 온보딩 프로세스 개편안 초안 검토 2. 인프라 장애 대응 런북 갱신 3. 다음 리뷰 전까지 지표 대시보드 확정
분기별 OKR 리뷰 회의록지금은 — 한 마디면, 찾고 연결해서 정리까지
담당자가 자리를 비우면 일이 멈추고
신규 입사자가 선임을 검색창처럼 쓰고
잘 아는 사람의 시간은 그렇게 자꾸 끊깁니다.
연결이 전부입니다
물어보면 근거로 답하고, 맡기면 근거로 일합니다.
WHAT YOU GET
이게 knowledge layer입니다
글마다 원본 링크가 붙은, 물어볼 수 있는 회사 위키.
AGENTIC RETRIEVAL
서버에 쌓을 것인가, 딸각 연결할 것인가
AS-IS
서버형 — 파이프라인을 전부 서버에 쌓는다
서버가 책임질 단계: 6+
- 질문
- 쿼리 계획
- 서브쿼리 분해
- 반복 검색
- 재랭킹
- 자기 평가
- 합성
- 답변
그리고 전부 서버 운영 몫 —
"reasoning effort" 튜닝인덱스 파이프라인 관리권한 동기화평가 대시보드비용·지연 모니터링TO-BE
클라이언트형 — 서버는 검색만 잘하면 된다
서버가 할 일: search / fetch 끝
질문답변
클라이언트 에이전트
Claude Code · Cursor
계획·분해·반복은 여기서
search / fetch
Claude Code · 터미널
claude mcp add --transport http otontology https://…/mcp
연결됨 — 에이전트가 팀 지식을 통째로 이해한 채 일합니다
주소 한 줄이면 끝. 딸각, 연결 — 복잡한 건 이미 잘하는 에이전트에게 맡기고, 서버는 검색 품질에만 집중합니다.
MCP · ANY AGENT
어떤 AI 도구든, 지금 쓰는 그대로
찾는 건 기본입니다. 에이전트가 일까지 끝냅니다.
연결되면 이렇게 씁니다
claude mcp add --transport http otontology https://otontology.otoworks.ai/mcp인증은 회사 단위, 범위는 연결한 워크스페이스의 공개 채널·위키까지
- Claude Code
- Cursor
- Codex
- Gemini CLI
- Windsurf
- MCP 되는 어디든
에이전트가 실제로 하는 일
Claude Code개발자
신규 입사자 온보딩, 지급 절차대로 체크리스트 만들어줘
wiki_fetch("신규 입사자 노트북 지급 절차")
체크리스트 완성 — 단계마다 절차 원문 링크.
CursorPM
온보딩 개편 킥오프 문서 초안 잡아줘. 왜 지금 구조로 정했는지도 넣어서
wiki_search("온보딩 프로세스 개편")
킥오프 초안 정리 — 결정 배경은 개편안 원문 인용으로.
ClaudeCS
이 고객 문의, 우리 응대 매뉴얼 기준으로 답장 초안 써줘
wiki_fetch("고객 응대 매뉴얼")
답장 초안 작성 — 매뉴얼 원문 링크 첨부.
Gemini CLI팀 리드
새벽 장애 후속 조치, 액션 아이템으로 정리해서 시작하자
wiki_fetch("인프라 장애 대응 런북")
후속 조치 목록 추림 — 항목마다 런북 원문 링크.
JUST CONNECT
직접 만들고, 계속 관리하고
연결만 하면, 나머지는 알아서
직접 만들 필요 없습니다. 몇 번 연결해 두면, 흩어져 있던 글이 물어볼 수 있는 회사 위키가 됩니다.
- 최대 5분 주기로 변경 확인
- 바뀐 것만 다시 생성
ASK IN SLACK · DISCORD
같은 질문에, 또 답하고
쓰던 채널에서, 그냥 물어보세요
봇을 부르면 knowledge layer에서 근거를 찾아 답합니다. 같은 질문에 두 번 답하지 않아도 됩니다.
- Slack
- Discord
- 쓰던 채널 그대로
NO EVIDENCE, NO ANSWER
그럴듯한데, 출처는 없고
근거가 없으면, 답하지 않습니다
검색해도 근거를 찾지 못하면 모델을 호출하지 않습니다.
- 답할 땐, 항상 원본 출처와 함께
거절은 이렇게 일어납니다
AUDIT LOG
모든 답변엔 근거가 남습니다
누가 묻고 뭐라고 답했는지, 어떤 글을 참고했는지 전부 남습니다. 사람의 질문도, 에이전트의 조회도요.
회사 단위 격리
데이터는 회사 단위로 나눕니다. 다른 회사 글은 검색에 잡히지 않습니다.
에이전트는 읽기만
에이전트에 열어 둔 통로는 읽기 전용입니다. 위키도 색인도 고칠 수 없습니다.
조회도 기록에 남음
사람의 질문도 에이전트의 조회도 같은 로그에 남습니다. 어떤 근거로 답했는지 나중에 찾아볼 수 있습니다.
WHY KNOWLEDGE LAYER
AI 에이전트 시대의 기반층,knowledge layer
에이전트가 일하려면 회사가 무엇을 알고 있는지 읽을 수 있어야 합니다. 업계는 이 층위를 knowledge layer라 부릅니다. 흩어진 회사 지식을 한곳에 모아 사람과 AI가 같은 근거를 보게 하는 기반층입니다. OTOntology는 이 기반층을 Notion·Slack·Discord 연결만으로 세웁니다.
“Why Enterprise AI Starts With A Knowledge Layer”
연결하면, 알아서 knowledge layer가 되고.
물으면 답이 되고, 맡기면 일이 되고.
근거가 없으면, 답하지 않습니다.
복붙 대신 연결해 두면 무엇이 달라지는지 보여드립니다.