한 줄 결론. Chrome 자동화용 profile을 여러 개 운영하면 같은
OptGuideOnDeviceModel AI 모델 파일이 profile마다 중복 저장됩니다. 안전하게 삭제하면 다음 Chrome 실행 시 자동으로 재다운로드합니다.
문제 상황
프로젝트 디렉터리 디스크 사용량을 점검하다가 작업 폴더가 29GB까지 부풀어 있는 걸 봤습니다. 코드와 백업으로는 설명이 안 되는 크기였습니다.
에러 증상
큰 폴더 분포를 측정한 결과:
- 옛 백업 폴더 12.0 GB
- Chrome 자동화 profile 1 — 6.5 GB
- Chrome 자동화 profile 2 — 5.3 GB
- Chrome 자동화 profile 3 — 4.8 GB
- 합계 약 28.6 GB가 Chrome 관련 폴더
각 폴더를 파고 들어가니 동일한 weights.bin 파일(4072 MB)이 3 profile에 똑같이 박혀있었습니다.
환경
- Windows 11 + Chrome 148.0.7778
- Chrome
--remote-debugging-port=9222자동화 환경 - Playwright + 여러 stealth profile
- 각 profile에 Gemini Nano on-device 모델이 자동 다운로드됨
시도했지만 실패한 방법
- Chrome 실행 중 profile 폴더 통째 삭제 —
SingletonLock때문에 access denied. Chrome 죽이지 않고 삭제 불가. - Chrome 끄고 폴더 통째 삭제 — 다음 자동화 실행 시 다시 4GB 다운로드. 임시 해결.
원인
운영 기록 기준 확인된 원인은 두 가지입니다.
- Chrome은 profile별로 OptGuide AI 모델을 따로 캐싱합니다. 같은 모델이라도 profile마다 별도 디렉토리에 저장돼서 자동화 profile 수가 늘어날수록 GB 단위로 중복됩니다.
- 옛 작업 결과로 만들어진 백업 폴더 안에도 동일 weights.bin이 들어있었습니다 (= profile 백업 = 모델까지 백업).
최종 해결
안전한 cleanup 절차:
# 1) lock 없는 archive profile들 먼저 통째 삭제
Remove-Item -Recurse -Force ".\unused-profile-a"
Remove-Item -Recurse -Force ".\unused-profile-b"
# 2) 현재 사용 중 profile은 lock 잡혀있으니
# subfolder만 골라서 (OptGuide는 lock 안 걸림)
Remove-Item -Recurse -Force ".\active-profile\OptGuideOnDeviceModel"
# 3) 백업 폴더 안 profile 잔재도 그냥 garbage
Remove-Item -Recurse -Force ".\old-backup\legacy_profiles"
검증 결과
- cleanup 후 폴더 총 크기: 29.6 GB → 3.45 GB (26.15 GB 회수)
- 다음 Chrome 9222 실행 시 OptGuide 모델 자동 재다운로드 (약 5분, 한 번만)
- 자동화 스크립트 정상 작동 — login 세션 보존됨 (Cookies/Local Storage는 OptGuide 폴더 밖)
현재 상태
fixed. 한 번 정리한 뒤로 자동화 profile은 1개만 운영. AI 모델 폴더가 새로 생기면 weekly로 1회 cleanup하는 게 효율적입니다.
같은 문제 겪는 분들에게
- 먼저 큰 파일부터 찾기:
Get-ChildItem -Recurse | Sort Length -Desc | Select -First 10으로 상위 파일 식별. 4GB짜리 weights.bin이 보이면 Chrome AI 모델입니다. - 로그인 세션은 다른 폴더에 있음: OptGuide만 삭제하면 cookies/login은 보존됩니다.
- profile 백업은 보관하지 말 것: 코드는 git으로, profile은 그때그때 새로 만드는 게 안전합니다.