[RAG] 최신 AI 서비스들이 '답변 출처'를 표시할 수 있는 이유
RPA를 주로 하는 레거시, 폐쇄 환경 위주의 기업에서도 AI의 바람은 피할 수 없는지, 요즘 회사에서 RAG를 이용하여 학습을 하고 주기적으로 내부 POC를 진행하자는 얘기가 나왔다.
진행하면서 겪은 내용 및 문제점 등 모든 경험을 정리해 볼 예정이다.
이것마저 AI(나노 바나나)로 생성한 이미지이다..
RAG란?
RAG(Retrieval-Augmented Generation, 검색 증강 생성)를 한 문장으로 요약하면 ‘AI가 모르는 내용을 외부 데이터베이스에서 직접 찾아보고 답변하게 만드는 기술’이라고 AI가 답변을 해줬다.
LLM의 한계
AGI의 영역에 도달하여 LLM의 로직을 새로 구성하지 않는 이상 LLM의 한계는 명확하다.
- 새롭게 학습이 되기 전까지는 최신 데이터가 없다.
- 회사 내부 데이터같은 대중적이지 않은 데이터는 없다.
- 비싸다.
등등… 이러한 문제점을 해결하기 위하여 RAG라는 신개념의 기술이 나왔다고 한다.
RAG 아키텍쳐
결론적으로 최종 목표는 LLM에 보다 더 잘 질문하려고 사용하는 것이다.
DB에 필요한 데이터를 넣어두고, 사용자의 질문에 따라 필요한 데이터를 꺼내서 기존의 프롬포트와 합쳐 LLM에 질문하면 끝이다.
RAG 구현
처음엔 회사에서 진행을 했었고, 그 후에 따로 개인적으로도 구현을 했었다.
- 회사에서 하던 방식
- LangFlow 기반으로 만들어진 솔루션을 이용하여 기존 시스템과의 연동 기반
- 개인적으로 하던 방식
- FastAPI를 이용하여 백앤드 위주의 채팅용 UI 구성
첫 번째 구현
회사에서 쓰는 Brity Automation이라는 RPA 기반의 플랫폼에 AI 관련 기능이 추가되었다. 알아보니 LangFlow 기반으로 만들어졌다고 한다. 처음 RAG를 구현하려다 보니 아이디어 구상이 꽤나 어려웠다. 이런 저런 시도를 거치다가 선정한 주제는 ‘특정 회사에 대한 주가 전망을 분석하고 알려주는 AI’ 였다. 대략적인 플로우는 아래와 같다.
예상 시나리오
1. RPA로 매일 아침 기업의 금융 분석 리포트/기업 관련 뉴스를 다운로드 한다.
↓
2. LLM을 이용하여 리포트/뉴스를 요약한다.
↓
3. 청킹, 임베딩 과정을 통하여 백터 DB에 저장한다.
↓
4. 사용자의 질문 + 시스템 프롬포트 + RAG 데이터를 합쳐 AI에게 최종 질문을 하고 답변을 받는다.
결과
PlayGround로 테스트 한 결과이다.
문제점
- 수 많은 기업의 자료를 가지고 있는 것 자체가 힘들다.
- 국내 기업으로만 한정해도 상장 기업이 2700개 정도인데, 이 자료를 모두 관리하기엔 다소 무리가 있다.
- 주식을 추천하기에는 어차피 과거 데이터이다.
- 리포트 자료와 뉴스 데이터는 과거 데이터이므로, 호재가 있더라도 이미 주가에 반영이 되어 있을 가능성이 높다.
- 정보의 신뢰도가 낮다.
- 여러 리포트와 뉴스를 결합했을 때, 조금이라도 환각 증세가 나온다면 완전히 뒤바뀐 결과를 낼 수도 있다.
- 주가 전망은 수치(재무제표, 주가 차트, 거래량)가 상당히 중요하다.
- 단순 텍스트만으로는 주가 전망을 표현하기가 힘들다.
첫 번째 구현 - 최종 결론
저 문제점들을 종합했을 때, 주가 전망과 주식 추천이라는 종목은 리스크가 너무 컸다. 시간이 많이 흘러 몇 년치~몇 십년치 데이터가 쌓이면 좋은 지표로 활용될 수도 있겠으나, 시장의 변동성을 생각했을 때 당장 좋은 아웃풋을 내기에는 힘든 주제였다고 생각한다. 다음번에 비슷한 걸 만든다면 모든 자산 관리와 AI를 활용한 내 포트폴리오 분석, 그리고 데이터를 축적해놓는 방식이 아닌 간단하게 시장 상황을 알아보는 기능, 자동 매매, 예상 수익 등 기업 분석보단 자산 관리에 초점을 맞춘 쪽으로 만드는게 좋을 것 같다고 생각한다.
사용한 기술 스택
- RPA
- 프레임워크: LangFlow(플랫폼에서 구현)
- 임베딩: OpenAI
- LLM: OpenAI
- 벡터 DB: 오픈서치
두 번째 구현
개인적으로 RAG개념과 AI 바이브 코딩을 경험할 겸 새로운 주제로 작은 프로그램을 만들기로 결정했다. 바이브 코딩에 대한 얘기는 다른 파트에서 다뤄보기로 하고.. 여기서는 RAG 위주로 얘기해 볼 예정이다. 어떤걸 주제로 선정해야 할까 고민을 하다가, 특성상 도메인에 종속될 수 밖에 없다고 생각해서 이번엔 의료 관련한 챗봇 비슷한 걸 만들면 쓸만하지 않을까 싶어 주제를 의료 관련 앱으로 정했다. 자료는 AI Hub라는 국가에서 운영하는 홈페이지에서 JSON 형식으로 다양한 샘플 데이터를 받을 수 있길래, 거기서 필수의료 의학지식 데이터를 다운 받아서 구현을 시작했다.
예상 시나리오
1. RAG에 의학지식 데이터를 미리 저장해둔다.
↓
2. 사용자가 질문시 유사도가 높은 청크 2개를 가져온다.
↓
3. RAG에서 가져온 내용을 LLM을 통하여 수정, 보완 및 요약까지 진행한다.
↓
4. 사용자에게 결과를 보여준다.
결과
top2 검색과 출처까지 보여준다.
문제점
- 의료 도메인 자체가 이미 AI가 학습을 했다.
- 최신 논문같은게 아닌 이상 이미 있는 데이터라 큰 의미가 없다.
- 환각 현상이 절대 일어나면 안된다.
- AI의 특성상 그럴듯한 답변을 할텐데 생명과 직결된 의료에서는 절대 일어나면 안되는 일이다.
- 의료는 단순 텍스트만 있는게 아니다.
- X-ray, 초음파 등 사진도 있으므로 멀티 모달이 필요하다.
- 정신적인 치료는 힘들다.
- 기계의 질문 답변 위주로는 정서적인 공감을 원하는 인간적인 치료는 불가능하다.
두 번째 구현 - 최종 결론
결과적으로 의료 도메인에 RAG를 접목하는 시도는 기술적인 구현보다 데이터의 가치와 윤리적 책임이라는 문제를 실감하게 했다. 이미 방대한 의학 지식을 학습한 LLM에게 일반적인 수준의 RAG 데이터를 제공하는 것은 사용자에게 새로운 가치를 전달하기가 힘들다고 생각했다. 특히 생명과 직결된 분야인 만큼, 1%의 환각도 허용되지 않는 의료 환경에서 현재의 RAG 구조는 보조적인 수단 이상의 역할을 수행하기 어려워 보였다. 만약 이 프로젝트를 고도화한다면, 단순 질의응답을 넘어 멀티 모달(Vision) 기능을 탑재해 엑스레이나 판독문을 분석하거나, 병원 예약 및 처방전 관리 같은 실무적인 의료 비서 서비스로 방향을 트는 것이 훨씬 실용적일 것이라는 결론을 내렸다.
사용한 기술 스택
- 프레임워크: FastAPI
- 임베딩: Gemini (text-embedding-004)
- LLM: Gemini (gemini-2.5-flash)
- 벡터 DB: Chroma
- 데이터 소스: AI Hub (필수의료 의학지식 데이터)
그래서 최신 AI 서비스들이 ‘답변 출처’를 표시할 수 있는 이유는?
제목으로 달아놓은 걸 글 마지막에서야 작성해본다. AI 서비스 업체에서 제공하는 이미 학습된 AI인 LLM만 사용하면 출처를 표시할 수 없지만, 내부에서 직접 만드는 RAG를 사용하면 벡터 DB에 저장시 문서의 출처를 같이 저장하고 최종 답변시 보여주면 출처를 표시할 수 있게 되고, 사용자에게 신뢰성을 높여줄 수 있는 서비스가 되는것이다.
RAG에 저장하는 전략, 검색하는 전략도 다양한 방법이 있는데 이것도 다른 글에서 다뤄보기로 하겠다. 이번에 한 두 개의 프로젝트는 RAG를 처음 접해보는 터라 이해도가 떨어져서 제대로 사용을 못 한 느낌이다. 이젠 개념과 사용 방법, 사용 예시 등 잘 알게되었으니 다음번에는 목적에 맞게 더 잘 구현할 수 있을 것 같다.
시간이 좀 지나서 어쩌다보니 한 번 더 내부에서 RAG 프로젝트를 진행하게 되었다.
세 번째 구현
이전에 경험으로 이루어보아, 기업에서 RAG로 활용하기 좋은 가장 좋은 케이스는 내부 문서였었다. 기업의 사규, 내부 회계 장부, 직원 정보 등 AI에게는 없는 데이터이며 다음 버전 모델에서도 학습할 일이 없는 데이터가 적합하다는 것을 느꼈다. 원래는 vision 기능을 활용한 영수증 처리와 회계 전산쪽 서비스를 만들려고 했으나, 사정상 ‘사용자가 보고서를 올리면 내부 문서들을 참조하여 보고서의 적합성을 검증’하는 서비스로 정하게되었다. 다만 기존에 하던 기능과 차별점을 두기 위해 MCP를 사용해서 만들었다.
예상 시나리오
1. RAG에 기업 사규 등 내부 데이터를 미리 적재해놓는다.
↓
2. 사용자가 보고서를 업로드 한다.
↓
3. LLM을 사용하여 보고서 내용을 요약하여 검증이 필요한 부분을 추린다.
↓
4. 검증이 필요한 부분과 RAG의 사규 데이터를 비교하여 적합성 여부를 판단한다.
↓
5. 검증이 완료되면 검증 결과와 요약 내용, 참조한 문서를 답변해준다.
결과
웹페이지로 구성된 파일 업로드 이후 채팅을 하는 화면
문제점
- 보고서에 한정되어 있으며, 그 기준이 모호하다.
- 내부 문서 종류는 다양하지만 보고서 위주만 가능하다.
- 사실상 텍스트 기반의 단락이 잘 나누어진 형식의 보고서만 된다.
- 업로드 하는 파일 자체를 검증하지는 않는다.
- 확장자만 검사할 뿐 전혀 다른 종류의 파일을 올리더라도 업로드 취소를 할 수 없다.
- 문서간의 관계성이 떨어진다.
- 문서 개수, 종류가 많아진다고 했을때 각각의 관계성을 표시할 수 없어, 추후 검색시 문제가 생길 가능성이 높다.
세 번째 구현 - 최종 결론
결과적으로 기업에서 활용하기에 가장 현실적이고 강력한 도구는 내부 문서를 활용한 RAG라는 것을 확인했다. 앞선 두 번의 시도에서 느꼈던 데이터의 중복성이나 신뢰도 문제를 해결할 수 있는 가장 확실한 방법이었기 때문이다. 비록 사정상 보고서 검증으로 주제를 좁혔지만, 기업 내부에 쌓여있는 방대한 비정형 데이터를 AI가 읽고 판단해준다는 점은 충분히 매력적인 서비스 모델이라고 생각한다.
하지만 실제 구현을 해보니 단순히 문서를 데이터베이스에 넣는 것보다 ‘데이터의 품질과 맥락’을 관리하는 것이 훨씬 중요하다는 것을 깨달았다. 특히 세 번째 문제점으로 꼽았던 문서 간의 관계성 부재는 향후 서비스 고도화에서 반드시 해결해야 할 숙제로 남았다. 단일 문서의 내용을 파악하는 수준을 넘어, 여러 문서가 얽혀있는 복잡한 사규나 규정을 정확히 연결할 수 있어야 진정한 의미의 업무 보조가 가능할 것 같다.
만약 이 프로젝트를 다음 단계로 발전시킨다면, 텍스트뿐만 아니라 표나 이미지를 더 정확하게 인식할 수 있는 전처리 과정을 추가하고, 멀티모달이 가능한 AI 도입과 문서 간의 연관 관계를 그래프 형태로 연결하여 검색 정확도를 높이는 방향으로 구현해보고 싶다. 이번 세 번의 구현을 통해 RAG는 단순히 기술적인 연결을 넘어, 우리가 가진 데이터를 어떻게 구조화하느냐가 핵심이라는걸 느꼈다.
사용한 기술 스택
- 프레임워크: FastAPI
- 임베딩: Gemini (text-embedding-004)
- LLM: Gemini (gemini-2.5-flash)
- 벡터 DB: Opensearch
- MCP: Parent-Child 청킹, AI 요약 등