Immich는 왜 원격 연결보다 LAN에서 더 빠르게 느껴질까요?

에바 왕

IceWhale author

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

Why Does Immich Feel Faster on LAN Than on Remote Connections?

Immich는 일반적으로 LAN에서 더 빠르게 느껴집니다. 로컬 클라이언트가 더 짧고 지연 시간이 낮은 경로를 통과하며, 게이트웨이 수가 적고 가정용 인터넷 연결이 병목으로 작용하지 않기 때문입니다.

원격 사용에서는 ISP 업로드 제한, 모바일 또는 호텔 네트워크, DNS, TLS 종료, 리버스 프록시, VPN 또는 오버레이, 때로는 릴레이가 추가될 수 있습니다. 이러한 요소들이 모든 요청을 동일한 방식으로 느리게 만드는 것은 아닙니다. 썸네일, 메타데이터 쿼리, 원본 다운로드, 업로드, 검색 호출은 경로의 서로 다른 부분에 부하를 주므로, “원격 Immich”를 하나의 성능 모드로 간주하기 전에 동일한 작업을 비교해야 합니다.

LAN에서는 WAN 경로의 변동성이 대부분 사라집니다

유선 또는 신호가 강한 Wi-Fi LAN에서는 일반적으로 클라이언트와 서버 사이에 로컬 스위칭 또는 라우팅 홉이 몇 개밖에 없습니다. 왕복 시간이 짧고 경로 대부분을 가정에서 제어하므로, 소규모 API 호출과 다수의 썸네일 요청도 네트워크 대기 시간이 거의 없이 완료될 수 있습니다.

NAT 순회의 직접 연결과 릴레이 연결 모델은 이러한 차이를 설명하는 데 도움이 됩니다. 원격 클라이언트는 동일한 서버에 직접 WAN 터널을 통해 연결하거나 릴레이를 거칠 수 있지만, LAN 클라이언트는 단순히 로컬 경로를 사용합니다. 전송 조건이 달라도 애플리케이션 엔드포인트는 동일할 수 있습니다.

더 빠른 LAN이 모든 워크로드에서 서버가 정상적으로 작동한다는 의미는 아닙니다. 로컬 지연 시간이 낮으면 네트워크 대기 시간이 짧아 비효율적인 요청이나 느린 스토리지가 가려질 수 있습니다. 두 경로에 모두 영향을 미치는 백엔드 병목을 원격 경로 문제로 오인하지 않도록 비교 시 서버 지표도 함께 확인하세요.

가정의 업로드 속도는 원격 다운로드 용량이 됩니다

집 밖에서 누군가 홈 서버의 사진을 열면 서버는 가정용 인터넷의 업로드 방향을 통해 데이터를 전송합니다. 많은 가정용 인터넷 회선은 로컬 이더넷이나 Wi-Fi보다 업스트림 용량이 훨씬 작으므로, LAN에서는 즉시 열리는 원본 사진과 대형 미리보기가 원격에서는 대역폭 제한을 받을 수 있습니다.

가족 원격 접속에 관한 커뮤니티 게시글은 가정에서 연결성 이상의 요소를 평가하는 이유를 보여 줍니다. 비기술 사용자도 쉽게 사용할 수 있도록 경로가 단순하고 안정적이어야 합니다. 성능, 인증, 사용자 경험은 모두 실용적인 원격 경로의 일부입니다.

작은 메타데이터 제어, 필터 또는 로그인 작업은 느린데 대용량 전송은 예상 속도를 내는 경우, 대역폭이 올바른 설명은 아닙니다. 이러한 패턴은 지연 시간, 요청 라우팅, 프록시 동작, DNS 또는 서버 응답 시간이 원인일 가능성이 더 높다는 것을 의미합니다.

프록시와 터널은 처리 및 구성 경계를 추가합니다

원격 요청은 프록시에서 TLS가 종료되거나, 다른 컨테이너 네트워크를 통과하거나, Immich에 도달하기 전에 암호화된 오버레이를 거칠 수 있습니다. 구성이 잘된 계층은 오버헤드를 거의 추가하지 않을 수 있지만, 각 계층은 버퍼링, 헤더 처리, 타임아웃 정책, 경로 선택 또는 MTU 문제로 인해 특정 요청에 영향을 줄 수 있는 지점을 하나씩 추가합니다.

원격 필터링 지연에 관한 2026년 Immich 사용자 보고에서는 릴레이 성능도 검토한 끝에 엔드포인트 경로 구성 문제가 원인으로 확인되었습니다. 이 사례가 유용한 이유는 서로 다른 두 메커니즘이 “원격이 느리다”는 비슷한 증상을 만들었기 때문입니다.

페이지 하나를 불러온 결과만으로 원격 접속 기술을 바꾸지 마세요. 먼저 문제가 발생하는 작업이 전송인지, API 요청인지, 인증인지, 연결 설정인지 확인하세요. 리버스 프록시는 포화된 가정용 업링크를 해결할 수 없고, 더 빠른 터널도 느린 데이터베이스 쿼리를 해결할 수 없습니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

캐싱으로 인해 LAN과 원격 테스트가 동일하지 않을 수 있습니다

LAN에 연결된 휴대폰에는 이미 썸네일, 세션 상태, DNS 응답 또는 최근에 액세스한 자산이 캐시되어 있을 수 있지만, 원격 테스트는 더 비어 있는 캐시 상태에서 시작할 수 있습니다. 한 클라이언트가 서버에서 요청하는 데이터가 더 적기 때문에 이 두 실행을 비교하면 네트워크 차이가 실제보다 크게 보일 수 있습니다.

스토리지 지연 시간에 관한 ZimaSpace의 설명은 성능을 비교할 때 캐시와 워크로드 상태를 통제해야 한다는 점을 뒷받침합니다. 경로 테스트에도 동일한 원칙을 적용하세요. 가능한 경우 동일한 계정, 자산 세트, 클라이언트, 캐시 상태를 사용해야 합니다.

두 테스트를 동일한 경로로 강제하거나 서버 측 응답 시간 자체가 동일하게 증가하는데도 차이가 계속된다면, LAN과 WAN의 차이로는 더 이상 불일치를 설명할 수 없습니다. 이때는 네트워크 토폴로지를 계속 최적화하기보다 애플리케이션이나 호스트를 점검하세요.

동일한 작업으로 경로를 비교하세요

다음 네 가지 작업을 선택하세요. 동일한 앨범 로드, 동일한 대용량 사진 열기, 미리 알고 있는 동일한 검색 실행, 동일한 테스트 파일 업로드입니다. 클라이언트에서 관찰된 시간, 가능한 경우 서버 요청 시간, 왕복 지연 시간, 전송 처리량, 원격 경로가 직접 연결인지 프록시인지 릴레이인지 기록하세요.

알려진 캐시 상태에서 LAN 실행과 원격 실행을 비교한 다음, 한 번에 하나의 경로 변수만 변경하세요. Tailscale의 직접 연결 및 릴레이 연결에 관한 설명은 경로를 분류하는 데 유용한 모델을 제공합니다. 대용량 전송만 개선된다면 대역폭이 더 강한 제한 요소입니다.

변경한 경로가 서버 워크로드를 바꾸지 않으면서 메커니즘이 예측한 작업을 개선한다면 진단을 받아들이세요. 가족의 접속 및 성능 목표를 충족하는 가장 단순한 원격 설계를 유지하세요. 추가 프록시, 터널 또는 릴레이 계층은 명확한 연결성 또는 보안상의 이유가 있을 때만 사용해야 합니다.