모바일 개발에서의 Runtime, Hot Reload 및 빌드: 개념, 핵심 원리 및 작동 방식

Runtime 및 Reflection: iOS Runtime, Method Swizzling 및 동적 디스패치

Runtime(실행 환경)은 애플리케이션 실행을 관리하는 소프트웨어입니다. iOS Runtime의 맥락에서, 이는 객체에 메시지를 보내고, 즉시 클래스를 생성하며, 런타임에 메서드를 교체할 수 있는 Objective-C의 동적 시스템입니다. 이는 Objective-C가 C 위에 구축된 동적 타입 언어이기 때문에 가능합니다.

Reflection은 프로그램이 런타임에 자신의 구조를 검사하고 수정하는 능력입니다. iOS Runtime에서는 class_getInstanceMethod, method_exchangeImplementations, objc_getAssociatedObject와 같은 함수를 통해 구현됩니다. Kotlin/Java에서는 리플렉션에 KClass / java.lang.reflect를 사용합니다.

IT Sectr에서는 Runtime을 매우 드물게 사용합니다 — 대안이 없는 특정 작업에만 사용합니다. 예를 들어, 중앙 집중식 분석 로깅 또는 라이브러리 버그 수정을 위한 Method Swizzling이 있습니다. 그러나 Runtime은 깊은 이해와 주의가 필요한 강력한 도구입니다.

Method Swizzling

Method Swizzling은 런타임에 Objective-C 메서드 구현을 다른 것으로 교체하는 기술입니다. 이는 iOS를 위한 관점 지향 프로그래밍(AOP)의 특수한 경우입니다. Swizzling을 사용하면 기존 메서드의 소스 코드를 변경하지 않고도 로깅, 분석 또는 캐싱을 추가할 수 있습니다.

일반적인 예: UIViewController의 viewWillAppear:를 교체하여 자동 화면 로깅 추가. 중요: swizzling은 +load 또는 +initialize 메서드에서 수행되어 클래스 사용 전에 실행되도록 보장해야 합니다. 잘못된 swizzling은 정의되지 않은 동작과 디버깅이 어려운 버그를 유발할 수 있습니다.

// Method Swizzling for logging viewWillAppear:
@implementation UIViewController (Tracking)

+ (void)load {
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        Class class = [self class];
        SEL originalSelector = @selector(viewWillAppear:);
        SEL swizzledSelector = @selector(xxx_viewWillAppear:);
        
        Method originalMethod = class_getInstanceMethod(class, originalSelector);
        Method swizzledMethod = class_getInstanceMethod(class, swizzledSelector);
        method_exchangeImplementations(originalMethod, swizzledMethod);
    });
}

- (void)xxx_viewWillAppear:(BOOL)animated {
    [self xxx_viewWillAppear:animated]; // 원래 메서드 호출
    [Analytics logScreen:NSStringFromClass([self class])];
}

@end

이 코드는 swizzling을 통해 모든 UIViewController의 viewWillAppear:를 교체합니다. method_exchangeImplementations 후, 원래 viewWillAppear:를 호출하면 xxx_viewWillAppear:가 호출되어 원래 메서드를 호출하고(재귀 호출 통해) 분석을 추가합니다. DispatchOnce는 swizzling의 단일 실행을 보장합니다.

웹 도구(Transpilation, Polyfill, Bundler, Webpack, Metro)

최신 웹 개발 및 React Native나 Flutter를 사용한 모바일 개발은 빌드 도구 없이 불가능합니다. Transpilation은 코드를 한 언어에서 다른 언어로 변환하는 것입니다. 가장 인기 있는 예: TypeScript → JavaScript. 트랜스파일러(Babel, tsc)는 최신 코드를 하위 호환 버전으로 변환합니다.

Polyfill은 오래된 브라우저에 누락된 기능을 추가하는 코드입니다. 예를 들어, Promise.allSettled()는 Internet Explorer에서 작동하지 않지만 폴리필이 이 기능을 추가합니다. 네이티브 Runtime이 기기에서 직접 코드 실행을 관리하는 것과 달리, 폴리필과 트랜스파일러는 언어 추상화 수준에서 작동합니다 — 구문과 API를 적응시키지만 실행 환경에는 간섭하지 않습니다.

Webpack은 가장 인기 있는 번들러입니다(State of JS 2024에 따르면 프로젝트의 72%에서 사용). Metro는 Facebook의 번들러로, React Native에서 기본으로 사용됩니다. JavaScript에서의 Reflection은 Object.getPrototypeOf, Proxy 및 Reflect API를 통해 존재합니다 — 이러한 메커니즘은 런타임에 객체를 검사하고 수정할 수 있어, 번들러의 정적 모듈 분석과 근본적으로 다릅니다. Webpack은 진입점, 출력, 로더(다양한 파일 유형 처리용) 및 플러그인(추가 기능용)을 설명하는 구성 파일을 사용합니다.

// webpack.config.js — 최소 구성
const path = require('path');

module.exports = {
    entry: './src/index.js',
    output: {
        filename: 'bundle.js',
        path: path.resolve(__dirname, 'dist'),
    },
    module: {
        rules: [
            {
                test: /\.js$/,
                exclude: /node_modules/,
                use: 'babel-loader',
            },
        ],
    },
    mode: 'production',
};

이 구성은 진입점(index.js), 출력 파일(bundle.js) 및 Babel을 통한 JavaScript 처리 규칙을 정의합니다. production 모드는 최적화(축소, 트리 쉐이킹, 자동 환경 감지)를 활성화합니다. Runtime 단계에서 이러한 모든 최적화는 로직에 영향을 미치지 않습니다 — 브라우저는 축소된 번들을 일반 JavaScript로 실행합니다.

코드 최적화(Minification, Tree Shaking, Obfuscation)

Minification은 공백과 주석을 제거하고 긴 변수명을 짧게 변경하여 코드를 압축하는 프로세스입니다. 인기 있는 미니파이어: Terser(JS/TS), CSSNano(CSS), html-minifier-terser. 축소는 파일 크기를 50~70% 줄입니다. 프로덕션에서 Runtime은 축소된 코드를 원본 코드와 동일하게 실행합니다 — 차이는 가독성과 파일 크기뿐이며 의미론에는 차이가 없습니다.

Tree Shaking은 애플리케이션에서 사용되지 않는 데드 코드를 제거하는 것입니다. ES 모듈(import/export)의 정적 분석을 기반으로 작동합니다. 함수가 내보내졌지만 가져오지 않은 경우, Tree Shaking은 최종 빌드에서 이를 제거합니다. Tree Shaking은 코드를 정적으로 분석합니다 — 동적으로 작동하며 컴파일 시 보이지 않는 메서드와 속성에 접근할 수 있는 Reflection과는 다릅니다.

Tree Shaking

Tree Shaking은 Webpack에서 프로덕션 모드에서 자동으로 활성화됩니다. 중요한 조건: 코드는 ES 모듈(import/export)을 사용해야 하며 CommonJS(require)를 사용하면 안 됩니다. 라이브러리가 CommonJS로 작성된 경우 트리 쉐이킹이 작동하지 않습니다. 최적의 트리 쉐이킹을 위해 import _ from 'lodash' 대신 import { merge } from 'lodash-es'와 같은 정확한 임포트를 사용하세요. 이렇게 하면 단일 함수에 대해 번들 크기가 500KB에서 10KB로 줄어듭니다.

Hot Reload

Hot Reload는 전체 리로드 없이 애플리케이션 코드를 업데이트할 수 있는 기술입니다. React Native 및 Flutter에서 Hot Reload는 현재 애플리케이션 상태를 유지하면서 변경된 파일을 즉시 업데이트합니다. 이는 개발을 근본적으로 가속화합니다: 전체 재빌드의 10~30초 대신 변경 사항이 1~2초 내에 표시됩니다. Hot Reload는 Runtime 내에서 작동합니다 — 실행 환경을 재시작하지 않고 변경된 모듈이 실행 중인 애플리케이션에 주입됩니다.

Hot Restart는 업데이트된 코드로 애플리케이션을 빠르게 재시작하지만 상태는 유지되지 않습니다. Hot Reload가 불가능한 경우(예: 네이티브 코드나 전역 변수가 변경된 경우) 사용됩니다. IT Sectr에서는 UI 개발의 모든 단계에서 Hot Reload를 사용합니다 — 시각적 조정에 소요되는 시간을 최대 50% 절약합니다.

표 3. 빌드 도구 비교. Webpack은 범용 표준입니다. Metro는 React Native에 특화되었습니다. Vite와 esbuild는 속도에 초점을 맞춘 새로운 세대입니다. Rollup은 라이브러리 게시에 가장 적합한 선택입니다.

핫 리로드(Hot Reload, Hot Restart)

Hot Reload는 웹 개발(React Hot Loader, HMR — Hot Module Replacement)에서 시작되어 Flutter 및 React Native와 함께 모바일 개발로 전환된 기술입니다. 핵심: 파일이 변경되면 번들러가 업데이트된 모듈을 실행 중인 애플리케이션으로 보내 상태 손실 없이 이전 코드를 교체합니다. 전체 재빌드와 달리 Hot Reload는 Runtime을 재시작하지 않습니다 — 실행 환경은 계속 실행되고, 변경된 모듈은 HMR 또는 Reflection과 유사한 참조 업데이트 메커니즘을 통해 동적으로 연결됩니다.

Hot Reload가 작동하는 이유는 프레임워크가 위젯(Flutter) 또는 컴포넌트(React)를 메모리에 유지하고 변경된 부분만 업데이트하기 때문입니다. Hot Restart는 더 거친 메커니즘으로 애플리케이션을 완전히 재시작하지만 네이티브 코드를 재컴파일하지 않으므로 전체 재빌드보다 빠릅니다. IT Sectr에서는 UI 개발 시 Hot Reload를, 탐색 또는 상태 관리 변경 시 Hot Restart를 사용합니다.