NoSQL 데이터베이스

NoSQL 데이터베이스는 문서, 키-값, 넓은 열, 그래프처럼 관계형 테이블 모델과 다른 방식으로 데이터를 다루는 데이터베이스 계열입니다. 데이터의 모양과 읽고 쓰는 방식에 맞춰 선택하는 것이 핵심이며, NoSQL이라는 이름만으로 더 빠르거나 설계가 더 간단하다고 판단할 수는 없습니다.

SQL(Structured Query Language)은 데이터 조회와 조작에 쓰는 언어이고, NoSQL은 여러 데이터 모델을 묶는 분류입니다. NoSQL을 “Not Only SQL”로 풀어 설명하기도 하지만, 모든 제품이 SQL을 금지한다는 뜻은 아닙니다. AWS의 NoSQL 개요도 여러 모델과 사용 목적을 구분해 설명합니다.

NoSQL의 네 가지 주요 데이터 모델

아래 유형은 데이터를 표현하는 방식을 이해하기 위한 분류입니다. 한 제품이 여러 모델을 지원할 수도 있으며, 같은 유형의 제품도 조회 기능과 운영 방식은 다릅니다.

키-값 데이터베이스

키-값 모델은 session:abc123 같은 키로 대응하는 값을 찾습니다. 세션 ID를 알고 세션 정보를 가져오는 작업처럼 조회 경로가 명확할 때 검토하기 좋습니다. 반대로 값 안의 여러 조건을 자유롭게 검색하려면 해당 제품이 지원하는 인덱스와 조회 기능을 별도로 확인해야 합니다.

키-값 저장소의 값이 항상 단순한 문자열인 것은 아닙니다. 예를 들어 Redis는 문자열 외에 해시, 목록, 집합과 정렬된 집합 등 여러 자료형을 제공합니다. Redis 자료형 문서에서 지원 범위를 확인할 수 있습니다. 캐시로 사용할 때는 원본 데이터의 위치, 만료 조건과 캐시가 없어졌을 때의 처리도 설계해야 합니다.

문서 데이터베이스

문서 모델은 한 항목을 필드, 배열과 중첩 객체로 묶어 저장합니다. JSON(JavaScript Object Notation)은 이런 구조를 표현하는 텍스트 형식이며, MongoDB는 BSON(Binary JSON)이라는 바이너리 문서 형식을 사용합니다. 상품 종류마다 속성이 다르거나 한 화면에 필요한 데이터를 한 묶음으로 읽을 때 문서 모델을 검토할 수 있습니다.

함께 조회하는 정보를 문서에 넣는 임베딩(embedding)과 다른 문서의 식별자로 연결하는 참조(reference) 중 무엇을 쓸지는 조회 빈도, 데이터 크기와 수정 방식에 따라 결정합니다. 모든 주문에 고객 주소를 복사하면 읽기는 편해질 수 있지만 복사본을 어떻게 유지할지도 정해야 합니다. MongoDB 데이터 모델링 문서는 접근 패턴에 맞춰 설계할 것을 안내합니다. 제품 자체의 개요는 MongoDB 소개와 도입 시 고려할 점에서 확인할 수 있습니다.

넓은 열 데이터베이스

넓은 열(wide-column) 모델은 행 키나 파티션 키를 중심으로 데이터를 묶고 여러 열을 관리합니다. Bigtable은 행 키로 정렬된 맵과 열 패밀리(column family, 관련 열의 묶음)를 사용합니다. Bigtable 저장 모델 문서는 행과 열, 열 패밀리의 관계를 설명합니다.

넓은 열 저장소를 “같은 열의 값을 모아 저장하는 분석용 열 지향 저장소”와 동일하게 취급하면 안 됩니다. Cassandra는 애플리케이션의 조회에 맞춰 테이블과 파티션을 설계하는 것이 중요하고 관계형 조인을 지원하지 않습니다. Cassandra의 조회 중심 데이터 모델링 안내에 따라 “어떤 장치의 어느 기간 데이터를 읽을 것인가”처럼 실제 질문을 먼저 정해야 합니다. 제품을 고르기 전에 범위 조회와 집계 작업이 필요한 형태로 지원되는지도 확인합니다.

그래프 데이터베이스

그래프 모델은 사람·상품·서버 같은 대상을 노드(node)로, 친구 관계·구매·의존성 같은 연결을 간선(edge)으로 표현합니다. “이 서버가 멈추면 어떤 서비스에 영향이 있는가”처럼 연결을 따라가는 질문에 적합한지 검토할 수 있습니다.

그래프도 데이터의 속성을 저장하며, Neo4j의 속성 그래프(property graph)에서는 노드와 관계에 속성을 넣을 수 있습니다. Neo4j 그래프 개념 문서가 이 구조를 설명합니다. 그래프 모델을 선택했다고 모든 조회가 빨라지는 것은 아니므로 탐색 범위와 경로 조건을 구체적으로 정해야 합니다.

관계형 데이터베이스와 무엇이 다른가요?

관계형 데이터베이스 관리 시스템(RDBMS, Relational Database Management System)은 행과 열로 이루어진 테이블, 키와 제약 조건을 중심으로 데이터를 관리합니다. 여러 항목 사이의 관계를 조인으로 조회하고 공통 규칙을 적용하기 좋습니다. NoSQL은 제품별 모델에 맞는 조회와 저장 방식을 선택하므로, 데이터를 같은 방식으로 옮겨 담기보다는 애플리케이션의 질문을 기준으로 비교해야 합니다.

JSON을 저장한다는 이유만으로 반드시 NoSQL이 필요한 것은 아닙니다. PostgreSQL처럼 관계형 데이터베이스도 JSON 자료형과 jsonb 인덱스를 제공합니다. PostgreSQL JSON 자료형 문서에서 기능을 확인할 수 있습니다. 기존 관계형 구조와 트랜잭션을 유지하면서 일부 속성만 유연하게 저장하는 선택도 비교 대상입니다.

스키마가 유연해도 데이터 설계는 필요합니다

스키마(schema)는 필드 이름, 자료형과 필수 조건처럼 데이터의 구조와 규칙을 말합니다. 문서 데이터베이스가 서로 다른 필드를 허용하더라도 애플리케이션은 어떤 값이 들어오는지 알아야 합니다. 다음은 서로 다른 속성을 가진 두 상품을 표현한 가상의 JSON 데이터입니다.

[
  {
    "product_id": "book-101",
    "name": "데이터베이스 입문",
    "price_krw": 24000,
    "attributes": {
      "author": "김민아",
      "pages": 320
    }
  },
  {
    "product_id": "headphones-201",
    "name": "무선 헤드폰",
    "price_krw": 79000,
    "attributes": {
      "wireless": true,
      "battery_hours": 30
    }
  }
]

두 상품은 product_id, name, price_krw를 공유하지만 attributes 내부의 필드가 다릅니다. 이런 차이를 자연스럽게 표현할 수 있는 것이 문서 구조의 장점입니다. 다만 같은 가격 필드에 숫자와 문자열이 섞이면 정렬이나 계산에 문제가 생길 수 있으므로 허용되는 자료형과 누락 처리 기준을 정해야 합니다.

MongoDB는 필드의 자료형이나 값 범위를 검사하는 스키마 검증을 지원합니다. MongoDB 스키마 검증 문서에 따라 필요한 부분에 규칙을 적용할 수 있습니다. 반면 Cassandra의 CQL(Cassandra Query Language)은 테이블을 만들 때 열과 자료형을 정의합니다. Cassandra 테이블 정의 문서가 이 조건을 명시하므로 “모든 NoSQL에는 스키마가 없다”는 설명은 맞지 않습니다.

JSON은 구조가 전혀 없는 데이터가 아니라 구조를 표현하는 형식입니다. 이미지·동영상의 본체를 데이터베이스에 넣을지, 객체 저장소에 두고 데이터베이스에는 주소와 메타데이터를 둘지는 파일 크기, 전달 방식과 관리 요구에 따라 따로 판단합니다.

트랜잭션과 일관성은 제품별로 확인합니다

트랜잭션 지원 여부와 범위

트랜잭션(transaction)은 여러 변경을 하나의 작업 단위로 다루는 기능입니다. ACID는 원자성(Atomicity), 일관성(Consistency), 격리성(Isolation), 지속성(Durability)을 뜻합니다. 주문 생성과 재고 차감처럼 함께 성공하거나 실패해야 하는 변경이 있다면 지원 범위를 먼저 확인해야 합니다.

NoSQL이 트랜잭션을 지원하지 않는다고 단정할 수는 없습니다. MongoDB는 복제 세트와 샤딩 클러스터에서 여러 문서의 트랜잭션을 지원하며, 읽기·쓰기 보장은 설정과 배포 조건에 영향을 받습니다. MongoDB 트랜잭션 문서에서 조건을 확인하세요. DynamoDB도 트랜잭션 API(Application Programming Interface, 프로그램이 기능을 요청하는 인터페이스)를 제공하지만 대상과 지역 범위 등 제약이 있습니다. DynamoDB 트랜잭션 문서가 그 범위를 설명합니다.

저장 직후 읽는 값의 보장

복제된 데이터가 여러 서버에 반영되는 방식도 중요합니다. 최종적 일관성(eventual consistency)을 사용하는 읽기에서는 최근에 완료된 쓰기가 아직 반영되지 않은 값을 읽을 수 있습니다. “주문을 저장한 직후 주문이 보이지 않는 상황을 허용할 수 있는가”처럼 사용자 동작별 조건을 정해야 합니다.

예를 들어 DynamoDB의 테이블과 로컬 보조 인덱스는 강한 일관성 읽기를 선택할 수 있지만 글로벌 보조 인덱스와 스트림 읽기는 최종적 일관성을 사용합니다. DynamoDB 읽기 일관성 문서에서 조회 대상에 따른 차이를 확인할 수 있습니다. 트랜잭션의 ACID 일관성과 여러 복제본에서 읽는 값의 일관성은 서로 다른 문제이므로 같은 말로 취급하지 않습니다.

수평 확장이 자동으로 성능을 보장하지는 않습니다

수평 확장(scale-out)은 더 큰 서버 한 대로 바꾸는 대신 서버 수를 늘려 처리 능력을 확장하는 방식입니다. 샤딩(sharding)은 데이터를 여러 서버로 나누는 것이고, 복제(replication)는 데이터의 사본을 유지하는 것입니다. 서버가 여러 대라는 사실만으로 데이터가 고르게 나뉘거나 모든 조회가 빨라지는 것은 아닙니다. MongoDB 샤딩 개요도 분산 구성을 별도로 설명합니다.

분산에 사용하는 키가 한쪽으로 쏠리면 일부 파티션에 요청이 집중되는 핫 파티션(hot partition)이 생길 수 있습니다. 예를 들어 모든 이벤트를 하나의 고정된 키 아래에 모으는 설계는 부하 분산에 불리할 수 있습니다. DynamoDB 파티션 키 설계 안내처럼 조회 요구와 키 분포를 함께 검토해야 합니다.

성능은 데이터 크기, 인덱스, 조회 범위, 읽기·쓰기 비율, 일관성 설정과 실제 부하에 따라 달라집니다. 도입 비교에서는 평균 응답 시간뿐 아니라 느린 요청의 지연, 실패율과 복구 동작도 측정합니다. 복제본, 백업, 네트워크와 운영 인력 비용까지 포함해야 하므로 NoSQL이라는 분류만으로 비용이 저렴하다고 판단하지 않습니다.

어떤 상황에서 NoSQL을 검토하나요?

• 키로 찾는 캐시·세션: 키-값 저장소를 검토하되 만료, 영속성, 원본 데이터와의 동기화 방법을 정합니다.
• 항목별 속성이 다른 카탈로그: 문서 모델을 검토하되 공통 필드의 검증과 검색용 인덱스는 설계합니다.
• 정해진 키·기간으로 읽는 이벤트: 넓은 열 모델을 검토하되 파티션 크기와 범위 조회를 확인합니다.
• 여러 단계의 관계 탐색: 그래프 모델을 검토하되 연결의 종류와 탐색 깊이를 정합니다.

반대로 다양한 테이블을 조합하는 보고서와 복잡한 조건 조회가 많거나, 여러 항목에 걸친 제약 조건을 중앙에서 관리하려는 요구가 강하다면 관계형 데이터베이스를 먼저 비교할 이유가 있습니다. 특정 업종이나 데이터 크기만으로 결론을 내리지 말고 가장 중요한 조회와 변경을 후보 제품에서 어떻게 구현할지 확인합니다.

관계형 데이터베이스를 원본 저장소로 두고 키-값 저장소를 캐시로 사용하는 등 역할을 나누는 구성도 가능합니다. 다만 저장소가 늘면 복사본 갱신, 장애 복구와 삭제 전파가 복잡해지므로 기능이 필요하다는 근거가 있을 때 추가합니다.

도입 전에 확인할 순서

1. 핵심 조회를 적습니다. “상품 ID로 상세 조회”, “사용자의 최근 주문”, “장치별 하루 기록”처럼 필터와 정렬 기준까지 구체적으로 정합니다.
2. 정확성 조건을 정합니다. 함께 성공해야 하는 변경, 중복 요청 처리, 저장 직후 읽기와 오래된 값의 허용 범위를 적습니다.
3. 실제 데이터 모델을 설계합니다. 문서 크기, 참조·임베딩, 인덱스, 파티션 키와 데이터가 증가했을 때의 조회 경로를 확인합니다.
4. 후보를 작은 환경에서 비교합니다. 같은 데이터와 작업으로 정상 부하, 집중 부하와 실패 상황을 재현하고, 제품 버전과 설정을 기록합니다.
5. 운영과 전환을 계획합니다. 권한, 백업·복원, 모니터링, 마이그레이션, 예상 비용과 문제가 생겼을 때 기존 저장소로 돌아가는 방법을 점검합니다.

처음부터 “SQL인가 NoSQL인가”만 결정하기보다, 필요한 조회와 정확성 조건을 만족하는 모델과 제품을 찾는 편이 판단에 도움이 됩니다. 이미 사용하는 데이터베이스가 그 조건을 충족한다면 새로운 종류의 저장소를 추가하는 이유부터 분명히 하세요.