안드로이드 속도가 아이폰보다 느릴 수 밖에 없는 이유와 구글의 숙제

Posted by taeho Tae-Ho
2013.11.15 11:02 운영체제

아이폰과 안드로이드의 속도 경쟁은 결국 32bit와 64bit 운영체제의 논쟁으로까지 번지는 형국이다. 하지만 그 싸움에서 안드로이드 진영은 애플을 이길 수 없다. 그 이유는 안드로이드의 앱 구동 체계의 구조적 문제 때문이다.


안드로이드는 리눅스 운영체제의 일종이면서도 사용자가 사용하는 앱은 모두 Java 언어로 개발된다. Java로 개발된 앱의 소스파일은 바이트 코드로 컴파일되기 때문에 운영체제가 직접 실행하는 것이 불가능하다. 왜냐하면 Java에서 컴파일된 바이트코드는 java Run-time 이라고 하는 실행환경(가상의 운영체제)에서만 읽고 해석(Just-In-Time 컴파일)이 가능하기 때문이다. 그리고 이러한 역할을 수행하는 것이 안드로이드에서 지원하는 앱구동 환경인 달빅(Dalvik)이다.


하지만 iOS는 앱이 기계어로 컴파일되어 저장소에 파일로 저장되어 있다가 사용자가 앱을 실행하면 곧바로 메모리에 올려져 운영체제에 의해 실행된다. 즉 안드로이드 처럼 앱과 운영체제의 중간에 존재하는 달빅과 같은 JIT 컴파일러가 필요없다. 이런 차이점은 바로 안드로이드의 앱 개발환경이 Java 이고 iOS의 앱 개발환경이 Object-C라고 불리는 C언어 환경이기 때문에 발생하는 차이다. iOS의 오브젝트C는 C언어로 작성된 앱의 소스파일을 아이폰의 운영체제인 iOS가 직접 읽어 메모리에 적재(loading)하고 곧바로 실행할 수 있도록 기계어코드(목적코드 혹은 Object-Code)로 만들어 저장소에 저장된다.


이 두가지 앱 구동 환경을 이해하기 쉽게 표시하면 아래그림과 같다.




간단한 그림의 표현만으로도 "안드로이드 스마트폰이 메모리도 더 크고 CPU도 더 빠른데 왜 아이폰보다 느린지"를 이해할 수 있을 것이다.


안드로이드와 애플의 64bit 전쟁.


앞에서 살펴본 스마트폰의 운영체제와 앱구동환경의 차이로 인해 최근 논란이 되고 있는 64bit 지원 논쟁에서 애플은 64bit 지원에 대해 자신감을 보이고 있는 반면 안드로이드를 만드는 구글은 멈칫하며 주저하는 미묘한 입장차이를 보이고 있기도 하다.


애플은 iOS와 오브젝트C 개발환경 그리고 CPU까지 모두 스스로 만들고 있으며 64bit CPU (AP : Application Processor라고도 부름)개발과 64bit iOS개발, 그리고 64bit 오브젝트C의 개발이 모두 하나의 작업처럼 진행될 수 있기 때문에 현재의 기술로서 64bit를 지원하는 것은 그리 어려운 일이 아니다. 게다가 32bit 오브젝트C로 개발된 앱의 64bit 포팅도 충분히 가능하다.


하지만 구글의 입장은 매우 복잡하다. 


리눅스 운영체제부터 64bit로 전환해야 하고 그 위에서 구동되는 Java는 Oracle에서 만들고 있으며 앱의 개발환경은 또 다른 곳에서 개발되고 있고 앱의 구동환경인 달빅의 64bit 포팅도 여러가지 문제로 인해 쉽지 않은 입장이다. 


여러 자유(?)진영의 합작품인 안드로이드가 64bit 지원이라는 복병을 만나 잠시 주춤하는 모습을 보이고 있다. 어찌보면 구글은 아이폰의 대항마였던 안드로이드를 만들면서 가장 쉬운길이었던 두가지의 선택, 즉 운영체제로서 리눅스를 선택한 것과 개발환경 및 앱 운영환경으로 가장 범용적이고 많은 개발자를 확보할 수 있었던 Java를 선택한 댓가를 64bit 환경의 지원이라는 과제 앞에서 치르고 있는지도 모르겠다.


어쩌면 구글은 64bit 문제로 인해 장기적으로는 안드로이드를 버리는 계획을 내부적으로 수립하고 있을지도 모른다. 그리고 그 대안으로 크롬(Chrome) OS를 밀어줄 것이 확실시 된다.


Dalvik vs ART(Android Run-time)


하지만 구글은 당장 안드로이드를 버릴 수 없기 때문에 현실적인 판단을 할 수 밖에 없다. 그 결과로서 구글은 안드로이드의 앱 구동에 대한 부정적인 이미지를 벗기위해 성능개선에 매달렸고 새로운 앱 구동환경 즉 런타임환경을 새롭게 만들었다.


구글은 최근에 출시한 넥서스5에서 Dalvik을 대체할 새로운 앱의 구동환경으로 내놓은 ART가 그것이다. 보다 빠른 앱의 구동을 지원하는 ART는 이 포스트를 올리는 현재시간 기준으로 넥서스5에서만 사용이 가능하다.



구글이 나름대로 안드로이드의 성능개선을 위해 많은 노력을 하고있긴 하지만 언제까지 지원을 아끼지 않을지는 알 수 없다. 그리고 "리눅스-Java-앱"의 3계층 구조 자체를 뜯어고치지 않는 이상 아이폰의 성능을 쫒아가는 것은 거의 불가능하다고 보여진다.  하지만 그러기엔 너무 먼길을 왔다. 아마도 그래서 구글이 크롬을 밀어줄 것 같다는 생각은 더욱 확실해진다.


관련포스트 : 아이폰은 정말 폐쇄적인가?

관련포스트 : C언어를 독학으로 공부한 이야기와 C언어를 공부해야하는 이유.

신고
이 댓글을 비밀 댓글로
  1. 흥미로운 글 잘 읽었습니다. 다른 부분은 동의하지만 크롬OS로 갈아탄다는 것은 상당히 어려운 일인거 같습니다. 안드로이드에서 구동 중인 여러 서드파티 앱들을 버려야만 한다는 것인데 구글이 과연 그런 결단을 내릴런진 의문입니다. 또한 HTML5 기반으로 돌아가는 크롬 앱들의 퍼포먼스 또한 안드로이드보다 나을지 장담할 수 없기도 하고요.
    • 물론 구글이 안드로이드를 버리고 크롬OS를 모바일 플랫폼의 주력OS로 갈아타는 것이 쉽지는 않겠지만 데스크탑과 모바일의 크로스플랫폼에 더근접하기 위해서는 어쩔 수 없는 선택이라고 봅니다. 크롬OS가 모바일과 데스크탑에 올라간다면 당분간은 안드로이드와 병행지원이 되지 않을까 싶습니다. 하지만 장기적으로 봤을 땐 안드로이드는 개발주체가 너무 산만하게 많고 복잡한 구조라서 오래 끌고갈 OS는 아니라고 보여집니다.
  2. 우와! 멋진 글이네요 ^ ^
    안드로이드도 좋고 iOS도 좋아하는데, 안드로이드가 거의 완성이라는 느낌에도 아이폰의 속도는 따라잡기 힘들다고 생각하고 있는데, 요로한 내용이 있었네요.
    혹시 모바일용 크롬OS가 나오나다면 요즘 또 식어버린 모바일에 급 관심이 갈 것 같기는 합니다. ㅎㅎㅎ ^ ^;;;
  3. 안드로이드에 64비트 도입은 그리 문제가 되지 않습니다. 생각보다 자바 계층의 오버헤드는 많지 않습니다. 애플이 64비트로 이동하면서 더 바빠진 쪽은 인텔입니다.
    • 안드로이드는 리눅스 이지만 ARM 계열로 포팅되면서 SMP의 지원측면, 64bit 지원 측면, 대용량 메모리의 지원 등 에서 많은 어려움을 겪고 있지요. Dalvik을 버리고 새로운 런타임인 ART를 구글이 새로 만든 것도 비슷한 이유 때문이라고 보면 됩니다. 이는 근본적으로 CPU, OS, Java 등을 모두 각기 다른 벤더에서 만들기 때문에 발생한다고도 볼 수 있지요. 결국 누구 하나에 의해서 아키텍쳐를 혁신할 수는 없기 때문에 안드로이드는 급변하는 하드웨어 환경에서 도태될 수 밖에 없는 운명이라고 보여집니다.
      그래서 구글은 그러한 어려움에 대비하여 크롬OS등 자체적인 생태계 구축을 위해 노력하고 있다고 보시면 됩니다. 나무를 보지 않고 숲을 보면 쉽게 이해할 수 있으실 겁니다.
    • mog422
    • 2013.12.15 13:15 신고
    이미 리눅스 커널은 64bit 폴랫폼을 충분히 지원하고 있습니다. (arm64는 어떤지 잘 모르겠지만요) Dalvik 이던 ART던지간에 앱을 실행하는 런타임 자체만 arm64에서 돌아갈 수 있게 지원을 해준다면 문제가 없을거 같은데요.
    • 리눅스 자체는 64bit가 잘 지원되지요. 하지만 ARM 계열에 포팅된 안드로이드의 경우 SMP의 지원이 부족하고 여러 제약사항으로 인해 그 위에서 구동되는 Dalvik에 대한 업그레이드 등의 문제로 구글이 어려움을 겪고 있는 것으로 압니다. 그래서 구글이 자체적으로 아예 새로운 런타임인 ART를 만든 것이구요.
  4. 오브젝트C가 아니라 오브젝티브C 입니다 ^^* 좋은 글 고맙습니다.
    • 행인235
    • 2013.12.15 21:12 신고
    개인적으로 지적하고 싶은 점이 여러개 있네요.
    1. JIT의 개념과 용어 정의가 틀렸습니다.
    2. 자바 바이트코드와 달빅 바이트코드는 서로 다릅니다.
    3. 바이트 코드를 사용하는 이유가 플랫폼(비트수를 포함해서)에 상관 없이 쓰기 위함이기 때문이고, JIT이 적용된 VM은 전체 실행타임에서 평균적으로 바이트 코드도 기계어와 유사한 성능을 냅니다.
    4. 안드로이드는 자바 형식을 빌려 바이트 코드를 달빅 바이트코드로 재컴파일 하므로 오라클과 아무 상관 없습니다.(이런 구글의 무단 차용 때문에 오라클과 법적 문제는 있었습니다만)
    5. 안드로이드 자체의(제조사 문제 이전에) 64비트 지원이 늦어지는건 C로 구현된 안드로이드 기본 라이브러리들을 포팅해야 하기 때문이지 협력 문제가 아닙니다.

    전제로 놓으신 부분들이 대부분 잘못된 정보라 신뢰성이 떨어지네요;
      • 행인235
      • 2013.12.15 21:16 신고
      추가로 달빅을 두고 ART를 만든건, 안드로이드를 느긋하게 준비하던 와중에(1.4~1.6) 아이폰의 출시로 인해 제조사들의 요구로 급하게 안드로이드 버전을 올리며 반년만에 달빅에 JIT을 추가하는 등 급하게 만들어 졌기때문에, 이를 처음부터 제대로 재설계하고 개선하기 위함이지 64비트 이슈와는 상관 없습니다.
    • 1. 틀린점을 구체적으로 이야기해주세요. 저는 고전적인 JIT의 구조를 설명한 것입니다. 너무 민감하게 반응하시는 듯 하네요. ^^ 무조건 틀리다, 무조건 다르다라고 이야기하는 것은 억지일 수 밖에 없습니다.
      2. pure java의 바이트코드와 달빅코드가 조금 다르다는건 압니다만 이 글의 주제가 두 코드의 차이를 이야기해야 할만큼 깊이 있는 주제는 아니라고 생각됩니다.
      3. cpu의 애플리케이션 실행속도는 백만분의 일초를 따져야할 만큼 미시적인 세상의 이야기 입니다. 가상머신 위에서 인간의 체감속도를 기준으로 비슷하다고 이야기 하는건 다른게 아니라 틀린거라고 생각됩니다. art던 dalvik이던 바이트코드는 네이티브코드의 속도를 따라갈 수 없습니다. (많이 따라잡긴 했습니다만.) 더군다나 하드웨어를 직접 제어하는 부분에서는 네이티브코드를 쓸 수밖에 없지요. 그리고 크로스플랫폼의 완벽한 지원은 아직까지도 멀었다고 보여집니다. 제아무리 자바소스라할지라도 다른 플랫폼으로 넘겼을 때 100% 정상적으로 구동이 되지는 않습니다. 더군다나 하드웨어에 의존하는 기능이 많을 수록 말이죠.
      4. 왜 구글과 오라클이 라이센스 문제로 법적인 다툼을 할까요?? 그리고 다른 많은 vm 업체들도 오라클과 라이센싱을 체결합니다. 그들의 VM이 java와 java vm과 아무런 관계가 정말 없을까요? 결코 아무런 상관이 없지 않으며 java vm의 기반을 그대로 사용하고 변형한 것이기 때문입니다.
      5. 안드로이드의 경우 멀티코어를 아직도 제대로 지원하지 못하고 있습니다. 일반 앱개발자들은 이를 잘 모르고 있죠. 작년인가?? 인텔이 이 문제를 이슈로 제기 하기도 했구요. (물론 영업적 목적이지만요.) 64비트 지원 문제는 자바나 달빅의 문제이기 이전에 cpu와 os를 제공하는 구글과 리눅스 그리고 cpu 제조사간의 협력이 이루어져야 해결될 문제임이 분명합니다. 이것 저것 64비트에서 지원해야할 까다로운 문제를 빼버리고 포팅하게 되면 CPU의 성능을 제대로 사용할 수 없습니다. 포팅은 했되 안하니만 못한 포팅이 되는거죠.

      사실..이글을 이렇게 많은 분들이 읽으리라곤 생각하지 못햇습니다. 그리고 작은 차이를 갖고 꼬투리를 잡으시면 사실 제대로 반박할만한 실력을 갖추고 있지도 못합니다. 그저 폭넓은 관점에서 안드로이드의 문제를 지적하고 싶었기 때문에 쓴 글임을 이해해주시고 읽어주셨으면 합니다.

      감정적인 대응은 서로에게 스트레스만 줄 뿐입니다.
    • 레보맨
    • 2013.12.15 22:06 신고
    윗분말씀에 동감입니다. 추가로 크롬 OS가 안드로이드보다 더좋은 퍼포먼스를 기대할수있다는 근거가 있어야 저런 결론으로 수렴될수 있을텐데요...
    • 크롬OS의 성능까지는 제가 잘 모르고 쓴글이 맞습니다. 하지만 안드로이드보다는 좋지 않을까요?? 최신버전을 써보신 분이 댓글달아 주시면 좋겠네요.
    • calming
    • 2013.12.15 22:52 신고
    근거가 하나도 없는 허무맹랑한 이야기네요. 어디서 들었다라는 식으로 이런 말도 안되는 글을 쓰다니...
    • ㅎㅎ 안드로이드를 무척 사랑하시나 봅니다만..
      이런 댓글은 그저 본인이 인격적으로 덜 성숙되었거나 삐뚤어진 심성을가진 사람이라는 것을 인증하는 것 밖에는 되지 않습니다.
    • 행인2
    • 2013.12.16 02:04 신고
    잘은 모르지만 퍼포먼스를 위해 NDK 나 JNI 를 활용한다고 들었는데요. 서드파티 개발자의 빠른 개발을 도모하기위해 달빅과 같은 런타임을 이용하지만 필요하다면 리눅스의 *.so 타입으로 직접 핵심 모듈을 개발하여 동작도 가능 한걸로 알고있습니다. 유니티 3D 엔진 내부에 보면 리눅스 라이브러리와 윈도우 라이브러리를 같이 쓰는걸로 보이더군요.
    • .so 파일은 Unix/Linux에서 지원하는 Shared Object 파일임을 나타내는 일종의 확장자같은 것입니다. 윈도의 DLL과 유사한 것이죠. 하지만 so 파일은 navtive 코드파일입니다. 다른 플랫폼으로 넘어갈 경우 전혀 동작하지 않죠. java에서 so 파일을 만들어 쓴다는 것 자체가 이미 바이트코드, java가 추구하는 의미가 퇴색된다는 것을 의미합니다. JNI나 NDK는 네이티브 코드를 java와 같은 jit 언어에서 사용하기 위한 수단을 제공하는 것입니다. 그렇기 때문에 JNI나 NDK를 사용해서 성능을 높아진다는 것은 결국 native 코드를 이용해 성능을 높인다는 의미이며 또한 java가 크로스플랫폼을 100% 완벽하게 지원하지는 못한다는 것을 의미합니다.
      하지만 이러한 것을 따지는 것은 큰 의미가 없습니다. 어떠한 솔루션으로도 100% 완벽한 소스코드의 크로스플랫폼 호환성을 보장하는 것은 기술적으로 거의 불가능에 가깝기 때문입니다. 불필요한 논쟁을 할 이유는 없다고 보여집니다.
    • 하하하하하하하하
    • 2013.12.16 09:55 신고
    암요. 개발툴, AP, OS를 모두 개발하고 있으면

    64bit 지원은 "그리 어려운 일이 아니다." 지요. 하하하하... 하하하하하하하... 하하하하하하하하하하하하하하핳.... 단어 선택에 너무 짙은 허세가 느껴져서 그냥 웃어봅니다.
    • ㅎㅎㅎ 제가 개발하는 것도 아닌데 허세까지야~~ ^^
      안드로이드와 iOS의 상대적인 비교를 그렇게 절대적으로 평가해주시니 몸둘바를 모르겠습니다. 저도 개인적으로 애플의 iOS를 그리 좋아하지 않는 사람입니다.~
      GNU 만세~~ ^^
  5. 한창 배움에 굶주리는 대학생입니다.
    본 포스팅과 댓글을 읽다가 한가지 궁금한 것이 있어 여쭈어봅니다.
    요즘 안드로이드 앱들도 달빅을 거치는 문제와 자바의 하드웨어 제어 문제로 NDK나 JNI를 사용하여 C와 java를 섞는다던지 하기도 하는 걸로 알고 있습니다.
    (랄까 저도 특강때 이렇게 들은 것이 맞나 헷갈리지만요..)
    또한 NDK나 JNI를 떠나 델파이(구 오브젝티브-파스칼)를 통해 c만으로 짠 프로그램과 앞서거니 뒷서거니 하는 처리속도(동작에 따라 평균보다 더 빨라지거나 느려질 수도 있으므로)로 처리할 수 있게끔 지원하고 있는 걸로 알고 있습니다.
    여기서 제가 궁금한 것은 델파이로 제작된 앱이 자바 언어나 오브젝티브-c 기반인 os 환경에서 동작하기 위해서는 네이티브로 빌드가 될 것 같은데요.

    바이트코드의 앱과 네이티브코드의 앱의 차이가 많은 편인가요?
    또, 네이티브 앱의 경우 호환성이 떨어진다고 하셨는데 이유가 있나요?
    델파이의 최신판 기준(XE5) 앱 빌드시 안드로이드에서는 조금 무거운 느낌이 있는데 네이티브로 빌드하더라도 결국 안드로이드는 달빅 머신을 거쳐야만 하는 구조인건가요?(애플제품에서는 오브젝티브-c로 한듯 제 속도가 나온다네요)
    • NDK와 JNI는 java의 한계를 극복하기 위한 솔루션입니다. Java는 특정 하드웨어에 종속된 기능을 사용하기 위해 java의 순수함을 일정부분 포기한 것이지요. 하지만 포기라기 보다는 현실적인 해결책을 찾기 위한 노력이라고 보는게 더 옳을 겁니다. NDK는 Java(여기서 자바란 안드로이드 프로그래밍을 포함함)에서 사용하기 위해 만들어 놓은 C/C++ 라이브러리고 JNI란 NDK와 Java를 연결시켜주는 프로그래밍 요소입니다. 때문에 NDK와 JNI를 사용한다는 것은 C/C++에서 컴파일된 Native Code를 사용하는 것입니다. Pure Java는 아닌 셈이지요. (사실 Pure Java냐 아니냐를 따질 필요는 없습니다.)

      델파이(Delphi)는 제가 90년대 중반에 처음 써봤던 언어인데요.. 그전에는 Turbo Pascal을 조금써봤구요. 델파이도 컴파일언어입니다. 델파이는 Pascal 언어의 문법을 따르는 객체지향형 컴파일언어 입니다. 일부 포인터도 사용할 수 있는 C와 비슷한 수준의 언어죠. 따라서 속도차이도 크지 않습니다. C와 델파이(저는 델파이를 그냥 파스칼이라고 생각하고 싶네요)는 동일하게 컴파일과정을 거쳐 네이티브코드를 생산하기 때문이죠. (C가 조금 빠르다는 평가가 있었습니다. 그럴 수 밖에 없습니다. 두 언어를 써보면 이해하게 됩니다.)

      예를 들어 C언어와 델파이와 비주얼베이직은 모두 컴파일 언어입니다. 즉 소스코드를 작성하고 컴파일하고 링킹 과정을 거치면 스스로 실행가능한 실행파일(네이티브코드)이 생산됩니다. 그렇다면 세 언어로 완벽하게 동일한 기능을 수행하는 언어에 따라 최적화된 200라인의 정도의 코드를 작성했을 때 컴파일하고 링크되어 생산된 네이티브코드가 동일할까요? 네이티브코드란 기계어코드를 말합니다. 세개의 기계어코드가 동일할 까요?

      이 세개의 기계어코드 중 어느 것이 빠르냐는 결국 컴파일러가 최적화된 기계어코드를 생산해 내느냐 아니냐의 차이라고 보시면 됩니다. 그렇다면 이쯤에서 조금 고민한 뒤 무릎을 치셔야 합니다. ^^
      어떤 언어냐를 떠나서 기계어에 가까운 로우레벨 프로그래밍이 가능한 언어로 작성된 소스코드를 컴파일 했을 때 최적화된 네이티브코드가 생산되는 건 당연한 결과겠죠. 사람이 이해하기 쉬운 수준의 프로그래밍언어로 작성된 소스를 컴파일할 때는 컴파일러가 기계어로 전환하기 위해 더 오랜 시간을 소비하게 되고 당연히 사이드이펙트로 부가적인 코드들을 더 넣게 됩니다.

      소스코드와 컴파일된 기계어코드간의 차이가 가장 적은 언어는 어셈블리입니다.
      어셈블리언어는 명령코드(C나 델파이 자바로 치자면 함수???쯤??)가 이론적으로 기계어와 1대1 매핑이 되기 때문에 번역 과정이 무척 단순하죠. 그래서 어셈블리를 기계어로 전환해주는 번역기는 컴파일러라고 하지 않고 어셈블러라는 별도의 이름으로 부릅니다. 어셈블리는 기계어와 1대1로 매핑되기 때문에 CPU의 아키텍쳐에 따라 따라 사용하는 명령어가 모두 다릅니다. 즉 인텔 i5에서 사용하는 명령어와 인텔80386에서 사용하는 명령어 세트가 다릅니다. C언어는 두 CPU의 명령어 차이를 이해하지 않아도 되죠. 하지만 어셈블리로 프로그래밍을 한다면 두 CPU의 명령어 세트의 차이를 이해해야만 더 빠르고 효과적인 프로그래밍을 할 수 있는 경우가 발생합니다. ^^ 이부분을 이해하셔야 합니다. 왜 그런지요...

      그 다음으로 최적화된 기계어코드(네이티브코드)를 생산하는 것이 전통적인 C언어입니다. C와 C++은 다릅니다. 예를 들어 동일한 기능을 수행하는 코드를 전통적인 C언어로 작성했을 때와 C++의 클래스를 이용해 상속과 생성자, 소멸자 등의 개념을 적용해 작성했을 때 과연 어느 쪽이 작고 빠른 네이티브코드를 생성해줄까요? 당연히 C입니다.

      델파이는 C와 유사한 수준일 겁니다. 다만 델파이도 전통적인 구조적프로그래밍만을 지원하는 오리지널 pascal 이라면 C와 비슷하겠지만 객체지향개념을 C++과 동일하게 적용한다면 아마도 C++ 수준의 속도를 내는 네이티브코드를 생산해주리라 예상됩니다.
      (제가 테스트를 해보진 않았으니... ^^)

      java의 경우 조금 차원이 다릅니다. 네이티브가 아닌 byte code를 생산해주고 그 byte code를 다시 네이티브로 번역한 뒤 실행하니까요. 당연히 바이트코드를 네이티브로 번역할 때의 효율성이 그 속도를 좌우한다고 봐야겠죠...

      금융권과 대기업들의 업무시스템이 대부분 Java로 만들어져있지만 속도가 중요한 모듈들은 아직도 C와 같은 컴파일 언어를 사용하는 경우가 많습니다. 최근 계정계 시스템을 메인프레임에서 Unix로 다운사이징을 시도하는 국내 넘버1급의 은행의 경우 메인프레임에서 사용하는 코볼(cobol)언어를 그대로 Unix에서도 사용할 계획이라고 하죠. Java로 바꾸는 것은 엄두를 못내고 있는데 전환도 어렵고 오래걸리지만 "성능"도 우려스럽기 때문이라는 이야기가 있습니다. 눈에 보이는 체감속도가 중요한 부분에서는 Java가 많은 부분 뛰어난 성능을 보이지만 눈에 보이지 않는 미시적인 부분에서의 속도는 네이티브를 따라갈 수 없습니다.

      호환성의 경우 델파이로 제작된 앱을 java에서 사용하기 위해서는 네이티브코드인 DLL이나 SO 형태 즉 라이브러리로 생성이 되어야 합니다. DLL이나 SO 로 생성된 네이티브 코드는 독립적으로 실행은 불가능하지만 그 안의 함수나 객체를 다른 자바 앱에서 호출해 사용할 수 있도록 해줍니다. 당연히 DLL이나 SO는 네이티브코드구요 이 네이티브코드를 호출하는 것은 다른 네이티브코드나 java 모두 가능합니다. 이런 형태가 바로 NDK와 JNI 죠.

      바이트코드와 네이티브코드의 앱은 속도면에서 큰 차이가 있구요. 그 이유는 앞에서 설명한바와 같습니다.

      네이티브 앱의 호환성이 떨어진다는 이야기는 컴파일러가 CPU 플랫폼에 종속적이기 때문입니다. 네이티브 코드는 기계어입니다. 따라서 기계(CPU)가 달라지면 실행이 불가능하다고 보면 됩니다. 물론 i5 CPU의 기계어와 Atom CPU의 기계어는 기계어 수준에서 호환성이 높기 때문에 거의 대부분 호환이 됩니다.(가상화 부분이나 멀티미디어 등에서 호환이 안되는 경우가 있습니다.) 하지만 i5 에서 컴파일된 네이티브코드(기계어코드)는 ARM이나 PowerPC, Sparc 등 다른 벤더의 CPU에서는 실행이 안되겠죠. 하지만 바이트코드는 물리적인 CPU가 아닌 Sun(지금은 오라클)에서 만들어주는 가상머신에서 가상머신이 구동되는 물리적인 CPU에 맞게 네이티브코드로 번역을 해서 java 가상머신이 대신 실행해 주는 구조이기 때문에 "플랫폼 독립적이다"라는 이야기를 하는 겁니다. 즉 플랫폼 구분하지 않기 때문에 호환성이 높다라고 이야기할 수 있는 거죠.

      도움이 되셨기를 바랍니다.
    • 아! 정말 감사드립니다.
      사실 도서관에서 책을 뒤져 읽어봐도 잘 이해가 되질 않았는데 이렇게 자세히 설명해 주셔서 너무 감사드립니다!
      답변에서 많은 부분이 - 질문 외의 궁금점까지 - 뚫린 기분입니다.
      그전에는 그저 언어 특성상 그렇다 정도로만 알았는데, 왜 언어별로 같은 동작이라도 차이가 나게 되는 지도 알게 되었구요.

      네이티브가 난해하다 라며 싫증을 내는 아는 애가 있어 네이티브가 뭔가 했는데 사실은 이미 네이티브 프로그램을 저는 쓰고 있었네요.
      SSE3 와 같은 시피유 정보를 볼 때마다 궁금했던 부분도 그 이유를 알겠습니다.

      그렇다면 최신 CPU라도 이전 세대의 CPU에 탑재된 명령어 세트로 빌드되었다면 이전 CPU에서도 동작을 하는 것인가요?
      또 네이티브가 컴파일러가 설치된 CPU에 종속적이라면 배포되는 프로그램의 경우 어느 CPU에서 동작할 지 알 수 없는데 그런 경우에는 어떻게 빌드되는건가요?

      제가 요즘 델파이를 한번 살펴보는 이유는 저도 잘 알지는 못했으나 파스칼로 불리울 당시의 문제점이 많이 개선되어 좋아졌다고 한번 배워보라는 타대학 교수님의 추천으로 관심이 있었거든요.
      그런데 툴이.. 너무 비싼게 흠입니다만..음..
      80, 90 년대의 파스칼과는 여러면에서 많이 달라졌다고는 하지만 저 역시 당시에 쓰이던 파스칼은 써보지 않았으니..(써본분 말씀으론 껍데기만 같고 델파이와 파스칼을 별개의 언어로 보는게 옮다는 분도 계시네요)
      그런데 델파이도 결국 SO나 DLL 라이브러리 형태로 생성되어 자바에서 호출하는 식으로 쓰인다고 하셨는데 다른 작품들을 보면 그게 아닌거 같습니다.
      자바에서 호출을 한다면 그 부분에 대한 코드도 작성되어야 할 것 같은데 아직까진 제가 델파이를 학습하면서 그런 부분은 보지 못하였고 델파이를 인수한 엠바카데로에서도 단일 코드로 순수 네이티브를 지원하는 유일한 플랫폼이라며 강조하는걸 보니 달빅을 아예 거치지를 않는건가 하는 의문이 있었거든요.
      이 부분은 좀더 공부해서 안드로이드로도 시도해보면 다시 확인해봐야 겠습니다.
    • 아~델파이가 많이 달라진 모양이네요. SO나 DLL 형태가 아닌 코드를 생성해준다면.. 어떤 방식인지 감이 오지를 않네요.. ^^ C에 관심을 가지면서 파스칼이나 델파이에는 관심을 갖지 못했거든요.. 일반적인 형태가 아닌 java와 조금더 밀착(?)한듯 하네요. 하지만 중요한건 개발속도와 성능개선을 위해 개발자들이 엄청난 노력을 한다는 거죠. 그래서 어떤 새로운 개념과 아이디어가 나올지 알 수 없고..그 모든 것을 다 머리속에 넣을 수는 없다는 거죠. 항상 열린 마음으로 새로운걸 받아들일 준비를 해야하는게..IT 업종에서 일하는 사람들의 숙명이죠.. ^^

      컴파일러의 옵션에 보면..(예전에 본 기억이 있는데..) 기준 CPU를 어떤걸로 할건지를 선택하는 옵션도 있었습니다. 하지만 구형 펜티엄CPU와 윈도XP에서 코딩하고 컴파일한 실행하일이 대부분 수정없이 최신 i7과 윈도7에서도 잘 돌죠.. 하드웨어도 마찬가지지만 운영체제도 그렇구요..대부분 하위호환을 보장하는 것이 기본입니다. 물론 상위기종에서 하위기종에 없는 명령어세트를 사용하도록 상위기종 CPU기준으로 컴파일했다면(당연히 컴파일러도 상위기종 CPU의 명령어세트를 사용해 컴파일하도록 기능이 갖춰져있어야 겠죠..) 하위 기존 CPU가 장착된 윈도에서 실행하려면 당연히 실행되지 않겠죠... ^^

      파스칼이 많이 좋아졌나 보네요..제가 처음 파스칼을 배울때도 C언어보다 더 구조적 프로그래밍에 적합한 언어다...라고 해서 C보다 먼저 파스칼을 공부했었거든요.. 지금은 다 잊었지만..ㅋㅋ
      그리고 안드로이드에서도 제가 알기론 달빅이나 ART를 거치지 않는 C로 작성하고 컴파일된 프로그램을 돌릴 수 있는 것으로 알고 있습니다. 안드로이드도 리눅스인데... C로 컴파일한 프로그램을 실행할 수 없다는건..말이 안되겠죠.. ^^

      공부 열심히 하셔서... 좋은 성과 얻으시길 바랍니다..
    • 감사합니다!
      바쁘신 와중에 갑작스런 질문에도 답변을 해주셔서 감사드립니다.
      더욱 공부에 정진하여 저 또한 이쪽에 한 팔을 거들 날이 오면 좋겠네요.
      좋은 하루 되시고 종종 들러 여러 가지 정보를 참고하도록 하겠습니다!
    • 2014.08.03 01:47
    비밀댓글입니다
    • ART도 Dalvik과 마찬가지로 자바런타임의 일종입니다. 다만 Dalvik이 애플리케이션이 실행될 때 마다 Java Byte코드를 Native 코드로 매핑하기 위해 번역을 하죠.. (쉽계 얘기해서..) ART는 앱이 실행(java에서는 load가 더 적합한 용어죠)될 때 ART가 앱의 번역 된 Native코드를 저장해 두었다가 다음번 실행 시 참조하여 빠르게 실행하는 구조입니다. 그래서 앱이 실행될 때 딜레이타임을 줄이는 방식이죠. 그 이외에는 크게 개선된 사항은 없는 것으로 알려져 있습니다. 아마도 앱을 다운받아 설치하고 실행하면 최초 실행 시 번역된 Native 코드(실제 Native코드인지 캐시인지는 모르겠지만)를 따로 보관하는 것으로 보입니다. 때문에 번역된 내용을 저장하기 위해 저장소를 더 사용하거나 아니면 리부팅하기 전까지만 메모리에 번역된 내용을 저장할 수 밖에 없기 때문에 저장소 혹은 램을 더 사용할 수 밖에 없겠죠..
      사실 운영체제와 자바의 기본을 제대로 배웠다면 대충 ART 장점에 대해 듣는 순간 이정도는 바로 캐치해야 합니다. dotbin 님은 금새 눈치채시고 물어보시는 거라 생각됩니다. ^^
      • 2014.08.26 15:27
      비밀댓글입니다
  6. 어쨌든 안드로이드 5.0이 나와 버렸군요.

    1. 힘든 64비트 지원 -> 이제 잘 됩니다. 더해서 공식적으로 x86도 지원합니다. 승리의 ART

    2. 인터프린터라서 느림 -> 이제 AOT라서 설치시 컴파일(기계어, 머신 코드를 생성) 합니다.

    거창하게 제시하셨던 숙제를 1년 만에 모두 해결해 버렸으니... 글 내려 주세요

    이런 잘못된 정보가 인터넷에 남아 있으면 않됩니다.
    • 저는 본문에서 64비트의 지원이 불가능하다고 언급한적이 없습니다. 여러 ap제조사와 구글이 어렵고 힘든 과정을 거쳐야 한다고 했죠. 그 과정은 쉽지 않습니다. 수년이 걸리는 걸 보지 않으셔나요 ? 반면 애플은 폐쇄적인 그들만의 아키텍쳐로 인해 오래전에 완료했습니다. 그 사실만은 인정해야죠. 님의 말대로 삼성은 아직도 그 힘든 작업을 마무리하지 못했고 롤리팝에서의 지원여부를 공개하지 않고 있습니다. 무엇이 원인이고 무엇이 결과인지 본문을 보고 판단하세요. 글의 요지를 잘 살펴보시기 바랍니다.

      자바는 컴파일된 바이코드를 각기 다른 플랫폼에서 재컴파일 없이 실행가능하게 하는 이식성을 목표로 개발된 언어입니다. 요즘의 자바만 보셔서 모르시겠지만 과거엔 잠시나마 분명 가능했습니다. 하지만 속도의 개선을 목표로 여러 플랫폼에서 그런 완벽한 이식성을 포기하게 됐죠. 이식성의 의미를 엄격히 이해하시길 바랍니다.무엇을 개발하든 이거 봐주고 저거 봐주는 유연함?은 때때로 치명적인 문제를 야기할 수도 있습니다. 엄격히 말해 aot나 art는 속도를 얻기 위한 fake 입니다. 그런 fake로 인해 이식성은 더욱 손상된 것이죠. 하지만 그런 fake가 잘못이라거나 해서는 안된다는 이야기는 절대 아닙니다. 기술분야에서는 때론 fake가 정답일 수도 있으니까요.. 다만 fake가 가져올 여파를 분명히 고려해야 한다는 겁니다.

      지금 님의 글은 분명 자바 추종자의 글입니다. 자바가 느리다. 자바의 이식성이 현재들어 많이 손상됐다는 글은 100% fact입니다. 대한민국이 망할놈의 나라면 이민가십시오. 당신의 토론 불가한 태도가 바로 망할놈의 자세입니다.

      언제 봤다고 불쌍하다느니 사실이 아닌 글을 내리라느니 버릇없는 글을 쓰면서 비난하나요? 그리고 아무데서나 아무주제에나 세줄요약 같은 되도 않는 말을 쓰지 마시기 바랍니다. 그런 말은 디씨나 오유나 일베 같은 가십을 다루는 사이트에서나 쓰시길 바랍니다.

      당신은 자바의 이슈를 논하기 전에 어디엔가 버려둔 온 예의부터 되찾기를 바랍니다. 다음부터는 예의 없이 쓰는 댓글은 예고 없이 삭제할 것임을 알려드립니다.
  7. 글 잘 읽었습니다. 덕분에 작년 몇 개월 동안 자바와 안드로이드를 공부하며 고민했던 부분들을 정리할 수 있는 기회가 되었습니다. 많은 것을 얻어 갑니다. 감사합니다.

    그리고 댓글들을 읽다 보니 타인을 전혀 배려 안하는 분들이 너무 많다는걸 세삼 느낍니다! 사람들 저마다 자라온 환경과 머릿속에 박혀 고착화된 지식이 다르며 그걸 표함함에 있어도 "아"가 다르고 "어"가 다르거늘... 조금 그러네요! 그냥 저 처럼 세상의 10%는 좋은 사람, 80%는 저 같은 평범인, 그리고 나머지 10%는 몰상식한 사람이구나 라고 여기시고 마음에 두시지 말길 바랍니다.
    • 저도 깊이 있는 지식이 있는 것은 아닙니다. 그래도 도움이 되셨다니...그저 기분이 좋습니다~~
      그리고 별로 신경 쓰지 않습니다~ ^^ 즐거운 하루~하루 되시길 바랍니다.
  8. 읽고나니. 13년도 글이군요. 제목이 자극적이여서 댓글이 불바다인가 봅니다 하하.

    본문에서 장기적으로는 안드로이드를 버리고 크롬OS로 갈 것이다. 라고 하셨는데 현재 시점에서 생각이 변화하시진 않으셨는지 궁금합니다. 물론 제시점에서도 크롬OS는 구글이 생각하는 미래를 위한 발판이고 그러한 의지가 보입니다. 하지만 안드로이드 생태계가 이젠 너무 광범위해지고 커졌습니다. 구글은 계속해서 안드로이드 웨어/오토/롤리팝 등을 차례차례 발표하고 있구요.

    때문에 저는 크롬 OS와 안드로이드가 가는 방향이 다르다고 생각합니다.
    윈도우가 터치스크린을 고려한 윈도우 8에서 윈도우 10으로 회귀하듯. IOS 와 OSX가 공존하듯
    PC와 모바일 운영체제에는 UX 적인 차이가 존재한다고 생각합니다. 그리고 이것을 하나의 운영체제에 자연스럽게 담는것은 어려운일이죠.

    물론 제가 안드로이드쪽 개발을 하고있어서 시점이 이러한 것 일수도 있겠지만요.
    (사람은 무의식적으로 보고싶은것만 보게된다고하니)
    • 말씀하신 것이 맞습니다. 전략이란 것은 시장상황에 따라 변하는 것이기 때문이죠. 안드로이드가 여러 단점이 있지만 이미 모바일 생태계에서 입지가 탄탄하고 성능 개선을 위해 많은 개발자들이 노력하고 있고 성과도 나타나고 있죠.. 구글이 크롬을 인위적으로 띄워줘도 역전은 쉽지 않을 겁니다. 또한 안드로이드를 포기하진 않을것이구요..

      예전 비디오기기 시장에서 vhs와 베타 방식의 사례를 보더라도 알 수 있듯이 말입니다...
  9. 오래 전 글이지만 잘 보고 갑니다.

    모바일은 안드로이드를 2009년부터 개발하다가 아이폰 개발을 늦게 시작했지만 타이틀이 사실이긴 하죠..

    안드로이드 덕에 재미있게 보내고 있지만 부정하고 싶진 않네요 ㅋㅋ

    저는 2014년인가부터 순다 피차이 크롬 개발 담당하던 부사장이 구글 IO에 전면에 나선 걸 보고, 유니센터 계정분께서 말씀하신 것과 비슷한 걸 느껴오고 있었는데, 조금 다르게 생각해보니 크롬 OS랑 모바일 OS랑 별개로 계속 진행은 하겠지만 크롬이 구글의 주력사업으로 올라설거다라는 걸 상징적으로 보여준 게 아녔나라는 생각도 들고 ㅋㅋ 복잡하네요.

    잡설만 길었네요.

    여튼 IT 생태계는 돌고 도는 것 같다가 비슷하려나 모르겠네요 ㅎㅎ
    모두 즐프하세요~
    • 저야 안드로이드와 별로 관계 없는 일을 하기에 한발짝 떨어져 있으면서 보이는 대로 느끼는 대로 쓴 글이죠.. 사실 현 시점에서는 크롬OS는 등장만 했을 뿐 파급력은 잘 느껴지지 않습니다. 오히려 요즘은 MS의 모바일 시장에 대한 도전(?)이 강하게 느껴지는게 더 피부에 와닿기도 하구요.

      안드로이드의 속도 문제는... 자바 개발자들에겐 꽤나 예민한 문제 인것 같습니다. IOS개발하시는 분들은 오히려 덤덤한데 말이죠. ^^

      방문 감사합니다~ ^^