Bun.Image가 기존의 모든 이미지 처리 파이프라인을 대체합니다

한국어العربية English Español हिन्दी Русский 中文

Computing/SoftwareInternet Technology

Transcript

00:00:00이것은 Bun 1.3.14에 탑재된 내장 이미지 처리 API인 Bun Image로, 이미지 크기 조정,

00:00:06자르기, 형식 변환 등을 네이티브 종속성 없이 수행할 수 있으며,

00:00:10모든 작업이 메인 스레드 외부에서 실행되므로 처리 중에도 서버가 차단되지 않습니다.

00:00:14그런데 Bun은 이미 런타임, 패키지 매니저, 번들러, 테스트 러너인데,

00:00:19이제 이미지 프로세서까지 된다고요? 너무 과한 걸까요, 아니면 Bun이 나아갈

00:00:24방향에 대해 더 큰 의미를 시사하는 걸까요? 구독하고 확인해 보시죠.

00:00:30자바스크립트로 서버에서 이미지를 처리해 본 적이 있다면 아마 Sharp라는 라이브러리를

00:00:35자신도 모르게 사용했을지도 모릅니다. 매주 npm 다운로드 수가 5천 5백만 건이 넘고,

00:00:41Next.js에서도 이미지 최적화를 위해 내부적으로 사용하죠. 하지만 Sharp는 libvips라는 네이티브 바이너리에 의존합니다.

00:00:47즉, 설치할 때마다 플랫폼에 맞는 빌드를 가져와야 합니다. Docker 빌드나

00:00:51CI 파이프라인이 이 문제로 실패해 본 적이 있다면 얼마나 짜증 나는지 아실 겁니다. 그래서 Bun은

00:00:57런타임 자체에 이미지 처리를 내장하기로 했고, 실제 대부분의 벤치마크에서 Sharp보다 빠릅니다.

00:01:02메타데이터 읽기는 70배 더 빠르고, 크기 조정은 약 30% 더 빠릅니다. 많은

00:01:08개발자들이 왜 Bun이 이걸 추가했는지 의아해하지만, 저는 이 모든 것이 어디로 향하는지 어느 정도 보입니다.

00:01:13나중에 그 이야기를 좀 들려드릴게요. 우선 Bun 이미지 API를 사용하는 몇 가지 데모를 살펴보겠습니다.

00:01:17제 블로그에서 시도해 볼 텐데, 정적 Waku 사이트로 꽤 큰 이미지들이 있습니다.

00:01:22우선 이미지 하나를 최적화하는 간단한 스크립트부터 살펴보죠.

00:01:27제 얼굴이 나온 프로필 사진인데, 크기를 99%나 줄일 수 있었습니다. 정말 놀랍죠.

00:01:33방법을 보죠. 먼저 이미지를 가져옵니다. 여기서는 Bun.image를 사용하고 있지만,

00:01:37image 함수와 함께 Bun file을 사용할 수도 있습니다. 그다음 크기를 줄이기 위해 이미지를 조정하고, 너비를 800픽셀로

00:01:43설정하면 높이는 가로세로 비율에 맞춰 자동으로 계산됩니다. 원한다면

00:01:47여기서 직접 지정할 수도 있고요. 출력 형식을 품질이 낮아진 WebP로 설정합니다. 물론,

00:01:52다른 출력 형식도 지원합니다. 그런 다음 새 이미지를 파일로 출력하는데,

00:01:56이는 Promise이므로 await 키워드가 필요합니다. 얼마나 간단한지 보이시죠?

00:02:01사실 여기 있는 모든 코드는 불필요하므로 제거해서 더 간단하게 만들 수도 있습니다.

00:02:06크기 조정 필터를 설정해 리샘플링 커널을 변경함으로써 이미지 크기를 더 줄일 수도 있습니다.

00:02:10이미지를 회전하거나 뒤집을 수도 있는데, 이건 정말 멋집니다. 심지어 밝기나

00:02:15채도를 변경할 수도 있죠. 이상하게 보일 수도 있겠지만요. 하지만 연결 속도가

00:02:19느릴 때 정말 유용한 영리한 방법이 있습니다. 바로 플레이스홀더 기능을 사용하는 것입니다.

00:02:23메인 이미지가 로딩되는 동안 흐릿한 이미지를 자동으로 보여주는 것이죠. 이를 위해 for 문을 사용하여

00:02:29블로그 이미지가 포함된 디렉토리 내의 해당 확장자를 가진 모든 파일을 순회합니다.

00:02:34각 이미지는 자르지 않고 크기가 조정되고 축소되며, 확대되지는 않습니다.

00:02:39그다음 각 이미지에 대한 플레이스홀더를 만드는데, 이는 썸 해시(thumb hash)를 생성합니다.

00:02:45즉, 이미지를 28바이트 해시로 인코딩하여 흐릿한 이미지 플레이스홀더로 쓰기에 완벽합니다.

00:02:49이 해시는 플레이스홀더 객체에 추가된 다음 파일로 작성되는데,

00:02:53그 결과물은 이렇습니다. 플레이스홀더가 별도의 작은 WebP 이미지가 아닌

00:02:58base64 이미지인 이유는 네트워크에서 이를 가져오기 위한 별도의 요청을 만들지 않기 위해서입니다.

00:03:02그래서 저는 모든 플레이스홀더를 임포트해서 CSS의 배경 이미지로 추가할 수 있는데,

00:03:07이렇게 하면 제 블로그의 모든 이미지에 적용됩니다.

00:03:11만약 MDX 파일의 단일 이미지에 그렇게 하고 싶다면, base64 코드를

00:03:16수동으로 추가하면 똑같이 잘 작동합니다. 참고로, JPEG 이미지의 경우

00:03:20progressive 옵션을 true로 설정하면 비슷한 동작을 구현할 수 있습니다. 물론 Bun 이미지에는

00:03:24제가 아직 다루지 않은 다른 많은 기능도 있습니다. 예를 들어 S3 호환 버킷에서

00:03:28이미지를 가져오거나, 버킷에 이미지를 작성하거나, 이미지 파이프라인을 유효한 응답 본문으로 사용하거나,

00:03:33특정 OS에서 지원하지 않는 형식을 위한 대체 형식을 구성하는 것 등이 가능합니다.

00:03:37그래서 사용할 가치가 있을까요? 이미 Bun을 사용 중이라면 고민할 필요도 없죠.

00:03:41하지만 Node를 사용하고 있다면 Sharp가 매우 잘 작동하고 검증된 도구이므로,

00:03:45단지 이미지 처리 때문에 완전히 다른 런타임으로 바꿀 필요는 없습니다.

00:03:49아까 Bun이 이걸 추가한 더 큰 이유가 있다고 했던 거 기억하시나요? 작년부터

00:03:54Bun이 해온 일들을 보면 SQLite, S3, Postgres 내장에 이어 이미지까지 추가했으니,

00:03:59인증과 이메일을 제외하면 풀스택 앱에 필요한 모든 것을 갖춘 셈입니다. 문득 궁금해집니다.

00:04:04Bun이 런타임 수준에서 자바스크립트를 위한 Laravel이나 Rails를 만들려는 걸까요? 만약 그렇다면,

00:04:11다음 작업은 인증일 것입니다. 만약 정말 그렇다면 여기서 처음 들으신 겁니다.

00:04:15하지만 아쉽게도 요즘은 Zig에서 Rust로의 거대한 재작성 언급 없이는

00:04:20Bun에 대해 말하기 어렵죠. 다음 버전에서는 부디 잘 해결되기를 바랍니다.

00:04:25Zig 이야기가 나와서 말인데, Zig처럼 보이지만 Zig은 아니며 AI 에이전트를 위해

00:04:29만들어진 Vercel의 Language Zero에 대해 더 알고 싶다면 James의 영상을 확인해 보세요.

Key Takeaway

Bun 1.3.14에 추가된 Bun Image API는 외부 종속성 없이 서버 차단 없는 고속 이미지 처리를 가능하게 하며, Bun을 풀스택 개발을 위한 통합 런타임으로 진화시키고 있다.

Highlights

Bun 1.3.14에 내장된 Bun Image API는 네이티브 종속성 없이 이미지 크기 조정, 자르기, 형식 변환을 지원한다.
Bun Image는 메인 스레드 외부에서 작업을 실행하여 이미지 처리 중에도 서버가 차단되지 않는다.
메타데이터 읽기 속도는 Sharp 대비 70배 빠르며, 이미지 크기 조정은 약 30% 더 빠르다.
이미지를 28바이트 해시로 인코딩하는 썸 해시(thumb hash)를 통해 base64 플레이스홀더를 생성하여 로딩 속도를 최적화할 수 있다.
Bun은 현재 SQLite, S3, Postgres, 이미지 처리를 런타임에 내장하여 풀스택 애플리케이션 개발 환경을 구축하고 있다.

Timeline

Bun Image API 소개 및 배경

Bun Image는 외부 라이브러리 없이 네이티브 이미지 처리를 수행한다.
기존 Sharp 라이브러리는 libvips 바이너리 의존성으로 인해 배포 환경에서 설정 오류를 유발한다.
대부분의 벤치마크에서 Bun Image가 Sharp보다 빠른 성능을 보인다.

기존 Node.js 환경에서 널리 쓰이는 Sharp 라이브러리는 플랫폼별 빌드가 필요하여 Docker나 CI 환경에서 문제를 자주 일으킨다. Bun은 이를 해결하기 위해 런타임 자체에 이미지 처리 기능을 내장하였다. 이 방식은 메타데이터 읽기 속도를 70배, 크기 조정 속도를 30% 향상시켰다.

실무 활용 및 최적화 기법

Bun.image 또는 Bun file을 사용해 간단하게 이미지를 조작할 수 있다.
가로세로 비율 자동 계산 및 출력 형식 변환이 가능하다.
28바이트 썸 해시 기반의 base64 플레이스홀더를 생성하여 네트워크 요청을 줄일 수 있다.

코드 한 줄로 이미지 너비를 조정하고 품질이 낮은 WebP로 변환하는 등 간결한 API를 제공한다. 특히 이미지 로딩 중 사용자 경험을 개선하기 위해, 원본 이미지의 흐릿한 표현을 담은 base64 해시를 CSS 배경으로 적용하는 기법이 유용하다. 이는 별도의 네트워크 요청 없이 즉각적인 시각적 피드백을 제공한다.

Bun의 생태계 전략

Node.js 환경의 기존 사용자라면 검증된 Sharp를 유지하는 것이 합리적이다.
Bun은 SQLite, S3, Postgres 등 데이터 관리 기능을 런타임에 대거 포함하고 있다.
Bun은 자바스크립트 생태계의 Laravel이나 Rails와 같은 통합 풀스택 프레임워크를 지향할 가능성이 있다.

이미지 처리 기능의 추가는 단순히 편리한 유틸리티를 넘어, Bun이 풀스택 개발에 필요한 모든 요소를 런타임에 통합하려는 의도를 드러낸다. 인증 및 이메일 기능을 제외한 핵심 백엔드 기능들이 이미 갖춰진 상태다. 향후 런타임 수준의 인증 기능이 추가될 경우, Bun은 별도의 외부 의존성 없이 독립적인 웹 애플리케이션 구축 환경이 될 것으로 보인다.

Community Posts

No posts yet. Be the first to write about this video!

Write about this video