NetDrive S3 마운트 시 느린 디렉터리 목록 속도 해결하기

한 백엔드 팀이 CI 픽스처 파이프라인을 위해 Amazon S3 버킷을 NetDrive로 Windows 드라이브 문자에 마운트했습니다. 몇 달간 아무 문제 없이 작동하다가, 어느 리팩터링에서 단일 S3 프리픽스 아래에 4만 개의 새 테스트 픽스처 객체가 추가되었습니다. 다음 날 아침 빌드는 테스트 설정 중 픽스처 디렉터리가 탐색기에 표시되기를 기다리며 90초간 멈춰 버립니다. NetDrive가 멈춘 게 아닙니다. 그 디렉터리 하나를 나열하기 위해 순차적으로 40번의 S3 API 호출을 하고 있는 것입니다.

S3 버킷을 네이티브 Windows 또는 macOS 드라이브로 마운트하세요

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

• S3 버킷이 Windows에서 D:, E: 등 원하는 드라이브 문자로 표시됩니다
• 최초 마운트 이후 반복 접근 속도를 높이는 디렉터리 목록 캐시
• 업스트림 객체가 변경되면 특정 폴더만 강제로 새로고침

WindowsmacOS

NetDrive 다운로드 →

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

S3 목록 조회가 로컬 파일 시스템보다 느린 이유

S3는 계층형 파일 시스템이 아니라 객체 스토리지입니다. fixtures/integration/이라는 폴더처럼 보이는 것은 사실 공유 키 프리픽스, 즉 그 문자열로 시작하는 수천 개의 객체 키일 뿐입니다. 실제 디렉터리는 존재하지 않습니다. NetDrive(그리고 rclone, ExpanDrive를 포함한 모든 S3 마운트 도구)는 S3 ListObjectsV2 API를 호출해 디렉터리를 흉내 냅니다.

문제는 여기에 있습니다. ListObjectsV2 호출 한 번은 최대 1,000개의 객체만 반환합니다. 4만 개의 키를 가진 프리픽스를 전부 나열하려면 40번의 순차적 API 호출이 필요합니다. 같은 AWS 리전 내에서 왕복당 50ms(합리적인 수치)라고 해도, 탐색기에 첫 파일 이름이 표시되기 전까지 순수 API 오버헤드만 2초가 걸립니다. 기업 프록시를 거치거나 다른 리전으로 요청이 나갈 경우, 이 40번의 호출은 30~90초까지 늘어날 수 있습니다.

이것은 NetDrive의 버그가 아닙니다. S3 API 자체의 계약이며, aws s3 ls, rclone의 마운트 모드를 비롯해 대용량 S3 프리픽스를 나열하는 모든 도구에 동일하게 나타나는 현상입니다. 해결책은 두 곳에 있습니다. NetDrive가 디렉터리 목록을 캐시하는 방식, 그리고 버킷을 구조화하는 방식입니다.

NetDrive의 디렉터리 캐시가 반복 오버헤드를 줄이는 방법

대용량 프리픽스를 처음 나열한 후, NetDrive는 디렉터리 트리를 로컬에 캐시합니다. 이후 어떤 프로세스든 D:\fixtures\integration\으로 이동하면, NetDrive는 S3 API를 한 번도 호출하지 않고 캐시된 목록을 반환합니다. 이 캐시는 세션 간에도 유지됩니다. 콜드 부팅 후에도 이전 마운트에서 캐시가 여전히 남아 있으므로, 밤새 빌드 서버를 재시작했더라도 두 번째 실행의 목록 조회는 즉시 이루어집니다.

캐시 저장 용량은 최대 1TB까지 설정할 수 있습니다(NetDrive 3.16.589에서 도입). 수십 개의 프리픽스에 걸쳐 수십만 개의 객체가 분산된 버킷이라면, 캐시 공간을 더 할당할수록 CI 실행 사이에 더 많은 트리를 웜 상태로 유지할 수 있습니다. 이 설정은 Drive Manager 내 드라이브 설정에서 조정할 수 있습니다.

다만 이 방식에는 최신성이라는 트레이드오프가 따릅니다. 동료나 업스트림 파이프라인이 AWS 콘솔, 별도의 도구, 또는 다른 머신을 통해 S3에 직접 새 객체를 업로드하면, NetDrive의 캐시된 뷰는 캐시가 만료되거나 새로고침을 실행하기 전까지 그 변경 사항을 반영하지 않습니다. 특정 폴더를 새로고침하려면 Windows 탐색기에서 해당 폴더를 마우스 오른쪽 버튼으로 클릭한 뒤 Refresh를 선택하세요. NetDrive는 해당 프리픽스에 대해 ListObjectsV2 호출을 다시 실행하고, 캐시를 갱신한 후 최신 목록을 반환합니다.

목록 조회 오버헤드를 줄이는 버킷 구조 변경

다음 수정 사항들은 S3 버킷을 구성하는 방식 자체를 바꿔야 하지만, NetDrive뿐 아니라 그 버킷을 읽는 모든 도구에 이득이 됩니다.

깊은 프리픽스 계층을 평탄화하세요. 탐색하는 계층마다 각각의 목록 조회 호출이 발생합니다. fixtures/integration/service-a/env-staging/2026/05/처럼 6단계 깊이의 경로는 객체에 도달하기까지 최대 6번의 순차적 API 호출이 필요합니다. 이를 fixtures/integration/service-a-staging-2026-05/처럼 평탄화하면 같은 데이터를 단 한 번의 목록 조회 호출로 리프까지 도달할 수 있습니다.

카디널리티가 높은 프리픽스는 시간이나 카테고리로 분할하세요. 단일 logs/ 프리픽스가 2년치 일별 출력을 담은 8만 개의 객체를 갖고 있다면, logs/2025/와 logs/2026/으로 분할하세요. NetDrive가 logs/를 나열할 때는 단 한 번의 API 호출로 두 개의 하위 프리픽스를 확인합니다. 이후 logs/2026/으로 이동하면 그 해에 해당하는 호출이 한 번 더 발생할 뿐입니다.

핫 데이터와 콜드 데이터를 분리하세요. 자주 읽는 객체는 fixtures/active/처럼 범위가 한정된 프리픽스에 두고, 오래된 객체는 fixtures/archive/로 보관하세요. 전체 버킷을 마운트하지만 fixtures/active/만 읽는 CI 파이프라인은 빠르게 목록을 조회할 수 있으며, 콜드 아카이브는 캐시되지 않은 채 임계 경로 밖에 남습니다.

드라이브에 Root path를 설정하세요. NetDrive의 S3 연결 설정에서 Root path 필드를 사용하면 특정 프리픽스를 드라이브의 루트로 마운트할 수 있습니다. 이를 fixtures/active로 설정하면 NetDrive는 그 프리픽스를 D:\처럼 취급합니다. 마운트 세션 동안 버킷의 나머지 부분은 전혀 나열되지 않으며, 도구가 실제로 필요로 하는 경로만 조회됩니다.

엔드포인트 리전을 확인하세요. Drive Manager에서 S3 연결을 열어 리전이 버킷의 홈 리전과 일치하는지 확인하세요. 리전이 다르면 API 호출마다 50200ms가 추가됩니다. 40번의 페이지네이션 목록 조회 호출 전체로 보면, 콜드 디렉터리를 열 때마다 피할 수 있었던 28초의 네트워크 지연이 발생하는 셈입니다.

마무리

느린 S3 디렉터리 목록 조회는 거의 항상 NetDrive 설정 문제가 아니라 버킷 구조 문제입니다. S3 API의 호출당 1,000개 객체 제한은 고정되어 있으며, 여러분이 통제할 수 있는 것은 도구가 필요한 객체에 도달하기까지 몇 번의 호출이 필요한가입니다. 깊은 계층을 평탄화하고, 카디널리티가 높은 프리픽스를 분할하고, Root path를 설정해 마운트 범위를 좁히고, 디렉터리 캐시가 반복 조회를 즉시 처리하도록 두세요.

성능이 아니라 S3에서 권한 오류가 발생하는 팀이라면 Fix S3 Access Denied Error with NetDrive를 참고하세요. CI 파이프라인이 AWS S3 대신 Wasabi를 사용한다면 동일한 목록 조회 동작이 적용됩니다. Mount Wasabi on Windows with NetDrive를 참고하세요.

— Jay, NetDrive