무엇이 일어났는가

Remotion(React로 영상을 만들 수 있는 프레임워크)에서 시리즈물의 9번째 영상을 렌더링했을 때, npx remotion render가 6회 연속으로 타임아웃되었다. 원인은 @remotion/google-fonts의 loadFont()를 인자 없이 호출했기 때문이었다. 수정하여 해결했으므로, 동일한 방식으로 작성하고 있는 사람들을 위해 원인과 대책을 정리한다.

loadFont()를 인자 없이 호출하면 모든 패턴을 가져온다

원인:

import { loadFont } from "@remotion/google-fonts/ShipporiMincho";
const { fontFamily } = loadFont();

loadFont()는 인자를 생략하면, 해당 폰트가 가진 모든 굵기(weight)와 문자 종류의 청크(subset) 조합을 개별적으로 네트워크를 통해 가져온다. 일본어 폰트인 「Shippori Mincho」의 경우, 굵기 5종류 × 일본어 청크 약 120개로 총 610개의 요청이 발생한다.

이 요청은 1건당 18초의 타임아웃이 하드코딩되어 있다. 게다가 헤드리스 브라우저(headless browser)의 셋업 전체에는 별도로 30초의 타임아웃이 있으며, 610건 중 단 1건이라도 18초를 초과하면 전체가 실패한다. --timeout 플래그를 늘려도 이 30초에는 적용되지 않는다.

함정: 대상 파일을 고쳐도 고쳐지지 않는다

렌더링 대상인 컴포지션(영상)에서만 loadFont()에 weights/subsets를 지정하여 수정해도 렌더링은 해결되지 않았다.

원인은 Remotion의 Root.tsx가 모든 컴포지션을 항상 일괄 번들링(bundle)하는 구성에 있다. 렌더링 대상을 1개로 한정하더라도, 실제로 빌드되는 코드에는 이전에 만든 다른 영상의 컴포넌트도 전부 포함된다. 이번 경우에는 인자가 없는 동일한 loadFont()가 무관한 과거 영상 8개 분량에도 존재하고 있었으며, 총 9개의 파일을 수정하고 나서야 타임아웃이 해소되었다.

grep -rn "loadFont(" src/로 프로젝트 전체를 횡단적으로 확인하면 이러한 종류의 버그를 찾기 쉽다.

대책: weights/subsets를 좁히기

const { fontFamily } = loadFont("normal", { weights: ["400"], subsets: ["japanese"] });

단계적으로 좁혔을 때의 실측값:

• 인자 없음: 610개 요청 → 실패
• weights: ["400", "700"], subsets: ["japanese"]: 240개 요청 → 여전히 실패
• weights: ["400"]만 지정: 약 120개 요청 → 성공

굵은 글씨가 필요한 부분은 폰트 측의 다른 굵기 데이터를 가져오는 대신, 브라우저가 자체적으로 굵기를 합성하는 메커니즘(synthetic bold)에 맡겼다. 일본어 subset은 글자 수가 많아 굵기 1종류만으로도 약 120개 청크로 분할되기 때문에, 영어권 폰트의 latin과 같은 작은 subset과는 사정이 다르다.

요약

• loadFont()는 반드시 weights와 subsets를 지정하여 호출한다. 새로운 컴포지션을 만드는 시점부터 그렇게 해둔다.
• 모든 컴포지션을 일괄 번들링하는 구성(Remotion의 Root.tsx가 이에 해당)에서는 렌더링 대상과 무관한 파일이 진정한 원인이 될 수 있다. grep -rn "loadFont(" src/와 같이 횡단적으로 확인한다.
• 수정 대상이 1개 파일에서 9개 파일로 늘어나는 상황에서는, 해결된 이유를 한 번 언어화한 뒤에 진행하면 재작업을 줄일 수 있다.

Discussion