0. 들어가며: 이미지 변환은 '자르기' 이전에 '판단'이다

디자이너가 하루에 다루는 이미지 변환 작업 중 체감 난이도 1위는 의외로 화려한 합성이 아닙니다.
"이 사진을 1:1, 4:5, 16:9, 1.91:1로 각각 뽑아주세요" 같은 멀티 비율 리사이즈 요청입니다.

이건 단순 노동처럼 보이지만 실제로는 세 가지 판단이 동시에 일어납니다.

첫째, 무엇을 버릴까(크롭 영역).
둘째, 어떻게 줄일까(리샘플링 알고리즘).
셋째, 어디에 쓸까(플랫폼 규격과 압축).

이 세 축을 모르면 결과물은 늘 아쉽습니다. 인물의 턱이 잘리거나, 로고가 흐려지거나, 픽셀이 계단처럼 튀거나, 업로드하자마자 플랫폼이 다시 압축해서 얼룩이 생기죠.

이 글은 감각적인 조언 대신 계산 가능한 기준을 다룹니다.
종횡비 수식, 커버/컨테인 로직, 리샘플링 커널의 차이, 세이프 에어리어 설계, 스마트 크롭 알고리즘의 원리, 그리고 CSS와 CLI 레벨의 실전 코드까지 순서대로 쌓아갑니다.

1. 종횡비의 수학: 비율은 감각이 아니라 나눗셈이다

1-1. 정의와 기본 계산

종횡비(aspect ratio)는 가로 ÷ 세로입니다.
1920×1080 이미지의 비율값은 1920/1080 = 약 1.7778. 이것을 기약분수로 정리하면 16:9입니다.

정리 방법은 최대공약수(GCD)로 양쪽을 나누는 것입니다.
1920과 1080의 GCD는 120이므로 1920/120 = 16, 1080/120 = 9.

function ratio(w, h) {
  const gcd = (a, b) => b ? gcd(b, a % b) : a;
  const g = gcd(w, h);
  return `${w/g}:${h/g}`;
}
ratio(1920, 1080); // "16:9"
ratio(3000, 2000); // "3:2"
ratio(1284, 2778); // "214:463"  ← 기약이 안 예쁜 경우도 많다

마지막 예시가 중요합니다. 실제 촬영/스크린샷 원본은 깔끔한 정수비가 아닌 경우가 훨씬 많습니다.
그래서 실무에서는 "정확한 기약분수"보다 목표 비율값(소수)과의 차이를 보는 편이 빠릅니다.

1-2. 자주 쓰는 비율과 성격

여기서 꼭 기억할 숫자 하나. 1.7778과 0.5625는 서로 역수입니다(16:9 ↔ 9:16).
비율은 방향만 바꿔도 완전히 다른 구도 언어가 됩니다. 가로 16:9는 맥락과 배경을 보여주고, 세로 9:16은 피사체를 압도적으로 세웁니다.

1-3. 픽셀 종횡비(PAR)라는 함정

대부분의 디지털 이미지는 픽셀이 정사각형(PAR 1:1)입니다.
하지만 일부 방송/DVD 계열 영상 소스는 픽셀 자체가 직사각형인 비정방 픽셀을 씁니다.

이 경우 저장 해상도(Storage AR)와 표시 비율(Display AR)이 다릅니다.
예: 720×480 저장 + PAR 32:27 → 표시상 16:9. 프레임을 그대로 캡처해 이미지로 쓰면 인물이 홀쭉해 보이는 왜곡이 발생합니다.

2. 비율을 바꾸는 네 가지 전략

원본 비율 ≠ 목표 비율일 때 선택지는 사실 네 개뿐입니다. 각각의 부작용을 알고 고르는 게 전문성입니다.

2-1. Cover(크롭 채우기) — 가장 많이 쓰이는 정답

목표 프레임을 가득 채우고 넘치는 부분을 잘라냅니다.
스케일 배율은 두 축 중 큰 값을 씁니다.

scale = max(targetW / srcW, targetH / srcH)

장점: 여백이 없고 화면을 꽉 채워 시각적으로 강하다.
단점: 정보가 물리적으로 삭제된다. 인물 머리, 상품 끝단, 텍스트가 사라질 위험.

2-2. Contain(레터박스) — 정보 보존 우선

원본 전체를 프레임 안에 넣고 남는 곳은 여백으로 둡니다. 스케일은 두 축 중 작은 값.

scale = min(targetW / srcW, targetH / srcH)

제품 도면, 인포그래픽, 스크린샷, 텍스트 포함 이미지처럼 한 픽셀도 잘리면 안 되는 자산에 적합합니다.
여백 색은 아무 색이나 쓰지 말고 배경색과 동일 계열 또는 브랜드 뉴트럴 톤으로 고정하세요.

2-3. Stretch(비율 무시 늘리기) — 원칙적으로 금지

가로세로를 각기 다른 배율로 늘리는 방식. 원(circle)이 타원이 되고 얼굴이 넓어집니다.
예외는 딱 하나, 앞서 말한 비정방 픽셀 보정처럼 왜곡을 되돌리기 위한 의도적 스케일일 때입니다.

2-4. Content-aware / Generative Fill — 확장으로 푸는 법

자르는 대신 없는 영역을 만들어 비율을 맞추는 방식입니다.
구조적 배경(하늘, 바다, 그라데이션, 벽면)에서는 결과가 매우 자연스럽고, 반복 패턴이나 직선 구조물(타일, 창틀, 격자)에서는 어긋난 이음매가 드러납니다.

3. 크롭 좌표를 직접 계산하기

도구에 의존하지 않고 좌표를 낼 수 있어야 자동화가 가능합니다.
중앙 정렬 커버 크롭의 공식은 다음과 같습니다.

3-1. 숫자로 직접 해보기

원본 4000×3000(4:3, rs=1.3333)을 16:9(rt=1.7778)로 만들고 싶습니다.

rs < rt이므로 상하를 자릅니다.
cropW = 4000, cropH = 4000 / 1.7778 = 2250.
y = (3000 − 2250)/2 = 375.

→ 크롭 박스는 (x=0, y=375, w=4000, h=2250).
위아래로 각각 375px, 즉 전체 높이의 25%가 사라집니다. 인물 사진이라면 머리 위 여백이 375px 이상인지 먼저 확인해야 하죠.

반대로 같은 원본을 9:16(rt=0.5625)으로 가면?
rs > rt이므로 좌우를 자릅니다. cropH = 3000, cropW = 3000 × 0.5625 = 1687.5 → 1688.
x = (4000 − 1688)/2 = 1156. 가로의 58%가 날아갑니다.

3-2. 앵커(정렬 기준) 개념

중앙 크롭은 기본값일 뿐 최선이 아닙니다. 앵커를 바꾸면 결과가 확 달라집니다.

포컬 포인트 방식은 이미지마다 정규화 좌표(0~1)를 메타데이터로 저장해 두는 방법입니다.
예: {"focal": [0.42, 0.28]} → "가로 42%, 세로 28% 지점(얼굴)을 중심에 두고 잘라라".

function cropWithFocal(srcW, srcH, rt, fx, fy) {
  const rs = srcW / srcH;
  let cw, ch;
  if (rs > rt) { ch = srcH; cw = Math.round(srcH * rt); }
  else         { cw = srcW; ch = Math.round(srcW / rt); }
  // 관심점을 중심에 두되 프레임 밖으로 나가지 않도록 클램프
  let x = Math.round(srcW * fx - cw / 2);
  let y = Math.round(srcH * fy - ch / 2);
  x = Math.max(0, Math.min(x, srcW - cw));
  y = Math.max(0, Math.min(y, srcH - ch));
  return { x, y, w: cw, h: ch };
}

이 clamp 처리가 빠지면 음수 좌표나 범위 초과로 검은 띠가 생깁니다. 자동화에서 가장 흔한 버그 지점입니다.

4. 리샘플링: 크기를 바꿀 때 실제로 벌어지는 일

크롭은 "잘라내기"라서 화질 손실이 없습니다(픽셀을 그대로 가져옴).
반면 리사이즈는 픽셀을 새로 만드는 작업이라 반드시 보간(interpolation)이 개입합니다.

4-1. 주요 보간 알고리즘 비교

4-2. 한 번에 줄이지 말고 '단계 축소'

4000px을 300px로 한 번에 줄이면 보간 커널이 참조하는 픽셀 범위를 넘어서서 앨리어싱이 남습니다.
전통적으로 50%씩 단계 축소하거나, 축소 전에 가벼운 가우시안 블러(안티앨리어싱 프리필터)를 넣어주면 결과가 안정됩니다.

다행히 현대 이미지 라이브러리(libvips, Pillow-SIMD 등)는 축소 배율에 따라 커널 반경을 자동 확장하므로 대부분 한 번에 처리해도 품질이 충분합니다. 다만 구형 CMS나 자체 구현 리사이저를 쓰는 환경이라면 여전히 단계 축소가 유효합니다.

4-3. 감마와 색 공간: 축소가 어두워지는 이유

대부분의 이미지 픽셀값은 sRGB로 감마 인코딩되어 있습니다(약 2.2 지수).
이 값을 그대로 평균하면 물리적 광량 평균과 달라져 축소 결과가 원본보다 어둡고 탁해집니다.

정확한 처리는 다음 순서입니다.

① sRGB → 선형 광(linear light)으로 디코드
② 선형 공간에서 리샘플링
③ 다시 sRGB로 인코드

흰 글자가 많은 스크린샷, 고대비 그래픽, 반짝이는 하이라이트가 있는 사진에서 차이가 확실히 보입니다.
libvips는 --linear 옵션, ImageMagick은 -colorspace RGB 후 처리 → -colorspace sRGB 복귀로 구현합니다.

4-4. 순서가 중요한 이유

크롭 → 리사이즈가 맞습니다. 순서를 반대로 하면 버릴 영역까지 계산하느라 느리고, 크롭 후 남은 픽셀이 부족해 재확대가 필요할 수 있습니다.

리사이즈 → 샤프닝이 맞습니다. 축소는 필연적으로 경계를 흐리게 하므로, 최종 크기에서 언샵 마스크를 약하게(반경 0.3~0.8px, 강도 40~80%) 넣어 복원합니다.
반대로 큰 이미지에서 미리 샤프닝하면 축소 과정에서 링잉만 남고 선명도는 사라집니다.

5. 구도 규칙과 세이프 에어리어 설계

5-1. 크롭은 미학이기도 하다

삼분할(Rule of Thirds): 프레임을 3×3으로 나눈 교점에 주 피사체를 배치.
크롭 시엔 "지금 피사체가 교점 근처인가"를 기준으로 오프셋을 미세 조정하면 결과가 즉시 안정됩니다.

눈높이 원칙: 인물 사진에서 눈은 프레임 상단 1/3 부근이 가장 자연스럽습니다.
1:1 프로필 썸네일에서 이 규칙을 지키면 머리 위 여백(헤드룸)이 과하거나 부족한 문제가 거의 사라집니다.

관절에서 자르지 않기: 인물을 자를 때 손목, 발목, 무릎, 목 라인에서 절단하면 불편한 인상을 줍니다.
관절 사이(허벅지 중간, 가슴 중간, 팔뚝 중간)에서 끊는 것이 사진 기본 문법입니다.

시선 방향 여백(Lead Room): 피사체가 바라보는 쪽에 여백을 더 주면 시선이 자연스럽게 흐릅니다. 반대로 하면 답답하게 갇힌 느낌이 납니다.

5-2. 멀티 비율 대응을 위한 세이프 에어리어

한 장의 이미지를 1:1 / 4:5 / 16:9 / 9:16으로 모두 써야 한다면, 크롭을 4번 하는 게 아니라 처음부터 공통 안전영역을 설계해야 합니다.

실측 예시를 보겠습니다. 마스터가 3000×2000(3:2)일 때,

9:16 크롭 → 폭 2000×0.5625 = 1125px (중앙 기준 x: 937~2062)
21:9 크롭 → 높이 3000/2.3333 = 1286px (중앙 기준 y: 357~1643)

따라서 공통 안전영역은 대략 1125 × 1286px, 즉 마스터 면적의 약 24%뿐입니다.
멀티 비율 대응이 까다로운 이유가 여기 있습니다. 핵심 요소를 중앙 24% 안에 모으는 설계가 선행되어야 합니다.

6. 스마트 크롭: 자동으로 잘 자르는 알고리즘의 원리

수천 장을 사람이 자를 수는 없습니다. 그래서 자동 크롭이 필요하고, 실제 서비스들은 아래 신호들을 조합합니다.

6-1. 엔트로피 기반

이미지를 격자로 나눠 각 영역의 정보 엔트로피(픽셀값 분포의 불확실성)를 계산하고, 엔트로피가 높은(=디테일이 많은) 영역을 남깁니다.
하늘이나 단색 배경은 엔트로피가 낮아 자연스럽게 버려집니다.
단점: 노이즈나 복잡한 배경이 "중요"하다고 오판될 수 있습니다.

6-2. 엣지/채도 기반 어텐션

소벨(Sobel) 등의 에지 검출로 윤곽 강도 맵을 만들고, 채도와 명도 대비를 가중합해 시각적 주목도 맵을 구성합니다.
libvips의 attention 스마트 크롭이 이 계열입니다. 속도가 빠르고 상품 사진에서 특히 안정적입니다.

6-3. 객체 검출 기반

얼굴 검출, 인체 키포인트, 텍스트 영역 검출(OCR 박스), 일반 객체 검출 결과를 받아 바운딩 박스의 합집합을 우선 보존합니다.
프로필 사진, 인물 화보, 포스터 등 "잘리면 안 되는 대상"이 명확할 때 가장 정확합니다.

6-4. 실무용 하이브리드 점수 모델

최근에는 재능넷의 AI 기반 시각화 전문지식 서비스처럼, 알고리즘 결과를 사람이 빠르게 검수·보정하는 협업 워크플로가 표준으로 자리 잡는 흐름입니다. 완전 자동보다 자동 90% + 검수 10%가 품질과 속도의 최적점에 가깝습니다.

7. 플랫폼별 규격 기준

규격은 플랫폼 정책에 따라 갱신되므로 세부 수치는 반드시 최신 공식 가이드를 재확인해야 합니다.
다만 아래 구조적 원칙은 오래 유지되어 왔습니다.

7-1. 원형 마스킹 보정

프로필은 정사각 업로드 후 원으로 마스킹되는 경우가 많습니다.
정사각형에 내접하는 원은 면적이 π/4 ≈ 78.5%뿐입니다. 즉 네 모서리 21.5%는 안 보입니다.

따라서 아바타용 1:1 크롭은 일반 정사각 크롭보다 얼굴을 5~10% 더 크게, 더 중앙에 두어야 원형에서 균형이 맞습니다.

7-2. 재압축을 전제로 한 품질 여유

대부분의 소셜 플랫폼은 업로드 이미지를 자체 재인코딩합니다.
그래서 이미 강하게 압축한 JPEG을 올리면 이중 압축으로 블록 노이즈가 심해집니다.

대응 원칙은 세 가지입니다.

① 업로드용은 품질 85~92 수준으로 여유 있게(파일 용량 한도 내에서 가장 높게).
② 플랫폼이 권장하는 최대 표시 해상도에 정확히 맞춰 업로드해 플랫폼 측 리사이즈를 피한다.
③ 그래픽/텍스트가 많은 이미지는 JPEG보다 PNG 또는 무손실 WebP를 고려한다.

8. 웹 구현: CSS와 HTML 레벨의 비율 제어

8-1. object-fit과 object-position

브라우저에서 "커버 크롭"을 구현하는 표준 방법입니다.

.thumb {
  width: 100%;
  aspect-ratio: 16 / 9;   /* 컨테이너 비율 고정 */
  object-fit: cover;       /* 채우고 넘치는 부분 크롭 */
  object-position: 50% 30%;/* 상단 쪽으로 앵커 이동(인물 대응) */
}

object-position의 두 번째 값을 30~35%로 두는 것은 인물 썸네일에서 매우 효과적인 실전 팁입니다.
얼굴이 보통 이미지 상단 1/3에 있기 때문이죠.

8-2. aspect-ratio로 CLS 방지

이미지 로딩 전 높이가 0이면 로드 후 레이아웃이 밀려 CLS(Cumulative Layout Shift)가 발생합니다.
해결책은 둘 중 하나, 또는 둘 다입니다.

① HTML에 width/height 속성을 실제 픽셀값으로 명시 → 브라우저가 비율을 미리 계산
② CSS aspect-ratio로 컨테이너 비율 선언

<!-- 속성 명시가 가장 저렴한 최적화 -->
<picture>
  <source srcset="hero-1600.avif 1600w, hero-800.avif 800w"
          sizes="(max-width: 768px) 100vw, 800px" type="image/avif">
  <source srcset="hero-1600.webp 1600w, hero-800.webp 800w"
          sizes="(max-width: 768px) 100vw, 800px" type="image/webp">
  <!-- 폴백 -->
</picture>

8-3. 아트 디렉션: 비율 자체를 바꿔주기

단순 해상도 대응은 srcset으로 충분하지만, 모바일에서는 세로 크롭, 데스크톱에서는 와이드 크롭처럼 비율이 달라져야 할 때는 <picture> + media 조건을 씁니다.

<picture>
  <source media="(max-width: 600px)" srcset="hero-4x5.webp">
  <source media="(max-width: 1200px)" srcset="hero-3x2.webp">
  <source srcset="hero-21x9.webp">
</picture>

이게 바로 아트 디렉션(art direction)입니다.
같은 히어로 이미지라도 좁은 화면에서는 피사체를 크게 세우고, 넓은 화면에서는 배경의 여유를 살리는 것. 비율 변경의 가장 고급스러운 활용입니다.

9. 자동화 명령어 레퍼런스

9-1. ImageMagick

# 중앙 커버 크롭 + 1:1 800px 출력
magick input.jpg -resize 800x800^ -gravity center -extent 800x800 out.jpg

# ^ 는 '최소 채우기'(cover), gravity로 앵커 지정
# gravity: North / South / East / West / center / NorthWest ...

# 컨테인(레터박스), 여백 흰색
magick input.jpg -resize 1200x630 -background white \
  -gravity center -extent 1200x630 out.jpg

# 감마 보정 리사이즈(선형 공간 처리)
magick input.jpg -colorspace RGB -resize 50% -colorspace sRGB out.jpg

# 특정 좌표 크롭 (w x h + x + y)
magick input.jpg -crop 4000x2250+0+375 +repage out.jpg

+repage를 빼먹으면 크롭 오프셋이 메타데이터에 남아 이후 처리에서 이상한 위치로 합성됩니다. 자주 나오는 실수입니다.

9-2. libvips (대량 처리에 강력)

# 스마트 크롭(주목도 기반) 1:1 1000px
vips thumbnail input.jpg out.jpg 1000 \
  --height 1000 --crop attention

# 중앙 크롭
vips thumbnail input.jpg out.jpg 1000 --height 1000 --crop centre

# 선형 공간 리사이즈
vips thumbnail input.jpg out.jpg 800 --linear

libvips는 스트리밍 방식으로 동작해 메모리 사용량이 낮고, 수만 장 배치 처리에서 체감 속도 차이가 큽니다.

9-3. Node.js (sharp)

const sharp = require('sharp');

// 4:5 커버 크롭 + 주목도 기반 위치 선정
await sharp('input.jpg')
  .resize(1080, 1350, {
    fit: 'cover',
    position: sharp.strategy.attention,
    kernel: 'lanczos3'
  })
  .sharpen({ sigma: 0.6 })
  .webp({ quality: 88 })
  .toFile('out-4x5.webp');

// 여러 비율 일괄 생성
const targets = [
  { name: '1x1',  w: 1080, h: 1080 },
  { name: '4x5',  w: 1080, h: 1350 },
  { name: '16x9', w: 1920, h: 1080 },
  { name: '9x16', w: 1080, h: 1920 }
];

for (const t of targets) {
  await sharp('master.jpg')
    .resize(t.w, t.h, { fit: 'cover', position: 'center' })
    .toFile(`out-${t.name}.webp`);
}

9-4. FFmpeg (영상 프레임/GIF 소스)

# 16:9 → 9:16 세로 크롭 (중앙)
ffmpeg -i in.mp4 -vf "crop=ih*9/16:ih,scale=1080:1920" out.mp4

# 레터박스 방식으로 비율 맞추기
ffmpeg -i in.mp4 -vf "scale=1080:-2,pad=1080:1920:0:(oh-ih)/2:black" out.mp4

# 비정방 픽셀 보정
ffmpeg -i in.mpg -vf "scale=iw*sar:ih,setsar=1" out.png

10. 화질을 지키는 해상도 계산

10-1. 크롭 후 남는 픽셀 수부터 확인

크롭은 무손실이지만 남은 픽셀이 목표 크기보다 작으면 결국 확대가 발생합니다.
확대는 없던 디테일을 만들 수 없으므로 흐려집니다.

예: 원본 1200×800에서 9:16 크롭 → 남은 폭은 800×0.5625 = 450px.
그런데 목표가 1080×1920이면 2.4배 확대. 이 결과물은 절대 선명할 수 없습니다.

10-2. 인쇄와 화면의 기준 차이

화면은 픽셀 수가 기준이고, 인쇄는 물리 크기 × 해상도(PPI)가 기준입니다.

필요 픽셀 = 인치 × PPI. A4(약 8.27 × 11.69인치)를 300PPI로 인쇄하려면 약 2481 × 3508px.
같은 A4를 150PPI로 인쇄하면 1240 × 1754px면 됩니다.

여기서 중요한 사실: 이미지 파일 안의 DPI 메타데이터를 바꾸는 것만으로 화질이 좋아지지 않습니다.
72DPI를 300DPI로 "설정"해도 픽셀 수가 그대로면 인쇄 물리 크기가 줄어드는 것뿐입니다.

10-3. 레티나·고밀도 화면 대응

DPR(Device Pixel Ratio) 2 화면에서 CSS 400px 폭으로 표시할 이미지는 실제 800px 이 필요합니다.
DPR 3이면 1200px.

다만 모든 이미지를 3배로 만들면 용량이 폭증합니다. 현실적인 균형점은 이렇습니다.

사진: 2배까지 제공 + 압축 품질을 살짝 낮춤(2배 이미지는 품질 70~80에서도 선명해 보임)
로고·아이콘·도형: 가능하면 SVG로 전환해 해상도 무한 대응
텍스트가 포함된 이미지: 최소 2배, 가능하면 텍스트를 이미지에서 분리

11. 파일 포맷과 압축 선택

실무 권장 구성은 AVIF → WebP → JPEG 순서의 폴백 체인입니다.
브라우저가 지원하는 최상 포맷을 알아서 고르고, 구형 환경도 안전하게 커버합니다.

12. 접근성과 SEO 관점

비율과 크롭은 시각 품질만의 문제가 아닙니다.

레이아웃 안정성: 앞서 다룬 width/height 명시와 aspect-ratio는 Core Web Vitals의 CLS 점수에 직접 영향을 줍니다.

대체 텍스트: 크롭으로 중요한 정보가 잘려나갔다면 alt 텍스트가 그 공백을 메워야 합니다.
단, 이미지의 모든 디테일을 나열하는 게 아니라 맥락상 필요한 정보만 간결히 서술하는 게 원칙입니다.

텍스트 이미지 회피: 중요한 문구를 이미지 안에 그려 넣으면 스크린 리더가 못 읽고, 크롭 시 잘리고, 확대 시 흐려지고, 번역도 안 됩니다.
텍스트는 HTML로, 배경은 이미지로 분리하는 것이 모든 면에서 유리합니다.

파일명: IMG_4821.jpg보다 navy-linen-shirt-front-1080x1350.webp가 검색 노출과 유지보수 모두에 낫습니다.

13. 자주 나오는 실수 12가지

14. 실전 워크플로 템플릿

Case A. 인물 프로필 대량 생성

① 얼굴 검출로 바운딩 박스 추출
② 박스 중심의 세로 위치를 프레임 상단 35~40%에 오도록 오프셋 설정
③ 박스 높이의 2.2~2.8배를 크롭 높이로(헤드룸 + 어깨 포함)
④ 1:1로 확정 후 800px 출력, Lanczos3 축소
⑤ sigma 0.5 언샵, WebP q88
⑥ 원형 프리뷰로 랜덤 샘플 검수

Case B. 커머스 상품 멀티 비율

① 촬영 시 여백을 넉넉히 확보(상품 주변 25% 이상)
② 마스터는 정방형 3000×3000, 무손실 보관
③ 배경 제거 또는 단색 통일로 크롭 자유도 확보
④ 1:1(상세), 4:5(피드), 16:9(배너)를 동일 포컬 포인트로 배치
⑤ 배너용에는 상품을 좌측 1/3, 카피 영역을 우측에 확보
⑥ 최종 산출 파일명 규칙: {sku}_{angle}_{ratio}_{width}.{ext}

Case C. 기존 가로 자산을 숏폼으로

① 9:16 크롭 후 잔여 해상도 검사 → 60% 미만이면 다음 단계
② 생성형 확장으로 상·하단 배경 보강(직선 구조물 없을 때)
③ 또는 상단 20% / 하단 20%를 블러 배경 또는 브랜드 컬러 밴드로 채우고 중앙에 원본 배치
④ 확보된 상·하단 밴드에 타이틀과 캡션을 배치해 여백을 '설계'로 전환

15. 마무리: 비율 감각은 숫자에서 온다

이미지 비율 변경과 크롭 최적화는 결국 세 가지 질문으로 압축됩니다.

무엇을 반드시 남길 것인가 → 세이프 에어리어와 포컬 포인트
얼마나 여유가 있는가 → 잔여 해상도 계산
어떻게 부드럽게 줄일 것인가 → 보간 알고리즘과 감마, 그리고 압축

감각은 이 숫자들을 반복적으로 다루는 사이에 자연스럽게 생깁니다.
"왜 예쁜지" 모르는 상태에서 예쁘게 자르는 일은 재현이 안 되지만, 기준을 갖고 자르면 누가 해도 같은 품질이 나옵니다. 그게 디자인 시스템이고, 그게 자동화의 출발점입니다.

마지막으로 한 가지만 더. 크롭은 빼는 작업입니다.
무엇을 넣을지보다 무엇을 버릴지를 결정하는 일이라, 잘 자른 이미지는 항상 의도가 선명합니다.
비율을 바꿀 때마다 "이 프레임에서 관객이 가장 먼저 봐야 할 한 가지는 무엇인가"를 스스로에게 물어보세요. 도구는 그다음 문제입니다.