GitHub Copilot
Claude Code
KubernetesGitHub Copilot의 전사 모델 기본 정책이 정식 제공됐다
GitHub는 Copilot Business와 Copilot Enterprise의 전사 기본 모델 정책을 정식 제공하고, 8월 26일부터 9월 1일까지 조직별로 단계 적용한다고 밝혔다. 정책이 적용되면 이전에 설정하지 않은 일반 제공 모델은 Delegate to default policy 상태로 바뀌어 전사 기본값을 따른다. 기본값이 활성화 상태라면 관리자가 개별 모델을 직접 선택하지 않았어도 사용 가능해질 수 있다.
명시적으로 허용하거나 차단한 모델은 그대로 유지된다. 오픈 웨이트 모델과 GitHub의 데이터 보존 계약에 포함되지 않는 모델도 기본 활성화 대상에서 빠진다. 따라서 실제 가용성은 전사 기본값, 조직과 팀의 상속 상태, 명시적 예외와 모델별 데이터 조건을 함께 봐야 한다.
운영팀은 새 모델 공지가 나올 때마다 허용 목록만 대조해서는 부족하다. 기본 정책 변경 권한을 제한하고, 조직별 상속 및 예외 상태를 정기적으로 내보내며, 단계 적용 기간에는 사용자 집단별 실제 모델 노출도 확인해야 한다.
Copilot 관리형 플러그인 마켓플레이스에 자동 업데이트가 추가됐다
엔터프라이즈 관리 설정의 extraKnownMarketplaces에 autoUpdate: true를 지정하면 Copilot 앱, Copilot CLI와 VS Code 같은 지원 클라이언트가 설치된 플러그인의 새 버전을 확인해 갱신한다. 마켓플레이스 자체는 유효한 strictKnownMarketplaces 허용 목록에 포함돼야 하므로, 자동 갱신이 출처 통제를 우회하지는 않는다.
다만 승인 대상이 저장소 URL에서 계속 변하는 배포 흐름으로 바뀐다. 팀은 마켓플레이스 허용과 자동 갱신을 별도 결정으로 관리하고, 플러그인 버전 변경 기록과 롤백 절차를 남겨야 한다. 모델 정책과 마찬가지로 미설정 및 자동 상태가 실제 실행 결과를 바꿀 수 있기 때문이다.
Claude Code 2.1.247이 에이전트 모델 폴백과 비용 점검을 보강했다
Claude Code 2.1.247은 서브에이전트가 첫 호출에서 지정 모델의 404 오류를 받으면 세션의 모델 폴백 체인을 사용하도록 바꿨다. 오류 세부 정보도 함께 보고하므로, 단순 실패 대신 어떤 모델 선택이 대체됐는지 추적할 수 있다. 에이전트별 모델 고정이 필요한 작업이라면 성공 여부뿐 아니라 실제 실행 모델도 로그에 남겨야 한다.
/claude-api cost-optimize는 프로젝트의 API 지출을 분석해 프롬프트 캐시, 토큰 사용, batch, effort와 모델 선택을 점검한다. 조직은 spinnerTipsOverride로 자체 안내를 배포하고 피드백 초안 기능도 제어할 수 있다. 비용 최적화와 실행 정책이 개인의 CLI 사용법을 넘어 공유 설정으로 이동한 변화다.
Transformers 5.16이 텐서 병렬화와 캐시 계약을 바꿨다
Transformers 5.16.0은 기존 텐서 병렬 구현을 DTensor 기반 백엔드로 옮기고, 계층별 캐시 설정과 파이프라인 병렬 추론을 확장했다. 동시에 FuyuProcessor의 image_patch_indices 제거처럼 호출부 수정이 필요한 변경도 포함한다. 같은 날 나온 5.16.1은 텐서 병렬 API의 하위 호환성을 일부 복구했다.
두 릴리스가 짧은 간격으로 이어졌다는 점 자체가 업그레이드 전략을 말해 준다. 5.16.0만 기준으로 마이그레이션 코드를 확정하지 말고 5.16.1에서 복원된 경로를 포함해 실제 모델, 캐시와 분산 실행 테스트를 다시 해야 한다.
vLLM 0.28이 대규모 서빙 기능과 호환성 변경을 함께 묶었다
vLLM 0.28은 디스크를 포함한 계층형 KV 캐시 오프로딩, Model Runner V2의 분리형 실행과 weight offloading, gRPC 멀티모달 경로를 확장했다. 추론 자원을 더 넓게 배치할 수 있지만 기본값도 바뀌었다. 배치 토큰 상한이 8,192에서 16,384로 늘고 일부 Mamba 모델의 prefix caching이 기본 활성화된다.
호환성 변경은 별도 점검이 필요하다. bitsandbytes가 외부 플러그인으로 분리됐고 런타임 KV scale 계산과 override_attention_dtype가 제거됐으며, KV 오프로딩 메트릭 이름도 바뀌었다. 또한 API 키가 모든 엔드포인트를 보호하지 않는다는 보안 주의가 명시됐다. 배포 전에는 시작 옵션과 이미지 의존성, 메트릭 쿼리, 인증 경계를 한 묶음으로 회귀 테스트해야 한다.
Ollama 0.33.1이 MLX 구조화 출력과 모델 로딩 안정성을 보완했다
Ollama 0.33.1은 MLX 실행기에 구조화 출력을 추가하고 Qwen3.8 Flash Next를 지원한다. 느린 저장소에서 모델을 불러올 때 Metal GPU 시간 초과가 발생하는 경로도 보완했다. macOS 로컬 추론에서 JSON 형태의 응답을 사용하는 팀이라면 스키마 준수와 대용량 모델의 첫 로딩 시간을 함께 확인할 만한 패치다.
Spring Modulith 2.2 M1이 다음 Spring 플랫폼 기준선으로 이동했다
Spring Modulith 2.2 M1은 Spring Boot 4.2 M1과 Spring Framework 7.1 M1로 기준선을 옮겼다. Namastack Outbox 통합과 자동 구성 등록도 보완됐다. 함께 나온 2.1.1, 2.0.8과 1.4.13은 주로 의존성 갱신과 수정 사항을 안정 계열에 전달한다.
마일스톤은 즉시 운영 반영할 버전이라기보다 다음 Spring 세대의 호환성 조합을 미리 검증하는 기준이다. 모듈 이벤트 외부화나 outbox를 사용하는 프로젝트는 현재 안정 계열의 수정과 2.2의 플랫폼 전환을 분리해 시험하는 편이 낫다.
Kubernetes 1.37이 제어면 복구와 AI 워크로드 스케줄링을 진전시켰다
Kubernetes 1.37은 67개 개선을 담았다. API 서버의 watch cache 초기화가 안정 단계에 들어가 재시작과 복구 때 etcd로 요청이 몰리는 위험을 줄이고, 처리하지 못하는 요청은 429 Too Many Requests와 Retry-After로 제어한다. 사용자 정의 컨트롤러도 429 응답에 지수 백오프를 적용하는지 확인해야 한다.
StorageVersionMigration API도 정식 제공돼 API 또는 암호화 방식 변경 뒤 기존 객체를 선언적으로 다시 저장할 수 있다. 한편 AI 학습 작업에 중요한 gang scheduling은 베타로 올라가 Pod 그룹을 필요한 자원이 모였을 때 함께 배치하고, 부분 배치로 인한 교착과 자원 낭비를 줄인다.
업그레이드에서는 안정 기능이라는 이름만 볼 수 없다. SELinux 볼륨 마운트 방식의 기본 변화는 서로 다른 레이블로 볼륨을 공유하던 Pod의 시작을 막을 수 있고, cgroup v1 노드는 명시적 임시 설정 없이는 kubelet이 시작되지 않는다. 제어면, 노드와 워크로드 호환성을 나눠 검증해야 한다.
Terraform 1.16이 plan과 apply 사이의 상태와 파괴 방지 표현을 넓혔다
Terraform 1.16은 공급자가 plan과 apply 사이에 전용 데이터를 보존할 수 있게 하고, terraform_data의 store 블록으로 일시적이거나 민감한 값을 전달한다. 모듈 내부 import와 lifecycle의 destroy = false도 추가돼 가져오기와 삭제 방지 의도를 구성에 더 직접적으로 표현할 수 있다.
리소스 액션의 실패 모드는 중단, taint 또는 계속 진행으로 나뉘고, 파괴 전후 이벤트도 지원한다. 파이프라인은 새 표현을 도입하기 전에 저장 계획 파일의 처리 방식, 민감 정보 노출과 실패 모드별 후속 상태를 검증해야 한다.
Mountpoint for Amazon S3가 컨테이너 메모리 한도를 인식한다
Mountpoint for Amazon S3는 명시적인 메모리 한도를 받거나 컨테이너 환경의 예산을 자동 감지할 수 있다. 메모리 압박이 커지면 작업 속도를 낮춰 프로세스가 종료되는 위험을 줄인다. EKS에서 모델과 데이터 파일을 S3에서 읽는 작업이라면 Pod 제한과 Mountpoint 예산을 맞추고, 제한에 가까워졌을 때 처리량 저하가 재시도 폭증으로 이어지지 않는지 확인해야 한다.