왜 스토리지가 AI의 성능을 결정하는가

최근 몇 년간 AI 모델의 규모와 학습 데이터셋은 기하급수적으로 커졌습니다. 특히 지난 1년여간 최신 모델의 출시 주기는 수개월에서 수주로 짧아졌죠. 이런 혁신의 속도를 따라가려면 저장소에 대한 빠르고 안정적인 접근이 필수입니다. AI를 뇌에 비유한다면, 스토리지는 기억력과 같아서 용량이 크고 검색 속도가 빨라야 모델의 성능과 학습 속도가 좌우됩니다.

하지만 AI 컴퓨팅 성능이 2년마다 약 3배씩 성장한 반면, 스토리지와 인터커넥트 성능 성장은 상대적으로 더뎠습니다. 그 결과, 스토리지 병목은 AI 워크로드에서 GPU 지연의 주요 원인 중 하나가 되었고, 이는 비용 증가와 시장 출시 지연으로 직결됩니다. GPU 활용률 외에도 스토리지 아키텍처는 AI 연구의 반복 속도에 직접적인 영향을 줍니다. GPU가 점점 지리적으로 분산되고 데이터셋이 대규모화되면서, 연구자들은 데이터를 지역 간에 옮기고 불러오는 데 많은 시간을 소비하게 됐습니다.

이 글에서는 Meta가 BLOB 스토리지 아키텍처를 어떻게 진화시켜 두 가지 핵심 과제를 해결했는지 자세히 살펴봅니다:

  • GPU 활용률 극대화
  • 연구 반복 속도 극대화

이 내용은 Meta 공식 엔지니어링 블로그에 게재된 글을 기반으로, 실제 적용 가능한 인사이트를 추가로 정리했습니다.

Meta AI storage clusters with GPU servers and high-speed network Coding Session Visual

GPU 활용률을 높이기 위한 설계 변화

왜 지연 시간이 중요한가

모델 학습 중에는 수십만 개의 GPU가 방대한 데이터를 여러 번 반복해서 읽습니다. GPU는 배치 단위로 데이터를 처리하고, 일정 스텝마다 서로 상태를 동기화합니다. 이때 하나의 GPU라도 느리면 전체 학습이 지연됩니다. 아래 그림처럼 데이터 로딩 파이프라인에서 스토리지 fetch 지연이 발생하면 GPU가 I/O를 기다리며 멈추는 현상이 생깁니다.

# 데이터 로딩 파이프라인 예시 (개념적)
import time
import random

def load_next_batch():
    # 스토리지에서 다음 배치를 가져오는 함수
    # 지연 시간이 길어지면 GPU가 멈춤
    latency = random.uniform(0.001, 0.5)  # 1ms ~ 500ms
    time.sleep(latency)
    return f"batch_data_{latency:.3f}"

# GPU1: 지연이 짧아 문제없음
# GPU2: 지연이 길어 스톨 발생
for step in range(10):
    batch = load_next_batch()
    print(f"Step {step}: {batch}")

기존 BLOB 스토리지의 한계

기존 아키텍처는 전통적인 웹 워크로드에 최적화되어 있었습니다. 하지만 AI 워크로드는 다음과 같은 특성이 달라서 새로운 설계가 필요했습니다:

  • 성능 및 지연 시간: AI는 밀리초 단위의 일관된 지연 시간을 요구하지만, 기존에는 수백 밀리초가 걸리는 메타데이터 조회가 흔했습니다.
  • 신뢰성 및 내구성: 기본적으로 전역 복제를 했지만, AI 워크로드는 지역 내 높은 가용성이 더 중요합니다.
  • 비용 효율성: HDD 기반 설계는 IOPS가 부족해 플래시가 필요하며, 스토리지 비용보다 GPU 비용이 압도적입니다.
  • 전력 효율성: GPU 데이터센터는 공간보다 전력에 제약이 있어, 스토리지 전력 소비를 최소화해야 합니다.

새로운 기반 구축

Meta는 다음과 같은 주요 설계 결정을 내렸습니다:

  1. 통합 메타데이터 스키마: 여러 레이어에 분산된 메타데이터를 ZippyDB 기반의 단일 플랫 스키마로 통합해 O(1) 조회가 가능하게 했습니다.
  2. 데이터플레인 프록시 제거: 프록시를 없애고 클라이언트 SDK가 직접 스토리지 서버에서 바이트를 스트리밍하도록 변경해 전력 효율과 성능을 높였습니다.
  3. 지역 배포: GPU와 함께 지역 내에 BLOB 스토리지 스택을 배포해 지연을 최소화했습니다.
# 새 아키텍처의 getObject 흐름 (개념적)
def get_object(sdk, bucket, path):
    # 1. 메타데이터 서버에 read plan 요청 (O(1) 조회)
    read_plan = sdk.get_read_plan(bucket, path)
    # 2. SDK에 내장된 Tectonic BlockClient가 직접 데이터 스트리밍
    data = sdk.stream_blocks(read_plan)
    return data

스파이크와 핫스팟 대응

AI 워크로드는 체크포인트 로딩 시 수백 개 GPU가 동시에 데이터를 읽어 스파이크가 발생합니다. 이를 해결하기 위해:

  • 분산 데이터 캐시: GPU 호스트의 여유 메모리를 활용해 자주 접근하는 데이터를 캐시 (평균 80% 히트율)
  • Readplan 메타데이터 캐시: 자주 접근하는 BLOB의 경로-주소 매핑을 분산 메모리 스토어에 캐시해 1-2ms 응답 보장

프로토콜 최적화

  • Laggards: 느린 스토리지 노드로 인한 꼬리 지연을 헤지드 리드로 해결
  • Egress 스파이크: 체크포인트 시 발생하는 트래픽 급증을 클라이언트 SDK의 동적 동시성 제어로 완화

Data ingestion pipeline with tiered caching for AI training Developer Related Image

연구 반복 속도 극대화: 티어드 캐싱과 프리페칭

GPU가 지리적으로 분산되면서 연구자들은 데이터를 지역 간에 이동해야 하는 부담을 안게 됐습니다. 기존에는 데이터 스냅샷을 대상 지역에 복사하는 데 몇 시간이 걸렸고, 이는 연구 반복 속도를 크게 저하시켰습니다.

Meta는 운영체제의 페이지 캐시 개념을 차용해 글로벌 BLOB 스토리지를 최종 소스로 하는 티어드 캐시 아키텍처를 도입했습니다:

  • L1 캐시: GPU 호스트 메모리
  • L2 캐시: GPU 호스트 플래시
  • L3 캐시: 지역 내 분리된 플래시 스토리지 (TTL/LRU 정책)
# 데이터 로딩 파이프라인 예시 (티어드 캐시 적용)
class Dataloader:
    def __init__(self, l1_cache, l2_cache, l3_cache):
        self.l1 = l1_cache
        self.l2 = l2_cache
        self.l3 = l3_cache

    def prefetch(self, path):
        # 원격 데이터를 L3 캐시로 하이드레이션
        self.l3.hydrate(path)

    def load_batch(self, path):
        # L1 -> L2 -> L3 순으로 캐시 확인
        if path in self.l1:
            return self.l1[path]
        if path in self.l2:
            return self.l2[path]
        if path in self.l3:
            return self.l3[path]
        # L3에 없으면 글로벌 스토리지에서 읽음
        return self.read_global(path)

이 아키텍처는 데이터 수집 시간을 획기적으로 줄였습니다. 기존에는 지역 간 복사에 몇 시간이 걸렸지만, 이제는 온디맨드 하이드레이션과 프리페칭을 통해 몇 분 만에 데이터에 접근할 수 있습니다. 이는 특히 대규모 학습 작업보다는 작은 규모의 반복 실험이 많은 연구 환경에서 큰 이점을 제공합니다.

한국 개발 생태계에서의 적용 맥락

국내에서도 AI 학습 인프라를 운영하는 기업이 늘고 있습니다. 특히 네이버, 카카오, LG AI 등 대형 테크 기업들은 자체 GPU 클러스터를 보유하고 있는데, 이번 Meta의 사례는 다음과 같은 시사점을 줍니다:

  • 스토리지 아키텍처를 GPU 활용률 관점에서 재검토해야 합니다. GPU는 비싸지만 스토리지 병목으로 인해 실제 활용률이 낮아지는 경우가 많습니다.
  • 데이터 수집 파이프라인을 자동화하고, 티어드 캐싱을 도입하면 연구자들의 반복 작업 시간을 크게 줄일 수 있습니다.
  • 국내 클라우드 환경에서는 지역 간 데이터 이동 비용이 높기 때문에, 데이터를 GPU와 같은 지역에 배치하는 전략이 중요합니다.

이 기술의 한계 및 주의사항

  • 초기 구축 비용: 통합 메타데이터 스키마와 팻 클라이언트 SDK는 초기 개발 및 마이그레이션 비용이 큽니다. 기존 레거시 시스템을 운영 중이라면 점진적 전환이 필요합니다.
  • 캐시 일관성: 분산 캐시는 데이터 일관성 문제를 야기할 수 있습니다. 특히 데이터 업데이트가 빈번한 워크로드에서는 주의가 필요합니다.
  • 지역성 제약: L3 캐시는 지역 내에서만 동작하므로, 데이터가 여러 지역에 걸쳐 있을 때는 성능 저하가 발생할 수 있습니다.
  • 하드웨어 의존성: 플래시 스토리지와 고속 네트워크가 필수적이어서 인프라 비용이 증가할 수 있습니다.

다음 단계 학습 방향

Global BLOB storage architecture with regional deployment IT Technology Image

결론: 실무 적용을 위한 제언

Meta의 사례는 AI 시대에 스토리지가 단순한 데이터 저장소가 아니라 GPU 활용률과 연구 생산성을 좌우하는 핵심 인프라임을 보여줍니다. 기존 아키텍처의 가정이 바뀌었을 때 과감하게 재설계하는 것이 중요하며, 특히 다음과 같은 원칙을 기억하면 좋습니다:

  • 메타데이터 조회를 O(1)로 단순화하라.
  • 데이터플레인 프록시를 제거하고 클라이언트가 직접 데이터를 읽게 하라.
  • 티어드 캐싱과 프리페칭을 통해 지역 간 데이터 이동 비용을 줄여라.
  • 동적 동시성 제어로 스파이크와 꼬리 지연을 완화하라.

이러한 설계 원칙은 비단 하이퍼스케일러뿐 아니라, AI 인프라를 운영하는 모든 조직에 유용한 지침이 될 것입니다. 스토리지 병목을 해결하면 GPU 투자 대비 효율을 극대화할 수 있고, 연구자들은 데이터 이동에 시간을 낭비하지 않고 모델 튜닝에 집중할 수 있습니다.

함께 보면 좋은 글:

본 콘텐츠는 신뢰할 수 있는 출처를 바탕으로 AI 도구를 활용하여 초안이 작성되었으며, 편집자의 검토를 거쳐 발행되었습니다. 전문가의 조언을 대체하지 않습니다.