The rise of \"context engineering\

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

컨텍스트 엔지니어링은 LLM이 과제를 수행할 수 있도록 적절한 정보·지시·도구를 알맞은 형식으로 제공하는 동적 시스템을 설계하는 일이다.

📌 핵심 요약

• LLM 애플리케이션이 단일 프롬프트에서 복잡한 동적 에이전트 시스템으로 발전하면서 컨텍스트 엔지니어링의 중요성이 커지고 있다.
• 저자는 에이전트 오류를 모델 자체의 역량 부족과 적절한 컨텍스트 전달 실패로 구분하며, 모델이 발전할수록 후자가 더 흔한 원인이라고 설명한다.
• 컨텍스트 엔지니어링은 개발자·사용자·이전 상호작용·도구 호출·외부 데이터에서 얻은 정보를 동적으로 결합하고, 필요한 도구와 이해하기 쉬운 형식을 함께 제공한다.
• 프롬프트 엔지니어링은 컨텍스트 엔지니어링의 일부이며, 구체적인 적용 사례에는 도구 사용, 단기 기억, 장기 기억, 행동 지시, 동적 검색이 포함된다.
• LangGraph는 실행 단계·LLM 입력·출력 저장 위치를 제어하도록 지원하고, LangSmith는 실행 추적과 정확한 입출력 확인을 통해 컨텍스트와 도구 제공 상태를 점검하도록 돕는다.

🧩 주요 포인트

1. 모델 역량 부족과 컨텍스트 전달 실패는 서로 다른 오류 유형이므로, 제공된 정보와 도구로 과제를 수행할 수 있었는지가 원인 구분의 기준이 된다.
2. 컨텍스트가 여러 출처에서 동적으로 유입되므로, 설계의 중심은 고정된 문구 최적화에서 정보 수집·조합·형식화로 확장된다.
3. LangGraph의 실행 제어와 LangSmith의 실행 추적은 각각 컨텍스트 구성과 전달 결과 확인을 지원하므로, 설계와 디버깅을 연결한다.

🧠 상세 정리

1. 단일 프롬프트에서 동적 시스템으로의 변화

해리슨 체이스는 LLM 애플리케이션이 단일 프롬프트 중심의 형태에서 복잡하고 동적인 에이전트 시스템으로 발전하고 있다는 변화에서 논의를 시작한다. 이러한 환경에서 에이전트의 신뢰성이 떨어지는 이유는 적절한 컨텍스트와 지시, 도구가 모델에 전달되지 않았기 때문인 경우가 많다는 것이 글의 핵심 문제의식이다. 저자는 과제를 수행하는 데 필요한 정보와 도구를 알맞은 형식으로 제공하는 동적 시스템 구축을 컨텍스트 엔지니어링이라고 정의한다. 이 정의는 개별 문장의 표현뿐 아니라 모델이 실제로 받는 입력과 사용할 수 있는 도구를 함께 다룬다. 따라서 저자는 컨텍스트 엔지니어링을 복잡해지는 에이전트 개발에서 AI 엔지니어가 갖춰야 할 가장 중요한 역량으로 제시한다.

2. 여러 출처의 정보를 결합하는 동적 구조

복잡한 에이전트가 사용하는 컨텍스트는 애플리케이션 개발자, 사용자, 이전 상호작용, 도구 호출, 외부 데이터 등 다양한 출처에서 들어올 수 있다. 저자는 이러한 요소를 하나로 모으는 작업 자체가 복잡한 시스템을 요구하므로 컨텍스트 엔지니어링을 시스템의 문제로 설명한다. 또한 여러 정보가 실행 중에 동적으로 들어오기 때문에 최종 프롬프트를 구성하는 논리도 그 변화에 대응할 수 있어야 한다. 즉, 사전에 작성한 정적 프롬프트만으로 설명할 수 없는 정보 수집과 결합의 과정이 포함된다. 이 관점에서 설계의 대상은 특정 입력 하나에 잘 작동하는 문구를 넘어, 서로 다른 시점과 출처에서 들어오는 데이터를 모델에 전달할 형태로 조합하는 방식으로 넓어진다.

3. 정보·도구·형식을 함께 설계해야 하는 이유

저자는 LLM이 제공받지 않은 정보를 스스로 알아낼 수 없으므로, 올바른 판단에 필요한 컨텍스트를 명시적으로 전달해야 한다고 강조한다. 주어진 입력만으로 과제를 해결할 수 없는 경우에는 추가 정보를 조회하거나 행동을 수행할 수 있는 적절한 도구도 제공해야 한다. 도구를 제공하는 일은 정보를 제공하는 일만큼 중요하며, 도구의 입력 매개변수 역시 모델이 실제로 도구를 사용할 수 있는지에 영향을 준다. 정보의 표현 형식도 중요해서, 저자는 방대한 JSON 덩어리보다 짧지만 설명력이 있는 오류 메시지가 더 유용할 수 있다고 설명한다. 따라서 컨텍스트 엔지니어링은 필요한 자료를 확보하는 데서 끝나지 않고, 그 자료와 도구를 모델이 이해하고 활용할 수 있는 형태로 전달하는 문제까지 포함한다.

4. 실패 원인을 구분하는 판단 기준

저자는 LLM의 실패 원인을 모델 자체가 충분히 뛰어나지 않아 발생한 오류와, 좋은 출력을 만들기에 적절한 컨텍스트를 전달받지 못한 경우로 나눈다. 모델이 발전할수록 후자의 문제가 더 흔한 원인이 된다고 주장하지만, 글에서 이를 뒷받침하는 정량적 비교 결과를 제시하지는 않는다. 전달된 컨텍스트의 문제로는 올바른 결정에 필요한 정보가 빠진 경우와, 정보가 부적절한 형식으로 표현된 경우를 설명한다. 이때 핵심 질문은 현재 제공된 정보와 도구만으로 모델이 해당 과제를 수행할 수 있는 조건이 갖춰졌는지다. 필요한 조건을 주지 못한 실패와 충분한 조건에서도 모델이 실수한 실패는 해결 방법이 다르므로, 이 구분은 오류의 원인과 수정 방향을 판단하는 기준이 된다.

5. 프롬프트 엔지니어링과의 관계

초기에는 개발자들이 프롬프트의 표현을 영리하게 다듬어 더 좋은 답변을 끌어내는 데 집중했지만, 저자는 애플리케이션이 복잡해질수록 완전하고 구조화된 컨텍스트가 더 중요해진다고 설명한다. 그렇다고 프롬프트 엔지니어링의 역할이 사라지는 것은 아니며, 글에서는 이를 컨텍스트 엔지니어링의 하위 영역으로 본다. 필요한 컨텍스트를 모두 확보했더라도 프롬프트 안에서 어떻게 조립하고 표현하는지는 여전히 결과에 영향을 준다. 차이는 단일 입력 데이터에 맞춘 프롬프트를 설계하는 수준에서 다양한 동적 데이터를 적절하게 형식화하는 수준으로 범위가 확장된다는 점이다. 에이전트의 행동을 규정하는 명확하고 상세한 핵심 지시 역시 중요한 컨텍스트이므로, 저자는 이러한 지시 작성이 두 영역에 모두 속한다고 설명한다.

6. 도구·기억·검색으로 구현되는 실제 사례

글은 좋은 컨텍스트 엔지니어링의 사례로 도구 사용, 단기 기억, 장기 기억, 프롬프트 엔지니어링, 검색이라는 다섯 가지 항목을 제시한다. 도구 사용에서는 외부 정보가 필요한 에이전트에 접근 수단을 제공하고, 도구가 반환하는 정보도 LLM이 이해하기 쉬운 형태로 구성하는 것이 중요하다. 단기 기억의 사례는 긴 대화를 요약해 이후에 활용하는 것이며, 장기 기억의 사례는 사용자가 이전 대화에서 표현한 선호를 다시 가져오는 것이다. 프롬프트 엔지니어링은 에이전트의 행동 지시를 명확하게 열거하는 방식으로, 검색은 LLM 호출 전에 정보를 동적으로 가져와 프롬프트에 삽입하는 방식으로 설명된다. 이 사례들은 현재 입력 외에도 과거 대화와 외부 정보를 과제 수행에 필요한 컨텍스트로 연결하는 여러 경로를 보여준다.

7. LangGraph를 통한 컨텍스트 구성 제어

저자는 LangGraph를 개발할 때 에이전트에 대한 높은 제어 가능성을 목표로 삼았으며, 이러한 특성이 컨텍스트 엔지니어링을 지원한다고 설명한다. 개발자는 어떤 단계를 실행할지, LLM에 정확히 무엇을 넣을지, 출력을 어디에 저장할지를 결정할 수 있다. 이는 모델 호출 전에 필요한 처리를 실행하고 최종 입력을 구성하는 과정에 개발자가 관여할 수 있다는 의미다. 반면 저자는 다른 에이전트 프레임워크들이 강조하는 추상화가 LLM 입력이나 사전 실행 단계를 변경하기 어렵게 만들어 컨텍스트 엔지니어링을 제한할 수 있다고 지적한다. 이어 덱스 호시의 에이전트 설계 글을 참고 자료로 소개하며, 프롬프트와 컨텍스트 구성에 대한 직접적인 통제라는 주제가 자신의 논의와 연결된다고 설명한다.

8. LangSmith를 통한 관찰과 소통의 중요성

LangSmith는 LLM 애플리케이션의 관측과 평가를 위한 제품으로 소개되며, 에이전트 호출을 추적하는 기능이 컨텍스트 엔지니어링에 어떻게 기여하는지 설명된다. 개발자는 에이전트의 전체 실행 단계를 확인해 모델에 전달할 데이터를 어떤 과정으로 수집했는지 살펴볼 수 있다. 또한 LLM의 정확한 입력과 출력을 확인함으로써 필요한 정보가 포함됐는지, 데이터 형식이 적절한지, 과제에 필요한 도구가 제공됐는지를 디버깅할 수 있다. 저자는 이전에 쓴 소통에 관한 글을 언급하며, LLM과의 의사소통이 어렵고 과소평가되어 왔으며 많은 에이전트 오류의 원인이라는 문제의식을 다시 연결한다. 결론적으로 컨텍스트 엔지니어링은 완전히 새로운 발명이 아니라 에이전트 개발자들이 지난 1~2년 동안 해 온 작업에 붙은 새로운 이름이며, 그 중요성이 커지고 있다는 것이 글의 주장이다.

🧾 핵심 주장 / 시사점

• 에이전트의 실패를 모델 역량만으로 설명하면 입력 누락과 형식 문제를 놓칠 수 있으므로, 모델이 실제로 받은 조건을 함께 살펴보는 것이 중요하다.
• 컨텍스트 엔지니어링의 설계 단위는 프롬프트 문구에서 정보의 유입 경로, 기억 활용, 도구 접근, 최종 입력 구성으로 확장된다.
• 컨텍스트를 구성할 수 있는 제어 기능과 실제 전달 내용을 확인할 수 있는 추적 기능은 설계 의도와 실행 결과를 연결하는 상호 보완적 역할을 한다.

✅ 액션 아이템

• 에이전트 오류를 모델 역량 부족과 컨텍스트 전달 실패로 나누어 원인 확인.
• 동적으로 유입되는 정보의 수집·조합·형식화와 필요한 도구의 제공 여부 점검.
• LangGraph의 실행 제어와 LangSmith의 실행 추적을 활용해 컨텍스트 구성과 실제 전달 결과 확인.

❓ 열린 질문

• 에이전트 오류가 모델 역량 부족에서 비롯됐는지, 컨텍스트 전달 실패에서 비롯됐는지 구분할 수 있는가?
• 여러 출처에서 동적으로 유입되는 정보와 필요한 도구가 LLM이 활용하기 쉬운 형식으로 전달되고 있는가?
• LangGraph로 구성한 실행 단계와 LLM 입력이 LangSmith의 실행 추적에서 의도대로 확인되는가?