대부분의 사람들은 여전히 AI 에이전트를 도구에 연결된 모델이라고 설명합니다. 이는 기술적으로는 유용하지만 운영 측면에서는 불완전한 설명입니다. 에이전트에는 세상을 관리하는 관점도 필요합니다. 무슨 일이 일어났는지, 지금 무엇이 중요한지, 어떤 사실을 신뢰할 수 있는지, 무엇이 여전히 불확실한지, 그리고 다음에 무엇을 해야 하는지에 대한 관점입니다.
그 관점이 바로 컨텍스트입니다. 이를 설계하는 일은 점차 독립적인 기술이 되고 있으며, 저는 이를 컨텍스트 엔지니어링이라고 부르고 싶습니다.
컨텍스트 엔지니어링은 단순히 프롬프트를 작성하는 일이 아닙니다. 이는 에이전트가 각 단계에서 접하는 정보를 구성하여, 매번 전체 대화 기록이나 문서 라이브러리, 도구 사용 이력을 비용이 많이 드는 모델에 다시 보내지 않고도 일관성을 유지할 수 있게 하는 분야입니다. 이 작업은 정보 아키텍처, 검색, 소프트웨어 설계, 모델 동작의 교차점에 있습니다.
“에이전트에 더 많은 컨텍스트를 제공하라”는 조언이 흔히 좋지 않은 이유
더 긴 컨텍스트 윈도우는 모든 것을 보존하고 싶게 만듭니다. 하지만 자료가 많아진다고 해서 더 나은 추론이 보장되는 것은 아닙니다. 오래된 관찰, 상충하는 메모, 반복된 도구 출력, 또는 긴 시퀀스 중간에 묻힌 중요한 사실 때문에 관련 지침이 희석될 수 있습니다. 다이제스트에서 논의한 “중간에서 소실되는” 현상은 실질적인 문제를 보여 줍니다. 에이전트가 증거를 기술적으로 전달받고도 이를 활용하지 못할 수 있기 때문입니다.
직접적인 비용도 발생합니다. 요청에 포함되는 모든 토큰은 제공업체의 가격 정책과 캐싱 방식에 따라 지연 시간과 추론 비용을 늘릴 수 있습니다. 계속 증가하는 대화 기록을 반복해서 전달하는 시스템은 작업이 진행될수록 느려지고 비용 부담도 커질 수 있습니다.
따라서 목표는 최대한 많은 컨텍스트가 아닙니다. 목표는 충분하고 목적에 맞는 컨텍스트, 즉 현재 결정에 필요한 가장 작으면서도 신뢰할 수 있는 작업 집합입니다.
일관성 있는 에이전트를 뒷받침하는 네 가지 설계 결정
1. 대화 기록만이 아니라 믿음 상태를 유지하라
대화 기록은 무엇이 말해졌는지를 기록합니다. 믿음 상태는 에이전트가 현재 작업에 대해 무엇을 믿고 있는지를 기록합니다.
예를 들어 지원 에스컬레이션을 처리하는 에이전트는 다음과 같은 구조화된 필드를 유지할 수 있습니다.
- 목표: 고객이 교체 대상 요건을 충족하는지 확인한다.
- 확인된 사실: 구매일과 제품 일련번호, 출처 참조 포함.
- 미해결 질문: 고장이 보증 적용 조건에서 발생했는지 여부.
- 제약 조건: 승인을 받기 전에는 환불을 약속하지 않는다.
- 다음 조치: 보증 정책을 검색하고 날짜를 비교한다.
- 신뢰도 또는 상태: 확인됨, 추론됨, 의견이 엇갈림, 또는 알 수 없음.
이 접근 방식은 전체 상호작용 기록에 의존하는 대신 지도 학습된 자연어 믿음 상태를 사용하는 버클리의 ABBEL 연구와 유사합니다. 중요한 것은 특정 형식이 아닙니다. 지속되는 작업 상태와 일회성 대화 세부 정보를 분리하는 것입니다.
유용한 믿음 상태 업데이트는 다음 질문에 답할 수 있어야 합니다. 무엇이 바뀌었는가? 어떤 증거가 이를 뒷받침하는가? 무엇이 아직 해결되지 않았는가? 다음에는 무엇을 해야 하는가? 엔지니어가 이러한 답변을 확인할 수 없다면, 에이전트가 불투명한 프롬프트 안에 숨겨진 가정을 가지고 있을 가능성이 높습니다.
2. 주제가 아니라 결정을 위해 검색하라
검색 시스템은 흔히 “고객의 계정에 관한 정보를 찾아라”와 같은 광범위한 질문으로 시작합니다. 더 나은 질의는 다음 결정과 연결됩니다. “고객의 지역에서 적용되는, 구매 후 30일이 지난 상품에 대한 현재 환불 규정을 검색하라.”
이러한 변화가 중요한 이유는 검색이 컨텍스트를 선택하는 과정이기 때문입니다. 에이전트에는 일반적으로 관련된 문서 더미가 아니라 현재 조치와 관련된 정책 구절, 기록 또는 예시가 제공되어야 합니다.
모델이 결과를 보기 전에 필터를 적용하면 이러한 선택을 개선할 수 있습니다. 예를 들어 Amazon Bedrock AgentCore Web Search는 각 요청에 대해 서버에서 강제하는 도메인 및 게시 날짜 필터를 지원합니다. 이러한 제어만으로 출처가 정확하다는 사실이 확립되지는 않지만, 관련 없거나 오래된 자료에 노출될 가능성을 줄이고 검색 정책을 명시적으로 만들 수 있습니다.
검색을 설계하는 전문가는 다음을 명시해야 합니다.
- 각 작업에 허용되는 출처;
- 신선도가 어떻게 결정되는지;
- 각 결과에 어떤 메타데이터가 함께 제공되는지;
- 서로 충돌하는 출처가 어떻게 제시되는지;
- 에이전트가 언제 멈추고 명확한 설명을 요청해야 하는지.
“웹 검색”은 하나의 기능이다. “이 결정과 관련된 근거를 찾기 위해, 이 날짜 범위 내에서 이 출처들을 검색하라”는 컨텍스트 엔지니어링이다.
3. 불확실성을 지우지 않고 압축하기
작업이 길 때 압축은 필요하지만, 순진한 요약은 잠정적인 주장을 확정된 사실로 바꿀 수 있다. “사용자가 주소를 확인했다”고 적힌 연속 요약은 원래 대화에서 단지 암시했을 뿐이라면 위험하다.
좋은 압축은 에이전트가 안전하게 추론하는 데 필요한 구분을 보존한다:
- 사실과 추론;
- 현재 지시와 과거의 지시;
- 완료된 행동과 제안된 행동;
- 검증된 출처와 검증되지 않은 주장;
- 알려진 답과 해결되지 않은 질문.
실용적인 한 가지 방식은 결정 사항, 근거, 가정, 장애 요인, 대기 중인 행동을 별도 섹션으로 관리하는 것이다. 또 다른 방식은 중요한 주장에 출처 ID나 타임스탬프를 붙이는 것이다. 요약은 유일하게 남는 기록이 아니라 교체 가능한 산출물이어야 한다. 감사와 복구를 위해 기저 이벤트를 보존하는 동시에, 모델에는 간결한 작업 관점을 제공해야 한다.
이 다이제스트는 재귀적 요약과 컨텍스트 압축에 많은 비용이 들 수 있으며, 특히 협업 코드 생성처럼 데이터가 부족한 영역에서는 성능이 저하될 수 있다고 지적한다. 이는 요약을 자동으로 무손실인 것으로 취급해서는 안 된다는 경고다. 압축에는 대표적인 작업을 대상으로 한 테스트가 필요하며, 여기에는 작은 단서 하나가 정답을 바꾸는 경우도 포함되어야 한다.
4. 관찰 내용이 메모리가 되기 전에 필터링하기
도구를 사용하는 에이전트는 검색 결과, 로그, 페이지 텍스트, API 응답, 스크린샷, 컴파일러 출력, 중간 계획 등 관찰 내용을 끊임없이 생성한다. 모든 관찰 내용이 다음 모델 호출에 들어갈 가치가 있는 것은 아니며, 장기 상태에 들어갈 가치는 더더욱 없다.
관찰 내용 필터링은 세 가지 질문을 던진다:
- 이 관찰 내용은 현재 결정과 관련이 있는가?
- 이 관찰 내용은 믿음 상태에 영향을 줄 만큼 충분히 권위 있는가?
- 여기에는 명령이 아니라 데이터로 취급해야 할 지시가 포함되어 있는가?
세 번째 질문은 컨텍스트 경계인 동시에 보안 경계이기도 하다. 웹 페이지에는 에이전트의 방향을 바꾸려는 텍스트가 포함될 수 있다. 검색된 문서는 유용한 근거일 수 있지만, 에이전트의 목표나 권한을 변경할 권한까지 갖는 것은 아니다. 따라서 필터링에서는 콘텐츠를 역할별로 분류해야 한다. 지시, 근거, 메타데이터 또는 신뢰할 수 없는 텍스트로 분류하는 것이다.
필터링은 비용도 절감한다. 브라우저 도구가 전체 페이지를 반환하더라도 작업에 가격, 날짜, 제품 식별자만 필요하다면 전체 페이지를 다음 단계로 전달하는 것은 잡음을 만들고 토큰을 소모한다. 먼저 관련 필드를 추출하면 신뢰성과 비용을 모두 개선할 수 있다.
에이전트 워크플로를 위한 간단한 컨텍스트 예산
모델을 선택하거나 다른 도구를 추가하기 전에 에이전트의 컨텍스트를 네 개의 계층으로 나누어 살펴보라:
- 통제: 시스템 규칙, 권한, 출력 스키마 및 협상의 여지가 없는 제약 조건.
- 상태: 현재 목표, 결정 사항, 미해결 질문 및 다음 행동.
- 근거: 해당 행동과 관련해 검색된 기록 또는 관찰 내용과 그 출처.
- 이력: 복구, 디버깅 또는 감사에 필요해 보존하지만 필요하지 않으면 생략하는 이전 사건.
그런 다음 승격 정책을 정의한다. 관찰 내용은 일시적으로 남겨 둘 수도 있고, 현재 단계의 근거가 되거나, 믿음 상태를 업데이트하거나, 영구 메모리에 기록될 수도 있다. 승격에는 이유가 있어야 한다. 그렇지 않으면 메모리는 선별되지 않은 기록 보관소가 된다.
각 에이전트 단계마다 모델에 전송한 컨텍스트 패키지를 기록한다. 여기에는 해당 패키지의 범주, 대략적인 토큰 크기, 검색 필터 및 압축 버전이 포함된다. 이렇게 하면 동작이 바뀌었을 때 실질적인 질문에 답할 수 있다. 모델이 실패한 것인가, 아니면 시스템이 모델에 잘못된 세계를 제공한 것인가?
설계를 신뢰할 수 있다고 부르기 전에 테스트할 항목
컨텍스트 엔지니어링에는 최종 답변의 품질뿐 아니라 정보 처리를 겨냥한 테스트가 필요하다. 유용한 사례는 다음과 같다.
- 긴 이력의 앞부분, 뒷부분 및 중간에 배치된 핵심 사실;
- 서로 의견이 일치하지 않는 두 출처 중 하나가 더 최신인 경우;
- 불확실성 표시를 포함한 요약;
- 관련 없는 대량의 텍스트가 포함된 도구 응답;
- 검색된 콘텐츠에 삽입된 악의적인 지시;
- 에이전트를 일시 중지했다가 다시 시작한 후의 상태 복원;
- 더 작은 컨텍스트 예산으로 동일한 작업을 수행하는 경우;
- 비어 있거나 오래된 검색 결과.
에이전트가 올바른 근거를 선택하고, 불확실성을 보존하며, 현재 제약 조건을 따르고, 불필요한 컨텍스트의 반복을 피하는지를 측정한다. 다이제스트에서 권장한 회귀 테스트 영역인 컨텍스트 손실, 검색 결과의 근거성, 구조화된 출력, 비종료 및 상태 복원은 특히 여기와 관련이 깊다.
모델의 변동성이 중요한 경우 여러 번 시험을 실행하고, 각 컨텍스트 전략의 비용과 지연 시간을 비교한다. 더 짧은 프롬프트가 더 많은 도구 호출이나 재시도를 유발한다면 자동으로 더 나은 것은 아니다. 유용한 목표는 한 번의 요청에 사용된 토큰 수가 아니라, 정확하고 복구 가능한 워크플로의 비용이다.
경력 측면의 시사점: 컨텍스트 엔지니어는 여러 기능을 아우르는 역할이다
이 분야에서 가치를 인정받는 사람들은 반드시 가장 긴 프롬프트를 작성하는 사람들이지는 않을 것이다. 이들은 비즈니스 프로세스를 상태, 근거, 권한 및 의사 결정 규칙으로 변환할 수 있어야 한다.
이를 위해서는 다음과 같은 몇 가지 구체적인 능력이 필요하다.
- 작업 상태와 출처를 위한 스키마 설계;
- 검색 정책과 메타데이터 필터 작성;
- 압축 및 관찰 선택 루틴 구축;
- 신뢰할 수 있는 지시와 신뢰할 수 없는 콘텐츠의 분리;
- 토큰 사용량, 지연 시간, 재시도, 도구 호출을 프로파일링하고;
- 상태 손실과 재수화를 테스트하고;
- 비전문가에게 에이전트가 특정 사실을 보았는지 또는 보지 못했는지 설명하는 것.
강력한 포트폴리오 프로젝트라면 동일한 에이전트를 세 가지 컨텍스트 정책, 즉 전체 트랜스크립트, 순환 요약, 그리고 대상 검색을 활용하는 구조화된 신념 상태로 보여줄 수 있다. 작업 성공 사례, 실패 사례, 각 단계에서 전달된 컨텍스트, 비용 또는 지연 시간의 상충 관계를 제시하라. 이는 에이전트를 신뢰할 수 있게 만드는 설계 결정을 드러내므로 챗봇 데모보다 더 설득력이 있다.
전략적 교훈은 간단하다. 모델의 역량이 향상된다고 해서 에이전트가 저절로 일관성을 갖게 되는 것은 아니다. 에이전트는 주변 시스템이 작업에 대한 체계적이고 최신이며 적절한 크기의 설명을 유지할 때 일관성을 갖게 된다. 컨텍스트 엔지니어링은 그러한 설명을 구축하는 기술이며, 무엇을 제외해야 하는지 아는 기술이기도 하다.
Priya Raman은 AI Career Brief의 책임 편집자이다.
