"로컬 LLM 한 달 돌렸더니 디스크가 가득 차서 앱이 멈췄어요."
흔한 사고. 로컬 LLM 운영의 가장 큰 함정은 디스크 / RAM 의 점진 누적. 본 글은 운영 흐름에서 도출한 4가지 안정 운영 노하우를 정리합니다.
결론 먼저, 4가지 안정 운영 노하우
네 가지 영역의 평소 사용량과 위험선을 한 화면에 본다. RAM 슬라이더는 모델 1개 로드 후 시스템 여유까지 합친 평소값이고, 디스크 슬라이더는 6개월 누적 평균이다.
각 영역 평균값은 100~500명 단톡방 운영 흐름 기준. 큰 단톡방은 로그 사용량이 더 큼.
1. 디스크 관리
GGUF 모델 파일 위치
Replyer 가 모델을 저장하는 폴더:
- macOS,
~/Library/Application Support/Replyer/models/*.gguf - Windows,
%APPDATA%\Replyer\models\*.gguf
모델별 디스크 + RAM 동시 비교
모델 4종의 디스크 점유 (GB) 와 load 후 RAM 사용 (GB) 을 가로 막대로 같이 본다. 디스크는 SSD 1회 비용, RAM 은 매 운영 사이클 비용이다.
막대를 보면 Q4 3B 는 8GB 노트북에서도 OS / 브라우저와 공존 가능. 27B 는 RAM 32GB+ 가 안전선이다.
안 쓰는 모델 정리
Replyer 의 [Settings → 디스크 사용량] 카드에서:
- 현재 사용 중 모델 / 다운로드된 다른 모델 / 총 사용 디스크 가시화
- [정리] 버튼 또는 모델별 [삭제] 로 안 쓰는 모델 제거
- 정리 후 디스크 여유 즉시 확인
수동 정리, 위 경로의 models/ 폴더에서 안 쓰는 .gguf 파일 직접 삭제도 가능.
2. RAM 관리
모델 1개만 로드
Replyer 는 동시에 1개 모델만 RAM 에 로드. 모델 변경 시 옛 모델 unload + 새 모델 load. 단, 모델 변경 시 첫 응답이 5~10초 추가 (load 시간), 자주 모델 바꾸면 응답 지연 누적 → default 모델 정착이 안정.
RAM 압박 신호 3가지
모델 load 후 RAM 부족 신호:
- 응답 속도 갑작스러운 저하 (3초 → 15초), swap 발생
- OS 알림 "메모리 부족" 또는 다른 앱 강제 종료
- Replyer 응답 실패 "Failed to load model from file" → R66+ 부터 자동 복구
대응, 다른 무거운 앱 (Chrome 탭 50개 / 비디오 / VM) 종료 또는 더 작은 모델 선택.
3. 로그 / 캐시 관리
Replyer 의 로그 / 데이터 위치
logs/시스템 / 응답 / 에러 로그 JSONLconversations/단톡방별 대화 JSONLbackups/자동 백업 zipagent_history/페르소나 버전 히스토리
단톡방 규모별 일 로그 누적
단톡방이 커질수록 로그가 모델보다 빠르게 디스크를 차지한다.
2,000명+ 단톡방은 월 36GB 까지 가능, 정기 정리 필수.
자동 정리 정책
Replyer 의 [Settings → 로그 정리]:
- 30일+ 옛 로그 자동 삭제 (default)
- 90일+ 옛 대화 자동 삭제 (default)
- 사용자가 보존 기간 조정 가능
수동 [정리] 버튼으로 즉시 정리 가능.
4. 자동 복구 (R66+ 도입)
R66 (v0.12.7) 부터 디스크 / 모델 자동 복구 기능. 다운로드 중단 / 디스크 가득 등으로 GGUF 파일 손상 시 Replyer 가 load 시도, "Failed to load model from file" 응답이 오면 자동으로 손상 파일 삭제 + 재다운로드 시도. 사용자에게는 친절한 메시지 ("부분 다운로드 / build 미지원 / RAM 부족" 3가지 가능 원인) 가 전달된다. R66 이전엔 같은 문제가 무한 루프 (load 실패 → 재다운로드 → 또 실패) 였음.
config.json 손상 자동 알림
config.json 파일이 손상되면 시작 시 banner 알림 (top-fixed amber), 가장 가까운 .bak 파일로 복원 옵션 제공, 클릭 한 번으로 복원 + 자동 새로고침.
Filelock 손상 자동 정리
R66 부터 stale filelock 자동 정리. 30분+ 옛 lock 자동 무시 (옛은 5분, false positive 많음), .incomplete mtime <60s 면 active 로 간주 → lock 보호. 모델 다운로드 끊김 후 재시도 안전.
장기 운영 사용자의 실제 디스크 / RAM
6개월+ 운영 흐름 평균, 디스크 (Replyer 데이터) 5~15GB, 사용 중 모델 1~2개, RAM 사용 4~10GB, 월 로그 누적 0.5~3GB (정리 전), 월 정리 빈도 1~4회. 대부분 default 설정 + 월 1회 디스크 사용량 확인 + 분기 1회 안 쓰는 모델 정리로 6개월+ 안정.
자주 묻는 질문
Q. 모델 다운로드 중에 디스크 가득 차면 어떻게 되나요?
R66+ 부터 다운로드 사전 디스크 체크. 모델 크기 + 1GB 여유가 없으면 다운로드 거부 + 친절한 메시지. 다운로드 중에 다 차면 부분 다운로드 → R66+ 자동 정리 + 재시도.
Q. RAM 압박 신호 보이면 어떻게 해야 하나요?
- 즉시, 다른 무거운 앱 종료 (Chrome 탭 / 비디오 등)
- 단기, 더 작은 모델 (예, Qwen 2.5 3B) 로 변경
- 장기, RAM 업그레이드 또는 데스크톱 운영 환경 검토
GPU 없는 노트북 가이드 의 RAM 권장값 매트릭스 참고.
Q. 로그 파일을 직접 삭제해도 되나요?
가능. logs/ / conversations/ 폴더의 .jsonl 파일 직접 삭제. Replyer 운영에 영향 X. 단 옛 대화 분석 (Diagnostics 의 키워드 / 라우팅) 데이터도 함께 사라짐.
Q. 백업 zip 이 누적되는데 정리 가능한가요?
가능. backups/ 폴더의 .zip 파일 직접 삭제 또는 Replyer 의 [Backup → 옛 백업 정리]. 1~2개월 최근 백업만 유지가 적절.
Q. 자동 복구가 동작 안 하면 어떻게 하나요?
- Replyer 종료
- 위 경로의
models/폴더에서 손상 GGUF 파일 직접 삭제 - Replyer 재시작 → 새 모델 다운로드
Q. 디스크 / RAM 모니터링 자동화 가능?
Replyer 의 [Settings → 시스템 리소스] 또는 /api/system/resources 엔드포인트. 자체 스크립트로 일 단위 점검 가능. 일반 운영자는 [Settings] 페이지 월 1회 확인이면 충분.
다음 단계
본인 단톡방에 자동 답장을 도입하려면 Replyer 다운로드 에서 본인 OS 빌드를 받고, 단계별 사용법은 사용 매뉴얼 을 참고하세요.