에이전트가 짧은 작업에서는 잘 작동하다 긴 작업에서 앞선 결정을 놓칠 때가 있다. 방금 확인한 조건을 잊거나 이미 처리한 일을 반복하는 식이다. 이런 실패의 원인은 모델 성능, 도구 오류, 작업 설계 등 여러 가지다. 그중 확인할 부분이 컨텍스트 구성이다.
컨텍스트는 모델이 이번 응답을 만들 때 참고하는 입력이다. 사용자 지시와 이전 대화, 도구 설명, 검색 결과가 여기에 들어갈 수 있다. 긴 작업에서는 이 내용이 계속 달라진다.
무엇을 넣을지 매번 판단한다
Anthropic의 컨텍스트 엔지니어링 설명은 개별 프롬프트뿐 아니라 작업 중 전체 입력 상태를 관리해야 한다고 제안한다. 오래된 도구 출력이 계속 남아 있는지, 현재 결정에 필요한 조건이 빠졌는지 살펴보는 일이다.
관련 자료를 많이 넣으면 정보가 풍부해질 수 있다. 반면 오래된 지시나 무관한 문서가 섞이면 필요한 내용을 찾기 어려워질 수 있다. 무조건 짧게 만드는 것보다 현재 작업에 필요한 근거를 유지하는 것이 중요하다.
앞선 결정과 진행 상태를 따로 남긴다
긴 대화를 요약할 때는 결론만 남기지 않는다. 사용자의 목적, 확정된 조건, 이미 끝낸 일과 아직 확인하지 못한 내용을 구분해야 한다. 실행 결과를 놓치면 같은 작업을 반복하고, 제안을 확정 사항으로 옮기면 승인하지 않은 일을 할 수 있다.
전체 대화가 필요하지 않은 다음 작업에는 이 요약과 원문 위치를 전달할 수 있다. 중요한 근거를 다시 읽을 수 있어야 요약 과정에서 빠진 정보를 보완할 수 있다.
필요한 자료는 필요할 때 가져온다
파일 경로와 문서 제목, 조회 조건을 보존해두면 모든 내용을 입력에 계속 유지할 필요가 줄어든다. 특정 결정을 앞두고 해당 자료를 읽는 방식이다.
다만 조회 자체가 실패하거나 잘못된 버전을 찾을 수 있다. 현재 정본이 어디인지, 어떤 시점의 자료인지 표시해야 한다. 외부 문서 속 문장을 사용자의 새로운 지시로 취급하지 않는 것도 중요하다.
실패를 대화 길이 하나로 설명하지 않는다
모든 에이전트가 20~30턴 뒤에 성능을 잃는다는 공통 기준은 없다. 턴마다 입력 길이와 도구 출력, 작업 난도가 다르고 모델과 시스템의 처리 방식도 다르다.
실제 점검에서는 실패한 순간의 입력을 확인한다. 필요한 조건이 있었는지, 서로 충돌하는 지시가 있었는지, 잘못된 도구 결과를 그대로 사용했는지 본다. 그 근거로 요약이나 조회 방식을 고친 뒤 같은 유형의 작업을 다시 확인한다.
적은 인원으로 자동화를 운영할수록 작업 상태를 읽고 이어받을 수 있어야 한다. 사람이든 다음 에이전트든 무엇을 했고 무엇이 남았는지 확인할 수 있는 기록이 필요하다.