학습용 스토리지의 성능은 SSD에서 데이터를 읽는 속도만으로 결정되지 않습니다. 파일을 열려면 대상 파일을 찾고 경로에 있는 디렉터리의 존재와 접근 권한을 확인해야 합니다. 메타데이터가 여러 서버에 나뉘어 있으면 실제 파일 내용은 읽기도 전에 여러 차례 네트워크 요청이 발생합니다. 이 과정이 병목이면 SSD 대역폭을 늘려도 가속기의 대기 시간은 줄지 않습니다.
Huawei와 상하이교통대학교가 개발한 FalconFS는 이러한 경로 확인을 학습 클라이언트에서 메타데이터 서버로 옮깁니다[1]. 작은 파일이 많고, 학습 때는 순서를 섞어 읽으며, 라벨링 때는 같은 디렉터리를 집중적으로 접근하는 파이프라인이 주요 대상입니다. 클라이언트마다 큰 디렉터리 캐시를 유지하는 대신, 서버에서 여러 클라이언트가 필요한 정보를 함께 사용합니다.
도입 여부를 판단하려면 벤치마크 순위보다 먼저 확인할 것이 있습니다. 실제 입력 처리에서 경로 조회가 얼마나 많은 요청을 만드는지, 디렉터리 정보를 서버에 복제할 메모리가 있는지, 그리고 지원하는 파일시스템 기능이 기존 도구와 맞는지입니다. 논문은 이 설계의 장점과 제약을 구체적으로 설명하지만, 통제된 시험 결과와 실제 운영 규모는 따로 읽어야 합니다.
데이터 로더와 메모리를 나눠 쓰는 디렉터리 캐시
클라이언트 캐시는 방금 사용한 경로를 다시 접근할 때 효과적입니다. 그러나 학습은 큰 데이터셋을 매 에포크마다 새로운 순서로 훑을 수 있습니다. 상위 디렉터리는 반복해서 사용하더라도 하위 디렉터리 정보는 다음 접근 전에 캐시에서 밀려나기 쉽습니다. 파일 수가 많다는 사실만으로 캐시가 비효율적인 것은 아니며, 디렉터리 작업 집합과 접근 순서, 할당할 메모리를 함께 봐야 합니다.
캐시에 더 주는 메모리는 학습 서버에서 다른 용도로도 필요합니다. 데이터 증강, 압축 해제한 샘플, 미리 읽어 둔 입력과 CPU 중간 결과가 같은 메모리를 사용합니다. 디렉터리 캐시를 키워 원격 조회를 줄이더라도 입력 전처리와 가속기 실행을 겹치는 데 쓸 공간이 줄 수 있습니다. 파일시스템 처리량 하나만 보면 이런 자원 경쟁을 놓치게 됩니다.
FalconFS의 출발점은 같은 데이터셋을 쓰는 클라이언트 수가 메타데이터 서버 수보다 훨씬 많다는 관찰입니다. 각 클라이언트가 커널 자료구조로 디렉터리를 보관하는 대신 서버가 압축된 형태로 정보를 유지하면 여러 요청이 이를 공유할 수 있습니다. 메모리가 필요 없어지는 것이 아니라 저장 위치와 표현을 바꾸는 방식이므로, 서버별 복제본의 크기와 앞으로의 증가량을 운영 비용에 포함해야 합니다.
디렉터리는 복제하고 파일 정보는 분할하는 구조
FalconFS는 경로를 따라가는 데 필요한 디렉터리 정보와 개별 파일의 메타데이터를 구분합니다. 메타데이터 노드는 디렉터리 트리를 유지하고, 파일별 inode는 여러 노드에 나눠 저장합니다. 파일 내용은 별도의 저장 계층에 있습니다. 따라서 ‘이름공간 복제’를 모든 파일 내용이나 모든 파일 정보를 서버마다 복제한다는 뜻으로 읽으면 안 됩니다.
파일을 담당하는 노드에 요청이 도착하면 그 노드는 로컬 디렉터리 정보로 경로를 확인한 뒤 자신이 가진 파일 정보를 처리합니다. 클라이언트가 상위 디렉터리부터 여러 서버를 왕복하며 위치를 찾는 과정을 줄이는 것입니다. 주요 접근 경로에서는 파일을 열기 전의 반복 조회가 사라지므로, 작은 파일의 실제 데이터를 공급하는 데 더 많은 처리 자원을 쓸 수 있습니다.
다만 모든 노드가 항상 최신 디렉터리를 빠짐없이 갖는 것은 아닙니다. 새 디렉터리 정보는 필요한 시점에 가져올 수 있으며, 정보가 없는 노드는 소유 노드에 추가로 조회합니다. 한 번의 원격 접근으로 끝난다는 설명은 일반적인 경우의 목표이지 모든 파일 연산에 대한 보장이 아닙니다. 처음 접근하는 경로와 배치 예외, 메타데이터 변경 중에는 추가 통신이 남습니다.
파일명 해시와 예외 처리의 역할
클라이언트 캐시를 없애려면 요청을 보낼 서버를 찾는 방법도 바꿔야 합니다. 전체 경로를 해시하면 목적지를 바로 계산할 수 있지만, 디렉터리 이름을 바꿀 때 하위 파일 전체의 배치가 달라질 수 있습니다. 반대로 부모 디렉터리의 식별자를 사용하면 그 식별자를 얻기 위해 먼저 경로를 조회해야 할 수 있습니다.
FalconFS는 일반적인 경우 파일명을 기준으로 메타데이터를 배치합니다. 서로 다른 이름의 파일이 많은 디렉터리라면 정보가 여러 노드에 분산되므로, 같은 디렉터리의 파일을 한꺼번에 읽어도 한 메타데이터 서버에만 집중되는 현상을 줄일 수 있습니다. 상위 디렉터리의 이름을 바꾸더라도 하위 파일명은 그대로여서 전체 경로 해시의 재배치 문제도 피할 수 있습니다.
파일명이 항상 고르게 분포하지는 않습니다. 여러 디렉터리에 같은 관례적 이름의 파일이 반복되면 특정 노드에 몰릴 수 있습니다. 이를 위해 일부 파일명의 목적지를 지정하거나, 부모 디렉터리 식별자까지 함께 사용하는 예외 처리를 둡니다. 후자는 다른 노드로 한 번 더 전달해야 할 수 있습니다. 클라이언트도 이 예외 정보를 유지하므로, 논문의 stateless는 로컬 상태가 단 하나도 없다는 뜻이 아닙니다.
저장된 inode 수를 고르게 만드는 것과 실제 요청 부하를 고르게 만드는 것도 구별해야 합니다. 특정 파일이 갑자기 자주 읽히거나 여러 작업이 동시에 시작되면 저장량은 균등해도 요청이 치우칠 수 있습니다. 따라서 도입 시험에서는 노드별 inode 수뿐 아니라 요청률과 지연을 함께 관찰해야 합니다.
지연 동기화와 접근 권한의 정확성
디렉터리를 새로 만드는 작업과 없애는 작업은 요구 조건이 다릅니다. 새 디렉터리 정보는 다른 노드가 필요할 때 가져오도록 미룰 수 있습니다. 반면 삭제, 이름 변경과 권한 변경은 다른 노드가 오래된 정보로 잘못된 접근을 허용하지 않도록 해야 합니다. FalconFS는 이때 조정 노드와 무효화, 잠금을 사용합니다.
흔한 생성 작업마다 모든 복제본을 즉시 동기화하지 않아도 된다는 것이 이점입니다. 대신 삭제나 권한 변경에는 더 넓은 범위의 조정이 필요합니다. 논문에서도 디렉터리 삭제는 메타데이터 노드 수가 늘수록 확인할 대상이 많아집니다. 무작위 샘플 읽기에서 나타난 확장성을 디렉터리 삭제 위주의 관리 작업에 그대로 적용해서는 안 됩니다.
정확성은 요청과 무효화의 순서를 맞추는 데서 나옵니다. 먼저 디렉터리 잠금을 잡은 연산이 있으면 무효화가 기다리고, 무효화가 먼저 진행됐으면 이후 연산은 유효한 정보를 얻을 때까지 기다립니다. 권한 확인을 잠시 생략해 속도를 얻는 방식이 아닙니다. 확인하는 위치를 서버로 옮기고 여러 요청이 정보를 공유하도록 만든 것입니다.
Linux 인터페이스에서 남는 기능 제약
Linux의 가상 파일시스템(VFS)은 이미 경로를 따라가며 디렉터리 정보를 캐시합니다. 서버에서 경로를 확인하도록 바꾸더라도 이 동작을 그대로 두면 클라이언트의 반복 작업이 남습니다. FalconFS 클라이언트는 중간 디렉터리와 최종 대상을 구분해, 중간 경로에는 임시 속성을 사용하고 전체 경로의 실제 존재·권한 검사는 서버에서 수행합니다.
임시 속성이 사용자에게 실제 파일 속성으로 보이지 않도록 하는 절차도 필요합니다. 앞서 중간 경로였던 항목이 이후 연산의 최종 대상이 되면 다시 검증하고 실제 속성을 가져옵니다. 서버 검사와 재검증 없이 임의로 허용적인 속성을 반환해도 된다는 뜻으로 이해하면 안 됩니다. 이 구현의 성능과 정확성은 두 부분이 함께 동작한다는 전제에 있습니다.
논문이 밝힌 기능 제약도 명확합니다. 해당 구현은 심볼릭 링크와 하위 중첩 마운트 처리를 지원하지 않으며, 디렉터리 접근·수정 시각도 비교 시스템과 같은 방식으로 유지하지 않습니다. 학습 루프가 단순 읽기만 사용하더라도 백업 도구나 데이터셋 관리 스크립트는 이런 기능에 의존할 수 있습니다. POSIX와 유사한 인터페이스가 있다는 사실만으로 기존 환경을 수정 없이 옮길 수 있다고 판단해서는 안 됩니다.
동시 요청을 묶어서 얻는 처리량
메타데이터 서버에 요청이 모이면 공통 작업을 합칠 수 있습니다. 같은 상위 경로를 지나는 요청은 잠금 처리 일부를 공유하고, 여러 메타데이터 변경은 쓰기 전 로그(WAL)를 묶어 작은 영속화 작업의 반복을 줄입니다. FalconFS는 PostgreSQL의 트랜잭션과 로그 기능에 파일시스템용 확장을 더해 이를 구현합니다.
이 최적화는 처리량을 높이는 대신 개별 요청의 지연을 늘릴 수 있습니다. 동시 요청이 적으면 합칠 일이 충분하지 않고, 한 요청이 끝날 때까지 걸리는 시간이 더 중요해집니다. 논문에서도 낮은 동시성에서는 Lustre가 더 유리한 경우가 있으며, 동시 요청이 늘면서 FalconFS의 처리량 이점이 나타납니다. 큰 학습 작업과 사람이 데이터셋을 탐색하는 작업을 같은 최대 처리량 숫자로 설명할 수 없는 이유입니다.
모의 학습 결과와 실제 운영 규모의 구분
평가 환경은 듀얼 소켓 서버 13대를 자원별로 나눠 만든 논리 노드 26개입니다. 서버를 포화시키는 시험에서는 CPU 자원을 제한했고, 비교한 파일시스템은 모두 메타데이터와 데이터 복제를 껐습니다. CephFS, JuiceFS와 Lustre의 특정 버전을 사용했으며, 일부 최대 메타데이터 처리량 시험에서는 FUSE 클라이언트가 서버를 충분히 부하시키지 못해 라이브러리 인터페이스를 사용했습니다.
따라서 이 결과를 실제 서비스의 구매 비율로 바로 바꿀 수는 없습니다. 복제를 켜면 영속화와 네트워크 비용이 달라지고, 클라이언트 인터페이스에 따라 CPU 비용도 달라집니다. 논문은 구조 차이를 보여 주지만, 운영자는 자신이 사용할 내구성 설정과 클라이언트 경로에서 다시 시험해야 합니다.
학습 평가는 MLPerf Storage로 ResNet-50의 입력 부하를 모의 실행했습니다. 112 KiB 파일 1,000만 개가 디렉터리 100만 개에 나뉘어 있고 직접 입출력(direct I/O)을 사용합니다. 가속기 활용률 90%를 기준으로 삼았을 때 지원한 모의 가속기 수는 FalconFS 80개, Lustre 32개였으며, CephFS는 이 시험에서 해당 기준을 충족하지 못했습니다. 실제 GPU 80개로 모델 학습을 수행한 측정값도, CephFS의 일반적인 지원 용량이 0이라는 뜻도 아닙니다.
최종 PDF의 초록과 평가 본문은 최대 성능 배율을 일관되게 표기하지 않습니다. 이 글에서는 그중 큰 숫자를 골라 제목이나 핵심 결론으로 사용하지 않았습니다. 구체적인 조건이 제시된 활용률 기준, 요청 수와 작동 원리가 도입 판단에 더 유용하기 때문입니다.
운영 경험과 별도로 확인할 복구·증설 조건
논문은 Huawei 자율주행 환경의 NPU 1만 개 규모에서 일 년 동안 사용한 경험을 별도로 보고합니다. 이는 실제 파이프라인에 적용됐다는 근거입니다. 그러나 이 운영 규모와 복제를 끈 실험 환경을 합쳐, 1만 개 NPU 전체가 같은 벤치마크 성능을 냈다고 쓰면 안 됩니다.
FalconFS의 장애 복구에는 로그와 주·보조 복제, 조정 노드 복구가 사용됩니다. 이는 경로 조회를 빠르게 하기 위한 디렉터리 정보의 지연 복제와 다른 기능입니다. 둘을 혼동하면 이름공간 최적화가 전체 내구성 설계를 대신하는 것처럼 보일 수 있습니다. 메타데이터의 가용성, 완료된 쓰기의 복구와 실제 파일 데이터 보호는 각각의 실패 조건으로 검증해야 합니다.
증설에도 제약이 있습니다. 설명된 구현은 클러스터 구성을 바꾸며 inode를 이동하는 동안 요청 처리를 중단합니다. 온라인 이동을 지원하는 방식이 아니므로, 계속 커지는 AI 플랫폼에서는 필요한 증설 주기와 허용 중단 시간을 확인해야 합니다. 정상 상태의 높은 처리량이 용량 확대 때의 긴 중단을 상쇄하지는 못합니다.
파일시스템 교체와 데이터 구성 변경 사이의 선택
작은 샘플을 큰 컨테이너 파일로 묶어 파일 열기 횟수를 줄이는 방법도 있습니다. 이는 파일시스템 대신 데이터 형식이나 로더를 바꾸는 선택입니다. 고정된 학습 데이터셋에는 적합할 수 있지만, 샘플을 개별 수정하거나 여러 단계가 같은 데이터를 사용하는 파이프라인에서는 재포장과 관리가 부담이 될 수 있습니다. 어느 쪽이 유리한지는 데이터를 누가 읽고 바꾸는지에 달려 있습니다.
먼저 측정할 값은 유효한 샘플 하나를 공급하는 데 발생한 메타데이터 요청 수와 클라이언트의 CPU·메모리 비용입니다. 이 비용이 크다면 FalconFS의 구조를 검토할 이유가 있습니다. 반대로 압축 해제, 데이터 증강, SSD 대역폭이나 네트워크가 주된 병목이라면 경로 조회를 개선해도 학습 진행은 거의 달라지지 않을 수 있습니다.
최종 비교 기준은 최대 SSD 대역폭이나 가장 큰 성능 배율보다, 필요한 내구성과 활용률을 유지하며 지원할 수 있는 가속기 수여야 합니다. 실제 디렉터리 분포와 파일명, 권한 변경, 동시성, 증설 절차를 넣어 다시 시험해야 합니다. FalconFS는 큰 공용 이름공간 때문에 클라이언트마다 같은 일을 반복하는 비용이 크고, 애플리케이션이 명시된 운영 제약을 수용할 수 있을 때 설득력 있는 선택입니다.
출처와 저작권 안내
이 글은 Huawei Technologies와 상하이교통대학교 연구진의 NSDI 2026 최종 논문[1]을 바탕으로 작성한 독립적인 편집 다이제스트입니다. 측정과 구현 제약은 해당 판본에 근거하며, 도입 판단은 Silicon & Systems의 분석입니다. 원문의 문장·표·도판은 옮기지 않았고 본문과 설명 그림을 새로 만들었습니다. 원 논문의 저작권은 해당 권리자에게 있으며(© 2026), 프로시딩 발행 기관은 USENIX Association입니다.