📰 데일리 테크 다이제스트 - 2026-08-04

🔥 오늘의 주요 소식

Analyze and remediate technical debt autonomously with AWS Transform – continuous modernization

AWS가 지난 6월 프리뷰로 선보였던 AWS Transform의 'continuous modernization' 기능을 정식 출시(GA)했다. 이 기능은 GitHub·GitLab·Bitbucket 등에 연결된 수천 개 저장소 전반의 기술 부채를 자동으로 스캔해 현황을 한눈에 보여주고, 문제의 우선순위를 매긴 뒤 사람의 검토(human oversight)를 거쳐 자동 리미디에이션을 예약 실행할 수 있게 해준다. 여기에는 버전 업그레이드, 런타임·API 마이그레이션, 언어 전환, 람다 런타임 업그레이드 같은 기존 AWS Transform의 코드 현대화 기능이 그대로 활용되며, 조직의 'AI 에이전트 준비도(agentic readiness)'와 현대화 준비도를 진단하는 분석도 제공한다. 또 AWS Security Agent와 연동해 소스 코드 수준의 보안 취약점까지 함께 탐지·수정할 수 있다. 사용자는 AWS Transform 웹 콘솔, CLI, AWS Transform Kiro, 또는 다른 코딩 에이전트에 얹는 AWS Transform 스킬 중 원하는 방식으로 접근할 수 있고, IDE에서 분석을 실행하고 웹 콘솔에서 진행 상황을 추적하는 등 작업 상태와 맥락이 모든 화면에서 공유된다. 이번 GA는 프리뷰 때와 마찬가지로 미국 동부(버지니아 북부), 유럽(프랑크푸르트) 등 AWS Transform이 지원하는 리전에서 제공된다.

💡 왜 중요한가: 수천 개 저장소의 EOL 의존성·구식 프레임워크를 사람이 일일이 찾아다니는 대신 상시 스캔하고 우선순위까지 매겨준다는 것은, 유지보수 인력이 부족한 대규모 조직에 실질적인 지렛대다. 다만 AWS도 자동 리미디에이션에 'human oversight'를 명시적으로 넣어둔 만큼, 리뷰 게이트를 생략하고 이걸 완전 자동 머지로 굴리려는 유혹은 경계할 필요가 있다.

🔗 원문 보기 · AWS DevOps

Kubernetes & Cloud Native

Kubeflow SDK evolution- One million downloads and counting

CNCF

쿠버네티스 기반 ML 플랫폼 쿠브플로우(Kubeflow)의 통합 파이썬 SDK인 kubeflow-sdk가 PyPI 다운로드 100만 건을 돌파했다. 이 SDK는 2025년 11월에 TrainerClient와 OptimizerClient를 시작으로 pip install kubeflow 형태로 처음 출시됐고, 1년이 채 안 되는 기간에 100만 다운로드를 넘겼다. 그전까지는 kubeflow-training, kubeflow-katib, model-registry 등 서브프로젝트마다 SDK가 따로 있어 사용자가 여러 API와 멘탈 모델을 오가야 했는데, Kubeflow SDK & ML Experience 워킹그룹이 이를 하나의 import kubeflow로 통합했다. 설계 원칙은 YAML 작성 없이 순수 파이썬만으로 리소스를 정의하는 것, 로컬 프로세스·Docker/Podman 컨테이너·쿠버네티스 세 가지 백엔드를 코드 변경 없이 설정 한 줄로 전환할 수 있는 것, 그리고 데이터 사이언티스트(AI Practitioner)와 플랫폼 관리자라는 두 사용자 유형을 위한 일관된 워크플로를 제공하는 것이다. 현재 Trainer, Katib, Model Registry, Spark, Pipelines 등 쿠브플로우 주요 서브프로젝트가 모두 이 SDK로 통합되어 있으며, 분산 파이토치 학습도 단 15줄의 코드로 실행할 수 있다는 예시를 공식 블로그에서 제시했다.

💡 YAML과 kubectl 없이 파이썬 코드만으로 로컬 프로세스에서 쿠버네티스 프로덕션까지 동일한 API로 넘어갈 수 있다는 것은, 온콜·플랫폼 엔지니어링 관점에서 ML 팀이 인프라 세부사항 때문에 플랫폼팀에 티켓을 안 넣어도 되는 셈이라 실질적인 운영 부담 감소다. 다만 여러 서브프로젝트 SDK를 하나로 합친 지 1년이 안 된 만큼, 백엔드별 동작 차이나 버전 호환성 이슈는 프로덕션 도입 전에 직접 검증할 필요가 있다.

Run GPU batch inference on Amazon ECS Managed Instances with scale to zero

AWS Containers

AWS 컨테이너 블로그가 Amazon ECS Managed Instances 위에서 GPU 배치 추론 파이프라인을 구축하는 레퍼런스 아키텍처를 공개했다. CloudFormation 스택 하나만 배포하면 전체 파이프라인이 만들어지며, 추론 작업은 Amazon SQS 큐에 쌓아 버퍼링하고 Application Auto Scaling이 큐에 작업이 없을 때는 인스턴스 수를 0까지 줄이는 구조다. ECS Managed Instances는 AWS가 인스턴스 구성, 용량 프로비저닝, 패치, 스케일링을 대신 처리하면서도 g4dn(NVIDIA T4), g5(NVIDIA A10G), p3(V100), p4d(A100) 등 원하는 GPU 인스턴스 패밀리를 직접 고를 수 있게 해주는 완전관리형 컴퓨트 옵션이다. GPU 인스턴스를 선택하면 NVIDIA 드라이버와 CUDA 툴킷이 자동으로 사전 설치돼 있어, 팀이 드라이버 버전 관리를 따로 신경 쓸 필요가 없다. 이 조합의 핵심은 배치 추론처럼 트래픽이 간헐적인 워크로드에서 유휴 시간 동안의 GPU 과금을 없애고, 실제 추론이 실행되는 시간에 대해서만 비용을 지불하도록 만든다는 것이다. 결국 사용자는 작업을 큐에 넣는 것 외에는 프로비저닝·스케일링·GPU 드라이버 설정을 신경 쓸 필요가 없어진다.

💡 배치 추론은 트래픽이 몰렸다 끊겼다 하는 특성상 GPU 인스턴스를 상시 띄워두면 유휴 비용이 크다. SQS 큐 깊이 기반으로 0까지 스케일하는 이 구조는 GPU 비용을 사실상 종량제로 바꾸면서도 드라이버·패치 같은 운영 부담은 관리형 서비스에 위임할 수 있다는 점이 실무적으로 유효하다.

Gateway API v1.6: TCPRoute and UDPRoute Graduate to Standard

Kubernetes

쿠버네티스 SIG Network가 6월 30일 릴리스된 Gateway API v1.6.0을 정리하는 블로그 글을 공개했다. 이번 릴리스의 핵심은 TCPRoute와 UDPRoute가 실험(Experimental) 단계를 졸업해 표준(Standard) 채널의 v1 API 버전으로 승격된 것이다. 그동안 Gateway API는 HTTP·TLS 같은 L7 트래픽에만 안정적인 라우팅 모델을 제공했고, 데이터베이스·DNS·VoIP·게임·IoT 텔레메트리처럼 순수 TCP/UDP 프로토콜을 쓰는 워크로드는 일반 Kubernetes Service나 컨트롤러별 전용 CRD에 의존할 수밖에 없어 구현체 간 이식성이 없었다. TCPRoute/UDPRoute는 프로토콜과 포트만으로 백엔드까지 트래픽을 라우팅해 이 공백을 메우며, 기존 v1alpha2는 이번 릴리스로 지원 중단(deprecated)되고 추후 제거될 예정이다. 동시에 신규 실험 리소스는 기존 gateway.networking.k8s.io와 분리된 gateway.networking.x-k8s.io 그룹에 X 접두사(신규 추가된 XBackend가 그 예)를 붙여 정의하도록 바뀌어, 실험과 표준 API의 경계가 버전 문자열이 아니라 API 그룹 수준에서 명확해졌다. 실험 단계로 새로 들어온 XBackend는 Service로는 지원되지 않던 ExternalHostname 백엔드(컨퓨즈드 디퓨티 공격 위험 때문에 배제됐던 기능)를 옵트인으로 지원해, 클러스터에서 실행되는 에이전틱 워크로드의 이그레스 같은 용도에 쓰일 수 있다. 발행 시점 기준 Agentgateway, Airlock Microgateway, GKE Gateway, kgateway, NGINX Gateway Fabric, Traefik Proxy가 v1.6 컨포먼스를 통과한 구현체로 소개됐다.

💡 TCPRoute/UDPRoute의 표준 승격으로 데이터베이스·게임·IoT처럼 L7이 아닌 워크로드도 벤더 종속 CRD 없이 이식 가능한 방식으로 Gateway API에 온보딩할 수 있게 됐다. 실험 리소스를 별도 API 그룹으로 분리한 것도 어떤 API가 프로덕션에 써도 되는지 그룹명만 보고 바로 구분할 수 있게 해 준다는 점에서 운영 리스크 관리에 실질적으로 도움이 된다.

Empty sandboxes break developer experience

Docker

Docker Sandboxes를 담당하는 엔지니어 Oleg Selajev가 자사 블로그에 '빈 샌드박스'가 개발자 경험을 해치는 이유와 이를 해결하는 kits 기능을 설명하는 글을 올렸다. 새로 뜬 샌드박스는 깨끗한 파일시스템과 제한된 네트워크, 자격 증명이 없는 상태로 시작하는데, 에이전트는 곧바로 gcloud, Java, Maven, 사내 CLI, 레지스트리 자격 증명 같은 것들을 요구하게 되고, 결국 개발자는 매번 수동으로 세팅하거나 격리를 포기하고 호스트에서 에이전트를 돌리는 쪽을 택하게 된다고 지적한다. kit은 spec.yaml과 부가 파일로 구성된 일종의 계약서로, 샌드박스가 시작될 때 어떤 도구를 설치하고 어떤 네트워크 도메인을 허용·차단하며 어떤 자격 증명을 연결할지를 선언적으로 기술한다. 자격 증명은 실제 시크릿을 마이크로VM 안에 복사하지 않고, 에이전트에는 대체값만 보여준 뒤 승인된 도메인으로 나가는 요청에 한해 호스트 프록시가 실제 헤더를 주입하는 방식으로 처리된다. kit에는 이미지·엔트리포인트·정책을 전부 정의하는 kind: sandbox와 기존 샌드박스에 기능 하나만 얹는 kind: mixin 두 종류가 있는데, 여러 개를 쌓아 조합할 수 있는 mixin 방식이 대부분의 경우에 권장된다. kit은 로컬 디렉터리, Git URL, OCI 아티팩트로 배포할 수 있어 Docker Hub 같은 레지스트리에 올려두면 팀 전체가 --kit 플래그 하나로 공유해 쓸 수 있다. 글은 격리가 실제로 쓰이려면 최소한 격리를 건너뛰는 것만큼은 편해야 한다는 점을 핵심 메시지로 제시한다.

💡 샌드박스 격리와 개발 생산성은 원래 트레이드오프 관계인데, kits는 이를 보안이냐 편의냐의 양자택일이 아니라 설정을 코드화·재사용 가능하게 만들어 둘 다 챙기는 방향으로 푼다. 자격 증명을 프록시로 분리해 시크릿이 마이크로VM에 들어가지 않게 한 설계는 에이전트에 사내 API 키를 그대로 노출하는 흔한 실수를 구조적으로 막아준다는 점에서 실무적으로 유효하다.

Docker AI Governance: Audit Logs, Now Where Your Security Team Already Works

Docker

Docker가 지난 5월 출시한 AI Governance에 감사 로그 기능을 강화해, 에이전트가 트리거하는 모든 정책 판단을 조직의 SIEM으로 스트리밍하고 Docker Cloud에서 검색 가능한 형태로 제공한다고 발표했다. 정책 판단의 결과는 허용, 거부, 사람 승인 대기 세 가지뿐인데, 허용된 행동은 에이전트 출력 로그로도 재구성할 수 있지만 거부되거나 보류된 행동은 실행 자체가 일어나지 않아 출력에 흔적이 남지 않으므로, 오직 정책이 실제로 실행되는 지점(enforcement point)에서만 포착할 수 있다는 점을 핵심 근거로 든다. 새로 제공되는 기능은 두 가지로, Docker Cloud에서 조직 전체를 한 화면에서 검색할 수 있는 감사 로그(90일 보관, CSV 내보내기 지원)와, Splunk·Dynatrace 등 기존에 쓰던 SIEM으로 HTTPS 연결을 통해 감사 기록을 그대로 스트리밍하는 기능이다. 로컬 디스크로 저장하는 기존 방식도 계속 지원되며 두 방식을 동시에 켤 수 있다. 현재 커버리지는 AI Governance 라이선스를 보유하고 조직 정책이 강제 적용된 사용자를 대상으로 한 Docker Sandboxes의 정책 판단과 세션 이벤트이며, 앞으로 MCP Gateway 등 다른 정책 집행 지점의 기록도 같은 스키마로 추가돼 별도 연동 없이 커버리지가 넓어질 예정이다. 기록에는 프롬프트 내용이나 에이전트 출력, 파라미터 값은 포함되지 않고 메타데이터만 담긴다고 명시했다. Docker는 이번 기록화가 첫 단계이며, 다음 단계로 무엇이 잘못됐고 무엇을 바꿔야 하는지까지 알려주는 시스템을 구축하고 있다고 밝혔다.

💡 에이전트가 무엇을 했는지뿐 아니라 정책이 무엇을 막았는지까지 증명해야 한다는 요구가 커지는 가운데, 거부·보류 이벤트를 실행 지점에서 직접 포착해 SIEM으로 넘긴다는 점에서 사후 로그 수집으로는 메울 수 없는 감사 공백을 메운다. 보안팀이 새 콘솔을 배우지 않고 이미 쓰는 SIEM에서 그대로 확인할 수 있게 한 것도 도입 문턱을 낮추는 실질적인 차별점이다.

Cortex completes OSTIF security audit

CNCF

CNCF 산하 오픈소스 보안 지원 기관인 OSTIF(Open Source Technology Improvement Fund)가 Prometheus·OpenTelemetry용 장기 멀티테넌트 스토리지 프로젝트 Cortex의 보안 감사를 완료했다고 밝혔다. 감사는 보안 전문 기업 Quarkslab 소속 감사관 2명이 2026년 초봄에 화이트박스 코드 리뷰 방식으로 수행했다. 진행 과정은 프로젝트 파악과 기존 위협 모델 검토, 메인테이너와의 정렬을 거쳐 정적 분석 기반 코드 리뷰, 마지막으로 동적 테스트 순으로 이어졌다. 감사 범위는 특히 테넌트 경계(tenant boundary)와 클러스터 운영 기능의 기밀성·무결성·가용성에 집중됐다. 그 결과 보안에 영향을 미치는 이슈 7건(중간 등급 6건, 낮음 등급 1건)이 발견됐고, 프로젝트 전용 문서화와 수정 권고, 향후 보안 개발 방향에 대한 권고도 함께 제공됐다. CNCF와 Cortex 측은 발견된 7건 모두 검증된 수정이 반영됐다고 밝히며, 그 혜택을 보려면 최신 릴리스로 업데이트할 것을 권장한다. 전체 감사 보고서와 수정 대응 문서는 OSTIF 사이트에, 관련 후기는 Cortex와 Quarkslab 블로그에 각각 공개돼 있다.

💡 멀티테넌트 Prometheus/OTel 스토리지의 테넌트 경계가 화이트박스 감사 대상이었다는 점이 핵심이다 — 여러 테넌트가 같은 클러스터를 공유하는 관측성 스택을 운영 중이라면 격리 결함 하나가 테넌트 간 데이터 유출로 이어질 수 있으므로, 수정 사항이 반영된 최신 릴리스로의 업그레이드를 후순위로 미루면 안 된다.

AI & ML

How we built a realtime system for responsive voice AI in six months

OpenAI

OpenAI가 2026년 7월 8일 실시간 음성 AI 모델 GPT-Live-1과 경량판 GPT-Live-1 mini를 공개하면서, 반응형 음성 시스템을 6개월 만에 구축한 과정을 소개하는 글을 함께 게시했다. 기존 음성 어시스턴트는 턴(turn) 단위로 사용자 발화가 끝나길 기다렸다가 응답을 생성하는 구조라 침묵이나 배경 소음을 발화 종료로 오인하는 문제가 있었는데, GPT-Live는 이런 턴 구분 자체를 없앤 턴리스(turnless) 풀 듀플렉스 아키텍처를 채택했다. 이 모델은 입력 오디오를 끊김 없이 계속 처리하면서 동시에 출력을 생성하고, 초당 여러 번 말할지·들을지·멈출지·끼어들지·백그라운드 도구를 호출할지를 판단한다. 검색이나 깊은 추론, 에이전트 작업이 필요한 질의는 대화를 끊지 않은 채 백그라운드에서 상위 모델(출시 시점 기준 GPT-5.5)에 위임하고, 결과가 준비되면 대화 중간에 자연스럽게 끼워 넣는 방식으로 지연을 체감하지 않게 한다. ChatGPT에서는 GPT-Live-1 mini가 기존 Advanced Voice Mode를 대체하는 기본 음성 모드가 되며, 유료 요금제 사용자는 더 큰 GPT-Live-1 모델을 쓸 수 있고 전 플랫폼에 순차 적용된다.

💡 음성 어시스턴트를 요청-응답 파이프라인이 아니라 상시 스트리밍·이벤트 기반 시스템으로 재설계했다는 점이 핵심이다. 클러스터·서빙 관점에서는 지속적 양방향 스트림 유지, 백그라운드 모델 위임을 위한 오케스트레이션, 끊김 없는 폴백 처리 등 기존 요청 단위 오토스케일링과는 다른 용량 계획과 관측성 설계가 필요해진다.

클라우드 업데이트

Real-world mainframe modernization with AI: A safe, scalable path from mainframe to cloud

Google Cloud

구글 클라우드가 인프라 모더나이제이션 블로그에 AI 기반 메인프레임 전환을 다룬 글 'Real-world mainframe modernization with AI: A safe, scalable path from mainframe to cloud'를 게시했다. 오랫동안 레거시 메인프레임을 운영해온 기업들은 위험을 감수하며 유지보수를 계속 미루거나, 예측하기 힘든 리스크를 안고 '빅뱅' 일괄 전환을 감행하거나 하는 양자택일에 몰려 있었다는 문제의식에서 출발한다. 이 글은 이 딜레마를 피해 안전하고 확장 가능한 방식으로 전환할 수 있다는 것을 실제 사례를 통해 보여준다고 밝힌다. 구글이 취해 온 접근은 Gemini 기반 코드 분석으로 COBOL 등 레거시 자산을 파악하고, 이를 점진적으로 현대 언어로 재작성한 뒤, 운영 중인 메인프레임과 전환된 애플리케이션을 병행 가동해 두 시스템의 산출 결과를 서로 대조 검증하는 식으로 리스크를 낮추는 것이다. 이런 평가-재작성-병행검증 구조는 시스템 전체를 한 번에 전환하는 대신, 업무 중단 없이 부분별로 검증하며 넘어갈 수 있게 해준다. 이번 글은 이 방법론이 실제 환경에서 어떻게 적용되고 있는지에 초점을 맞춘다.

💡 메인프레임 전환의 진짜 리스크는 '한 번에 다 바꾸는' 빅뱅 컷오버 자체다. AI 기반 코드 분석과 병행 검증으로 단계적·롤백 가능한 경로를 확보하면 업무 중단 없이 유지보수 비용과 전환 리스크를 동시에 낮출 수 있다는 점이 실무적으로 중요하다.

Cortex Framework v7 is GA: Build agentic workflows without disrupting SAP operations

Google Cloud

구글 클라우드가 SAP 연동 프레임워크인 Cortex Framework 버전 7의 정식 출시(GA)를 알렸다. 이 프레임워크는 SAP ECC·SAP S/4HANA 같은 SAP ERP 데이터를 BigQuery 기반 분석 및 에이전트형 AI 워크로드에 쓸 수 있도록 데이터 모델과 파이프라인을 구축해 주는 솔루션으로, 매출 확대·리스크 완화·자본 최적화를 노리는 AI 에이전트를 기간계 ERP 운영을 건드리지 않고도 빠르고 안전하게 배포해야 한다는 문제의식을 담고 있다. v7은 오케스트레이션을 전적으로 Dataform에 맡겨 상시 가동되는 컴퓨트 클러스터나 Airflow 없이 버전관리되는 SQL만으로 서버리스 데이터 변환을 수행하고, 필요한 데이터 프로덕트만 선택하면 의존성을 자동으로 해석해 배포하는 모듈형 구조로 바뀌었다. 증분 로딩을 지원해 이미 처리한 데이터는 다시 돌리지 않아 BigQuery 처리 시간과 비용을 줄이고, SAP 특유의 통화 자릿수 처리 같은 로직까지 반영한 비즈니스 친화적 시맨틱 매핑과 필드 단위 AI 대응 메타데이터를 제공해 Gemini 같은 에이전트가 원시 테이블이 아니라 의미가 부여된 데이터 위에서 추론하도록 한다. 하나의 배포에서 SAP ECC와 S/4HANA 데이터를 동시에 통합하는 멀티 시스템 지원도 새로 강화됐다. v7은 메이저 버전업이라 v6에서 자동 마이그레이션 경로는 없지만, 기존 Looker 대시보드나 LookML 모델이 깨지지 않도록 v6 호환 콘텐츠를 별도로 제공해 SAP 리포팅을 유지하면서 전환할 수 있게 했다.

💡 SAP 데이터를 다루는 에이전트 워크로드에서 가장 위험한 실패는 원시 ERP 테이블의 의미를 잘못 해석해 그릇된 판단을 내리는 것인데, 필드 단위 시맨틱 메타데이터와 Dataform 기반 서버리스 오케스트레이션은 이 리스크를 줄이면서 Airflow 같은 운영 인프라도 함께 걷어낸다는 점에서 실무적이다. 다만 v6에서 v7로의 전환이 브레이킹 체인지인 만큼, 호환성 검증 없이 넘어가면 기존 리포팅이 깨질 수 있다는 점은 주의해야 한다.

Unifying public and private data: Scale knowledge graphs with Data Commons on Spanner

Google Cloud

구글 클라우드가 공개 데이터셋 프로젝트인 Data Commons를 Spanner Graph 위에서 함께 쓸 수 있도록 통합하는 내용을 다루는 글을 게시했다. Data Commons는 인구조사국·UN·보건 당국·환경 기관 등이 공개한 통계·참조 데이터를 하나의 스키마로 정리해온 구글의 오픈소스 프로젝트로, 지금까지는 이 공개 데이터를 기업의 내부 데이터와 엮어 지식 그래프를 만들려면 별도의 ETL 파이프라인을 짜서 두 세계를 이어붙여야 했다. Spanner Graph는 기존 Spanner 관계형 테이블 위에 데이터를 복제하지 않고 그래프 스키마를 매핑할 수 있고, ISO 표준 그래프 질의어인 GQL을 SQL과 섞어 한 쿼리에서 관계형·그래프 데이터를 함께 탐색할 수 있는 게 특징이다. 이 글은 이런 Spanner Graph의 통합 질의 능력을 활용해 Data Commons가 제공하는 공개 개체(지역·인구·경제 지표 등)와 기업의 사설 데이터를 하나의 그래프 안에서 직접 연결하는 방법을 제시한다. 이렇게 하면 실세계 사물과 그 관계를 표현하는 지식 그래프를 구축할 때, 공개 데이터를 별도로 내려받아 정제·적재하는 과정 없이 곧바로 조인해 활용할 수 있다. 벡터 검색·전문 검색·생성형 AI 연동까지 같은 데이터베이스 안에서 지원되는 만큼, 이렇게 만들어진 지식 그래프는 곧바로 에이전트나 검색 기반 애플리케이션의 근거 데이터로도 쓸 수 있다.

💡 지식 그래프를 만들 때 병목은 대개 그래프 엔진 자체가 아니라 공개 참조 데이터를 내부 데이터와 맞춰 적재하는 ETL이었는데, Data Commons를 Spanner Graph에서 직접 조인 가능하게 만들면 이 파이프라인 구축·유지 비용을 통째로 없앨 수 있다. 다만 공개 데이터가 운영 데이터베이스에 곧바로 연결되는 구조인 만큼, 스키마 변경이나 데이터 신선도 관리 책임을 어느 쪽이 지는지는 별도로 확인해야 한다.

Your agent needs a computer, not a container — introducing @cloudflare/computer

Cloudflare

Cloudflare가 에이전트 실행 전용 런타임 패키지 @cloudflare/computer를 공개했다. 에이전트마다 컨테이너를 통째로 띄우는 대신, 가볍고 빠른 Workers의 isolate와 완전한 리눅스 컨테이너 사이를 작업 성격에 따라 동적으로 오가며 알맞은 실행 환경을 골라주는 것이 핵심이다. Cloudflare는 올해 초만 해도 에이전트 하나당 컨테이너 하나를 띄우는 방식이 일반적이었지만, 최근 몇 달 사이 에이전트 하네스들이 도구 기반 샌드박스 코드 실행으로 옮겨가면서 '작업을 실행하는 손(샌드박스)'과 '판단하는 두뇌(에이전트 루프)'가 분리되는 흐름이 있었다고 설명했다. @cloudflare/computer는 SQLite 기반 가상 파일시스템을 클라우드 스토리지나 소스 컨트롤 등에서 미리 채워 넣고, isolate와 컨테이너가 서로 동기화된 동일한 파일에 접근하도록 만든다. 파일 조작·데이터 처리·git 작업처럼 가벼운 일은 isolate가, 리눅스 환경이나 npm, 네이티브 바이너리가 필요한 작업만 컨테이너가 맡도록 나눠, 전체 작업 중 컨테이너가 필요한 비중을 10% 미만으로 줄이는 것이 목표라고 밝혔다. 사용법은 Durable Object 위에 워크스페이스 인스턴스를 하나 붙이고 npm install @cloudflare/computer로 설치하는 정도로 단순하다. Cloudflare는 사내에서 이미 이 방식으로 JS 애플리케이션 빌드·테스트·배포, 고객용 문서 생성, 브라우저 자동화 작업 대부분을 isolate만으로 처리하고 있다고 소개했다.

💡 컨테이너 콜드스타트와 상시 유지 비용이 에이전트 워크로드의 큰 비용 요인이었던 만큼, 작업별로 isolate/컨테이너를 자동 선택해 컨테이너 비중을 10% 미만으로 낮춘다는 설계는 에이전트 인프라 비용과 지연시간을 동시에 줄일 실질적인 방법이 될 수 있다.

Cloudflare Workers and Containers now support inbound TCP connections and gRPC

Cloudflare

Cloudflare가 Workers와 Containers에서 인바운드 TCP 연결과 gRPC를 지원한다고 발표했다. 핵심은 Cloudflare의 비HTTP(TCP/UDP) 트래픽용 인그레스 프록시인 Spectrum을 통해 들어오는 TCP 연결을 Durable Objects나 Containers로 직접 소켓 포워딩할 수 있게 됐다는 점이다. 이를 통해 개발자는 완전한 양방향(full-duplex) gRPC 애플리케이션을 Workers와 Containers 위에서 그대로 구동할 수 있다. Workers가 gRPC와 gRPC-Web 간 변환을 자동으로 처리해 주기 때문에, 브라우저가 보낸 gRPC-Web 요청을 별도 프록시 없이 백엔드 gRPC 서비스로 그대로 중계하는 것도 가능하다. 블로그는 이 기능을 '클라우드플레어 컨테이너에서의 양방향 gRPC' 섹션으로 소개하며, Durable Object 안에서 소켓 바이트를 그대로 에코하는 예제 코드로 동작 방식을 보여준다. gRPC는 HTTP/2 기반의 널리 쓰이는 원격 프로시저 호출(RPC) 프레임워크인데, 브라우저에서는 표준 gRPC 통신이 제한적이라 그동안 Envoy 같은 별도 프록시로 gRPC-Web 변환을 처리하는 경우가 많았다. 이번 발표로 기존 gRPC 마이크로서비스나 TCP 기반 백엔드를 별도 게이트웨이 계층 없이 Cloudflare 엣지로 옮겨올 수 있는 경로가 열렸다.

💡 TCP/gRPC 백엔드를 서비스하려면 보통 Envoy 같은 별도 프록시 계층과 전용 인프라를 운영해야 했는데, 이제 이를 Workers·Durable Objects·Containers 안에서 엣지 단에 통합할 수 있어 게이트웨이 홉과 그 운영 부담을 줄일 수 있다.

Introducing the Billable Usage API: programmatic cost visibility for Cloudflare

Cloudflare

Cloudflare가 계정 단위 비용과 사용량을 프로그래밍 방식으로 조회할 수 있는 신규 Billable Usage API를 공개했다. 개발자와 FinOps 팀은 여러 대시보드를 오가는 대신 단일 엔드포인트 호출 한 번으로 Workers, R2, D1, Workers AI, Vectorize, Images, Stream 등 사용량 기반 과금 상품 전체의 비용 데이터를 가져올 수 있다. 이 API는 FinOps 진영에서 널리 쓰이는 비용·사용량 표준 스키마인 FOCUS 규격을 기반으로 설계돼, 이미 FinOps 툴체인을 쓰고 있다면 컬럼명이 낯설지 않다. 실제로 공식 문서에는 Cloudflare의 청구 필드(BillingCurrency 등)를 FOCUS 컬럼에 대응시키는 매핑 표까지 함께 제공된다. 그동안 재무팀은 지출 데이터를 사내 시스템으로 가져와 프로젝트·팀·고객별로 비용을 배분하고 싶어도 화면 캡처나 수동 내보내기에 의존해야 했는데, 이번 API는 스크립트에 바로 넣을 수 있는 curl 호출 하나로 이를 대체한다. 출력이 FOCUS 스키마를 따르는 만큼, 다른 클라우드 사업자의 FOCUS 호환 청구 데이터와 나란히 놓고 통합 비용 분석을 하는 것도 가능해진다. 결국 이번 발표는 화면으로 눈으로 확인하던 비용을 파이프라인으로 흘려보낼 수 있는 데이터로 바꿔놓았다는 데 의미가 있다.

💡 클러스터·서비스 단위로 원가를 추적하는 FinOps 파이프라인에 Cloudflare 지출을 코드 몇 줄로 붙일 수 있게 됐다는 점이 실무적으로 크다 — 그동안 CSV 내보내기나 대시보드 캡처로 때우던 멀티클라우드 비용 통합을 API 호출 하나로 자동화할 수 있다.

Dynamic troubleshooting with guarded command execution in the MCP server for Red Hat Enterprise Linux

Red Hat

Red Hat이 2026년 7월 28일, RHEL용 MCP 서버(MCP server for RHEL)에 가디드 커맨드 실행(guarded command execution) 기능을 개발자 프리뷰로 추가했다고 블로그에 발표했다. 기존 MCP 서버는 사전 정의된 읽기 전용(read-only) 도구 집합만 제공해 안전하지만, 서비스 재시작이나 설정 파일 수정처럼 실제 근본 원인 분석에 필요한 동적 작업은 수행할 수 없다는 한계가 있었다. 새 기능은 LLM이 고정된 툴셋에 얽매이지 않고 명령어와 스크립트를 그때그때 생성·실행하도록 하되, 인터넷 콘텐츠 다운로드 차단, 사전 설정된 저장소로의 접근 제한, 그리고 명령을 실행 전에 검증하는 게이트키퍼(gatekeeper) 모델 등 여러 안전장치를 두었다. 블로그는 /app1 디렉터리에 파일을 만들 수 없는 실제 시나리오로 이를 시연한다. LLM이 읽기 전용 도구로 디스크 여유 공간(9.7GB)이 충분함을 먼저 확인한 뒤, 가디드 커맨드 실행으로 df -i 명령을 실행해 아이노드(inode) 고갈이 원인임을 찾아내고, 문제 디렉터리를 스크립트로 좁혀낸 뒤 xfs_growfs로 imaxpct 값을 30%에서 35%로 늘리는 조치를 제안한다. 이때는 시스템을 변경하는 명령이라 읽기 전용 플래그가 자동으로 꺼지므로, 사람이 Allow 버튼을 눌러 명시적으로 승인해야 실행되며, 이후 다시 확인 명령으로 조치가 실제로 적용됐는지 검증한다.

💡 게이트키퍼 모델 검증과 사람의 명시적 승인을 변경 커맨드에만 강제하는 설계는, 온콜 엔지니어가 흔히 겪는 읽기 전용 진단은 자동화하되 실제 변경은 통제하고 싶다는 딜레마를 MCP 서버 레벨의 표준 패턴으로 풀어낸 사례다. RHEL 운영 환경에 LLM을 붙이려는 조직이라면 이 가디드 실행·승인 흐름이 사내 변경관리 정책과 어떻게 맞물릴지 먼저 검토할 만하다.

DevOps & 인프라

Apple and Bynario agree GPT-5.5 found a real macOS bug. They disagree on the report cap.

The New Stack

애플이 보안 연구자들의 버그바운티 제출 창구인 피드백 어시스턴트에 동시 접수 가능한 리포트 수를 제한하고, 한도에 도달하면 30일간의 '냉각기'를 두는 정책을 도입했다. AI가 생성한 저품질 취약점 보고서, 이른바 'AI 슬랍(slop)'이 크게 늘어나 실제 취약점을 심사하는 검토 파이프라인이 마비될 지경이었기 때문이다. 그런데 이 정책은 역설적인 결과로 이어졌다 — 이탈리아 보안업체 바이나리오(Bynario)가 오픈AI GPT-5.5 기반 AI 플랫폼으로 macOS 화면 공유(Screen Sharing) 기능의 실제 취약점을 찾아냈는데, 이는 인증된 VNC 뷰어가 보호된 데이터에 접근하고 루트 권한으로 파일을 생성할 수 있는 심각한 결함이었다. 문제는 바이나리오가 3주 동안 50건 넘는 취약점을 접수한 탓에 이미 애플의 제출 한도에 걸려 있었고, 그래서 이 실제 취약점을 제때 신고할 수 없었다는 것이다. 바이나리오의 CEO 알프레도 페솔리는 이 미신고 결함의 암시장 가치를 10만~20만 달러로 추정했다고 밝혔다. 보도 이후 애플은 바이나리오에 연락을 취했으며, 양측 모두 GPT-5.5가 실제 macOS 버그를 찾아냈다는 점에는 동의하지만 제출 상한 정책 자체의 타당성을 두고는 입장이 갈린다.

💡 AI 리포트 홍수에 대응한 '제출 상한'이 노이즈만 걸러내리라는 보장은 없다 — 이번 사례처럼 진짜 취약점을 낸 리서처가 한도에 막혀 신고를 못 하면 벤더 입장에서도 치명적인 취약점을 더 늦게 아는 셈이다. 물량 기반 레이트리밋보다 신뢰도·과거 적중률로 우선순위를 매기는 심사 체계가 필요하다는 신호로 읽힌다.

Alibaba’s AI coded for 16 days straight and every commit is on GitHub

The New Stack

알리바바가 멀티모달 플래그십 모델 Qwen3.8-Max를 공개했다. 2.4조 파라미터 규모의 스파스 MoE(Mixture-of-Experts) 아키텍처에 하이브리드 어텐션을 결합했지만, 실제 추론 시 활성화되는 파라미터는 950억 개 수준이다. 알리바바는 이 모델이 장시간 자율 작업에 강하다는 것을 보여주기 위해, 사람 개입 없이 16일 동안 연속으로 소프트웨어 엔지니어링 프로젝트를 수행하게 하는 테스트를 진행했다. 과제는 자가 진화형 에이전트 프레임워크를 처음부터 만드는 것이었고, 모델은 사용자 요청을 깃허브 이슈로 변환해 스스로에게 할당한 뒤 코드를 작성하고 테스트를 돌리고 결과를 반복 개선하는 루프를 스스로 구축했다. 그 결과물이 'oh-my-cli'라는 CLI 도구이며, 깃허브에 전체 소스와 커밋 이력이 공개되어 있다. 2026년 7월 30일 기준으로 265건의 커밋, 127건의 풀 리퀘스트, 151건의 이슈가 사람의 손을 거치지 않고 쌓였고, 누구나 저장소를 열어 커밋 하나하나와 코드 품질을 직접 검증할 수 있다는 점이 이번 발표의 특징이다.

💡 AI가 이슈 생성부터 PR 머지까지 16일을 스스로 굴렸다는 것 자체보다, 그 과정 전체가 커밋 단위로 공개돼 있어 제3자가 실제로 검증할 수 있다는 점이 실무적으로 더 중요하다 — 자율 코딩 에이전트를 파이프라인에 들일지 판단하려면 벤치마크 점수보다 이런 감사 가능한(auditable) 로그가 훨씬 설득력 있는 근거다. 다만 265커밋·127PR이 실제 프로덕션 수준의 코드 품질과 유지보수성을 갖췄는지는 별개 문제이므로, 리뷰 없이 이런 결과를 그대로 신뢰하는 것은 위험하다.

GEM Training: How Meta Doubled the Efficiency of Its LLM-Scale Ads Foundation Model

Meta Engineering

메타가 인스타그램과 페이스북 광고 추천에 쓰이는 파운데이션 모델 GEM(Generative Ads Recommendation Model)을 이제 수천 개의 최신 세대 GPU로 LLM급 규모로 학습시키고 있다고 밝혔다. 메타는 지난 12개월 동안 커널·정밀도·병렬화·네트워킹·메모리를 함께 공동 설계(co-design)해, GEM의 전체 학습 FLOPs를 4배로 늘리면서도 종단 간(E2E) 학습 효율을 MFU(모델 FLOPs 활용률) 기준 2025%로 두 배 끌어올렸다고 설명한다. 추천 모델은 LLM과 달리 사용자별 시퀀스 길이가 제각각인 '자그드(jagged)' 데이터와 조 단위 희소 임베딩·수십억 개의 밀집 파라미터를 동시에 다루기 때문에, LLM에 최적화된 기존 GPU 소프트웨어 스택으로는 GPU 활용률을 높이기가 특히 어렵다는 문제가 있었다. 이를 풀기 위해 메타는 Jagged Flash Attention(JFA), Generalized Dot-Product Attention(GDPA), BlockAttention 등 추천 시스템 특화 커널 라이브러리를 자체 구축했는데, 그중 JFA의 최신 버전(v4)은 2세대 전인 v2 대비 40140% TFLOPS 개선과 함께 로컬 MFU 18.5%, QPS 12% 향상을 이끌어냈다. 여기에 더해 FP8·FP4 같은 초저정밀도 학습을 지원하기 위해 수치 안정성을 고려한 MXFP8 어텐션·MLP 커널을 새로 설계해 순전파는 1.3배 이상, 역전파는 1.5배 이상 속도를 높였다. 마지막으로 조밀 파라미터는 전문가 병렬화를 곁들인 2D FSDP로, 희소 파라미터는 완전 샤딩된 2D 모델 병렬화로 나누는 5차원 병렬화를 메타의 다단계 네트워크 토폴로지(호스트 내 NVLink, 존 내 RoCE, 존 간 오버서브스크라이브 RoCE)에 맞춰 최적화해 통신 병목을 줄였다.

💡 수천 대 GPU 클러스터에서 MFU를 20%대까지만 끌어올려도 동일 하드웨어로 처리할 수 있는 학습량이 두 배가 된다는 뜻이라, 대규모 GPU 예산을 쓰는 조직이라면 커널·정밀도·병렬화 전략에 대한 투자가 곧 직접적인 비용 절감으로 이어진다는 것을 보여주는 사례다. 다만 LLM용으로 튜닝된 어텐션 커널이나 병렬화 레시피를 그대로 추천·랭킹 같은 자그드 워크로드에 적용하면 활용률이 크게 떨어질 수 있다는 반례이기도 하다.

DeepSeek’s smaller model just outperformed its own flagship

The New Stack

DeepSeek가 소형 모델 라인업인 V4-Flash를 아키텍처 변경 없이 추가 후속 학습(post-training)만으로 개선한 DeepSeek-V4-Flash-0731을 공개했다. 파라미터 구성은 총 2840억 개 중 추론 시 활성화되는 파라미터가 130억 개인 MoE 구조로 이전 버전과 동일하며, 100만 토큰 컨텍스트 윈도우도 그대로 유지했다. Artificial Analysis Intelligence Index 점수는 기존 40점에서 50점으로 10점 올라, 자사 플래그십 모델인 DeepSeek V4 Pro보다 6점 높은 결과를 기록했다. 특히 실무형 에이전트 작업을 측정하는 GDPval-AA v2 Elo 점수가 1189에서 1559로 크게 뛰었고, Terminal-Bench 2.1은 17점 상승한 79%, τ³-Bench Banking은 8점 상승한 31%를 기록해 에이전트·코딩 성능 개선이 두드러졌다. 벤치마크 수행에 소모된 출력 토큰량도 이전 대비 12% 줄어 응답이 더 간결하고 저렴해졌다. 가격은 100만 토큰당 입력 0.14달러·출력 0.28달러로 이전과 동일하지만 캐시 히트 시 약 98% 할인이 적용돼, 비슷한 지능 수준의 GPT-5.6 Luna 대비 작업당 비용이 약 60% 낮다는 분석이 나왔다. 이 모델은 오픈 웨이트로 공개됐다.

💡 아키텍처 변경 없이 후속 학습만으로 자사 플래그십을 넘어선 사례라, 에이전트 파이프라인에 쓸 모델을 고를 때 무조건 더 큰 모델이 필요한 건 아니라는 걸 보여준다. 토큰 사용량 감소와 캐시 할인까지 겹쳐 작업당 추론 비용이 눈에 띄게 낮아진 만큼, 비용 최적화 관점에서 모델 교체를 검토할 근거가 된다.

Spend More Time Talking to Humans

Honeycomb

옵저버빌리티 기업 Honeycomb가 'Spend More Time Talking to Humans'라는 블로그 글에서, LLM이 소프트웨어 엔지니어링의 일하는 방식 자체를 바꿔놓았다고 진단한다. 글의 핵심은 시니어 엔지니어와 주니어 엔지니어가 서로 다른 이유로 지쳐가고 있다는 것이다. 시니어는 여러 AI 작업 사이를 오가는 컨텍스트 스위칭에 지치고, 주니어는 예전 방식대로 커리어를 어떻게 키워야 할지 갈피를 잡지 못한다. 과거에는 빠르고 정확하게 구현하는 능력이 주니어 엔지니어가 커리어를 쌓는 핵심 경로였는데, AI가 구현 자체를 빠르게 대신해주면서 그 경로가 흔들리고 있다는 것이 글의 지적이다. 이런 피로와 스트레스의 근본 원인은 LLM 기반 코딩이 소프트웨어 개발의 핵심 작업 방식을 바꿔놓았기 때문이라고 설명한다. 결론에서는 AI 코딩이 구현 속도를 계속 끌어올리는 지금이야말로 그것이 팀을 둘러싼 사람과 인간 시스템에 미치는 영향을 이해하는 게 중요하며, 그 영향이 좋을지 나쁠지는 팀이 일하는 방식을 의도적으로 바꾸고 팀원들이 실제로 필요로 하는 것에 집중하는지에 달려 있다고 강조한다. 제목 그대로, 그 해법의 방향은 코드를 더 많이 짜는 게 아니라 사람과 더 많이 대화하는 데 있다.

💡 AI 코딩 도구가 확산될수록 병목은 코드 리뷰나 PR 처리량이 아니라 팀 내 커뮤니케이션·멘토링 구조로 옮겨간다는 신호로, 온보딩·페어링·1:1 체계를 다시 설계하지 않으면 주니어 성장 경로 붕괴와 시니어 번아웃이 동시에 심해질 수 있다.

DS와 MLE가 함께 일하는 법

토스

토스 기술 블로그에 실린 DS와 MLE가 함께 일하는 법은 데이터사이언티스트(DS)와 머신러닝 엔지니어(MLE)가 노트북과 서빙 사이의 간극을 좁혀온 과정을 세 단계로 정리한 글이다. 문제의 뿌리는 DS가 모델링 과정에서 짠 코드와 MLE가 비즈니스 로직과 함께 서빙용으로 재작성한 코드 사이에 명확한 약속이 없었다는 점으로, 노트북에서 잘 돌던 코드를 다른 사람 손에서 그대로 재현하는 전달받아 맞추기에 많은 시간이 들었다고 한다. 1단계(Phase 1)에서는 실제 ML 로직을 .py 파일로 분리해 MLE 리뷰와 CI를 반드시 거치게 했지만, 한 모델의 노트북 코드가 공용 추론 라이브러리의 전역 설정을 바꿔버려 같은 프로세스에서 도는 다른 서빙 모델에 영향을 준 사례, 그리고 모델마다 predict()·run()·inference() 등 실행 함수 이름이 제각각이라 서빙으로 옮길 때마다 다시 고쳐야 했던 문제가 반복됐다. 2단계(Phase 2)에서는 작업 분담 기준을 인터페이스(약속)로 바꿔, commons-ml-model이라는 패키지의 추상화 클래스(전처리·추론·후처리 메서드)를 DS가 구현해 패키지로 만들고 MLE는 이를 pip install로 설치해 서비스에 올리는 방식으로 전환했으며, 로그·메트릭·트레이싱은 추상화 클래스가 자동으로 처리해 DS와 MLE 모두 서로의 영역을 신경 쓸 필요가 없어졌다. 실제로 어떤 서비스는 첫 커밋 당일에 배포까지 마쳤다고 소개된다. 최근에는 AI가 코드를 작성하는 시대가 되면서 인터페이스만으로는 부족하고 코드 스타일(컨벤션)까지 맞추는 협업이 새로운 과제로 떠올랐다며, 구조를 너무 엄격히 하면 DS의 커스터마이징이 어려워지고 너무 느슨하면 인터페이스가 다시 제각각이 되는 균형을 찾는 것이 관건이라고 정리한다. 글은 토스뱅크 팀이 작성한 것으로, 1년 전 노트북을 통째로 전달하고 MLE가 전면 재작성하던 방식에서 지금의 인터페이스 구현과 패키지 설치 방식으로 협업이 진화하며 DS와 MLE의 역할이 더 섞이는 동시에 책임은 더 뚜렷해졌다고 맺는다.

💡 DS·MLE 협업의 병목은 결국 노트북 코드와 서빙 코드 사이의 암묵적 계약이었고, 이를 추상 클래스 기반 인터페이스와 사내 공용 패키지(commons-ml-model)로 명문화해 배포 리드타임을 며칠에서 당일로 줄인 사례다. MLOps 파이프라인을 설계할 때 역할을 코드 계약으로 강제하는 이 패턴은 조직 규모가 커질수록 참고할 만하다.

Secure every commit to production with Claude and GitLab

GitLab

GitLab이 2026년 8월 3일 블로그를 통해, Anthropic의 Claude 시큐리티 가이던스 플러그인·Claude Security와 GitLab의 정책·파이프라인 기능을 연결해 에이전틱 코딩을 프로덕션까지 거버넌스하는 방법을 제시했다. 글은 에이전틱 코딩의 속도가 많은 기업 거버넌스 프로그램을 앞지르고 있다는 문제의식에서 출발하는데, Claude의 두 도구는 코드가 작성되는 세션 안에서 취약점을 바로 찾아 고쳐주지만 이는 커밋에 이르는 여러 단계 중 한 지점일 뿐이라는 점을 짚는다. 이에 대해 GitLab은 머지 리퀘스트(MR) 승인 정책으로 코드를 작성한 에이전트나 이를 지시한 개발자가 자신의 변경을 스스로 승인하지 못하게 막고, 해결되지 않은 심각한(critical) 취약점이 있으면 지정된 승인자가 서명하기 전까지 머지를 보류하도록 강제한다. 또한 Vulnerability report와 Security dashboard로 모든 발견 항목의 상태(탐지, 사유가 있는 기각, 해결)를 영구적으로 추적하고, 컴플라이언스 컨트롤로 모든 MR에 스캔이 실행되도록 보장해 사람이 볼 수 있게 만든다. 글은 Claude의 두 플러그인이 사람의 코드 리뷰와 여러 보안 스캐너를 대체하는 것이 아니라 보조하는 최선형(best-effort) 도구일 뿐이라는 점, 그리고 2021년 12월 Log4Shell처럼 배포 당시엔 안전했던 의존성이 나중에 취약점이 공개돼 문제가 되는 경우도 있다는 점을 강조하며, GitLab의 파이프라인 단위 스캔·정책이 사람이 짰든 에이전트가 짰든 코드 출처와 무관하게 적용되는 안전망 역할을 한다고 설명한다. 참고로 Claude Security는 2026년 7월 21일 퍼블릭 베타로 출시된 Claude Code용 멀티에이전트 취약점 스캐너로, 여러 Claude 에이전트가 아키텍처를 매핑하고 위협 모델을 세운 뒤 취약점을 찾고 서로 교차 검증하는 방식으로 동작한다.

💡 핵심은 에이전트가 짠 코드를 에이전트 스스로 승인하지 못하게 만드는 MR 승인 정책과, AI 도구 사용 여부와 무관하게 모든 머지에 스캔을 강제하는 파이프라인 게이트다. 이는 어시스턴트가 세션에서 이미 취약점을 잡아줬으니 안전하다는 안이한 가정을 막고, Log4Shell류의 사후 발견 취약점까지 감사 추적을 남기는 구조적 장치로 봐야 한다.

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