어떤 AI 도구를 써도, 회사 지식은 하나로 읽힙니다

먼저 문제를 정확히 짚어야 했어요. 이 팀은 프롬프트를 못 쓰는 팀이 아니었습니다. 회의록도 있고 가이드 문서도 있었어요. 그런데 리포트를 맡은 사람이 바뀌면 AI에게 붙여 넣는 문서가 달라지고, 배경을 설명하는 문장이 달라지고, 결국 AI가 이해하는 회사 지식이 달라졌습니다. 같은 모델에 같은 질문을 던져도 답이 조금씩 다른 건 생성형 AI의 성질이라 어쩔 수 없어요. 우리가 손댈 수 있는 건 그 앞단, 사람마다 달랐던 시작점이었습니다.

이 문제를 겪는 회사가 한둘이 아니라는 것도 이미 알고 있었어요. 사내 에이전트를 만들 때 출발점은 늘 컨텍스트였고, 우리는 그걸 RAG라는 이름으로 여러 방식을 시도하며 쌓아 왔습니다. 업계도 같은 자리를 보고 있습니다. Microsoft는 여러 에이전트가 하나의 지식 기반을 공유하며 출처가 붙은 답을 내는 층을 knowledge layer라 부르고, Gartner는 context layer, Forrester는 system of context라고 부릅니다. 이름은 아직 열 가지가 넘지만 2026년 들어 가리키는 곳은 하나예요. 도구와 데이터 사이의 지식 층입니다. 표준이 잡힌 건 그 층에 연결하는 방식, MCP뿐입니다.

설치할 것은 없었어요. Notion, Slack, Discord 같은 사내 위키와 메신저를 연결하면 OTOntology가 글을 읽어 위키를 만듭니다. 글마다 원본 링크가 붙고 변경분은 최대 5분 주기로 다시 반영됩니다. 그다음 MCP 주소를 한 번 등록합니다. Claude Code에서는 명령 한 줄이고 Codex나 다른 도구도 같은 주소를 씁니다. 인증은 회사 단위이고 범위는 연결한 워크스페이스의 공개 채널과 위키까지입니다. 이 한 번의 연결 뒤로는 어느 도구에서 물어도 같은 위키를 읽고, 답할 때 원문 링크를 함께 돌려줍니다.

가장 먼저 바뀐 게 문제의 출발점이던 고객 경험 리포트였어요. 전에는 담당자가 Claude Code에 이번 달 VoC 회의록을 붙이고, 가이드 문서를 다시 붙이고, 배경을 설명하는 데서 시작했습니다. 그 준비가 사람마다 달랐고 결과도 달랐죠. 지금은 회의록에서 리포트를 정리해 달라고만 합니다. CI와 BI 가이드, 지난 리포트, 그때 왜 그렇게 결론 냈는지 남긴 기록을 에이전트가 위키에서 직접 읽습니다. 누가 맡아도 같은 근거를 보고 시작하니 방향이 크게 갈리지 않게 됐어요. 문장은 여전히 사람마다 다르지만 근거와 방향은 하나입니다.

이 팀과 전에 함께 만든 CS 처리 로직이 여기서 다시 살았어요. 문의 유형별 처리 기준과 응대 원칙이 문서로 있었지만 담당자가 그걸 AI에게 매번 설명하고 있었습니다. 지금은 Slack에서 봇을 불러 이 문의에 답장 초안을 써 달라고 하면, 봇이 처리 기준 문서를 근거로 초안을 만들고 원문 링크를 붙여 줍니다. 담당자가 확인할 건 초안이 기준을 제대로 따랐는지, 링크를 눌러 보는 것뿐이에요. 응대 톤이 사람마다 달라지는 문제도 같은 기준 문서를 보게 되면서 줄었습니다.

개발 쪽 변화는 조용하지만 컸어요. 기능을 고치기 전에 이 기능이 왜 이렇게 설계됐는지, 전에 어떤 이슈가 있었는지 알아야 하는데, 그 답은 회의록과 Notion 스펙 어딘가에 있었습니다. 전에는 아는 사람에게 물었죠. 지금은 Claude Code 안에서 그대로 묻습니다. 에이전트가 위키에서 결정 기록과 스펙 원문을 찾아 링크와 함께 정리해 주니 코드를 건드리기 전에 배경을 다 읽고 시작합니다. 구현 방향이 사람마다 달라지는 일도, 옛 이슈를 모른 채 같은 실수를 반복하는 일도 줄었어요.

새로 들어온 사람은 선임을 검색창처럼 쓰게 됩니다. 이 절차 어디 있어요, 이건 누구한테 물어요 같은 질문이 하루에도 여러 번이죠. 지금은 Slack 봇에게 먼저 묻습니다. 봇은 위키에서 절차 문서를 찾아 답하고 원문 링크를 붙여 주니 입사자는 답을 받는 동시에 원문이 어디 있는지 배웁니다. 선임은 답을 대신하는 사람이 아니라, 봇이 근거를 못 찾은 질문만 받는 사람이 됐어요. 근거가 없으면 봇이 답하지 않으니 틀린 안내가 새로 들어온 사람에게 그대로 흘러가는 일도 막힙니다.

이 사례에서 팀이 가장 좋아한 건 속도가 아니라 출처였어요. 답에는 항상 원문 링크가 붙습니다. 검색해도 근거를 찾지 못하면 모델을 부르지 않고 모른다고 답합니다. 그래서 검수가 달라졌습니다. 전에는 AI가 쓴 글을 처음부터 끝까지 읽고 사실인지 따져야 했는데, 지금은 링크를 눌러 원문을 확인하면 끝이에요. 어디서 AI에게 일을 시켜도 배경과 해야 할 일을 설명할 필요가 없어졌습니다. 서류를 직접 찾거나 옆자리에 다시 묻는 일도 그만큼 줄었어요.

외부와 연동하는 에이전트에도 같은 지식을 넣을 수 없느냐는 요청이 이 팀의 마지막 질문이었어요. MCP로 열어 둔 덕에 답은 간단했습니다. 같은 주소를 등록하면 됩니다. 우리가 이 프로젝트에서 확실히 배운 것도 여기에 있어요. AI 도구를 잘 쓰는 팀에서 최적화할 곳은 프롬프트가 아니라 그 아래의 지식 층이라는 것. 우리가 사내 에이전트를 만들며 RAG라는 이름으로 쌓아 온 시도를, 설치 없이 연결만으로 쓸 수 있게 가볍고 범용적으로 다듬은 것이 OTOntology이고 이 팀이 그 첫 적용이었습니다.