파일 탐색기도 DB처럼 CRUD 가능한데 -
0️⃣들어가며
서버 개발을 시작하면 자연스럽게 이런 스택을 구성한다.
Spring Boot ↔ JPA ↔ JDBC ↔ DBMS (MySQL/PostgreSQL)나 역시 그랬고, "서버 개발 = 데이터는 DB에 저장"이 너무나 당연한 전제여서, 의심해본 적이 없었다.
JDBC 드라이버를 연결하고, JPA 엔티티를 정의하고, Repository를 만들고...
그런데 최근 사내 학습동아리의 강의 자료를 준비하면서 문득 궁금해진게 하나 있다.
"윈도우의 파일 탐색기나 DBMS나 데이터를 조회하고, 삭제하고, 수정하는 것에는 다름이 없지 않나?"
이 질문을 따라가다 보니, 내가 매일 쓰는 DBMS와 어떤 차이점이 있는지 알 수 있었다.
이 글은 그 과정의 정리다.
1️⃣파일 탐색기와 DBMS의 아키텍처
순수하게 아키텍처만 보면, 파일 탐색기와 DBMS 모두 CRUD의 최종 저장은 파일 시스템을 통해 이루어진다.
핵심 차이는 커널 그 위의 구성이다.
파일 탐색기는 데이터 관리 기능을 자체 구현하지 않고 전부 커널의 파일 시스템에 위임하는 반면, DBMS는 파일 시스템 위에 자체 처리 엔진을 추가로 구축했다. 트랜잭션, SQL, 동시성 제어라는 추가 기능은 이 엔진에서 나온다.
여기에 네트워크 프로토콜 계층이 더해지면서, 이 엔진을 다수의 원격 클라이언트가 동시에 이용하는 서버 모델이 완성된다.
공통점은 사용자 관점에서 CRUD라는 동일한 동사를 수행할 수 있다는 것, 그리고 데이터가 최종적으로 파일 시스템을 거쳐 블록 스토리지에 저장된다는 것이다. 다만 이 'CRUD를 할 수 있다'는 공통점이 나에겐 함정이였는데, 이는 다음 절에서 다룬다.
2️⃣비교 대상 오류
본론부터 말하면 "데이터의 CRUD 기능"에 국한하여 머릿속에서 둘을 비교 대상으로 올렸다.
최초의 관심사는 Windows의 파일 탐색기도 DBMS처럼 데이터(파일)에 대해 CRUD를 할 수 있는데, 그렇다면 둘은 어떤 차이가 있는지였다.
그러나 이 비교는 처음부터 잘못 구성되어 있었다.
둘은 파일 시스템 위에서 동작하는 사용자 모드 프로그램이라는 점에서 계층은 같지만, 탐색기는 CRUD 기능의 주체가 아니기 때문이다. 탐색기와 DBMS를 나란히 놓은 비교는, 정말 아주 작은 일부분을 전체로 착각했던 것과 같다.
그렇다면 "탐색기도 CRUD가 된다"는 처음의 관찰은 무엇이었을까.
파일 시스템에는 애초에 CRUD 기능이 내장되어 있다. (open, read, write, unlink라는 시스템 콜이 곧 파일 단위 CRUD 인터페이스다)
'탐색기가' CRUD를 제공한다고 본 것은 착각이었고, 실제로는 파일 시스템에 내장된 CRUD를 탐색기가 사람이 쓰기 쉽게 노출하고 있었을 뿐이다.
탐색기는 능력(capability)을 추가하지 않는다. 접근성(accessibility)만 추가한다.
반면 DBMS는 파일 시스템의 CRUD를 그대로 노출하는 것이 아니라, 그것을 원료 삼아 전혀 다른 층위의 CRUD(행 단위 연산과 트랜잭션 보장)를 새로 만들어낸 도구다.
같은 CRUD라는 단어가 탐색기에서는 파일 시스템 기능의 반사였고, DBMS에서는 새로 제조된 기능이었던 셈이다.
따라서 굳이 비교를 한다면, DBMS의 올바른 비교 대상은 탐색기가 아니라 파일 처리 시스템을 비교해야할 것이다.
다만 탐색기와의 비교가 무의미했던 것은 아니다.
같은 파일 시스템 위에서 아무것도 더하지 않는 프로그램(탐색기)과 새로운 계층을 건설한 프로그램(DBMS)을 나란히 놓았기에, DBMS의 본질이 '저장'이 아니라 '저장 위에 더한 보장'임을 알았기 때문이다.
저장은 파일 시스템이 한다.
DBMS는 그 위에서 어떠한 보장을 만든다.
-- 여기까지가 최초 논점의 결론이다.
아래는 파일 처리 시스템과 DBMS를 추가적으로 비교한 내용이다.
3️⃣파일 처리 시스템
DBMS가 등장하기 전인 1960년대, 업무 시스템의 데이터는 그냥 파일이었다.
이 시기에 주로 사용된 데이터를 다루는 방식이 파일 처리 시스템(File Processing System)이다.
파일 처리 시스템은 DBMS처럼 특정 제품(툴)을 지칭하는 용어가 아니다.
데이터를 관리하는 방식(접근법)을 가리키는 총칭이며, DBMS가 등장한 뒤 그 이전 방식과 대비하기 위해 정착된 용어에 가깝다.
DBMS라는 소프트웨어 계층 자체가 없던 시절, 프로그램이 데이터를 처리할 수 있는 방법은 파일을 직접 다루는 것뿐이었다.
데이터 관리를 독립된 계층으로 분리한다는 개념과 데이터 모델 이론 자체가 아직 발명되지 않았기 때문이다.
그리고 그 발명이 늦어진 배경에는 당시의 기술 환경이 있다.
- 저장 매체 제약 — 주 저장 매체였던 자기 테이프는 순차 접근만 가능했다. 처리 패턴은 자연스럽게 배치(batch)로 고정되었고, 랜덤 접근을 전제로 하는 데이터 관리 소프트웨어는 하드웨어적으로 성립할 수 없었다.
- 메모리 제약 — 수 KB~수십 KB 수준의 메모리로는 버퍼 풀, 락 테이블, 시스템 카탈로그 같은 상주형 관리 계층을 올릴 여유가 없었다.
- 요구사항 부재 — 당시 컴퓨터의 용도는 급여 계산, 회계 같은 정형화된 배치 업무뿐이었다. 다중 사용자의 동시 접근을 관리해야 할 필요 자체가 존재하지 않았다.
파일 처리 시스템은 프로그램 내 비즈니스 로직에 필요한 데이터를 특정 파일 단위로 관리하는 방식이다.
즉, 프로그램에 필요한 데이터를 파일로 관리하며, 필요한 데이터의 범주 수 = 관리해야 할 파일의 수가 된다.
예를 들어 부서별 프로그램은 각자 필요한 데이터를 담을 전용 파일을 갖는다.
| 부서 | 관리 파일 |
| 인사 | 인사 파일 |
| 회계 | 회계 파일 |
| 영업 | 영업 파일 |
이 때, 각 프로그램(부서)은 자신이 처리할 파일 구조를 개별 정의한다.
즉 파일 구조가 변경될 경우 프로그램 코드 수정이 필요하게 된다.
※ 프로그렘 - 데이터 의존성 문제
이러한 파일 처리 시스템은 프로그램 규모가 커질수록 몇 가지 문제점을 드러낸다.
이 문제점에 대해 정리가 잘 되어 있는 자료가 있어 공유한다. (파일 처리 시스템 자체의 설명도 포함되어 있다)
4️⃣문제를 해결하는 원리 - 데이터 독립성(Data Independence)
오늘날 위와 같은 레거시한 방법론(?)은 사용하지 않는다는 걸 알고 있다.
DBMS는 이러한 문제를 해결하여 나와 같이 머슬메모리처럼 '당연하게' 사용하는 툴이 되었다.
당연히 DBMS가 문제를 어떻게 해결했는지도 살펴보았다.
파일 처리 시스템의 근본 문제는 "데이터 구조를 아는 주체가 프로그램 자신"이라는 데 있었다.
파일의 필드 하나만 바뀌어도 그 파일을 쓰는 모든 프로그램을 고쳐야 했던 이유(위키독스 참고)가 여기에 있다.
DBMS는 이 문제를 해결하기 위해 데이터 구조(스키마)를 프로그램에서 분리한다.
프로그램은 더 이상 "몇 번째 바이트가 무슨 필드다"같은 걸 알 필요가 없고,
DBMS가 제공하는 인터페이스(SQL)에만 의존한다.
나는 이 과정을 추상화라고 생각한다.
구조가 바뀌어도 그 인터페이스가 유지되는 한 프로그램은 영향을 받지 않는다는게 데이터 독립성이다.
데이터 독립성은 논리적/물리적으로 나뉘며, 단순히 변경에 강함을 나타낸다.
| 구분 | 정의 | 예시 |
| 논리적 독립성 | 개념 스키마(테이블 구조)가 바뀌어도 응용 프로그램(외부 스키마)이 영향받지 않음 | EMPLOYEE 테이블에 hire_date 컬럼 추가 → 기존 조회 프로그램은 수정 불필요 |
| 물리적 독립성 | 저장 방식(내부 스키마)이 바뀌어도 개념 스키마와 응용 프로그램이 영향받지 않음 | 인덱스를 B-Tree에서 Hash로 변경, 저장 파일을 다른 디스크로 이전 → 쿼리는 그대로 동작 |
문제점 - 해결 원리
앞서 공유한 위키독스에 정리된 파일 처리 시스템의 문제들과 1:1로 대응시켜보자.
| 파일 처리 시스템의 문제 | DBMS의 해결방식 |
| 데이터 중복 | 부서별 파일 대신 하나의 통합 데이터베이스에 저장 |
| 데이터 불일치 | 중복이 줄어드니 불일치가 발생할 지점 자체가 감소 (파생오류) |
| 프로그램-데이터 의존성 | 스키마를 프로그램에서 분리 (논리적 독립성) |
| 데이터 공유 어려움 | 여러 응용 프로그램이 동일 DB를 공유/접근 |
| 접근성 제한 | SQL로 임의 조회·결합 가능 - 새 질문마다 프로그램을 새로 짤 필요 없음 |
| 유지보수 비용 증가 | 구조 변경의 영향 범위가 DBMS 내부로 국한됨 |
5️⃣마무리
'CS > DataBase' 카테고리의 다른 글
| MinIO - "온프레미스 S3" (0) | 2026.05.21 |
|---|---|
| 객체 스토리지 (Object Storage) (0) | 2026.05.21 |
| 블록, 파일, 객체 — 스토리지 3종류를 제대로 이해하기 (1) | 2026.05.05 |
| [TIL] RDBMS (1) | 2024.10.10 |
| [MySQL] 인덱스(INDEX) (1) | 2023.12.29 |
