안드로이드 런타임편집자 확인

안드로이드 런타임은 안드로이드 4.4 킷캣에서 처음으로 실험적인 기능으로 도입되었다. 이 버전에서는 개발자 옵션 내에서 사용자가 기존의 달빅 가상 머신과 ART를 선택할 수 있도록 했다. 당시 ART는 설치 시간 증가와 저장 공간 사용량 증가 등의 문제가 있었지만, 앱 실행 성능과 배터리 효율성에서 잠재력을 보여주었다.

안드로이드 5.0 롤리팝부터 ART는 기본 런타임으로 완전히 채택되어 달빅을 완전히 대체했다. 이 변경으로 애플리케이션 설치 시 AOT 컴파일이 수행되어 설치 시간은 길어졌지만, 앱 실행 속도와 시스템 반응성이 전반적으로 향상되었다. 또한, ART의 설계는 64비트 프로세서 아키텍처를 공식적으로 지원하는 기반을 마련했다.

안드로이드 7.0 누가에서는 컴파일 방식을 다시 한번 진화시켰다. 순수 AOT 컴파일 방식의 단점을 보완하기 위해 JIT 컴파일러를 다시 도입하고 프로파일 기반의 혼합 컴파일 방식을 채택했다. 이로 인해 앱 설치 시간이 크게 단축되었고, 자주 사용되는 코드는 백그라운드에서 최적화되는 방식으로 효율성이 개선되었다. 이후 안드로이드 8.0 오레오와 안드로이드 9.0 파이를 거치며 이 혼합 컴파일 방식은 계속 최적화되어 왔다.

달빅(Dalvik) VM과의 가장 큰 차이는 컴파일 방식에 있다. 달빅은 JIT(Just-In-Time) 컴파일 방식을 사용하여 앱이 실행되는 동안 필요한 코드를 실시간으로 기계어로 변환했다. 반면, 안드로이드 런타임(ART)은 AOT(Ahead-Of-Time) 컴파일 방식을 기본으로 채택하여 앱 설치 시점에 모든 코드를 미리 기계어로 변환해 저장한다. 이 근본적인 차이는 실행 속도, 배터리 효율, 저장 공간 사용 등 여러 측면에서 영향을 미쳤다.

실행 성능 측면에서 ART는 결정적인 이점을 가진다. AOT 컴파일 덕분에 앱 실행 시 매번 코드를 해석하고 변환하는 과정이 생략되어, 앱의 구동 속도와 실행 반응성이 크게 향상되었다. 또한, 달빅이 JIT 컴파일 과정에서 발생시키던 CPU 부하가 사라지면서, 동일한 작업을 수행할 때의 배터리 소모 효율도 개선되었다.

그러나 이러한 성능 향상에는 대가가 따른다. ART는 앱 설치 시 전체 코드를 컴파일해야 하므로, 달빅에 비해 설치 시간이 더 길다. 또한, 컴파일된 네이티브 코드를 저장해야 하기 때문에 앱이 차지하는 저장 공간도 약 1.5배에서 2배 가량 더 커지는 단점이 있었다. 이는 안드로이드 7.0 누가 이후 혼합 컴파일 방식이 도입되는 중요한 원인이 되었다.

아키텍처 지원 측면에서도 차이가 있다. 달빅 VM은 안드로이드 시스템의 핵심 부분으로 깊게 통합되어 있었으나, ART는 하나의 라이브러리 형태로 구현되었다. 이 변경 덕분에 ART는 x86, MIPS 등 다양한 CPU 아키텍처와 64비트 환경을 공식적으로 지원하는 것이 더욱 용이해졌다.

JIT 컴파일은 프로그램이 실행되는 도중에, 필요한 코드 부분을 실시간으로 기계어로 변환하는 방식이다. 안드로이드 2.2 프로요 버전부터 달빅 가상 머신에 이 방식이 도입되었다. 앱을 처음 실행할 때, 자주 사용되는 코드 경로를 식별하여 네이티브 코드로 컴파일하고, 그 결과를 램에 캐시로 저장한다. 이후 동일한 코드가 실행될 때는 미리 컴파일된 캐시를 재사용하여 실행 속도를 높인다.

이 방식의 주요 장점은 설치 시간이 짧고 저장 공간을 덜 차지한다는 점이다. 앱 설치 시 전체 코드를 미리 컴파일하지 않기 때문이다. 또한, 앱 실행 중에 실제 사용 패턴을 분석하여 자주 호출되는 메서드만 컴파일하는 적응형 최적화가 가능하다. 그러나 실행 중에 컴파일 작업이 발생하면 CPU와 배터리에 추가 부하를 주며, 특히 앱을 최초 실행할 때 지연이 발생할 수 있다는 단점이 있다.

안드로이드 7.0 누가 버전부터는 AOT 컴파일과 JIT 컴파일을 혼합한 방식을 채택했다. 이는 초기 설치 속도와 저장 공간 효율을 유지하면서, 자주 사용되는 앱의 성능을 점진적으로 개선하기 위한 설계이다.

AOT 컴파일은 애플리케이션을 설치하는 시점에 바이트코드를 기계어로 미리 완전히 컴파일하는 방식이다. 이는 달빅 가상머신이 사용하던 JIT 컴파일 방식과 근본적으로 다르다. JIT 방식은 앱을 실행하면서 필요한 코드 부분을 실시간으로 컴파일했지만, AOT 방식은 설치 과정에서 dex2oat 변환기를 통해 DEX 파일을 OAT 파일로 변환하여 저장한다. 결과적으로 앱 실행 시에는 이미 준비된 네이티브 코드를 바로 실행할 수 있어 인터프리트 또는 JIT 컴파일의 오버헤드가 사라진다.

이 방식의 가장 큰 장점은 실행 성능과 효율성의 향상이다. 코드가 미리 컴파일되어 있기 때문에 앱의 실행 속도가 빨라지고, 실행 중에 발생하던 JIT 컴파일 부하가 제거되어 CPU 사용률과 전력 소모가 감소한다. 또한, 가비지 컬렉션 등의 런타임 오버헤드도 최적화되어 전체적인 시스템 반응성이 개선된다.

그러나 AOT 컴파일에는 명확한 단점도 존재한다. 앱 설치 시간이 상당히 길어지며, 미리 컴파일된 네이티브 코드를 저장해야 하므로 저장 공간을 더 많이 차지한다. 일반적으로 APK 파일 크기 대비 1.5배에서 2배에 달하는 추가 공간이 필요하다. 또한, 설치 시 모든 코드 경로를 컴파일해야 하므로, 실제로는 자주 실행되지 않는 코드까지도 컴파일되어 공간을 차지하는 비효율성이 발생할 수 있다.

이러한 단점을 해결하기 위해 안드로이드 7.0 누가부터는 AOT 컴파일과 JIT 컴파일을 혼합한 방식을 도입했다. 초기 설치 시에는 JIT를 사용하여 설치 속도를 높이고, 백그라운드에서 자주 사용되는 코드를 점진적으로 AOT로 컴파일하는 적응형 방식을 채택했다. 이는 ART의 진화된 형태로, 설치 시간, 저장 공간, 실행 성능 사이의 균형을 찾은 결과이다.

안드로이드 7.0 누가부터는 JIT(Just-In-Time) 컴파일과 AOT(Ahead-Of-Time) 컴파일의 장점을 결합한 혼합 컴파일 방식을 도입했다. 이전까지 ART는 앱 설치 시 모든 코드를 미리 네이티브 코드로 컴파일하는 AOT 방식을 사용했는데, 이로 인해 설치 시간이 길어지고 저장 공간을 더 많이 차지하는 단점이 있었다.

새로운 방식에서는 앱을 최초 설치할 때는 JIT 컴파일러만을 사용한다. 앱이 실행되면서 JIT 컴파일러는 자주 실행되는 코드(핫 코드)를 실시간으로 컴파일하고, 이 정보를 프로파일 데이터로 저장한다. 이후 기기가 유휴 상태이거나 충전 중일 때, ART의 데몬(dex2oat)이 이 프로파일 데이터를 분석하여 실제로 자주 사용되는 코드 부분만을 선별적으로 AOT 컴파일한다.

이러한 혼합 전략은 설치 시간을 크게 단축시키는 동시에, 자주 실행되는 앱의 성능은 AOT 컴파일의 이점을 통해 최적화한다. 결과적으로 사용자는 앱 설치 시의 빠른 속도를 경험하면서도, 일정 시간 사용 후에는 해당 앱의 실행 속도가 점차 개선되는 효과를 얻을 수 있다. 이 방식은 안드로이드의 효율성을 높이는 중요한 진전으로 평가받는다.

안드로이드 런타임의 핵심 성능 개선은 기존 달빅 가상 머신의 JIT 컴파일 방식에서 AOT 컴파일 방식으로의 전환에서 비롯된다. AOT 컴파일은 앱 설치 시점에 자바 바이트코드를 기기의 CPU 아키텍처에 맞는 네이티브 코드로 미리 변환하여 저장한다. 이로 인해 앱 실행 시 매번 코드를 해석하거나 컴파일할 필요가 없어져, 앱의 구동 속도와 반응성이 크게 향상되었다.

실제로 안드로이드 4.4 킷캣에서 ART를 실험적으로 적용했을 때부터 사용자들은 앱 실행 및 전환 속도에서 체감할 수 있는 성능 향상을 보고했다. 특히 안드로이드 5.0 롤리팝부터 ART가 기본 런타임으로 완전히 채택되면서, 인터프리터 방식의 초기 달빅이나 JIT 컴파일 방식에 비해 시스템 전반의 반응성이 더욱 부드러워졌다. 이는 UI 렌더링, 애니메이션, 그리고 복잡한 계산이 필요한 앱에서 두드러진다.

성능 향상은 가비지 컬렉션의 효율성 개선에서도 나타난다. ART는 동시 마크-스위프 방식을 도입하여 가비지 컬렉션으로 인한 정지 시간을 줄였고, 메모리 할당 성능도 개선했다. 이는 앱이 실행 중일 때 발생할 수 있는 끊김 현상을 감소시키고, 멀티태스킹 시 전체 시스템의 안정성을 높이는 데 기여했다.

안드로이드 7.0 누가 이후 도입된 혼합 컴파일 방식은 이러한 성능 이점을 유지하면서 설치 시간과 저장 공간 사용량을 줄이는 데 초점을 맞췄다. 자주 실행되는 코드는 AOT로 컴파일되어 빠른 실행 속도를 보장하고, 덜 사용되는 코드는 JIT로 실행되거나 나중에 컴파일되어 효율성을 극대화한다.

ART의 AOT 컴파일 방식은 배터리 효율성 측면에서 기존 달빅 VM의 JIT 방식에 비해 이점을 가진다. JIT 컴파일은 앱 실행 중에 코드를 실시간으로 변환하는 작업을 수행하므로, 특히 앱 실행이나 화면 전환이 빈번할 경우 CPU에 지속적인 부하를 발생시켜 배터리 소모를 증가시켰다. 반면, ART는 앱 설치 시점에 대부분의 컴파일 작업을 미리 완료(AOT)하기 때문에, 앱을 실행할 때 추가적인 컴파일 부하가 거의 발생하지 않는다. 이로 인해 실행 시의 CPU 사용률이 낮아지고, 결과적으로 배터리 수명이 향상될 수 있다.

초기 안드로이드 4.4 킷캣과 안드로이드 5.0 롤리팝에서 ART를 사용할 때 배터리 지속 시간이 기대에 미치지 못하는 경우가 있었으나, 이는 새로운 런타임에 대한 최적화가 덜 진행된 상태의 불안정성 때문이었다. 시간이 지나 안드로이드 6.0 마시멜로와 이후 버전으로 발전하면서 ART 런타임 자체가 안정화되고 최적화가 이루어지며 배터리 효율성은 크게 개선되었다. 따라서 구조적으로 ART는 JIT 컴파일의 런타임 오버헤드를 제거함으로써 배터리 효율에 유리한 설계를 가지고 있다.

한편, 안드로이드 7.0 누가부터 도입된 JIT와 AOT의 혼합 컴파일 방식은 배터리 효율성 유지에 중점을 두고 설계되었다. 이 방식은 앱 설치 시에는 빠른 설치를 위해 JIT를 사용하지만, 기기가 유휴 상태이거나 충전 중일 때 백그라운드에서 자주 사용되는 코드를 점진적으로 AOT 방식으로 컴파일한다. 이를 통해 설치 시간과 저장 공간 사용이라는 AOT의 단점을 보완하면서도, 최종적으로는 자주 실행되는 앱의 코드가 네이티브 코드로 미리 준비되어 실행 효율이 높아지므로, 장기적으로는 배터리 소모를 줄이는 데 기여한다.

ART는 달빅과 달리 안드로이드 운영체제의 핵심 라이브러리로 통합된 런타임 라이브러리 형태를 가진다. 이 아키텍처적 차이는 구글이 다양한 CPU 아키텍처를 공식적으로 지원하는 데 중요한 기반이 되었다. 달빅이 안드로이드 시스템의 일부로 깊숙이 통합되어 있어 다른 아키텍처로의 이식이 어려웠다면, ART는 상대적으로 독립적인 라이브러리 모듈로 설계되어 이식성이 크게 향상되었다.

이러한 설계 덕분에 ART는 x86 및 MIPS 같은 인텔 계열 아키텍처에 대한 공식 지원을 가능하게 했다. 더 나아가, 64비트 컴퓨팅 시대에 발맞춰 ARMv8-A 아키텍처 기반의 64비트 프로세서를 완벽하게 지원한다. 64비트 지원은 더 넓은 메모리 주소 공간 접근과 향상된 연산 성능을 제공하여, 고사양 모바일 게임 및 멀티미디어 애플리케이션의 실행 효율을 높이는 데 기여한다.

ART의 도입은 안드로이드 생태계가 스마트폰과 태블릿을 넘어 안드로이드 TV, 안드로이드 오토, 다양한 임베디드 시스템으로 확장되는 데도 기술적 토대를 마련했다. 런타임 자체의 모듈화와 효율적인 네이티브 코드 실행 방식은 다양한 하드웨어 플랫폼에서 안정적인 성능을 보장하는 핵심 요소로 작용한다.

ART의 AOT 컴파일 방식은 앱 설치 시점에 모든 코드를 미리 네이티브 코드로 변환하여 저장하기 때문에, 설치 과정 자체가 상대적으로 오래 걸린다는 단점이 있다. 이는 기존 달빅 VM이 앱 실행 중에 필요한 부분만 즉시(JIT) 변환하는 방식과 비교할 때 명백한 차이로 나타난다. 특히 대용량 앱이나 게임을 설치할 때 사용자는 이 설치 시간 지연을 체감할 수 있다.

또한, 미리 컴파일된 네이티브 코드를 저장해야 하므로 앱이 차지하는 저장 공간도 증가한다. 일반적으로 AOT 컴파일을 적용하면 앱의 용량이 원본 DEX 파일 대비 약 1.5배에서 2배 정도 커진다. 이는 스마트폰이나 태블릿의 내부 저장소(플래시 메모리) 공간을 더 많이 소비함을 의미한다.

이러한 설치 시간과 저장 공간 문제를 완화하기 위해, 안드로이드 7.0 누가부터는 JIT 컴파일러를 다시 도입한 혼합 방식을 채택했다. 이 방식에서는 앱 설치 시 초기 변환 작업을 최소화하여 설치 속도를 높이고, 백그라운드에서 점진적으로 AOT 컴파일을 수행하거나 자주 실행되는 코드를 최적화한다. 그러나 궁극적으로 자주 사용하는 앱은 결국 네이티브 코드로 변환되어 저장되므로, 저장 공간 증가 문제는 근본적으로 해결되지 않았다. 다만, 저장 장치의 용량이 지속적으로 증가하는 추세이므로 실제 사용에서의 체감 부담은 상대적으로 줄어드는 편이다.

ART의 도입은 자바 기반 안드로이드 앱의 실행 성능을 네이티브 수준으로 끌어올릴 수 있을 것이라는 기대를 낳았다. 그러나 상용 앱의 성능 개선 정도는 앱의 구현 방식에 따라 크게 달라질 수 있다. NDK를 통해 C++이나 C 언어로 작성된 네이티브 코드를 이미 많이 사용하고 있는 앱의 경우, AOT 컴파일러의 이점이 상대적으로 제한적일 수 있다. 이러한 앱들은 달빅 환경에서도 하드웨어에 가까운 계층에서 효율적으로 실행되도록 최적화되어 왔기 때문이다.

반면, 자바나 코틀린으로 작성된 로직에 크게 의존하는 앱들은 ART로의 전환으로 인해 가장 큰 성능 향상을 체감할 수 있다. AOT 컴파일 방식은 앱 실행 시 반복적으로 발생하던 JIT 컴파일의 오버헤드를 제거하여, 특히 앱의 구동 시간과 복잡한 계산을 수행하는 부분에서의 반응 속도를 개선한다. 그러나 이는 이론상의 잠재력이며, 실제 사용자 체감 속도는 앱의 아키텍처, 메모리 관리, 그리고 UI 렌더링 최적화 등 다양한 요소의 영향을 받는다.

결론적으로 ART는 플랫폼 차원에서 제공하는 성능 개선의 토대를 마련했지만, 최종적인 앱의 반응성과 효율성은 여전히 개발자의 구현 방식과 품질에 크게 좌우된다. ART 환경 하에서도 여전히 비효율적인 코드나 메모리 누수는 성능 저하를 일으키며, 구글이 제공하는 안드로이드 스튜디오의 프로파일링 도구 등을 활용한 지속적인 최적화 작업이 필요하다.