Scarab Diagnostic Suite 현장 테스트 #008: Next.js 이미지 최적화 리소스 경계

이번 현장 테스트는 Next.js를 대상으로 진행되었습니다.

문제는 이미지 최적화 (Image Optimization) 과정에서 발생하는 지속적인 메모리 압박 (memory pressure)이었습니다:

https://github.com/vercel/next.js/issues/54482

해당 스레드에서는 최적화된 이미지가 반복적으로 생성될 때 높은 메모리 사용량이 발생하는 현상을 설명했습니다. 기존 이슈는 보고된 내용이 주로 메모리 증가, 스크린샷, 운영 환경에서의 동작과 같은 운영상의 증상들이었기 때문에 정확한 원인을 파악하기 어려웠습니다.

Scarab Diagnostic Suite는 테스트할 가치가 있는 하나의 구체적인 경계 (boundary)를 찾아냈습니다:

네이티브 이미지 변환 (native image transformation) → 최적화된 출력 버퍼링 (optimized output buffering) → 응답 크기 예산 (response-size budget)

쉽게 말해, 이미지 최적화 도구가 Sharp를 사용하여 이미지를 변환한 다음, toBuffer()를 사용하여 최적화된 출력을 수집하고 있었습니다.

이는 기존의 응답 크기 예산 (response-size budget)이 작동하여 중단시키기 전에, 최적화된 이미지 출력이 메모리에 완전히 실체화 (materialized)될 수 있음을 의미합니다.

수정 후보 (repair candidate)는 의도적으로 범위를 좁게 설정했습니다.

이미지 최적화 도구를 재설계하지 않습니다.

이미지 캐시 (image cache) 동작을 변경하지 않습니다.

응답을 클라이언트로 직접 스트리밍 (stream)하지 않습니다.

대신, 캐시 및 ETag 처리에서 사용되는 기존의 최종 Buffer 반환 형태는 유지하되, 최적화된 출력이 수집되는 방식을 변경합니다.

로컬 패치 (local patch) 내용:

• Sharp 출력을 청크 (chunk) 단위로 소비합니다.
• 최적화된 출력 바이트가 도착할 때마다 카운트합니다.
• 기존의 images.maximumResponseBody 값을 출력 예산으로 사용합니다.
• 최적화된 출력이 해당 예산을 초과하면 기존의 ImageError(413) 동작과 함께 수집을 중단합니다.
• 결과가 예산 내에 정확히 들어오는 경우 성공적인 출력을 보존합니다.

경계의 양쪽 측면 모두에 대해 집중적인 회귀 테스트 (regression test)가 추가되었습니다:

• 예산을 초과하는 출력은 ImageError(413)를 발생시킵니다.
• 예산에 정확히 일치하는 출력은 성공합니다.

로컬 검증 결과 이미지 최적화 테스트, 타입 체크 (type checks), 포맷팅 체크 (formatting check), 그리고 디프 체크 (diff check)를 모두 통과했습니다.

저는 해당 이슈에 유지 관리자(maintainer)를 대상으로, 이 방향이 canary 버전에 대한 PR (Pull Request)로서 유용할지 묻는 코멘트를 남겼습니다.

현장 테스트 (Field Test) #008
프로젝트: Next.js

이슈 유형: 이미지 최적화 (image optimization) 메모리/리소스 압박

경계 (Boundary): 네이티브 미디어 변환 출력 버퍼링 (native media transform output buffering) 대 선언된 응답 크기 예산 (declared response-size budget)

결과: 좁은 범위의 로컬 수정 후보 (local repair candidate) 및 회귀 테스트 (regression test) 준비 완료

상태: PR (Pull Request)을 생성하기 전 유지보수자 (maintainer)의 방향성 요청 중

중요한 점은 Scarab가 최적화 경로 (optimizer path) 내부의 특정 리소스 경계 (resource boundary)를 식별하였고, 제한적이며 테스트 가능한 수정 후보 (repair candidate)를 생성했다는 것입니다.