스택에 있는 모든 타임아웃은 언젠가 포기하는 클라이언트를 전제로 합니다. 브라우저 탭은 닫힙니다. CI 작업은 정해진 시간에 도달합니다. 사람은 자리를 떠납니다. 로드 밸런서, 게이트웨이, HTTP 라이브러리에서 물려받은 기본값들은 인내심이 초 단위로 측정되는 호출자를 기준으로 조정된 것입니다.
Anthropic에 따르면 Claude Opus 5.5는 작업에 18시간 이상 머무릅니다.
이것은 하나의 매우 긴 HTTP 요청에 대한 주장이 아닙니다. 이것은 일관성에 대한 주장입니다. 즉, 모델이 여러분의 API가 지금까지 처리해 온 그 어떤 것보다 훨씬 긴 세션에 걸쳐 단일 목표를 수행한다는 것입니다. 그러한 세션 중 하나가 여러분의 엔드포인트를 향할 때, 그것은 여러분의 액세스 토큰, 멱등성 윈도우, 배포 주기, 그리고 대부분의 재시도 예산보다 오래 살아남습니다. 그리고 사람과 달리, 그것은 멈춰야 한다는 사실을 알아차리지 못합니다.
이것은 모델 문제가 아니라 API 설계 문제입니다. 무엇이 깨지는지, 무엇을 바꿔야 하는지 살펴보겠습니다.
Anthropic이 실제로 발표한 내용
새 모델에 대한 벤더 수치입니다. 같은 자료를 기준으로 논의해 보겠습니다:
| 속성 | Claude Opus 5.5 |
|---|---|
| API 모델 ID | claude-opus-5-5 |
| 입력 / 출력 | 백만 토큰당 $4 / $20 |
| 캐시된 입력 읽기 | 백만당 $0.20 (캐시 쓰기 $5) |
| 컨텍스트 윈도우 | 1M |
| 최대 출력 | 128k |
| 고속 모드 | 백만당 $8 / $40 |
| Opus 5 대비 실행 비용 | 40% 절감 |
| Opus 5 대비 출력 속도 | 30% 향상 |
| 지속적인 작업 수행 시간 | 18시간 이상 |
| 사용 가능 플랫폼 | Claude Platform, AWS, GCP, Azure |
같은 발표의 벤치마크: Terminal-Bench 4.0 66.4%, OSWorld 2.0 81.8%, AutomationBench 40.0%, FrontierCode v1.1 54.4%, CursorBench 4.0 57.8%, 도구 사용 시 Humanity's Last Exam 67.7%, Chartography 89.0%, GDPval-AA v2.1 1846 Elo, 그리고 성공적인 경계 우회 시도가 85% 감소했습니다.
여러분의 인프라에 직접 영향을 미치는 것은 18시간이라는 수치입니다. 벤치마크 점수는 어떤 모델을 선택할지 바꿉니다. 지속 시간은 여러분의 API가 무엇을 견뎌내야 하는지를 바꿉니다.
더 이상 유효하지 않게 되는 여섯 가지 가정
| 가정 | 예전에는 왜 유효했는가 | 18시간짜리 에이전트가 그것에 하는 일 |
|---|---|---|
| 호출은 하나의 타임아웃 안에서 완료되거나 실패한다 | 호출자는 대화형이었다 | 작업이 안전하게 설정할 수 있는 그 어떤 유휴 타임아웃보다 오래 걸린다 |
| 윈도우가 짧으므로 재시도는 저렴하다 | 중복이 몇 초 간격으로 도착했다 | 중복이 몇 시간 간격으로 도착하고, 중복 제거 윈도우는 이미 닫혀 있다 |
| 시작 시점의 자격 증명은 끝나도 유효하다 | 세션이 토큰 TTL보다 짧았다 | 작업 하나 안에서 토큰이 두세 번 교체된다 |
| 스트림은 연결이다 | 스트림이 응답 하나 동안만 지속되었다 | 연결은 끊기지만 작업은 끝나지 않는다 |
| 클라이언트는 자기가 무엇을 하던 중인지 기억한다 | 상태가 하나의 프로세스 안에 있었다 | 에이전트는 컨텍스트를 압축하고 재시작하며, 여러분이 상기시켜 주기를 필요로 한다 |
| 클라이언트는 자신이 진행 중임을 알 수 있다 | 사람이 스피너를 지켜보았다 | 진행 상황이 없으면 에이전트는 작업을 처음부터 다시 시작하거나 영원히 기다린다 |
각각에는 시시하고 잘 알려져 있으며, 문제가 강제되지 않았기 때문에 보통 건너뛰는 해결책이 있습니다. 이제 무언가가 그것을 강제하고 있습니다.
작업이 아니라 핸들을 반환하세요
가장 가치 있는 변경: 몇 초를 초과할 수 있는 모든 작업은 연결을 붙잡고 있는 대신 즉시 작업 리소스를 반환합니다.
POST /v1/reports HTTP/1.1
Host: api.example.com
Idempotency-Key: 01J9Z4KCQ7M3XN2YB8V6H0
Content-Type: application/json
{"dataset": "orders_2026_q3", "format": "parquet"}
HTTP/1.1 202 Accepted
Location: /v1/jobs/job_01J9Z4KD
Retry-After: 5
Content-Type: application/json
{
"id": "job_01J9Z4KD",
"status": "queued",
"created_at": "2026-09-23T04:12:09Z",
"api_version": "2026-08-01"
}
그다음 상태 리소스는 에이전트가 다음에 무엇을 할지 결정하는 데 필요한 모든 것을 담습니다:
{
"id": "job_01J9Z4KD",
"status": "running",
"progress": { "completed": 41200, "total": 180000, "unit": "rows" },
"started_at": "2026-09-23T04:12:11Z",
"updated_at": "2026-09-23T05:47:02Z",
"expires_at": "2026-09-24T04:12:09Z",
"retry_after_seconds": 15,
"result_url": null,
"error": null
}
실질적인 역할을 하는 것은 네 개의 필드입니다. 명시적인 unit이 있는 progress는 모델이 경과 시간을 추측하는 대신 기다리는 것이 합리적인지 추론할 수 있게 합니다. retry_after_seconds는 폴링 주기를 서버가 통제하게 하는데, 이는 호출자에게 예의라는 개념이 없을 때 중요합니다. expires_at은 핸들이 언제까지 유효한지 에이전트에게 알려주어, 핸들을 잃기 전에 체크포인트를 만들 수 있게 합니다. api_version은 작업을 생성 당시의 계약에 고정하며, 이는 오후 3시 배포와 새벽에 시작된 실행 사이를 가르는 유일한 것입니다.
웹훅을 제공할 수 있다면 웹훅이 더 나은 완료 신호이며, 에이전트에 호출 가능한 주소가 없을 때 폴링이 대체 수단입니다. 장시간 실행되는 에이전트 호출을 위한 폴링과 웹훅 비교 안내에서 그 트레이드오프를 다룹니다. 18시간이라는 지평에서 달라지는 점은 두 가지 모두 필요하다는 것입니다. 왜냐하면 3시간째에 전달된 웹훅은 그 사이 컨텍스트를 압축한 에이전트에게 도달하는데, 그 호출자는 자신이 요청했다는 사실조차 더 이상 기억하지 못하기 때문입니다.
멱등성이 작업보다 오래 살아남게 하세요
대부분의 멱등성 구현은 키를 하루 이하로 저장하며, 그것으로 항상 충분했습니다. 긴 실행 후반에 실패한 프로비저닝 호출을 재시도하는 에이전트는 원래의 중복 제거 윈도우 밖에 떨어지고, 그 시점에 여러분의 API는 아무렇지 않게 작업을 두 번 수행합니다.
세 가지 변경은 비용이 거의 들지 않습니다:
- 윈도우를 공개하세요. 한 번 문서화하고 기대하기만 하는 대신, 응답에 만료 시점을 반환하여 호출자가 추론할 수 있게 하세요.
- 재생했음을 알리세요.
Idempotency-Replayed: true헤더는 조용한 무동작을 에이전트가 대응할 수 있는 것으로 바꿔 줍니다. - 불일치는 소리 내어 거부하세요. 같은 키에 다른 본문이라는 것은 호출자가 자신의 상태를 놓쳤다는 뜻입니다. 오래된 결과를 제공하는 대신 원래 요청 지문과 함께
409를 반환하세요.
HTTP/1.1 200 OK
Idempotency-Replayed: true
Idempotency-Expires: 2026-09-24T04:12:09Z
작업이 진정으로 위험한 경우에는 불투명한 키보다 클라이언트가 제공한 자연 키를 선호하세요. 비즈니스 사실에서 도출된 transfer_id는 에이전트가 11시간 전에 생성한 임의의 UUID가 그렇지 못한 방식으로, 에이전트의 메모리 압축을 견뎌냅니다. 에이전트 멱등성 입문서에 실패 모드들이 있습니다.
자격 증명이 작업 중간에 만료된다고 가정하세요
18시간짜리 실행은 거의 모든 단기 액세스 토큰보다 오래 살아남습니다. 그것이 올바른 보안 태세이지만, 여러분의 API가 그 구분을 읽을 수 있게 만들어 줄 때만 그렇습니다.
토큰이 만료되었을 때는 WWW-Authenticate: Bearer error="invalid_token" 챌린지와 함께 401을 반환하고, 권한이 없는 주체에게는 403을 남겨 두세요. 에이전트는 이 둘을 매우 다르게 취급합니다. 하나는 갱신하고 계속하라는 뜻이고, 다른 하나는 멈추고 보고하라는 뜻입니다. 이 둘을 일반적인 실패로 뭉뚱그리면, 결코 허용되지 않을 일을 네 시간 동안 재시도하며 태워 버리는 에이전트를 얻게 됩니다.
작업을 토큰 인스턴스가 아니라 주체에 묶으세요. 그 사이 교체된 토큰 아래에서 시작된 작업은 동일한 신원에 의해 계속 읽을 수 있어야 하며, 그렇지 않으면 모든 자격 증명 갱신이 진행 중인 작업을 고아로 만듭니다.
스트림을 연결이 아니라 재개 가능한 것으로 취급하세요
긴 스트림은 끊깁니다. 그렇다고 가정하고, 연결이 아니라 재연결을 설계하세요.
서버 전송 이벤트의 경우, 이는 모든 이벤트에 단조 증가하는 id를 부여하고, 재연결 시 Last-Event-ID 요청 헤더를 존중하며, 여러분과 클라이언트 사이의 가장 빡빡한 유휴 타임아웃보다 짧은 간격으로 keepalive 주석을 내보내는 것을 의미합니다. 여러분의 문서에 설정 키 이름을 명시하세요. 읽는 사람이 그것을 바꾸러 가야 하기 때문입니다: AWS 로드 밸런서의 idle_timeout.timeout_seconds, nginx의 proxy_read_timeout, Cloud Run 서비스의 timeout. 요점은 특정 값이 아닙니다. 그 값이 존재하고, 작업보다 짧으며, 서비스가 만들어진 이후로 아무도 그것을 들여다보지 않았다는 것입니다. SSE 스트리밍 가이드에서 전송 형식을 다룹니다. 에이전트 특유의 부분은 재개입니다.
속도 제한 헤더도 평소보다 더 중요합니다. RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset은 모델이 긴 실행에 걸쳐 속도를 조절할 수 있게 하며, 모든 429에 붙는 Retry-After는 추측을 제거합니다. 숫자를 받은 에이전트는 그것을 존중합니다. 아무것도 받지 못한 에이전트는 백오프를 지어내며, 그 발명은 여러분의 것보다 나을 리 없습니다.
비용 측면은 설계 결정입니다
가격 행을 다시 보세요. 입력은 백만 토큰당 $4이고 캐시된 읽기는 $0.20입니다. 이는 에이전트가 가장 자주 다시 보내는 페이로드 부분에서 스무 배 차이이며, 1M 컨텍스트 윈도우에서는 절대 수치가 빠르게 커집니다. $5의 캐시 쓰기는 첫 번째 통과가 일반 읽기보다 약간 더 비싸다는 뜻이므로, 캐싱은 접두사가 실제로 재사용될 때만 이득입니다. 18시간에 걸쳐서는 그렇습니다.
바로 이 지점에서 여러분의 API 표면이 다른 누군가의 청구서에서 비용 입력이 됩니다. 여러분의 OpenAPI 명세, 도구 정의, 오류 목록이 에이전트 컨텍스트의 앞부분에 있다면, 바이트 안정성은 기능입니다. 결정론적으로 직렬화하세요. 키 순서를 안정적으로 유지하세요. 도구 정의를 제자리에서 편집하지 말고 버전을 매기세요. 명세의 겉치레 순서 변경 하나가 캐시된 접두사를 무효화하고 전체를 온전한 입력 가격으로 다시 청구하며, 그 비용을 지불하는 고객은 그것이 여러분 때문이라는 사실을 결코 알지 못할 것입니다.
이 규모는 가상이 아닙니다. OpenAI는 자사의 중간값 연구원이 코딩 에이전트에 하루 $600 이상을 지출하며, 90번째 백분위수는 하루 $7,000을 넘는다고 공개했습니다. 그것이 아무도 최적화하지 않을 때 지속적인 에이전트 작업에 드는 비용이며, 이틀 만에 세 번의 모델 출시가 모두 토큰당 비용이 아니라 작업당 비용을 앞세운 이유 중 하나입니다. 캐싱이 언제 이득으로 돌아오는지에 대한 계산은 Opus 5.5 캐싱 비용 분석에 있습니다.
에이전트가 찾아내기 전에 긴 경로를 테스트하세요
이 중 어느 것도 한 번 보내기를 클릭하고 200을 읽는 것으로 검증할 수 없습니다. 실패는 9시간째에 살아 있습니다.
Apidog에서는 단일 요청이 아니라 전체 수명 주기를 테스트 시나리오로 모델링하세요: 생성 호출이 Location과 Retry-After를 포함한 202를 반환하는지 검증하고, 상태 엔드포인트를 종료 상태까지 반복 호출하며, progress.completed가 결코 뒤로 가지 않는지 검증하세요. 마지막 검증은 어떤 상태 코드 검사보다도 더 많은 실제 버그를 잡아냅니다. 왜냐하면 단조 증가하지 않는 진행 상황이 바로 에이전트가 처음부터 다시 시작하도록 설득하는 것이기 때문입니다.
그다음 목 서버로 의도적으로 망가뜨려 보세요. 스무 번의 폴링 동안 running 상태를 유지하다가 실패하는 작업을 제공하세요. Retry-After가 없는 429를 제공하고 여러분의 클라이언트가 어떻게 하는지 지켜보세요. 작업이 진행 중일 때 갱신 경로가 작동하는지 확인하기 위해 중간에 401을 제공하세요. Apidog의 SSE 테스트는 스트리밍 연결을 열어 둔 채 개별 이벤트를 검증하는데, 이는 Last-Event-ID 재개가 처음부터 재생하지 않고 올바른 커서를 반환하는지 확인하는 유일한 실용적인 방법입니다. 시나리오를 CI에 연결하여 향후 타임아웃 변경이 고객의 밤샘 실행이 아니라 테스트를 실패하게 하세요. Apidog는 무료로 시작할 수 있으며, 한 번 만들어 둔 시나리오는 여러분이 보유한 모든 장시간 실행 엔드포인트를 커버합니다.
짧은 체크리스트
- 긴 작업은 연결을 붙잡지 않고 작업 핸들과 함께
202를 반환한다 - 상태 응답은 진행 상황, 단위, 서버가 선택한 폴링 간격, 만료를 담는다
- 작업은 생성 당시의 API 버전을 고정한다
- 멱등성 윈도우는 공개되고, 재생은 표시되며, 본문이 바뀐 키 재사용은
409를 반환한다 - 만료된 토큰에 대한
401은 거부된 권한에 대한403과 구별 가능하다 - 작업은 토큰 인스턴스가 아니라 주체에 속한다
- 스트림은 이벤트 id를 담고,
Last-Event-ID를 존중하며, 경로상 가장 짧은 유휴 타임아웃 안에서 keepalive를 보낸다 - 모든
429는Retry-After를 담고, 속도 제한 헤더는 항상 존재한다 - 명세와 도구 정의는 바이트 안정적으로 직렬화되어 클라이언트 측 캐시가 따뜻하게 유지된다
Opus 5.5가 이 요구 사항 중 어느 것도 새로 만들어 내지는 않았습니다. 그것은 이것들을 건너뛸 마지막 변명을 제거했습니다. 왜냐하면 균열을 찾기도 전에 포기하던 클라이언트가 이제는 18시간 동안 그 균열을 뚫고 곧장 작업하기 때문입니다.