17. 컨텍스트 엔지니어링 실전 사고법

🎯 이 장의 목표
  • 3부의 원칙들을 하나의 사고 흐름으로 통합한다
  • "컨텍스트를 유한한 자원으로 다루는" 관점을 체화한다
  • 프롬프트 엔지니어링(2부)과 컨텍스트 엔지니어링(3부)을 잇는다

3부를 한 문장으로

3부 전체는 1부에서 깔아둔 한 문장의 펼침이었습니다.

컨텍스트를 귀하고 유한한 자원으로 다루어라.

한 제공자의 표현을 빌리면, 모델 능력이 아무리 커져도 "컨텍스트를 귀하고 유한한 자원으로 다루는 것은 신뢰할 수 있는 에이전트를 만드는 데 핵심으로 남는다"고 합니다. 윈도우가 커지고 모델이 똑똑해져도, 무엇을 보여줄지의 설계는 사라지지 않습니다.

4개 원칙으로 압축

3부에서 다룬 것을, 자동화 분야에서 자주 인용되는 네 전략(write·select·compress·isolate)에 맞춰 정리하면 기억하기 쉽습니다. 비개발자도 일상 사용에 그대로 적용할 수 있습니다.

전략일상 사용에서다룬 장
select (선별)필요한 것만 골라 넣기관련 자료만 붙여넣기, 무관한 것 빼기13
compress (압축)요약해 신호 밀도 높이기긴 자료·대화를 핵심만 요약13, 15
isolate (격리)작업별로 컨텍스트 분리한 창에 한 작업15
(배치)중요한 것을 가장자리에질문은 자료 뒤 맨 끝에14
select·compress·isolate에 14장의 "배치"를 더하면, 컨텍스트 설계의 거의 모든 결정을 포괄합니다.

하나의 사고 흐름

새 작업을 만났을 때, 컨텍스트를 이렇게 설계해보세요.

flowchart TB
    q["1. 출발 질문<br/>이 작업의 결과를 좌우할<br/>최소 고신호 집합은?"] --> sel["2. 선별 (select)<br/>관련된 것만 추리고<br/>무관한 것 뺀다"]
    sel --> comp["3. 압축 (compress)<br/>긴 것은 핵심만 요약<br/>신호 밀도 높인다"]
    comp --> place["4. 배치<br/>변하지 않는 지시는 앞,<br/>자료는 가운데, 질문은 끝"]
    place --> ground["5. 근거화<br/>출처 표시·자료 우선·<br/>근거 인용 요구"]
    ground --> run["6. 실행 & 검증"]
    run --> iso["7. 격리·관리<br/>꼬이면 새 창,<br/>길면 압축 요약"]

    classDef step fill:#ede9fe,stroke:#8b5cf6,color:#4c1d95
    classDef good fill:#dcfce7,stroke:#22c55e,color:#14532d
    class q,sel,comp,place,ground,iso step
    class run good

📌 핵심: 컨텍스트 엔지니어링은 한 번 쓰고 끝나는 정적 작업이 아니라, 매 단계 무엇을 넣고 뺄지 결정하는 동적 과정입니다. 이것이 단순 프롬프트 작성과의 가장 큰 차이입니다.

2부와 3부는 함께 작동한다

3장에서 둘은 "대사 vs 무대 전체"라고 했습니다. 실전에서는 분리되지 않습니다. 한 작업을 예로 보겠습니다.

CODE
[작업: 고객 불만 메일에 답장]

컨텍스트 설계 (3부)              프롬프트 설계 (2부)
─────────────────              ─────────────────
- 관련 주문 내역만 선별 (13)     - 역할: CS 담당자 (6)
- 환불 규정 핵심만 압축 (13)     - 톤: 정중하고 단호 (5,10)
- 규정을 자료로 구분 (16,11)     - 형식: 인사-공감-해결-마무리 (8)
- 질문을 맨 끝에 배치 (14)       - 근거 자료 인용 요구 (16)
컨텍스트가 "무엇을 보여줄지"를, 프롬프트가 "그것으로 무엇을 어떻게 할지"를 담당합니다. 좋은 결과는 둘이 맞물릴 때 나옵니다.

흔한 컨텍스트 실수 한눈에

3부에서 경고한 함정들을 모아둡니다(부록의 안티패턴 목록에서 더 확장됩니다).

실수왜 문제어디서
"윈도우 크니 다 넣자"attention 희석, 무관 정보 방해12
"많을수록 안전"모순·오류 자료가 결과 흔듦13
중요한 걸 긴 자료 한가운데중간 소실14
한 창에 여러 작업오염15
긴 대화 끝까지 우기기누적·부패15
최신 자료만 주면 알아서 쓰겠지옛 상식으로 기울 수 있음16

모델이 똑똑해지면 — 변하는 것과 안 변하는 것

마지막으로 균형을 잡습니다. 모델이 발전하면 덜 처방적인 컨텍스트로도 잘 동작하는 경향이 있습니다(한 제공자는 "더 똑똑한 모델일수록 더 적은 처방적 엔지니어링을 요구한다"고 표현). 그래서 과도하게 세밀한 통제는 오히려 줄여도 될 수 있습니다.

하지만 변하지 않는 것이 있습니다: 유한한 attention과, 무관 정보가 방해가 된다는 사실. 윈도우가 커지고 모델이 영리해져도, "고신호의 최소집합"을 찾는 일의 가치는 사라지지 않습니다. 오히려 작업이 길고 복잡해질수록 더 중요해집니다.

🧪 직접 검증법: 같은 작업을 (a) 컨텍스트를 최소한으로 추린 버전과 (b) "혹시 몰라" 다 넣은 버전으로 비교해보세요. 최신 모델일수록 (a)가 (b)와 비슷하거나 더 나은 경우가 많을 겁니다. 이 비교가 "더 많이 = 더 좋다"는 직관을 교정해줍니다.

이 장에서 배운 것

  • 3부의 핵심은 "컨텍스트를 귀하고 유한한 자원으로 다루어라" 한 문장이다.
  • select(선별)·compress(압축)·isolate(격리)에 배치를 더하면 컨텍스트 설계의 거의 모든 결정을 포괄한다.
  • 컨텍스트 엔지니어링은 정적 작업이 아니라 매 단계 무엇을 넣고 뺄지 결정하는 동적 과정이다.
  • 컨텍스트(무엇을 보여줄지)와 프롬프트(그것으로 무엇을 할지)는 실전에서 맞물려 함께 작동한다.
  • 모델이 똑똑해지면 처방적 통제는 줄여도 되지만, 유한한 attention과 무관 정보의 방해는 변하지 않으므로 최소집합 원칙은 남는다.

✍️ 확인 문제

  1. select·compress·isolate·배치 네 가지를, 당신이 실제로 자주 하는 작업 하나에 어떻게 적용할지 각각 한 줄로 적어보세요.
  1. "최신 모델은 똑똑하니 컨텍스트 설계는 신경 안 써도 된다"는 주장에서, 맞는 부분과 틀린 부분을 구분해 설명해보세요.
  1. (실습) 2부와 3부를 모두 동원해, "긴 이메일 스레드를 받아 핵심 결정사항을 요약하고 다음 행동을 제안하는" 작업의 컨텍스트·프롬프트 설계를 표로 정리해보세요. (위 "함께 작동한다" 예시를 참고)
다음 → 4부 · 신뢰성과 품질 (작성 예정)
이전 ← 16. 관련 자료를 효과적으로 제공하기 · 목차