RAG 위에 4개의 컨텍스트 레이어를 추가했습니다. Sonnet은 12% 개선되었고, Haiku는 14% 악화되었습니다.

"Full Context Engineering (전체 컨텍스트 엔지니어링)"에 관한 글을 읽고, 즉시 제 RAG (Retrieval-Augmented Generation) 파이프라인에 네 개의 레이어를 더 추가했습니다. 구조화된 출력 지침 (Structured output instructions), 계층적 문서 레이아웃 (Hierarchical document layout), 역할 정의 (Role definition), 퓨샷 예시 (Few-shot examples). 그야말로 모든 것을 다 때려 넣었습니다. 결과는 Claude Sonnet의 경우 12% 개선되었지만, Claude Haiku의 경우 -14%로 악화되었습니다. 저는 작은 모델의 성능을 떨어뜨리기 위해 2주 동안이나 스캐폴딩 (Scaffolding)을 구축하는 데 시간을 허비한 셈입니다. 방에 벽지를 바른 뒤 뒤로 물러나 보니 전등 스위치를 덮어버린 것을 발견했을 때의 기분을 느껴본 적이 있다면, 그 느낌을 이해할 것입니다. 이 포스트는 2026년에 여러분이 컨텍스트 엔지니어링 (Context engineering) 노력을 어떻게 소비해야 하는지에 대해, 그 수치들이 실제로 무엇을 의미하는지에 대해 다룹니다.

제가 측정한 것은 이전 실험(저렴한 모델에 관한 포스트)을 위해 제 도서 코퍼스 (Book corpus)를 대상으로 실행했던 벤치마크 (Benchmark)였습니다. 동일한 채점 기준을 적용했습니다: 사실적 정확성 (Factual accuracy), 환각률 (Hallucination rate), 구체성 (Specificity), 그리고 0에서 15점 척도의 정직성 (Honesty)입니다. 구성은 사다리 형태였습니다. 각 단계는 이전 단계 위에 하나씩을 더 추가하는 방식입니다.

• System prompt only (시스템 프롬프트만 사용): 최소한의 베이스라인 (Baseline). 검색(Retrieval)도 없고 아무것도 없는 상태.
• System + RAG: 큐레이션된 코퍼스에 대한 벡터 검색 (Vector search)을 수행하고, 상위 문서들을 주입 (Injected).
• Full Context Engineering: RAG + 구조화된 출력 지침 + 계층적 레이아웃 + 역할 정의 + 퓨샷 예시.

제가 기대했던 것: 매끄러운 상승 곡선. 제가 얻은 것: 앞으로 기울어지다가 툭 떨어져 버리는 곡선.

Claude Sonnet, 총점 (15점 만점):

구성	총점	이전 단계 대비 변화량
System only	8.8	--
System + RAG	10.2	+1.4 (+16%)
Full Context Engineering	11.4	+1.2 (+12%)

Claude Haiku, 총점 (15점 만점):

구성	총점	이전 단계 대비 변화량
System only	3.7	--
System + RAG	11.8	+8.1 (+219%)
Full Context Engineering	10.1	-1.7 (-14%)

제가 예상하지 못했던 두 가지 발견이 있었습니다. 첫째: RAG가 거의 모든 일을 하고 있습니다. Sonnet의 경우, RAG가 베이스라인과 풀 옵션 파이프라인 사이의 격차 중 88%를 메웠습니다 (총 2.6점 개선 중 1.4점). Haiku의 경우, RAG가 최종 수치를 완전히 초과해 버렸습니다. 둘째: RAG 위에 더 많은 것을 쌓아 올리는 것은 공짜가 아닙니다.

Haiku의 경우, 상황을 적극적으로 악화시켰습니다. 환각 (Hallucination) 점수는 1.7에서 0.5로 떨어졌습니다. 정직성 (Honesty) 점수는 1.3에서 0.5로 떨어졌습니다. 모델은 이전에는 확답을 피했던 내용들에 대해 자신 있게 지어내기 시작했습니다. 왜 이런 일이 발생하는지에 대해, 저는 현실과 부딪혀도 살아남을 수 있을 만한 가설을 하나 가지고 있습니다. 작은 모델은 작업 기억 (Working memory)이 제한적입니다. RAG는 모델에게 올바른 사실을 전달합니다. 일단 그 사실들이 모델 앞에 놓이면, 추가적인 구조를 더함으로써 얻는 한계 효용 (Marginal returns)은 작습니다. 하지만 추가적인 컨텍스트 (Context)로 인한 한계 비용 (Marginal cost)은 작지 않습니다. 역할 정의 (Role definition)의 모든 문단, 모든 퓨샷 (Few-shot) 예시, 모든 "출력 형식을 맞추는 방법" 블록은 모델의 주의력 (Attention)을 두고 검색된 문서들과 경쟁합니다. Sonnet의 경우, 작업 기억이 충분히 넓어서 이러한 추가 요소들이 사용되지 않는 공간에 자리 잡습니다. 하지만 Haiku의 경우, 추가 요소들이 실제로 유용한 검색된 컨텍스트를 컨텍스트 창 (Context window)의 가장자리로 밀어내 버립니다. 모델이 그것을 여전히 보기는 하지만, 더 이상 신뢰하지 않게 되는 것입니다. 이는 최근 롱 컨텍스트 (Long-context) 동작에 관한 연구에서 계속해서 나타나고 있는 것과 동일한 발견입니다. 높은 컨텍스트 채움 상태에서의 지시 이행 (Instruction-following)에 관한 연구들에 따르면, 2026년의 대부분의 프런티어 모델 (Frontier models)들은 컨텍스트가 60~70% 채워질 때 품질이 측정 가능한 수준으로 저하되기 시작하며, 90% 부근에서는 낭떠러지처럼 급격히 떨어집니다. 이 낭떠러지는 작은 모델일수록 더 가파릅니다. 파레토 법칙 (Pareto principle)은 컨텍스트 엔지니어링 (Context engineering)에 당혹스러울 정도로 정확하게 적용됩니다. RAG는 결과의 80%를 만들어내는 20%의 노력입니다. 그 위에 쌓아 올리는 모든 것은 롱테일 (Long tail)입니다. 제가 거의 언급하는 것을 잊을 뻔했던 2026년의 현실: 제가 원래의 실험을 수행했을 때는 200K 컨텍스트 창을 가진 Sonnet 4와 Haiku 3를 사용하고 있었습니다. 이 글을 쓰는 시점에서, Sonnet 4.6은 표준 가격으로 1M 토큰의 컨텍스트 창을 제공하며, 프롬프트 캐싱 (Prompt caching)은 반복되는 컨텍스트의 비용을 90% 절감합니다. 이것은 계산 방식을 바꾸지만, 여러분이 생각하는 방향으로는 바뀌지 않습니다. 1M 컨텍스트 창이 쌓아 올린 컨텍스트를 설계하는 비용을 마법처럼 저렴하게 만들어주지는 않습니다. 모델은 여전히 올바른 것에 주의를 기울여야 하기 때문입니다.

60%에서 70% 채워졌을 때 발생하는 절벽은 절대적인 수치가 아니라 비율입니다. 컨텍스트 창(Context Window)이 더 크다는 것은, 절벽 아래로 떨어지기 전까지 더 많은 잘못된 컨텍스트를 작성할 수 있다는 의미일 뿐입니다. 만약 쌓아 올린 레이어들이 정적(Static)이라면 프롬프트 캐싱 (Prompt Caching)이 도움이 됩니다. 역할 정의(Role definition), 퓨샷 예시 (Few-shot examples), 구조화된 출력 지침 (Structured output instructions)과 같은 부분들은 깔끔하게 캐싱됩니다. 하지만 이는 비용만 절감할 뿐입니다. 품질을 보존해주지는 않습니다. 만약 Haiku의 결과가 -14%였다면, 프롬프트 캐싱은 그 -14%를 더 저렴하게 만들어줄 뿐입니다. 그것은 당신이 원하던 승리가 아닙니다.

아무도 말해주지 않았던 점은, 이러한 관점에서 Anthropic의 Skills 기능이 흥미롭다는 것입니다. Skills는 필요할 때 로드되는 재사용 가능한 컨텍스트 번들 (Context bundles)입니다. 이를 생각하는 올바른 방식은 "항상 더 많은 컨텍스트"가 아니라 "적시에 필요한 컨텍스트 (Just in time)"입니다. 이것이 제 Full CE 실험이 직면했던 실패 모드였습니다. 저는 모든 레이어를 모든 요청에 쑤셔 넣고 있었습니다. Skills는 대안을 제시합니다. 시스템 프롬프트 (System prompt)를 작게 유지하고, 관련 있는 Skill을 검색(Retrieve)하여, 나머지는 컨텍스트 창 밖에 머물게 하는 것입니다. 이는 RAG에 적용되는 교훈을 한 단계 위로 올린 것과 같습니다. 모든 것을 다 집어넣는 것보다 선택적인 것이 더 낫습니다.

지금 제가 하는 방식
이 글에서 단 한 가지만 얻어 가신다면, 이것을 가져가십시오: 연산의 횟수보다 연산의 순서가 더 중요합니다. 먼저 검색(Retrieval) 시스템을 구축하십시오. 깨끗한 코퍼스 (Corpus), 괜찮은 임베딩 (Embeddings), 그리고 관련성 임계값 (Relevance threshold)을 사용하여 RAG가 작동하도록 만드십시오. 이것이 당신의 80%입니다. 벤치마크 (Benchmark)를 실행하십시오. 느낌(Vibes)이 아니라, 실제 질문을 대상으로, 실제 루브릭 (Rubric)에 따라 채점하는 진짜 벤치마크를 수행하십시오. 그 다음 한 번에 하나의 레이어씩 추가하십시오. 구조화된 출력 (Structured output), 그다음 계층적 레이아웃 (Hierarchical layout), 그다음 역할 정의 (Role definition) 순서로 진행하십시오. 각 단계 후에 다시 벤치마크를 수행하십시오. 만약 점수가 떨어진다면, 해당 레이어를 제거하십시오. 레이어가 좋고 벤치마크가 잘못되었다고 가정하지 마십시오. 벤치마크는 당신이 생각하는 것보다 더 자주 옳습니다. 동일한 사다리 방식을 더 작은 모델에도 시도해 보십시오. Sonnet을 돕는 것이 Haiku를 해칠 수도 있습니다. 당신이 선의 어느 쪽에 있는지 아는 것이 비용을 아껴줄 것입니다. 이는 당연하게 들리겠지만, 대부분의 팀이 실제로 하는 방식은 아닙니다.

대부분의 팀은 Context Engineering (컨텍스트 엔지니어링)에 관한 블로그 포스트를 읽고, 주말 동안 네 개의 레이어를 추가한 뒤, 그 레이어들이 실제로 도움이 되었는지 전혀 측정하지 않습니다. 요리사와 주방, 재방문. 저는 이전 포스트에서 모델은 요리사이고 컨텍스트는 주방이라고 썼습니다. 저는 이를 확장하고 싶습니다. 더 많은 컨텍스트 레이어를 추가하는 것은 더 많은 주방 장비를 설치하는 것과 같습니다. 두 번째 오븐, 파스타 기계, 수비드 기계 같은 것들 말이죠. 이 중 그 어떤 것도 요리사가 파스타를 만드는 실력을 떨어뜨리지는 않습니다. 하지만 만약 파스타 기계가 요리사가 채소를 다듬던 조리대 공간을 차지해 버린다면, 저녁 식사는 어쨌든 나빠질 것입니다. 요리사에게는 모든 가전제품이 필요한 것이 아닙니다. 요리사에게 필요한 것은 손이 닿는 곳에 있는 적절한 재료입니다. Full Context Engineering (전체 컨텍스트 엔지니어링)에 관한 다음의 숨 가쁜 포스트를 읽고 레이어를 추가하기 시작하기 전에, 실험을 먼저 수행하십시오. RAG 단독으로 측정하십시오. RAG에 한 가지를 더했을 때를 측정하십시오. 제값을 하는 레이어를 찾아내고, 나머지는 카탈로그에 그대로 두십시오. 정답은 거의 항상 이렇습니다: 먼저 RAG를 제대로 수행하십시오. 그 외의 모든 것은 장식입니다. 소형 모델에서 그 장식은 정확도 점수의 부호를 뒤집어 버릴 수 있으며, 당신을 왜 이런 일이 일어났는지 의아하게 만들 수 있습니다. 다음에 누군가 "Context Engineering"이라고 말한다면, 제가 되받아치고 싶은 말은 이것입니다: 당신이 말하는 컨텍스트의 20%가 정확히 무엇인지 정의해 주십시오. 나머지 80%는 상황을 악화시킬 가능성이 높습니다. 전체 Context Engineering 시스템(다섯 가지 전략, 이 수치들의 근거가 되는 RAG 벤치마크, MCP 서버 설계, 그리고 Agentic RAG 구현)은 Turning LLMs from Liars into Experts: Context Engineering in Practice 에 담겨 있습니다.