시작하며
이번에는 MySQL 에 대한 잡다한 이야기를 적어보고자 한다. 알아도 별 것 없는, 몰라도 아무래도 좋은 그런 이야기가 되겠다.
많은, 어쩌면 대부분의 프로그램들이 이전에 비슷한 목적으로 사용되던 다른 프로그램들의 문제점, 또는 불편함을 해소하기 위해 등장한다. MySQL 역시 마찬가지로 mSQL 의 문제점을 해결하기 위해 등장하였다. 그럼 대체 mSQL은 뭐였냐면…
mSQL
mSQL 역시 기존에 사용하던 어떤 프로그램의 문제를 해결하기 위해 등장하였다. 그 프로그램이 무엇이냐면 Postgres 라고 하는, 지금도 MySQL과 더불어 오픈소스 RDB의 양대산맥인 PostgresSQL 의 그 Postgres 이다.
당시 Postgres는 오픈소스 RDB로 명성을 쌓고 있었지만 결코 사용하기 쉬운 DB가 아니었는데 왜냐하면 SQL을 사용할 수가 없었기 때문이다.
range of E is EMPLOYEE
retrieve into W
(COMP = E.Salary / (E.Age - 18))
where E.Name = "Jones"
위의 쿼리가 당시 Postgres에서 사용하던 QUEL 이라는 쿼리문이다. 이 쿼리문을 SQL로 변환하면 아래와 같다.
select (e.salary / (e.age - 18)) as comp
from employee as e
where e.name = "Jones"
뭔가 SQL비스무리한것 같지만 SQL과는 꽤나 거리가 있는 이 QUEL 문법 때문에 Postgres에 쉽게 접근하기가 힘들었다. mSQL은 이 문제를 해결하기 위해 등장한 것으로, 일반 SQL을 QUEL로 변환시켜주는 프로그램이었다. 처음에는.
그러나 mSQL의 개발자는 자신의 프로젝트에 Postgres 가 어울리지 않는다고 판단하고 mSQL을 본격적인 DB로 만들게 된다. 이 때, 쿼리를 해석하고 연결을 유지하는 기능들은 이미 기존의 mSQL이 다 가지고 있었다. mSQL이 완전한 DB가 되기위해 추가적으로 만들어야 했던 것은 데이터를 저장하고 검색하는 것. 즉 스토리지 부분 뿐이었다.
MySQL 의 탄생
스웨덴의 TcX라는 회사에서 근무하던 Michael Widenius (일명 Monty)는 mSQL에 주목하였으나 원하는 만큼의 성능이 나오지 않았다. 이에 몬티는 mSQL 측에 스토리지 부분을 ISAM을 적용해볼 것을 제안을 하였으나 거절당하자 본인이 직접 mSQL 시스템 기반의 ISAM방식 스토리지를 가지는 DB를 만들게 된다.
MySQL을 개발하면서 중점을 두었던건 성능 뿐만 아니라 mSQL과의 호환성이었는데, mSQL에서 제공하는 API와 동일한 API를 제공하였다. 그래서 mSQL용으로 작성한 프로그램은 큰 수정 없이 바로 MySQL을 붙일 수 있었는데 이는 mSQL의 이용자들을 쉽게 MySQL로 넘어올 수 있게 했다.
결국 모든 면에서 mSQL을 압도하게된 MySQL은 순식간에 오픈소스 DB의 최강자로 우뚝서게 된다.
여담으로 MySQL의 개발자이자 MySQL AB의 공동창립자 중 하나인 몬티는 자신이 만든 제품에 자신의 자녀 이름을 붙이는걸 선호했는데, 첫째 딸 My의 이름을 따 MySQL이 된건 꽤 유명한 이야기다. 조금 덜 유명한 이야기도 있는데, 그의 막내 딸 이름은 Maria 라는 것이다.
Postgres 와 MySQL
IT버블과 웹시대의 개막과 함께 무료로 사용가능했던 MySQL은 폭발적으로 성장하게 되고 오픈소스 DB의 최강자로 올라서게 된다. 이 시기(지금도 그렇지만) MySQL 의 경쟁자로는 PostgresSQL이 있었는데 PostgresSQL도 적지 않은 점유율을 가져갔으나 MySQL 과는 꽤나 격차가 컸고, 이것은 지금까지도 계속 이어진다.
사실 DB로서의 완성도는 PostgresSQL가 더 좋았다. 상용 DB에서 제공하는 기능의 대부분을 구현했을 뿐만 아니라 ACID 도 잘 구현되었다. 다만 그 댓가로 성능을 희생해야 했는데, MySQL에 적게는 2배, 많게는 10배 이상 느렸기 때문이다. 특히 쓰기 작업이 발생 할 때의 속도가 느렸는데, 이는 속도를 위해 무결성을 희생해버린 MySQL에 비해서는 느릴 수 밖에 없었던 것이었다.
PostgresSQL는 상용DB 수준의 기능들을 제공했지만 그에 따라 서버의 스펙도 상용DB를 돌리는 급의 서버를 요구했다. 그에 비해 MySQL은 여러가지 단점들이 있었으나 어쨋든 가볍고 빨랐다. 웹사이트를 구축하는데는 MySQL만한 DB가 없었던 것이다.
오라클, 썬, MySQL
2009년, 썬 마이크로시스템즈가 오라클에 인수되면서 MySQL도 오라클의 품으로 들어갔다. 재미있는 것은 MySQL AB를 썬 마이크로시스템즈가 2008년에 인수를 했었는데, 이 때 잠재적 경쟁자가 오라클이었다는 것이다.
실제로 오라클은 2005년에 Innobase를 인수하고 2006년 Sleepycat을 인수함으로서 어떻게든 MySQL에 영향력을 끼치기 위해 노력하였다. 그러나 MySQL AB를 인수하지는 않았는데, 이는 EU의 반독점법의 영향으로 보인다.
IT버블로 직격타를 맞았던 썬은 2008년까지도 별 다른 반등을 보이지 못하였는데, 이것을 타개하기 위해 MySQL AB를 인수한다. PostgresSQL과 오라클을 꽤나 적극적으로 지원해주던 썬이었기에 이 인수는 조금 의외였던 면이 있었으나 어쨋든 당시에는 좋은 인수라는 평가를 받았었다.
아마 썬은 MySQL을 자사의 많은 상품과 연계하여 부활을 꾀할 예정이었으리라 생각되지만 그러나 그게 다 무슨 소용이랴. MySQL을 인수한지 1년만에 썬은 오라클에 넘어가게 되고 MySQL도 오라클의 것이 되고 만다.
이후, 많은 사람들은 MySQL의 미래를 걱정하였는데 오라클이 경쟁DB 였던 MySQL을 곱게 볼 리가 없다는 생각에서였다. 그러나 현재 MySQL이 오라클에서 차지하는 위치를 볼 때, 그 생각들은 틀린 것으로 보인다. MySQL은 어쨋든 오라클에게 꾸준히 수익을 안겨다주고 있다. 오라클DB 에는 영향을 미치지 않으면서 말이다. 사실 이것은 당연한 것으로, MySQL과 오라클DB는 같은 관계형 데이터베이스이지만 지향하는 시장이 전혀 다르기 때문이다.
마치며
오라클, SQL Server, MySQL이 시장의 3대장으로 위치를 굳건히 한지 근 10년이 다 되어가고 앞으로도 크게 변할 일은 없어보인다. RDB 시장에서는 AWS Aurora 가 상당한 기대를 모았으나 기대만큼은 아니었던 것으로 서서히 드러나고 있는 중이라 좀 더 지켜보아야 한다. 오라클이 돈 잘 벌어오고 있는 MySQL을 내팽개칠 일도 당분간은 없을 것이며, 오히려 지원을 잘해주고 있는 편에 속한다.
하드웨어 발전으로 인해 RDB의 위치는 오히려 과거보다 더 굳건해져가고 있는 모양새다. 보수적인 개발 시장에서도 가장 보수적이라 할 수 있는 데이터베이스 시장에서 지난 20년간 꾸준히 성장하여 시장 점유율 최상위 레벨까지 올라온 MySQL의 성과는 정말 대단한 것이다.
시장 특성 상 MySQL이 지금보다 더 점유율을 늘리기는 힘들 것으로 보이지만, 딱히 더 아래로 내려갈 것 같지도 않다. 비록 불완전한 DB로 시작했을지언정 지난 20년동안 쌓아온 MySQL이라는 이름의 신뢰는 사람들이 생각하는 것도 훨씬 크다. 이만한 이름 값을 지닐 오픈 소스 데이터베이스가 과연 또 다시 등장할 수 있을까? 어렵지 않을까 싶다.
