UEFI와 파티션(MBR, GPT) 그리고 파일 시스템

PC에 전원이 공급되면 어떻게 하드 디스크에 저장되어 있는 운영체제가 실행될까 궁금한적이 있을 것이다. 이렇게 운영체제가 시작하기 위한 과정을 부트 스트랩(Boot Strap)이라고 하는데 이와 관련된 기술 용어로 BIOS, EFI, UEFI, MBR, GPT 등이 있으며 이 게시글을 통해 부트 스트랩 과정과 더불어 메인보드 펌웨어, 파티션, 파일시스템에 대해서 살펴보도록 한다.

PC에 전원이 들어오면 메인보드에 내장된 펌웨어가 가장 먼저 실행된다. 그리고 메인보드 펌웨어 >> 부트로더 >> 운영체제 순으로 부팅을 위한 과정을 거치게 되며 각 단계별 기술과 역할을 살펴보도록 하겠다.

 

1. 메인보드 펌웨어(Mainboard Firmware) - BIOS, EFI, 그리고 UEFI

컴퓨터에 전원이 공급되면 메인보드에 내장된 펌웨어가 실행된다. 이 펌웨어는 BIOS(Basic Input/Output System Firmware Interface), EFI(Extensible Firmware Interface), UEFI(Unified Extensible Firmware Interface) 와 같은 기술 규약에 호환되게 만들어져 있으며 이 기술 규약을 통해서 컴퓨터에 연결된 장치를 관리하고 부팅을 시작한다.

기술 규약의 발전은 BIOS >> EFI >> UEFI 순이고 최신 기술 일수록 화면이 화려해지고 기능이 다양해지고 지원가능한 부팅방식이 늘어난다. 당연한 이야기겠지만 하위 호환도 가능하다. 예전 기억을 되살려보면 BIOS는 CUI(Character User Interface) 환경에 마우스 사용이 불가능했지만 UEFI는 GUI(Graphic User Interface)에 마우스 사용이 가능하다. 그 이유는 마우스 드라이버를 UEFI가 지원하기 때문이다. 지나가는 이야기로 EFI는 2008년쯤 출시된 메인보드에 적용되고 UEFI는 2012년쯤 적용된 메인보드가 출시된 것으로 보인다. 

이 기술의 역할은 명료하다. [그림01]에서 보듯 펌웨어가 운영체제와 연결되기 위한 기술 규약이다. 그리고 이 펌웨어는 2차 저장장치 (하드 디스크 혹은 SSD, 이하 저장장치)에서 부트로더를 메모리로 읽어와 실행시키게 된다. 그리고 펌웨어의 부팅에 관련된 역할은 끝나게 된다. 다만 여기서 알아야 할 것이 디스크 파티션이다. 부트로더는 파티션 기술 종류에 따라 다르게 관리된다. 즉 펌웨어가 저장장치의 파티션을 기술적으로 지원하지 못하면 부트로더를 실행시킬 수 없다는 이야기가 된다.

[그림01] EFI의 역할 - www.nolitor.com

현재 대표적인 디스크 파티션 기술은 MBR과 GPT이다. MBR의 기술적 제한을 해결하기 위한 것이 GPT이며 이를 지원할 수 있는 펌웨어 기술 규약은 EFI, UEFI이다. 즉 BIOS는 GPT 파티션으로 만들어진 저장장치에서 운영체제를 부팅할 수 없다. 다음으로 디스크 파티션에 대한 더 자세한 것을 알아보자.

참고로 UEFI의 장점은 아래와 같다.

   - GPT(GUID Partion Table)를 사용한 대용량 디스크(2TB 이상)에서 부팅이 가능하게 한다.

   - CPU에 독립적인 아키텍처이다.

   - CPU에 독립적인 드라이버이다. 

   - 운영체제를 설치하기 전에 네트워크 사용을 포함하여 유연한 기능을 제공한다.

   - 모듈화 디자인이다.

   - Backward and forward compatibility

2. 파티션(Partition) - MBR, GPT

파티션이란 단순한 물리 디스크를 파티션이라는 논리 단위로 나누는 것이다. 하나의 저장장치가 실제로 사용되기 위해서는 최소 1개의 논리 파티션으로 나눠져 있어야 한다. 그리고 여러 개의 논리 파티션을 만들게 되면 여러 개의 디스크가 연결된 것처럼 사용할 수 있다. 윈도우를 기준으로 본다면 하나의 하드 디스크를 연결하고 C:\, D:\, E:\ 처럼 3개의 디스크가 연결된 것 사용할 수 있다는 것이다.

파티션은 역할에 따라 시스템 파티션, 부트 파티션으로 호칭한다. 부트 파티션은 부트 로더가 저장되어 있는 영역으로 주 파티션이 된다. 시스템 파티션은 운영체제가 담긴 파티션을 의미한다. 이 두 개의 파티션은 같을 수도, 다를 수도 있다. 리눅스를 예를 들면 부트 파티션과 시스템 파티션은 동일하다. 그리고 부트로더 데이터를 /boot에 저장한다.[02]

그러면 펌웨어는 어떻게 디스크에서 부트로더를 찾아서 실행시킬 수 있는가? 이 의문점을 해결할 수 있는 것이 MBR(Master Boot Record)이라는 영역이다. 가장 보편화된 파티션 기술 이름이기도 하지만 MBR은 디스크의 첫 번째 섹터 (Sector 0)를 의미한다. 이 영역에는 파티션를 구성하고 있는 정보와 부트로더를 실행하기 위한 가장 기본적이고 첫 번째로 실행되어야 할 코드가 담겨있다. 그리고 GPT(GUID Patition Table)도 MBR 영역 개념을 활용하고 있다.

[그림02]을 살펴보자. 이미지 상에서 Core.img라고 적인 부분은 부트로더를 의미하고 /boot/grub이라고 적힌 부분이 운영체제라고 보면 된다. 결국 펌웨어는 MBR이든 GPT이든 MBR 영역을 첫 번째로 실행하고 이 코드가 어딘가 저장되어 있는 부트로더를 이어서 실행하고 마지막으로 운영체제를 읽어와 실행하게 된다. 이것이 펌웨어부터 이어지는 부팅과정이다.

[그림02]을 보았을 때 눈에 띄는 차이는 부트로더의 위치 차이이다. MBR은 기술 규약에 따라 부트로더가 MBR 영역에 이어서 저장되어 한다. 하지만 GPT는 부트로더의 위치를 따로 정하지 않는다. MBR에 담긴 정보를 통해 찾아가게 될 것이다.

 

[그림02] MBR 방식과 GPT 방식의 레이아웃 비교[02] - www.nolitor.com

그럼 GPT는 MBR과 비교하여 어떤 장점을 가질까? 가장 큰 장점은 지원하는 디스크 용량의 크기이다. 기존 MBR 파티션은 32Bit 주소체계를 가지고 있기 때문에 단일 논리 파티션을 사용한다고 했을 때 2^32 x 512Bytes = 2TB 밖에 용량지원이 안되지만 GPT는 64Bit 주소체계이기 때문에 2^64 x 512Bytes =  9ZB의 대용량을 지원하게 한다. 그리고 파티션을 구성하는 정보가 쉽게 망가지지 않게 백업기능도 가지고 있다. 하지만 BIOS 펌웨어는 GPT를 지원하지 못하기 때문에 이를 사용하기 위해서는 반드시 UEFI 펌웨어를 사용해야 한다.

최근 하드 디스크의 용량이 2TB를 넘어 3TB, 4TB 등 대용량이 출시되고 있다. 이런 대용량 하드 디스크를 사용하기 위해서는 위에 이야기한 것처럼 GPT 파티션을 사용하던지 2TB 이하의 여러 논리 파티션으로 나눠서 MBR 파티션으로 사용하는 방법이 존재한다.

3. 파일 시스템 (File System)

파일 시스템은 윈도우의 FAT32, NTFS. 리눅스의 EXT3, EXT4와 같은 기술로 운영체제가 책임지는 기능이다. 파일 시스템은 각 운영체제가 파티션에 데이터를 읽고 쓰는 규칙이다. 이 규칙에 따라서 쓰여진 의미를 가진 데이터는 다시 의미있는 데이터로 읽어올 수 있다. 부가적으로 빠른 파일 I/O, 안정적인 파일 쓰기를 지원하기 위한 기술이 함께 포함되어 있다.

의미있는 데이터를 쓰고 의미있는 데이터를 읽는다는 이야기는 다음과 같이 풀어 쓸 수 있을 것 같다. 0110 1111 0000 1100 이라는 데이터가 있을 때 NTFS는 앞 4Bit를 Index, 나머지 12Bit를 필요한 데이터라고 약속하고 저장장치에 쓰기를 하였는데 EXT3가 앞 8Bit를 Index, 나머지 8Bit를 필요한 데이터라고 읽어버리면 의도했던 바와 다른 정보가 된다. 때문에 파일 시스템간의 호환성이 이뤄지기 어려운 것이다.

REFERENCE

[01] https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface

[02] https://en.wikipedia.org/wiki/System_partition_and_boot_partition

[03] https://en.wikipedia.org/wiki/Disk_partitioning

[04] https://en.wikipedia.org/wiki/GUID_Partition_Table

Updated By Hoseok Seo

2017. 07. 02

Written By Hoseok Seo

2016. 08. 23