Insight

HPC 성능의 발목을 잡는 ‘데이터 로딩 병목’, 병렬 파일 시스템으로 해결하기

AI·HPC 환경에서 성능 이야기가 나오면 많은 조직이 먼저 CPU나 GPU 스펙부터 떠올립니다. 그러나 실제 현장에서는 최고급 연산 자원을 확보하고도 기대한 만큼 성능이 나오지 않는 경우가 적지 않습니다. 이유는 의외로 단순합니다. 연산 장치가 데이터를 기다리는 시간이 생각보다 훨씬 길기 때문입니다. 모델 학습이든 시뮬레이션이든, 계산은 결국 데이터를 끊임없이 읽고 쓰는 흐름 위에서 이뤄집니다. 이때 스토리지에서 데이터를 불러오는 속도가 연산 속도를 따라가지 못하면, GPU는 계산보다 대기 상태에 더 오래 머무르게 됩니다. 결국 인프라의 병목은 연산 장비가 아니라 데이터 공급 경로에서 시작되는 경우가 많습니다.

특히 최근 AI 워크로드는 과거보다 훨씬 더 많은 파일, 더 큰 데이터셋, 더 복잡한 전처리 과정을 동반합니다. 이미지, 영상, 로그, 센서 데이터, 텍스트 코퍼스처럼 다양한 형식의 데이터가 수많은 작은 파일 단위로 저장되면서, 단순한 저장 용량보다 메타데이터 처리와 병렬 읽기 성능이 더 중요해졌습니다. 다시 말해 지금의 스토리지 문제는 “데이터를 담을 수 있는가”가 아니라, “연산 노드가 필요한 순간에 데이터를 끊김 없이 공급할 수 있는가”의 문제로 바뀌고 있습니다.
 

전통적인 업무 시스템에서는 저장장치의 응답이 조금 늦더라도 체감 영향이 제한적일 수 있습니다. 하지만 AI 학습과 HPC 시뮬레이션은 수십, 수백 개의 연산 노드가 동시에 같은 데이터셋 또는 대규모 파일 집합에 접근하는 경우가 많습니다. 이때 단일 NAS나 일반 파일 서버 구조는 중앙 집중식 병목을 일으키기 쉽습니다. 여러 클라이언트가 동시에 읽기 요청을 보내면 I/O 대역폭이 한 지점에 몰리고, 결과적으로 전체 처리량이 급격히 떨어집니다. 즉, 연산 자원은 병렬로 확장했는데 스토리지 접근 방식은 여전히 직렬적이라면, 확장 효과는 기대만큼 나오지 않습니다.

AI 파이프라인에서는 이 문제가 특히 전처리 단계에서 자주 드러납니다. 학습 전에 데이터를 정제하고, 포맷을 변환하고, 샤딩하거나 증강하는 과정에서 대량의 읽기·쓰기 작업이 반복되기 때문입니다. 현업에서는 종종 “학습이 느리다”고 인식하지만, 실제 원인은 GPU 연산이 아니라 학습 직전까지 이어지는 데이터 준비 과정에 있는 경우가 많습니다. 데이터셋이 커질수록, 그리고 파일 수가 많아질수록 이러한 병목은 더 심해집니다. 결국 전처리 성능이 받쳐주지 않으면 전체 학습 일정이 밀리고, GPU 클러스터의 가동률도 떨어집니다.
 

이 문제를 해결하기 위해 주목받는 것이 바로 병렬 파일 시스템입니다. 병렬 파일 시스템의 핵심은 파일 데이터를 여러 스토리지 노드에 분산 저장하고, 여러 클라이언트가 이를 동시에 병렬로 읽고 쓸 수 있게 한다는 점입니다. 대표적으로 Lustre는 오픈소스 기반의 병렬 파일 시스템으로, 대규모 HPC 환경에서 폭넓게 활용되어 왔습니다. 이 구조의 장점은 명확합니다. 하나의 큰 파일을 여러 저장 대상에 스트라이핑해 분산시키거나, 다수의 클라이언트가 여러 스토리지 서버에 동시에 접근하도록 함으로써 전체 처리량이 하드웨어 확장에 비례해 커질 수 있다는 점입니다.

최근에는 소프트웨어 정의 방식의 고성능 데이터 플랫폼도 함께 주목받고 있습니다. 예를 들어 WEKA와 같은 구조는 AI 데이터 파이프라인 전반에서 빠른 접근성과 낮은 지연, 그리고 대규모 확장성을 강조합니다. 특히 많은 수의 작은 파일이 존재하는 환경에서 기존 스토리지가 약점을 드러내는 반면, 이러한 플랫폼은 AI 워크플로우 전반을 하나의 고성능 파일 계층 위에서 처리하는 방향을 제시합니다. 중요한 것은 특정 제품명이 아니라, 이제 스토리지는 단순한 보관소가 아니라 GPU를 먹여 살리는 실시간 데이터 공급 계층으로 재정의되고 있다는 사실입니다.
 

병렬 파일 시스템을 도입한다고 해서 모든 문제가 자동으로 해결되는 것은 아닙니다. 실무에서는 데이터 전처리 단계의 I/O 패턴을 함께 최적화해야 진짜 효과가 납니다. 첫째, 작은 파일이 지나치게 많은 구조는 메타데이터 연산을 폭증시켜 전체 로딩 속도를 떨어뜨릴 수 있으므로, 가능한 경우 샤딩이나 묶음 포맷을 통해 파일 수를 줄이는 전략이 필요합니다. 둘째, 자주 사용하는 데이터는 연산 노드와 가까운 계층에 캐싱해 반복 접근 비용을 낮춰야 합니다. 셋째, 학습·분석 작업의 병렬도와 스토리지 스트라이프 정책이 맞지 않으면 오히려 대역폭을 충분히 쓰지 못하므로, 워크로드 특성에 맞는 스트라이핑과 프리페치 전략이 병행되어야 합니다.

특히 AI 환경에서는 “학습 서버는 빠른데 학습이 느린” 현상이 자주 발생합니다. 이는 연산 성능 부족이 아니라, 데이터 준비와 공급이 연산 속도를 따라가지 못하기 때문입니다. 따라서 인프라 운영자는 GPU 사용률만 볼 것이 아니라, 데이터 로딩 시간, 전처리 대기 시간, 메타데이터 응답 지연, 스토리지 처리량까지 함께 모니터링해야 합니다. 그래야만 병목이 GPU에 있는지, 네트워크에 있는지, 스토리지에 있는지 정확히 구분할 수 있습니다. 결국 스토리지 최적화는 저장장치만의 문제가 아니라, 전체 AI 파이프라인의 시간을 줄이는 핵심 과제입니다.
 

이제 고성능 컴퓨팅 환경에서 스토리지는 더 이상 후순위 인프라가 아닙니다. 연산 자원은 계속 빨라지고 있지만, 데이터 경로가 그 속도를 따라가지 못하면 전체 시스템의 효율은 쉽게 무너집니다. 특히 대규모 AI 프로젝트와 HPC 워크로드에서는 데이터 로딩 병목이 곧 일정 지연, 자원 낭비, 비용 증가로 이어집니다. 그래서 앞으로의 스토리지 전략은 단순한 용량 확대가 아니라, 대규모 동시 접근을 감당할 수 있는 병렬 구조, 전처리 단계까지 고려한 I/O 최적화, 연산 환경과 긴밀히 맞물린 데이터 파이프라인 설계로 나아가야 합니다.

결국 AI·HPC 인프라의 성능은 CPU, GPU, 네트워크, 스토리지 중 어느 하나만으로 결정되지 않습니다. 그러나 실제 현장에서는 가장 늦은 계층이 전체 속도를 결정합니다. 그리고 그 병목이 스토리지에서 발생하는 순간, 최고급 GPU도 충분히 활용되지 못합니다. 이제는 “얼마나 좋은 GPU를 도입했는가”만큼이나 “그 GPU에 데이터를 얼마나 빠르고 안정적으로 공급할 수 있는가”가 중요한 시대입니다. 병렬 파일 시스템과 전처리 I/O 최적화는 바로 그 질문에 대한 가장 현실적인 해답이 되고 있습니다.