팀의 데이터를 엑셀로 관리하다가 두 사람이 동시에 수정하면서 데이터가 꼬였습니다. 파일이 여러 개 복제되면서 어느 게 최신 버전인지도 모르게 됩니다. 수만 건에서 특정 조건을 검색하면 수 초씩 걸리고, 잘못된 데이터가 들어가도 막을 방법이 없습니다. DBMS가 왜 필요한지 이해하려면 파일 방식의 구체적인 한계를 먼저 알아야 합니다.

파일 기반 데이터 관리의 현실

스타트업 초기 단계에서 개발자들은 종종 CSV 파일에 사용자를 추가하고, 이메일로 조회하는 단순한 코드를 작성합니다. 처음에는 잘 동작하는 것처럼 보입니다. 하지만 실제 서비스에 투입되는 순간 다음과 같은 문제들이 연쇄적으로 터져 나옵니다.

문제 1: 동시 쓰기 충돌 (Concurrent Write Conflict)

두 명의 사용자가 동시에 회원가입을 시도하면 프로세스 A와 B가 모두 파일을 읽은 뒤 각자 새 줄을 추가합니다. 나중에 저장하는 쪽이 먼저 저장된 내용을 덮어씁니다. 결과적으로 프로세스 A가 저장한 사용자 데이터는 사라집니다. 이를 Lost Update(유실된 갱신)라고 합니다. 파일 시스템에는 이를 막을 잠금(lock) 메커니즘이 없습니다.

문제 2: 데이터 중복과 불일치

파일 여러 개로 데이터를 관리하다 보면 같은 정보가 여러 곳에 저장됩니다. orders.csv에 고객 이름과 이메일이 주문마다 반복 저장되면, 고객 정보가 바뀌었을 때 모든 파일에서 해당 데이터를 찾아 수정해야 합니다. 하나라도 빠뜨리면 데이터 불일치가 발생합니다.

문제 3: 무결성 제약 없음

CSV 파일에는 나이에 음수가 들어가도, 이메일 형식이 틀려도, 필수 값이 비어 있어도 그냥 저장됩니다. 파일은 데이터의 형식이나 범위를 전혀 검증하지 않습니다.

문제 4: 검색 성능 저하

100만 개의 레코드가 있는 CSV에서 특정 사용자를 찾으려면 파일 전체를 처음부터 끝까지 읽어야 합니다. 이를 Full Scan이라고 하며, O(n) 시간 복잡도를 가집니다. 평균적으로 50만 번의 비교 연산이 필요합니다.

문제 5: 트랜잭션 없음

쇼핑몰 주문 처리에서 "재고 감소 → 주문 생성 → 결제 처리"는 하나의 단위로 성공하거나 실패해야 합니다. 파일 기반에서 두 번째 단계까지 성공한 뒤 시스템이 다운되면, 재고는 줄었고 주문은 생성됐는데 결제 기록은 없는 불일치 상태가 영구적으로 남게 됩니다.

파일 방식 vs DBMS 비교

다섯 가지 문제를 나란히 놓고 보면 파일과 DBMS의 차이가 한눈에 들어옵니다.

두 사용자가 동시에 같은 상품의 마지막 재고를 구매했습니다. 재고가 음수가 됩니다. 서버 재시작 중에 결제 데이터가 유실됩니다. 잘못된 형식의 값이 그대로 저장됩니다. DBMS는 동시성 제어, 무결성 제약, 영속성 보장으로 이 문제들을 시스템 수준에서 차단합니다. 이 네 가지 역할을 이해해야 DB를 단순 저장소가 아닌 엔지니어링 도구로 쓸 수 있습니다.

DBMS란 무엇인가

**DBMS(Database Management System)**는 데이터를 체계적으로 저장, 관리, 검색하기 위한 소프트웨어 시스템입니다. 1970년 Edgar F. Codd가 IBM에서 관계형 모델을 제안한 이후, 오늘날 PostgreSQL, MySQL, Oracle, SQL Server 등 수많은 RDBMS가 이 원칙을 구현하고 있습니다.

애플리케이션은 SQL 쿼리를 DBMS 엔진으로 보내고, 엔진은 내부적으로 쿼리 파싱 → 실행 계획 수립 → 트랜잭션 처리 → 잠금 관리 → 디스크 I/O 순서로 처리합니다. 개발자는 이 복잡한 과정을 SQL 한 줄로 요청하기만 하면 됩니다.

ACID: DBMS의 핵심 보장

DBMS가 파일과 근본적으로 다른 이유는 ACID 트랜잭션을 보장하기 때문입니다.

ACID의 각 속성은 트랜잭션 모듈에서 구체적인 메커니즘과 함께 자세히 다룹니다. 이 모듈에서는 "DBMS가 이 네 가지를 보장한다"는 사실만 기억하면 충분합니다.

동시성 제어: 잠금(Lock)과 MVCC

DBMS는 동시 접근을 제어하기 위해 잠금(Lock) 또는 **MVCC(Multi-Version Concurrency Control)**를 사용합니다. PostgreSQL은 MVCC를 기본으로 채택합니다. 아래 예시에서 두 UPDATE는 하나의 트랜잭션으로 묶여 원자적으로 처리됩니다. 중간에 실패하면 두 변경 모두 롤백됩니다.

BEGIN;
UPDATE accounts SET balance = balance - 100000 WHERE id = 1;
UPDATE accounts SET balance = balance + 100000 WHERE id = 2;
COMMIT;

실행 완료 또는 조회 결과가 표시됩니다.

인덱스: 검색 성능 혁신

DBMS는 B-Tree 등의 자료구조를 사용한 인덱스를 제공합니다. 인덱스 없이는 100만 건 중 1건을 찾으려면 최대 100만 번 비교가 필요하지만, B-Tree 인덱스가 있으면 최대 20번 비교로 충분합니다(O(log n)). 아래에서 인덱스를 생성하면 이후 email 조건 검색에 Full Table Scan 대신 인덱스가 자동으로 사용됩니다.

CREATE INDEX idx_users_email ON users(email);

SELECT * FROM users WHERE email = 'kim@example.com';

무결성 제약: 잘못된 데이터 차단

테이블 정의에 제약조건을 걸면 DBMS가 INSERT/UPDATE 시점에 자동으로 검증합니다. 아래 테이블에 나이가 음수이거나 이메일이 중복된 행을 삽입하려 하면 DB가 즉시 오류를 반환합니다.

CREATE TABLE users (
    id        SERIAL PRIMARY KEY,
    name      VARCHAR(100) NOT NULL,
    email     VARCHAR(255) UNIQUE NOT NULL,
    age       INT CHECK (age >= 0 AND age <= 150),
    created_at TIMESTAMP DEFAULT NOW()
);

역사적 맥락: 관계형 DB의 탄생

• 1970년: Edgar F. Codd, IBM 연구소에서 관계형 모델 논문 발표
• 1974년: IBM System R 프로젝트 — SQL의 전신인 SEQUEL 개발
• 1979년: Oracle(Relational Software Inc.)이 최초 상용 RDBMS 출시
• 1986년: SQL이 ANSI 표준으로 채택
• 1989년: PostgreSQL의 전신 Postgres 프로젝트 시작 (UC Berkeley)
• 1995년: MySQL 첫 공개 릴리스
• 현재: 클라우드 네이티브 환경에서도 PostgreSQL, MySQL이 가장 널리 사용

파일 저장에서 DBMS로의 전환은 단순한 기술 선택이 아닙니다. 데이터를 진지하게 다루기 시작하는 순간, DBMS는 선택이 아닌 필수입니다.