규정은 잘 답하는데, 사업은 못 답하는 AI
AX(AI 전환)를 시작하면 사내 문서로 RAG 챗봇부터 만드는 경우가 많습니다. 처음엔 꽤 쓸 만합니다. 휴가 규정, 복지 제도, 업무 매뉴얼 — 직원 질문에 곧잘 답하죠. 그런데 조금 지나면 임원에게서 이런 질문이 옵니다. "그래서 이 AI가 매출에 뭘 해주죠?"
여기서 막힙니다. 사내 문서만 넣은 RAG는 회사 안의 일만 알기 때문입니다. 경쟁사가 이번에 얼마에 냈는지, 우리 신제품 리뷰 반응이 어떤지, 시장에서 무슨 이야기가 도는지 — 사업 판단에 필요한 건 대부분 회사 밖의 데이터인데, 그게 RAG에 하나도 없습니다.
이 글은 RAG를 '연결하는 법'이 아니라 '무엇을 넣을지, 그리고 어떻게 안 낡게 유지할지' 를 다룹니다. 기술 연동은 이미 나와 있는 가이드가 많으니, 여기서는 기획하는 사람 관점에서 봅니다.
외부 데이터가 RAG를 사업 도구로 바꾼다
같은 RAG라도 무엇을 넣느냐에 따라 답할 수 있는 질문의 급이 달라집니다.
넣은 데이터답할 수 있는 질문사내 문서만"출장비 규정이 어떻게 되나요?"+ 경쟁사 가격·상품"경쟁사 대비 우리 가격이 어디서 밀리나요?"+ 고객 리뷰·VOC"최근 우리 제품 불만이 어느 항목에 몰리나요?"+ 시장·뉴스"이번 주 업계에 우리와 관련된 이슈가 있었나요?"
아래로 갈수록 임원이 궁금해하는 질문이고, 전부 외부 데이터가 있어야 답할 수 있습니다. RAG의 가치는 모델이 아니라 넣은 데이터의 범위가 정합니다.
진짜 문제는 '신선도'입니다
외부 데이터를 넣기로 했다면, 그다음 함정이 신선도입니다. 사내 규정은 몇 달에 한 번 바뀌지만, 경쟁사 가격은 매일 바뀌고 리뷰는 매시간 쌓입니다. 한 번 넣고 방치한 외부 데이터는 빠르게 독이 됩니다.
3개월 전 가격으로 답하는 AI는 틀린 답을 자신 있게 말합니다 — 차라리 모르는 것보다 위험합니다.
낡은 답이 한두 번 나오면 현업은 AI를 신뢰하지 않게 되고, 운영 서비스는 그때 사실상 끝납니다.
그래서 외부 데이터를 넣는 RAG는 **"넣는 프로젝트"가 아니라 "갱신하는 운영"**으로 설계해야 합니다. 관건은 최초 적재가 아니라 지속 갱신입니다.
신선도를 '수집 주기'로 설계하기
신선도는 막연히 "자주 갱신하자"가 아니라, 데이터 종류별로 필요한 주기를 정하는 문제입니다.
데이터 성격에 따라 주기를 나눈다
빠르게 변하는 것(가격·재고·순위): 일 단위 이상 갱신이 필요합니다
중간(리뷰·게시글): 일~주 단위
느린 것(기업 정보·카탈로그): 주~월 단위
갱신을 파이프라인에 위임한다
정해진 주기에 맞춰 수집 → 정제 → 벡터DB 갱신이 자동으로 도는 구조를 만들어야 합니다. 사람이 매번 손으로 넣는 방식은 몇 주를 못 갑니다.
낡음을 감지한다
마지막 갱신 시각을 데이터에 기록하고, 갱신이 끊기면 알림이 오게 합니다. "언제 수집된 데이터인지"를 답변 근거로 함께 보여 주면 신뢰도도 올라갑니다.
이 세 가지가 갖춰지면 신선도는 관리 가능한 지표가 되고, RAG는 시간이 지나도 낡지 않습니다.
정제 없는 원본은 RAG에 바로 못 넣는다
한 가지 더. 크롤링한 원본을 그대로 벡터DB에 밀어 넣으면 검색 품질이 떨어집니다. 중복 문서가 답을 오염시키고, 형식이 제각각인 값은 비교가 안 되며, 다국어 리뷰는 그대로면 검색에 안 걸립니다.
그래서 수집과 RAG 사이에 정제 레이어가 필요합니다. 중복 제거, 형식 표준화, 그리고 감성·분류·번역 같은 AI 분석으로 원본에 구조를 입히면, 검색이 정확해지고 필터링도 가능해집니다. 해시스크래퍼는 수집한 데이터에 이 정제·분석을 얹어 API·DB로 전달하기 때문에, RAG에 바로 태울 수 있는 형태로 받을 수 있습니다. 정기 수집 주기가 곧 RAG의 신선도 주기가 되고요.
자주 묻는 질문
Q. 외부 데이터 연결은 기술 문제 아닌가요? 왜 기획이 먼저인가요? 연결 자체는 기존 가이드로 해결됩니다. 하지만 '무엇을 어느 주기로 넣을지'를 잘못 잡으면 기술이 완벽해도 낡은 답이 나옵니다. 신선도 설계는 기술이 아니라 기획 결정입니다.
Q. 얼마나 자주 갱신해야 하나요? 데이터 성격에 따라 다릅니다. 가격·순위처럼 자주 변하는 건 일 단위, 기업 정보처럼 느린 건 주·월 단위가 기준입니다. 대상별로 주기를 나눠 설계하면 비용과 신선도의 균형을 맞출 수 있습니다.
Q. 수집한 데이터를 우리 벡터DB에 바로 넣을 수 있나요? 정제를 거치면 가능합니다. 중복 제거·형식 표준화·AI 분석을 얹은 데이터를 API·DB로 전달받아 사내 파이프라인에서 벡터DB에 적재하는 구조가 일반적입니다.
함께 보면 좋은 글
지금 바로 시작하기
RAG에 넣을 외부 데이터가 필요하신가요? 어떤 데이터를 어느 주기로 신선하게 유지할지, 목적을 알려주시면 수집·정제·갱신 구조를 함께 설계해 드립니다.




