프롬프트 트릭은 죽었지만, 컨텍스트 엔지니어링은 그렇지 않다

이 영상에서 다루는 내용:

0:00 1백만 토큰 창은 끝없이 선택할 수 있는가? 아니다
0:19 프롬프트 엔지니어링은 절반만 맞다
1:25 두 가지 반사 작용: 다듬기 또는 모든 것을 쏟아붓기
2:34 페르소나, 채우기(stuffing) 그리고 실험
5:15 선택, 순서, 길이
8:15 도구(Tools), 스키마(schemas), 예시
10:58 비용(Costs), 그리고 언제 채우기가 괜찮은지
12:37 프롬프트, 컨텍스트, 및 하네스 레이어

대부분의 개발자들은 백만 토큰 창이 입력되는 내용을 선택하는 것을 멈출 수 있다는 의미라고 가정한다. 하지만 그 가정은 틀렸다. Chroma는 2025년에 열여덟 개의 모델을 테스트했으며, 단순한 검색(retrieval)에서도 입력값이 증가함에 따라 신뢰도가 떨어졌다. 문구적 속임수는 사라졌지만, 창에 무엇이 들어갈지 결정하는 것은 여전히 과제이다.

프롬프트를 다시 작성해도 아무것도 바뀌지 않았다

현재의 최첨단 모델(frontier model)을 사용하여 요약 기능을 가져와 지침을 열 가지 방식으로 다시 작성해 보았다: 더 짧게, 더 길게, 더 공손하게, 페르소나를 부여하여, 단계별로 유도하며. 실무자들은 출력물이 예상보다 훨씬 적게 움직인다고 보고한다.

따라서 프롬프트 엔지니어링이 끝났다는 주장은 절반만 맞다. 페르소나와 마법의 문구(magic-phrase) 트릭은 정확도를 신뢰성 있게 개선하지 못한다. 하지만 톤과 행동은 여전히 산문 속에 존재하며, 공급업체 가이드라인은 작업에 필요한 정밀한 지침뿐 아니라 논리와 데이터도 강조한다.

이제 단어는 그대로 두고 주변의 자료를 변경해 본다. 검색된 문서를 교체하거나, 순서를 바꾸거나, 도구를 추가하거나, 히스토리(history)를 잘라낸다. 같은 기능이라도 다른 답변을 내놓는다. 이러한 실패는 실제이며, 결코 문구 자체에 있는 문제가 아니었다.

지켜야 할 주장은 하나의 기술이 전체 작업과 혼동되었다는 것이다. 문구화가 그 기술이었다. 이 작업은 모델이 무엇을 보게 할지를 통제하는 것이다. Anthropic의 엔지니어링 팀도 같은 말을 한다: 그들은 컨텍스트 엔지니어링(context engineering)을 프롬프트 엔지니어링의 자연스러운 발전 단계라고 부른다. 이 학문은 사라진 것이 아니라 확장된 것이다. 만약 당신의 기능이 여전히 잘못되었다면, 문구를 다시 작성하는 것만으로는 절대 고쳐지지 않았을 것이다.

두 가지 반사 작용: 단어를 다듬거나, 모든 것을 쏟아붓거나

출력이 나쁠 때, 유능한 개발자는 두 가지 해결책 중 하나를 선택하며, 둘 다 엔지니어링처럼 느껴진다.

첫 번째는 단어를 다듬는 것입니다. 당신은 세계적인 전문가입니다. 심호흡을 하고 단계별로 생각하세요. 그런 다음 뇌물, 위협, 정교한 공손함이 뒤따릅니다. 이것은 어디서 온 미신이 아닙니다. 이전 모델에서는 그러한 문구가 출력의 어조를 특정 방향으로 유도할 수 있었습니다. 더 공식적이거나, 더 신중하거나, 원하는 것에 가까운 방식으로 말입니다. 당신은 그것이 작동하는 것을 보았기 때문에 계속해서 이를 사용하려 합니다.

두 번째 반사 작용은 아예 선택을 멈추는 것입니다. 2026년 9월 후반에 출시된 Claude Sonnet 5.5는 백만 토큰 창(window)을 가지고 있습니다. Gemini 3.8 Flash는 1,048,576개의 입력 토큰을 수용합니다. GPT-6.1 Sol은 1,050,000개로 보고되었습니다. 문서를 선택하는 것은 작업이며, 작업에는 버그가 있습니다. 그렇다면 왜 선택할까요? 창이 그렇게 많은 양을 담을 수 있다면, 모든 것을 포함시키고 모델이 스스로 정리하도록 내버려 두는 것입니다. 그것은 공짜처럼 보입니다.

두 반사 작용은 공통점을 가집니다. 둘 다 모델을 조정해야 할 변수로, 입력을 고정된 것으로 취급합니다. 하나는 더 나은 단어로 모델을 설득하고, 다른 하나는 더 많은 자료를 제공하며 모델이 스스로 처리할 것이라고 신뢰합니다. 어느 쪽도 입력 자체가 문제였는지 묻지 않습니다. 그리고 이 '덤핑(dumping)'이 공짜라는 것에는 측정 가능한 의문점이 있습니다.

페르소나와 추론 증거가 말하는 바

페르소나 문구부터 시작하세요. 왜냐하면 이는 테스트되었기 때문입니다. 2025년 12월의 Wharton 연구에 대한 보고서에서, 박사 수준의 질문을 다루는 여섯 가지 최첨단 모델(frontier models)에 대해 모델에게 자신이 전문가라고 말하는 것이 사실적 정확도를 신뢰성 있게 향상시키지 못한다는 것을 발견했습니다. 네 가지 모델 계열에 걸쳐 162개의 페르소나를 사용한 EMNLP 2024 연구 보고서는 무작위로 하나를 선택하는 것보다 일관되게 우수한 성능을 보이는 어떤 페르소나 전략도 찾지 못했습니다.

두 연구 모두 제가 받은 이차적인 정리(secondary write-ups)를 통해 접했으므로, 인용하기 전에 논문들을 읽어보세요. 이 주장 또한 범위가 좁습니다. 페르소나는 여전히 어조를 형성할 수 있으며, 일부 작가들은 여전히 이를 권장합니다. 발견된 바는 그것들이 정확도에 있어 신뢰성이 떨어진다는 것이지, 쓸모없다는 것은 아닙니다.

추론(Reasoning) 역시 이동했습니다. Claude 문서에 따르면 이전의 수동 확장 사고(manual extended-thinking) 설정은 Claude 5 모델에서 지원되지 않으며, 이를 대체한 제어 기능이 적응형 사고(adaptive thinking)입니다. Sonnet 5.5에서는 기본적으로 높은 노력 수준으로 활성화되어 있습니다. 이제 '사고'는 작성하는 문장이 아니라 구성하는 설정이 되었습니다.

테스트: 단어 선택 대(對) 내용 선택

Claude Sonnet 5.5를 사용하여 이 테스트를 진행했습니다. 고정된 풀에 30개의 검색된 청크가 있습니다. 첫 번째 실행에서는 세 개의 청크는 고정되고, '이것을 요약해라'라는 지시문만 15가지 방식으로 재작성됩니다: 더 짧게, 더 길게, 공손하게, 페르소나를 부여하여, 단계별로 유도하며 등. 두 번째 실행에서는 단어 선택은 고정되고 오직 선택(choice)만 변경되어, 30개 중 어떤 세 개가 컨텍스트 창에 들어갈지 결정됩니다. 모든 출력은 동일한 방식으로 점수가 매겨집니다.

예상되는 결과는 단어 방식 전반의 분산 정도가 청크 선택 전반의 분산 정도보다 작게 나오는 것입니다. 하지만 이것은 기대일 뿐, 발견된 사실은 아닙니다. 여기서 한 가지 주의할 점이 있습니다: 이 대비를 측정한 1차 자료를 찾지 못했으므로, 이는 법칙이 아니라 하나의 모델에서 진행된 단일 실험입니다.

모든 것을 쏟아내는 반사 작용이 무너지는 곳

Chroma의 Context Rot 연구는 18개 모델을 테스트하여 검색이나 텍스트 복제 같은 간단한 작업에서도 입력 길이가 길어질수록 신뢰도가 떨어진다는 것을 발견했습니다. Lost in the Middle은 위치 효과(position effects)를 발견했는데, 모델이 관련 구절이 입력의 시작이나 끝에 있을 때 가장 잘 작동하고 중간에 있을 때는 성능이 떨어지는 경우였습니다.

두 연구 모두 이전 모델을 사용했습니다. Chroma의 것은 2025년 중반 시스템이었고, 현재 출시되는 백만 토큰(million-token) 모델에서는 재현할 수 없었습니다. 이를 판단 근거가 아닌, 자체 파이프라인을 테스트해야 할 이유로 간주하십시오. 또한, 30개의 청크는 백만 토큰에 비하면 훨씬 적은 양이므로, 제 실험은 부패(rot)를 테스트하는 것이 아니라 선택(selection)을 테스트합니다.

다음으로 언급할 것은 요금 문제입니다. GPT-6.1 Sol은 1,050,000 토큰의 컨텍스트 창을 갖는 것으로 보고되었지만, 입력 토큰이 272,000개를 초과하는 프롬프트는 전체 요청에 대해 입력 속도의 두 배로 요금이 부과됩니다. 이 수치는 보조 출처에서 나온 것이므로 가격 페이지를 확인하세요. 그럼에도 불구하고 교훈은 유효합니다. 창의 크기가 사용이 신뢰할 수 있거나 저렴한 범위의 크기를 의미하지는 않는다는 것입니다. 컨텍스트 창은 용량입니다. 그것이 무엇을 담아야 하는지 알려주지는 않습니다.

컨텍스트 창은 어텐션 예산이다

창에 추가하는 모든 토큰은 어텐션(attention)으로 비용이 청구됩니다. Anthropic의 엔지니어링 가이드라인은 지식 기반 문서에 요약되어 있으며, 컨텍스트를 '어텐션 예산(attention budget)'이라고 부릅니다. 그 이유는 트랜스포머(transformer)가 모든 토큰을 다른 모든 토큰과 연결하기 때문에 n개의 토큰은 n 제곱의 쌍별 관계를 의미하기 때문입니다. 토큰을 추가할수록 각 토큰이 차지하는 비중은 얇아집니다. 컨텍스트는 저장 공간이 아닙니다. 그것은 예산이며, 포함시키는 모든 구절은 실제로 질문에 답하는 구절과 경쟁합니다.

Chroma의 연구는 2025년 모델을 기반으로 수행되었으며 같은 방향을 가리킵니다. 방해 요소(distractors)는 성능을 불균형하게 저하시키며, 바늘이 질문과 얼마나 유사했는지에 따라 결과가 달라졌습니다. 이는 최악의 채움재(filler)가 무작위 노이즈가 아니라 '근접한 오류(near miss)'라는 것을 시사합니다. 즉, 관련 있어 보이는 것처럼 보이지만 실제로는 그렇지 않은 청크입니다. 이것을 현재 모델에 대한 가설로 간주하세요.

네 가지 레버: 선택, 순서, 길이, 타이밍

첫 번째 레버는 '선택(selection)'입니다. 30개의 청크 중 상위 3개를 고르는 것은 랭킹 문제이자 검색 정밀도 결정 문제입니다. 만약 당신의 랭커가 그럴듯하지만 틀린 청크를 상위 3개에 포함시킨다면, 어떤 지침으로도 답변을 구할 수 없습니다. 테스트할 가치가 있는 베팅은 이것입니다. 즉, 단어 선택이 아니라 청크의 선택이 조정해야 할 변수라는 것입니다. 이 대조(contrast)에 대한 공개된 측정치는 없으므로, 자신만의 작업과 모델로 실행해 보세요. 실제적으로 이는 검색 정밀도를 일급 수치(first-class number)로 측정하고, 느슨한 유사도 임계값 대신 명확한 개수로 자르는 것을 의미합니다.

두 번째 레버는 순서(order)입니다. 'Lost in the Middle' 연구에 따르면, 모델은 입력의 시작이나 끝에 있는 증거를 중간에 묻힌 증거보다 더 신뢰성 있게 사용했습니다. 이는 구형 모델을 대상으로 측정된 것이므로, 이 규칙은 사용자님의 모델에 대한 가설로 받아들이셔야 합니다. 질문과 중요한 자료는 양쪽 끝(edge)에 배치하고, 질문 자체는 끝 근처에 두십시오. 그런 다음 주요 구절을 위치별로 이동시키면서 점수를 관찰하여 사용자님의 모델에서 테스트해 보세요.

세 번째 레버는 길이(length)이며, 이를 위한 도구는 압축(compression)입니다. Anthropic이 요약 보고서에서 언급한 다중 에이전트 패턴은 하위 에이전트가 검색에 수만 개의 토큰을 소모하고 약 1천~2천 개의 토큰으로 응축된 요약을 반환하게 합니다. 부모 에이전트는 40페이지 분량의 막다른 길(dead ends)을 결코 보지 못합니다. 오직 결론만을 봅니다. 작업은 격리되며, 그 결과만이 사용자가 신경 쓰는 창(window) 안으로 들어옵니다.

네 번째 레버는 데이터가 들어오는 시점입니다. Anthropic은 적시성 전략(just-in-time strategy)을 설명합니다. 모든 문서를 미리 로드하는 대신, 에이전트는 가벼운 식별자들—파일 경로, 저장된 쿼리, 링크—을 유지합니다. 그리고 도구를 통해 런타임에 실제 데이터를 가져옵니다. Claude Code는 대규모 데이터베이스에서 이를 수행하며, 전체를 로드하기보다는 객체의 헤드와 테일만 살펴봅니다. Anthropic은 또한 Claude Code가 기본적으로 도구 응답을 2만 5천 개의 토큰으로 제한한다고 언급합니다.

에이전트는 무엇이 존재하는지 학습하고, 필요한 것만 열어본 다음, 다음 것을 엽니다. 이것이 점진적 공개(progressive disclosure)입니다. 참조 자료가 저렴하고 로드가 의도적이므로 창은 작게 유지됩니다.

선택(Selection), 순서(order), 압축(compression), 그리고 지연(deferral) 모두 무엇을 자리를 차지하게 할지 결정합니다. 이들 중 어느 것도 창의 크기가 얼마나 되는지를 묻지는 않습니다. 백만 개의 토큰은 단지 잘못할 수 있는 최대치를 높일 뿐입니다.

도구 설명도 컨텍스트이다

문서는 모델이 보는 것의 일부에 불과합니다. 첫 번째 검색된 청크가 도착하기 전에, 모델은 이미 사용자의 도구 정의를 읽었습니다. 이름, 설명, 매개변수 문서: 이 모든 것이 창 안으로 로드되며, 이 모든 것이 에이전트를 안내합니다.

Anthropic의 엔지니어링 팀은 도구 설명을 위한 프롬프트 엔지니어링을 도구를 개선하는 가장 효과적인 방법 중 하나라고 언급하며, 그 조언은 간단합니다. 마치 신입 사원에게 온보딩(onboarding)하는 것처럼 설명을 작성하세요. 암묵적인 것을 명시적으로 만드세요: 가정하는 쿼리 형식, 팀이 사용하는 전문 용어, ID의 의미 등을 말입니다.

단순히 '티켓을 검색한다'고 설명된 도구는 모델로 하여금 추측하게 만듭니다. 무엇으로 검색하나요? 제목만 반환하나요 아니면 전체 스레드를 반환하나요? 날짜가 문자열인가요 아니면 범위인가요? Claude 자체의 문서도 이 경계를 명확히 합니다. 좋은 설명은 도구가 무엇을 하는지, 언제 사용해야 하는지, 어떤 데이터를 반환하는지, 그리고 각 매개변수가 무엇을 의미하는지를 말해줍니다. 형편없는 설명은 너무 간결하고, 그 공백이 바로 위 네 가지 핵심 포인트입니다. 모델은 이 공백을 추측으로 채우고, 당신은 그 추측들을 잘못된 도구 호출로 보게 됩니다.

반대 방향도 중요합니다. 도구의 응답 역시 선택 문제(selection problem)입니다. 만약 도구가 일치하는 모든 레코드를 반환한다면, 당신은 함수 호출 안에 '모두 덤프하기'라는 반사 작용을 재건한 것입니다. Anthropic은 페이지네이션(pagination), 범위 선택(range selection), 필터링(filtering), 그리고 잘 정의된 기본값과 함께 자르기(truncation)를 결합하여, 첫 번째 응답이 작고 에이전트가 의도적으로 더 많은 정보를 요청하도록 제안합니다. 위에서 언급한 Claude Code 제한은 동일한 아이디어이며, 하네스(harness)에 의해 강제됩니다.

출력 스키마와 예시 (Output schemas and examples)

출력 스키마는 모델이 작성할 수 있는 공간을 제약합니다. 필드(Fields), 타입(Types), 허용되는 값들: 이 각각은 생성이 시작되기 전에 잘못된 답변의 전체 계열을 제거해 줍니다.

예시도 비슷한 역할을 하지만, 한 가지 주의점이 있습니다. Anthropic의 가이드는 수많은 예외 케이스(edge cases)들의 더미보다 다양하고 표준적인 몇 가지 대표 예시를 선호합니다. 일반적인 형태를 포괄하는 세 가지 예시는 형식을 고정합니다. 스무 개의 예외 케이스는 모델에게 예외 케이스가 정상이라는 것을 가르치고, 매번 주의력을 소모하게 만듭니다.

지형은 변하고, 산문(prose)은 여전히 역할을 한다

이 기반 지식(ground)이 얼마나 빠르게 움직이는지에 대한 경고가 필요합니다. Claude Sonnet 5.5에서는 강제 도구 사용(forced tool use) 시 오류가 반환됩니다. 우리 중 많은 사람이 특정 모델이 특정 도구를 호출하도록 만들 때 사용했던 스위치가 해당 모델에서는 사라졌습니다. 이제 도구 선택을 유도하는 것은 설명(descriptions)에 작성된 내용과 컨텍스트 내의 다른 요소들에 의존합니다. 여러분의 프롬프트는 변하지 않았지만, 그 아래의 하우징(harness)이 바뀌었습니다.

산문(Prose)은 여전히 이 창에서 중요한 역할을 하지만, 역할 자체가 달라졌습니다. OpenAI가 GPT-6 Astra에 제시한 프롬프팅 가이드라인은 모델에게 컨텍스트로부터 의도를 추론하고 행동(action) 쪽으로 편향되도록 지시합니다. 'can you'나 'help me'와 같은 구절은 후속 질문을 하라는 초대(invitation)가 아니라, 행동을 요청하는 것으로 처리되어야 합니다. 이것이 바로 행동 사양(behaviour spec)입니다. 이는 페르소나가 아니며 마법의 문구도 아닙니다. 모델이 문서에서 읽어낼 수 없는 정책을 명시합니다.

따라서 이 창은 단순히 문서 이상의 것입니다. 도구, 스키마(schema), 예제, 그리고 몇 줄의 정책으로 구성되어 있으며, 이 모든 것이 동일한 주의력 예산(attention budget)을 두고 경쟁하고 있습니다. 이 모든 것이 제자리를 잡고 모델 자체가 업데이트되었을 때, 이것이 여전히 작동하는지 어떻게 알 수 있을까요?