한 줄 요약
컨텍스트 엔지니어링은 에이전트가 필요한 정보를 적절한 시점에 가져오고, 버리고, 압축하며, 충돌 없이 활용하도록 설계하는 동적 시스템 설계다.1
핵심 개념
AI 에이전트의 성능은 모델 자체의 능력만으로 결정되지 않는다. 같은 모델을 써도 어떤 정보를 넣어 주는지, 그 정보가 얼마나 최신인지, 서로 충돌하지 않는지, 작업 단계에 맞게 정리되어 있는지에 따라 결과가 크게 달라진다.
여기서 말하는 컨텍스트는 단순히 사용자가 입력한 문장만 뜻하지 않는다. 시스템 메시지, 규칙, 참고 지식, 도구 사용법, 이전 대화, 사용자 취향, 임시 추론 과정까지 모델이 현재 판단에 참고하는 모든 정보가 컨텍스트다.
중요한 점은 컨텍스트 윈도우가 무한하지 않다는 것이다. 영상에서는 이를 제한된 장바구니처럼 볼 수 있다. 장바구니에 모든 물건을 담을 수 없듯, 에이전트도 모든 정보를 한꺼번에 들고 갈 수 없다. 게다가 모든 정보는 토큰 비용을 만든다. 따라서 좋은 에이전트는 "많이 기억하는 에이전트"가 아니라 "필요한 것을 필요한 때에 기억하는 에이전트"에 가깝다.
프롬프트 엔지니어링과 컨텍스트 엔지니어링의 차이
프롬프트 엔지니어링은 주로 모델에게 어떤 방식으로 답해야 하는지 알려 주는 정적인 지침 설계에 가깝다. 예를 들어 "친절하게 답하라", "전문가처럼 설명하라", "JSON 형식으로 출력하라" 같은 지시가 여기에 속한다.
반면 컨텍스트 엔지니어링은 시간에 따라 변하는 정보를 어떻게 관리할지 설계하는 일이다. 사용자의 새 요청, 이전 대화, 검색된 문서, 데이터베이스 결과, 도구 호출 결과, 사용자 선호도는 계속 바뀐다. 컨텍스트 엔지니어링은 이 변화하는 정보들 중 무엇을 현재 작업에 넣을지, 무엇을 제외할지, 언제 요약할지, 어떤 저장소에 남길지를 결정한다.
즉 프롬프트 엔지니어링이 "모델에게 어떻게 말할 것인가"의 문제라면, 컨텍스트 엔지니어링은 "모델이 무엇을 알고 판단하게 할 것인가"의 문제다. 비즈니스 에이전트에서는 후자가 특히 중요하다. 단순한 말솜씨보다 정확한 정보 선택과 흐름 관리가 신뢰성을 좌우하기 때문이다.
에이전트가 관리해야 할 컨텍스트 5가지
지침
지침은 에이전트의 행동 기준이다. 시스템 메시지, 역할 정의, 규칙, 출력 형식, 금지 사항, 퓨샷 예제가 여기에 포함된다.
예를 들어 여행 예약 에이전트라면 "사용자의 예산을 초과하지 않는다", "예약 전 반드시 확인 질문을 한다", "항공권과 호텔 조건을 분리해서 비교한다" 같은 규칙이 필요하다. 이런 지침은 에이전트가 매번 일관된 기준으로 행동하게 만든다.
하지만 지침이 너무 많거나 서로 충돌하면 오히려 문제가 된다. "짧게 답하라"와 "모든 근거를 자세히 설명하라"가 동시에 들어가면 모델은 어느 쪽을 우선해야 할지 흔들릴 수 있다. 따라서 지침은 명확하고 우선순위가 있어야 한다.
지식
지식은 에이전트가 문제를 해결하기 위해 참고하는 외부 정보다. RAG로 가져온 문서, 데이터베이스 조회 결과, 외부 웹 정보, 장기 기억에 저장된 정보가 여기에 해당한다.
중요한 것은 모든 지식을 항상 넣는 것이 아니라, 현재 질문과 관련 있는 지식만 골라 넣는 것이다. 관련 없는 문서가 섞이면 모델은 엉뚱한 근거를 사용할 수 있다. 반대로 필요한 정보가 빠지면 답변은 그럴듯하지만 부정확해진다.
장기 기억도 신중히 다뤄야 한다. 사용자의 선호나 반복되는 요구는 저장할 가치가 있지만, 일시적인 요청까지 모두 장기 기억에 넣으면 나중에 잘못된 개인화로 이어질 수 있다.
도구
도구 컨텍스트는 에이전트가 사용할 수 있는 API, 함수 명세, 외부 시스템 사용법, 입력값과 출력값의 구조를 말한다.
예를 들어 항공권 검색 API, 호텔 예약 API, 일정 관리 도구, 결제 시스템이 있다면 에이전트는 각 도구가 언제 필요하고 어떤 인자를 요구하는지 알아야 한다. 도구 설명이 부정확하면 에이전트는 잘못된 함수를 호출하거나 필요한 단계를 건너뛸 수 있다.
도구 컨텍스트는 단순히 "이 도구가 있다"를 알려 주는 수준을 넘어서야 한다. 사용 조건, 제한 사항, 실패 시 대응 방식까지 포함해야 실제 업무 흐름에서 안정적으로 작동한다.
대화 이력
대화 이력은 사용자와 에이전트가 주고받은 상호작용 기록이다. 사용자가 이미 말한 조건, 이전에 거절한 선택지, 확정한 요구사항 등이 여기에 들어간다.
대화 이력이 있으면 에이전트는 같은 질문을 반복하지 않고 자연스럽게 이어서 작업할 수 있다. 예를 들어 사용자가 이미 "직항을 선호한다"고 말했는데 다시 "직항이 좋으신가요?"라고 묻는다면 경험이 나빠진다.
다만 모든 대화 이력을 그대로 유지하는 것은 비효율적이다. 오래된 대화는 요약하거나, 현재 작업과 무관한 부분은 제거해야 한다. 대화 이력은 기억의 원본이라기보다 현재 의사결정에 필요한 맥락으로 재구성되어야 한다.
사용자 선호도
사용자 선호도는 개인화된 요구, 취향, 제약 조건이다. 예산, 선호 시간대, 음식 취향, 업무 스타일, 피하고 싶은 선택지 등이 포함된다.
좋은 에이전트는 사용자의 선호를 단순한 부가 정보가 아니라 의사결정 기준으로 사용한다. 예를 들어 어떤 사용자가 "아침 비행은 피하고 싶다"고 여러 번 말했다면, 이후 여행 검색에서 이를 기본 조건으로 반영할 수 있다.
하지만 선호도는 변할 수 있다. 예전에는 저가 항공을 선호했지만 이번에는 가족 여행이라 편안함을 우선할 수 있다. 그래서 사용자 선호도는 고정된 진실이 아니라 최신 요청과 함께 해석되어야 한다.
컨텍스트 설계 3단계
결과 정의
첫 단계는 에이전트가 만들어야 할 결과를 분명히 정하는 것이다. 결과가 불명확하면 어떤 컨텍스트가 필요한지도 정할 수 없다.
예를 들어 "여행을 도와줘"라는 목표는 너무 넓다. "사용자의 예산과 날짜에 맞는 파리 왕복 항공권과 호텔 후보를 비교하고, 최종 예약 전 확인을 받는다"처럼 결과를 구체화해야 한다. 그래야 필요한 정보, 도구, 검증 절차가 보인다.
필요한 정보 매핑
두 번째 단계는 원하는 결과를 만들기 위해 필요한 정보를 나열하고 연결하는 것이다. 사용자에게 받아야 할 정보, 외부에서 조회해야 할 정보, 장기 기억에서 가져올 정보, 도구 호출 결과로 확인해야 할 정보를 구분한다.
파리 여행 예약이라면 출발지, 날짜, 인원, 예산, 항공 선호, 호텔 위치, 여권 관련 조건, 결제 가능 여부 등이 필요하다. 이 중 일부는 사용자에게 물어야 하고, 일부는 검색 API나 예약 시스템에서 가져와야 한다.
정보 매핑의 핵심은 빠진 정보와 중복 정보를 동시에 줄이는 것이다. 빠진 정보가 있으면 에이전트는 추측하게 되고, 중복 정보가 많으면 컨텍스트 윈도우를 낭비한다.
정보 흐름 및 파이프라인 설계
세 번째 단계는 정보가 어떤 순서로 들어오고, 어디에 저장되며, 언제 압축되고, 어떤 도구로 전달되는지 설계하는 것이다.
예를 들어 사용자 요청을 받으면 먼저 의도를 파악하고, 부족한 정보를 질문하고, 조건이 충분해지면 검색 도구를 호출하고, 결과를 요약한 뒤 사용자 선호와 비교한다. 이후 예약 전에는 최종 확인 메시지를 만들고, 확정된 정보만 장기 기억이나 업무 시스템에 저장한다.
이 파이프라인이 없으면 에이전트는 매번 즉흥적으로 행동한다. 반대로 흐름이 잘 설계되면 작업이 길어져도 정보가 정리되고, 실수가 줄어든다.
실무 전략
스크래치 패드와 장기 메모리 분리
스크래치 패드는 에이전트가 현재 작업을 처리하기 위해 임시로 사용하는 공간이다. 계산 과정, 후보 비교, 중간 판단처럼 지금 작업이 끝나면 버려도 되는 정보가 들어간다.
장기 메모리는 다음 작업에서도 가치가 있는 정보를 저장하는 공간이다. 사용자의 지속적인 선호, 반복되는 제약, 계정 설정 등이 여기에 해당한다.
둘을 섞으면 문제가 생긴다. 임시 추론이 장기 기억으로 저장되면 나중에 잘못된 사실처럼 재사용될 수 있다. 반대로 장기적으로 중요한 선호를 스크래치 패드에만 두면 다음 대화에서 잊어버린다.
컨텍스트 압축
컨텍스트 압축은 긴 대화나 많은 문서를 현재 작업에 필요한 형태로 줄이는 전략이다. 단순히 짧게 요약하는 것이 아니라, 의사결정에 필요한 핵심을 남기고 불필요한 세부사항을 제거하는 작업이다.
예를 들어 사용자가 여러 차례 조건을 바꿨다면 전체 대화를 그대로 넣는 대신 "최종 조건: 6월 초, 2명, 예산 300만 원, 직항 선호, 에펠탑 근처 숙소 선호"처럼 현재 유효한 조건으로 정리하는 것이 낫다.
압축의 목적은 토큰 절약만이 아니다. 모델이 중요한 정보를 더 잘 보게 만드는 것도 중요한 목적이다.
멀티에이전트 활용
복잡한 작업에서는 하나의 에이전트가 모든 컨텍스트를 들고 있는 것보다 역할을 나누는 편이 효과적일 수 있다. 예를 들어 한 에이전트는 항공권을 비교하고, 다른 에이전트는 호텔을 비교하며, 또 다른 에이전트는 전체 일정과 예산을 검토할 수 있다.
멀티에이전트 구조의 장점은 컨텍스트를 역할별로 분리할 수 있다는 점이다. 각 에이전트는 자기 작업에 필요한 정보만 집중적으로 다룬다. 이렇게 하면 컨텍스트 혼잡을 줄이고 전문성을 높일 수 있다.
다만 에이전트 간 정보 전달 방식이 명확해야 한다. 그렇지 않으면 각자 다른 기준으로 판단하거나 중요한 정보가 중간에 누락될 수 있다.
샌드박스 활용
샌드박스는 에이전트가 외부 시스템에 영향을 주기 전에 안전하게 실행하거나 검증할 수 있는 환경이다. 특히 예약, 결제, 데이터 수정처럼 되돌리기 어려운 작업에서는 중요하다.
예를 들어 여행 예약 에이전트가 실제 결제를 바로 실행하지 않고, 먼저 예약 가능 여부와 총액을 샌드박스에서 확인한 뒤 사용자에게 최종 승인을 받게 할 수 있다. 이는 실수를 줄이고 사용자의 신뢰를 높인다.
샌드박스는 컨텍스트 관리와도 연결된다. 실제 실행 전에 필요한 정보가 모두 있는지, 도구 호출 결과가 지침과 충돌하지 않는지 점검하는 완충지대 역할을 한다.
주요 실패 유형과 대응
컨텍스트 오염
컨텍스트 오염은 관련 없거나 잘못된 정보가 컨텍스트에 섞여 모델의 판단을 흐리는 현상이다. 오래된 조건, 잘못 검색된 문서, 임시 추론 결과가 대표적이다.
대응 방법은 정보의 출처와 유효성을 관리하는 것이다. 최신 조건을 우선하고, 확정된 사실과 추측을 구분하며, 작업이 끝난 임시 정보는 제거해야 한다.
컨텍스트 분산
컨텍스트 분산은 필요한 정보가 여러 위치에 흩어져 있어 에이전트가 전체 상황을 제대로 보지 못하는 문제다. 일부 정보는 대화 이력에 있고, 일부는 데이터베이스에 있으며, 일부는 도구 결과에만 남아 있을 때 발생한다.
대응하려면 현재 작업에 필요한 정보를 하나의 작업 상태로 모아야 한다. 원본은 여러 곳에 있어도, 모델이 판단하는 시점에는 핵심 조건이 정리된 형태로 제공되어야 한다.
컨텍스트 혼란
컨텍스트 혼란은 너무 많은 정보가 들어와 모델이 무엇이 중요한지 구분하지 못하는 상황이다. 컨텍스트 윈도우를 많이 채웠다고 좋은 결과가 나오는 것은 아니다.
대응 방법은 압축과 우선순위 설정이다. 현재 목표와 직접 관련 있는 정보, 최신 정보, 사용자 승인 정보, 시스템 규칙을 중심으로 남기고 나머지는 요약하거나 제외해야 한다.
컨텍스트 충돌
컨텍스트 충돌은 서로 다른 지침이나 정보가 동시에 존재해 에이전트가 일관된 결정을 내리기 어려운 상태다. 예를 들어 시스템 규칙은 "예산 초과 금지"라고 하는데, 사용자 메시지에는 "조금 초과해도 예약해줘"가 있을 수 있다.
대응하려면 우선순위 체계가 필요하다. 시스템 규칙, 안전 규칙, 사용자 요청, 추천 기준 사이의 위계를 정해야 한다. 충돌이 해결되지 않으면 에이전트가 임의로 결정하지 말고 사용자나 운영자에게 확인해야 한다.
예시: 파리 여행 예약 에이전트에 적용하는 방식
파리 여행 예약 에이전트를 만든다고 가정해 보자. 이 에이전트의 목표는 사용자의 조건에 맞춰 항공권과 숙소를 찾고, 비교하고, 예약 전 최종 확인을 받는 것이다.
먼저 결과를 정의한다. 단순히 "파리 여행 추천"이 아니라 "출발지, 날짜, 인원, 예산, 선호 조건에 맞는 항공권과 호텔 후보를 제시하고, 사용자가 선택하면 예약 단계로 넘긴다"처럼 정해야 한다.
다음으로 필요한 정보를 매핑한다. 사용자에게는 여행 날짜, 인원, 예산, 선호 항공 시간, 숙소 위치, 객실 조건을 물어야 한다. 외부 시스템에서는 항공권 가격, 좌석 가능 여부, 호텔 가격, 취소 정책을 가져와야 한다. 장기 기억에서는 사용자가 선호하는 좌석, 호텔 등급, 이동 방식 같은 정보를 참고할 수 있다.
그다음 정보 흐름을 설계한다. 에이전트는 먼저 부족한 조건을 질문하고, 조건이 충분하면 검색 도구를 호출한다. 검색 결과는 그대로 보여 주지 않고 예산, 이동 편의성, 사용자 선호를 기준으로 압축한다. 이후 후보를 2~3개로 좁혀 설명하고, 사용자가 선택하면 예약 전 총액과 취소 조건을 다시 확인한다.
이 과정에서 스크래치 패드에는 후보 비교와 중간 계산을 둔다. 장기 메모리에는 "이 사용자는 야간 비행을 싫어한다"처럼 반복적으로 유효한 선호만 저장한다. 실제 예약이나 결제는 샌드박스에서 먼저 검증한 뒤, 사용자 승인을 받은 다음 실행한다.
이 예시에서 핵심은 에이전트가 모든 정보를 한 번에 넣고 답하는 것이 아니라는 점이다. 단계마다 필요한 정보가 다르고, 각 단계가 끝날 때마다 컨텍스트를 정리해야 한다. 그래야 긴 작업에서도 정확성과 신뢰성을 유지할 수 있다.
결론 및 실무 시사점
컨텍스트 엔지니어링은 에이전트를 실제 업무에 투입하기 위한 핵심 기술이다. 프롬프트를 잘 쓰는 것만으로는 충분하지 않다. 비즈니스 환경에서는 정보가 계속 바뀌고, 도구를 호출해야 하며, 사용자 선호를 기억해야 하고, 실수하면 비용이 발생한다.
따라서 좋은 에이전트 설계는 컨텍스트 관리 파이프라인 설계에서 시작된다. 어떤 정보를 언제 넣을지, 언제 뺄지, 무엇을 압축할지, 무엇을 장기 기억에 저장할지, 어떤 도구 결과를 신뢰할지 정해야 한다.
결국 에이전트의 신뢰성은 "얼마나 똑똑하게 말하는가"보다 "얼마나 정확한 맥락에서 판단하는가"에 달려 있다. 제한된 컨텍스트 윈도우를 잘 운영하는 능력이 곧 실무형 AI 에이전트의 경쟁력이다.
참고
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.