WWDC 2016에서 많은 내용이 발표되었다. 독자분들도 알고 있듯이 macOS 시에라의 발표부터 iOS 10, watchOS 3, 새로운 버전의 tvOS등 애플의 주력 운영체제의 전면적인 메이저 업그레이드 소식이 있겠다. 좀 더 관심이 많은 독자들이라면 좀 더 내밀한 내용들 역시 관심이 있을지 모르겠다. SiriKit 등 각종 새로운 API들이 개발자들을 위해 공개되었고, 오픈소스가 된 Swift 역시 메이저 업데이트를 겪는 등 많은 발표사항들이 있었다.
하지만 이 외에도 많은 개발자들이 지대한 관심을 보인 주제가 하나 있었으니, 그것이 바로 본 글에서 다룰 내용인 'Apple File System(APFS)', 애플의 새로운 파일 시스템이다.
0. 목차
1. 파일 시스템이란 무엇인가
2. 왜 새로운 파일 시스템이 필요한가
3. Apple File System(APFS) 자세히 알아보기
3.1. 뿌리부터 새로 설계된 파일 시스템
3.2. 파티션? 이젠 APFS의 볼륨 : Space sharing
3.3. 복제본을 다루는 APFS의 방식 : Cloning files and directories
3.4. 더 빨라진 타임머신? : Snapshots
3.5. 더 이상 기다림은 그만 : Fast Directory Sizing
3.6. 파일 시스템의 안정성을 높인다 : Atomic safe-save primitives
3.7. 더 강력해진 암호화를 제공하는 APFS
4. 결론
5. 덧붙이는 말
1. 파일 시스템이란 무엇인가
먼저 시작하기 전에 파일 시스템이 무엇인지에 대해서 간단히 알아볼 필요가 있다.
컴퓨터가 사용하는 기억 장치의 종류는 매우 다양한데, 오늘 우리가 살펴볼 것은 그 중에서 보조기억장치에 해당하는 부분이다(흔히 하드디스크, SSD가 담당하는). 보조기억장치는 상대적으로 용량이 크고, 비휘발성이라는 특징이 있다. 이 때문에 보조기억장치에 저장된 데이터를 효율적으로 관리하고 접근하기 위해서는 이를 위한 규칙과 여러 기능을 정해둔 파일 시스템이 필요하다.
예를 들어 파일을 어떤 식으로 읽고, 쓰고, 지우는지에 대한 규칙부터 파일이 수정된 시간을 기록하고 파일의 이름을 설정하는 규칙 등이 있을 것이다. 너무 뜬구름 잡는 이야기만 한 것 같은데, 하드디스크나 USB 저장장치를 포맷해 본 사람이라면 보았을 FAT32, NTFS등이 바로 파일 시스템의 이름이다.
파일시스템에는 다양한 종류가 있다. 윈도우즈의 경우 위에서도 언급한 NTFS가 주력 파일 시스템이다. 하지만 비교적 최근까지도 외장 USB 드라이브의 경우 FAT32로 포맷하는 경우도 많았다. 이 때 FAT32로 포맷한 드라이브의 경우 4GB보다 큰 파일을 쓰지 못하는 등의 단점이 있는데 이는 바로 파일 시스템의 한계에 기인한 것으로 파일시스템의 중요성을 잘 보여준다.
애플의 운영체제들은 HFS+와 그 개량형을 사용하고 있었으며, 리눅스에서는 매우 다양한 파일 시스템이 공존하고 있다. 파일시스템은 위에서 언급한 용량 제한 외에도 실제 파일이 차지하는 용량, 저장장치의 속도, 파일의 이름 결정 등 일반 사용자들에게도 비교적 쉽게 와닿는 여러 요소들에 영향을 준다.
2. 왜 새로운 파일 시스템이 필요한가
macOS 부터 watchOS까지 현재 애플의 모든 운영체제는 HFS+라는 파일 시스템을 사용하고 있다.
HFS는 Hierarchy File System의 약자로 그 역사가 30년 이상을 거슬러 올라간다. 물론 이 파일시스템은 여러 차례의 개량을 받긴 했지만 그 근본은 플로피디스크와 자기기록식 하드디스크를 주로 사용하는 환경에 맞추어져 있다. 하지만 오늘날의 애플 제품들을 보자. 애플워치부터 맥 프로까지 대부분의 제품이 낸드 플래시 기반의 보조저장장치를 사용하고 있다. 또, HFS가 처음 설계되던 시점에서의 컴퓨터 보안과 디지털 개인정보 보호에 대한 인식은 지금과는 비할 바가 못 된다. 당연히 HFS는 암호화에 대해 깊은 고민을 바탕으로 만들어진 파일 시스템이 아니다.
물론 지금도 애플은 HFS 자체를 개량하거나, 소프트웨어 레이어를 추가함으로써 필요한 기능들을 추가하고 있다.
그 예로 애플은 iOS에 개량된 파일 시스템인 per-file crypto HFS+를 사용해서 파일 단위의 암호화 기능을 구현하고 있다. 또 macOS의 암호화 기능인 파일볼트의 경우 파일시스템과 운영체제 사이에 하나의 소프트웨어 레이어를 추가함으로써 특정 디스크 암호화 기능을 수행하고 있다. 아래 슬라이드에서 회색으로 표시된 글자는 현재 애플이 사용하고있는 HFS의 다양한 개량형들이며 녹색으로 표시된 글씨는 애플이 자체적인 소프트웨어 레이어를 추가해 구현하고 있는 기능들을 나타낸다.
현재 여러 개로 파편화되어 있는 HFS의 개량형들의 기능을 모두 통합한 새로운 파일 시스템이 있다면, 애플의 모든 제품이 단일 파일 시스템을 사용할 수 있을 것이다. 이렇게 되면 각 제품은 다른 제품이 사용하던 파일 시스템의 장점을 누릴 수 있을 것이고, 애플 내부적으로 여러 개의 파일 시스템을 유지, 보수하는 데 드는 노력을 줄일 수 있을 것이다.
또 현재 별도의 소프트웨어 레이어를 통해 지원하는 기능들을 파일시스템 단에서 지원할 수 있다면 운영체제는 별도의 소프트웨어 레이어 없이도 같은 기능을 수행할 수 있을 것이며, 이 경우 오버헤드가 줄어드는 것은 당연하다. 이렇게 줄어든 오버헤드는 체감성능의 향상이나 더 강력한 암호화 등으로 환원될 수 있을 것이다.
대표적인 예시로 든 것이 암호화지만 당연히 새로운 파일시스템이 제공하는 이점이 암호화 측면에만 있는 것은 아니다.
위에서 언급한 것처럼 새로운 파일시스템은 현재 널리 사용되는 저장장치에 더 최적화되어 있을 것이고, 기존의 파일시스템에서 불필요한 부분을 제거함으로써 체감 성능 향상에 기여할 수 있을 것이다. 또 현재 운영체제단에서 구현하고 있는 여러 소프트웨어 기능들을 파일시스템 설계에 반영함으로써 운영체제 사용시의 전반적인 사용자 경험을 향상시킬 수 있을 것이다.
3. Apple File System(APFS) 자세히 알아보기
애플은 위 문제들을 해결할 새로운 파일 시스템으로 HFS의 개량형이 아닌 완전히 새로 설계된 파일시스템을 소개했다.
바로 Apple File System(APFS)이다. 많은 독자분들은 이미 감을 잡으셨겠지만, 위에서 열심히 설명한 부분들이 APFS의 개략적인 장점들이다. 애플 파일시스템은 근본부터 낸드 플래시 기반의 저장장치에 맞춰 설계되었으며 덕분에 플래시 기반의 저장장치에서의 성능이나 그 안정성 등을 확보할 수 있었다.
또 애플 파일시스템은 암호화에 대한 매우 깊은 고민을 바탕으로 만들어진 파일 시스템이다. 기존 iOS에 투입되었던 per-file crypto HFS+의 기능을 가져온 것은 물론 파일볼트가 수행하던 기능 역시 파일시스템에 포함했다. 여기에 그치지 않고 추가적인 몇 가지 암호화 기능이 투입되기까지 했다. 또 성능 향상이나 안정성 향상을 위한 여러 신기술들이 투입된 것은 물론이다.
◼︎ 3.1 뿌리부터 새로 설계된 파일 시스템
많은 신기술들이 투입되었다 하더라도 파일시스템의 기본적인 요소들이 결여되거나 개선되지 않았다면 그것은 훌륭한 파일 시스템이라 할 수 없다. 애플 파일시스템은 새로운 파일시스템을 기본부터 재설계하면서 파일시스템의 근본적인 부분을 크게 개선했다.
먼저 APFS는 플래시 기반 저장장치에 최적화된 파일 시스템이다.
하드디스크 등 물리적으로 회전하고 자기로 기록되는 저장장치에서는 파일을 지울 때는 그 파일을 지정하고 있는 메타데이터만을 수정하면 된다. 파일의 본 내용은 실제로는 지워지지 않은 상태로 디스크상에 존재하고, 이후에 그 영역에 다른 파일이 쓰여질 때 덮어씌워지는 방식으로 기록된다. 즉, 파일을 삭제하고 덮어씌우는 일이 단 한번의 작업으로 가능하다. 하지만 이들은 물리적으로 동작하는 장치이기 때문에 단일 메타데이터가 지정하는 파일들이 저장장치의 이곳저곳에 흩어져 있을 경우 그 파일을 읽을 때 성능이 크게 저하된다. 이를 해결하는 방법이 흔히 우리가 알고 있는 '디스크 조각 모음' 기능이다.
낸드 플래시 메모리 기반의 저장장치는 데이터를 저장하는 셀들이 전자적으로 동작하고, 같은 메타데이터가 지정하는 데이터일지라도 그 물리적 위치가 가까울 필요는 없다. 하지만 플래시 메모리는 하드디스크와는 다르게 어떤 파일이 쓰여진 공간에 다른 데이터를 쓰기 위해서는 그 셀을 초기 상태로 돌리는 작업이 필요하다.
문제는 이 지우기 작업에 소요되는 시간이 쓰기나 읽기 작업에 소요되는 시간에 비해 월등히 길다는 점이다. 즉, 하드디스크와 같은 방식으로 SSD를 관리한다면 어떤 데이터를 쓰려고 했을 때 만약 그 셀이 다른 의미없는 데이터로 차 있다면 이를 초기화하는 데 긴 시간이 소요될 것이고, 사용자는 컴퓨터가 버벅인다고 느낄 것이다.
이를 해결하는 것이 소위 'TRIM'이라고 불리는 기능으로, 메타데이터가 변경되어 더 이상 의미가 없어진 데이터를 실제로 삭제해 주는 기능이다. 물론 현행 HFS+ 에서도 TRIM 기능이 지원되긴 하지만, APFS에서는 좀 더 진보된 형태의 비동기식 TRIM을 지원한다. 비동기식 TRIM은 항상 백그라운드에서 Garbage Collector가 동작하는 방식으로 작동하는 것이 아니라 메타데이터의 변경이 감지된 시점에서만 비동기적으로 TRIM 명령을 실행하는 방식으로 더 안정적으로 저장장치를 유지할 수 있도록 해 준다.
낸드 플래시 메모리 사용 시 문제가 되는 내용은 또 있는데 각 셀이 쓸 수 있는 횟수에 한계가 있다는 점이다. APFS는 파일 시스템 단위에서 쓰기 동작을 최소화함으로써 낸드 플래시 기반 저장장치에 가해지는 부담을 줄이는 방법 역시 채택하고 있다. APFS는 'Copy-On-Write' 방식의 쓰기 정책을 채택하고 있는데 이는 복사된 파일의 처리에 대한 정책이다. 기존의 파일 시스템에서는 복사 명령이 내려지면 그 즉시 파일의 물리적인 복제본이 형성되고 쓰기 동작이 일어난다. 이후 파일의 일부가 수정되면 그 수정된 부분에 대해 다시 쓰기 동작이 발생할 것이다.
하지만 'Copy-On-Write' 정책 하에서는 최초 파일 복사 명령이 내려졌을 때 그 파일을 실제로 복사하지 않는다. 하지만 사용자가 보기에는 그 파일이 복제된 것으로 보인다. 실제 쓰기 동작은 그 복제된 파일에 수정이 일어난 시점에서 발생한다. 기존 시나리오에서 두 번의 쓰기 동작이 발생하는 데 반해 이 경우 단 한번의 쓰기 동작만이 일어난다. 이는 성능상에서 이득을 줄 뿐만 아니라 쓰기 동작을 줄임으로써 플래시 메모리 기반의 저장장치의 단점을 파일 시스템 단위에서 보정해 줄 수 있을 것이다. 또 이 기능은 트랜잭션 서브시스템과 함께 구동되어 시스템에 갑자기 전원이 끊어지는 등의 상황에서도 더 나은 데이터 안정성을 보장한다.
또 APFS는 64비트 아이노드를 지원한다. 아이노드는 유닉스 계통의 파일 시스템에서 사용하는 자료구조로, 파일마다 한 개의 아이노드가 할당되어 있다. 아이노드에는 각 파일의 소유자 그룹, 접근 모드(읽기, 쓰기, 실행 권한 등의 정보), 파일 형태, 파일 식별번호 등 해당 파일에 관한 정보를 포함하고 있다. 기존 애플 시스템에서 사용되던 HFS+ 기반의 파일 시스템은 32비트 아이노드를 지원했는데, APFS는 64비트 아이노드를 지원함으로써 볼륨 하나에 40억개의 파일을 담을 수 있던 HFS+보다 훨씬 많은 볼륨당 900경개 이상의 파일을 저장할 수 있다. 또 아이노드의 크기가 커지면서 기존에는 초단위로 기록하던 파일의 타임스탬프를 나노초 단위로 기록할 수 있게 되었다.
아울러 APFS의 자료 구조는 HFS+의 그것에 비해 훨씬 유연하다. 특정 상황에서는 파일의 존재 자체만으로도 충분한 정보를 전달할 수 있는 경우가 있다. APFS는 이런 경우에 실제 데이터를 쓰지 않고 메타데이터상으로만 존재하는 파일을 생성할 수 있다. 거기에 애플 파일시스템은 새로운 기능을 추가하기 쉬운 설계를 채택했다. 애플 파일시스템은 많은 여분 필드를 가지고 있으며, 만약 새로운 기능이 추가되더라도 이 영역을 이용하여 기존의 파일시스템에서도 호환 가능한 업데이트를 시행할 수 있다(새로운 기능을 추가하면서도 하방 호환성을 보장할 수 있다).
이 외에도 APFS는 애플의 소프트웨어 생태계(애플의 운영체제와 개발자들을 위한 각종 API와 연계되어 개발되었기 때문에 서로에게 최적화되어 있으며, 이는 개발자들이 더 나은 앱을 개발할 수 있도록 해 줄 것이다. 다음으로 APFS는 지연시간과 스루풋 사이의 트레이드 오프에서 지연시간에 최적화된 설계를 선택했다. 일반 사용자가 느끼는 사용자 경험에서는 스루풋보다는 레이턴시가 더 중요하기에 일반사용자용 기기가 포트폴리오의 대부분을 차지하는 애플로써는 당연한 결정이라 할 수 있겠다.
마지막으로 지금의 HFS와는 달리 APFS는 그 근본부터 암호화에 기반을 두고 있다. 암호화에 대한 내용은 글의 뒷부분에서 좀 더 자세하게 다뤄질 것이다.
여기까지의 내용에서 짐작할 수 있듯 파일 시스템을 새로 설계하고 기존의 파일 시스템을 교체하는 것은 쉬운 작업이 아니다. 당장 HFS 기반의 파일시스템이 30여년간 개량을 거쳐서 쓰이고 있는 것만 봐도 알 수 있을 것이다. 그렇기 때문에 애플은 APFS를 설계하면서 현재뿐만 아니라 미래의 유지, 보수에 대한 사항들까지도 고민한 모습을 보여주고 있다.
하지만 현재의 HFS+ 기반에서 각종 API 등을 이용해 만들어진 어플리케이션들이 APFS 시스템에서 동작하지 않는다면 APFS가 아무리 훌륭한 기능을 가졌다 하더라도 진통이 심할 것이다. 애플은 이를 막기 위해 APFS를 HFS+와 호환되도록 설계했다. HFS가 API로 제공하는 모든 기능을 동일한 형태로 제공하여 혼선을 없앴다. 당연히 APFS가 제공하는 새로운 기능들을 이용하기 위해서는 개발자가 앱을 수정해야 하겠지만 이전에 개발된 앱 역시 APFS 기반의 애플 기기에서도 정상 동작할 것이다.
지금까지 애플 파일 시스템의 기본적인 기술적 변화를 알아보았다. 지금부터는 애플 파일시스템의 특징과 새로 추가된 기능들을 중점적으로 알아보도록 하자.
◼︎ 3.2 파티션? 이젠 APFS의 볼륨 : Space sharing
애플 파일시스템의 특징 중 하나를 꼽자면 우리가 흔히 알던 파티션 개념이 조금 달라졌다는 것이다. 기존에는 GPT 헤더 아랫쪽에 여러 개의 파티션이 존재하는 형식이었다면, APFS의 경우 GPT 헤더 아래에 단일한 APFS 컨테이너가 존재하고 그 하부에 여러 개의 볼륨이 존재하는 형식이다. APFS의 각 볼륨은 우리가 흔히 아는 파티션처럼 사용, 접근할 수 있다. 이들은 논리적으로 구분된 공간으로 존재하며 우리가 파티셔닝을 통해 얻을 수 있는 형태의 이점을 얻을 수 있게 해 준다. 하지만 실제로 이들은 특정 공간을 나눠서 존재하는 것이 아니기 때문에 우리가 아는 파티션의 단점을 극복할 수 있다.
기존의 파티션에서는 한 파티션에 남는 공간이 있고, 다른 파티션이 가득 차 있더라도 이 용량을 즉각적으로 재조정해서 사용하기 어렵다. 이런 문제를 해결하기 위해 APFS은 Space sharing이라는 기법을 사용한다. APFS의 볼륨은 파티션을 다시 할 필요 없이 용량을 확장하거나 축소할 수 있다. 즉, 각 볼륨은 기본적으로 할당받은 용량을 차지하고 있지만 현재의 파티션처럼 모든 디스크 공간을 파티션에 할당할 필요는 없다. 볼륨에 여유 공간이 부족해지면 각 볼륨은 별도의 파티션 없이 자신의 크기를 늘이고 그래도 부족할 경우 다른 볼륨이 차지하는 여유공간 역시 받아올 수 있을 정도로 유연하다. 당연히 각 볼륨이 남은 여유 공간을 보고하는 방식 역시 이전과 확연히 달라졌다.
기존 파티션 방식의 예시를 먼저 살펴보자.
파티션0, 파티션1 두 개의 파티션으로 나눠진 저장장치가 있다고 가정하자. 저장장치의 총 용량은 100GB이고 각각의 파티션은 50GB의 용량을 갖고 있다. 파티션0이 10GB의 파일을 갖고 있고, 파티션1이 40GB의 파일을 갖고 있다고 가정했을 때 각각의 파티션은 여유 공간을 40GB, 10GB로 보고할 것이다. 만약 파티션1에 10GB이상의 파일을 추가로 쓰고자 한다면 디스크를 다시 파티션해야 할 것이다.
만약 똑같은 일이 APFS의 볼륨에서 일어난다면 어떨까?
각 볼륨의 최초 지정 용량은 크게 중요하지 않다. 볼륨0의 경우 10GB의 파일을 가지고 있기 때문에 그 용량은 10GB일 것이고, 볼륨1은 40GB의 파일을 갖고 있기 때문에 40GB의 용량을 차지하고 있을 것이다. 이들은 APFS 컨테이너 내부의 남은 공간을 모두 사용할 수 있기 때문에 볼륨0과 볼륨1 모두 여유공간이 50GB 남았다고 보고할 것이다. 이 경우 볼륨1에 10GB가 넘는 파일을(컨테이너의 용량을 초과하지 않는 이상) 쓸 경우에도 아무런 문제가 없다. 볼륨1은 추가되는 파일의 용량만큼 자신의 용량을 확장시킬 따름이다.
이 기능을 제대로 이용한다면 좀 더 적극적으로 볼륨을 나눌 수 있을 것이다. 시스템 파일들이 포함된 볼륨, 중요한 업무관련 파일들이 포함된 볼륨, 개인정보가 포함된 볼륨, 게임 클라이언트 파일 등 암호화 보호 등이 크게 필요하지 않은 데이터들을 위한 볼륨 등으로 볼륨을 구분하고 각각의 볼륨에 서로 다른 암호화 방식을 적용함으로써 필요한 파일을 강력하게 보호하면서도 전체 시스템 성능을 크게 저하시키지 않는 등의 방식으로 응용이 가능하다.
다음으로 살펴볼 기능은 'Cloning files and directories' 기능이다. 이는 앞에서 살펴보았던 'Copy-on-Write' 정책의 확장판이라고 볼 수 있는데, 전자는 소프트웨어적으로 이를 지원하는 API 등을 이용해 적용할 수 있는 기능이고, 후자는 별도의 기능 추가 없이도 파일시스템이 모든 파일을 그 방식으로 다룬다는 차이점이 있다.
◼︎ 3.3 복제본을 다루는 APFS의 방식 : Cloning files and directories
앞에서 잠깐 살펴보았던 APFS의 쓰기 정책인 'Copy-on-Write'의 핵심은 특정 파일이 복제된 시점에서는 실제로 아무런 쓰기 동작이 일어나지 않지만 복제된 파일이 변경된 시점에서 실제로 쓰기 동작이 일어나는 것이다. 단지 파일이 복제되기만 했을 시점에는 당연히 원본 파일과 복제본 파일의 내용에 아무런 차이가 없기 때문에 이런 방식은 논리적으로 아무런 문제가 없다.
여기서 잠깐 생각해 볼 문제가 있다. 복제가 일어난 시점에서 원본 파일과 복제본의 내용이 똑같기 때문에 실제로 디스크에 쓰는 동작이 불필요하다면, 복제본의 일부가 수정되었을 때 수정된 부분을 제외한 나머지는 원본과 동일하기 때문에 수정된 복제본 전체를 쓰는 동작 자체도 불필요한 것이 아닐까?
Cloning files and directories 기능은 이런 생각을 적극적으로 채용한 기능이다. 위 그림은 Cloning files and directories 기능이 어떻게 동작하는지를 잘 보여주고 있다. 어떤 파일이 복제되면 그 시점에서 변경되는 것은 메타데이터 뿐이다. 메타데이터는 새로운 파일이 존재함을 알리는 동시에 그 파일의 위치를 지정한다.
하지만 실제 그 파일의 내용은 새로 복제된 디스크의 어딘가를 가리키는 것이 아니라 기존의 파일을 그대로 지정하고 있을 것이다. 이 때 파일의 일부가 수정되면 'Copy-on-Write' 정책에 따라 디스크의 빈 공간에 복제본을 기록할 것이다. 이 때 Cloning files and directories 기능이 작동할 경우, 전체 복제본이 디스크에 기록되는 것이 아니라 수정된 부분만 디스크에 기록되고 수정되지 않은 부분은 여전히 기존의 파일 데이터를 가리키고 있을 것이다.
이 기능은 실제로 쓰여지는 파일의 용량이 적어지기 때문에 성능상 이득을 제공할 뿐만 아니라, 동일한 파일의 여러 개의 개정판을 저장할 때 더 적은 용량으로 그 일을 수행할 수 있다. 물론 지금도 애플은 소프트웨어적으로 이와 비슷한 원리로 동작하는 Version 기능을 제공하고 있다. 하지만 이렇게 파일 시스템이 이런 기능을 제공하면 성능상 이득이 있을 뿐만 아니라 서드 파티 개발자들이 자신의 앱에 같은 기능을 훨씬 더 쉽게 적용할 수 있는 장점이 있다.
다음에 살펴볼 기능은 역시 APFS의 고수준의 기능 중 하나이다. 바로 Snapshots 기능인데, 말 그대로 APFS로 포맷된 디스크의 특정 시점의 상태를 스냅샷 찍듯 남겨놓아 언제든 그 지점으로 복구할 수 있도록 하는 기능이다.
◼︎ 3.4 더 빨라진 타임머신? : Snapshots
스냅샷은 간단하게 말하면 특정 볼륨에 대한 특정 시점의 읽기 전용 인스턴스이다.
스냅샷은 개별 어플리케이션 단위로도 지정되어 사용될 수 있다. 스냅샷이 생성되면 실제 데이터가 새로 생성되지는 않는다. 단지 스냅샷은 그 시점에서의 데이터를 지정하는 메타데이터의 역할을 할 따름이다. 만약 스냅샷이 지정하고 있는 파일의 일부가 변경된다면, 원본 데이터는 변경되지 않고 변경된 부분에 대해서만 디스크의 다른 공간에 데이터를 쓸 것이다.
스냅샷이 지정하고 있는 파일이 삭제될 경우도 마찬가지로 실제 데이터는 삭제되지 않고 남을 것이다. 이런 방식으로 운영 체제나 응용 프로그램은 많은 용량을 사용하지 않고도, 특정 시점으로 파일을 되돌리는 등의 기능을 수행할 수 있다.
이는 당연하게도 애플 운영체제의 백업에도 큰 영향을 줄 수 있다.
예를 들어, 타임머신은 하드 링크를 통해 파일의 변화를 추적하고 기록하는 오래된 파일 시스템에 의존하기 때문에 시간이 오래 걸릴 뿐만 아니라 시스템에도 부하를 일으킨다. 하지만 애플 파일시스템 하에서는 단지 스냅샷과 스냅샷이 지정하는 데이터를 외장하드에 전송하는 식으로 백업 과정을 간소화시킬 수 있다. 이렇게 되면 타임 머신이 시스템을 백업하는 시간이 훨씬 줄어들 뿐만 아니라 시스템 부하 역시 크게 줄어들 것이다.
또, APFS는 Sparse File을 지원하기 때문에 이렇게 생성된 스냅샷과 스냅샷이 지정하는 데이터의 용량을 최소화해서 보관할 수 있다. Sparse File은 파일 내부의 빈 공간을 실제로 디스크게 쓰지 않고 메타데이터로 처리하는 형식이다.
예를 들어 1F2B000086 이라는 데이터가 있으면 0000부분은 실제 디스크에 쓰지 않고 5번째부터 8번째 바이트는 빈 공간이라는 표식만 남겨놓음으로써 용량을 아끼는 방법이다. 운영체제가 이 파일을 요구할 경우 실시간으로 빈 공간을 채워넣어 제공하기 때문에에 사용자는 이 데이터가 변환되었다는 사실을 인지하지 못한다.
다음으로 살펴볼 기능은 현재 유저들이 체감하는 불편함을 해결해 줄 수 있는 내용이다. 현재 맥 운영체제에서 복잡한 폴더 구조와 큰 용량을 가진 디렉토리의 용량을 알기 위해서는 꽤나 오랜 기다림이 필요하다. 하지만 APFS의 Fast Directory Sizing 기능은 이런 불편함을 최소화해줄 수 있을 것이다.
◼︎ 3.5 더 이상 기다림은 그만 : Fast Directory Sizing
위에서 언급한 것과 같이 현재의 HFS+ 파일 시스템은 사용자가 용량을 원할 때마다 용량을 새로 계산한다. 따라서 복잡한 계층 구조를 가진 디렉토리의 경우 계층별로 접근해 그 용량을 계산해 나와야 하기 때문에 최종 용량 계산까지 긴 시간이 소요된다.
하지만 APFS는 각 디렉토리가 용량 정보를 항상 기록하고 있다. 즉, 사용자가 그 디렉토리의 용량을 요구하면 새로 용량을 계산하는 것이 아니라 자신이 갖고 있는 용량 정보를 보여주기만 하는 것이다. 당연히 훨씬 빠르고, 용량을 여러 번 확인하는 경우 전체 컴퓨터가 계산하는 정보를 줄일 수 있는 이점을 가지고 있다.
디렉토리의 용량 정보는 하위 디렉토리의 용량 정보가 변할 때마다 비동기적으로 갱신된다. 당연히 용량이 직접적으로 바뀐 디렉토리의 용량이 다시 계산될 것이고, 이는 상위의 디렉토리의 용량에 각각 반영된다. 이 때 중복된 용량 계산을 막기 위해 항상 부모 노드가 자식 노드에 잠금을 걸게 된다. 이는 항상 단방향이며, 이로써 발생할 수 있는 데드락 문제를 해결할 수 있다. 이런 일련의 과정을 통해 APFS는 최소한의 컴퓨팅 자원만으로 정확한 용량 정보를 항상 유지할 수 있다.
다음에 살펴볼 기능은 Atomic safe-save primitives이다. 이 기능은 파일 시스템의 안정성을 향상시키는 데 핵심적인 기능으로, 어떤 상황에서든 Atomic한 파일 교환을 보장해주는 기능이다.
◼︎ 3.6 파일 시스템의 안정성을 높인다 : Atomic safe-save primitives
먼저 본격적으로 기능의 세부사항을 알아보기 전에 Atomic의 의미를 살펴보도록 하자.
Atomic은 특정 동작이 '원자적'으로 일어난다는 것을 의미한다. 돌턴의 정의에 따르면 원자는 더 이상 쪼갤 수 없는 단위이다. 이 용어는 원자의 이러한 특징에 착안한 용어로 특정 동작이 다른 동작에 의해 쪼개지지 않는, 즉 동시에 일어남을 의미한다. 그렇다면 원자적인 동작이 파일시스템의 안정성에 있어 왜 중요한 역할을 하는지를 좀 더 자세히 알아보도록 하자.
예를 들어 당신이 특정 파일을 응용 프로그램에서 수정을 마치고 저장하는 명령을 내렸다고 생각해보자. 그렇다면 응용 프로그램은 저장할 파일을 임시로 생성한 뒤 원래 위치에 있던 파일과 교체함으로써 저장 작업을 마칠 것이다.
이 때 원래 위치에 있던 파일을 제거하는 동작과 임시 파일을 위치로 옮기는 명령이 원자적으로 수행되지 않을 경우 원래 위치에 있던 파일이 삭제되고 새로운 파일이 그 위치에 덮어씌워지기 전의 찰나의 순간에 PC의 전원이 차단된다면 우리는 단순히 저장하지 않은 부분만을 잃는 것이 아니라 이전에 저장되어 있던 파일마저 잃어버리게 될 것이다. 하지만 이 두 동작이 원자적으로 일어난다면 전원의 차단이 발생하더라도 원본 데이터 전체가 손실되는 일은 없을 것이다. 기존의 HFS+ 역시 단순한 파일에 대해서는 원자적으로 안정성을 보장하고 있다. 하지만 macOS에서 핵심적인 번들에 대해서는 POSIX 호환 파일시스템의 한계로 원자적으로 안정성을 보장하지 못했다.
그런데 '번들'이 도대체 무엇일까?
맥을 쓰는 유저라면 macOS에서 실행되는 어플리케이션이 일종의 폴더임을 이미 알고 있을 것이다. 겉으로 보기에는 단순히 하나의 실행가능한 파일로 보이지만, 실제로 그 내부에는 실행 가능한 코드부터 그 어플리케이션에 필요한 그림, 정보 등 각종 파일들이 디렉토리를 구성하고 있다. 이것이 바로 macOS가 제공하는 '번들'이다. 단지 어플리케이션 뿐만 아니라 각종 프레임워크, 심지어 일부 문서 파일들 역시 이런 번들의 형태로 제공되고 있다. 즉, macOS와 번들은 떼놓을래야 떼놓을 수 없는 관계인 것이다.
APFS는 HFS+가 번들에 대해 원자적인 동작을 담보할 수 없는 점을 개선하여 번들에 대해서도 원자적인 동작을 수행할 수 있도록 했다. 이는 불의의 사고 상황에서도 파일 시스템이 파일을 좀 더 안정적으로 관리할 수 있게 되었음을 뜻한다.
지금까지 APFS에 새로 추가된 여러 기능들을 살펴보았다. 하지만 애플이 APFS를 도입하면서 언급한 신기능들 만큼이나 중요하게 강조하고 있는 사항이 있다. 바로 암호화이다. 애플은 APFS에서 암호화가 단지 파일 시스템의 부가적인 기능이 아니라 파일시스템을 설계할 때 가장 먼저 고려되었던 핵심적인 가치라고 강조했다. APFS가 어떤 식으로 사용자의 데이터를 보호하는지 지금부터 알아보도록 하자.
◼︎ 3.7 더 강력해진 암호화를 제공하는 APFS
APFS의 암호화에 대해 논하기 전에 먼저 현재 애플 운영체제에서 암호화 기능이 어떻게 지원되는지를 알아볼 필요가 있다.
현재 macOS는 파일볼트라는 기능으로 디스크 전체를 암호화하는 방법을 제공한다. 하지만 이 기능은 현행 파일시스템인 HFS+가 자체적으로 지원하는 것이 아니라 별도의 소프트웨어 레이어인 CoreStorage를 통해 지원되고 있다. 당연히 파일시스템이 직접 그 기능을 지원할 때에 비해 오버헤드가 발생할 수밖에 없다. iOS의 경우 암호화를 지원하기 위해 파일시스템 자체를 개량했다. iOS에서 사용되는 파일시스템은 HFS+의 개량형을 사용하여 파일 단위의 암호화를 지원하고 있다.
APFS는 당연히 iOS가 사용하는 개량형 HFS+가 지원하는 개별 파일 단위의 암호화를 지원할 뿐만 아니라 기존에는 별도의 소프트웨어를 통해 지원하던 전체 디스크 암호화 역시 파일시스템 자체적으로 지원한다. 거기에 더해 APFS는 볼륨마다 여러 단계의 암호화를 적용할 수 있도록 하여 필요에 따라 매우 강력한 암호화를 지원할 수 있다. APFS 컨테이너 속에 있는 볼륨은 다음 세 가지 암호화 방식을 선택할 수 있다.
첫 번째는 볼륨을 암호화하지 않는 단계이다. 두 번째는 볼륨당 하나의 키를 이용해 볼륨을 암호화시키는 방법이다. 이 방식은 현재 macOS가 지원하는 파일볼트와 같은 정도의 암호화를 제공한다고 생각하면 된다. 세 번째 방법은 메타데이터와 각각의 파일 데이터를 서로 다른 키를 이용해 암호화시키는 방법이다. APFS는 여기에 더해 특정 파일을 추가적인 키를 이용해 암호화시킬 수 있도록 지원한다. 만약 디스크가 탈취당했다고 하더라도 여러 키로 암호화된 볼륨의 내용을 해석하는 것은 극히 어려울 것이다.
애플은 단지 강력한 암호화를 파일시스템에 추가시키는 것에 그치지 않고, 실제로 사용자가 암호화에 좀 더 적극적으로 나설 수 있는 환경을 만드는 것에도 소홀하지 않았다. 암호화는 기본적으로 성능과 트레이드 오프 관계에 있다. 강력한 암호화를 적용하면 할수록 당연히 그 파일을 쓰거나 접근할 때 암, 복호화 과정이 복잡해질 것이고 이는 필히 성능 저하를 유발한다.
애플은 이런 성능 저하를 최소화하기 위해 각종 기능들을 파일시스템에 통합하여 오버헤드를 최대한 줄이는 데 더해서 파티션보다 훨씬 유연한 볼륨 시스템을 적용하여 사용자가 암호화가 필요하다고 생각하는 데이터에 선택적으로 강력한 암호화를 설정할 수 있도록 함으로써 전체 시스템의 성능 저하를 최대한 막을 수 있도록 했다.
지금까지 APFS에 새로 추가된 다양한 신기술들과 APFS의 특징을 살펴보았다. 당연히 여기에 언급한 내용이 APFS의 전부는 아니다. 대규모 저장장치를 구성할 때 필요한 블럭을 우선 할당하고 그 쪽에만 파일시스템을 구축하여 즉시 사용가능하도록 하는(대용량의 저장장치가 포맷이 끝나지 않았더라도 필요한 지점부터 포맷하고 파일시스템을 구축하여 전체 저장장치의 포맷이 진행되는 중에도 디스크를 사용할 수 있음) 확장 블록 할당이나 파일의 추가 속성을 담는 확장 속성 등 자세히 다루지 못한 내용들 역시 존재한다. 무엇보다 APFS는 아직 개발이 진행중인 파일시스템이기에 정식 출시 시점까지 추가적인 기능 추가나 변동이 있을 수 있다.
4. Exclusive Summary
먼저 지금까지 살펴봤던 내용을 간략하게 정리해보자.
APFS는 애플의 새로운 파일 시스템으로, 현재 애플이 사용중인 HFS 기반의 파일 시스템을 대체하게 될 것이다. HFS는 30여년 전에 개발된 파일 시스템으로 여러 번의 크고작은 변경과 개량이 가해졌지만 현재의 컴퓨팅 환경에 적합한 파일 시스템이라 보기 어렵다. 애플은 자사의 모든 기기들을 하나의 파일 시스템으로 관리하여 여러 개의 파편화된 파일 시스템을 유지보수하는 수고를 덜고 새로운 파일시스템을 도입함으로써 얻을 수 있는 여러 가지 이익을 위해 APFS를 개발했다.
APFS는 플래시 기반의 저장장치에 최적화된 파일 시스템이다 (하지만 전통적인 하드디스크에서도 사용할 수 있다). 비동기식 TRIM을 지원하고, Copy-on-Write 쓰기 정책을 채택하여 쓰기 횟수를 최대한 줄일 뿐만 아니라 성능상에서 이득을 얻고 예기치 못한 사고시에 데이터를 더 안전하게 유지한다. 또, 아이노드를 64비트로 확장함으로써 파일 정보 등을 더 여유롭게 기록할 수 있게되었다. 이제 APFS는 파일의 타임스탬프를 나노초 단위로 기록한다. 이 기능의 연장선상에서 애플은 파일 필드에 공백을 많이 남김으로써 추후 기능 추가에 대한 가능성을 열어두었다. 무엇보다 APFS은 설계 초기부터 암호화를 핵심적인 가치로 삼고 설계되었기 때문에 기존의 파일시스템에 비해 더 나은 암호화 기능을 제공한다.
파일시스템의 근본적인 부분이 엄청나게 바뀐 것처럼 매우 다양한 고 수준의 기능들 역시 추가되었다.
눈에 띄는 것 중 하나는 Space sharing이다. APFS의 볼륨은 기존에 우리가 아는 파티션과 비슷한 개념이지만 훨씬 유연하다. 별도의 작업 없이 쉽게 그 용량을 늘리거나 줄일 수 있으며, 이런 특징 덕분에 컨테이너 내의 빈 공간(심지어 다른 볼륨이 점유하고 있는 빈 공간)도 필요하다면 끌어다 쓸 수 있다. 또 현재 애플이 작성한 몇몇 어플리케이션에서 제공하고 있는 Version 등과 유사한 기능을 파일시스템 자체 기능으로 제공한다.
스냅샷 역시 눈에 띄는 기능 중 하나이다. 스냅샷 기능을 이용하면 시스템 백업이 훨씬 더 간단한 작업이 될 것이다. 이 외에도 APFS는 디렉토리의 용량을 비동기적으로 계산해 정보를 보유함으로써 그 정보를 즉각적으로 사용자에게 제공할 수 있으며 macOS에서 매우 자주 쓰이는 번들과 디렉토리에도 원자적인 교환을 가능하게 함으로써 데이터를 좀 더 안전하게 유지할 수 있게 되었다.
마지막으로 짚어봐야 할 부분은 개선된 암호화인데, 기존에 애플에서 제공하던 각종 암호화 기능을 모두 지원할 뿐만 아니라 이를 파일시스템 단위에서 지원한다. 거기에 한발짝 더 나아가 멀티 키 암호화를 통해 중요한 정보를 매우 강력하게 보호할 수 있으면서 동시에 볼륨별로 다른 암호화 방식을 적용함으로써 시스템 성능의 저하를 최소화할 수 있게 되었다.
APFS의 핵심은 간명하다.
먼저 낸드 플래시 기반의 저장장치에 최적화된 설계로 기존의 파일 시스템에 비해 낸드 플래시 기반 저장장치에서 이점을 갖는다. 그 다음은 애플이 제공하던 여러 소프트웨어 기능들을 파일 시스템 단위에서 지원함으로써 오버헤드를 줄이고 시스템 안정성을 높임으로써 사용자 경험을 향상시키는 것이다. 마지막은 파일시스템 단위에서 더 강력한 암호화를 지원함으로써 성능 손실을 최소화하면서 사용자에게 더 훌륭한 개인정보 보호를 제공하는 점이다.
물론 APFS는 아직 개발이 진행중인 파일 시스템이다. 현 시점에서 APFS는 부팅 디스크로 사용될 수 없고, Case sensitive(파일 이름의 대소문자를 구분함)한 모드밖에 제공하지 않는다. 파일 시스템의 기능과 운영체제의 기능이 충돌하는 파일볼트나 타임머신 백업 역시 현 시점의 소프트웨어로는 불가능하다. 하지만 애플은 2017년에 생산되는 모든 애플 제품들의 기본 파일 시스템은 APFS가 될 것이라 공언했다. 이 또한 운영체제와 하드웨어를 동시에 설계하는 애플이기에 가능한 전격적인 이주이다.
적어도 현 시점에서 가장 진보된 파일시스템 중 하나인 APFS이 애플의 제품들에 어떤 활력을 불어넣을지 기대해 보는 것도 즐거운 일이 될 것이다.
5. 덧붙이는 말
지난 수십년간 컴퓨터의 성능은 비약적으로 발전해왔다. 모든 컴퓨터의 전자적인 부품들이 무어의 법칙 하에 견조한 성장세를 보이는 가운데 이 속도를 따라가기 힘들어하는 부품이 있었다.
바로 보조기억 장치이다. 비교적 근래에 낸드 플래시 기반의 보조기억장치가 본격적으로 보급되기 전까지 보조기억장치는 물리적인 이동을 기반으로 동작했다. 물론 기술의 발전에 따라 디스크의 회전 속도가 빨라지고 저장밀도가 올라가는 등 성능 향상이 없지는 않았지만 무어의 법칙에 따라 성큼성큼 발전하는 컴퓨터의 나머지 부품을 따라잡기 역부족이었음은 모두가 알고 있을 것이다.
하지만 지난 몇 년간 이런 상황은 극적으로 변했다. 처음 SSD가 상품화되던 시점만 해도 SSD의 가격은 매우 비쌌으며 대중화되기까지 긴 시간이 걸릴 것이라 예측했다. 하지만 SSD의 가격은 빠르게 떨어졌고, 많은 전문가들이 대중화의 마지노선이라 말했던 1GB당 1달러를 깬 지도 꽤나 시간이 흘렀다. 이제 낸드 플래시 기반의 저장장치는 더 이상 얼리어답터의 것이 아니다.
초기의 SSD는 하드디스크와 같은 방식으로 시스템과 연결되었고, 하드디스크와 같은 프로토콜을 이용하여 시스템과 통신했다. 하드디스크와 같은 파일 시스템을 이용했음은 물론이다. 하지만 SSD가 빠르게 발전하면서 이런 것들이 하나하나 바뀌고 있다. 최근 나오는 고속의 SSD들은 PCI-E 버스를 통해 시스템과 직결된다. 이는 기존에 하드디스크가 이용하던 SATA와는 달리 시스템과 바로 데이터를 주고받기 때문에 대역폭은 물론이고 지연속도 등의 관점에서도 유리하다. 프로토콜 역시 기존 하드디스크의 AHCI에서 낸드 플래시 기반의 저장장치에 최적화된 NVMe로 대체되고 있다.
이 시점에서 애플의 APFS 발표는 의미심장하다. 마침내 PC OS의 파일시스템까지도 낸드 플래시 기반의 저장장치에 최적화된 형태로 바뀌기 시작한 것이다. APFS의 발표는 HDD 시대가 가고 SSD 시대가 도래했음을 상징적으로 보여주는 사건이다.
또 APFS는 개인정보 보호라는 가치를 핵심으로 삼고 설계된 파일 시스템이다. 암호화에 관련된 여러 기능들이 추가된 것에 더해 암호화가 동반하는 성능의 저하를 최대한 막을 수 있는 여러 방안을 제시함으로써 사용자로 하여금 더 적극적으로 암호화를 적용할 수 있도록 하는 고민 역시 포함되어 있다. APFS는 애플이 사용자의 개인정보 보호에 매우 다방면으로 신경을 쓰고 있다는 것을 다시 한 번 확인시켜 주는 신호이기도 하다.
애플은 APFS이 개발이 완료되는 시점에 오픈 소스로 전환될 것임을 공표했다. 물론 APFS를 애플이 아닌 다른 주요 벤더들이 채택할 것이라고는 상상하기 어렵지만 애플 파일시스템이 강조한 여러 아이디어들을 자사 파일시스템에 보강한다거나 APFS를 자사의 제품에 맞게 개량하여 적용하는 등의 움직임은 충분히 있을 수 있다. 필자는 APFS 그 자체보다 APFS가 상징하고 있는 의미들이 컴퓨터 업계 전반으로 퍼져나가기를 기대하면서 이만 글을 맺겠다.
필자: Jin Hyeop Lee (홈페이지) 생명과학과 컴퓨터 공학을 복수전공하고 있는 대학생입니다. |
참조
• 애플의 새로운 파일 시스템, APFS의 모든 것
• Apple File System Guide
관련 글
• 애플, macOS 시에라부터 오래된 'HFS(Mac OS 표준)' 파일 시스템 지원 중단
• 애플, 차세대 맥 운영체제 'macOS Sierra' 발표
• macOS 시에라의 저장 공간 최적화 기능 살펴보기
