이번 주의 출시 소식은 두 가지 주제로 모아집니다: 에이전트 시스템 (agentic systems)에 대한 인프라 비용을 줄이는 것과, 더 낮은 비용으로 추론 (inference) 처리량을 높이는 것입니다. 멀티 턴 에이전트 루프 (multi-turn agent loops)를 연결하든, CPU 집약적인 분류기 (classifiers)를 대규모로 실행하든, 혹은 매 라운드 트립 (round-trip)마다 발생하는 컨텍스트 재전송 (context re-transmission) 비용을 지불하지 않으려 하든, 여기에는 구체적이고 즉시 배포 가능한 옵션들이 있습니다.

Claude Managed Agents 이제 Chat SDK와 연동 가능

Anthropic의 관리형 에이전트 런타임(managed agent runtime)—모델, 도구, 상태 및 실행 루프 포함—이 이제 타입 안전 핸들러 (type-safe handler)를 통해 Vercel의 AI Chat SDK와 직접 통합됩니다. SDK의 어댑터 계층 (adapter layer) 덕분에, 작동하는 에이전트를 웹훅 핸들러 (webhook handlers), 세션 저장소 (session stores), 또는 플랫폼별 글루 코드 (platform-specific glue)를 직접 작성하지 않고도 Slack, WhatsApp, Discord 또는 웹 클라이언트에 배포할 수 있습니다.

이것이 실제로 제거하는 것들: 직접 소유해야 했던 에이전트 루프 (agent loop), 어딘가에 유지해야 했던 세션 관리 (session management), 그리고 직접 유지보수해야 했던 플랫폼별 어댑터 코드 (per-platform adapter code)입니다. Anthropic 자격 증명을 입력하고 핸들러를 구성하면, SDK가 턴 (turns) 간의 상태 스레딩 (state threading)을 처리합니다.

지금 이것이 중요한 이유: 이전에는 멀티 플랫폼 에이전트를 구축하려면 제어 권한이 제한된 관리형 플랫폼을 선택하거나, 직접 인프라를 구축하는 것 중 하나를 선택해야 했습니다. 이 방식은 실용적인 중간 지점에 위치합니다. Anthropic은 실행 모델 (execution model)을 소유하고, Chat SDK는 전송 (transport)을 소유하며, 사용자는 작업 정의 (task definition)를 소유합니다. 퀵스타트 (quickstart)는 플랫폼 등록 없이 브라우저에서 작동하는 리서치 애널리스트 (research analyst)를 제공하며, 이는 복잡성에 대한 합리적인 첫 번째 신호입니다.

판결: 배포하십시오 (Ship). 이미 에이전트 프레임워크 (agent frameworks)를 평가 중이고 Anthropic API 키를 가지고 있다면, 여기서의 설정 비용은 낮고 건너뛸 수 있는 구축 범위는 매우 넓습니다. 제약 사항은 에이전트 런타임 측의 락인 (lock-in)입니다—전념하기 전에 Anthropic의 관리형 루프가 무엇을 노출하고 무엇을 노출하지 않는지 이해하십시오.

Gemini 2.5 Flash 토큰 사용량 17% 절감

Gemini 2.5 Flash는 출력 토큰 100만 개당 7.50달러의 비용으로 2.0 Flash 대비 출력 토큰 양을 17% 줄여줍니다. 이와 별개로, 2.0 Flash-Lite는 지연 시간(latency)에 민감한 워크로드(workloads)를 위해 초당 350 토큰의 처리량을 달성합니다. 이들은 동일한 문제를 해결하는 동일한 모델이 아닙니다. 2.5 Flash는 기존 워크로드의 비용 절감을 목표로 하며, Flash-Lite는 멀티 에이전트(multi-agent) 및 문서 처리 파이프라인에서의 처리량(throughput) 한계 돌파를 목표로 합니다.

17%의 토큰 절감은 귀하의 작업 혼합(task mix)에서 유지된다면 실제 수치이겠지만, 균일하게 나타나지는 않을 것입니다. 구조화된 출력(Structured output) 작업, 긴 추론 체인(reasoning chains), 그리고 요약(summarization) 작업은 다르게 동작할 것입니다. 마이그레이션(migration) 경로는 최소한입니다. 엔드포인트(endpoint) 변경만 필요하며, 프롬프트 엔지니어링(prompt engineering)은 요구되지 않습니다.

지금 이것이 중요한 이유: 추론(Inference) 비용은 프로덕션 에이전트 시스템(agentic systems)에서 확장을 가로막는 주요 제약 사항입니다. 출력 토큰의 17% 절감은 대량의 워크로드 전반에 걸쳐 복리로 작용합니다. Flash-Lite의 처리량 한계는 병렬 에이전트 실행이나 배치 문서 작업에서 속도 제한(rate limits) 또는 지연 시간 장벽에 부딪히고 있다면 중요하게 작용합니다.

결론: 평가 후 배포하십시오. 프로덕션 트래픽을 전환하기 전에 새로운 엔드포인트를 대상으로 기존 벤치마크 제품군(benchmark suite)을 실행하십시오. 실제 워크로드에서 절감 효과를 확인하고 나면 마이그레이션은 매우 간단합니다. 17%가 직접적으로 적용될 것이라고 가정하지 말고, 직접 측정하십시오.

OpenAI, 취약점 스캐닝을 위한 Codex Security CLI 출시

@openai/codex-security npm 패키지는 CLI 및 CI 파이프라인(pipeline)에 AI 지원 취약점 스캐닝 기능을 추가합니다. Node.js 22+ 및 Python 3.10+가 필요합니다. 인증은 ChatGPT 자격 증명과 API 키를 모두 지원합니다. 프로젝트 루트에서 scan .을 실행하는 것이 가장 이상적인 경로(happy path)입니다.

이 도구는 별도의 대시보드나 SaaS 포털이 아닌, 환경 변수(env-var) 기반의 단계로서 기존 CI에 삽입됩니다. 상태 관리(State management)는 환경 간 재현 가능한 결과를 위해 처리되며, 이는 비결정론(non-determinism)이 노이즈를 유발하는 CI 파이프라인에서 중요합니다.

지금 이것이 중요한 이유: 역사적으로 SAST (정적 분석 보안 테스트) 도구는 구성 및 튜닝을 위해 전담 보안 엔지니어링 시간이 필요했습니다. 만약 이것이 설정 비용을 npm install과 API 키 입력 수준으로 낮춘다면, 전담 보안 기능이 없는 팀들의 진입 장벽을 낮춰줄 것입니다. 진짜 관건은 오탐률 (false positive rate)과 보안 전문 지식 없이도 발견된 항목들을 분류 (triage)할 수 있을 만큼 실행 가능한 정보인지 여부입니다.

판결: 평가 필요. 도구를 설치하여 취약점이 알려진 브랜치에서 실행해 보고, 기존 도구와 출력을 비교해 보세요. 시도하는 데 드는 마찰이 진정으로 낮습니다. 여러분의 코드베이스에서 신호 품질 (signal quality)을 검증하기 전까지는 기존의 SAST 커버리지를 대체하지 마세요.

AI Gateway, Responses API를 위한 WebSocket 지원 추가

Vercel의 AI Gateway가 이제 wss://ai-gateway.vercel.sh/v1/responses에서 지속적인 WebSocket 연결을 지원합니다. 매 HTTP 라운드 트립 (round-trip)마다 전체 컨텍스트를 다시 전송하는 대신, 새로운 입력과 previous_response_id를 함께 보냅니다. Vercel의 테스트 결과, 20개 이상의 도구 호출 (tool calls)이 포함된 멀티 턴 (multi-turn) 워크플로우는 엔드 투 엔드 (end-to-end) 실행 속도가 약 40% 빨라졌습니다. store=false 및 데이터 보존 제로 (ZDR, zero data retention) 설정과도 호환됩니다.

여기서의 프로토콜 변화는 의미가 큽니다. 턴이 거듭될수록 컨텍스트가 커지는 상태 비저장 (stateless) HTTP 방식에서, 게이트웨이가 대화 상태를 유지하는 상태 저장 (stateful) 프레임 모델로 이동하는 것입니다. 이는 단순한 교체(drop-in swap)가 아닌 실제적인 아키텍처의 변화입니다.

지금 이것이 중요한 이유: 컨텍스트 재전송 오버헤드는 빈번한 도구 호출이 발생하는 에이전트 루프 (agent loops)에서 실질적인 병목 현상입니다. 만약 에이전트가 작업당 20회 이상의 라운드 트립을 수행한다면, 누적되는 대역폭과 지연 시간 (latency)이 상당할 것입니다. 프롬프트를 압축하는 대신 전송 계층 (transport layer)에서 이 문제를 해결하는 것이 올바른 접근입니다.

판결: 이미 멀티 턴 워크로드를 사용하며 AI Gateway를 이용 중이라면 도입하세요. wss:// 엔드포인트로 전환하는 과정의 마찰은 적습니다. 아직 AI Gateway를 사용하지 않고 있다면, 전송 계층을 최적화하기 전에 플랫폼 전체의 적합성을 평가하여 도입 여부를 결정하세요.

LFM2.5 인코더, 8K 토큰에서 더 큰 모델과 대등한 성능 달성

두 개의 새로운 양방향 인코더(bidirectional encoders)—230M 및 350M 파라미터—는 8,192 토큰의 네이티브 컨텍스트 윈도우(context window)를 갖추고 있으며, CPU에서 ModernBERT보다 3.7배 높은 처리량(throughput)으로 분류(classification) 및 시맨틱 라우팅(semantic routing) 작업을 수행합니다. 이 모델들은 오픈 웨이트(open-weight) 모델로 Hugging Face에서 사용할 수 있으며, 표준 transformers를 통해 설치할 수 있습니다. 법률 문서를 대상으로 하는 미세 조정(fine-tuning) 튜토리얼도 포함되어 있습니다.

이는 생성(generation)이 필요하지 않은 NLP 작업 부류, 즉 의도 라우팅(intent routing), 개인정보(PII) 탐지, 정책 분류(policy classification), 문서 레이블링(document labeling) 등에 있어 매우 중요합니다. 이러한 워크로드(workloads)는 대량으로 실행되며, GPU 가용성이나 비용 문제로 인해 병목 현상이 빈번하게 발생합니다.

지금 중요한 이유: 만약 프로덕션 환경에서 CPU 기반으로 BERT급 모델을 실행하고 있으며 처리량 한계에 부딪히고 있다면, 이것은 직접적인 교체 경로가 됩니다. 또한 8K 컨텍스트 윈도우는 이전에 청킹(chunking)이 필요했던 문서 수준의 작업들을 가능하게 합니다.

결론: CPU 집약적인 분류 워크로드에 도입하십시오. 다운스트림(downstream) 작업을 위해서는 미세 조정이 필요하지만, 제공된 튜토리얼이 그 비용을 낮춰줍니다. 이미 ModernBERT나 유사한 모델을 사용 중이라면, 전환하기 전에 본인의 작업 분포(task distribution)에 대해 벤치마크를 실행해 보십시오.

Vercel, Python Functions를 위한 WebSocket 지원 추가

Vercel은 이제 Python Functions에서 ASGI 및 WSGI WebSocket을 네이티브로 지원합니다. FastAPI, Django, Flask 앱은 별도의 WebSocket 서버 없이도 지속적인 양방향 연결을 처리할 수 있습니다. 최소 요구 사양은 Python 3.9+입니다. FastAPI 및 Flask를 위한 스타터 예제가 제공됩니다.

운영 측면의 이점은 명확합니다. Python 백엔드를 사용하여 Vercel에서 스트리밍 AI 기능을 구축하는 경우, 더 이상 WebSocket 트래픽을 별도의 서비스나 자체 호스팅 인프라를 통해 라우팅할 필요가 없습니다.

지금 중요한 이유: 스트리밍 채팅과 실시간 에이전트 피드백은 AI 애플리케이션의 필수 요소입니다. 이를 별도의 WebSocket 제공업체를 통해 실행하는 것은 배포 복잡성을 높이고 장애 지점(failure domain)을 추가합니다. Vercel의 네이티브 지원은 이 두 가지 문제를 모두 제거합니다.

결론: Python을 사용 중이고 Vercel을 이용하고 있다면 바로 배포하세요. 설정 방식은 표준 ASGI/WSGI 패턴을 따르므로 새로 배워야 할 추상화 계층(abstractions)이 없습니다. 만약 Vercel을 사용하지 않는다면, 이것이 귀하의 인프라 계산(infrastructure calculus)을 변화시키지는 않습니다.