Home Assistant 캐시를 구성할 때는 먼저 폐기 가능한 데이터가 무엇인지 확인하세요. 영구 구성 경로 전체를 임시 스토리지로 옮기지 마세요.
“캐시”는 브라우저 프런트엔드 자산, TTS 출력, 통합별 임시 파일, 컨테이너의 /tmp, 운영 체제 페이지 캐시 또는 데이터베이스 작업 공간을 가리킬 수 있습니다. 각 계층의 소유 주체와 복구 방식은 서로 다릅니다. 사용자, 레지스트리, 구성, Recorder 상태 및 기타 기준 파일은 영구 스토리지에 보관하세요. 손실 및 메모리 사용량을 재시작 과정에서 테스트한, 문서화된 폐기 가능 경로에만 tmpfs 또는 RAM 기반 스토리지를 사용하세요.
경로를 옮기기 전에 캐시의 종류를 분류하세요
먼저 데이터의 소유 주체, 경로, 예상 최대 크기, 재생성 방법, 데이터가 사라질 경우의 결과를 확인하세요. 브라우저 캐시는 클라이언트에 있고, Home Assistant의 영구 애플리케이션 상태는 설정된 데이터 경로에 있으며, 통합 캐시는 통합마다 다릅니다. 임시 컨테이너 파일은 재시작 시 사라질 수 있습니다. 이들을 모두 하나의 전역 “캐시 디렉터리” 설정으로 해결해서는 안 됩니다.
Home Assistant TTS 사례는 특정 캐시 경로에 생성된 오디오를 RAM 기반 위치로 의도적으로 리디렉션한 제한적인 예입니다. 폐기 가능한 TTS 캐시 이동의 중요한 기준은 사용자가 다시 생성할 수 있는 디렉터리 하나를 대상으로 했다는 점이지, 구성 트리 전체를 옮긴 것이 아니라는 점입니다.
파일이 사라져도 ID, 기록, 설정, 대시보드 또는 통합 등록 정보가 손실되지 않는다는 것을 입증할 수 없다면 영구 데이터로 분류하세요. 가장 안전한 기본값은 영구 스토리지입니다. 최적화는 복구 책임이 명확해진 뒤에 진행하세요.
Home Assistant의 영구 상태와 Recorder는 영구 스토리지에 보관하세요
구성 마운트에 생성된 파일이 일부 들어 있다고 해서 캐시인 것은 아닙니다. 여기에는 인증 정보, 엔티티 및 기기 레지스트리, 자동화 상태, 구성, 사용자 지정 구성 요소, 기본 Recorder 데이터베이스가 포함될 수 있습니다. 이 전체 경로를 tmpfs에 두면 재부팅 시 데이터가 손실되고, 원래 기준 데이터로 사용하도록 만들어지지 않은 메모리 내용에 백업이 의존하게 됩니다.
ZimaSpace의 Home Assistant 영구 데이터 역할 설명은 올바른 첫 번째 판단 기준입니다. 스토리지 계층을 지정하기 전에 기준이 되는 상태 데이터와 다시 생성할 수 있는 캐시 및 임시 작업 데이터를 분리하세요.
앱 상태에는 SSD 또는 다른 신뢰할 수 있는 영구 파일 시스템을 사용하고, 데이터베이스 증가, 업그레이드 및 유지 관리를 위해 충분한 여유 공간을 확보하세요. 작고 폐기 가능한 캐시를 RAM으로 옮겨도 용량이 부족하거나 고장 난 영구 볼륨을 보완할 수는 없습니다.
메모리 제한을 두고 명시적으로 폐기 가능한 경로에만 tmpfs 사용
tmpfs는 쓰기 작업을 줄이고 매우 낮은 지연 시간을 제공할 수 있지만 호스트 RAM을 사용하며 컨테이너나 호스트가 중지되면 데이터가 사라집니다. 따라서 용량이 제한된 임시 데이터에는 적합하지만 재시작 후에도 필요한 데이터에는 적합하지 않습니다. 또한 임시 작업으로 인해 Home Assistant Core와 인접 서비스에 필요한 메모리까지 소모되지 않도록 마운트 크기를 설정해야 합니다.
최신 Docker Compose 가이드에서는 tmpfs 사용량이 메모리 용량에 포함되며, 컨테이너 메모리 예산에 비해 크기가 지나치게 크거나 상한이 없으면 공간 부족 또는 OOM이 발생할 수 있다고 설명합니다.
최대 용량을 설정하고, 최대 사용량을 모니터링한 뒤 컨테이너를 의도적으로 재시작하세요. 사용자, 설정, 기록, 통합은 그대로 유지되고 해당 경로만 자동으로 다시 채워져야 합니다. 애플리케이션이 디렉터리를 다시 생성하지 못하거나 디렉터리가 없으면 손상된 것으로 취급한다면 영구 저장소로 되돌리세요.
프런트엔드 캐시를 서버 저장소 문제가 아닌 클라이언트 문제로 다루기
서버가 정상이어도 브라우저나 앱이 프런트엔드 리소스를 캐시하기 때문에 한 브라우저에서 오래된 Home Assistant 페이지가 계속 표시될 수 있습니다. 서버 측 임시 파일을 지워도 해당 클라이언트 상태는 해결되지 않습니다. 반대로 브라우저 캐시를 지워도 Recorder의 디스크 I/O가 줄거나 Home Assistant 데이터베이스가 작아지지는 않습니다.
Home Assistant 사용자들은 프런트엔드 캐시가 브라우저 캐시라는 점을 명확히 구분합니다. 따라서 캐시 문제를 해결할 때는 먼저 증상이 한 클라이언트에서만 나타나는지, 서버 전체에서 나타나는지 확인해야 합니다.
검증을 위한 기준으로 깨끗한 브라우저나 비공개 프로필을 사용하세요. 새 클라이언트에서 문제가 없으면 수정은 프런트엔드 경로에 적용하세요. 모든 클라이언트에서 동일한 데이터 누락이나 서버 측 오류가 발생한다면 로컬 캐시를 계속 지우지 말고 Home Assistant 로그, 저장소, 통합 또는 데이터베이스 문제 해결로 돌아가세요.
재시작, 메모리 압박, 여유 공간 테스트로 임시 저장소 검증하기
캐시 또는 tmpfs 경로를 변경한 후에는 일반 및 최대 사용량, 호스트에서 사용 가능한 메모리, 컨테이너 메모리 압박, 영구 볼륨의 여유 공간, 재시작 후 동작을 측정하세요. 그런 다음 캐시를 생성하는 작업(TTS, 미디어, 커스텀 통합 처리 또는 알려진 다른 생성 작업)을 실행하고 예상대로 정리되는지 확인하세요.
일상적인 데이터베이스가 여유롭게 들어가더라도 임시 작업 공간이 필요한 작업을 위해 영구 저장소에 여유 공간을 남겨 두세요. RAM 캐시 덕분에 일반 쓰기 작업의 용량이 작아 보인다고 영구 볼륨을 가득 채우지 마세요. 업그레이드, 데이터베이스 유지 관리, 백업, 로그 급증에는 임시 공간이 훨씬 더 많이 필요할 수 있습니다.
모든 임시 경로가 사라졌다가 다시 생성될 수 있고, 영구 상태가 컨테이너와 호스트를 재시작한 뒤에도 유지되며, tmpfs 최대 사용량이 메모리 예산 이내이고, Home Assistant에 충분한 영구 저장 공간이 남아 있으면 통과입니다. 테스트 후 필수 설정이나 기록이 하나라도 사라지면 경로를 잘못 분류한 것이므로, 추가 조정 전에 해당 경로를 영구 저장소로 되돌려야 합니다.
지원 및 팁
더 읽어보기

Transformers에서 커뮤니티 모델을 불러오기 전에 확인할 사항
Transformers Jinja 샌드박스 업데이트를 활용해 모델의 출처, 채팅 템플릿, 원격 코드, 직렬화된 가중치, 격리된 첫 실행을 검토하세요.

Mirage를 로컬에서 실행: 한 장의 이미지로 OCR 및 객체 감지
Cactus Compute의 소형 로컬 비전 모델을 사용해 보고, 실제 입력으로 OCR 및 객체 추출을 검증하며, 메모리, 언어 및 개인정보 보호의 한계를 파악해 보세요.

홈 서버에서 Open WebUI 코딩 에이전트 예약 실행하는 방법
Open WebUI에서 보고 전용 코딩 에이전트 자동화를 설정하고, 터미널과 작업 공간을 선택한 다음 권한, 로그 및 오류 복구를 확인하세요.



