RDBMS 기본 개념

오늘은 백엔드 개발의 가장 기본이면서도, 연차가 쌓일수록 그 중요성을 더 깊게 체감하게 되는 RDBMS(관계형 데이터베이스 관리 시스템)에 대해 이야기해보려 합니다.

우리가 매일 사용하는 서비스 뒤에는 수많은 데이터가 숨어 있고, 이를 어떻게 '잘' 관리하느냐가 곧 서비스의 안정성을 결정하죠.

1. 💾 왜 우리는 RDBMS를 배워야 할까요?

처음 프로그래밍을 배우면 데이터를 변수에 저장하거나 리스트에 담는 것부터 시작합니다.

하지만 프로그램이 종료되면 그 데이터는 모두 사라지죠. 데이터를 영구적으로 저장하기 위해 가장 먼저 떠올리는 것은 아마 엑셀(Excel)이나 텍스트 파일일 것입니다.

하지만 동시 접속자가 수만 명인 쇼핑몰을 운영한다고 가정해 봅시다.

• 여러 사람이 동시에 같은 상품의 재고를 수정한다면?
• 주문 정보는 저장됐는데, 결제 정보만 누락된다면?
• 수백만 개의 주문 데이터 중 특정 고객의 데이터를 찾는 데 1분이 걸린다면?

이런 문제를 해결하기 위해 등장한 것이 바로 RDBMS입니다.

RDBMS는 데이터를 표(Table) 형태로 관리하며, 데이터 간의 관계(Relationship)를 정의하여 데이터의 일관성과 무결성을 보장합니다.

단순히 저장하는 것을 넘어, '안전하고 빠르게' 관리하는 것이 핵심이죠. 실무에서는 사용자의 소중한 자산이나 이력을 다루기 때문에, RDBMS에 대한 이해는 백엔드 개발자에게 선택이 아닌 필수입니다.

2. ⚠️ 초보자들이 흔히 하는 실수

저 역시 주니어 시절, RDBMS를 단순히 '데이터 저장소'로만 생각해서 저질렀던 실수들이 있습니다. 여러분은 이런 시행착오를 겪지 않길 바랍니다.

① 모든 정보를 한 테이블에 몰아넣기 (비정규화의 함정)

"나중에 조인(Join)하기 귀찮으니까..."라는 생각으로 회원 이름, 주소, 주문 상품, 배송지 정보를 하나의 커다란 테이블에 다 넣는 경우가 있습니다. 이렇게 하면 데이터 중복이 발생하고, 회원 이름이 변경될 때 수천 개의 주문 행을 모두 수정해야 하는 끔찍한 상황(수정 이상)이 발생합니다.

② 인덱스(Index)는 마법의 도구?

조회가 느리다는 이유로 모든 컬럼에 인덱스를 거는 실수입니다. 인덱스는 읽기 속도를 높여주지만, 쓰기(Insert, Update) 속도를 늦춥니다. 또한 저장 공간도 추가로 차지하죠. 인덱스의 원리를 모른 채 남발하는 것은 성능 저하의 주범입니다.

③ 데이터 타입을 무조건 '문자열(VARCHAR)'로 설정

날짜 데이터는 DATETIME으로, 숫자는 INT나 DECIMAL로 관리해야 합니다. 하지만 귀찮다는 이유로 모두 VARCHAR로 저장하면, 나중에 날짜 범위를 조회하거나 숫자를 합산할 때 성능이 극도로 떨어지고 데이터가 오염될 가능성이 큽니다.

3. 🧠 RDBMS의 기본기와 구조

이제 본격적으로 RDBMS가 어떻게 구성되고 동작하는지 알아봅시다.

3.1. 테이블, 로우, 그리고 컬럼: 데이터의 집 🏠

RDBMS는 데이터를 2차원 표 구조로 관리합니다.

• 테이블(Table): 특정 주제(예: 사용자, 상품)에 대한 데이터 집합입니다.
• 로우(Row/Record): 테이블의 한 행으로, 구체적인 데이터 한 건을 의미합니다.
• 컬럼(Column/Field): 데이터의 속성(이름, 이메일, 가격 등)을 정의합니다.

3.2. 제약 조건 (Constraints): 데이터의 수문장 🛡️

데이터가 엉망으로 들어오는 것을 막기 위해 우리는 규칙을 정합니다.

• Primary Key (PK, 기본키): 각 행을 식별할 수 있는 유일한 값입니다. (중복 불가, NULL 불가)
• Foreign Key (FK, 외래키): 다른 테이블과의 연결 고리입니다. 데이터 간의 참조 무결성을 유지합니다.
• Unique: 해당 컬럼에 중복된 값이 들어올 수 없게 합니다.
• Not Null: 필수적으로 값이 채워져야 함을 의미합니다.

3.3. SQL: DB와 대화하는 공식 언어 🗣️

RDBMS를 조작하기 위해서는 SQL이라는 언어를 사용합니다. 크게 3가지로 나뉩니다.

✅ 테이블 생성 (DDL)

CREATE TABLE members (
    member_id INT PRIMARY KEY AUTO_INCREMENT, -- 고유 번호 (자동 증가)
    name VARCHAR(50) NOT NULL,               -- 이름 (필수)
    email VARCHAR(100) UNIQUE,               -- 이메일 (중복 불가)
    point INT DEFAULT 0                      -- 포인트 (기본값 0)
);

✅ 데이터 조작 (DML)

-- 데이터 추가
INSERT INTO members (name, email) VALUES ('홍길동', 'hong@test.com');

-- 데이터 수정
UPDATE members SET point = point + 100 WHERE member_id = 1;

✅ 데이터 조회와 조인 (DQL) 🌟

실무에서 가장 많이 쓰는 것은 역시 조회입니다. 특히 여러 테이블을 합쳐서 보는 JOIN이 핵심이죠.

-- 회원 정보와 그 회원의 주문 내역을 합쳐서 조회
SELECT m.name, o.order_date, o.amount
FROM members m
INNER JOIN orders o ON m.member_id = o.member_id
WHERE m.point > 50;

3.4. 관계(Relationship)의 설계

RDBMS의 핵심은 '관계'입니다.

1. 1:1 관계: 사용자 정보와 사용자 설정 정보 등.
2. 1:N 관계 (가장 흔함): 한 명의 사용자가 여러 개의 주문을 하는 경우.
3. N:M 관계: 여러 학생이 여러 수업을 듣는 경우. (중간에 '매핑 테이블'이 필요함)

3.5. 트랜잭션(Transaction)과 ACID

데이터베이스의 상태를 변화시키는 하나의 논리적 작업 단위를 트랜잭션이라고 합니다. 은행 송금을 예로 들면, '내 계좌 출금'과 '상대 계좌 입금'은 반드시 동시에 성공하거나 동시에 실패해야 합니다. 이를 보장하는 것이 ACID 원칙입니다.

• Atomicity (원자성): 다 성공하든가, 다 실패하든가! (All or Nothing)
• Consistency (일관성): 작업 후에도 DB 규칙(제약 조건)은 변함없어야 함.
• Isolation (격리성): 동시에 실행되는 트랜잭션들이 서로 방해하지 않음.
• Durability (지속성): 성공한 결과는 시스템이 고장 나도 영구적으로 저장됨.

4. 마무리: 오늘의 3줄 요약 📝

RDBMS는 현대 백엔드 아키텍처의 뿌리와 같습니다. 오늘 내용을 요약하면 다음과 같습니다.

1. RDBMS는 데이터를 표(Table) 형태로 관리하며, 데이터의 무결성과 일관성을 지키기 위해 사용한다.
2. PK와 FK를 통한 관계 설정이 핵심이며, 이를 통해 데이터 중복을 방지하고 체계적으로 관리한다.
3. 트랜잭션(ACID)은 데이터베이스가 안전하게 작업을 수행하게 만드는 가장 중요한 약속이다.