---
id: wiki-2026-0508-hermes
title: Hermes
category: Frontend
status: needs_review
canonical_id: self
aliases: []
duplicate_of: none
source_trust_level: A
confidence_score: 0.92
tags: [auto-wikified, technical-documentation, frontend]
raw_sources: []
last_reinforced: 2026-05-08
github_commit: pending
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
tech_stack:
  language: unspecified
  framework: unspecified
---

# Hermes

## 📌 한 줄 통찰 (The Karpathy Summary)
Hermes는 React Native에서 로직을 실행하기 위해 사용하는 고도로 최적화된 자바스크립트 엔진이다 [1-3]. React Native 애플리케이션이 실행될 때 자바스크립트 번들을 파싱하고 구동하는 핵심 역할을 담당한다 [2, 3]. JSI(JavaScript Interface)와 같은 React Native의 새로운 아키텍처와 결합하여 모바일 애플리케이션의 전반적인 실행 성능과 런타임 효율성에 직접적인 영향을 미친다 [1].

## 📖 구조화된 지식 (Synthesized Content)
* **자바스크립트 실행 및 로직 처리**: Hermes는 React Native 프레임워크 내에서 자바스크립트 코드를 실행하는 기반 엔진이다 [3]. 모든 React Native 앱은 애플리케이션 로직 구동을 위해 이 엔진과 함께 배포된다 [2, 4].
* **새로운 아키텍처와의 통합**: React Native의 렌더링 및 통신 방식을 혁신한 JSI(JavaScript Interface)는 고도로 최적화된 Hermes를 비롯한 다양한 자바스크립트 엔진을 지원한다 [1]. 이를 기반으로 자바스크립트와 네이티브 코드 간의 직접적이고 동기적인 바인딩이 가능해진다 [1].
* **앱 용량(App Size)에 미치는 영향**: Hermes 자바스크립트 엔진을 포함하여 빌드 및 배포되는 React Native 앱은 대략 5~8 MB 수준의 기본(baseline) APK 크기를 가진다 [2, 4].

## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
**초기 시작 지연(Startup Latency) 및 콜드 스타트 문제**
React Native 앱은 시작할 때 반드시 Hermes 자바스크립트 엔진을 초기화하고 JS 번들을 파싱하는 과정을 거쳐야 하며, 이는 측정 가능한 수준의 시작 지연(Startup latency)을 추가로 발생시킨다 [2]. 
결과적으로 네이티브 ARM 코드로 미리 컴파일(AOT)하는 Flutter 앱의 콜드 스타트 시간(일반적으로 200~400ms)과 비교했을 때, Hermes를 사용하는 React Native 앱의 콜드 스타트 시간은 보통 300~600ms로 상대적으로 더 느리다 [2, 4]. 이러한 지연은 성능 벤치마크 상에서는 눈에 띄는 차이지만, 실제 대부분의 앱 사용자에게는 결정적인 방해 요소가 되지는 않는다 [2].

## 🔗 지식 연결 (Graph)
### Related Concepts

#### [관계 유형 A (아키텍처/기반 기술)]
- [[JSI (JavaScript Interface)]]
  - 연결 이유: JSI는 Hermes와 같은 자바스크립트 엔진을 지원하며, 자바스크립트와 네이티브 코드 간의 동기적 바인딩을 가능하게 하는 토대이기 때문이다 [1].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 이전의 비동기 브릿지(Bridge) 모델에서 벗어나 어떻게 직렬화 오버헤드 없이 빠른 네이티브 통신이 이루어지는지 이해할 수 있다.
- [[React Native New Architecture]]
  - 연결 이유: Hermes 엔진은 Fabric 렌더러, TurboModules, JSI로 구성된 React Native의 새로운 아키텍처 파이프라인 내에서 핵심 자바스크립트 실행 환경으로 작동하기 때문이다 [5, 6].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 엔진의 고도화가 크로스 플랫폼 프레임워크 전체의 성능 향상(동시성 렌더링, 지연 로딩 등)으로 이어지는 구조적 맥락을 파악할 수 있다.

#### [관계 유형 B (비교/경쟁 기술)]
- [[Flutter AOT Compilation (Dart)]]
  - 연결 이유: Hermes 엔진이 실행 시점에 JS를 파싱하는 것과 대조적으로, Flutter는 코드를 사전에 네이티브로 컴파일하여 초기 시작 속도의 차이를 만들기 때문이다 [2].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 모바일 프레임워크가 코드를 실행하는 방식(파싱 vs 사전 컴파일)에 따른 초기 로딩 속도(Cold Start)의 트레이드오프를 명확히 이해할 수 있다.

### Deeper Research Questions
- Hermes 엔진이 JSI와 결합되었을 때 구체적으로 어떤 메커니즘을 통해 기존 브릿지(Bridge)의 직렬화(Serialization) 오버헤드를 제거하는가?
- Hermes의 엔진 초기화 및 JS 번들 파싱 시간(300~600ms)을 단축하기 위해 번들 크기를 최적화하거나 캐싱하는 기법에는 어떤 것들이 있는가?
- 다른 자바스크립트 엔진(예: V8, JavaScriptCore)과 비교했을 때 Hermes가 모바일 환경에 특화되어 가지는 메모리 및 성능적 이점은 무엇인가? (소스에 관련 정보가 부족합니다.)
- 대규모 React Native 애플리케이션에서 Hermes 엔진의 가비지 컬렉션(GC) 패턴이 UI 프레임 드롭이나 애니메이션 성능에 미치는 영향은 무엇인가? (소스에 관련 정보가 부족합니다.)
- 앱의 복잡도가 증가함에 따라 Hermes 기반 React Native 앱과 Impeller/AOT 기반 Flutter 앱의 성능 격차가 사용자 경험 측면에서 어떻게 다르게 발현되는가?

### Practical Application Contexts
- **Implementation:** React Native 앱 개발 및 빌드 과정에서 번들 크기(5~8 MB 기준)를 관리하고, 프레임워크 성능을 극대화하기 위해 JSI와 호환되는 최적화된 자바스크립트 엔진 설정을 구성할 때 활용된다.
- **System Design:** 모바일 애플리케이션 아키텍처 설계 시, 비즈니스 로직(자바스크립트)과 네이티브 렌더링 간의 처리 속도 및 통신 병목을 평가하는 지표로 작용한다.
- **Operation / Maintenance:** 프로덕션 환경에서 앱의 초기 진입 속도(콜드 스타트 300~600ms)를 모니터링하고 최적화 포인트를 찾는 기준점이 된다.
- **Learning Path:** React Native 개발자가 기존의 브릿지 기반 아키텍처에서 벗어나 새로운 아키텍처(JSI, Fabric, TurboModules)로 전환하는 렌더링 및 실행 파이프라인을 학습할 때 필수적으로 이해해야 하는 기반 환경이다.
- **My Project Relevance:** 모바일 앱 개발 프레임워크 선정 시, React Native가 가지는 '네이티브 컴포넌트 렌더링의 강점'과 '엔진 초기화 지연'이라는 성능적 기회비용을 저울질하는 데 직접적인 근거로 사용된다.

### Adjacent Topics
- [[React Native Performance Optimization]]
  - 확장 방향: 번들 분할(Chunking), 메모리 관리 등 Hermes 엔진 위에서 실행되는 애플리케이션의 성능을 실질적으로 개선하는 최적화 기법으로 지식을 확장할 수 있다.
- [[Cross-platform Mobile Development Frameworks]]
  - 확장 방향: 렌더링 엔진(Skia, Impeller)을 사용하는 Flutter와 자바스크립트 엔진(Hermes)을 사용하는 React Native의 철학적, 아키텍처적 접근 방식을 폭넓게 비교 연구할 수 있다.

---
*Last updated: 2026-05-03*

## 🤖 LLM 활용 힌트 (How to Use This Knowledge)

**언제 이 지식을 쓰는가:**
- *(TODO)*

**언제 쓰면 안 되는가:**
- *(TODO)*

## 🧪 검증 상태 (Validation)

- **정보 상태:** needs_review
- **출처 신뢰도:** A
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*

## 🧬 중복 검사 (Duplicate Check)

- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
- **처리 방식:** UPDATE (자동 정규화)
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.

## 🕓 변경 이력 (Changelog)

| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|------|-----------|-----------|--------|
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |

## 💻 코드 패턴 (Code Patterns)

**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*

```text
# TODO
```

## 🤔 의사결정 기준 (Decision Criteria)

**선택 A를 써야 할 때:**
- *(TODO)*

**선택 B를 써야 할 때:**
- *(TODO)*

**기본값:**
> *(TODO)*

## ❌ 안티패턴 (Anti-Patterns)

- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*