Google Gemini
GitHub Copilot
AWS
TerraformGemini 3.8 Flash가 장기 실행 코딩과 에이전트 작업용 정식 모델로 공개됐다
Google은 gemini-3.8-flash를 정식 제공하기 시작했다. 공식 설명은 이 모델을 Flash 계열에서 가장 지능적인 모델로 소개하며 장기 소프트웨어 엔지니어링, 자율 에이전트와 복잡한 기업 워크플로를 주요 대상으로 든다. 빠른 단발 응답보다 여러 단계의 계획과 도구 호출을 이어 가는 작업에 초점을 맞춘 GA endpoint가 생겼다는 점이 핵심이다.
정식 모델이라도 기존 Flash의 drop-in replacement로 가정하면 안 된다. 코드 수정 agent에서는 같은 issue와 repository snapshot을 고정한 뒤 완료율, 잘못된 tool 호출, rollback 횟수와 wall-clock latency를 비교해야 한다. 긴 실행에서는 평균 token보다 실패 뒤 재시도까지 포함한 task당 총비용이 더 중요한 지표다.
Java 또는 Kotlin 서비스에서 model routing을 운영한다면 gemini-3.8-flash를 별도 canary로 등록하고 timeout, tool schema 오류와 안전 필터 응답을 기존 모델과 나란히 측정하는 편이 좋다. 자동 승격 조건도 단순 정답률보다 성공한 작업당 비용과 사람이 되돌린 변경 비율까지 포함해야 한다.
GitHub Copilot의 콘텐츠 제외가 app과 CLI까지 정식 지원된다
GitHub Copilot의 content exclusion이 Copilot app과 CLI에서 정식 지원된다. repository에 지정한 제외 파일과 경로를 IDE 안의 completion뿐 아니라 agent가 작업하는 별도 client에도 적용할 수 있게 됐다. 비밀이 들어 있는 설정, 생성 산출물이나 규제 대상 코드가 prompt 문맥으로 들어가는 범위를 한 정책으로 줄일 수 있다.
다만 제외는 접근 제어 자체가 아니다. agent가 shell이나 별도 tool로 파일을 읽는 권한, build log에 노출되는 값과 이미 생성된 index는 각각 다른 경계다. 정책이 적용되는 client와 기능 범위를 확인하고 deny path의 symlink, 대소문자와 하위 repository 처리도 실제 환경에서 시험해야 한다.
조직 단위 적용 후에는 알려진 sentinel 문자열을 민감 경로에 둔 테스트 repository로 검증하는 것이 안전하다. Copilot app, CLI와 IDE에서 해당 문자열이 답변이나 인용에 나타나지 않는지 확인하고, 정책 배포가 지연되거나 client가 offline일 때의 동작도 기록해야 한다.
gRPC Java 1.84.0이 HTTP/2 스트림 제한 취약점과 OOM 경로를 막는다
gRPC Java 1.84.0은 Netty server의 client-initiated stream 한도가 handshake 전에 우회될 수 있던 취약 경로를 닫았다. Netty의 CVE-2026-47244 수정이 gRPC의 직접 초기화 경로에는 적용되지 않아 SETTINGS_ACK 전 활성 stream 수가 사실상 무제한이 될 수 있었고, 이번 버전은 connection 생성 시점부터 한도를 설정한다. 연속된 작은 buffer를 병합하다 OOM에 이를 수 있는 core 경로도 수정됐다.
동시에 Android API 23 이하 지원을 중단해 최소 API가 24로 올라갔다. server library 교체와 mobile client 호환성 변화가 한 릴리스에 함께 있으므로 공용 dependency catalog를 쓰는 조직은 backend patch와 Android baseline 변경을 분리해서 검토해야 한다. Netty는 4.2.16, netty-tcnative는 2.0.81로 갱신된다.
외부에 노출된 gRPC server는 우선순위가 높다. 최대 concurrent stream 설정을 고정하고 SETTINGS_ACK 전후에 다수 stream을 여는 부하 테스트로 제한이 유지되는지 확인해야 한다. OOB channel 종료, xDS shutdown과 servlet backpressure 수정도 포함됐으므로 connection churn과 graceful shutdown 회귀를 함께 보는 편이 좋다.
AWS Lambda SnapStart가 컨테이너 이미지 함수의 초기화도 스냅샷으로 줄인다
AWS Lambda가 container image로 배포한 함수에도 SnapStart를 지원한다. 최대 10GB의 image layer를 내려받고 runtime과 application code를 초기화하던 과정을 배포 시점 snapshot으로 만들고 invocation 때 복원해 수 초의 시작 시간을 sub-second까지 줄이는 방식이다. 기존에는 Java, Python과 .NET managed runtime의 zip 함수가 중심이었지만 이제 조직의 container 배포 표준을 유지하면서 cold start를 줄일 수 있다.
AWS base image를 쓰는 Java 11 이상, Python 3.12 이상과 .NET 8 이상은 zip archive와 같은 방식으로 켤 수 있다. 그 밖의 base image와 custom image는 runtime hook과 restore 동작을 별도로 맞춰야 한다. 모든 commercial region에서 제공되지만 뉴질랜드와 타이베이 region은 제외된다.
Java 함수에서는 snapshot 이후 고유해야 하는 random seed, credential, socket과 database connection을 restore hook에서 재설정하는지 확인해야 한다. 배포 전후의 init duration, restore duration과 p95 cold start를 같은 image digest로 비교하고, image 크기를 줄이는 작업과 SnapStart 효과를 분리해 측정해야 한다.
Terraform 1.16.1이 실행 대기와 import 및 destroy 순서 오류를 고쳤다
Terraform 1.16.1은 실패한 run task에 policy evaluation이 남아 있을 때 CLI가 무기한 멈추는 문제를 고쳤다. sensitive value를 참조한 import identity와 잘못된 state show 주소에서 발생하던 panic, 여러 for_each 또는 count instance를 대상으로 한 import block 누락도 수정했다.
리소스 교체 순서와 직접 연결되는 수정도 있다. 일부 변경 조합에서 create_before_destroy 순서가 잘못되던 문제가 바로잡혔고 stack의 provider lock file과 configuration version 호환성 검증도 강화됐다. 단순한 CLI 안정화가 아니라 실제 plan 및 apply 순서와 state 반영에 영향을 줄 수 있는 patch다.
1.16.0을 이미 쓰는 pipeline은 대표 plan을 보관한 뒤 1.16.1 결과와 비교해야 한다. 특히 import block, run task와 create_before_destroy가 있는 module을 우선 대상으로 삼고, 예상 밖 replacement가 생기면 apply 전에 provider lock과 state 주소를 확인하는 것이 안전하다.