이미지 변환, 원본 하나로 여러 크기를 만들기

원본 하나만 보관하고 나머지는 만들어 씁니다

이미지 변형을 미리 만들어 보관하면 조합 수만큼 파일이 늘어납니다. 폭 5종에 형식 2종이면 원본 하나당 10개입니다. 요청 시 변환 방식은 원본만 보관하고 필요한 조합을 그때 만들어 캐시합니다. 보관 비용과 관리 부담이 줄고, 새 폭이나 새 형식을 추가할 때 전체를 다시 만들 필요가 없습니다. 대가는 처음 요청될 때의 변환 비용과 약간의 지연입니다. 그래서 선택 기준은 조합 수와 변경 빈도입니다. 조합이 많고 자주 바뀐다면 요청 시 변환이 유리하고, 조합이 적고 고정적이라면 미리 만들어 두는 쪽이 단순합니다.

변환 주소를 안정적으로 유지합니다

요청 시 변환에서 중요한 것은 같은 요청이 같은 주소로 오게 만드는 일입니다. 주소가 매번 달라지면 캐시가 쓰이지 않고 매번 변환 비용이 발생합니다. 그래서 세 가지를 고정합니다. 첫째, 매개변수 순서를 고정합니다. 둘째, 허용하는 폭 값을 목록으로 제한합니다. 임의의 폭을 허용하면 조합이 무한히 늘어납니다. 셋째, 품질 값을 기본값으로 통일합니다. 또 원본이 바뀔 때는 주소가 바뀌어야 하므로 원본 파일 이름에 식별자를 둡니다. 이 네 가지가 지켜지면 첫 요청 이후에는 변환 비용이 거의 발생하지 않습니다.

미리 만드는 방식의 보관량을 계산합니다

학습용 가정으로 계산합니다. 가정값은 이미지 800장이고 폭 5종과 형식 2종을 쓰며, 변형 파일 하나가 평균 30킬로바이트라고 두겠습니다. 조합 수는 10개이고 전체 변형 파일은 8,000개입니다. 보관량은 240,000킬로바이트, 즉 240메가바이트입니다. 이것이 중간 계산값입니다. 최종 판단은 변경 빈도로 합니다. 이미지가 매월 100장씩 추가되면 변형 파일도 매월 1,000개씩 늘고, 폭을 하나 추가하는 결정은 800장 전체를 다시 만드는 작업이 됩니다. 요청 시 변환에서는 이 재생성 작업이 없으므로 운영 부담이 줄어듭니다.

변환할 수 없는 이미지가 있습니다

결론을 뒤집는 조건은 원본의 성격입니다. 투명 배경이나 애니메이션이 포함된 이미지는 형식 변환에서 결과가 달라질 수 있어 자동 변환에 맡기기 어렵습니다. 그래서 그런 이미지는 목록으로 분리해 수동으로 관리합니다. 두 번째 조건은 저작권 표시입니다. 변환 과정에서 메타데이터가 제거되면 촬영자 정보가 사라질 수 있으므로, 표시가 필요한 이미지는 화면에 캡션으로 적어 둡니다. 세 번째는 접근 권한입니다. 원본이 비공개 저장소에 있으면 변환기가 읽을 수 있게 권한을 열어야 하고, 그 권한 범위를 원본 경로로 좁혀야 합니다.

성능 최적화 실행 전 점검표

• 조합 수와 변경 빈도로 변환 방식을 골랐다
• 매개변수 순서와 허용 폭 목록, 품질 값을 고정했다
• 원본 파일 이름에 식별자를 두어 교체 시 주소가 바뀌게 했다
• 투명 배경·애니메이션 이미지를 수동 관리 목록으로 분리했다