RAG context engineering이 중요한 이유는 간단합니다. 벡터DB를 붙였다고 해서 모델이 자동으로 좋은 답을 만드는 것은 아니기 때문입니다. RAG의 진짜 품질은 무엇을 검색했는가보다 검색한 조각을 어떤 맥락으로 구성했는가에서 갈리는 경우가 많습니다.
RAG를 처음 붙일 때는 ‘문서를 넣고 검색하면 답이 좋아지겠지’라고 생각하기 쉽습니다. 하지만 실제 운영에서는 엉뚱한 chunk, 너무 긴 context, 출처 없는 요약, 오래된 문서, 서로 충돌하는 문서 때문에 답이 흔들립니다. 이 문제는 RAG chunking 글에서 다룬 검색 단위 문제와 바로 이어집니다.
RAG context engineering이란 무엇인가
RAG는 Retrieval-Augmented Generation의 약자로, 모델이 답하기 전에 외부 문서를 검색하고 그 결과를 근거로 답을 만들게 하는 방식입니다. OpenAI Retrieval 문서는 semantic search를 키워드가 적거나 없어도 의미적으로 관련된 결과를 찾는 기법으로 설명합니다.
context engineering은 여기서 한 걸음 더 들어갑니다. 검색 결과를 그냥 prompt 뒤에 붙이는 것이 아니라, 답변에 실제로 도움이 되는 맥락을 고르고, 정렬하고, 압축하고, 출처와 함께 모델에 전달하는 설계 작업입니다.
- 질문을 검색 가능한 형태로 바꾸기
- chunk 크기와 경계를 조정하기
- 검색 결과를 다시 정렬하기
- 중복되거나 오래된 문서를 빼기
- 답변에 필요한 범위만 context로 넣기
- 출처와 불확실성을 함께 전달하기
벡터DB만 붙이면 왜 부족할까
1. 검색된 chunk가 답변 단위와 다를 수 있다
문서는 사람이 읽기 좋은 단위로 작성되지만, 검색은 chunk 단위로 일어나는 경우가 많습니다. chunk가 너무 작으면 근거가 잘리고, 너무 크면 불필요한 문장이 많이 들어갑니다. 이 경계가 어긋나면 검색은 맞았는데 답변은 흔들릴 수 있습니다.
2. 의미적으로 비슷한 것과 답에 필요한 것은 다르다
semantic search는 비슷한 내용을 잘 찾지만, 비슷하다고 항상 답에 필요한 것은 아닙니다. 예를 들어 ‘요금제 환불 조건’을 물었는데 ‘요금제 변경 조건’ 문서가 높은 점수로 나올 수 있습니다. 이때 reranking이나 필터링이 필요합니다.
3. 오래된 문서와 최신 문서가 같이 들어갈 수 있다
운영 문서에는 버전, 날짜, 정책 변경 이력이 섞입니다. RAG가 서로 충돌하는 문서를 동시에 넣으면 모델은 그럴듯하게 평균을 내거나 잘못된 결론을 만들 수 있습니다.
좋은 RAG 흐름은 검색 이후가 더 길다
좋은 RAG 파이프라인은 대략 다음 흐름을 가집니다.
- 사용자 질문을 정리하고 필요한 제약 조건을 뽑는다
- metadata filter로 범위를 먼저 좁힌다
- semantic search로 후보 chunk를 찾는다
- reranking으로 실제 답변 관련도를 다시 판단한다
- 중복과 충돌을 제거한다
- 출처와 함께 context를 구성한다
- 모델 답변 후 근거 누락과 hallucination을 평가한다
OpenAI Retrieval 문서는 vector store search가 관련 chunk, score, file origin을 포함한 결과를 반환할 수 있음을 보여줍니다. 이 정보는 단순 로그가 아니라 context engineering의 재료입니다. 어떤 파일에서 왔는지, 점수가 어떤지, 속성 필터가 맞는지 확인해야 합니다.
운영에서 바로 보는 체크리스트
- 답변에 인용된 출처가 실제 문서와 맞는가
- 검색 결과 상위 5개가 질문에 직접 답하는가
- chunk 안에 답을 판단할 충분한 문맥이 들어 있는가
- 같은 의미의 chunk가 context를 낭비하고 있지 않은가
- 날짜, 버전, 제품군 metadata로 필터링하고 있는가
- 모르는 질문에는 모른다고 답하게 만들었는가
- prompt 변경 전후로 같은 eval set을 돌리고 있는가
이 체크리스트가 필요한 이유는 RAG 문제가 모델 문제처럼 보이기 때문입니다. 하지만 실제로는 검색 범위, chunk 설계, ranking, context 압축, 평가 데이터 부족이 원인인 경우가 많습니다.
마무리
RAG는 벡터DB를 붙이는 순간 끝나는 기능이 아닙니다. 검색은 시작이고, context engineering은 검색 결과를 답변 가능한 근거로 바꾸는 과정입니다.
정리하면 RAG context engineering의 목표는 단순합니다. 모델에게 많은 문서를 주는 것이 아니라, 지금 질문에 답하는 데 필요한 정확한 근거를 적당한 크기와 순서로 주는 것입니다.
