RDB란 무엇인가 — 관계형 데이터베이스의 본질

데이터를 다루는 방법은 수십 년간 진화해 왔지만, 오늘날 대부분의 서비스는 여전히 **관계형 데이터베이스(Relational Database, RDB)**를 핵심 저장소로 사용합니다. “관계형”이라는 단어는 테이블과 테이블 사이의 연결을 뜻하기보다, 수학의 관계(Relation) — 즉 집합론에서 출발한 엄밀한 개념에서 비롯됩니다. 이 글에서는 RDB가 왜 만들어졌는지, 어떤 원칙 위에서 동작하는지, 그리고 SQL이 왜 지금도 압도적인 이유를 살펴봅니다.

RDB가 해결하는 문제

1970년대 이전에는 데이터를 계층형(Hierarchical) 또는 네트워크형(Network) 모델로 저장했습니다. 데이터를 꺼내려면 포인터를 따라가는 코드를 직접 작성해야 했고, 저장 구조가 바뀌면 애플리케이션 전체를 다시 짜야 했습니다. Edgar F. Codd는 1970년 논문 *“A Relational Model of Data for Large Shared Data Banks”*에서 이 문제를 근본적으로 해결하는 아이디어를 제안합니다.

핵심 아이디어는 세 가지입니다.

물리적 독립성: 파일이 어떻게 저장되든, 애플리케이션은 논리적 테이블만 보면 된다.
수학적 기반: 집합 연산(합집합, 교집합, 차집합, 곱집합)으로 데이터를 조합할 수 있다.
선언적 질의: 원하는 결과를 “선언”하면 DB 엔진이 최적 방법을 알아서 찾아준다.

RDB 개념도

테이블, 행, 열

관계형 모델에서 데이터는 **테이블(Table, Relation)**에 담깁니다.

용어	수학적 용어	의미
테이블	Relation	동일한 스키마를 가진 행의 집합
행	Tuple	하나의 레코드
열	Attribute	특정 속성 (이름, 나이 등)
셀 값	Value	단일 원자 값 (NULL 포함)

집합론의 성질상 테이블 안에는 중복 행이 없어야 하고, 행의 순서는 의미가 없습니다. 이 제약이 PK(기본 키)의 필요성으로 이어집니다.

SQL: 선언적 언어

SQL(Structured Query Language)은 절차형이 아닌 선언형 언어입니다. “어떻게 가져올지”가 아니라 “무엇이 필요한지”를 기술합니다. 옵티마이저가 최적 실행 계획을 고르는 일은 DBMS가 담당합니다.

SQL 코드 예시

-- 가장 단순한 조회
SELECT name, email
FROM   customers
WHERE  id = 1;

동일한 결과를 C나 Java로 직접 파일에서 읽는다면 파일 열기 → 레코드 순회 → 조건 검사 → 결과 수집의 수십 줄 코드가 필요합니다. SQL은 이를 세 줄로 압축합니다.

RDB가 제공하는 무결성 보장

RDB는 데이터가 올바른 상태를 유지하도록 여러 **제약(Constraint)**을 지원합니다.

기본 키(PK): 행을 유일하게 식별
외래 키(FK): 다른 테이블의 PK를 참조해 관계 정합성 보장
NOT NULL: 필수 값 강제
CHECK: 범위·패턴 조건 강제
UNIQUE: 중복 값 방지

이 제약들은 애플리케이션 코드 밖에서 DB 엔진이 강제하므로, 어떤 경로로 데이터가 들어오더라도 일관성이 유지됩니다.

왜 아직도 RDB인가?

NoSQL이 등장한 지 20년이 넘었지만 RDB의 점유율은 여전히 높습니다. 이유는 간단합니다.

트랜잭션(ACID): 돈이 오가거나 재고가 변경되는 작업에서 “모두 성공하거나 모두 실패”는 필수입니다.
관계 표현: 외래 키와 JOIN을 통해 복잡한 비즈니스 관계를 자연스럽게 모델링합니다.
표준 SQL: 어느 RDBMS든 SQL을 알면 문법 차이만 조금 있을 뿐 동일하게 다룰 수 있습니다.
성숙한 생태계: 옵티마이저, 인덱스, 파티션 등 수십 년 축적된 최적화 기법이 내장되어 있습니다.

정리

RDB는 “데이터를 행과 열의 테이블에 저장하고, SQL로 선언적으로 다루며, 제약으로 무결성을 지킨다”는 단순하지만 강력한 원칙 위에 세워져 있습니다. 이 시리즈 전체는 이 원칙을 깊이 파헤치는 여정입니다. 다음 글에서는 관계형 모델의 수학적 토대를 좀 더 구체적으로 살펴봅니다.

다음 글: 관계형 모델의 핵심 — 테이블, 키, 그리고 관계

읽어주셔서 감사합니다. 😊