GPU 학습 데이터는 어떻게 연결할까? ENV·MOUNT·FUSE·COPY 비교와 실무 예제

GPU 서버에 AI 학습 환경을 구성했다면 다음으로 고민해야 할 것은 학습 데이터와 모델 결과물을 어디에 저장하고, 학습 작업(Job)에서 어떻게 접근할 것인가입니다.

데이터셋이 Amazon S3에 있을 수도 있고, 연구실 NAS에 저장돼 있을 수도 있습니다. 학습이 끝난 뒤 모델 체크포인트가 남아야 하는데, 컨테이너의 임시 경로에만 저장했다면 작업 종료 후 파일을 찾지 못할 수도 있습니다.

결론부터 말하면, 저장소에 접근하는 방법은 크게 환경변수(ENV)를 통한 설정·인증 정보 전달, 파일 시스템 마운트(MOUNT), FUSE 기반 오브젝트 스토리지 마운트, 데이터 복사(COPY·stage-in/stage-out)로 이해할 수 있습니다. 다만 이 네 가지는 기술적으로 완전히 같은 계층의 대안은 아닙니다. ENV는 연결에 필요한 설정을 전달하는 수단이고, FUSE는 마운트를 구현하는 기술 중 하나입니다. 실제 시스템에서는 이 방식들을 함께 사용하기도 합니다.

이 글에서는 각 방식이 어디서 데이터를 읽고, 누가 전송을 수행하며, 어떤 조건에서 유리한지를 코드와 운영 사례로 설명합니다.

1. GPU 학습 데이터 연결을 이해하기 위한 기본 개념

1-1. 파일 스토리지와 오브젝트 스토리지는 어떻게 다른가?

AI 학습 환경에서 자주 사용하는 저장소는 파일 스토리지와 오브젝트 스토리지로 구분할 수 있습니다.

S3에서 images/train.jpg는 실제 중첩 디렉터리 구조가 아니라 오브젝트 키(key)입니다. /가 포함된 키를 사용자 인터페이스에서 폴더처럼 표시하는 것입니다. 그래서 일반 리눅스 파일 시스템과 동일한 방식으로 접근하려면 별도 계층이 필요합니다.

1-2. 컨테이너 내부 경로가 항상 영구 저장소는 아니다

Kubernetes나 컨테이너 기반 GPU 플랫폼에서 Job을 실행할 때는 컨테이너의 쓰기 가능 계층, Pod 임시 볼륨, 영구 볼륨을 구분해야 합니다.

• 컨테이너 쓰기 가능 계층: 컨테이너 재생성·삭제 시 데이터가 보존된다고 가정하면 안 됩니다.
• emptyDir 볼륨: 같은 Pod 내에서는 컨테이너가 재시작돼도 파일이 남을 수 있지만, Pod가 노드에서 제거되면 데이터가 삭제됩니다.
• PersistentVolumeClaim(PVC) 등 영구 볼륨: 저장소와 회수 정책이 적절히 구성되어 있다면 Pod가 종료된 뒤에도 데이터를 유지할 수 있습니다.
• S3 등 외부 저장소: 업로드가 정상 완료된 오브젝트는 Job 수명주기와 독립적으로 관리됩니다.

따라서 /output/model.pt라는 경로에 저장했다는 사실만으로 결과가 영구 보관되는 것은 아닙니다. /output이 어떤 볼륨에 연결돼 있는지를 확인해야 합니다.

1-3. 마운트란 무엇인가?

마운트(Mount)는 파일 시스템을 특정 디렉터리에 연결해, 프로그램이 그 경로를 통해 파일에 접근하도록 하는 운영체제 기능입니다. 예를 들어 NAS가 /mnt/datasets에 마운트되어 있다면 학습 코드는 일반 로컬 경로를 읽듯이 데이터를 읽을 수 있습니다. 다만 경로가 로컬처럼 보이는 것과 실제 I/O가 로컬 디스크에서 처리되는 것은 다릅니다. NFS나 FUSE로 연결된 데이터는 읽는 과정에서 네트워크 통신이 발생할 수 있습니다.

2. ENV: 환경변수로 저장소 연결 설정과 인증 정보를 전달하는 방식

ENV는 실제로 무엇을 하는가?

ENV(Environment Variables)는 실행 중인 프로세스에 설정값을 전달하는 방법입니다. S3를 사용하는 경우 버킷 이름, 리전, 엔드포인트, 인증 관련 설정을 환경변수로 전달할 수 있습니다. 여기서 중요한 점은 환경변수를 설정하는 것만으로 S3가 /data 폴더에 마운트되거나 데이터가 자동으로 다운로드되지는 않는다는 것입니다. 애플리케이션이 AWS SDK, S3 호환 API 또는 CLI를 사용해 데이터를 직접 읽고 써야 합니다.

데이터 흐름

GPU Job 시작
    ├─ 환경변수·워크로드 자격 증명으로 접속 정보 확보
    └─ 학습 코드(Boto3 등)가 S3 API 호출
           ├─ 입력 데이터 다운로드 또는 스트리밍
           └─ 학습 결과 업로드

GPU Job 시작
    ├─ 환경변수·워크로드 자격 증명으로 접속 정보 확보
    └─ 학습 코드(Boto3 등)가 S3 API 호출
           ├─ 입력 데이터 다운로드 또는 스트리밍
           └─ 학습 결과 업로드

Python Boto3로 S3 파일 읽고 업로드하기

아래는 S3에서 학습 데이터를 가져오고 결과 파일을 업로드하는 예시입니다. 코드에 Access Key를 직접 작성하지 않습니다.

from pathlib import Path
import boto3

input_dir = Path("/workspace/data")
input_dir.mkdir(parents=True, exist_ok=True)

s3 = boto3.client("s3")  # IAM 역할 또는 설정된 자격 증명 체인 활용

# 학습 입력 파일 다운로드
s3.download_file(
    "ml-datasets", "training/train.csv", str(input_dir / "train.csv")
)

# 실제 학습은 별도 코드에서 수행한다고 가정
# train_model(input_dir / "train.csv", "/workspace/output/model.pt")

# 학습이 완료되어 결과 파일이 존재할 때 업로드
s3.upload_file(
    "/workspace/output/model.pt", "ml-results", "runs/exp01/model.pt"
)

from pathlib import Path
import boto3

input_dir = Path("/workspace/data")
input_dir.mkdir(parents=True, exist_ok=True)

s3 = boto3.client("s3")  # IAM 역할 또는 설정된 자격 증명 체인 활용

# 학습 입력 파일 다운로드
s3.download_file(
    "ml-datasets", "training/train.csv", str(input_dir / "train.csv")
)

# 실제 학습은 별도 코드에서 수행한다고 가정
# train_model(input_dir / "train.csv", "/workspace/output/model.pt")

# 학습이 완료되어 결과 파일이 존재할 때 업로드
s3.upload_file(
    "/workspace/output/model.pt", "ml-results", "runs/exp01/model.pt"
)

Boto3는 환경변수의 AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, 임시 자격 증명을 위한 AWS_SESSION_TOKEN 등을 읽을 수 있습니다. 그러나 환경변수가 유일한 인증 방법은 아닙니다. IAM 역할이나 워크로드 아이덴티티로 단기 자격 증명을 제공하는 방식을 우선 고려하는 것이 좋습니다.

ENV 방식이 적합한 경우와 주의할 점

• 적합: 기존 코드가 SDK로 S3를 읽거나, Hugging Face 토큰·W&B API 키·사용자 지정 엔드포인트처럼 실행 시점 설정이 필요한 경우
• 장점: 컨테이너 내부에 별도 파일 시스템을 마운트하지 않고 애플리케이션에서 데이터 접근과 오류 처리를 제어할 수 있음
• 주의: 코드가 파일 경로를 전제로 작성됐다면 다운로드 또는 별도의 데이터 로더 구현이 필요할 수 있음
• 보안: 인증 정보를 코드, 이미지, Git 저장소, 로그에 남기지 않고 최소 권한·단기 자격 증명·전용 Secret 관리 기능을 사용해야 함

정리하면 ENV는 ‘스토리지 종류’나 ‘데이터 전송 프로토콜’이 아니라, 연결 설정을 애플리케이션에 전달하는 방법입니다. 따라서 뒤에서 설명할 COPY나 FUSE와 함께 사용할 수도 있습니다.

3. MOUNT: NAS·공유 파일 시스템을 GPU Job의 디렉터리로 연결하는 방식

MOUNT는 원격 파일 시스템을 호스트 또는 컨테이너에 연결하는 방법입니다. 연구실 NAS, NFS 서버, Lustre나 EFS 같은 공유 파일 시스템을 여러 GPU 작업에서 접근해야 할 때 유용합니다.

데이터 흐름

NAS / NFS 서버
   ↓ (NFS 등 파일 시스템 프로토콜)
GPU 노드의 마운트 지점 또는 스토리지 드라이버
   ↓ (볼륨 연결)
GPU Job 컨테이너의 /data
   ↓
학습 코드가 /data/train.csv 읽기

NAS / NFS 서버
   ↓ (NFS 등 파일 시스템 프로토콜)
GPU 노드의 마운트 지점 또는 스토리지 드라이버
   ↓ (볼륨 연결)
GPU Job 컨테이너의 /data
   ↓
학습 코드가 /data/train.csv 읽기

리눅스 NFS 마운트 예시

다음은 접속 권한과 네트워크가 사전에 구성됐다는 전제의 예시입니다.

sudo mkdir -p /mnt/datasets
sudo mount -t nfs4 -o ro 10.20.30.40:/datasets /mnt/datasets

# 마운트 확인
findmnt /mnt/datasets
ls -lah /mnt/datasets

sudo mkdir -p /mnt/datasets
sudo mount -t nfs4 -o ro 10.20.30.40:/datasets /mnt/datasets

# 마운트 확인
findmnt /mnt/datasets
ls -lah /mnt/datasets

• -t nfs4: NFSv4 파일 시스템으로 연결
• -o ro: 읽기 전용으로 마운트해 원본 데이터 변경을 방지
• 10.20.30.40:/datasets: NAS/NFS 서버와 내보내기(export) 경로의 예시
• /mnt/datasets: GPU 서버에서 접근할 경로

NFS 서버의 export 설정, 접근 제어, 클라이언트 권한에 따라 실제 연결 명령은 달라질 수 있습니다. ro 옵션만으로 모든 보안 요구사항이 충족되는 것은 아니므로 서버 측 권한도 함께 관리해야 합니다.

Kubernetes에서는 PVC를 통해 연결할 수 있다

Kubernetes에서는 PersistentVolume(PV), PersistentVolumeClaim(PVC), 스토리지 드라이버(CSI 등)를 통해 스토리지를 Pod에 연결합니다. 아래는 이미 생성된 training-dataset-pvc를 Pod에서 사용하는 부분만 발췌한 YAML입니다.

spec:
  containers:
    - name: trainer
      image: example/training:latest
      volumeMounts:
        - name: training-dataset
          mountPath: /data
          readOnly: true
  volumes:
    - name: training-dataset
      persistentVolumeClaim:
        claimName: training-dataset-pvc

spec:
  containers:
    - name: trainer
      image: example/training:latest
      volumeMounts:
        - name: training-dataset
          mountPath: /data
          readOnly: true
  volumes:
    - name: training-dataset
      persistentVolumeClaim:
        claimName: training-dataset-pvc

PVC가 실제 NFS, 클라우드 파일 스토리지 또는 다른 스토리지에 연결되는 방식은 클러스터 설정에 따라 달라집니다. 이 예시는 단독으로 배포할 수 있는 완전한 Job 매니페스트가 아닙니다.

연결 후 학습 코드는 다음처럼 파일 경로만 사용합니다.

import pandas as pd

df = pd.read_csv("/data/train.csv")

import pandas as pd

df = pd.read_csv("/data/train.csv")

MOUNT의 장점과 제약

• 장점: 기존 파일 경로 기반 코드를 유지하기 쉽고, 여러 작업이 공유 데이터셋에 접근 가능
• 장점: 읽기 전용 입력 볼륨과 별도의 쓰기 가능 출력 볼륨을 분리할 수 있음
• 제약: GPU 노드에서 저장소까지 네트워크 라우팅, 포트, 권한, 스토리지 클라이언트 설정이 필요
• 제약: 성능은 네트워크 대역폭과 지연 시간, NAS 서버 성능, 파일 크기 및 동시 접속 수에 따라 달라짐
• 운영 포인트: 동시에 쓰는 작업은 작업별 출력 디렉터리를 분리하고, 공유 볼륨의 접근 모드와 권한을 검토

MOUNT가 무조건 빠르다고 볼 수는 없습니다. 잘 구성된 고성능 병렬 파일 시스템은 높은 처리량을 제공하지만, 부하가 집중된 일반 NAS에서는 스토리지 I/O가 GPU 학습의 병목이 될 수 있습니다.

4. FUSE: S3 같은 오브젝트 스토리지를 파일 경로로 접근하는 방식

FUSE(Filesystem in Userspace)는 사용자 공간에서 파일 시스템을 구현하는 기술입니다. S3는 기본적으로 오브젝트 API로 접근하지만, FUSE 기반 클라이언트를 사용하면 학습 프로그램이 파일 경로로 데이터를 읽도록 구성할 수 있습니다. 즉, FUSE도 마운트의 한 형태입니다. 앞 절의 NFS MOUNT와 구분되는 핵심은 연결 대상과 내부 구현 방식입니다.

데이터 흐름

학습 코드: open("/data/train.csv")
   ↓
운영체제 파일 I/O 요청
   ↓
FUSE 클라이언트(Mountpoint for Amazon S3 등)
   ↓
S3 API 요청(GetObject 등)
   ↓
오브젝트 데이터를 파일처럼 읽기

학습 코드: open("/data/train.csv")
   ↓
운영체제 파일 I/O 요청
   ↓
FUSE 클라이언트(Mountpoint for Amazon S3 등)
   ↓
S3 API 요청(GetObject 등)
   ↓
오브젝트 데이터를 파일처럼 읽기

Mountpoint for Amazon S3 예시

Mountpoint for Amazon S3가 설치돼 있고 적절한 IAM 권한과 네트워크 접근이 준비돼 있다는 전제입니다.

mkdir -p /mnt/s3-datasets
mount-s3 ml-datasets /mnt/s3-datasets --read-only

# S3 오브젝트를 파일 경로로 조회
ls -lah /mnt/s3-datasets

mkdir -p /mnt/s3-datasets
mount-s3 ml-datasets /mnt/s3-datasets --read-only

# S3 오브젝트를 파일 경로로 조회
ls -lah /mnt/s3-datasets

--read-only는 해당 마운트에서 데이터 변경 작업을 제한합니다. 실제 GPU 플랫폼에서는 사용자 컨테이너 내부에서 직접 FUSE 마운트를 실행하기보다, 관리형 CSI 드라이버 또는 사전에 구성된 마운트를 제공할 수 있습니다. 이때 필요한 권한과 노드 설정은 플랫폼마다 다릅니다.

대표 도구로는 Mountpoint for Amazon S3, gcsfuse, blobfuse2, rclone mount 등이 있습니다.

FUSE 사용 전 확인할 제약 사항

S3 기반 파일 경로는 일반적인 POSIX 파일 시스템과 완전히 같지 않습니다. 예를 들어 Mountpoint for Amazon S3는 기존 파일 수정, 이름 변경, 디렉터리 삭제, 파일 잠금 등의 동작에 제약이 있습니다. 일부 동작은 버킷 종류·스토리지 클래스·실행 옵션에 따라 달라집니다.

또한 FUSE가 항상 느린 것은 아닙니다. 큰 파일을 순차적으로 읽는 작업에서는 높은 처리량을 확보할 수 있지만, 작은 파일을 매우 자주 열거나 임의 접근을 반복하는 학습 패턴에서는 요청 지연과 캐시 동작이 성능에 영향을 줍니다.

가령 이미지 파일이 수십만 개인 학습에서는 각 파일을 열 때 발생하는 메타데이터 조회와 읽기 요청의 누적 비용이 문제일 수 있습니다. 이런 경우 WebDataset(tar 기반 샤드), TFRecord 등의 묶음 형식, 로컬 캐시, 데이터 로더 최적화, COPY 방식을 함께 검토하는 것이 좋습니다. 파일을 묶으면 모든 요청이 정확히 파일 수만큼 줄어드는 것은 아니지만, 작은 파일로 인한 오버헤드를 줄이는 데 도움이 될 수 있습니다.

5. COPY: 학습 전 데이터 다운로드, 학습 후 결과 업로드하는 방식

COPY는 데이터를 실행 전에 복사하고(stage-in), 처리 결과를 실행 후에 외부 저장소로 내보내는(stage-out) 구성입니다. 학습 중에는 원격 저장소를 매번 읽지 않고 준비된 로컬 또는 고속 임시 볼륨을 사용하도록 설계할 수 있습니다.

데이터 흐름

S3의 training/ 데이터
   ↓ stage-in: 작업 시작 전 복사
/scratch/input
   ↓ GPU 모델 학습
/scratch/output
   ↓ stage-out: 결과 업로드
S3의 runs/exp01/

S3의 training/ 데이터
   ↓ stage-in: 작업 시작 전 복사
/scratch/input
   ↓ GPU 모델 학습
/scratch/output
   ↓ stage-out: 결과 업로드
S3의 runs/exp01/

rclone으로 stage-in/stage-out 구현하기

아래 명령은 rclone 설치와 mys3라는 원격 저장소 설정을 마친 환경을 가정합니다.

set -euo pipefail

mkdir -p /scratch/input /scratch/output

# 1. S3 → 작업 디스크로 입력 데이터 복사
rclone copy mys3:ml-datasets/training /scratch/input --progress

# 2. 로컬 경로를 사용해 학습
python train.py --data /scratch/input --output /scratch/output

# 3. 작업 결과 → S3에 업로드
rclone copy /scratch/output mys3:ml-results/runs/exp01 --progress

set -euo pipefail

mkdir -p /scratch/input /scratch/output

# 1. S3 → 작업 디스크로 입력 데이터 복사
rclone copy mys3:ml-datasets/training /scratch/input --progress

# 2. 로컬 경로를 사용해 학습
python train.py --data /scratch/input --output /scratch/output

# 3. 작업 결과 → S3에 업로드
rclone copy /scratch/output mys3:ml-results/runs/exp01 --progress

rclone copy는 원본에서 대상으로 파일을 복사하며, 기본적으로 목적지에만 존재하는 파일을 모두 삭제하는 sync와는 동작이 다릅니다. 특히 운영 데이터에서는 sync의 삭제 동작을 이해하지 못한 채 사용하지 않도록 주의해야 합니다.

COPY의 장점과 반드시 설계해야 할 부분

• 장점: 학습 중 반복적인 원격 읽기를 줄여 로컬 디스크 또는 캐시의 성능을 활용할 수 있음
• 장점: 데이터 접근 코드를 경로 기반으로 유지할 수 있고, 원격 저장소에 대한 요청 패턴을 단순화할 수 있음
• 제약: 최초 다운로드 시간, 필요한 디스크 여유 공간, 추가 데이터 복사 비용 발생
• 제약: 학습 데이터가 로컬 디스크보다 크거나 변경이 매우 잦다면 관리 비용이 커질 수 있음
• 운영 포인트: 복사 실패 시 재시도, 무결성 확인, 이전 결과와의 충돌, 작업별 경로 분리 등을 설계해야 함

가장 중요한 문제는 학습 실패 시 결과를 어떻게 회수할 것인가입니다. 위의 간단한 스크립트는 python train.py가 실패하면 set -e 때문에 뒤의 업로드 단계가 실행되지 않습니다. 따라서 운영 환경에서는 실패 시에도 가능한 범위에서 체크포인트·로그를 업로드하도록 작업 컨트롤러의 종료 처리, 셸 종료 훅(trap), 별도 업로드 프로세스, 주기적 체크포인트 업로드 등을 구성해야 합니다.

단, 강제 종료나 노드 장애가 발생하면 종료 훅이 실행되지 않을 수 있습니다. 그러므로 ‘실패해도 무조건 업로드된다’고 보장해서는 안 됩니다. 중요한 체크포인트는 작업 진행 중에도 영구 저장소에 주기적으로 남기는 편이 안전합니다.

6. ENV·MOUNT·FUSE·COPY 차이 한눈에 비교

‘어느 방식이 가장 빠른가?’의 정답은 하나가 아닙니다. 데이터셋 크기와 파일 개수, 읽기 패턴, 네트워크 속도, 캐시, GPU 학습 시간, 스토리지 서버 구성에 따라 결과가 달라집니다. 실제 워크로드로 데이터 로딩 시간·GPU 사용률·처리량·단계별 실패율을 측정해야 합니다.

7. 실제 GPU 인프라에서는 어떻게 구성할까?

사례 1. 사내 GPU 서버와 연구실 NAS

같은 네트워크에 GPU 서버와 NAS가 있다면, 공용 데이터셋은 NFS/PVC를 읽기 전용으로 연결하고 결과물은 별도의 쓰기 가능 영구 볼륨에 기록하는 구성이 단순합니다. 작업별 출력 디렉터리를 나눠 덮어쓰기를 방지하고, NAS 성능을 모니터링합니다.

사례 2. 외부 클라우드 GPU와 S3

학습 코드가 S3 SDK를 지원하면 API 기반 접근으로 시작할 수 있습니다. 데이터셋을 반복해서 읽고 작업 디스크에 충분한 공간이 있다면 COPY(stage-in)를 검토합니다. 전체 데이터 다운로드가 비효율적이거나 일부 파일만 필요하고, 파일 API가 필요하다면 FUSE 기반 마운트를 고려할 수 있습니다.

사례 3. 작은 이미지 파일이 매우 많은 학습

이 경우 저장소 연결 방식만 바꿔서는 충분하지 않을 수 있습니다. 데이터 로더의 병렬 처리 수, 전처리 비용, 파일 형식, 캐시 활용 여부도 중요합니다. 가능하다면 WebDataset 또는 TFRecord 같은 샤드 구성과 고성능 공유 스토리지, 사전 복사를 비교 테스트합니다.

사례 4. 관리형 AI 학습 서비스

Amazon SageMaker AI는 학습 데이터 입력 방식으로 File, FastFile, Pipe 모드 등을 제공합니다. File 모드는 학습 전에 데이터를 로컬에 준비하는 COPY와 유사한 패턴이고, FastFile은 S3 데이터를 파일 경로로 스트리밍한다는 점에서 FUSE 접근과 목적이 비슷합니다. 다만 SageMaker의 내부 구현과 FUSE를 동일한 기술로 단정해서는 안 됩니다. 파일 시스템을 통한 접근이 필요하면 EFS나 FSx for Lustre 같은 서비스도 검토할 수 있습니다.

8. GPU 학습 저장소 연결이 실패하거나 느릴 때 점검할 것

운영 전 체크리스트

1. 데이터 위치와 규모: NAS인지 S3인지, 총용량·파일 개수·평균 파일 크기는 얼마인가?
2. 접근 패턴: 전체 데이터를 반복적으로 읽는지, 큰 파일을 순차적으로 읽는지, 임의 접근이 많은지?
3. 네트워크: GPU 노드에서 저장소에 접근 가능한지, 대역폭과 지연 시간은 적절한지?
4. 권한 관리: 원본은 읽기 전용인지, 결과 경로만 쓰기 가능한지, Secret이나 역할 기반 인증을 사용하는지?
5. 데이터 영속성: 입력 캐시와 출력 영구 저장소가 구분돼 있는지?
6. 장애 대응: 학습 실패·Pod 삭제·노드 장애 때 체크포인트와 로그가 남는지?
7. 운영 비용: 데이터 전송, API 요청, 로컬 디스크, 공유 스토리지 사용 비용은 적절한지?
8. 검증: 실제 학습 Job에서 로딩 시간·GPU 사용률·I/O 처리량을 비교했는지?

9. 자주 묻는 질문(FAQ)

Q1. S3에 있는 데이터를 GPU 학습 코드에서 바로 읽을 수 있나요?

가능합니다. Boto3 같은 SDK로 S3 API를 호출하거나, Mountpoint for Amazon S3 등으로 파일 경로를 제공하거나, 학습 전에 로컬 디스크로 복사할 수 있습니다. 기존 코드가 파일 경로를 사용하는지, 데이터 크기가 어느 정도인지에 따라 선택이 달라집니다.

Q2. 환경변수(ENV)를 등록하면 S3가 자동으로 마운트되나요?

아닙니다. 환경변수는 접속 설정과 인증 정보를 전달할 뿐입니다. S3에서 데이터를 읽으려면 코드가 SDK·CLI를 사용하거나, 별도로 FUSE 같은 마운트 계층을 구성해야 합니다.

Q3. NFS MOUNT와 FUSE MOUNT의 차이는 무엇인가요?

NFS는 네트워크 파일 시스템 프로토콜을 이용해 공유 파일 시스템에 접근하는 방식입니다. FUSE는 사용자 공간에서 파일 시스템을 구현하는 기술이며, S3처럼 원래 파일 시스템이 아닌 저장소를 파일 경로로 표시하는 데 활용할 수 있습니다. 둘 다 프로그램에서는 마운트된 경로로 보일 수 있지만 내부 I/O 동작과 제약 사항이 다릅니다.

Q4. FUSE로 연결한 S3는 NAS처럼 자유롭게 파일을 수정할 수 있나요?

항상 그렇지는 않습니다. 예를 들어 Mountpoint for Amazon S3는 전체 POSIX 기능을 구현하지 않으며 기존 파일 변경, 이름 변경, 잠금 등에서 제한이 있습니다. 사용하는 클라이언트와 버킷 종류, 옵션에 맞춰 지원 기능을 확인해야 합니다.

Q5. GPU 학습에서는 COPY가 가장 빠른가요?

학습 중 로컬 디스크 I/O만 필요하도록 구성할 수 있다는 장점은 있지만, 전체 소요 시간이 반드시 가장 짧은 것은 아닙니다. 데이터 다운로드에 오래 걸리거나 저장 공간이 부족하면 비효율적입니다. 데이터 규모·반복 학습 횟수·스토리지 성능에 따라 MOUNT나 스트리밍 방식이 유리할 수 있습니다.

Q6. Kubernetes Job이 끝나면 학습 결과는 모두 삭제되나요?

그렇지 않습니다. 어느 볼륨에 저장했는지에 따라 달라집니다. 컨테이너 임시 저장소나 emptyDir에만 기록했다면 Pod 삭제 후 데이터가 사라질 수 있습니다. PVC 등 영구 볼륨에 기록했거나 S3 업로드를 완료했다면 해당 저장소의 보존 정책에 따라 유지됩니다.

Q7. ENV, MOUNT, FUSE, COPY를 함께 사용해도 되나요?

가능하며 실제로 흔한 구성입니다. 예를 들어 데이터셋은 NFS로 읽기 전용 MOUNT, 외부 모델 다운로드에는 환경변수 기반 인증, 학습 결과물은 rclone COPY로 S3 업로드하는 식으로 조합할 수 있습니다.

마무리: 연결 방식보다 중요한 것은 데이터 수명주기다

GPU 학습 스토리지 설계에서는 ‘어떤 기술을 사용하느냐’만큼 데이터가 언제 읽히고, 어디에서 처리되며, 작업 종료 후 어디에 남는지가 중요합니다.

• ENV: 애플리케이션에 저장소 접속 설정과 인증 정보를 전달합니다.
• MOUNT: NAS 등의 공유 파일 시스템을 GPU 작업의 디렉터리로 연결합니다.
• FUSE: S3 같은 오브젝트 스토리지를 파일 경로로 접근하도록 구현합니다.
• COPY: 학습 전 데이터를 준비하고 학습 후 결과를 외부 저장소에 복사합니다.

가장 실용적인 접근은 데이터 위치, 읽기 패턴, 저장 공간, 영속성 요구사항을 먼저 정리한 다음 실제 GPU 학습으로 성능을 검증하는 것입니다. 초기에 입력 데이터와 결과 저장 경로를 분리해 두면, 나중에 저장소를 교체하거나 클라우드 환경으로 이전할 때도 운영 부담을 줄일 수 있습니다.

공식 문서 및 참고 자료

• AWS — Boto3 자격 증명 설정
• AWS — S3 오브젝트 키와 접두사
• AWS — Mountpoint for Amazon S3
• AWS — Mountpoint 파일 시스템 동작 및 제한
• AWS — SageMaker 학습 데이터 입력 방식 선택
• Kubernetes — Volumes
• Kubernetes — Secrets
• rclone — 공식 명령어 문서