icon

안동민 개발노트

1장 : 데이터베이스 소개

데이터베이스란 무엇인가


프로그래밍을 배우면 가장 먼저 변수에 데이터를 저장합니다. 하지만 프로그램을 종료하면 변수의 값은 사라집니다. 그래서 파일에 저장합니다. 텍스트 파일, JSON, CSV — 작은 규모에서는 이것으로 충분합니다. 하지만 사용자가 수천, 수만 명이 되고, 여러 프로그램이 같은 데이터를 동시에 읽고 쓰기 시작하면, 파일 시스템만으로는 감당할 수 없는 문제가 터지기 시작합니다.

이 절에서는 데이터베이스가 왜 필요하고, 어떤 문제를 해결하며, 어떤 특성을 가지는지를 깊이 있게 살펴봅니다.


데이터와 정보

데이터(Data)는 관찰이나 측정을 통해 수집된 사실입니다. "25", "서울", "2024-01-15" 같은 날것의 값입니다. 이 자체로는 큰 의미가 없습니다.

정보(Information)는 데이터를 가공하여 의미를 부여한 결과입니다. "서울 지역의 1월 평균 기온은 -2.5도"처럼 의사 결정에 활용할 수 있는 형태입니다.

지식(Knowledge)은 정보를 축적하고 분석하여 얻은 체계적 이해입니다. "서울의 1월 기온은 해마다 하강하는 추세이므로, 올겨울 방한 용품 재고를 20% 늘려야 한다"처럼 행동 지침으로 이어집니다.

데이터 → 정보 → 지식
데이터:  25, 서울, 2024-01-15, -3, 맑음
  ↓ 수집 · 정리
정보:    "2024년 1월 15일 서울의 기온은 -3도, 날씨 맑음"
  ↓ 분석 · 패턴 파악
지식:    "서울 1월 평균 기온은 매년 0.2도씩 하강 추세"
  ↓ 의사 결정
행동:    "방한 용품 재고 20% 증대"

데이터베이스는 이 데이터를 체계적으로 저장하고, 필요할 때 빠르게 꺼내어 정보로 변환할 수 있도록 조직화한 구조입니다.


데이터베이스의 정의

데이터베이스(Database)는 특정 조직의 여러 사용자가 공유하여 사용할 수 있도록 통합하여 저장운영 데이터의 집합입니다.

이 정의에는 네 가지 핵심 키워드가 있습니다.

Excalidraw 씬을 불러오는 중입니다.

데이터베이스의 정의를 이루는 네 가지 성격을 공유, 통합, 저장, 운영 관점으로 정리한 도식입니다.

통합중복이 없다는 뜻은 아닙니다. 성능이나 안정성을 위해 최소한의 통제된 중복은 허용합니다. 핵심은 통제되지 않은 중복을 방지하는 것입니다.


데이터베이스의 특성

데이터베이스는 다음 네 가지 특성을 가집니다.

실시간 접근성 (Real-time Accessibility)

사용자의 질의에 대해 즉시 응답을 반환합니다. 배치 처리가 아닌 온라인 처리 방식입니다.

실시간 접근 예시
사용자: "재고가 10개 미만인 상품을 알려줘"
시스템: 즉시 결과 반환 (밀리초 단위)
  →  마우스 (재고: 5)
  →  키보드 (재고: 3)

계속적 변화 (Continuous Evolution)

데이터베이스는 삽입, 삭제, 수정을 통해 항상 최신 상태를 유지합니다. 정적인 데이터 모음이 아니라 살아있는 데이터입니다.

계속적 변화 예시
시점 1: 재고 100개
시점 2: 주문 접수 → 재고 97개 (3개 감소)
시점 3: 입고 → 재고 147개 (50개 증가)
→ 항상 현재 상태를 정확히 반영

동시 공유 (Concurrent Sharing)

여러 사용자가 동시에 같은 데이터에 접근할 수 있습니다. 한 사용자가 사용 중이라고 다른 사용자가 기다릴 필요가 없습니다.

동시 공유 예시
시점 T: 
  사용자 A → 상품 목록 조회 (읽기)
  사용자 B → 같은 상품의 재고 수정 (쓰기)
  사용자 C → 같은 상품의 가격 조회 (읽기)
→ DBMS의 동시성 제어가 충돌을 방지

내용 기반 참조 (Content Reference)

데이터를 물리적 위치(주소, 파일 경로)가 아닌 내용(값)으로 참조합니다. 3번째 파일의 100번째 줄이 아니라, 이름이 김철수인 레코드로 찾습니다.

내용 기반 참조
-- 위치가 아닌 내용(값)으로 데이터를 찾음
SELECT * FROM employees WHERE name = '김철수';
SELECT * FROM products WHERE price > 50000 AND category = '전자';

파일 시스템의 한계

데이터베이스가 왜 필요한지 이해하려면, 파일 시스템으로 데이터를 관리할 때 어떤 문제가 생기는지를 먼저 봐야 합니다.

데이터 종속성 문제

파일 시스템에서는 데이터의 구조가 프로그램에 종속됩니다. 파일의 형식이 바뀌면 그 파일을 읽는 모든 프로그램을 수정해야 합니다.

데이터 종속성
프로그램 A → employees.csv (이름, 부서, 전화번호)
프로그램 B → employees.csv (이름, 부서, 전화번호)
프로그램 C → employees.csv (이름, 부서, 전화번호)

만약 employees.csv에 '이메일' 컬럼을 추가하면?
→ 프로그램 A, B, C를 모두 수정해야 함!
→ 데이터 구조와 프로그램이 강하게 결합

DBMS에서는 데이터 구조(스키마)를 프로그램과 분리합니다. 테이블에 컬럼을 추가해도 기존 SQL은 수정할 필요가 없습니다. 이것이 데이터 독립성입니다.

데이터 중복과 불일치

각 부서가 자기 파일에 같은 데이터를 따로 저장합니다. 수정할 때 모든 파일을 동시에 바꾸지 않으면 데이터가 어긋납니다.

데이터 중복과 불일치
인사팀 파일: employees.csv
  김철수, 개발팀, 010-1234, 서울

급여팀 파일: salary.csv
  김철수, 개발팀, 123-456, 5000

영업팀 파일: clients.csv
  김철수, 개발팀, k@mail.com

→ 김철수가 '기획팀'으로 이동하면?
→ 3개 파일을 모두 수정해야 함
→ salary.csv만 수정하고 나머지를 빼먹으면?
→ 인사팀 데이터와 급여팀 데이터가 불일치!

동시 접근 문제

두 사용자가 같은 파일을 동시에 수정하면, 한쪽의 변경이 사라질 수 있습니다. 파일 시스템에는 이를 조율하는 메커니즘이 없습니다.

동시 접근 문제
시점 T1: 사용자 A가 파일을 읽음 (재고 = 100)
시점 T2: 사용자 B가 파일을 읽음 (재고 = 100)
시점 T3: 사용자 A가 재고 - 10 = 90으로 저장
시점 T4: 사용자 B가 재고 - 5 = 95로 저장
→ 최종 재고 = 95 (A의 변경이 사라짐!)
→ 올바른 결과는 85여야 함

DBMS는 트랜잭션과 락(Lock) 메커니즘으로 이 문제를 해결합니다.

보안 문제

파일 시스템은 파일 단위로만 접근 권한을 설정할 수 있습니다. 이 파일의 급여 컬럼만 숨기고 이름은 보여줘같은 세밀한 제어가 불가능합니다.

무결성 제약 어려움

급여는 0 이상이어야 한다, 부서 코드는 부서 테이블에 존재해야 한다같은 규칙을 파일 시스템에서는 프로그램마다 직접 검증해야 합니다. DBMS는 제약 조건을 데이터베이스 레벨에서 선언적으로 관리합니다.

복구 어려움

파일 수정 중 시스템이 다운되면, 파일이 손상되거나 부분적으로만 수정된 상태로 남을 수 있습니다. DBMS는 로그 기반 복구로 이 문제를 해결합니다.

파일 시스템 vs DBMS 비교
| 문제점        | 파일 시스템     | DBMS                   |
| ------------- | --------------- | ---------------------- |
| 데이터 종속성 | 프로그램에 종속 | 데이터 독립성 보장     |
| 데이터 중복   | 통제 불가능     | 정규화로 최소화        |
| 동시 접근     | 충돌 발생       | 트랜잭션, 락으로 제어  |
| 보안          | 파일 단위만     | 컬럼/행 수준 세밀 제어 |
| 무결성        | 프로그램 각자   | 선언적 제약 조건       |
| 복구          | 수동 복구       | 로그 기반 자동 복구    |
| 검색          | 순차 탐색       | 인덱스, 옵티마이저     |

DBMS의 등장

이 모든 문제를 해결하기 위해 등장한 것이 DBMS(Database Management System)입니다. DBMS는 데이터베이스를 생성하고 관리하는 소프트웨어입니다.

DBMS의 역할
┌──────────────────────────────────────────┐
│            사용자 / 응용 프로그램        │
└──────────────┬───────────────────────────┘
               │ SQL 질의
┌──────────────┴─────────────────────────────┐
│              DBMS                          │
│  ┌───────────────────────────────────┐     │
│  │ 질의 처리: SQL 파싱, 최적화, 실행 │     │
│  ├───────────────────────────────────┤     │
│  │ 동시성 제어: 락, MVCC             │     │
│  ├───────────────────────────────────┤     │
│  │ 무결성 관리: PK, FK, CHECK        │     │
│  ├───────────────────────────────────┤     │
│  │ 권한 관리: GRANT, REVOKE          │     │
│  ├───────────────────────────────────┤     │
│  │ 복구 관리: 로그, 체크포인트       │     │
│  └───────────────────────────────────┘     │
└──────────────┬─────────────────────────────┘

┌──────────────┴──────────────────────────────┐
│          데이터베이스 (디스크)              │
└─────────────────────────────────────────────┘

DBMS의 장단점

DBMS 장점
* 데이터 독립성: 구조 변경이 프로그램에 영향 없음
  → 물리적 독립성: 인덱스 변경해도 SQL 수정 불필요
  → 논리적 독립성: 테이블 변경해도 뷰(VIEW)에 영향 없음
* 데이터 중복 최소화: 정규화로 통합 저장
* 데이터 일관성: 무결성 제약 자동 검증
* 동시성 제어: 여러 사용자의 동시 접근 안전
* 보안: 세밀한 접근 권한 관리
* 복구: 장애 발생 시 자동 복구
* 표준화: SQL이라는 표준 질의어
DBMS 단점
* 비용: 라이선스, 하드웨어, 교육 비용
* 복잡성: 설계, 운영, 튜닝에 전문 지식 필요
* 오버헤드: 단순 파일 접근보다 느릴 수 있음
* 단일 장애점: DBMS 장애 시 모든 시스템 영향
* 백업/복구 계획 필수: 데이터 손실 시 치명적

DBMS의 단점에도 불구하고, 데이터의 양이 많아지고 동시 접근이 필요한 거의 모든 시스템에서 DBMS는 필수적입니다. DBMS 없이 파일 시스템만으로 구축한 시스템이 규모가 커지면, 결국 DBMS가 제공하는 기능을 직접 구현해야 하므로 비용이 더 커집니다.

DBMS를 사용하지 않아도 되는 경우

모든 상황에서 DBMS가 필요한 것은 아닙니다.

DBMS가 불필요할 수 있는 상황
* 데이터가 매우 적고 구조가 단순할 때 (설정 파일 등)
* 동시 접근이 없고 단일 사용자만 사용할 때
* 실시간 처리가 불필요한 일괄 처리(Batch) 데이터
* DBMS의 오버헤드가 허용되지 않는 초저지연 임베디드 시스템
* 개인용 메모, 로그 파일 등 단순 기록

이런 경우에는 JSON 파일, CSV, SQLite 같은 경량 솔루션이 더 적합할 수 있습니다. 하지만 시스템이 성장할 가능성이 있다면 처음부터 DBMS를 사용하는 것이 장기적으로 유리합니다.


데이터베이스 시스템의 구성

데이터베이스 시스템은 데이터베이스, DBMS, 사용자, 응용 프로그램으로 구성됩니다.

데이터베이스 시스템 구성 요소
┌─────────────────────────────────────────────┐
│ 데이터베이스 시스템 (Database System)       │
│                                             │
│  ┌───────────┐  ┌─────┐  ┌───────────────┐  │
│  │ 사용자    │  │DBMS │  │ 데이터베이스  │  │
│  │ DBA,      │→ │SW   │→ │ (디스크 저장) │  │
│  │ 개발자,   │  │     │  │               │  │
│  │ 최종사용자│  │     │  │               │  │
│  └───────────┘  └─────┘  └───────────────┘  │
│                                             │
│  ┌───────────────────────────────────────┐  │
│  │ 응용 프로그램 (Application Programs)  │  │
│  │ 웹 서버, 모바일 앱, 분석 도구         │  │
│  └───────────────────────────────────────┘  │
└─────────────────────────────────────────────┘

혼용되기 쉬운 용어를 정리하면, 데이터베이스는 데이터 자체의 집합이고, DBMS는 데이터베이스를 관리하는 소프트웨어이며, 데이터베이스 시스템은 이 모든 것을 포함하는 전체 시스템입니다. 하지만 일상적으로 이 세 용어를 혼용하여 사용하는 경우가 많습니다.


데이터베이스의 발전 과정

1세대: 파일 시스템 (1950~60s)

초기 컴퓨터에서는 순차 파일(Sequential File)과 직접 파일(Direct File)로 데이터를 관리했습니다. 프로그램마다 자체 파일을 사용했으며, 위에서 설명한 종속성, 중복, 불일치 문제가 만연했습니다.

2세대: 계층형 · 네트워크형 데이터베이스 (1960~70s)

계층형 데이터베이스는 데이터를 트리(Tree) 구조로 표현합니다. IBM의 IMS(Information Management System)가 대표적이며, 아폴로 우주 프로그램의 부품 관리를 위해 개발되었습니다.

계층형 모델
        [대학교]
       /        \
  [공과대학]    [인문대학]
   /    \         |
[컴공]  [전기]  [국문]
  |       |       |
[김철수] [이영희] [박민수]

특징:
* 부모-자식 관계 (1:N만 가능)
* 루트에서 리프까지 경로가 유일
* M:N 관계를 표현하려면 데이터 중복 필요
* 포인터를 따라가는 절차적 탐색

네트워크형 데이터베이스는 CODASYL(Conference on Data Systems Languages) 위원회가 표준화했습니다. 계층형 모델의 한계를 극복하여 M:N 관계를 표현할 수 있지만, 프로그래밍이 매우 복잡했습니다.

네트워크형 모델
[학생:김철수]──→[수강]──→[과목:데이터베이스]
     │                          ↑
     └──→[수강]──→[과목:알고리즘]

[학생:이영희]──→[수강]──┘

특징
* 레코드 간 포인터로 연결 (그래프 구조)
* M:N 관계 표현 가능
* 프로그래밍 복잡: 포인터 탐색 코드 직접 작성
* 구조 변경 시 프로그램 수정 필수

3세대: 관계형 데이터베이스 (1970s~)

1970년 IBM 연구원 에드거 커드(Edgar F. Codd)가 발표한 논문 A Relational Model of Data for Large Shared Data Banks가 관계형 모델의 시작입니다.

관계형 모델의 혁신은 두 가지입니다.

첫째, 데이터를 단순한 테이블(릴레이션)로 표현하여, 포인터나 물리적 구조에 의존하지 않습니다. 둘째, 선언적 질의어(SQL)를 사용하여 무엇을 원하는가만 기술하면 되고, 어떻게 찾을지는 DBMS가 알아서 결정합니다.

관계형 모델의 혁신
계층형/네트워크형:
  "커서를 열고, 부모 레코드를 찾고,
   첫 번째 자식으로 이동하고,
   다음 자식으로 이동하고..."
  → 절차적 탐색 코드 수십 줄

관계형:
  SELECT 이름, 학과 FROM 학생 WHERE 학년 = 3;
  → 선언적 질의 한 줄

IBM의 System R과 UC Berkeley의 INGRES가 초기 관계형 시제품이며, 이후 Oracle, DB2, SQL Server, PostgreSQL, MySQL 등 오늘날의 주류 DBMS가 모두 관계형 모델을 기반으로 합니다.

4세대: NoSQL과 NewSQL (2000s~)

2000년대 후반 구글(Bigtable), 아마존(Dynamo) 등이 관계형 모델의 확장 한계에 직면하면서 NoSQL이 등장했습니다. 2010년대에는 관계형의 ACID와 NoSQL의 확장성을 결합한 NewSQL(Spanner, CockroachDB)이 등장했습니다.

데이터베이스 발전 타임라인
1950s  파일 시스템 (순차/직접 파일)
1960s  계층형 DB (IMS), 네트워크형 DB (CODASYL)
1970   관계형 모델 (E.F. Codd 논문)
1970s  System R, INGRES, SQL 탄생
1979   Oracle V2 (최초 상용 RDBMS)
1986   SQL-86 (최초 SQL 표준)
1992   SQL-92 (현재 SQL의 기반)
1996   PostgreSQL 출시
1999   SQL:1999 (재귀 쿼리, 트리거)
2003   SQL:2003 (윈도우 함수, XML)
2006   Google Bigtable 논문
2007   Amazon Dynamo 논문
2009   MongoDB 출시
2012   Google Spanner 논문
2016   SQL:2016 (JSON 지원)
2020s  벡터 DB, 서버리스 DB

데이터베이스 관련 핵심 용어

데이터베이스를 학습하기 전에 반드시 알아야 할 핵심 용어들을 정리합니다. 이 용어들은 앞으로 모든 장에서 반복적으로 등장합니다.

스키마와 인스턴스

스키마(Schema)는 데이터베이스의 구조와 제약 조건을 정의한 것입니다. 프로그래밍의 "타입 정의"에 해당합니다. 한 번 정의하면 자주 변경되지 않습니다.

인스턴스(Instance)는 특정 시점에 데이터베이스에 실제로 저장된 데이터의 집합입니다. 프로그래밍의 "변수 값"에 해당합니다. 시간에 따라 계속 변합니다.

스키마 vs 인스턴스 비유
┌──────────────────────────────────────────────────────┐
│ 스키마 (Schema) — "틀"                               │
│  학생(학번 INT, 이름 VARCHAR, 학과 VARCHAR)          │
│                                                      │
│ 인스턴스 (Instance) — "실제 데이터"                  │
│  (20240001, '김철수', '컴퓨터공학')                  │
│  (20240002, '이영희', '전자공학')                    │
│  (20240003, '박지민', '수학')                        │
└──────────────────────────────────────────────────────┘

비유하면, 스키마는 건물의 설계도이고 인스턴스는 설계도에 따라 실제로 지어진 건물입니다. 설계도(스키마)는 바뀌지 않지만, 건물 안의 사람들(인스턴스)은 수시로 바뀝니다.

메타데이터

메타데이터(Metadata)는 데이터에 대한 데이터입니다. 스키마 정보, 테이블 크기, 인덱스 정보, 사용자 권한 등이 메타데이터에 해당합니다. DBMS는 이러한 메타데이터를 데이터 사전(Data Dictionary)이라 불리는 특별한 저장소에 관리합니다.

메타데이터 예시
* 테이블 이름: 학생
* 컬럼 수: 3개
* 행 수: 1,000개
* 인덱스: 학번 (PRIMARY KEY)
* 생성 일시: 2024-01-15
* 마지막 수정: 2024-03-20
* 접근 권한: admin(RW), guest(R)

데이터 독립성

데이터 독립성은 하위 단계의 변경이 상위 단계에 영향을 미치지 않는 성질입니다.

데이터 독립성의 두 가지 유형
┌────────────────────────────────────────────────────────┐
│ 논리적 독립성 (Logical Independence)                   │
│  개념 스키마가 변경되어도 외부 스키마에 영향 없음      │
│  예: 테이블에 컬럼을 추가해도 기존 뷰(View)는 정상 동작│
├────────────────────────────────────────────────────────┤
│ 물리적 독립성 (Physical Independence)                  │
│  내부 스키마가 변경되어도 개념 스키마에 영향 없음      │
│  예: 인덱스를 추가/삭제해도 SQL 쿼리는 수정 불필요     │
└────────────────────────────────────────────────────────┘

이 독립성은 DBMS의 3단계 스키마 구조(외부-개념-내부)를 통해 실현됩니다. 스키마 구조에 대해서는 다음 절에서 자세히 학습합니다.


데이터 모델

데이터 모델은 데이터의 구조, 연산, 제약 조건을 정의하는 개념적 도구입니다. DBMS는 특정 데이터 모델을 기반으로 설계됩니다.

주요 데이터 모델
| 데이터 모델 | 구조              | 대표 DBMS     |
| ----------- | ----------------- | ------------- |
| 계층형      | 트리              | IMS           |
| 네트워크형  | 그래프            | CODASYL       |
| 관계형      | 테이블 (릴레이션) | Oracle, MySQL |
| 객체지향    | 객체              | ObjectStore   |
| 객체관계형  | 테이블 + 객체     | PostgreSQL    |
| 문서        | JSON/BSON 문서    | MongoDB       |
| 키-값       | 해시 맵           | Redis         |
| 그래프      | 노드 + 엣지       | Neo4j         |

현재 가장 널리 사용되는 것은 관계형 데이터 모델이며, 이 교재에서도 관계형 모델을 중심으로 학습합니다. 관계형 모델은 수학적 집합 이론을 기반으로 하여 데이터의 정확성을 수학적으로 증명할 수 있다는 강점이 있습니다.

데이터 모델을 선택할 때는 데이터의 특성, 질의 패턴, 확장성 요구사항, 일관성 요구 수준을 종합적으로 고려해야 합니다. 최근에는 하나의 시스템에서 여러 데이터 모델을 함께 사용하는 다중 모델(Polyglot Persistence) 접근법도 널리 활용됩니다. 예를 들어 사용자 정보는 관계형 DB에, 세션 캐시는 Redis에, 검색 로그는 Elasticsearch에 저장하는 식입니다.


핵심 정리

데이터베이스 핵심 요약
┌────────────────────────────────────────────────────┐
│ 데이터베이스 = 공유 + 통합 + 저장 + 운영 데이터    │
├────────────────────────────────────────────────────┤
│ 4대 특성                                           │
│  실시간 접근성: 즉시 응답                          │
│  계속적 변화: 항상 최신 상태                       │
│  동시 공유: 여러 사용자 동시 접근                  │
│  내용 기반 참조: 값으로 데이터 검색                │
├────────────────────────────────────────────────────┤
│ 파일 시스템 한계 → DBMS가 해결                     │
│  종속성 → 독립성     중복 → 정규화                 │
│  동시성 → 트랜잭션   보안 → 권한                   │
│  무결성 → 제약조건   복구 → 로그 기반              │
├────────────────────────────────────────────────────┤
│ 발전 과정                                          │
│  파일 → 계층형 → 네트워크형 → 관계형 → NoSQL/NewSQL│
├────────────────────────────────────────────────────┤
│ DB 시스템 = 데이터베이스 + DBMS + 사용자 + 응용    │
├────────────────────────────────────────────────────┤
│ 핵심 용어                                          │
│  스키마: DB의 구조 정의 (설계도)                   │
│  인스턴스: 특정 시점의 실제 데이터 (건물)          │
│  메타데이터: 데이터에 대한 데이터 (데이터 사전)    │
│  데이터 독립성: 논리적 독립성 + 물리적 독립성      │
└────────────────────────────────────────────────────┘

다음 절에서는 DBMS의 내부 구조와 핵심 기능을 살펴보겠습니다.

목차