🔥 오늘의 주요 소식
How CloudFormation Express mode accelerates your development cycle
AWS가 CloudFormation에 리소스 안정화(stabilization) 대기를 생략하는 'Express mode'를 도입했다. 기존에는 리소스가 실제 트래픽을 처리할 수 있을 때까지 기다린 뒤 CREATE_COMPLETE를 보고했지만, Express mode는 구성이 적용되는 즉시 스택 작업을 완료 처리한다. 리소스 의존성 준수와 생성·수정·삭제 방식은 기존과 동일하게 유지된다. CloudFront 배포처럼 5~10분 걸리던 작업이 1분 미만으로 단축되는 사례를 제시하며, CLI의 --deployment-config '{"mode": "EXPRESS"}', CDK의 cdk deploy --express, SAM의 sam deploy --express로 활성화한다. 기본적으로 롤백이 비활성화되어 실패 시 스택을 그대로 두고 즉시 수정·재시도할 수 있다. AWS는 개발 반복(dev iteration)과 AI 에이전트의 배포→관찰→조정 루프에 권장하고, 프로덕션 배포에는 기본 모드가 여전히 적합하다고 안내한다.
💡 왜 중요한가: dev 환경 IaC 피드백 루프를 분 단위에서 초 단위로 줄여주므로 CDK/SAM 반복 배포가 잦은 팀이라면 개발 스택에 선별 적용할 가치가 있다 — 단, 롤백이 기본으로 꺼진다는 점은 파이프라인 정책에 명시해야 한다.
🔗 원문 보기 · AWS DevOps
Kubernetes & Cloud Native
Diagnose Kubernetes Control Plane Performance Issues with AWS DevOps Agent
AWS Containers
AWS가 DevOps Agent로 EKS API 서버 성능 저하를 진단하는 과정을 시연하는 고급(레벨 300) 기술 튜토리얼을 공개했다. 시나리오는 오작동 컨트롤러 50 레플리카가 초당 약 1,600~2,000건의 LIST/GET/WATCH/MUTATE 요청을 쏟아내 kubectl 응답이 약 100ms에서 1.5초 이상으로 악화되고 429 스로틀링이 발생하는 상황이다. 429는 client-go가 투명하게 재시도하기 때문에 문제 워크로드의 로그에는 남지 않고 EKS 감사 로그에만 나타나며, Karpenter 같은 정상 시스템 컨트롤러까지 함께 스로틀링되는 'APF(API Priority and Fairness) 투명성 문제'를 재현한다. DevOps Agent는 CloudWatch 메트릭, EKS 감사 로그, CloudTrail 이벤트, 파드 로그, 클러스터 상태를 상관분석해 약 7분 만에 'controller' 디플로이먼트가 분당 약 66,000건의 요청으로 API 서버 트래픽의 99% 이상을 점유하고 workload-low priority level 동시성을 포화시켰다는 근본원인을 도출했다. 실습 리소스는 aws-samples/sample-troubleshooting-eks-with-devops-agent 리포로 제공되며, AWS DevOps Agent는 현재 프리뷰 단계다.
💡 컨트롤 플레인 429/APF 이슈는 원인 워크로드 로그에 흔적이 남지 않아 진단이 특히 어려운 영역인데, 감사 로그 상관분석을 에이전트가 대신해 준다면 EKS 운영 MTTR을 실질적으로 줄일 수 있다.
(re)introducing kpt: Your toolchain for infrastructure automation
CNCF
CNCF 블로그에서 Ericsson의 Ciaran Johnston이 최근 CNCF 샌드박스 프로젝트로 온보딩된 kpt를 재소개했다. kpt는 Kubernetes Resource Model(KRM) 파일 번들을 '패키지'로 다루는 패키지 중심 툴체인으로, validator/mutator 함수를 파이프라인으로 실행해 구성을 검증·변형한다. base+패치 오버레이를 적용 시점에 렌더링하는 Kustomize와 달리 in-place 업데이트 방식이라, 클러스터에 적용될 최종 구성을 적용 전에 그대로 검토·승인할 수 있는 'WYSIWYG' 접근을 표방한다. 순수 KRM 데이터(패키지)와 이를 변형하는 비즈니스 로직(KRM 함수)을 분리하는 'Configuration as Data' 철학으로 감사 가능성과 조합성을 확보하며, ArgoCD·Flux·Helm·Porch 등 기존 GitOps 도구와 공존한다. 가장 복잡한 활용처는 Kubernetes 위에서 RAN·코어 네트워크 배포를 정의하는 통신망 자동화 프로젝트 Nephio다. 로드맵으로는 파이프라인 실행 성능 개선, 문서 대규모 재구성, secrets·멀티클러스터·Helm 지원, API 안정화를 통한 v1 릴리스를 제시했다.
💡 Kustomize 오버레이의 '적용해 봐야 최종 결과를 아는' 문제가 불편했던 플랫폼팀이라면, 렌더링된 구성을 그대로 리뷰·승인하는 kpt의 접근이 GitOps 감사 흐름과 잘 맞는지 검토해볼 만하다.
클라우드 업데이트
Meet Brain: The AI system behind Azure reliability
Azure
Microsoft가 Azure 신뢰성 운영의 중추인 AIOps 시스템 'Brain'을 소개하는 다부작 시리즈의 첫 편을 발표했다. Brain은 Azure Resource Graph(ARG) 위의 지능형 레이어로 동작하며, 둘이 함께 Azure 서비스 헬스의 '디지털 트윈'을 구성한다. 수백 개 서비스, 80개 이상 리전, 500개 이상 데이터센터 규모에서 표준화된 SLI, 서비스팀이 등록한 도메인 특화 모니터, 서드파티 지표를 입력으로 받아, 모든 평가 대상(서비스·리전·배포 단위·고객 리소스)에 health state, severity, impact, 판단 근거 4가지 표준 출력을 반환한다. 이미 프로덕션에서 blast radius 기반 장애 선언, 고객 알림, 인시던트 라우팅, 유해 롤아웃을 멈추는 deployment gate에 활용되고 있다. 지난 1년간 Brain 연동 장애의 상당수가 자동으로 고객에게 통지됐고, 판정 속도는 분이 아닌 초 단위라고 한다. 글의 핵심 주장은 이런 헬스 인텔리전스(디지털 트윈)가 에이전틱 AI 운영의 결과물이 아니라 전제조건이라는 것이다.
💡 AIOps 에이전트를 붙이기 전에 신뢰할 수 있는 헬스 판정 기반(토폴로지·의존성·런타임 상태의 단일 뷰)부터 만들어야 한다는 순서론은, 하이퍼스케일러가 아닌 조직의 관측성 투자 우선순위에도 그대로 적용된다.
Google’s Continued Disruption of Malicious Residential Proxy Networks
Google Cloud
Google이 FBI, Lumen 등과 공조해 대형 residential proxy 네트워크 NetNut(일명 Popa)에 대한 차단 조치를 발표했다. 지난 1월 IPIDEA 네트워크 차단에 이은 후속 작전이다. 조치에는 멀웨어 C2에 사용된 Google 계정·서비스 비활성화, NetNut SDK와 백엔드 인프라 인텔리전스의 업계 공유, Play Protect의 NetNut SDK 포함 앱 자동 경고·비활성화·설치 차단이 포함된다. Google Threat Intelligence Group(GTIG)은 NetNut 규모를 전 세계 최소 200만 대 기기로 추산하며, 이번 조치로 프록시 사업자의 가용 기기 풀이 수백만 대 줄었다고 평가했다. 2026년 6월 단 1주 동안 NetNut 추정 exit node를 사용하는 316개의 개별 위협 클러스터(사이버범죄·간첩 그룹 포함)가 관측됐다 — 피해자 환경 접근이나 패스워드 스프레이 시 출처 IP 은닉에 쓰인다. NetNut은 스마트 TV·스트리밍 박스 등에 SDK를 심어 봇넷을 확장했고, 다수의 유명 residential proxy 브랜드가 실은 NetNut의 화이트라벨이라고 Google은 높은 확신으로 평가한다. IPIDEA 차단 후 운영자들이 경쟁사 용량을 구매해 리셀러화하는 행태가 확인돼, 상호 연결된 사업자들을 동시에 타격해야 지속 효과가 있다고 결론짓는다.
💡 패스워드 스프레이나 크리덴셜 스터핑의 출처가 '일반 가정 IP'로 보이는 이유가 바로 이런 프록시 네트워크인 만큼, IP 평판 기반 차단만으로는 부족하고 행위 기반 탐지를 병행해야 한다는 근거가 된다.
Introducing Red Hat OpenShift Service Mesh 3.4
Red Hat
Red Hat이 Istio 1.30과 Kiali 2.27 기반의 OpenShift Service Mesh 3.4를 GA로 발표했다(3.3 대비 Istio 마이너 2개 버전 상승). 사이드카리스(ambient) 모드가 성숙해, 같은 메시 안에서 ambient와 사이드카 워크로드의 공존, 그리고 사이드카에서 ambient로의 점진적·가역적 마이그레이션이 공식 지원된다. ztunnel에 CRL(인증서 폐기 목록) 지원이 추가돼 외부 CA 사용 시 폐기된 인증서를 검증·거부할 수 있고, RHEL 10 이후를 대비한 네이티브 nftables 지원과 istiod·istio-cni·ztunnel용 네트워크 폴리시 옵션도 들어갔다. Kubernetes Gateway API 1.5의 TLSRoute termination·mixed mode가 완전 지원되며, SPIRE 기반 zero trust workload identity 연동이 테크 프리뷰로 승격됐고 WasmPlugin 대체를 목표로 하는 TrafficExtension API(Lua 지원)도 테크 프리뷰로 추가됐다. Kiali는 수백 개 네임스페이스 규모의 멀티클러스터를 위해 개요 페이지를 전면 재설계했고, OpenShift Lightspeed와 MCP 서버로 연동되는 AI 지원도 테크 프리뷰로 담겼다. 한편 Service Mesh 2.6은 2026년 6월 30일부로 EOL이라 마이그레이션 계획이 시급하다.
💡 2.6 EOL이 이미 지난 시점이라 OpenShift 메시 사용자에게는 3.x 마이그레이션이 급선무이며, 사이드카→ambient 전환이 공식 지원되는 지금이 사이드카 리소스 오버헤드 절감을 검토할 적기다.
DevOps & 인프라
The $1.3 million theft that exposed AI’s blind spot
The New Stack
시카고 외곽 Elk Grove Township의 트럭 야드에서 약 130만 달러 상당의 데이터센터 장비와 구리선을 실은 도난 트레일러 2대가 회수됐다. 한 대에는 앨라배마에서 도난된 약 30만 달러어치 데이터센터 건설용 구리선이, 다른 한 대에는 플로리다 잭슨빌에서 도난된 약 100만 달러어치 인프라 장비가 실려 있었다. Verisk CargoNet에 따르면 2025년 북미 화물 도난 손실은 약 60% 급증해 7억 2,500만 달러에 육박했는데 사건 건수는 보합세다 — 절도범들이 고가 화물을 선별하고 있다는 뜻이다. 금속 도난은 구리 수요에 힘입어 77% 증가했고, 조직적 절도단은 RAM 모듈·스토리지 드라이브·엔터프라이즈 장비로 표적을 옮기고 있다. 미 국토안보부는 화물 도난이 연간 최대 350억 달러의 비용을 초래한다고 추정한다. 기사는 GPU 클러스터가 서버·스위치·옵틱스·전력분배·냉각이 동시에 설치돼야 하는 긴밀 결합 시스템이라, 부품군 하나의 도난·지연이 전체 배치 지연으로 연쇄된다고 지적한다.
💡 AI 인프라 보안이 방화벽과 IAM을 넘어 물리적 공급망까지 확장되고 있다는 신호로, 데이터센터 증설 일정을 세울 때 하드웨어 물류 리스크를 별도 변수로 관리해야 한다.
Microsoft just admitted its biggest AI mistake — and spent $2.5 billion fixing it
The New Stack
Microsoft가 기업 고객의 멀티모델 AI 도입을 돕는 신규 법인 'Microsoft Frontier Company'를 초기 자금 25억 달러로 출범시켰다. Unilever와 Novo Nordisk 등이 초기 고객으로 참여하며, 고객은 Microsoft 및 외부 제공사의 AI 도구를 내부 데이터와 통합하고 그 결과물의 소유권을 가진다. Microsoft Commercial Business CEO Judson Althoff는 Reuters에 "초기 Copilot을 OpenAI 모델에만 묶은 것은 실수였다"고 인정했다. 기사는 이를 단일 모델 표준화 시대의 종언으로 해석한다 — 초장문 계약서엔 100만 토큰 이상 컨텍스트의 Gemini, 티켓 요약엔 GPT mini나 Claude Haiku, 온프레미스 규제 요건엔 Llama·Mistral 같은 오픈웨이트 모델을 용도별로 라우팅하는 식이다. LiteLLM, Portkey, LangChain/LangGraph, MCP 같은 라우팅·오케스트레이션 도구와 Bedrock·Azure AI Foundry·Vertex AI 같은 단일 API 멀티모델 서비스가 이 흐름을 뒷받침한다. 결론은 모델 성능이 수렴하면서 오케스트레이션 계층이 새로운 해자(moat)가 되고 있으며, 기업들이 모델을 플랫폼이 아닌 교체 가능한 부품으로 취급하기 시작했다는 것이다.
💡 하이퍼스케일러조차 단일 모델 종속을 '실수'로 규정한 만큼, 애플리케이션을 특정 LLM API에 하드코딩하지 말고 게이트웨이/라우팅 추상화 계층을 아키텍처에 넣어 모델 교체 비용을 낮춰야 한다.
“AI contributions are demoralizing”: Godot bans coding agents to save its mentoring model
The New Stack
오픈소스 게임 엔진 Godot이 기여 정책을 개정해 대부분의 AI 생성 코드를 저장소에서 금지하기로 했다. 프로젝트를 관리하는 비영리 Godot Foundation이 수개월 논의 끝에 내린 결정으로, 배경에는 AI 작성 PR로 불어난 감당 불가능한 리뷰 백로그가 있다. Foundation은 "AI 기여는 사기를 꺾는다(demoralizing)"며, PR 피드백이 모델의 다음 행동을 바꾸지 못하고 헤비 AI 사용자가 자기 코드를 이해해 피드백을 반영하리라 신뢰할 수 없다는 점을 이유로 들었다. 핵심 논지는 코드 품질 문제를 넘어, PR 리뷰를 통해 미래 메인테이너를 길러내는 멘토링 파이프라인의 보호다. 코드 완성·정규식·찾아바꾸기 같은 저위험 사용은 PR에 공개(disclosure)하는 조건으로 허용되며, 머지된 PR이 3개 이하인 신규 기여자는 대형 변경 전 사전 승인이 필요하다. Zig가 지난 4월 유사한 무관용 정책을 채택했고 Ghostty와 curl도 기여 경로를 제한하는 등, 오픈소스 전반으로 번지는 흐름이다.
💡 AI 코드 기여가 늘수록 리뷰 비용과 멘토링 가치의 균형이 무너진다는 문제 제기로, 오픈소스에 업스트림 기여를 하는 조직이라면 프로젝트별 AI 사용 가이드라인을 반드시 확인하고 사내 정책을 맞춰야 한다.
How GitHub used secret scanning to reach inbox zero
GitHub
GitHub 보안팀이 자사 15,000개 이상 리포지토리에 걸친 20,000건 이상의 secret scanning 경고를 9개월 만에 0건(inbox zero)으로 정리한 내부 사례를 공유했다. 분석해 보니 단 5개 리포지토리가 약 18,000건을 차지했고, 대부분 테스트 픽스처나 비활성화된 자격증명 같은 비활성 시크릿이었다 — GitHub 스스로 secret scanning 제품을 만들기 때문에 테스트용 시크릿이 많았던 것. '전용 테스트 리포 + 활성 이력 없음 + 알려진 테스트 패턴 일치'라는 기준으로 대량 종결해 실제 주의가 필요한 경고를 2,000여 건으로 줄였는데, 초기 집계의 90%는 유효하지 않은 경고였다. 신규 유입을 막기 위해 전 조직에 secret scanning과 push protection을 opt-out 불가 조직 수준 설정으로 강제 적용했다. 당시 없던 유효성 검사(validity checking)를 자체 구축했고, 이는 이후 제품 네이티브 기능이 됐다. 경고를 내부 취약점 관리 플랫폼으로 라우팅해 리포 소유 팀에 자동 배정하고 리더십 대시보드로 추적한 워크플로가 성공 요인으로 꼽힌다.
💡 시크릿 스캐닝 도입 직후 마주치는 수만 건의 백로그는 대부분 비활성 경고라는 실증 사례로, 유효성 기준의 대량 트리아지와 push protection 전면 강제가 백로그 정리의 실질적 공식임을 보여준다.
Could vs. Should: The First Year Managing an SRE Team
Honeycomb
Honeycomb의 엔지니어링 매니저 Reid Savage가 SRE 팀을 맡은 첫 1년을 회고하는 글을 썼다. 핵심 프레임은 SRE 팀과 매니지먼트의 공통점 — '할 수 있는 일(could)은 많지만 해야 하는 일(should)은 일부이며, 그 구분이 어렵다'는 것이다. 저자는 세 가지 실수를 꼽는다: 완벽히 준비할수록 오히려 참여가 줄어들던 회의 운영, 팀원에 대한 피드백을 너무 오래 묵힌 것, 그리고 8년 이상의 실무 경력이 있음에도 기술 결정에서 완전히 발을 뺀 것이다. 교정책으로는 회의 목표에서 역산한 최소한의 프로세스, 모든 1:1에서 자신(매니저)에 대한 건설적 피드백을 요청하는 반복 훈련, 상황에 따라 단독 결정·방향 권고·조언 공유·침묵을 명시적으로 구분해 선언하는 개입 방식을 소개한다. 신임 매니저에게는 최대한 높은 신뢰의 관계 구축, 집요한 피드백 추구, 상사·상사의 상사·팀원에게 '내 역할과 우리 팀의 일'을 묻기, 그리고 명령보다 질문을 훨씬 많이 하라고 조언한다. 스태프 엔지니어의 갑작스러운 퇴사와 AI 전략 전환이 있었던 2년 차 이야기는 후속 글로 예고했다.
💡 시니어 IC가 매니저로 전환할 때 가장 흔한 함정(기술 결정에 과잉 개입하거나 완전히 방임하거나)을 '개입 수준을 명시적으로 선언한다'는 실용적인 프레임으로 풀어낸 점이 참고할 만하다.
AI로 웹 엔지니어 없이 LINE 앱 안에서 그룹 영상 통화 서비스 만들기
LINE
LINE Planet 팀의 PM 정덕범과 Android 엔지니어 강대경 두 사람이, 웹 전문 인력 없이 LINE 앱 안에서 동작하는 그룹 영상통화 서비스를 만든 과정을 재현 가능한 튜토리얼로 정리했다. 아키텍처는 LINE 공식 계정(진입점), LIFF(인앱 웹뷰+로그인·프로필 전달), React+Vite 웹 앱, LINE Planet 액세스 토큰을 발급하는 앱 서버, WebRTC 기반 실시간 통신 인프라인 LINE Planet의 5개 컴포넌트로 구성되며, 직접 구축하는 것은 웹 앱과 앱 서버(Firebase Cloud Functions로 서버리스 구성 가능) 둘뿐이다. 미디어 처리에서는 PlanetKit SDK의 MediaStreamManager 인스턴스 하나를 미리보기부터 그룹 통화까지 재사용해 카메라·마이크 권한 재요청을 방지하는 노하우를 다룬다. 전·후면 카메라 전환은 facingMode를 받지 않는 SDK 제약을 enumerateDevices() 라벨 매칭으로 우회한다. 참가 흐름은 LIFF에서 사용자 정보 획득 → 앱 서버 토큰 발급 → joinConference 호출 순이며, 참가자 수에 따른 동적 그리드와 해상도(hd/vga/qvga) 조정, liff.shareTargetPicker를 통한 친구 초대도 구현했다. 실시간 방송 시나리오는 기본 500명, 최대 1만 명 동시 참여까지 지원한다고 소개한다.
💡 인증과 미디어 인프라를 플랫폼 SDK에 위임하면 웹 비전공 엔지니어 두 명으로도 영상통화 서비스가 가능하다는 사례로, 사내 도구나 PoC를 만들 때 풀스택 채용보다 플랫폼 위임 아키텍처를 먼저 검토할 근거가 된다.
이 다이제스트는 RSS 피드에서 수집한 뒤 AI(Claude)가 요약·정리했습니다. 자세한 내용은 원문 링크를 확인하세요.