이 기록은 img-compressor의 ImageCompressor 컴포넌트에 있는 실제 상태와 함수 흐름을 기준으로 합니다. 특정 라이브러리의 일반 사용법이 아니라, 파일 도구 UI에서 어떤 코드가 언제 필요한지, 그리고 왜 Web Worker 옵션을 켰는지를 정리했습니다.

초기 화면과 압축 실행은 필요한 코드가 다르다

첫 화면에서 사용자에게 필요한 것은 파일을 고를 수 있는 입력과 품질·크기 옵션입니다. 실제 압축 라이브러리는 파일을 선택하고, 리사이즈 후에도 추가 압축이 필요한 경우에만 필요합니다. 구현은 browser-image-compression을 정적 import하지 않고 해당 분기 안에서 동적으로 불러옵니다.

const { default: imageCompression } = await import(
  'browser-image-compression'
);

const compressedFile = await imageCompression(resizedFile, {
  maxSizeMB: 1,
  maxWidthOrHeight: Math.max(maxWidth, maxHeight),
  useWebWorker: true,
  fileType: resizedFile.type,
  initialQuality: quality,
});

이 구조는 모든 사용자가 압축 라이브러리를 다운로드할 필요가 없게 합니다. 다만 실제 효과는 번들 분석과 배포 환경에서 다시 측정해야 하며, 이 글은 동적 import가 존재한다는 구현 사실만 기록합니다. 성능 개선 수치를 추정으로 쓰지 않는 것이 중요합니다.

왜 압축 중에 화면이 멈춘 것처럼 느껴질까

브라우저에서 큰 이미지를 읽고 압축하면 사용자는 화면이 잠깐 멈춘 것처럼 느낄 수 있습니다. 파일 크기가 크고 여러 장을 처리할수록 이 문제가 커집니다. 압축 도구는 사용자가 품질값을 바꾸거나 결과를 확인하며 계속 화면을 조작하는 UI이기 때문에, 처리 중 반응성을 완전히 잃지 않는 것이 중요합니다. img-compressor는 useWebWorker: true를 전달해 가능한 환경에서 무거운 처리 일부를 Worker 쪽으로 넘깁니다. 단, 모든 브라우저와 모든 파일에서 같은 체감 결과를 보장한다고 쓰지는 않습니다.

Worker 옵션만으로 UX가 완성되지는 않는다

Web Worker를 사용해도 사용자는 현재 작업이 진행 중인지 알아야 합니다. 그래서 진행 상태, 현재 파일 번호, 전체 파일 개수, 처리 중 버튼 잠금이 함께 필요합니다. Worker는 내부 처리 부담을 줄이는 도구이고, 진행률 표시는 사용자 불안을 줄이는 UI입니다. 둘 중 하나만으로는 충분하지 않습니다. 여러 파일을 처리할 때 진행 상태를 어떻게 나누는지는 다중 파일 압축 UI 글에서 이어서 다룹니다.

또한 Worker 사용 가능 여부와 라이브러리 내부 구현은 브라우저 환경에 따라 달라질 수 있습니다. 실패했을 때 사용자에게 안내하고, 성공한 파일은 결과 목록에 남기는 예외 흐름이 같이 있어야 합니다.

현재 구현에서 의도적으로 하지 않는 일

이 컴포넌트에는 업로드 취소, 백그라운드 큐 우선순위, 서버 동기화가 들어 있지 않습니다. 파일을 하나씩 처리하는 동안 사용자가 새 파일을 추가하면 다음 결과 목록에 합쳐지는 구조이며, 처리 중인 한 장을 중단하는 별도 API는 없습니다. 이 한계를 문서에 남기면, 다음 기능을 넣을 때 무엇을 상태 모델에 추가해야 하는지 분명해집니다.

예를 들어 취소 기능을 추가하려면 단순히 버튼 하나를 넣는 것으로 끝나지 않습니다. 현재 작업을 식별할 값, 취소된 결과를 목록에 넣지 않는 조건, 진행률 초기화, Object URL 정리, 사용자가 다시 시도할 수 있는 UI가 함께 필요합니다. 이런 항목은 구현되지 않은 기능을 성능이나 사용자 경험 개선으로 포장하지 않고, 다음 설계 과제로 남겨 두는 편이 안전합니다.

큰 사진 한 장으로 먼저 느껴 본 것

Worker 옵션이 체감상 도움이 되는지 확인하는 가장 단순한 방법은 큰 사진 한 장을 넣고 처리 중에도 화면을 계속 조작할 수 있는지 보는 것이었습니다. 여러 장을 넣었을 때 현재 파일 번호가 멈추지 않고 갱신되는지, 작은 파일에서는 추가 압축을 건너뛰는 조건이 그대로 동작하는지도 같이 봤습니다. 압축 라이브러리 로드가 실패하는 상황을 흉내 냈을 때 결과 목록에 잘못된 파일이 끼어들지 않는지, 빌드 결과에서 이 라이브러리가 초기 청크에 과하게 들어가 있지 않은지는 화면이 아니라 빌드 산출물을 직접 열어 확인해야 하는 부분이었습니다.

운영 시 남겨야 할 기록

성능 관련 글은 수치가 없으면 쉽게 주장처럼 보입니다. 그래서 이 사이트에서는 체감 개선을 단정하지 않고, 구현 코드와 확인할 항목을 함께 적습니다. 다음 단계로는 동일 자산을 기준으로 Worker 옵션을 켰을 때와 껐을 때의 처리 시간, UI 입력 지연, 브라우저별 차이를 따로 기록하는 것이 좋습니다. 동적 import, 처리 상태, 다운로드 흐름 전체는 자료실에서 확인할 수 있습니다.