"MySQL" 태그로 연결된 2개 게시물개의 게시물이 있습니다.

MySQL에서 분석 쿼리를 억지로 버텨 본 경험이 있다면, 이 숫자들이 남 일 같지 않을 거예요. InnoDB로 28시간 넘게 돌리고도 다 못 끝낸 TPC-H 22개 쿼리를, 같은 MySQL 프로세스 안의 DuckDB 엔진이 185.6초에 끝냈습니다.

Percona가 8월 7일 공개한 실험입니다. DuckDB를 MySQL의 스토리지 엔진으로 붙인 실험 프로젝트를 TPC-H 스케일팩터 500, 그러니까 원본 CSV 500GB(약 30억 행) 규모에서 검증했습니다. MySQL은 스토리지 엔진을 갈아 끼울 수 있는 구조라는 걸 다들 알지만, 그 자리에 컬럼 지향 분석 엔진을 꽂는 발상을 실제 수치로 검증한 것은 드문 일입니다.

숫자부터​

테스트 환경은 80코어, 187.5GB RAM 서버 한 대입니다. 같은 데이터를 InnoDB, MySQL+DuckDB 엔진, 순수 DuckDB 세 가지로 적재하고 비교했습니다.

쿼리별로 보면 격차가 더 생생합니다. Q1은 InnoDB 11,864초가 11.1초로, Q6는 3,539초가 1.3초로 줄었습니다. InnoDB는 쿼리당 2시간 제한을 두었는데도 4개를 완주하지 못했습니다.

디스크 방향도 반대입니다. 원본 CSV 500GB가 InnoDB에서는 673GB로 늘어났고, DuckDB에서는 132GB로 압축됐습니다. 행 지향 저장과 인덱스 오버헤드 대 컬럼 저장과 압축의 차이가 그대로 드러납니다.

정확성 검증도 곁들여져 있습니다. 22개 쿼리 중 21개가 순수 DuckDB 결과와 소수점 4자리까지 일치했습니다.

어떻게 동작하나​

핵심은 MySQL의 스토리지 엔진 인터페이스입니다. 애플리케이션은 여전히 MySQL 프로토콜로 접속해 SQL을 실행하고, 해당 테이블의 저장과 스캔을 DuckDB가 담당합니다. 적재가 25.5배 빨랐던 비결도 여기 있는데, 엔진이 LOAD DATA를 행 단위 삽입으로 처리하지 않고 DuckDB의 COPY로 직접 전달해 배치 적재로 바꿉니다.

시도해 보는 것도 쉽게 만들어 놨습니다. Docker 이미지 한 줄로 실행됩니다.

docker run -d -p 3306:3306 -e MYSQL_ROOT_PASSWORD=secret \
  perconalab/ducksdb-mysql-engine:latest

냉정하게 볼 부분​

Percona 스스로 못박은 제약들이 있습니다.

첫째, 이것은 실험 소프트웨어입니다. 운영 투입 대상이 아니라고 글에서 반복해 강조합니다. 둘째, 분석 전용입니다. 포인트 조회 같은 OLTP 패턴은 여전히 행 경로가 낫고, 이 엔진의 목적이 아닙니다. 셋째, 메모리 관리가 아직 거칩니다. 메모리 제한을 넘는 쿼리는 디스크 스필 설정을 손봐야 합니다. 넷째, 서버 한 대의 특정 워크로드만 검증한 결과입니다.

그리고 벤치마크 자체의 성격도 감안해야 합니다. TPC-H는 컬럼 스토어에 유리한 순수 분석 워크로드입니다. InnoDB가 28시간 걸렸다는 것은 InnoDB가 나쁘다는 뜻이 아니라, 애초에 이 일을 시키면 안 되는 엔진에 이 일을 시켰다는 뜻에 가깝습니다. 문제는 현실의 많은 조직이 정확히 그렇게 쓰고 있다는 점이고, 이 실험의 가치는 그 간극을 숫자로 보여준 데 있습니다.

이어지는 실험: 복제로 OLTP와 분석 분리​

Percona는 이 실험을 한 단계 더 밀고 나가는 중입니다. 8월 13일 후속 글 Replicating from InnoDB into a DuckDB storage engine에서는 primary의 InnoDB 테이블을 replica의 DuckDB 엔진 테이블로 복제하는 구성을 다뤘습니다. 쓰기는 InnoDB가 받고, 분석은 DuckDB replica가 받는 그림입니다.

이 방향이 흥미로운 이유는 기존 선택지와의 비교 때문입니다. MySQL의 분석 부하를 떼어내는 전통적인 답은 별도 웨어하우스(ClickHouse, BigQuery 등)로의 CDC 파이프라인인데, 그 순간 스키마 동기화, 지연, 운영 부담이 따라옵니다. replica 한 대의 스토리지 엔진만 바꿔서 같은 효과를 얻는다면, MySQL 프로토콜과 권한 체계 안에서 문제가 끝납니다. PostgreSQL 진영에서 pg_duckdb가 겨냥하는 자리와 정확히 같은 자리입니다.

아직 붙일 이름은 실험이지만, 방향은 뚜렷해 보여요. 분석 엔진을 밖에 두고 데이터를 나르는 대신, 익숙한 DB 안으로 분석 엔진을 들여오는 흐름입니다. Docker 이미지가 공개되어 있으니 가벼운 데이터로 직접 실행해 보고, 결과가 재미있으면 후속으로 다루겠습니다.

참고 자료​

• The DuckDB MySQL engine at 500 GB - Percona Blog, 2026-08-07
• Replicating from InnoDB into a DuckDB storage engine - Percona Blog, 2026-08-13

한 주에 겹친 세 건​

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를 목표로 합니다.

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

마이그레이션 경로는 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나 웹페이지에서 원클릭으로 끝납니다.

즉 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 안의 에이전트가 작업을 조립하도록 합니다.

공통 메시지는 분명합니다. 주요 클라우드 데이터베이스가 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가 챙길 일은 줄지 않았고, 검토할 초안의 품질이 좋아졌을 뿐이에요.

참고​

• AWS Weekly Roundup: Claude Opus 4.8 on AWS, Aurora MySQL with Kiro Powers, and more (June 1, 2026)
• Amazon Aurora MySQL 8.4 is now generally available (AWS Database Blog)
• Kiro Powers