Vercel Sessions: 캐시 비용이 늘면 공급자 경로와 실행 ID부터 확인하세요

AI 에이전트의 호출 비용이 늘었다고 바로 더 싼 모델로 바꾸거나 허용 공급자를 늘리지는 마세요. 먼저 Vercel AI Gateway의 Sessions에서 캐시된 입력과 턴별 공급자 경로를 함께 보고, 로그의 한 세션이 정말 하나의 작업인지 구분하는 편이 낫습니다. 같은 시작 문장을 쓰는 자동화 여러 개가 하나로 묶였다면, 합쳐진 비용부터 비교하는 판단 자체가 흔들릴 수 있습니다.

캐시 입력과 공급자 경로를 같은 세션에서 대조한 뒤, 그 세션이 실제 하나의 실행인지 확인하세요. 이 글의 결과물은 설정을 무작정 바꾸는 처방이 아니라, 다음 조사 대상을 고르는 진단표입니다. 세션이 안 보이는 문제, 공급자 이동, 실행 구분 실패, 모델 변경을 서로 다른 문제로 다룹니다.

1. 비용부터 보지 말고 묶음과 경로를 나란히 보세요

공식 변경 공지가 새로 소개하는 것은 요청을 세션으로 묶어 보여주는 로그 화면입니다. 세션 친화성(session affinity) 자체가 이번에 처음 나온 것으로 읽으면 안 됩니다. 함께 읽은 친화성 문서는 이미 2026년 10월 13일 갱신으로 표시되어 있습니다. 여기서 친화성이란 관련 요청이 앞서 사용한 공급자의 캐시를 활용하도록 해당 공급자를 우선 시도하는 동작입니다.[1][2]

Sessions 목록은 해당 작업을 실행한 에이전트나 앱, 비용, 모델, 공급자, 여러 턴에 걸친 캐시 입력을 보여줍니다. 세션을 열면 캐시 적중률과 소요 시간, 턴마다 사용한 모델·타이밍·공급자 경로를 확인할 수 있습니다. 현재 공급자뿐 아니라 이전 공급자도 보인다는 점이 조사에 중요합니다. 총비용 하나로는 보이지 않던 경로 변화와 입력 캐시 상태를 함께 읽을 수 있기 때문입니다.[1]

다음 순서는 이 정보를 활용하기 위한 편집적 제안입니다. 제품이 비용 증가의 원인을 자동 확정한다는 뜻이 아닙니다.

먼저 보이는 현상 바로 단정하지 말 것 다음에 확인할 것
짧은 테스트가 세션 목록에 없다 요청이 실행되지 않았다 최소 턴 수 필터를 해제했는지
같은 세션에서 캐시 입력이 줄고 공급자가 달라졌다 공급자 이동이 유일한 원인이다 해당 턴의 모델, 이전·현재 공급자와 실행 구분
서로 다른 자동화가 같은 세션에 모였다 한 작업의 비용이 갑자기 늘었다 명시적 ID 유무와 동일한 시작 템플릿 사용 여부
같은 세션 ID인데 모델을 바꾼 뒤 캐시가 차갑다 세션 친화성이 고장 났다 처음 쓰는 모델인지, 모델별 캐시를 혼동했는지
단일 턴 필터, 실행 ID와 시작 템플릿, 턴별 모델 및 공급자 경로를 차례로 확인하는 세션 비용 진단 순서

공식 로그 기능에서 도출한 편집적 진단 순서입니다. 먼저 세션의 표시와 묶음을 확인한 뒤 캐시 입력·모델·공급자 경로를 대조합니다. 실측 절감 효과나 자동 원인 판정이 아닙니다. 출처: vercel.com/changelog/ai-gateway-logs-now-show-session-affinity.

한 번의 요청으로 끝난 세션은 최소 턴 수 필터를 해제하기 전까지 숨겨집니다. 따라서 단일 턴 테스트를 확인하려는 사람은 필터부터 살펴야 합니다. 문서의 필터 동작을 로그 유실이나 호출 실패의 증거로 바꾸지 않는 것이 첫 단계입니다.[1]

2. 같은 시작 템플릿은 서로 다른 실행도 묶을 수 있습니다

명시적 세션 ID를 보내지 않으면 Gateway는 대화 시작 부분으로 만든 지문(fingerprint)으로 요청을 묶습니다. 공식 문서에 따르면 팀 ID와 첫 시스템 또는 개발자 메시지, 첫 비시스템·비개발자 메시지, 도구의 이름·설명·스키마 집합을 해시에 사용합니다. 도구 목록의 순서만 달라지는 것은 지문을 구분하는 방법이 아닙니다.[2: Fingerprint requests without a session ID]

가령 매번 같은 시스템 지시와 같은 도구를 사용하고 첫 사용자 메시지도 “작업을 시작하세요”인 자동화를 생각해 보세요. 실제로는 별도의 실행 A와 실행 B인데 시작 조건이 같아 같은 지문에 묶일 수 있습니다. 이는 문서가 설명한 조건을 적용한 가상 예시이며, 이 글에서 그런 호출을 실행하거나 실제 고객 로그를 관측한 것은 아닙니다. 또한 팀 ID가 지문에 들어가므로 서로 다른 팀의 요청이 전역적으로 하나로 합쳐진다는 설명도 아닙니다.

명시적 ID는 이때 실행 단위를 구별하는 수단입니다. 같은 대화·에이전트 실행·워크플로 안에서는 동일한 값을 유지하고, 관계없는 실행에는 별도 값을 배정합니다. 워크플로 안에서 모델을 바꿨다는 이유만으로 ID를 새로 만드는 것과, 별개의 작업에 같은 ID를 계속 쓰는 것은 모두 조사 기준을 흐릴 수 있습니다. 어떤 단위를 하나의 실행으로 볼지는 애플리케이션 설계에서 먼저 정해야 합니다.

같은 팀에서 시작 메시지와 도구가 같은 가상 실행 A와 B가 지문으로 묶이는 경우와 별도 실행 ID로 구분되는 경우의 비교

A와 B는 가상 실행입니다. 같은 팀에서 시작 조건이 같으면 다른 실행도 같은 지문을 가질 수 있습니다. 실행마다 별도 ID를 쓰되 같은 실행 안에서는 유지하고 개인정보는 넣지 않습니다. 실제 고객 로그가 아닙니다. 출처: vercel.com/docs/ai-gateway/models-and-providers/session-affinity.

다음은 실제 전송 코드가 아니라 문서의 필드 위치만 나타낸 설정 조각입니다. SDK 설치, 인증, 모델 지정과 호출은 생략했습니다. 전체 애플리케이션에서 정상 실행됐다는 뜻이 아닙니다.

{
  "providerOptions": {
    "gateway": {
      "sessionId": "run_example_a"
    }
  }
}

같은 실행의 다음 요청에도 같은 providerOptions.gateway.sessionId를 전달합니다. 호환 API에서는 x-session-id 헤더도 사용할 수 있습니다. 문서는 세션 ID를 불투명한 값으로 만들고 개인정보를 넣지 말라고 안내합니다. 길이는 최대 256문자를 권장하며, 더 긴 값은 해시되어 묶음의 안정성이 유지됩니다. 256토큰 제한이나 초과 요청의 무조건 거절로 해석해서는 안 됩니다.[1][2: Identify a session]

이 ID는 작업을 묶는 표식이지 API 인증 키나 권한을 주는 토큰이 아닙니다. 예제 값을 여러 무관한 운영 작업에 그대로 재사용하지 마세요. 진단을 위해 ID를 도입할 때는 기존 인증이나 개인정보 처리 규칙을 느슨하게 바꾸는 작업과 분리하는 편이 안전합니다.

3. 캐시를 위해 허용 공급자 경계를 넓히지 마세요

공식 문서의 순서는 필터를 적용한 뒤 이미 허용된 공급자 안에서 고정된 공급자를 우선하는 것입니다. 제외된 공급자를 친화성이 다시 추가하지 않습니다. only나 데이터 보존 관련 준수 설정으로 제거된 공급자는 우선 대상이 될 수 없습니다. 고정된 공급자가 실패하면 Gateway는 통상적인 다음 공급자를 시도할 수 있으므로, 친화성을 “어떤 상황에서도 한 공급자만 사용한다”는 약속으로 읽어서도 안 됩니다.[2: How it works; Interaction with your routing settings]

이 경계가 비용 조사에도 중요합니다. 공급자 이동이 보였다는 이유만으로 허용 목록을 넓히면 캐시 조사와 데이터 처리 정책 변경이 뒤섞입니다. 먼저 해당 실행에 적용된 기존 제한 안에서 어떤 경로가 가능했는지 살펴보세요. 이동과 캐시 입력 감소가 같은 턴에 보이는 것은 원인 후보를 좁히는 단서이지, 다른 조건을 통제한 인과 실험 결과가 아닙니다.

공급자 허용 및 준수 필터를 먼저 적용한 뒤 허용 범위 안에서만 고정 공급자를 우선하며 제외된 공급자는 다시 추가하지 않는 경계도

필터가 먼저이고 친화성은 이미 허용된 공급자 안에서만 우선순위를 바꿉니다. 고정 공급자가 실패하면 다음 공급자를 시도할 수 있습니다. 공급자 제한을 넓히라는 제안이나 실제 설정 화면이 아닙니다. 출처: vercel.com/docs/ai-gateway/models-and-providers/session-affinity.

적용 범위도 제한되어 있습니다. 세션 친화성은 텍스트와 채팅 요청에 기본 적용되며 임베딩·이미지·실시간 요청까지 같은 동작으로 일반화할 수 없습니다. 따라서 다른 요청 유형의 캐시 문제를 이 화면과 설명만으로 해결할 수 있다고 약속하지 않습니다.[2]

공급자 순서를 정확히 고정해야 하는 애플리케이션이라면 문서의 sessionAffinity: false 옵션과 기존 라우팅 설정의 상호작용을 따로 검토할 수 있습니다. 다만 이 글은 옵션 변경을 실행하지 않았고, 비용 증가만으로 끄거나 켜라고 권하지도 않습니다. 우선 현재 설정과 실제 경로를 비교하는 것이 이 진단표의 범위입니다.[2: Interaction with your routing settings]

4. 같은 세션이라고 모델 사이에서 캐시가 옮겨지지는 않습니다

세션 ID는 관련 작업을 묶는 기준이지만, 캐시의 소유 단위와 같지 않습니다. 문서가 설명하는 프롬프트 캐시는 특정 공급자의 특정 모델에 속합니다. 한 워크플로에서 모델을 바꾸면 새 모델의 고정을 만들고 이전 모델의 고정도 유지할 수 있습니다. 이후 기존 고정이 만료되기 전에 돌아오면 그 모델의 캐시를 가진 공급자로 다시 요청할 수 있습니다.[2: Keep caches warm across models]

여기서 “돌아가서 재사용할 수 있다”와 “다른 모델로 캐시를 이전한다”는 전혀 다릅니다. 아직 사용하지 않은 모델의 첫 요청은 새 캐시를 쓰며 캐시 쓰기 요율이 적용됩니다. 모델을 바꿨는데 캐시 적중이 이어지지 않았다는 사실만으로 로그나 ID 설계가 실패했다고 결론 내리지 마세요. 비교 대상의 모델과 공급자가 같은지부터 구분해야 합니다.

가상 모델 A와 B의 캐시를 분리하고 A로 돌아올 때 기존 고정 만료 전에 재사용할 수 있으나 모델 간 캐시 이전은 불가능함을 표시한 구조도

A·B와 P·Q는 설명용 모델·공급자입니다. 처음 쓰는 모델은 새 캐시를 쓰며, 원래 모델로 돌아가는 재사용은 기존 고정 만료 전이라는 조건이 붙습니다. 최대 8개는 모델 고정 수이지 동시 호출이나 캐시 이전 수가 아닙니다. 출처: vercel.com/docs/ai-gateway/models-and-providers/session-affinity.

문서상 한 세션은 최대 8개 모델의 고정을 보관할 수 있습니다. 이것은 동시 호출 수 보장도, 여덟 모델 사이의 캐시 이동 기능도 아닙니다. 이번 글에서는 공급자별 가격이나 캐시 할인율을 가져와 절감액을 계산하지 않습니다. 다른 제품의 할인율, 과거 글의 라우팅 비용 비율을 이 세션 로그 기능의 성능 수치로 옮기지 않는 이유입니다.[2]

5. 다음 조사 한 가지를 고르는 기록법

위 진단표를 적용한다면 작업 기록에 “세션 ID의 출처, 비교한 턴, 모델과 공급자, 캐시 입력 상태, 유지한 공급자 제한, 아직 확인하지 못한 점”을 남겨 보세요. 예를 들어 “가상 실행 A와 B는 시작 템플릿이 같다. 별도 실행 ID를 배정한 뒤 각 실행의 경로를 따로 확인해야 한다”는 기록은 유용합니다. 반면 “ID를 넣으면 비용이 반드시 내려간다”는 결론은 문서만으로 뒷받침되지 않습니다. 실행을 올바르게 나누는 것과 캐시 적중을 보장하는 것은 다릅니다.

우선순위는 간단합니다. 목록에 안 보이면 필터를 확인하고, 비용 비교가 이상하면 실행 묶음을 확인합니다. 그다음 같은 세션의 캐시 입력과 경로를 대조하고, 모델 변경과 공급자 변경을 구별합니다. 공급자 제한은 이 조사 중에도 그대로 유지할 조건이지 절감 실험을 위해 자동 해제할 장애물이 아닙니다.

이 글은 공식 문서에 근거한 진단 절차이며, 유료 API 호출이나 대시보드 실측으로 절감 효과를 검증한 실험이 아닙니다. 본문 그림은 설명용으로 직접 만든 도식으로 실제 Vercel 화면이나 실제 비용·적중률 측정값이 아닙니다. 문서로 확인한 기능, 편집적으로 제안한 조사 순서, 가상 실행 예시를 구분했으며 비용 절감·지연 개선·출력 동일성을 보장하지 않습니다.

같은 공급자 안에서 요청 앞부분의 변경을 조사하려면 프롬프트 캐시가 깨졌다면: GPT-6에서 먼저 비교할 다섯 가지 변경이 별도 진단 관점을 제공합니다. 모델을 오가는 설계의 문맥 재처리 비용은 코딩 에이전트 라우팅의 KV 캐시 함정에서 가상 계산으로 다룹니다. 두 글의 할인율이나 계산 결과는 이번 Gateway Sessions의 실측 성능이 아니며, 여기서는 이전하지 않습니다.

참고 자료

[1] Vercel 공식 변경 공지 — AI Gateway logs now show session affinity

[2] Vercel 공식 문서 — AI Gateway Session Affinity. How it works, Interaction with your routing settings, Identify a session, Fingerprint requests without a session ID, Keep caches warm across models. 보존 문서의 최종 갱신 표기: 2026년 10월 13일.

댓글

이 블로그의 인기 게시물

체크아웃은 분리됐는데 Git 상태는 공유된다: Codex 0.154 worktree의 세 경계

잠근 작업이 커밋 뒤 다시 나온다: PostgreSQL 에이전트 큐의 소유권 설계

코딩 에이전트는 API 문서보다 AGENTS.md를 먼저 읽었다