Enterprise AI Search Architecture 설계: NotebookLM, LLM API 그리고 RAG의 역할

기업 내부의 파편화된 지식을 검색하고 활용하기 위해 AI 도입을 결정하더라도, 이를 실제 IT 인프라에 구현하는 것은 별개의 문제다.

 

단일 SaaS형 AI 비서를 전사적으로 도입하는 방식은 보안 규정과 데이터 주권 문제로 인해 엔터프라이즈 환경에 그대로 적용하기 어렵다.

반대로 자체적인 파운데이션 모델(Foundation Model)을 학습시키는 것은 천문학적인 컴퓨팅 비용과 긴 프로젝트 기간을 요구한다.

 

결국 기업이 선택할 수 있는 가장 현실적인 대안은 기존의 내부 데이터를 안전하게 보호하면서도 상용 LLM의 추론 능력을 결합하는 아키텍처를 설계하는 것이다.

이 과정에서 RAG(Retrieval-Augmented Generation) 패턴, LLM API, 그리고 NotebookLM과 같은 애플리케이션 계층의 도구들이 각각 어떤 역할을 수행하며, 어떻게 상호 보완적인 지식 플랫폼을 구성하는지 이해하는 것이 필수적이다.

 

이번 글에서는 Enterprise AI Search를 구성하는 핵심 아키텍처의 논리적 구조를 분석하고, 실무 환경에서 각 기술 요소를 배치할 때 고려해야 할 의사결정 기준을 살펴본다.

 

이 글은 특정 AI 플랫폼이나 제품을 추천하기 위한 것이 아니라, Enterprise AI Knowledge Platform을 구성하는 핵심 요소들의 역할과 상호 연계 구조를 이해하기 위한 아키텍처 설계 원칙을 설명하는 데 목적이 있습니다.

---

[연재]Enterprise AI Knowledge Platform 구축 실무 시리즈 : 

• 1편 : 기존 사내 KMS는 왜 원하는 정보를 찾지 못할까? Enterprise AI Search 도입이 필요한 이유
• 2편 : Enterprise AI Search Architecture 설계: NotebookLM, LLM API 그리고 RAG의 역할 (현재 글)
• 3편 : Enterprise AI Workflow 구축: 프롬프트 자산화와 LLM API 기반 문서 자동화
• 4편 : Enterprise AI Governance 구축: 데이터 보안과 AI 운영 정책

---

---

정보의 신뢰성을 확보하는 RAG 아키텍처의 역할

RAG는 대규모 언어 모델이 가진 환각 현상(Hallucination)의 가능성을 줄이고, 외부 지식에 근거한 답변을 생성할 수 있도록 설계된 대표적인 아키텍처 패턴이다.

 

LLM이 학습된 사전 지식에만 의존하지 않고, 기업의 내부 데이터베이스에서 관련 정보를 먼저 검색(Retrieval)한 후 검색된 내용을 컨텍스트로 활용하여 답변을 생성(Generation)하도록 구성한다.

 

엔터프라이즈 환경에서 RAG 파이프라인은 크게 세 단계로 동작한다.

 

첫째, 내부 저장소(NAS, 클라우드 스토리지, 사내 위키 등)에 존재하는 비정형 텍스트 데이터를 수집하여 일정한 크기로 분할(Chunking)한다.

 

둘째, 분할된 텍스트를 임베딩 모델을 통해 벡터(Vector) 값으로 변환하여 Vector DB에 저장한다.

 

셋째, 사용자의 질의가 입력되면 Vector DB에서 가장 유사도가 높은 문서 조각을 추출하여 LLM에 컨텍스트로 제공한다.

 

Vector Database는 원본 문서를 저장하는 저장소가 아니라, 문서를 벡터 형태로 인덱싱하여 의미 기반 유사도 검색을 수행하는 검색 계층입니다.

 

이 구조에서 RAG의 핵심 역할은 '검색의 정확도'와 '데이터의 경계'를 설정하는 것이다.

 

시스템이 사용자의 권한과 연계된 데이터 범위 내에서 정보를 탐색하도록 설계하면 기존 보안 정책(ACL)을 검색 과정에 반영할 수 있으며, 답변의 근거가 되는 출처를 추적할 수 있어 기업 운영 환경의 감사(Audit) 및 검증 체계 구축에도 활용할 수 있다.

 

기존 ACL뿐 아니라 RBAC(Role-Based Access Control), ABAC(Attribute-Based Access Control) 정책과 연계 가능한지도 함께 검토해야 합니다.

 

이러한 RAG 기반 검색 구조가 필요한 배경에는 기존 KMS의 키워드 중심 검색이 가진 한계가 있으며, 기존 사내 KMS의 검색 한계와 Enterprise AI Search가 필요한 이유에서 그 차이를 자세히 확인할 수 있습니다.

---

---

반응형

LLM API: 추론 엔진과 프롬프트 프레임워크의 결합

RAG 파이프라인이 사용자 질의에 맞는 정확한 문서를 찾아내는 '검색'을 담당한다면, LLM API는 검색된 문서들을 분석하고 사용자의 의도에 맞게 재구성하는 '추론 엔진(Reasoning Engine)'의 역할을 수행한다.

 

기업이 자체 애플리케이션이나 사내 포털에 AI 검색을 연동하기 위해서는 LLM API를 호출하여 데이터를 처리해야 한다.

이때 실무적으로 가장 중요하게 다루어져야 하는 영역이 프롬프트 프레임워크(Prompt Framework)의 설계다.

 

API를 통해 LLM에 전달되는 프롬프트는 단순히 질문을 넘기는 수준을 넘어, RAG에서 추출된 문서 데이터를 어떻게 해석하고 어떤 형식(JSON, 표, 요약 보고서 등)으로 반환할지 규정하는 시스템적 명령어 역할을 한다.

 

또한, LLM API 운영 시에는 토큰(Token) 사용량에 따른 비용과 지연 시간(Latency)을 고려해야 한다.

 

RAG 파이프라인에서 너무 많은 문서를 추출하여 API로 전송하면 처리 비용이 급증하고 응답 속도가 저하된다.

따라서 실무 환경에서는 필요한 정보만 압축하여 API에 전달하도록 컨텍스트 길이를 최적화하고, 인프라 운영 예산에 맞춰 호출 빈도와 모델의 크기를 조정하는 거버넌스가 요구된다.

---

애플리케이션 계층과 파일럿 환경에서의 NotebookLM

엔터프라이즈 지식 플랫폼을 구축할 때 모든 조직이 처음부터 대규모 RAG 아키텍처와 API 연동 개발을 진행해야 하는 것은 아니다.

특정 프로젝트 팀이나 단위 부서의 경우, 복잡한 인프라 개발 없이 즉시 활용할 수 있는 애플리케이션 계층의 도구가 필요하다.

이때 NotebookLM과 같은 소스 기반(Source-grounded) AI 도구가 중요한 역할을 한다.

 

NotebookLM은 단순한 파일럿 도구를 넘어, 향후 전사 AI 플랫폼 구축 과정에서 실제 사용자의 요구사항과 활용 패턴을 검증하는 환경으로 활용할 수 있습니다.

 

NotebookLM은 사용자가 제공한 문서를 기반으로 정보를 탐색하고 답변을 생성하는 소스 기반(Source-grounded) AI 서비스입니다.

동작 방식은 RAG와 유사한 특성을 가지지만, 기업이 직접 구축하는 API 기반 RAG 시스템과는 목적과 구현 방식이 다릅니다.

 

별도의 대규모 인프라 개발 없이 실무자가 허용된 범위의 기술 가이드 문서, 회의록, 장애 보고서 등을 활용하여 비교적 빠르게 문서 기반 지식 탐색 환경을 구성할 수 있다.

 

엔터프라이즈 아키텍처 관점에서 이러한 도구는 전사적 도입을 위한 파일럿(Pilot) 환경으로 가치가 높다.

대규모 API 연동 개발에 앞서, 실무자들은 소규모 문서 셋을 대상으로 프롬프트 프레임워크를 테스트하고 답변의 품질을 검증할 수 있다.

 

여기서 정립된 텍스트 워크플로우와 질의 패턴은 향후 전사 API 기반 RAG 시스템을 설계할 때 중요한 요구사항 정의서로 활용된다.

---

도입 형태에 따른 의사결정 기준

기업은 부서의 요구사항과 보안 정책, 예산에 따라 API 기반의 자체 RAG 구축과 SaaS형 지식 도구(NotebookLM 등)의 활용 비중을 결정해야 한다.

구분	API 기반 자체 RAG 시스템	NotebookLM 등 소스 기반 AI 도구
적용 범위	전사적 지식 검색 및 사내 시스템 통합	개별 프로젝트 팀, 단위 부서의 문서 분석
인프라 통제권	기업이 직접 Vector DB 및 파이프라인 관리	서비스 제공자의 인프라에 의존 (SaaS)
운영 복잡도	높음 (개발 인력, 임베딩 최적화, 지속적 유지보수 필요)	낮음 (별도의 인프라 구축 없이 즉시 사용 가능)
초기 비용 구조	인프라 구축, 인덱싱 컴퓨팅, API 호출 비용 발생	구독 기반 또는 무료 쿼터 활용
보안 및 규제	사내 보안 정책(On-Prem/Private Cloud) 완벽 연동 가능	퍼블릭 클라우드 서비스 약관 및 데이터 규정 확인 필요

---

---

결론

Enterprise AI Search 아키텍처는 단일 기술로 완성되지 않는다.

 

RAG는 사내 데이터를 검색하고 필요한 정보를 제공하는 기반 계층을 구성하며, LLM API는 검색된 데이터를 기반으로 추론과 업무 처리를 연결하는 역할을 수행한다. NotebookLM과 같은 도구는 최종 사용자가 문서 기반 AI 활용 가능성을 빠르게 검증할 수 있는 애플리케이션 계층의 접점을 제공한다.

 

그러나 이러한 기술적 구조만으로 기업의 데이터 파편화 문제가 자동으로 해결되는 것은 아니다.

시스템의 아키텍처가 아무리 정교하더라도, 원본 데이터의 품질이 낮거나 보안 경계가 모호하다면 AI 검색 결과 역시 신뢰도를 잃게 된다.

 

기업이 실무적으로 판단해야 할 가장 중요한 기준은 어떤 모델이나 도구를 사용할 것인지가 아니라, 내부 데이터 중 AI 검색을 통해 가장 큰 비즈니스 가치를 창출할 수 있는 '핵심 자산(Critical Asset)'이 무엇인지 식별하는 것이다.

 

명확한 데이터 범위를 설정하고 파일럿 검증을 거친 후 점진적으로 아키텍처를 확장하는 접근이 요구된다.

 

Enterprise AI Search Architecture가 준비되었다면, 다음 단계는 이를 실제 업무 프로세스와 연결하는 것입니다.

 

검색된 지식을 실제 업무 결과물로 연결하는 단계에서는 프롬프트 표준화와 LLM API 기반 자동화가 중요하며, Enterprise AI Workflow 구축: 프롬프트 자산화와 LLM API 기반 문서 자동화에서 이러한 구조를 이어서 확인할 수 있습니다.

 

다음 편에서는 프롬프트 자산화와 LLM API 기반 문서 자동화를 중심으로 Enterprise AI Workflow를 어떻게 설계할 수 있는지 살펴보겠습니다.

---

[연재] 엔터프라이즈 AI 인프라 밸류체인 구축 및 실무 가이드 이어보기

• 이전 글: 1편 : 기존 사내 KMS는 왜 원하는 정보를 찾지 못할까? Enterprise AI Search 도입이 필요한 이유
• 다음 글: 3편 : Enterprise AI Workflow 구축: 프롬프트 자산화와 LLM API 기반 문서 자동화

---

참고자료

• Google Cloud Architecture Center, Enterprise generative AI architecture
• AWS Prescriptive Guidance, Designing a Retrieval-Augmented Generation (RAG) system
• Microsoft Learn, Retrieval-Augmented Generation (RAG) in Azure AI Search