<?xml version="1.0" encoding="utf-8" ?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
<title>개발기술정보 &amp;gt; 커뮤니티 &amp;gt; 블로그</title>
<link>https://devtechinfo.xyz/blog</link>
<language>ko</language>
<description>블로그 (2026-09-10 22:05:01)</description>

<item>
<title>RAG란 무엇인가: 문서를 검색한 뒤 답변하는 LLM의 구조</title>
<link>https://devtechinfo.xyz/blog/rag%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80-%EB%AC%B8%EC%84%9C%EB%A5%BC-%EA%B2%80%EC%83%89%ED%95%9C-%EB%92%A4-%EB%8B%B5%EB%B3%80%ED%95%98%EB%8A%94-llm%EC%9D%98-%EA%B5%AC%EC%A1%B0/</link>
<description><![CDATA[<p>RAG는 검색 증강 생성의 약자로, 질문과 관련된 외부 자료를 찾은 뒤 그 내용을 참고해 언어 모델이 답변하도록 구성하는 방식입니다. 사내 규정이나 제품 설명서처럼 별도로 관리되는 자료를 질문에 활용할 때 등장하는 개념입니다.</p>
<p>핵심은 모델이 이미 학습한 내용만으로 답하도록 두는 대신, 답변에 필요한 자료를 질문과 함께 제공한다는 점입니다.</p>

<blockquote style="border-left:4px solid #475569;background-color:#f1f5f9;padding:16px 20px;margin:24px 0;color:#1e293b;"><p style="margin:0;"><strong>핵심 정리</strong><br />RAG는 관련 자료를 검색해 모델의 답변 문맥에 추가하는 구조입니다. 검색 품질과 답변의 근거 일치를 나누어 확인합니다.</p></blockquote>
<h2>1. 검색과 답변 생성을 나누어 봅니다</h2>
<p>일반적인 흐름은 질문 입력, 관련 자료 검색, 참고 문맥 구성, 답변 생성 순서로 이해할 수 있습니다. 검색기는 질문과 맞는 문서 일부를 찾아오고, 언어 모델은 전달받은 내용을 바탕으로 문장을 만듭니다.</p>
<p>두 과정의 역할이 다르므로 답변이 틀렸을 때도 어디에서 문제가 생겼는지 나누어 살펴야 합니다. 자료를 못 찾은 것인지, 찾은 자료를 잘못 해석한 것인지는 다른 문제입니다.</p>
<h2>2. 문서는 검색할 수 있는 형태로 준비합니다</h2>
<p>긴 문서를 그대로 한 덩어리로 다루기보다 적절한 구간으로 나누는 구성이 흔하며, 나눈 단위를 청크라고 부릅니다. 청크가 너무 짧으면 설명의 앞뒤가 끊길 수 있고 너무 길면 질문과 관계없는 내용이 함께 들어갈 수 있습니다.</p>
<p>문서 제목, 작성일, 항목 이름 같은 정보도 검색 결과를 해석하는 데 도움이 됩니다. 표나 목록은 문장을 나누는 과정에서 관계가 사라지지 않는지 확인해야 합니다.</p>
<h2>3. 임베딩은 검색을 돕는 표현입니다</h2>
<p>임베딩은 텍스트 등을 숫자 벡터로 표현하는 방법입니다. 벡터를 사용하는 검색에서는 질문과 문서의 표현을 비교해 관련성이 높은 후보를 찾습니다.</p>
<p>다만 RAG가 반드시 벡터 검색만 사용해야 하는 것은 아닙니다. 단어 기반 검색을 활용하거나 서로 다른 검색 방식을 함께 사용할 수도 있습니다. 어떤 검색 구성이 적합한지는 문서 성격과 실제 질문으로 확인할 문제입니다.</p>
<h2>4. 찾아온 문서를 모두 넣지는 않습니다</h2>
<p>검색 결과에는 중복된 내용이나 질문과 관련성이 낮은 구간이 섞일 수 있습니다. 필요한 결과를 추리고 순서를 조정하는 단계가 그래서 중요합니다.</p>
<p>모델이 한 번에 처리할 수 있는 문맥의 범위도 고려해야 합니다. 자료를 많이 넣었다는 사실만으로 답변이 좋아지는 것은 아닙니다. 질문의 답이 담긴 부분을 충분한 맥락과 함께 전달했는지가 핵심입니다.</p>
<h2>5. 가상의 사내 규정 질문으로 이해합니다</h2>
<p>예를 들어 직원이 교육비 신청 절차를 묻는 상황을 생각해 볼 수 있습니다. 시스템은 관련 규정을 찾고, 신청 대상과 제출 항목이 담긴 부분을 모델에 전달합니다.</p>
<p>모델은 그 자료를 읽고 절차를 정리합니다. 이때 검색 대상에 예전 규정만 들어 있다면 답변도 오래된 내용을 따를 수 있습니다. 문서를 준비할 때 버전과 적용 시점을 함께 관리해야 한다는 뜻입니다.</p>
<h2>6. 출처가 있어도 정답을 보장하지는 않습니다</h2>
<p>답변에 문서 링크를 붙일 수 있다는 점은 검토에 유용하지만, 링크가 있다는 이유만으로 내용 전체를 믿을 수는 없습니다. 실제 인용 구간이 질문에 답하는지, 생성된 문장이 자료에 없는 내용을 덧붙이지 않았는지 확인해야 합니다.</p>
<p>관련 자료를 찾지 못했을 때는 근거가 부족하다고 알리는 처리도 필요합니다. RAG는 근거를 제공하는 구조이며 오류 가능성을 없애는 이름은 아닙니다.</p>
<h2>7. 파인튜닝과는 바꾸는 대상이 다릅니다</h2>
<p>파인튜닝은 추가 학습으로 모델의 가중치를 조정하는 접근입니다. RAG는 일반적으로 질문을 처리할 때 가져오는 외부 문맥을 구성하는 접근입니다.</p>
<p>답변 형식이나 과업 수행 방식을 학습시키려는 요구와, 관리 중인 문서를 답변에 참고시키려는 요구는 구분해서 볼 수 있습니다. 둘은 반드시 하나만 골라야 하는 관계가 아니며, 필요한 경우 함께 사용할 수도 있습니다.</p>
<h2>8. 작게 평가한 뒤 범위를 넓힙니다</h2>
<p>처음에는 실제로 받을 만한 질문과 답의 근거 문서를 한 쌍씩 준비해 봅니다. 검색 결과에 필요한 문서가 들어오는지, 답변이 그 근거와 맞는지를 따로 기록합니다.</p>
<p>정답이 문서에 없는 질문도 넣어 무리하게 답을 만드는지 확인합니다. 질문·검색·생성을 나누어 관찰하면 모델을 바꿔야 할 문제와 문서 정리부터 고쳐야 할 문제를 구별하는 데 도움이 됩니다.</p>
<h2>참고 자료</h2>
<ul><li><a href="https://www.ibm.com/think/topics/retrieval-augmented-generation" rel="nofollow">IBM: RAG 개념과 검색 구조</a></li><li><a href="https://www.ibm.com/think/topics/rag-vs-fine-tuning" rel="nofollow">IBM: RAG와 파인튜닝 비교</a></li><li><a href="https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html" rel="nofollow">AWS: 검색 결과와 근거를 활용하는 Knowledge Bases</a></li></ul>]]></description>
<dc:creator>그누보드5_2rttcq</dc:creator>
<dc:date>2026-09-10T22:05:01+09:00</dc:date>
</item>

</channel>
</rss>
