Aurora MySQL 3.14 정식 제공: 양자 내성 하이브리드 TLS 키 교환은 클라이언트도 지원해야 하고, DELETE의 RETURNING으로 예약어가 늘었으며, 행 크기 동작은 커뮤니티 8.0.46과 달리 기존 유지

Published 2026-11-02 · AI Daily — AI-assisted deep research, methodology & disclosure

2026년 11월 2일 AWS는 Aurora MySQL 3.14(MySQL 8.0.46 호환)의 정식 제공을 발표했고, 핵심은 양자 내성 TLS(PQ-TLS) 키 교환입니다. 릴리스 노트에 따르면 TLS 1.3용으로 X25519MLKEM768과 SecP256r1MLKEM768 하이브리드 그룹이 추가되며, 클라이언트가 지원할 때만 협상되고 아니면 기존 그룹을 쓰며 Aurora_ssl_named_group 상태 변수로 확인합니다. 3.08 이상에서 더 빠른 마이너 업그레이드, 단일 테이블 DELETE의 RETURNING(예약어가 되어 같은 이름 식별자는 백틱 필요), FTSCacheMemoryUsed 지표, 커뮤니티 버전과 다른 8.0.46 이전의 행 크기 동작 유지도 있습니다. 감사 로그는 정의자가 아니라 호출한 클라이언트를 기록합니다. 노트 날짜는 10월 26일이며 업그레이드 속도나 TLS 오버헤드 수치는 없습니다.

2026년 11월 2일 AWS는 Amazon Aurora MySQL 호환 에디션 3(MySQL 8.0 계열)이 Aurora MySQL 3.14로 MySQL 8.0.46을 지원한다고 밝혔습니다. 발표에 따르면 이 릴리스에는 커뮤니티 MySQL 수정과 Aurora 고유 개선이 담겨 있고, 가장 큰 추가 사항은 양자 내성 TLS(PQ-TLS) 키 교환 지원입니다. Aurora MySQL이 제공되는 모든 AWS 리전에서 쓸 수 있습니다. 날짜는 주의해야 합니다. Aurora 릴리스 노트는 3.14.0을 2026-10-26 날짜 아래에 올려 두었으므로, 엔진은 '오늘부터'라는 발표보다 약 일주일 앞서 문서화되어 있었습니다.

발표는 짧고, 양자 내성 기능이 무엇을 하는지는 릴리스 노트가 설명합니다. Aurora MySQL은 TLS 1.3 연결에서 기존 타원 곡선 그룹과 함께 X25519MLKEM768과 SecP256r1MLKEM768이라는 두 하이브리드 키 교환 그룹을 추가합니다. 양자 내성 키 교환을 지원하는 클라이언트는 자동으로 양자 내성 공유 비밀을 협상하고, 지원하지 않는 클라이언트는 기존 그룹을 계속 씁니다. 따라서 서버에서 스위치를 켜는 설정이 아니라, 클라이언트 라이브러리도 이 그룹을 지원하고 TLS 1.3을 쓸 때만 일어납니다. 세션이 무엇을 협상했는지는 SHOW STATUS LIKE 'Aurora_ssl_named_group'으로 확인합니다.

릴리스 노트에는 운영자에게 더 중요할 수 있는 다른 변경도 있습니다. 버전 3.08 이상에서 3.14로의 마이너 버전 업그레이드가 더 빨리 끝나 쓰기 인스턴스가 더 일찍 서비스로 돌아오며, 설정 변경이나 옵트인은 필요 없습니다. 단일 테이블 DELETE 문에 RETURNING 절이 추가되어 별도 SELECT 없이 삭제된 행의 값을 돌려받을 수 있습니다. RETURNING이 예약어가 되었으므로 returning이라는 이름의 식별자는 백틱으로 감싸야 하며, 감싸지 않으면 업그레이드 후 구문 분석에 실패합니다. 새 CloudWatch 지표 FTSCacheMemoryUsed는 인스턴스의 모든 테이블에 걸친 InnoDB 전문 검색 캐시의 메모리 사용량을 보여 줍니다.

호환성 선택 하나는 꼼꼼히 읽을 만합니다. 커뮤니티 MySQL 8.0.46은 특정 종류의 열이 많은 테이블 처리를 바꿔, 이전 8.0에서는 성공하던 같은 문도 ERROR 1118 'Row size too large'로 실패할 수 있습니다. 릴리스 노트는 Aurora MySQL 3.14.0이 이전 동작을 유지해 이런 문이 3.13.0 이하와 같이 계속 동작한다고 말합니다. 즉 이 점에서 Aurora 3.14는 커뮤니티 8.0.46과 다르며, 둘 사이를 오가며 테스트하거나 이전할 때 중요합니다.

노트에는 보안 수정도 있습니다. Advanced Audit 로그는 SQL SECURITY DEFINER 루틴 안에서 실행된 문에 대해 호출한 클라이언트가 아니라 정의자의 사용자와 호스트를 기록했는데, 이제는 호출한 클라이언트를 기록합니다. 준비된 문이 중복 감사 항목을 만들지 않게 되었습니다. 쓰기 전달을 쓰는 세션에서 SET ROLE NONE이 이전 역할의 권한을 지우지 않아 거부되어야 할 작업이 허용될 수 있던 문제도 고쳐졌습니다. 이 릴리스는 심각도 높음 CVE 두 건과 더 긴 심각도 중간 CVE 목록의 수정도 담고 있습니다. 규정 준수를 위해 감사 로그를 분석하는 팀은 업그레이드 후 사용자와 호스트 값이 달라질 것으로 예상해야 합니다.

배포에 관해 AWS는 자동 마이너 버전 업그레이드로 유지 관리 기간에 업그레이드할 수 있고, AWS Organizations 업그레이드 롤아웃 정책으로 여러 클러스터에 단계적으로 업그레이드할 수 있다고 합니다. 업그레이드는 제자리에서도, 스냅샷 복원으로도 가능합니다. 팀에게 실용적인 점검 목록은 짧습니다. PQ-TLS가 목표라면 클라이언트 라이브러리가 하이브리드 그룹을 협상하는지 확인하고, 코드에서 따옴표 없는 returning 식별자를 찾고, 감사 로그 소비자를 검토하고, 먼저 하위 환경에서 테스트하는 것입니다. 발표와 노트에는 빨라진 업그레이드의 속도나 TLS 오버헤드에 대한 수치가 없습니다.

요약하면, 하이브리드 키 교환은 클라이언트도 지원해야 하고, RETURNING은 예약어가 되었으며, 감사 로그의 사용자와 호스트 값이 달라지고, 행 크기 동작은 커뮤니티 8.0.46과 다릅니다. 노트의 날짜는 10월 26일이며 업그레이드 속도나 TLS 오버헤드 수치는 없습니다.

Sources

FAQ

Aurora MySQL 3.14로 올리면 연결이 자동으로 양자 내성이 되나요?

반드시 그렇지는 않습니다. 릴리스 노트는 TLS 1.3용 X25519MLKEM768과 SecP256r1MLKEM768 하이브리드 그룹을 추가하지만, 클라이언트도 양자 내성 키 교환을 지원할 때만 협상되고 아니면 기존 그룹이 쓰입니다. Aurora_ssl_named_group 상태 변수로 세션이 협상한 결과를 확인하세요.

업그레이드 전에 가장 쉽게 부딪히는 호환성 문제는 무엇인가요?

단일 테이블 DELETE에 RETURNING 절이 생기면서 RETURNING이 예약어가 되었습니다. returning이라는 이름의 식별자는 백틱으로 감싸지 않으면 업그레이드 후 구문 분석에 실패합니다. 또 감사 로그가 정의자 루틴에서 호출한 클라이언트를 기록하므로 옛 사용자·호스트 값에 의존하는 분석은 점검해야 합니다.

Aurora 3.14의 행 크기 처리는 커뮤니티 MySQL 8.0.46과 같은가요?

같지 않습니다. 커뮤니티 8.0.46은 열이 많은 일부 테이블 문에서 ERROR 1118 'Row size too large'로 실패할 수 있지만, 릴리스 노트는 Aurora MySQL 3.14.0이 8.0.46 이전 동작을 유지해 3.13.0 이하처럼 성공한다고 말합니다. 둘 사이를 오가며 테스트하거나 이전할 때 이 차이에 유의하세요.