Booil Jung

관계형 데이터베이스

1970년, IBM의 연구원 에드거 F. 커드(Edgar F. Codd)가 발표한 한 편의 논문은 데이터 관리의 역사를 근본적으로 바꾸어 놓았다.1 지난 50여 년간, 그가 제안한 관계형 모델(Relational Model)은 데이터베이스 기술의 확고한 근간으로 자리매김하며 오늘날 우리가 경험하는 디지털 세계의 기반을 구축했다. 본 보고서는 관계형 데이터베이스의 이론적 토대에서 출발하여, 그 실제적 구현, 현대적 도전 과제, 그리고 미래를 향한 진화 과정까지를 체계적으로 고찰하는 것을 목표로 한다.

본 연구의 범위는 관계형 모델의 수학적 기초, 데이터 무결성을 위한 설계 원칙, 표준 질의어 SQL, 주요 관계형 데이터베이스 관리 시스템(RDBMS) 분석, 그리고 NoSQL, NewSQL, 클라우드 컴퓨팅이라는 새로운 패러다임과의 상호작용을 심층적으로 다룬다. 이를 통해 관계형 데이터베이스의 본질적 가치와 현대적 의의를 재조명하고자 한다. 관계형 데이터베이스의 역사는 단순히 기술의 발전사가 아니라, ‘데이터 독립성(Data Independence)’이라는 핵심 철학을 구현하기 위한 이론과 실제의 끊임없는 상호작용 과정이다. 이 철학적 토대 위에서 데이터베이스는 응용 프로그램의 종속물에서 벗어나 독립적인 과학의 영역으로 진입할 수 있었다.

1970년, IBM 산호세 연구소에 재직 중이던 수학자이자 컴퓨터 과학자인 에드거 F. 커드는 ACM(Association for Computing Machinery)의 학술지 ‘Communications of the ACM’에 “A Relational Model of Data for Large Shared Data Banks”라는 제목의 논문을 발표했다.1 이 논문은 데이터베이스 분야를 직관과 경험의 영역에서 엄밀한 수학적 원리에 기반한 과학의 반열로 올려놓은 기념비적인 업적으로 평가받는다.1

커드는 이 논문에서 수학의 집합론에 등장하는 ‘관계(relation)’ 개념을 데이터 구성에 도입할 것을 제안했다. 이를 통해 사용자가 데이터의 물리적 청사진, 즉 데이터가 디스크 상에 어떻게 저장되고 연결되어 있는지 알 필요 없이 정보에 접근할 수 있는 혁신적인 소프트웨어 아키텍처를 제시했다.1 이 논문은 단순한 이론 제시에 그치지 않고, 수십억 달러 규모의 데이터베이스 산업을 탄생시키고 데이터 관리의 패러다임을 근본적으로 전환하는 계기가 되었다. 그 중요성은 2002년 Forbes 매거진이 관계형 모델을 지난 85년간 가장 중요한 혁신 중 하나로 선정한 사실에서도 확인할 수 있다.1

커드의 논문이 발표되기 이전인 1960년대와 1970년대 초반, 데이터베이스 시장은 IBM의 IMS(Information Management System)와 같은 계층형(Hierarchical) 모델과 네트워크(Network) 모델이 지배하고 있었다.4 이 모델들은 데이터를 각각 트리(tree) 또는 그래프(graph) 구조로 저장했으며, 레코드 간의 연결을 물리적인 포인터(pointer)로 직접 유지했다.4 이러한 구조는 특정 데이터 경로에 최적화된 빠른 접근을 제공할 수 있었지만, 치명적인 한계를 내포하고 있었다.

가장 근본적인 문제는 ‘데이터 종속성(Data Dependency)’이었다. 데이터의 저장 구조나 표현 방식이 조금이라도 변경되면, 해당 데이터를 사용하는 모든 응용 프로그램을 찾아 수정해야만 했다.4 예를 들어, 계층 구조에서 새로운 필드를 추가하거나 레코드 간의 연결 관계를 바꾸면, 그 경로를 따라 데이터를 탐색하던 모든 프로그램 코드가 영향을 받았다. 이는 시스템의 유지보수 비용을 기하급수적으로 증가시켰고, 새로운 비즈니스 요구사항에 대응하는 개발 유연성을 심각하게 저해하는 요인이었다. 데이터에 접근하기 위해서는 전문가가 특정 데이터를 추출하는 복잡한 프로그램을 작성해야 했으며, 이는 시간과 비용이 많이 소요되는 작업이었다.1

커드는 이러한 기존 모델의 한계를 극복하기 위한 핵심 철학으로 ‘데이터 독립성’을 제시했다. 그는 논문 서두에서 데이터 독립성을 “응용 프로그램과 단말기 활동이 데이터 유형의 증가 및 데이터 표현 방식의 변경으로부터 독립적인 것”으로 명확히 정의했다.4 이는 관계형 모델이 추구하는 가장 중요한 목표였다.

관계형 모델은 데이터의 논리적 구조(사용자가 테이블 형태로 인식하는 구조)와 물리적 구조(데이터가 디스크에 파일 형태로 저장되는 방식)를 완벽하게 분리함으로써 데이터 독립성을 달성하고자 했다.6 사용자는 데이터 항목의 실제 값(value)에 기반하여 테이블들을 연결하고, 단일 쿼리를 통해 완전히 새로운 형태의 결과 테이블을 얻을 수 있다.5 이 과정에서 데이터가 물리적으로 어디에, 어떤 순서로, 어떤 포인터로 연결되어 저장되어 있는지는 전혀 고려할 필요가 없다. SQL의 공동 개발자인 돈 챔벌린(Don Chamberlin)은 커드의 핵심 사상을 “데이터 항목 간의 관계가 별도로 지정된 연결이나 중첩 구조가 아닌, 항목 자체의 값에 기반해야 한다는 것”으로 정확히 요약했다.5

이러한 관계형 모델의 등장은 기술적 진보를 넘어선 ‘철학적 전환’이었다. 이는 데이터 접근의 패러다임을 ‘어떻게(How)’ 데이터를 찾을 것인가의 문제에서 ‘무엇을(What)’ 원하는가의 문제로 이동시켰다. 계층형/네트워크 모델에서 개발자는 원하는 데이터에 도달하기 위한 탐색 ‘절차(procedure)’를 코드로 상세히 명시해야 했다. 반면, 관계형 모델에서는 SQL과 같은 선언적 언어를 통해 ‘원하는 데이터의 조건’을 ‘선언(declare)’하기만 하면 된다. 그러면 RDBMS가 내부적으로 최적의 실행 계획을 수립하여 결과를 반환한다. 이 철학적 전환은 데이터 접근의 민주화를 이끌었다. 이전에는 고도로 숙련된 프로그래머만 가능했던 데이터 추출 작업을, 이제는 비전문가도 SQL을 통해 비교적 쉽게 수행할 수 있게 된 것이다.1 이는 데이터 기반 의사결정이 조직 전체로 확산되는 결정적인 계기가 되었다.

관계형 모델의 지속적인 영향력과 강점은 그것이 직관적인 테이블 구조를 사용한다는 ‘단순함’에 있는 것이 아니라, 수학적 논리에 기반한 ‘엄밀함’에 있다. 커드는 집합론과 1차 술어 논리라는 견고한 수학적 기반 위에 자신의 모델을 구축함으로써, 데이터베이스 시스템의 논리적 일관성과 예측 가능성을 보장했다.4 이 수학적 토대는 SQL과 같은 고수준의 선언적 언어가 탄생할 수 있는 이론적 배경을 제공했다.

커드의 모델은 다음과 같은 엄밀한 수학적 정의에 기반한다.

• 관계 (Relation): 주어진 집합들 S1,S2,…,Sn (반드시 서로 다를 필요는 없음)에 대하여, 관계 R은 이 집합들상의 n-튜플(n-tuple)들의 집합이다. 각 튜플의 첫 번째 요소는 S1에서, 두 번째 요소는 S2에서 오는 식으로 구성된다.4 현대 데이터베이스 용어로는 테이블(Table)에 해당한다.3

• 도메인 (Domain): 관계 R의 j번째 구성 집합 Sj를 j번째 도메인이라 칭한다.4 이는 특정

  속성(Attribute) 또는 열(Column)이 가질 수 있는 모든 허용 가능한 값들의 집합을 의미한다.9

• 튜플 (Tuple): 관계를 구성하는 하나의 n-튜플. 이는 오늘날 행(Row) 또는 레코드(Record)에 해당한다.9

• 속성 (Attribute): 관계의 각 열을 지칭하며, 특정 엔티티가 가지는 속성을 나타낸다.8

• 차수 (Degree): 관계에 포함된 속성(열)의 개수.4

• 카디널리티 (Cardinality): 관계에 포함된 튜플(행)의 개수.12

관계 대수는 관계(테이블)들을 피연산자로 받아들여 연산을 수행하고, 그 결과로 새로운 관계를 생성하는 연산자들의 집합이다. 이는 원하는 데이터를 얻기 위한 구체적인 절차를 순서대로 명시하는 절차적 언어(procedural language)의 특징을 가진다.7 관계 대수의 주요 연산자들은 다음과 같다.

• 셀렉션 (Selection, σ): 특정 조건을 만족하는 튜플들을 기존 관계에서 선택하여 새로운 관계를 생성한다. SQL의 WHERE 절에 해당한다. \(\sigma_{P}(R)\) 프로젝션 (Projection, Π): 관계에서 특정 속성들만 추출하여 새로운 관계를 생성한다. SQL의 SELECT 절에 해당한다. \(\Pi_{A_1, A_2,..., A_k}(R)\)

• 집합 연산자 (Set Operators): 두 관계가 합집합 호환(union-compatible)일 때, 합집합 (Union, ∪), 차집합 (Difference, −), 교집합 (Intersection, ∩) 연산을 수행할 수 있다.

• 카티전 곱 (Cartesian Product, ×): 두 관계에 속한 모든 튜플들의 가능한 모든 조합을 생성하여 새로운 관계를 만든다.

• 조인 (Join, ⋈): 두 관계에서 공통된 속성의 값이 특정 조건을 만족하는 튜플들을 결합하여 새로운 관계를 생성한다. 이는 관계형 모델에서 가장 중요하고 강력한 연산 중 하나로, 분리된 테이블들을 의미적으로 연결하는 핵심 메커니즘이다.13 가장 일반적인 자연 조인(Natural Join)은 카티전 곱과 셀렉션의 조합으로 표현될 수 있다. \(R \bowtie_{P} S = \sigma_{P}(R \times S)\) 이러한 연산자들은 실제 데이터베이스 질의 최적화기(Query Optimizer)가 SQL 쿼리를 내부적으로 처리하는 방식의 이론적 기반을 형성한다.7

관계 대수가 ‘어떻게(how)’ 데이터를 얻을지를 명시하는 반면, 관계 해석은 ‘무엇을(what)’ 원하는지를 기술하는 비절차적 언어(non-procedural language)이다.7 이는 술어 논리(predicate calculus)에 기반하여 원하는 결과 집합의 특징이나 조건을 선언적으로 명시한다. 관계 해석은 튜플 변수를 사용하는 튜플 관계 해석(Tuple Relational Calculus)과 도메인 변수를 사용하는 도메인 관계 해석(Domain Relational Calculus)으로 나뉜다.

커드의 가장 중요한 이론적 공헌 중 하나는 관계 대수와 관계 해석의 표현력이 수학적으로 동등하다는 것을 증명한 것이다. 이를 커드의 정리(Codd’s Theorem) 또는 관계적 완전성(Relational Completeness)이라고 한다.2 어떤 질의 언어가 관계 대수의 모든 연산자를 표현할 수 있다면, 그 언어는 ‘관계적으로 완전하다’고 정의된다. 이 개념은 SQL과 같은 현대적 질의 언어의 표현력을 평가하고 설계하는 데 있어 객관적인 기준을 제시했다.

이러한 수학적 엄밀함 덕분에 데이터베이스 관리는 특정 구현에 종속된 ‘기술’의 영역을 넘어, 보편적이고 증명 가능한 원리를 갖춘 ‘과학’의 영역으로 진입할 수 있었다.1 SQL이 수십 년간 데이터베이스의 표준 언어로 군림할 수 있었던 근본적인 이유도 바로 이 강력한 이론적 배경에 있다.

수학적 이론으로 정립된 관계형 모델은 실제 데이터베이스 관리 시스템(RDBMS)에서 구체적인 구성 요소들로 구현된다. 이론의 ‘관계’, ‘튜플’, ‘속성’은 각각 ‘테이블’, ‘행’, ‘열’이라는 보다 직관적인 용어로 현실 세계에 적용되었다. 이 과정에서 데이터의 고유성을 보장하고 테이블 간의 논리적 연결을 설정하는 ‘키(Key)’의 개념과, 이 모든 것을 조작하기 위한 표준 언어 ‘SQL’이 핵심적인 역할을 수행한다.

관계형 모델의 수학적 개념들은 실제 RDBMS에서 다음과 같이 구현된다.

• 테이블 (Table): 수학적 ‘관계(relation)’를 시각적으로 표현한 것으로, 데이터를 저장하는 기본 단위다.8
• 행 (Row) / 레코드 (Record): 수학적 ‘튜플(tuple)’에 해당하며, 하나의 개체(entity) 또는 관계 인스턴스에 대한 데이터의 집합이다.11
• 열 (Column) / 속성 (Attribute): 수학적 ‘속성(attribute)’에 해당하며, 개체가 가지는 특정 속성을 나타낸다.8

이러한 테이블은 몇 가지 중요한 특성을 가진다. 첫째, 행과 열의 물리적 저장 순서는 논리적으로 의미가 없다.13 둘째, 테이블의 각 셀(행과 열이 만나는 지점)은 단 하나의 값만을 가져야 하며, 이 값은 더 이상 분해될 수 없는 원자적(atomic) 값이어야 한다.3 셋째, 특정 열에 속한 모든 값은 반드시 동일한 데이터 타입, 즉 동일한 도메인(domain)에 속해야 한다.13

키(Key)는 테이블 내에서 각 행을 고유하게 식별하거나 테이블 간의 관계를 설정하는 데 사용되는 하나 이상의 속성 집합이다.8 이는 데이터의 무결성, 고유성 보장 및 효율적인 데이터 검색을 위한 핵심적인 장치다.15 키는 그 역할과 특성에 따라 다음과 같이 다양하게 분류된다.

• 슈퍼키 (Super Key): 테이블 내의 튜플을 고유하게 식별할 수 있는 하나 이상의 속성들의 집합이다. 유일성은 만족하지만, 최소성은 만족하지 않을 수 있다. 예를 들어, ‘학생’ 테이블에서 {학번}이 튜플을 고유하게 식별한다면, {학번, 이름}이나 {학번, 주민번호} 등 학번을 포함하는 모든 속성의 조합은 슈퍼키가 된다.9
• 후보키 (Candidate Key): 슈퍼키 중에서 튜플을 고유하게 식별하는 데 필요한 최소한의 속성들로만 구성된 집합이다. 즉, 유일성과 최소성을 모두 만족해야 한다. ‘학생’ 테이블에서 {학번}과 {주민번호}가 각각 튜플을 고유하게 식별할 수 있다면, 이 둘은 모두 후보키가 된다.11
• 기본키 (Primary Key, PK): 여러 후보키 중에서 데이터베이스 설계자가 주 식별자로 선택한 단 하나의 키다. 기본키는 NULL 값을 가질 수 없으며(NOT NULL), 테이블 내에서 절대 중복된 값을 가져서는 안 된다(UNIQUE). 테이블의 각 행을 대표하는 가장 중요한 고유 식별자 역할을 한다.11
• 대체키 (Alternate Key): 후보키 중에서 기본키로 선택되지 않은 나머지 키들을 지칭한다. 예를 들어, {학번}이 기본키로 선택되었다면 {주민번호}는 대체키가 된다.15
• 외래키 (Foreign Key, FK): 한 테이블(자식 테이블)에 있는 속성이 다른 테이블(부모 테이블)의 기본키를 참조하는 것을 말한다. 이는 테이블 간의 관계(relationship)를 설정하고, 부모 테이블에 존재하는 값만 자식 테이블에서 참조할 수 있도록 보장하는 ‘참조 무결성(Referential Integrity)’을 유지하는 핵심적인 역할을 한다.11 외래키는 참조하는 기본키와 달리 중복된 값을 가질 수 있으며, 경우에 따라 NULL 값을 허용할 수도 있다.17
• 복합키 (Composite Key): 두 개 이상의 속성을 조합하여 하나의 기본키를 구성하는 경우를 말한다. 예를 들어, ‘수강’ 테이블에서는 {학생ID, 과목ID}의 조합이 하나의 수강 기록을 고유하게 식별하는 복합키가 될 수 있다.9

아래 표는 주요 데이터베이스 키의 유형과 그 특성을 비교한 것이다.

키 종류	유일성 (Uniqueness)	최소성 (Minimality)	NULL 허용	주된 역할
슈퍼키 (Super Key)	O	X	일부 허용	튜플을 식별하는 모든 속성 조합
후보키 (Candidate Key)	O	O	불가	기본키가 될 수 있는 최소 식별자
기본키 (Primary Key)	O	O	불가	튜플을 대표하는 주 식별자
대체키 (Alternate Key)	O	O	일부 허용	기본키로 선택되지 않은 후보키
외래키 (Foreign Key)	X	해당 없음	일부 허용	다른 테이블을 참조하여 관계 설정

SQL(Structured Query Language)은 관계형 데이터베이스를 관리하고 조작하기 위해 만들어진 표준 프로그래밍 언어다.8 1970년대 초 IBM의 System R 프로젝트에서 돈 챔벌린(Don Chamberlin)과 레이먼드 보이스(Raymond Boyce)에 의해 개발되었으며, 관계 대수와 관계 해석의 이론적 개념을 실제 사용 가능한 언어로 구현한 것이다.1 SQL 명령어는 그 기능에 따라 크게 세 가지 하위 언어로 분류된다.

• DDL (Data Definition Language, 데이터 정의어): 데이터베이스 객체(테이블, 뷰, 인덱스 등)의 구조, 즉 스키마를 정의, 수정, 삭제하는 데 사용된다. 주요 명령어로는 CREATE, ALTER, DROP, TRUNCATE가 있다. DDL 명령어는 실행되는 즉시 데이터베이스에 영구적으로 반영되는 자동 커밋(Auto-commit) 특성을 가지므로, 실행 취소(Rollback)가 불가능하다.22
• DML (Data Manipulation Language, 데이터 조작어): 테이블에 저장된 데이터를 조회(SELECT), 삽입(INSERT), 수정(UPDATE), 삭제(DELETE)하는 데 사용된다. DML 명령어는 트랜잭션의 일부로 간주되어, 실행 후 COMMIT 명령어를 통해 변경 사항을 영구적으로 저장하거나 ROLLBACK 명령어를 통해 이전 상태로 되돌릴 수 있다.24
• DCL (Data Control Language, 데이터 제어어): 데이터베이스 사용자에게 특정 객체에 대한 접근 권한을 부여(GRANT)하거나 회수(REVOKE)하는 데 사용된다. 데이터 보안과 접근 제어를 담당하는 핵심적인 역할을 한다.25

아래 표는 SQL 명령어의 분류와 각 분류의 주요 특징을 요약한 것이다.

분류	역할 (Purpose)	주요 명령어	트랜잭션 제어
DDL	데이터 구조 정의 및 관리	CREATE, ALTER, DROP, TRUNCATE	자동 커밋 (롤백 불가)
DML	데이터 조작 (조회, 삽입, 수정, 삭제)	SELECT, INSERT, UPDATE, DELETE	수동 제어 (COMMIT/ROLLBACK 필요)
DCL	사용자 권한 부여 및 회수	GRANT, REVOKE	자동 커밋 (롤백 불가)

관계형 데이터베이스 설계의 핵심 목표 중 하나는 데이터의 무결성(Integrity)과 일관성(Consistency)을 유지하는 것이다. 이를 달성하기 위한 가장 체계적이고 이론적인 방법론이 바로 정규화(Normalization)이다. 정규화는 단순히 데이터의 중복을 제거하는 기술적 과정을 넘어, 데이터 간의 논리적 관계를 명확히 분석하여 데이터 모델의 구조적 안정성과 예측 가능성을 확보하는 설계 철학에 가깝다.

정규화는 데이터의 중복성을 최소화하고 데이터 무결성을 향상시키기 위해, 크고 비효율적인 테이블을 더 작고 잘 구조화된 테이블들로 분해하는 체계적인 과정이다.31 정규화되지 않은 테이블에서는 데이터의 중복으로 인해 다음과 같은 세 가지 주요 이상 현상(Anomalies)이 발생할 수 있다.34

• 삽입 이상 (Insertion Anomaly): 새로운 데이터를 추가하려 할 때, 불필요한 다른 데이터가 존재하지 않으면 삽입할 수 없는 문제. 예를 들어, ‘수강’ 테이블에 (학번, 이름, 주소, 과목코드, 과목명) 속성이 모두 포함되어 있을 때, 아직 아무 과목도 수강 신청하지 않은 신입생의 정보(학번, 이름, 주소)를 등록할 수 없다. 과목코드가 비어있을 수 없기 때문이다.
• 갱신 이상 (Update Anomaly): 중복 저장된 데이터 중 일부만 수정되어 데이터 간의 불일치가 발생하는 문제. 앞선 예에서 한 학생이 여러 과목을 수강할 경우, 그 학생의 주소 정보가 수강 과목 수만큼 중복 저장된다. 만약 이 학생이 이사를 가서 주소를 변경해야 할 때, 중복된 모든 행의 주소를 빠짐없이 수정하지 않으면 어떤 주소가 올바른 정보인지 알 수 없게 된다.
• 삭제 이상 (Deletion Anomaly): 특정 데이터를 삭제할 때, 의도치 않게 유지되어야 할 다른 정보까지 함께 삭제되는 문제. 만약 한 학생이 단 하나의 과목만 수강하고 있다가 그 수강을 취소하면, 해당 행이 삭제되면서 그 학생의 학번, 이름, 주소 정보까지 데이터베이스에서 완전히 사라져 버릴 수 있다.

정규화는 이러한 이상 현상들을 방지하여 데이터의 일관성을 유지하고, 저장 공간의 낭비를 줄이며, 데이터 구조의 유연성을 높이는 것을 목표로 한다.

정규화 과정의 이론적 기반은 함수 종속성 개념에 있다. 릴레이션 내에서 어떤 속성 집합 X의 값이 다른 속성 집합 Y의 값을 유일하게 결정할 때, “Y는 X에 함수적으로 종속된다”고 정의하며, 이를 X–»Y로 표기한다.37 여기서 X를 결정자(Determinant), Y를 종속자(Dependent)라고 한다. 예를 들어, ‘학생’ 테이블에서 학번이 이름을 유일하게 결정하므로 학번 –» 이름 이라는 함수 종속 관계가 성립한다. 정규화는 이러한 함수 종속 관계를 분석하여 테이블을 분해하는 과정이며, 주요 종속성 유형은 다음과 같다.

• 완전 함수 종속 (Full Functional Dependency): 어떤 속성이 기본키 전체에 종속되며, 기본키를 구성하는 어떠한 진부분집합(proper subset)에도 종속되지 않는 상태를 의미한다. 제2정규형은 모든 비-키 속성이 기본키에 완전 함수 종속될 것을 요구한다.37
• 부분 함수 종속 (Partial Functional Dependency): 복합 기본키(composite primary key)로 구성된 테이블에서, 비-키 속성이 기본키의 일부 속성에만 종속되는 경우를 말한다. 이는 제2정규화 과정에서 제거해야 할 대상이다.33
• 이행적 함수 종속 (Transitive Functional Dependency): 결정자가 후보키가 아닌 함수 종속 관계를 의미한다. 즉, A–»B 이고 B–»C 라는 종속 관계가 있을 때, A가 후보키가 아니라면 A–»C는 이행적 종속이 된다. 이는 제3정규화 과정에서 제거해야 할 대상이다.31

정규화는 단계적인 프로세스로 진행되며, 각 정규형(Normal Form)은 이전 단계의 정규형을 만족해야 한다.33

• 제1정규형 (1NF): 테이블의 모든 속성 값이 원자적(atomic) 값을 가져야 한다는 규칙이다. 즉, 하나의 셀에 리스트나 배열과 같은 다중 값이 포함되어서는 안 된다.32
  • 예시: (고객ID, 구매상품) 테이블에서 ‘구매상품’ 열에 “노트북, 마우스”와 같이 여러 값이 쉼표로 구분되어 있다면 1NF를 위반한다. 이를 해결하기 위해 테이블을 (고객ID, 구매상품)으로 재구성하고, 각 구매 건을 별도의 행으로 분리해야 한다: (101, 노트북), (101, 마우스).34
• 제2정규형 (2NF): 테이블이 1NF를 만족하고, 모든 비-키(non-key) 속성이 기본키 전체에 완전 함수 종속되어야 한다. 이는 복합 기본키를 사용하는 테이블에서 부분 함수 종속을 제거하는 것을 의미한다.31
  • 예시: (주문번호, 제품번호)가 기본키인 주문상세 테이블에 (주문번호, 제품번호, 고객명, 제품명, 수량) 속성이 있다고 가정하자. 여기서 고객명은 기본키의 일부인 주문번호에만 종속되고, 제품명은 제품번호에만 종속된다. 이는 부분 함수 종속이다. 2NF를 만족시키기 위해 이 테이블을 주문(주문번호, 고객명), 제품(제품번호, 제품명), 주문상세(주문번호, 제품번호, 수량) 세 개의 테이블로 분해해야 한다.
• 제3정규형 (3NF): 테이블이 2NF를 만족하고, 이행적 함수 종속이 존재하지 않아야 한다. 즉, 키가 아닌 모든 속성은 다른 키가 아닌 속성에 의존해서는 안 되며, 오직 기본키에만 직접적으로 종속되어야 한다.31
  • 예시: (사원번호, 사원명, 부서코드, 부서명) 테이블에서 사원번호가 기본키라고 하자. 여기서 부서명은 부서코드에 의해 결정되고(부서코드 –» 부서명), 부서코드는 사원번호에 의해 결정된다(사원번호 –» 부서코드). 따라서 사원번호 –» 부서명은 이행적 종속 관계다. 3NF를 만족시키기 위해 이 테이블을 사원(사원번호, 사원명, 부서코드)와 부서(부서코드, 부서명) 두 테이블로 분해해야 한다.
• 보이스-커드 정규형 (BCNF): 3NF보다 더 엄격한 조건을 요구하는 정규형이다. 테이블에 존재하는 모든 함수 종속성 X–»Y에 대해, 결정자 X가 반드시 슈퍼키여야 한다는 규칙이다.32 3NF가 해결하지 못하는 일부 특수한 이상 현상을 해결할 수 있다.
  • 예시: (학생, 과목, 교수) 테이블이 있고, 다음과 같은 제약 조건이 있다고 가정하자: (1) 한 학생은 여러 과목을 수강할 수 있다. (2) 한 과목은 여러 교수가 강의할 수 있다. (3) 특정 과목에 대해, 한 학생은 단 한 명의 교수에게만 배정된다. 이 경우 후보키는 {학생, 과목}이다. 그런데 만약 (4) 한 교수는 오직 한 과목만 강의한다는 추가 제약이 있다면, 교수 –» 과목이라는 함수 종속이 발생한다. 여기서 결정자인 교수는 후보키가 아니므로 BCNF를 위반한다. 이를 해결하려면 테이블을 (학생, 교수)와 (교수, 과목)으로 분해해야 한다.

잘 정규화된 데이터베이스는 단순히 저장 공간을 절약하는 것을 넘어, 데이터 모델 자체가 비즈니스 규칙을 명확하게 반영하게 된다. 이는 데이터의 의미를 풍부하게 하고, 향후 시스템 확장에 대한 유연성을 제공하며, 데이터의 일관성을 시스템 수준에서 보장하는 강력한 메커니즘으로 작용한다.

다수의 사용자가 동시에 데이터베이스에 접근하고 수정하는 환경에서 데이터의 무결성과 일관성을 유지하는 것은 매우 중요하다. 관계형 데이터베이스는 이러한 문제를 해결하기 위해 ‘트랜잭션(Transaction)’이라는 개념과 이를 보장하기 위한 네 가지 핵심 원칙, 즉 ACID를 도입했다. ACID는 기술적 속성의 나열을 넘어, 다중 사용자 환경에서 데이터의 ‘신뢰성(Reliability)’을 보장하기 위한 일종의 사회적 계약과 같으며, 각 속성은 서로를 긴밀하게 보완하며 완전한 신뢰 체계를 구축한다.

트랜잭션은 데이터베이스의 상태를 변화시키는 하나의 논리적인 작업 단위(a single logical unit of work)로 정의된다.44 이는 데이터베이스에 대해 수행되는 하나 이상의 SQL 문(statements)으로 구성될 수 있다. 트랜잭션의 가장 대표적인 예는 은행의 계좌 이체다. A 계좌에서 10만 원을 출금하고 B 계좌에 10만 원을 입금하는 과정은 ‘출금’과 ‘입금’이라는 두 개의 개별적인 데이터베이스 연산으로 이루어진다. 하지만 이 두 연산은 논리적으로 절대 분리되어서는 안 된다. 출금만 성공하고 입금이 실패한다면 시스템의 총액이 맞지 않게 되어 데이터의 일관성이 파괴된다. 따라서 이 두 연산은 반드시 하나의 묶음으로 처리되어야 하며, 이것이 바로 트랜잭션이다.44

ACID는 데이터베이스 트랜잭션이 시스템 오류, 정전, 동시성 문제 등 예기치 않은 상황에서도 데이터의 유효성과 신뢰성을 보장하기 위한 네 가지 핵심 속성(원자성, 일관성, 고립성, 지속성)의 약어다.44 이는 관계형 데이터베이스가 금융, 전자상거래 등 미션 크리티컬한 시스템에서 오랫동안 절대적인 지위를 유지할 수 있었던 근본적인 이유다.47

• 원자성 (Atomicity): 트랜잭션은 ‘전부 아니면 전무(All or Nothing)’ 원칙에 따라 처리되어야 한다. 트랜잭션에 포함된 모든 연산이 성공적으로 완료되어야만 해당 트랜잭션이 성공적으로 커밋(Commit)된다. 만약 연산 중 하나라도 실패하면, 이전에 실행되었던 모든 연산이 취소(Rollback)되고 데이터베이스는 트랜잭션 시작 이전의 상태로 완벽하게 되돌아간다. 부분적인 성공은 절대 허용되지 않는다.44 이는 작업의 완전성을 보장한다.

• 일관성 (Consistency): 트랜잭션은 데이터베이스를 하나의 ‘일관된(valid)’ 상태에서 또 다른 ‘일관된’ 상태로 전환시켜야 한다. 트랜잭션의 실행 전과 후, 데이터베이스는 사전에 정의된 모든 규칙과 제약 조건(예: 기본키의 고유성, 외래키의 참조 무결성, 특정 열의 값 범위 등)을 항상 만족해야 한다.44 예를 들어, 두 계좌의 잔고 합계가 항상 일정해야 한다는 비즈니스 규칙이 있다면(

  A+B=100), 계좌 이체 트랜잭션이 완료된 후에도 이 규칙은 반드시 지켜져야 한다.44 원자성이 깨지면(출금만 되고 입금은 안 되면) 일관성 역시 자연스럽게 깨지게 된다.

• 고립성 (Isolation): 여러 트랜잭션이 동시에 실행될 때, 각 트랜잭션은 서로에게 영향을 주지 않고 마치 순차적으로 실행되는 것처럼 독립적으로 수행되어야 한다. 즉, 특정 트랜잭션이 실행되는 동안의 중간 결과는 다른 트랜잭션에게 노출되어서는 안 된다.44 이는 동시성 제어(Concurrency Control)를 통해 달성되며, 일반적으로 락(Locking)이나 다중 버전 동시성 제어(Multi-Version Concurrency Control, MVCC)와 같은 메커니즘을 통해 구현된다. 고립성이 보장되지 않으면, 한 트랜잭션이 다른 트랜잭션의 미완료된 데이터를 읽어(Dirty Read) 잘못된 결정을 내리고 결과적으로 데이터의 일관성을 해칠 수 있다.

• 지속성 (Durability): 성공적으로 완료(Commit)된 트랜잭션의 결과는 영구적으로 데이터베이스에 저장되어야 한다. 트랜잭션 커밋 이후에 시스템 장애(예: 정전, 서버 다운)가 발생하더라도 해당 데이터는 손실되지 않아야 한다.44 이는 일반적으로 변경 사항을 디스크에 기록하기 전에 로그(Write-Ahead Log, WAL)에 먼저 기록하는 방식을 통해 보장된다. 지속성이 없다면, 원자성, 일관성, 고립성을 모두 지켜 성공적으로 완료된 트랜잭션의 결과가 사라져 버릴 수 있으므로, ACID의 다른 모든 원칙이 무의미해진다.

이 네 가지 원칙은 독립적으로 존재하지 않고 유기적으로 연결되어 있다. 하나가 무너지면 다른 원칙들도 위협받으며, 이들이 모두 함께 지켜질 때 비로소 데이터베이스 시스템의 신뢰성이 완벽하게 보장될 수 있다.

관계형 모델의 이론은 다양한 상용 및 오픈소스 관계형 데이터베이스 관리 시스템(RDBMS)을 통해 현실 세계에 구현되었다. 각 RDBMS는 관계형 모델의 기본 원칙을 공유하면서도, 고유한 아키텍처, 성능 특성, 기능적 강점을 바탕으로 특정 시장과 사용 사례에 최적화되어 발전해왔다. 본 장에서는 현재 시장을 주도하고 있는 대표적인 네 가지 RDBMS인 MySQL, PostgreSQL, Oracle Database, Microsoft SQL Server를 심층적으로 분석한다.

• 특징: 세계에서 가장 널리 사용되는 오픈소스 RDBMS로, 특히 웹 애플리케이션 개발 분야에서 압도적인 점유율을 자랑한다. LAMP(Linux, Apache, MySQL, PHP/Python/Perl) 스택의 핵심 구성 요소로서, 사용 편의성과 빠른 읽기 성능, 방대한 사용자 커뮤니티가 가장 큰 특징이다.52
• 장점: 커뮤니티 에디션은 무료로 사용할 수 있어 비용 효율적이며, 설치와 사용법이 비교적 간단하여 진입 장벽이 낮다. 또한, 오랜 역사만큼 풍부한 문서와 활발한 커뮤니티를 통해 문제 해결이 용이하다.55
• 단점: 대규모 데이터베이스나 복잡한 쿼리가 많은 환경에서는 성능 저하가 발생할 수 있다. 고급 SQL 기능(예: 윈도우 함수, CTE) 지원이 다른 RDBMS에 비해 제한적이었으며, 복잡한 복제 및 고가용성(High Availability) 구성이 상대적으로 어렵다는 평가를 받는다.52

• 주요 사용 사례: 블로그, 포럼과 같은 콘텐츠 관리 시스템(CMS), 중소규모의 웹사이트 및 전자상거래 플랫폼의 백엔드 데이터베이스로 널리 활용된다.53

• 특징: ‘세상에서 가장 진보한 오픈소스 관계형 데이터베이스’를 표방하며, SQL 표준을 매우 엄격하게 준수하고 뛰어난 확장성을 제공한다. JSON, XML, Geospatial(지리공간) 데이터 등 다양한 비정형 데이터 타입을 네이티브하게 지원하며, 사용자 정의 함수, 연산자, 데이터 타입을 생성할 수 있는 등 객체-관계형 데이터베이스(ORDBMS)의 특징을 강하게 가진다.58
• 장점: 강력한 SQL 표준 준수, ACID 트랜잭션의 완벽한 지원, MVCC를 통한 높은 동시성 처리 능력, 고급 인덱싱 기법과 정교한 쿼리 최적화기, 그리고 외부 데이터 소스를 로컬 테이블처럼 다룰 수 있는 FDW(Foreign Data Wrappers) 기능이 뛰어나다.58
• 단점: MySQL에 비해 상대적으로 설정 및 관리가 복잡하여 초기 학습 곡선이 가파를 수 있다. 단순한 읽기 중심의 작업에서는 MySQL보다 성능이 다소 떨어질 수 있다는 인식이 있다.58

• 주요 사용 사례: 복잡한 쿼리와 데이터 분석이 요구되는 데이터 웨어하우징, 비즈니스 인텔리전스(BI) 시스템, 금융 거래 시스템, PostGIS 확장을 활용한 지리정보시스템(GIS) 등에서 강력한 성능을 발휘한다.58

• 특징: 대규모 기업(Enterprise) 시장의 전통적인 절대 강자다. 최고의 성능, 수직/수평적 확장성, 강력한 보안 기능, 그리고 포괄적인 고가용성 솔루션으로 명성이 높다. 다양한 하드웨어 및 운영체제 플랫폼을 지원하며, 미션 크리티컬한 대규모 시스템에 주로 사용된다.63
• 장점: 대용량 데이터 처리와 높은 트랜잭션 환경에서의 안정성과 성능은 타의 추종을 불허한다. Real Application Clusters(RAC)와 같은 고가용성 기술, 세밀한 접근 제어와 암호화 등 강력한 보안 기능, 포괄적인 백업 및 복구 솔루션을 제공한다.63
• 단점: 매우 높은 라이선스 비용과 유지보수 비용이 가장 큰 단점이다. 시스템을 운영하기 위한 하드웨어 요구사항이 높고, 기능이 방대한 만큼 시스템이 극도로 복잡하여 숙련된 데이터베이스 관리자(DBA)를 필요로 한다.63

• 주요 사용 사례: 대규모 금융 시스템, 전사적 자원 관리(ERP), 고객 관계 관리(CRM), 공급망 관리(SCM), 데이터 웨어하우징 등 안정성과 성능이 최우선시되는 모든 엔터프라이즈급 애플리케이션에서 사용된다.63

• 특징: Microsoft Windows 서버 환경에 최적화된 RDBMS로,.NET 프레임워크, Azure 클라우드, Power BI 등 다른 Microsoft 제품군과의 뛰어난 통합성을 자랑한다. 직관적인 관리 도구(SSMS)와 강력한 비즈니스 인텔리전스(BI) 및 분석 도구가 내장된 것이 큰 강점이다.68
• 장점: Microsoft 생태계 내에서의 완벽한 통합으로 개발 및 운영이 편리하다. SQL Server Analysis Services(SSAS), Reporting Services(SSRS) 등 강력한 BI 및 리포팅 도구를 기본 제공한다. Enterprise부터 무료 버전인 Express까지 다양한 에디션을 제공하여 선택의 폭이 넓다.68
• 단점: Enterprise 에디션의 라이선스 비용이 비싸고, 라이선스 정책이 복잡하다. 전통적으로 Windows 환경에 종속적이었으며(최근 Linux 지원 강화), 이로 인한 벤더 종속성(vendor lock-in)이 발생할 수 있다.69
• 주요 사용 사례: Windows 서버 기반의 엔터프라이즈 애플리케이션, 데이터 웨어하우징, BI 및 리포팅 시스템 등 Microsoft 기술 스택을 중심으로 하는 환경에서 주로 선택된다.70

아래 표는 앞서 분석한 네 가지 주요 RDBMS의 핵심 특징을 비교한 것이다.

구분	MySQL	PostgreSQL	Oracle Database	Microsoft SQL Server
라이선스 모델	오픈소스 (GPL) / 상용	오픈소스 (PostgreSQL License)	상용	상용 / 무료(Express, Developer)
주요 강점	사용 편의성, 빠른 읽기 성능, 웹 생태계	SQL 표준 준수, 높은 확장성, 데이터 타입 다양성	최고 수준의 성능, 확장성, 보안, 고가용성	Microsoft 생태계 통합, 강력한 BI 도구
주요 약점	고급 기능 제한, 복잡한 트랜잭션 처리	상대적 복잡성, 낮은 인지도	높은 비용, 극도의 복잡성	높은 비용, 벤더 종속성
성능 특성	읽기 중심 워크로드에 최적화	복잡한 쿼리 및 쓰기/읽기 혼합 워크로드	대규모 OLTP 및 데이터 웨어하우징	Windows 환경 최적화, BI 워크로드
확장성	수직적 확장 중심	수직적 확장 중심, FDW 통한 분산	수직적 및 수평적 확장(RAC)	수직적 확장 중심, 클러스터링 지원
대표 사용 사례	웹 애플리케이션, CMS, 중소규모 서비스	데이터 분석, GIS, 복잡한 비즈니스 로직	대기업 ERP, 금융, 통신 등 미션 크리티컬 시스템	Windows 기반 기업용 애플리케이션, BI
생태계/커뮤니티	가장 큰 사용자 커뮤니티	강력하고 기술 중심적인 커뮤니티	거대 기업 생태계, 전문 컨설팅	Microsoft 중심의 강력한 개발자/기업 생태계

관계형 데이터베이스는 지난 반세기 동안 데이터 관리의 표준으로 자리 잡으며 그 가치를 입증해왔다. 그러나 기술 환경이 급변하면서 그 한계 또한 명확해졌다. 관계형 데이터베이스의 장점과 단점은 동전의 양면과 같이, 그 본질적인 특징인 ‘엄격한 구조’에서 비롯된다. 이 ‘구조’는 데이터 무결성이라는 강력한 장점을 제공하는 동시에, 유연성과 확장성 측면에서는 한계로 작용한다.

• 데이터 무결성 및 정확성: 관계형 데이터베이스의 가장 큰 장점은 데이터의 무결성을 시스템 수준에서 보장한다는 점이다. 정규화 과정을 통해 데이터 중복을 최소화하고, 기본키(Primary Key)와 외래키(Foreign Key)를 통해 테이블 간의 관계를 명확히 정의함으로써 데이터의 일관성과 정확성을 유지한다.50
• ACID 규정 준수: 모든 트랜잭션이 원자성(Atomicity), 일관성(Consistency), 고립성(Isolation), 지속성(Durability)을 보장하는 ACID 원칙을 준수한다. 이는 데이터의 신뢰성을 극대화하며, 특히 금융 거래, 주문 처리, 재고 관리와 같이 데이터의 정확성이 비즈니스의 성패를 좌우하는 시스템에서 필수적인 요건이다.50
• 사용 편의성 및 표준화: SQL이라는 표준화된 선언적 질의 언어를 사용한다. SQL은 영어와 유사한 문법 구조를 가지고 있어 배우기 쉽고, 사용자는 ‘어떻게’ 데이터를 가져올지 고민할 필요 없이 ‘무엇을’ 원하는지만 명시하면 된다. 이를 통해 복잡한 데이터 조회, 집계, 조작을 효율적으로 수행할 수 있다.50
• 보안: 역할 기반 접근 제어(Role-Based Access Control, RBAC)와 같은 정교한 보안 모델을 기본적으로 제공한다. 이를 통해 사용자별로 테이블, 뷰, 심지어 특정 열(column)에 대한 접근 권한까지 세밀하게 제어하여 민감한 데이터를 보호할 수 있다.74

이러한 강력한 장점에도 불구하고, 관계형 데이터베이스는 현대의 빅데이터 및 웹 스케일 환경에서 다음과 같은 한계를 드러낸다.

• 확장성 문제 (Scalability): 전통적인 RDBMS는 주로 단일 서버의 CPU, 메모리, 저장 공간을 증설하는 수직적 확장(Vertical Scaling 또는 Scale-up)에 최적화되어 있다. 그러나 이 방식은 하드웨어 성능의 물리적 한계에 부딪히고 비용이 기하급수적으로 증가하는 단점이 있다. 반면, 여러 대의 저렴한 서버를 클러스터로 묶어 부하를 분산하는 수평적 확장(Horizontal Scaling 또는 Scale-out)은 RDBMS의 구조적 특성상 구현이 매우 복잡하고 어렵다. 데이터가 여러 테이블에 정규화되어 분산되어 있고, 트랜잭션의 일관성을 모든 노드에 걸쳐 유지해야 하기 때문이다.50
• 스키마의 경직성 (Flexibility): RDBMS는 데이터를 저장하기 전에 테이블의 구조(열 이름, 데이터 타입 등)를 미리 엄격하게 정의해야 하는 ‘스키마 온 라이트(Schema-on-Write)’ 방식을 사용한다. 이로 인해 로그 데이터, 소셜 미디어 게시물, 센서 데이터와 같은 비정형(unstructured) 또는 반정형(semi-structured) 데이터를 효율적으로 저장하고 처리하기 어렵다. 또한, 비즈니스 요구사항의 변화로 인해 한번 정의된 스키마를 변경(예: 열 추가 또는 수정)하는 작업은 매우 복잡하며, 서비스 중단을 유발할 수도 있다.50
• 성능 병목: 데이터의 양이 수십 테라바이트 이상으로 방대해지거나, 여러 개의 대형 테이블을 조인(JOIN)하는 복잡한 쿼리가 실행될 경우, 성능이 급격히 저하될 수 있다. 특히 조인 연산은 디스크 I/O를 많이 유발하여 시스템의 병목 현상을 초래하는 주요 원인이 된다.50

결론적으로, RDBMS를 선택하는 것은 ‘신뢰성과 일관성’이라는 가치를 위해 ‘유연성과 대규모 확장성’을 어느 정도 희생하는 전략적 트레이드오프를 감수하는 결정이다. 이러한 본질적인 특성을 이해하는 것이 특정 애플리케이션의 요구사항에 가장 적합한 데이터베이스 기술을 선택하는 데 있어 핵심적인 기준이 된다.

2000년대 후반, 인터넷의 폭발적인 성장과 함께 등장한 빅데이터 시대는 관계형 데이터베이스가 지배하던 세계에 거대한 균열을 일으켰다. 페이스북, 구글, 아마존과 같은 웹 스케일 기업들은 기존 RDBMS의 한계, 즉 확장성, 유연성, 성능의 제약을 극복하기 위한 새로운 해법을 모색하기 시작했다. 그 결과로 등장한 것이 바로 NoSQL(Not Only SQL) 데이터베이스 패러다임이다.

NoSQL의 등장은 다음과 같은 세 가지 주요 동인에 의해 촉발되었다.

• 데이터 양의 폭증 (Volume): 소셜 미디어, 사물 인터넷(IoT), 모바일 기기 등에서 생성되는 데이터의 양이 기존 RDBMS가 효율적으로 처리할 수 있는 한계를 넘어섰다.82
• 데이터 다양성의 증가 (Variety): 텍스트, 이미지, 동영상, 로그 파일, JSON 문서 등 정형화되지 않은 비정형 및 반정형 데이터가 급증했다. RDBMS의 엄격한 고정 스키마는 이러한 다양한 형태의 데이터를 수용하기에 부적합했다.82
• 빠른 데이터 처리 속도 요구 (Velocity) 및 높은 가용성: 전 세계 사용자를 대상으로 24시간 무중단 서비스를 제공해야 하는 웹 애플리케이션들은 RDBMS의 수직적 확장 방식으로는 감당할 수 없는 수준의 수평적 확장성과 고가용성을 요구했다.81

이러한 문제들을 해결하기 위해 등장한 NoSQL 데이터베이스는 관계형 모델을 따르지 않으며, 유연한 스키마(또는 스키마리스), 수평적 확장성, 높은 가용성을 핵심적인 특징으로 내세운다.85

NoSQL 데이터베이스는 대부분 여러 서버에 데이터를 분산 저장하는 분산 시스템 아키텍처를 기반으로 한다. 이러한 분산 시스템의 근본적인 특성을 설명하는 이론이 바로 2000년 에릭 브루어(Eric Brewer)가 제시한 CAP 정리(CAP Theorem)다. 이 정리는 어떠한 분산 데이터 저장소도 다음 세 가지 속성 중 최대 두 가지만을 동시에 보장할 수 있다는 원칙을 제시한다.88

• 일관성 (Consistency): 모든 노드가 동시에 같은 데이터를 보여주는 것을 의미한다. 즉, 특정 데이터에 대한 읽기 요청은 언제나 가장 최근에 완료된 쓰기 결과를 반환해야 한다.89
• 가용성 (Availability): 시스템의 일부 노드에 장애가 발생하더라도, 모든 클라이언트의 요청에 대해 (성공 또는 실패) 응답을 보장하는 것을 의미한다.89
• 분할 허용성 (Partition Tolerance): 노드 간의 네트워크 통신이 일시적으로 단절(분할)되더라도 시스템 전체가 동작을 멈추지 않고 계속 운영될 수 있는 능력을 의미한다.89

분산 시스템에서 네트워크 장애는 피할 수 없는 현실이므로, 분할 허용성(P)은 선택이 아닌 필수적인 요구사항으로 간주된다.89 따라서 CAP 정리는 실질적으로 네트워크 분할이 발생했을 때, 시스템 설계자가 일관성(C)과 가용성(A) 사이에서 반드시 하나를 선택해야 하는 트레이드오프가 존재함을 시사한다.88

• CP (Consistency/Partition Tolerance) 시스템: 가용성을 희생하여 일관성을 선택한다. 네트워크 분할 시, 데이터의 일관성을 보장할 수 없는 노드는 요청에 대해 에러를 반환하거나 응답을 지연시킨다. 데이터의 정확성이 중요한 시스템에 적합하다.90
• AP (Availability/Partition Tolerance) 시스템: 일관성을 희생하여 가용성을 선택한다. 네트워크 분할 시, 노드는 현재 자신이 가지고 있는 최신 버전이 아닐 수 있는 데이터를 일단 반환한다. 무중단 서비스가 중요한 시스템에 적합하다.90

CAP 정리의 C와 A 사이의 트레이드오프는 데이터베이스의 일관성 모델에 대한 두 가지 상반된 철학, 즉 ACID와 BASE로 구체화된다.

• ACID 모델: 전통적인 RDBMS가 채택하는 강력한 일관성(Strong Consistency) 모델이다. 트랜잭션이 커밋되는 즉시 모든 사용자가 동일한 데이터를 볼 수 있음을 보장한다. 이는 일관성을 최우선으로 하는 비관적(Pessimistic) 접근 방식이다.94
• BASE 모델: 많은 NoSQL 시스템이 채택하는 모델로, Basically Available(기본적 가용성), Soft state(소프트 상태), Eventually consistent(궁극적 일관성)의 약어다.95
  • 특징: 이 모델은 즉각적인 일관성을 포기하는 대신 가용성을 극대화한다. 데이터는 쓰기 작업 후 즉시 모든 노드에 반영되지 않을 수 있지만, 시간이 지나면 ‘궁극적으로는’ 모든 노드에서 일관된 상태에 도달하게 된다(궁극적 일관성). 이는 가용성을 최우선으로 하는 낙관적(Optimistic) 접근 방식이다.94

결국 RDBMS와 NoSQL의 근본적인 차이는 단순히 데이터 모델의 차이를 넘어, 분산 환경에서 어떤 가치(일관성 vs. 가용성)를 우선시할 것인가에 대한 설계 철학의 차이에서 비롯된다.

아래 표는 RDBMS와 NoSQL의 핵심적인 차이점을 여러 관점에서 비교한 것이다.

구분	RDBMS (관계형 데이터베이스)	NoSQL (비관계형 데이터베이스)
데이터 모델	관계형 모델 (정형 데이터, 테이블 구조)	문서, 키-값, 컬럼 패밀리, 그래프 등 다양
스키마	고정 스키마 (Schema-on-Write)	유연한/동적 스키마 (Schema-on-Read)
확장성	수직적 확장 (Scale-up) 중심	수평적 확장 (Scale-out)에 최적화
일관성 모델	ACID (강력한 일관성)	BASE (궁극적 일관성) 중심
쿼리 언어	SQL (표준화된 선언적 언어)	표준 부재 (API 기반, 시스템별 상이)
주요 강점	데이터 무결성, 신뢰성, 복잡한 쿼리 지원	높은 확장성, 유연성, 고가용성, 빠른 속도
주요 약점	확장성 한계, 스키마 경직성, 비정형 데이터 처리	약한 일관성, 복잡한 쿼리/Join 제한, 표준 부재
적합한 사용 사례	금융 시스템, ERP, 전자상거래 등 트랜잭션 무결성이 중요한 시스템	빅데이터 분석, 실시간 웹 애플리케이션, IoT, 콘텐츠 관리 등

관계형 데이터베이스는 NoSQL의 등장으로 인한 도전에 직면했지만, 이는 종말이 아닌 새로운 진화의 시작이었다. 관계형 데이터베이스 진영은 NoSQL의 장점을 흡수하여 내부적으로 발전하고(NewSQL), 클라우드라는 외부 환경의 변화를 통해 운영상의 약점을 극복하며(DBaaS), 인공지능(AI)과 같은 새로운 기술과 결합하여 그 가치를 확장하고 있다. 이는 관계형 데이터베이스가 정체된 기술이 아니라, 외부의 도전에 맞서 끊임없이 적응하고 발전하는 역동적인 생태계임을 보여준다.

• 등장 배경: 대규모 온라인 트랜잭션 처리(OLTP) 환경, 예를 들어 금융 거래나 전자상거래 주문 처리 시스템에서는 RDBMS가 제공하는 강력한 트랜잭션과 ACID 일관성을 포기할 수 없었다. 동시에, 폭증하는 사용자 트래픽을 감당하기 위해서는 NoSQL 수준의 수평적 확장성과 고성능이 절실히 필요했다.83

• 정의: NewSQL은 이러한 상충되는 요구사항을 모두 만족시키기 위해 등장한 새로운 아키텍처의 관계형 데이터베이스다. 즉, RDBMS의 핵심 가치인 ACID 보장과 표준 SQL 인터페이스를 그대로 유지하면서, NoSQL 시스템의 수평적 확장성과 높은 처리 성능을 제공하는 것을 목표로 한다.102

• 핵심 아키텍처: NewSQL은 분산, 비공유(Shared-Nothing) 아키텍처를 기반으로 한다. 각 노드가 독립적인 CPU, 메모리, 디스크 자원을 가지고 데이터의 일부(파티션 또는 샤드)를 담당하며, 이를 통해 클러스터에 노드를 추가하는 것만으로 손쉽게 수평적 확장이 가능하다.83 또한, 빠른 성능을 위해

  인메모리 처리 기술과 잠금(Locking)을 최소화하는 고성능 동시성 제어 메커니즘을 적극적으로 활용한다.99

• 주요 시스템: 구글의 Spanner를 필두로, CockroachDB, VoltDB, NuoDB 등이 대표적인 NewSQL 데이터베이스로 꼽힌다.108 특히 CockroachDB는 PostgreSQL과 호환되는 SQL 계층을 제공하며, Raft 합의 알고리즘을 사용하여 분산 환경에서도 데이터의 강력한 일관성과 고가용성을 보장하는 것으로 잘 알려져 있다.110

클라우드 컴퓨팅의 등장은 RDBMS의 운영 패러다임을 근본적으로 바꾸어 놓았다. 서비스형 데이터베이스(DBaaS)는 클라우드 제공업체가 데이터베이스의 설치, 설정, 패치, 백업, 모니터링, 확장 등 모든 운영 및 관리 업무를 자동화된 서비스 형태로 제공하는 모델이다.112 Amazon RDS, Azure SQL Database, Google Cloud SQL과 같은 주요 DBaaS는 MySQL, PostgreSQL, SQL Server 등 전통적인 RDBMS를 완전 관리형 서비스로 제공한다.115

DBaaS는 RDBMS의 고질적인 단점들을 다음과 같이 효과적으로 해결한다.

• 운영 복잡성 및 비용 절감: 기업은 더 이상 데이터베이스 운영을 위해 값비싼 하드웨어를 구매하고 전문 DBA 팀을 유지할 필요가 없다. 초기 자본 비용(CapEx)이 사용한 만큼만 지불하는 운영 비용(OpEx)으로 전환되어 총소유비용(TCO)을 크게 절감할 수 있다.113
• 탄력적 확장성: 비즈니스 요구에 따라 몇 번의 클릭만으로 데이터베이스 서버의 사양을 높이거나(수직적 확장) 읽기 전용 복제본을 추가(수평적 읽기 확장)하는 등 리소스를 유연하고 신속하게 조절할 수 있다.112
• 고가용성 및 재해 복구의 대중화: 과거에는 대기업만 구현할 수 있었던 자동 백업, 시점 복구(Point-in-time recovery), 다중 가용 영역(Multi-AZ) 배포를 통한 자동 장애 복구(Failover) 기능이 기본적으로 제공되어, 중소기업도 높은 수준의 안정성을 쉽게 확보할 수 있게 되었다.112

최근 RDBMS는 단순히 데이터를 저장하고 관리하는 수동적인 역할을 넘어, AI 및 머신러닝 기술과 적극적으로 통합되며 데이터 플랫폼으로서의 가치를 확장하고 있다.118

• 벡터 검색 (Vector Search): 생성형 AI의 핵심 기술인 검색 증강 생성(RAG, Retrieval-Augmented Generation)을 지원하기 위해, 텍스트나 이미지 같은 비정형 데이터를 의미적으로 표현하는 벡터(Vector)를 저장하고, 유사도 기반으로 빠르게 검색하는 기능이 RDBMS에 내장되고 있다. Oracle Database의 AI Vector Search, Google Cloud SQL의 pgvector 지원이 대표적인 예다.115
• 인-데이터베이스 머신러닝 (In-Database ML): 데이터를 외부 ML 플랫폼으로 이동시키는 복잡하고 비효율적인 과정 없이, 데이터가 저장된 데이터베이스 내에서 직접 머신러닝 모델을 훈련하고 예측을 수행하는 기능이다. 이는 데이터 이동에 따른 비용과 시간을 절감하고, 데이터 보안을 강화하는 효과가 있다.118
• 자동화 및 자율 운영: AI 기술을 활용하여 쿼리 성능 튜닝, 인덱스 관리, 보안 위협 탐지, 리소스 할당 등 복잡한 데이터베이스 관리 작업을 자동화하는 ‘자율 데이터베이스(Autonomous Database)’ 개념이 확산되고 있다. 이를 통해 DBA는 반복적인 운영 업무에서 벗어나 데이터 아키텍처 설계와 같은 더 높은 가치를 창출하는 작업에 집중할 수 있다.107

본 보고서는 1970년 에드거 F. 커드의 수학적 모델 제안에서 시작하여 현대 클라우드 환경의 AI 통합 데이터베이스에 이르기까지, 관계형 데이터베이스의 광범위한 여정을 심층적으로 고찰했다. 관계형 모델의 이론적 견고함, 함수 종속성에 기반한 정규화를 통한 데이터 무결성 확보, 그리고 ACID 원칙에 기반한 트랜잭션의 신뢰성은 지난 반세기 동안 데이터 기술의 발전을 이끌어온 핵심 동력이었음을 확인했다. 이 원리들은 데이터 관리를 과학의 영역으로 끌어올렸으며, 오늘날 우리가 의존하는 수많은 정보 시스템의 근간을 이루고 있다.

21세기에 들어 빅데이터와 웹 스케일 환경의 도래로 인해 NoSQL이라는 새로운 패러다임의 도전을 받으며 관계형 데이터베이스의 한계가 부각되기도 했다. 그러나 관계형 데이터베이스는 소멸하는 기술이 아니라, 오히려 외부의 도전에 적극적으로 대응하며 스스로 진화하는 생명력을 보여주었다. NoSQL의 수평적 확장성을 수용한 NewSQL의 등장, 클라우드 기술과 결합하여 운영상의 약점을 극복한 DBaaS의 보편화는 이러한 진화의 명백한 증거다.

미래의 데이터 아키텍처는 단일 기술이 모든 것을 지배하는 세상이 아닌, 다양한 데이터베이스 기술이 각자의 강점을 발휘하며 공존하는 ‘폴리글랏 퍼시스턴스(Polyglot Persistence)’ 환경이 될 것이 자명하다. 이러한 환경 속에서 관계형 데이터베이스는 데이터의 강력한 일관성과 신뢰성이 요구되는 핵심 트랜잭션 시스템의 역할을 앞으로도 굳건히 지킬 것이다. 동시에, 벡터 검색과 인-데이터베이스 머신러닝 등 AI 기술과의 융합을 통해 데이터 플랫폼으로서의 가치와 활용 범위를 더욱 확장해 나갈 것으로 전망된다. 따라서 관계형 데이터베이스의 근본 원리에 대한 깊이 있는 이해는 변화하는 기술 환경 속에서도 모든 데이터 전문가에게 변함없이 요구되는 필수적인 역량으로 남을 것이다.

1. Edgar F. Codd - IBM, 8월 3, 2025에 액세스, https://www.ibm.com/history/edgar-codd
2. Edgar F. Codd - Wikipedia, 8월 3, 2025에 액세스, https://en.wikipedia.org/wiki/Edgar_F._Codd
3. 관계형 데이터베이스 - 위키백과, 우리 모두의 백과사전, 8월 3, 2025에 액세스, https://ko.wikipedia.org/wiki/%EA%B4%80%EA%B3%84%ED%98%95_%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4
4. Important Papers: Codd and the Relational Model - Two-Bit History, 8월 3, 2025에 액세스, https://twobithistory.org/2017/12/29/codd-relational-model.html
5. The relational database - IBM, 8월 3, 2025에 액세스, https://www.ibm.com/history/relational-database
6. A Relational Model of Data for Large Shared Data Banks, 8월 3, 2025에 액세스, https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf
7. “A RELATIONAL MODEL OF DATA FOR LARGE SHARED DATA BANKS”, 8월 3, 2025에 액세스, https://www.idc-online.com/technical_references/pdfs/information_technology/A_Relational_Model_of_Data_for_Large_Shared_Data_Banks.pdf
8. [DB] 관계형 데이터베이스란 - velog, 8월 3, 2025에 액세스, https://velog.io/@ghldjfldj/DB-%EA%B4%80%EA%B3%84%ED%98%95-%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4%EB%9E%80
9. Relational Model in DBMS - GeeksforGeeks, 8월 3, 2025에 액세스, https://www.geeksforgeeks.org/dbms/relational-model-in-dbms/
10. [Database] 데이터베이스 기본 용어 정리 - 코딩 공부 일지 - 티스토리, 8월 3, 2025에 액세스, https://cocoon1787.tistory.com/769
11. 관계형 데이터베이스 설계 - 설계 용어 - Coding JOAH, 8월 3, 2025에 액세스, https://july7k.tistory.com/51
12. [DB] 데이터 베이스 기초 개념 및 용어 정리 - 1일1코딩 - 티스토리, 8월 3, 2025에 액세스, https://1-day-1-coding.tistory.com/2
13. Relational database concepts, 8월 3, 2025에 액세스, https://www.upi.pr.it/docs/easfg/easvrfgp7.htm
14. 9 DATABASES KEY TERMINOLOGY (CIE) - COMPUTER SCIENCE CAFÉ, 8월 3, 2025에 액세스, https://www.computersciencecafe.com/9-databases-key-terminology-cie.html
15. Keys in Relational Model - GeeksforGeeks, 8월 3, 2025에 액세스, https://www.geeksforgeeks.org/dbms/types-of-keys-in-relational-model-candidate-super-primary-alternate-and-foreign/
16. [DB] 관계형 데이터베이스 키(Key) 이해하기 - Contributor9 - 티스토리, 8월 3, 2025에 액세스, https://adjh54.tistory.com/245
17. Difference between Primary Key and Foreign Key - GeeksforGeeks, 8월 3, 2025에 액세스, https://www.geeksforgeeks.org/dbms/difference-between-primary-key-and-foreign-key/
18. Introduction to Relational Databases - Keys and indexes - Cornell Virtual Workshop, 8월 3, 2025에 액세스, https://cvw.cac.cornell.edu/RelationalDBs/intro/keys-indexes
19. www.cockroachlabs.com, 8월 3, 2025에 액세스, https://www.cockroachlabs.com/blog/what-is-a-foreign-key/#:~:text=Primary%20keys%20serve%20as%20unique,cross%2Dreferencing%20the%20two%20tables.
20. Dimensional modeling: Primary and foreign keys - IBM, 8월 3, 2025에 액세스, https://www.ibm.com/docs/en/ida/9.1.1?topic=entities-primary-foreign-keys
21. Primary Key vs Foreign Key : r/SQL - Reddit, 8월 3, 2025에 액세스, https://www.reddit.com/r/SQL/comments/17bq4p2/primary_key_vs_foreign_key/
22. SQL DDL: The Definitive Guide on Data Definition Language - DbVisualizer, 8월 3, 2025에 액세스, https://www.dbvis.com/thetable/sql-ddl-the-definitive-guide-on-data-definition-language/
23. SQL Data Definition Language (DDL) - Create, Alter, Drop, Truncate, Rename, 8월 3, 2025에 액세스, https://www.faastop.com/dbms/41.sql_data_definition_language.html
24. [SQL] DDL, DML, DCL, TCL 요약 - Seol-Hee! - 티스토리, 8월 3, 2025에 액세스, https://seolhee2750.tistory.com/247
25. [DB] DDL, DML, DCL 종류 및 개념 - mun dev - 티스토리, 8월 3, 2025에 액세스, https://mndeveloper.tistory.com/361
26. Chapter 16 SQL Data Manipulation Language – Database Design - BC Open Textbooks, 8월 3, 2025에 액세스, https://opentextbc.ca/dbdesign01/chapter/chapter-sql-dml/
27. SQL Data Manipulation Language (DML) Operations: Insert, Update, Delete - DZone, 8월 3, 2025에 액세스, https://dzone.com/articles/sql-data-manipulation-language-dml-operations-inse
28. Data Control Language (DCL) Statement Reference - Ocient Documentation, 8월 3, 2025에 액세스, https://docs.ocient.com/data-control-language-dcl-statement-reference
29. Difference between Grant and Revoke - GeeksforGeeks, 8월 3, 2025에 액세스, https://www.geeksforgeeks.org/dbms/difference-between-grant-and-revoke/
30. SQL GRANT, REVOKE, Privileges and Roles - Beginner-Sql-Tutorial.com, 8월 3, 2025에 액세스, https://beginner-sql-tutorial.com/sql-grant-revoke-privileges-roles.htm
31. Database Normalization: A Comprehensive Guide to 1NF, 2NF, 3NF, and BCNF - Medium, 8월 3, 2025에 액세스, https://medium.com/@digitaldadababu/database-normalization-a-comprehensive-guide-to-1nf-2nf-3nf-and-bcnf-1e877d9f942a
32. Normal Forms in DBMS - GeeksforGeeks, 8월 3, 2025에 액세스, https://www.geeksforgeeks.org/dbms/normal-forms-in-dbms/
33. Database Normalization – Normal Forms 1nf 2nf 3nf Table Examples - freeCodeCamp, 8월 3, 2025에 액세스, https://www.freecodecamp.org/news/database-normalization-1nf-2nf-3nf-table-examples/
34. Database Normalization: 1NF, 2NF, 3NF & BCNF Examples …, 8월 3, 2025에 액세스, https://www.digitalocean.com/community/tutorials/database-normalization

35. Normalization in DBMS - 1NF, 2NF, 3NF, BCNF, 4NF and 5NF

    Studytonight, 8월 3, 2025에 액세스, https://www.studytonight.com/dbms/database-normalization.php

36. [DataBase] 정규화(1NF, 2NF, 3NF, BCNF) - 인성의 개발 공부 노트 - 티스토리, 8월 3, 2025에 액세스, https://superohinsung.tistory.com/111
37. Types of Functional Dependencies in DBMS + 4 Examples - Monday.com, 8월 3, 2025에 액세스, https://monday.com/blog/project-management/functional-dependencies-2/
38. What are Database Normalization and Functional Dependencies? - Stack Overflow, 8월 3, 2025에 액세스, https://stackoverflow.com/questions/29764062/what-are-database-normalization-and-functional-dependencies
39. Types of Functional dependencies in DBMS - GeeksforGeeks, 8월 3, 2025에 액세스, https://www.geeksforgeeks.org/dbms/types-of-functional-dependencies-in-dbms/
40. 데이터베이스 정규화 단계 (각 정규화 별 예시) - seseJeon, 8월 3, 2025에 액세스, https://sese-jeon.tistory.com/6
41. 정규화 과정과 원칙: 쉬운 예시로 1, 2, 3정규형 이해하기, 8월 3, 2025에 액세스, https://bommbom.tistory.com/entry/%EC%A0%95%EA%B7%9C%ED%99%94-%EA%B3%BC%EC%A0%95-%EC%9B%90%EC%B9%99-%EC%89%AC%EC%9A%B4%EC%98%88%EC%8B%9C-1-2-3%EC%A0%95%EA%B7%9C%ED%98%95-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0
42. 정규화 (1NF, 2NF, 3NF, BCNF, 4NF, 5NF) - velog, 8월 3, 2025에 액세스, https://velog.io/@wisdom-one/%EC%A0%95%EA%B7%9C%ED%99%94Normalization
43. Course Notes for Comp 419 - Normalization Using Functional Dependencies, 8월 3, 2025에 액세스, https://turing.cs.hbg.psu.edu/courses/comp419.taw.s97/rdesign3.html
44. ACID - Wikipedia, 8월 3, 2025에 액세스, https://en.wikipedia.org/wiki/ACID

45. Database ACID Properties: Atomic, Consistent, Isolated, Durable – BMC Software

    Blogs, 8월 3, 2025에 액세스, https://www.bmc.com/blogs/acid-atomic-consistent-isolated-durable/

46. ACID Properties in DBMS: A Comprehensive Guide - Simplilearn.com, 8월 3, 2025에 액세스, https://www.simplilearn.com/acid-properties-in-dbms-article

47. Understanding ACID Properties in Database Management

    Yeran Kods

    Nerd For Tech, 8월 3, 2025에 액세스, https://medium.com/nerd-for-tech/understanding-acid-properties-in-database-management-98243bfe244c

48. ACID Properties in DBMS - GeeksforGeeks, 8월 3, 2025에 액세스, https://www.geeksforgeeks.org/dbms/acid-properties-in-dbms/
49. ACID : 원자성, 일관성, 독립성, 지속성, 8월 3, 2025에 액세스, https://www.joinc.co.kr/w/man/12/ACID
50. Relational Vs. Non-Relational Databases - MongoDB, 8월 3, 2025에 액세스, https://www.mongodb.com/resources/compare/relational-vs-non-relational-databases
51. [Database] ACID(원자성, 일관성, 고립성, 지속성) - 범데이의 개발노트 - 티스토리, 8월 3, 2025에 액세스, https://bumday.tistory.com/180
52. MySQL: 10 Cons & Disadvantages with 5 Alternatives - ProjectManagers.net, 8월 3, 2025에 액세스, https://projectmanagers.net/mysql-10-cons-disadvantages-with-5-alternatives/
53. What Is MySQL: Definition, Features & Benefits Explained - Devart Blog, 8월 3, 2025에 액세스, https://blog.devart.com/what-is-mysql.html
54. MySQL Database: Overview and Advantages - Motadata, 8월 3, 2025에 액세스, https://www.motadata.com/it-glossary/mysql-database/
55. 8 Major Advantages of Using MySQL - Datamation, 8월 3, 2025에 액세스, https://www.datamation.com/storage/8-major-advantages-of-using-mysql/
56. MySQL: Advantages, Disadvantages, and Expert Guide - CyloSpark, 8월 3, 2025에 액세스, http://cylospark.liveblog365.com/2024/12/23/mysql-advantages-disadvantages-and-expert-guide/
57. MySQL - concepts, benefits and use cases - Tessell, 8월 3, 2025에 액세스, https://www.tessell.com/blogs/mysql-concepts-benefits-and-use-cases
58. What is PostgreSQL? Features and Benefits - Quest Software, 8월 3, 2025에 액세스, https://www.quest.com/learn/what-is-postgresql.aspx
59. What is PostgreSQL? Key Features, Benefits, and Real-World Uses - Percona, 8월 3, 2025에 액세스, https://www.percona.com/blog/what-is-postgresql-used-for/
60. About - PostgreSQL, 8월 3, 2025에 액세스, https://www.postgresql.org/about/
61. PostgreSQL: Advantages and Disadvantages in 2025, 8월 3, 2025에 액세스, https://www.ralantech.com/resources/postgresql-advantages-and-disadvantages/
62. PostgreSQL: What Is It, Key Features, Advantages and Disadvantages - Analytics Drift, 8월 3, 2025에 액세스, https://analyticsdrift.com/postgresql-database/
63. All about Oracle Database - Definition, Features, Benefits - Devart, 8월 3, 2025에 액세스, https://www.devart.com/dbforge/oracle/all-about-oracle-database/
64. Oracle Database Advantages, Disadvantages and Features [Guide 2025] - The NineHertz, 8월 3, 2025에 액세스, https://theninehertz.com/blog/advantages-of-using-oracle-database
65. What is Oracle and use cases of Oracle? - DevOpsSchool.com, 8월 3, 2025에 액세스, https://www.devopsschool.com/blog/what-is-oracle-and-use-cases-of-oracle/

66. Oracle Database Pros and Cons

    User Likes & Dislikes - G2, 8월 3, 2025에 액세스, https://www.g2.com/products/oracle-database/reviews?qs=pros-and-cons

67. Oracle Database Advantages, Disadvantages and Features - Next Big Technology, 8월 3, 2025에 액세스, https://nextbigtechnology.com/oracle-database-advantages-disadvantages-and-features-guide-2021/
68. What Is Microsoft SQL Server? [2025 Overview] - Red9, 8월 3, 2025에 액세스, https://red9.com/blog/what-is-sql-server/
69. Microsoft SQL Server: Advantages & Best Practices for Technical Corporate Decision Makers - Virtual-DBA, 8월 3, 2025에 액세스, https://virtual-dba.com/blog/microsoft-sql-server-advantages-and-best-practices/
70. What is SQL Server and use cases of SQL Server? - DevOpsSchool.com, 8월 3, 2025에 액세스, https://www.devopsschool.com/blog/what-is-sql-server-and-use-cases-of-sql-server/
71. Advantages And Disadvantages Of SQL Simplified (With Examples) - Unstop, 8월 3, 2025에 액세스, https://unstop.com/blog/advantages-and-disadvantages-of-sql

72. Microsoft SQL Server Pros and Cons

    LearnSQL.com, 8월 3, 2025에 액세스, https://learnsql.com/blog/microsoft-sql-server-pros-and-cons/

73. Types of Databases, Pros & Cons, and Real-World Examples - Actian Corporation, 8월 3, 2025에 액세스, https://www.actian.com/blog/databases/types-of-databases-pros-cons/
74. RDBMS Benefits and Limitations - GeeksforGeeks, 8월 3, 2025에 액세스, https://www.geeksforgeeks.org/dbms/rdbms-benefits-and-limitations/
75. 관계형 데이터베이스 비관계형 데이터베이스 - velog, 8월 3, 2025에 액세스, https://velog.io/@wjd15sheep/%EA%B4%80%EA%B3%84%ED%98%95-%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-%EB%B9%84%EA%B4%80%EA%B3%84%ED%98%95-%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4
76. 관계형 데이터베이스(RDBMS)란 무엇인가요? - Google Cloud, 8월 3, 2025에 액세스, https://cloud.google.com/learn/what-is-a-relational-database?hl=ko
77. Top 10+ Advantages and Disadvantages of Using RDBMS - Webandcrafts, 8월 3, 2025에 액세스, https://webandcrafts.com/blog/advantages-disadvantages-rdbms
78. [데이터베이스] 관계형 DB와 비관계형 DB - Gonna be my Best part - 티스토리, 8월 3, 2025에 액세스, https://excited-hyun.tistory.com/112
79. SQL vs NoSQL - 관계형 데이터베이스, 비관계형 데이터베이스 - NEW WORD - 티스토리, 8월 3, 2025에 액세스, https://sunrise-new-world.tistory.com/19
80. Relational Database Benefits and Limitations - databasetown.com, 8월 3, 2025에 액세스, https://databasetown.com/relational-database-benefits-and-limitations/
81. [DB] 데이터베이스 종류와 장단점 - 같이 배우는 공부방! - 티스토리, 8월 3, 2025에 액세스, https://unagi-zoso.tistory.com/266
82. SQL vs NoSQL: A Comparison of Database Technologies for Data Engineers - Airbyte, 8월 3, 2025에 액세스, https://airbyte.com/data-engineering-resources/sql-vs-nosql
83. NewSQL에 대하여, 8월 3, 2025에 액세스, https://blog.skaiworldwide.com/57

84. SQL vs. NoSQL vs. NewSQL- A Comparative Study - Communications on Applied Electronics

    CAE, 8월 3, 2025에 액세스, https://www.caeaccess.org/archives/volume6/number1/binani-2016-cae-652418.pdf

85. Relational Database vs NoSQL: 15 Key Differences 2024 - Atlan, 8월 3, 2025에 액세스, https://atlan.com/relational-database-vs-nosql/
86. Decoding different types of databases: A comparison - Data Science Central, 8월 3, 2025에 액세스, https://www.datasciencecentral.com/decoding-different-types-of-databases-a-comparison/
87. [Database] NoSQL 이해하기 - 미스터리의 IT 공부 일기, 8월 3, 2025에 액세스, https://mysterlee.tistory.com/106
88. www.bmc.com, 8월 3, 2025에 액세스, https://www.bmc.com/blogs/cap-theorem/#:~:text=But%20the%20CAP%20theorem%20maintains,a%20choice%20must%20be%20made.
89. CAP theorem - Wikipedia, 8월 3, 2025에 액세스, https://en.wikipedia.org/wiki/CAP_theorem
90. What is the CAP theorem? - Educative.io, 8월 3, 2025에 액세스, https://www.educative.io/blog/what-is-cap-theorem

91. CAP Theorem & Strategies for Distributed Systems

    Splunk, 8월 3, 2025에 액세스, https://www.splunk.com/en_us/blog/learn/cap-theorem.html

92. CAP Theorem Explained: Consistency, Availability & Partition Tolerance - BMC Software, 8월 3, 2025에 액세스, https://www.bmc.com/blogs/cap-theorem/

93. What is CAP Theorem? Definition & FAQs

    ScyllaDB, 8월 3, 2025에 액세스, https://www.scylladb.com/glossary/cap-theorem/

94. ACID vs BASE Databases - Difference Between Databases - AWS, 8월 3, 2025에 액세스, https://aws.amazon.com/compare/the-difference-between-acid-and-base-database/
95. ACID vs BASE Databases: The Clash between Consistency and Scalability, 8월 3, 2025에 액세스, https://matthewmacfarquhar.medium.com/acid-vs-base-databases-the-clash-between-consistency-and-scalability-916104c6249e
96. ACID Model vs BASE Model For Database - GeeksforGeeks, 8월 3, 2025에 액세스, https://www.geeksforgeeks.org/dbms/acid-model-vs-base-model-for-database/
97. Data Consistency Models: ACID vs. BASE Databases Explained - Neo4j, 8월 3, 2025에 액세스, https://neo4j.com/blog/graph-database/acid-vs-base-consistency-models-explained/
98. aws.amazon.com, 8월 3, 2025에 액세스, https://aws.amazon.com/compare/the-difference-between-acid-and-base-database/#:~:text=ACID%20databases%20prioritize%20consistency%20over,can%20access%20inconsistent%20data%20temporarily.

99. What is NewSQL? {+Best NewSQL Databases}

    phoenixNAP KB, 8월 3, 2025에 액세스, https://phoenixnap.com/kb/newsql

100. SQL vs NoSQL vs NewSQL: The Full Comparison - XenonStack, 8월 3, 2025에 액세스, https://www.xenonstack.com/blog/sql-vs-nosql-vs-newsql
101. NewSQL - 위키백과, 우리 모두의 백과사전, 8월 3, 2025에 액세스, https://ko.wikipedia.org/wiki/NewSQL
102. www.dremio.com, 8월 3, 2025에 액세스, https://www.dremio.com/wiki/newsql/#:~:text=NewSQL%20databases%20are%20designed%20to,models%20and%20SQL%20query%20semantics.

103. What is NewSQL?

     Aerospike, 8월 3, 2025에 액세스, https://aerospike.com/glossary/newsql-rdms/

104. NewSQL Databases: Definition, Examples, and Applications - Graph AI, 8월 3, 2025에 액세스, https://www.graphapp.ai/engineering-glossary/cloud-computing/newsql-databases
105. 데이터베이스 - 위키백과, 우리 모두의 백과사전, 8월 3, 2025에 액세스, https://ko.wikipedia.org/wiki/%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4
106. NewSQL - CelerData, 8월 3, 2025에 액세스, https://celerdata.com/glossary/newsql
107. 뉴SQL: SQL의 부활? NoSQL의 반란? 아니면 둘 다? ‍♂️ - 재능넷, 8월 3, 2025에 액세스, https://www.jaenung.net/tree/3040
108. What is NewSQL and how does it differ from traditional SQL and, 8월 3, 2025에 액세스, https://www.designgurus.io/answers/detail/what-is-newsql-and-how-does-it-differ-from-traditional-sql-and-nosql-databases

109. Distributed SQL vs. NewSQL

     YugabyteDB, 8월 3, 2025에 액세스, https://www.yugabyte.com/blog/distributedsql-vs-newsql/

110. NewSQL Databases Assessment: CockroachDB, MariaDB Xpand, and VoltDB - MDPI, 8월 3, 2025에 액세스, https://www.mdpi.com/1999-5903/15/1/10

111. NewSQL DATABASES 🗄️. Abstract

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

112. What to Know About Database-as-a-Service (DBaaS) - Nutanix, 8월 3, 2025에 액세스, https://www.nutanix.com/info/what-is-dbaas
113. What is DBaaS? Understanding Database as a Service - DigitalOcean, 8월 3, 2025에 액세스, https://www.digitalocean.com/resources/articles/dbaas

114. Advantages and Disadvantages of Using a DBaaS

     Severalnines, 8월 3, 2025에 액세스, https://severalnines.com/blog/advantages-and-disadvantages-using-dbaas/

115. Cloud SQL for MySQL, PostgreSQL, and SQL Server - Google Cloud, 8월 3, 2025에 액세스, https://cloud.google.com/sql
116. Cloud Relational Database – Amazon RDS Features - AWS, 8월 3, 2025에 액세스, https://aws.amazon.com/rds/features/
117. Relational Databases in Multi-Cloud across AWS, Azure, and GCP - Rapydo, 8월 3, 2025에 액세스, https://www.rapydo.io/blog/relational-databases-in-multi-cloud-across-aws-azure-and-gcp
118. 관계형 데이터베이스 관리의 6가지 최신 동향 - AppMaster, 8월 3, 2025에 액세스, https://appmaster.io/ko/blog/gwangyehyeong-deiteobeiseu-gwanri-donghyang
119. DBaaS Explained: What Is Database as a Service? - University of San Diego Online Degrees, 8월 3, 2025에 액세스, https://onlinedegrees.sandiego.edu/what-is-dbaas/
120. The five key benefits of DBaaS - Aerospike, 8월 3, 2025에 액세스, https://aerospike.com/blog/the-five-key-benefits-of-dbaas/
121. 클라우드 데이터베이스란 무엇인가요? - Google Cloud, 8월 3, 2025에 액세스, https://cloud.google.com/learn/what-is-a-cloud-database?hl=ko
122. DBaaS Benefits: Pros And Cons [2025] - ScaleGrid, 8월 3, 2025에 액세스, https://scalegrid.io/blog/dbaas-pros-cons/
123. DBMS시장: 관계형과 클라우드의 미래 - Goover, 8월 3, 2025에 액세스, https://seo.goover.ai/report/202411/go-public-report-ko-bb862e1c-f9d9-45d7-9bf9-b39ae0ab27e9-0-0.html
124. 관계형 데이터베이스 시장 규모, 점유율 및 추세 보고서 2031 - Kings Research, 8월 3, 2025에 액세스, https://www.kingsresearch.com/ko/relational-database-market-1117

125. Database Features

     Oracle, 8월 3, 2025에 액세스, https://www.oracle.com/database/features/