DBMS는 RDB와 NoSQL만 있나요?

엘키About 2 min

DBMS는 RDB와 NoSQL만 있나요? 관련

관계형 데이터베이스는 오랜 시간 데이터 관리의 중심에 자리 잡고 있었습니다. 그러나 인터넷과 모바일의 급격한 성장으로 대규모 비정형 데이터를 다루어야 하는 상황이 늘어났습니다. 그와 함께 RDB의 한계가 드러나기 시작했습니다. 이에 대응하여 등장한 것이 바로 NoSQL입니다. 다만 NoSQL이라는 이름으로 묶여 있는 다양한 데이터베이스는 그저 RDB의 대안이 아닙니다. 이번 글에서는 NoSQL이라는 단순한 분류를 넘어, 세분화된 데이터베이스 관리 시스템의 세계를 탐구해 보고자 합니다. 또, 이토록 다양한 DBMS를 적절히 사용하기 위해 고려할 내용 역시 살펴보겠습니다.

관계형 데이터베이스(이하 RDB)는 오랜 시간 데이터 관리의 중심에 자리 잡고 있었습니다. 특히 강력한 데이터 무결성과 ACID 트랜잭션은 기업 애플리케이션의 표준으로 삼기에 적합했죠. 그러나 인터넷과 모바일의 급격한 성장으로 대규모 비정형 데이터를 다루어야 하는 상황이 늘어났습니다. 그와 함께 RDB의 한계가 드러나기 시작했습니다. 웹 애플리케이션의 급속한 확장, 실시간 데이터 처리의 필요성, 그리고 비정형 데이터의 관리 요구가 커지며 데이터 처리 성능에서 분명한 한계를 보였죠.

이에 대응하여 등장한 것이 바로 NoSQL입니다. 다만 NoSQL이라는 이름으로 묶여 있는 다양한 데이터베이스는 그저 RDB의 대안이 아닙니다. 각기 다른 특성과 사용 사례를 가진 독립적인 데이터베이스 관리 시스템이라고 봐야 하죠. 이들 시스템은 빅데이터와 비정형 데이터를 처리하기에 적합한 유연성과 확장성을 제공합니다.

이번 글에서는 NoSQL이라는 단순한 분류를 넘어, 세분화된 데이터베이스 관리 시스템(이하 DBMS)의 세계를 탐구해 보고자 합니다. 또, 이토록 다양한 DBMS를 적절히 사용하기 위해 고려할 내용 역시 살펴보겠습니다.

성장하는 스타트업 A와 5가지 DBMS

여기 DBMS 적용이 필요한 스타트업 A가 있습니다. 이 스타트업은 소셜 네트워크 애플리케이션을 개발하고 있는데요, 기업이 성장하며 데이터의 양과 복잡도가 점점 커지고 있습니다. 스타트업 A의 성장을 따라가며 다양한 DBMS의 특징과 이를 언제 어떻게 활용할지 보겠습니다.

본격적으로 들어가기 전, 오해할 분들이 혹시 있을까 말하자면 스타트업 A의 사례는 가상입니다. 여기 나온 DBMS의 도입 순서는 해당 기술의 우수성이나 난이도와 무관합니다.

초기 개발 단계: 키-값 DB(Key-Value DB)

A 스타트업의 초기 제품은 복잡하지 않은 사용자 프로필과 친구 관계를 저장하는 간단한 구조를 가지고 있습니다. 이 단계에서 A 스타트업의 개발자들은 **키-값 DB(Key-Value DB)**를 선택합니다. Redis, Aerospike와 같은 DBMS가 대표적이죠. 이 DB는 매우 단순한 구조를 가지고 있지만, 빠른 데이터 접근을 필요로 하는 상황에서 놀라운 성능을 발휘할 수 있습니다.

특히 키-값 DB는 빠른 속도와 간단한 구조 덕분에 사용자 세션 데이터나 캐시를 관리하는 데 적합합니다. 그래서 개발자들은 사용자가 애플리케이션에 로그인할 때마다 필요한 데이터를 빠르게 불러오고, 최근에 조회한 프로필을 캐싱하도록 Redis를 사용했습니다. 이러한 단순한 데이터 모델은 빠른 프로토타이핑과 초기 서비스 출시를 가능하게 했습니다.

유연한 성장: 도큐먼트 DB(Document DB)

제품은 시장의 호응을 얻으며 성장해 나갑니다. 사용자 프로필은 더 복잡해졌고, 사용자 생성 콘텐츠와 다양한 메타데이터를 저장할 필요도 생겼습니다. 이제 A 스타트업의 개발자들은 유연한 스키마를 제공하는 MongoDB, 즉 **도큐먼트 DB(Document DB)**로 시스템을 전환합니다.

도큐먼트 데이터베이스는 JSON과 유사한 구조의 문서를 저장하여 데이터를 구조화하는 데 유연성을 제공합니다. 그 덕분에 빠른 개발 속도와 스키마 변경의 자유로움을 가져왔습니다. 예를 들어, 사용자 프로필에 새로운 필드를 추가하거나 기존 필드가 바뀌어도, 도큐먼트 데이터베이스는 이러한 변화를 쉽게 반영할 수 있습니다. 또한, 복잡한 쿼리를 빠르게 실행할 수 있다는 장점도 가집니다. 그 덕에 사용자의 활동 내역 조회, 게시물 검색 기능 등을 손쉽게 구현할 수 있습니다.

이를 기반으로 A 스타트업은 빠르게 새로운 기능을 추가하고 변화하는 요구사항에 대응할 수 있었습니다. 제품의 빠른 실험과 성장에 적합했죠.

데이터가 복잡해질 때: 그래프 DB(Graph DB)

제품을 쓰는 사용자가 늘어나며 친구 관계와 같은 데이터의 복잡성이 증가했습니다. 이제 단순히 문서 기반 접근 방식만으로는 관계를 효율적으로 관리하기 어려워졌죠. 그래서 다시 A 스타트업의 개발자들은 Neo4j, EdgeDB와 같은 그래프 DB를 도입하기로 결정합니다.

그래프 DB는 노드와 엣지 구조를 사용해 관계를 직관적으로 저장하고 탐색할 수 있게 해줍니다. 그래서 특히 소셜 네트워크와 같은 관계 중심의 데이터를 처리하는 데 뛰어납니다. 예를 들어, 친구 추천 시스템이나 사용자 간의 상호작용 패턴 분석 등 복잡한 관계를 탐색하고 분석하는 작업에 적합합니다. 이 작업에서는 RDB보다 월등히 뛰어난 능력을 보여 주죠.

이번 그래프 DB 도입으로 A 스타트업은 복잡한 친구 추천 알고리즘과 소셜 네트워크 분석을 효과적으로 구현할 수 있었습니다. 이는 곧 사용자의 참여도를 높이고 더 나은 사용자 경험을 제공하는 데 중요한 역할을 했습니다.

대규모 분산 처리: 분산 DB(Distributed DB)

A 스타트업의 다음 과제는 글로벌 진출입니다. 이제 서비스가 글로벌로 나아가면서 자연스레 지연 시간과 가용성이 중요한 요소로 떠올랐습니다. 그래서 개발팀은 여러 지역에 걸쳐 데이터를 분산하여 저장할 수 있는 Spanner, CockroachDB와 같은 **분산 DB(Distributed DB)**를 도입하기로 합니다.

분산 DB는 데이터를 여러 서버에 걸쳐 저장하기에 시스템의 확장성과 가용성을 높입니다. 그 때문에 사용자가 전 세계 어디에서 접속해도 빠른 응답 시간을 제공할 수 있습니다. 서버 장애 시에도 데이터에 접근할 수 있으니 서비스의 연속성을 보장할 수 있습니다. 특히 CockroachDB는 글로벌 트랜잭션과 고가용성을 지원합니다. 데이터가 여러 지역에 분산되어 있더라도 일관성을 유지할 수 있다는 뜻입니다.

이제 A 스타트업은 전 세계 사용자에게 더 빠르고 안정적인 서비스를 제공할 수 있습니다. 글로벌 시장에서도 경쟁력을 유지할 수 있었죠.

시계열 데이터 분석: 메트릭 DB(Metric DB)

지금까지 이룬 것에 멈추지 않고 더 나은 제품을 만들기 위해, A 스타트업은 사용자의 활동 데이터를 실시간으로 모니터링하며 분석하고자 시계열 데이터를 다루기 시작했습니다. 그와 함께 개발자들은 InfluxDB, KairosDB와 같은 **메트릭 DB(Metric DB)**를 활용하기 시작합니다.

메트릭 DB는 시간에 따라 변화하는 데이터를 효율적으로 저장하고 분석하는 데 특화되어 있습니다. 특히 높은 쓰기 성능과 쿼리 효율성을 제공하여, 대량의 시계열 데이터를 효과적으로 관리할 수 있었습니다. 따라서 실시간 데이터 모니터링과 분석에 매우 적합했죠. 곧 사용자 활동 로그나 성능 모니터링 데이터를 수집하여 실시간으로 분석한 다음, 서비스의 성능을 최적화하거나 문제가 발생할 경우 빠르게 대응할 수 있었습니다.

DBMS를 선택할 때는 무엇을 생각해야 할까?

이처럼 DBMS는 상황에 따른 애플리케이션의 성능과 안정성에 큰 영향을 미치는 중요한 구성 요소입니다. 따라서 이를 선택할 때는 여러 가지 요소를 함께 비교하며 신중하게 고려해야 합니다. 앞서 다룬 DBMS의 종류별 특징을 기반으로 DBMS를 고를 때 고려해야 할 사항을 알아보겠습니다.

DBMS 선택을 위한 6가지 고려 사항

제가 다룰 6가지 내용이 DBMS를 선택할 때 모든 상황에 고려해야 할 포인트는 아닐 수 있습니다. 그래도 도입 전에 한 번쯤은 확인할 체크리스트로 봐주시면 좋겠습니다.

데이터의 구조: 정형 데이터 vs. 비정형 데이터

RDB는 정형화된 데이터, 즉 스키마가 명확한 데이터를 관리하는 데 강점을 가집니다. 반면, 이미지, 비디오, JSON 문서 등 비정형 데이터를 다룰 때는 도큐먼트 DB나 NoSQL이 더 유연합니다. 따라서 데이터가 명확한 구조를 가지는지, 아니면 다양한 형태로 들어오는지에 따라 선택이 달라집니다.

확장성: 수직 확장 vs. 수평 확장

RDB는 서버의 성능을 향상하는 수직 확장에 적합합니다. NoSQL 데이터베이스는 분산 시스템으로 노드를 추가하는 수평 확장에 강점을 가집니다. 한편 애플리케이션이 확장성을 필요로 하는 경우, 대규모 트래픽을 처리할 수 있는 분산 DB가 유리하죠.

성능 요구 사항: 읽기 vs. 쓰기

DBMS에 따라 읽기 또는 쓰기 성능 역시 차이 납니다. 예를 들어, Cassandra와 같은 일부 분산 데이터베이스는 쓰기 성능이 우수한 반면, Redis는 읽기 성능이 뛰어난 메모리 기반 데이터베이스입니다. 기업의 애플리케이션이 주로 읽기 성능을 요구하는지, 아니면 쓰기 성능이 중요한지 역시 DBMS 선택의 핵심이 될 수 있습니다.

일관성 및 가용성 요구: CAP 이론

모든 DBMS는 CAP 이론을 따릅니다. 일관성(Consistency), 가용성(Availability), 네트워크 분할 허용(Partition Tolerance) 중 두 가지를 선택할 수밖에 없다는 뜻이죠. 모든 클라이언트가 동일한 데이터를 볼 수 있어야 한다면 일관성이 중요합니다. 반면 서비스가 연속성을 가지는 것이 무엇보다 중요하면 가용성이 핵심이 되겠죠. 이를테면 금융 시스템에서는 일관성이 중요하지만, 소셜 네트워크에서는 가용성이 더 중요할 수 있습니다. 이에 따라 적합한 DBMS를 선택해야 합니다.

트랜잭션 관리: ACID vs BASE

RDB는 ACID를 보장하는 트랜잭션 처리를 제공합니다. ACID는 데이터베이스 트랜잭션의 속성을 나타내며, 원자성(Atomicity), 일관성(Consistency), 고립성(Isolation), 지속성(Durability)을 보장하여 데이터의 신뢰성을 유지한다는 뜻입니다. 반면 일부 NoSQL 데이터베이스는 유연한 트랜잭션 처리를 위해 BASE 모델을 따릅니다. BASE는 분산 시스템에서 사용되는 개념인데요, “Basically Available, Soft state, Eventually consistent”의 약자로, 데이터의 일관성보다 가용성과 성능을 우선시하는 특성을 가지고 있습니다. 이런 특징으로 복잡한 트랜잭션 처리가 필요한 경우, RDB가 더 적합합니다.

개발 및 운영 복잡성

각 DBMS는 서로 다른 고유 설정, 유지보수 및 운영의 복잡성을 가지고 있습니다. 그런 만큼 새로운 DBMS를 도입할 경우, 팀의 기술 역량 역시 중요한 고려 사항이 됩니다. 또, DBMS를 학습하고 유지하는 데 들어갈 비용과 시간도 함께 평가해야 합니다.

여러 DBMS를 한 번에 사용해도 괜찮을까?

다만 모든 애플리케이션이 오직 한 가지 특징만 지니는 것은 아닙니다. 그에 따라 한 가지 DBMS로 모든 요구사항을 충족시키는 것이 어려울 수 있죠. 이럴 때는 여러 DBMS를 조합하여 사용하는 것도 선택지가 됩니다.

DBMS를 함께 사용할 때 우려

그러나 이처럼 DBMS의 조합을 선택하기에는 몇 가지 우려가 따릅니다.

운영 및 유지 보수 복잡성

여러 DBMS를 도입하면 각 시스템을 독립적으로 운영하고 유지보수해야 합니다. 인프라 관리의 복잡성이 올라가겠죠. 또 각각 DBMS에 대한 모니터링, 백업, 성능 최적화 작업이 추가로 필요합니다. DBMS 특성에 맞는 전문적인 운영을 해야 하는 팀의 부담 역시 커질 수 있습니다.

데이터 일관성 문제

여러 DBMS에서 데이터를 다루다 보면 일관성을 유지하는 것이 더더욱 어려워집니다. 서로 다른 시스템 간에 데이터를 복제하거나 동기화할 때 지연이 발생할 수도 있죠. 특히 실시간 처리가 필요한 애플리케이션에서는 이러한 문제가 심각하게 작용할 수 있습니다.

통합의 어려움

DBMS는 고유한 쿼리 언어와 접근 방식을 가지고 있습니다. 여러 DBMS를 사용하다 보면 자연스레 통합적인 데이터 처리 로직을 구성하는 것이 복잡해질 수 있습니다. 예를 들어, RDB에서는 SQL을 사용하고, 도큐먼트 DB에서는 JSON 기반의 쿼리 문법을 사용합니다. 두 DBMS에서 쿼리 및 처리 로직을 관리하려면 추가적인 비용이 발생할 것입니다.

데이터 분할 및 중복

여러 DBMS를 사용하다 보면 데이터가 서로 다른 시스템에 분산될 수 있습니다. 이런 현상은 곧 데이터의 중복 저장 문제로 이어지기도 합니다. 아무래도 데이터가 여러 곳에 분산되면 데이터 일관성을 유지하기 어려운 데다 중복 데이터를 관리하기 위한 추가 작업이 필요해집니다.

그럼에도 DBMS의 조합이 유리할 때

이런 우려 사항에도 특정 상황에서는 DBMS를 조합해 쓰는 것이 유리할 수 있습니다. 그런 상황을 몇 가지 정리해 봤습니다.

서로 다른 데이터 유형을 처리할 때

어떤 애플리케이션은 정형 데이터와 비정형 데이터를 모두 처리해야 합니다. 이때는 여러 DBMS를 사용하는 것이 합리적이기도 합니다. 이를테면 사용자 정보와 같은 정형 데이터는 MySQL 등 RDB에 저장하고, 사용자 활동 로그나 이미지, 동영상 같은 비정형 데이터는 NoSQL이나 오브젝트 스토리지(Object Storage)에 저장하는 방식이죠. 이렇게 구성하면 각각 데이터 유형에 맞는 DBMS의 장점을 극대화할 수 있습니다.

서로 다른 성능 요구 사항이 있을 때

성능에 대한 요구 사항은 어떤 기능을 쓰는지에 따라 달라집니다. 예를 들어, 사용자 로그인 세션과 같은 고속 캐시가 필요한 경우 Redis를, 대규모 데이터 분석이 필요한 경우 Hadoop이나 Spark 같은 빅데이터 솔루션을 사용할 수 있습니다. 이처럼 여러 DBMS를 결합해 각각의 성능 요구 사항에 맞춘 데이터 저장 및 처리 방식을 적용하면, 시스템 전체의 성능을 최적화할 수 있습니다.

확장성 및 가용성 문제를 해결할 때

글로벌 규모로 확장되거나, 고가용성이 중요한 시기도 여러 DBMS를 조합하여 사용하는 것이 유리할 때입니다. 글로벌 확장성과 분산 처리가 중요한 경우에는 Cassandra나 CockroachDB와 같은 분산 DB를 사용할 수 있죠. 그와 함께 실시간 데이터 처리를 위해 Redis를 캐시 시스템으로 사용할 수도 있습니다. 지리적 분산과 고가용성을 동시에 만족시키면서도 특정 기능에서 빠른 응답성을 유지하는 방법 중 하나입니다.

복잡한 관계 데이터를 처리할 때

그래프 DB는 그래프 기반의 데이터를 처리해야 하는 애플리케이션에 매우 유리합니다. 특히 소셜 네트워크 서비스에서는 사용자 간의 관계, 친구 추천, 관계 중심의 탐색이 중요해 그래프 DB를 쓰는 것이 훨씬 효율적입니다. 여기에 사용자 프로필이나 게시물 데이터는 도큐먼트 DB에 저장하고, 이를 그래프 DB와 함께 사용하는 방식도 있죠. 이처럼 서로 다른 DBMS를 결합할 수 있습니다.

마치며

이처럼 DBMS는 RDB와 NoSQL이 전부가 아닙니다. 여러 가지 요구와 환경에 맞는 세분화된 유형의 시스템을 포함하고 있죠.

이토록 다양한 DBMS는 특정한 문제를 해결하기 위해 고안되었습니다. 애플리케이션 모두는 각자의 문제를 가지고 있으니까요. 따라서 데이터베이스를 선택할 때는 여러 옵션을 검토하고 우리 애플리케이션에 맞는 최적의 시스템을 선택하는 것이 중요합니다. 마치 스타트업 A처럼 서비스의 성장과 변화에 따라 적합한 DBMS를 유연하게 도입해 데이터 관리의 효율성을 극대화할 수 있죠.

그런 만큼 DBMS가 제공하는 특성과 장점을 이해하고 활용하는 것이 데이터 아키텍처 설계의 핵심입니다. 기업의 비즈니스와 구성원에 맞는 합리적인 결정에 이 글이 도움이 되면 좋겠습니다.

DBMS는 RDB와 NoSQL만 있나요?