Google Gemini
Claude Code
Ollama
Apache Tomcat
AWSGemini 3.8 Live 두 모델이 실시간 음성 API에 정식 공개됐다
Gemini API 출시 노트 | Gemini 3.8 Live 모델 문서 | Extended Thinking 모델 문서
전화 상담이나 실시간 음성 에이전트에서 함수 호출을 기다리는 동안 대화가 멈추면 사용자는 응답이 끊겼다고 느낀다. Google은 Live API에 gemini-3.8-live와 gemini-3.8-live-extended-thinking을 정식 공개했다. 전자는 낮은 지연의 대화에, 후자는 대화 도중 더 긴 배경 추론이 필요한 흐름에 맞춘 선택지다.
두 모델은 텍스트, 이미지, 오디오, 비디오를 입력으로 받고 텍스트와 오디오를 출력한다. 모델 문서의 한도는 입력 131,072토큰과 출력 65,536토큰이다. 일반 Live 모델에는 thinking_level이나 thinking_config을 세션 설정으로 넘기지 않아야 한다. 확장 추론 모델은 비동기 함수 호출을 사용하며, 도구 응답과 대화 종료를 turnComplete 하나로 판정하지 말고 세션의 유휴 상태를 확인해야 한다.
기존 gemini-3.1-flash-live-preview 통합을 교체할 팀이라면 모델 ID만 바꾸지 말고 함수 호출 방식, 세션 이벤트, 응답 지연을 함께 회귀 테스트해야 한다. 가격과 데이터 처리 조건은 적용 플랫폼과 사용량에 따라 별도 확인이 필요하므로 두 모델을 같은 단가나 보존 정책으로 가정하지 않는 편이 안전하다.
Claude Code 2.1.273이 명령 승인과 작업 경로 우회를 막았다
코딩 에이전트에 파일 접근과 명령 실행을 허용한 팀이라면 허용 목록이 실제로 어디까지 적용되는지가 중요하다. Claude Code 2.1.273은 명령 권한 검사가 명령을 완전히 분석하지 못했을 때 승인 프롬프트를 건너뛰던 경로와, 서브셸 안의 위험한 rm을 감추는 경우를 수정했다.
관리형 MCP 제한을 MDM이 지정했는데 서버 관리 설정에서 무시되던 문제, 작업 디렉터리 밖의 메모리 경로가 로드되거나 색인되는 문제도 함께 고쳤다. 조직 정책이 있다고 해서 그 정책이 모든 실행 경로에 적용된다고 볼 수 없었던 부분이다. 관리자가 정한 읽기 경계와 사용자 승인 흐름을 이용하는 환경은 2.1.273으로 올린 뒤 차단 명령, 서브셸, 외부 경로 읽기의 회귀 시나리오를 다시 확인할 가치가 있다.
Gemini CLI 0.60.0이 MCP OAuth와 확장 경로 검사를 강화했다
여러 MCP 서버와 확장을 연결한 개발 환경에서는 로그인 자체보다 토큰이 올바른 발급자와 확장에만 전달되는지가 더 중요하다. Gemini CLI 0.60.0은 MCP OAuth 흐름에 RFC 9207 발급자 식별을 적용하고, 확장 로더의 경로 경계 검사를 강화했다.
확장이 실행 환경 변수를 바꿀 때 동의를 요청하고 런타임 동작을 바꾸는 값을 정리하도록 바뀌었다. 작업공간의 심볼릭 링크, 시스템 전체 설정 파일의 권한과 소유권, Windows NTFS 짧은 경로, 신뢰하지 않는 도구 출력의 출처 메타데이터도 검사 대상이다. 확장과 MCP 서버를 사내 표준으로 배포한다면 기존 확장이 새 경계에서 차단되는지 시험하고, 승인 요청이 뜰 때 어떤 환경 변경을 허용할지 정책을 분명히 해야 한다.
Ollama 0.34.1이 MLX 모델 생성과 GGUF 변환 경로를 바꿨다
로컬 모델 배포 파이프라인에서 ollama create에 safetensors와 GGUF를 같은 방식으로 넣었다면 0.34.1에서 작업 경로를 나눠야 한다. MLX safetensors 모델 생성은 더 이상 실험 기능이 아니지만 GGUF를 만들기 위한 safetensors 변환과 양자화에는 llama.cpp 도구를 사용해야 한다.
새 모델을 만들 때 typical_p도 더는 설정할 수 없다. 이미 존재하는 GGUF 모델의 지원은 유지된다. 대규모 모델 라이브러리의 /api/tags 응답 개선과 Apple Silicon의 MLX 메모리 처리 수정도 포함됐다. 모델 빌드 스크립트는 입력 형식과 양자화 단계를 분리하고, 기존 Modelfile의 typical_p 사용 여부를 먼저 찾아보는 것이 직접적인 마이그레이션 작업이다.
Tomcat 9, 10, 11 유지보수 릴리스가 TLS와 WebSocket 처리를 보완했다
Apache Tomcat 9.0.122, 10.1.60, 11.0.26 공지 | Tomcat 11 변경 기록
Java 웹 서버에서 TLS 종료와 WebSocket을 Tomcat에 맡긴다면 9월 15일 나온 세 유지보수 계열의 변경을 살펴볼 만하다. Tomcat 9.0.122, 10.1.60, 11.0.26은 각 계열의 Tomcat Native 최소 버전을 올리고 RewriteValve, OCSP와 ALPN 처리, WebSocket 메시지 전체에 적용되는 쓰기 시간 초과를 보완했다.
9 계열의 Native 최소 버전은 1.3.9, 10.1과 11 계열은 2.0.16이다. 세 버전 중 하나를 고르는 문제는 아니다. 현재 사용하는 Servlet 세대에 맞는 계열에서 패치 버전을 선택하고, Tomcat Native와 OpenSSL 조합, 프록시 뒤 TLS 핸드셰이크, 오래 걸리는 WebSocket 쓰기를 후보 환경에서 검증해야 한다. 9 계열에서 10 계열로 넘어가는 javax.*에서 jakarta.*로의 마이그레이션은 이번 패치와 별개다.
SageMaker 학습과 처리 작업에 인스턴스 우선순위 목록이 생겼다
학습 작업이 특정 인스턴스 유형의 공급 부족 때문에 대기한다면 동일 작업에 대체 자원을 우선순위대로 제시할 수 있게 됐다. SageMaker AI의 학습 및 처리 작업은 인스턴스 유형과 수량의 선호 목록을 받고, 사용 가능한 첫 선택지를 사용한다.
이는 모델 코드의 변경보다 작업 제출과 용량 계획의 변경에 가깝다. 현재 예약 용량이나 Flexible Training Plans를 쓰는 팀은 대체 인스턴스에서 메모리, GPU 유형, 분산 학습 구성이 동등하게 동작하는지 확인해야 한다. 우선순위 목록은 가용성을 높이는 장치이지 다른 하드웨어에서 같은 처리 시간이나 비용을 보장하지 않는다.
Google Cloud API Gateway가 생성 시 스트리밍 모드를 선택할 수 있게 됐다
실시간 AI 응답을 프록시하는 API Gateway에서 SSE나 WebSocket 연결이 필요했다면 게이트웨이 생성 방식이 달라졌다. Cloud SDK 585.0.0의 gcloud api-gateway gateways create에 --enable-streaming이 추가되어 HTTP 청크, SSE, WebSocket, gRPC/HTTP2 양방향 스트리밍을 제공하는 게이트웨이를 만들 수 있다.
스트리밍 모드는 생성 시에만 지정할 수 있다. 기존 게이트웨이에 플래그를 나중에 적용하는 변경 절차가 아니라 새 게이트웨이 생성과 트래픽 전환을 계획해야 한다는 뜻이다. 같은 버전에서 gcloud auth enterprise-certificate-config create의 오래된 --tls-offload도 제거됐으므로, 해당 명령을 자동화한 팀은 ECP HTTP Proxy 경로로 이전해야 한다.
GitHub가 HTTPS 연결의 SHA-1 지원을 종료했다
오래된 빌드 이미지에서만 GitHub clone이나 API 호출이 실패하기 시작했다면 코드나 저장소 권한보다 TLS 구성을 먼저 볼 필요가 있다. GitHub는 9월 15일 github.com과 파트너 CDN에서 HTTPS의 SHA-1 사용을 예정대로 종료했다. GitHub Enterprise Cloud와 데이터 레지던시 환경에도 적용되지만 GitHub Enterprise Server에는 적용되지 않는다.
영향 범위는 브라우저, API 클라이언트, HTTPS로 push와 pull을 하는 Git 클라이언트다. 실패하는 CI 이미지는 Git 버전뿐 아니라 그 Git이 쓰는 TLS 라이브러리와 운영체제 구성까지 함께 갱신해야 한다. 이것은 Git 객체 ID로 쓰는 SHA-1을 없앴다는 뜻이 아니라 HTTPS 연결에서 오래된 SHA-1 방식의 사용을 중단한 변경이다.