Why “Context Engineering” Matters

https://www.dbreunig.com/2025/07/24/why-the-term-context-engineering-matters.html

지난 밤, 저는 Lance Martin과 함께 LangChain이 주최한 행사에서 발표를 했습니다. 이 기회를 통해 “컨텍스트 엔지니어링(context engineering)”이라는 용어가 단순히 남아 있는 것이 아니라, 새로운 분야, 문화, 커뮤니티의 등장을 알리는 신호임을 주장했습니다.

발표 준비에 하루밖에 없어서 조금 긴장했지만(아무도 컨텍스트 실패와 해결책을 다시 들을 필요는 없다고 생각했죠), 결과에 매우 만족했습니다. Harrison, Lance, 그리고 LangChain 팀 모두 훌륭한 행사를 열어주었습니다. 30분간의 발표 후, Lance와 저는 건물에서 쫓겨날 때까지 2시간 동안 질문에 답했습니다.

컨텍스트 엔지니어링의 필요성
…그리고 그 이유

“컨텍스트 엔지니어링”이라는 용어가 등장했을 때, Karpathy가 이를 공식화한 이후, 꽤 많은 반발이 있었습니다. “또 하나의 마케팅 용어”라고 말하는 사람도 있었고, 한 HN 댓글러는 “한 달짜리 기술, 곧 사라질 것”이라고 했습니다.

저는 그렇게 생각하지 않습니다. 이번 발표에서 저는 “컨텍스트 엔지니어링”이 단순히 남아 있는 것이 아니라, 이 용어의 등장이 분야, 문화, 커뮤니티의 발전을 가속화할 것임을 주장할 것입니다.

“미래가 만들어지는 곳을 알고 싶다면, 새로운 언어가 탄생하고 변호사들이 모이는 곳을 찾아라.”
– 스튜어트 브랜디

이 인용구는 제가 가장 좋아하는 것일지도 모릅니다. 이 인용구를 언급할 때마다 심슨 가족의 한 장면이 떠오릅니다: “표지판을 두드리게 하지 마.”

하지만 이 인용구는 AI에서 자주 등장합니다.

우리가 사용하는 언어는 세상을 이해하는 프레임워크입니다. 언어는 단순히 현실을 묘사하는 것이 아니라, 현실을 정의합니다.최소한, 다른 사람들과 나눌 수 있는 대화의 한계를 설정합니다. 우리가 알고 있는 단어와 우리가 가진 단어는 우리가 이해할 수 있는 것의 경계를 정합니다.

유행어를 만드는 방법

1. 식별하기: 사람들이 직관적으로 이해하지만 명확하게 표현하기 어려워하는 공통된 경험을 찾아라.
2. 만들기: 그 경험을 포착할 수 있는 명확하고 인상적인 언어로 용어를 만들어라.
3. 퍼뜨리기: 새로운 용어를 표현력이 풍부하고 사회적으로 연결된 커뮤니티에 도입하여 사용과 공유를 장려하라.

성공적인 유행어(buzzword)는 허공에서 만들어지는 것이 아닙니다. 오히려 모두가 경험하고 공감할 수 있는 공통된 경험을 식별합니다. 이러한 경험에 이름을 붙이면, 그 생각과 경험이 구체화되고 공동체적이 됩니다. 이것이 유행어의 힘입니다. 그리고 이런 것들이 명확해지면, 커뮤니티를 만들고, 문화를 변화시키며, 우리의 작업에 영향을 줍니다.

_Context engineering_은 이러한 패턴의 전형적인 예입니다.

컨텍스트 엔지니어링은 성공적인 유행어입니다. 왜냐하면 이 방에 있는 모든 사람이 처음 프롬프트 엔지니어링(prompt engineering)을 이야기하기 시작했을 때와는 다른 방향으로 나아가고 있음을 경험하고 있기 때문입니다.

처음 컨텍스트를 다루던 경험은 대화형이었고, 한두 번의 LLM 상호작용을 다듬는 것이었습니다. 하지만 우리가 더 견고한 에이전트와 애플리케이션을 구축하고, 새로운 모범 사례를 개발하면서, 우리는 챗봇 사용 전략을 개발한 마케터, 임원, 기타 비기술적 사용자들과 점점 멀어졌습니다.

그리고 저는 마케터를 사랑하는 마음으로 이 말을 합니다(기술 업계는 마케팅을 너무 과소평가하죠!). “프롬프트 엔지니어링”과 “컨텍스트 엔지니어링”은 단순히 다른 것입니다. 어느 것이 본질적으로 더 낫다고 할 수 없습니다.

어떻게 여기까지 왔는가?

• 모델 개발자들과 생태계 전체가 더 긴 컨텍스트가 필수적이라고 믿었지만, 실제로는 여러 어려움이 있다는 것을 실무자들이 깨달았다.
• 전문성과 도구가 성숙해지면서 이전의 프롬프트 편집 방식과는 다른 길로 나아가게 되었다.
  • 도구 개발: 도구 사용이 증가했고, 함수 호출과 MCP(Model Control Protocols)가 부상했다.
  • 챗봇 개발: 시스템 프롬프트 사용이 더 프로그래밍적으로 변했고, Claude와 ChatGPT 같은 챗봇 개발 주기가 공식화되었다.
  • 에이전트 개발: 에이전트가 인기를 얻으며 구조화된 프롬프트 방식이 발전했고, 초기에는 “정보 관리”로 불렸으며, “Preempt by Cursor”가 언급되었다.

프롬프트 엔지니어링에서 시작한 곳에서 멀어진 이유는 몇 가지가 있습니다.

첫째, 대형 모델 개발자들이 2024년 내내 컨텍스트 윈도우 경쟁에 몰두하는 동안, 이 모델을 사용하는 개발자들은 거대한 컨텍스트 윈도우가 우리의 문제를 해결해주지 않는다는 것을 깨달았습니다. 큰 컨텍스트는 공짜 점심이 아닙니다. 그래서 우리는 우리가 약속한 애플리케이션을 제공하기 위해, 작동하게 만들기 위한 전술과 기법을 개발했습니다.

그 과정에서 우리는 배우고 성숙해졌습니다. 도구를 다루고 설계하는 방법을 배웠습니다. 챗봇을 모델과 직접 상호작용하는 인터페이스에서 대규모 애플리케이션으로 발전시켰고, 에이전트 구축 디자인 패턴이 등장했습니다.

이 모든 과정의 핵심은 우리 모두가, 각자이면서 동시에, _결과를 얻기 위해 컨텍스트를 체계적으로 설계하는 방법_을 알아내고 있었다는 점입니다.

프롬프트의 선물과 저주 (프롬프트를 사용하면 누구나 작업을 빠르게 설명할 수 있다…)

저는 Databricks의 Data+AI Summit에서 이 슬라이드를 보여줬고, 방 안의 모든 사람들이 고개를 끄덕이는 것을 봤습니다. 자연어로 프롬프트를 작성하는 것은 오늘날 가장 흥미로운 혁신 중 하나지만, 아무도 그것이 쉽거나, 유지보수 가능하거나, 견고하다고 주장하지 않을 것입니다. 우리는 모두 이 고통을 알고 있습니다 – 그리고 “컨텍스트 엔지니어링”이라는 용어가 등장하면서 그 고통이 명확해졌습니다.

“컨텍스트 엔지니어링”은 빠르게 성장했습니다. 한 달 만에 “프롬프트 엔지니어링” 검색량의 4분의 1을 넘었습니다. 그리고 앞으로 더 성장할 것으로 기대합니다. 그 지속적이고 상승하는 추세는 여기 잠재적 이해가 있었음을 보여줍니다. 마케팅 유행어라면 급등했다가 곧 사라졌을 것입니다. 하지만 여기서는 이미 진행 중인 작업을 조직화하는 역할을 하고 있습니다.

컨텍스트가 실패하는 방식…

1. 컨텍스트 오염: 환각(hallucination)이 컨텍스트에 포함될 때
2. 컨텍스트 산만: 컨텍스트가 학습을 압도할 때
3. 컨텍스트 충돌: 컨텍스트의 일부가 서로 상충할 때
4. 컨텍스트 혼란: 불필요한 컨텍스트가 응답에 영향을 줄 때

…그리고 이를 해결하는 방법

1. RAG: LLM을 돕기 위해 관련 정보를 추가한다.
2. 컨텍스트 격리: 하위 작업의 컨텍스트를 별도의 스레드로 분리한다.
3. 컨텍스트 요약: 누적된 컨텍스트를 요약한다.
4. 도구 로드아웃: 관련 도구 정의만 선택한다.
5. 컨텍스트 가지치기: 불필요하거나 관련 없는 정보를 제거한다.
6. 컨텍스트 오프로딩: 정보를 LLM의 컨텍스트 외부에 저장한다.

그리고 이것이 중요한 점입니다: 우리는 모두 이 분야에서 이미 일하고 있었지만, 이름이 없었습니다. 제가 컨텍스트 실패와 해결책에 대해 쓴 글들은 이미 연구 논문 바다에 있던 아이디어와 접근법을 정리한 것뿐입니다.

하지만(그리고 이것이 제가 컨텍스트 엔지니어링이 다른 유행어보다 더 실질적이라고 생각하는 또 다른 이유입니다) 사람들이 즉시 이 용어를 자신이 경험한 것을 설명하는 데 사용하기 시작했다는 점이 재미있었습니다. Lance도 마찬가지였고, 곧 이에 대해 이야기할 것입니다.

합의된 언어가 있으면 모든 것이 가속화됩니다. 항상 _무엇_에 대해 이야기하는지 먼저 기준을 세울 필요가 없습니다.

그렇다면 “컨텍스트 엔지니어링”이라는 용어의 등장이 실제로 무언가를 바꾸는 것일까요? 정말 중요한 걸까요?

저는 그렇다고 생각합니다. 이 용어 덕분에 우리는 서로를 알아보고, 공통의 지형을 갖게 되며, 앞으로 나아가기 시작할 수 있습니다. 그리고 이것이 변화와 가속을 가져올 것입니다.

이제 예측은 어리석은 짓입니다. 다음 슬라이드는 큰 의심을 가지고 봐주시길 바랍니다. 하지만 앞으로 몇 달 동안 컨텍스트 엔지니어링에 집중하면 변화할 것이라고 생각하는 몇 가지를 소개합니다.

그래서 무엇이 달라지는가? ‘컨텍스트 엔지니어링’이 실제로 무언가를 바꾸는가?

• 대부분의 사람들에게 에이전트와 모델의 경계가 흐려질 것이다. “o3와 Sonnet은 묻지 않고 검색한다”는 점, 그리고 “Grok 4 Heavy”가 챗봇처럼 보이지만 실제로는 멀티 에이전트 파이프라인이라는 점이 언급된다. 동료와 고객을 포함한 이해관계자들은 점점 더 에이전트적 행동을 기대하게 될 것이다.
• 컨텍스트 엔지니어들 사이에서 하나의 문화가 등장하고 굳어질 것이다. Cognition의 “우리는 아직 React 시대가 아니라 HTML 시대에 있다”는 언급처럼, 개발자들은 여전히 웹의 기초적인 표준을 다루고 있다. 각 개발자는 전체 스택을 직접 탐색하며, 구축하면서 모범 사례를 스스로 찾아내고, 많은 작업이 ‘덕트 테이프’로 겨우 이어져 있다. 무언가에 이름을 붙이면, 그 주위로 조직과 문화가 형성된다.

• 현재 비즈니스의 요구가 이 커뮤니티를 성장시킬 것이다. 대기업들이 “현장 배치 엔지니어(forward deployed engineers)”를 필요로 하는데, 이는 고객들이 AI를 어떻게 활용해야 하는지 잘 모르기 때문이다. 이러한 수요가 자금과 관심을 바탕으로 문화를 만들어낼 것이며, 컨텍스트 엔지니어 관련 콘텐츠, 컨퍼런스, 채용 공고 등이 생겨날 것이다.
• ‘골디락스(Goldilocks)’ 프레임워크가 필수적이 될 것이다. 현재의 컨텍스트 엔지니어링은 대부분 프로토타입을 만드는 개인의 경험에 의존하고 있다. 앞으로는 이러한 관행이 LangChain, DSPy와 같은 도구로 공식화되어, 모델 선택, 최적화, 프롬프트 기법을 추상화하는 데 도움이 될 것이다. 이러한 과정을 쉽게 해주는 프레임워크가 필요하며, 미래의 발전을 방해하지 않도록 주의해야 한다(‘The Bitter Lesson’ 참고).

• 에이전트가 성숙해짐에 따라 모델을 전문화하고 최적화하게 될 것이다. 우리의 업무가 (적당히!) 구조화되면, 가장 큰 모델이 아니라 적합한 모델에 작업을 할당할 수 있다. Anthropic의 Deep Researcher는 Opus로 조율하고, Sonnet을 정보 수집에 활용한다. Osmosis의 구조화 데이터 추출기, ART•E의 이메일 리서치 모델, Menlo의 MCP에 최적화된 Jan이나 검색에 최적화된 Lucy처럼, 일반적인 작업을 위한 특화 모델들이 등장할 것이다. 이로 인해 비(非) 프런티어 연구소에서도 더 작고, 빠르고, 효율적이며, 차별화된 모델을 개발할 수 있는 공간이 생길 것이다.

1. 대부분의 사람들에게 에이전트와 모델의 경계가 흐려질 것이다.
2. 컨텍스트 엔지니어들 사이에서 하나의 문화가 등장하고 굳어질 것이다.
3. 이 문화는 공개적으로, 그리고 이면에서 함께 발전할 것이다.
4. ‘골디락스(Goldilocks)’ 프레임워크가 필수적이 될 것이다.
5. 에이전트가 성숙해짐에 따라 모델을 전문화하고 최적화하게 될 것이다.

저는 여러분이 컨텍스트 엔지니어링 이 단순한 유행어가 아니라, 새로운 분야, 커뮤니티, 문화의 등장이며, 앞으로 수년간 크게 성장할 것임을 납득하셨길 바랍니다. 모델의 성능이 두 배로 향상되거나, 컨텍스트 윈도우의 모든 토큰을 활용할 수 있게 되더라도, 여기 있는 사람들이 결과를 얻기 위해 컨텍스트를 체계적으로 설계하는 일 을 계속할 것이라고 확신합니다. 이것은 사라지지 않을 것입니다.

그리고 여러분이 기대감을 느끼셨길 바랍니다. 이런 집단적 깨달음은 경력에서 드물게 찾아옵니다. 그리고 여러분은 이 새로운 흐름을 함께 만들어갈 수 있습니다.