Fire-Flyer File System(3FS)의 아키텍처부터 Lustre, GPFS, WekaFS, DAOS까지 — AI 학습·추론을 책임지는 차세대 스토리지의 모든 것
3FS(Fire-Flyer File System)는 DeepSeek이 2025년 2월 오픈소스로 공개한 AI 전용 분산 파일시스템입니다. NVMe SSD와 RDMA 네트워크를 적극 활용해 180노드 클러스터에서 6.6 TiB/s의 읽기 처리량을 달성했으며, KVCache 환경에서는 최대 40 GiB/s의 피크 처리량을 보여줬습니다. 전통적인 POSIX 의미론(semantics)을 일부 포기하는 대신, AI 워크로드의 핵심인 대용량 순차 읽기와 메타데이터 처리량을 극대화한 것이 특징입니다.
안녕하세요, 마빈정입니다. 베이징 주재 근무 중에 중국 AI 생태계의 변화를 가까이서 지켜보고 있는데요, 그중에서도 DeepSeek의 행보가 가장 흥미롭습니다. 모델뿐만 아니라 학습 인프라까지 통째로 오픈소스화하고 있기 때문입니다.
오늘은 그중에서도 가장 묵직한 한 방, 3FS(Fire-Flyer File System)를 다뤄보겠습니다. 이 글 한 편으로 다음 세 가지를 모두 이해하실 수 있습니다.
본격적인 이야기에 앞서, 가장 기초적인 개념부터 짚고 넘어가겠습니다. 파일시스템(File System)은 운영체제가 저장장치 위에 데이터를 어떻게 배치하고, 어떻게 찾아오게 할지를 정의하는 규칙의 묶음입니다. 우리가 평소에 사용하는 ext4, NTFS, APFS가 모두 파일시스템입니다.
그런데 파일시스템마다 동작 방식이 제각각이라면, 응용 프로그램은 모든 파일시스템 종류를 따로 지원해야 합니다. 이 문제를 해결하기 위해 표준이 만들어졌는데, 그것이 바로 POSIX(Portable Operating System Interface)입니다.
POSIX는 1988년 IEEE가 제정한 운영체제 호환성 표준입니다. open(), read(), write(), close() 같은 시스템 콜의 동작 방식을 정의해, 같은 코드가 여러 OS에서 동일하게 동작하도록 보장합니다.
POSIX가 정의하는 가장 강력한 약속 중 하나는 강한 일관성(Strong Consistency)입니다. 어떤 프로세스가 파일에 무언가를 썼다면, 그 직후 다른 프로세스가 같은 파일을 읽을 때 반드시 새로 쓴 내용이 보여야 한다는 규칙입니다.
단일 노드 환경이라면 이 규칙은 지키기 쉽습니다. 하지만 대규모 분산 시스템에서는 사정이 달라집니다. 데이터가 여러 노드에 복제되어 있을 때, 모든 노드의 상태를 항상 동기화시키는 비용이 폭증하기 때문입니다. Lustre, GPFS, BeeGFS 같은 대표적인 병렬 파일시스템(PFS)들은 모두 POSIX 일관성을 지원하지만, HPC 시스템 규모가 커지고 SSD가 일반화되면서 POSIX 일관성을 유지하는 비용이 점점 받아들이기 어려운 수준이 되고 있습니다.
AI 학습 워크로드는 전통적인 OLTP(온라인 트랜잭션)나 일반 HPC와는 다른 특성을 가집니다. 이 차이를 이해해야 왜 새로운 파일시스템이 필요한지 보입니다.
이런 워크로드 앞에서 POSIX 의미론은 두 가지 큰 부담을 만듭니다. 첫째, 메타데이터 병목입니다. 수천 개의 GPU 워커가 동시에 파일을 열고 닫으면, POSIX의 엄격한 디렉터리 락(directory lock)과 atime 갱신이 메타데이터 서버를 마비시킵니다.
둘째, 쓰기 일관성 비용입니다. 모든 쓰기 직후 모든 읽기가 최신값을 봐야 한다는 규칙은, RDMA로 마이크로초 단위까지 줄여놓은 네트워크 지연을 다시 늘립니다. 그런데 AI 학습 데이터셋은 대부분 읽기 전용(read-only)입니다. 데이터를 미리 한 번 써두고 수십 epoch 동안 읽기만 합니다. 이 경우 POSIX 수준의 강한 쓰기 일관성은 과잉 사양인 셈입니다.
POSIX는 "범용성"을 위해 설계된 표준입니다. 그러나 AI 학습은 "범용 워크로드"가 아닙니다. 읽기 비중이 압도적이고, 패턴이 예측 가능하며, 동시성 규모가 극단적입니다. 범용 표준의 안전망이 오히려 발목을 잡는 구간이 발생합니다.
2025년 2월 28일, DeepSeek은 3FS(Fire-Flyer File System)를 GitHub에 오픈소스로 공개했습니다. 3FS는 FUSE 기반의 리눅스 파일시스템으로, 현대 SSD와 RDMA 네트워크를 활용해 AI 학습·추론 성능을 끌어올리는 것을 목표로 합니다. 언어 구성은 C++ 87%, Rust 4.3%, Python 2.1%로, 성능과 안정성을 모두 챙기는 조합입니다.
"3FS는 thousands of SSDs의 처리량과 hundreds of storage nodes의 네트워크 대역폭을 결합해, 응용프로그램이 데이터의 물리적 위치에 구애받지 않고 스토리지에 접근할 수 있게 합니다."
— DeepSeek 3FS 공식 README 요약
3FS는 분리형(disaggregated) 아키텍처를 채택해, 역할이 명확한 4개의 서비스로 구성됩니다. 모든 컴포넌트는 RDMA 네트워크로 통신합니다.
클러스터 매니저는 멤버십 변경과 설정을 관리합니다. 가용성을 위해 다중 매니저를 배포하며, 그중 하나가 ZooKeeper나 etcd 같은 분산 코디네이션 서비스를 통해 프라이머리로 선출됩니다. 메타데이터 서비스와 스토리지 서비스로부터 하트비트를 받아 장애를 감지하고, 변경된 클러스터 설정을 모든 컴포넌트에 배포합니다.
전통적인 분산 파일시스템에서 메타데이터 서버는 가장 큰 단일 병목이었습니다. 3FS는 이 문제를 영리하게 풀었습니다. 메타데이터 서비스는 무상태이며, 파일 메타데이터는 트랜잭셔널 KV 스토어인 FoundationDB에 저장됩니다. 따라서 클라이언트는 어떤 메타데이터 서비스에든 접속할 수 있습니다.
FoundationDB는 Apple이 개발해 오픈소스화한 분산 ACID KV 스토어입니다. 키 글로벌 정렬과 일관 해싱 기반 자동 분산을 제공해, 디렉터리 리스팅 같은 메타데이터 패턴을 효율적으로 처리할 수 있습니다. 3FS는 DENT 프리픽스와 부모 inode 번호, 파일명을 결합해 dentry 키를 구성합니다.
3FS의 가장 흥미로운 결정은 데이터 일관성을 보장하는 방법입니다. 바로 CRAQ(Chain Replication with Apportioned Queries)를 채택한 것이죠.
CRAQ는 읽기 중심 워크로드에 최적화된 write-all-read-any 복제 프로토콜입니다. 모든 복제본의 읽기 대역폭을 활용하는 것은 올플래시 스토리지에서 최고의 읽기 처리량을 달성하기 위한 핵심입니다. 동작 방식은 다음과 같습니다.
이 구조의 묘미는 읽기는 모든 복제본이 분산 처리하고, 쓰기 일관성은 체인의 꼬리(Tail)에서 단일 진실 공급원으로 보장한다는 점입니다. AI 학습처럼 read-heavy한 워크로드에 최적화된 선택입니다.
3FS는 두 종류의 클라이언트를 제공합니다. 대부분의 응용은 FUSE 클라이언트를 사용하는데, 채택 장벽이 낮기 때문입니다. 성능이 중요한 응용은 native client를 사용해 직접 통합합니다. Native 클라이언트는 USRBIO API를 사용해 RDMA를 직접 활용하므로, FUSE 오버헤드 없이 최대 성능을 끌어낼 수 있습니다.
DeepSeek이 공개한 공식 벤치마크 수치를 보겠습니다. 이론적 최대치가 아닌 실제 운영 클러스터에서 측정한 값입니다.
읽기 스트레스 테스트 클러스터는 180개 스토리지 노드(노드당 2×200Gbps InfiniBand NIC, 16×14TiB NVMe SSD)와 500여 클라이언트 노드(노드당 1×200Gbps InfiniBand NIC)로 구성되었으며, 학습 작업의 백그라운드 트래픽이 있는 상태에서 약 6.6 TiB/s의 집계 읽기 처리량을 기록했습니다. GraySort 테스트에서는 25개 스토리지 노드와 50개 컴퓨트 노드 환경에서 110.5 TiB의 데이터를 8,192개 파티션에 걸쳐 30분 14초 만에 정렬했습니다.
이제 본 주제로 돌아갑니다. 3FS는 POSIX와 정확히 어디가 같고 어디가 다를까요?
| 항목 | POSIX 표준 | DeepSeek 3FS |
|---|---|---|
| 설계 목표 | 범용 OS 호환성 | AI 학습/추론 처리량 극대화 |
| 파일 인터페이스 | 표준 정의 | FUSE로 호환 제공 |
| 일관성 모델 | Strong (모든 쓰기 즉시 가시화) | CRAQ 기반 Strong (체인 종단 보장) |
| 메타데이터 | OS·FS별 상이 | FoundationDB KV 스토어 (무상태) |
| 분산 의식 | 없음 (단일 노드 전제) | 분리형 아키텍처 |
| RDMA 네이티브 | 없음 | 전 컴포넌트 RDMA |
| 쓰기 지연 | 로컬: 매우 낮음 | 체인 전파로 다소 높음 (트레이드오프) |
| 읽기 처리량 | 로컬 SSD 한계 | 전 노드 합산 (TiB/s급) |
| 파일 락(advisory lock) | 완전 지원 | 제한적 |
| 하드 링크/심볼릭 링크 | 지원 | 제한적 |
요약하면 3FS는 POSIX의 "겉모습"은 유지하되, 내부 구현에서 분산 환경에 맞지 않는 부분은 과감히 다른 방식으로 구현했습니다. FUSE 클라이언트로 표준 인터페이스를 노출해 응용프로그램은 그대로 사용할 수 있게 하면서도, 백엔드는 RDMA·CRAQ·KV 스토어 조합으로 완전히 새로 짠 셈입니다.
3FS만 보면 그림의 일부만 보는 것입니다. 현재 AI 인프라 시장에서 활발히 사용되는 주요 파일시스템 7종을 비교해보겠습니다.
GPFS
GFS
FS
| 시스템 | 오픈소스 | RDMA | 주 용도 | 강점 |
|---|---|---|---|---|
| Lustre | Yes | Yes | HPC·대형 학습 | 대용량 처리량 |
| GPFS | No | Yes | 엔터프라이즈 | 관리·정책 |
| BeeGFS | 부분 | Yes | 중소 HPC | 설치 용이성 |
| WekaFS | No | Yes | 대형 AI | 메타 IOPS |
| DAOS | Yes | Yes | 차세대 HPC | 최저 지연 |
| JuiceFS | 부분 | No | 클라우드 | 비용 효율 |
| 3FS | Yes | Yes | LLM 학습/추론 | KVCache 최적화 |
이 글에서 다룬 7개 파일시스템은 모두 POSIX의 아이디어에서 출발해, 각자의 워크로드에 맞춰 표준의 일부를 다시 짠 결과물입니다. 3FS도 마찬가지입니다. POSIX를 부정하는 것이 아니라, FUSE로 호환을 유지하면서 AI 시대의 요구를 받아들인 절충안입니다.
특히 흥미로운 점은 중국발 오픈소스의 약진입니다. JuiceFS와 3FS는 모두 중국에서 만들어졌고, 둘 다 활발한 글로벌 사용자 베이스를 확보하고 있습니다. AI 인프라 분야에서 미·중·EU의 기술 분포가 빠르게 재편되고 있다는 신호이기도 합니다.
"파일시스템은 더 이상 OS의 부속품이 아니라, AI 학습의 1차 변수가 되었습니다. GPU가 아무리 빨라도 파일시스템이 굼뜨면 모델은 굶주립니다."
— AI Infra Series 결론
다음 글에서는 3FS의 KVCache 메커니즘을 LLM 추론 관점에서 더 깊이 파헤쳐보겠습니다. 또한 NVMe-oF, GPUDirect Storage(GDS) 같은 인접 기술들도 시리즈로 다룰 예정입니다.
읽어주셔서 감사합니다. 질문이나 추가로 다뤘으면 하는 주제가 있다면 댓글로 남겨주세요.
'AI' 카테고리의 다른 글
| 클라우드 데이터베이스 완전 정복: AI in DB 시대의 개막과 글로벌 CSP 비교 (0) | 2026.05.13 |
|---|---|
| 백 투 더 베이직(Back to the Basic): 데이터베이스(Database)의 본질, 기초부터 다시 배우는 DB의 모든 것 (0) | 2026.05.13 |
| OLAP vs OLTP 완벽 정복 (0) | 2026.05.13 |
| SPDK가 뭘까? 전격 해부 (0) | 2026.05.13 |
| DeepSeek V4 출시 전격 분석: 1.6조 파라미터 오픈소스가 GPT-5와 클로드를 흔든 날 (0) | 2026.05.13 |