2026년에 들어서면서, X의 엔지니어 업계에서 이 말을 몇 번이고 보게 되었다.

“프롬프트 엔지니어링 (Prompt Engineering)은 이제 구식이다. 앞으로는 컨텍스트 엔지니어링 (Context Engineering)이다.”

계기는 명확하다. 2025년 6월 25일, Andrej Karpathy가 X 상에서 context engineering이라는 개념을 언급했고, 같은 달 Shopify의 CEO인 Tobi Lütke도 그 중요성을 공개적으로 지지하면서 업계 전체에 순식간에 퍼졌다.

다만, 이런 “○○은 이제 구식이다” 계열의 문구는 매년 등장했다가 사라지곤 한다. 정말 프롬프트 엔지니어링은 끝난 것인가? 컨텍스트 엔지니어링이란 무엇인가? ——이번에는 이를 냉정하게 정리하여 생각해 보고자 한다.

먼저 정의부터.

**컨텍스트 엔지니어링 (Context Engineering)**이란, LLM이 추론 시에 참조하는 정보 전체 (컨텍스트 윈도우 (Context Window))에 무엇을, 어떤 순서로, 얼마나 전달할지를 설계하는 기술이다.

프롬프트 엔지니어링과의 차이점을 정리하면 다음과 같다.

중요한 것은, 두 개념은 대립 관계가 아니다라는 점이다. Sakana AI의 아키바 타쿠야(秋葉拓哉) 씨는 “1회 왕복의 대화라면 프롬프트 엔지니어링과 컨텍스트 엔지니어링은 거의 같은 것이 된다”라고 말했다. 즉, 컨텍스트 엔지니어링은 프롬프트 엔지니어링을 포함하는 상위 개념으로 파악하는 것이 정확하다.

“컨텍스트 윈도우가 100만 토큰이 되었으니, 전부 다 집어넣으면 되는 것 아닌가?”

직관적으로는 그렇게 생각될 수 있다. 하지만 여기에 큰 함정이 있다.

2025년 7월, Chroma Research가 발표한 연구는 AI 커뮤니티에 충격을 주었다. GPT-4.1 · Claude 4 · Gemini 2.5를 포함한 18개의 최첨단 모델을 평가한 결과, 모든 모델에서 입력 토큰 수가 늘어날수록 성능이 저하된다는 것이 실증되었다.

짧은 프롬프트에서 95%였던 정확도가 긴 컨텍스트에서는 60~70%까지 저하

이 현상은 **“Context Rot (컨텍스트의 부패)”**라고 명명되었다. 정보가 윈도우 안에 들어있더라도, 필요한 정보가 방대한 노이즈에 파묻혀 출력 정확도가 떨어지는 것 —— 이것이 실서비스 시스템에서의 가장 큰 실패 요인이 되고 있다.

즉, 컨텍스트 엔지니어링의 핵심은 **“덧셈”이 아니라 “뺄셈”**이다. Anthropic도 2025년 9월에 “좋은 컨텍스트 엔지니어링이란, 바람직한 결과의 가능성을 최대화하는 최소한의 고시그널(High-signal) 토큰 세트를 찾는 것이다”라는 원칙을 공개했다.

이것이 단순한 유행어가 아니라는 증거로, 정량적인 성과도 나오고 있다.

LangChain의 실험에서는 모델을 전혀 변경하지 않고, 하네스(컨텍스트 설계)만을 개선함으로써 벤치마크인 Terminal Bench 2.0의 점수가 52.8% → 66.5%로 13.7포인트 향상되었다.

같은 모델이라도 전달하는 정보의 설계에 따라 이만큼의 차이가 난다. 이것이 컨텍스트 엔지니어링이 “진정한 기술”이라고 불리는 이유다.

여기서부터는 개인적인 의견이다.

“프롬프트 엔지니어링은 이제 구식이다”라는 말은 절반은 맞고, 절반은 오도(mislead)하고 있다고 생각한다.

“Act as a...”, “Think step by step”과 같은 마법의 주문 같은 테크닉은 확실히 범용화(Commodity)되었다. 모델이 똑똑해지면서 다소 거칠게 물어도 의도를 파악해 주기 때문이기도 하다. 실제로 LinkedIn 상의 “Prompt Engineer”라는 직함의 구인 정보는 2024~2025년에 크게 감소했다는 데이터도 있다.

하지만 “프롬프트를 설계하는 능력”이 불필요해진 것은 아니다. 그것은 컨텍스트 엔지니어링이라는 커다란 프레임워크의 일부로 흡수되었을 뿐이다.

실제로 현장의 Claude Code나 Cursor를 사용한 개발에서는 ——

• CLAUDE.md에 기술 스택이나 금지 사항을 작성하기 (영구적 컨텍스트 (Permanent Context) 설계)
• RAG로 전달할 정보를 엄선하기 (노이즈 제거)
• 도구를 필요한 만큼 단계적으로 공개하기 (Progressive Disclosure)

이러한 「AI에게 보여줄 세계 그 자체를 설계하는」 작업이 엔지니어의 새로운 일상이 되어가고 있다.

고찰만으로 끝나면 실용성이 없기에, 내가 의식하고 있는 세 가지를 적어둔다.

1. 「넣지 않을 용기」를 갖기

모두 전달한다고 해서 좋은 것은 아니다. 컨텍스트 부패 (Context Rot)를 피하기 위해, 정말로 필요한 정보만을 큐레이션한다.

2. CLAUDE.md / 시스템 프롬프트 (System Prompt)에 영구적인 규칙을 집약하기

「매번 같은 지시를 쓰는 것」은 설계 미스다. 지켜주길 바라는 제약 사항은 세션을 넘어서도 적용될 수 있는 곳에 둔다.

3. 도구를 너무 많이 담지 않기

100개 이상의 도구를 사전에 로드하면 환각 (Hallucination)의 원인이 된다. 필요한 것만 단계적으로 제공한다.

「○○은 이제 구식이다」라는 문구에 휘둘리지 않고, 그 이면에 있는 본질적인 변화를 포착하는 것이 중요하다고 생각한다. 이번 사례로 말하자면, 그것은 「AI에게 무엇을 보여줄지를 설계하는 책임이 엔지니어에게로 넘어오고 있다」는 것이다.

프롬프트의 주문을 연마하던 시대에서, AI가 보는 세계 그 자체를 설계하는 시대로.

여러분의 현장에서는 어떤 컨텍스트 설계 노하우를 사용하고 계신가요? 꼭 댓글로 알려주세요 🙏

도움이 되었다면 LGTM(Like) 부탁드립니다. 큰 힘이 됩니다!

• Andrej Karpathy 氏 X 게시물 (2025년 6월 25일)
• Tobi Lütke 氏 (Shopify CEO) X 게시물 (2025년 6월 19일)
• Chroma Research 「Context Rot」 연구 (2025년 7월)
• LangChain 「Agent = Model + Harness」 벤치마크 실험 (2026년 3월)
• Anthropic 「Effective context engineering for AI agents」 (2025년 9월)
• Nikkei XTECH 「LLM을 AI 에이전트로 진화시키는 컨텍스트 엔지니어링」 (2026년 2월)