1. NoSQL
NoSQL은 특정한 요구사항에 맞춰 데이터를 저장하고 조회하는 기법을 제공하는 데이터베이스를 말한다. 기존의 RDBMS를 사용하는 것보다 더 적합한 방식일 수 있다.
예시로
- 수천만 회원 간의 연결 관계를 분석해서 친구를 추천하는 기능에는 그래프를 지원하는 데이터 베이스를 사용하거나
- 대량의 데이터를 실시간으로 수집하고 통계를 추출하는 경우에는 수평 확장을 지원하는 데이터 베이스를 사용하는 것이 있다.
NoSQL을 사용하는 이유는 다음과 같다.
- 수평확장을 통한 데이터 저장 용량 확장으로 대용량 데이터나 분산 처리 가능
- 예시 : Casandra, HBase
- 고속의 읽기와 쓰기 성능
- 트랜잭션의 ACID 기능 일부를 미지원해 일관성보단 DB 접근 속도를 높이고
- 인덱스를 최소화하고 데이터 분산 저장함으로써 병렬처리로 성능 향상
- 특정한 요구사항에 맞는 데이터 설계
- 전통적인 관계형 모델을 사용하는 RDBMS의 저장방식과 반대
- RDBMS의 조인 기능 미지원
- DynamoDB : 키 값 형태로 데이터 저장, MongoDB : BSON(바이너리 JSON) 형태로 데이터 저장
- 비정형 데이터 처리 또는 유연한 스키마
- RDBMS의 고정된 스키마와 달리 고정된 스키마가 없거나 유연한 스키마를 갖는다
- 데이터 신규 속성 추가와 같은 구조 변화에 더 유연하게 대처 가능하다
RDBMS의 Sharding vs. NoSQL
관계형 데이터베이스도 수평 확장을 할 수 있는데, 그 방식을 샤딩(sharding)이라 한다. 샤딩은 여러 개의 데이터베이스를 구성하고 각 데이터베이스 데이터를 나누어 넣는 식으로 확장하는 방식이다.
| Sharding | NoSQL |
| RDBMS는 서로 다른 데이터베이스 10개를 사용하는 것처럼 동작 | NoSQL의 클러스터는 개념적으로 데이터베이스가 하나 |
| 데이터 베이스 하나에 장애가 발생하면 해당 데이터 베이스에 속한 데이터를 사용할 수 없다. | 클러스터에서는 노드 중 하나에 장애가 발생해도 전체 클러스터가 정상 동작 가능 |
2. NoSQL 종류
NoSQL의 종류는 다음과 같다.
- 키-값 DB
- 문서 DB
- 컬럼 패밀리 DB
- 그래프 DB
키-값 DB(key-value DB)
키-값DB는 가장 강단한 형태의 NoSQL인데, 특징은 다음과 같다.
- 키 밸류를 매핑해서 저장한다.
- 모든 데이터를 값으로 사용 가능하다.
- 구조가 단순해서 읽기/쓰기가 빠르다.
- 예시 : DynamoDB, Redis
- Redis는 키-값 외에 다양한 형태의 값을 지원한다.
- 정렬된 집합을 제공해 순위표 쉽게 구현가능하고,
- 큐 기능을 제공하고 있어 메시징 시스템으로도 활용가능하다
키-값 저장소의 주된 용도는 다음과 같다.
- 세션 관리 : 인증 토큰과 같은 세션 정보를 저장한다.
- 캐시 : 자주 사용하는 데이터를 캐싱하는 용도로 사용한다
- 설정 관리 : 설정은 키-값 형태를 가지므로 키-값 DB로 관리하기에 적합하다
문서DB
- 예시 : MongoDB
- 가장 큰 특징은 스키마가 고정되어 있지 않다는 건데, 데이터를 주로 JSON과 유사한 문서에 저장한다.
- JSON 형태면 되므로 RDBMS의 테이블과 달리 복잡하고 중첩된 모델을 쉽게 표현할 수 있다.
- 새로운 속성이 필요하면 추가하면 되고 중첩된 구조나 배열을 사용할 수 있다.
- 어플리케이션에서 사용하는 데이터 모델과 DB에서 사용하는 데이터 모델이 거의 일치하는 장점도 있다. (RDBMS에서는 하나의 모델을 저장하기 위해 여러 테이블을 사용해야하는 것과 비교된다)
문서DB의 주요 용도는 다음과 같다.
- 컨텐츠 관리 : 유연한 스키마를 이용해서 다양한 종류의 컨텐츠를 관리한다
- 제품 카탈로그 : 다양한 메타데이터를 가진 카탈로그(제품/서비스의 설명/사진/가격 같은 상세정보 홍보물)를 제공한다.
컬럼 패밀리 DB
예시 : Cassandra, HBase
키-값DB의 확장 버전이라고 할 수 있다.
각 행은 여러 컬럼을 가질 수 있고, 여러 컬럼들을 그룹으로 묶어 관리한다는 공통점이 있다.
대량의 데이터를 저장할 수 있는 수평 확장이 용이한 구조를 갖는다.
컬럼 기반 DB의 주요 용도는 다음과 같다.
대규모 데이터 관리 : 채팅 플랫폼의 채팅 메시지나 IoT 데이터 등 대규모 데이터에 대한 저장과 조회가 필요한 서비스에 사용한다.
참고) 컬럼 기반 DB
컬럼 기반 DB 또는 컬럼형 DB는 컬럼 패밀리 DB와는 다르다. 컬럼 기반 DB는 컬럼 단위로 데이터를 저장하는데, 이는 RDBMS의 행 단위로 데이터를 저장하는 방식과 차이가 있다. 컬럼 기반 DB는 OLAP과 같이 데이터 분석을 목적으로 주요 사용된다. 컬럼 기반 DB로는 Clickhouse와 MariaDB ColumnStore 등이 있다.
그래프 DB
그래프DB는 데이터를 노드와 엣지가 있는 그래프 형태로 데이터를 관리한다.
노드와 엣지로 데이터의 관계를 표현하며 노드와 엣지는 필요한 프로퍼티를 갖는다.
예시 : Neo4j

그래프DB의 주요 용도는 다음과 같다.
- 소셜 : 소셜 네트워크 그 자체가 그래프다.
- 추천 : 사용자 관계에 기반한 친구 추천, 사용자 활동에 기반한 상품 추천 등에 활용할 수 있다.
- 부정 탐지 : 관계에 대한 패턴을 이용해서 실시간으로 이상 사용을 탐지할 수 있다.
3. NoSQL 도입 시 고려 사항
NoSQL은 성능, 확장성, 고가용성, 모델 유연함 등 좋은 특징이 있지만 RDBMS가 아닌 NoSQL을 도입할 때는 몇 가지를 고려해야 한다.
1) 트랜잭션 지원 여부
다수의 NoSQL은 RDBMS가 지원하는 수준의 트랜잭션을 지원하지 않는다. 따라서 트랜잭션이 필요한 기능에 NoSQL을 도입하려면 해당 NoSQL이 ACID를 지원하는지 확인하고 검증해야 한다. 만약 NoSQL이 원하는 수준의 트랜잭션을 지원하지 않으면 어플리케이션에서 따로 트랜잭션을 보완해야 하고, RDBMS와 NoSQL을 함께 사용할 경우 두 데이터 저장소 간의 데이터 동기화도 고려해야 한다.
2) 데이터 모델 요구사항
데이터 모델이 요구사항에 적합한지 확인해야 한다. NoSQL마다 지원하는데이터 모델이 다르기에, 데이터 모델에 맞춰 적합한 NoSQL을 선택해야 한다. 예시로 설문조사처럼 질문/답변이 계층 관계를 갖고 있는 모델은 문서 DB 사용이 적합하고, 단순 캐시가 필요한 경우엔 문서DB보다는 키-값DB가 적당하다.
3) 확장성과 성능 요구
일반적으로 NoSQL은 RDBMS와 대비해서 확장성이 뛰어나고 속도가 빠른 특징을 갖지만 궁극적 일관성(eventual consistency)을 지원해 높은 일관성을 요하는 기능에서는 적합하지 않을 수 있다. 따라서 성능과 일관성 면에서 사용하려는 NoSQL이 적합한지 검증하는 단계가 필요하다.
4) 운영과 개발 역량
NoSQL을 적용하면 운영과 개발 역량 확보가 필요하다. NoSQL은 백업, 모니터링, 확장 등 관리가 복잡할 수 있기 때문이다. SQL의 조인을 사용하는 것에 익숙한 개발자는 NoSQL이 제공하는 데이터 모델을 사용하는 데에 어려움을 겪을 수 있다. 따라서 NoSQL을 도입할 때에는 팀이 가진 경험을 고려해야 하며 필요하다면 미리 학습해서 기술을 익혀야 한다.
4. CAP 정리
분산 시스템에서 주로 언급되는 이론으로 CAP 정리가 있다. CAP 정리는 다음 세 조건을 모두 만족하는 분산 시스템은 존재하지 않는다는 것을 증명한 정리이다.
- 일관성(Consistency) : 모든 노드가 같은 순간에 같은 데이터를 볼 수 있다. 한 노드의 데이터가 변경되면 모든 노드의 데이터도 동일한 값으로 바뀐다.
- 가용성(Availability) : 모든 요청이 성공 또는 실패 결과를 반환할 수 있다.
- 분할내성(Partition tolerance) : 네트워크 장애가 발생해도 시스템이 계속 동작할 수 있다.
CAP정리에 따르면 위 조건 중 최대 2가지만 충족할 수 있다.

CAP 정리에 따르면 다음의 세 종류로 DB를 나눌 수 있다.
- CA
- 모든 노드에서 일관성과 가용성을 제공한다.
- 즉 모든 노드에서 변경된 최종 값을 사용하고 일부 노드가 다운되어도 나머지 노드가 동작한다.
- RDBMS가 CA에 해당한다.
- AP
- 가용성을 우선하며 분할내성을 제공한다.
- 노드 간에 네트워크 분할이 발생하면 일관성을 포기하고 기능을 계속한다(가용성).
- 컬럼 패밀리 DB인 Cassandra가 AP에 해당한다.
- CP
- 일관성을 우선하며 분할내성을 제공한다.
- 네트워크 분할이 발생하면 일관성을 보장할 수 없으므로 분할이 해결될 때까지 (일부 또는 전체) 기능을 차단한다.
- 문서DB인 MongoDB가 CP에 해당한다.
NoSQL은 분산 시스템을 기반으로 하고 있기 때문에 분할내성(P, Partition tolerance)을 기본으로 한다. 따라서 NoSQL은 가용성(AP)이나 일관성(CP)을 우선하는 설계를 선택한다. 따라서 서비스 품질 속성에서 가용성과 일관성 중 무엇을 중점에 두느냐에 따라 선택할 수 있는 NoSQL도 달라진다.
5. 마치며
느리게 공부하고 기록한 과정이 약 4개월 2주만에 마침표를 찍었다.
작년 9월에 본격적인 이직 준비를 하겠다며 이 책을 구매했지만, 속도가 더뎌 10월, 11월, 12월 많이 공부를하지 못했다. 그래서 올해 유일한 목표는 이직 성공으로 정하고 출근 전 스터디카페에서, 주말에 집에서 이 책을 이론적으로 한 번 훑고 블로그에 내용을 정리해서 올렸다. 시간과 체력이 한정적이라 속도가 더디긴 했지만 결국 마무리 했다는 게 후련하고, 이제 다음 단계로 넘어갈 수 있을 것 같아 마음이 가볍다. 결국 이 과정이 오래 걸리더라도 꼭 거쳐야 할 과정으로 생각한 이유는 기본적인 백엔드 지식을 쌓아서 기본적인 상황에서 어버버하지 않기 위해, 추후 면접을 보게 되었을 때 빠르게 참고할 정리된 자료가 높은 확률로 필요할 것 같았기 때문이다.
이제 기본적인 건 습득을 했으니 실용적이고 실무적인 것으로 넘어가고 추후 이직 성공으로도 결과가 이어졌으면 한다. 기록 끝!
'기타 > 책' 카테고리의 다른 글
| [주니어 백엔드 개발자가 반드시 알아야 할 실무지식] 12. 성능 테스트 (0) | 2026.05.05 |
|---|---|
| [주니어 백엔드 개발자가 반드시 알아야 할 실무지식] 11. 서버 구조/설계 (0) | 2026.05.03 |
| [주니어 백엔드 개발자가 반드시 알아야 할 실무지식] 10. 네트워크 기초 (0) | 2026.05.03 |
| [주니어 백엔드 개발자가 반드시 알아야 할 실무지식] 9.2 서버 (0) | 2026.04.26 |
| [주니어 백엔드 개발자가 반드시 알아야 할 실무지식] 9.1 서버 (0) | 2026.04.26 |