
## 들어가며

포토부스 키오스크를 만들면서 촬영한 이미지를 합성하고, 영상을 서버에 전송하는 과정이 필요했다. 브라우저에서 이미지와 영상을 어떻게 처리했는지, 그리고 포맷을 선택하면서 부딪힌 문제를 정리한다.

## 브라우저에서 이미지를 처리해야 했던 이유

촬영한 사진 4장을 하나의 이미지로 합성하고, 프레임 배경을 씌우고, QR코드를 올리는 작업이 필요했다. 이 과정을 서버에서 처리하면 원본 4장을 모두 업로드한 뒤 합성 결과를 다시 받아야 한다. 키오스크 환경에서 여러 사용자가 동시에 촬영하면 업로드 대기 시간이 길어졌고, 사용자가 결과를 받기까지 체감이 느려지는 문제로 이어졌다.

브라우저의 Canvas API를 사용하면 이미지 합성을 클라이언트에서 직접 처리할 수 있다. 서버 왕복 없이 촬영 직후 바로 결과물을 만들 수 있다는 점이 이 환경에 적합했다.

## Canvas API로 이미지 처리하기

### canvas.toBlob()과 canvas.toDataURL()

브라우저에서 이미지를 Canvas로 처리한 결과를 내보내는 네이티브 API는 두 가지다.

https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement/toBlob

https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement/toDataURL

둘 다 canvas에 그린 내용을 원하는 포맷으로 인코딩하지만 반환 형태가 다르다.

- `toDataURL()`은 Base64 인코딩된 문자열을 동기적으로 반환한다.
  - Base64는 바이너리를 텍스트로 변환하기 때문에 원본 대비 약 33% 크기가 증가한다.
  - 중간 처리 단계에서 이미지를 문자열로 다룰 때 유용하다.
- `toBlob()`은 바이너리 Blob을 비동기 콜백으로 반환한다.
  - 바이너리 그대로 다루기 때문에 크기 증가가 없고, File 객체로 변환하기도 간편하다.
  - 서버에 전송할 최종 파일을 만들 때 적합하다.

실제로는 두 API를 용도에 따라 섞어 사용했다. 좌우반전이나 4컷 합성처럼 중간 단계에서는 `toDataURL()`로 이미지를 문자열로 넘기고, 서버에 업로드할 최종 파일을 만들 때는 `toBlob()`을 사용했다.

### 이미지 합성 흐름

`drawImage()`는 canvas 위에 이미지를 그리는 Canvas 2D API 메서드다. 4컷 합성은 이 메서드를 호출하는 순서를 조절하는 것만으로 해결했다.

```typescript
// 4장의 사진을 각 위치에 배치
for (const [index, photo] of photos.entries()) {
  const img = await loadImage(photo);
  ctx.drawImage(img, positions[index].left, positions[index].top, photoWidth, photoHeight);
}

// 프레임 배경을 위에 덮어씌우기
const bg = await loadImage(backgroundImage);
ctx.drawImage(bg, 0, 0, baseWidth, baseHeight);
```

Canvas는 나중에 그린 것이 위에 온다. 사진 4장을 먼저 깔고, 프레임 배경을 그 위에 덮으면 프레임의 투명 영역을 통해 아래의 사진이 보이는 구조가 된다. 합성이 끝나면 `canvas.toDataURL("image/png", 1.0)`으로 결과를 뽑아낸다.

`devicePixelRatio`(DPR, 디스플레이의 물리 픽셀과 CSS 픽셀의 비율)를 곱해 canvas 해상도를 높이는 시도도 했다. DPR이 2인 화면에서 canvas 내부 픽셀 수를 2배로 늘리면 이론적으로 더 선명한 이미지를 얻을 수 있다. 하지만 고해상도 캔버스에 저해상도 이미지를 크게 그리는 것뿐이었기 때문에 실제 인쇄 결과는 달라지지 않았다. 코드로 할 수 있는 조치는 다 했지만, 원본 해상도의 한계는 소프트웨어로 넘을 수 없었다.

### 리사이징

촬영된 이미지의 해상도가 목표 크기와 다른 경우 리사이징이 필요하다. 단순히 크기를 줄이면 이미지가 찌그러질 수 있기 때문에, 비율을 유지하면서 중앙 크롭하는 방식을 사용했다.

```typescript
// 원본과 목표의 가로/세로 비율을 비교하여 크롭 방향을 결정
const imgRatio = img.width / img.height;
const targetRatio = targetWidth / targetHeight;

if (imgRatio > targetRatio) {
  // 원본이 목표보다 가로가 넓으면 좌우를 자른다
  sw = img.height * targetRatio;
  sx = (img.width - sw) / 2;
} else {
  // 원본이 목표보다 세로가 높으면 상하를 자른다
  sh = img.width / targetRatio;
  sy = (img.height - sh) / 2;
}

ctx.drawImage(img, sx, sy, sw, sh, 0, 0, targetWidth, targetHeight);
```

`drawImage`의 9개 인자 버전은 원본에서 잘라낼 영역과 canvas에 그릴 영역을 각각 지정한다. `sx`, `sy`는 원본에서 잘라내기 시작할 좌표, `sw`, `sh`는 잘라낼 영역의 크기다. 비율 비교로 어느 방향을 잘라야 하는지 판단한 뒤, 중앙을 기준으로 크롭하여 이미지가 찌그러지지 않도록 했다.

## WASM 기반 FFmpeg 라이브러리로 영상 압축하기

### 브라우저에서 ffmpeg를 실행하는 방법

브라우저에서 영상을 다루는 네이티브 API로 `MediaRecorder`가 있다. 웹캠 스트림을 실시간으로 녹화할 때 사용하며, `videoBitsPerSecond` 옵션으로 비트레이트 힌트를 줄 수 있다. 하지만 이 값은 브라우저가 정확히 지키는 것이 보장되지 않고, 코덱도 브라우저가 지원하는 것만 선택할 수 있다. 무엇보다 `MediaRecorder`는 녹화 시점에 동작하는 API라서, **이미 녹화된 영상을 다시 압축하는 용도로는 쓸 수 없다**.

`@ffmpeg/ffmpeg`는 C로 작성된 ffmpeg를 WebAssembly(WASM, 브라우저에서 네이티브에 가까운 속도로 실행되는 바이너리 포맷)로 컴파일해 브라우저에서 실행할 수 있게 만든 패키지다. 실제 파일시스템 대신 메모리(Emscripten FS)를 사용한다는 점만 다르고, ffmpeg 명령어를 그대로 쓸 수 있다.

### 구현

```typescript
const ffmpeg = createFFmpeg({ log: false });

async function compressVideo(file: File): Promise<File> {
  if (!ffmpeg.isLoaded()) await ffmpeg.load();

  ffmpeg.FS("writeFile", file.name, await fetchFile(file));
  await ffmpeg.run("-i", file.name, "-c:v", "libvpx", "-b:v", "1M", "-c:a", "libvorbis", "output.webm");
  const data = ffmpeg.FS("readFile", "output.webm");

  // 메모리 누수 방지
  ffmpeg.FS("unlink", file.name);
  ffmpeg.FS("unlink", "output.webm");

  return new File([data.buffer], "output.webm", { type: "video/webm" });
}
```

### 프로덕션에 적용하지 못한 이유

영상 압축 로직은 구현까지 완료했지만, 실제 서비스에 적용하지는 못했다. 2주라는 짧은 외주 기간 안에 결과물을 내야 했고, 같은 날 다양한 기능들을 통합해서 구현하는 상황이었다. 원본 그대로 올려도 동작은 했기 때문에, 압축 연결보다 다음 기능 구현이 우선순위에서 앞섰다. 결과적으로 압축 유틸은 만들어둔 채로 다시 돌아오지 못했다.

## 정리

- Canvas API의 `toBlob()`과 `toDataURL()`은 용도에 따라 사용처가 다르다. 중간 처리에는 `toDataURL()`, 최종 파일 생성에는 `toBlob()`이 적합하다.
- `drawImage()`의 호출 순서로 이미지 합성을 구현했다. Canvas는 나중에 그린 것이 위에 오는 특성을 이용해 사진 위에 프레임을 덮는 구조를 만들었다.
- 이미지 리사이징 시 비율을 유지하면서 중앙 크롭하는 방식으로 찌그러짐을 방지했다.
- `@ffmpeg/ffmpeg` WASM으로 브라우저 영상 압축을 구현했지만, 제한된 일정 안에서 우선순위가 밀려 프로덕션에 적용하지 못했다.

## 참고 자료

- [HTMLCanvasElement.toBlob() - MDN](https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement/toBlob)
- [HTMLCanvasElement.toDataURL() - MDN](https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement/toDataURL)
- [@ffmpeg/ffmpeg - npm](https://www.npmjs.com/package/@ffmpeg/ffmpeg)
- [WebP - Google Developers](https://developers.google.com/speed/webp)


WASM

2025

포토부스 이미지를 브라우저에서 처리한 과정