개념
컨텍스트 엔지니어링(context engineering)은 모델에게 보내는 컨텍스트 윈도우 안에 무엇을 담고 무엇을 뺄지, 어떤 순서로 배치할지를 설계하는 작업이다. 실제 요청에는 시스템 프롬프트, 사용자의 질문, 이전 대화, 검색해 온 문서, 도구의 정의와 실행 결과, 저장해 둔 메모가 함께 들어간다. 이 구성 전체를 다루는 관점이 컨텍스트 엔지니어링이다.
프롬프트 엔지니어링과 자주 겹쳐 쓰이지만 초점이 다르다. 프롬프트 엔지니어링이 지시문을 어떻게 쓸 것인가에 무게를 둔다면, 컨텍스트 엔지니어링은 그 지시문을 포함해 어떤 정보를 어느 시점에 어느 정도 실어 보낼 것인가를 다룬다. 에이전트처럼 여러 단계를 거치며 정보가 계속 쌓이는 구조에서는 후자가 훨씬 큰 변수가 된다.
문제의 핵심은 넣을 자리가 유한하다는 것이다. 창이 커졌다 해도 관계없는 내용이 많이 섞이면 정작 중요한 문장이 묻혀 정확도가 떨어지고, 매 요청 토큰 비용도 함께 늘어난다. 그래서 무엇을 넣을지만큼이나 무엇을 버릴지가 설계의 절반을 차지한다.
또 하나 짚어 둘 점은 문맥이 한 번 짜고 끝나는 것이 아니라 요청마다 다시 조립된다는 것이다. 어떤 정보를 항상 넣을지, 어떤 정보를 조건에 따라 넣을지, 무엇을 어느 자리에 놓을지를 규칙으로 정해 두면 그 규칙 자체가 시스템의 설계도 역할을 한다. 이 부분이 정리되어 있지 않으면 답변 품질이 왜 들쭉날쭉한지 설명할 근거도 남지 않는다.
쓰임새
실무에서 다루는 수단은 대체로 네 가지다. 필요한 문서만 골라 넣는 검색, 즉 RAG와, 길어진 대화를 압축해 남기는 요약, 세션을 넘어 유지할 정보를 따로 저장했다가 필요할 때 불러오는 메모리, 그리고 오래된 내용을 잘라 내는 정리다.
에이전틱 워크플로에서는 이 작업이 특히 중요해진다. 도구 실행 결과가 매 단계 누적되면 문맥은 금세 불어나는데, 그중 대부분은 다음 단계에 필요 없는 중간 산출물이다. 단계별로 무엇을 요약해 남기고 무엇을 버릴지 정해 두지 않으면 작업이 길어질수록 답변 품질이 서서히 무너진다.
배치 순서도 신경 쓸 부분이다. 문맥이 길어지면 가운데 놓인 내용이 앞이나 뒤에 놓인 내용보다 덜 반영되는 경향이 여러 곳에서 관찰되어 왔다. 그래서 반드시 지켜야 할 규칙이나 핵심 근거는 앞뒤 끝에 배치하고, 부피가 큰 참고 자료는 가운데에 두는 구성이 흔히 쓰인다.
자주 하는 오해
컨텍스트 윈도우가 커지면 필요 없어지는 일 아닌가?
창이 커질수록 무엇을 넣을지 고르는 판단이 더 중요해진다. 넣을 수 있는 양과 모델이 제대로 활용하는 양은 별개다.
컨텍스트 엔지니어링은 프롬프트 엔지니어링을 대체하는 새 이름 아닌가?
두 관점은 다루는 범위가 다르다. 지시문을 잘 쓰는 일은 그대로 필요하고, 그 바깥의 정보 구성을 함께 설계하는 관점이 더해진 것이다.
관련 있어 보이면 일단 넣는 편이 안전하지 않나?
애매하게 관련된 문서가 오히려 잘못된 근거로 인용되기도 한다. 특히 오래된 버전의 문서나 폐기된 규정이 함께 들어가면, 모델은 그것이 최신인지 판단할 방법이 없어 그대로 인용한다. 확실히 필요한 것만 넣는 편이 낫다.