결정: SQL인가 NoSQL인가(어떤 데이터베이스 계열인가)?

올바른 데이터베이스 계열 선택은 데이터 모델의 형태, 일관성과 확장성의 우선순위, 쿼리 복잡도로 결정된다. 'NoSQL이 더 현대적'이라는 식의 일반화는 오해를 낳는다. 각 계열은 특정 접근 패턴을 위해 설계되었다. 이 트리는 데이터 구조에서 출발해 관계형, 문서형, 키-값, 검색 엔진 중 올바른 도구로 안내하며, 필요 시 폴리글랏 접근 방식을 상기시킨다.

데이터의 성격과 지배적인 접근 패턴은 무엇인가?

가장 결정적인 질문부터 시작한다: 데이터가 강한 관계를 가진 구조화된 레코드인가, 유연/가변 스키마의 문서인가, 단순 키-값 조회인가, 아니면 텍스트 검색 같은 특수한 요구인가? 데이터의 형태와 조회 방식이 계열을 대부분 결정한다.

• 관계형, 구조화된 레코드와 복잡한 쿼리
• 유연/가변 스키마의 중첩 문서
• 단순 키-값, 매우 낮은 지연/캐싱
• 전문(full-text) / 패싯 검색, 로그 분석

강한 일관성(ACID)과 수평 확장 중 무엇이 우선인가?

데이터는 관계형으로 보인다. 그렇다면 우선순위는 무엇인가? 다중 테이블 조인, 트랜잭션 무결성, 강한 일관성(ACID)이 필수인가, 아니면 단일 노드에 담기지 않는 대용량을 수평 확장하는 것인가? 관계형 모델은 대부분의 워크로드에 올바른 기본값이며, 확장 규모가 실제로 단일 노드를 넘어설 때만 한계에 부딪힌다.

• ACID, 조인, 복잡한 쿼리 무결성이 우선
• 무엇보다 확장성, 약한 관계/조인

권장: 관계형 데이터베이스(RDBMS)

강한 관계를 가진 구조화된 데이터와 트랜잭션 무결성이 필요한 워크로드에 올바른 기본값이다. ACID 보장, 성숙한 SQL 쿼리 엔진, 조인을 통해 복잡한 질의에 안정적으로 응답한다.

권장: 문서 데이터베이스

자주 변경되는 스키마를 가진 유연한 중첩 데이터를 자연스러운 형태(JSON 유사 문서)로 저장한다. 주로 단일 문서 단위로 읽기/쓰기하고, 조인이 적으며, 수평 확장이 필요한 애플리케이션에 적합하다.

권장: 키-값 저장소 / 캐시

키 기반의 매우 빠른 읽기/쓰기가 필요하고 복잡한 쿼리가 필요 없는 워크로드를 위해 설계되었다. 대개 메모리에서 동작하며 마이크로초/밀리초 지연을 제공한다. 캐싱, 세션, 카운터 같은 작업에 이상적이다.

권장: 검색 / 분석 엔진

전문 검색, 관련도 순위, 패싯 필터링, 대용량 로그/텍스트 분석에 특화된 역색인(inverted index) 기반 엔진이다. 관계형 LIKE 쿼리로는 불가능한 검색 경험을 제공한다.