사내 지식이 흩어져 있으면 AI도 바보가 돼요
Stripe 엔지니어링 블로그에 회사 내부의 지식을 AI가 활용할 수 있게 하나로 묶은 'Knowledge AI Platform'을 소개하는 글이 올라왔어요. 결제 회사가 왜 이런 걸 만들었냐 싶을 수 있는데요, 사실 Stripe는 요 몇 년 사이 사내 AI 도구를 꽤 공격적으로 만들어온 회사거든요. 코딩 에이전트인 Minions, 사내 도구를 AI에게 연결해주는 MCP 서버 Toolshed 같은 것들을 먼저 공개했었고, 이번 글은 그 밑바탕이 되는 '지식' 계층 이야기예요.
배경을 조금 풀어볼게요. 요즘 웬만한 회사는 한 번쯤 사내 챗봇을 만들어봤을 거예요. 위키 문서 몇 개 긁어서 벡터 DB에 넣고, 질문하면 답해주는 그런 거요. 그런데 막상 써보면 실망스러운 경우가 많아요. 옛날 문서를 근거로 엉뚱한 답을 하거나, 슬랙에서 이미 결론 난 내용을 모르거나, 심지어 보면 안 되는 문서 내용을 알려주기도 하고요. 문제는 모델이 아니라 모델에게 주는 재료가 엉망이라서 그래요. Stripe가 한 일은 이 재료 공급망을 회사 차원의 플랫폼으로 만든 거예요.
이게 뭐냐면: RAG를 팀마다 만들지 않고 회사가 한 번 만든다
먼저 RAG라는 말부터 짚고 갈게요. Retrieval-Augmented Generation의 약자인데, 쉽게 말하면 '오픈북 시험'이에요. 모델이 머릿속 기억만으로 답하는 게 아니라, 질문이 들어오면 관련 문서를 먼저 찾아서 책상 위에 펼쳐놓고 그걸 보면서 답하는 방식이죠. 그런데 이 오픈북 시험이 잘 되려면 책이 잘 정리돼 있어야 하고, 어떤 책을 펼칠지 잘 찾아야 하고, 그 학생이 볼 자격이 있는 책만 펼쳐야 해요.
Stripe의 접근을 세 층으로 나눠서 이해하면 편한데요.
첫 번째는 수집과 정규화 층이에요. 문서 도구, 위키, 슬랙 대화, 코드 저장소, 이슈 트래커, 장애 기록처럼 형식이 제각각인 소스를 하나의 공통 형태로 바꿔서 모으는 거예요. 여기서 중요한 게 문서를 그대로 통째로 넣는 게 아니라 적당한 크기로 자르는 '청킹'인데요, 너무 잘게 자르면 문맥이 끊기고 너무 크게 자르면 검색 정확도가 떨어져서 소스 종류마다 다르게 다뤄야 해요. 코드는 함수 단위로, 슬랙은 스레드 단위로, 이런 식으로요.
두 번째는 검색 층이에요. 임베딩 기반의 의미 검색과 키워드 검색을 섞은 하이브리드 검색으로 관련 조각을 찾고, 다시 순위를 매겨서 정말 관련 있는 것만 추려요. 여기서 Stripe 같은 회사가 특히 신경 쓸 수밖에 없는 부분이 권한이에요. 결제 회사라 민감한 문서가 많잖아요. 검색 결과를 만들 때 질문한 사람이 원래 볼 수 있는 문서만 걸러내는 걸 'permission-aware retrieval'이라고 하는데, 이걸 각 앱이 알아서 하게 두면 반드시 구멍이 나요. 그래서 플랫폼 차원에서 원본 시스템의 권한을 그대로 따라가도록 만드는 게 핵심이에요.
세 번째는 소비 층이에요. 이렇게 준비된 지식을 하나의 API로 열어두면, 사내 Q&A 봇도, 코딩 에이전트도, 고객지원 도우미도 같은 걸 가져다 쓸 수 있어요. 팀마다 따로 크롤러 짜고 벡터 DB 세우던 걸 없애는 거죠. 그리고 이 위에 평가 루프가 얹혀요. '이 질문에는 이 문서가 나와야 한다'는 정답 세트를 만들어놓고 검색 품질을 계속 측정하는 건데, 이게 없으면 임베딩 모델 하나 바꿨을 때 좋아졌는지 나빠졌는지조차 모르거든요.
업계 맥락: 모두가 같은 곳을 향하고 있어요
이 방향이 Stripe만의 것은 아니에요. Glean 같은 회사는 아예 이런 사내 지식 검색을 제품으로 팔고 있고, Atlassian의 Rovo, Google의 Agentspace, Microsoft 365 Copilot도 결국 '회사 데이터를 AI가 안전하게 쓰게 하기'가 본질이에요. 오픈소스 쪽에서는 LlamaIndex나 LangChain으로 직접 조립하는 경우가 많고요.
차이는 어디에 있냐면, 사서 쓰는 제품은 편하지만 우리 회사만의 데이터 소스나 권한 체계에 맞추기 어렵고, 직접 조립하면 자유롭지만 팀마다 제각각 만들어서 품질과 보안이 들쭉날쭉해져요. Stripe의 선택은 그 중간이에요. 직접 만들되 회사 전체가 쓰는 하나의 플랫폼으로요. 그리고 이 지식 층이 있어야 Toolshed 같은 도구 계층과 Minions 같은 에이전트 계층이 제대로 돌아가요. 에이전트가 코드를 고치려면 '이 서비스는 왜 이렇게 설계됐지'를 알아야 하는데, 그 답이 사내 문서와 과거 논의에 있으니까요.
한국 개발자에게 주는 시사점
당장 Stripe 규모로 만들 필요는 없어요. 오히려 이 글에서 가져갈 건 순서예요.
- 소스를 먼저 정리하세요. 노션, 컨플루언스, 슬랙, 깃허브에 흩어진 지식 중 뭘 신뢰할지 정하는 게 반이에요. 쓰레기를 넣으면 쓰레기가 나와요.
- 권한을 처음부터 설계하세요. 나중에 붙이려면 거의 다시 만들어야 해요. 원본 시스템의 권한을 그대로 따라가는 구조가 가장 안전해요.
- 평가셋을 작게라도 만드세요. 실제 직원들이 자주 묻는 질문 50개와 기대하는 답을 적어두는 것만으로도 개선 방향이 보여요.
- MCP로 열어두세요. 검색 API를 MCP 서버로 감싸두면 Claude Code나 Cursor 같은 도구에서 바로 사내 지식을 쓸 수 있어서 코딩 에이전트의 답 품질이 확 달라져요.
정리
한 줄로 정리하면, AI를 회사에서 제대로 쓰려면 모델보다 먼저 '회사가 아는 것'을 한곳에 안전하게 모아두는 플랫폼이 필요하다는 이야기예요.
여러분 회사는 사내 지식이 어디에 흩어져 있나요? 사내 AI 도구를 만들어봤다면 가장 큰 벽은 뭐였는지 궁금해요. 권한 문제였는지, 문서 품질이었는지, 아니면 그냥 아무도 안 썼는지요.
🔗 출처: Hacker News