구글 드라이브 데스크톱으로 연결한 G: 드라이브 안에서 쇼츠를 조립하다가, 3초짜리 구간 하나가 20분 넘게 끝나지 않은 적이 있습니다. 같은 구간을 로컬 폴더로 옮겨 돌리자 1.9초 만에 끝났습니다. 몇 주 뒤에는 C: 드라이브 남은 공간이 4.5GB까지 떨어졌는데, 이것도 구글 드라이브와 엮여 있었습니다. 2026년 10월 기준, 작업용 PC에서 겪은 두 가지 일을 기록해 둡니다.
“구글 드라이브 데스크톱 느림”으로 검색하면 대부분 동기화가 늦다는 이야기가 나옵니다. 제 경우는 동기화가 아니라 드라이브 폴더 안에서 프로그램이 파일을 읽는 속도가 문제였습니다.
3초짜리 구간이 20분 넘게 끝나지 않았습니다
저는 IT 회사 마케터인데, 쇼츠와 영상 작업을 자주 하고 개인 유튜브 쇼츠 채널도 운영합니다. 집 PC와 작업용 PC에서 같은 작업 폴더를 열려고 영상 프로젝트를 전부 구글 드라이브 안에 두고 씁니다. 평소엔 편했는데 영상 조립 단계에서 걸렸습니다.
그날 작업은 60초짜리 쇼츠 한 편이었습니다. 대사 한 컷마다 영상 클립 위에 말풍선, 이름표 같은 투명 PNG를 얹어 짧은 구간(세그먼트)으로 렌더하고 18개를 이어 붙이는 구조입니다. 조립은 클로드 코드에게 ffmpeg 스크립트로 맡겼습니다.
그런데 3초짜리 세그먼트 하나가 20분이 지나도 끝나지 않았습니다. 프로세스를 들여다보니 ffmpeg 메모리가 2.6GB까지 불어 있었고 엉뚱한 것도 하나 나왔습니다. 전에 돌리다 만 작업의 ffmpeg가 9시간째 살아서 CPU를 쓰고 있었습니다. 이건 따로 정리했습니다. 진짜 원인은 파일이 놓인 위치였습니다.
원인은 스트리밍 드라이브에서 같은 PNG를 계속 다시 읽은 것
데스크톱용 구글 드라이브는 내 드라이브를 두 가지 방식으로 PC에 붙입니다. 구글 공식 도움말에 나온 차이를 줄이면 이렇습니다.
| 구분 | 스트리밍 | 미러링 |
|---|---|---|
| 파일 위치 | 클라우드. 로컬 저장공간은 작업 중이거나 최근 쓴 파일 보관용 | 클라우드와 로컬 하드 드라이브 둘 다 |
| 오프라인 사용 | 오프라인 사용을 따로 설정해야 함 | 항상 가능 |
| 로컬 디스크 사용 | 거의 쓰지 않음 | 내 드라이브 전체 복사본만큼 |
| 앱 영향(공식 설명) | 일부 앱은 파일 스트리밍이 어려움 | 동영상 편집, 고해상도 사진 편집은 미러링이 더 빠름 |
제 PC는 스트리밍 모드라서 G: 드라이브가 따로 생깁니다. 디스크 정보를 조회해 보면 G:는 이름이 “Google Drive”인 가상 볼륨으로 잡힙니다. 진짜 디스크가 아니라 드라이브 앱이 띄운 창구라서 파일을 열 때마다 앱이 캐시나 클라우드에서 꺼내 줍니다. 공식 도움말에도 스트리밍 파일은 드라이브 앱이 실행 중일 때만 열 수 있다고 적혀 있습니다.
여기에 ffmpeg 쪽 사정이 겹쳤습니다. PNG 한 장을 영상처럼 몇 초 동안 띄우려면 -loop 1 옵션을 씁니다. ffmpeg 공식 문서의 설명은 “1이면 입력을 반복한다”는 한 줄뿐인데, 제 작업에서는 이 반복이 같은 PNG를 프레임마다 다시 읽는 식으로 일어났습니다. 30fps로 3초면 90번입니다. 얹은 PNG가 여러 장이면 그만큼 곱해집니다.
같은 명령을 로컬 폴더에서 돌리면 1.9초에 끝났으니, 반복 읽기 자체는 일반 디스크에서 티가 나지 않는 수준입니다. 스트리밍 드라이브에서는 그 한 번 한 번이 드라이브 앱을 거치면서 쌓였다는 게 제 결론입니다. 구글이 쓰기가 많은 작업이나 동영상 편집은 미러링이 더 빠르다고 따로 적어 둔 것도 같은 맥락으로 읽힙니다.
렌더는 로컬 폴더에서, 결과만 드라이브로 옮겨서 해결
고친 방법은 단순합니다.
- 세그먼트에 들어가는 입력 파일(클립 mp4, PNG, 음성 wav)을
%LOCALAPPDATA%아래 작업 폴더로 복사합니다. 다시 돌릴 때는 크기나 수정 시각이 바뀐 파일만 복사합니다. - ffmpeg는 그 로컬 폴더에서 실행합니다.
- 완성된 mp4만 드라이브의 프로젝트 폴더로 복사합니다. 올리는 일은 드라이브 앱이 알아서 합니다.
헷갈리기 쉬운 부분이 하나 있습니다. 저는 이걸 “로컬 미러”라고 부르는데, 드라이브 설정의 “미러링 모드”와는 다른 이야기입니다. 드라이브는 그대로 스트리밍으로 두고 렌더하는 순간에만 입력 파일을 로컬로 복사해 쓰는 방식입니다.
렌더가 비정상적으로 길어지면 남아 있는 ffmpeg부터 확인합니다. PowerShell에서 쓰는 명령은 두 줄입니다.
Get-Process ffmpeg -ErrorAction SilentlyContinue | Select-Object Id, StartTime, CPU
Stop-Process -Id 12345
첫 줄은 살아 있는 ffmpeg의 시작 시각과 누적 CPU 시간(초)을 보여 줍니다. 둘째 줄은 지금 작업이 아닌 프로세스만 골라 끝내는 명령입니다. 12345 자리에 위 목록의 Id를 넣습니다.
이후로는 개인 채널 롱폼(8분 넘는 16:9 영상)과 그 일본어판 조립 스크립트에도 이 구조를 기본으로 넣었습니다.
수치로 본 결과
| 항목 | 수치 | 메모 |
|---|---|---|
| 3초 세그먼트 렌더 (G:에서 직접) | 20분 넘게 진행 중 | 입력 파일이 스트리밍 드라이브에 있음 |
| 같은 세그먼트 (로컬 폴더) | 1.9초 | 입력 복사 후 렌더 |
| G:에서 렌더하던 ffmpeg 메모리 | 2.6GB | 렌더가 길어지며 계속 증가 |
| 이전 작업에서 남은 ffmpeg | 9시간째 실행 | 별도로 종료 |
| 60초 쇼츠 전체 렌더 (18세그먼트) | 25초 | 로컬 폴더 기준 |
| 로컬 작업 폴더 크기 | 편당 1.6~1.7GB | 롱폼 일본어판 기준, 끝나면 삭제 |
20분을 1.9초와 단순 비교하면 600배가 넘습니다. PC는 그대로였고 남아 있던 ffmpeg를 정리한 것 말고는 입력 파일 위치를 바꾼 게 전부입니다.
같이 겪은 문제, C: 남은 공간 4.5GB
10월 초에는 C: 드라이브 남은 공간이 4.5GB까지 떨어졌습니다. 처음에는 다운로드 폴더에 있던 쇼츠 클립(156개, 0.83GB)부터 지우려 했는데, 작업 중인 파일인 데다 크기도 작았습니다. 폴더별로 크기를 재 보니 범인은 %LOCALAPPDATA%\Temp였고 여기에만 173GB가 쌓여 있었습니다.
- After Effects 디스크 캐시(
Temp\Adobe\After Effects안의.aecache파일): 79GB. 하루 영상 작업으로 쌓인 양입니다 - Temp 폴더 바로 아래 30일 지난 파일: 70.5GB. 그중 이름이 무작위 문자열인 지난해 mp4가 60GB였습니다
두 묶음을 지우자 남은 공간이 4.5GB에서 154.1GB로 돌아왔습니다. Adobe 캐시는 After Effects를 끈 상태에서 지워야 합니다.
이 일이 구글 드라이브와 엮이는 이유가 있습니다. 스트리밍 드라이브의 캐시는 기본으로 %LOCALAPPDATA%\Google\DriveFS, 즉 C:에 있습니다(구글 워크스페이스 관리자 도움말). 그래서 G:의 남은 공간도 C:를 따라 줄어듭니다. 작업용 PC에서 디스크 정보를 조회해 보면 G:의 전체 용량이 C:와 똑같은 숫자로 나옵니다.
데스크톱용 Drive 설정 도움말에는 캐시 폴더가 있는 파티션의 여유 공간보다 큰 폴더는 업로드할 수 없다고 나옵니다. C:가 4.5GB 남은 상태라면 그보다 큰 영상 폴더는 드라이브에 올리지도 못합니다. 앞에서 만든 로컬 작업 폴더도 C:에 있으니, 렌더가 끝나면 지워야 공간이 다시 줄지 않습니다.
재발을 막으려면 After Effects 환경설정의 디스크 캐시 항목에서 캐시 폴더를 다른 드라이브로 옮기거나 최대 크기를 줄여야 합니다. 제 PC에는 600GB 넘게 비어 있는 D:가 있어서 그쪽으로 옮기는 걸 다음 할 일로 적어 뒀습니다.
같은 상황이라면 이 순서로 점검하세요
- 렌더나 인코딩에 쓰는 입력 파일이 G:(스트리밍 드라이브) 안에 있는지 먼저 봅니다
-loop 1이미지 입력처럼 같은 파일을 반복해서 읽는 작업이면, 입력을 로컬 폴더로 복사한 뒤 실행합니다- 완성본만 드라이브 폴더로 복사합니다. 중간 파일까지 드라이브에 쓰면 그만큼 올라갈 것도 늘어납니다
- 렌더가 이상하게 길면 남아 있는 ffmpeg부터 확인합니다
- 로컬 작업 폴더는 끝나면 지웁니다. 롱폼 일본어판은 한 편에 1.6GB가 넘었습니다
- C: 공간이 부족하면 Temp 안의 Adobe 캐시, Temp 바로 아래 30일 지난 파일, 다운로드 폴더 순으로 크기를 잽니다
- 미러링 모드 전환을 고민한다면 내 드라이브 전체가 로컬에 복사된다는 점부터 따져 봅니다
자주 묻는 질문
미러링 모드로 바꾸면 G:에서 바로 렌더해도 되나요?
공식 도움말은 동영상 편집처럼 쓰기가 많은 앱은 미러링이 더 빠르다고 설명합니다. 다만 저는 바꿔 보지 않았습니다. 미러링은 내 드라이브 전체 복사본을 로컬에 두는 방식이라 C: 여유가 넉넉해야 합니다. 또 공유 드라이브는 스트리밍만 지원하니 공유 드라이브 파일은 여전히 로컬로 복사해 써야 합니다.
구글 드라이브 캐시 위치를 다른 드라이브로 옮길 수 있나요?
됩니다. 드라이브 앱의 설정 > 환경설정 > 고급 설정에서 “로컬 캐시 파일 디렉터리”를 바꿉니다. 다만 구글은 기본 위치를 권장하고 미러링 폴더 안이나 스트리밍 위치의 상위·하위 폴더는 고를 수 없습니다. 캐시 경로를 쓸 수 없으면 드라이브 앱 자체가 동작하지 않는다고 하니, 뺐다 꼈다 하는 외장 디스크는 피하는 편이 안전해 보입니다. 저는 아직 기본 위치 그대로 씁니다.
렌더가 멈춘 건지 느린 건지 어떻게 구분하나요?
위의 Get-Process 명령으로 StartTime과 CPU를 봅니다. 시작 시각이 몇 시간 전인 ffmpeg는 이전 작업에서 남은 것일 가능성이 큽니다. 제 경우가 9시간짜리였습니다. 지금 돌리는 프로세스는 몇 초 간격으로 다시 조회해서 CPU 값이 거의 늘지 않는데 끝나지도 않는다면, 계산보다 파일 읽기에서 막혀 있을 가능성이 큽니다. 그때는 입력 파일 위치부터 확인해 보세요.