챗GPT 같은 AI가 아무리 말을 잘한다고 해도, 정작 우리 회사 취업 규칙이나 작년에 체결한 주요 고객사 계약서 내용을 물어보면 엉뚱한 소리를 하거나 모른다고 답합니다. 업무 자동화를 추진하며 처음 시스템 구축을 의뢰하려는 회사 대표님들이나 운영 책임자분들이 공통으로 묻는 질문이 있습니다. '외부의 똑똑한 AI가 다른 소리 없이 오직 우리 회사 자료만 보고 답하게 할 수는 없을까?'
이 질문의 해답을 찾다 보면 필연적으로 RAG란 무엇인지 마주하게 됩니다. 유행하는 기술 용어를 걷어내고, 기업의 쌓인 데이터와 반복 업무를 자동화하기 위해 AI를 도입할 때 왜 이 기술이 필요한지, 그리고 막상 적용했을 때 부딪히는 한계점은 무엇인지 당장 실무에 적용할 수 있는 기준으로 쉽게 정리해 드립니다.
RAG란? 먼저 찾고, 찾은 것으로만 답하는 원리
RAG(Retrieval-Augmented Generation)는 글자 그대로 '검색(Retrieve)'하여 '답변을 생성(Generation)'하는 기술입니다. 과거에는 AI가 똑똑해지려면 회사의 모든 자료를 직접 학습시키는 값비싼 파인튜닝(미세조정) 과정을 거쳐야만 한다고 생각했습니다. 하지만 RAG는 전혀 다른 접근 방식을 취합니다.
먼저 기업의 원본 데이터를 안전한 사내 저장소에 둡니다. 사용자의 질문이 들어오면 AI는 답을 바로 지어내는 대신, 저장소에서 필요한 사실만 먼저 '검색'하여 발췌합니다. 그리고 그 찾아낸 문서만을 근거로 삼아 최종 답변을 작성합니다.
최근 오픈AI의 GPT-5.6 제품군(Sol, Terra, Luna)이나 앤스로픽의 Claude 5 라인업(Fable, Opus, Sonnet, Haiku 4.5), 구글의 Gemini 3.6 Flash 등 최신 모델들은 한 번에 읽어낼 수 있는 정보량(컨텍스트 윈도우)이 엄청나게 늘어났습니다. 그럼에도 불구하고 기업들은 여전히 RAG를 필수 인프라로 채택합니다. 매번 질문을 할 때마다 회사의 전체 데이터베이스를 통째로 모델에 밀어 넣고 읽게 하는 것은 응답 속도와 컴퓨팅 비용 면에서 극히 비효율적이기 때문입니다.
이 구조의 가장 큰 장점은 정보 유출과 환각(거짓 답변)을 크게 줄일 수 있다는 점입니다. AI가 자신이 학습했던 과거의 방대한 지식에 의존해 짐작하는 대신, 눈앞에 주어진 회사 규정집이나 매뉴얼만 요약해서 대답하기 때문입니다. 게다가 최근의 RAG는 단순히 한 번 검색해서 답변하는 1세대 방식을 넘어섰습니다. AI 스스로 어떤 질문을 해야 할지 계획하고 여러 단계를 거쳐 문서를 추적해 검증하는 '에이전틱 RAG(Agentic RAG)' 구조가 주류로 자리 잡았으며, LangChain, Dify, RAGFlow 같은 프레임워크가 이를 든든하게 뒷받침하고 있습니다.
검색이 실패하면 답변도 실패한다: 명확한 기술적 한계
원리가 명쾌하다고 해서 모든 문제가 마법처럼 풀리는 것은 아닙니다. RAG 기반 시스템을 회사에 도입할 때는 이 기술이 지닌 명확한 한계를 반드시 인지해야 합니다.
첫 번째 한계는 '검색(Retrieval) 단계가 전체 품질의 병목'이라는 점입니다. 모델의 지능이 아무리 뛰어나도, 애초에 찾아온 문서 자체가 엉뚱하다면 오답을 낼 수밖에 없습니다. 흔한 실패 사례로, 단순한 벡터 검색 방식을 적용했다가 AI가 "재무 책임자 존 스미스"와 "영업 부서 존 스미스"를 구분하지 못해 전혀 엉뚱한 부서의 문서를 가져오는 문제가 기업들의 큰 두통거리가 되고 있습니다.
두 번째는 데이터 거버넌스의 부재가 곧 보안 사고로 직결된다는 점입니다. RAG는 원본 문서 저장소의 권한을 그대로 상속받아 작동합니다. 사전에 문서별 접근 권한 설정과 민감도 분류(Labeling)가 엉망이라면, AI가 '임원 회의용 민감 문서'를 요약해서 질문을 던진 일반 직원이나 고객에게 친절하게 안내해 버리는 치명적인 사고가 발생합니다. 즉, AI를 도입하기 전에 우리 회사의 데이터부터 깨끗하게 정비하는 거버넌스 수립이 필수적입니다.
우리 회사에 도입한다면? 3가지 필수 점검 포인트
실제 업무에 AI 시스템을 무사히 안착시키기 위해 의뢰 전 반드시 점검해야 할 기준이 있습니다. 겉보기엔 그럴싸한 데모를 만들었지만, 실제 서비스 전환(Production)에 실패하여 재무적 이익을 증명하지 못하는 파일럿 프로젝트가 전체의 95%에 달한다는 통계를 가볍게 넘겨서는 안 됩니다.
1. 예상치 못한 인프라 고정 비용 확인
클라우드 기반의 관리형 서비스는 보통 '사용한 만큼 낸다'고 생각하기 쉽습니다. 하지만 데이터를 저장하고 검색하는 벡터 데이터베이스에는 숨겨진 최저 유지비가 존재할 수 있습니다. 예를 들어, 기업용 RAG 서비스를 통폐합한 AWS의 Amazon Bedrock Knowledge Bases에서 기본 설정인 서버리스 옵션을 사용할 경우, 사용자 트래픽이 전혀 없는 상태에서도 월 최소 약 350달러 안팎의 고정 유지비가 발생합니다. 초기 예산 계획 시 이러한 고정비를 반드시 고려해야 합니다.
2. 규제 컴플라이언스와 데이터 주권 방어
유럽연합의 AI Act(인공지능법) 집행이 본격적으로 시작되는 등 글로벌 규제가 엄격해지는 추세입니다. 금융, 의료 등 민감한 고객 데이터를 다루는 산업군이라면 일반적인 퍼블릭 클라우드 RAG 대신 데이터 주권이 보장되거나 자체 호스팅(Self-hosting)이 가능한 환경을 꾸려야 합니다. 마이크로소프트의 Azure AI Foundry와 Azure AI Search를 결합해 사내 데이터 파이프라인 단편화 없이 안전한 에이전트를 구축하는 식의 규제 준수 특화 설계가 중요해지고 있습니다.
3. 단일 '정확도'가 아닌 입체적 품질 평가
완성된 시스템을 테스트할 때 단순히 '질문에 정답을 맞췄나'라는 하나의 지표만 믿는 것은 위험합니다. 앞서 말씀드린 RAG의 단계별 특성을 고려하여, ①원하는 문서를 잘 찾아왔는가(Retrieval Quality) ②답변이 그 문서 내 사실에만 기반했는가(Groundedness) ③자체적으로 환각을 섞지 않았는가(Faithfulness) 등 세 가지 지표를 엄격하게 분리하여 평가해야 합니다. 이를 위해 Ragas나 Confident AI 같은 최신 평가 프레임워크를 도입해 조용히 품질이 하락하는 현상을 막아야 합니다.
실제 프로젝트 설계: 찾아서 근거로만 쓰는 구조
RAG의 본질은 방대한 자료 속에서 '먼저 찾고, 조건에 맞을 때만 근거로 활용한다'는 것입니다. 실제 저희 센티프에서는 다이어트 기록 앱 'datoki'의 요청을 받아 이 원리를 극대화한 AI 대화 에이전트를 설계했습니다.
무수히 쏟아지는 음식 이름과 기록 요청을 처리하기 위해, 사용자의 발화가 들어오면 무작정 언어 모델을 호출하지 않습니다. 먼저 28만 행에 달하는 식품 데이터베이스를 임베딩 방식으로 빠르게 검색합니다. 여기서 조건이 정확히 맞아떨어지는 음식 정보는 비용이 발생하는 AI 생성 모델을 호출하지 않고도 바로 영양소를 계산해 데이터로 기록합니다. 검색 결과만으로 처리가 모호한 나머지 항목들만 배치로 묶어서 최소한의 횟수로 모델에 넘기는 구조입니다. 여러 개의 음식을 한 번에 기록해도 생성 호출을 최대 1회로 방어함으로써, 무료 사용자가 주를 이루는 B2C 앱에서도 감당 가능한 원가 구조를 만들어 냈습니다.
이처럼 무조건 AI에게 질문을 던져 대답을 지어내게 하는 것이 아니라, 우리 회사가 가진 명확한 데이터베이스를 먼저 훑어보게 하고 그 통제된 근거 위에서만 움직이도록 파이프라인을 설계하는 것. 이것이 그럴싸한 장난감이 아닌 진짜 업무 자동화를 이뤄내는 기업용 AI 구축의 핵심입니다.
