컨텍스트 엔지니어링 실패모드 위키

Select 전략 — RAG · 하이브리드 검색 · Tool Loadout · 능동적 검색

9 min read

상위: 06_00_MOC

Select 전략 — RAG · 하이브리드 검색 · Tool Loadout · 능동적 검색

한 줄 정의

Select 전략은 RAG, 벡터 검색, 도구 로드아웃 등으로 작업에 관련된 정보만 컨텍스트 창 안에 골라 싣는 전략이다. 관련 없는 정보가 흘러들어 생기는 03 혼란, 상충하는 정보가 섞여 생기는 04 충돌를 함께 막는다.

“If you treat your context like a junk drawer, the junk will influence your response.” — Drew Breunig, 2025

왜 Select인가 — 동기

컨텍스트 창에 “모든 것”을 넣으면 세 가지 문제가 생긴다.

  • 혼란(Confusion): 관련 없는 정보가 모델의 판단을 흐린다.
  • 충돌(Clash): 상충하는 정보가 함께 들어가 일관되지 않은 응답이 나온다.
  • 낭비: 토큰 예산을 헛되이 써서 비용과 속도가 모두 나빠진다.

Select 전략은 컨텍스트 창을 잘 정돈된 서랍으로 만들어 이 세 문제를 푼다.

flowchart TD
    Q["사용자 쿼리 / 에이전트 상태"] --> SEL

    subgraph SEL["Select 전략"]
        RAG["RAG / 벡터 검색<br/>시맨틱 유사도"]
        HYB["하이브리드 검색<br/>시맨틱 + 키워드 + 엔티티"]
        TOOL["Tool Loadout<br/>~20개 이내 동적 선택"]
        FIX["항상 포함 파일<br/>CLAUDE.md · .cursorrules"]
        PACT["능동적 검색 (Letta)<br/>LLM이 직접 결정"]
    end

    SEL -->|"관련 정보만"| CTX["컨텍스트 창<br/>(정제된 입력)"]
    SEL -->|"무관한 정보 차단"| BIN["폐기"]

1. RAG (Retrieval-Augmented Generation)

쿼리와 비슷한 청크를 벡터 검색으로 찾아 컨텍스트에 끼워 넣는다. 효과는 단순한 지식 주입에 그치지 않는다.

1-1. 도구 설명에도 RAG를 적용

“RAG applied to tool descriptions shows 3× improvement in tool selection accuracy.” — LangChain, 2025

도구가 너무 많아 생기는 문제(03 혼란)를 Select 전략으로 푸는 핵심 기법이다. 도구 설명을 전부 컨텍스트에 욱여넣는 대신, 지금 태스크와 관련된 도구만 RAG로 추린다.

1-2. 코드 에이전트의 RAG 복잡도

LangChain(2025)은 Windsurf의 코드 인덱싱 방식을 인용하며 단순 임베딩 검색의 한계를 지적한다.

“Indexing code ≠ context retrieval… combining AST parsing, semantic chunking, embedding search, grep/file search, knowledge graphs, and re-ranking steps.” — LangChain, 2025 (Windsurf 사례 인용)

프로덕션 코드 에이전트에서 RAG는 AST 파싱, 시맨틱 청킹, 임베딩 검색, 키워드 검색, 지식 그래프, 재랭킹을 엮은 복합 파이프라인이다.

2. 하이브리드 검색 — Mem0 2026 기준

시맨틱 유사도와 키워드 매칭, 엔티티 매칭을 함께 병렬로 스코어링하는 하이브리드 검색이 단일 방식보다 낫다(Mem0, 2026).

지표수치
토큰 소비 (하이브리드)쿼리당 약 6,900 토큰
토큰 소비 (전체 컨텍스트)쿼리당 약 26,000 토큰
토큰 절감율약 73%
Temporal query 향상+29.6점
Multi-hop reasoning 향상+23.1점

“All three systems consume approximately 6,900 tokens per query — a significant reduction from the ~26,000 tokens required by full-context approaches.” — Mem0 Research Team, 2026

하이브리드 검색은 Select 전략을 가장 실용적으로 구현한 형태로, 관련성(precision)과 토큰 효율을 한꺼번에 잡는다.

3. Tool Loadout — 도구 수 관리

도구가 너무 많으면 모델이 혼란에 빠진다(03 혼란). 관련 수치는 다음과 같다.

모델도구 수결과
Llama 3.1 8B46개실패
Llama 3.1 8B19개성공
동적 도구 선택 적용 시—정확도 44% ↑, 속도 77% ↑, 전력 18% ↓
Extended Thinking 결합 시—최대 54% ↑

“Performance dropped with 46 tools but improved 44% when limited to 19 tools—with bonus speed gains of 77%.” — Breunig, 2025 (연구 인용)

실무 규칙: 도구 수는 약 20개 이내로 동적으로 관리하고, 지금 태스크와 관련된 도구만 RAG로 골라 싣는다.

flowchart LR
    ALL["전체 도구 목록<br/>(수십~수백 개)"] -->|"RAG 시맨틱 검색"| SEL
    SEL["선별된 도구<br/>(~20개 이내)"] --> LLM["LLM 컨텍스트"]
    LLM --> ACC["정확도 44% ↑<br/>속도 77% ↑"]

4. 항상 포함 파일 (Always-Include Files)

태스크와 무관하게 항상 컨텍스트에 포함하는 참조 파일이다.

도구파일역할
Claude CodeCLAUDE.md절차 기억 — 프로젝트 규칙·워크플로우
Cursor.cursorrules코딩 스타일·제약
Windsurfrules 파일에이전트 행동 지침

이들은 크로스세션 절차 기억(06_01-Write전략-스크래치패드-파일시스템-크로스세션)의 Select 측면에 해당한다. Write로 저장해 두고, Select로 매번 불러온다.

5. 능동적 검색 vs 수동적 검색

Letta(2024)는 기존 RAG와 결을 달리하는 방식을 제안한다.

방식설명장단점
수동 RAG생성 전에 자동으로 검색 (passive retrieval before generation)단순하지만 정밀도 제한
능동적 검색 (Letta)LLM이 직접 언제·무엇을 검색할지 tool call로 결정정밀하지만 추가 tool call 비용 발생

“Unlike standard RAG which passively retrieves before generation, Letta is proactive — the LLM decides if, when, and what to retrieve using tools.” — Letta, 2024

능동적 검색은 정밀한 대신 tool call 비용이 더 든다. 그 손익분기점이 어디인지는 아직 정량적으로 밝혀지지 않은 열린 질문이다.

6. Simon Willison의 경고 — 원치 않는 검색

LangChain(2025)이 든 사례를 보면, ChatGPT가 사용자의 위치 정보를 예상치 못하게 이미지 생성에 끌어다 썼다. Select가 지나치면 사용자의 에이전시(agency)를 침해할 수 있다는 뜻이다.

원칙: 검색이 필요한가를 먼저 판단하고, 검색 범위를 명시적으로 통제하라.

7. Select가 막는 실패모드

실패모드Select 기법메커니즘
혼란 (Confusion)RAG 관련성 필터, Tool Loadout무관한 정보·도구 차단
충돌 (Clash)최신 정보 우선 선택상충 소스 중 신뢰도 높은 것 선택
암묵적 결정 분산전체 트레이스 공유 (Cognition 원칙)서브에이전트에 전체 컨텍스트 전달
과부하하이브리드 검색 73% 절감필요한 토큰만 로딩

참고문헌

관련 노트

그래프 뷰

백링크