YugabyteDB 2026.1: 분산 추적·QPM·Flink CDC·즉시 클론으로 운영 제어면을 넓힌 STS 릴리스

왜 지금 봐야 하나

YugabyteDB v2026.1.0.0은 2026년 6월 29일 공개된 STS(Short-Term Support) 릴리스다. 이번 릴리스가 중요한 이유는 새 SQL 문법 몇 개를 추가한 정도가 아니라, 운영자가 분산 SQL 클러스터를 관찰하고, CDC 파이프라인을 붙이고, 복구용 사본을 만들고, 플랜 회귀를 되돌리는 제어면(control plane) 이 한 번에 넓어졌기 때문이다.

특히 눈여겨볼 변화는 네 가지다.

YSQL Distributed Tracing (TP): 애플리케이션이 traceparent를 전달하면 YugabyteDB가 parse → plan → execute → commit → RPC 구간을 OpenTelemetry trace로 내보낸다. PostgreSQL 호환 SQL 계층에서 지연이 어디서 생겼는지 DB 밖의 tracing 도구로 볼 수 있게 됐다.
Query Plan Management (GA, 기본 활성화): 계획 히스토리와 힌트를 저장해, 통계 갱신·인덱스 추가·업그레이드 뒤에 나빠진 plan을 이전의 “좋았던 plan”으로 되돌릴 수 있다.
CDC DDL 이벤트 + Flink CDC support (EA/TP): 논리 복제 중 테이블 rewrite가 발생해도 slot을 내렸다 다시 만들지 않고 스트림을 이어가는 경로가 생겼고, Flink CDC 쪽에는 YugabyteDB용 커넥터 포크가 제공됐다.
Instant database cloning (GA): 포인트인타임 기준으로 zero-copy writable clone 을 초 단위로 만들 수 있다. 실수 복구와 재현 실험의 비용 구조가 달라진다.

즉, 2026.1은 “분산 PostgreSQL 호환 엔진”이라는 설명만으로는 부족하다. 관찰성, 복구, CDC 연결, plan 회귀 대응까지 운영자가 손댈 수 있는 표면이 늘어난 릴리스로 보는 편이 정확하다.

이 장은 2026-06-29 공개된 v2026.1.0.0을 기준으로 썼다. 보조 근거로 2026-07-09 공개된 Yugabyte 공식 Flink CDC 기술 설명과 각 기능 문서를 함께 참조했다.

YugabyteDB 2026.1 핵심 변화 요약

영역	maturity	무엇이 달라졌나	운영자가 받는 의미
YSQL Distributed Tracing	TP	`traceparent` 기반 OTel trace export	느린 쿼리를 DB 내부 단계와 RPC 구간까지 waterfall로 분해 가능
Query Plan Management	GA	`yb_pg_stat_plans_track=all` 기본 활성화	업그레이드·통계 변경 뒤 plan regression을 추적·pin 가능
CDC table rewrite handling	EA	rewrite DDL 중에도 CDC가 DDL 이벤트를 보내고 새 tablet으로 전환	slot 재생성·재스냅샷 없이 스키마 변경을 수행할 여지 증가
Implicit publication	GA	publication 변경을 commit 시점 기준으로 정확 반영	새 테이블 추가 시 CDC 누락 가능성 감소
Flink CDC support	TP	YugabyteDB용 Flink CDC 포크 및 배포 가이드	Kafka Connect 없이도 Flink SQL/DataStream 기반 파이프라인 가능
Instant database cloning	GA	zero-copy clone + independent delta file	사용자 실수 복구·디버깅용 사본 생성 비용 대폭 감소
YCQL OIDC auth	GA	JWT를 password로 쓰는 YCQL OIDC auth	Cassandra API 계층도 외부 IdP와 직접 연동 가능

YugabyteDB 2026.1 운영 제어면 아키텍처

YugabyteDB 2026.1: tracing·QPM·CDC·clone이 분산 SQL 운영면에 붙는 방식

1. 분산 추적과 QPM: 느린 이유를 찾고, 나빠진 plan을 되돌리는 경로가 생겼다

YSQL Distributed Tracing은 어디까지 보여 주나

YSQL Distributed Tracing은 애플리케이션이 W3C traceparent 값을 전달하면 YugabyteDB가 그 쿼리에 대해 trace를 생성하고, OTLP/HTTP로 collector에 내보내는 기능이다. span 이름은 query, parse, rewrite, plan, execute, commit, 그리고 rpc yb.tserver.PgClientService.Perform 같은 RPC 단계까지 포함된다.

중요한 점은 두 가지다.

기본값은 off 이고, query opt-in 방식이다.
tablet-server 내부 tracing은 아직 포함되지 않는다. 즉, “RPC를 어디까지 보냈는가”는 보이지만, tablet 내부 compaction·Raft·storage 세부 단계까지 한 번에 보이는 것은 아니다.

그래도 운영상 의미는 크다. 기존에는 “느린 쿼리”를 보려면 애플리케이션 APM, PostgreSQL 계열 쿼리 로그, Yugabyte 메트릭을 따로 맞춰야 했는데, 이제는 적어도 SQL 계층의 어느 단계가 긴지 를 trace 하나로 잡아낼 수 있다.

# preview flag 허용 + collector endpoint 설정 (YB-TServer, restart 필요)
--allowed_preview_flags_csv=otel_collector_traces_endpoint
--otel_collector_traces_endpoint=http://otel-collector:4318/v1/traces

-- 쿼리 단위 opt-in
/* traceparent='00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01' */
SELECT *
FROM orders
WHERE account_id = 42;

QPM은 “왜 plan이 바뀌었는지” 대신 “어떻게 되돌릴지”를 제공한다

2026.1부터 QPM은 yb_pg_stat_plans_track=all 로 기본 활성화된다. QPM의 핵심은 실행 계획의 “현재 상태”보다 계획 히스토리 를 남기는 데 있다.

통계 갱신으로 optimizer 추정치가 바뀌었을 때
새 인덱스가 추가됐을 때
minor/major upgrade 뒤에 planner 동작이 바뀌었을 때
바인드 변수 분포가 달라졌을 때

QPM은 yb_pg_stat_plans, yb_pg_stat_plans_insights 같은 view에 query별·plan별 이력을 남긴다. 그리고 이전에 더 좋았던 plan을 재생성할 수 있는 hint를 보존해 pin 할 수 있게 한다.

이 기능은 tracing과 성격이 다르다.

Tracing 은 한 번의 느린 요청을 세로로 쪼개는 도구다.
QPM 은 시간이 지나며 바뀐 실행 계획을 가로로 비교하는 도구다.

둘을 같이 써야 하는 이유는 분명하다. trace가 plan 단계 이후 execute 가 늘어났다고 알려 주더라도, 실제 원인이 통계 변화에 따른 join plan 전환인지, 데이터 분포 변화인지, 업그레이드 때문인지는 plan history 없이는 판단하기 어렵다.

EXPLAIN (queryid on, planid on)
SELECT count(*)
FROM orders o
JOIN order_items i
  ON o.order_id = i.order_id
WHERE o.account_id = 42;

운영상 주의할 점도 있다.

QPM은 hint를 생성할 수 있는 SELECT/INSERT/UPDATE/MERGE/DELETE/EXECUTE 만 추적한다.
EXPLAIN ANALYZE 자체는 추적 대상이 아니다.
Query ID는 FROM 절 순서, predicate 순서에 민감하다. 논리적으로 같은 SQL이어도 문장 형태가 바뀌면 query ID가 달라질 수 있다.

즉, ORM이나 query builder가 SQL 문자열을 자주 재배열하는 환경 에서는 QPM 운영 규칙을 먼저 정해 두는 편이 낫다.

2. CDC와 Flink: “slot을 내리고 다시 떠야 하는 순간”을 줄이기 시작했다

table rewrite DDL을 CDC가 감지하고 스트림을 이어 간다

2026.1 이전에는 CDC가 켜진 DB에서 table rewrite를 유발하는 DDL이 나오면 운영자가 대개 두 선택지 중 하나를 강요받았다.

DDL을 미루거나,
replication slot을 내리고 다시 만들어 CDC snapshot을 다시 잡는다.

2026.1부터는 enable_table_rewrite_for_cdcsdk_table=true(기본값)일 때, logical replication이 rewrite DDL을 감지하고 DDL 이벤트를 보낸 뒤 기존 tablet에서 남은 변경을 먼저 흘려보내고, 이후 새로 rewrite된 tablet의 변경을 이어 받는 경로 가 생겼다.

이 변화는 “DDL을 아무 때나 해도 안전하다”는 뜻이 아니다. 문서가 분명히 적은 한계가 있다.

TRUNCATE 는 CDC client로 truncate record를 보내지 않는다.
rewrite 이후 기존 데이터가 다시 전송될 수 있다. downstream에서 중복 처리 전략이 필요하다.
colocated table에서는 아직 지원되지 않는다.

그럼에도 운영자 입장에선 큰 진전이다. 이제 스키마 변경이 logical replication 전체를 리셋해야 하는 절차가 아니라, downstream dedupe와 재처리 규칙을 갖춘 조건부 운영 변경 으로 바뀌기 시작했기 때문이다.

implicit publication은 PostgreSQL 기대치에 더 가까워졌다

FOR ALL TABLES publication이나 publication 변경을 다루는 팀에게는 implicit publication 이 더 직접적이다. 새 테이블을 publication에 추가한 commit 시점부터 변경이 정확히 반영되므로, publication poll timing 때문에 새 테이블 이벤트를 놓치는 종류의 오류를 줄일 수 있다.

이건 화려한 기능처럼 보이지 않지만, CDC 장애의 상당수가 “slot은 살아 있는데 어떤 테이블은 안 들어오는” 식의 경계 문제라는 점을 생각하면 실전 가치가 높다.

Flink CDC support는 PostgreSQL 호환 “같아 보이는” 지점에서 멈추지 않았다

공식 기술 글이 설명한 가장 중요한 부분은 여기다. Yugabyte는 PostgreSQL 호환이지만, Flink CDC upstream postgres connector가 단일 PostgreSQL 서버를 전제한 몇몇 내부 동작 을 그대로 기대하면 분산 DB에서는 어긋난다.

Yugabyte가 Flink CDC용 포크에서 수정한 핵심은 다음과 같다.

snapshot 이후 스트리밍 시작 지점 계산

- upstream은 PostgreSQL 함수로 현재 로그 위치를 읽는다. - Yugabyte 포크는 그 대신 replication slot에서 직접 위치를 읽도록 바꿨다. - 목적: snapshot → streaming 전환 시 누락·중복 없이 이어 붙이기.

replication slot 생성 방식

- Yugabyte가 기대하는 방식에 맞게, slot 생성이 transaction 안에 묶이지 않도록 조정했다.

초기 snapshot 준비 단계 분리

- upstream snapshot setup의 묶음 명령 중 일부가 Yugabyte 제약과 충돌해, setup을 분리 실행하도록 바뀌었다.

장애 내구성 검증

- 공식 글에 따르면 chaos/failure scenario를 넣어 stress test했고, 장기 실행 안정성을 위해 checkpoint + restart strategy를 전제로 설명한다.

이건 단순한 “새 connector가 생겼다” 수준이 아니다. PostgreSQL 호환 API만 맞추면 되는 줄 알았던 CDC 경로에서, 분산 DB 고유의 snapshot/LSN/slot semantics를 별도로 다뤄야 한다는 사실을 공식적으로 드러낸 변화 다.

CREATE PUBLICATION dbz_publication FOR ALL TABLES;
SELECT * FROM pg_create_logical_replication_slot('flink', 'pgoutput');

Flink CDC TP 운영 전제
- 검증된 Flink 버전: 1.20.x
- source connector: postgres-cdc (YugabyteDB fork)
- sink connector: JDBC 등
- decoding.plugin.name: 반드시 pgoutput
- restart strategy + checkpoint 저장소 필수

운영 해석

Kafka Connect + Debezium을 이미 쓰는 팀이라면 Flink CDC가 무조건 대체재는 아니다. 그러나 다음 조건이면 검토 가치가 높다.

CDC 이후에 바로 Flink SQL/DataStream 변환이 필요하다.
Kafka topic fan-out보다 한 작업 안에서 snapshot + stream + sink 를 끝내는 편이 단순하다.
downstream sink가 PostgreSQL, Kafka, Elasticsearch, Iceberg처럼 Flink 생태계에 이미 있다.

반대로 아직 TP 단계인 만큼, 장애 주입 테스트와 checkpoint 복구 훈련 없이 프로덕션 기본 경로로 올리는 것은 이르다.

3. Instant database cloning: PITR 전체 복구와 다른 선택지가 생겼다

Instant database cloning은 이름 그대로 “빠른 사본”이 핵심이 아니다. 더 중요한 건 사본이 writable clone인데도 처음엔 source data file을 공유하는 zero-copy 구조 라는 점이다.

문서 기준 동작은 이렇다.

clone 생성 시점에는 source와 같은 data file 을 읽는다.
clone 쪽에 새 쓰기가 들어오면 그때부터 clone의 delta file 로 분기한다.
둘은 물리적으로 일부 파일을 공유하지만, 논리적으로는 독립적이다. clone에서 DDL·쓰기·삭제를 해도 원본은 영향받지 않는다.

이 설계가 바꾸는 운영 시나리오는 두 가지다.

1) 사용자 실수 복구

예를 들어 09:01에 테이블이 잘못 삭제됐고, 10:45에 문제를 알았다면 전체 PITR로 원본을 되돌리기 어렵다. 그 사이 다른 테이블에 쌓인 정상 데이터까지 날릴 수 있기 때문이다.

clone은 여기서 더 작은 복구 단위를 제공한다.

09:00 시점 clone 생성
clone에서 손실 데이터 확인
필요한 행/테이블만 export
원본으로 selective import

즉, 전체 DB 롤백 없이 특정 손실만 건지는 절차가 가능해진다.

2) production 상태 재현

버그 재현, migration rehearsal, query tuning 검증을 할 때도 효과가 크다. 예전에는 최신 백업을 복원해 staging을 새로 띄우는 시간이 길었지만, clone은 history retention window 안의 임의 시점으로 빠르게 붙일 수 있다.

하지만 진짜 운영 비용은 따로 있다

문서가 명확히 말한 주의점도 중요하다.

clone은 추가 tablet을 만들기 때문에 메모리 사용량이 늘 수 있다.
원본이나 clone에서 compaction이 일어나면, 서로 다른 읽기 시점을 보존하기 위해 디스크 사용량이 일시적으로 더 커질 수 있다.
history retention 경계에 너무 가까운 시점으로 clone하려 하면 실패할 수 있다.
DDL이 실행 중이던 시점으로 clone하면 실패할 수 있다.
multi-region에서 object가 많은 DB는 시간이 오래 걸릴 수 있고, 필요하면 ysql_clone_pg_schema_rpc_timeout_ms 조정이 필요하다.

즉, clone은 “무료 복구”가 아니다. restore 시간을 줄이는 대신 retention·tablet count·compaction 이후 disk growth를 운영자가 떠안는 기능 이다.

4. 2026.1을 어떻게 도입할 것인가

먼저 켤 것

QPM 기본 상태 점검

- yb_pg_stat_plans_track 값 확인 - yb_pg_stat_plans, yb_pg_stat_plans_insights 수집 경로 마련 - upgrade 전후 대표 쿼리의 plan ID 변화 기록

Instant clone 리허설

- history retention window 안에서 2~3개 복구 시나리오 연습 - clone 생성 후 tablet 수, compaction 이후 disk growth 관찰 - selective export/import runbook 작성

CDC rewrite DDL 검증

- staging에서 ALTER TYPE, ADD COLUMN DEFAULT, TRUNCATE 등을 실제로 흘려 보기 - downstream dedupe 기준과 re-snapshot 기준 합의

조건부로 켤 것

Distributed Tracing

- 이미 Jaeger/Tempo/OTel collector가 있는 환경이면 pilot이 쉽다. - 다만 TP이고 tablet 내부 span이 없으므로, 모든 성능 분석을 이걸로 대체하려 하면 실망하기 쉽다.

Flink CDC

- Flink를 이미 운영 중이고, CDC 뒤에서 바로 join/transform/sink를 태워야 하는 팀에 적합하다. - checkpoint 저장소·restart strategy·slot failover 훈련이 없으면 아직 TP를 production 기본 경로로 보기 어렵다.

YCQL OIDC auth

- Cassandra API 사용자까지 외부 IdP에 붙여야 하는 팀엔 반갑다. - 다만 DB 사용자 사전 생성, use_cassandra_authentication=true, ycql_jwt_conf 의 JWKS/audience/issuer 관리가 필요하다.

당장 미뤄도 되는 것

tracing이 필요한 조직적 수요가 아직 없고, 느린 쿼리 대응이 EXPLAIN + metrics + ASH 수준에서 충분하다면 TP tracing은 급하지 않다.
Debezium/Kafka Connect 기반 CDC가 안정적으로 굴러가고 있고 downstream 변환도 Kafka 기반이라면, Flink CDC로 갈아탈 이유는 아직 약하다.

운영자 체크리스트

yb_pg_stat_plans_track 가 실제로 기본값 all 로 들어왔는지 확인한다.
대표 쿼리군에 대해 EXPLAIN (queryid on, planid on) 저장 절차를 만든다.
otel_collector_traces_endpoint 를 preview flag 허용 목록과 함께 설정할 수 있는지 확인한다.
tracing pilot에서 span export 지연(otel_batch_schedule_delay_ms)과 drop 위험(otel_batch_max_queue_size)을 점검한다.
CDC를 쓰는 테이블에서 rewrite DDL 시 downstream dedupe가 되는지 검증한다.
TRUNCATE 미전송, colocated table 미지원, rewrite 후 기존 데이터 재전송 가능성을 runbook에 적는다.
Flink CDC job에 checkpoint 저장소와 restart strategy를 강제한다.
Flink CDC source가 pgoutput 로 설정됐는지 확인한다.
clone 시나리오에서 history retention, tablet 증가, compaction 후 disk growth를 측정한다.
YCQL OIDC를 쓸 경우 ycql_jwt_conf 의 jwt_jwks_url, jwt_audiences, jwt_issuers, jwt_matching_claim_key 를 문서화한다.

결론

YugabyteDB 2026.1은 “분산 SQL 엔진이 더 빨라졌다”는 식으로 요약하면 놓치는 것이 많다. 이번 릴리스의 본질은 운영자가 DB를 다루는 방식 을 바꿨다는 데 있다.

느린 요청은 trace로 쪼갤 수 있게 됐고,
plan regression은 QPM으로 되돌릴 수 있게 됐고,
CDC는 DDL과 Flink 쪽으로 한 단계 더 넓어졌고,
복구는 전체 restore 대신 clone 기반 선택 복구라는 옵션이 생겼다.

다만 maturity는 섞여 있다. QPM·clone·implicit publication은 바로 운영 표면에 올려도 되지만, tracing과 Flink CDC는 아직 TP 성격이 강하다. 따라서 2026.1의 올바른 도입 순서는 QPM과 clone부터 실전 runbook에 넣고, CDC rewrite handling을 staging에서 검증한 뒤, tracing과 Flink CDC를 pilot으로 붙이는 것 에 가깝다.

이 릴리스는 “분산 PostgreSQL”의 기능 확장이 아니라, 분산 PostgreSQL을 운영 가능한 시스템으로 만드는 주변부가 정리되기 시작한 시점 으로 읽는 편이 정확하다.

References

YugabyteDB Docs, "What’s new in the YugabyteDB v2026.1 STS release series" — https://docs.yugabyte.com/stable/releases/ybdb-releases/v2026.1/
YugabyteDB Docs, "YSQL Distributed Tracing" — https://docs.yugabyte.com/stable/launch-and-manage/monitor-and-alert/ysql-distributed-tracing/
YugabyteDB Docs, "Query plan management" — https://docs.yugabyte.com/stable/launch-and-manage/monitor-and-alert/query-tuning/query-plan-manage/
YugabyteDB Docs, "Instant database cloning" — https://docs.yugabyte.com/stable/manage/backup-restore/instant-db-cloning/
YugabyteDB Docs, "Advanced topics" (logical replication) — https://docs.yugabyte.com/stable/additional-features/change-data-capture/using-logical-replication/advanced-topic/
YugabyteDB Docs, "Get started with Flink CDC and YugabyteDB" — https://docs.yugabyte.com/stable/additional-features/change-data-capture/using-flink-cdc/get-started/
Bakul Gupta, "Flink CDC for YugabyteDB", Yugabyte Blog, 2026-07-09 — https://www.yugabyte.com/blog/flink-cdc-for-yugabytedb/
YugabyteDB Docs, "OIDC authentication in YCQL" — https://docs.yugabyte.com/stable/secure/authentication/oidc-authentication-ycql/