Summary
이 글은 컨텍스트 엔지니어링의 중요성과 LLM(대규모 언어 모델) 애플리케이션에서 이것이 어떻게 작동하는지를 설명합니다. 컨텍스트 엔지니어링은 LLM이 작업을 성공적으로 수행할 수 있도록 적절한 정보와 도구를 올바른 형식으로 제공하는 동적 시스템을 구축하는 것입니다. 이 과정에서 정보의 형식과 도구의 적절성이 중요하며, LLM이 성공적으로 작업을 수행할 수 있도록 설정하는 것이 필요합니다.
헤더 이미지 출처: 트위터의 Dex Horthy.
컨텍스트 엔지니어링은 LLM이 작업을 그럴듯하게 수행할 수 있도록 적절한 정보와 도구를 올바른 형식으로 제공하는 동적 시스템을 구축하는 것입니다.
에이전트가 안정적으로 작동하지 않는 경우, 대부분은 적절한 컨텍스트, 지침 및 도구가 모델에 전달되지 않았기 때문입니다.
LLM 애플리케이션은 단일 프롬프트에서 더 복잡하고 동적인 에이전트 시스템으로 진화하고 있습니다. 따라서 컨텍스트 엔지니어링은 AI 엔지니어가 개발할 수 있는 가장 중요한 기술이 되고 있습니다.
컨텍스트 엔지니어링이란 무엇인가?
컨텍스트 엔지니어링은 LLM이 작업을 그럴듯하게 수행할 수 있도록 적절한 정보와 도구를 올바른 형식으로 제공하는 동적 시스템을 구축하는 것입니다.
이것은 제가 선호하는 정의로, Tobi Lutke, Ankur Goyal, Walden Yan의 최근 견해를 기반으로 합니다. 이를 세부적으로 살펴보겠습니다.
컨텍스트 엔지니어링은 시스템이다
복잡한 에이전트는 여러 소스로부터 컨텍스트를 가져올 가능성이 높습니다. 컨텍스트는 애플리케이션 개발자, 사용자, 이전 상호작용, 도구 호출 또는 기타 외부 데이터로부터 올 수 있습니다. 이 모든 것을 통합하려면 복잡한 시스템이 필요합니다.
이 시스템은 동적이다
이러한 컨텍스트의 많은 부분이 동적으로 들어올 수 있습니다. 따라서 최종 프롬프트를 구성하는 로직도 동적이어야 합니다. 단순히 정적인 프롬프트가 아닙니다.
올바른 정보가 필요하다
에이전트 시스템이 제대로 작동하지 않는 일반적인 이유는 올바른 컨텍스트가 없기 때문입니다. LLM은 마음을 읽을 수 없습니다 - 올바른 정보를 제공해야 합니다. 쓰레기가 들어가면 쓰레기가 나옵니다.
올바른 도구가 필요하다
LLM이 입력만으로 작업을 해결할 수 있는 것은 아닐 수 있습니다. 이러한 상황에서 LLM이 작업을 수행할 수 있도록 권한을 부여하려면 올바른 도구가 있는지 확인해야 합니다. 이러한 도구는 더 많은 정보를 조회하거나, 작업을 수행하거나, 그 사이의 모든 것을 할 수 있는 도구일 수 있습니다. LLM에게 올바른 도구를 제공하는 것은 올바른 정보를 제공하는 것만큼 중요합니다.
형식이 중요하다
사람과의 의사소통처럼 LLM과의 의사소통 방식도 중요합니다. 짧지만 설명적인 오류 메시지가 거대한 JSON 블롭보다 훨씬 더 효과적입니다. 이는 도구에도 적용됩니다. 도구의 입력 매개변수가 무엇인지는 LLM이 해당 도구를 사용할 수 있도록 하는 데 매우 중요합니다.
작업을 그럴듯하게 수행할 수 있는가?
이것은 컨텍스트 엔지니어링을 생각할 때 물어봐야 할 훌륭한 질문입니다. 이는 LLM이 마음을 읽는 존재가 아니라는 것을 강조합니다 - 성공할 수 있도록 설정해야 합니다. 또한 실패 모드를 구분하는 데 도움이 됩니다. 올바른 정보나 도구를 제공하지 않아서 실패하는 것인가요? 아니면 모든 올바른 정보를 가지고 있지만 단순히 실수한 것인가요? 이러한 실패 모드는 해결 방법이 매우 다릅니다.
왜 컨텍스트 엔지니어링이 중요한가
에이전트 시스템이 잘못 작동하는 경우, 대부분은 LLM이 실수했기 때문입니다. 첫 번째 원칙에서 생각해보면, LLM은 두 가지 이유로 실수할 수 있습니다:
- 기본 모델 자체가 실수했고, 충분히 좋지 않다
- 기본 모델에 좋은 출력을 만들기 위한 적절한 컨텍스트가 전달되지 않았다
대부분의 경우 (특히 모델이 개선됨에 따라) 모델의 실수는 두 번째 이유로 인한 것입니다. 모델에 전달된 컨텍스트가 나쁠 수 있는 몇 가지 이유가 있습니다:
- 모델이 올바른 결정을 내리는 데 필요한 컨텍스트가 누락되어 있습니다. 모델은 마음을 읽을 수 없습니다. 올바른 컨텍스트를 제공하지 않으면 그것이 존재하는지 알 수 없습니다.
- 컨텍스트가 제대로 형식화되지 않았습니다. 사람과 마찬가지로 의사소통이 중요합니다! 모델에 데이터를 전달할 때 형식을 어떻게 지정하는지가 모델이 응답하는 방식에 절대적으로 영향을 미칩니다.
컨텍스트 엔지니어링은 프롬프트 엔지니어링과 어떻게 다른가?
왜 “프롬프트”에서 “컨텍스트”로 전환하는 것일까요? 초기에 개발자들은 더 나은 답변을 유도하기 위해 프롬프트를 영리하게 표현하는 데 집중했습니다. 그러나 애플리케이션이 점점 더 복잡해짐에 따라, AI에게 완전하고 구조화된 컨텍스트를 제공하는 것이 어떤 마법 같은 표현보다 훨씬 더 중요하다는 것이 분명해지고 있습니다.
또한 프롬프트 엔지니어링은 컨텍스트 엔지니어링의 하위 집합이라고 주장하고 싶습니다. 모든 컨텍스트를 가지고 있더라도 프롬프트에서 그것을 어떻게 조립하는지는 여전히 절대적으로 중요합니다. 차이점은 단일 입력 데이터 세트와 잘 작동하도록 프롬프트를 설계하는 것이 아니라, 동적 데이터 세트를 가져와서 적절하게 형식을 지정하도록 하는 것입니다.
또한 컨텍스트의 핵심 부분은 종종 LLM이 어떻게 동작해야 하는지에 대한 핵심 지침이라는 점을 강조하고 싶습니다. 이것은 종종 프롬프트 엔지니어링의 핵심 부분입니다. 에이전트가 어떻게 동작해야 하는지에 대한 명확하고 상세한 지침을 제공하는 것이 컨텍스트 엔지니어링인가요, 프롬프트 엔지니어링인가요? 저는 둘 다라고 생각합니다.
컨텍스트 엔지니어링의 예시
좋은 컨텍스트 엔지니어링의 기본 예시는 다음과 같습니다:
- 도구 사용: 에이전트가 외부 정보에 접근해야 하는 경우, 그것에 접근할 수 있는 도구가 있는지 확인합니다. 도구가 정보를 반환할 때, LLM이 최대한 소화하기 쉬운 방식으로 형식화됩니다.
- 단기 메모리: 대화가 오랫동안 진행되는 경우, 대화의 요약을 만들어 향후에 사용합니다.
- 장기 메모리: 사용자가 이전 대화에서 선호도를 표현한 경우, 해당 정보를 가져올 수 있습니다.
- 프롬프트 엔지니어링: 에이전트가 어떻게 동작해야 하는지에 대한 지침이 프롬프트에 명확하게 열거됩니다.
- 검색: 정보를 동적으로 가져와서 LLM을 호출하기 전에 프롬프트에 삽입합니다.
LangGraph가 컨텍스트 엔지니어링을 가능하게 하는 방법
LangGraph를 구축할 때, 가장 제어 가능한 에이전트 프레임워크로 만드는 것을 목표로 구축했습니다. 이를 통해 컨텍스트 엔지니어링을 완벽하게 가능하게 합니다.
LangGraph를 사용하면 모든 것을 제어할 수 있습니다. 어떤 단계가 실행될지 결정합니다. LLM에 정확히 무엇이 들어가는지 결정합니다. 출력을 어디에 저장할지 결정합니다. 모든 것을 제어합니다.
이를 통해 원하는 모든 컨텍스트 엔지니어링을 수행할 수 있습니다. 에이전트 추상화의 단점 중 하나는 (대부분의 다른 에이전트 프레임워크가 강조하는 것) 컨텍스트 엔지니어링을 제한한다는 것입니다. LLM에 정확히 무엇이 들어가는지, 또는 사전에 정확히 어떤 단계가 실행되는지 변경할 수 없는 곳이 있을 수 있습니다.
참고: 매우 좋은 읽을거리는 Dex Horthy의 “12 Factor Agents”입니다. 거기에 있는 많은 포인트가 컨텍스트 엔지니어링과 관련이 있습니다 (“프롬프트를 소유하라”, “컨텍스트 구축을 소유하라” 등). 이 블로그의 헤더 이미지도 Dex로부터 가져왔습니다. 우리는 그가 이 분야에서 중요한 것에 대해 소통하는 방식을 정말 즐깁니다.
LangSmith가 컨텍스트 엔지니어링에 어떻게 도움이 되는가
LangSmith는 우리의 LLM 애플리케이션 관찰성 및 평가 솔루션입니다. LangSmith의 핵심 기능 중 하나는 에이전트 호출을 추적하는 기능입니다. LangSmith를 구축할 때 “컨텍스트 엔지니어링”이라는 용어는 존재하지 않았지만, 이 추적이 도움이 되는 것을 적절하게 설명합니다.
LangSmith를 사용하면 에이전트에서 발생하는 모든 단계를 볼 수 있습니다. 이를 통해 LLM으로 전송된 데이터를 수집하기 위해 어떤 단계가 실행되었는지 확인할 수 있습니다.
LangSmith를 사용하면 LLM에 대한 정확한 입력과 출력을 볼 수 있습니다. 이를 통해 LLM에 정확히 무엇이 들어갔는지 - 가지고 있던 데이터와 그것이 어떻게 형식화되었는지를 볼 수 있습니다. 그런 다음 작업에 필요한 모든 관련 정보가 포함되어 있는지 디버그할 수 있습니다. 여기에는 LLM이 접근할 수 있는 도구도 포함됩니다 - 따라서 당면한 작업을 도울 수 있는 적절한 도구가 제공되었는지 디버그할 수 있습니다.
의사소통이 전부다
몇 달 전 저는 “의사소통이 전부다”라는 블로그를 썼습니다. 주요 요점은 LLM과의 의사소통이 어렵고 충분히 인정받지 못하며, 많은 에이전트 오류의 근본 원인이라는 것이었습니다. 이러한 많은 포인트가 컨텍스트 엔지니어링과 관련이 있습니다!
컨텍스트 엔지니어링은 새로운 아이디어가 아닙니다 - 에이전트 빌더들은 지난 1~2년 동안 이것을 해왔습니다. 이것은 점점 더 중요해지는 기술을 적절하게 설명하는 새로운 용어입니다. 우리는 이 주제에 대해 더 많이 쓰고 공유할 것입니다. 우리가 구축한 많은 도구들(LangGraph, LangSmith)이 컨텍스트 엔지니어링을 가능하게 하도록 완벽하게 구축되었다고 생각하며, 따라서 이에 대한 강조가 본격화되는 것을 보게 되어 기쁩니다.