왜 Immich는 다양한 클라이언트에서 반응성이 떨어지게 느껴질까요?

Immich가 한 클라이언트에서 더 느리게 느껴질 수 있는 이유는 서버가 응답한 후에도 클라이언트 측 렌더링, 이미지 디코딩, 캐시 상태, 네트워크 경로에서 추가 작업이 발생하기 때문입니다.

가족 구성원은 Immich 서버, 스토리지, 데이터베이스가 그대로인 상태에서 데스크톱 브라우저, 오래된 휴대폰, 태블릿으로 같은 라이브러리를 탐색할 수 있습니다. 그런데도 어떤 기기에서는 타임라인이나 미리보기를 여는 데 더 오래 걸릴 수 있습니다. 전체 요청 처리 과정에는 서버 외부에서 수행되는 작업도 포함되기 때문입니다. 따라서 유용한 비교 기준은 서버 응답 시간과 각 클라이언트가 결과를 수신하고, 디코딩하고, 캐시하고, 화면에 그리는 데 추가로 걸리는 시간을 나누어 보는 것입니다.

Immich가 응답한 후 수행되는 작업은 클라이언트에 따라 달라집니다

Immich 요청은 서버가 JSON, 썸네일 URL 또는 이미지 응답을 준비했다고 끝나지 않습니다. 클라이언트는 해당 응답을 처리하고, 인터페이스를 업데이트하고, 렌더링을 예약하고, 사용자 입력에 반응해야 합니다. 따라서 빠른 서버라도 기기나 브라우저가 반환된 데이터를 눈에 보이고 상호작용 가능한 화면으로 바꾸는 데 추가 시간을 쓰면 클라이언트는 느리게 느껴질 수 있습니다.

이 차이는 특히 브라우저에서 중요합니다. 브라우저에서는 JavaScript, 이벤트 처리, 스타일 계산, 레이아웃, 페인팅 작업 대부분이 메인 스레드 작업을 두고 경쟁합니다. 오래된 휴대폰이나 작업이 많은 브라우저가 이 스레드를 더 오래 점유하면, Immich API가 더 빠른 데스크톱과 거의 같은 시간에 완료되더라도 탭과 스크롤이 끊길 수 있습니다.

따라서 서버 CPU나 데이터베이스 지연 시간만 비교하면 실제 사용 경험의 일부를 놓치게 됩니다. ZimaSpace의 네이티브 클라이언트와 브라우저 클라이언트에 관한 설명에서도 같은 시스템 원리를 확인할 수 있습니다. 하나의 백엔드가 서로 다른 클라이언트 실행 경로에 데이터를 제공할 수 있다는 점입니다. Immich에서는 지연이 응답이 도착하기 전에 발생하는지, 아니면 클라이언트가 응답 처리를 시작한 후에 발생하는지를 먼저 확인해야 합니다.

이미지 렌더링 때문에 빠른 응답도 느리게 느껴질 수 있습니다

사진 탐색에서는 클라이언트 간 차이가 더 뚜렷하게 나타납니다. 갤러리는 단순한 텍스트와 API 메타데이터만으로 구성되지 않기 때문입니다. 클라이언트는 여러 썸네일이나 더 큰 미리보기를 요청하고, 일부를 메모리에 유지하며, 압축된 이미지 데이터를 디코딩하고, 화면 크기에 맞게 조정하고, 사용자가 계속 스크롤하는 동안 여러 이미지를 합성할 수 있습니다. 같은 Immich 자산을 요청하더라도 이러한 로컬 작업의 양과 시점은 기기마다 크게 다를 수 있습니다.

JPEG와 WebP 같은 압축 형식은 픽셀을 표시하기 전에 이미지 디코딩 과정을 거쳐야 합니다. 더 빠른 CPU, 최적화 수준이 높은 디코더, 더 넉넉한 가용 메모리, 서로 다른 브라우저 엔진은 이 단계를 단축할 수 있습니다. 성능이 낮은 클라이언트에서는 네트워크 전송이 먼저 끝나고, 사용자가 실제로 기다리는 부분은 디코딩과 페인팅이 될 수 있습니다.

따라서 서버가 고해상도 미리보기를 빠르게 생성할 수 있다고 해서 더 크고 선명한 미리보기가 공짜인 것은 아닙니다. 고해상도 이미지는 디코딩된 픽셀을 저장하는 데 더 많은 메모리가 필요하고, 크기를 조정하고 그리는 작업도 더 많이 요구합니다. 전체 미리보기를 열거나 밀집된 타임라인을 빠르게 스크롤할 때만 특정 클라이언트가 느려지고, 단순한 메타데이터 화면은 계속 반응한다면 서버 전체의 용량 한계보다 이미지 렌더링 경로가 더 유력한 원인입니다.

캐시가 준비된 상태에서는 반복 방문 속도가 달라집니다

이미 앨범을 탐색한 클라이언트는 새 클라이언트가 아직 가져와 처리해야 하는 썸네일, 스크립트, 메타데이터 또는 디코딩된 리소스를 재사용할 수 있습니다. 따라서 두 번째 탐색은 더 짧아지지만, 서버의 처리 용량이 갑자기 증가한 것은 아닙니다. 첫 번째 탐색보다 더 준비된 상태에서 시작했기 때문에 요청 처리 경로의 일부가 사라진 것입니다.

실제 브라우저 연구에서도 캐시 적중률은 브라우저, 버전, 기기, 시간에 따라 달라지는 것으로 나타납니다. Facebook의 구체적인 비율이 Immich의 벤치마크는 아니지만, 작동 원리는 중요합니다. 두 클라이언트가 같은 서버에 접속하더라도 로컬 캐시의 이력이 다를 수 있습니다. 따라서 캐시가 준비된 데스크톱 브라우저가 새로 설치한 휴대폰 앱보다 훨씬 반응성이 좋아 보일 수 있지만, 그렇다고 어느 클라이언트가 본질적으로 더 빠르다고 단정할 수는 없습니다.

캐시는 전후 비교 테스트를 오해하게 만들기도 합니다. 같은 앨범을 여러 번 새로 고치면 이후 실행에서는 다운로드와 처리 작업이 줄어들 수 있으므로, 가장 빠른 실행 결과는 대표적인 가족 사용 환경이 아니라 재사용 효과를 측정하는 경우가 많습니다. 클라이언트를 비교하려면 콜드 상태 또는 새로 연 경로와 반복 경로를 모두 기록하세요. 두 결과의 차이 자체가 각 클라이언트가 로컬 재사용에 얼마나 의존하는지 보여주는 유용한 증거입니다.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

클라이언트 차이만으로 지연을 설명하기 어려운 경우

서로 다른 여러 클라이언트가 같은 작업 부하에서 동시에 느려진다면 클라이언트 차이는 더 이상 주된 원인이라고 보기 어렵습니다. 데스크톱 브라우저, 휴대폰, 태블릿이 모두 타임라인 데이터나 미리보기 응답을 기다리는 시간이 길어지고, 동시에 서버 CPU, 스토리지 지연 시간, 데이터베이스 활동 또는 네트워크 사용량이 증가한다면 특정 클라이언트 구현보다 공유 인프라가 응답성의 하한을 결정하고 있을 가능성이 큽니다.

종단 간 시간은 측정하기 쉬운 구성 요소 하나보다 더 많은 요소를 포함해야 합니다. Datadog의 지연 시간 분석에서도 왕복 지연 시간에는 데이터베이스 자체 외에도 네트워크 전송, 프록시, 연결 풀, 애플리케이션 디코딩이 포함될 수 있다고 설명합니다. Immich에도 같은 원칙이 적용됩니다. 데이터베이스 수치가 정상이라고 해서 요청 시작부터 렌더링된 결과가 나타날 때까지의 다른 구간에서 발생하는 지연을 배제할 수는 없습니다.

유용한 경계 테스트는 대칭성을 확인하는 것입니다. 같은 LAN과 앨범을 사용하는 다른 클라이언트는 빠른데 한 클라이언트만 느리다면 클라이언트 실행, 캐싱 또는 로컬 네트워크에 더 큰 비중을 두고 조사해야 합니다. 반대로 모든 클라이언트가 거의 같은 시점에 동일한 지연 임계값에 도달한다면, 특히 가져오기, 썸네일 생성, 백업 또는 기타 호스트 작업 중에 그렇다면 원인은 클라이언트 간 차이에서 공유 서버, 스토리지 또는 네트워크 제약으로 옮겨간 것입니다.

통제된 클라이언트 테스트로 경계를 찾으세요

대표적인 앨범 하나를 선택하고 서버 버전, 네트워크 위치, 계정, 이미지 집합, 백그라운드 작업 상태를 동일하게 유지하세요. 각 클라이언트를 한 번에 하나씩 테스트하면서 관찰 가능한 세 가지 시간을 기록합니다. 초기 타임라인 로드, 같은 대형 미리보기 열기, 고정된 사진 범위를 빠르게 스크롤하는 데 걸리는 시간입니다. 또한 각 실행 중 서버에서 리소스 급증이 나타나는지도 기록하세요. 샘플 간 백엔드 작업 부하가 달라지면 클라이언트 비교가 유효하지 않기 때문입니다.

각 클라이언트를 의도적으로 콜드 상태에서 한 번 실행한 다음, 바로 이어서 다시 실행하세요. 성능 테스트에서는 일반적으로 첫 화면과 반복 화면 결과를 구분합니다. 캐시가 채워지면 이후 요청에서 작업이 줄어들기 때문입니다. Immich에서는 콜드 상태에서 웜 상태로 바뀔 때의 차이가 재사용이 사용 경험을 얼마나 바꾸는지 보여주며, 같은 캐시 조건에서 클라이언트 간 차이를 비교하면 기기나 애플리케이션 자체에 더 가까운 차이를 확인할 수 있습니다.

최소 세 번의 실행에서 차이가 반복되고, 서버와 네트워크 조건이 비슷한 동안 더 빠른 클라이언트가 계속 더 빠를 때만 해당 차이를 클라이언트에 국한된 것으로 보세요. 모든 클라이언트가 함께 느려진다면 클라이언트 조정을 중단하고 공통 경로를 살펴보세요. 이미지가 많은 작업에서만 차이가 난다면 디코딩과 렌더링에 집중하세요. 첫 실행에서만 차이가 나타난다면 지속적인 서버 용량 문제가 아니라 캐시 상태가 더 타당한 결론입니다.