창에 더 많은 토큰이 들어간다는 이유만으로 에이전트가 신뢰할 만해지지는 않는다. 판단하는 순간에 적절한 근거와 지시, 상태가 도착할 때 더 나아진다.
컨텍스트는 에이전트의 작업 상태다
컨텍스트에는 시스템 지시, 대화 기록, 도구 정의, 검색된 문서, 도구 결과, 임시 계획이 포함된다. Anthropic은 컨텍스트 엔지니어링을 프롬프트 문구를 다듬는 데 그치지 않고 이 전체 토큰 집합을 선별하는 일로 설명한다. 목표는 다음 행동을 뒷받침하는 작고 신호 밀도가 높은 상태다.
자료가 많아지면 오래된 규칙, 중복된 근거, 주의를 흩뜨리는 도구 출력이 섞일 수 있다. 용량과 관련성은 서로 다른 제약이다. 팀은 컨텍스트에 무엇이 들어오는지, 왜 필요한지, 언제까지 유효한 정보인지 추적해야 한다.
정보는 필요한 순간에 가져와라
지속해야 할 정보는 프롬프트 밖에 저장하고 파일 경로, 문서 ID, 검색 질의처럼 가벼운 참조만 둔다. 에이전트가 필요한 구간을 직접 가져오게 한다. 이 방식은 반복되는 페이로드를 줄이고 출처 이력을 더 쉽게 살필 수 있게 한다.
검색에는 경계가 필요하다. 권한 확인, 버전 메타데이터, 출처 순위, 신뢰할 수 없는 지시에 대한 제한이 있어야 한다. 도구 결과는 데이터이지 시스템 프롬프트의 자동 연장이 아니다. 추론할 콘텐츠와 에이전트가 따를 수 있는 명령을 분리한다.
약속을 지우지 않고 압축하라
오래 이어지는 작업에는 결국 압축이 필요하다. 유용한 요약은 목표, 합의된 결정, 완료한 작업, 해결되지 않은 장애물, 산출물 위치, 검증 증거를 보존한다. 반복된 대화와 다시 가져올 수 있는 큰 출력은 버린다.
요약은 구조화하고 검토할 수 있게 만든다. ‘승인 없이 보내지 않는다’처럼 중요한 약속은 서술형 요약이 기억해 주길 바라지 말고 명시적 상태로 저장한다. 요약을 원본 산출물과 연결해 이후 세션이 세부 내용을 복구할 수 있게 한다.
서브에이전트로 잡음이 많은 작업을 격리하라
집중된 서브에이전트는 깨끗한 컨텍스트에서 큰 코퍼스를 검색하거나 여러 접근법을 시험한 뒤 압축된 결과를 돌려줄 수 있다. 격리는 탐색 과정의 잔해가 조정자의 판단 상태에 섞이지 않게 한다. 작업이 실제로 독립적이라면 병렬 처리도 가능하다.
그래도 조정자에게는 인수 기준과 검증이 필요하다. 자신감 있는 요약은 파일이 존재하거나 작업이 성공했다는 증거가 아니다. 작업에 맞는 경로, 출처 링크, 시험 출력, 읽기 확인 증거를 요구한다.
컨텍스트를 시스템 지표로 관측하라
컨텍스트 크기, 검색 출처, 압축 이벤트, 도구 페이로드 크기, 판단에 사용한 상태의 경과 시간을 기록한다. 실패 표본에서 불필요하거나 빠진 컨텍스트를 찾는다. 비용과 지연 시간도 중요하지만 시스템이 오래된 사실로 행동했는지도 중요하다.
좋은 컨텍스트 아키텍처는 실패 원인을 읽을 수 있게 한다. 에이전트가 근거가 없었는지, 규칙을 무시했는지, 둘 다 있었는데도 잘못 선택했는지 엔지니어가 확인할 수 있다.
실전에 적용하는 방법
먼저 더 적은 컨텍스트로 AI 에이전트의 판단을 개선할, 범위가 명확한 워크플로 하나를 고른다. 시스템을 바꾸기 전에 현재 완료 시간, 품질 검사, 흔한 실패 범주, 에스컬레이션 경로, 결과 담당자를 한 페이지에 정리한다. 가장 깔끔한 사례만 고르지 말고 대표 표본을 선택한다. 일반 사례와 어려운 경계 사례, 그리고 멈추거나 추가 정보를 요청하는 것이 정답인 사례를 최소 하나 포함한다.
후보 시스템이 기존 절차를 대체하도록 허용하기 전에 두 시스템을 나란히 운영한다. 오류율이 낮아져도 영향이 큰 새로운 실패를 감출 수 있으므로 성공한 출력과 실패한 출력을 모두 검토한다. 각 시험에 사용한 정확한 구성을 기록하고, 다른 검토자가 결과를 재현할 수 있는 산출물을 보관한다. 파일럿이 끝나면 가장 인상적인 시연을 보고 뒤늦게 판단하지 말고, 미리 합의한 기준에 따라 확대·수정·중단을 결정한다.
벤더나 내부 팀에 물어볼 질문
핵심 주장을 뒷받침하는 증거가 무엇인지, 그 증거를 만든 시스템과 데이터의 버전은 무엇인지, 어떤 조건이 제외됐는지 묻는다. 실제 배포에서 맞닥뜨릴 언어, 입력 유형, 위험 범주별 결과를 요청한다. 변경 사항을 어떻게 알리고 회귀를 어떻게 탐지하는지, 고객이 사고 검토에 필요한 로그를 내보낼 수 있는지도 확인한다.
확신도가 낮거나 의존성이 실패하거나 요청이 지원 범위를 벗어날 때 시스템이 어떻게 작동하는지도 묻는다. 신뢰할 수 있는 제품에는 더 매끄러운 답변만이 아니라 정의된 실패 상태가 있어야 한다. 책임 주체도 중요하다. 누가 워크플로를 멈출 수 있는지, 누가 예외를 승인하는지, 중대한 오류가 운영 환경으로 빠져나갔을 때 누가 영향받은 사용자에게 알리는지 정한다.
실전 체크리스트
- 모델이나 도구를 선택하기 전에 사용자 작업과 중요하게 봐야 할 실패를 정의한다.
- 실제 업무에서 뽑은 작고 버전 관리되는 시험 세트를 유지하고, 까다로운 사례와 적대적 사례도 포함한다.
- 모든 실행에서 모델, 프롬프트, 도구, 검색 설정, 데이터 버전, 지연 시간, 비용을 기록한다.
- 되돌릴 수 없거나 영향이 크거나 외부에 공개되는 작업에는 사람의 확인을 요구한다.
- 평균 점수 하나가 아니라 범주별로 실패를 검토하고, 회귀 사례를 시험 세트에 추가한다.
Meydo Journal 관련 글
주요 출처
- AI 에이전트를 위한 효과적인 컨텍스트 엔지니어링Anthropic
