💡 핵심 인사이트
데이터베이스가 하드 디스크에 남기는 물리적인 족적(파일 집합)은 크게 3가지로 나뉩니다.
실제 고객 정보가 담긴 데이터 파일, 만약의 사태를 대비한 블랙박스인 로그 파일(Redo Log), 그리고 데이터베이스 전체의 뼈대와 상태를 기록하는 뇌 구조도인 **제어 파일(Control File)**입니다.

Ⅰ. 데이터베이스의 물리적 3대 파일

메모리 위의 인스턴스(Instance)가 휘발성이라면, 이 파일들은 영속성(Durability)을 책임지는 데이터베이스의 영혼과 같습니다. (Oracle 및 MySQL InnoDB 기반 설명)

1. 데이터 파일 (Data Files)

• 역할: 실제로 사용자가 INSERT한 데이터(회원 정보, 게시글, 결제 내역)와 이를 빠르게 찾기 위한 인덱스(B-Tree) 구조가 고스란히 영구 저장되는 거대한 창고 파일입니다.
• 특징: .dbf, .ibd 등의 확장자를 가집니다. 크기가 수십 GB에서 수 TB에 달하며, 테이블스페이스(Tablespace)라는 논리적 덩어리에 매핑되어 관리됩니다.
• DBWR(Database Writer) 프로세스가 메모리의 더티 페이지를 이곳으로 쏟아냅니다.

2. 리두 로그 파일 (Redo Log Files / WAL Log)

• 역할: 비행기의 블랙박스이자 CCTV 녹화 테이프입니다. 데이터가 변경되는 모든 궤적("A의 잔고가 100에서 50으로 변함")을 시간순으로 아주 잘게 썰어서 무조건 기록해 두는 파일입니다.
• 왜 필요한가?: 서버가 갑자기 정전으로 죽었을 때, 시스템이 재부팅되면서 이 로그 파일을 처음부터 끝까지 재생(Redo)하면, 정전되기 1초 전의 완벽한 상태로 DB를 100% 살려낼 수 있습니다.
• 특징: 빠르고 순차적인 쓰기(Sequential Write)를 위해 2~3개의 파일 그룹을 원형 큐처럼 뺑글뺑글 돌며 덮어쓰는(순환) 구조를 가집니다. (LGWR 프로세스가 기록함)

3. 제어 파일 (Control File)

• 역할: 데이터베이스의 '호적 등본'이자 '나침반'입니다. 데이터베이스의 이름, 생성 시간, 데이터 파일과 로그 파일들이 디스크의 어느 경로(C:...)에 몇 개나 있는지에 대한 메타 정보를 담고 있습니다.
• 왜 중요한가?: 데이터베이스 서버가 켜질 때 가장 먼저 읽는 파일입니다. 이 제어 파일이 깨지거나 삭제되면, 데이터 파일 100TB가 멀쩡히 있어도 DB는 어디에 뭐가 있는지 몰라 아예 부팅(Mount)조차 되지 않습니다.
• 보호: 워낙 치명적이기 때문에, DBA(관리자)는 이 파일을 물리적으로 다른 하드 디스크 여러 곳에 2~3개씩 다중화(Multiplexing)하여 똑같이 복사해 둡니다.

Ⅱ. 부팅 과정에서의 파일 상호작용 (DB Open)

DB 서버 스위치를 켜면 인스턴스와 이 파일들이 어떻게 만날까요?

1. Nomount (메모리 로드): 메모리에 인스턴스(SGA)가 차려지고 백그라운드 프로세스가 깨어납니다.
2. Mount (제어 파일 읽기): 인스턴스가 하드디스크에 있는 **'제어 파일(Control File)'**을 찾아내어 읽습니다. 여기서 데이터 파일과 로그 파일의 위치를 파악합니다.
3. Open (데이터 파일 개방): 제어 파일에 적힌 주소를 따라가 **'데이터 파일'**과 **'리두 로그 파일'**의 락을 풀고 엽니다. 비로소 일반 사용자들이 SQL을 날려 데이터를 조회할 수 있게 됩니다.

📢 섹션 요약 비유: DB 물리 파일은 거대한 박물관 세트장입니다. 데이터 파일은 수백만 점의 유물이 보관된 '지하 수장고'이고, 로그 파일은 누가 언제 유물을 꺼내갔는지 적힌 '출입 보안 대장'이며, 제어 파일은 박물관의 모든 방 구조와 열쇠가 어디 있는지 그려져 있는 '마스터 도면'입니다. 도면이 타버리면 수장고가 멀쩡해도 아무 문도 열 수 없습니다.