Anthropic Claude
GitHub Copilot
AWSClaude Fable 5.1이 긴 에이전트 작업의 API와 캐시 비용 기준을 바꾼다
Anthropic은 Claude Fable 5.1을 Claude API와 AWS, Google Cloud 및 Microsoft Foundry에 공개했다. 기본 context window는 100만 token, 최대 출력은 12만 8천 token이며 adaptive thinking이 항상 켜진다. 입력과 출력 가격은 100만 token당 10달러와 50달러로 Fable 5와 같지만 prompt cache 읽기는 기본 입력 가격의 0.025배인 0.25달러로 낮아졌다. 긴 agent session에서 동일한 system prompt와 tool 정의를 반복하는 비용 구조가 달라지는 변화다.
모델 이름만 바꾸면 끝나는 업그레이드는 아니다. tool_choice의 any와 tool은 지원하지 않아 400 오류를 반환하며, 특정 tool 호출을 강제해야 한다면 strict tool use 또는 structured output으로 바꿔야 한다. thinking block은 생성한 모델이나 그보다 새로운 모델에서만 재사용할 수 있고, 이전 모델로 되돌리면 API가 해당 block을 제거한다. 신규 account에서는 system prompt, tool 또는 앞선 message가 달라진 뒤 thinking block을 replay하는 요청도 400 오류가 될 수 있다.
Java 또는 Kotlin 서비스에서 model routing과 fallback을 운영한다면 model ID 교체보다 conversation replay 테스트가 먼저다. tool 강제 선택, cached prompt 재사용, thinking block이 포함된 retry와 이전 모델 fallback을 각각 검증하고 400 응답을 일반 장애 재시도로 반복하지 않도록 분류해야 한다. 30일 data retention 요구도 유지되므로 zero data retention을 전제로 한 workload는 별도 승인을 확인해야 한다.
GitHub Copilot 코드 리뷰가 저장소의 필수 PR 승인으로 계산될 수 있다
GitHub Copilot code review가 pull request의 승인 가능 여부를 overview comment에 표시하고, 관리자가 허용하면 실제 approval을 제출할 수 있게 됐다. 이 승인은 저장소의 required approvals 규칙에 포함된다. 기능은 기본으로 꺼져 있으며 enterprise, organization과 repository 단위에서 설정한다. 승인 뒤 새 commit이 push되면 사람의 승인과 마찬가지로 Copilot 승인도 취소되고 다시 검토를 요청해야 한다.
변화의 핵심은 AI 의견이 merge gate의 표로 바뀔 수 있다는 점이다. 지금까지 Copilot comment를 참고 자료로만 사용하던 저장소가 설정 하나로 필수 승인 수를 채우게 되면 사람 reviewer 수와 branch protection의 의미가 달라진다. public preview 단계에서는 보안과 규제 요구가 있는 저장소에 일괄 활성화하기보다, 낮은 위험의 repository에서 false approval과 missed finding을 측정하는 편이 안전하다.
정책을 켤 경우 CODEOWNERS, status check와 human approval 조건을 분리해 어떤 조합에서 merge가 가능한지 테스트해야 한다. 특히 AI approval 하나만으로 required approvals가 충족되지 않도록 rule을 설계하고, 새 commit 이후 승인이 실제로 해제되는지 audit log와 함께 확인할 필요가 있다.
CloudWatch Database Insights가 EC2의 자체 관리 PostgreSQL을 관측한다
Amazon CloudWatch Database Insights가 Amazon EC2에서 직접 운영하는 PostgreSQL을 지원한다. CloudWatch Agent가 database load, wait event, query 통계와 host metric을 수집하고, 자체 관리 instance를 RDS 및 Aurora와 같은 fleet view에 표시한다. managed database와 EC2 database가 섞인 환경에서 성능 병목을 한 console과 같은 탐색 흐름으로 비교할 수 있다.
편의성이 늘어난 만큼 agent 배포와 데이터 경계가 새로 생긴다. query-level 통계에는 SQL text나 parameter 형태가 포함될 수 있으므로 수집 범위, IAM 권한과 CloudWatch 전송 비용을 먼저 검토해야 한다. database account는 관측에 필요한 최소 권한으로 분리하고 agent 장애가 database workload에 영향을 주지 않는지도 부하 환경에서 확인해야 한다.
Spring Boot 서비스의 connection pool 지표와 Database Insights의 DB load를 함께 볼 팀은 timestamp와 tag 기준을 맞추는 것이 중요하다. application trace에서 느린 요청을 찾은 뒤 같은 시간대의 wait event와 query 통계로 이동할 수 있도록 service, environment와 database 식별자를 일관되게 정해 두면 실제 진단 시간을 줄일 수 있다.
CloudWatch 알람이 신규 서비스의 지표 준비 시간을 기다릴 수 있다
CloudWatch metric alarm과 log alarm에 생성 직후 평가를 미루는 워밍업 기간이 추가됐다. WarmUpConfiguration으로 1분부터 2,880분까지 지정하며, 기본 동작은 평가 window를 채울 데이터가 모이면 설정 시간보다 일찍 평가를 시작한다. 전체 워밍업이 끝날 때까지 반드시 기다리도록 설정할 수도 있다. 워밍업 동안 alarm은 INSUFFICIENT_DATA 상태를 유지하고 action을 실행하지 않는다.
애플리케이션과 알람을 같은 CI/CD에서 만드는 환경에서는 시작 직후 지표가 없어 발생하는 page를 줄일 수 있다. 하지만 시작 단계의 CPU 급증이나 health check 실패까지 가리면 실제 배포 장애의 탐지가 늦어진다. 고정 시간보다 metric이 준비되는 즉시 평가하는 기본 모드를 우선 검토하고, 초기 변동 자체를 무시해야 하는 근거가 있을 때만 전체 시간 대기를 사용하는 편이 낫다.
배포 검증에서는 워밍업 종료 조건을 명시해야 한다. 새 revision이 metric을 전혀 내보내지 않는 경우, 늦게 내보내는 경우와 정상적으로 evaluation window를 채우는 경우를 각각 재현하고 INSUFFICIENT_DATA가 deployment success로 오해되지 않도록 별도의 readiness signal을 유지해야 한다.