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 무대 전체"라고 했습니다. 실전에서는 분리되지 않습니다. 한 작업을 예로 보겠습니다.
[작업: 고객 불만 메일에 답장] 컨텍스트 설계 (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과 무관 정보의 방해는 변하지 않으므로 최소집합 원칙은 남는다.
✍️ 확인 문제
- select·compress·isolate·배치 네 가지를, 당신이 실제로 자주 하는 작업 하나에 어떻게 적용할지 각각 한 줄로 적어보세요.
- "최신 모델은 똑똑하니 컨텍스트 설계는 신경 안 써도 된다"는 주장에서, 맞는 부분과 틀린 부분을 구분해 설명해보세요.
- (실습) 2부와 3부를 모두 동원해, "긴 이메일 스레드를 받아 핵심 결정사항을 요약하고 다음 행동을 제안하는" 작업의 컨텍스트·프롬프트 설계를 표로 정리해보세요. (위 "함께 작동한다" 예시를 참고)
다음 → 4부 · 신뢰성과 품질 (작성 예정)
이전 ← 16. 관련 자료를 효과적으로 제공하기 · 목차