DCL, 데이터베이스 구현, 스토리지 관리

• RAID (Redundant Array of Independent Disks)

여러 개의 하드디스크(HDD) 또는 SSD를 묶어서 성능을 높이거나, 데이터를 안전하게 보호하는 기술

 

여러 개의 하드디스크로 디스크 배열을 구성하고, 파일을 구성하는 데이터 블록들을 서로 다른 디스크들에 분산 저장할 경우 그 블록들을 여러 디스크에서 동시에 읽고 쓸 수 있으므로 디스크의 속도가 매우 향상된다.

 

하나의 디스크에 모든 데이터를 저장하면, 그 디스크는 한 번에 하나의 I/O 작업밖에 못 한다.

하드 디스크에는 내부에 하나의 읽기/쓰기 헤드가 있다.

그 헤드는 한 번에 하나의 위치만 접근 가능하다.

그래서 동시에 여러 요청이 들어오면 순차적으로 처리해야 한다.

 

SSD는 내부 구조상 병렬 처리가 더 자유롭지만, RAID 스트라이핑을 하면 더 큰 병렬성과 처리량을 확보할 수 있다

 

 

RAID 레벨과 설명

RAID 레벨	설명
RAID 0	스트라이핑(Striping) 방식, 성능 향상 O, 장애 대응 X, 데이터 보호 기능 없음, 여러 개의 디스크에 데이터를 나눠서 저장,
RAID 1	미러링(Mirroring) 방식, 장애 대응 O, 성능 향상 X
RAID 2	비트 단위 오류 검출 코드 사용 (잘 사용되지 않음)
RAID 3	바이트 단위 스트라이핑 + 패리티 디스크 (비효율적)
RAID 4	블록 단위 스트라이핑 + 전용 패리티 디스크
RAID 5	블록 단위 스트라이핑 + 분산 패리티 (성능/안정성 균형)
RAID 6	RAID 5 + 이중 패리티, 더 높은 내구성 제공
RAID 10 (1+0)	RAID 1과 RAID 0을 결합, 성능 + 장애 대응

출제 포인트:

• RAID 0, 1, 5, 10이 실기에서 자주 출제됨
• RAID 0과 RAID 1의 차이점
• RAID 5와 RAID 10의 특징 비교

 

** 스트라이핑(Striping)

데이터 블록 단위로 쪼개서 여러 개의 디스크에 분산하여 저장하는 기술

데이터를 저장할 때, 마치 줄무늬처럼 일정한 간격으로 데이터를 나눠서 여러 디스크에 분산 저장

데이터를 병렬로 분산 저장해 I/O 성능을 높이기 위해 사용하는 기술!

 

 

🔹 RAID 0 (스트라이핑, Striping)

💡 속도는 빠르지만, 데이터 보호 기능이 없음! (장애 발생 시 데이터 복구 불가)

• 여러 개의 디스크에 데이터를 나눠서 저장
• 읽기/쓰기 속도가 빨라짐
• 하지만! 한 개의 디스크라도 고장 나면 모든 데이터가 손실됨 😨

 

패리티가 없는 스트라이핑된 2개 이상의 디스크를 병렬로 연결하여 구성하는 방식

디스크의 개수가 증가할수록 입, 출력 속도 및 저장 용량이 배로 증가하지만,

하나의 디스크만 손상되어도 전체 데이터가 유실되는 문제가 발생한다.

 

 

🔹 RAID 1 (미러링, Mirroring - 중복 저장)

💡 디스크 하나가 망가져도 데이터 보호 가능! => 안정성이 높음. 고장 시 복구 가능

• 동일한 데이터를 두 개의 디스크에 똑같이 저장 => 이중화
• ❌ 단점: 디스크 사용 효율이 50%로 낮음

 

cf) 이중화(Duplication)

시스템의 가용성과 안정성을 높이기 위해 중요 구성 요소를 중복하여 구성하는 것

(1) 디스크 수준: RAID1과 같은 미러링 기술을 통해 데이터를 두 개 이상의 디스크에 동일하게 저장하여, 하나의 디스크에 장애가 발생해도 데이터 손실을 방지한다

(2) 서버 수준: 중요한 서버를 두 대 이상 운영, 한 대의 서버에 문제가 생겨도 다른 서버가 서비스를 지속적으로 제공할 수 있음

(3) 데이터센터 수준: 여러 데이터센터에 시스템을 분산 배치하여, 한 데이터센터의 문제가 발생해도 다른 데이터센터에서 서비스를 유지할 수 있게 함

 

 

🔹 RAID 5 (스트라이핑 + 패리티, Striping + Parity)

💡 속도 + 데이터 보호 둘 다 잡은 방식

• 데이터를 여러 개의 디스크에 나눠 저장 + 패리티(Parity) 정보 추가
• 패리티란? 데이터를 복구할 수 있는 정보

 

• 디스크 하나가 고장 나도, 나머지 디스크에서 데이터를 복구 가능!

✅ 장점: 성능 + 데이터 보호 균형 잡힘
❌ 단점: 패리티 저장 공간이 필요함 (디스크 1개 분량)

항목	내용
주요 기능	스트리핑 + 패리티 (복구 정보 저장)
데이터 보호	✅ 가능 (디스크 1개 고장 시 복구 가능)
속도	읽기 ✅ 빠름 / 쓰기 ❌ 느림 (패리티 연산 필요)
디스크 사용 효율	(N-1)/N (패리티를 1개 디스크 용량만큼 사용)
최소 디스크 개수	3개 이상
적용 사례	서버, 데이터센터, 대용량 저장소

 

 

🔹 RAID 10 (RAID 1 + RAID 0, 성능 + 안정성) => 복제하고 분산 저장

데이터를 미러링하여 이중화하고, 동시에 스트리핑으로 성능을 향상

그 복제된 데이터를 다시 **RAID 0(스트리핑)**으로 분산 저장하여 성능 향상

 

복제해서 2개 + 분산 저장해서 *2 => 최소 4개

 

💡 속도도 빠르고, 데이터 보호도 가능!

• RAID 1(미러링)과 RAID 0(스트라이핑)을 결합한 방식
• 데이터를 빠르게 저장하면서도 안정성 보장

✅ 장점: 빠르고 안전함
❌ 단점: 저장 공간이 절반만 사용됨 (비효율적)

 

 

 

 

DCL

 

 

데이터의 보안, 무결성, 회복, 병행 제어 등을 정의하는 데 사용하는 언어

데이터베이스 관리자(DBA)가 데이터 관리를 목적으로 사용한다

 

GRANT

 

 

데이터베이스 관리자가 데이터베이스 사용자에게 권한을 부여하는 데 사용하는 명령어

 

데이터베이스에서 특정 사용자나 역할에게 권한을 부여하는 SQL 명령어

 

GRANT 권한 1, 권한2 ON 테이블명 TO 사용자;

GRANT SELECT, INSERT, UPDATE ON employees TO user1;

 

권한을 다른 사용자에게 줄 수 있음

GRANT SELECT ON employees TO user1 WITH GRANT OPTION;

user1은 자신이 받은 SELECT 권한을 다른 사용자에게도 줄 수 있다

 

 

REVOKE

 

데이터베이스에서 특정 사용자나 역할(Role)에게 부여된 권한을 회수하는 SQL 명령어

 

REVOKE 권한1, 권한2 ON 테이블명 FROM 사용자;

REVOKE SELECT ON employees FROM user1;

 

모든 사용자에게서 권한 회수

REVOKE SELECT ON employees FROM PUBLIC;

 

✅ WITH GRANT OPTION을 통해 받은 권한을 회수하면,

✅ user1이 다른 사용자에게 부여했던 권한도 자동으로 사라짐!

 

부여할 수 있는 권한: ALL, SELECT, INSERT, DELETE, UPDATE, ALTER
권한 취소 시 권한을 부여받았던 사용자가 다른 사용자에게 부여한 권한도 연쇄적으로 취소하는 옵션은 CASCADE

 

REVOKE GRANT OPTION FOR SELECT ON 수강 FROM 박문수;

=> 다른 사람에게 부여하는 권한 제거

 

REVOKE SELECT ON 수강 FROM 박문수 CASCAD; 

=> 박문수에게 부여된 select 권한 취소, 다른 사람에게 select 권한 부여할 수 있는 권한 취소, 박문수가다른 사람에게 부여한 select 권한 취소

 

• 트랜잭션

 

데이터베이스에서 하나의 작업 단위

트랜잭션이 안전하게 처리되려면 ACID(Atomicity, Consistency, Isolation, Durability) 특성을 만족해야 한다.

 

(1) commit => 개발자가

 

트랜잭션을 정상적으로 완료하고 데이터베이스에 영구적으로 저장하는 연산

 

트랜잭션이 성공적으로 끝나면 데이터베이스가 새로운 일관성(Consistency) 상태를 가지기 위해 수행된 모든 변경을 데이터베이스에 반영하여 COMMIT하여야 한다.

 

(2) ROLLBACK => 개발자가

 

(약술형 기출) 트랜잭션이 실패할 경우 작업을 취소하고 이전 상태로 되돌리기 위한 명령어

트랜잭션 수행 중 문제가 발생하면, 변경된 데이터를 원래 상태로 되돌리는 연산

commit 전에만 실행 가능함

 

UPDATE account SET balance = balance - 10000 WHERE id = 1;

ROLLBACK;

 

트랜잭션의 일부를 성공적으로 끝내지 못하면 데이터베이스가 비일관적인 상태를 가질 수 있기 때문에 일부분만 완료된 트랜잭션은 롤백되어야 한다.

 

(3) REDO => 시스템이

 

트랜잭션이 성공적으로 완료(COMMIT)되었지만, 장애로 인해 데이터가 손실된 경우 다시 실행하는 과정

로그에 기록된 트랜잭션을 사용하여 작업을 재실행한다.

 

데이터베이스가 비정상적으로 종료되었을 때, 디스크에 저장된 로그를 분석하여 트랜잭션의 시작(start)과 완료(commit)에 대한 기록이 있는 트랜잭션들의 작업을 재작업한다. 즉 로그를 이용하여 해당 데이터 항목에 대해 이전 값을 이후 값으로 변경하는 연산

 

ex. 서버 장애로 DB가 종료되었지만, REDO를 사용해 최근 COMMIT된 데이터 복구 가능

 

 

(4) UNDO => 시스템이

 

데이터베이스가 비정상적으로 종료되었을 때, 디스크에 저장된 로그를 분석하여 트랜잭션의 시작을 나타내는 ‘start’는 있지만 완료를 나타내는 ‘commit’ 기록이 없는 트랜잭션들이 작업한 내용들을 모두 취소한다.

즉, 로그를 이용하여 해당 데이터 항목에 대해 이후 값을 이전 값으로 변경한다.

 

트랜잭션이 완료되지 않았는데 장애가 발생한 경우, 해당 트랜잭션이 변경한 데이터를 원래 상태로 복구하는 과정

ROLLBACK 시 UNDO가 실행됨

 

(5) RECOVERY

 

데이터베이스 장애 발생 시, 데이터 일관성을 유지하기 위해 복구하는 과정

REDO와 UNDO를 포함하는 개념

 

ex. 시스템이 충돌했을 때, RECOVERY 기능이 로그를 보고 데이터를 복원

 

(6) BACKUP

 

데이터베이스를 주기적으로 저장하여 장애 발생 시 데이터를 복원할 수 있도록 하는 과정

주로 정기적으로 수행 됨

 

ex. 하루에 한 번 전체 데이터베이스를 백업해서 장애 발생 시 복구 가능

 

(7) CHECK

 

트랜잭션이 특정 조건을 충족하는지 확인하는 과정

데이터 무결성을 유지하는 데 사용됨

 

ex. CHECK (salary > 0)

 

 

 

ACID

 

데이터베이스 트랜잭션의 신뢰성을 보장하는 4가지 특성

 

(1) Atomicity (원자성)

 

(약술형 기출)

원자성은 트랜잭션의 연산은 데이터베이스에 모두 반영되도록 완료(Commit)되든지

아니면 전혀 반영되지 않도록 복구(Rollback)되어야 한다는 특성을 의미한다

 

All or Nothing (모두 실행되거나, 전혀 실행되지 않거나)

중간에 실패하면 모든 변경사항을 취소(Rollback)하여 원래 상태로 되돌림

 

(2) Consistency (일관성)

 

트랜잭션 수행 전후 데이터의 무결성 제약조건이 유지돼야 한다

데이터베이스가 정상적인 상태에서만 변경되도록 보장

 

데이터 정합성이 깨지지 않고 논리적으로 올바른 상태를 유지해야 한다

 

일관성 (Consistency)

트랜잭션 전후에 데이터가 정해진 규칙이나 제약조건을 항상 만족하는 상태

ex. 계좌 이체 트랜잭션 중간에 시스템이 꺼져도, 돈이 사라지거나 두 배가 되지 않음.

 

무결성 (Integrity)

데이터에 부여된 제약 조건(기본키, 외래키 등)을 위반하지 않도록 보장하는 성질

ex. 고객 ID는 중복되면 안 되고, 주문 정보에는 반드시 존재하는 고객 ID만 사용해야 함.

 

정합성

여러 데이터 간 값이 서로 논리적으로 모순 없이 일치하는 상태

ex. 고객 테이블에 주소가 서울인데, 배송지 테이블에는 같은 고객이 부산으로 되어 있음 → 정합성 오류

 

도메인 무결성 유지 예시

ALTER TABLE Users ADD CONSTRAINT chk_age CHECK (age >= 18); -- 18세 이상만 가입 가능

✔ 18세 미만 사용자가 가입하려 하면 트랜잭션이 실패함

 

구분	일관성(Consistency)	무결성(Integrity)
의미	데이터 변경 후에도 논리적 모순이 없도록 유지	데이터가 정확하고 신뢰성을 유지하도록 보장
적용 대상	트랜잭션 수행 과정	데이터베이스 제약 조건
예시	A에서 출금한 금액과 B에 입금된 금액이 일치해야 함	학생 ID(PK)는 중복될 수 없고, 주문의 고객 ID(FK)는 존재하는 값이어야 함

개념	정의	유지하는 방법	예시
정합성(Consistency, Data Integrity)	데이터가 논리적으로 일치하는 상태	데이터 무결성 유지, 트랜잭션 제어, 정규화 적용, 동시성 제어	주문 테이블의 고객 ID가 회원 테이블에 존재해야 함
일관성(Consistency, Transaction Consistency)	트랜잭션 수행 후에도 데이터가 제약 조건을 만족하는 상태		은행 계좌 이체 시 A 계좌에서 출금되면 B 계좌에 동일한 금액이 입금됨

 

 

(3) Isolation (고립성)

 

동시에 수행되는 트랜잭션이 서로 영향을 주지 않도록 격리되어야 한다

 

📌 설명

• 여러 트랜잭션이 동시에 실행될 때, 다른 트랜잭션의 중간 작업이 보이지 않아야 함
• 트랜잭션이 완료되기 전까지 다른 트랜잭션에서 접근할 수 없음

📌 예시

• A가 상품을 구매하는 중에 B가 같은 상품을 구매하려 하면 A의 트랜잭션이 완료될 때까지 대기

📌 트랜잭션 격리 수준 (Isolation Level)

격리 수준	설명	현상 발생 여부 (더 낮은 수준일수록 충돌 가능)
Read Uncommitted	커밋되지 않은 데이터 읽기 허용 (남이 수정중인 걸 훔쳐볼 수 있음)	DIRTY READ 발생
Read Committed (기본)	커밋된 데이터만 읽기 허용(반복 불가능한 읽기, Non-repeatable Read), 트랜잭션 중 같은 데이터를 두 번 읽으면 값이 달라질 수 있음	DIRTY READ 방지
Repeatable Read	트랜잭션 동안 같은 데이터 조회 시 결과 동일(행 자체는 안 바뀌는데, 조건에 맞는 새로운 행이 생김), 트랜잭션 A가 시작한 시점의 스냅샷을 기준으로 읽기 때문에, 중간에 누가 값을 바꿔도 A 입장에서는 변화가 안 보임 (기존 행은 고정된 스냅샷을 보지만, 조건에 맞는 새로 삽입된 행은 스냅샷 범위 바깥이라 보인다)	PHANTOM READ 발생 가능
Serializable	가장 엄격한 격리 수준 (완전한 고립), how? 조건 자체를 lock한다. select… where 금액 > 10000처럼 조건을 쓰면, 그 범위에 대해 삽입/삭제를 못하게 막는다.	충돌 없음 (성능 저하 가능)

구분	Non-Repeatable Read	Phantom Read
바뀌는 대상	기존 행의 값	행의 개수 (새 행/삭제 행)
원인	다른 트랜잭션의 UPDATE	다른 트랜잭션의 INSERT/DELETE
방지 격리 수준	REPEATABLE READ 이상	SERIALIZABLE만 방지 가능

"값이 바뀌면 Non-repeatable Read"

"행이 생기거나 없어지면 Phantom Read"

 

 

 

👻 팬텀 리드 (Phantom Read)

 

: 한 트랜잭션에서 같은 조건으로 SELECT했는데, 그 사이 다른 트랜잭션이 행을 INSERT/DELETE해서 결과가 달라지는 현상

 

📘 예시

1. 트랜잭션 A:
   SELECT * FROM 주문 WHERE 금액 > 10000;
2. 트랜잭션 B:
   INSERT INTO 주문 VALUES (고객5, 20000);

COMMIT;

트랜잭션 A에서 다시 같은 SELECT 실행
👉 아까 없던 고객5의 주문이 튀어나옴 → 팬텀(유령)처럼 갑자기 생긴 데이터

 

 

 

📌 SQL 예제 (격리 수준 설정)

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

START TRANSACTION;

SELECT * FROM Orders WHERE user_id = 'A';

COMMIT;

 

✔ SERIALIZABLE → 가장 높은 격리 수준으로 설정

 

(4) 지속성 (Durability)

 

트랜잭션이 완료되면 그 결과는 영구적으로 저장되어야 한다

시스템 장애(전원 꺼짐, 서버 다운)가 발생해도 변경 내용 유지

 

✅ 📌 정리: ACID 4가지 특성

특성	설명	예시
원자성 (Atomicity)	트랜잭션은 모두 실행되거나 전혀 실행되지 않아야 함	계좌 이체 중 실패하면 전체 취소
일관성 (Consistency)	트랜잭션 전후 데이터의 무결성이 유지되어야 함	은행 계좌 총합은 변하지 않아야 함
고립성 (Isolation)	동시에 실행되는 트랜잭션이 서로 영향을 주지 않아야 함	한 사용자의 주문이 끝나기 전에는 다른 사용자가 접근 불가
지속성 (Durability)	트랜잭션 완료 후 데이터가 영구적으로 저장되어야 함	COMMIT 후에는 정전이 되어도 데이터 보존

 

 

버클리 데이터베이스 강의: https://www.youtube.com/playlist?list=PLYp4IGUhNFmw8USiYMJvCUjZe79fvyYge

 

 

병행 제어(Concurrency Control) 개념

 

여러 사용자가 동시에 같은 데이터에 접근하여 조작할 때, 

(여러 트랜잭션이 동시에 실행될 때)

일관성과 무결성을 유지(보장)하는 기법

 

✅ 병행 제어가 필요한 이유

1. 갱신 손실(Lost Update)
2. 비완료 의존성(Dirty Read)
3. 모순성(Inconsistent Read, Non-repeatable Read)
4. 연쇄 복귀(Cascading Rollback)

 

✅ 병행 제어 기법

1. 로킹(Locking) 기법

 

데이터베이스의 병행제어 기법 중 하나로, 접근한 데이터에 대한 연산을 모두 마칠 때까지 추가적인 접근을 제한함으로써 상호 배타적으로 접근하여 작업을 수행하도록 하는 기법

 

 

1. 타임스탬프 순서 기법(Timestamp Ordering)
2. 낙관적 병행 제어(Optimistic Concurrency Control, OCC)
3. 다중 버전 동시성 제어(MVCC, Multi-Version Concurrency Control)

 

⚙️ MVCC에서 일어나는 일

동작	설명
SELECT	내 트랜잭션 시작 시점의 버전만 읽음
INSERT / UPDATE / DELETE	새로운 버전을 생성 (기존 데이터는 그대로 두고, 새 버전 추가)
COMMIT	해당 버전이 확정되어 다른 트랜잭션에서도 보이게 됨
ROLLBACK	새 버전은 버려지고, 기존 데이터만 유지됨

 

✅ 정리

병행 제어는 동시에 여러 트랜잭션이 실행될 때 데이터의 무결성을 보장하는 중요한 기법입니다.
시험에서는 병행 제어 기법과 발생할 수 있는 문제점을 이해하는 것이 중요합니다.

📌 출제 예상 포인트

• 병행 제어가 필요한 이유
• 대표적인 병행 제어 기법 (로킹, 타임스탬프, 낙관적 병행 제어, MVCC)
• 병행 실행 시 발생할 수 있는 문제 (갱신 손실, Dirty Read 등)

이해 안 가는 부분 있으면 추가로 질문해줘! 😊

 

 

(1) 어떤 작업이 번갈아 행해질 수 있는지

 

Transaction Schedules

 

A schedule is a sequence of actions on data from one or more transactions

 

Actions: Begin, Read, Write, Commit, Abort

 

 

Serial schedule:

Each transaction runs from start to finish without any intervening actions from other transactions

complete isolation

 

• serializable

직렬 가능 스케쥴은 실제 실행은 병렬로 진행되더라도, 결과(읽고 쓰는 값, 최종 데이터베이스 상태)가 어느 한 트랜잭션을 모두 끝낸 뒤 다음 트랜잭션을 실행하는 직렬 스케쥴과 동일하게 나타난다.

병렬로 보이지만 실제로는 직렬 스케쥴과 같은 결과를 내는 스케쥴

데이터베이스 트랜잭션의 일관성과 정확성을 보장하기 위한 핵심 개념

 

ATM이 여러 개 있을 때와 비슷

 

• 병행 제어

복수 사용자 DBMS는 병행성을 지원하며, 병행성은 몇 개의 트랜잭션들을 동시에 실행시키는 것

 

 

데이터베이스 회복 기법

 

데이터베이스 회복

시스템 장애(하드웨어 오류, 트랜잭션 오류, 소프트웨어 오류 등) 발생 시 데이터의 일관성과 무결성을 유지하기 위해 수행하는 복구 작업

 

주요 원칙

(1) 회복(Undo, Rollback)

잘못된 트랜잭션을 되돌려서(Undo) 데이터의 일관성을 유지해야 함

(2) 재실행 (Redo, Rollforward)

정상적으로 수행된 트랜잭션은 다시 실행해서 데이터가 손실되지 않도록 해야 함

 

장애 유형 4가지

 

장애 유형	설명	예시
트랜잭션 장애	특정 트랜잭션만 비정상 종료	트랜잭션 수행 중 오류 발생 (제약 조건 위반, 논리적 오류 등)
시스템 장애	DBMS 전체가 다운됨	전원 차단, 운영체제 오류, 메모리 문제
디스크 장애	하드웨어 장애로 인해 데이터 손실	디스크 고장, 파일 시스템 오류
소프트웨어 장애	프로그램 오류, 버그 등으로 인해 장애 발생	DBMS 소프트웨어 오류, 애플리케이션 버그

 

주요 회복 기법

 

즉시 갱신, 지연 갱신, 검사 시점, 그림자 페이징, 미디어 회복 기법

기법	설명	특징
즉시 갱신 회복(Immediate Update)	트랜잭션 수행 중 변경 내용을 즉시 DB에 반영, 트랜잭션이 데이터를 변경하면 트랜잭션이 부분 완료되기 전이라도 즉시 실제 DB에 그 내용을 반영하는 기법, 장애가 발생하여 회복 작업할 경우를 대비하여 갱신된 내용들을 로그에 보관시킨다	장애 발생 시 UNDO와 REDO 필요
지연 갱신 회복(Deferred Update)	트랜잭션이 완료(COMMIT) 된 후 변경 내용을 반영	장애 발생 시 REDO만 수행
그림자 페이지 회복(Shadow Paging)	데이터 변경 시 기존 페이지를 유지하고, 새로운 페이지를 생성하여 반영	로그를 사용하지 않고 트랜잭션이 완료되면 새로운 페이지를 활성화
검사점 회복(Checkpoint)	일정 주기마다 트랜잭션의 중간 상태를 저장하여 장애 발생 시 복구 속도를 향상, 장애 발생 시 체크포인트 이후의 트랜잭션만 복구하여 속도 향상	장애 발생 시 검사점 이후의 REDO만 수행

 

그림자 페이지 회복 개념

 

• 데이터 변경 시 기존 페이지를 수정하지 않고, 새로운 페이지를 생성하여 변경 내용을 반영
• 트랜잭션이 완료(COMMIT)되면 새로운 페이지를 활성화
• 장애 발생 시 기존 페이지를 사용하여 자동 복구

 

✅ 그림자 페이지 구조

1. 현재 페이지 테이블(Current Page Table)
2. 그림자 페이지 테이블(Shadow Page Table)
3. 데이터 페이지(Data Pages)