CI 팀을 위한 S3 테스트 픽스처 — NetDrive로 Amazon S3를 드라이브로 마운트

한 백엔드 팀은 Amazon S3에 40GB 분량의 바이너리 테스트 픽스처를 저장합니다 — 데이터베이스 스냅샷, 사전 렌더링된 미디어 파일, 대용량 참조 데이터셋 등입니다. 이 팀의 통합 테스트 스위트는 이를 일반 파일 경로로 읽습니다. 픽스처가 바뀔 때마다 기존 워크플로는 늘 같았습니다. aws s3 cp로 각 CI 러너에 수 기가바이트를 내려받고, 파이프라인을 실행한 사람은 테스트가 시작되기까지 25분을 기다려야 했습니다. NetDrive로 S3 버킷을 로컬 드라이브로 마운트하면 이 복사 과정 자체가 사라집니다 — 테스트는 T:\fixtures\ 같은 경로를 통해 S3에서 바로 읽으며, 로컬 다운로드 단계가 없습니다.

S3를 드라이브 문자로 마운트 — 다운로드도, 코드 변경도 없이

NetDrive 는 Google Drive, OneDrive, S3, SFTP, WebDAV 등을 Windows 와 macOS 에서 일반 드라이브처럼 보이게 합니다 — 동기화도, 전체 다운로드도 없이.

• 파일 경로를 읽는 모든 앱이 자동으로 동작합니다
• 부팅 시 자동 마운트로 로그인 전부터 드라이브가 준비됩니다
• Wasabi와 MinIO도 Amazon S3와 동일한 방식으로 동작합니다

WindowsmacOS

NetDrive 다운로드 →

무료 체험. 평생 라이선스와 구독 플랜 제공.

CI에서 파일 경로 호환성이 중요한 이유

대부분의 테스트 스위트는 픽스처를 로컬 경로에서 읽도록 작성되어 있습니다. 모든 픽스처 참조를 S3 URL로 바꾸려면 수십 개 파일을 손대야 하고, 로컬 개발 환경 경험까지 망가질 수 있습니다. 더 깔끔한 해법은 S3를 로컬 드라이브처럼 보이게 만들어 기존 경로가 수정 없이 그대로 동작하게 하는 것입니다.

NetDrive는 S3 버킷을 CI 러너의 필요에 따라 네트워크 드라이브, 읽기 전용 드라이브, 또는 로컬 디스크 볼륨으로 마운트합니다. Windows에서는 드라이브 문자(T:, S: 등)로 나타나 머신의 모든 프로세스가 읽을 수 있습니다. macOS에서는 /Volumes/ 아래나 사용자 지정 경로에 FUSE 볼륨으로 나타납니다. 테스트 스위트에는 파일 시스템으로 보이고, S3 API 호출은 NetDrive가 뒤에서 처리합니다.

대용량 픽스처 파일도 안정적으로 동작합니다. NetDrive가 데이터를 청크 단위로 스트리밍하고 네트워크 순간 장애 시 자동으로 재시도하기 때문입니다. 5GB를 넘는 파일은 S3 멀티파트 전송(NetDrive 3.5.434부터 지원)을 사용하므로, 픽스처 크기에 실질적인 상한이 없습니다.

S3 버킷을 드라이브로 설정하기

1. Open NetDrive를 실행하고 Drive Manager에서 + Add Drive를 클릭합니다.
2. 공급자 목록에서 Amazon S3를 선택합니다.
3. AWS Access Key ID와 Secret Access Key를 입력합니다. 최소 권한 원칙에 따른 전용 IAM 역할을 사용하세요 — 픽스처 버킷은 읽기 전용으로, 테스트가 산출물을 만드는 곳만 쓰기 권한을 부여합니다.
4. Bucket Name을 입력합니다. NetDrive 3.19.7부터는 버킷 설정에서 리전이 자동으로 감지되므로, 재정의가 필요한 경우가 아니라면 리전 필드는 비워둬도 됩니다.
5. Drive Type에서 표준 읽기/쓰기 마운트라면 Network drive를, CI 러너가 픽스처 버킷에 절대 다시 쓰지 않아야 한다면 Read-only drive를 선택합니다.
6. Mount on을 Boot로 설정합니다 — 개발자 워크스테이션 설정과 갈라지는 핵심 지점입니다. 부팅 시 마운트를 설정하면 사용자가 로그인하기 전부터 드라이브를 사용할 수 있으며, 이는 헤드리스 CI 서버가 정확히 필요로 하는 방식입니다.
7. Mount를 클릭합니다.

이제 사용자 세션이 없어도 드라이브 문자(Windows)나 볼륨 경로(macOS)를 CI 에이전트를 포함한 머신의 모든 프로세스가 사용할 수 있습니다.

로그인 없는 자동 마운트 — 헤드리스 CI 서버 구성

Mount on Boot 옵션이야말로 NetDrive를 CI 인프라에서 실용적으로 만드는 요소입니다. 대부분의 CI 러너(Jenkins 에이전트, GitHub Actions 셀프 호스트 러너, GitLab 에이전트)는 사용자 세션이 아니라 시스템 서비스로 시작됩니다. 사용자 로그인 시에만 마운트되는 드라이브는 이런 에이전트에게는 보이지 않습니다.

부팅 시 마운트를 활성화하면 OS 부팅이 끝나는 즉시 S3 드라이브가 준비됩니다. CI 에이전트는 이를 자동으로 인식합니다 — 로그인도, 마운트 명령을 실행할 스크립트도, 에이전트 시작과 드라이브 등장 사이의 경쟁 조건도 필요 없습니다.

마운트를 프로그래밍 방식으로 처리해야 하는 경우 — 예를 들어 브랜치 이름이나 파이프라인 변수에 따라 어떤 버킷을 마운트할지 동적으로 결정해야 하는 경우 — NetDrive에는 스크립트로 드라이브를 관리할 수 있는 명령줄 도구 nd3cmd가 포함되어 있으며, NetDrive 3.8.921에서 추가되었습니다. 정확한 플래그는 버전마다 다르므로 최신 nd3cmd 명령 레퍼런스는 NetDrive 지원 포럼을 참고하세요.

테스트가 산출물(커버리지 리포트, 렌더링 결과물, 벤치마크 결과 등)을 만들어낼 때도 같은 마운트된 드라이브가 쓰기 작업에 사용됩니다. NetDrive의 background upload 모드는 먼저 로컬 캐시에 쓴 뒤 비동기적으로 S3에 업로드하므로, 테스트 프로세스가 업로드 완료를 기다리며 멈추지 않습니다.

온프레미스 S3: MinIO와 Wasabi

모든 팀이 AWS를 직접 쓰는 것은 아닙니다. 픽스처 데이터를 퍼블릭 클라우드 밖에 두려고 온프레미스에서 MinIO를 운영하는 팀도 있고, 비용 최적화를 위해 콜드 스토리지로 Wasabi를 쓰는 팀도 있습니다. NetDrive는 3.4.398부터 S3 호환 스토리지 공급자를 지원하며, 3.15.450에서 MinIO 지원을 명시적으로 추가했습니다.

S3 호환 엔드포인트를 연결하려면:

1. + Add Drive를 클릭하고 (Amazon S3가 아닌) S3 Compatible을 선택합니다.
2. MinIO 클러스터나 Wasabi 리전 엔드포인트의 커스텀 엔드포인트 URL을 입력합니다.
3. 이전과 동일하게 버킷 이름과 자격 증명을 입력합니다.
4. 드라이브 타입과 마운트 트리거도 동일한 방식으로 설정합니다.

나머지 설정 과정은 동일합니다. 테스트 스위트 입장에서 T:\fixtures\는 백엔드 스토리지가 AWS us-east-1이든, Wasabi 버킷이든, CI 러너와 같은 데이터센터에서 돌아가는 MinIO 클러스터든 똑같이 T:\fixtures\일 뿐입니다.

마무리

S3를 드라이브 문자로 마운트하는 것은 오브젝트 스토리지에 저장된 대용량 픽스처 라이브러리에 CI 파이프라인이 접근하도록 만드는, 코드 변경이 전혀 없는 방법입니다. 테스트 스위트는 계속 로컬 경로를 읽고, S3 변환은 NetDrive가 처리합니다. 부팅 시 마운트 덕분에 수동 개입 없이도 CI 에이전트가 필요로 할 때 드라이브가 항상 그 자리에 있습니다.

개발자용 Mac에서 S3 접근을 설정하는 방법은 NetDrive로 macOS에서 Amazon S3 마운트하기를 참고하세요. 오래된 픽스처를 위한 비용 효율적인 콜드 스토리지 계층도 필요하다면, NetDrive로 Windows에서 Backblaze B2 마운트하기에서 Backblaze의 S3 호환 API를 활용한 비슷한 구성을 다룹니다.

— Alex, NetDrive