본문으로 건너뛰기
J
피드

Oracle이 MySQL에 흥미를 잃자, 개발자들이 포크를 포함한 미래를 논의하기 시작

backend 약 3분
tags
#mysql#oracle#open-source#database#fork
vote
0
댓글
북마크

Oracle의 MySQL 핵심 개발팀 대규모 해고와 커밋 수 급감으로 커뮤니티가 위기감을 느끼고, Percona·PlanetScale 등이 모여 포크를 포함한 미래 옵션을 논의. 벡터 검색 등 누락 기능에 대한 고객 불만도 커지는 상황.

  • 1

    MySQL 창시자 몬티 비데니우스가 Oracle 해고 소식에 'heartbroken'

  • 2

    하드 포크(MariaDB 방식)와 트래킹 포크(Percona 방식) 두 옵션 검토

  • 3

    Oracle 대표도 미팅에 참석

  • 4

    클라우드 벤더 고객들이 벡터 검색 등 미지원 기능 때문에 고통

  • Oracle이 MySQL에 대한 관심을 잃어가면서, 커뮤니티 개발자들이 포크를 포함한 미래 옵션을 본격적으로 논의하기 시작함

  • 배경: Oracle의 MySQL 핵심 개발팀에서 대규모 해고가 있었고, 프로젝트 커밋 수도 급감. MySQL 창시자 몬티 비데니우스는 소식을 듣고 "가슴이 찢어진다(heartbroken)"고 표현

  • 샌프란시스코에서 Percona, PlanetScale 등의 엔지니어들이 모여서 향후 방향을 논의하는 미팅을 가짐. Oracle 대표도 참석했는데, Percona 공동창업자 자이체프는 "사랑을 많이 받을 자리가 아니었을 텐데 왔다는 건 높이 평가한다"고

  • Percona CTO 트카첸코의 비유: Oracle의 MySQL 관리 방식이 "개구리 삶기(boiling a frog)"와 같다고. 점점 더 많은 기능을 클라우드/엔터프라이즈 제품으로 옮기고, 인력을 줄이지만, 극단적인 조치는 안 해서 위기 임계점을 너무 늦게 깨달을 수 있다는 것

  • 테이블 위의 옵션은 두 가지:

    1. Oracle에 거버넌스 유지 — 투명성과 헌신을 개선하도록 압박
    2. 포크 — 하드 포크(MariaDB 방식)와 트래킹 포크(Percona Server 방식) 두 종류

  • PlanetScale CEO 샘 램버트: "MySQL은 웹의 작동에 필수적이며 수백만 개의 제품을 구동함. 우리는 자체 MySQL 포크를 유지하고 있고, 엔지니어링 자원을 투입해 MySQL의 건강을 보장할 것"

ℹ️참고

> 오픈소스 커뮤니티에서 벤더로부터 코드를 포크해온 전례가 있음. 2024년 Linux Foundation이 Redis를 포크해서 Valkey를 만들었고, AWS, Google Cloud, Oracle, Ericsson 등이 지원

  • 클라우드 벤더들도 접촉 중. 자이체프에 따르면 많은 벤더의 고객들이 벡터 검색 같은 MySQL 미지원 기능 때문에 고통받고 있다고. 구체적인 커밋먼트는 아직 비공개

  • 유럽 개발자 중심 후속 미팅이 FOSDEM 26(브뤼셀) 시기에 열릴 예정. 추가 피드백을 받은 뒤 최선의 방향을 결정할 계획

Redis → Valkey의 전례가 있는 만큼 MySQL 포크도 현실적인 시나리오. Oracle의 '개구리 삶기' 전략이 커뮤니티 반발의 임계점에 도달한 것으로 보임.

prev

이전 기사 (P)

next

다음 기사 (N)

댓글

댓글

댓글을 불러오는 중...

관련 기사

backend

클릭하우스가 PgBouncer 처리량을 4배로 끌어올린 방법

ClickHouse Managed Postgres 팀은 단일 스레드인 PgBouncer를 여러 프로세스로 띄우고 `so_reuseport`와 피어링(peering)을 조합해 16 vCPU 머신을 제대로 쓰게 만들었다. 동일한 AWS 환경에서 단일 프로세스는 약 8.7만 TPS 근처에서 막혔지만, 16개 프로세스 구성은 약 33.6만 TPS까지 올라갔다.

backend

SQLite 쓸 거면 STRICT 테이블을 기본값으로 보자는 주장

SQLite의 STRICT 테이블은 INTEGER 컬럼에 문자열이 들어가는 식의 타입 실수를 막아주는 기능이다. 글쓴이는 SQLite 특유의 유연한 타입 시스템보다, 실수는 빨리 터뜨리는 쪽이 실무에서 낫다고 주장한다. 다만 기존 테이블을 바로 STRICT로 바꾸기 어렵고, SQLite 3.37.0 이상에서만 쓸 수 있다는 제약도 있다.

backend

왜 아직도 Lisp를 배워볼 만한가

Lisp는 괄호가 많은 이상한 언어처럼 보이지만, 핵심은 문법이 아니라 언어 자체를 확장할 수 있다는 점에 있음. 매크로, 코드-데이터 동일성, REPL 중심 개발이 합쳐지면 프로그램을 '작성'한다기보다 살아 있는 시스템을 계속 진화시키는 방식으로 개발하게 됨.

backend

EDB 포스트그레스 AI, 포레스터 멀티모델 데이터 플랫폼 리더 선정

EDB의 AI 데이터 플랫폼 EDB 포스트그레스 AI가 2026년 2분기 포레스터 웨이브 멀티모델 데이터 플랫폼 보고서에서 리더로 선정됐음. 트랜잭션, 분석, AI 워크로드를 하나의 플랫폼에서 다루는 흐름이 강해지는 가운데, EDB는 전략과 현재 제공 기능 모두에서 높은 평가를 받았다고 밝힘.

backend

Bun, Zig에서 Rust로 갈아탔다: 11일짜리 초대형 런타임 포팅 실험

Bun 팀이 53만 줄이 넘는 Zig 코드베이스를 Rust로 기계적으로 포팅했고, Bun v1.4.0부터 Rust 기반으로 전환될 예정임. 핵심 이유는 성능보다 안정성이었고, use-after-free, double-free, 메모리 누수 같은 문제를 컴파일러와 타입 시스템으로 더 빨리 잡기 위해서였음. Claude Code 워크플로 64개를 병렬로 돌려 11일 만에 전 플랫폼 테스트 통과까지 밀어붙인 사례라, LLM 기반 대규모 코드 마이그레이션의 꽤 강한 신호탄임.