RDBMS

에드거 F. 커드는 1970년 논문 "대형 공유 데이터 뱅크를 위한 관계형 데이터 모델"에서 관계형 모델을 처음 제안했다. 그는 기존의 계층형 데이터베이스나 네트워크 데이터베이스가 가진 복잡한 포인터 구조 대신, 수학의 집합론과 관계대수에 기반한 단순한 테이블 구조를 제시했다. 이 모델에서 모든 데이터는 행과 열로 구성된 테이블에 저장되며, 테이블 간의 관계는 데이터 값 자체에 의해 정의된다.

이 개념은 당시 데이터베이스 업계에 혁신적이었다. 기존 시스템은 데이터 접근 경로가 물리적 구조에 강하게 의존했지만, 관계형 모델은 사용자가 데이터의 논리적 관계에만 집중하여 선언형 방식으로 질의할 수 있도록 했다. 커드는 데이터 독립성, 즉 응용 프로그램이 데이터의 물리적 저장 방식 변경으로부터 자유로워져야 한다는 점을 강조했다.

커드의 이론을 실현하기 위한 초기 연구 개발이 이어졌다. IBM 연구소에서는 시스템 R 프로젝트를 통해 관계형 모델을 구현하는 최초의 시스템 중 하나를 구축했다. 이 프로젝트는 SEQUEL이라는 질의 언어를 개발했으며, 이는 후에 SQL의 기초가 되었다. 거의 동시에, 캘리포니아 대학교 버클리에서는 INGRES 프로젝트를 진행하며 또 다른 관계형 데이터베이스 시스템과 QUEL이라는 질의 언어를 만들어냈다.

이 초기 프로젝트들은 관계형 모델의 실용성을 입증하는 데 결정적 역할을 했다. 시스템 R과 INGRES는 트랜잭션 처리, 쿼리 최적화, 시스템 카탈로그 등 현대 RDBMS의 핵심 기능에 대한 기초 연구를 수행했다. 1970년대 후반까지 이론적 모델은 실제 작동 가능한 시스템으로 진화했으며, 1980년대 상용 RDBMS 제품들의 등장으로 이어지는 토대를 마련했다.

1970년대 에드거 F. 커드가 제안한 관계형 모델은 이론적 토대를 마련했지만, 이를 실제로 구현하고 산업 표준으로 자리 잡게 한 것은 SQL 언어의 발전과 상용 RDBMS 제품의 등장이었다.

초기에는 각 벤더가 독자적인 질의 언어를 사용했다. IBM은 SEQUEL(Structured English Query Language)을 개발했으며, 이는 후에 SQL로 명칭이 변경되었다. 1980년대 중반에 이르러 SQL의 중요성이 부각되자, ANSI와 ISO 표준 기구에서 공식 표준화 작업에 착수했다. 최초의 공식 표준은 1986년에 SQL-86(또는 SQL1)로 채택되었고, 이후 SQL-92(SQL2), SQL:1999(SQL3) 등으로 지속적으로 확장되어 강력한 데이터 조작, 정의, 제어 기능을 제공하는 언어로 발전했다.

표준화와 병행하여 상용 RDBMS 시장이 본격적으로 형성되기 시작했다. 1979년 오라클이 최초의 상용 관계형 데이터베이스 관리 시스템을 출시했고, IBM은 System R 연구 프로젝트의 성과를 바탕으로 DB2를 개발했다. 1980년대 후반에는 마이크로소프트와 사이베이스(Sybase)가 협력해 SQL Server를 선보였으며, 이후 마이크로소프트가 독자적인 개발 경로를 걸었다. 이러한 상용화는 기업의 데이터 처리 방식을 근본적으로 바꾸었고, SQL은 사실상 모든 RDBMS의 표준 인터페이스가 되었다.

이 과정에서 SQL 표준은 벤더 간 호환성의 기초를 제공했지만, 각 제품은 성능 최적화나 고급 기능을 위해 표준을 확장하는 독자적인 변형을 포함하게 되었다. 이로 인해 완벽한 호환성보다는 특정 벤더에 종속되는 경우도 발생했다.

1990년대 이후 RDBMS는 인터넷의 확산과 기업 업무의 디지털화에 따라 폭발적인 성장을 이루었다. 이 시기에는 클라이언트-서버 아키텍처가 보편화되면서 다수의 사용자가 동시에 데이터베이스에 접근하는 환경이 일반화되었다. 이에 따라 트랜잭션 처리량을 높이고 동시성 제어를 효율적으로 관리하는 기술이 발전의 핵심 과제가 되었다.

2000년대에 들어서는 오픈 소스 RDBMS의 부상이 두드러진 특징이다. MySQL과 PostgreSQL이 상용 제품에 대한 강력한 대안으로 자리 잡으면서, 특히 웹 기반 애플리케이션 개발의 표준 데이터 저장소가 되었다. 한편, 상용 RDBMS는 OLAP와 데이터 웨어하우스 지원, 고급 분석 기능, 그리고 클러스터링과 고가용성 솔루션을 강화하여 대규모 엔터프라이즈 시장을 공고히 했다.

최근 10여 년간의 발전은 클라우드 컴퓨팅과 빅데이터 환경에 대응하는 방향으로 이루어졌다. 주요 변화는 다음과 같다.

이러한 발전을 통해 현대 RDBMS는 전통적인 OLTP 업무뿐만 아니라, 일부 분석 작업과 유연한 데이터 모델 요구사항까지 포괄하는 범용 데이터 플랫폼으로 진화하고 있다.

관계형 데이터베이스 관리 시스템의 데이터는 테이블이라는 구조에 저장된다. 테이블은 행과 열로 구성된 2차원 격자 형태를 가지며, 특정 엔터티(예: 고객, 주문, 상품)에 관한 데이터를 표현하는 기본 단위이다. 각 테이블은 고유한 이름을 가지며, 데이터베이스 스키마를 정의하는 데이터 정의 언어를 통해 생성된다.

테이블의 열은 속성 또는 필드라고도 불리며, 저장할 데이터의 종류를 정의한다. 예를 들어 '고객' 테이블은 '고객ID', '이름', '주소', '전화번호' 등의 열을 가질 수 있다. 각 열은 정수, 문자열, 날짜 등 특정 데이터 타입을 가지며, 널 값 허용 여부 등의 제약 조건을 설정할 수 있다. 행은 레코드 또는 튜플이라고 불리며, 테이블에 저장된 개별 데이터 항목에 해당한다. '고객' 테이블의 각 행은 한 명의 고객에 대한 구체적인 정보를 담는다.

테이블, 행, 열의 관계는 다음과 같은 표로 요약할 수 있다.

이 구조는 데이터를 체계적으로 조직화하고, 기본 키를 통해 각 행을 고유하게 식별하며, 외래 키를 통해 다른 테이블의 행과 관계를 맺는 기반이 된다. 모든 데이터 조작과 질의는 궁극적으로 하나 이상의 테이블에서 특정 행과 열을 대상으로 이루어진다.

기본 키는 테이블 내의 각 행을 고유하게 식별하는 하나 이상의 열 또는 열의 조합이다. 기본 키로 지정된 열은 NULL 값을 가질 수 없으며, 테이블 내에서 중복된 값을 가질 수 없다. 이 제약 조건을 통해 각 레코드의 유일성이 보장된다. 기본 키는 데이터의 무결성을 유지하고, 다른 테이블과의 관계를 정의하는 기준점 역할을 한다. 일반적으로 자동 증가하는 숫자(시퀀스)나 비즈니스적으로 의미 있는 고유 코드 등이 기본 키로 사용된다.

외래 키는 한 테이블의 열이 다른 테이블의 기본 키를 참조하는 관계를 정의한다. 이는 두 테이블 간의 논리적 연결을 생성하며, 참조 무결성을 유지하는 핵심 메커니즘이다. 외래 키 제약이 설정되면, 참조되는 테이블(부모 테이블)에 존재하지 않는 값을 외래 키 열에 삽입할 수 없다. 또한 부모 테이블의 레코드를 삭제하려 할 때, 해당 레코드를 참조하는 자식 테이블의 레코드가 존재하면 삭제가 제한되는 등의 동작이 발생할 수 있다.

기본 키와 외래 키의 관계는 데이터 모델링의 기초를 형성한다. 예를 들어, 고객 테이블의 기본 키인 고객ID를 주문 테이블이 외래 키로 포함하면, 각 주문이 정확히 한 명의 고객에 속함을 명시적으로 정의할 수 있다. 이 관계는 ERD로 시각화되며, 데이터베이스 스키마의 청사진 역할을 한다.

이러한 키들의 적절한 설계는 데이터 중복을 방지하고, 일관된 데이터 구조를 유지하며, 효율적인 데이터 검색을 가능하게 한다.

관계형 데이터베이스에서 테이블 간의 관계는 외래 키를 통해 정의되며, 데이터의 논리적 연결을 표현한다. 주요 관계 유형은 일대일 관계, 일대다 관계, 다대다 관계로 구분된다.

일대일 관계는 주로 보안상 이유로 데이터를 분리하거나, 자주 조회하지 않는 대용량 칼럼을 별도 테이블로 관리할 때 사용한다. 일대다 관계는 관계형 모델의 핵심으로, 부모 테이블의 기본 키가 자식 테이블의 외래 키로 참조되는 패턴이다. 다대다 관계를 구현할 때 생성되는 조인 테이블(또는 연결 테이블)은 양쪽 테이블의 기본 키를 복합 외래 키로 포함하며, 때로는 관계 자체의 추가 속성을 저장하기도 한다[1].

이러한 관계는 SQL 조인 연산을 통해 물리적으로 결합되어 활용된다. 데이터베이스 설계 시 이러한 관계를 정확히 정의하는 것은 데이터 무결성을 보장하고 데이터 중복을 최소화하는 데 중요하다.

데이터 무결성 제약은 RDBMS가 저장하는 데이터의 정확성과 일관성을 보장하기 위해 정의하는 규칙의 집합이다. 이 제약 조건들은 데이터베이스 스키마를 정의할 때 설정되며, 이후 모든 데이터 조작 작업은 이 규칙들을 위반하지 않아야 한다. 제약 조건을 위반하는 작업은 시스템에 의해 거부되어 데이터의 신뢰성을 유지한다.

주요 무결성 제약에는 엔터티 무결성, 참조 무결성, 도메인 무결성 등이 있다. 엔터티 무결성은 각 테이블의 기본 키 열이 NULL 값을 가질 수 없고 고유해야 함을 규정한다. 참조 무결성은 외래 키의 값이 참조하는 테이블의 기본 키에 존재하는 값이거나 NULL이어야 함을 보장하여 테이블 간 관계의 일관성을 유지한다. 도메인 무결성은 각 열에 입력될 수 있는 데이터의 유형과 범위를 제한한다(예: '나이' 열은 0 이상의 정수만 허용).

이 외에도 사용자 정의 무결성 규칙과 고유 제약이 있다. 고유 제약은 기본 키가 아닌 열에 대해 중복 값을 허용하지 않는다. NOT NULL 제약은 특정 열이 빈 값을 가질 수 없도록 한다. CHECK 제약은 열의 값이 특정 논리적 조건을 만족하도록 한다(예: CHECK (재고수량 >= 0)). 이러한 제약들은 주로 SQL의 DDL 문인 CREATE TABLE 또는 ALTER TABLE을 사용하여 정의된다.

트랜잭션은 데이터베이스의 상태를 변화시키기 위해 수행하는 작업의 논리적 단위이다. 이는 하나 이상의 SQL 문으로 구성되며, 모두 성공하거나 모두 실패하는 '전부 아니면 전무(All or Nothing)' 원칙을 따른다. RDBMS의 트랜잭션 관리는 이러한 작업 단위의 신뢰성을 보장하기 위해 ACID 속성을 구현한다.

ACID는 트랜잭션이 안전하게 수행된다는 것을 보장하기 위한 네 가지 핵심 속성의 약자이다.

* 원자성(Atomicity): 트랜잭션의 모든 연산은 완전히 수행되거나, 전혀 수행되지 않아야 한다. 중간에 오류가 발생하면 트랜잭션 시작 전 상태로 롤백(rollback)된다.

* 일관성(Consistency): 트랜잭션이 성공적으로 완료되면, 데이터베이스는 미리 정의된 모든 무결성 제약 조건을 만족하는 일관된 상태로 유지되어야 한다.

* 격리성(Isolation): 동시에 실행되는 여러 트랜잭션은 서로에게 영향을 미치지 않고 독립적으로 실행되는 것처럼 동작해야 한다.

* 지속성(Durability): 한 번 커밋(commit)된 트랜잭션의 결과는 시스템 장애가 발생하더라도 영구적으로 데이터베이스에 반영되어야 한다.

이러한 속성을 구현하기 위해 RDBMS는 로그 파일과 락(Lock) 같은 메커니즘을 사용한다. 로그 파일은 모든 변경 사항을 기록하여 원자성과 지속성을 보장하고, 락은 동시에 접근하는 트랜잭션 간의 간섭을 제어하여 격리성을 유지한다. 격리성 수준은 성능과 데이터 정합성 사이의 트레이드오프에 따라 조정될 수 있다[2].

동시성 제어는 여러 사용자나 트랜잭션이 동시에 데이터베이스에 접근하여 데이터를 조작할 때 발생할 수 있는 문제를 방지하고, 데이터의 일관성을 유지하는 메커니즘이다. 주요 목표는 동시 실행되는 작업들이 서로 간섭하지 않으면서도 시스템의 처리량을 최대화하는 것이다. 이를 위해 락(Lock) 기반의 제어, 다중 버전 동시성 제어(MVCC), 타임스탬프 순서화 등 다양한 기법이 사용된다.

동시성 제어가 없을 때 발생하는 대표적인 문제는 다음과 같다.

이러한 문제를 해결하기 위해 RDBMS는 격리 수준을 정의한다. 일반적인 격리 수준은 READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE로 구분된다. 격리 수준이 높을수록 데이터 일관성은 강화되지만, 동시에 접근할 수 있는 사용자 수와 시스템 성능은 저하되는 트레이드오프 관계가 있다. 대부분의 상용 RDBMS는 기본 격리 수준으로 READ COMMITTED 또는 REPEATABLE READ를 채용한다.

락(Lock)은 가장 일반적인 동시성 제어 수단이다. 공유락(Shared Lock)은 데이터를 읽을 때 사용되며, 여러 트랜잭션이 동시에 획득할 수 있다. 배타락(Exclusive Lock)은 데이터를 쓰거나 수정할 때 사용되며, 한 번에 하나의 트랜잭션만 획득할 수 있다. 락의 범위에 따라 행 단위, 페이지 단위, 테이블 단위 락 등으로 구분된다. 락 기반 방식의 단점인 데드락 가능성을 최소화하기 위해, 데이터베이스는 데드락 감지 및 회복 알고리즘을 운영한다.

데이터베이스의 백업은 시스템 장애, 사용자 오류, 자연 재해 등으로부터 데이터를 보호하기 위해 데이터와 스키마 정보를 복사본으로 저장하는 과정이다. 복구는 손실되거나 손상된 데이터를 백업된 복사본을 사용하여 원래 상태로 되돌리는 작업을 의미한다. 효과적인 백업 및 복구 전략은 비즈니스 연속성과 재해 복구 계획의 핵심 요소이다.

백업은 수행 방식에 따라 물리적 백업과 논리적 백업으로 구분된다. 물리적 백업은 데이터 파일, 컨트롤 파일, 리두 로그 파일 등 데이터베이스를 구성하는 운영체제 파일을 그대로 복사하는 방식이다. 논리적 백업은 SQL 문을 사용하여 데이터베이스 객체(테이블, 프로시저 등)의 구조와 데이터를 추출하는 방식으로, exp/imp 또는 데이터 펌프 같은 도구를 사용한다. 또한 백업 유형은 전체 백업, 증분 백업, 차등 백업으로 나뉘며, 복구 목표 시점에 따라 복구 시간 목표와 복구 시점 목표를 기준으로 전략을 수립한다.

복구 시나리오는 손상 정도에 따라 다르게 적용된다. 인스턴스 실패 후의 재시작 시 발생하는 자동 복구부터, 미디어 실패 시 백업 파일과 아카이브 로그를 사용하여 데이터 파일을 복원하고 트랜잭션 로그를 재적용하는 완전 복구가 있다. 특정 시점 복구는 사용자 오류로 인한 데이터 손실 시, 오류 발생 직전의 특정 시점으로 데이터베이스를 되돌릴 수 있다. 현대 RDBMS는 핫 백업과 스냅샷 기술을 지원하여 백업 중에도 데이터베이스 서비스를 중단하지 않고 운영할 수 있다.

백업의 정기적인 테스트는 복구 절차의 신뢰성을 보장하는 필수 단계이다. 백업 매체의 오프사이트 저장은 화재나 홍수 같은 물리적 재해로부터 데이터를 보호한다. 클라우드 기반 RDBMS 서비스는 자동화된 백업, 지리적으로 분산된 복제본, 관리형 복구 옵션을 제공하여 백업 및 복구 부담을 줄인다.

DDL은 데이터베이스의 구조를 정의하고 변경하며 삭제하는 데 사용되는 SQL의 하위 언어이다. 이 언어를 통해 데이터베이스 관리자나 개발자는 스키마, 테이블, 인덱스, 뷰와 같은 데이터베이스 객체의 생명주기를 관리한다. DDL 문장은 실행 즉시 데이터베이스 구조에 영향을 미치며, 일반적으로 트랜잭션 내에서 롤백이 가능하지만 제품에 따라 차이가 있을 수 있다.

주요 DDL 명령어는 다음과 같다.

* CREATE: 새로운 데이터베이스, 테이블, 인덱스, 뷰 등을 생성한다.

* ALTER: 기존 객체의 구조를 변경한다. 예를 들어 테이블에 새로운 열을 추가하거나 제약 조건을 수정하는 데 사용된다.

* DROP: 기존 객체를 데이터베이스에서 완전히 삭제한다.

* TRUNCATE: 테이블 내의 모든 데이터를 빠르게 삭제하지만, 테이블 구조는 유지한다. 이는 로그를 최소화하는 방식으로 작동하여 대량 데이터 삭제 시 DELETE 문보다 효율적일 수 있다[4].

DDL의 핵심 작업 중 하나는 테이블을 생성하고 수정하는 것이다. CREATE TABLE 문에서는 각 열의 이름, 데이터 타입(예: INT, VARCHAR, DATE), 그리고 기본 키, 외래 키, NOT NULL, UNIQUE와 같은 데이터 무결성 제약 조건을 함께 정의한다. ALTER TABLE 문은 이후 요구사항의 변화에 따라 이 구조를 유연하게 조정하는 수단을 제공한다.

DML은 데이터베이스 내에 저장된 실제 데이터를 조작하는 데 사용되는 SQL 명령어 집합이다. 주된 목적은 테이블에 저장된 레코드를 검색, 추가, 수정, 삭제하는 것이다. DML 명령어는 사용 빈도가 매우 높으며, 애플리케이션의 핵심 비즈니스 로직을 구현하는 데 주로 활용된다.

가장 기본적이고 핵심적인 DML 명령어는 다음과 같다.

* SELECT: 하나 이상의 테이블에서 데이터를 조회한다. 다양한 조건(WHERE), 정렬(ORDER BY), 그룹화(GROUP BY)와 결합(JOIN)을 통해 복잡한 질의를 수행할 수 있다.

* INSERT: 새로운 레코드(행)를 특정 테이블에 추가한다.

* UPDATE: 테이블 내에 이미 존재하는 레코드의 값을 수정한다. 일반적으로 WHERE 절과 함께 사용하여 특정 행만을 대상으로 한다.

* DELETE: 테이블에서 기존 레코드를 제거한다. WHERE 절 없이 사용하면 테이블의 모든 데이터가 삭제될 수 있다.

이 명령어들은 트랜잭션의 핵심 구성 요소로 작동한다. INSERT, UPDATE, DELETE로 이루어진 변경 작업은 COMMIT 명령이 실행되기 전까지는 영구적으로 적용되지 않으며, ROLLBACK 명령을 통해 변경 사항을 취소하고 트랜잭션 시작 전 상태로 되돌릴 수 있다[5]. SELECT 문은 일반적으로 데이터를 읽기만 하므로 트랜잭션의 롤백 대상에 포함되지 않지만, 특정 트랜잭션 격리 수준에서는 읽기 작업도 트랜잭션의 영향을 받을 수 있다.

DCL은 데이터베이스의 보안과 접근 권한을 관리하는 SQL 명령어의 집합이다. 주로 데이터베이스 관리자(DBA)가 사용하며, 데이터에 대한 접근을 제어하고 사용자에게 특정 작업을 수행할 수 있는 권한을 부여하거나 회수하는 데 목적이 있다. 이를 통해 데이터의 무단 접근, 수정, 삭제를 방지하고 데이터 무결성과 보안을 유지한다.

DCL의 주요 명령어는 GRANT와 REVOKE이다. GRANT 명령어는 사용자나 역할(Role)에게 특정 데이터베이스 객체(예: 테이블, 뷰)에 대한 권한을 부여한다. 부여할 수 있는 권한에는 SELECT(조회), INSERT(삽입), UPDATE(수정), DELETE(삭제)와 같은 객체 권한과, 데이터베이스나 스키마를 생성할 수 있는 CREATE와 같은 시스템 권한이 포함된다. 예를 들어, GRANT SELECT, INSERT ON employees TO user1;은 user1에게 employees 테이블을 조회하고 새 행을 삽입할 수 있는 권한을 준다.

반대로, REVOKE 명령어는 이미 부여된 권한을 취소한다. 권한 관리 정책이 변경되거나 사용자의 역할이 바뀌었을 때 필요하다. 예를 들어, REVOKE INSERT ON employees FROM user1;을 실행하면 user1은 더 이상 해당 테이블에 데이터를 삽입할 수 없다. 권한은 일반적으로 개별 사용자에게 직접 부여하기보다는 역할을 생성하고 그 역할에 권한을 부여한 후, 사용자를 해당 역할에 할당하는 방식으로 관리하여 효율성을 높인다.

일부 RDBMS는 GRANT와 REVOKE 외에 DENY와 같은 명령어를 추가로 제공하기도 한다[6]. DENY는 특정 권한을 명시적으로 거부하며, 이는 다른 경로를 통해 부여된 권한보다 우선시된다. DCL을 통한 세밀한 권한 제어는 다중 사용자 환경에서 데이터 보안의 핵심 메커니즘이 된다.

오라클 데이터베이스(Oracle Database)는 미국 오라클사가 개발하고 판매하는 객체-관계형 데이터베이스 관리 시스템이다. 1979년에 최초로 출시된 이후, 기업용 데이터베이스 시장에서 오랜 기간 선도적인 위치를 차지해왔다. 높은 신뢰성, 확장성, 그리고 강력한 기능 세트를 특징으로 하며, 대규모 트랜잭션 처리와 복잡한 비즈니스 애플리케이션을 위한 핵심 인프라로 널리 사용된다.

이 시스템의 주요 아키텍처 구성 요소로는 SGA(시스템 글로벌 영역)와 백그라운드 프로세스가 있다. SGA는 데이터베이스 인스턴스가 시작될 때 할당되는 공유 메모리 영역으로, 데이터 버퍼 캐시와 리두 로그 버퍼 등을 포함한다. 백그라운드 프로세스는 데이터베이스의 핵심 기능을 담당하며, DBWn(데이터베이스 기록기), LGWR(로그 기록기), PMON(프로세스 모니터), SMON(시스템 모니터) 등이 대표적이다.

오라클 데이터베이스는 고급 기능을 다수 제공한다. RAC(리얼 애플리케이션 클러스터)는 여러 서버가 단일 데이터베이스를 공유하여 고가용성과 확장성을 실현하는 기술이다. Data Guard는 재해 복구 솔루션으로, 프라이머리 데이터베이스의 변경 사항을 스탠바이 데이터베이스에 지속적으로 적용하여 데이터 보호를 보장한다. 또한, 플래시백 기술을 통해 사용자 오류로 인한 데이터 손실을 특정 시점으로 롤백하여 복구할 수 있다.

주요 버전의 발전은 다음과 같은 연표로 정리할 수 있다.

라이선스 모델은 복잡한 편으로, 프로세서 단위 또는 사용자 수(NAU)를 기준으로 구매한다. 높은 성능과 기능에 대한 대가로, 타 오픈소스 제품에 비해 상당히 비싼 라이선스 비용이 요구되는 것이 일반적인 평가이다. 최근에는 오라클 클라우드를 통한 구독형 서비스와 자율 운영 데이터베이스(Autonomous Database)로의 전환을 적극적으로 추진하고 있다.

Microsoft SQL Server는 마이크로소프트가 개발하고 판매하는 상업용 관계형 데이터베이스 관리 시스템(RDBMS)이다. 주로 윈도우 서버 운영 체제 환경에서 실행되도록 설계되었으며, .NET 프레임워크와의 긴밀한 통합을 특징으로 한다. 기업용 애플리케이션, 데이터 웨어하우징, 비즈니스 인텔리전스 솔루션 등 중대형 규모의 비즈니스 환경에서 널리 사용된다.

주요 버전은 SQL Server 2005, SQL Server 2008 R2, SQL Server 2012, SQL Server 2016, SQL Server 2019, SQL Server 2022 등으로 발전해왔다. 각 주요 릴리스마다 성능, 보안, 고가용성 기능이 지속적으로 강화되었다. 핵심 구성 요소로는 데이터베이스 엔진(데이터베이스 엔진), SSIS(SQL Server Integration Services), SSAS(SQL Server Analysis Services), SSRS(SQL Server Reporting Services) 등이 있으며, 이는 데이터 통합, 분석, 보고를 위한 포괄적인 플랫폼을 제공한다.

다음은 주요 버전별 특징을 요약한 표이다.

라이선스 모델은 코어 기반 라이선싱과 서버+CAL(클라이언트 액세스 라이선스) 모델을 제공한다. 또한 마이크로소프트는 Azure SQL Database라는 완전 관리형 PaaS(Platform as a Service) 형태의 클라우드 서비스도 운영하며, 이는 온프레미스 SQL Server와 높은 호환성을 유지한다.

MySQL은 1995년 스웨덴의 MySQL AB사가 개발한 오픈 소스 관계형 데이터베이스 관리 시스템이다. C와 C++로 작성되었으며, GPL과 상용 라이선스를 함께 제공하는 이중 라이선스 정책을 채택했다. 초기에는 웹 애플리케이션과 결합하여 LAMP 스택(Linux, Apache, MySQL, PHP/Perl/Python)의 핵심 구성 요소로 빠르게 보급되었다. 2008년 썬 마이크로시스템즈에 인수되었고, 이후 2010년 오라클이 썬을 인수함에 따라 현재는 오라클의 소유가 되었다.

오라클의 인수 이후 커뮤니티의 우려 속에서 MySQL의 포크(fork) 프로젝트인 MariaDB가 탄생했다. MariaDB는 MySQL의 창시자인 몬티 와이드니어스(Monty Widenius)가 주도하여 2009년 개발을 시작했다. 이는 MySQL의 오픈 소스 정신과 개발 방향성을 지키기 위한 목적이었다. MariaDB는 MySQL과 높은 호환성을 유지하며, MySQL의 API와 프로토콜을 그대로 사용할 수 있어 대부분의 경우 드라이버나 애플리케이션 코드 변경 없이 교체가 가능하다.

두 시스템의 주요 특징과 차이점은 다음과 같다.

MySQL은 전통적으로 웹 호스팅 분야에서 압도적인 점유율을 차지하며 대표적인 오픈 소스 RDBMS로 자리 잡았다. 반면 MariaDB는 여러 리눅스 배포판(예: 레드햇 엔터프라이즈 리눅스, 우분투)의 기본 데이터베이스로 채택되며 점차 영향력을 확대하고 있다. 둘 다 온라인 트랜잭션 처리(OLTP) 환경에 적합하며, 비교적 가볍고 설치 및 관리가 용이하다는 공통점을 지닌다.

PostgreSQL은 오픈 소스 객체 관계형 데이터베이스 관리 시스템(ORDBMS)이다. BSD 허가서를 따르는 자유 소프트웨어로, 상업적 이용을 포함한 자유로운 사용, 수정, 배포가 가능하다. 1986년 캘리포니아 대학교 버클리에서 시작된 POSTGRES 프로젝트를 기반으로 하여 발전했으며, 1996년 SQL 언어 지원을 강화하며 현재의 이름으로 변경되었다. 높은 신뢰성, 기능 완성도, 표준 준수로 평가받으며, 특히 복잡한 쿼리와 대용량 데이터 처리에 강점을 보인다.

주요 기술적 특징으로는 표준 SQL을 광범위하게 지원하는 것은 물론, JSON 및 JSONB 데이터 타입을 통한 반구조화 데이터 처리, 공간 데이터 확장 모듈인 PostGIS, 다양한 프로그래밍 언어(PL/pgSQL, PL/Python, PL/Java 등)를 이용한 저장 프로시저 작성, 풍부한 인덱스 유형(B-tree, Hash, GiST, SP-GiST, GIN, BRIN) 등을 꼽을 수 있다. 또한 MVCC(다중 버전 동시성 제어)를 구현하여 읽기와 쓰기 작업 간의 블로킹을 최소화하면서 데이터 무결성을 유지한다.

PostgreSQL의 커뮤니티는 활발한 개발과 지속적인 개선을 주도한다. 주요 릴리스는 매년 이루어지며, 성능 향상, 보안 강화, 새로운 기능 추가가 꾸준히 이뤄진다. 상용 데이터베이스에 버금가는 고급 기능들을 무료로 제공한다는 점에서 기업과 개발자들에게 널리 채택되고 있다. 클라우드 환경에서는 Amazon RDS for PostgreSQL, Google Cloud SQL for PostgreSQL, Azure Database for PostgreSQL과 같은 완전 관리형 서비스로도 쉽게 이용할 수 있다.

인덱싱은 RDBMS의 성능을 결정하는 핵심 요소 중 하나이다. 적절한 인덱스는 데이터 검색 속도를 획기적으로 향상시키지만, 잘못 설계된 인덱스는 불필요한 저장 공간을 차지하고 데이터 갱신(INSERT, UPDATE, DELETE) 성능을 저하시킬 수 있다. 효과적인 인덱싱 전략은 애플리케이션의 주요 쿼리 패턴, 데이터 분포, 그리고 시스템의 읽기/쓰기 비율을 종합적으로 분석하여 수립한다.

가장 기본적인 인덱스 유형은 단일 컬럼에 생성하는 B-트리 인덱스이다. 이는 등치 조회(=)나 범위 조회(BETWEEN, >, <)에 효율적이다. 자주 조인 조건이나 필터링 조건으로 사용되는 컬럼, 그리고 기본 키나 외래 키에는 일반적으로 인덱스를 생성한다. 반면, 카디널리티(중복도)가 매우 낮은 컬럼(예: 성별, 상태 코드)이나 자주 갱신되는 테이블에 과도한 인덱스를 생성하는 것은 피해야 한다.

복합 인덱스는 두 개 이상의 컬럼을 조합하여 생성하며, 컬럼의 순서가 성능에 결정적 영향을 미친다. 인덱스의 첫 번째 컬럼을 조건으로 사용하지 않는 쿼리는 대부분 인덱스를 효과적으로 활용하지 못한다. 따라서, 가장 자주 질의되고 선택도가 높은 컬럼을 선두에 배치하는 것이 원칙이다. 또한, 쿼리 최적화기에게 더 많은 정보를 제공하기 위해, 쿼리의 WHERE 절, ORDER BY 절, JOIN 절에 사용되는 모든 컬럼을 포함하는 커버링 인덱스를 구성할 수 있다. 이는 인덱스 자체에서 모든 필요한 데이터를 제공하므로 테이블 접근을 피해 성능을 극대화한다.

전문 검색이 필요한 텍스트 컬럼에는 B-트ree 대신 풀텍스트 인덱스를 고려해야 한다. 데이터베이스의 작업 부하를 주기적으로 모니터링하고, 사용되지 않는 인덱스를 제거하거나 쿼리 패턴 변화에 따라 인덱스를 재구성하는 것도 전략의 일부이다. 최적의 인덱싱은 데이터 모델링 단계에서 시작되어 애플리케이션의 전체 라이프사이클 동안 지속적으로 조정되는 과정이다.

쿼리 최적화는 RDBMS가 사용자의 SQL 질의를 가장 효율적으로 실행할 수 있는 실행 계획을 생성하고 선택하는 과정이다. 이 과정의 핵심 목표는 디스크 I/O, CPU 사용량, 메모리 소비를 최소화하여 응답 시간을 단축하고 시스템 자원의 부하를 줄이는 것이다. 쿼리 최적화기는 주어진 쿼리에 대해 여러 가지 가능한 실행 계획을 생성하고, 각 계획의 예상 비용을 계산하여 가장 낮은 비용의 계획을 선택한다.

최적화기는 주로 비용 기반 최적화 방식을 사용한다. 이 방식은 데이터베이스에 수집된 통계 정보를 기반으로 각 연산의 비용을 추정한다. 통계 정보에는 테이블의 총 행 수, 열의 고유 값 수, 값의 분포, 인덱스의 깊이와 카디널리티 등이 포함된다. 예를 들어, WHERE 절 조건에 해당하는 행의 비율을 추정하여 전체 테이블을 스캔할지 인덱스를 사용할지 결정한다. 통계 정보가 부정확하거나 오래된 경우 최적화기가 비효율적인 실행 계획을 선택할 수 있으므로 정기적인 통계 갱신이 중요하다.

실행 계획을 최적화하는 주요 기법으로는 조인 순서 변경, 조인 알고리즘 선택, 불필요한 연산 제거 등이 있다. 조인 연산 시 어떤 테이블을 외부 테이블로, 어떤 테이블을 내부 테이블로 할지, 그리고 중첩 루프 조인, 해시 조인, 병합 조인 중 어떤 알고리즘을 사용할지는 데이터 크기와 인덱스 존재 여부에 따라 결정된다. 또한, 쿼리 재작성 기법을 통해 사용자가 작성한 원본 쿼리를 의미는 동일하지만 더 효율적인 형태로 변환하기도 한다. 예를 들어, 서브쿼리를 조인으로 변환하거나, 복잡한 조건식을 단순화하는 작업이 여기에 해당한다.

개발자는 쿼리 성능을 개선하기 위해 실행 계획을 분석하고 최적화에 기여할 수 있다. 대부분의 RDBMS는 EXPLAIN 명령어를 제공하여 선택된 실행 계획을 단계별로 보여주고 각 단계의 예상 비용을 출력한다. 이를 통해 풀 테이블 스캔이 발생하는지, 적절한 인덱스가 사용되는지, 조인 순서가 비효율적인지 등을 확인할 수 있다. 분석 결과를 바탕으로 인덱스를 추가하거나 쿼리를 재구성하여 최적화기가 더 나은 계획을 선택하도록 유도한다.

정규화는 데이터베이스 설계 과정에서 데이터 중복을 최소화하고 데이터 무결성을 보장하기 위해 테이블을 구조화하는 체계적인 과정이다. 주로 이상 현상(Anomaly)을 제거하는 것을 목표로 한다. 이상 현상에는 갱신 이상, 삽입 이상, 삭제 이상이 포함된다. 정규화는 일반적으로 제1정규형(1NF)부터 보이스-코드 정규형(BCNF)까지 여러 단계로 진행되며, 각 단계는 특정 조건을 만족해야 한다.

정규화의 주요 단계와 목표는 다음과 같다.

반정규화는 정규화된 데이터베이스 구조에서 의도적으로 데이터 중복을 허용하거나 테이블을 통합하는 등의 작업을 말한다. 주된 목적은 읽기 성능을 향상시키는 것이다. 정규화가 지나치게 진행되면 하나의 논리적 작업을 처리하기 위해 너무 많은 테이블을 조인(Join)해야 하여 성능 저하가 발생할 수 있다. 반정규화는 이러한 상황에서 선택적으로 적용되는 기법이다.

반정규화의 대표적인 기법으로는 테이블 통합, 테이블 분할(수평/수직 분할), 중복 컬럼 추가, 파생 컬럼 추가, 요약 테이블 생성 등이 있다. 반정규화는 데이터 무결성을 훼손할 위험과 저장 공간 증가라는 대가를 수반한다. 따라서 성능 향상 효과와 이러한 단점을 신중하게 비교 분석한 후에 적용해야 한다. 데이터베이스 설계는 정규화를 통해 무결성을 확보한 후, 성능 요구사항에 따라 선택적으로 반정규화를 수행하는 절충 과정이다.

RDBMS는 사전에 정의된 스키마에 따라 데이터를 테이블 형태로 구조화합니다. 각 테이블은 행(레코드)과 열(속성)로 구성되며, 열은 각 데이터 항목의 타입(예: 정수, 문자열, 날짜)을 엄격하게 정의합니다. 테이블 간의 관계는 기본 키와 외래 키를 통해 명시적으로 연결됩니다. 이 구조화된 접근 방식은 데이터 무결성과 일관성을 보장하는 데 강점을 가지지만, 스키마 변경이 비교적 유연하지 않다는 특징을 가집니다.

반면, NoSQL 데이터베이스는 단일한 데이터 모델을 따르지 않으며, 주로 다음 네 가지 범주로 나뉩니다.

이러한 NoSQL 모델들은 일반적으로 스키마를 고정하지 않거나 유연한 스키마(Schema-less 또는 Schema-flexible)를 채택합니다. 이는 애플리케이션 개발 중 데이터 구조를 쉽게 변경할 수 있게 해주지만, 데이터 일관성 수준은 RDBMS의 ACID 속성보다 느슨한 BASE 모델을 따르는 경우가 많습니다[9]. 따라서 데이터 모델의 근본적인 차이는 구조화된 테이블 관계 대신 유연한 형태의 데이터 저장에 초점을 맞추는지 여부에 있습니다.

RDBMS는 ACID 트랜잭션을 보장해야 하는 금융 거래 시스템, 재고 관리 시스템, 회계 소프트웨어 등에 가장 적합하다. 데이터의 정확성과 일관성이 최우선인 비즈니스 애플리케이션의 핵심에 위치한다. 또한 데이터 구조가 명확하고 사전에 정의된 스키마를 통해 안정적인 쿼리와 보고가 필요한 경우, 예를 들어 인사 관리, 고객 관계 관리(CRM), 엔터프라이즈 자원 관리(ERP) 시스템 등에서 널리 사용된다. 복잡한 조인과 집계 쿼리가 빈번하게 수행되는 분석 및 보고 환경에서도 RDBMS의 강력한 SQL 기능이 빛을 발한다.

반면, NoSQL 데이터베이스는 특정 사용 사례에서 더 나은 적합성을 보인다. 수평 확장성(Scale-out)이 매우 중요한 대규모 웹 애플리케이션(예: 소셜 미디어, 콘텐츠 관리 시스템)에서는 문서형(Document) 또는 키-값(Key-Value) 저장소가 선호된다. 또한 반정형 또는 비정형 데이터(예: JSON 문서, 로그 데이터, 센서 데이터)를 유연하게 처리해야 하거나, 데이터 모델이 빠르게 진화하는 프로토타입 개발 환경에서는 스키마의 유연성이 큰 장점으로 작용한다. 그래프 데이터베이스는 소셜 네트워크, 추천 엔진, 사기 탐지 시스템과 같이 데이터 간의 복잡한 관계와 연결을 탐색하는 데 특화되어 있다.

다음 표는 주요 사용 사례에 따른 데이터베이스 유형의 적합성을 비교한다.

현대 애플리케이션 아키텍처에서는 단일 데이터베이스 기술에만 의존하기보다는 폴리글랏 퍼시스턴스(Polyglot Persistence) 접근 방식이 일반화되고 있다. 이는 서비스의 특성에 따라 RDBMS와 다양한 NoSQL 데이터베이스를 함께 사용하여 각자의 장점을 최대한 활용하는 전략이다. 예를 들어, 핵심 주문 처리에는 RDBMS를 사용하고, 사용자 세션 데이터나 제품 조회 기록에는 키-값 저장소를, 제품 추천 엔진에는 그래프 데이터베이스를 적용할 수 있다.

관리형 데이터베이스 서비스(DBaaS)는 클라우드 서비스 제공업체가 RDBMS의 설치, 구성, 패치, 백업, 모니터링, 확장 등 운영상의 부담을 대신 관리해주는 서비스 모델이다. 사용자는 핵심 비즈니스 로직과 데이터 모델 설계, SQL 쿼리 작성에 집중할 수 있으며, 인프라 관리의 복잡성과 운영 비용을 크게 줄일 수 있다. 이 서비스는 일반적으로 종량제 또는 구독 기반 모델로 제공되어 초기 투자 비용 없이 필요에 따라 데이터베이스 리소스를 신속하게 확장하거나 축소할 수 있는 유연성을 제공한다.

주요 클라우드 제공업체들은 자체적으로 최적화된 관리형 RDBMS 서비스를 제공한다. AWS의 Amazon RDS는 MySQL, PostgreSQL, MariaDB, Oracle Database, Microsoft SQL Server 등 다양한 데이터베이스 엔진을 지원한다. Microsoft Azure는 Azure SQL Database를 통해 완전 관리형 SQL Server 환경을 제공하며, GCP는 Cloud SQL과 Cloud Spanner 서비스를 운영한다. 이러한 서비스들은 고가용성 구성, 자동 백업, 읽기 전용 복제본 생성, 암호화, 성능 모니터링 대시보드 등 엔터프라이즈급 기능을 기본으로 포함한다.

DBaaS의 도입은 조직의 데이터베이스 운영 패러다임을 근본적으로 변화시켰다. 데이터베이스 관리자(DBA)의 역할은 순수한 인프라 유지보수에서 성능 튜닝, 보안 정책 수립, 비용 최적화 등 더 높은 가치의 작업으로 전환되었다. 또한, 개발팀은 CI/CD 파이프라인과 쉽게 통합될 수 있는 데이터베이스 서비스를 통해 애플리케이션 개발과 배포 속도를 가속화할 수 있다. 그러나 벤더 종속성, 네트워크 지연 시간, 특정 제공업체의 한정된 기능 세트 등은 DBaaS 채택 시 고려해야 할 주요 요소이다.

클라우드 컴퓨팅의 확산과 함께 주요 클라우드 서비스 제공업체들은 자체적인 관리형 관계형 데이터베이스 관리 시스템 서비스를 제공하며, 이는 DBaaS의 핵심 구성 요소가 되었다. 이러한 서비스는 사용자가 하드웨어 프로비저닝, 데이터베이스 소프트웨어 설치, 패치 적용, 백업 등 인프라 관리 부담을 덜고, 주로 SQL을 사용하여 애플리케이션 개발과 데이터 관리에 집중할 수 있도록 설계되었다.

주요 제공업체별 대표 솔루션은 다음과 같다.

이들 클라우드 RDBMS 솔루션은 전통적인 온프레미스 데이터베이스의 핵심 기능을 유지하면서 탄력적인 확장성(스케일 업/아웃), 사용량 기반 과금 모델(종량제), 그리고 지리적 복제를 통한 재해 복구와 같은 클라우드 네이티브 장점을 추가한다. 선택은 기존 기술 스택, 특정 데이터베이스 엔진에 대한 요구사항, 비용 구조, 그리고 글로벌 인프라 통합 필요성에 따라 이루어진다.