‘컨텍스트 엔지니어링’의 부상
요약
Context engineering은 LLM이 작업을 수행할 수 있도록 필요한 정보, 도구, 지침을 올바른 형식으로 제공하는 동적 시스템 구축 기술입니다. 복잡한 에이전트가 신뢰성 있게 작동하려면 단순히 프롬프트만으로는 부족하며, 이 컨텍스트를 체계적으로 관리하는 것이 핵심입니다.
핵심 포인트
- Context engineering은 정보와 도구를 올바르게 전달하는 '동적 시스템' 구축 과정이다.
- 에이전트의 오작동 원인은 모델 자체보다 적절한 컨텍스트가 부족하기 때문이다.
- LLM에게는 필요한 정보를 제공하고, 작업을 수행할 수 있는 '도구(Tool)'를 함께 제공해야 한다.
- 정보와 도구를 전달하는 '형식(Format)' 또한 결과에 큰 영향을 미친다.
Dex Horthy on Twitter의 헤더 이미지.*
Context engineering은 LLM이 작업을 그럴듯하게 수행할 수 있도록 적절한 정보와 도구를 올바른 형식으로 제공하는 동적 시스템을 구축하는 것입니다.
에이전트가 신뢰성 있게 작동하지 않을 때 대부분 근본적인 원인은 모델에게 적절한 컨텍스트, 지침, 도구가 전달되지 않았기 때문입니다.
LLM 애플리케이션은 단일 프롬프트에서 더 복잡하고 동적인 에이전틱 시스템으로 진화하고 있습니다. 따라서 context engineering은 AI 엔지니어가 개발할 수 있는 가장 중요한 기술이 되고 있습니다.
Context engineering이란 무엇인가?
Context engineering은 LLM이 작업을 그럴듯하게 수행할 수 있도록 적절한 정보와 도구를 올바른 형식으로 제공하는 동적 시스템을 구축하는 것입니다.
이는 Tobi Lutke, Ankur Goyal, 그리고 Walden Yan의 최근 논의를 바탕으로 제가 좋아하는 정의입니다. 이를 자세히 살펴보겠습니다.
Context engineering은 시스템입니다
복잡한 에이전트는 여러 출처에서 컨텍스트를 얻을 가능성이 높습니다. 컨텍스트는 애플리케이션 개발자, 사용자, 이전 상호작용, 도구 호출 또는 기타 외부 데이터에서 올 수 있습니다. 이 모든 것을 모으는 것은 복잡한 시스템을 포함합니다.
이 시스템은 동적입니다
이러한 여러 컨텍스트 조각들은 동적으로 들어올 수 있습니다. 따라서 최종 프롬프트를 구성하는 로직 또한 동적이어야 합니다. 단순히 정적인 프롬프트가 아닙니다.
필요한 정보가 있어야 합니다
에이전틱 시스템이 제대로 작동하지 않는 일반적인 이유는 적절한 컨텍스트를 가지고 있지 않기 때문입니다. LLM은 마음을 읽을 수 없습니다. 올바른 정보를 제공해야 합니다. 쓰레기가 들어가면, 쓰레기가 나옵니다(Garbage in, garbage out).
필요한 도구가 있어야 합니다
필요한 도구가 있어야 합니다
LLM이 입력만으로 항상 작업을 해결할 수 있는 것은 아닐 수 있습니다. 이러한 상황에서 LLM에게 그렇게 할 힘을 주고 싶다면, 적절한 도구를 갖추도록 해야 합니다. 이 도구들은 더 많은 정보를 찾아보거나(look up), 특정 행동을 취하거나(take actions), 그 사이의 어떤 것이든 될 수 있습니다. LLM에 올바른 도구를 제공하는 것은 올바른 정보를 제공하는 것만큼이나 중요합니다.
형식이 중요합니다 (The format matters)
인간과 소통하는 것처럼, LLM과 소통하는 방식도 중요합니다. 짧지만 설명적인 오류 메시지가 방대한 JSON 덩어리보다 훨씬 더 효과적입니다. 이는 도구에도 적용됩니다. LLM이 해당 도구를 사용할 수 있도록 하려면 입력 매개변수(input parameters)가 무엇인지가 매우 중요합니다.
과제를 그럴듯하게 수행할 수 있는가? (Can it plausibly accomplish the task?)
이는 컨텍스트 엔지니어링을 생각할 때 던져야 할 훌륭한 질문입니다. 이는 LLM이 마음을 읽는 존재가 아니며, 성공하도록 설정해 주어야 함을 강조합니다. 또한 실패 모드(failure modes)를 분리하는 데 도움이 됩니다. 잘못된 정보나 도구를 제공하지 않아서 실패하고 있는 것일까요? 아니면 모든 올바른 정보를 가지고 있는데 그냥 실수한 것일까요? 이러한 실패 모드는 고치는 방법이 매우 다릅니다.
컨텍스트 엔지니어링은 왜 중요한가 (Why is context engineering important)
에이전트 시스템(agentic systems)이 잘못 작동하는 것은 주로 LLM이 잘못 작동하기 때문입니다. 제1원칙(first principles)으로 생각해보면, LLM은 두 가지 이유로 오작동할 수 있습니다:
- 근본 모델 자체가 오작동한 경우 (즉, 충분히 좋지 않은 경우)
- 근본 모델에 적절한 컨텍스트가 전달되지 않아 좋은 출력을 만들지 못한 경우
대부분의 경우(특히 모델이 좋아짐에 따라) 모델의 실수는 두 번째 이유로 인해 발생합니다. 모델에 전달되는 컨텍스트는 몇 가지 이유로 나쁠 수 있습니다:
- 모델이 올바른 결정을 내리는 데 필요한 맥락 정보가 누락된 경우. 모델은 마음을 읽지 못합니다. 적절한 컨텍스트를 제공하지 않으면, 그 존재조차 알지 못합니다.
- 컨텍스트의 형식이 부적절한 경우. 인간과 마찬가지로 소통 방식이 중요합니다! 모델에 전달할 때 데이터를 어떻게 형식화(format)하느냐가 응답하는 방식에 절대적인 영향을 미칩니다.
컨텍스트 엔지니어링은 프롬프트 엔지니어링과 어떻게 다른가요?
왜 '프롬프트(prompts)'에서 '컨텍스트(context)'로 초점이 이동했을까요? 초기에는 개발자들이 더 나은 답변을 유도하기 위해 프롬프트를 영리하게 작성하는 데 집중했습니다. 하지만 애플리케이션이 더욱 복잡해지면서, AI에게 완전하고 구조화된 컨텍스트를 제공하는 것이 어떤 마법 같은 문구보다 훨씬 중요하다는 것이 분명해지고 있습니다.
저는 또한 프롬프트 엔지니어링이 컨텍스트 엔지니어링의 하위 집합(subset)이라고 주장하고 싶습니다. 모든 컨텍스트가 있더라도, 그 컨텍스트를 프롬프트에 어떻게 조립하느냐는 여전히 절대적으로 중요합니다. 차이점은 당신이 단일한 입력 데이터 세트와 잘 작동하도록 프롬프트를 설계하는 것이 아니라, 동적인(dynamic) 데이터 세트를 가져와 적절하게 형식화(format)한다는 것입니다.
또한 컨텍스트의 핵심 부분 중 하나는 LLM이 어떻게 행동해야 하는지에 대한 핵심 지침(core instructions)이라는 점을 강조하고 싶습니다. 이것은 종종 프롬프트 엔지니어링의 주요 부분이기도 합니다. 에이전트가 어떻게 행동해야 하는지에 대한 명확하고 상세한 지침을 제공하는 것이 컨텍스트 엔지니어링일까요, 아니면 프롬프트 엔지니어링일까요? 저는 둘 다 약간씩 섞여 있다고 생각합니다.
컨텍스트 엔지니어링의 예시
좋은 컨텍스트 엔지니어링의 기본적인 예시에는 다음이 포함됩니다:
- 도구 사용(Tool use): 에이전트가 외부 정보에 접근해야 할 경우, 이를 접근할 수 있는 도구를 갖추도록 하는 것입니다. 도구가 정보를 반환할 때, LLM에게 최대한 소화하기 쉬운 방식으로 형식화합니다.
- 단기 기억(Short term memory): 대화가 오랫동안 진행되는 경우, 대화의 요약본을 생성하여 미래에 사용하는 것입니다.
- 장기 기억(Long term memory): 사용자가 이전 대화에서 선호도를 표현했다면, 그 정보를 가져올 수 있는 능력입니다.
- 프롬프트 엔지니어링(Prompt Engineering): 에이전트가 어떻게 행동해야 하는지에 대한 지침이 프롬프트에 명확하게 열거됩니다.
- 검색(Retrieval): 정보를 동적으로 가져와 LLM을 호출하기 전에 프롬프트에 삽입하는 것입니다.
LangGraph가 컨텍스트 엔지니어링을 가능하게 하는 방법
LangGraph를 구축했을 때, 가장 제어 가능한 에이전트 프레임워크가 되도록 목표로 삼았습니다. 이는 컨텍스트 엔지니어링을 완벽하게 구현할 수 있도록 합니다.
LangGraph를 사용하면 모든 것을 제어할 수 있습니다. 어떤 단계가 실행될지 결정합니다. LLM에 정확히 무엇이 들어갈지 결정합니다. 출력물을 어디에 저장할지 결정합니다. 모든 것을 통제할 수 있습니다.
이를 통해 원하는 모든 컨텍스트 엔지니어링을 수행할 수 있습니다. 에이전트 추상화(대부분의 다른 에이전트 프레임워크가 강조하는 부분)의 단점 중 하나는 이것이 컨텍스트 엔지니어링을 제한한다는 것입니다. LLM에 들어가는 내용이나 사전에 실행되는 단계들을 정확하게 변경할 수 없는 부분이 있을 수 있습니다.
참고: Dex Horthy의
몇 달 전 저는 "Communication is all you need"라는 블로그를 작성했습니다. 핵심 내용은 LLM에게 소통하는 것이 어렵고, 충분히 인정받지 못하며, 종종 많은 에이전트 오류의 근본 원인이 된다는 것입니다. 이 중 많은 부분이 컨텍스트 엔지니어링과 관련되어 있습니다!
컨텍스트 엔지니어링은 새로운 아이디어는 아닙니다. 에이전트 빌더들은 지난 1~2년 동안 이를 수행해 왔습니다. 이것은 점점 더 중요해지고 있는 기술을 적절하게 설명하는 새로운 용어입니다. 저희는 이 주제에 대해 더 많이 작성하고 공유할 예정입니다. 저희가 구축한 많은 도구들(LangGraph, LangSmith)이 컨텍스트 엔지니어링을 가능하게 하도록 완벽하게 설계되었다고 생각하며, 따라서 이 강조점이 높아지는 것을 기대합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 LangChain Blog의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기