합동회사 코무라소프트
문의하기
메뉴

같은 1GB인데, 동영상 한 편보다 사진 폴더 복사가 느린 이유는?

· 업데이트: · · Windows, Windows 11, 파일 복사, 성능, SSD, NAS, ZIP, robocopy

1GB짜리 동영상은 금방 복사되었는데, 합계 1GB인 사진 폴더는 좀처럼 끝나지 않습니다. 새 SSD로 바꿨는데도 잘게 나뉜 파일을 옮기면 전송 속도가 뚝 떨어집니다.

용량이 같으면 시간도 같을 것 같지만, 복사 시간을 정하는 것은 「몇 바이트를 옮기는가」만이 아니라 「몇 개의 파일을 다루는가」이기도 합니다.

이 글은 Windows 11에서 사진이나 자료를 외장 드라이브·NAS로 복사하는 일반 사용자를 위한 입문입니다. 구조를 설명한 뒤, 같은 합계 용량의 데이터를 직접 비교하는 절차를 소개합니다. 2026년 9월 5일에 확인한 공식 자료에 기반한 해설이며, 특정 PC나 NAS의 속도를 측정한 결과는 아닙니다.

1. 「1GB를 옮긴다」와 「1만 건을 처리한다」는 다른 일입니다

이사에 빗대어 보면, 짐의 총무게가 같아도 큰 상자 하나와 받는 사람을 확인해야 하는 소포 1만 개는 손이 가는 정도가 다릅니다. 파일에도 내용을 옮기기 전후에 해야 할 일이 있습니다.

같은 용량이라도 다른 파일의 수합계 1GB의 데이터라도 하나의 파일과 다수의 파일은 관리 처리의 횟수가 다릅니다.합계 1GB의 데이터큰 파일 1개작은 파일 1만 개파일 단위의 처리가 적음파일 단위의 처리를 반복

그림 1: 바이트 수가 같아도 파일 수까지 같다고는 할 수 없습니다.

Microsoft도 다수의 작은 파일을 네트워크 너머로 차례차례 복사할 때는 데이터 전송 이외의 처리가 작용해 회선 속도를 다 쓰지 못한다고 설명합니다.1

물론 「사진은 느리고 동영상은 빠르다」는 형식별 법칙은 아닙니다. 큰 사진 몇 장과 수만 개의 작은 이미지는 조건이 다릅니다. 먼저 폴더 속성에서 합계 크기와 파일 수 양쪽을 봅시다. 비교에서는 「디스크상의 크기」가 아니라 파일 내용의 합계 바이트 수를 맞춥니다.

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 11건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

2. 복사에서는 내용 이외의 정보도 다룹니다

파일을 복사할 때는 복사 원본을 열고, 복사 대상 파일을 만들고, 내용을 읽고 쓰고, 필요한 정보를 설정한 뒤 닫습니다. Windows에서 파일을 여는 처리는 액세스 권한이나, 다른 처리와 동시에 열어도 되는지 같은 조건도 다룹니다.2

이름·크기·날짜 등 파일을 관리하는 정보를 메타데이터라고 합니다. 예를 들어 NTFS라는 파일 시스템은 파일마다의 관리 정보를 MFT(마스터 파일 테이블) 등에 기록합니다. 사진의 픽셀 데이터만 쓰면 끝나는 구조가 아닙니다.3

파일 하나를 복사할 때의 일복사 원본의 읽기에 더해, 복사 대상의 생성과 정보 관리, 닫기가 파일마다 필요해집니다.복사 원본을 연다복사 대상을 만든다내용을 읽고 쓴다정보를 정리하고 닫는다다음 파일에서도 반복

그림 2: 개념적인 흐름입니다. 실제 처리 순서나 병행 실행은 복사 방법과 파일 시스템에 따라 달라집니다.

SSD라도 이 관리의 일이 없어지지는 않습니다. 제품에 적힌 큰 전송 속도 숫자만으로는 1만 개 파일의 복사 시간을 구할 수 없습니다. 또한 작은 파일의 복사를 그대로 「전부 랜덤 I/O」라고 부르는 것도 거칩니다. 읽고 쓰는 배치뿐 아니라, 파일을 다루는 처리 자체를 나누어 생각해야 합니다.

3. NAS에서는 「상대의 답을 기다리는 시간」도 더해집니다

NAS는 네트워크를 통해 쓰는 저장 장치입니다. Windows의 공유 폴더에서 쓰이는 SMB(Server Message Block)에서는 파일 조작을 상대에게 의뢰하고, 상대의 처리와 응답을 기다리는 장면이 있습니다.

네트워크 너머의 파일 조작PC의 조작 요청은 네트워크를 지나 상대의 파일 처리가 되고, 응답이 PC로 돌아옵니다.PC에서 파일 조작을 의뢰네트워크를 지남상대가 파일을 처리응답이 PC로 돌아옴

그림 3: 한 번에 옮길 수 있는 양이 많은 것과, 한 조작의 답이 빠른 것은 별개입니다.

도로의 차선 수에 해당하는 것이 대역폭, 답이 돌아올 때까지의 시간에 해당하는 것이 지연입니다. 작은 파일마다 기다리는 시간이 늘면, 대역폭에 여유가 있어도 전송량은 늘지 않습니다. 바이러스 백신의 검사도 파일마다의 처리 시간에 영향을 줄 수 있습니다.1

다만 파일 하나마다 반드시 정해진 횟수의 통신을 한다는 뜻은 아닙니다. SMB에는 요청을 묶는 구조가 있고, 캐시나 병행 처리의 조건에 따라 기다리는 방식도 달라집니다.45 가정 내 LAN과 원격지의 공유 폴더에서도 결과는 달라집니다.

숫자로 생각하기 위한, 단순화한 예

겹치지 않고 차례대로 처리한다고 가정하면 사고방식은 다음과 같습니다.

복사 시간 ≒ 합계 바이트 수 ÷ 데이터 전송 속도
          ＋ 파일 수 × 파일 하나당 추가 시간

이는 측정값도, Windows의 정확한 계산식도 아닙니다. 설명을 위해 데이터 부분은 100MB/초, 추가 시간은 파일 하나당 2밀리초라고 가정합니다. 여기에서 1GB＝1,000MB입니다.

1GB의 데이터 부분은 10초. 파일이 1개면 추가는 0.002초이지만, 1만 개면 20초가 되어 합계는 약 30초가 됩니다. 병렬화, 캐시, CPU나 스토리지의 제약을 뺀 모형이지만, 「용량이 같은데 시간이 다르다」는 것은 설명할 수 있습니다.

복사 시간을 둘로 나누어 생각한다합계 용량으로 정해지는 전송 시간과, 파일 수에 따라 쌓이는 추가 시간을 구별합니다.합계 용량에 따른 시간복사 전체의 시간파일 수에 따른 추가 시간

그림 4: 파일 수가 늘면 데이터 양만으로는 보이지 않던 시간이 작용하기 시작합니다.

4. ZIP은 「작게 만드는」 것만이 아니라 「하나로 묶는」 것

ZIP에는 데이터를 압축하는 역할과, 여러 파일을 하나의 그릇에 담는 역할이 있습니다. JPEG는 이미 압축된 형식이므로 ZIP으로 만들어도 용량이 별로 줄지 않을 수 있습니다.6

그래도 전송할 때 다루는 파일이 1만 개에서 하나가 되는 효과는 별개로 있습니다. 압축률만 보고 「ZIP으로 만든 의미가 없었다」고 판단하는 것은 이릅니다.

ZIP의 두 가지 역할ZIP으로 묶어서 생기는 파일 수의 변화와, 압축에 의한 용량의 변화는 다른 효과입니다.사진을 ZIP으로 묶는다전송할 파일은 하나용량의 변화는 내용에 따라

그림 5: 거의 압축되지 않더라도 전송할 파일의 개수는 줄일 수 있습니다.

다만 묶는 처리도 푸는 처리도 공짜가 아닙니다. 사진을 일반 폴더로 쓰고 싶다면 다음 합계로 비교합니다.

ZIP 경유의 소요 시간 ＝ ZIP 생성 ＋ ZIP 전송 ＋ 압축 해제

ZIP을 만드는 단계에서 작은 파일을 읽고, 푸는 곳에서 다시 만듭니다. 파일마다의 일을 없애는 것이 아니라, 그 일을 하는 장소와 전송의 형태를 바꾸는 것이 핵심입니다. 전송 전후의 처리가 무거우면 묶지 않는 편이 빠를 때도 있습니다.1

5. 「어디에서 푸는가」에 따라 ZIP의 효과는 달라집니다

받는 쪽 PC에 ZIP을 보내고, 그 PC의 로컬 드라이브에서 푼다면 작은 파일을 하나씩 네트워크로 흘려보내지 않아도 됩니다. Microsoft의 안내도 아카이브를 전송 대상 시스템에서 푸는 방법을 들고 있습니다.1

전송 대상에서 푸는 경우와 PC에서 공유 위치로 푸는 경우전송 대상에서 내부적으로 푸는 경로와, PC가 푼 파일을 공유 위치로 쓰는 경로를 구별합니다.ZIP을 전송 대상으로 보낸다전송 대상이 스스로 내부에서 푼다PC의 앱으로 푼다작은 파일을 공유 위치로 보낸다

그림 6: 「ZIP이 NAS 위에 있다」는 것만으로 압축 해제 처리도 NAS 안에서 이루어진다고 할 수는 없습니다.

여기가 틀리기 쉬운 부분입니다. PC의 파일 탐색기로 NAS 위의 ZIP을 열고, 푸는 위치로 같은 공유 폴더를 지정하면, PC가 푼 작은 파일을 NAS로 쓰기 때문에 잘게 나뉜 네트워크 조작이 다시 발생합니다.

NAS 자신에게 대응하는 압축 해제 기능이 있어서 관리 화면 등에서 NAS 내부에서 실행할 수 있는 경우와는 구분하십시오. 그런 기능이 없다면 「ZIP을 보내면 해결」이라고 하지 말고, 실제로 쓰는 경로 전체를 측정합니다. NAS 내부로의 압축 해제와 PC 로컬로의 압축 해제를 비교할 때는, 최종적으로 파일을 두는 장소가 다르다는 점도 잊어서는 안 됩니다.

6. 같은 1GB로 큰 파일·작은 파일·ZIP을 비교해 봅니다

우선은 가진 동영상과 사진으로 시험해도 괜찮습니다. 다만 내용, 파일 수, 압축되기 쉬운 정도까지 다르므로, 원인을 분리하고 싶을 때는 실험용 데이터를 씁니다. 아래는 속도의 측정 결과가 아니라, 독자의 환경에서 수행하는 비교 절차입니다.

준비할 것은 큰 파일 1개, 작은 파일 1만 개, 그 1만 개를 묶은 무압축 ZIP의 세 가지입니다. A와 B의 내용 합계는 둘 다 정확히 1,000,000,000바이트. C에는 ZIP의 관리 정보가 더해지므로 파일 크기는 A·B와 완전히 일치하지 않습니다.

세 종류의 비교용 데이터같은 합계 용량의 큰 파일과 작은 파일 군을 만들고, 후자로부터 무압축 ZIP도 만듭니다.같은 합계 1GB를 준비1GB의 파일 1개100KB의 파일 1만 개같은 내용을 무압축 ZIP으로

그림 7: 무압축 ZIP이라면 압축률의 차이와 파일 수를 묶는 효과를 나누어 관찰하기 쉬워집니다.

실험용 파일 만들기(선택)

명령을 쓸 수 있는 분을 위한 내용입니다. Windows PowerShell 5.1 이상에서 로컬 임시 폴더에 새 실험용 폴더를 만듭니다. 큰 파일과 작은 파일 군만으로 약 2GB, ZIP까지 포함하면 약 3GB를 쓰며, 전송 대상에도 별도의 여유 용량이 필요합니다. 디스크를 가득 채우지 않도록 복사 원본에는 적어도 5GB 정도의 여유를 확보하십시오.

기존의 사진이나 자료는 쓰지 않습니다. 유사 난수 데이터를 생성하므로 동영상이나 사진으로 열 수 있는 파일은 아닙니다. 0으로만 채운 데이터를 썼을 때의 극단적인 압축은 피하지만, 실제 사진에 대한 검사나 앱의 동작까지 재현하는 것은 아닙니다.

$ErrorActionPreference = 'Stop'
$lab = Join-Path ([System.IO.Path]::GetTempPath()) ('copylab-' + [guid]::NewGuid().ToString('N'))
$drive = New-Object System.IO.DriveInfo ([System.IO.Path]::GetPathRoot($lab))
if ($drive.AvailableFreeSpace -lt 5GB) {
    throw '실험용 드라이브에 5GB 이상의 여유 공간을 확보하십시오.'
}
$largeDir = Join-Path $lab 'large'
$smallDir = Join-Path $lab 'small'
[System.IO.Directory]::CreateDirectory($largeDir) | Out-Null
[System.IO.Directory]::CreateDirectory($smallDir) | Out-Null
Write-Host "생성 위치: $lab"

$fileCount = 10000
$buffer = New-Object byte[] 100000
$random = New-Object System.Random 20260905
$large = [System.IO.File]::Open(
    (Join-Path $largeDir 'one.bin'),
    [System.IO.FileMode]::CreateNew,
    [System.IO.FileAccess]::Write,
    [System.IO.FileShare]::None
)
try {
    for ($i = 0; $i -lt $fileCount; $i++) {
        $random.NextBytes($buffer)
        $name = 'part-{0:D5}.bin' -f $i
        [System.IO.File]::WriteAllBytes((Join-Path $smallDir $name), $buffer)
        $large.Write($buffer, 0, $buffer.Length)
    }
}
finally {
    $large.Dispose()
}
Write-Host "준비 완료. 각 데이터 군의 내용은 $([long]$fileCount * $buffer.Length) 바이트입니다."

같은 바이트 열을 잘게 나눈 파일과 하나의 파일 양쪽에 씁니다. 이어서 같은 PowerShell 화면에서 무압축 ZIP을 만듭니다. 생성 시간을 여기에서 기록합니다. NoCompression은 압축하지 않고 ZIP에 담으라는 지정입니다.7

$zip = Join-Path $lab 'small.zip'
$watch = [System.Diagnostics.Stopwatch]::StartNew()
Compress-Archive -LiteralPath $smallDir -DestinationPath $zip -CompressionLevel NoCompression
$watch.Stop()
Write-Host "ZIP 생성: $($watch.Elapsed.TotalSeconds) 초"
Write-Host "ZIP의 크기: $((Get-Item -LiteralPath $zip).Length) 바이트"

이 절차는 생성한 일반 파일 전용입니다. Compress-Archive에는 숨김 파일을 무시하는 등의 제한이 있으므로, 중요한 폴더의 완전 백업에 그대로 전용하지 마십시오.7 오류로 멈췄다면 그 회차는 측정에 쓰지 말고, 표시된 실험용 폴더를 확인합니다. 뒷정리도 자신이 만든 폴더임을 확인한 뒤에 합니다.

측정 조건을 맞춥니다

복사 원본과 복사 대상의 장치, 네트워크, 복사 방법을 맞춥니다. 처음에는 세 가지 모두 파일 탐색기로 복사하고, 이동은 쓰지 않습니다. 복사 대상은 매번 새 빈 폴더로 해서, 기존 파일의 건너뛰기나 덮어쓰기 확인이 섞이지 않도록 합니다.

비교 조건을 맞추는 절차복사 경로와 방법을 고정하고, 빈 복사 대상으로 순서를 바꿔 여러 번 복사한 뒤 완료 후 내용도 확인합니다.같은 장치·경로·방법매번 빈 복사 대상순서를 바꿔 여러 번 측정건수와 내용도 확인

그림 8: 이미 복사된 파일이 건너뛰어져 절약된 시간을, 전송이 빨라진 결과로 다루지 않도록 합니다.

각 사례를 예컨대 3회씩 순서를 바꿔 측정하고, 중앙값과 편차를 기록합니다. Windows는 파일을 메모리에 캐시하므로 두 번째만 빨라질 수 있습니다. 새 복사 대상으로 해도 읽기 쪽의 캐시는 사라지지 않습니다. 이 절차로 알 수 있는 것은 평소의 복사에 가까운 경향이지, 엄밀하게 캐시 없는 매체 성능은 아닙니다.5

같은 물리 드라이브 내의 복사는 읽기와 쓰기가 경합하므로, 다른 장치로의 복사와 섞지 않습니다. 온라인 전용 클라우드 파일은 가져오는 시간이 들어가므로 쓰지 않고, 바이러스 백신이나 동기화 등의 조건도 도중에 바꾸지 않도록 합니다.

사례 생성 시간 전송 시간 압축 해제 시간 사진 군 등을 쓸 수 있게 될 때까지의 합계
A: 큰 파일 1개 비교용 준비이므로 제외 실측해 기록 불필요 전송 시간(대조용)
B: 작은 파일 1만 개 비교용 준비이므로 제외 실측해 기록 불필요 전송 시간
C: B를 묶은 무압축 ZIP ZIP 생성을 기록 실측해 기록 필요하면 기록 생성＋전송＋압축 해제

이는 기록용 표이며, 결과 수치는 넣지 않았습니다. A는 전송의 성질을 보는 대조이며, 파일 구조가 다르므로 B의 대용품은 아닙니다. B와 C의 실용적인 비교에서는 같은 파일 군을 같은 최종 저장 위치에 두는 것을 목표로 합니다. 푸는 장소도 반드시 기록하십시오.

복사나 압축 해제 후에는 건수·합계 바이트 수를 대조하고, 필요하면 해시로 내용을 확인합니다. 확인을 위한 읽기는 계측 밖에서 하고, 다음 시도의 캐시에도 영향을 준다는 점을 기록합니다. 복사 화면이 닫힐 때까지의 시간은 전원이 끊겨도 견딜 수 있는 상태까지의 시간을 재는 것이 아니므로, 외장 기기를 직후에 뽑는 실험도 하지 않습니다.5

7. ZIP으로 만들 수 없을 때는 조금씩 병렬로 복사합니다

복사 대상에서 곧바로 개별 파일을 쓰고 싶다, 매번 바뀐 파일만 보내고 싶다 같은 용도에서는 ZIP으로 묶는 것이 맞지 않을 때도 있습니다. Windows 기본 제공 robocopy에는 여러 파일을 병렬로 다루는 /MT가 있습니다.89

파일마다의 대기 시간을 병렬화한다여러 파일의 처리를 진행하면, 한 파일이 기다리는 동안 다른 전송을 진행할 수 있습니다.여러 파일을 병행 처리파일 A는 응답 대기파일 B는 전송 중대기 시간을 겹친다

그림 9: 병렬화는 대기 시간을 겹치는 방법이며, 회선이나 디스크 자체를 빠르게 하지는 않습니다.

아래는 앞에서 만든 $smallDir에서 복사하는 예입니다. $targetRoot만 자신이 쓸 수 있는 복사 대상으로 변경합니다. 매번 다른 복사 대상 폴더를 만들고, 원본 데이터나 복사 대상을 삭제하는 지정은 쓰지 않습니다.

$targetRoot = '\\NAS\share\CopyLab' # 자신의 복사 대상으로 변경한다
$runId = [guid]::NewGuid().ToString('N')
$target = Join-Path $targetRoot ('small-mt8-' + $runId)
$log = Join-Path $lab ('robocopy-' + $runId + '.log')
robocopy $smallDir $target /E /MT:8 /R:1 /W:1 /XJ "/LOG:$log"
$code = $LASTEXITCODE
if ($code -ge 8) {
    throw "복사에 실패가 있었습니다. 종료 코드=$code, 로그=$log"
}
Write-Host "종료 코드=$code. 로그의 복사 건수·실패 건수와 복사 대상의 내용을 확인하십시오: $log"

/MT:8은 8스레드, /R:1 /W:1은 실패 시의 재시도 횟수와 대기 초, /LOG는 로그 저장입니다. robocopy는 종료 코드 1이어도 정상 복사이며, 8 이상은 실패를 포함합니다. 0~7이면 내용 확인이 불필요하다는 뜻은 아닙니다.8

/MT:8은 비교의 출발점 예시이지 최적값이 아닙니다. 병렬 수를 너무 늘리면 상대의 부하가 커져 오히려 느려질 수도 있습니다.1 같은 방법으로 /MT:1과 /MT:8을 비교하는 식으로, 한 번에 바꾸는 조건을 좁힙니다. ZIP과 병렬화를 동시에 바꾼 결과로 한쪽만의 효과를 판단하지 않도록 합니다.

8. 「느리니까 고장」이라고 정하기 전에

다수의 작은 파일만 느린가, 큰 파일도 느린가. 같은 파일을 로컬로 복사하면 어떤가. 이를 나누면 조사할 곳을 좁힐 수 있습니다. 도중부터 속도가 떨어지는 경우에는 캐시의 영향도 생각할 수 있어, 표시 속도만으로는 원인을 특정할 수 없습니다.5

복사가 느린 원인을 분리한다작은 파일만 느린 경우와, 데이터의 종류와 관계없이 느린 경우를 나누어 조사합니다.예아니오작은 파일만 느린가?파일 수와 대기 시간을 본다장치·연결·부하도 조사한다실패나 끊김의 유무도 확인

그림 10: 작은 파일에서 속도가 오르지 않는 것과, 복사 실패나 장치의 이상은 같은 이야기가 아닙니다.

복사 실패나 연결 끊김이 나온다, 예전보다 갑자기 나빠졌다 같은 경우에는 파일 수만으로 설명하고 끝내지 않습니다. 중요한 데이터의 보전을 우선하고, 로그와 장치의 상태를 확인합니다.

또한 속도를 올리려고 바이러스 백신을 끄거나 SMB 서명을 사용하지 않게 하는 것은 권하지 않습니다. SMB 서명에는 통신의 변조 등을 막는 역할이 있습니다.10 관리되는 PC에서는 설정을 우회하지 말고 담당자와 상의하십시오.

정리

복사 시간에는 데이터의 양에 따른 시간과, 파일의 수에 따른 일이 모두 있습니다. 「1GB니까 같은 시간」이라고 할 수 없는 이유가 여기에 있습니다.

ZIP을 시험한다면 압축률만이 아니라 생성·전송·압축 해제까지. 병렬 복사를 시험한다면 한 번에 바꾸는 것은 병렬 수만. 빠른 장치를 사기 전에 합계 크기와 파일 수를 함께 보면, 지금의 Windows에서 무엇이 일어나고 있는지 생각하기 쉬워집니다.

참고 링크

  1. Microsoft Learn, Slow SMB files transfer speed. 다수의 작은 파일, 파일 생성·통신·검사의 부담, 병렬 복사와 전송 대상에서의 아카이브 압축 해제에 대해. ↩ ↩2 ↩3 ↩4 ↩5

  2. Microsoft Learn, CreateFileW function. 파일을 열고 만드는 조작, 액세스 권한과 공유 모드에 대해. ↩

  3. Microsoft Learn, Master File Table. NTFS가 파일마다의 관리 정보를 보관하는 구조에 대해. ↩

  4. Microsoft Open Specifications, Sending Compounded Requests. SMB2에서 관련된 여러 조작을 묶어 보내는 구조에 대해. ↩

  5. Microsoft Learn, File Caching. 시스템 파일 캐시와, 쓰기를 늦춰 반영하는 구조에 대해. ↩ ↩2 ↩3 ↩4

  6. Microsoft Support, Zip and unzip files. ZIP에 의한 파일의 집약과, JPEG는 추가 압축해도 잘 작아지지 않는다는 점에 대해. ↩

  7. Microsoft Learn, Compress-Archive. NoCompression의 지정과 숨김 파일 등의 제한에 대해. ↩ ↩2

  8. Microsoft Learn, robocopy. 병렬 수, 재시도, 로그, 복사 옵션과 종료 코드에 대해. ↩ ↩2

  9. Microsoft Learn, Performance Tuning for SMB File Servers. 작은 파일의 복사에 대한 robocopy의 병렬화와 로그 출력에 대해. ↩

  10. Microsoft Learn, SMB signing overview. SMB 서명의 보호 목적과 운영상의 사고방식에 대해. ↩

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

용량이 같은데 사진 폴더의 복사가 느린 이유는 무엇입니까?
복사는 내용을 전송하는 것만이 아닙니다. 파일을 만들고, 정보를 관리하고, 닫는 처리 등이 파일마다 발생합니다. 작은 파일이 많으면 이 처리와 대기 시간의 비중이 커집니다. 사진이라는 형식 자체보다, 파일 수와 하나당 크기가 중요합니다.
SSD나 빠른 LAN에서도 작은 파일의 복사는 느려집니까?
그렇습니다. SSD라도 파일 관리 처리는 남고, NAS 등으로 복사할 때는 통신과 상대 쪽 처리를 기다리는 시간도 더해집니다. 큰 파일을 연속으로 전송했을 때의 속도와, 다수의 작은 파일을 처리하는 속도는 별개입니다.
JPEG를 ZIP으로 만들어도 작아지지 않는다면 묶는 의미가 없습니까?
용량이 거의 줄지 않더라도, 전송할 파일을 하나로 묶는 효과는 있습니다. 다만 ZIP의 생성과 압축 해제에도 시간이 걸립니다. 압축 해제가 필요한 용도라면 생성·전송·압축 해제의 합계 시간으로 비교합니다.
ZIP을 NAS로 보낸 뒤 PC에서 공유 폴더에 풀어도 빨라집니까?
그 방법은 압축 해제된 작은 파일을 PC에서 NAS로 쓰기 때문에, 네트워크 너머의 파일 생성이 다시 발생합니다. NAS 자신의 기능으로 내부에서 푸는 경우와 구분하고, 압축 해제까지 포함해 측정하십시오.
robocopy의 병렬 복사는 늘릴수록 빨라집니까?
아닙니다. 병렬화는 파일 처리의 대기 시간을 겹칠 수 있는 반면, 스토리지나 NAS의 부하도 늘립니다. 적은 병렬 수부터 같은 조건에서 비교하고, 복사의 실패나 누락도 로그로 확인합니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.

문의하기
블로그 목록으로 돌아가기