Zettelkasten

인터프리트되는 코드는 데이터이므로 OTA로 교체 가능하다

·수정 1회
otainterpreterruntimearchitecture

요약

  • OTA(Over-The-Air) 업데이트가 가능한 시스템은 모두 "런타임은 미리 설치되어 있고, 그 위에서 도는 코드는 인터프리트되는 데이터" 라는 구조를 공유한다.
  • 컴파일된 네이티브 바이너리는 OS의 코드 서명 검증을 거쳐야 하므로 임의 교체가 어렵지만, 데이터로 취급되는 인터프리트 코드는 일반 파일처럼 다운로드/교체 가능하다.
  • 브라우저, Python, CodePush는 모두 이 동일한 원리의 변주.

본문

두 가지 전제 조건

OTA가 동작하려면 두 조건이 만족돼야 한다:

  1. 런타임이 미리 깔려 있다 — 인터프리터, VM, JS 엔진 같은 실행 환경이 네이티브 바이너리 형태로 사용자의 머신에 설치돼 있어야 함.
  2. 실행 대상은 인터프리트되는 형식 — 네이티브로 컴파일된 게 아니라 JS, Python .py, JVM bytecode, WASM 같은 "데이터" 형태여야 함.

이 두 조건이 만족되면 실행 대상은 일반 파일이 되고, 일반 파일은 서명 검증 없이도 자유롭게 다운로드·교체할 수 있다.

사례 매핑

시스템 런타임 (네이티브) 실행 대상 (데이터) OTA 메커니즘
브라우저 Chrome/Safari (V8/JSC + 렌더러) 웹사이트의 JS/HTML/CSS 매 페이지 로드마다 새 파일 다운로드
Python python 인터프리터 (brew install python) .py 파일 git pull
CodePush (React Native) 앱 안에 박힌 JS 엔진 (Hermes/JSC) JS 번들 + 에셋 zip 서버에서 받아 다음 앱 재시작 시 적용
JVM java (JIT/HotSpot) .class / .jar bytecode classpath에 새 파일 배포
게임 (Lua scripting) 클라이언트 안의 Lua VM Lua 스크립트 서버에서 핫패치

브라우저는 사실 세상에서 가장 큰 OTA 시스템이다. 우리는 도메인에 들어갈 때마다 새 코드를 다운로드해 실행하지만 누구도 "OTA 업데이트"라 부르지 않는다 — 그냥 너무 당연해서.

CodePush는 이 브라우저 패턴을 모바일 네이티브 앱 안으로 가져왔다고 보면 된다. React Native는 한 발 더 나아가 "브라우저 없는 브라우저" — JS 엔진을 앱 바이너리에 직접 내장.

반대 사례: 왜 순수 네이티브 앱은 OTA가 어려운가

순수 Swift/Kotlin/C++ 앱은 모든 로직이 AOT(Ahead-Of-Time) 컴파일되어 네이티브 바이너리 안에 박혀있다. 인터프리트되는 부분이 없으므로:

  • 부분 교체할 단위 자체가 없음 (인스트럭션을 패치하려면 OS의 코드 서명 정책에 막힘)
  • 앱스토어는 이를 보안 모델의 핵심으로 강제 (특히 iOS는 임의 코드 실행을 정책으로 금지)

그래서 Apple은 한때 React Native/CodePush 같은 "동적 코드 다운로드"를 제한하려 했고, 지금도 App Store 규정 4.7로 "교육/스크립팅 목적"이라는 좁은 예외로만 허용한다. 본질적으로 "JS도 결국은 데이터"라는 점이 이 회색 지대의 근거.

한 단계 더 추상화

이 원리는 결국 "인터프리터(interpreter)와 인터프리트되는 프로그램의 분리" 라는 컴퓨터 과학의 오래된 패턴 — Turing의 universal machine, McCarthy의 Lisp eval/apply, JVM bytecode 전부 같은 발상이다.

OTA는 이 분리가 배포(distribution) 영역에서 발현된 형태:

  • 분리가 있다 → 두 층을 다른 채널로 배포할 수 있다
  • 두 채널의 변경 빈도/검증 강도를 다르게 가져갈 수 있다 (네이티브는 드물게/엄격하게, 코드는 자주/가볍게)

이 관점에서 보면 docker image와 컨테이너 안의 코드, OS와 그 위의 프로세스도 같은 패턴의 변주다.

관련 노트

참고

이 문서를 참조하는 노트 (1)

함께 읽기 좋은 글