Responses API retained reasoning 운영법: 에이전트가 같은 실수를 반복하지 않게 만드는 설정

에이전트가 툴을 여러 번 호출하는 작업에서 이상하게 헤매는 경우가 있다. 앞에서 이미 확인한 사실을 다시 묻고, 이전 단계에서 세운 계획을 잊고, 같은 파일을 반복해서 읽는다. 모델이 약해서일 수도 있지만, 더 흔한 원인은 세션 설계다. 특히 tool call 사이에 reasoning을 버리거나 오래된 기록을 단순 truncation으로 날리면 에이전트는 매 턴마다 일을 처음부터 다시 해석하게 된다.

OpenAI가 ARC-AGI-3 실험에서 공개한 결과는 이 문제를 잘 보여준다. GPT-5.6 Sol은 공식 harness에서 13.3%를 기록했지만, Responses API 기반으로 retained reasoning과 compaction을 켜자 38.3%까지 올라갔다. 동시에 output token은 6분의 1 수준으로 줄었다고 설명했다. 이 수치를 그대로 모든 업무에 적용할 수는 없지만, 메시지는 분명하다. 장기 작업에서 모델 성능은 모델 자체뿐 아니라 대화 기록을 어떻게 보존하느냐에 크게 좌우된다.

이 글은 retained reasoning과 compaction을 실무 에이전트에 적용할 때 확인해야 할 구조를 정리한다.

문제는 모델 기억력이 아니라 harness 기억력이다

LLM 에이전트는 보통 다음 루프를 돈다. 입력을 읽고, 계획을 세우고, 툴을 호출하고, 결과를 보고, 다음 행동을 정한다. 여기서 중요한 정보는 툴 결과만이 아니다. 왜 그 툴을 호출했는지, 어떤 가설을 세웠는지, 어떤 선택지를 버렸는지도 다음 턴의 판단에 영향을 준다.

일부 구현은 tool call이 끝날 때 visible message만 다음 요청에 넘긴다. 내부 reasoning이나 계획은 버리고, 툴 결과 요약만 남긴다. 그러면 에이전트는 다음 턴에서 과거 결정을 다시 추론해야 한다. 작업이 짧으면 티가 덜 난다. 하지만 20번 이상 툴을 호출하는 코드 수정, 장애 분석, 웹 리서치, 게임형 벤치마크에서는 누적 손실이 커진다.

rolling truncation도 비슷한 문제를 만든다. 컨텍스트가 길어지면 오래된 메시지를 앞에서부터 버리는 방식이다. 단순하고 구현하기 쉽지만, 처음에 발견한 제약, 사용자 요구사항, 실패했던 접근, 파일 구조 같은 정보가 사라진다. 남은 최근 로그만 보고 판단하면 방향이 흔들릴 수밖에 없다.

retained reasoning은 “생각을 저장한다”보다 “작업 연속성을 보존한다”에 가깝다

retained reasoning은 모델이 이전 턴에서 만든 reasoning 흐름을 다음 턴에서도 이어갈 수 있게 하는 접근이다. OpenAI는 Responses API에서 previous response ID를 넘기는 방식으로 reasoning을 보존할 수 있다고 설명한다. 개발자가 매번 전체 reasoning을 직접 다룬다는 뜻이 아니라, 모델이 장기 작업에서 자기 판단의 맥락을 잃지 않도록 API 레벨에서 세션을 이어주는 방식이다.

이 기능이 중요한 작업은 정해져 있다.

• 여러 툴 호출을 거쳐야 결론이 나오는 작업.
• 중간 가설을 세우고 검증하는 디버깅.
• 같은 목표를 오래 유지해야 하는 코드 에이전트.
• 단계별 게임, 시뮬레이션, 브라우저 자동화.
• 긴 문서 분석 후 여러 질문에 답하는 워크플로우.

반대로 단일 분류, 짧은 요약, 독립적인 응답 생성에서는 효과가 작을 수 있다. 모든 요청에 무조건 적용하기보다 장기 작업 전용 agent runner에 먼저 붙이는 게 안전하다.

compaction은 truncation의 대체재다

컨텍스트가 길어질 때 선택지는 보통 세 가지다. 아무것도 안 하고 한도에 부딪힌다. 앞부분을 버린다. 중요한 내용을 압축해 보존한다. compaction은 세 번째에 가깝다. 단순히 오래된 메시지를 삭제하는 대신, 작업에 필요한 학습 내용과 상태를 압축해 남긴다.

실무에서는 compaction을 다음 정보 중심으로 설계해야 한다.

• 최종 목표와 성공 조건.
• 사용자가 명시한 금지사항.
• 이미 확인한 사실과 출처.
• 실패한 시도와 실패 이유.
• 현재까지의 파일, API, 데이터 구조 이해.
• 다음에 해야 할 구체적인 행동.

좋은 compaction은 짧은 요약문이 아니다. 작업 재개에 필요한 상태 파일이다. “여러 파일을 봤다”가 아니라 “src/auth/session.ts에서 refresh token 만료 처리가 누락되어 401 루프가 발생했다”처럼 재사용 가능한 사실을 남겨야 한다.

구현할 때 필요한 상태 모델

Responses API를 쓰든 다른 provider를 쓰든, 에이전트 runner에는 최소한 다음 상태가 있어야 한다.

{
  "task_id": "fix-auth-refresh-loop",
  "response_cursor": "prev_response_id_or_session_id",
  "goal": "401 루프 원인 분석 후 수정안 제시",
  "constraints": ["파일 삭제 금지", "테스트 실행 전 변경 요약"],
  "known_facts": [],
  "failed_attempts": [],
  "open_questions": [],
  "next_action": "로그에서 refresh token 만료 시점 확인"
}

핵심은 provider cursor와 사람이 읽을 수 있는 상태를 함께 저장하는 것이다. provider cursor만 저장하면 장애 복구가 어렵다. 사람이 읽을 수 있는 상태만 저장하면 모델 내부 연속성을 놓칠 수 있다. 둘 다 있어야 재시작, 디버깅, 감사가 가능하다.

또한 툴 호출 결과를 그대로 전부 넣지 않는 편이 좋다. 긴 로그, 대형 JSON, HTML 페이지는 원문 저장소에 보관하고 모델에는 요약과 참조 키를 넘긴다. 필요한 경우 다시 fetch하면 된다. 이렇게 해야 compaction이 의미 있는 정보를 중심으로 작동한다.

비용과 품질을 같이 측정해야 한다

retained reasoning과 compaction은 품질을 올릴 수 있지만 비용 구조도 바꾼다. 내부 reasoning을 보존하고 압축하는 과정이 항상 공짜는 아니다. 따라서 도입할 때는 “성공률이 올랐다”만 보면 안 된다. 다음 지표를 같이 봐야 한다.

• 작업당 총 입력 토큰.
• 작업당 총 출력 토큰.
• 평균 tool call 횟수.
• 반복 tool call 비율.
• 작업 성공률.
• 사람이 개입한 횟수.
• 평균 완료 시간.
• compaction 이후 오류율.

흥미로운 부분은 retained reasoning이 오히려 출력 토큰을 줄일 수 있다는 점이다. 모델이 매 턴 처음부터 생각하지 않아도 되면 중복 reasoning과 반복 탐색이 줄어든다. OpenAI의 ARC-AGI-3 사례에서도 점수 상승과 output token 감소가 함께 나타났다. 따라서 비용 평가는 한 요청 단가가 아니라 “작업 하나를 끝내는 총 비용”으로 해야 한다.

언제 적용하지 말아야 하나

모든 에이전트에 장기 기억을 붙이면 좋아 보이지만, 위험도 있다. 개인정보나 민감 데이터가 포함된 작업에서는 retention 범위를 명확히 해야 한다. 규제 환경에서는 어떤 내용이 보존되는지, 얼마나 오래 저장되는지, 누가 접근하는지 정책이 필요하다. 또 사용자별 세션이 섞이면 치명적인 보안 사고가 된다.

다음 조건에서는 기본 적용을 피하는 편이 낫다.

• 요청들이 서로 독립적인 대량 분류 작업.
• 민감 정보가 많고 보존 정책이 없는 작업.
• 재현성과 감사가 필요한데 provider 내부 상태만 의존하는 구현.
• 낮은 지연시간이 최우선인 단발 응답.
• 실패해도 재시도 비용이 매우 낮은 작업.

장기 기억은 성능 기능이면서 동시에 상태 관리 기능이다. 상태가 생기면 운영 책임도 생긴다.

실행 체크리스트

이번 주에 agent runner를 개선한다면 아래 순서로 진행하면 된다.

1. 장기 작업과 단기 작업을 라우팅 단계에서 분리한다.
2. 장기 작업에는 provider response cursor 또는 session ID를 저장한다.
3. visible 상태 요약을 별도 JSON으로 저장한다.
4. rolling truncation 대신 goal, facts, failed attempts, next action 중심 compaction을 만든다.
5. 툴 원문은 파일이나 DB에 저장하고 모델에는 참조와 요약만 넣는다.
6. 반복 tool call 비율과 작업당 총 토큰을 측정한다.
7. retained reasoning 적용 전후의 성공률, 완료 시간, 비용을 비교한다.
8. 민감 데이터 retention 정책을 문서화한다.

에이전트 성능을 올리는 방법은 새 모델을 붙이는 것만이 아니다. 같은 모델도 기억을 잃으면 멍청해 보이고, 작업 맥락을 유지하면 훨씬 안정적으로 보인다. 장기 작업이 많은 팀이라면 retained reasoning과 compaction은 옵션이 아니라 runner 설계의 기본값으로 검토할 만하다.