에이전트 공학의 부상 — 파트 3: 컨텍스트 엔지니어링(Context Engineering)의 명명

컨텍스트 엔지니어링(Context Engineering)의 명명

대규모 언어 모델(LLM) 주변의 기술에 대한 연대기적 조사 중 파트 3. 파트 2는 어렵게 얻어낸 깨달음으로 끝났습니다: 용량(capacity)만으로는 정보 문제를 해결할 수 없다는 사실입니다. 2025년 중반, 그 깨달음은 이름과 분류 체계, 그리고 커뮤니티를 갖게 되었습니다.

요약(TL;DR) — Karpathy는 _컨텍스트 엔지니어링(context engineering)_이라는 용어를 만들었습니다. Breunig는 컨텍스트가 실패하는 네 가지 방식(오염(poisoning), 주의 분산(distraction), 혼란(confusion), 충돌(clash))을 분류했습니다. Microsoft/Salesforce의 연구에 따르면, 턴(turn) 사이에 흩어진 동일한 정보는 순수하게 구조적인 문제로 인해 약 39%의 비용을 발생시킵니다(데이터 손실이 아닌 구조적 문제). 또한

	프롬프트 (Prompt)	컨텍스트 (Context)
전형적인 저자	사람	시스템/프로그램
...

Breunig는 어느 쪽이 "더 나은" 것도 아니며, 서로 "다를" 뿐이며, 각기 다른 작업에 적합하다고 주의를 기울였습니다. 프롬프트 엔지니어링 (Prompt engineering)은 사람이 챗봇에게 요청을 작성하는 것을 설명합니다. 컨텍스트 엔지니어링 (Context engineering)은 각 모델 호출 (model call) 시에 적절한 도구, 문서, 이력 및 지침을 하나의 _시스템_이 조립하는 것을 설명합니다.

이 둘 사이의 이탈은 빌더들이 채팅 인터페이스에서 애플리케이션과 에이전트 (agents)로 이동함에 따라 1년 넘게 조용히 진행되어 왔습니다. 이 용어는 단순히 그 이탈에 이름을 붙인 것이며, Breunig는 그 명명 행위 자체가 중대한 결과를 초래한다고 주장했습니다.

그가 자주 인용하는 Stewart Brand의 문구인 "언어가 발명되고 변호사들이 모여드는 곳을 찾아라"를 빌려, 그는 성공적인 유행어 (buzzword)가 무(無)에서 만들어지는 것이 아니라고 주장했습니다. 유행어는 "우리 모두가 가진 공통된 경험을 식별"하며, 이를 공유된 단어로 결정화하는 것은 "커뮤니티를 형성하고, 문화를 변화시키며, 우리의 업무에 영향을 미칩니다."

이것이 실재한다는 신호는 분명했습니다. 한 달 만에 "컨텍스트 엔지니어링 (context engineering)"의 검색량은 "프롬프트 엔지니어링 (prompt engineering)" 검색량의 4분의 1 이상으로 급증했습니다. 이는 마케팅으로 인한 일시적 급증이 아니라, 진정한 잠재적 니즈를 나타내는 지속적인 상승세였습니다.

회의론자들은 이를 리브랜딩 (rebrand)이라고 불렀습니다. Hacker News의 한 댓글 작성자는 이를 "한 달짜리 기술일 뿐이며, 그 이후에는 더 이상 존재하지 않을 것"이라며 일축했습니다. 이 시리즈의 나머지 부분은 부분적으로 왜 그러한 회의론이 잘못되었는지에 대한 이야기입니다. 즉, 이 용어가 명명한 작업은 더욱 핵심적인 위치를 차지하며 성장해 왔습니다.

분류 체계: 컨텍스트가 실패하는 네 가지 방식

이 시점의 지적 핵심은 컨텍스트가 어떻게 실패하는지에 대한 Breunig의 분류였습니다. 이전에는 "모델이 긴 컨텍스트 때문에 혼란을 겪었다"라는 모호한 불만이 전부였습니다. Breunig는 이를 네 가지의 뚜렷하고 명명된 실패 모드 (failure modes)로 나누었습니다. 이러한 정밀함 덕분에 사람들은 단순히 토큰 (tokens)을 무작정 쏟아붓는 대신, 구체적인 문제를 진단하고 해결할 수 있게 되었습니다.

컨텍스트 오염 (Context Poisoning) — 환각 (hallucination)이나 기타 오류가 컨텍스트 (context)에 포함되어, 해당 오류가 반복적으로 참조되는 현상. Breunig이 제시한 주요 사례는 Google DeepMind의 Gemini 2.5 기술 보고서에 기술된 포켓몬 (Pokémon)을 플레이하는 에이전트에 관한 내용입니다. 에이전트가 환각을 일으키고 그 잘못된 믿음이 컨텍스트의 "목표 (goals)" 또는 "요약 (summary)" 부분에 입력되면, 에이전트는 "불가능하거나 무관한 목표를 달성하는 데 집착하게" 되며, "되돌리는 데 매우 오랜 시간이 걸릴 수 있는" 터무니없는 전략을 개발하게 됩니다. 일단 오류가 컨텍스트에 기록되면, 그것은 계속해서 다시 읽히고 강화됩니다.

컨텍스트 주의 분산 (Context Distraction) — 컨텍스트가 너무 길어져서 모델이 컨텍스트에 과도하게 집중한 나머지, 훈련 (training) 과정에서 학습한 내용을 소홀히 하는 현상. 동일한 Gemini 포켓몬 보고서가 그 증거를 제공했습니다. 약 100,000 토큰 (tokens)을 넘어서면, 에이전트는 "새로운 계획을 합성하기보다는 방대한 이력에서 행동을 반복하려는 경향을 보였습니다." 새로운 전략을 고안하기 위해 훈련 중에 학습한 내용을 활용하는 대신, 자신의 과거 행동을 앵무새처럼 따라 한 것입니다. 더 작은 모델들의 경우 주의 분산 임계치 (distraction ceiling)가 훨씬 더 낮습니다. 파트 2에서 언급한 Databricks의 발견(Llama-3.1-405B의 경우 약 32k에서 성능 저하 발생)도 동일한 현상입니다.

컨텍스트 혼란 (Context Confusion) — 컨텍스트 내의 불필요한 콘텐츠가 모델에 의해 사용되어 저품질의 응답을 생성하게 되는 현상. 이는 "모든 도구를 MCP를 통해 연결하자"는 지나치게 의욕적인 꿈 이면에 숨겨진 실패 모드 (failure mode)입니다.

Berkeley Function-Calling Leaderboard를 통해 증거가 확인되었습니다. 모든 모델은 하나 이상의 도구가 주어졌을 때 성능이 저하되며, 모든 모델은 때때로 완전히 무관한 도구를 호출합니다. 이 벤치마크에는 도구를 전혀 호출하지 않는 것이 정답인 경우도 포함되어 있으며, 모델들은 이 경우에도 실패합니다.

생생한 사례 연구: 연구진들이 양자화된 (quantized) Llama 3.1 8B 모델에 GeoEngine 벤치마크의 도구 46개를 모두 포함한 쿼리를 제공했을 때, 컨텍스트가 컨텍스트 윈도우 (context window) 내에 충분히 들어맞음에도 불구하고 모델은 실패했습니다. 하지만 도구를 19개로 줄이자 성공했습니다. Breunig의 표현을 빌리자면, 문제는 이렇습니다: "컨텍스트에 무언가를 넣으면 모델은 반드시 그것에 주의를 기울여야 합니다." 무관한 토큰 (tokens)은 공짜가 아닙니다. 모델은 그것들을 적극적으로 참조합니다.

컨텍스트 충돌 (Context Clash) — 새로운 정보나 도구를 추가했을 때, 그것이 컨텍스트 내의 다른 정보와 충돌하는 현상입니다. 이는 가장 교묘한 실패 모드이며, 아래에서 별도로 살펴볼 Microsoft Research와 Salesforce의 연구에서 가장 엄격하게 다루어졌습니다.

핵심 연구: "대화 속에서 길을 잃다 (getting "lost in conversation")"

컨텍스트 충돌 (Context Clash) 실패 모드는 "LLMs Get Lost in Multi-Turn Conversation" (Microsoft Research 및 Salesforce, 2025년 5월) 논문에서 상세히 기록되었습니다. 이 논문은 실험 설계가 효과를 매우 깔끔하게 분리해냈기 때문에 깊이 살펴볼 가치가 있습니다.

직관은 사람들이 실제로 챗봇을 사용하는 방식에서 시작됩니다. 때로는 완전하고 상세하게 명시된 문단을 입력하고 엔터를 누릅니다. 반면, 때로는 모호한 요청으로 시작하여 모델의 답변이 사용자가 언급하는 것을 잊은 부분을 드러낼 때마다 턴 (turn) 별로 세부 사항을 추가하기도 합니다. 벤치마크는 거의 항상 첫 번째 방식을 테스트하지만, 실제 사용은 두 번째 방식으로 가득 차 있습니다. 그래서 연구진은 **샤딩 (sharding)**이라 불리는 방법을 구축했습니다. 고품질 벤치마크에서 완전한 지시문을 가져와, 각각 원본의 한 조각을 담고 있는 "샤드 (shards)"로 나눈 뒤, 이를 한 턴에 하나씩 공개하여 점진적으로 구체화되는 실제 대화를 시뮬레이션하는 방식입니다. 그런 다음 그들은 _동일한 작업_을 여러 방식으로 전달하여 비교했습니다:

• FULL — 하나의 프롬프트에 전체 지침을 포함하는 방식 (벤치마크의 이상적인 형태).
• SHARDED — 지침을 여러 턴에 걸쳐 분할하여, 한 번에 하나의 조각(shard)씩 공개하는 방식.
• CONCAT — 모든 조각을 다시 하나의 프롬프트로 연결(concatenate)한 방식 (FULL보다는 덜 구체적이지만, 멀티 턴 방식은 아님).
• RECAP — SHARDED 방식에 더해, 마지막 턴에서 이전의 모든 조각을 반복하는 방식.
• SNOWBALL — SHARDED 방식이지만, 각 턴마다 다음 조각을 추가하기 전에 이전의 모든 조각을 다시 언급하는 방식.

6가지 생성 작업(코드, SQL/데이터베이스, 수학, API 액션, 데이터-텍스트 변환, 긴 문서 요약)과 15개 이상의 주요 오픈 웨이트(open-weight) 및 클로즈드 웨이트(closed-weight) 모델을 대상으로 200,000개 이상의 시뮬레이션된 대화를 분석한 결과, 결과는 극명하고 보편적이었습니다:

모든 모델은 FULL과 SHARDED 성능을 비교했을 때, 모든 작업에서 성능이 저하되는 것을 보였으며, 평균 저하율은 -39%였습니다.

동일한 작업에 동일한 정보를 제공했음에도 불구하고, 단지 정보를 한 번에 전달하지 않고 여러 턴에 걸쳐 전달했다는 이유만으로 평균 39%의 성능 하락이 발생했습니다. 플래그십 모델들(논문에서는 Gemini 2.5 Pro 및 GPT-4급 시스템 등을 언급함)조차 비슷한 수준으로 하락했습니다. Breunig이 수치를 인용한 바에 따르면, OpenAI의 o3는 98.1에서 64.1로 떨어졌습니다.

이 발견을 확실하게 만드는 것은 대조군(control condition)입니다. 조각들을 하나의 프롬프트로 재조립한 CONCAT 방식은 FULL 성능의 약 95%까지 회복되었습니다. 이는 명백한 설명 하나를 배제합니다. 즉, 성능 저하는 조각화(sharding)로 인해 정보가 손실되기 때문이 아닙니다 (조각들을 모으면 모든 정보가 포함되어 있습니다). 모델을 망가뜨리는 것은 바로 주고받는 구조(back-and-forth structure) 그 자체입니다.

정보는 모두 그곳에 있었습니다. 정보를 잃어버린 것이 아니라, 여러 턴에 걸쳐 분산시킨 것이 39%의 손실을 초래했습니다.

왜일까요? 저자들은 이 39%의 하락을 두 부분으로 나누었습니다: 적성(aptitude, 최선의 능력)의 미미한 손실과 신뢰성(unreliability)의 큰 증가입니다. 그 메커니즘은 다음과 같습니다:

우리는 LLM이 초기 턴(early turns)에서 종종 가정을 하고, 지나치게 의존하게 될 최종 솔루션을 성급하게 생성하려고 시도한다는 것을 발견했습니다... LLM이 대화 도중 잘못된 방향으로 접어들면, 길을 잃고 회복하지 못합니다.

다시 말해, 모델은 모든 정보를 갖추기도 전에 답변을 확정(commit)해 버리며, 이러한 성급하고 잘못된 시도들은 컨텍스트(context) 내에 남아 이후의 모든 내용을 오염시킵니다. 이것이 가장 순수한 형태의 컨텍스트 충돌(Context Clash)입니다. 즉, 전체적인 그림이 드러났을 때 올바른 경로와 충돌하는 모델 자신의 초기 실수들이 컨텍스트에 포함되어 있는 상태를 의미합니다.

파트 4에서 다룰 에이전트 빌더(agent builders)들에게 주는 시사점은 매우 엄중합니다. 에이전트는 문서, 도구 호출(tool calls), 다른 에이전트의 출력물 등 다양한 소스로부터 컨텍스트를 조립하며, 이렇게 조립된 컨텍스트는 스스로 모순될 모든 가능성을 가지고 있습니다. 에이전트가 더 많은 정보를 수집할수록, 길을 잃을 가능성도 더 커집니다.

얼마나 적은 양으로도 가능한가: "고양이 사실(cat facts)" 공격

다회차 대화(multi-turn) 연구가 모델 자신의 누적된 실수가 모델을 탈선시킨다는 것을 보여주었다면, 더 작고 날카로운 결과는 누군가에 의해 주입된 단 하나의 무관한 문장만으로도 실질적인 피해를 줄 수 있음을 보여주었습니다. Breunig은 후속 연구에서 이를 강조했는데, 그 제목은 기억하기 쉽게 _"고양이 사실이 컨텍스트 혼란을 야기한다(Cat Facts Cause Context Confusion)"_였습니다.