MariaDB

MySQL 이 오라클에 인수된 뒤 원 개발자들이 갈라져 나와 만든 포크. 초기에는 드롭인 대체를 표방했지만, 시간이 지나며 서로 다른 DB 로 벌어졌다.

왜 갈라졌나

MySQL 이 인수되면서 오픈소스로 남을지에 대한 불확실성이 생겼다. 원 개발자들은 코드를 포크해 재단 아래 두고 개발을 이어 갔다. 기술적 불만이 아니라 거버넌스와 라이선스가 이유였다는 점이 중요하다 — 그래서 초기에는 기능이 거의 같았고 "드롭인 대체" 라는 말이 성립했다.

시간이 지나며 양쪽이 각자 기능을 넣었고, 그 기능들이 서로 호환되지 않으면서 벌어졌다. 같은 뿌리에서 시작해도 따로 발전하면 갈라진다는 포크의 일반적인 경로를 그대로 밟았다.

무엇이 같고 무엇이 다른가

기본 SQL 문법, 접속 프로토콜, 대부분의 클라이언트 도구는 그대로 통한다. 그래서 간단한 애플리케이션은 접속 문자열만 바꿔도 돈다. 문제는 깊이 들어갈수록 갈라진다는 점이다.

• JSON 타입 — MySQL 은 전용 바이너리 타입으로 저장하고 경로 색인을 지원한다. MariaDB 의 JSON 은 사실상 텍스트 타입의 별칭이라 동작이 다르다
• 복제 방식 — MySQL 은 GTID 기반, MariaDB 는 자체 GTID 체계를 쓴다. 서로 복제를 걸 수 없다
• 기본 스토리지 엔진과 옵션 — InnoDB 계열을 쓰지만 세부 튜닝 파라미터 이름과 기본값이 다르다
• 버전 번호가 안 맞는다 — MariaDB 10.x·11.x 와 MySQL 8.x 사이에 대응 관계가 없다

그래서 실무에서 무엇이 문제인가

드라이버와 도구가 조용히 어긋난다. JDBC 드라이버를 MySQL 것으로 두고 MariaDB 에 붙이면 대체로 되지만, 메타데이터 조회나 특정 타입 처리에서 예상 밖 동작이 나온다. ORM 이 방언(dialect)을 잘못 잡으면 생성되는 DDL 이 달라진다.

더 흔한 사고는 "MySQL 문서를 보고 MariaDB 를 운영하는 것" 이다. 파라미터 이름이 같아 보여 그대로 넣었는데 무시되거나 다른 의미로 동작한다. 버전에 맞는 자기 문서를 봐야 한다.

어느 쪽을 고르나

기술적 우열보다 주변 환경으로 정해지는 경우가 많다.

• 클라우드 관리형 서비스가 무엇을 지원하나
• 팀이 아는 쪽이 어디인가
• 쓰려는 기능이 한쪽에만 있나

한번 고르면 바꾸기가 생각보다 어렵다. 스키마와 쿼리는 옮겨도 운영 도구·백업 절차·모니터링 지표가 전부 그쪽에 맞춰져 있기 때문이다.

마이그레이션을 한다면

옮기는 일 자체보다 확인할 목록이 길다.

• 쓰고 있는 SQL 에 한쪽 고유 문법이 있는지 (JSON 함수, 윈도 함수 세부, 힌트)
• 스토리지 엔진 파라미터 이름이 대응되는지
• 복제 구성을 새로 짜야 한다는 점 — 양쪽 사이 복제는 안 된다
• 백업·모니터링 도구가 대상 DB 를 지원하는지

가장 확실한 검증은 운영 쿼리를 그대로 재생해 보는 것이다. 스키마가 올라가고 애플리케이션이 뜨는 것만으로는 성능 회귀나 미묘한 동작 차이를 못 잡는다. 특히 실행 계획이 달라져 인덱스를 안 타는 쿼리가 나오는 경우가 있는데, 이것은 부하를 걸어 봐야 드러난다.

면접 함정

• ❌ "MariaDB 는 MySQL 의 최신 버전" → 별개의 포크다. 버전 번호에 대응 관계가 없다.
• ❌ "드롭인 대체라 그냥 바꿔도 된다" → 초기 주장이었고 지금은 아니다. JSON·복제·튜닝 파라미터가 갈렸다.
• ❌ "둘 사이에 복제를 걸면 된다" → GTID 체계가 달라 안 된다.