📰 데일리 테크 다이제스트 - 2026-09-02

🔥 오늘의 주요 소식

BenchMIRT: What are LLM benchmarks actually measuring?

BenchMIRT는 심리측정학의 다차원 항목반응이론(MIRT)을 LLM 벤치마크 채점에 적용해, 점수 하나로 뭉뚱그려지던 능력을 문항 단위로 분해하는 방법론이다. 연구팀은 100개 LLM을 MMLU-Pro, GPQA, MATH, BBH 같은 추론 벤치마크와 HarmBench, StrongReject, WildJailbreak, BBQ, WMDP, XSTest 같은 안전성 벤치마크 등 16개, 3만 4천여 문항에 대해 분석했다. 그 결과 벤치마크 전반에서 일반 추론과 안전성이라는 두 개의 독립적 축이 드러났고, 편향 테스트용으로 설계된 BBQ는 의외로 안전성보다 추론 축에 더 가깝게 움직였다. HarmBench 역시 저작권 관련 문항은 추론 축, 유해 요청 문항은 안전성 축으로 쪼개지는 혼합 신호를 보였다. BenchMIRT는 전체 문항의 10%만 써도 능력 측정치를 거의 그대로 보존했고, 50%를 쓰면 전체 벤치마크 결과와 더 가깝게 일치했다. 미공개 문항에 대한 성능 예측 정확도는 79%로, 기존 평균 방식의 70%보다 높았다.

💡 왜 중요한가: 클러스터에서 여러 모델을 평가·라우팅하는 팀이라면, 종합 점수 대신 추론/안전성처럼 벤치마크가 실제로 측정하는 축을 구분해 모델을 고르고, 문항의 10~50%만으로도 평가 파이프라인 비용을 줄일 수 있다는 시사점을 얻을 수 있다.

🔗 원문 보기 · Hugging Face

Kubernetes & Cloud Native

Automate proxy injection for Amazon EKS on AWS Fargate using Kyverno

AWS Containers

AWS Fargate에서 실행되는 Amazon EKS 팟은 노드 계층에 접근할 수 없어 기존 방식으로 프록시 환경변수를 주입할 수 없다는 문제가 있다. 일반 EC2 노드에서도 kubelet 같은 노드 프로세스에만 프록시 설정이 적용되고 컨테이너는 노드 환경변수를 물려받지 않아, 팟 단위 프록시 주입에는 애드미션 단계의 해법이 필요하다. AWS는 CNCF 졸업 프로젝트인 Kyverno의 뮤테이팅 어드미션 정책을 이용해, 레이블이 붙은 네임스페이스의 팟이 생성될 때 HTTPS_PROXY, HTTP_PROXY, NO_PROXY 환경변수를 모든 컨테이너와 초기화 컨테이너에 자동 주입하는 방법을 제시한다. 이 방식은 애플리케이션 배포 매니페스트를 건드리지 않고, 클러스터 운영팀이 정책 하나만 관리하면 레이블된 네임스페이스 전체에 프록시 설정이 자동으로 적용되도록 한다. 변이(mutation)가 객체 저장 전에 일어나기 때문에, 컨테이너가 프록시 설정 전에 네트워크 호출을 시도하는 경쟁 조건도 원천적으로 막힌다.

💡 Fargate 노드 계층이 막혀 있다는 구조적 한계를 애드미션 정책으로 우회하는 이 패턴은, 규제·보안 때문에 아웃바운드를 프록시로만 허용해야 하는 클러스터에서 서버리스 컴퓨트를 포기하지 않고도 egress 컴플라이언스를 지킬 수 있게 해준다.

Fast model loading for AI inference on Amazon EKS

AWS Containers

AWS는 Amazon EKS에서 AI 추론용 모델 로딩 속도를 높이기 위해 Run:ai Model Streamer의 설정만 바꿔 콜드스타트 시간을 후속 실행에서 8093% 줄였다고 밝혔는데, 코드 변경은 전혀 없었다. 처음에는 청크 크기를 작게(256MiB), 동시성을 높게(256스레드) 설정하면 S3 처리량이 늘어날 것으로 예상했지만, 테스트 결과 256MiB부터 4GiB까지는 성능 차이가 5% 이내였고 병렬 연결을 17개에서 256개로 늘려도 이득이 없었으며, 8GiB로 올리면 오히려 56% 성능이 떨어졌다. 원인은 Run:ai Model Streamer가 샤드 파일마다 워커 스레드 하나씩 붙이고, 같은 워커 안에서는 요청을 순차적으로 처리해 파이프라이닝을 하지 않기 때문이었다. 대부분의 SafeTensors 샤드가 35GiB인 점을 고려해 청크 크기를 4GiB로 맞추면 샤드당 요청이 한 번으로 줄어 동시성 설정도 가장 낮게 잡을 수 있었다. S3 GET 요청의 약 10%가 중간값보다 2~3배 느려지는 롱테일 지연이 있어, 모든 청크가 끝나야 모델이 준비되는 구조에서는 단 하나의 느린 연결이 전체 로딩을 붙잡는다는 점도 확인됐다.

💡 코드 한 줄 바꾸지 않고 청크 크기·동시성 설정만으로 콜드스타트를 80% 이상 줄일 수 있었다는 결과는, GPU 추론 클러스터를 운영하는 팀이 스케일아웃 지연과 비용을 당장 줄일 수 있는 저비용 개선 지점임을 보여준다.

Platform engineering maturity: From toolchain to self-service

CNCF

CNCF 블로그는 플랫폼 엔지니어링 성숙도 모델을 다루며, 플랫폼이 아직 없는 팀과 이미 골든 패스·개발자 포털·CLI·AI 에이전트까지 갖춘 팀이 똑같이 '다음 단계의 플랫폼 인터페이스가 뭔지 모른다'는 같은 문제를 겪고 있다고 지적한다. 플랫폼을 이미 구축한 팀도 골든 패스 밖의 요청은 여전히 플랫폼팀이 수동으로 처리해야 해서, '셀프서비스'를 도입했다고 믿으면서도 실제로는 업무량이 줄지 않는 경우가 많다는 것이 핵심 관찰이다. CNCF 플랫폼 엔지니어링 성숙도 모델은 투자(Investment), 도입(Adoption), 인터페이스(Interfaces), 운영(Operations), 측정(Measurement) 다섯 가지 측면을 각각 독립적으로 평가한다. 각 측면은 Provisional, Operational, Scalable, Optimizing 네 단계를 가지며, 조직은 한 덩어리로 단계를 오르는 게 아니라 측면별로 각자의 속도로 진행한다. 이 글은 대부분의 팀이 자각하지 못한 채 '인터페이스' 측면의 2단계(Operational)에서 정체된다고 지적하며, 그 이유와 다음 단계로 가는 길을 다룬다.

💡 플랫폼팀이 '셀프서비스를 갖췄다'고 믿으면서도 골든 패스 밖 요청을 여전히 손으로 처리한다면, 그 병목이 바로 인터페이스 성숙도 2단계 정체의 신호이므로 다음 투자는 새 기능 추가가 아니라 인터페이스 설계에 둬야 한다.

Security briefing: August 2026

Sysdig

Sysdig는 2026년 8월 보안 브리핑을 공개했다. 이 브리핑은 AI가 완전히 새로운 공격을 만들어낸 게 아니라 기존 공격의 속도를 높였을 뿐이라는 관점으로 시작한다. 이번 브리핑에서 다루는 구체적 사례로 'ChainDrop'과 'Ghostjacking'이라는 이름의 공격 기법, 그리고 Claude Code가 랜섬웨어 공격에 쓰인 사례가 언급된다. 다만 이 사례들이 각각 어떤 방식으로 동작하는지, 피해 규모나 대응 방안 등 세부 내용은 페이지의 요약 수준에서는 확인되지 않는다. 본문 전체를 가져오지 못해, 이 요약은 제목과 페이지 설명(메타 디스크립션) 수준의 정보로만 작성했다.

💡 코딩 에이전트가 랜섬웨어 공격에 악용된 사례가 나왔다는 것만으로도, CI/CD에서 에이전트에 부여하는 자격증명과 실행 권한을 랜섬웨어 시나리오 기준으로 다시 점검할 필요가 있다.

Kubernetes v1.37: Storage Version Migration Enabled by Default

Kubernetes

쿠버네티스 1.37에서 스토리지 버전 마이그레이션(SVM)이 정식(GA) 기능으로 승격됐다. 쿠버네티스 컨트롤 플레인에 내장된 StorageVersionMigrator 컨트롤러가 StorageVersionMigration 오브젝트를 감시하며, 기존에 저장된 리소스를 해당 API의 기본 스토리지 버전으로 자동 이전한다. 예를 들어 CustomResourceDefinition에서 crontabs.example.com의 스토리지 버전을 v1로 바꾼 뒤, group과 resource를 지정한 StorageVersionMigration 매니페스트를 kubectl apply로 적용하면 기존 저장본이 전부 마이그레이션된다. 진행 상황은 kubectl get storageversionmigration으로 확인할 수 있고, 성공하면 status.conditions에 Succeeded가 True로 표시된다. 이 기능이 선언적 쿠버네티스 API로 제공되는 덕분에 CRD 작성자는 CRD 업그레이드와 마이그레이션을 같은 매니페스트에 묶어 함께 적용할 수 있다.

💡 스토리지 버전 마이그레이션이 선언적 API로 GA된 덕분에, CRD를 운영하는 플랫폼팀은 구버전 스토리지를 안전하게 폐기하기 위해 별도 스크립트를 짜지 않고도 업그레이드 매니페스트 하나로 마이그레이션까지 끝낼 수 있다.

Secure by default is your only way forward

Docker

Docker는 에이전트에게는 기존 보안 도구가 맞지 않는다며, 에이전트마다 격리된 디스포저블 MicroVM 기반 'Docker Sandbox'에서 세션을 실행하는 새 방어 계층을 내놓았다. 샌드박스는 OS 레벨에서 에이전트를 호스트로부터 차단하고, 자격증명은 작업에 필요한 만큼만 프록시로 주입돼 샌드박스 안에 저장되지 않으며, 무엇을 들여오고 내보낼지는 사용자가 정한다. Docker는 자사 보안팀이 코딩 에이전트를 호스트에서는 완전히 막고 샌드박스 안에서만 여러 개를 동시에 자율적으로 돌리게 했다고 밝혔으며, 이 구조 덕분에 샌드박스 하나에 인포스틸러가 들어와도 훔칠 것이 없다고 설명한다. 에이전트가 외부 도구를 호출하는 MCP(Model Context Protocol) 서버는 하드닝된 이미지와 같은 카탈로그에서 같은 방식으로 빌드·서명돼 MCP Catalog와 Toolkit을 통해 제공되며, 모든 호출은 MCP Gateway를 거쳐 인증·인가·로깅된 뒤에야 외부 시스템에 도달한다. Docker Scout는 이 정책을 빌드 시점에 강제해, 사람이 일일이 단속하지 않아도 안전한 경로가 기본값이 되게 한다.

💡 에이전트 세션을 MicroVM 샌드박스에 가두고 MCP 호출을 게이트웨이에서 인가·로깅하게 만든 구조는, 에이전트에게 풀 자율성을 주면서도 인포스틸러나 과다 권한 MCP 서버로 인한 피해 반경을 호스트 밖으로 묶어둘 수 있다.

OpenTelemetry has graduated… now what?

CNCF

OpenTelemetry(OTel)는 2026년 5월 CNCF 졸업(graduated) 상태를 공식 획득했다. CNCF에 따르면 OTel은 2,800개 이상의 기업과 수백 명의 메인테이너가 참여해 1만 2천 건이 넘는 기여를 쌓았으며, 쿠버네티스에 이어 CNCF에서 두 번째로 속도가 빠른 프로젝트다. OTel은 구글의 OpenCensus와 CNCF의 OpenTracing이라는 두 개의 분리된 표준화 시도를 2019년 5월에 통합해 만들어졌는데, 그 전에는 벤더마다 자체 계측 라이브러리를 유지해 벤더를 바꾸려면 코드에서 이전 라이브러리를 전부 뜯어내야 했다. OpenTracing은 2022년 1월, OpenCensus는 2023년 7월에 각각 아카이브됐다. 출범 이후 트레이스·로그·메트릭이 모두 GA에 도달했고, 프로파일링이 새 신호로 추가됐으며, OpAMP·OTel Operator·OTel Weaver·OTel Arrow 같은 생태계 컴포넌트도 계속 늘어, 이제 겨우 7년 된 프로젝트로서는 이례적인 성취라고 이 글은 평가한다.

💡 벤더 종속 계측 라이브러리 시대를 끝낸 표준이 이제 CNCF에서 쿠버네티스 다음으로 빠른 속도로 성장하고 있다는 것은, 아직 벤더별 SDK에 묶인 관측성 스택을 운영하는 팀이 OTel로 이전할 때의 생태계 위험이 크게 줄었다는 뜻이다.

Observability in Kubernetes: From metrics to meaning

CNCF

CNCF 블로그는 전통적인 모니터링이 'CPU가 기준치를 넘었는가, 메모리가 오르는가, 오류율이 늘어나는가'처럼 미리 정해진 질문에만 답한다는 한계를 짚으며, 쿠버네티스에서는 장애가 한 호스트의 명백한 고장이 아니라 컴포넌트 간 상호작용에서 생겨나는 경우가 많다고 지적한다. 예를 들어 배포는 배포 레벨에서는 건강해 보이면서도 다운스트림 의존성이나 노이즈 섞인 재시도 루프, 과부하된 컨트롤 플레인 경로를 통해 지연을 일으킬 수 있다. CNCF는 관측성을 메트릭·로그·트레이스·프로파일링 같은 텔레메트리의 계측·수집·처리·저장·질의·정제·상관분석까지 포괄하는 개념으로 정의하며, 이는 하나의 도구나 대시보드가 아니라 시스템의 설계 속성이자 팀의 운영 모델이라고 강조한다. 이 글은 시스템이 충분히 품질 좋은 신호를 노출해 엔지니어가 외부 출력만으로 내부 동작을 추론할 수 있을 때 '관측 가능하다'고 부를 수 있다고 설명하며, 이렇게 되면 사고 대응이 추측이 아니라 증거를 따라가는 조사가 된다고 말한다. 메트릭은 저렴하고 수치화돼 있어 팀이 가장 먼저 도입하는 신호로, 노드 압박·팟 재시작·API 서버 지연 같은 첫 징후를 가장 먼저 포착하는 역할을 한다고 덧붙인다.

💡 모니터링과 관측성을 명확히 구분하면, 쿠버네티스 팀은 메트릭 대시보드만 늘리는 대신 로그·트레이스·프로파일링을 상관분석까지 엮는 투자로 사고 조사 시간을 실제로 줄일 수 있다.

Defending the battlefield: Stateful detections for an agentic threat landscape

Sysdig

Sysdig는 '첫 에이전틱 랜섬웨어 작전이 파괴적인 데이터베이스 갈취 플레이북을 자율적으로 실행했다'는 사례를 언급하며, 방어 측에도 빠른 자동 대응을 가능하게 하는 런타임 보안이 점점 더 중요한 안전망이 되고 있다고 말한다. 기존 탐지 엔진은 이벤트를 맥락 없이 단독으로 판단해, 예컨대 컨테이너에서 터미널 셸이 열렸다는 것만으로는 개발자의 디버깅인지 공격자의 침투인지 구분하지 못해 보안 엔지니어가 다른 경보와 대조하며 수동으로 추적해야 했다. 스테이트풀 탐지는 셸을 열고 /tmp에 바이너리를 내려받은 뒤 실행하는 흐름처럼 개별 이벤트 연쇄를 추적해, 각각은 정상적일 수 있는 행동이 합쳐지면 거의 확실한 공격 신호가 된다는 것을 잡아낸다. Sysdig의 Falco 에이전트는 이를 'observation'이라는 확장으로 구현해, 프로세스 ID 같은 필드가 같은 세션인지(obs_link_fields)를 연결하고 obs.occurs·obs.link 조건으로 패키지 관리자 설치 같은 후속 행위가 쉘 실행에 이어지는지 규칙으로 탐지한다. Sysdig의 2026년 클라우드 네이티브 보안·사용 현황 보고서에 따르면 조직의 70%가 스테이트풀 탐지를 쓰고 있고, 이를 도입한 조직은 클라우드 환경의 91%에 걸쳐 적용하고 있다.

💡 개별 이벤트가 아니라 이벤트 연쇄를 보는 스테이트풀 탐지로 전환하면, 런타임 보안팀이 개발자의 정상적인 디버깅 셸과 실제 공격 체인을 구분하는 데 들이던 수동 조사 시간을 줄여 알림 피로를 낮출 수 있다.

AI & ML

The latest AI news we announced in August 2026

Google AI

2026년 8월 한 달간 구글이 내놓은 AI 업데이트를 모은 글로, 코딩·에이전트용 최신 경량 모델 Gemini 3.7 Flash가 전작 3.6 Flash 대비 절반 가격의 도입가로 나온 것이 핵심이다. 음성 전사용 Gemini 3.5 Transcribe와 4K 업스케일링을 포함한 스튜디오급 영상 생성 도구 Gemini Omni 1.1 Flash도 함께 발표됐다. 사이클론 예측 모델 WeatherNext 2는 연구 커뮤니티에 오픈소스로 공개됐고, 구글 텐서 G6 칩을 탑재한 Pixel 11·11 Pro·11 Pro XL·11 Pro Fold 시리즈도 이 기간에 나왔다. 대학생 대상 1년 무료 Google AI 플랜 제공과 함께, Gemini 앱은 월 사용자 10억 명을 넘겼고 하루 1억 5천만 장 이상의 이미지를 생성하며 Gemma 모델 다운로드는 10억 건을 돌파했다. 항공 컨트레일(비행운) 저감을 위한 파트너십 '오퍼레이션 블루 스카이즈'도 같은 달 소개됐다.

💡 Gemini 3.7 Flash의 반값 도입가와 WeatherNext 2의 오픈소스 공개는, 코딩/에이전트 워크로드를 돌리는 클러스터 운영자에게 모델 교체로 추론 비용을 바로 줄일 수 있는 기회가 생겼다는 뜻이다.

Mapping global methane emissions from space with deep learning

Google Research

구글 리서치와 NASA 제트추진연구소(JPL)는 Swin-S 비전 트랜스포머 기반 딥러닝 모델로 국제우주정거장에 탑재된 NASA의 EMIT 장비 초분광 영상에서 메탄 플룸을 탐지하는 방법을 공개했다. EMIT은 60미터 공간 해상도와 7.4나노미터 분광 해상도로 지구 표면을 관측하며, 이 모델은 화소 단위 분석 대신 스펙트럼 전체와 주변 공간 맥락을 함께 처리해 가짜 신호를 걸러낸다. 실제 환경에 훈련 데이터가 거의 없다는 문제를 해결하기 위해 라그랑주 퍼프 모델로 만든 360만 개의 합성 메탄 플룸을 실제 EMIT 장면에 주입해 학습시켰다. 그 결과 전문가가 주석을 단 플룸에 대해 재현율 84%를 기록했고, 약 1,100개 EMIT 그래뉼 전반에서 기존보다 약 50% 더 많은 플룸을 찾아냈으며, 전 세계 상위 배출 매립지 25곳 중 24곳에서 플룸을 포착했다. 이 모델은 농도 정량화, 플룸 경계 구분, 배출원 위치 추정을 동시에 수행해 밀집 산업 지역의 겹치는 플룸도 분리해낼 수 있다.

💡 합성 데이터로 라벨 부족 문제를 돌파한 이 접근은, 실측 라벨이 희귀한 도메인에서 관측성 모델을 학습시켜야 하는 클러스터·인프라 팀에게도 합성 데이터 파이프라인이 현실적 대안이 될 수 있음을 보여준다.

How AI-native companies turn workflows into operating capability

OpenAI

이 글은 Basis, Clay, Exa Labs 세 회사의 사례를 다룬다. 이들은 AI 에이전트를 활용해 온보딩, 계정 관리, 개발자 통합을 개선했다. 제목은 이를 '워크플로를 운영 역량으로 전환하는 AI 네이티브 기업'이라는 틀로 소개한다. 다만 각 회사가 구체적으로 어떤 에이전트를 어떻게 도입했는지, 어떤 지표가 얼마나 개선됐는지는 제목과 발췌문에 나오지 않는다. 본문을 가져오지 못해(403 응답), 이 요약은 제목과 발췌문 수준의 정보로만 작성했다.

💡 온보딩·계정관리·개발자 통합에 에이전트를 투입한 사례라는 점만 봐도, 반복적인 운영 워크플로부터 에이전트 적용을 시작하는 것이 검증된 출발점이 될 수 있다는 시사점은 얻을 수 있다.

Try Google Pics: Easy image creation and editing in Google Workspace

Google AI

구글은 최신 Nano Banana 이미지 모델을 기반으로 한 이미지 생성·편집 도구 Google Pics를 공개했다. 이 도구는 텍스트 프롬프트로 여러 결과물을 만들어내고, 이미지 안의 특정 객체만 분리해 나머지에 영향을 주지 않고 변형할 수 있으며, 디자인을 깨지 않고 이미지 안의 텍스트를 수정하거나 번역할 수 있다. 동료와 함께 편집을 협업하는 기능도 제공된다. Google AI Pro·Ultra 구독자 전체와 대부분의 Workspace 비즈니스 고객에게 앞으로 몇 주에 걸쳐 순차 제공되며, 출시와 함께 Docs·Slides에 바로 통합되고 Drive 통합은 추후 제공된다. pics.new에서 독립 제품으로도, Workspace 안에서도 써볼 수 있다.

💡 디자인을 깨지 않고 이미지 속 텍스트를 바로 번역·수정할 수 있다는 점은, 다국어 마케팅 자산이나 문서를 운영하는 팀이 별도 디자인 툴 왕복 없이 로캘라이제이션 작업을 바로 Workspace 안에서 끝낼 수 있다는 뜻이다.

Path to Astra: critical capabilities and frontier safeguards

OpenAI

OpenAI는 Astra라는 모델을 공개했다. 이 모델은 자사 Preparedness Framework 기준 '치명적(Critical) 사이버보안 역량' 문턱을 넘은 첫 모델이라고 밝혔다. 이 때문에 출시에는 더 강화된 안전장치가 적용됐다고 한다. 다만 어떤 구체적 역량 테스트를 통과했는지, 안전장치가 정확히 무엇인지는 제목과 발췌문에 나오지 않는다. 본문을 가져오지 못해(403 응답), 이 요약은 제목과 발췌문 수준의 정보로만 작성했다.

💡 자체 프레임워크상 '치명적' 사이버보안 역량 문턱을 넘은 모델이 나왔다는 것은, 이 모델에 API 접근 권한을 줄 때 기존보다 강화된 접근 통제와 사용 모니터링이 필요하다는 뜻이다.

Healthcare organizations can now connect EHR and additional industry data to ChatGPT

OpenAI

OpenAI는 새 기능을 발표했다. ChatGPT가 신뢰할 수 있는 의료 데이터에 연결될 수 있게 됐다는 내용이다. 이를 통해 임상의가 환자 맥락과 의학 연구 자료 등에 안전하게 접근하도록 돕는다는 설명이다. 제목에서는 전자건강기록(EHR)과 기타 업계 데이터 소스 연결이 언급되지만, 구체적으로 어떤 EHR 시스템이나 파트너사와 연동되는지, 보안·컴플라이언스 조치가 무엇인지는 제목과 발췌문에 나오지 않는다. 본문을 가져오지 못해(403 응답), 이 요약은 제목과 발췌문 수준의 정보로만 작성했다.

💡 임상 환경에서 ChatGPT가 EHR 데이터에 연결된다면, 이를 도입하는 의료기관의 플랫폼팀은 PHI 접근 경계와 감사 로그를 다루는 배포 정책을 먼저 정비해야 한다.

Introducing @huggingface/kernels: 200+ WebGPU Kernels for Local AI

Hugging Face

Hugging Face는 브라우저에서 WebGPU로 돌아가는 최적화된 커널 207개를 모은 라이브러리 @huggingface/kernels를 공개했다. 각 커널은 webgpu-kernels 조직 아래 Apache-2.0 라이선스의 개별 저장소로 배포되며, 인터페이스·셰이더 템플릿·정확성 테스트·벤치마크 케이스·사용법까지 한 패키지에 묶여 있다. 이 라이브러리는 huggingface.co/webgpu-kernels 허브에서 커널을 내려받아 바로 실행하는 자바스크립트 로더 역할을 한다. 함께 출시된 'Fleet'은 브라우저 안에서 커널을 실행하고 채점하는 GPU 벤치마킹·테스트 도구로, 사용자 동의를 받아 각 실행 결과를 익명으로 모아 팀이 직접 보유하지 못한 다양한 실제 하드웨어에서의 정확성·성능 데이터를 확보한다. Hugging Face는 이를 브라우저 추론을 빠르고 쓰기 쉽게 만들기 위한 다층 노력의 첫 번째 단계라고 소개한다.

💡 커널마다 정확성 테스트와 벤치마크 케이스를 묶어 배포하는 구조는, 브라우저에서 모델을 서빙하는 팀이 GPU 종류별 회귀를 직접 검증하지 않고도 재현 가능한 성능 기준을 얻을 수 있게 해준다.

TimesFM-3: A zero-shot foundation model for multivariate forecasting

Google Research

구글 리서치는 다변량 시계열 예측 파운데이션 모델 TimesFM-3을 공개했다. 이 모델은 과거-미래 공변량(past-future covariate)으로 프로모션 일정처럼 미래에 알려진 신호를 입력받아, 얼터네이팅 어텐션 레이어로 마스킹된 구간(horizon) 패치를 반복 루프 없이 한 번에 채워 넣는다. 예시로 든 아이스크림 판매 시나리오에서, 프로모션 일정을 과거-미래 공변량으로 넣은 다변량 모드는 프로모션일마다 약 20%의 판매 증가를 예측해 일반적인 단변량 모델보다 한 달 전체 매출 예측 정확도가 더 높았다. 예측마다 10~90번째 백분위수에 해당하는 9개 분위수를 산출해 확률적 불확실성까지 보여준다. Gift-Eval, FEV-Bench, Time이라는 세 가지 공개 예측 벤치마크에서 TimesFM-3은 Chronos-2, Toto 2.0, 이전 모델인 TimesFM-2.5를 비롯한 모든 사전학습 파운데이션 모델 중 점·확률적 예측 지표 양쪽에서 1위를 차지했고, 단변량 모드만 써도 이미 경쟁 모델과 비슷하거나 더 나은 성능을 보였다.

💡 프로모션 일정 같은 미래에 이미 알려진 신호를 공변량으로 넣어 예측을 개선할 수 있다는 점은, 용량 계획이나 트래픽 스파이크를 예측해 오토스케일링 정책을 짜는 인프라팀에게 예약된 이벤트 정보를 바로 활용할 여지를 보여준다.

클라우드 업데이트

What Google Cloud announced in AI this month

Google Cloud

이 글은 2026년 8월 한 달간 구글 클라우드가 내놓은 AI 관련 발표를 모은 월간 리캡이다. 코드의 보안 취약점을 자동으로 찾아 고치는 CodeMender가 프리뷰로 공개됐고, Gemini 기반 코드 최적화·탐색 에이전트 AlphaEvolve는 구글 클라우드 모든 사용자에게 정식 제공됐다. Gemini Enterprise Agent Platform에는 Agent Runtime, Agent Identity 등 기존 인기 기능이 전체 공개로 전환됐고, 이번 달에는 아키텍처 설계를 돕는 실습 데모 13개와 진단 질문 20개도 함께 제공됐다. 신규 고객에게는 프로토타입 검증용으로 300달러 무료 크레딧과 매달 AI API를 포함한 20개 이상 제품 무료 사용량이 제공된다. 에이전트 시스템 구축을 기초부터 배우는 무료 5주 라이브 강좌 'Agent Valley'도 이번 달에 소개됐다.

💡 AlphaEvolve의 전면 공개와 CodeMender 프리뷰는, 코드 최적화·취약점 패치를 AI 에이전트에 위임하는 실험을 지금 바로 구글 클라우드에서 비용 부담 없이 시작할 수 있다는 뜻이다.

How Blackline simplifies perimeter policy intelligence with VPC Service Controls

Google Cloud

구글 클라우드는 VPC Service Controls(VPC-SC)에 Violation 대시보드와 Violation 분석기라는 새 정책 인텔리전스 기능 두 가지를 추가했다. 대시보드는 조직 전체의 서비스 경계 위반을 한 화면에 모아 시각화해, 특정 경계·프로젝트·아이디(ID)별로 필터링하며 추세와 급증을 바로 확인할 수 있게 한다. 분석기는 대시보드의 트러블슈팅 토큰이나 거부 ID를 입력하면 Cloud Logging SQL 쿼리를 직접 짜지 않고도 요청의 신원·소스·타겟과 위반된 VPC-SC 규칙을 매핑해 보여준다. 고객사 BlackLine은 이 도구 덕분에 경계 위반 문제의 평균 해결 시간(MTTR)이 눈에 띄게 줄었다고 밝혔다. 두 도구는 초기 드라이런 테스트, 실시간 모니터링, 사건 조사, 정책 규칙 수정까지 VPC-SC 라이프사이클 전 단계에서 쓸 수 있다.

💡 Cloud Logging SQL 쿼리 없이 위반 원인을 바로 매핑해주는 분석기는, 데이터 유출 방지 경계를 운영하는 보안팀의 사고 대응 시간을 줄이는 동시에 온콜 부담을 낮출 수 있다.

Introducing TabFM in BigQuery: Predictive analytics reimagined

Google Cloud

구글 클라우드는 BigQuery에 테이블 기반 파운데이션 모델 TabFM을 도입해, 단일 SQL문으로 정형 데이터에 대한 예측 분석을 수행할 수 있게 했다. 전통적인 머신러닝처럼 파라미터를 학습 데이터에 맞춰 훈련하는 대신, TabFM은 LLM의 퍼샷 학습과 비슷하게 학습 테이블을 맥락으로 읽어 한 번의 순전파로 대상 테이블의 예측값을 생성하는 인컨텍스트 러닝 방식을 쓴다. AI.EVALUATE 함수로 회귀 문제는 r2_score·평균절대오차, 분류 문제는 정밀도·재현율·F1 같은 표준 평가 지표를 바로 뽑을 수 있다. BigQuery는 대규모 연산을 감당하기 위해 분산·병렬 추론과 지능형 학습 데이터 샘플링을 함께 사용해 수백만 행 규모의 추론도 빠르게 처리한다. 구글은 데이터가 적거나 자주 바뀌고 빠른 재학습이 필요한 상황, 또는 대화형·에이전트 워크플로에는 TabFM을, 대규모 데이터나 특성 중요도 설명이 필요한 경우에는 XGBoost 같은 전통 모델을 쓰라고 권고한다.

💡 SQL 한 줄로 예측 모델을 돌릴 수 있다는 점은, 별도 ML 인프라나 재학습 파이프라인을 운영하지 않고도 BigQuery 안에서 바로 예측 분석을 실험할 수 있다는 뜻이어서, 데이터 플랫폼 운영 부담을 줄일 수 있다.

Hybrid cloud orchestration: Modernizing on-premises infrastructure management with AWS

AWS Architecture

AWS는 수백 곳에 분산된 온프레미스 사이트를 관리하는 하이브리드 클라우드 오케스트레이션 아키텍처 1부를 공개했다. 하드웨어 자원은 벤더 중립적인 Redfish API로 관리되고, 이 위에 EKS Anywhere 쿠버네티스 클러스터(관리용·워크로드용)가 컨테이너 워크로드의 컴퓨트·스토리지·네트워킹 기반을 이룬다. 중심에는 DynamoDB 테이블로 구성된 Inventory Management System이 있어 사이트, 하드웨어(BIOS·펌웨어 버전, 암호화된 자격증명), 네트워크 정보, 클러스터, 그리고 '오더(Order)'라 부르는 추적 가능한 인프라 생애주기 작업까지 단일 소스로 관리한다. 운영자가 '모든 서버 재부팅' 같은 작업을 요청하면 고유 ID를 가진 오더가 생성되고, 이 이벤트를 Amazon EventBridge가 해당 AWS Step Functions 워크플로로 라우팅해 상태 변화에 따라 진행 상황이 업데이트된다. API 계층은 Amazon API Gateway로 CRUD 작업을 노출하고, Lambda 함수가 요청을 검증해 오더 관리 시스템과 연동하며, 운영자는 CLI나 API 지식 없이도 통합 포털에서 셀프서비스로 작업을 수행할 수 있다.

💡 DynamoDB 기반 단일 인벤토리와 이벤트 기반 오케스트레이션을 쓰면, 사이트가 수백 곳으로 늘어나도 서버 재부팅 같은 반복 작업을 사람이 SSH로 하나씩 처리하지 않고 셀프서비스·감사 가능한 방식으로 확장할 수 있다.

MCP went stateless: Is your AWS MCP server deployment well-architected?

AWS Architecture

2026년 7월 28일 MCP(Model Context Protocol) 명세가 프로토콜 코어를 스테이트리스로 전환해, initialize 핸드셰이크와 세션 헤더를 제거했다. AWS는 이 2026-07-28 스펙을 AWS Well-Architected Agentic AI Lens의 각 기둥에 대응시켜, 스테이트리스 구조가 상시 가동되는 세션 인프라 비용과 버스트성 에이전트 트래픽에 대한 과잉 프로비저닝을 동시에 없애준다고 설명한다. 다만 subscriptions/listen 메서드로 변경 알림을 하나의 옵트인 POST 응답 스트림으로 묶는 장시간 연결은 여전히 남아 있어, 로드밸런서·프록시·컴퓨트 계층의 유휴 타임아웃을 점검해야 한다. 명세는 Roots, Sampling, Logging, HTTP+SSE 트랜스포트를 12개월의 유예 기간을 두고 폐기 예정으로 지정했고(가장 빨리 제거될 수 있는 시점은 2027년 7월), ping·logging/setLevel·notifications/roots/list_changed는 즉시 제거했다. cacheScope를 "public"으로 설정하면 한 테넌트의 응답을 다른 테넌트에게 캐시로 내어줄 위험이 있어, 테넌트별로 응답이 완전히 동일한 경우에만 신중하게 넓혀야 한다.

💡 세션 인프라를 없애는 스테이트리스 MCP 전환은 에이전트 트래픽용 상시 과잉 프로비저닝 비용을 직접 줄여주지만, cacheScope를 섣부르게 public으로 여는 것은 새로운 멀티테넌트 데이터 유출 경로가 될 수 있어 배포 전 점검이 필요하다.

How we could save petabytes of cache storage with Zstandard and Pingora

Cloudflare

Cloudflare는 캐시 계층 내부에서 압축을 적용해 같은 하드웨어로 더 많은 캐시 공간을 확보할 수 있는지 실험한 'Cache Transcoding' 프로토타입을 소개했다. 이 프로토타입은 Content-Encoding이 없고 압축 가능한 텍스트이며 Content-Length가 최소 4KiB 이상인 200 OK 응답만 zstd로 인코딩하며, 슬라이스 서브요청이나 이미 압축된 응답, 바이너리 콘텐츠 등은 건드리지 않는다. 4KiB 기준값은 대상에서 제외되는 바이트를 약 1%로 줄이면서도 작은 요청 건당 오버헤드를 없애는 절충점으로 선택됐다. 10개 캐시 서버에 걸쳐 100만 건 이상의 요청을 보낸 성능 테스트에서, 195KiB와 272KiB 크기의 두 테스트 자산이 모두 약 2.8배 압축됐다. 이번 실험은 의도적으로 압축 친화적인 코퍼스를 썼기 때문에 이 비율을 인터넷 전체 텍스트 객체에 그대로 적용할 수는 없다고 Cloudflare는 밝혔다.

💡 캐시 계층에서 zstd 전송 압축으로 동일 하드웨어에서 2.8배 압축률을 확보했다는 결과는, CDN·엣지 캐시를 운용하는 팀에게 캐시 용량 증설 없이도 히트율과 스토리지 비용을 개선할 여지가 있음을 보여준다.

5 ways to augment security risk management in the AI era

Red Hat

Red Hat은 IT 운영·보안팀이 취약점 스캐너, 관측성 도구, Red Hat Lightspeed 같은 위협 인텔리전스 소스에서 매일 수천 건의 경보를 받는 현실을 짚으며, AI 시대에 보안 위험 관리를 보강하는 다섯 가지 방법을 제시한다. IBM의 'X-Force Threat Intelligence Index 2026'을 인용해, 취약한 소프트웨어 스캐닝이 잘못 구성된 접근 제어 악용에 이어 두 번째로 흔한 공격 경로라고 짚는다. Event-Driven Ansible은 SIEM에서 경보가 들어오는 즉시 조치 단계나 사람 검토를 거치는 워크플로를 실행해, 사실 수집부터 격리, 패치 적용·검증, ITSM 티켓 생성까지 자동화할 수 있다고 소개한다. RHEL 환경에서는 Red Hat Lightspeed가 패치가 필요한 시스템을 구체적으로 짚어주고 관련 Ansible 플레이북을 제공하며, 다른 플랫폼에서는 Ansible Automation Platform의 코딩 어시스턴트와 MCP 서버 연동으로 자동화를 만들어 대규모로 패치를 적용할 수 있다고 설명한다. 이 글은 완화·패치·검증·확인 사이의 격차를 좁히는 과정을 단기·중기·장기 3단계로 나눠 제시한다.

💡 SIEM 경보를 Event-Driven Ansible로 바로 연결해 격리·패치까지 자동화하면, 취약점 악용 속도가 수동 대응 속도를 앞지르는 상황에서도 패치 사이클을 실제로 단축할 수 있다.

Why the virtualization decision keeps getting deferred

Red Hat

Red Hat은 가상화 플랫폼 전환을 미루는 가장 흔한 이유로 '전환 기간 중 기존 플랫폼과 신규 플랫폼 비용을 동시에 내야 하는 첫해 이중 비용'을 짚는다. 실제로 많은 인프라팀이 거의 2년째 대안을 검토하면서도, 이 결정이 같은 해 AI 예산과 자원을 놓고 경쟁하면서 계속 미뤄지고 있다고 설명한다. 해법으로 자격을 충족하는 3년 계약을 맺으면 Red Hat OpenShift Virtualization 구독의 첫 1년 비용을 면제해, 그 비용 중첩 구간만 없애준다고 제시한다(하드웨어·마이그레이션 작업·교육 비용은 별도). 이를 판단하기 위해 무료·셀프서브 방식의 'Red Hat OpenShift migration advisor'로 현재 환경을 즉시 점검할 수 있고, 더 구체적인 계획이 필요하면 Red Hat Consulting이나 파트너가 2주간 진행하는 유료 'Virtualization Migration Assessment'를 받을 수 있으며, 이후 실제로 전환하면 이 평가 비용은 구독료에서 다시 크레딧으로 돌려받는다. OpenShift Virtualization은 가상머신을 컨테이너 워크로드와 같은 플랫폼, 같은 운영 모델 위에서 돌리기 때문에, 하이퍼바이저만 바꾸는 것과 달리 컨테이너·하이브리드 클라우드·AI·엣지로 점진적으로 확장할 여지를 남긴다.

💡 첫해 이중 비용이라는 전환 장벽 하나만 제거해주는 제안이라는 점을 인지하면, 인프라팀은 이 무료 혜택을 가격 협상 지렛대로만 쓰고 실제 마이그레이션 범위·속도는 자체 평가 결과에 맞춰 독립적으로 결정할 수 있다.

How Ask Red Hat earns trust in enterprise AI troubleshooting

Red Hat

Red Hat은 AI에 대한 인간의 신뢰를 다룬 562건의 실증 연구를 검토한 결과, 역량·설명 가능성·투명성·개인별 성향이 사람들이 AI 답변을 신뢰할지를 일관되게 좌우한다고 인용하며, 'Ask Red Hat'이 바로 이 신뢰 문제를 풀기 위해 설계됐다고 소개한다. Ask Red Hat은 여러 Red Hat 웹사이트에 탑재된 대화형 AI로, 프런티어 모델만큼 넓은 지식을 갖추는 것이 목표가 아니라 '검증 가능한 최고의 Red Hat 전문가'가 되는 것을 목표로 100만 건이 넘는 Red Hat 전문 자료에서 답을 찾는다. 내부적으로는 스킬 라우팅과 답변 생성을 분리해, 라우팅 정확도와 답변 품질을 각각 독립적으로 평가할 수 있게 설계했다. 신뢰 지표를 단일 숫자로 단순화하면 저위험 조회와 프로덕션에 영향을 줄 수 있는 질문의 차이가 묻히기 때문에, 대신 출처를 제시하고 위험도가 높을 때는 명확히 경고하는 방식을 택했다고 밝힌다. 개발자용 무상 구독을 포함한 Red Hat 구독이 있으면 지금 바로 Ask Red Hat을 써볼 수 있고, 각 답변에 엄지 아이콘으로 피드백을 남기면 팀이 전부 확인해 개선에 반영한다.

💡 스킬 라우팅과 답변 생성을 분리해 독립적으로 평가하는 설계는, 사내 지원 챗봇을 운영하는 팀이 답변 정확도 문제를 리트리벌 문제와 생성 문제로 나눠 디버깅할 수 있게 해 MTTR을 줄여준다.

Introducing Azure Multicloud Interconnect for AWS

Azure

마이크로소프트와 AWS는 표준화된 오픈 API 규격을 함께 써서 Azure와 AWS 사이에 전용 프라이빗 연결을 단순한 경험으로 제공하는 'Azure Multicloud Interconnect'를 발표했다. 기존에는 물리적 연결, 라우팅 설정, 프로비저닝 조율, 모니터링, 생애주기 관리를 여러 공급자에 걸쳐 직접 조립해야 했지만, 이 서비스는 그 복잡성을 추상화한다. Azure Multicloud Interconnect는 Azure Private Link까지 이어지는 고용량 프라이빗 연결을 제공해, 클라우드 경계를 넘나들며 데이터에 접근해야 하는 학습·추론 워크로드를 지원하도록 설계됐다. 마이크로소프트는 이를 AWS의 'AWS Interconnect-multicloud'와 짝을 이루는 서비스로 소개하며, 기본 제공되는 MACsec 보안과 포 나인(four-nines) 가용성, 클릭 한 번으로 확장 가능한 스케일을 강조한다. 양사는 이 모델을 단일 클라우드 대 클라우드 관계를 넘어, 같은 오픈 API 규격으로 다른 하이퍼스케일 클라우드 제공자 간 상호운용성까지 확장할 수 있는 출발점으로 본다고 밝혔다.

💡 두 하이퍼스케일러가 같은 오픈 API로 전용 프라이빗 연결을 표준화했다는 것은, 멀티클라우드 아키텍처를 운영하는 네트워크팀이 직접 조립하던 전용선·라우팅 구성 작업을 상당 부분 걷어낼 수 있다는 뜻이다.

Inside Microsoft’s marketing team: Scaling expertise with AI

Azure

마이크로소프트는 자사 마케팅 조직이 Microsoft Foundry(엔터프라이즈 AI 애플리케이션 구축·관리 플랫폼)를 활용해 업무 맥락에 내재된 에이전트를 만든 사례를 소개한다. 핵심 교훈은 'AI는 접근 가능한 데이터만큼만 좋다'는 것으로, 문서·워크플로·비즈니스 시스템·소통 기록에 흩어진 정보를 Microsoft IQ로 연결해 직원이 여러 소스를 직접 취합하지 않고도 에이전트가 관련 정보를 찾아 더 나은 의사결정을 돕도록 했다. 마케팅팀은 매년 200건이 넘는 블로그 글을 검토·발행하는데, 기존에는 소수의 전문가가 같은 검토 기준을 반복 적용하는 데 많은 시간을 썼다. 이를 줄이기 위해 한 콘텐츠 리더가 자신이 쓰던 좋은 블로그 평가 루브릭을 문서화하고 다듬어, 모든 초안을 처음부터 다시 검토하지 않아도 되게 만들었다. 이 글은 단일 에이전트가 아니라 한 팀에서 성공한 에이전트·AI 스킬을 다른 팀이 그대로 재사용할 수 있게 만든 것이 진짜 돌파구였다고 강조한다.

💡 성공한 에이전트·AI 스킬을 팀 간에 그대로 재사용할 수 있게 만든 것이 핵심이었다는 점은, 사내 플랫폼팀이 개별 에이전트 구축 지원보다 재사용 가능한 에이전트 카탈로그와 공유 구조를 먼저 갖춰야 확산 속도가 빨라진다는 뜻이다.

Introducing Adaptive Intelligence: Undermining the economics of every bot attack

Cloudflare

Cloudflare는 봇 공격의 경제성을 역전시키는 것을 목표로 하는 'Adaptive Intelligence' 봇 탐지 시스템을 발표했다. 기존의 규칙 기반 탐지는 결정론적이어서 같은 입력에는 항상 같은 출력이 나오는데, 공격자가 자동화된 프로브로 수없이 시도하며 경계를 학습해 결국 뚫는 구조라고 지적한다. 특히 정교한 공격자는 대규모 레지덴셜 프록시 네트워크에 요청을 분산시켜 각 주소의 속도를 낮추고 매번 새 유저 에이전트나 봇 핑거프린트를 써서, 로그인·결제·계정복구 플로우를 단일 출처 속도 제한을 넘지 않으면서 통과한다. Adaptive Intelligence는 방어 쪽이 반응하는 비용을 공격자가 우회하는 비용보다 낮게 만들고, 공격자가 시스템을 학습하는 데 쓰는 피드백 자체를 차단하는 두 조건을 동시에 만족시켜 이 경제성을 뒤집으려 한다. Cloudflare는 이런 방식으로 봇을 탐지하는 다른 제품은 없다고 주장하며, 공격자를 완전히 막기보다 공격을 계속할 가치가 없을 만큼 느리고 비싸게 만드는 것이 목표라고 설명한다.

💡 공격자가 자동화 프로브로 학습하는 피드백 자체를 차단한다는 설계는, 결정론적 규칙 기반 WAF·봇 방어에 의존하던 팀이 규칙 업데이트 경쟁에서 구조적으로 불리했던 위치를 벗어날 수 있다는 뜻이다.

DevOps & 인프라

Claude Fable 5.1 watermark: It has a blind spot developers can’t ignore

The New Stack

Anthropic는 화요일 출시한 Claude Fable 5.1의 생성 텍스트에 통계적 워터마크(statistical signature)를 삽입했다. 다만 이 워터마크는 코드 토큰에는 적용되지 않는데, 코드에 워터마크를 걸면 정확도가 깨질 수 있기 때문이다. 같은 출시에서 Anthropic은 대규모 모델 증류(distillation)를 겨냥한 새로운 API 제한도 함께 도입했다. 기사 제목은 이 워터마크에 개발자가 무시해서는 안 될 '사각지대(blind spot)'가 있다고 지적한다. 다만 본문 전체를 가져오지 못해 이 기사는 제목과 발췌문, 메타 설명 수준의 정보로만 작성했다.

💡 코드 토큰이 워터마크 대상에서 빠진다는 점은, 생성 코드의 출처 추적이나 AI 생성물 탐지를 워터마크에 의존해 설계 중인 배포 파이프라인이 있다면 코드 경로에서는 그 가정이 성립하지 않는다는 뜻이다.

Runway wants to generate software as you use it. Solaris is its first step.

The New Stack

Runway는 월요일 Solaris를 발표했다. 이는 회사가 '인터페이스 월드 모델(Interface World Models)'이라 부르는 새로운 AI 시스템 범주의 첫 모델이다. 설명에 따르면 이 모델은 화면에 보이는 시각적 요소 자체를 애플리케이션으로 바꾸는 방식으로 동작한다. 즉 정적인 화면을 생성하는 것이 아니라, 보이는 것 자체가 곧 상호작용 가능한 앱이 되도록 만드는 접근이다. 다만 본문 전체를 가져오지 못해 구체적인 구현 방식이나 벤치마크, 공개 일정 등은 확인하지 못했고, 이 요약은 제목과 발췌문, 페이지 설명 수준의 정보로만 작성했다.

💡 '보이는 화면이 곧 앱'이라는 개념이 실제로 구현된다면, 프런트엔드 배포 파이프라인이나 UI 생성 자동화를 다루는 데브옵스 팀은 기존 렌더링·배포 경계가 흐려지는 상황에 대비할 필요가 있다.

Anthropic’s Fable 5.1 is a bit cheaper, a bit smarter, and refuses a lot less

The New Stack

Anthropic는 화요일 주력 모델인 Fable과 Mythos의 최신 버전 Fable 5.1과 Mythos 5.1을 출시했다. 가격은 기존 Fable의 입력 10달러/출력 50달러(백만 토큰당) 체계를 그대로 유지했다. 대신 캐시 읽기 비용을 75% 인하해 반복 호출이 많은 워크로드의 실질 비용을 낮췄다. 또한 이전 Fable 5가 특정 요청을 Opus로 떠넘기게 만들었던 안전장치(safeguards)도 이번에 조정됐다. 본문 전체는 확보하지 못해 세부 수치와 맥락은 제목·발췌문·페이지 설명 수준에서만 확인했다.

💡 캐시 읽기 비용 75% 인하는 긴 대화나 반복 프롬프트가 많은 운영 환경의 실질 API 비용을 바로 낮출 수 있어, 기존 Fable 5 기반 파이프라인의 비용 재계산이 필요하다는 뜻이다.

Secure mainframe access with HashiCorp Boundary

HashiCorp

HashiCorp는 메인프레임 접근을 위한 Boundary 통합을 공개했다. 기존 메인프레임 접근은 장기 유효한 계정·비밀번호·SSH 키를 팀 단위로 공유하는 방식이라 교체 주기가 느리고 감사 추적이 파편화된다는 문제가 있었다. Boundary는 Okta, Ping Identity 같은 OIDC 공급자 기반의 신원 기반 접근 제어와 정책 기반 타깃 제어를 적용하고, SSH·TN3270 세션에 자격증명을 즉시 주입(just-in-time)하는 방식으로 이를 대체한다. 지원 경로는 HMC용 HTTPS, z/OS용 SSH, 그리고 TN3270/TN3270E 세 가지이며, HCP Vault Dedicated와 HashiCorp Vault Enterprise, IBM Vault Self-Managed for Z and LinuxOne과 연동된다. 배포 구조는 메인프레임과 같은 네트워크의 리눅스 VM에 올라간 워커가 컨트롤 플레인으로 암호화된 아웃바운드 연결을 맺고 승인된 세션을 대상에 프록시하는 방식이며, 모든 세션은 중앙에서 기록·로그로 남아 공유 자격증명 방식이 만들었던 감사 추적 공백을 메우는 것을 목표로 한다.

💡 메인프레임 접근에 OIDC 기반 신원 제어와 세션 기록을 적용하면, z/OS·HMC 운영팀이 공유 계정 의존을 끊고 개인 단위 감사·규정 준수 증적을 확보할 수 있다.

HashiCorp Vault agentic IAM is now generally available

HashiCorp

HashiCorp Vault의 에이전틱 identity and access management(IAM) 기능이 정식 출시(GA)됐다. 2026년 6월 퍼블릭 프리뷰로 공개됐던 이 기능은 Vault Enterprise 2.1에서 GA로 전환되며, 기존의 사람·비인간(non-human) 신원 관리에 더해 AI 에이전트 신원까지 아우른다. 에이전트는 authorization_details 클레임을 담은 서명된 OAuth JWT로 인증하고, Vault가 이 신원을 검증해 권한 부여 규칙과 대조한다. 새 기능에는 에이전트 신원·인증 활동·정책을 한 화면에 보여주는 에이전트 레지스트리 UI와, IETF RFC 9396 기반 Rich Authorization Requests(RAR)로 요청 단위 세밀한 권한 부여를 강제하는 기능이 포함된다. 위임된 OAuth JWT를 검증해 사용자를 대신해 행동하는 에이전트를 지원하는 On-Behalf-Of(OBO) 워크플로도 제공되며, Terraform의 vault_agent_registration·vault_oauth_resource_server_config_profile 리소스로 이 설정을 코드로 관리할 수 있다. IBM Verify, Auth0, PingFederate, Microsoft Entra, Okta 등 신원 공급자와의 연동도 검증됐다.

💡 에이전트 신원을 Vault의 기존 IAM 체계에 통합하면, 운영팀은 AI 에이전트를 위한 별도 비밀 관리 체계를 새로 구축하지 않고도 기존 비밀·접근 정책 안에서 에이전트 권한을 감사·제한할 수 있다.

Bringing the Most Advanced Sampling to the OpenTelemetry Collector

Honeycomb

샘플링은 대규모 관측성 파이프라인을 운영하는 모든 팀이 결국 마주치는 기술로, 대역폭·CPU·메모리와 비용, 백엔드 성능 사이의 트레이드오프를 수반한다. Honeycomb는 자사의 오픈소스 테일 샘플링 프록시 Refinery에서 쌓은 경험을 바탕으로 만든 어댑티브 테일 샘플링 프로세서를 OpenTelemetry Collector에 기증한다고 밝혔다. 기존 샘플링 방식은 세 가지뿐이었는데, 트래픽 스파이크 때도 예산을 넘기지 않으면서 중요한 컨텍스트를 지키는 '어댑티브 테일 샘플링'이 네 번째 옵션으로 제시된다. 이 기증에는 트레이스 핑거프린팅과 샘플링 비율 귀속(attribution) 기능도 포함돼, 어떤 트레이스 패턴이 어떤 비율로 샘플링됐는지 추적할 수 있다. 해당 기능은 Honeycomb Collector Distribution을 통해 지금 바로 사용해볼 수 있다.

💡 어댑티브 테일 샘플링과 샘플링 비율 귀속이 OTel Collector 표준 기능으로 들어오면, 벤더 종속 샘플링 프록시 없이도 트레이스 예산과 중요 컨텍스트 보존을 동시에 관리할 수 있어 관측성 파이프라인 비용 절감에 바로 쓸 수 있다.

Making Rust observability reliable at scale with OpenTelemetry

Datadog

Datadog는 러스트(Rust)로 만든 프로덕션 서비스가 늘어나면서 팀마다 다른 트레이싱 라이브러리를 쓰고 컨텍스트 전파 방식이 크레이트에 따라 달라져, 요청이 러스트 서비스 경계에서 끊기며 장애 조사 시간이 늘어나는 문제를 겪었다고 밝힌다. Datadog는 하루 100조 건 이상의 이벤트를 수집하는데, 성능이 중요한 인프라에 러스트 채택이 늘면서 이 문제가 커졌다고 설명한다. 많은 팀이 구조화된 로깅 라이브러리인 tracing 크레이트에 OpenTelemetry 익스포터를 덧붙여 썼는데, 이 때문에 같은 요청 경로 안에서 tracing 기반과 OpenTelemetry 기반 계측이 뒤섞여 내보낼 때 트레이스가 조각나는 문제가 발생했다. 이를 해결하기 위해 Datadog APM 팀은 OpenTelemetry에 직접 기여하면서 그 위에 자체 러스트 트레이서 'dd-trace-rs'를 만들었다. 이 글은 전파(propagation)와 샘플링에서 겪은 설계상의 트레이드오프와, 프로덕션에서 러스트 서비스 트레이싱을 운영하며 얻은 교훈을 다룬다.

💡 여러 팀이 각자 다른 계측 라이브러리를 섞어 쓰던 러스트 서비스 경계에서 트레이스가 끊기는 문제를 표준 트레이서 하나로 통일해 풀었다는 사례는, 다중 언어 마이크로서비스 환경에서 언어별 계측 파편화를 관측성 비용 문제로 다뤄야 한다는 시사점을 준다.

From traces to experiments: A loop for improving AI agents

Datadog

Datadog는 지난 분기 출시한 지원 에이전트를 예로 들며, 출시 초반 데모는 잘 됐지만 몇 달 뒤 긴 대화 요약이 잘리고 청구 API 호출에서 지연 스파이크가 나타나는 등 문제가 드러나는 상황을 다룬다. 팀들은 보통 프롬프트를 손보거나 모델을 올리는 식으로 대응하는데, 성능이 나아져도 왜 나아졌는지, 트래픽이 바뀌어도 그 개선이 유지될지는 알 수 없다는 점을 짚는다. 문제는 텔레메트리 부족이 아니라, 에이전트형 시스템을 배포한 팀이 리뷰할 수 있는 양보다 더 많은 트레이스 데이터를 쌓아두면서도 어디가 부진한지 식별하고 변화가 실제로 도움이 됐는지 반복 측정할 방법이 없다는 데 있다고 설명한다. 이 글은 트레이스를 투자 우선순위를 보여주는 로드맵으로 읽는 법, 평가(evaluation)와 실험(experiment)을 함께 돌려야 하는 이유, 그리고 이 둘을 최적화 루프로 합치는 방법을 다룬다. 예로는 '요약 프롬프트가 15개 이상 메시지의 스레드에서 성능이 떨어지고, 그런 티켓은 재오픈율이 평소의 두 배'처럼 트레이스와 평가 점수를 연결해 막연한 우려를 구체적이고 검증 가능한 주장으로 좁히는 방식을 든다.

💡 트레이스를 평가 점수와 연결해 검증 가능한 주장으로 좁히는 방식은, 프롬프트·모델 교체를 '감'으로 반복하는 에이전트 운영팀이 실제로 개선이 유지되는지 실험으로 확인하는 체계로 옮겨가게 해준다.

Visualize how CUPED adjusts experiment results with Datadog

Datadog

CUPED(Controlled-experiment Using Pre-Experiment Data)는 실험 전 데이터를 활용해 지표 분산을 줄이고 더 적은 데이터로도 정밀한 실험 결과를 얻게 해주는 기법이다. 다만 사전 노출 지표와 대상 속성이 많을 경우 CUPED 보정 후 상승폭(lift)과 원본 상승폭의 차이를 설명하기 어렵다는 문제가 있다. Datadog Experiments에 새로 추가된 'CUPED adjustments visualization'은 이 차이를 일련의 개별 보정값으로 쪼개 시각화해 보여준다. 각 지표 룩백이나 배정 속성이 예상 lift를 어느 방향으로, 얼마나 조정했는지를 연결해, 어떤 공변량(covariate)이 가장 큰 영향을 미쳤는지 한눈에 파악할 수 있게 한다. 이를 통해 팀은 CUPED가 왜 lift 추정치를 바꿨는지 이해하고, 'CUPED 폭포(waterfall)'에서 각 보정 단계를 추적하며 결과를 더 풍부한 맥락 속에서 해석할 수 있다.

💡 CUPED 보정 차이를 공변량 단위로 쪼개 보여주면, 실험 플랫폼을 운영하는 팀이 '왜 이 숫자가 나왔는지' 설명하지 못해 실험 결과를 신뢰하지 못하는 문제를 줄일 수 있다.

Testing cookie behavior across hundreds of web surfaces with our in-house auditor

Dropbox

Dropbox는 자체 제작한 쿠키 배너와 동의 시스템에 맞춰, Playwright 브라우저 자동화로 실제 방문자처럼 행동하는 '쿠키 감사기(cookie auditor)'를 만들어 수백 개 웹 페이지의 쿠키 동작을 검증한다고 밝혔다. 승인된 쿠키 목록과 예외 규정은 코드 밖에 따로 두어, 프라이버시팀이 엔지니어의 코드 변경·배포 없이도 기준을 바로 갱신할 수 있게 했다. 동의 배너를 외부 제품 대신 자체 구축했기 때문에 감사기를 기존 동의 인프라와 긴밀하게 통합할 수 있었고, 그 덕분에 서비스가 바뀔 때마다 테스트 범위도 함께 조정하기 쉬웠다. 감사기는 페이지마다 미국 방문자, EU 방문자, GPC(Global Privacy Control) 신호를 보내는 방문자를 각각 시뮬레이션하는 세 가지 테스트를 새 브라우저 세션에서 실행해, 페이지 로드 시점부터 이미 로드된 쿠키가 기대와 일치하는지 먼저 확인한다. 이어서 감사기는 배너·플로팅 컨트롤·환경설정창·푸터 링크 등 22개 지원 언어로 다양하게 나타나는 동의 컨트롤을 찾아 비필수 쿠키를 거부한 뒤, 페이지를 새로고침해 그 다음에 어떤 일이 벌어지는지 확인한다.

💡 쿠키 승인 목록을 코드 밖 데이터로 분리하고 Playwright로 자동 감사하는 구조는, 웹 규모가 커질수록 수동 QA로는 따라갈 수 없는 프라이버시 규정 준수를 CI에 편입시킬 수 있는 패턴을 제시한다.

Fin's CTO on Building Great Engineering Organizations in the AI Era

Honeycomb

Fin(옛 Intercom)의 CTO 대러 커런(Darragh Curran)은 엔지니어링 생산성을 두 배로 늘리겠다는 공개 목표를 세웠다가 실제로는 거의 세 배 가까이 끌어올렸다. Honeycomb의 공동창업자 채리티 메이저스(Charity Majors)가 새로 시작한 영상 시리즈 'Leading With Observability' 첫 화에서 그를 초대해, AI가 코드를 대규모로 작성하고 AI 기반 PR 리뷰 시스템을 구축한 과정, 그리고 전환기 동안 리더십이 더 현장 중심적으로 바뀐 과정을 다뤘다. 커런은 관측성을 팀이 AI 주도 변화를 신뢰할 수 있게 만드는 '신뢰 메커니즘'이라고 표현했다. 그는 책 'Observability Engineering'에 리더십 관점을 담은 챕터를 썼는데, 그 글은 '뭔가를 하고, 배우고, 다음 걸 한다'는 단순한 반복 루프로 요약된다. 이 영상은 15분 내외로 짧게 구성된 시리즈의 첫 편이다.

💡 AI 기반 PR 리뷰를 도입하면서도 관측성을 '신뢰 메커니즘'으로 먼저 세웠다는 사례는, AI로 코드 생산량을 늘리려는 엔지니어링 조직이 관측성 투자를 생산성 프로젝트보다 먼저 또는 동시에 해야 한다는 것을 보여준다.

Optimize EKS operations with agents: Reduce MTTR with AWS DevOps Agent and a Kubernetes Operator

AWS DevOps

AWS는 EKS에서 OOMKilled나 IP 고갈 같은 장애가 발생했을 때, 엔지니어가 수집 단계에서 시간을 쓰는 것 자체가 평균 복구 시간(MTTR)의 순수 오버헤드라고 지적한다. 기존 AI 도구는 한계가 있는데, K8sGPT는 현재 리소스 상태만 분석하고 Amazon Bedrock Agents는 도구 연동과 파이프라인을 수동으로 구성해야 해서 엔드투엔드 자동 조사를 제공하지 못한다는 것이다. 이 글은 AWS DevOps Agent(코드 저장소·관측성 도구·CI/CD 파이프라인·스킬을 연결해 자율적으로 근본 원인을 분석하는 프런티어 에이전트)를 웹훅으로 자동 호출하는 'DevOps Agent Operator'라는 쿠버네티스 오퍼레이터를 소개한다. 쿠버네티스는 이벤트를 약 1시간만 보관하고 재시작된 컨테이너는 로그를 덮어쓰며 삭제된 팟은 로그를 완전히 잃기 때문에, 장애 직후 바로 데이터를 수집하지 않으면 핵심 증거가 영구히 사라진다는 점이 이 오퍼레이터가 필요한 이유다. 오퍼레이터는 S3나 CloudWatch Logs 업로드가 실패하면 지수 백오프로 재시도하고, 단일 조정(reconcile) 워커와 처리완료 어노테이션으로 팟 100개가 동시에 장애가 나도 하나씩 순서대로 처리해 중복 보고를 막으며, WEBHOOK_MIN_SEVERITY·WEBHOOK_SKIP_CATEGORIES 환경변수로 어떤 장애에만 조사를 트리거할지 조절할 수 있다.

💡 장애 직후 1시간 안에 사라지는 쿠버네티스 이벤트·로그를 오퍼레이터가 자동으로 캡처해둔다는 구조는, 온콜 엔지니어가 증거 수집에 쓰던 시간을 없애 MTTR을 실제로 줄이는 동시에 대량 장애에서도 중복 알림 폭주를 막아준다.

곧, if(kakao)26의 이야기가 시작됩니다.

카카오

카카오의 기술 콘퍼런스 if(kakao)26이 곧 공개된다는 예고 글이다. 올해 슬로건은 '모든 연결에 지능을'이다. 카카오는 이 콘퍼런스를 기술을 만들며 마주한 고민과 질문, 그 과정에서 얻은 경험과 발견을 나누는 자리로 소개한다. 다만 구체적인 개최 일정이나 장소, 세션 트랙, 발표자, 참가 신청 방법 등은 이 예고 글의 본문에서 확인되지 않는다. 본문 전체를 가져오지 못해, 이 요약은 제목과 발췌문 수준의 정보로만 작성했다.

💡 아직 구체적 일정과 세션이 공개되지 않은 예고 단계이므로, 참석을 검토하는 클라우드·데브옵스 팀은 공식 if.kakao.com 발표를 기다렸다가 세션 트랙을 확인한 뒤 참가 여부를 결정하는 것이 합리적이다.

같은 장애를 두 번 겪지 않기 위해, 배포 전에 리뷰합니다 — KRIS 개발기

카카오

이 글은 카카오의 사내 AI 코드 리뷰 서비스 '코드버디(CodeBuddy)'의 응답 품질을 LLM as a Judge로 평가했던 이전 글에 이어지는 KRIS 개발기다. 제목에서 드러나듯 핵심 목표는 '같은 장애를 두 번 겪지 않기 위해 배포 전에 리뷰한다'는 것으로, KRIS는 이 배포 전 리뷰와 관련된 시스템으로 보인다. 글은 평가 체계를 세운 뒤 자연스럽게 이어진 다음 질문에서 시작한다고 밝힌다. 다만 KRIS가 정확히 어떤 기능을 하는 시스템인지, 배포 전 리뷰가 구체적으로 어떻게 동작하는지, CodeBuddy와의 관계나 아키텍처 세부사항은 본문을 가져오지 못해 확인되지 않는다. 이 요약은 제목과 발췌문 수준의 정보로만 작성했다.

💡 배포 전 리뷰로 같은 장애의 재발을 막으려 한다는 목표 자체는, 사내 플랫폼팀이 장애 재발률을 배포 게이트의 핵심 지표로 삼아야 한다는 방향성을 뒷받침한다.

이 다이제스트는 RSS 피드에서 수집한 뒤 AI(Claude)가 요약·정리했습니다. 자세한 내용은 원문 링크를 확인하세요.