glean의 모델이 기업 검색을 AI로 재정의하려는 목표

Glean은 기업 내부에 흩어진 데이터(Slack, Google Drive, Confluence, Jira, GitHub 등 100여 개 SaaS)를 통합 검색하는 엔터프라이즈 서치 플랫폼으로, 최근 자체 학습 모델을 도입하며 기존 범용 LLM 의존 구조에서 벗어나는 행보를 보이고 있다. CEO Arvind Jain이 강조한 "task-specific model" 접근은 RAG(Retrieval-Augmented Generation)의 한계를 극복하기 위한 것으로, 각 기업의 권한 그래프(permission graph)와 문서 임베딩, 사용자 행동 신호를 결합해 도메인 특화 검색·추론 능력을 강화한다. 핵심은 ① 기업별 컨텍스트를 반영한 파인튜닝된 임베딩 모델, ② 권한·ACL을 보존한 vector store, ③ 워크플로우 자동화를 위한 에이전트 오케스트레이션 레이어의 결합이며, 이는 단순 키워드 매칭이나 GPT-4o 같은 범용 모델의 단순 RAG로는 도달하기 어려운 정확도와 보안 수준을 목표로 한다.

개발자/엔지니어 관점에서 가장 큰 영향은 "사내 지식 검색"이라는 일상 업무가 IDE와 워크플로우에 직접 통합된다는 점이다. 예컨대 특정 마이크로서비스의 장애 대응 가이드, 과거 인시던트 포스트모템, 관련 PR과 Slack 스레드를 한 번의 자연어 질의로 모아볼 수 있고, Glean Agents를 통해 "이 PR의 리뷰어 후보 추천", "관련 Jira 티켓 자동 링크"처럼 반복 작업을 위임할 수 있다. 반면 Microsoft Copilot, Google Agentspace, Notion AI 같은 빅테크 통합 솔루션과의 경쟁이 심화되면서, 각 벤더가 자체 모델을 들고 들어오는 흐름은 향후 사내 검색 인프라 선택 시 "범용 모델 + 벡터 DB 직접 구축"이냐 "수직 통합 SaaS"이냐의 의사결정 비용을 더 키운다.

한국 개발자가 실무에서 챙겨야 할 포인트는 세 가지다. 첫째, 기업 검색 시스템을 직접 구축한다면 단순 RAG가 아닌 권한 모델·사용자 행동 로그·도메인 어휘를 반영한 reranker와 하이브리드 검색(BM25 + dense)을 설계해야 Glean 수준에 근접할 수 있다. 둘째, 보안·컴플라이언스 측면에서 source-level ACL을 답변 생성 단계까지 일관되게 전파하는 것이 핵심이며, LangChain·LlamaIndex 같은 프레임워크를 쓰더라도 권한 필터링은 retrieval 이전에 강제해야 한다. 셋째, "task-specific model" 트렌드는 곧 자체 데이터로 소형 모델을 파인튜닝하거나 distillation해 추론 비용을 낮추는 흐름을 의미하므로, 사내 도입 검토 시 토큰 단가뿐 아니라 응답 지연(latency)과 캐시 hit rate, 사용자 피드백 루프 설계까지 함께 평가하는 것이 중요하다.