Booil Jung

NoSQL

데이터베이스 기술의 역사는 데이터 관리 패러다임의 진화 과정 그 자체라 할 수 있다. 수십 년간 이 영역의 절대적 표준으로 군림해 온 관계형 데이터베이스 관리 시스템(RDBMS)은 데이터의 정형화와 무결성을 통해 정보 시스템의 신뢰성을 담보하는 견고한 기반을 제공했다. 그러나 21세기에 들어서면서 데이터의 양, 속도, 다양성이 전례 없는 수준으로 폭증함에 따라, 기존 RDBMS가 지닌 구조적 한계는 점차 명확해졌다. 본 서론에서는 NoSQL이라는 새로운 패러다임이 태동하게 된 역사적, 기술적 필연성을 RDBMS의 유산과 그 한계를 통해 조명하고, ‘Not Only SQL’이라는 용어에 담긴 철학적 의미를 탐구함으로써 앞으로 전개될 논의의 서막을 연다.

1970년대에 이르러 데이터베이스 기술은 중요한 전환점을 맞이했다. 이전의 계층형 및 네트워크형 데이터 모델은 데이터의 논리적 구조와 물리적 저장 방식이 강하게 결합되어 있어, 데이터베이스 구조의 작은 변경이 애플리케이션 코드의 대대적인 수정을 유발하는 문제를 안고 있었다.1 이러한 한계를 극복하기 위해 등장한 관계형 모델은 데이터를 행(Row)과 열(Column)으로 구성된 단순한 2차원 테이블의 집합으로 표현함으로써, 데이터의 논리적 구성과 물리적 저장 구조를 성공적으로 분리했다.1

이러한 구조적 혁신과 더불어, 관계형 모델의 성공을 이끈 두 가지 핵심 기둥은 바로 SQL(Structured Query Language)과 ACID 트랜잭션이었다. SQL은 데이터베이스와 상호작용하기 위한 표준화된 언어로서, 개발자들이 데이터 저장 방식의 복잡성에서 벗어나 데이터 자체에 집중할 수 있게 했다.1 한편, ACID 트랜잭션은 데이터베이스 연산의 신뢰성을 보장하는 네 가지 핵심 속성, 즉 원자성(Atomicity), 일관성(Consistency), 고립성(Isolation), 지속성(Durability)을 정의한다.3 이 ACID 원칙은 금융 거래와 같이 데이터의 정확성과 무결성이 무엇보다 중요한 시스템에서 RDBMS를 대체 불가능한 선택지로 만들었다.

데이터의 일관성을 유지하기 위한 또 다른 핵심 전략은 정규화(Normalization)였다. 정규화는 데이터의 중복을 최소화하기 위해 테이블을 논리적으로 분해하는 과정으로, 이를 통해 데이터 저장 공간을 효율적으로 사용하고 데이터 변경 시 발생할 수 있는 이상 현상(Anomaly)을 방지했다.6 이처럼 RDBMS는 SQL, ACID, 정규화라는 강력한 도구를 통해 지난 수십 년간 데이터 관리의 황금 표준으로 자리매김했다.

21세기 초, 웹 2.0의 등장과 함께 데이터 환경은 근본적인 변화를 맞이했다. Facebook, Twitter와 같은 소셜 미디어 서비스, 사물 인터넷(IoT) 센서, 모바일 애플리케이션 등에서 생성되는 데이터는 그 양이 기하급수적으로 증가했을 뿐만 아니라, 텍스트, 이미지, 동영상, 로그 파일 등 그 형태 또한 기존의 정형 데이터를 압도하는 비정형(Unstructured) 및 반정형(Semi-structured) 데이터가 주를 이루게 되었다.3

이러한 데이터 환경의 변화는 RDBMS의 구조적 한계를 드러내는 계기가 되었다. RDBMS의 가장 큰 특징인 엄격한 스키마는 데이터의 일관성을 보장하는 장점이었지만, 데이터 구조가 수시로 변경되는 애자일(Agile) 개발 환경에서는 오히려 빠른 개발과 배포를 저해하는 족쇄로 작용했다.1 또한, 정규화를 통해 잘게 쪼개진 테이블들은 데이터를 조회할 때마다 복잡한 조인(Join) 연산을 요구했는데, 이는 페타바이트(PB)급의 대규모 데이터셋에서는 감당하기 어려운 성능 저하를 유발했다.1

무엇보다 현대적인 웹 애플리케이션은 전 세계 수백만 명의 동시 접속자를 처리하면서도 밀리초(ms) 단위의 낮은 지연 시간을 유지해야 하는 ‘웹 스케일(Web-Scale)’ 요구사항에 직면했다.1 RDBMS는 주로 단일 서버의 성능을 높이는 수직적 확장(Scale-Up)에 의존했는데, 이는 고사양 서버의 막대한 비용 문제와 함께 확장성 자체의 물리적 한계에 부딪혔다.2 대규모 읽기/쓰기, 빠른 응답 시간, 상시 가동을 위한 높은 가용성 등 새로운 시대의 요구사항 앞에서 RDBMS만으로는 더 이상 충분하지 않다는 인식이 확산되기 시작했다.

이러한 기술적 배경 속에서 2009년, Last.fm의 Johan Oskarsson이 오픈 소스 분산 데이터베이스 관련 모임을 조직하며 ‘NoSQL’이라는 용어를 처음 사용했다.13 이 용어는 단순히 기술적 분류를 넘어, 수십 년간 데이터베이스 시장을 독점해 온 RDBMS 패러다임에 대한 일종의 반발 정신을 담고 있었다.15

초기에는 ‘No SQL’ 즉, SQL을 사용하지 않는 데이터베이스로 오해되기도 했으나, 현재는 ‘Not Only SQL’로 해석하는 것이 일반적이다.17 이는 SQL이나 관계형 모델을 완전히 부정하고 대체하려는 것이 아니라, 데이터 저장 및 관리 문제에 있어 SQL 외에도 다양한 해결책이 존재하며, 문제의 특성에 맞는 최적의 도구를 선택해야 한다는 실용주의적 철학을 내포한다.9

이러한 철학적 전환은 NoSQL이 단순히 RDBMS의 성능 문제를 해결하기 위한 기술적 대안을 넘어, 데이터를 바라보고 관리하는 근본적인 관점의 변화, 즉 패러다임의 전환임을 시사한다. RDBMS가 데이터를 ‘관계’와 ‘정형화된 스키마’라는 엄격한 틀 안에서 중앙집중적으로 통제하려는 ‘통제 중심’ 패러다임이었다면, NoSQL은 ‘스키마 유연성’과 ‘분산’을 통해 데이터 관리의 자율성을 애플리케이션 개발자에게 부여하고 다양한 데이터 모델을 허용하는 ‘자율성과 다양성 중심’ 패러다임이라 할 수 있다. 이 패러다임은 단일 데이터베이스가 모든 문제를 해결할 수 없다는 인식 아래, 애플리케이션의 각 기능에 최적화된 여러 데이터 저장소를 조합하여 사용하는 ‘폴리글랏 영속성(Polyglot Persistence)’이라는 현대적인 아키텍처 사상으로 발전하게 되었다.6

NoSQL 데이터베이스는 단일 기술이 아닌, 공통된 철학을 공유하는 다양한 기술들의 집합체다. 그 본질을 이해하기 위해서는 전통적인 RDBMS와 근본적으로 어떤 차이가 있는지 비교 분석하는 것이 효과적이다. 이 장에서는 NoSQL을 정의하는 세 가지 핵심 원리인 데이터 모델, 스키마 유연성, 그리고 확장성 패러다임을 RDBMS와 비교하여 심층적으로 분석하고, 이러한 차이가 어떻게 NoSQL의 고유한 특성을 형성하는지 탐구한다.

데이터를 어떻게 구조화하고 저장하는가 하는 데이터 모델의 차이는 RDBMS와 NoSQL을 가르는 가장 근본적인 분기점이다.

• RDBMS의 정형 모델: RDBMS는 모든 데이터를 행(Row)과 열(Column)으로 구성된 2차원 테이블 형태로 저장한다.20 데이터 간의 논리적 관계는 기본 키(Primary Key)와 외래 키(Foreign Key)를 통해 명확하게 정의되며, 조인(Join) 연산을 통해 여러 테이블에 분산된 관련 데이터를 결합하여 조회한다.6 이 모델은 데이터 구조가 명확하고 일관성이 중요한 정형 데이터(Structured Data)를 다루는 데 매우 효율적이다.
• NoSQL의 다형적 모델: 반면, NoSQL은 고정된 테이블 구조에서 벗어나 다양한 데이터 모델을 제공한다.6 이는 현대 애플리케이션이 다루는 비정형(Unstructured) 및 반정형(Semi-structured) 데이터를 변환 과정 없이 자연스러운 형태로 저장할 수 있게 한다.9 주요 모델은 다음과 같다.
  • 키-값(Key-Value): 고유한 키에 값을 매핑하는 가장 단순한 모델.22
  • 문서(Document): JSON이나 BSON과 같이 계층적 구조를 가진 문서를 값으로 저장.22
  • 컬럼 패밀리(Column-Family): 행이 아닌 열을 기준으로 데이터를 그룹화하여 저장.22
  • 그래프(Graph): 데이터와 그 관계를 노드(Node)와 엣지(Edge)로 표현.22

이러한 데이터 모델의 유연성은 개발 생산성에도 직접적인 영향을 미친다. 많은 NoSQL 데이터베이스, 특히 문서 모델은 데이터를 애플리케이션 코드에서 사용하는 객체(Object)와 매우 유사한 형태로 저장한다. 이로 인해 RDBMS 환경에서 흔히 발생하는 ‘객체-관계 임피던스 불일치(Object-Relational Impedance Mismatch)’ 문제를 완화하고, 복잡한 객체-관계 매핑(ORM) 계층의 필요성을 줄여준다.6

데이터 구조의 정의, 즉 스키마(Schema)를 언제, 어떻게 적용하는지에 대한 접근 방식은 두 패러다임 간의 또 다른 핵심적인 차이를 만든다.

• Schema-on-Write (RDBMS): RDBMS는 ‘쓰기 시 스키마 적용(Schema-on-Write)’ 방식을 따른다. 이는 데이터를 데이터베이스에 저장하기 전(on-write), 사전에 엄격하게 정의된 테이블 스키마(데이터 타입, 제약 조건 등)에 부합하는지 검증하는 것을 의미한다.23 이 방식은 데이터베이스 수준에서 데이터의 일관성과 무결성을 강력하게 보장하는 장점이 있다. 하지만, 일단 정의된 스키마를 변경하는 작업(예:

  ALTER TABLE)은 매우 복잡하고 비용이 많이 들며, 서비스 중단을 유발할 수도 있다.1

• Schema-on-Read (NoSQL): 대부분의 NoSQL 데이터베이스는 ‘읽기 시 스키마 적용(Schema-on-Read)’ 방식을 채택한다.26 데이터를 저장할 때는 스키마 검증 없이 유연하게 받아들이고(Schema-less), 데이터를 읽어가는 애플리케이션이 데이터의 구조를 해석하고 활용한다.1 이러한 동적 스키마(Dynamic Schema)는 데이터 구조가 미리 정해지지 않았거나, 비즈니스 요구사항에 따라 빈번하게 변경될 수 있는 현대적 애플리케이션 개발 환경에 매우 적합하다.20 개발자는 스키마 변경에 대한 부담 없이 새로운 필드를 동적으로 추가할 수 있어, 빠른 프로토타이핑과 반복적인 개발이 가능한 애자일(Agile) 방법론과 잘 부합한다.22

이러한 차이는 데이터 관리에 대한 책임 소재의 변화를 의미하기도 한다. RDBMS에서는 데이터베이스가 데이터 무결성에 대한 상당 부분의 책임을 지지만, NoSQL에서는 그 책임이 애플리케이션 개발자에게로 상당 부분 이전된다. 즉, NoSQL의 유연성은 개발자에게 더 큰 자율성을 부여하는 동시에, 애플리케이션 레벨에서 데이터의 일관성과 유효성을 검증해야 하는 새로운 과제를 안겨준다.29 이는 기술 선택 시 반드시 고려해야 할 중요한 트레이드오프다.

데이터와 사용자 트래픽이 증가함에 따라 시스템의 처리 용량을 늘리는 확장(Scaling) 방식에서도 두 패러다임은 뚜렷한 차이를 보인다.

• 수직 확장 (Scale-Up, RDBMS): RDBMS는 전통적으로 수직 확장 방식을 선호한다. 이는 기존 서버 한 대의 하드웨어 사양, 즉 CPU, RAM, 저장 장치 등을 더 고성능으로 교체하여 처리 능력을 향상시키는 것을 의미한다.30 이 방식은 아키텍처 변경 없이 비교적 간단하게 성능을 높일 수 있지만, 고사양 하드웨어의 비용이 기하급수적으로 증가하며, 단일 서버가 가질 수 있는 성능에는 물리적인 한계가 존재한다.2
• 수평 확장 (Scale-Out, NoSQL): NoSQL 데이터베이스는 설계 초기부터 분산 환경을 염두에 두고 개발되었으며, 수평 확장 방식을 기본으로 채택한다.1 이는 고가의 단일 서버에 의존하는 대신, 상대적으로 저렴한 범용 서버 여러 대를 클러스터로 연결하여 전체 시스템의 처리 용량을 늘리는 방식이다.31 필요에 따라 클러스터에 서버를 추가하기만 하면 되므로, 이론적으로 거의 무한한 확장이 가능하며 비용 효율적이다.1 또한, 여러 서버에 데이터가 분산 및 복제되어 있어 일부 서버에 장애가 발생하더라도 서비스 중단 없이 운영이 가능한 고가용성(High Availability)을 확보하는 데 유리하다.1

NoSQL의 수평 확장은 주로 샤딩(Sharding)이라는 기술을 통해 구현된다. 샤딩은 대규모 데이터셋을 여러 개의 작은 조각(샤드)으로 나누어 각기 다른 서버에 분산 저장하는 기법이다.35 RDBMS 환경에서도 샤딩을 구현할 수는 있지만, 테이블 간의 관계와 트랜잭션의 ACID 속성을 유지하면서 데이터를 분산시키는 것은 매우 복잡하고 어려운 작업이다.35 반면, 관계(Join)가 없고 데이터 모델이 유연한 NoSQL은 샤딩을 훨씬 자연스럽고 효율적으로 적용할 수 있다.

다음 표는 RDBMS와 NoSQL의 핵심적인 특징을 요약하여 비교한 것이다.

표 1: RDBMS와 NoSQL의 핵심 특징 비교

특징	RDBMS (관계형 데이터베이스)	NoSQL (비관계형 데이터베이스)
데이터 모델	정형 데이터 (테이블, 행, 열)	비정형/반정형 데이터 (키-값, 문서, 컬럼, 그래프 등)
스키마	엄격함 (Schema-on-Write)	유연함 (Schema-on-Read)
확장성	수직 확장 (Scale-Up) 중심	수평 확장 (Scale-Out) 중심
트랜잭션	ACID (강한 일관성)	BASE (결과적 일관성, 가용성 중심)
데이터 관계	조인(Join)을 통한 관계 표현	비정규화, 임베딩을 통한 데이터 중복 허용
쿼리 언어	표준 SQL	DB별 다양한 쿼리 언어 또는 API (MQL, CQL 등)

결론적으로, NoSQL의 핵심 혁신은 데이터 모델의 다형성, 스키마의 유연성, 그리고 수평적 확장성에 있으며, 이는 RDBMS가 지배하던 시대에는 상상하기 어려웠던 대규모의 동적인 데이터를 처리할 수 있는 새로운 가능성을 열었다. 그러나 이러한 유연성과 성능은 데이터베이스의 책임을 애플리케이션으로 옮겨온 대가이며, 이는 NoSQL 시스템을 설계하고 운영하는 데 있어 새로운 고려사항을 제시한다.

NoSQL 데이터베이스는 대부분 분산 시스템을 기반으로 한다. 따라서 NoSQL의 동작 원리를 깊이 있게 이해하기 위해서는 분산 시스템을 지배하는 핵심 이론들을 먼저 살펴보아야 한다. 이 장에서는 RDBMS의 근간을 이루는 ACID 모델과 대척점에 있는 BASE 철학을 소개하고, 분산 시스템 설계의 근본적인 트레이드오프를 설명하는 CAP 정리를 분석한다. 나아가 CAP 정리의 한계를 보완하고 현대 분산 시스템의 복잡성을 더 잘 설명하는 PACELC 정리까지 탐구함으로써 NoSQL 기술의 이론적 토대를 공고히 한다.

데이터베이스 트랜잭션 모델은 데이터의 변경 사항을 어떻게 안정적으로 처리할 것인가에 대한 철학을 담고 있다. RDBMS와 NoSQL은 이 지점에서 근본적으로 다른 길을 선택했다.

• ACID 모델: 전통적인 RDBMS는 ACID 모델을 통해 데이터의 정확성과 신뢰성을 최우선 가치로 삼는다.3

  • 원자성 (Atomicity): 트랜잭션에 포함된 모든 작업이 전부 성공하거나 전부 실패해야 한다.4

  • 일관성 (Consistency): 트랜잭션이 성공적으로 완료되면 데이터베이스는 항상 일관된 상태를 유지해야 한다.4

  • 고립성 (Isolation): 동시에 실행되는 여러 트랜잭션은 서로에게 영향을 미치지 않아야 한다.4

  • 지속성 (Durability): 일단 성공적으로 커밋된 트랜잭션은 시스템 장애가 발생하더라도 영구적으로 보존되어야 한다.4

    이 ACID 속성은 분산 환경에서 모든 노드에 걸쳐 보장하기가 매우 어렵고 큰 비용을 수반하기 때문에, NoSQL 시스템들은 종종 이 모델을 완화하는 선택을 한다.

• BASE 모델: 많은 NoSQL 시스템, 특히 가용성을 중시하는 시스템들은 BASE 철학을 따른다. 이는 강력한 일관성을 일부 희생하는 대신, 높은 가용성과 성능을 확보하려는 실용적인 접근 방식이다.4

  • 기본적 가용성 (Basically Available): 시스템의 일부에 장애가 발생하더라도, 시스템의 나머지 부분은 계속해서 사용 가능해야 한다.4
  • 유연한 상태 (Soft State): 데이터의 상태는 외부의 개입 없이도 시간이 지남에 따라 변경될 수 있다. 이는 데이터가 모든 노드에 전파되는 과정에서 일시적으로 비일관적인 상태에 있을 수 있음을 의미한다.38
  • 결과적 일관성 (Eventual Consistency): 시스템에 새로운 쓰기 작업이 유입되지 않는다면, 시간이 흐름에 따라 결국 모든 데이터 복제본이 동일한 값으로 수렴하게 된다는 모델이다.38 즉, 데이터의 일관성이 즉각적으로 보장되지는 않지만, 최종적으로는 일관된 상태에 도달함을 보장한다. 이 모델은 소셜 미디어의 ‘좋아요’ 수나 최신 게시물 피드처럼, 약간의 데이터 지연이 사용자 경험에 치명적이지 않은 서비스에 매우 적합하다.40

2000년, 컴퓨터 과학자 Eric Brewer는 분산 시스템 설계에 있어 근본적인 제약을 설명하는 CAP 정리를 제시했다.41 이 정리는 어떤 분산 데이터 저장소도 다음 세 가지 속성 중 최대 두 가지만을 동시에 만족시킬 수 있다는 것을 골자로 한다.3

• 일관성 (Consistency): 모든 클라이언트는 분산 시스템 내의 어떤 노드에 접속하더라도 항상 동일한, 가장 최근에 쓰여진 데이터를 보아야 한다.41
• 가용성 (Availability): 시스템 내 일부 노드에 장애가 발생하더라도, 모든 클라이언트의 요청은 항상 성공적인 응답(에러가 아닌)을 받아야 한다.41
• 분할 허용성 (Partition Tolerance): 노드 간의 네트워크 통신이 끊어지는 ‘네트워크 분할’이 발생하더라도 시스템은 전체적으로 계속 동작해야 한다.41

현실의 분산 시스템에서 네트워크 장애는 언제든 발생할 수 있는 피할 수 없는 문제다. 따라서 분할 허용성(P)은 선택이 아닌 필수적인 속성으로 간주된다.42 결국, CAP 정리는 네트워크 분할이 발생했을 때 시스템 설계자가 일관성(C)과 가용성(A) 사이에서 불가피한 선택을 해야 한다는 것을 의미한다.

• CP (Consistency / Partition Tolerance): 가용성을 일부 희생하여 일관성을 선택하는 시스템. 네트워크 분할이 감지되면, 데이터 불일치를 유발할 수 있는 노드(예: 최신 데이터를 받지 못한 노드)는 요청 처리를 중단하고 오류를 반환할 수 있다. 이를 통해 시스템 전체의 데이터 정합성을 유지한다. 금융 시스템이나 재고 관리처럼 데이터의 정확성이 무엇보다 중요한 경우에 적합하다. MongoDB, HBase 등이 이 분류에 속하는 대표적인 NoSQL 데이터베이스다.41
• AP (Availability / Partition Tolerance): 일관성을 일부 희생하여 가용성을 선택하는 시스템. 네트워크 분할 상황에서도 모든 노드는 어떻게든 응답을 하려고 시도한다. 이 과정에서 일부 노드는 오래된(stale) 데이터를 반환할 수 있다. 이러한 시스템은 앞서 설명한 ‘결과적 일관성’ 모델을 따른다. 서비스가 중단 없이 계속 제공되는 것이 중요한 경우에 적합하다. Apache Cassandra, Amazon DynamoDB, CouchDB 등이 대표적이다.41
• CA (Consistency / Availability): 분할 허용성을 포기하는 시스템. 이는 네트워크 분할을 허용하지 않으므로, 사실상 분산 시스템이 아닌 단일 노드 시스템을 의미한다. 전통적인 단일 서버 RDBMS가 이 범주에 해당한다.41

CAP 정리는 분산 시스템의 트레이드오프를 이해하는 데 강력한 프레임워크를 제공하지만, 한계 또한 명확하다. 이 정리는 오직 네트워크 분할이라는 ‘장애 상황’에서의 선택만을 다룰 뿐, 대부분의 시간 동안 시스템이 동작하는 ‘정상 상황’에서의 트레이드오프는 설명하지 못한다.45

이러한 한계를 보완하기 위해 Daniel Abadi는 PACELC 정리를 제안했다. 이 정리는 CAP의 논리를 확장하여 다음과 같이 설명한다: 만약 Partition(분할)이 발생하면, 시스템은 Availability(가용성)와 Consistency(일관성) 사이에서 선택해야 한다. 하지만 그 외(Else)의 정상 상황에서는, Latency(지연시간)와 Consistency(일관성) 사이에서 선택해야 한다.51

• ELC (Latency vs. Consistency) 트레이드오프:
  • EC (Consistency 우선): 정상 상황에서도 강력한 일관성을 유지하기 위해, 쓰기 요청이 들어왔을 때 모든 (또는 과반수의) 복제본에 데이터가 동기식(synchronous)으로 복제될 때까지 기다린 후 클라이언트에게 성공을 응답한다. 이 방식은 데이터의 일관성을 보장하지만, 복제에 걸리는 시간만큼 쓰기 지연시간(write latency)이 증가한다.53
  • EL (Latency 우선): 정상 상황에서 낮은 지연시간을 확보하기 위해, 쓰기 요청을 받은 노드가 일단 데이터를 기록한 후, 다른 복제본에는 비동기식(asynchronous)으로 데이터를 전파한다. 클라이언트는 즉시 응답을 받으므로 지연시간은 매우 낮지만, 잠시 동안 노드 간 데이터 불일치가 발생할 수 있다 (결과적 일관성).53

이러한 이론적 프레임워크들은 NoSQL 시스템을 선택하고 설계할 때 중요한 지침을 제공한다. 다음 표는 ACID와 BASE, 그리고 PACELC 정리에 따른 데이터베이스 시스템의 특성을 요약한 것이다.

표 2: ACID와 BASE 속성 비교

속성	ACID	BASE
목표	데이터 정확성, 신뢰성	확장성, 가용성
일관성	강한 일관성 (Strong Consistency)	결과적 일관성 (Eventual Consistency)
가용성	일관성을 위해 희생될 수 있음	최우선으로 보장 (Basically Available)
상태	항상 일관된 상태	일시적으로 비일관적 상태 허용 (Soft State)
주 적용 분야	RDBMS (금융, 재고 관리 등)	NoSQL (소셜 미디어, 빅데이터 분석 등)

표 3: PACELC 정리에 따른 데이터베이스 시스템 분류

	Else: Latency 선호 (EL)	Else: Consistency 선호 (EC)
Partition: Availability 선호 (PA)	PA/EL (가용성/지연시간 우선) - Amazon DynamoDB - Apache Cassandra	PA/EC (장애 시 가용성, 평시 일관성 우선) - MongoDB
Partition: Consistency 선호 (PC)	PC/EL (장애 시 일관성, 평시 지연시간 우선) - 이론적 조합, 드묾	PC/EC (항상 일관성 우선) - CockroachDB (NewSQL) - VoltDB (NewSQL) - RDBMS

중요한 점은, CAP이나 PACELC가 시스템을 ‘CP 또는 AP’와 같이 이분법적으로 규정하는 것이 아니라는 것이다. 실제 시스템들은 완벽한 CP나 AP가 아니며, 이 두 극단 사이의 스펙트럼 어딘가에 위치한다.45 예를 들어, Cassandra는 요청마다 일관성 수준을 조절할 수 있는 ‘튜닝 가능한 일관성(tunable consistency)’을 제공하여, 개발자가 특정 요구사항에 맞춰 일관성과 가용성/지연시간의 균형을 동적으로 선택할 수 있게 한다. 따라서 이 이론들은 데이터베이스를 특정 상자에 가두는 분류법이 아니라, 분산 시스템 설계 시 고려해야 할 다차원적인 ‘트레이드오프 공간(trade-off space)’을 이해하는 유용한 프레임워크로 활용해야 한다.

NoSQL은 단일한 데이터 모델을 강요하지 않고, 문제의 특성에 따라 최적의 구조를 선택할 수 있는 ‘다형성(Polymorphism)’을 제공한다. 이는 NoSQL의 가장 큰 강점 중 하나로, 데이터를 보다 자연스럽고 효율적으로 표현할 수 있게 한다. 이 장에서는 NoSQL을 구성하는 네 가지 주요 데이터 모델-키-값 스토어, 문서 스토어, 컬럼 패밀리 스토어, 그래프 데이터베이스-의 구조, 특징, 장단점 및 대표적인 시스템을 심층적으로 분석한다. 각 모델이 어떤 유형의 문제 해결에 최적화되어 있는지 구체적인 사용 사례를 통해 살펴본다.

• 구조 및 특징:

  키-값 스토어는 모든 NoSQL 모델 중 가장 단순한 구조를 가진다. 이는 고유한 식별자인 ‘키(Key)’와 그에 해당하는 ‘값(Value)’을 하나의 쌍으로 저장하는 방식이다.17 프로그래밍 언어의 해시 테이블(Hash Table)이나 딕셔너리(Dictionary) 자료구조와 매우 유사하다.55 이 모델의 핵심 철학은 단순성이다. 복잡한 기능 대신,

  get(key), put(key, value), delete(key)와 같은 기본적인 연산에 집중하여 극도로 빠른 성능을 구현한다.54 값(Value)은 단순한 문자열이나 숫자부터 복잡한 객체, 심지어 이미지 파일까지 어떤 형태의 데이터든 제약 없이 저장할 수 있어 높은 유연성을 제공한다.54 이러한 단순한 구조는 수평 확장을 매우 용이하게 하여, 다른 유형의 NoSQL 데이터베이스가 따라오기 힘든 수준의 확장성을 가능하게 한다.6

• 장단점 및 사용 사례:

  최대 장점은 단연 속도다. 단순한 조회 연산에 최적화되어 있으며, 많은 시스템이 데이터를 디스크가 아닌 주 메모리(In-memory)에 저장하여 응답 시간을 밀리초 이하로 단축시킨다.12 반면, 명확한 단점도 존재한다. 값의 내용을 기반으로 데이터를 검색하거나 필터링하는 기능이 거의 없으며, 여러 키에 걸친 복잡한 쿼리나 조인 연산은 지원하지 않는다.54

  이러한 특성으로 인해 키-값 스토어는 주로 다음과 같은 용도에 사용된다.

  • 캐싱(Caching): RDBMS와 같은 주 데이터베이스의 부하를 줄이기 위해 자주 접근하는 데이터를 임시로 저장하는 캐시 서버로 널리 활용된다.57
  • 세션 관리(Session Management): 웹 애플리케이션에서 사용자의 로그인 상태나 장바구니 정보와 같은 세션 데이터를 빠르게 저장하고 조회하는 데 이상적이다.58
  • 실시간 순위표(Real-time Leaderboards): 게임이나 소셜 앱에서 사용자의 점수나 순위를 실시간으로 집계하고 보여주는 데 효과적이다.58

• 대표 시스템:

  • Redis: 가장 대표적인 인메모리 키-값 스토어. 단순한 키-값 외에도 리스트(List), 셋(Set), 해시(Hash), 정렬된 셋(Sorted Set) 등 다양한 데이터 구조를 값으로 지원하여 활용 범위를 크게 넓혔다.57 빠른 성능을 바탕으로 캐싱, 세션 저장소뿐만 아니라 메시지 큐, 실시간 분석 등 다목적으로 사용된다.57
  • Amazon DynamoDB: AWS에서 제공하는 완전 관리형 키-값 및 문서 데이터베이스. 어떤 규모에서도 일관된 10밀리초 미만의 지연 시간을 보장하며, 서버리스 아키텍처를 통해 트래픽에 따라 자동으로 확장된다.6 대규모 전자상거래, 게임, IoT 플랫폼의 백엔드로 널리 채택되고 있다.64

• 구조 및 특징:

  문서 스토어는 키-값 모델을 자연스럽게 확장한 형태다. 키에 대응하는 값을 JSON(JavaScript Object Notation)이나 BSON(Binary JSON)과 같은 반정형 문서(Document) 형태로 저장한다.11 문서는 필드(Field)와 값(Value)의 쌍으로 구성되며, 값으로는 다른 문서나 배열을 포함할 수 있어 계층적인 데이터 구조를 표현하는 데 매우 용이하다.22

  문서 스토어의 가장 큰 특징은 스키마 유연성(Schema Flexibility)이다. 같은 컬렉션(RDBMS의 테이블에 해당) 내의 문서들이 서로 다른 구조나 필드를 가질 수 있다.15 이는 개발 과정에서 데이터 요구사항이 변경되더라도 데이터베이스 스키마 수정 없이 새로운 필드를 쉽게 추가할 수 있음을 의미한다.67 또한, 문서 내의 특정 필드를 기준으로 데이터를 조회하고 인덱스를 생성할 수 있어, 단순 키 조회만 가능한 키-값 스토어보다 훨씬 강력하고 정교한 쿼리 기능을 제공한다.28

• 장단점 및 사용 사례:

  애플리케이션에서 사용하는 객체 모델과 데이터베이스의 문서 모델이 거의 일치하기 때문에, 개발이 직관적이고 생산성이 높다는 장점이 있다.11 하지만 유연성이 지나치면 데이터 구조에 대한 일관성이 부족해질 수 있으며, 여러 문서에 걸친 트랜잭션 처리가 RDBMS보다 복잡하다. 데이터 중복이 발생하기 쉬운 구조이기도 하다.

  이러한 특성으로 인해 문서 스토어는 범용 데이터베이스로서 다양한 분야에서 활용된다.

  • 콘텐츠 관리 시스템(CMS): 블로그 게시물, 기사 등 각기 다른 속성을 가진 콘텐츠를 유연하게 저장하는 데 적합하다.66
  • 사용자 프로필 관리: 사용자에 따라 선택적으로 저장되는 정보(예: 추가 연락처, 취미 등)가 많은 프로필 데이터를 효과적으로 관리할 수 있다.
  • 전자상거래 제품 카탈로그: 의류, 전자제품 등 상품 유형에 따라 속성이 천차만별인 제품 정보를 단일 컬렉션 내에서 효율적으로 저장하고 검색할 수 있다.28

• 대표 시스템:

  • MongoDB: 문서 데이터베이스 분야에서 가장 압도적인 인지도와 사용률을 자랑한다.69 풍부한 쿼리 언어(MQL)와 강력한 인덱싱 기능, 그리고 복잡한 데이터 분석을 위한 집계 파이프라인(Aggregation Pipeline)을 제공하여 단순한 데이터 저장을 넘어 데이터 처리 플랫폼으로서의 역할을 수행한다.22

• 구조 및 특징:

  컬럼 패밀리 스토어는 구글의 Bigtable 논문에서 유래한 모델로, 데이터를 바라보는 관점을 행(Row)에서 열(Column)로 전환했다.71 데이터는 행 키(Row Key), 컬럼 패밀리(Column Family), 컬럼 키(Column Key), 그리고 타임스탬프(Timestamp)라는 4차원적인 구조로 구성된다.72 핵심은 관련된 컬럼들을 ‘컬럼 패밀리’라는 단위로 묶어 물리적으로 함께 저장하는 것이다. RDBMS가 행 전체를 하나의 단위로 저장하는 것과 달리, 이 모델은 각 컬럼 패밀리별로 데이터를 저장하므로 특정 컬럼 데이터만 읽어오는 작업에 매우 효율적이다. 또한, 각 행은 서로 다른 컬럼을 가질 수 있어, 특정 행에만 값이 존재하는 희소 데이터(sparse data)를 저장하는 데 공간 효율성이 뛰어나다.

• 장단점 및 사용 사례:

  이 모델의 가장 큰 장점은 대규모 데이터에 대한 쓰기 처리량(write throughput)과 수평 확장성이다.29 분산 환경에 최적화되어 있어 수백, 수천 대의 서버로 클러스터를 확장하며 페타바이트급 데이터를 처리할 수 있다. 반면, RDBMS처럼 복잡한 조인이나 집계 쿼리를 수행하기는 어렵고, 데이터 모델링 방식이 독특하여 학습 곡선이 높은 편이다.73

  주로 다음과 같은 쓰기 중심(write-heavy)의 대규모 데이터 처리 시스템에 사용된다.

  • 시계열 데이터(Time-series Data): IoT 센서 데이터, 주식 시세 데이터 등 시간의 흐름에 따라 대량으로 발생하는 데이터를 저장하고 분석하는 데 적합하다.74
  • 로그 분석(Log Analytics): 웹 서버나 애플리케이션에서 생성되는 방대한 양의 로그 데이터를 실시간으로 수집하고 처리하는 데 사용된다.
  • 메시징 시스템: 대규모 메시징 서비스의 메시지 보관소로 활용된다.75

• 대표 시스템:

  • Apache Cassandra: Facebook에서 개발한 분산 데이터베이스로, 마스터 노드가 없는 P2P(Peer-to-Peer) 아키텍처를 채택하여 단일 장애점(SPOF)이 없고 뛰어난 가용성과 내결함성을 제공한다.73 여러 데이터 센터에 걸쳐 데이터를 복제하는 기능이 강력하여 지리적으로 분산된 글로벌 서비스에 널리 사용된다.29
  • HBase: Apache Hadoop의 HDFS(Hadoop Distributed File System) 위에서 동작하도록 설계되었다.71 Hadoop 생태계의 MapReduce, Hive 등과 긴밀하게 통합되어, 대규모 데이터의 실시간 랜덤 읽기/쓰기와 배치(batch) 분석을 동시에 지원하는 데 강점이 있다.77

• 구조 및 특징:

  그래프 데이터베이스는 데이터와 데이터 간의 ‘관계’를 가장 직접적이고 효율적으로 표현하기 위해 설계된 모델이다. 데이터는 ‘노드(Node)’ 또는 ‘정점(Vertex)’으로 표현되고, 노드 간의 연결은 ‘엣지(Edge)’ 또는 ‘관계(Relationship)’로 표현된다.22 노드와 엣지 모두 키-값 쌍 형태의 속성(Property)을 가질 수 있다. 이 모델은 세상의 많은 데이터가 본질적으로 서로 연결되어 있다는 점에 착안하여, 관계 자체를 데이터 모델의 최우선 요소(first-class citizen)로 다룬다.

• 장단점 및 사용 사례:

  가장 큰 장점은 관계 탐색의 성능이다. RDBMS에서 수많은 테이블을 조인해야 하는 복잡한 관계 쿼리(예: ‘내 친구의 친구들이 좋아하는 영화 찾기’)를 매우 빠른 속도로 처리할 수 있다.11 스키마가 유연하여 새로운 유형의 데이터나 관계를 기존 구조에 영향을 주지 않고 쉽게 추가할 수 있다는 점도 강점이다.79 반면, 전체 데이터셋에 대한 집계 연산이나 특정 속성값으로 대량의 노드를 찾는 작업은 다른 모델에 비해 비효율적일 수 있다.

  데이터 간의 연결성이 중요한 다음과 같은 분야에서 독보적인 성능을 발휘한다.

  • 소셜 네트워크: 친구 관계, 팔로우, 그룹 멤버십 등 복잡한 사회적 연결망을 분석하는 데 최적화되어 있다.79
  • 추천 엔진: ‘나와 비슷한 구매 패턴을 가진 다른 사용자들이 구매한 상품’과 같은 추천 로직을 구현하는 데 매우 효과적이다.80
  • 사기 탐지 시스템(FDS): 여러 계정, 주소, IP가 비정상적인 패턴으로 연결되어 있는지를 신속하게 탐지하여 금융 사기 등을 방지한다.80
  • 지식 그래프(Knowledge Graph): 다양한 개체와 그들 간의 의미적 관계를 연결하여 지식 기반 시스템을 구축하는 데 사용된다.

• 대표 시스템:

  • Neo4j: 가장 널리 사용되는 그래프 데이터베이스로, Cypher라는 직관적이고 선언적인 그래프 쿼리 언어를 제공한다.79
  • Amazon Neptune: AWS에서 제공하는 완전 관리형 그래프 데이터베이스 서비스로, 대규모 그래프 데이터를 쉽게 구축하고 운영할 수 있게 지원한다.22

다음 표는 네 가지 주요 NoSQL 데이터 모델의 핵심 특징을 요약하여 비교한 것이다.

표 4: NoSQL 데이터 모델 유형별 특징 및 대표 시스템

데이터 모델	구조	장점	단점	주요 사용 사례	대표 시스템
키-값 스토어	(Key, Value) 쌍	단순, 빠른 속도, 높은 확장성	복잡한 쿼리 불가, 값 검색 어려움	캐싱, 세션 관리, 실시간 순위표	Redis, DynamoDB
문서 스토어	(Key, Document) 쌍, JSON/BSON	유연한 스키마, 풍부한 쿼리, 직관적 개발	데이터 중복 가능성, 대규모 트랜잭션 복잡	콘텐츠 관리, 사용자 프로필, 제품 카탈로그	MongoDB, Couchbase
컬럼 패밀리 스토어	(Row Key, Column Family, Column, Timestamp)	대규모 쓰기 성능, 높은 확장성, 희소 데이터 효율적	복잡한 쿼리 및 집계 어려움, 높은 학습 곡선	시계열 데이터, 로그 분석, IoT 데이터	Cassandra, HBase
그래프 데이터베이스	(Node, Edge, Property)	복잡한 관계 모델링, 빠른 관계 탐색	특정 사용 사례에 한정, 대규모 집계 연산 비효율	소셜 네트워크, 추천 엔진, 사기 탐지	Neo4j, Amazon Neptune

결론적으로, NoSQL 데이터 모델의 선택은 저장하려는 ‘데이터의 구조’ 자체보다, 애플리케이션이 해당 데이터를 ‘어떻게 접근하고 활용할 것인가(Access Pattern)’에 의해 결정되어야 한다. RDBMS가 데이터의 논리적 구조를 정규화하여 모델링하는 ‘데이터 중심’ 접근 방식을 취한다면, NoSQL은 애플리케이션의 쿼리 패턴에 최적화된 구조를 설계하는 ‘애플리케이션 중심’ 접근 방식을 요구한다.85 예를 들어, Cassandra의 데이터 모델링은 “쿼리를 먼저 설계하고, 그 쿼리에 맞는 테이블을 만들라”는 원칙을 따를 정도로 접근 패턴을 중시한다. 이는 NoSQL로의 기술 전환이 단순히 데이터베이스를 교체하는 것을 넘어, 데이터 모델링에 대한 철학적 전환을 필요로 함을 시사한다.

NoSQL 데이터베이스의 성능과 확장성을 최대한 활용하기 위해서는 그 특성에 맞는 데이터 모델링 전략이 필수적이다. RDBMS의 정규화(Normalization)가 데이터의 중복을 최소화하고 일관성을 유지하는 데 초점을 맞추었다면, NoSQL의 모델링은 애플리케이션의 읽기 성능을 극대화하는 데 주안점을 둔다. 이 장에서는 NoSQL 모델링의 핵심 전략인 비정규화(Denormalization)의 개념과 그에 따른 트레이드오프를 분석하고, 특히 문서 데이터베이스에서 데이터 관계를 표현하는 주요 패턴인 임베딩(Embedding)과 참조(Referencing)를 구체적인 예시를 통해 심층 비교한다.

• 정의 및 목적:

  비정규화는 데이터베이스의 읽기 성능을 향상시키기 위해 의도적으로 데이터 중복을 허용하는 최적화 기법이다.7 RDBMS 환경에서도 성능 튜닝을 위해 제한적으로 사용되지만, 조인(Join) 연산이 없거나 비효율적인 NoSQL 환경에서는 핵심적인 데이터 모델링 전략으로 자리 잡았다.3 NoSQL에서 비정규화의 주된 목적은 여러 번의 데이터베이스 조회를 통해 가져와야 할 관련 데이터를 하나의 레코드(문서 등)에 미리 통합하여, 단 한 번의 읽기 작업으로 필요한 모든 정보를 가져오기 위함이다.89

• 장점:

  비정규화의 가장 큰 이점은 쿼리 성능의 획기적인 향상이다.87 RDBMS에서 여러 테이블을 조인하는 데 드는 비용은 데이터가 많아질수록 커지지만, 비정규화된 모델에서는 이러한 비용이 원천적으로 제거된다. 이로 인해 애플리케이션은 더 빠르고 일관된 응답 시간을 사용자에게 제공할 수 있다. 또한, 데이터를 가져오는 쿼리 로직 자체가 단순해져 개발 및 유지보수가 용이해지는 효과도 있다.89

• 단점과 트레이드오프:

  이러한 성능상의 이점은 몇 가지 중요한 트레이드오프를 수반한다.

  1. 데이터 중복과 저장 공간: 가장 명백한 단점은 데이터 중복이다. 동일한 정보가 여러 문서에 걸쳐 반복적으로 저장되므로, 전체적인 데이터 저장 공간이 증가하게 된다.7
  2. 데이터 일관성 문제 (Update Anomaly): 비정규화의 가장 큰 도전 과제는 데이터 일관성 유지다. 만약 중복 저장된 데이터(예: 사용자 이름)가 변경될 경우, 해당 데이터가 포함된 모든 문서를 찾아서 일관되게 업데이트해야 한다.11 이 과정에서 일부 문서의 업데이트가 누락되거나 실패하면, 시스템 내에 동일한 개체에 대한 서로 다른 정보가 공존하는 데이터 불일치 상태가 발생한다.35

• 결론:

  따라서 비정규화 전략은 데이터의 변경(쓰기) 빈도보다 조회(읽기) 빈도가 압도적으로 높은 ‘읽기 중심(read-heavy)’ 워크로드에 가장 적합하다.20 데이터 업데이트가 빈번하게 발생하는 시스템에서는 일관성을 유지하기 위한 추가적인 로직(예: 관련된 모든 문서를 트랜잭션으로 묶어 업데이트)이 애플리케이션 레벨에서 구현되어야 하며, 이는 개발 복잡성을 증가시킬 수 있다.

문서 데이터베이스(예: MongoDB)에서 데이터 간의 관계를 모델링하는 방식은 크게 임베딩과 참조, 두 가지로 나뉜다. 이 둘은 각각 비정규화와 정규화에 해당하는 접근법으로, 애플리케이션의 데이터 접근 패턴에 따라 신중하게 선택해야 한다.

• 임베딩 (Embedding / Denormalization):

  임베딩은 관련된 데이터를 부모 문서 내에 하위 문서(sub-document)나 배열(array) 형태로 직접 포함시키는 방식이다.91 예를 들어, 하나의 블로그 게시물(post) 문서 안에 여러 개의 댓글(comment) 객체를 배열로 포함시키는 것이 대표적인 임베딩 모델이다.

  • 장점: 임베딩된 데이터는 부모 문서와 함께 단 한 번의 읽기 작업으로 조회할 수 있어 읽기 성능이 매우 뛰어나다.91 또한, 단일 문서 내에서의 모든 변경 작업은 원자적(atomic)으로 처리되므로, 게시물과 댓글 데이터를 한 번에 업데이트할 때 데이터 일관성을 쉽게 보장할 수 있다.91
  • 적합한 관계: 데이터 간의 관계가 명확한 ‘포함(contains)’ 관계이거나, ‘일대일(One-to-One)’, 그리고 자식 데이터의 개수가 제한적인 ‘일대소수(One-to-Few)’ 관계에 이상적이다.92 자식 데이터가 부모 데이터의 맥락 안에서만 주로 사용되고 독립적으로 조회되는 경우가 거의 없을 때 효과적이다.
  • 한계: 임베딩된 배열이 무한정 커질 수 있는 ‘일대다수(One-to-Many)’ 관계에서는 문제가 될 수 있다. MongoDB는 단일 문서의 최대 크기를 16MB로 제한하고 있어, 이 한계를 초과할 위험이 있다.91 또한, 임베딩된 데이터 일부만 자주 변경되는 경우, 전체 문서를 다시 써야 하므로 쓰기 성능이 비효율적일 수 있다.

• 참조 (Referencing / Normalization):

  참조는 RDBMS의 외래 키(Foreign Key)와 유사하게, 한 문서에서 다른 문서의 고유 ID(예: _id)를 저장하여 관계를 연결하는 방식이다.91 예를 들어, 주문(order) 문서에 해당 주문을 한 사용자(user)의

  user_id를 저장하고, 실제 사용자 정보는 별도의 users 컬렉션에 저장하는 방식이다.

  • 장점: 데이터 중복을 피할 수 있어 저장 공간이 효율적이고, 데이터 일관성을 유지하기 용이하다. 사용자 이름이 변경될 경우, users 컬렉션의 해당 문서 하나만 수정하면 된다.91 각 문서는 비교적 작은 크기를 유지하므로 문서 크기 제한 문제에서 자유롭다.
  • 적합한 관계: 자식 데이터의 수가 매우 많거나 예측 불가능한 ‘일대다수(One-to-Many)’ 관계나, 복잡한 ‘다대다(Many-to-Many)’ 관계에 적합하다.91 또한, 참조되는 데이터(예: 사용자 정보)가 여러 다른 데이터(주문, 게시물, 댓글 등)에서 공통으로 사용되거나 독립적으로 자주 조회될 때 유리하다.
  • 단점: 관련된 데이터를 함께 조회하려면 애플리케이션에서 여러 번의 쿼리가 필요하다. 예를 들어 주문 정보와 주문자 정보를 함께 보려면, 먼저 orders 컬렉션에서 주문을 조회한 후, 거기서 얻은 user_id를 가지고 다시 users 컬렉션을 조회해야 한다. 이는 RDBMS의 조인을 애플리케이션 레벨에서 수동으로 구현하는 것과 같아, 읽기 성능 저하와 네트워크 오버헤드를 유발할 수 있다.91

• 하이브리드 접근법 (Hybrid Approach):

  실제 애플리케이션에서는 임베딩과 참조를 혼합하여 사용하는 하이브리드 접근법이 자주 사용된다. 이는 각 패턴의 장점을 취하고 단점을 보완하기 위함이다. 예를 들어, 전자상거래 사이트의 제품(product) 문서 모델링을 생각해보자.

  • 제품의 이름, 가격, 설명 등 핵심 정보는 제품 문서에 저장한다.

  • 사용자에게 즉시 보여줄 필요가 있는 ‘최신 리뷰 5개’는 성능을 위해 제품 문서 내에 직접 임베딩한다.95

  • 과거의 모든 리뷰 목록은 별도의 reviews 컬렉션에 저장하고, 제품 문서에는 전체 리뷰 수를 나타내는 필드와 reviews 컬렉션을 가리키는 참조 ID만 유지한다.96

    이러한 하이브리드 모델은 빠른 읽기 성능(임베딩)과 데이터 관리의 효율성(참조) 사이에서 최적의 균형을 찾으려는 시도다.

결론적으로, NoSQL 데이터 모델링의 성패는 애플리케이션이 데이터를 어떻게 사용하고 조회할 것인지, 즉 ‘쿼리 패턴(Query Pattern)’을 얼마나 정확하게 예측하고 그에 맞게 구조를 설계하는가에 달려있다.86 RDBMS처럼 데이터의 논리적 관계를 우선하여 정규화된 모델을 만든 뒤 쿼리를 작성하는 것이 아니라, 가장 빈번하고 중요한 쿼리가 무엇인지를 먼저 정의하고, 해당 쿼리가 가장 효율적으로 실행될 수 있도록 데이터 구조(임베딩, 참조, 비정규화)를 결정해야 한다.

이러한 접근 방식은 NoSQL 데이터 모델링이 프로젝트 초기에 한 번에 완성되는 정적인 ‘설계(Design)’가 아니라, 애플리케이션의 발전과 사용자 행동의 변화에 따라 지속적으로 성능을 측정하고 구조를 개선해 나가는 동적인 ‘튜닝(Tuning)’ 과정에 가깝다는 것을 의미한다.68 이는 개발팀에게 단순히 데이터베이스를 사용하는 능력을 넘어, 데이터 아키텍처를 지속적으로 관리하고 진화시킬 수 있는 역량을 요구하는 중요한 변화다.

앞서 논의한 이론적 기반과 데이터 모델링 전략이 실제 NoSQL 시스템에서 어떻게 구체적으로 구현되어 성능과 확장성을 달성하는지 살펴보는 것은 매우 중요하다. 이 장에서는 시장에서 널리 사용되는 주요 NoSQL 시스템들의 핵심 아키텍처와 기능을 심층적으로 분석한다. 문서 데이터베이스의 강자인 MongoDB의 데이터 처리 엔진인 ‘집계 파이프라인’, 분산 쓰기 성능에 최적화된 Cassandra의 데이터 분산 및 정렬 메커니즘, 그리고 SQL과 NoSQL의 장점을 결합하려는 NewSQL의 대표주자 CockroachDB의 아키텍처를 통해 이론이 실제 기술로 구현되는 과정을 탐구한다.

MongoDB는 유연한 문서 모델뿐만 아니라, 저장된 데이터를 강력하게 처리하고 분석할 수 있는 ‘집계 파이프라인(Aggregation Pipeline)’ 기능을 제공한다. 이는 RDBMS의 복잡한 SQL 쿼리와 유사한 작업을 데이터베이스 서버 내에서 효율적으로 수행할 수 있게 해주는 핵심 기능이다.

• 개념 및 구조:

  집계 파이프라인은 다수의 문서를 입력으로 받아 여러 단계(Stage)를 거치면서 문서를 순차적으로 처리하고 변환하여 최종 결과를 출력하는 데이터 처리 프레임워크다.98 각 단계는 이전 단계의 출력 문서를 입력으로 받아 특정 작업을 수행한 후, 그 결과를 다음 단계로 전달하는 파이프라인 형태로 구성된다.98 이 구조는 복잡한 데이터 변환 로직을 여러 개의 단순한 단계로 나누어 명확하고 관리하기 쉽게 만들어준다.

• 주요 단계(Stages)와 기능:

  집계 파이프라인은 다양한 연산자를 가진 여러 단계를 조합하여 구성할 수 있다.

  • $match: SQL의 WHERE 절과 유사하게, 특정 조건을 만족하는 문서들만 필터링하여 다음 단계로 전달한다. 파이프라인의 초기에 위치시켜 처리할 데이터의 양을 줄이는 것이 성능 최적화의 핵심이다.98
  • $group: SQL의 GROUP BY 절에 해당하며, 지정된 식별자(_id 필드)를 기준으로 문서를 그룹화한다. 각 그룹에 대해 $sum, $avg, $max, $min 등과 같은 누산기(accumulator) 연산자를 사용하여 집계된 값을 계산할 수 있다.98
  • $project: SQL의 SELECT 절과 유사하게, 출력 문서에 포함될 필드를 선택하거나, 기존 필드를 바탕으로 새로운 필드를 계산하여 추가하거나, 필드 이름을 변경하는 등 문서의 구조를 재구성한다.98
  • $sort: 지정된 필드를 기준으로 문서를 오름차순 또는 내림차순으로 정렬한다.98
  • $unwind: 문서 내의 배열 필드를 입력으로 받아, 배열의 각 요소를 포함하는 개별 문서를 생성한다. 배열 데이터를 처리하고 분석할 때 매우 유용하다.98
  • $lookup: 다른 컬렉션의 문서와 조인(join) 연산을 수행할 수 있게 해준다. RDBMS의 LEFT OUTER JOIN과 유사한 기능을 제공하지만, 성능상의 이유로 신중하게 사용해야 한다.

• 아키텍처적 의의:

  집계 파이프라인은 MongoDB가 단순한 데이터 저장소를 넘어, 데이터 처리 및 분석 플랫폼으로서의 역할을 수행할 수 있게 하는 핵심 요소다. 이전의 MapReduce 프레임워크에 비해 사용법이 훨씬 간편하고 대부분의 경우 더 나은 성능을 제공한다.98 애플리케이션 서버로 대량의 데이터를 가져와 처리하는 대신, 데이터가 저장된 데이터베이스 서버 내에서 직접 복잡한 연산을 수행함으로써 네트워크 부하를 줄이고 전체적인 처리 속도를 향상시킨다.100

Apache Cassandra는 대규모 분산 환경에서의 쓰기 성능과 고가용성에 특화된 컬럼 패밀리 데이터베이스다. 이러한 특성은 데이터를 클러스터에 분산하고, 파티션 내에서 정렬하는 독특한 키(Key) 구조에 기반한다.

• Primary Key의 이중 구조:

  Cassandra에서 테이블의 Primary Key는 두 부분으로 구성된다: 파티션 키(Partition Key)와 선택적으로 사용되는 0개 이상의 클러스터링 키(Clustering Key).101 이 두 키의 조합이 Cassandra의 데이터 모델링과 성능을 결정하는 가장 중요한 요소다.

• 파티션 키 (Partition Key): 데이터 분산의 기준점

  • 역할: 파티션 키는 데이터 행(row)이 클러스터 내의 어떤 물리적 노드(node)에 저장될지를 결정하는 역할을 한다. Cassandra는 파티션 키의 값을 해시(hash)하여 토큰(token)을 생성하고, 이 토큰 값의 범위에 따라 데이터가 저장될 노드를 결정한다.101 동일한 파티션 키를 가진 모든 데이터는 항상 같은 노드에 저장된다.
  • 성능 영향: 쿼리를 실행할 때 WHERE 절에 파티션 키를 명시하면, Cassandra는 클러스터 전체를 스캔할 필요 없이 해당 데이터가 저장된 노드를 직접 찾아갈 수 있어 매우 빠른 조회가 가능하다.103 따라서 Cassandra의 데이터 모델링은 예상되는 쿼리가 항상 파티션 키를 포함하도록 설계하는 것이 제1원칙이다.
  • 설계 시 고려사항: 데이터가 특정 노드에만 집중되는 ‘핫스팟(hotspot)’ 현상을 방지하기 위해, 파티션 키는 클러스터 전체에 데이터가 고르게 분산될 수 있도록 충분히 높은 카디널리티(cardinality)를 가져야 한다.102 여러 컬럼을 묶어 복합 파티션 키(Composite Partition Key)로 만들어 분산도를 높일 수도 있다.104

• 클러스터링 키 (Clustering Key): 파티션 내 데이터 정렬의 기준

  • 역할: 클러스터링 키는 하나의 파티션(즉, 동일한 파티션 키를 가진 데이터 그룹) 내에서 데이터가 디스크에 물리적으로 저장되는 순서를 결정한다.101
  • 성능 영향: 데이터가 클러스터링 키를 기준으로 미리 정렬되어 있기 때문에, 특정 범위의 데이터를 조회하는 범위 쿼리(예: >,<)나 ORDER BY를 사용한 정렬 쿼리를 매우 효율적으로 수행할 수 있다.101 예를 들어, 시계열 데이터에서 특정 기간의 데이터를 조회하는 경우, 타임스탬프를 클러스터링 키로 지정하면 디스크에서 연속적인 읽기 작업만으로 빠르게 결과를 얻을 수 있다.

• 아키텍처적 의의:

  파티션 키와 클러스터링 키의 조합은 Cassandra가 대규모 데이터의 수평적 확장(파티션 키를 통한 분산)과 특정 쿼리 패턴에 대한 고성능 조회(클러스터링 키를 통한 정렬)라는 두 마리 토끼를 동시에 잡을 수 있게 하는 핵심 메커니즘이다. 이는 Cassandra의 데이터 모델링이 철저하게 ‘쿼리 중심적’이어야 함을 보여주는 아키텍처적 증거다.

NewSQL은 RDBMS의 강력한 일관성과 친숙한 SQL 인터페이스, 그리고 NoSQL의 수평적 확장성과 고가용성을 결합하려는 시도에서 탄생한 새로운 데이터베이스 패러다임이다.105 그 대표주자 중 하나인 CockroachDB의 아키텍처는 이러한 융합이 어떻게 이루어지는지를 잘 보여준다.

• 아키텍처의 핵심 원리:

  • 대칭적 구조 (Symmetric Architecture): CockroachDB 클러스터의 모든 노드는 동등한 역할을 수행한다. 마스터 노드나 프라이머리 노드가 존재하지 않으므로 단일 장애점(SPOF)이 없으며, 클라이언트는 어떤 노드에 접속하더라도 SQL 쿼리를 실행할 수 있다. 요청을 받은 노드는 필요에 따라 다른 노드와 통신하여 쿼리를 처리한다.108
  • 데이터 분산 (Ranges): 내부적으로 모든 데이터는 정렬된 키-값(Key-Value) 맵에 저장된다. 이 거대한 키 공간은 약 512MB 크기의 연속적인 청크인 ‘레인지(Range)’ 단위로 분할되어 클러스터의 여러 노드에 자동으로 분산된다. 데이터가 증가하면 레인지는 자동으로 분할(split)되어 새로운 노드로 재분배된다.109 이는 NoSQL의 샤딩과 유사한 수평 확장 메커니즘이다.
  • 강력한 일관성 (Raft Consensus): CockroachDB의 가장 큰 특징은 분산 환경에서도 ACID 트랜잭션과 직렬화 가능(Serializable) 수준의 강력한 격리 수준을 보장한다는 점이다. 이는 각 레인지의 복제본(Replica, 기본 3개)들이 Raft 합의 알고리즘을 사용하여 데이터 변경에 대한 합의를 이루기 때문에 가능하다.110 쓰기 작업은 과반수 이상의 복제본이 동의(commit)해야만 최종 완료되므로, 일부 노드에 장애가 발생해도 데이터의 일관성이 깨지지 않는다.109
  • SQL 계층: CockroachDB는 PostgreSQL 와이어 프로토콜과 호환되는 SQL API를 제공한다.108 이 덕분에 기존 RDBMS 개발자들은 새로운 쿼리 언어를 배울 필요 없이 친숙한 SQL을 사용하여 분산 데이터베이스의 이점을 누릴 수 있다.

• 아키텍처적 의의:

  CockroachDB의 아키텍처는 NoSQL 시스템의 분산 및 복제 기술(레인지, Raft)을 기반으로, 그 위에 RDBMS의 트랜잭션 처리 및 SQL 인터페이스 계층을 성공적으로 구현했다. 이는 CAP 정리에서 전통적으로 양립하기 어렵다고 여겨졌던 일관성(C)과 분할 허용성(P)을 높은 수준으로 동시에 달성하면서, 가용성(A) 또한 보장하려는 시도다 (PC/EC 시스템). 이는 NoSQL과 RDBMS의 경계가 점차 허물어지고, 두 패러다임의 장점을 결합한 하이브리드 아키텍처가 미래 데이터베이스 기술의 중요한 방향이 될 것임을 시사한다.

이처럼 각 NoSQL 시스템의 내부 아키텍처는 CAP/PACELC 정리에서 논의된 이론적 트레이드오프에 대한 각자의 구체적인 해답을 담고 있다. Cassandra의 Masterless 구조는 가용성을, MongoDB의 Primary-Secondary 복제는 일관성을, CockroachDB의 Raft 합의는 강력한 일관성을 우선시한 결과물이다. 이러한 아키텍처적 선택을 이해하는 것은 특정 비즈니스 요구사항에 가장 적합한 데이터베이스를 선택하는 데 있어 핵심적인 통찰을 제공한다.

이론과 기술적 원리를 넘어, NoSQL이 실제 비즈니스 환경에서 어떻게 대규모 문제를 해결하고 가치를 창출하는지 살펴보는 것은 매우 중요하다. 이 장에서는 전 세계 수억 명의 사용자를 대상으로 서비스를 제공하는 글로벌 IT 기업들의 사례를 통해, NoSQL이 복잡한 시스템 아키텍처의 핵심 구성 요소로 어떻게 활용되는지 심층 분석한다. 특히 Netflix, Uber와 같은 기업들이 왜 특정 NoSQL 솔루션을 선택했으며, 기존 RDBMS 및 다른 데이터 시스템과 어떻게 유기적으로 통합하여 거대한 데이터 파이프라인을 구축했는지 탐구한다.

• 비즈니스 문제와 기술적 요구사항:

  Netflix는 전 세계 2억 명이 넘는 구독자에게 스트리밍 서비스를 제공하며, 이 과정에서 엄청난 양의 데이터를 생성하고 처리한다. 그중에서도 ‘사용자 시청 기록’ 데이터는 개인화 추천 알고리즘의 핵심 입력값이자 서비스의 근간을 이루는 데이터다. 이 데이터는 다음과 같은 특징을 가진다.

  1. 압도적인 쓰기 워크로드: 사용자가 콘텐츠를 시청할 때마다 시청 위치, 시간 등의 데이터가 지속적으로 생성되므로, 읽기보다 쓰기 작업이 훨씬 빈번하다 (쓰기:읽기 비율 약 9:1).112
  2. 대규모 확장성: 하루에 수천억 건의 이벤트와 페타바이트(PB)급의 데이터가 발생하므로, 수평적으로 무한히 확장 가능한 아키텍처가 필수적이다.113
  3. 글로벌 고가용성: 전 세계에 분산된 사용자들에게 끊김 없는 서비스를 제공하기 위해, 특정 데이터 센터에 장애가 발생하더라도 서비스가 중단되지 않는 강력한 내결함성과 고가용성이 요구된다.114

• 솔루션으로서의 Apache Cassandra:

  Netflix는 이러한 요구사항을 충족시키기 위해 Apache Cassandra를 핵심 데이터 저장소로 선택했다. 그 이유는 Cassandra의 아키텍처가 Netflix의 문제 정의에 완벽하게 부합하기 때문이다.115

  • Masterless 아키텍처: 모든 노드가 동등한 역할을 수행하므로 단일 장애점이 없고, 어떤 노드에나 쓰기 요청을 보낼 수 있어 뛰어난 쓰기 처리량을 제공한다.114
  • 선형적 확장성: 클러스터에 노드를 추가하는 것만으로 성능 저하 없이 용량을 선형적으로 늘릴 수 있다.76
  • 다중 데이터센터 복제: 여러 지역의 데이터센터에 데이터를 자동으로 복제하는 기능이 내장되어 있어, 지리적 재해에도 데이터를 안전하게 보호하고 사용자에게 가장 가까운 데이터센터에서 서비스를 제공하여 지연 시간을 줄일 수 있다.114
  • 결과적 일관성: 시청 기록 데이터는 금융 거래와 달리 몇 초 정도의 데이터 지연이 허용되므로, Cassandra의 결과적 일관성 모델이 비즈니스 요구사항과 충돌하지 않는다.

• 아키텍처와 데이터 파이프라인:

  Netflix는 단순히 Cassandra를 도입하는 데 그치지 않고, 이를 중심으로 한 정교한 데이터 파이프라인을 구축했다. 수백 개의 클러스터와 수만 개의 노드로 구성된 대규모 Cassandra 인프라를 운영하며 112, Cassandra에 저장된 원본 데이터(Source of Truth)를 다양한 목적으로 활용한다. 예를 들어, 실시간 검색 및 조회를 위해 Elasticsearch와 연동하고, 대규모 배치 분석을 위해 자체 개발한 ‘Casspactor’라는 도구를 사용해 Cassandra의 데이터를 Apache Iceberg와 같은 데이터 웨어하우스 형식으로 변환하여 내보낸다.117

  또한, Netflix는 ‘폴리글랏 영속성(Polyglot Persistence)’ 전략을 적극적으로 활용한다. 시청 기록과 같은 대규모 비정형 데이터는 Cassandra(NoSQL)에 저장하지만, 결제 정보나 사용자 계정 정보처럼 강력한 트랜잭션 일관성(ACID)이 요구되는 데이터는 여전히 MySQL(RDBMS)에 저장하여 각 데이터의 특성에 맞는 최적의 기술을 조합한다.112

• 비즈니스 문제와 기술적 요구사항:

  Uber는 차량 공유, 음식 배달 등 다양한 서비스를 운영하며, 운전자와 승객의 위치 정보, 운행 기록, 결제 정보 등 복잡하고 방대한 데이터를 실시간으로 처리해야 한다. 이 시스템은 초당 수천만 건에 달하는 읽기 및 쓰기 요청을 매우 낮은 지연 시간으로 처리해야 하며, 높은 신뢰성과 확장성을 동시에 만족시켜야 한다.120

• 독자적인 솔루션: Docstore와 CacheFront:

  Uber는 기성 NoSQL 솔루션을 선택하는 대신, 기존에 안정적으로 사용하던 MySQL 위에 분산 데이터베이스의 기능을 구현한 독자적인 시스템 ‘Docstore’를 개발하는 길을 택했다.121

  • Docstore 아키텍처: Docstore는 상태를 저장하지 않는 ‘쿼리 엔진 계층’과 데이터를 실제로 저장하는 ‘스토리지 엔진 계층’으로 구성된다. 스토리지 엔진은 다수의 MySQL 인스턴스로 이루어져 있으며, 이들 간의 데이터 복제와 트랜잭션 합의는 Raft 알고리즘을 통해 관리된다.121 이는 MySQL의 데이터 저장 안정성과 분산 시스템의 확장성을 결합하려는 시도다.
  • 통합 캐싱 전략: 대규모 읽기 요청으로 인한 데이터베이스 부하를 해결하고 응답 속도를 극대화하기 위해, Docstore는 Redis를 기반으로 한 통합 캐싱 계층 ‘CacheFront’를 쿼리 엔진에 내장했다.121 애플리케이션은 데이터베이스에 직접 접근하는 대신 쿼리 엔진을 통해 데이터를 요청하며, 쿼리 엔진은 캐시에 데이터가 있으면 즉시 반환하고, 없으면 스토리지 엔진(MySQL)에서 데이터를 읽어와 캐시에 저장한 후 반환한다.
  • 일관성 유지: 캐시와 데이터베이스 간의 데이터 불일치 문제를 해결하기 위해, 데이터 변경이 발생하면 CDC(Change Data Capture) 파이프라인(Flux)을 통해 이를 감지하고, 수 초 내에 관련된 캐시 항목을 무효화하거나 갱신한다.121 이를 통해 결과적 일관성을 높은 수준으로 유지한다.

• 아키텍처적 의의:

  Uber의 사례는 특정 비즈니스의 고유한 요구사항을 만족시키기 위해 기존 기술(MySQL, Redis)을 창의적으로 조합하고, 그 위에 독자적인 분산 계층을 구축하여 맞춤형 NoSQL 시스템을 만들어낸 엔지니어링의 정수를 보여준다. 이는 NoSQL 도입이 단순히 외부 솔루션을 구매하는 것을 넘어, 내부 기술 역량을 바탕으로 시스템을 진화시키는 과정이 될 수 있음을 시사한다.

• Twitter와 람다 아키텍처:

  Twitter는 초당 수만 건의 트윗이 생성되는 대규모 실시간 데이터 스트림을 처리하기 위해 ‘람다 아키텍처(Lambda Architecture)’를 도입했다.122 이 아키텍처는 데이터를 두 개의 경로로 나누어 처리한다.

  1. 배치 계층(Batch Layer): 모든 원본 데이터를 Hadoop과 같은 분산 파일 시스템에 저장하고, 주기적으로 배치 작업을 실행하여 전체 데이터에 대한 정밀한 분석 뷰(Batch View)를 생성한다.

  2. 속도 계층(Speed Layer): 실시간으로 유입되는 데이터 스트림을 처리하여 배치 작업 사이의 지연 시간 동안 발생한 데이터를 보완하는 실시간 뷰(Real-time View)를 생성한다.

     사용자 쿼리는 이 두 뷰를 모두 조회하여 결합함으로써 전체 데이터에 대한 최신 결과를 얻게 된다. 이 아키텍처에서 Cassandra와 같은 NoSQL 데이터베이스는 마스터 데이터셋이나 각 뷰를 저장하는 서빙 계층(Serving Layer)의 역할을 수행한다.123

• Facebook/Instagram의 Polyglot Persistence:

  Facebook은 자사의 메시징 시스템을 위해 Cassandra를 직접 개발했으며, 이는 대규모 쓰기 부하와 고가용성 요구를 해결하기 위함이었다.124 Instagram은 수억 명 사용자의 활동 피드, 팔로워 관계, 메타데이터 등 다양한 유형의 데이터를 처리하기 위해 Cassandra, Redis, PostgreSQL 등 여러 데이터베이스를 조합하여 사용한다. 예를 들어, 휘발성이 강하고 빠른 조회가 필요한 데이터는 Redis에, 대규모 데이터는 Cassandra에, 관계형 데이터는 PostgreSQL에 저장하는 식이다.126

• IoT 데이터 플랫폼:

  IoT 환경은 수많은 센서로부터 초당 수백만 건의 시계열 데이터가 지속적으로 유입되는, 전형적인 쓰기 중심의 빅데이터 워크로드다.127 이러한 데이터를 효율적으로 수집, 저장, 분석하기 위해 Cassandra, HBase, InfluxDB와 같은 컬럼 패밀리 또는 시계열 특화 NoSQL 데이터베이스가 널리 사용된다.128 NoSQL의 유연한 스키마는 온도, 습도, 압력 등 센서 종류마다 다른 데이터 구조를 쉽게 수용할 수 있게 해주며 9, 수평 확장성은 끊임없이 증가하는 센서와 데이터를 감당할 수 있게 한다.

이러한 사례들은 공통적으로 NoSQL 데이터베이스가 독립된 시스템으로 사용되기보다는, Kafka와 같은 메시지 큐, Spark와 같은 데이터 처리 엔진, Redis와 같은 캐싱 시스템, 그리고 전통적인 RDBMS와 유기적으로 결합된 전체 ‘데이터 파이프라인’의 일부로서 기능한다는 점을 보여준다. 성공적인 NoSQL 도입은 단일 제품의 성능을 평가하는 것을 넘어, 데이터의 수집, 처리, 저장, 분석, 서빙에 이르는 전체 데이터 생명주기를 고려한 통합 아키텍처를 설계하는 문제임을 명확히 시사한다.

NoSQL은 지난 10여 년간 데이터베이스 기술 지형을 근본적으로 바꾸어 놓았다. RDBMS가 해결하기 어려웠던 웹 스케일의 확장성, 비정형 데이터 처리, 그리고 빠른 개발 속도에 대한 요구를 충족시키며 현대적인 애플리케이션 아키텍처의 필수 요소로 자리 잡았다. 그러나 NoSQL이 모든 문제에 대한 만병통치약은 아니며, 그 이면에는 새로운 기술적 도전과 트레이드오프가 존재한다. 이 마지막 장에서는 NoSQL 도입 시 현실적으로 마주하게 되는 한계와 도전 과제를 검토하고, 성공적인 도입을 위한 전략적 접근법을 제시한다. 또한, 빠르게 변화하는 기술 환경 속에서 NoSQL의 미래 발전 방향과 생성형 AI 시대에서의 역할을 조망하며 본 고찰을 마무리한다.

NoSQL이 제공하는 유연성과 성능의 이면에는 다음과 같은 실질적인 도전 과제들이 존재한다.

• 데이터 일관성 문제: 많은 NoSQL 시스템이 채택하는 ‘결과적 일관성(Eventual Consistency)’ 모델은 높은 가용성을 보장하지만, 데이터의 즉각적인 일관성을 보장하지는 않는다.130 이는 동시에 같은 데이터를 수정하려는 ‘쓰기-쓰기 충돌(write-write conflict)’이나, 아직 전파되지 않은 데이터를 읽는 ‘읽기-쓰기 충돌(read-write conflict)’의 가능성을 내포한다.132 이러한 잠재적 불일치를 처리하는 책임은 데이터베이스에서 애플리케이션 개발자에게로 이전되므로, 개발자는 비즈니스 로직 내에서 데이터의 최종 상태를 보장하기 위한 추가적인 구현(예: 충돌 감지 및 해결 로직)을 고려해야 한다.133
• 표준화된 쿼리 언어의 부재: RDBMS 세계에는 ANSI SQL이라는 강력한 표준이 존재하여, 데이터베이스 제품이 바뀌더라도 개발자들이 비교적 쉽게 적응할 수 있다. 반면, NoSQL 세계에는 이러한 표준이 부재하다. MongoDB는 MQL(MongoDB Query Language), Cassandra는 CQL(Cassandra Query Language), Neo4j는 Cypher 등 각 제품이 고유한 쿼리 언어나 API를 사용한다.22 이는 특정 기술에 대한 높은 학습 곡선과 기술 종속성(vendor lock-in)을 유발하며, 다른 NoSQL 시스템으로의 데이터 마이그레이션을 어렵게 만드는 요인이 된다.135
• 복잡한 트랜잭션 및 분석 쿼리의 한계: NoSQL은 단일 레코드(문서, 행 등)에 대한 원자적 연산은 잘 지원하지만, 여러 레코드에 걸친 복잡한 ACID 트랜잭션은 지원이 미흡하거나 성능 저하가 크다.29 (물론 MongoDB 등 일부 DB는 다중 문서 트랜잭션을 지원하지만 제약이 따른다 93). 또한, RDBMS의 강력한 조인(Join) 기능이 없어, 여러 데이터 집합을 결합하는 복잡한 분석 쿼리를 수행하기 어렵다.134 이 때문에 실시간 분석이나 비즈니스 인텔리전스(BI)를 위해서는 데이터를 Hadoop/Spark와 같은 별도의 빅데이터 분석 시스템으로 옮겨 처리해야 하는 경우가 많다.
• 데이터 모델링의 어려움: 스키마가 없는 유연성은 양날의 검이다. 명확한 가이드라인 없이 사용될 경우, 일관성 없는 데이터 구조를 양산하거나 데이터 구조에 대한 중요한 결정을 개발 후반으로 미루게 하여 결국 기술 부채로 이어질 수 있다.11 성공적인 NoSQL 모델링은 애플리케이션의 쿼리 패턴에 대한 깊은 이해를 바탕으로 한 신중한 설계를 요구한다.

결론적으로 ‘RDBMS와 NoSQL 중 어느 것이 더 우월한가?’라는 질문은 더 이상 유효하지 않다. 현대적인 애플리케이션 아키텍처는 두 패러다임을 대립적인 것으로 보지 않고, 각자의 강점을 활용하여 상호 보완적으로 사용하는 ‘폴리글랏 영속성(Polyglot Persistence)’ 접근 방식을 지향한다.6 이는 애플리케이션을 구성하는 각각의 마이크로서비스나 기능 단위별로 가장 적합한 데이터 저장소를 선택하여 조합하는 전략이다.

올바른 데이터베이스를 선택하기 위해서는 다음과 같은 기준을 종합적으로 고려해야 한다.

• 데이터의 구조와 관계: 데이터가 고도로 정형화되어 있고 복잡한 관계를 가지며 데이터 무결성이 중요하다면 RDBMS가 적합하다. 반면, 데이터 구조가 유연하고 비정형적이거나, 관계가 없거나 단순하다면 NoSQL이 유리하다.137
• 일관성 요구사항: 금융 거래처럼 단 1원의 오차도 허용할 수 없는 강력한 일관성(ACID)이 필수적이라면 RDBMS나 NewSQL을 선택해야 한다. 소셜 미디어 피드처럼 약간의 지연이 허용되고 결과적 일관성으로 충분하다면 NoSQL이 좋은 선택이다.
• 읽기/쓰기 패턴: 쓰기 작업이 매우 빈번하고 대규모라면 Cassandra와 같은 컬럼 패밀리 스토어를, 다양한 조건으로 데이터를 조회하는 복잡한 읽기 작업이 많다면 MongoDB와 같은 문서 스토어를, 단순 키 조회가 대부분이라면 Redis와 같은 키-값 스토어를 고려할 수 있다.
• 확장성 요구사항: 서비스가 폭발적으로 성장하여 페타바이트급 데이터와 수백만 QPS를 처리해야 할 것으로 예상된다면, 수평 확장에 최적화된 NoSQL을 초기 설계부터 고려하는 것이 현명하다.137

성공적인 도입을 위해서는 특정 기술에 대한 맹신을 버리고, 비즈니스 요구사항을 명확히 정의한 후, 후보 기술들에 대한 철저한 개념 증명(PoC)과 벤치마크 테스트(BMT)를 통해 실제 워크로드에서의 성능과 운영 복잡성을 검증하는 과정이 반드시 선행되어야 한다.138

NoSQL 기술은 지금도 끊임없이 진화하고 있으며, 특히 생성형 AI의 등장은 NoSQL의 역할을 더욱 중요하게 만들고 있다.

• 생성형 AI 시대와 NoSQL의 시너지:

  대규모 언어 모델(LLM)을 비롯한 생성형 AI 모델은 방대한 양의 비정형 데이터(텍스트, 코드, 이미지 등)를 학습 데이터로 필요로 한다. NoSQL 데이터베이스는 이러한 대규모 비정형 데이터를 유연하게 저장하고 효율적으로 처리하는 데 핵심적인 인프라를 제공한다.140 특히, 그래프 데이터베이스는 데이터 간의 복잡한 의미적 관계를 ‘지식 그래프(Knowledge Graph)’ 형태로 구축하는 데 사용된다. 이렇게 구축된 지식 그래프는 LLM이 외부의 최신 정보를 참조하여 더 정확하고 신뢰성 있는 답변을 생성하도록 돕는 RAG(Retrieval-Augmented Generation) 아키텍처의 핵심 구성 요소로 주목받고 있다.82

• 미래 기술 전망:

  1. 다중 모델 데이터베이스(Multi-model Database)의 확산: 하나의 데이터베이스 엔진 내에서 문서, 키-값, 그래프, 시계열 등 여러 데이터 모델을 동시에 지원하는 다중 모델 데이터베이스가 더욱 발전할 것이다.22 이는 폴리글랏 영속성 아키텍처의 복잡성을 줄여주면서도, 다양한 데이터 요구사항에 유연하게 대응할 수 있는 장점을 제공한다.
  2. 서버리스(Serverless) 및 클라우드 네이티브의 대중화: AWS DynamoDB, Google Firestore, Azure Cosmos DB와 같이, 개발자가 인프라 프로비저닝이나 스케일링, 관리에 신경 쓸 필요 없이 코드에만 집중할 수 있는 완전 관리형 서버리스 NoSQL 서비스가 클라우드 환경의 표준으로 자리 잡을 것이다.36
  3. SQL과 NoSQL의 지속적인 융합: NewSQL의 발전과 더불어, 기존 NoSQL 진영에서도 SQL과 유사한 쿼리 언어(예: Couchbase의 N1QL, Cassandra의 CQL) 지원을 강화하고 있다.140 이는 개발자의 진입 장벽을 낮추고, 기존 BI 도구와의 연동성을 높여 데이터 분석 역량을 강화하는 방향으로 계속 진화할 것이다.

궁극적으로 NoSQL의 등장은 ‘데이터베이스’라는 개념 자체를 확장시켰다. 전통적인 데이터베이스가 데이터의 ‘저장과 조회’라는 수동적인 역할에 머물렀다면, 현대의 NoSQL 시스템들은 캐싱(Redis), 데이터 스트리밍(Kafka), 검색, 분석(Elasticsearch) 등 데이터의 생명주기 전반에 걸친 다양한 기능을 능동적으로 수행하는 ‘데이터 플랫폼’으로 진화하고 있다. 앞으로도 NoSQL 기술은 데이터 중심 아키텍처의 핵심 동력으로서, 기술의 경계를 허물고 새로운 가능성을 창출하며 그 여정을 계속해 나갈 것이다.

1. NoSQL의 역사와 특징 - velog, 8월 3, 2025에 액세스, https://velog.io/@hanblueblue/NoSQL%EA%B3%BC-%EC%97%AD%EC%82%AC
2. SQL과 NoSQL 비교: 5가지 주요 차이점 - Integrate.io, 8월 3, 2025에 액세스, https://www.integrate.io/ko/blog/the-sql-vs-nosql-difference-ko/
3. nosql 등장배경 - back end 개발자!! - 티스토리, 8월 3, 2025에 액세스, https://roynus.tistory.com/316
4. ACID vs BASE - velog, 8월 3, 2025에 액세스, https://velog.io/@jeb1225/ACIDvsBASE
5. 데이터베이스의 ACID와 BASE 속성 - Medium, 8월 3, 2025에 액세스, https://medium.com/@delivalue100/%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4%EC%9D%98-acid%EC%99%80-base-%EB%AA%A8%EB%8D%B8-14242a1d0316
6. NoSQL 데이터베이스란 무엇인가요? - 비관계형 데이터베이스 설명 - AWS, 8월 3, 2025에 액세스, https://aws.amazon.com/ko/nosql/
7. [DataBase] 정규화와 비정규화의 탄생 배경 및 장단점, 8월 3, 2025에 액세스, https://superohinsung.tistory.com/126
8. [데이터베이스] 정규화 VS 비정규화 공부 및 정리 - velog, 8월 3, 2025에 액세스, https://velog.io/@mindfulness_22/%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-%EC%A0%95%EA%B7%9C%ED%99%94-VS-%EB%B9%84%EC%A0%95%EA%B7%9C%ED%99%94-%EA%B3%B5%EB%B6%80-%EB%B0%8F-%EC%A0%95%EB%A6%AC
9. SQL 대 NoSQL 데이터베이스 이해 - MongoDB, 8월 3, 2025에 액세스, https://www.mongodb.com/ko-kr/resources/basics/databases/nosql-explained/nosql-vs-sql
10. noSQL의 정의와 특징, 장단점을 알아보자 - 개발 공부 자료실, 8월 3, 2025에 액세스, https://codewos.tistory.com/11
11. [Database] RDBMS와 NoSQL의 차이점 - 히진쓰의 서버사이드 기술 블로그, 8월 3, 2025에 액세스, https://khj93.tistory.com/entry/Database-RDBMS%EC%99%80-NOSQL-%EC%B0%A8%EC%9D%B4%EC%A0%90
12. NoSQL 데이터베이스란 무엇인가요? - IBM, 8월 3, 2025에 액세스, https://www.ibm.com/kr-ko/think/topics/nosql-databases
13. NoSQL - 위키백과, 우리 모두의 백과사전, 8월 3, 2025에 액세스, https://ko.wikipedia.org/wiki/NoSQL
14. ko.wikipedia.org, 8월 3, 2025에 액세스, https://ko.wikipedia.org/wiki/NoSQL#:~:text=2009%EB%85%84%20%EC%B4%88%EC%97%90%20%EB%9D%BC%EC%8A%A4%ED%8A%B8,%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4%EB%A5%BC%20NoSQL%EC%9D%B4%EB%9D%BC%EA%B3%A0%20%EB%B6%88%EB%A0%80%EB%8B%A4.
15. NoSQL - 나무위키, 8월 3, 2025에 액세스, https://namu.wiki/w/NoSQL
16. NoSQL(Not only SQL)이란? - Next-BlockChain - 티스토리, 8월 3, 2025에 액세스, https://next-block.tistory.com/m/entry/NoSQLNot-only-SQL%EC%9D%B4%EB%9E%80-MongoDB%EB%9E%80
17. NoSQL이란 무엇인가? - Dev.GA - 티스토리, 8월 3, 2025에 액세스, https://gangnam-americano.tistory.com/30
18. cloud.google.com, 8월 3, 2025에 액세스, https://cloud.google.com/discover/what-is-nosql?hl=ko#:~:text=%22not%20only%20SQL%22%EC%9D%98%20%EC%A4%84%EC%9E%84%EB%A7%90,%EA%B4%80%EA%B3%84%ED%98%95%20%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4%EB%A5%BC%20%EC%9D%98%EB%AF%B8%ED%95%A9%EB%8B%88%EB%8B%A4.
19. NoSQL이란? SQL이란? 둘의 차이는 무엇인가? - 나만을 위한 블로그, 8월 3, 2025에 액세스, https://onlyfor-me-blog.tistory.com/268

20. SQL과 NOSQL의 차이

    ‍ Tech Interview - Gyoogle, 8월 3, 2025에 액세스, https://gyoogle.dev/blog/computer-science/data-base/SQL%20&%20NOSQL.html

21. [Database] RDB와 NoSQL 비교(특징, 장단점 등) - 개발자의 기록 - 티스토리, 8월 3, 2025에 액세스, https://dev-records.tistory.com/entry/Database-RDB%EC%99%80-NoSQL-%EB%B9%84%EA%B5%90%ED%8A%B9%EC%A7%95-%EC%9E%A5%EB%8B%A8%EC%A0%90-%EB%93%B1
22. NoSQL이란 무엇인가요? NoSQL 데이터베이스 이해하기 - MongoDB, 8월 3, 2025에 액세스, https://www.mongodb.com/ko-kr/resources/basics/databases/nosql-explained
23. Schema on Write vs. Schema on Read - Software AG Tech Community & Forums, 8월 3, 2025에 액세스, https://tech.forums.softwareag.com/t/schema-on-write-vs-schema-on-read/294853
24. Big Data SQL Quick Start. Schema on Read and Schema on Write - Part11. - Oracle Blogs, 8월 3, 2025에 액세스, https://blogs.oracle.com/datawarehousing/post/big-data-sql-quick-start-schema-on-read-and-schema-on-write-part11
25. [DataBase] RDBMS VS NoSQL - 자바랑 썸타는중 - 티스토리, 8월 3, 2025에 액세스, https://gwamssoju.tistory.com/99

26. Schema-on-Read vs Schema-on-Write

    Dremio, 8월 3, 2025에 액세스, https://www.dremio.com/wiki/schema-on-read-vs-schema-on-write/

27. ELI5: Schema-on-Read vs Schema-on-Write : r/explainlikeimfive - Reddit, 8월 3, 2025에 액세스, https://www.reddit.com/r/explainlikeimfive/comments/nz7tjy/eli5_schemaonread_vs_schemaonwrite/
28. NoSQL 데이터베이스 - NoSQL이란? - Microsoft Azure, 8월 3, 2025에 액세스, https://azure.microsoft.com/ko-kr/resources/cloud-computing-dictionary/what-is-nosql-database
29. [NoSQL 데이터베이스별 특징]. Key-Value, Document 등 NoSQL 데이터베이스별 특성에… - Jaemun Jung, 8월 3, 2025에 액세스, https://jaemunbro.medium.com/nosql-%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-%ED%8A%B9%EC%84%B1-%EB%B9%84%EA%B5%90-c9abe1b2838c
30. thebook.io, 8월 3, 2025에 액세스, https://thebook.io/006884/0487/#:~:text=%EC%88%98%EC%A7%81%20%ED%99%95%EC%9E%A5%EC%9D%80%20%EC%84%9C%EB%B2%84%EC%9D%98,%EC%9D%B4%20%EB%8D%94%20%ED%98%84%EC%8B%A4%EC%A0%81%EC%9D%B8%20%EB%B0%A9%EB%B2%95%EC%9E%85%EB%8B%88%EB%8B%A4.
31. 수평 확장 vs 수직 확장 / Tier vs Layer - 베스핀글로벌 테크센터 블로그, 8월 3, 2025에 액세스, https://btcd.tistory.com/16
32. [Database] SQL vs NoSQL - Hoyeon, 8월 3, 2025에 액세스, https://hoyeonkim795.github.io/posts/SQL-vs-NoSQL/
33. SQL, NoSQL 비교(특징, 스키마, 속도, 확장) - Eddy - 티스토리, 8월 3, 2025에 액세스, https://node-js.tistory.com/23
34. NoSQL DB 도입기, 8월 3, 2025에 액세스, https://velog.io/@seanlion/nosqldb
35. [데이터베이스] RDB와 NoSQL의 차이는? - 데일리디벨롭, 8월 3, 2025에 액세스, https://hyuuny.tistory.com/158

36. 데이터 혁명: NoSQL로 더 빠르게, 더 유연하게

    인사이트리포트

    삼성SDS, 8월 3, 2025에 액세스, https://www.samsungsds.com/kr/insights/data-innovations.html

37. [DB이론] 트랜잭션(transaction)과 ACID 특성을 보장하는 방법 - Victolee - 티스토리, 8월 3, 2025에 액세스, https://victorydntmd.tistory.com/129
38. BASE와 NoSQL: ACID와의 차이점 및 선택 기준 - 0and24 님의 블로그, 8월 3, 2025에 액세스, https://0and24.tistory.com/30
39. 분산 시스템에서의 일관성 모델: 다이나모 스타일과 완화된 일관성 - 백번 열번, 8월 3, 2025에 액세스, https://100100e.tistory.com/591
40. Eventual Consistency 란? - velog, 8월 3, 2025에 액세스, https://velog.io/@soongjamm/Eventual-Consistency-%EB%9E%80

41. What Is the CAP Theorem?

    IBM, 8월 3, 2025에 액세스, https://www.ibm.com/think/topics/cap-theorem

42. CAP theorem - Wikipedia, 8월 3, 2025에 액세스, https://en.wikipedia.org/wiki/CAP_theorem
43. 서비스에 적합한 데이터베이스 선택법. cap theorem - 공부하샘 - 티스토리, 8월 3, 2025에 액세스, https://hxnsxxm.tistory.com/m/21
44. [Database] CAP 정리 - Azderica, 8월 3, 2025에 액세스, https://azderica.github.io/00-db-cap/
45. 분산 데이터 시스템의 일관성과 가용성. CAP 이론과 PACELC - Mark-Kim, 8월 3, 2025에 액세스, https://mark-kim.blog/cap_pacelc/cap_pacelc_theorem/
46. CAP Theorem: CAP 이론 - 최윧의 개발 노트 - 티스토리, 8월 3, 2025에 액세스, https://choi-yud.tistory.com/27
47. CAP 정리란? - IBM, 8월 3, 2025에 액세스, https://www.ibm.com/kr-ko/topics/cap-theorem
48. NoSQL CAP이론 - 도리의 디지털라이프, 8월 3, 2025에 액세스, https://blog.skby.net/nosql-cap%EC%9D%B4%EB%A1%A0/
49. RDBMS의 한계와 NoSQL을 사용하는 이유 (1) CAP, PACELC 이론 - TheWing - 티스토리, 8월 3, 2025에 액세스, https://sujl95.tistory.com/81
50. CAP 이론과 PACELC 이론을 알아보자, 8월 3, 2025에 액세스, http://happinessoncode.com/2017/07/29/cap-theorem-and-pacelc-theorem/
51. Beyond CAP: Unveiling the PACELC Theorem for Modern Systems - DEV Community, 8월 3, 2025에 액세스, https://dev.to/ashokan/beyond-cap-unveiling-the-pacelc-theorem-for-modern-systems-465j
52. PACELC design principle - Wikipedia, 8월 3, 2025에 액세스, https://en.wikipedia.org/wiki/PACELC_design_principle

53. PACELC Theorem Explained: Distributed Systems Series

    by Lohith Chittineni - Medium, 8월 3, 2025에 액세스, https://medium.com/distributed-systems-series/pacelc-theorem-explained-distributed-systems-series-9c509febb8f8

54. [NoSQL] 키-값 데이터베이스 - O! JAVA - 티스토리, 8월 3, 2025에 액세스, https://ojava.tistory.com/130
55. NoSQL 저장 유형별 간단 정리 - 이런 사람도 개발합니다., 8월 3, 2025에 액세스, https://rural-mouse.tistory.com/38
56. 데이터베이스에 대한 기본적인 이해 (NoSQL) - RaMoo - 티스토리, 8월 3, 2025에 액세스, https://ramoo1101.tistory.com/67
57. Redis, 초면입니다. - 정의, 구조, 장단점, 활용 사례 - 바켠진로그, 8월 3, 2025에 액세스, https://hgggny.tistory.com/entry/Redis-%EC%B4%88%EB%A9%B4%EC%9E%85%EB%8B%88%EB%8B%A4-%EC%A0%95%EC%9D%98-%EA%B5%AC%EC%A1%B0-%EC%9E%A5%EB%8B%A8%EC%A0%90-%ED%99%9C%EC%9A%A9-%EC%82%AC%EB%A1%80
58. In-memory DB Redis의 특징, 어떻게 사용할까? - 데이널 『데이터 ∙ 분석 ∙ 지식소통』, 8월 3, 2025에 액세스, https://bommbom.tistory.com/entry/Redis%EC%9D%98-%ED%8A%B9%EC%A7%95-%EC%96%B4%EB%96%BB%EA%B2%8C-%EC%82%AC%EC%9A%A9%ED%95%A0%EA%B9%8C
59. CAP 이론으로 보는 RDBMS vs NoSQL - 자바시작 워니 - 티스토리, 8월 3, 2025에 액세스, https://oneny.tistory.com/114
60. [NoSQL]NoSQL(Not Only SQL) 종류와 특징 간단히 정리, 8월 3, 2025에 액세스, https://spidyweb.tistory.com/127
61. Redis 자료구조와 명령어 & 활용사례.md - GitHub, 8월 3, 2025에 액세스, https://github.com/binghe819/TIL/blob/master/DB/Redis/Redis%20%EC%9E%90%EB%A3%8C%EA%B5%AC%EC%A1%B0%EC%99%80%20%EB%AA%85%EB%A0%B9%EC%96%B4/Redis%20%EC%9E%90%EB%A3%8C%EA%B5%AC%EC%A1%B0%EC%99%80%20%EB%AA%85%EB%A0%B9%EC%96%B4%20&%20%ED%99%9C%EC%9A%A9%EC%82%AC%EB%A1%80.md
62. [Redis] 레디스란 무엇인가? - 특징, 장단점, 사용 사례 - IT is True, 8월 3, 2025에 액세스, https://ittrue.tistory.com/317
63. DynamoDB 장단점과 DynamoDB를 시작 전에 알면 좋은 11가지 - TheWing - 티스토리, 8월 3, 2025에 액세스, https://sujl95.tistory.com/84
64. Amazon DynamoDB: 게임 서비스 사용 사례 및 설계 패턴, 8월 3, 2025에 액세스, https://aws.amazon.com/ko/blogs/korea/amazon-dynamodb-gaming-use-cases-and-design-patterns/
65. 고속 NoSQL 키 값 데이터베이스 - Amazon DynamoDB, 8월 3, 2025에 액세스, https://aws.amazon.com/ko/dynamodb/
66. NoSQL이란 무엇인가요? 데이터베이스 설명 - Google Cloud, 8월 3, 2025에 액세스, https://cloud.google.com/discover/what-is-nosql?hl=ko
67. NoSQL과 RDBMS의 장단점 - velog, 8월 3, 2025에 액세스, https://velog.io/@wert1593/NoSQL%EA%B3%BC-RDBMS%EC%9D%98-%EC%9E%A5%EB%8B%A8%EC%A0%90
68. 데이터 모델링 - MongoDB, 8월 3, 2025에 액세스, https://www.mongodb.com/ko-kr/docs/manual/data-modeling/
69. [10분 테코톡] 스플릿, 애쉬의 SQL과 NoSQL - YouTube, 8월 3, 2025에 액세스, https://www.youtube.com/watch?v=cnPRFqukzek
70. 냅다 디비를 만들어! 1위부터 5위까지 DB 비교 - 인하대학교 인트아이, 8월 3, 2025에 액세스, https://int-i.github.io/sql/2022-05-01/db-comparison/
71. HBase - IT 위키, 8월 3, 2025에 액세스, https://itwiki.kr/w/HBase
72. Hbase 개요 - DB의 DB - 티스토리, 8월 3, 2025에 액세스, https://dabingk.tistory.com/19
73. [Cassandra] 아파치 카산드라란? - 윤복로그 - 티스토리, 8월 3, 2025에 액세스, https://goyunji.tistory.com/95
74. Apache Hbase - velog, 8월 3, 2025에 액세스, https://velog.io/@dksgyals1/Apache-Hbase
75. [NoSQL] Cassandra vs Hbase vs MongoDB - 좌충우돌 개발자의 기록 - 티스토리, 8월 3, 2025에 액세스, https://lovelushi.tistory.com/entry/NoSQL-Cassandra-vs-Hbase-vs-MongoDB
76. Apache Cassandra에 대해 알아보자 - 아웃풋 트레이닝, 8월 3, 2025에 액세스, https://baek.dev/post/23/
77. NoSQL강의) HBase 개요, 특징, client 설명 + Apache Phoenix - 데브원영, 8월 3, 2025에 액세스, https://blog.voidmainvoid.net/236
78. NoSQL 데이터베이스의 다양한 종류와 선택: 그래프, 키-값, 문서형 등의 데이터 모델, 8월 3, 2025에 액세스, https://4happy5122.tistory.com/2
79. NEO4J: 그래프 데이터베이스 소개 - velog, 8월 3, 2025에 액세스, https://velog.io/@gun_123/NEO4J-%EA%B7%B8%EB%9E%98%ED%94%84-%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-%EC%86%8C%EA%B0%9C
80. 그래프 데이터베이스란 무엇인가요? - 그래프 DB 설명 - AWS, 8월 3, 2025에 액세스, https://aws.amazon.com/ko/nosql/graph/
81. [Neo4j] Graph Database란? RDBMS와 비교, neo4j 도입 이유 - dgjinsu - 티스토리, 8월 3, 2025에 액세스, https://dgjinsu.tistory.com/48

82. 통합 그래프 데이터베이스

    Oracle 대한민국, 8월 3, 2025에 액세스, https://www.oracle.com/kr/database/integrated-graph-database/

83. 그래프디비(Graph DB)란? - Liz0904의 멍멍왈왈 - 티스토리, 8월 3, 2025에 액세스, https://liz09045.tistory.com/142
84. Neo4j와 Graph Data Platforms - Medium, 8월 3, 2025에 액세스, https://medium.com/@godtaehee/neo4j%EC%99%80-graph-data-platforms-439fe012aaa4
85. NoSQL vs. SQL - cutting through the Tech Twitter noise with a real-world use case - Reddit, 8월 3, 2025에 액세스, https://www.reddit.com/r/programming/comments/13eo11t/nosql_vs_sql_cutting_through_the_tech_twitter/
86. How Data Models Affect Normalization & Denormalization in NoSQL Databases - MoldStud, 8월 3, 2025에 액세스, https://moldstud.com/articles/p-how-data-models-affect-normalization-denormalization-in-nosql-databases
87. Denormalization in Databases - GeeksforGeeks, 8월 3, 2025에 액세스, https://www.geeksforgeeks.org/dbms/denormalization-in-databases/
88. NoSQL 데이터 모델링 - Study Note - 티스토리, 8월 3, 2025에 액세스, https://more-learn.tistory.com/5
89. [데이터베이스] 정규화 vs. 비정규화(반정규화) - lijly - 티스토리, 8월 3, 2025에 액세스, https://owlyr.tistory.com/20
90. NoSQL과 RDBMS의 차이 - 챈챈 - 티스토리, 8월 3, 2025에 액세스, https://develoyummer.tistory.com/99
91. Embedded vs. Referenced Documents in MongoDB - GeeksforGeeks, 8월 3, 2025에 액세스, https://www.geeksforgeeks.org/mongodb/embedded-vs-referenced-documents-in-mongodb/
92. Embedded Data Versus References - Database Manual - MongoDB Docs, 8월 3, 2025에 액세스, https://www.mongodb.com/docs/manual/data-modeling/concepts/embedding-vs-references/
93. 운영 요인 및 데이터 모델 - 데이터베이스 매뉴얼 v7.0 - MongoDB Docs, 8월 3, 2025에 액세스, https://www.mongodb.com/ko-kr/docs/v7.0/core/data-model-operations/
94. References vs Embedding : r/mongodb - Reddit, 8월 3, 2025에 액세스, https://www.reddit.com/r/mongodb/comments/nag9yd/references_vs_embedding/
95. Data Modeling - Database Manual - MongoDB Docs, 8월 3, 2025에 액세스, https://www.mongodb.com/docs/manual/data-modeling/
96. References vs Embedding : r/mongodb - Reddit, 8월 3, 2025에 액세스, https://www.reddit.com/r/mongodb/comments/1iniwbm/references_vs_embedding/

97. NoSQL Database Design. Best Practices and Considerations

    by Bubu Tripathy - Medium, 8월 3, 2025에 액세스, https://medium.com/@bubu.tripathy/nosql-database-design-1a42731c8265

98. MongoDB Aggregation: tutorial with examples and exercises - Studio 3T, 8월 3, 2025에 액세스, https://studio3t.com/knowledge-base/articles/mongodb-aggregation-framework/
99. How To Use Aggregations in MongoDB - DigitalOcean, 8월 3, 2025에 액세스, https://www.digitalocean.com/community/tutorials/how-to-use-aggregations-in-mongodb
100. Complete Aggregation Pipeline Tutorials - Database Manual - MongoDB Docs, 8월 3, 2025에 액세스, https://www.mongodb.com/docs/manual/tutorial/aggregation-complete-examples/

101. What is Cassandra Clustering Key? Definition & FAQs

     ScyllaDB, 8월 3, 2025에 액세스, https://www.scylladb.com/glossary/cassandra-clustering-key/

102. Partition Key in Cassandra - Madhura Mehendale - Medium, 8월 3, 2025에 액세스, https://madhuramehendale.medium.com/partition-key-in-cassandra-f36d8670375c
103. Difference between partition key, composite key and clustering key in Cassandra?, 8월 3, 2025에 액세스, https://stackoverflow.com/questions/24949676/difference-between-partition-key-composite-key-and-clustering-key-in-cassandra

104. Composite Partition Key

     CQL for Cassandra 3.0 - DataStax Docs, 8월 3, 2025에 액세스, https://docs.datastax.com/en/cql-oss/3.3/cql/cql_using/useCompositePartitionKeyConcept.html

105. www.yugabyte.com, 8월 3, 2025에 액세스, https://www.yugabyte.com/distributed-sql/newsql/#:~:text=This%20does%20not%20mean%20they,Citus%2C%20VoltDB%2C%20and%20NuoDB.
106. Top 13 NewSQL Databases in 2024 - Reviews, Features, Pricing, Comparison, 8월 3, 2025에 액세스, https://www.predictiveanalyticstoday.com/newsql-databases/

107. NewSQL DATABASES 🗄️. Abstract

     by Madusanka Nipunajith - Medium, 8월 3, 2025에 액세스, https://medium.com/@madushankanipunajith/newsql-databases-%EF%B8%8F-78b50fbae357

108. An Enterprise Architecture Overview - CockroachDB, 8월 3, 2025에 액세스, https://www.cockroachlabs.com/blog/cockroachdb-enterprise-architecture/
109. Architecture Overview - CockroachDB, 8월 3, 2025에 액세스, https://www.cockroachlabs.com/docs/stable/architecture/overview.html
110. Reads and Writes in CockroachDB, 8월 3, 2025에 액세스, https://www.cockroachlabs.com/docs/stable/architecture/reads-and-writes-overview
111. Architecture Overview - CockroachDB, 8월 3, 2025에 액세스, https://www.cockroachlabs.com/docs/stable/architecture/overview

112. System Design Netflix

     A Complete Architecture - GeeksforGeeks, 8월 3, 2025에 액세스, https://www.geeksforgeeks.org/system-design/system-design-netflix-a-complete-architecture/

113. Evolution of the Netflix Data Pipeline

     by Netflix Technology Blog, 8월 3, 2025에 액세스, http://techblog.netflix.com/2016/02/evolution-of-netflix-data-pipeline.html

114. Cassandra Serving Netflix @ Scale - Vinay Chella, Netflix - YouTube, 8월 3, 2025에 액세스, https://www.youtube.com/watch?v=2l0_onmQsPI
115. Netflix Is Built On Apache Cassandra. Here’s Why It’s Also A Platform for Midsize Companies, 8월 3, 2025에 액세스, https://www.mescomputing.com/news/4185742/netflix-built-apache-cassandra-heres-platform-midsize-companies

116. Introducing Netflix’s Key-Value Data Abstraction Layer

     by Netflix Technology Blog, 8월 3, 2025에 액세스, https://netflixtechblog.com/introducing-netflixs-key-value-data-abstraction-layer-1ea8a0a11b30

117. Netflix Built a Scalable Annotation Service Using Cassandra, Elasticsearch and Iceberg, 8월 3, 2025에 액세스, https://www.infoq.com/news/2023/02/netflix-annotations-cassandra/
118. Navigating the Netflix Data Deluge: The Imperative of Effective Data Management, 8월 3, 2025에 액세스, https://netflixtechblog.medium.com/navigating-the-netflix-data-deluge-the-imperative-of-effective-data-management-e39af70f81f7
119. What SQL does Netflix use? - Design Gurus, 8월 3, 2025에 액세스, https://www.designgurus.io/answers/detail/what-sql-does-netflix-use

120. System Design of Uber App

     Uber System Architecture - GeeksforGeeks, 8월 3, 2025에 액세스, https://www.geeksforgeeks.org/system-design/system-design-of-uber-app-uber-system-architecture/

121. How Uber Serves Over 40 Million Reads Per Second from Online …, 8월 3, 2025에 액세스, https://www.uber.com/blog/how-uber-serves-over-40-million-reads-per-second-using-an-integrated-cache/
122. NoSQL을 사용하는 람다 아키텍처 - Couchbase, 8월 3, 2025에 액세스, https://www.couchbase.com/blog/ko/lamda-architecture-and-beyond-with-nosql/

123. Twitter’s tweets analysis using Lambda Architecture

     by Knoldus Inc. - Medium, 8월 3, 2025에 액세스, https://medium.com/knoldus/twitters-tweets-analysis-using-lambda-architecture-17ee1393787f

124. Cassandra 및 HBase - NoSQL 데이터베이스 간의 차이점 - AWS, 8월 3, 2025에 액세스, https://aws.amazon.com/ko/compare/the-difference-between-cassandra-and-hbase/
125. 아파치 분산 데이타 베이스 Cassandra 소개 - 조대협의 블로그, 8월 3, 2025에 액세스, https://bcho.tistory.com/440
126. NoSQL강의) Redis 개요, 기본사용법, command 설명 및 Jedis 예제 - 데브원영, 8월 3, 2025에 액세스, https://blog.voidmainvoid.net/233
127. [사례연구] 북미 메이저 석유 및 가스 채굴 기업의 재무 운영 개선 - Wiki, 8월 3, 2025에 액세스, https://wiki.a-platform.biz/2b419099-7672-448c-940a-96da42c0c851
128. 사물 인터넷(IoT) 애플리케이션을 위한 NoSQL 데이터베이스 - Couchbase, 8월 3, 2025에 액세스, https://www.couchbase.com/ko/use-cases/iot/
129. 스마트팩토리 핵심 IoT데이터, 어떻게 분석할 것인가? 동화기업 NoSQL 몽고DB IoT 적용사례, 8월 3, 2025에 액세스, https://talkit.tv/main/events/3189
130. [DataBase] NoSQL의 정의와 특징 그리고 NoSQL DB 와 관계형 DB의 차이점, 8월 3, 2025에 액세스, https://slowprogramer.tistory.com/entry/DataBase-NoSQL%EC%9D%98-%EC%A0%95%EC%9D%98%EC%99%80-%ED%8A%B9%EC%A7%95-%EA%B7%B8%EB%A6%AC%EA%B3%A0-NoSQL-DB-%EC%99%80-%EA%B4%80%EA%B3%84%ED%98%95-DB%EC%9D%98-%EC%B0%A8%EC%9D%B4%EC%A0%90
131. DB RDBMS의 한계와 NoSQL을 사용하는 이유 (3) NoSQL 장단점, 특징 - TheWing - 티스토리, 8월 3, 2025에 액세스, https://sujl95.tistory.com/83
132. [NoSQL] Ch5. 일관성 - 데이터 이야기, 8월 3, 2025에 액세스, https://jjaesang.github.io/nosql/2019/05/11/nosql-consistency-ch5.html
133. [NOSQL] NOSQL의 일관성에 대해 알아보자 - Log level - 티스토리, 8월 3, 2025에 액세스, https://firststep-de.tistory.com/34
134. NoSQL이 뭐길래 - 야망찬 개발자의 블로그, 8월 3, 2025에 액세스, https://sowon-dev.github.io/2022/02/26/220226NoSQL/
135. 사용 사례에 적합한 데이터베이스는 무엇일까요? - Integrate.io, 8월 3, 2025에 액세스, https://www.integrate.io/ko/blog/which-database-ko/
136. [데이터베이스] SQL vs NoSQL 개념, 장단점, 비교, 8월 3, 2025에 액세스, https://nice-engineer.tistory.com/entry/SQL-vs-NoSQL
137. SQL과 NOSQL 특징 및 장단점 - 백엔드로의 코딩 여행 - 티스토리, 8월 3, 2025에 액세스, https://bruno-jang.tistory.com/44
138. NoSQL 데이터베이스를 평가할 때 가장먼저 고려해야 할 5가지 사항 - MongoDB, 8월 3, 2025에 액세스, https://www.mongodb.com/collateral/top-5-nosql-considerations-whitepaper-south-korea

139. 무신사 서비스에 적합한 NoSQL 도입 여정 - 1편. AWS DocumentDB에서 Couchbase로 마이그레이션 하기

     by MUSINSA tech - Medium, 8월 3, 2025에 액세스, https://medium.com/musinsa-tech/database-6d1052ca6b36

140. “NoSQL과 생성AI 결합해 개발자의 타임 투 마켓 단축 도울 것” - 전자신문, 8월 3, 2025에 액세스, https://m.etnews.com/20231103000321?obj=Tzo4OiJzdGRDbGFzcyI6Mjp7czo3OiJyZWZlcmVyIjtOO3M6NzoiZm9yd2FyZCI7czoxMzoid2ViIHRvIG1vYmlsZSI7fQ%3D%3D
141. 생성형 AI 모델의 성능을 강화하는 그래프 데이터베이스 Neo4j - 클루커스, 8월 3, 2025에 액세스, https://gcp.cloocus.com/insight-genai_x_neo4j/