기고 | MySQL의 8가지 단점

InfoWorld
MySQL은 설치가 간편하고 상대적으로 빠르며 다양한 기능을 지원한다. 유명한 오픈소스 프로젝트 중 하나이기도 하다. 하지만 직접 사용해 본 사람이라면 여러 가지 이유로 놀라움을 감추지 못했을 것이다. 이를테면 인터넷에서 쓸데 없는 것들만 모으고 아무런 시도도 하지 않는 기술처럼 여겨지기도 한다.

많은 이들이 선택하는 이 오픈소스 관계형 데이터베이스와 관련해 불편하거나 당황스러운 8가지 특성을 정리했다. 단 아래의 모든 이유가 비단 MySQL에만 국한된 것은 아니다. 일부는 일반적인 관계형 데이터베이스에 모두 적용되는 이야기이다.

하지만 관계형 데이터베이스와 MySQL에 대해 명확하게 생각하지 않는다면 1990년대에 영원히 갇히게 될지도 모른다. 쌓기 위해서는 먼저 무너뜨릴 필요가 있다. (또는 이런 목록을 작성할 수 있을 정도로 오래 되지 않은 새로운 데이터베이스로 전환해야 할 필요가 있을 것이다.)



깊숙이 자리 잡은 버그와 특이함
대형 소프트웨어 패키지는 버그가 있게 마련이다. 하지만 좀 더 깊이 파보면 MySQL의 버그는 고질적이다. NULL이 늘 언제나 동일하게 동작하거나 외부 키 제약이 강제되거나 자동 증가가 올바르게 진행되는지 알 수 없기 때문에 주의해야 한다.

수십 가지의 작은 문제들이 존재하며 이런 문제가 항상 해결되는 것은 아니다. 이 때문에 사람들이 이와 같은 갓차(gotcha) 리스트를 유지하는 것이다. MySQL이 상시 버그 보고 시스템을 유지하는 점만 보아도 문제가 실제로 존재한다는 사실을 알 수 있다. 다른 사람들도 같은 불만감을 느끼고 있다.

관계형 테이블의 비유연성
테이블은 원칙을 제공하며 원칙은 좋은 것이다. 하지만 프로그래머가 강제로 데이터를 조작하거나 스키마(Schema)로 정의한 불가변 행에 데이터를 넣을 때는 그렇지 못하다.

NoSQL이 인기를 얻고 있는 이유 중 하나는 프로그래머가 상황에 따라 데이터 모델을 개선할 수 있는 유연성 때문이다. 주소에 1줄을 추가해야 하는 경우 NoSQL 문서에 손쉽게 추가할 수 있다. 누가 무엇을 알고 있는지에 관해 새로운 블록을 추가하고 싶은 경우에도 문서 모델은 데이터 자체를 있는 그대로 수용할 준비가 되어 있다.

우편번호가 모두 정수로 저장되어 있는 테이블을 구축한다고 생각해 보자. 매우 효율적이며 규칙도 잘 시행한다. 그리고 누군가 하이픈이 들어 있는 9자리 우편번호를 보낸다. 또는 캐나다의 고객이 글자가 섞여 있는 우편번호를 보내올 수 있다.

그러면 모든 것이 엉망이 된다. 상사는 수 시간 이내에 웹 사이트의 정상 동작을 원한다. 솔루션을 다시 설계할 시간이 없다. 이 때 프로그래머는 무엇을 할까? 캐나다의 우편번호를 Base64 번호로 취급하거나 기본 10으로 다시 변환하는 핵(Hack)을 만들까? 아니면 실제 우편번호가 다른 곳에 있다는 것을 나타내는 특수 이스케이프(Escape) 부호가 있는 보조 테이블을 구성할까?

누가 알겠는가? 수십 가지의 핵(Hack)이 존재할 수 있으며 모두 위험하다. 하지만 문제는 시간이 부족하다는 것이다.

MySQL의 관계형 규칙 때문에 모든 사람이 솔직하고 신중해지지만 핵과 닷지(Dodge)를 통해 문제를 숨기는 것 밖에 다른 방도가 없을 수 있다.

JOIN
한 동안 컴퓨터 공학 분야에서는 데이터를 복수의 테이블로 분할하는 것이 최고라는 생각이 팽배했었다. 결과 테이블이 훨씬 작을 뿐 아니라 간결함을 제공했기 때문이다. 그러나 그런 원칙과 명쾌함의 대가는 JOIN 성명의 형태로 뒤따른다.

개발자들은 복잡한 JOIN 시퀀스를 구성하다가 절망을 맛본다. 그리고 스토리지 엔진은 JOIN을 효율적으로 풀어낼 최적의 방법을 찾아야 한다. 개발자들은 정교한 쿼리(Query)를 개발하고 데이터베이스가 이를 풀어낸다.

이 때문에 속도를 원하는 많은 개발자들이 이 엄청난 실험을 단념하고 자신의 테이블을 비정규화하고 있다. 항목을 분리하는 대신에 그들은 하나의 크고 방대한 테이블에 쑤셔 넣어 복잡성을 우회한다. 모든 것이 빠르며 서버의 메모리는 (그리 쉽게) 떨어지지 않는다.

오늘 날 디스크 용량은 저렴하다. 시장에는 8TB의 드라이브가 존재하며 더 큰 것들이 개발되고 있다. 사실 우리는 더 이상 JOIN 때문에 머리를 쥐어 뜯을 필요가 없다.

포크(Fork) 혼란
MySQL의 탄탄하면서 지원이 적절한 포크의 존재 때문에 경쟁과 선택이 존재할 수 있는 것은 사실이다. 그러나 혼란과 혼돈도 일어나고 있다. 상황을 악화시키는 것은 MariaDB가 MySQL의 개발에 일조한 몬티 와이드니우스(Monty Widenius)에 의해 운영되고 있다는 점이다. MariaDB야 말로 진정한 제왕일까? 아니면 MySQL일까?

우리는 본래 해당 데이터베이스를 구축한 조직이 운영하는 중앙의 코드를 고수해야 할까? 아니면 분명 더 똑똑하고 때로는 편리하기까지 한 저항 세력에 합류해야 할까? 그리고 호환성에 대한 메시지를 어떻게 풀어내야 할까?

한편으로 MariaDB와 MySQL의 상호 호환성이 상당하다. 그러나 다른 한편으로 차이가 있다고 생각해야 한다. 왜 모두가 논쟁을 벌여야 할까? 아마도 이것들이 성능의 범위에 속하며 우리의 쿼리가 양쪽에서 동일하게 동작하기 때문은 아닐까? 하지만 그렇지 않을 수도 있고, 앞으로 그러지 않을 수도 있다.

스토리지 엔진 혼돈
MySQL은 사실 하나가 아닌 여러 개의 데이터베이스다. 이들은 대부분의 자세한 사항을 가리고 있는 하나의 표면 아래에 숨어 있다. 초창기에는 빠르지만 일관성에 따로 신경쓰지 않은 엔진이었던 MyISAM이 있었다. 때로는 속도가 필요하고 일관적이지 못한 결과도 큰 문제가 없었기 때문에 괜찮았다.

그러나 사람들이 더 많은 것을 원하자 완전한 트랜잭션(Transaction) 지원을 갖춘 InnoDB가 등장했다. 하지만 그걸로는 부족했다. 현재 20개 이상의 스토리지 엔진 옵션이 존재하기 때문에 DBA들이 큰 혼란을 겪고 있다.

물론, SQL을 다시 작성하지 않고도 엔진 사이에서 전환할 수 있을 때도 있다. 그러나 나중에 반드시 혼란이 발생할 수 밖에 없다. 그 테이블에 MyISAM 또는 InnoDB를 선택했었나? 아니면 대신에 CSV 형식으로 데이터를 작성하기로 했었나?

수익 동기
오픈소스 제품으로써 성공을 거둔 MySQL이지만 이는 여전히 상용 시장을 노리는 전문 개발자들이 활동하는 비즈니스 영역이다. 대부분의 사용자들이 오픈소스 라이선스의 좋은 기능을 활용할 수 있지만 기업을 지속적으로 운영하기 위해서는 분명 수입이 있어야 한다. 이로 인해 "커뮤니티 에디션"으로 배포된 무료 코드와 기업에 판매된 완전한 제품 사이에 이상한 긴장감이 존재한다.

돈을 지불해야 할까? 그 만한 값어치가 있을까? 커뮤니티 에디션으로 사업을 하면 잘못된 것일까? 기업 에디션의 추가 기능은 단지 영원히 비용을 지불하도록 유도하기 위한 속임수인 것은 아닐까? 또 이런 질문에 대한 답도 얻어야 할 것이다. 어떤 에디션을? 어떤 라이선스를? 어떤 기능을?

네이티브 JSON 지원 부재
MySQL을 직접 설치해 보면 제대로 사용하기 위해서 더 많은 드라이버를 추가해야 한다. 일반적으로 MySQL은 포트 3306을 이용해 통신하며 불가해한 자체 형식으로 데이터를 뱉어낸다. 자신의 코드가 호환되도록 하려면 반드시 MySQL의 언어를 다른 유용한 것으로 변환하는 또 다른 코드 계층을 추가해야 한다. 라이브러리로 분산되어 있는 이런 코드 계층 때문에 사람들은 종종 상용 라이선스를 구매하곤 한다.

일반적으로 현대의 데이터 스토리지 계층은 JSON을 직접 사용한다. MySQL와 MariaDB가 현재 SQL의 일환으로 JSON을 분석할 수 있기는 하지만 CouchDB, MongoDB 등의 최신 툴에서 볼 수 있는 네이티브 JSON 인터페이스와는 차이가 있다.

클로즈드 소스 주변 모듈의 등장
MySQL이 오픈소스지만 "오픈 코어"를 중심으로 개발된 새로운 클로즈드 소스 비전매 특허 모듈은 예외다. 프로그래머들도 먹어야 산다. 이것이 기업의 현실인 것이다. MySQL을 사용하는 병원이 무료로 치료를 제공하는 것과는 다르다. MySQL을 사용하는 농부가 무료로 음식을 제공하는 것과는 다르다.

MySQL의 기준을 높게 유지하는 것이 다소 불공평하긴 하지만 오픈소스 성공이 함정이 될 수 있다. 무료로 시작했다고 해서 그 상태를 반드시 유지할 수 있는 것은 아니다. 기업들이 많은 새로운 기능을 원한다면 어쨌든 비용을 지불해야 한다. 때로는 자체적으로 코드를 작성하는 것보다 오라클에 비용을 지불하는 것이 저렴하다. 때로는 상용 클로즈드 소스 코드를 사용해야 한다. 단, 이에 대한 검증이 반드시 필요할 것이다.

* Peter Wayner는 인포월드 정기 기고가이자 16권을 서적을 집필한 저술가다. 주로 다루는 영역은 오픈소스, 자동화 자동차, 프라이버시, 디지털 트랜잭션 등이다. ciokr@idg.co.kr