RAG vs Context Engineering: 어떤 시나리오를 쓸지 선택할 것 같아요

이 두 개념이 같은 결정에서 어떤 역할을 할까요?

AI 애플리케이션을 설계할 때 우리는 종종 피할 수 없는 모순에 직면합니다: 모델은 점점 더 정확한 맥락을 필요로 하지만, 컨텍스트 윈도우는 자유로울 수 없으며, 이는 지연을 증가시키고 모델이 관련 없는 주요 신호를 잃을 수 있게 만듭니다. RAG(검색 증강 생성)와 Context Engineering(때때로 Loop Engineering 또는 컨텍스트 엔지니어링이라고도 불림)는 이 모순을 두 가지 다른 방향에서 다룹니다.

RAG의 핵심 활동은 "외부 지식 기반에서 검색하기"입니다. 벡터 유사성, 키워드 회상 등 다양한 방법을 사용하여 문서 데이터베이스에서 가장 관련성 높은 구간을 정확히 추출한 후, 모델이 사용할 수 있도록 프롬프트에 입력합니다. 이 연구는 "모델이 모르는 것들" 문제—즉, 개인 데이터, 최신 발전, 또는 롱테일 지식—을 다룹니다.

Context Engineering는 완전히 다르며, "대화의 맥락 구조를 어떻게 설계하고 유지할지"에 초점을 맞춥니다. 다중 턴 대화, 함수 호출, 에이전트 루프를 사용할 때는 어떤 과거 라운드를 유지할지, 어떤 도구 출력을 주입할지, 역할 시스템 프롬프트를 어떻게 오케스트레이션할지, 그리고 컨텍스트 창이 꽉 찼을 때 어떤 콘텐츠를 잘라낼지 결정해야 합니다. 이 질문은 "모델이 현재 상태를 어떻게 이해해야 하는가"—즉, 대화 흐름, 중간 상태, 도구 호출 기록—에 대해 다룹니다.

두 분야의 업무 분담은 한 문장으로 요약할 수 있다: RAG는 외부 정보를 끌어들이고, Context Engineering는 내부 상태를 조율한다. 같은 제품 내에서는 이 둘이 종종 함께 작동합니다: RAG는 모델의 도메인 지식을 보완하고, Context Engineering 모델이 긴 대화 중 정체성을 잃거나 핵심 명령을 잊지 않도록 보장합니다.

현실 상황에서 어떤 상황에서 A를 선택할까요?

시나리오: 내부 문서 Q&A 봇 개발

팀이 내부 기술 및 프로세스 문서에 답변할 수 있는 로봇을 만들어 달라는 요청을 받았다고 가정해 봅시다. 이 경우 대부분의 사용자 문제는 일회성("서버 배포 프로세스는 무엇인가요?")입니다. 대화 라운드는 보통 매우 짧고(1-3라운드) 역사적 맥락을 암기할 필요가 없습니다. 여기서 핵심 모순은 모델이 내부 회사 문서의 내용을 알지 못한다는 점입니다.

**먼저 RAG를 선택해야 해. ** 이유는 간단합니다: Context Engineering 거의 아무런 도움이 되지 않습니다—단일 라운드 질의응답은 복잡한 맥락 구조가 필요하지 않지만, RAG는 지식 손실이라는 주요 문제를 해결합니다. 간단한 검색 루프를 만들 수 있습니다: 내부 문서를 조각으로 잘라 벡터 형식으로 저장합니다. 사용자가 질문할 때, Top-K 관련 블록을 찾아 프롬프트에 입력한 후 모델에 답변을 받습니다. 추가적인 대화 상태를 유지할 필요도 없습니다.

시나리오: 연속적인 다라운드 운영을 위한 프로젝트 관리 에이전트 개발

이제 요구사항을 변경하세요: 팀이 프로젝트 작업 상태를 추적하고, 작업을 자동으로 할당하며, 여러 차례의 명확한 확인과 확인을 처리하는 에이전트가 됩니다. 사용자는 먼저 "현재 Sprint에서 아직 완료되지 않은 작업은 무엇인가요?"라고 물으면 에이전트가 JSON 목록을 반환합니다. 사용자는 "가장 긴급한 두 개를 할당해 주세요"라고 요청하고, 에이전트는 생성 함수를 호출해 확인 응답을 반환합니다. 그 사용자가 다시 물었다, "지난달 지연의 책임은 누구인가요?" —이 시점에서 에이전트는 앞서 언급한 "가장 긴급한 작업"이 현재 스프린트 내에 있는 작업을 의미한다는 것을 알아야 합니다.

**Context Engineering를 선택해야 합니다. ** RAG는 "모델이 3분 전에 출력한 JSON 구조를 기억하지 못하는 문제"를 해결할 수 없습니다. 컨텍스트 관리 방식을 설계해야 합니다: 각 함수 호출 후 실행 결과를 구조화된 요약으로 컨텍스트에 다시 쓰고; 상황이 윈도우 제한에 가까워지면 가장 오래된 중계 라운드를 버리고; 동시에 현재 프로젝트 ID, 사용자 역할, 기타 변하지 않는 정보와 같은 '중요 상태'를 위한 고정된 영역을 유지하세요. 이것이 전형적인 Context Engineering 작업입니다.

가장 흔한 불일치 방법과 그 비용

제가 본 가장 전형적인 불일치는 3라운드 대화만 있는 간단한 Q&A 제품인데도 팀이 컨텍스트 윈도우 스택 과부하, 축소 전략, 상태 압축 설계에 많은 노력을 쏟는 경우입니다. 그 대가로 개발 주기가 2주에서 6주로 늘어났고, 사용자 경험에는 거의 개선이 없습니다. 반대로, 20라운드 이상의 대화가 필요한 복잡한 에이전트 시나리오에서는 팀은 벡터 라이브러리만 쌓고 RAG에서 모델을 재정렬했으며, 문맥 상실로 인한 도구 호출 실패는 무시했습니다. 그 결과 에이전트들은 종종 관련 없는 질문에 답하고 반복 작업을 반복하여 사용자 만족도가 극히 낮았습니다.

또 다른 흔한 오해는 "RAG와 Context Engineering가 서로 대체할 수 있다'는 것입니다. 일부 사람들은 모든 역사적 대화를 RAG 색인에 단순히 넣는 것이 기억을 얻을 수 있다고 생각하지만, RAG의 검색 세분화는 단편적이어서 일관된 맥락적 재구성을 보장하지 못합니다. 예를 들어, 이전 라운드에서 사용자가 "작업을 장산에게 할당하라"고 말했고, 이번 라운드에서 "그가 완료했나요?"라고 묻는다면, 모델이 "작업을 장산에게 할당하라"는 세그먼트만 가져오면 "그"가 누구를 가리키는지 알 수 없습니다. Context Engineering 참조의 매핑을 명시적으로 유지함으로써 이 문제를 해결합니다(예: {action: "assign", user: "張三", task: "..."} 문맥에 구조를 저장하는 것).

팀이 지금 한 명만 시작할 수 있다면, 어떤 걸 먼저 해야 할까요?

핵심 기준은 다음과 같습니다: 지식 격차 + 대화 라운드.

사용자의 일반적인 시나리오가 단일 또는 짧은 대화(≤ 5라운드)이고 질문이 많은 개인적이거나 동적 지식을 포함한다면, RAG부터 시작하세요. 이 시점에서 Context Engineering의 한계 이점은 매우 낮기 때문입니다—간단한 프롬프트 명령어만으로도 맥락을 유지하기에 충분합니다. 이후 반복에서는 컨텍스트 히스토리 관리를 추가할 수 있고, 심지어 '마지막 N라운드'를 간단하게 잘라내는 방법부터 시작할 수도 있습니다.

사용자의 일반적인 시나리오가 다중 라운드의 복잡한 작업(도구 호출 >라운드 또는 상태 전이 수행)이고, 지식이 주요 문제가 아니라면(모델의 기존 학습 데이터가 이미 덮어쓰여 있음), Context Engineering를 수행하세요. 문맥을 잃으면 에이전트가 목표 작업을 완료하지 못하기 때문에 치명적인 결함이 됩니다. 지식 부족은 모델이 "관련 정보를 찾을 수 없으니 더 많은 맥락을 제공해 주세요"라고 응답하는 임시 해결책으로 보완할 수 있습니다.

실용적인 경험 법칙: 대부분의 모델 오류가 "이전에 말한 내용을 잊어버리는" 데서 발생한다면, 우선순위를 정하세요 Context Engineering; 대부분의 오류가 '이 지식을 모른다'는 이유로 발생한다면, RAG를 우선시하세요.

선택을 한 후 다음에 어떤 능력을 추가해야 할까요?

RAG를 먼저 했다면, 다음에 집중할 단계는 다음과 같습니다:

• 블록 정책 최적화: 문서 블록 크기, 겹치는 창, 메타데이터 오케스트레이션이 검색 품질에 직접적인 영향을 미칩니다.
• 검색 품질 모니터링: 노이즈 감소를 위해 리트리싱 모델(Cohere Rerank, BGE Reranker) 또는 혼합 검색(BM25 + 벡터)을 도입합니다.
• 컨텍스트 주입 설계: 문자 명령을 중단하거나 모델에 무시하지 않고 프롬프트를 자연스럽게 삽입하는 방법.

이미 Context Engineering를 완료했다면, 다음 단계는 다음에 집중하는 것입니다:

• 상태 지속성 및 정렬: 대화 내 핵심 상태(사용자 신원, 작업 상태, 맥락적 지문)를 유지하고 여러 턴에 걸쳐 정렬을 유지하는 방법.
• 컨텍스트 압축 및 요약: 컨텍스트 창이 끝나기 전에 역사적 내용을 자동으로 요약하여 핵심 정보를 보존합니다.
• 도구 호출에 대한 피드백 루프: 각 도구 호출 후 실행 결과가 구조화되어 이후 의사결정을 위해 맥락에 주입됩니다.

두 제품은 결국 통합될 것입니다. 성숙한AI제품은 RAG가 지속적으로 지식을 갱신하고Context Engineering상태를 유지해야 합니다. 하지만 초기 의사결정은 팀의 투입-산출 비율을 결정하며, 잘못된 방향을 선택하면 몇 달을 낭비할 수 있습니다.

구체적인 의사결정 시나리오가 '어느 쪽이 더 나은가'보다 논의할 가치가 더 큽니다.

이 주제가 처음이라면, 현재 만들고 싶은 제품을 정리해 보세요: 모르는 질문에 답할 모델이 필요한가요? 사용자가 연속으로 10라운드 이상 질문할까요? 이 두 차원을 의사결정 매트릭스에 그려내면, 현재 가장 집중해야 할 방향을 빠르게 파악할 수 있을 것입니다. RAG가 유행한다고 해서 레이더에 올리지 말고, 에이전트가 엄청나게 인기 있다고 해서 Context Engineering가 만병통치약이라고 생각하지 마세요. 각 분야는 고유한 경계가 있습니다; 문제를 명확히 정의하는 것이 올바른 도구를 선택하는 핵심입니다.