긴 대화와 도구 출력을 모두 넣었는데 에이전트가 중요한 제약을 놓칩니다. 프롬프트 수정과 컨텍스트 엔지니어링은 무엇이 다른가요?

프롬프트 문장을 다듬는 것뿐 아니라 현재 판단에 어떤 정보가 언제 들어가고 무엇이 빠지는지 설계해야 합니다. 시스템 지침, 사용자 목표, 도구 설명, 검색 근거, 작업 상태, 이전 결과가 한정된 입력 공간을 공유합니다. 이 전체 정보 흐름을 관리하는 것이 컨텍스트 엔지니어링입니다. 큰 컨텍스트 창은 더 많은 입력을 허용하지만 중요한 사실을 항상 정확히 활용한다는 보장은 아닙니다.

현재 결정에 필요한 정보를 고릅니다

저장소의 모든 파일을 넣기보다 수정할 기능의 진입점과 호출 경로, 테스트, 관련 규칙을 먼저 찾겠습니다. 파일 경로·문서 ID 같은 참조를 유지하고 필요할 때 해당 부분을 읽는 방식은 초기 토큰을 줄이고 최신 정보를 얻기 좋습니다. 대신 검색을 놓치면 필요한 제약이 아예 들어오지 않으므로 탐색 범위와 누락 확인이 필요합니다. 항상 많이 넣는 방식과 항상 적게 넣는 방식 모두 정답은 아닙니다.

도구 결과는 모델이 다음 결정을 할 수 있는 형태로 반환합니다. 원본 로그 10만 줄 대신 오류 구간·관련 요청·집계와 원문 참조를 줄 수 있지만, 요약자가 판단에 필요한 반례를 지우지 않았는지 확인해야 합니다. 권한·승인 범위·미확정 상태는 압축하면서도 명시적으로 보존합니다. 외부 문서와 사용자 지시의 신뢰 수준도 함께 유지해야 문맥에서 가까이 보인다는 이유로 데이터가 지시가 되지 않습니다.

토큰 수와 정보 품질은 다릅니다

같은 사실의 복사본이 많으면 최신 버전과 옛 버전이 충돌하고 주의가 분산될 수 있습니다. 관찰 시각·출처·대상 버전을 붙이고 중복 자료는 정리하되, 상충하는 근거를 편한 쪽으로 임의 삭제하지 않습니다. 최근 자료라고 무조건 맞는 것도 아니므로 원본성·적용 버전을 봅니다. 장기 메모리는 매 요청 전부 넣기보다 현재 과제와 관련된 항목만 읽고 원문과 대조합니다.

평가에서는 입력 토큰 감소뿐 아니라 중요한 제약의 회상, 올바른 파일·도구 선택, 근거 누락, 추가 검색 비용과 최종 성공률을 비교합니다. 문맥 중간에 놓인 조건이나 서로 모순된 문서, 긴 무관 자료를 섞어 강건성도 확인합니다. 최근 설계 방향은 무한히 긴 프롬프트를 만드는 것보다 검색·압축·외부 기록·좁은 하위 작업을 조합하는 쪽으로 확장되고 있습니다. 이는 특정 구성의 보편적인 성능 보장이 아니라 과제별로 평가해야 할 설계 선택입니다.

실행 사례로 확인합니다

문서 A는 버전 1에서 초기화 세션이 필요하다고 하고 문서 B는 버전 2에서 요청별 상태를 쓴다고 할 수 있습니다. 둘을 날짜·버전 없이 요약하면 모델은 상충 규칙을 한 구현에 섞을 수 있습니다. 현재 목표 구현의 버전을 먼저 고정하고 다른 자료는 비교 자료로 표시하겠습니다. 문맥 테스트도 정답이 포함됐는지만 보지 않고 어느 버전의 조건이 적용돼야 하는지를 검사합니다. 자료를 제거했을 때 실패가 늘어나는지, 추가했을 때 무관한 내용 때문에 결정이 흔들리는지 비교하면 필요한 정보의 범위를 알 수 있습니다. 컨텍스트 구성의 개선은 토큰 수와 정답률을 함께 기록해야 과도한 삭제나 무차별 적재를 피할 수 있습니다.