Home Assistant에는 “사용자 20명”이나 “사용자 100명”처럼 유용한 보편적 답이 없습니다. 로그인한 채 유휴 상태인 계정은 복잡한 대시보드를 렌더링하는 벽면 태블릿, 기록을 여는 휴대폰, 수천 개의 엔티티가 업데이트되는 동안 카메라 카드를 시청하는 여러 사용자와는 전혀 다른 부하를 만듭니다.
연결된 클라이언트 수와 각 클라이언트가 유발하는 작업을 측정하여 동시 사용 규모를 정하세요. 실제로 사용하는 대시보드, WebSocket 업데이트, 서버 작업, 네트워크 경로가 여러분이 허용할 수 있는 응답 목표를 충족하지 못하기 시작하는 지점이 실질적인 한계입니다.
사용자 계정이 아니라 연결된 클라이언트 수를 세세요
계정 100개를 만든다고 해서 동시 세션이 100개가 되는 것은 아닙니다. 반대로 한 사람이 브라우저, 휴대폰, 태블릿, 키오스크를 동시에 연결할 수도 있습니다.
Home Assistant의 WebSocket 통합은 sensor.connected_clients를 현재 연결된 WebSocket 클라이언트 수로 표시할 수 있습니다. 해당 수치를 워크로드를 재현하는 동안 동시성 지표로 사용하세요.
클라이언트 수를 서버 CPU, 메모리 압박, 네트워크 처리량, 작업 지연 시간과 함께 기록하세요. 그 뒤에 어떤 워크로드가 있는지 모른 채 연결 수만으로는 용량을 판단할 수 없습니다.
프런트엔드 비용은 상태 업데이트와 대시보드 작업에 따라 달라집니다
프런트엔드는 WebSocket 연결을 설정하고 브라우저와 Home Assistant의 상태를 동기화된 상태로 유지합니다. 각 클라이언트는 자신이 여는 대시보드도 렌더링해야 하므로 서버보다 먼저 클라이언트 하드웨어와 사용자 지정 카드가 한계에 도달할 수 있습니다.
현재 프런트엔드 아키텍처는 프런트엔드가 WebSocket API를 통해 핵심 상태와 추가 구독을 수신하는 방식을 설명합니다. 따라서 사용량이 많은 설치 환경에서는 초기 페이지 로드 후에도 지속적인 업데이트 작업이 발생합니다.
모든 클라이언트에서 빈 테스트 페이지를 여는 대신, 가정에서 실제로 사용하는 대시보드 구성을 기준으로 벤치마크하세요.
엔티티 업데이트 빈도가 높으면 사용자 수가 많지 않아도 클라이언트에 부담을 줄 수 있습니다
자주 변경되는 센서가 수천 개 있는 시스템은 대부분 정적인 엔티티를 보는 더 많은 사용자보다 훨씬 많은 프런트엔드 작업을 발생시킬 수 있습니다. 이는 구형 태블릿과 저전력 벽면 패널에서 특히 두드러집니다.
Home Assistant 이슈에는 대량의 엔티티 업데이트로 인해 보이는 대시보드 자체는 단순한데도 대시보드 클라이언트가 과부하된 사례가 기록되어 있습니다.
이 사례가 보편적인 임계값을 정해 주는 것은 아니지만, “사용자 수”가 유일한 기준으로 적절하지 않은 이유를 보여 줍니다. 연결 수와 함께 초당 업데이트 수와 클라이언트 응답성도 측정하세요.
그대로 참고할 수 있는 가정용 최대 사용자 수는 공개되어 있지 않습니다
비정상적으로 대규모인 배포에 관한 커뮤니티 질문은 이러한 불확실성을 보여 줍니다. 약 200명의 사용자에 관한 토론에서도 명확한 공식 지원 최대치가 제시되지 않았으며, 해당 규모는 당연히 가능하다고 가정하기보다 테스트해야 하는 이례적인 사용 사례로 다뤄졌습니다.
일반적인 가정에서는 공급업체가 제시하는 최대 세션 수를 찾아다닐 필요가 없습니다. 커뮤니티 게이트웨이, 공동 건물, 연구실 또는 기타 다중 사용자 환경에서는 서버가 기술적으로 연결을 유지할 수 있더라도 Home Assistant가 적합한 사용자 인증 및 접근 관리 플랫폼이 아닐 수 있습니다.
ZimaSpace의 동시 워크로드 기반 용량 산정 방법을 여기에 적용할 수 있습니다. 용량은 등록된 전체 계정 수가 아니라 현실적으로 가장 많은 작업이 겹치는 상황을 기준으로 산정해야 합니다.
한 지표에서 반복적으로 문제가 발생할 때까지 단계별 테스트를 실행하세요
| 단계 | 측정 항목 | 중단 조건 |
|---|---|---|
| 활성 클라이언트를 소규모 그룹으로 추가 | 연결된 클라이언트 수 | 대표적인 동시 사용량에 도달 |
| 실제 대시보드 열기 | 초기 렌더링 및 상호작용 지연 | 사용자가 반복적으로 체감하는 지연 발생 |
| 일반적인 엔티티 트래픽 생성 | WebSocket/업데이트 부하 | 클라이언트가 업데이트를 따라가지 못함 |
| 일반적인 작업 실행 | 서버 작업에서 장치까지의 지연 시간 | 제어 지연 시간이 크게 증가 |
| 최대 사용량에서 반복 | CPU, 메모리, 네트워크, 클라이언트 부하 | 동일한 제한 계층이 다시 나타남 |
처음으로 반복적으로 문제가 발생한 지점보다 한 단계 낮은 수준을 용량으로 정하고, 백업, 업데이트, 카메라 트래픽, 예기치 않은 급증에 대비한 여유를 남겨 두세요. 서버 작업은 여전히 빠른데 오래된 태블릿 하나만 느려진다면 서버를 교체해도 실제로 사용할 수 있는 동시성이 늘어나지 않을 수 있습니다.
FAQ
Home Assistant 사용자 계정 20개가 동시 사용자 20명을 의미하나요?
아니요. 계정은 신원을 나타내고, 동시성은 활성 클라이언트 연결과 해당 클라이언트가 생성하는 작업을 의미합니다. 한 사용자가 여러 클라이언트를 사용할 수도 있고, 많은 계정이 완전히 유휴 상태일 수도 있습니다.
대시보드가 단순할수록 항상 더 많은 사용자를 연결할 수 있나요?
클라이언트 렌더링 작업은 줄일 수 있지만, 서버 용량은 엔티티 업데이트 빈도, WebSocket 트래픽, 기록 쿼리, 카메라, 네트워크 경로, 백그라운드 서비스에도 영향을 받습니다. 전체 워크로드를 측정하세요.
지원 및 팁
더 읽어보기

Home Assistant 데이터베이스에 유지 관리 또는 교체가 필요한 징후
대규모 Home Assistant 데이터베이스에는 일반적으로 보존 기간 관리 또는 정리 작업이 필요하지만, 반복되는 손상이나 무결성 오류는 교체를 고려해야 한다는 더 강력한 신호입니다.

Home Assistant는 업그레이드를 중단하지 않고 외부 데이터베이스를 사용할 수 있나요?
외부 Recorder 데이터베이스는 업그레이드 후에도 유지될 수 있지만, 자체적인 가용성, 스키마 마이그레이션, 백업, 복원 및 버전 관리 책임이 추가됩니다.

DNS가 Home Assistant 연결 실패의 원인인지 테스트하는 방법
영향을 받는 경로에서 동일한 호스트 이름을 테스트하고, 직접 IP 연결 가능 여부를 비교하며, A/AAAA 응답을 확인하여 Home Assistant DNS 장애를 입증하세요.

