Claude Code
GitHub Copilot
AWS
DatadogClaude Code 2.1.248이 제한 실행 모드를 추가했다
Claude Code 2.1.248은 --restricted 실행 프로필을 추가했다. 이 모드는 명령이나 코드를 실행하는 내장 도구와 WebFetch를 기본 목록에서 제거하고, 파일 도구가 작업 디렉터리 밖을 다루지 못하게 한다. bypassPermissions도 거부하며 사용자, 프로젝트와 로컬 설정 파일을 무시한다. 필요한 도구만 --tools로 다시 허용할 수 있어 에이전트의 기본 권한을 넓게 준 뒤 차단하는 방식보다 작은 허용 범위에서 시작할 수 있다.
CI 점검이나 외부 기여 코드 분석처럼 입력을 신뢰하기 어려운 작업에서는 특히 의미가 크다. 다만 제한 모드가 컨테이너나 별도 자격 증명 경계를 대신하지는 않는다. 파일 쓰기가 허용된 범위, 상위 프로세스가 가진 환경 변수와 명시적으로 되살린 도구를 함께 점검해야 한다.
같은 버전은 원격 설정을 불러오지 못한 이유를 시작 경고와 /doctor, /status에 표시하고, 훅이 잘못된 JSON을 반환할 때 파싱 오류를 드러내도록 바꿨다. 제한 자체뿐 아니라 정책이 실제로 적용됐는지 진단하는 경로가 함께 보강된 릴리스다.
Copilot 코드 리뷰가 봇 작성 PR과 대형 변경까지 범위를 넓혔다
GitHub Copilot 코드 리뷰는 자동으로 리뷰가 요청된 봇 작성 PR을 지원한다. Copilot cloud agent가 연 PR도 기존의 제한된 검토 대신 완전한 에이전트 리뷰를 받을 수 있다. 조직이 라이선스가 없는 구성원의 Copilot 코드 리뷰 사용 정책을 켜면 봇 PR의 리뷰 비용은 조직에 귀속된다.
기존의 300개 파일 또는 2만 줄 제한도 없어졌다. 대형 PR을 기술적으로 검토할 수 있다는 뜻이지 한 번에 큰 변경을 만드는 비용이 사라졌다는 뜻은 아니다. 리뷰 문맥이 넓어질수록 생성자와 검토자의 모델이 같은 전제를 공유할 수 있으므로, 테스트와 정적 분석 및 사람이 확인할 위험 구간을 별도로 유지해야 한다.
리뷰 의견을 해결할 때는 Addressed, Won't fix, Incorrect 중 사유를 남길 수 있다. 에이전트가 만든 변경을 다시 에이전트가 검토하는 흐름에서는 이 기록이 중요하다. 단순 해결 건수보다 어떤 의견이 틀렸고 무엇을 의도적으로 수용하지 않았는지 분리해야 리뷰 품질을 평가할 수 있기 때문이다.
GitHub Top 100의 급상승 상위권이 에이전트 실행 도구에 집중됐다
전날과 비교한 하루 star 증가 상위 다섯 개는 DeepSeek Harness 2,608, Ponytail 1,555, Skills 1,205, Public APIs 617, Codex 592였다. 이 가운데 네 개가 에이전트 실행 구조, 기술 패키지 또는 코딩 에이전트와 직접 연결된다. 여러 저장소가 같은 날 함께 오른 점은 개발자 관심이 모델 자체보다 에이전트의 실행 방식과 재사용 가능한 작업 절차로 이동하는 흐름을 보여 준다.
다만 star 증가는 관심의 크기만 나타낸다. 실제 도입 판단에는 유지보수 활동, 릴리스 안정성, 보안 경계와 조직 환경의 재현 가능성을 별도로 확인해야 한다.
Amazon Redshift가 Agent Toolkit for AWS와 결합했다
Amazon Redshift는 Agent Toolkit for AWS와 결합해 Claude Code, Kiro와 Cursor 같은 AI 에이전트에서 데이터 웨어하우스 작업을 수행할 수 있게 했다. AWS MCP 서버가 사용자 대신 인증된 AWS API를 실행하고, Redshift 기술 패키지가 SQL 문법, 메타데이터 탐색, 데이터 적재, 구체화 뷰와 데이터 형식에 관한 검증된 절차를 제공한다.
마이그레이션도 발견, 스키마와 SQL 변환, 데이터 이동, 검증과 성능 비교까지 한 흐름으로 안내한다. 에이전트가 런타임에 기술 패키지를 찾아 불러올 수도 있어 자연어 요청이 실제 데이터 작업으로 이어지는 거리가 짧아졌다.
운영에서는 편의보다 권한과 검증 경계를 먼저 정해야 한다. 탐색용 읽기 역할과 변경 역할을 분리하고, 생성 SQL은 실행 전에 계획과 대상 스키마를 확인하며, 데이터 이동과 DDL에는 승인을 요구하는 편이 안전하다. MCP 연결이 인증을 제공해도 에이전트가 수행할 수 있는 작업의 범위까지 자동으로 적정해지는 것은 아니다.
AWS Elastic Disaster Recovery가 복구 순서와 승인을 계획으로 관리한다
AWS Elastic Disaster Recovery는 여러 서버로 구성된 애플리케이션의 복구 순서를 계획으로 정의할 수 있게 했다. 서버를 단계별로 묶고 단계 사이 대기 시간과 사람의 승인 지점을 설정하며, 실제 서비스에 영향을 주지 않는 훈련 모드로 절차를 검증한다.
복구 자동화의 가치는 버튼 하나보다 반복 가능성에 있다. 데이터베이스, 애플리케이션과 지원 서비스의 기동 의존성을 코드 밖의 운영 계획으로 명시하고, 정기 훈련 결과와 승인 지연 시간을 함께 측정해야 실제 복구 시간 목표를 판단할 수 있다.
Datadog Live Debugger가 재배포 없이 운영 코드의 실행 근거를 수집한다
Datadog은 실행 중인 서비스에 코드를 바꾸거나 재배포하지 않고 진단 지점을 붙이는 Live Debugger 프리뷰를 공개했다. 비파괴 로그 지점에서 변수 값, 메서드 인자와 실행 문맥을 수집하고, 서드파티 라이브러리 안의 코드도 조사할 수 있다. 로컬이나 스테이징에서 재현되지 않는 오류를 위해 임시 로그를 넣고 배포하는 반복을 줄이는 접근이다.
Bits AI는 연결된 소스 코드와 운영 중 수집한 증거를 함께 분석해 로그 지점을 배치하고 결과를 해석한 뒤 수정안을 제안한다. 코딩 에이전트가 추측이나 정적 코드만으로 수정하는 대신 실제 실패 조건을 근거로 삼을 수 있다는 점이 핵심이다.
그만큼 운영 데이터 노출 범위도 커진다. Remote Configuration과 소스 연동 권한, 캡처할 수 있는 변수, 보존 기간과 접근 기록을 함께 설계해야 한다. 운영 증거를 에이전트에 연결할수록 어떤 값이 수집됐고 누가 수정안을 실행했는지 추적 가능해야 한다.
Datadog이 AI 에이전트 보안 관측 단위를 전체 실행 경로로 제시했다
Datadog은 AI 에이전트의 최종 API 호출만 기록해서는 행동의 원인을 조사하기 어렵다고 설명했다. 모델과 지침, 검색된 문서, 도구 결과, 사람 및 에이전트 신원과 후속 호출을 하나의 실행 경로로 연결해야 민감 정보가 어디에서 들어와 어떤 행동에 영향을 줬는지 추적할 수 있다.
모든 에이전트에 같은 통제를 적용하는 방식도 충분하지 않다. 외부 입력을 받고 변경 도구를 호출하는 에이전트와 저장된 결과를 평가하기만 하는 에이전트는 노출 수준이 다르다. 관측 데이터는 에이전트 이름보다 입력의 신뢰도, 접근 가능한 데이터와 도구 호출의 영향도를 기준으로 분류해야 한다.