13. 무엇을 넣고 무엇을 뺄까

컨텍스트 엔지니어링의 심장

12장의 출발 질문 — "결과를 좌우할 가장 작은 고신호 정보 집합은 무엇인가" — 에 실제로 답하는 것이 이 장입니다. 한 제공자는 이 작업을 "정보를 충실하게 유지하되 가능한 한 작게"라고 요약합니다. 핵심은 균형입니다: 너무 적으면 모델이 추측하게 되고(환각 위험), 너무 많으면 신호가 희석됩니다(attention 분산).

flowchart LR
    few["너무 적음<br/>모델이 추측·환각"] --- sweet["적정<br/>고신호 최소집합"] --- many["너무 많음<br/>신호 희석·방해"]

    classDef bad fill:#fee2e2,stroke:#ef4444,color:#7f1d1d
    classDef good fill:#dcfce7,stroke:#22c55e,color:#14532d
    class few,many bad
    class sweet good

📌 핵심: 컨텍스트 선별은 "최대한 많이"도 "최대한 적게"도 아니라, 작업에 필요한 만큼 정확히입니다. 그 선을 찾는 것이 기술입니다.

넣을 후보를 평가하는 4가지 질문

어떤 정보를 컨텍스트에 넣을지 고민될 때, 각 후보에 대해 물어보세요.

관련성 — 가장 중요한 필터

"있으면 좋을 것 같아서" 넣는 정보가 가장 위험합니다. 이번 질문에 직접 쓰이지 않는 자료는, 좋게 봐야 중립이고 나쁘면 방해물입니다.

질문: "환불 절차가 어떻게 되나요?"

넣을 것 ✅: 환불 규정, 환불 신청 방법
뺄 것 ❌: 배송 정책, 회사 연혁, 멤버십 등급표
         (관련 없는데 윈도우만 차지하고 주의를 분산시킴)

고유성 — 모델이 이미 아는 건 빼도 된다

모델은 방대한 일반 지식을 갖고 있습니다. "물은 100도에 끓는다" 같은 상식을 컨텍스트에 넣는 건 낭비입니다. 반대로 모델이 알 수 없는 것 — 회사 내부 규정, 최신 데이터, 특정 문서 내용, 비공개 맥락 — 은 반드시 넣어야 합니다(4장 속성 2).

💡 팁: "이걸 빼면 모델이 지어낼까, 아니면 알고 있을까?"를 자문하세요. 지어낼 것 같으면(고유 정보) 넣고, 이미 알 것 같으면(일반 상식) 빼는 게 기본 원칙입니다. 단, 모델 지식이 오래됐거나 틀릴 수 있는 영역(최신 사실, 빠르게 변하는 정보)은 "안다"고 가정하지 말고 직접 주세요.

신호 밀도 — 자료를 그대로 vs 정제해서

긴 원문을 통째로 넣기보다, 작업에 필요한 부분만 추리거나 요약해 넣으면 신호 밀도가 올라갑니다. 한 가이드의 원칙처럼, 답의 최종 형태에 가까운 자료일수록 모델이 할 일이 줄고 오류 여지도 줍니다.

신호 밀도 낮음 ❌
[30페이지 매뉴얼 전체 붙여넣기] + "환불 절차 알려줘"

신호 밀도 높음 ✅
[매뉴얼 중 '환불' 섹션 2문단만] + "이 절차를 고객용으로 풀어 써줘"

"빼기"가 왜 그토록 중요한가

초보자는 "넣기"에 집중하고 "빼기"를 잊습니다. 하지만 3장에서 봤듯 컨텍스트에 든 것은 전부 영향을 줍니다. 무관·모순·오래된 정보를 빼는 것은, 좋은 정보를 넣는 것만큼, 때로는 그 이상으로 결과를 좌우합니다.

⚠️ 흔한 실수·미신: "정보가 많을수록 안전하다"는 직관은 컨텍스트에선 틀립니다. 모순된 두 자료를 함께 넣으면 모델이 어느 쪽을 따를지 들쭉날쭉해지고, 오래된 자료가 최신 자료와 섞이면 틀린 쪽을 인용할 수 있습니다. 빼는 것은 "정보 손실"이 아니라 "신호 정제"입니다.

🧪 직접 검증법: 컨텍스트에서 자료를 하나씩 빼보며 답이 나빠지는지 보세요. 빼도 답이 그대로거나 더 나아지면, 그 자료는 신호가 아니라 잡음이었던 것입니다. 이 "제거 실험"이 무엇이 진짜 고신호인지 알려줍니다.

예시도 컨텍스트다 — 큐레이션

7장의 few-shot 예시 역시 컨텍스트의 일부이고, 같은 원칙이 적용됩니다. 한 제공자는 "엣지케이스를 잔뜩 쌓지 말고, 다양하고 대표적인 정준 예시를 큐레이션하라"고 권합니다. 예시도 "많이"가 아니라 "잘 고른 최소집합"이 이깁니다.

후보별 처리 결정 흐름

flowchart TB
    cand["넣을까 말까<br/>고민되는 정보"] --> rel{"이번 작업에<br/>직접 관련?"}
    rel -->|아니오| drop["빼기"]
    rel -->|예| uniq{"모델이<br/>이미 아는<br/>일반 상식?"}
    uniq -->|예, 정확히| drop
    uniq -->|아니오/불확실| dense{"군더더기가<br/>섞였나?"}
    dense -->|예| refine["핵심만 추려서 넣기"]
    dense -->|아니오| keep["그대로 넣기"]

    classDef dec fill:#fef9c3,stroke:#eab308,color:#713f12
    classDef drop fill:#fee2e2,stroke:#ef4444,color:#7f1d1d
    classDef keep fill:#dcfce7,stroke:#22c55e,color:#14532d
    class rel,uniq,dense dec
    class drop drop
    class refine,keep keep

🔧 개발자 노트: 자동화 시스템에서는 이 선별을 코드로 합니다. 대표적 패턴이 LangChain 등이 정리한 네 가지 전략입니다 — write(컨텍스트를 외부에 저장), select(필요한 것만 검색해 가져오기, RAG가 여기 해당), compress(요약·압축), isolate(작업별로 컨텍스트 분리). 5부의 RAG·도구 결합 장에서 select·compress를 더 다룹니다. 핵심은 "윈도우에 무엇을 동적으로 넣을지"를 매 단계 결정하는 것이며, 이것이 정적인 프롬프트 작성과 컨텍스트 엔지니어링의 큰 차이입니다.

이 장에서 배운 것

• 컨텍스트 선별의 목표는 "최대한 많이"도 "최대한 적게"도 아닌, 작업에 필요한 만큼 정확히 — 고신호 최소집합이다.
• 넣을 후보는 관련성·고유성·신뢰성·신호 밀도 4가지로 평가한다. 관련성이 가장 강력한 필터다.
• 모델이 이미 아는 일반 상식은 뺄 수 있지만, 모델 밖 정보(내부 규정·최신 데이터·특정 문서)는 반드시 넣는다.
• 긴 원문은 통째로보다 필요한 부분만 추려 신호 밀도를 높인다. 답에 가까운 형태일수록 좋다.
• "빼기"는 정보 손실이 아니라 신호 정제다. 제거 실험으로 무엇이 진짜 신호인지 확인할 수 있다.

✍️ 확인 문제

1. "혹시 도움될까 봐" 넣은 무관한 자료가 왜 중립이 아니라 방해가 될 수 있는지, 3장의 컨텍스트 의존 개념과 연결해 설명해보세요.

1. 다음 중 컨텍스트에서 뺄 수 있는 후보를 고르고 이유를 적어보세요. (질문: "우리 회사 작년 4분기 매출 추세를 분석해줘")
   • (a) 작년 4분기 월별 매출 데이터
   • (b) "매출이란 무엇인가"에 대한 일반 정의
   • (c) 재작년 1분기 매출 (비교 맥락이 필요 없다면)
   • (d) 회사 창립 스토리

1. (실습) 고객 문의 자동 답변을 만들려 합니다. 사내 위키 전체(50페이지)를 넣는 대신, 4가지 평가 질문을 적용해 "무엇을 어떻게 넣을지" 전략을 세워보세요.

다음 → 14. 긴 컨텍스트와 중간 소실
이전 ← 12. 컨텍스트 윈도우란 무엇인가 · 목차