모두 다 지원하겠다는 DBMS 강자들

한 2년 전만 해도 응용프로그램 요구사항에 따라 RDBMS와 NoSQL을 병용하는 게 비용효율적이라고 제언했습니다. 물론 인사가 만사라 각 DB를 두루 잘 쓰는 사람이 조직에 있어야 가능합니다. 요즘 들어서는 이렇게 얘기하지 않는 편입니다. 어지간히 여력 있고 규모 있는 조직이 아니면 두루 잘할 사람을 구하거나 키우기가 어려웠고, 무엇보다 각 DB들이 너무나 막강해졌기 때문입니다.

이제는 유명무실해지는 CAP 이론

 

빅데이터와 NoSQL 열풍이 불면서 CAP 이론 도해를 발표자료 서두에 넣어 이야기를 풀어 나가던 시절이 있었습니다. Consistency(일관성), Availability(가용성), Partition tolerance(파티션 허용) 세 가지를 한꺼번에 충족하는 솔루션은 없고 용도에 따라 두 가지만 충족하는 솔루션을 선택해야 한다는 취지였습니다. 그런 식으로 RDBMS는 CA를 지원하고, 몽고DB는 CP를 지원한다고 분류했습니다. 자세한 사항은 IBM 자료(https://www.ibm.com/kr-ko/topics/cap-theorem)를 참조하시길 바랍니다.

2024년 기준으로 이 구도는 깨졌습니다만, 완전히 뒤집어지지는 않았습니다. 태생을 거스르지는 못하므로 몽고DB가 금융업계에서 요구하는 수준으로 ACID를 구현하기는 힘들고, Oracle DB가 서버 노드를 여러 개 두면서 스케일아웃을 지원하지는 않습니다. 단, DBA 입장에서는 이제까지 다루던 DBMS로 여러 개발자의 갖가지 니즈를 충족해줄 수 있게 되었습니다.

전통적으로 막강한 RDBMS와 신흥 강자 DB 홈페이지에서 검색해 보세요. 트랜잭션(ACID, 거래처리), 문서(JSON), 시계열 DB, Graph DB에 이어 최근에 각광받는 생성형 AI로 지식 검색, 문답을 개발할 때에 필수적인 Vector DB까지 몽땅 지원합니다. 제가 써 본 Oracle, MS SQL Server, MySQL, PostgreSQL, SAP HANA, MongoDB 모두 이렇습니다. 10년 전에는 상상도 못할 일입니다. 저 제품들 모두 MPP(Massively Parallel Processing 대량 병렬 처리)에 준하는 기술로 data warehouse 혹은 data lakehouse에 준하는 뭔가를 구현할 방법도 갖추었습니다. 기존 고객을 뺏기지 않겠다는 신념에 그저 감탄했습니다.

어떻게 보면 치킨게임같기도 한 경쟁 구도입니다. IT 업계가 꾸준히 성장하지 못했다면 벌써 두어 개는 망하지 않았을까 합니다. 퍼블릭 클라우드가 변수로 작용하는 가운데, 앞으로 어떤 변화가 더 밀어닥칠까요? 한시가 급한 개발 조직 입장에서는 기술 트렌드에 흔들리지 말고 쓰던 제품을 쓰는 역량을 더욱 키우는 게 당장은 유익하지 않을까 합니다. 작은 조직, 작은 기업일수록 개발자가 치는 사고를 수습할 DBA를 서너 명씩 두기는 힘들겠지요? 일단은 익숙한 제품을 쓰던 대로만이 아니라 속속들이 숙지하여 아주 잘 쓰는 게 리스크를 줄이고 불가피하게 밀려오는 개발자 충격에 넉넉히 대응하는 길이겠습니다.