한 줄 요약

2026-06-01 AWS Weekly Roundup의 핵심은 두 갈래다. Aurora MySQL 8.4가 정식 출시(GA)되어 커뮤니티 MySQL 8.4 LTS와 버전 번호가 직접 맞춰졌고, 같은 흐름에서 Aurora MySQL이 Kiro Powers와 통합되어 자연어로 데이터베이스 작업을 거는 길이 열렸다.

여기에 그 주의 헤드라인 발표로 Amazon Bedrock과 AWS의 Claude Platform에서 Claude Opus 4.8을 쓸 수 있게 됐다는 소식이 얹혔다. DBA 입장에서 흘려 넘기기 쉬운 발표 묶음이지만, 세 가지를 한 줄에 꿰면 클라우드 데이터베이스가 어디로 가는지가 보인다.

Aurora MySQL 8.4 GA — 무엇이 바뀌나

가장 실무적인 변화는 버전 번호 정책이다. Aurora MySQL 8.4는 Aurora가 커뮤니티 MySQL의 LTS(Long Term Support) 메이저 릴리스에 정렬되는 첫 버전이다. MySQL 8.4가 커뮤니티 MySQL의 첫 LTS 메이저이고, Aurora MySQL 8.4가 그 정렬을 처음 적용한 Aurora 메이저다. 커뮤니티 MySQL 8.4.7과 호환된다.

이게 왜 중요한가. 예전에는 Aurora MySQL 메이저 번호와 커뮤니티 MySQL 버전이 따로 놀았다. 자체 관리 MySQL이나 Amazon RDS for MySQL에서 Aurora로 마이그레이션할 때, 두 체계 사이를 머릿속으로 번역해야 했다. 8.4부터는 Aurora에서 돌리는 번호가 곧 호환되는 커뮤니티 MySQL 버전이다. 번역 부담이 사라진다.

LTS 정렬이 가져오는 두 번째 효과는 안정성이다. 커뮤니티 MySQL LTS 메이저는 최초 릴리스 이후 버그 수정과 보안 패치만 받는다. 그래서 Aurora MySQL 8.4 위에서 도는 애플리케이션은 minor 업그레이드를 거쳐도 동작이 일관되리라 기대할 수 있다. Aurora는 그 위에 새 기능을 minor 버전으로 계속 얹는다. 패치 관리도 단순해진다. minor 안에서의 patch 버전은 AWS가 대신 관리하고, Aurora가 해당 minor의 최신 patch로 자동으로 올라간다.

릴리스 주기도 명시됐다. Aurora는 커뮤니티 MySQL LTS 릴리스 후 12개월 안에 메이저를, 각 커뮤니티 minor 후 3개월 안에 minor를, 그리고 각 메이저 후 12개월 안에 Aurora LTS minor를 목표로 한다.

보안 기본값도 신규 클러스터 기준으로 단단해졌다.

항목8.4 신규 클러스터 기본값
인증 플러그인caching_sha2_password (기존 mysql_native_password 대체, 레거시는 호환용으로 유지)
전송 보안require_secure_transport 기본 활성 — 모든 연결에 TLS 요구
TLS 버전TLS 1.2 / 1.3만 지원 (1.0 / 1.1 제거)
비밀번호 정책DB 클러스터 파라미터로 복잡도·사용자명 검증 규칙 지정 가능

마이그레이션 경로는 RDS Blue/Green Deployments, in-place 업그레이드, 스냅샷 복원, AWS DMS, Percona XtraBackup 물리 마이그레이션까지 폭넓게 열려 있다. 8.4는 Aurora MySQL이 제공되는 모든 AWS 리전에서 쓸 수 있다.

기존 클러스터를 8.4로 올릴 계획이라면, 엔진 기능보다 먼저 챙길 것이 이 보안 기본값이다. TLS 강제와 caching_sha2_password는 오래된 드라이버나 connection 설정에서 연결이 끊기는 원인이 될 수 있다. 마이그레이션 전 검증 단계에서 클라이언트 호환성을 먼저 확인하는 편이 안전하다.

Kiro Powers — 자연어 DB 작업의 실체

“자연어로 DB를 만진다"는 문구는 마케팅처럼 들리기 쉽다. 실체를 보면 생각보다 구체적이다.

Kiro Powers는 미리 묶어둔 MCP 서버, steering 파일, hook을 모아둔 큐레이션 저장소다. Kiro 파트너가 검증한 묶음이며, 특정 용도를 빠르게 붙여 쓰도록 만들어졌다. Aurora MySQL 통합은 이 저장소에서 Aurora MySQL용 묶음을 끌어다 쓰는 방식이다.

개발자가 할 수 있는 일은 두 평면으로 나뉜다.

  • data plane — 쿼리, 스키마 관리 같은 데이터 작업
  • control plane — 클러스터 관리 같은 인프라 작업

둘 다 자연어로 지시할 수 있다. “Serverless 스케일링을 어떻게 잡아야 하나”, “RDS에서 Aurora로 어떻게 마이그레이션하나”, “replication을 어떻게 설정하나” 같은 질문에 상황에 맞춘 가이드를 돌려준다.

여기서 오해하면 안 되는 지점이 있다. 에이전트가 자연어를 받아 곧장 운영 클러스터에 손을 대는 게 아니다. 에이전트는 API 호출, SQL, 설정값을 만들어 보여주고, 사람이 검토한 뒤 실행한다. 마지막 방아쇠는 여전히 사람이 당긴다. 설치는 Kiro IDE나 웹페이지에서 원클릭으로 끝난다.

flowchart TD
  A[자연어 요청] --> B[Kiro 에이전트]
  B --> C[MCP 서버 도구 호출]
  C --> D[API·SQL·설정
초안 생성] D --> E{사람 검토} E -->|승인| F[Aurora MySQL 실행] E -->|수정| B

즉 Kiro Powers가 줄여주는 것은 “어떤 API를 어떤 순서로, 어떤 파라미터로 부를지"를 문서 뒤지며 조립하는 시간이다. 실행 권한과 책임은 그대로 DBA에게 남는다.

클라우드 DB의 AI 통합 흐름

이 발표를 단독으로 보면 기능 하나가 늘어난 것이다. 같은 시기 다른 발표와 묶으면 흐름이 드러난다.

바로 며칠 전 Google Cloud는 AlloyDB Remote MCP Server를 정식 출시했다. AI 에이전트가 표준 프로토콜로 PostgreSQL 호환 데이터베이스에 직접 붙어 SQL을 실행하고 인스턴스를 관리하도록 길을 연 발표다. 이 건은 AlloyDB가 AI 에이전트에 문을 열다에서 따로 다뤘다.

두 발표는 접근 방식이 조금 다르다. AlloyDB는 클라우드가 직접 관리형으로 호스팅하는 remote MCP 엔드포인트를 노출해, 에이전트가 그 엔드포인트로 붙는다. Aurora MySQL은 개발 환경(Kiro IDE)에 MCP 서버 묶음을 설치해, IDE 안의 에이전트가 작업을 조립하도록 한다.

항목AlloyDB Remote MCPAurora MySQL + Kiro Powers
호스팅클라우드 관리형 원격 엔드포인트Kiro IDE에 설치하는 MCP 묶음
진입점인증된 에이전트가 엔드포인트로 접속IDE 안의 에이전트가 도구 호출
공통점MCP 표준으로 DB에 자연어 인터페이스 부착MCP 표준으로 DB에 자연어 인터페이스 부착

공통 메시지는 분명하다. 주요 클라우드 데이터베이스가 MCP를 공통 규약으로 삼아 AI 에이전트에 인터페이스를 여는 중이다. 데이터 작업뿐 아니라 클러스터 관리 같은 control plane까지 자연어 대상으로 들어왔다. 1년 전이라면 콘솔이나 CLI로만 하던 일이다.

DBA 관점

세 발표를 DBA 시선으로 정리하면 이렇다.

첫째, Aurora MySQL 8.4 GA는 버전 관리가 단순해진다는 실용적 이득이 가장 크다. 커뮤니티 MySQL과 번호가 같아지니 마이그레이션 계획서에서 버전 매핑 표가 사라진다. 다만 보안 기본값이 바뀐 만큼, 업그레이드는 클라이언트 호환성 검증을 끼고 진행해야 한다.

둘째, Kiro Powers는 생산성 도구이지 자동 운영 도구가 아니다. 에이전트가 초안을 만들고 사람이 실행하는 구조라, 검토 없이 적용되는 위험은 설계상 막혀 있다. 그래도 운영 계정 자격증명이 에이전트의 작업 흐름과 맞닿는 만큼, 어떤 권한으로 어떤 클러스터에 접근할 수 있는지는 미리 좁혀두는 편이 좋다.

셋째, Bedrock의 Claude Opus 4.8은 이 흐름에서 엔진에 해당하는 변화다. AWS는 이 모델을 agentic coding과 knowledge work, 긴 자율 작업을 겨냥해 만든 모델로 소개했다. 더 긴 자율 세션을 이어가고, 오류에서 스스로 복구하며, 엔지니어처럼 코드베이스를 읽고 편집에 앞서 계획을 세운다는 설명이다. Bedrock에서는 Guardrails, Knowledge Bases, 데이터 거주(data residency) 같은 AWS 관리 기능과 함께 쓸 수 있다. 데이터베이스 작업을 다루는 에이전트의 추론 강도가 올라간다는 뜻이고, 그만큼 사람이 검토 경계를 어디에 둘지가 더 중요해진다.

결국 이번 묶음의 핵심은 “AI가 DB를 대신 운영한다"가 아니다. “조립과 탐색은 에이전트가 빠르게, 실행과 책임은 사람이” 쪽에 가깝다. DBA가 챙길 일은 줄지 않았다. 검토할 초안의 품질이 좋아졌을 뿐이다.

참고