Windows 11 Dev Drive, ReFS와 보안 필터를 함께 봐야 하는 이유

AI를 활용하여 생성한 이미지입니다.

개발용 SSD를 하나 더 샀다고 해서 빌드와 패키지 설치가 자동으로 빨라지는 것은 아닙니다. Windows 11의 Dev Drive는 이름만 다른 폴더가 아니라 개발 작업을 염두에 둔 ReFS 볼륨과 보안 정책의 조합입니다.[1] 실제 효과를 보려면 자주 읽고 쓰는 프로젝트 파일과 캐시를 어디에 둘지, 백신 필터를 어떤 상태로 유지할지, 사용하는 도구가 ReFS를 받아들이는지를 함께 결정해야 합니다.

따라서 Dev Drive를 “무조건 빠른 드라이브”로 이해하기보다, 개발 파일의 위치와 보호 정책을 다시 설계하는 선택으로 보는 편이 정확합니다. 소스만 옮기고 빌드 출력이나 패키지 캐시는 C:에 남겨 두면 파일 접근이 여러 볼륨으로 갈라져 기대한 변화가 작을 수 있습니다.

Dev Drive에 무엇을 둘 것인가

Microsoft는 Dev Drive를 개발 작업용 저장공간으로 설명하며 프로젝트 디렉터리와 패키지 캐시를 배치하는 구성을 안내합니다.[1] 반면 개인 자료나 장기 보관용 백업을 단순히 Dev Drive로 옮길 이유는 적습니다. 개발 도구가 필요로 하는 파일 기능과 백업 도구의 지원 범위가 다를 수 있기 때문입니다.

ReFS라면 모든 프로그램이 같은 방식으로 동작할까

ReFS는 데이터 가용성과 손상 복원력을 목표로 설계된 파일 시스템이지만, 모든 Windows 기능과 애플리케이션이 NTFS와 같은 범위로 동작한다고 가정해서는 안 됩니다.[2] 오래된 설치 프로그램, 특정 플러그인, 백업·암호화 도구가 파일 시스템 조건을 따로 요구할 수 있습니다. 프로젝트를 통째로 옮기기 전에 공식 문서에서 저장 경로와 파일 기능을 확인하는 것이 안전합니다.

특히 저장소를 새로 만들면 개발 환경의 경로가 바뀝니다. IDE의 프로젝트 경로, 패키지 관리자 캐시, 빌드 출력, 검증 산출물, 생성된 코드가 어디에 생성되는지 목록으로 적어 보세요. 소스만 Dev Drive에 두고 결과물은 시스템 볼륨에 두면 성능 비교가 복잡해지고, 문제가 생겼을 때 어느 경로가 원인인지 찾기 어려워집니다.

성능 최적화와 보안 필터의 관계

Dev Drive의 성능 최적화는 바이러스 백신을 자동으로 무력화하는 기능이 아닙니다. Microsoft 문서에 따르면 Defender와 타사 보안 제품의 필터는 Dev Drive에 연결될 수 있고, 조직 정책이나 로컬 관리자 설정으로 허용되는 필터 범위를 조정할 수 있습니다.[3] 검사 범위를 줄이는 예외를 넓히면 일부 작업의 지연이 줄어들 가능성은 있지만, 소스와 생성물이 보호되는 범위도 함께 바뀝니다.

개인 PC에서는 “성능 모드”라는 이름만 보고 예외를 추가하지 마세요. 먼저 현재 필터가 무엇인지 기록하고, 보안 제품의 공식 설명과 Windows 정책을 비교하세요. 회사 장비에서는 로컬 설정처럼 보여도 그룹 정책이 우선할 수 있으므로, 예외 설정은 관리자 승인과 변경 기록을 거쳐야 합니다.

설정 후 확인하는 순서

1. 설정과 디스크 관리에서 대상 볼륨이 실제로 ReFS인지 확인합니다.
2. fsutil devdrv query로 Dev Drive의 활성화 상태와 보호 정책을 읽습니다.
3. Defender 또는 회사 보안 제품에서 연결된 필터와 예외 범위를 기록합니다.
4. 소스, 빌드 출력, 캐시의 실제 경로를 도구별 설정에서 확인합니다.
5. 같은 커밋과 빌드 구성을 사용해 작은 프로젝트로 비교합니다.
6. 빌드 시간뿐 아니라 파일 접근 오류, IDE 인덱싱, 테스트와 컨테이너 작업도 확인합니다.

이 과정에서 명령 결과가 예상과 다르면 정책을 바꾸기 전에 원인을 분리하세요. 개발 볼륨이 보호되고 있는지, 어떤 필터가 연결됐는지, 도구가 해당 경로를 사용할 수 있는지는 서로 다른 질문입니다. 하나의 화면에 표시되는 상태를 근거로 세 가지를 모두 판단하면 안 됩니다.

프로젝트를 옮길 때의 비교 기준

가장 먼저 비교하기 좋은 대상은 반복해서 읽고 쓰는 소스 트리와 재생성 가능한 빌드 캐시입니다. npm·NuGet·Gradle 같은 패키지 캐시나 작은 파일이 많은 프로젝트는 대형 파일 복사보다 실제 개발 작업에 가까운 비교가 될 수 있습니다. 다만 이것이 모든 프로젝트의 결과를 대표하는 것은 아닙니다. 사용하는 빌드 도구가 파일을 직렬로 처리하는지, 병렬로 처리하는지에 따라서도 결과가 달라집니다.

비교할 때는 같은 커밋, 같은 빌드 옵션, 같은 백그라운드 앱을 유지하고 첫 빌드와 두 번째 빌드를 나누어 기록하세요. 첫 번째는 캐시 생성 비용을, 두 번째는 캐시 재사용 상황을 보여줍니다. 로컬 SSD와 네트워크 경로를 직접 비교하면 네트워크 지연이 섞이므로 Dev Drive의 파일 시스템 효과만 따로 보기 어렵습니다.

문제가 생겼을 때 되돌리는 방법

이동 전에는 프로젝트 경로와 캐시 설정을 파일로 저장하고, 원격 저장소와 별도 백업이 정상인지 확인하세요. 문제가 생기면 소스만 원래 위치로 되돌리고 캐시는 다시 만들 수 있게 분리해 두면 진단이 쉬워집니다. IDE, 패키지 관리자, 빌드 도구의 경로를 한 번에 바꾸지 말고 하나씩 바꾸는 편이 좋습니다.

• 파일 생성이 실패하면 권한과 경로, 보안 필터를 차례로 확인합니다.
• 빌드가 느려지면 캐시 적중 여부와 검사 상태를 함께 봅니다.
• 특정 플러그인만 실패하면 그 플러그인의 ReFS·Dev Drive 지원 문서를 확인합니다.
• 삭제나 포맷 전에는 소스뿐 아니라 생성하기 어려운 설정과 인증서 위치도 백업합니다.

누구에게 적합한가

Windows에서 소스와 패키지 캐시를 반복해서 읽고 쓰고, 개발 파일과 개인 데이터를 분리하고 싶은 사람이라면 Dev Drive를 검토할 만합니다. 단순한 사진·게임 보관 공간으로 쓰는 목적은 약합니다. 성능이 필요해도 작은 프로젝트에서 경로, 보안 필터, 오류 유무를 먼저 확인한 뒤 범위를 넓히세요.

저장소와 가상 환경의 연결을 함께 설계해야 한다면 Hyper-V 가상 스위치 선택법도 참고할 수 있습니다. 저장장치 경로와 네트워크 경로는 별개의 문제이므로 서로의 효과로 착각하지 않는 것이 좋습니다.

운영 중 놓치기 쉬운 예외

컨테이너나 가상 환경을 사용하는 프로젝트는 호스트의 소스 경로와 컨테이너 내부 경로가 다를 수 있습니다. 소스는 Dev Drive에 두었는데 이미지 레이어나 패키지 저장소는 다른 볼륨에 남아 있으면, 어느 구간이 빨라졌는지 분리해서 판단해야 합니다. 심볼릭 링크로 여러 경로를 감추는 방식도 처음에는 편하지만 업데이트나 권한 검사에서 원래 경로를 찾기 어렵게 만들 수 있어 공식 경로 설정을 우선하세요.

또한 여유 공간이 부족한 볼륨은 파일 시스템이 달라도 개발 작업이 안정적이지 않습니다. 빌드 산출물과 캐시가 계속 쌓이는 프로젝트라면 정리 정책과 보존 기간을 정하고, 소스 관리에 올리면 안 되는 비밀 파일이 캐시에 섞이지 않는지도 확인하세요. Dev Drive는 빠른 저장공간이나 백업 정책을 대신하지 않습니다.

자주 묻는 질문

IDE도 Dev Drive에 다시 설치해야 하나요?

반드시 그렇지는 않습니다. IDE와 SDK는 시스템 볼륨에 두고, 실제로 많이 읽고 쓰는 소스·빌드·캐시만 Dev Drive에 두는 구성이 가능합니다. 다만 도구별 공식 지원 경로는 확인해야 합니다.

보안 필터를 끄면 빨라지나요?

측정 조건에 따라 지연이 달라질 수 있지만, 검사 범위가 줄어드는 대가가 있습니다. 개인 판단으로 예외를 넓히기보다 현재 정책과 보호 상태를 먼저 기록하고, 회사 장비에서는 관리자 승인을 받으세요.[3]

ReFS가 백업을 대신하나요?

아닙니다. ReFS의 무결성·복원력 관련 기능은 별도 백업과 같은 의미가 아닙니다. 원격 저장소와 독립 백업을 유지하고, 복원 절차도 미리 확인하세요.[2]

Sources

1. [1] Microsoft Learn, Set up a Dev Drive on Windows 11
2. [2] Microsoft Learn, ReFS overview
3. [3] Microsoft Learn, Configure Dev Drive policy for enterprise business devices