LLM이 작업을 그럴듯하게 수행할 수 있도록 적절한 정보와 도구를 적절한 형식으로 제공하는 동적 시스템을 구축하는 ‘컨텍스트 엔지니어링’의 개념과 중요성, 프롬프트 엔지니어링과의 차이, 그리고 LangGraph·LangSmith가 이를 어떻게 지원하는지 살펴본다.
URL: https://blog.langchain.com/the-rise-of-context-engineering/
헤더 이미지 출처: Twitter의 Dex Horthy .
컨텍스트 엔지니어링이란, LLM이 작업을 그럴듯하게 수행할 수 있도록 올바른 정보와 도구를 올바른 형식으로 제공하는 동적 시스템을 구축하는 일이다.
대부분의 경우 에이전트가 안정적으로 동작하지 않는 근본 원인은, 적절한 컨텍스트·지침·도구가 모델에 전달되지 않았기 때문이다.
LLM 애플리케이션은 단일 프롬프트에서 더 복잡하고 동적인 에이전트형(Agentic) 시스템으로 진화하고 있다. 그에 따라 컨텍스트 엔지니어링은 AI 엔지니어가 개발할 수 있는 가장 중요한 기술이 되어가고 있다.
컨텍스트 엔지니어링이란, LLM이 작업을 그럴듯하게 수행할 수 있도록 올바른 정보와 도구를 올바른 형식으로 제공하는 동적 시스템을 구축하는 일이다.
이 정의는 Tobi Lutke, Ankur Goyal, Walden Yan의 최근 관점을 바탕으로 내가 선호하는 방식으로 정리한 것이다. 하나씩 풀어보자.
컨텍스트 엔지니어링은 ‘시스템’이다
복잡한 에이전트는 여러 소스에서 컨텍스트를 얻는 경우가 많다. 컨텍스트는 애플리케이션 개발자, 사용자, 이전 상호작용, 도구 호출, 또는 기타 외부 데이터에서 올 수 있다. 이를 모두 모아 최종 프롬프트를 구성하려면 복잡한 시스템이 필요하다.
이 시스템은 ‘동적’이다
이 컨텍스트 조각들 중 상당수는 동적으로 들어올 수 있다. 따라서 최종 프롬프트를 구성하는 로직 역시 동적이어야 한다. 단순한 정적 프롬프트가 아니다.
‘올바른 정보’가 필요하다
에이전트형 시스템이 성능을 못 내는 흔한 이유는, 필요한 컨텍스트를 갖고 있지 않기 때문이다. LLM은 마음을 읽지 못한다. 올바른 정보를 제공해야 한다. 입력이 쓰레기면 출력도 쓰레기다(garbage in, garbage out).
‘올바른 도구’가 필요하다
LLM이 입력만으로 항상 작업을 해결할 수 있는 것은 아니다. 이런 상황에서 LLM이 작업을 수행하도록 권한을 부여하려면, 적절한 도구를 갖추게 해야 한다. 더 많은 정보를 조회하는 도구, 어떤 행동을 수행하는 도구 등 무엇이든 될 수 있다. LLM에 올바른 도구를 제공하는 것은 올바른 정보를 제공하는 것만큼 중요하다.
형식(format)이 중요하다
사람과의 커뮤니케이션과 마찬가지로, LLM과의 커뮤니케이션도 방식이 중요하다. 짧지만 설명적인 오류 메시지 하나가 거대한 JSON 덩어리보다 훨씬 도움이 될 수 있다. 도구에도 똑같이 적용된다. 도구의 입력 파라미터가 무엇인지(어떤 형태인지)는 LLM이 이를 제대로 사용할 수 있게 만드는 데 큰 영향을 준다.
‘그럴듯하게 작업을 달성할 수 있는가?’
컨텍스트 엔지니어링을 고민할 때 이 질문은 매우 유용하다. 이는 LLM이 마음을 읽지 못한다는 점을 다시 상기시켜 주며, 성공 가능성을 높이도록 환경을 세팅해야 함을 강조한다. 또한 실패 모드를 분리하는 데도 도움이 된다. 올바른 정보나 도구를 제공하지 않았기 때문에 실패한 것인가? 아니면 필요한 정보는 다 있었는데도 모델이 그냥 실수한 것인가? 이 둘은 해결책이 매우 다르다.
에이전트형 시스템이 망가질 때, 대부분은 LLM이 실수했기 때문이다. 1원칙(First principles)로 생각해 보면, LLM이 실수하는 이유는 두 가지뿐이다.
대개(특히 모델이 좋아질수록) 모델의 실수는 2번 이유에서 비롯되는 경우가 더 많다. 모델에 전달된 컨텍스트가 나쁜 이유는 몇 가지가 있다.
왜 “프롬프트”에서 “컨텍스트”로 옮겨가고 있을까? 초기에는 개발자들이 더 좋은 답을 끌어내기 위해 프롬프트 문구를 영리하게 다듬는 데 집중했다. 하지만 애플리케이션이 복잡해질수록, 마법 같은 문구보다 완전하고 구조화된 컨텍스트를 제공하는 것이 AI에 훨씬 중요하다는 점이 분명해지고 있다.
또한 프롬프트 엔지니어링은 컨텍스트 엔지니어링의 부분집합이라고도 주장할 수 있다. 모든 컨텍스트가 갖춰져 있더라도, 그것을 프롬프트에서 어떻게 조립하느냐는 여전히 매우 중요하다. 차이는, 하나의 고정된 입력 데이터 세트에 맞춰 프롬프트를 설계하는 것이 아니라, 동적인 데이터 집합을 적절히 포맷해 전달하도록 프롬프트를 설계한다는 데 있다.
더불어 컨텍스트의 핵심 요소 중 하나는 종종 LLM이 어떻게 행동해야 하는지에 대한 핵심 지침이다. 이는 프롬프트 엔지니어링의 핵심 영역이기도 하다. 에이전트가 어떻게 행동해야 하는지에 대한 명확하고 상세한 지침을 제공하는 일을 컨텍스트 엔지니어링이라 해야 할까, 프롬프트 엔지니어링이라 해야 할까? 둘 다에 걸쳐 있다고 본다.
좋은 컨텍스트 엔지니어링의 기본 예시는 다음과 같다.
우리가 LangGraph를 만들 때 목표는, 가장 제어 가능한 에이전트 프레임워크를 만드는 것이었다. 이는 컨텍스트 엔지니어링을 완벽하게 가능하게 해준다.
LangGraph에서는 모든 것을 제어할 수 있다. 어떤 단계(step)를 실행할지 결정한다. LLM에 무엇을 넣을지 정확히 결정한다. 출력물을 어디에 저장할지도 결정한다. 모든 것을 통제한다.
이는 원하는 만큼의 컨텍스트 엔지니어링을 수행할 수 있게 해준다. (대부분의 다른 에이전트 프레임워크가 강조하는) 에이전트 추상화의 단점 중 하나는 컨텍스트 엔지니어링을 제한한다는 점이다. LLM에 정확히 무엇이 들어가는지, 이전에 어떤 단계가 실행되는지 등을 바꿀 수 없는 지점들이 생길 수 있다.
참고: Dex Horthy의 “12 Factor Agents”는 매우 좋은 글이다. 많은 포인트가 컨텍스트 엔지니어링(“own your prompts”, “own your context building” 등)과 관련되어 있다. 이 블로그의 헤더 이미지도 Dex에게서 가져왔다. 우리는 그가 이 분야에서 무엇이 중요한지를 전달하는 방식이 정말 마음에 든다.
LangSmith는 LLM 애플리케이션을 위한 관측 가능성(observability) 및 평가(evals) 솔루션이다. LangSmith의 핵심 기능 중 하나는 에이전트 호출을 트레이싱(trace)하는 기능이다. LangSmith를 만들 당시에는 “컨텍스트 엔지니어링”이라는 용어가 존재하지 않았지만, 이 트레이싱 기능이 실제로 돕는 바를 정확히 설명해 주는 표현이다.
LangSmith는 에이전트에서 일어나는 모든 단계를 볼 수 있게 해준다. 이를 통해 LLM에 전달된 데이터를 모으기 위해 어떤 단계들이 실행되었는지 확인할 수 있다.
LangSmith는 LLM의 정확한 입력과 출력을 볼 수 있게 해준다. 즉, LLM에 무엇이 들어갔는지—모델이 어떤 데이터를 가졌고 그것이 어떻게 포맷되었는지—를 정확히 볼 수 있다. 그리고 그 안에 작업에 필요한 모든 관련 정보가 포함되어 있는지 디버깅할 수 있다. 여기에는 LLM이 접근 가능한 도구도 포함되므로, 해당 작업을 돕기 위한 적절한 도구가 제공되었는지도 디버깅할 수 있다.
몇 달 전 나는 “Communication is all you need”라는 글을 썼다. 핵심은 LLM과 커뮤니케이션하는 것이 어렵고, 그 중요성이 충분히 인정받지 못하며, 많은 에이전트 오류의 근본 원인이 되곤 한다는 것이었다. 이 포인트들 상당수는 컨텍스트 엔지니어링과 관련이 있다.
컨텍스트 엔지니어링은 새로운 아이디어가 아니다. 에이전트 빌더들은 지난 1~2년간 이를 해왔다. 다만 점점 더 중요해지는 기술을 정확히 설명하는 새로운 용어가 생긴 것이다. 우리는 이 주제에 대해 더 많이 쓰고 공유할 예정이다. 우리가 만든 많은 도구(LangGraph, LangSmith)가 컨텍스트 엔지니어링을 가능하게 하도록 완벽히 설계되었다고 믿으며, 이 관점에 대한 강조가 본격적으로 확산되는 것이 기대된다.
LangChain 팀과 커뮤니티의 업데이트
이메일을 입력하세요
신청을 처리 중...
성공! 받은편지함을 확인하고 링크를 클릭해 구독을 확인하세요.
죄송합니다. 문제가 발생했습니다. 다시 시도해 주세요.
