[활용가이드] kt cloud AI RAG(검색 증강 생성) 활용법 – 컨텍스트 최적화로 성능 높이기

 

 

[ kt cloud Cloud컨설팅팀 심대섭 님 ]

📋 요약

이 글에서는 RAG(검색 증강 생성) 기반 LLM 서비스에서 컨텍스트 품질이 답변 성능에 미치는 영향과,
TopK 조정·rerank·중복 제거·질문 기반 압축 등 실무 적용 가능한 컨텍스트 최적화 기법을 다룹니다.
프롬프트 튜닝보다 근거 문서의 선별·정제·구조화가
답변의 신뢰성과 일관성을 결정하는 핵심 변수임을 정리합니다.

#RAG #컨텍스트최적화 #rerank #TopK #query-aware-compression

 

---

LLM을 서비스에 붙이면 가장 먼저 손대는 건 보통 프롬프트입니다. 그런데 운영 단계로 들어가면, 프롬프트를 아무리 다듬어도 답변 품질이 들쭉날쭉한 상황을 자주 마주합니다. 특히 RAG처럼 문서를 붙여 답하게 만드는 구조에서는 “문장을 잘 쓰는 능력”보다 “모델이 어떤 입력을 받았는지”가 결과를 더 크게 좌우합니다.

 

kt cloud처럼 RAG 기반 서비스를 활용하는 외부 사용자 관점에서도 마찬가지입니다. 사용자 질문이 요금·약관·SLA·보안 가이드처럼 책임이 걸리는 영역으로 갈수록, 프롬프트의 표현보다 근거 문서가 어떻게 선별·정제·구조화되어 들어왔는지가 신뢰를 결정합니다. 이 글은 그 이유를 정리하고, 바로 적용 가능한 개선 포인트를 실무 기준으로 묶었습니다.

RAG 전체 흐름 다이어그램(Image: AI-Generated Content)

1. 사용자 질문 입력: 질문의 범위와 출력 형식(표, 요약, 조건 포함)을 먼저 확정
2. 문서 검색(리트리벌): 검색 대상(문서 집합)과 필수 메타데이터(버전, 날짜, 출처) 기준을 고정
3. TopK 후보 선택: TopK는 최소로 시작하고, 불필요한 후보가 섞이면 즉시 축소
4. 재정렬(rerank): 상위 근거가 질문과 직접 연결되는지 확인하고, 상위 몇 개만 남김
5. 필터링·중복 제거·버전 정합: 구버전 제거, 중복 제거, 충돌 문구가 함께 들어오지 않게 차단
6. 질문 기반 압축: 문서 전체가 아니라 질문에 필요한 문장만 남기고 나머지는 과감히 제거
7. 컨텍스트 패키징: 규칙 → 질문 재정의 → 근거 3~5개 → 답변 형식 순서로 고정
8. LLM 답변 생성(근거 인용): 근거 인용을 기본값으로 두고, 근거가 부족하면 추가 질문으로 전환

---

1) 모델은 입력 기반으로 답을 만든다.

LLM은 “좋은 문장”을 이해한 뒤 답을 쓰는 방식이라기보다, 현재 입력된 토큰 전체를 조건으로 다음 토큰을 예측합니다. 모델은 학습된 지식 위에서 동작하지만, 최신·사내·정책 질문의 사실성은 입력으로 주어진 근거에 크게 좌우됩니다.

 

여기서 자주 생기는 오해가 있습니다. “모델이 똑똑하니까 알아서 맞게 답하지 않을까?”라는 기대입니다. 하지만 근거가 입력에 없으면 모델은 추측으로 메워야 하고, 추측은 문장이 자연스러워도 업무적으로는 위험합니다. RAG가 필요한 이유도 결국 같습니다. 정답을 만들 재료를 입력으로 제공하겠다는 선택이기 때문입니다.

---

2) 프롬프트는 지시이고, 컨텍스트는 증거다.

프롬프트는 방향을 잡습니다. 예를 들어 “정책 기준으로 답해라”, “표로 정리해라”, “근거를 인용해라” 같은 지시가 여기에 해당합니다.

 

컨텍스트는 내용의 원재료입니다. 문서 발췌, 표, 로그, 약관 문구, SLA 조항, 릴리즈 노트처럼 실제 답을 구성하는 증거입니다.

 

현장에서는 지시를 조금 더 정교하게 쓰는 것보다, 증거를 더 정확하게 넣는 쪽이 품질에 더 큰 영향을 줍니다. 프롬프트가 훌륭해도 근거가 부정확하거나 서로 충돌하면 답이 흔들리고, 프롬프트가 단순해도 근거가 선명하면 답이 안정됩니다.

---

3) 컨텍스트가 망가지는 대표적인 4가지 패턴

컨텍스트는 잡음에 매우 취약합니다. 특히 아래 4가지가 섞이면 모델은 생각보다 쉽게 틀립니다.

1. 관련 없는 문단이 많이 들어오는 경우
   검색 품질이 낮거나 TopK를 과도하게 키우면, 질문과 무관한 청크가 섞이면서 판단이 흐려집니다.
2. 서로 충돌하는 정보가 함께 들어오는 경우
   구버전·신버전 문서가 섞이면 모델은 둘 중 하나를 임의로 선택하거나, 둘을 섞어 새로운 규칙을 만들어버릴 수 있습니다.
3. 중복 문장이 많은 경우
   같은 내용이 여러 청크에 반복되면 모델은 중요도를 잘못 추정할 수 있고, 결론 문장에 편향이 생기기도 합니다.
4. 핵심 근거가 질문과 멀리 떨어진 경우
   긴 입력에서 핵심 근거가 뒤쪽에 몰리면, 앞쪽 잡음이 더 크게 영향을 주는 경향이 생깁니다.

이 상황에서는 “프롬프트를 더 잘 쓰기”로 해결이 잘 안 됩니다. 해법은 대체로 하나입니다. 덜 넣고 더 정확히 넣기.

즉, 입력 묶음을 재구성해야 합니다.

구분	정제되지 않은 컨텍스트	정제된 컨텍스트
입력 문서	다수, 중복 포함	3~5개 핵심 근거
버전	구/신 혼재	최신 기준
관련성	질문과 간접적	질문 직접 연결
모델 동작	추측 발생	근거 기반 판단
답변 특성	그럴듯함	검증 가능

< 표1. RAG 입력 컨텍스트 정제 전·후에 따른 답변 품질 차이>

---

4) 토큰 예산은 한정돼서 무엇을 넣을지가 곧 성능이다.

컨텍스트 윈도우가 커져도 무한은 아닙니다. 그리고 더 많이 넣을수록 비용과 지연이 증가합니다.

더 중요한 문제는 “많이 넣을수록 안전”이 아니라 “많이 넣을수록 핵심이 희석”된다는 점입니다.

• 근거가 많아질수록 충돌 가능성이 증가합니다.
• 입력이 길어질수록 중요한 근거의 상대적 비중이 줄어듭니다.
• 결국 답변이 모호해지거나, 엉뚱한 근거를 집어 결론을 내릴 수 있습니다.

그래서 RAG 품질 튜닝은 “근거를 더 추가”하는 방향보다 “근거 밀도를 높이는 정제” 쪽이 더 잘 맞습니다.

---

5) 구조화된 입력에서 추론이 안정된다.

같은 정보라도 구조가 있으면 성능이 확 뛰는 경우가 많습니다. 이유는 단순합니다. 모델은 사람처럼 맥락을 이해하기보다 입력에서 규칙적인 패턴을 찾습니다. 구조는 그 패턴을 명확하게 만들어 줍니다.

 

효과가 좋은 구조 예시는 아래와 같습니다.

1. 규칙(우선순위) → 질문 재정의 → 근거(인용) → 답변 형식
2. 문서 발췌에 제목·섹션·날짜·버전·출처 메타데이터 포함
3. 근거는 3~5개로 제한하고, 각 근거가 질문의 어떤 부분을 뒷받침하는지 연결

핵심은 길게 설명하는 컨텍스트가 아니라, 판단 가능한 증거를 앞쪽에 밀도 있게 배치하는 것입니다.

---

TopK의 정의는 무엇인가?

TopK는 검색 단계에서 “후보로 몇 개를 가져올지”를 정하는 값입니다. 실무에서는 검색 후보 수(TopK)와 최종 컨텍스트에 실제로 넣는 개수(삽입 개수)를 분리해 운영하는 경우가 많습니다. K는 개수이고, TopK는 검색 점수(유사도/랭킹 점수 등)가 높은 순으로 상위 K개 문서/청크(chunk)를 후보로 뽑는다는 뜻입니다.

 

예를 들어 TopK=5라면 관련도가 높은 상위 5개 청크를 후보로 가져옵니다. TopK=20이라면 더 많은 후보를 가져오지만, 잡음·중복·충돌 가능성도 같이 커집니다. RAG 성능 튜닝에서 TopK는 컨텍스트에 들어갈 재료의 양을 좌우하므로, 정확도뿐 아니라 지연과 비용에도 직접 영향을 줍니다.

---

실무에서 바로 먹히는 개선 포인트 6가지

아래 6가지는 모델을 바꾸지 않고도 체감 품질을 빠르게 끌어올리는 방법입니다.

1. TopK를 줄이고 rerank로 정확한 몇 개만 남기기
   • TopK를 늘리면 정답이 포함될 확률은 올라갈 수 있지만, 동시에 잡음도 늘어납니다. “TopK 소폭 + rerank 강화 + 정제”가 운영에서는 더 안정적입니다.
2. 중복 제거(동일 문장·유사 문단 제거)
   • 중복은 비용과 지연을 늘리고, 모델의 중요도 판단을 망가뜨립니다. 먼저 제거하면 얻는 이득이 큽니다.
3. 구버전 문서 필터링(날짜·버전 기준)
   • 구버전과 신버전이 섞이면 모델은 임의 선택을 합니다. 최신 우선 규칙을 메타데이터 기준으로 강제하는 것이 핵심입니다.
4. 질문과 직접 연결되는 문장만 추출(청킹 + 하이라이트)
   • 문서 전체를 넣지 말고, 질문에 답이 되는 문장만 남기면 근거 밀도가 올라가고 답이 안정됩니다.
5. 길면 요약이 아니라 질문 관련 부분만 압축(query-aware compression)
   • 일반 요약은 필요한 디테일을 지울 수 있습니다. 질문 기반 압축은 조건·예외·수치 같은 “답의 골격”을 유지하며 줄이는 방식입니다.
6. 근거 인용을 강제하고, 근거가 없으면 추가 질문/모른다로 전환
   • 근거 인용을 강제하고, 근거가 없으면 추가 질문 또는 “근거 부족”으로 보수적으로 응답하도록 전환(추가 질문이 불가한 채널이라면 “모른다/확인 필요” 정책으로 고정)

---

외부 공개 자료로 보는 ‘정제 전/후’ 효과

정제(TopK 축소, rerank, 중복/버전 필터, 압축)의 효과는 내부 실측이 아니더라도 외부 공개 자료에서 “방향성과 규모”를 확인할 수 있습니다. 아래 표는 대표 공개 자료를 기준으로, 정확도·지연·비용이 어떤 축에서 움직이는지 정리한 참고용 비교입니다.

항목	정제 전	정제 후	외부 근거
정확도(검색 실패율)	Top-20 기준 5.7%	Top-20 기준 1.9% (67% 감소)	Anthropic은 Contextual Retrieval과 reranking 결합 시 Top-20 기준 검색 실패율이 5.7%→1.9%로 감소했다고 공개했습니다.
지연(응답 시간)	기준값	출력 토큰을 줄이면 지연이 큰 폭으로 감소(경험칙)	OpenAI는 지연 최적화 가이드에서 출력 토큰이 지연에 큰 영향을 주며, 출력 길이를 줄이는 것이 지연 개선에 직접적이라고 안내합니다.
비용(토큰 기반)	기준값	입력/출력 토큰이 줄면 토큰 기반 비용도 함께 감소	OpenAI는 토큰이 과금과 직접 연결되며, 사용량(입력/출력 토큰) 기준으로 비용이 산정된다고 설명합니다.

---

[핵심 용어를 한 줄로 정리]
rerank: 1차 검색 후보를 질문 적합도로 다시 점수화해 상위 몇 개만 남기는 재정렬 단계
query-aware compression: 문서 전체 요약이 아니라 질문과 직접 관련된 문장만 압축해 넣는 방식

---

RAG 답변 품질을 안정시키는 컨텍스트 템플릿

아래 템플릿은 그대로 복사해 써도 됩니다. 핵심은 [근거]에 들어가는 청크가 질문과 얼마나 직접 연결돼 있는지, 그리고 구버전·중복·충돌이 얼마나 제거돼 있는지입니다.

 

규칙(우선순위)
1) 최신 문서 > 구버전
2) 근거에 없는 내용은 추측 금지
3) 답변에는 근거 인용 필수, 없으면 추가 질문

질문 재정의
- 사용자가 원하는 산출물: (예: 조건/예외 포함 요약, 표 형태)

근거(3~5개, 메타데이터 포함)
[근거1] 제목/섹션/날짜/버전/출처 + 질문과 직접 연결되는 문장 발췌
[근거2] ...
[근거3] ...

답변 형식
- 결론
- 근거 인용
- 예외/주의사항
- 추가 확인 질문(필요 시)

 

이 구조가 좋은 이유는 간단합니다. 모델이 어떤 규칙으로, 무슨 질문을, 어떤 근거로, 어떤 형식으로 답해야 하는지가 입력 안에서 명확해지기 때문입니다.

---

컨텍스트 품질을 운영 지표로 만들면 서비스가 안정된다.

프롬프트는 감각에 기대기 쉽지만, 컨텍스트는 지표화가 가능합니다. 외부 사용자 대상 서비스라면 특히 유효합니다.

1. 근거 밀도: 입력 토큰 중 실제 답변에서 인용된 근거 토큰 비율(또는 인용된 근거 문장 비율)
2. 충돌률: 상충 문장이 함께 들어오는 빈도
3. 중복률: 유사 문장이 반복되는 정도
4. 인용 성공률: 답변이 근거 인용을 만족한 비율
5. 추가 질문 전환율: 근거 부족 시 추측이 아니라 추가 질문으로 전환되는 비율

이 지표를 잡으면 “누가 프롬프트를 잘 쓰냐” 논쟁에서 빠져나와, 재현 가능한 개선 루프를 만들 수 있습니다.

---

kt cloud RAG 품질을 안정시키는 3가지 핵심

kt cloud에서 RAG 기반 서비스를 사용하면서, 아래 세 가지를 먼저 정리해두면 답변 품질과 비용이 함께 안정됩니다.

1. 구버전·신버전 문서 혼재를 막는 버전/날짜 기준(최신 우선)
2. TopK를 무작정 키우기보다 rerank로 정확한 근거 몇 개만 남기고 중복·잡음을 제거하기
3. 답변에 근거 인용을 기본값으로 강제하고, 근거가 없으면 추가 질문으로 전환되게 하기

외부 사용자를 대상으로 하는 RAG는 “그럴듯한 답”보다 “검증 가능한 답”이 중요합니다. 컨텍스트를 덜 넣고 더 정확히 넣는 방향으로 정리하면, 정확도와 일관성이 먼저 안정되고, 경우에 따라 응답 지연과 토큰 비용도 함께 줄어듭니다. 프롬프트를 다듬기 전에 컨텍스트 파이프라인을 먼저 정리하는 것, 그게 가장 빠른 안정화 전략입니다.

 

---

❓ 자주 묻는 질문 (FAQ)

Q. TopK를 늘리면 정답이 더 잘 나오지 않나요?

A. 정답이 포함될 확률은 오를 수 있지만, 잡음과 충돌도 같이 늘어납니다. rerank와 정제가 약한 상태에서 TopK를 키우면 정확도가 떨어지는 경우가 많습니다. TopK는 적정 수준으로 두고 rerank·중복 제거·버전 필터를 강화하는 쪽이 더 안정적입니다.

Q. rerank는 왜 필요한가요?

A. 1차 검색은 후보를 넓게 잡는 단계라 오탐이 섞일 수 있습니다. rerank는 질문과 근거의 적합도를 다시 평가해 상위 몇 개만 남기는 단계입니다. 컨텍스트에 들어갈 근거 품질을 한 번 더 보정하는 역할이라 효과가 큽니다.

Q. 컨텍스트 윈도우가 큰 모델을 쓰면 문제는 줄지 않나요?

A. 더 많이 넣을 수는 있지만, 더 많이 넣는다고 자동으로 좋아지진 않습니다. 오히려 구버전 혼재·중복·희석 문제가 커질 수 있습니다. 윈도우가 커질수록 선별과 구조화의 중요도도 같이 올라갑니다.

---

📚 관련/출처

kt cloud, 「[Tech Series] kt cloud AI 검색 증강 생성(RAG) #1 : 핵심 개념과 시스템 구조 이해」 kt cloud 기술 블로그 (2025.08.22). kt cloud, 「[Tech Series] kt cloud AI 검색 증강 생성(RAG) #2 : 데이터 파싱과 전처리 최적화」 kt cloud 기술 블로그 (2025.09.29). kt cloud, 「RAG Suite 상품 개요」 kt cloud Cloud 매뉴얼 (2025.09.04). OpenAI, 「What are tokens and how to count them?」 OpenAI Help Center (접근: 2026.01.12). OpenAI, 「Latency optimization」 OpenAI API Docs (접근: 2026.03.11). Anthropic, 「Contextual Retrieval」 Anthropic News/Research (2024.09.19). Patrick Lewis et al., 「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」 NeurIPS / arXiv:2005.11401 (2020). Rodrigo Nogueira, Kyunghyun Cho, 「Passage Re-ranking with BERT」 arXiv:1901.04085 (2019). Nelson F. Liu et al., 「Lost in the Middle: How Language Models Use Long Contexts」 Transactions of the Association for Computational Linguistics (TACL) (2024). Christopher D. Manning, Prabhakar Raghavan, Hinrich Schütze, 『Introduction to Information Retrieval』 Cambridge University Press (2008). LangChain, 「Improving Document Retrieval with Contextual Compression」 LangChain Blog (2023.04.20).