한 주에 겹친 세 건

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

여기에 그 주의 헤드라인 발표로 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를 만진다"는 문구는 마케팅처럼 들리기 쉽습니다. 실체를 보면 생각보다 구체적입니다.

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가 챙길 일은 줄지 않았고, 검토할 초안의 품질이 좋아졌을 뿐이에요.

참고