AI 에이전트의 성능은 모델 가중치만으로 결정되지 않습니다. 이전 추론을 다음 단계에 어떻게 넘기는지, 길어진 기록을 삭제할지 압축할지에 따라 정확도와 비용, 재현성이 함께 달라집니다.
같은 모델인데 점수가 달라진 이유
최근 OpenAI는 ARC-AGI-3 공개 과제에서 동일 계열 모델의 실행 설정을 바꾸자 결과가 13.3%에서 38.3%로 달라졌다고 보고했습니다. 핵심 변경은 두 가지였습니다. 여러 단계에 걸쳐 이전 추론 항목을 보존하고, 컨텍스트가 길어질 때 오래된 기록을 단순 삭제하는 대신 압축하는 방식입니다. 보도된 수치는 OpenAI가 자체 실행 환경에서 낸 값이므로 독립 검증된 공식 리더보드 순위와 같은 뜻은 아닙니다. 그래도 이 결과를 그냥 넘기기는 어렵습니다. 우리가 쓰는 에이전트도 모델 하나가 아니라 모델, 프롬프트, 도구, 상태 저장, 컨텍스트 관리가 합쳐진 시스템이기 때문입니다.
ARC-AGI-3는 설명 없이 주어진 새 인터랙티브 환경을 탐색하고, 규칙을 모델링하고, 목표를 세운 뒤 행동해야 하는 벤치마크입니다. 따라서 한 번의 답변보다 여러 차례 관찰하고 가설을 수정하는 능력이 중요합니다. 이 구조는 브라우저 자동화, 고객 문의 분류, 코드 수정, 리서치처럼 도구 호출이 이어지는 업무형 에이전트와 닮아 있습니다.
모델의 ‘기억’보다 시스템의 상태 관리
1. 이전 응답을 온전히 이어 주기
API 호출 자체는 대개 독립적입니다. 다음 호출에 무엇을 전달하느냐가 에이전트가 기억하는 범위를 정합니다. OpenAI의 대화 상태 문서는 다단계 추론 모델에서 이전 응답의 출력 항목 전체를 다시 전달하면 추론 항목과 응답 단계 정보를 보존할 수 있다고 설명합니다. 반대로 사용자가 보기 좋다는 이유로 중간 항목을 제거하거나 텍스트 요약만 남기면, 에이전트는 직전 결론은 알아도 그 결론을 만든 가설과 관찰을 잃을 수 있습니다.
다만 주의할 점이 있습니다. ‘추론을 보존한다’는 말은 모델의 내부 생각을 사람이 읽어 보관한다는 뜻이 아닙니다. 제공자가 반환하는 불투명한 상태 항목을 다음 실행에 안전하게 연결하는 패턴에 가깝습니다. 따라서 로그에는 업무상 필요한 입력·도구 결과·최종 행동을 남기되, 민감 정보와 불필요한 모델 상태를 무분별하게 장기 보관하지 않는 데이터 정책이 같이 필요합니다.
2. 잘라내기(truncation)와 압축(compaction)의 차이
긴 작업은 결국 컨텍스트 창 한계에 닿습니다. 가장 쉬운 대응은 가장 오래된 메시지를 잘라내는 것입니다. 하지만 초기에 발견한 제약 조건, 사용자의 승인 범위, 실패했던 시도처럼 뒤의 판단에 필요한 정보도 함께 사라질 수 있습니다. 압축은 이전 맥락을 더 작은 상태로 바꿔 다음 단계에 이어 주는 접근입니다. OpenAI의 compaction 문서는 이 과정이 품질·비용·지연시간의 균형을 위한 것이며, 압축 결과가 다음 컨텍스트에 필요한 이전 상태와 추론을 더 적은 토큰으로 운반한다고 설명합니다.
압축이 만능은 아닙니다. 압축된 항목은 사람에게 읽기 쉬운 회의록이 아니며, 압축 과정에서 어떤 세부 정보가 남는지 제품마다 다릅니다. 특히 계약 조건, 숫자 계산, 규정 문구처럼 원문 정확성이 필요한 작업은 압축에만 의존하지 말고 원본 근거를 별도 구조화 데이터나 검색 가능한 저장소로 관리해야 합니다.
이번 사례에서 확실한 것과 아직 불확실한 것
확실한 부분은 장기 상호작용 과제에서 상태 전달 방식이 결과에 영향을 준다는 점입니다. ARC Prize는 ARC-AGI-3가 낯선 환경에서 탐색·모델링·목표 설정·계획과 실행을 평가한다고 공개합니다. OpenAI API 문서도 이전 응답 연결과 컨텍스트 압축을 장기 상호작용을 위한 기능으로 안내합니다. 독립 분석 역시 이번 수치를 ‘동일 모델의 절대적 우열’보다 실행 하네스가 측정값에 끼치는 영향을 드러낸 사례로 해석합니다.
불확실한 부분도 분명합니다. 38.3%는 OpenAI가 공개 과제와 자체 설정에서 보고한 값입니다. ARC Prize의 공식 리더보드는 공통 프로토콜과 검증 정책을 사용하며, 서로 다른 과제 집합·실행 하네스·비용 조건에서 나온 숫자를 한 줄의 순위처럼 비교하면 안 됩니다. 따라서 ‘어느 모델이 이겼다’보다 ‘우리 업무에서 어떤 상태 정책이 더 잘 작동하는가’를 묻는 것이 정확합니다. 독립적인 비공개 세트 재실행과 설정·비용의 공개가 있어야 더 강한 일반화가 가능합니다.
모델 벤치마크와 제품 벤치마크를 나눠 보기
팀이 새 모델을 고를 때 흔히 단일 프롬프트 정확도와 가격만 비교합니다. 이는 출발점으로는 유용하지만, 도구를 여러 번 쓰는 업무에는 부족합니다. 다음 두 종류의 평가를 나란히 두는 편이 낫습니다.
- 프로토콜 평가: 동일 프롬프트, 동일 도구, 동일 토큰·시간 한도에서 모델을 비교합니다. 외부 리더보드와 가까운 질문에 답합니다.
- 제품 평가: 실제 상태 저장, 권한, 도구 오류 처리, 재시도, 압축 정책을 포함해 측정합니다. 사용자가 실제로 겪을 품질·비용·지연시간에 답합니다.
두 점수가 다르면 모델이 ‘나쁘다’고 단정하기보다 먼저 하네스를 살펴봐야 합니다. 예를 들어 에이전트가 매 도구 호출마다 이전 출력 전체를 버리는지, 컨텍스트 제한에 닿으면 어떤 항목을 버리는지, 실패 후 재시도에 과거 관찰을 전달하는지 확인합니다. 동시에 안전성도 별도로 봐야 합니다. 기억을 오래 유지할수록 오래된 잘못된 지시나 민감 데이터도 남을 위험이 커집니다. 작업별 보존 기간, 신뢰할 수 있는 상태와 비신뢰 입력의 구분, 권한 재확인 지점을 설계해야 합니다.
직접 점검해 볼 것
- 현재 에이전트의 상태 흐름을 한 장에 그립니다. 사용자 입력, 모델 응답, 도구 결과, 다음 호출로 전달되는 항목을 순서대로 적습니다. 그러면 다음 단계에서 사라지는 정보가 보입니다.
- 작은 회귀 과제를 만듭니다. 최소 10개 정도의 다단계 업무를 골라 완료율, 평균 도구 호출 수, 입력·출력 토큰, 사람 개입 횟수를 기록합니다. 같은 모델에서 상태 보존과 단순 잘라내기 설정을 비교하되, 실제 데이터가 아닌 안전한 테스트 데이터로 시작합니다.
- 압축 전후의 검증 지점을 정합니다. 긴 작업 뒤에는 원본 근거 링크, 최종 제안, 실행 권한을 다시 확인하게 만드세요. 압축은 연속성을 높이는 도구이지 사실 검증이나 승인 절차를 대체하지 않습니다.
벤치마크 숫자 옆에 적어둘 것
이번 ARC-AGI-3 사례를 모델 순위 경쟁으로만 보면 얻는 것이 적습니다. 더 유용한 교훈은 에이전트의 실행 환경이 성능 측정의 일부라는 사실입니다. 좋은 모델을 선택하는 일과 좋은 상태 관리 정책을 설계하는 일은 분리되지 않습니다. 다음번 벤치마크 숫자를 볼 때는 모델명 옆에 사용한 도구와 남긴 상태, 길어진 맥락을 처리한 방식, 비용과 검증 조건을 함께 적어야 합니다. 그래야 그 결과가 실제 업무에서도 재현되는지 판단할 수 있습니다.