RAG, 요즘 기업 AI 도입 미팅마다 빠지지 않고 나오는 단어입니다.
"우리도 사내 챗봇 하나 만들어야 할 것 같은데 RAG가 그거 맞죠?"
"ChatGPT는 보안 때문에 못 쓰고, 파인튜닝은 비싸니까 결국 RAG라더라."
맞는 말입니다. RAG는 지금 기업이 사내 자료로 AI를 쓸 수 있는 가장 현실적인 방법입니다. 그래서 글로벌 빅테크부터 국내 대기업, 중견기업까지 RAG로 방향을 잡고 있습니다.
다만 미팅의 절반 이상은 "사내 챗봇 만들어주세요"에서 멈춥니다. RAG로 챗봇 하나 만들고 끝나는 회사가 많다는 뜻이고, 진짜 가치는 거기서부터 시작합니다.
이 글에서는 RAG가 무엇인지, 일반 챗봇과 무엇이 다른지, 실무에서 어디에 쓰이는지, 도입할 때 무엇이 무너지는지를 차례로 정리합니다.
저희 팀리부뜨는 AI를 활용해 무역과 회계, 경영지원 영역에서 사내 데이터 기반 자동화를 구축하고 있어, 마지막 단락에서 저희가 RAG를 어떻게 바라보고 있는지도 함께 정리했습니다.
RAG는 Retrieval-Augmented Generation의 줄임말입니다. 한국어로 풀면 "찾아와서 답하는 AI"입니다.
기존 ChatGPT는 학습한 내용 안에서만 답합니다. 학습 시점 이후 정보나 사내 자료처럼 학습에 포함되지 않은 내용에는 답할 수 없습니다.
RAG는 다릅니다. 질문이 들어오면 사전에 연결된 사내 자료(매뉴얼, 계약서, 회의록 등)에서 답이 있을 만한 부분을 먼저 찾아와서, 그 자료를 근거로 답을 만듭니다.
비유하면 이렇습니다. 기존 AI가 "외운 것만 답하는 학생"이라면, RAG는 "회사 자료실에서 책을 펴서 답하는 학생"입니다. 같은 AI라도 어떤 자료를 참고하느냐에 따라 답의 정확도와 최신성이 완전히 달라집니다.
회사 입장에서 RAG가 중요한 이유는 두 가지입니다. 자료를 다시 학습시킬 필요가 없고, 답변에 어떤 자료를 참고했는지 출처가 남는다는 점입니다.
"우리도 사내 챗봇 만들고 싶어요"라고 할 때 떠올리는 챗봇은 보통 셋 중 하나입니다. 규칙 기반 챗봇, ChatGPT 같은 외부 LLM에 자료를 붙여 쓰는 챗봇, 파인튜닝한 자체 챗봇입니다. RAG는 이 셋과 본질적으로 다릅니다.
규칙 기반 챗봇과의 차이
규칙 기반 챗봇은 "환불"이라는 키워드가 들어오면 미리 짜둔 답을 띄우는 방식입니다. 질문 표현이 조금만 달라져도 답이 안 나옵니다. RAG는 질문의 의도를 이해해서 자료를 찾기 때문에, "B2B 환불 절차"든 "기업 고객 환불은 어떻게 해야 하나"든 같은 자료를 가져옵니다.
ChatGPT 같은 외부 LLM과의 차이
외부 LLM에 직접 붙여넣는 방식은 사내 자료를 외부 서버로 보내야 해서 보안 이슈가 생깁니다. 한 번에 처리할 수 있는 분량도 제한됩니다. RAG는 미리 인덱싱된 사내 자료에서 필요한 부분만 가져와 LLM에 넘기기 때문에, 회사 서버 안에서 동작하도록 구성할 수 있고 분량 제한도 사실상 없습니다.
파인튜닝과의 차이
파인튜닝은 사내 자료로 AI를 직접 학습시키는 방식이라 정확도는 올라가지만 견적이 수천만 원에서 억 단위입니다. 자료가 바뀔 때마다 다시 학습해야 합니다. RAG는 학습이 아니라 검색 방식이라, 자료가 바뀌면 그 부분만 다시 인덱싱하면 됩니다. 운영 비용과 갱신 부담이 훨씬 낮습니다.
세 방식 중 운영 비용, 자료 갱신 편의성, 보안 통제, 답변 출처 추적까지 네 가지를 동시에 만족시키는 방식이 RAG입니다.
기술 문서에 나오는 Retrieval, Augmented, Generation 3단계는 어디서나 같습니다. 다만 회사 안에서 실제로 일어나는 일은 좀 다릅니다.
직원이 사내 챗봇에 "A고객사 작년 4분기 발주 내역 알려줘"라고 묻습니다. RAG가 ERP, 메일함, 공유드라이브에 흩어진 자료에서 관련 부분을 가져옵니다. 가져온 자료를 LLM에 넘겨 답을 만들고, "출처: 2024년 12월 A고객사 PO_v3.pdf 2페이지"까지 함께 보여줍니다. 직원은 답을 보고, 의심이 들면 원본 PDF로 바로 넘어가서 확인합니다.
여기까지가 "사내 챗봇으로서의 RAG"입니다. 많은 회사가 이 단계에서 만족하고 멈춥니다.
그런데 실제 업무를 보면, 직원이 그 답을 확인한 다음에 해야 할 일이 남아 있습니다. PO를 ERP에 다시 입력하거나, 답변 내용으로 고객에게 회신하거나, 결재 양식에 옮기는 일입니다.
RAG의 진짜 가치는 그 다음 단계, 즉 검색된 결과가 후속 업무까지 자동으로 이어지는 흐름에서 나옵니다. 이걸 빼면 RAG는 "검색이 좋아진 위키"에 머무릅니다.
저희가 무역과 회계, 경영지원 현장에서 본 RAG 활용 패턴을 정리하면 다섯 가지입니다.
무역 PO 처리 흐름
거래처마다 양식이 다른 PO가 메일로 들어오면, RAG가 과거 동일 거래처의 PO 처리 사례를 가져와 품목, 수량, 인코텀즈를 어떻게 매핑했는지 참고합니다. 담당자는 AI가 만든 매핑 초안을 검토하고 승인만 누르면 되어, 한 건당 20분짜리 입력이 1~2분짜리 검토로 줄어듭니다.
회계 영수증과 세금계산서 분류
영수증 이미지가 들어오면 RAG가 과거 동일 거래처의 분류 이력과 회사 계정과목 규칙을 가져와 어떤 계정으로 분류해야 하는지 답합니다. 회계 담당자는 월 800건 처리하던 분류 작업을 검토 중심으로 바꿔, 월말 마감 시간이 절반 이하로 줄어듭니다.
컴플라이언스 약관 검토
신규 상품 출시 전 200페이지짜리 약관을 RAG가 과거 규제 위반 사례 DB와 대조해 위험 조항 5~10건을 자동으로 표시합니다. 컴플라이언스 팀이 1주일 들여 읽던 작업이 1일짜리 검토로 바뀝니다.
고객 응대 답변 초안 생성
까다로운 CS 문의가 들어오면 RAG가 과거 응대 이력, 약관, 매뉴얼을 종합해 답변 초안과 근거 자료를 함께 띄웁니다. 신규 입사한 CS 직원도 베테랑 수준의 응대가 가능해져, 평균 응대 시간이 5분에서 2분으로 줄어듭니다.
신입 온보딩과 사내 지식 검색
신입이 "B2B 환불 절차 어떻게 돼"라고 묻기만 하면 RAG가 영업 매뉴얼 22페이지를 찾아 절차와 출처를 함께 답합니다. 시니어가 직접 답하던 30분짜리 설명이 신입의 1분짜리 검색으로 바뀝니다.
다섯 사례 모두 공통점이 있습니다. 단순 검색이 아니라, 검색된 결과가 곧바로 다음 업무 행동으로 연결된다는 점입니다. 이게 챗봇 수준에서 멈춘 RAG와 도메인 자동화로 간 RAG의 차이입니다.
저희가 보는 RAG의 단계는 이렇게 흘러갑니다.
1단계. 사내 검색 챗봇
직원이 물으면 사내 자료에서 답을 찾아줍니다. 신입 온보딩, 규정 조회, 자료 검색 같은 영역에서 즉시 효과가 납니다. 대부분의 회사가 여기서 시작합니다.
2단계. 답변에서 업무로 연결
검색된 결과를 그냥 보여주는 게 아니라, 다음 행동까지 자동으로 만듭니다. "이 환불 케이스 답변 초안 작성해서 CS 메일 드래프트로 만들어줘"라고 하면 메일 초안까지 나옵니다. 검색이 곧 작업의 출발점이 됩니다.
3단계. 도메인 자동화의 인프라
무역 PO 처리, 회계 전표 분류, 보험 언더라이팅처럼 회사마다 다른 도메인 업무에 RAG를 깔고, 그 위에 자동화를 올립니다. 이 단계가 되면 RAG는 챗봇이 아니라 사내 데이터 기반 AI 에이전트가 동작하는 인프라가 됩니다.
저희는 RAG를 "검색이 좋아진 챗봇"이 아니라 "사내 데이터 위에서 AI가 일하게 만드는 인프라"로 봅니다. 챗봇은 그 위에 올라가는 첫 번째 응용일 뿐입니다.
저희가 현장에서 본 RAG 프로젝트가 실패하는 패턴은 거의 정해져 있습니다.
1. 데모는 멀쩡한데 실데이터 넣으면 답이 엉뚱하다
시연용 깨끗한 자료 10건으로는 다 잘 됩니다. 그런데 실제 사내 자료 1만 건을 넣는 순간 답이 흔들립니다. 자료마다 양식, 용어, 약어가 다르기 때문입니다. RAG 프로젝트의 70%는 사실상 자료 정비 프로젝트입니다. 이 작업을 PoC 이후로 미루면 본 프로젝트에서 같은 자리에 다시 부딪힙니다.
2. 권한 설계를 미루다가 폭탄이 된다
신입용 챗봇을 만들었더니 신입이 임원 평가 자료까지 검색되더라, 같은 사고가 흔합니다. 부서별, 직급별 권한이 기존 사내 시스템과 그대로 연결되지 않으면 보안팀이 처음 한 번 막아버리고 프로젝트가 멈춥니다. 권한 체계는 설계 단계에서 함께 들어가야 합니다.
3. 챗봇만 만들고 끝난다
가장 흔한 패턴입니다. 챗봇은 잘 만들어졌는데 직원들이 한 달 쓰다가 안 씁니다. 답을 받아도 그 답으로 해야 할 후속 업무가 그대로 남아 있기 때문입니다. 챗봇을 만들었다면 그 답이 결재, 입력, 회신, 작성으로 이어지는 흐름까지 함께 설계해야 합니다.
4. 도메인 지식을 빼놓고 일반 챗봇으로 만든다
무역, 회계, 의료 같은 도메인은 일반 챗봇 수준으로는 못 풉니다. "FOB랑 CIF일 때 운임 처리가 어떻게 다른가" 같은 질문은 도메인 규칙이 RAG에 함께 들어가야 답할 수 있습니다. 도메인 정확도를 끌어올리는 작업이 본 프로젝트의 성패를 가릅니다.
저희는 RAG를 도구가 아니라 사내 데이터 기반 자동화의 인프라로 봅니다. 챗봇 한 개를 만드는 게 아니라, 그 위에 무역 자동화, 회계 자동화, 컴플라이언스 자동화가 차례로 올라가는 토대를 까는 일이라고 생각합니다.
그래서 저희가 RAG를 구축할 때 우선순위가 보통 이렇게 잡힙니다.
먼저 자료가 외부로 나가지 않는 구조부터 잡습니다. 100% 폐쇄형 온프레미스, 사내 클라우드, 하이브리드 중 회사 보안 정책에 맞춰 배포 방식을 정합니다. 보안팀에 가장 먼저 답이 나오는 구조여야 본 프로젝트가 멈추지 않습니다.
다음으로 사내 자료를 정비하고 인덱싱합니다. 노션, 컨플루언스, 구글드라이브, 메일, ERP, CRM, PDF 매뉴얼이 어디에 있어도 원본은 그대로 두고 AI가 읽을 수 있는 형태로 변환합니다. 이 단계가 RAG 프로젝트의 가장 큰 비중이고, 여기서 정확도의 절반이 결정됩니다.
다음으로 도메인 지식과 권한 체계를 함께 넣습니다. 무역, 회계, 보험처럼 회사가 속한 영역의 규칙을 RAG에 결합하고, 사내 권한 체계와 자동으로 연결합니다. 팀리부뜨의 특허 자체개발 AI 기술이 이 단계에서 정확도를 끌어올립니다.
마지막으로 챗봇 위에 자동화를 얹습니다. 검색된 결과가 그 다음 업무(ERP 입력, 결재 상신, 메일 회신 등)로 이어지도록 설계합니다. 이 단계까지 와야 RAG가 단순 챗봇을 넘어 실제 일하는 AI가 됩니다.
RAG는 기술 그 자체가 새로운 가치를 주는 게 아닙니다. RAG 위에 무엇을 올리느냐가 가치를 결정합니다. 같은 RAG를 깔아도 챗봇 하나로 끝나는 회사가 있고, 무역 PO부터 회계 전표 분류까지 자동으로 도는 회사가 있습니다. 차이는 처음 설계에서 결정됩니다.
사내 챗봇을 검토하고 계시거나, 이미 만들었는데 다음 단계로 어떻게 가야 할지 고민이라면 팀리부뜨의 사무자동화 전문가와 함께 정리해보세요. 현재 어떤 사내 자료가 있고 어떤 업무 흐름에 적용하고 싶은지만 공유해주시면, 챗봇 다음 단계까지 어떻게 갈 수 있는지 보여드립니다.
상담문의 시 "RAG 글을 보고 문의했다"고 남겨주시면 보다 원활한 상담이 가능합니다.
지금 기업 맞춤형 AI 도입 상담을 받아보세요.
[1:1 도입 문의하기]
%202.png){kind=logo}
