JVM이 무엇인가?
이번 포스팅은 JVM이 무엇인지 어떻게 등장하게 되었는지 얘기해볼 것입니다.
JAVA의 큰 장점 중 "운영체제에 독립적"이라는 점이 있습니다. 이것은 JVM의 역할로 인해 지니게된 장점입니다.
JVM(Java Virtual Machine, 자바 가상 머신)은 무엇일까요?
JVM이 무엇인지 얘기하기 전에 왜 나오게 됐는지 생각해보고자 합니다.
1. 기계어
현재와 달리 먼 과거로 돌아가서 "컴퓨터"와 처음 의사소통을 할 수 있었던 시절에는
지금처럼 소스코드로 컴퓨터에게 연산을 맡기는게 아닌, 개발자들이 직접 (컴퓨터가 알아먹을 수 있는) 0과 1을 이용해서 나름의 규칙을 통해 명령을 만들었습니다.
만약 1+3 수식 연산을 처리하도록 명령한다면, 2진법을 이용해서 01010101 00000001 00001001 과 같이 작성한 것입니다.
이렇게 이진 숫자로만 되어있는 기계어가 컴퓨터에 명령을 내리는 방법의 시초였습니다.
2. 어셈블리어
이후 인간이 이해할 수 있는 단어들로 조합된 "어셈블리어"라는 프로그래밍 언어가 등장합니다.
어셈블리어는 기계어의 문제점(매우 낮은 가독성, 이해하기 어려움)을 개선합니다.
개발자가 어셈블리어를 작성하면 어셈블러가 이를 기계어 코드(2진수)로 변환하여, 컴퓨터에게 전달하게 됩니다.
하지만 어셈블리어도 문제가 있습니다. 기계마다 어셈블리어가 영향을 받는 다는 것이었습니다.
각각의 회사에서 만든 컴퓨터에 따라 다른 어셈블리어가 존재해야했고,
개발자들은 각 컴퓨터의 어셈블러가 이해할 수 있는 어셈블리어를 공부하여 사용해야했습니다.
(+ 컴퓨터마다 바이트 저장 방식도 달라 숫자 표기법 또한 습득해야했다고 합니다.)
결국 서로 다른 100개의 컴퓨터가 존재하면, 개발자는 조금씩 다른 어셈블리어로 된 100개의 소스코드를 작성해야했습니다.
3. C언어 (WOCA 아닌 WOCA)
다행히 이 문제를 보완하기 위해 "C언어"가 등장합니다.
개발자는 "딱 하나의 소스코드"를 작성하면, 기계에 맞춰진 "컴파일러"가 각 기계가 이해하는 기계어로 변환해줍니다.
즉, 개발자가 소스코드를 작성하면, 특정 OS나 CPU 구조에 맞춰진 컴파일러에 의해 컴파일이 됩니다.
컴파일된 코드를 Binary code, 기계가 읽을 수 있는 이진 코드, 기계어라고 부릅니다.
이를 WOCA의 특성이라 부르며, Write Once, Compile Anywhere, '한번만 작성하고 컴파일하면 어디서든 사용 가능하다' 를 의미합니다.
하지만 이러한 컴파일러는 다양한 환경의 기기(다른 OS, CPU 구조)를 사용하는 환경에서는 이 기계어를 이해할 수 없다는 문제가 존재합니다.
컴파일러는 같은 형식의 기계어를 만들어내지만, 각 환경에 맞춰진 컴파일러이기 때문에, 다른 환경에서는 이해하지 못하는 것입니다.
이를 "이식성이 낮다"고 표현합니다.
이는 C언어를 OS에 종속된 언어라고도 표현하는데, (뒤에 나올 JAVA는 C언어와 달리 OS에 종속되지 않은 언어입니다.)
A OS 환경에서 컴파일된 코드가 B OS환경에서는 읽어질 수 없기에 A OS 환경에 종속되었다고 볼 수 있습니다.
여기서 "다른 환경"이라는 것에 대해 짧게 얘기하면,
각각의 CPU는 각각의 ISA (Instruction Set Architecture)가 존재하고, 같은 x86 CPU라 하더라도 32 bit, 64 bit 가 존재합니다. 심지어 각 bit 별로 window, mac, linux 등 다른 OS가 존재합니다.
이러한 OS들은 다른 System call, libraries가 존재합니다.
4. JAVA (WORA)
이렇게 컴파일러가 운영체제에 의존적(환경마다 다르게 만들어지는 기계어)이었던 문제를 해결하고자 JAVA가 등장합니다.
JAVA 언어로 작성한 소스파일은 바로 운영체제로 가는 것이 아닌, "JVM을 거쳐서 운영체제와 상호작용"을 하는데,
그렇기 때문에 개발자가 소스코드를 작성하는 것에 있어서 "운영체제로부터 독립적"일 수 있게 됩니다.
이것이 가능한 이유는 컴파일된 코드와 하드웨어/OS 사이 중간에서 해당 하드웨어/OS 환경에 알맞는 JVM이 Byte Code로 변환해주기 때문입니다. 이전까지는 다양한 환경에 맞춰진 컴파일러가 이해할 수 있도록 코드에 변경이 필요했습니다.
그렇기 때문에 JAVA 프로그램은 아래와 같은 구조적 차이가 있습니다.
C언어에서의 컴파일 과정은 소스 코드를 Binary Code(기계어)로 바로 변환하여 하드웨어에 의해 읽어지고, 그렇기 때문에 환경에 따라 코드가 달라져야했던 것과 달리,
Java는 아래 두가지 과정을 거치는 것을 통해 코드의 수정이 불필요하게 됩니다.
1. Java Compiler가 JAVA로 작성된 소스 코드 .java 파일을 .class 파일인 Byte Code로 컴파일합니다. (javac 명령어)
- example.java 파일 --- java 컴파일러를 통해 컴파일(javac example.java) ---> example.class(example.java의 Byte Code)
- 해당 코드는 직접 CPU에서 동작할 수 있는 코드가 아닙니다. 가상머신 JVM이 이해할 수 있는 코드입니다.
2. JVM이 Byte Code를 기계어(Binary Code)로 변환합니다.
- example.class 파일 --- JVM에 의해 실행(java example.class) ---> 기계어(Binary Code)
- Byte Code를 기계어로 변환시키기 위해 가상 CPU가 필요한데, 이것이 Java Virtual Machine인 것입니다.
- JVM에 의해 컴파일된 기계어는 바로 CPU에서 실행 가능한 코드입니다.
*CLI 환경에서의 명령어입니다.
JAVA는 "Write Once, Read Anywhere"이라는 철학으로 만들어졌습니다.
여기서 "Read"는 재컴파일할 필요 없는, 바로 기계가 읽고 실행할 수 있게 한다는 의미로 해석해도 좋을 것 같습니다.
즉, 한번 컴파일 한 것은, 어느 구조에서든지 읽고 동작할 수 있어야 한다는 것을 의미합니다.
A 환경에서 컴파일한 Byte Code를 다른 B, C 환경에서도 쉽게 동작할 수 있어야 합니다.
이것이 가능하기 위해서는 A 환경에서 컴파일한 Byte Code가 B, C환경에도 알맞은 기계어로 변환되어야 합니다.
그래서 이러한 다양한 환경에서 실행 가능하도록, Byte Code를 기계어(Binary Code)로 변환해주는 것이 JVM입니다.
이로 인해 JAVA언어는 이식성이 높은 특성을 갖게 됩니다.
- Binary Code : 기계(컴퓨터)가 읽을 수 있는 이진 코드. 기계어
- Byte Code : 가상머신이 읽을 수 있는 이진 코드
- javac가 컴파일한 Byte Code는 모든 환경의 JVM에 의해서 사용될 수 있고, 특정 OS에 알맞은 JVM이 해당 OS에 알맞는 기계어(Binary Code)로 바꾸어줍니다.
➕ JAVA는 (C언어와 달리) 두번의 컴파일로 인한 속도의 문제가 있는데, 이를 보완하기 위해 JIT 컴파일러가 필요한 부분만을 기계어로 바꾸어 줌으로써 성능 향상을 가져오도록 했습니다.
(그럼에도 C언어의 실행 속도를 따라잡을 수는 없다고 합니다)
결국, JAVA의 등장으로, 엄밀히 말해 JVM이라는 소프트웨어의 등장으로
물리적 컴퓨터 위에서, 기기에 따른 어떠한 수정없이, 어떠한 환경에 의존하지 않고 Java 소스코드가 잘 돌아가도록 하기 위해 가상적 환경을 구축함으로써
운영체제에 의존적이었던 문제까지 해결하게 됩니다.
JVM의 정의를 내려보면
CPU나 운영체제의 종류와 무관하게(독립적으로) 자바 바이트코드를 실행시킬 수 있는 가상적 환경의 소프트웨어입니다.
JVM은 Java Virtual "Machine"이지만, 가상 CPU의 역할을 하는 "소프트웨어"입니다.
CPU의 역할을 하기 때문에 Machine이라는 단어를 사용한 것 같다는 의견이 있습니다.
공부하며 작성한 포스팅입니다.
피드백과 댓글은 환영입니다😊