hermes-memory-installer의 최신 릴리스에는 특정 수정 사항이 포함되었습니다: 이제 메모리 사이드카 (memory sidecar) 모듈이 런타임 스크립트 (runtime scripts)로부터 적절하게 로드됩니다. 이 변경 사항은 Hermes 메모리 관리 훅 (memory management hooks)에 부착되는 작은 래퍼 (wrappers)인 사이드카 모듈이 빌드 타임 (build time)에는 초기화되었지만, 런타임 스크립트 컨텍스트 (runtime script context)에서는 활성화되지 않았던 불일치 문제를 해결합니다. 프로덕션 (production) 또는 디버그 빌드 (debug builds)에서 정확한 메모리 프로파일링 (memory profiling)에 의존하는 개발자들에게 이 수정은 미묘하지만 중요한 격차를 메워줍니다.

Hermes-memory-installer는 플러그 가능한 사이드카 모듈을 통해 세밀한 메모리 할당 이벤트 (memory allocation events), GC 사이클 (GC cycles), 그리고 힙 스냅샷 (heap snapshots)을 드러내도록 Hermes JavaScript 엔진을 구성하는 도구입니다. 이러한 모듈은 환경 인식 (environment-aware)이 가능하도록 설계되어, 런타임 스크립트가 실행될 때 엔진에 부착됩니다. 이 수정 전에는 설치 프로그램이 빌드 구성 (build configuration)에서 사이드카 경로를 참조하기는 했으나, 런타임 엔트리 포인트 (runtime entry point)에서 해당 경로가 반드시 필요하도록(required) 보장하지 못했습니다. 그 결과: 사이드카 모듈이 완전히 생략되는 경우가 많았으며, 이는 메모리 모니터링에서의 거짓 음성 (false negatives)이나 프로파일링 API가 호출되었으나 등록된 사이드카가 없을 때 발생하는 크래시 (crashes)로 이어졌습니다.

수정 자체는 간단하지만 영향력이 큽니다. 이제 설치 프로그램은 빌드 자산 (build assets)뿐만 아니라 생성된 런타임 스크립트에 각 사이드카 모듈에 대한 require 호출을 주입합니다. 이를 통해 엔진이 시작될 때, 즉 어떤 애플리케이션 코드도 실행되기 전에 모듈이 동기적으로 로드되고 초기화됨을 보장합니다. 이 변경 사항은 최종 런타임 구성 번들 (runtime configuration bundle)을 생성하는 hermes-memory-installer 내부의 핵심 코드 생성 로직 (code generation logic)을 수정합니다.

전형적인 사용 패턴을 고려해 보겠습니다. 수정 전에는 개발자가 네이티브 할당 크기 (native allocation sizes)를 추적하는 커스텀 사이드카를 다음과 같이 정의했을 수 있습니다:

// 런타임 엔트리 스크립트 (수정 전)
const { createMemorySidecar } = require('hermes-memory-installer');
// 사이드카가 생성되었으나 런타임에 자동으로 부착되지 않음
...

업데이트 이후에는 설치 프로그램이 이를 자동으로 처리합니다:

// 생성된 런타임 부트스트랩 (수정 후)
const sidecarLoader = require('hermes-memory-installer/sidecar-loader');
const sidecar = sidecarLoader('sidecar-custom-allocation');
...

빌드 타임 (build-time) 배치에 의존하는 대신 런타임 스크립트 (runtime scripts)에서 로드하는 이러한 작은 변화는, 활성화 시점을 "링크 타임 (link time)에 사용 가능"한 상태에서 "엔진 시작 시 등록"되는 상태로 변경합니다. 이는 사이드카 (sidecar) 모듈이 기대하는 라이프사이클 (lifecycle)을 반영합니다. 즉, 사이드카 모듈은 단순히 컴파일된 바이너리 (compiled binary)에 부착되는 것이 아니라, 실행 중인 엔진 컨텍스트 (engine context)에 바인딩 (bound)되어야 합니다.

숙련된 개발자들에게 이 변화는 Hermes가 네이티브 모듈 (native modules)과 함께 사용되거나 표준이 아닌 빌드 툴체인 (build toolchains)을 실행하는 하이브리드 환경에서 가장 중요합니다. 기존의 동작 방식은 사이드카가 완전히 등록되기 전에 코드를 프로파일링 (profiling)할 때만 나타나는 메모리 보고 버그를 숨길 수 있었습니다. 이번 수정으로 사이드카의 라이프사이클은 결정론적 (deterministic)이 되었습니다. 설치 프로그램은 런타임 스크립트가 엔진 초기화의 유일한 진실의 원천 (source of truth)이라는 계약을 준수합니다.

운영 측면에서 업그레이드한다는 것은 커스텀 런처 (custom launcher)를 사용하는 경우 런타임 스크립트를 재생성해야 함을 의미합니다. 이제 설치 프로그램은 사이드카 require 문을 포함하는 runtime.hermes.js 또는 그에 상응하는 파일을 출력합니다. 런타임 스크립트를 수동으로 관리하는 경우, 수정을 적용하기 위해 설치 프로그램을 다시 실행해야 합니다. 사이드카 설정 변경은 필요하지 않으며, 이번 업데이트는 기존 사이드카 정의에 대해 하위 호환성 (backward compatible)을 유지합니다.

한 가지 미묘한 차이점은, 이번 수정이 사이드카 모듈의 로드를 보장하지만 모듈이 선택되는 방식 자체를 바꾸지는 않는다는 점입니다. 개발자는 여전히 설치 프로그램의 설정 객체 (configuration object)를 통해 사이드카를 지정합니다. 개선 사항은 순수하게 로드 순서 (load sequence)에 있습니다. 이미 설치 프로그램의 기본값을 사용하고 있었다면 이번 업데이트는 투명하게 적용됩니다. 만약 로드 누락 문제를 해결하기 위해 별도의 패치를 적용해 사용 중이었다면, 이제 해당 워크아라운드 (workarounds)를 제거할 수 있습니다.

이 버그가 존재했던 근본적인 이유는 hermes-memory-installer가 빌드(build)와 런타임(runtime)의 관심사(concerns)를 너무 엄격하게 분리했기 때문입니다. Sidecar 모듈은 엔진별 심볼(engine-specific symbols)과 함께 컴파일되어야 했으므로, 빌드 단계에서 처리되었습니다. 하지만 엔진은 런타임 스크립트가 등록 함수를 호출할 때만 sidecar를 활성화합니다. 이 두 단계는 제대로 연결된 적이 없었습니다. 이번 수정은 새로운 API를 추가하지 않으면서 그 간극을 메웁니다.

성능 관점에서 볼 때, 런타임 스크립트에서 로드하는 것은 무시할 만한 수준의 시작 오버헤드(startup overhead)만 추가합니다. sidecar 모듈은 작고 초기화가 즉각적이지만 저렴하기 때문입니다. 더 큰 이점은 정확성(correctness)입니다. 이제 메모리 추적(memory tracking)은 애플리케이션 자체의 초기화 코드 순서와 관계없이 첫 접근 시 신뢰할 수 있게 작동합니다.

무거운 JS 실행을 하는 React Native 앱을 디버깅하는 팀에게 이 수정은 메모리 도구가 특정 빌드에서만 'sidecar not found' 오류를 보고했던 흔한 혼란의 원인을 제거합니다. sidecar가 런타임 스크립트에서 로드됨이 보장되면서, 이러한 오류는 드물어질 것입니다.

요약하자면, 이번 업데이트는 간단한 규칙을 강제함으로써 hermes-memory-installer를 더 예측 가능하게 만듭니다. 즉, sidecar 모듈은 빌드 단계에서 가정되는 것이 아니라 런타임 스크립트에 의해 등록되어야 한다는 것입니다. 이 설치 프로그램을 사용한다면, 런타임 구성을 다시 생성하고 부트스트래핑(bootstrapping) 코드에 sidecar 요구 사항(sidecar require lines)이 나타나는지 확인하십시오. 수정 내용은 변경 로그에서는 작지만, Hermes에서 정확한 메모리 검사(memory introspection)에 의존하는 모든 사람에게는 큰 의미가 있습니다.