자바란?

 

자바는 “언어”이면서 동시에 “표준”이다

자바를 단순히 하나의 프로그래밍 언어라고만 이해하면 이후 개념에서 계속 막히게 된다.
자바의 핵심은 표준(specification) 이 존재한다는 점이다.

자바에는 다음과 같은 공식 표준 문서들이 존재한다.

• 자바 문법은 어떻게 생겼는가
• 자바 컴파일러는 어떤 규칙으로 동작해야 하는가
• 자바 표준 라이브러리는 어떤 API를 제공해야 하는가
• JVM은 바이트코드를 어떻게 실행해야 하는가

이 모든 것이 자바 표준 스펙(Java Standard Specification) 이다.
즉, 자바는 “이렇게 동작해야 한다”는 설계도를 먼저 정의한 언어이다.

이 단계에서는 아직 실행 가능한 프로그램이 존재하지 않는다.
오직 “규칙”만 존재한다.

 

 

자바 구현체란 무엇인가

표준만으로는 실제 프로그램을 실행할 수 없다.
그래서 이 표준을 실제로 구현한 결과물들이 등장한다.

대표적인 자바 구현체는 다음과 같다.

• OpenJDK
• Eclipse Temurin
• Amazon Corretto

이들은 모두 자바 표준 스펙을 충실히 구현한 배포판이다.
즉, 내부 구현 방식이나 최적화는 다를 수 있지만, 외부에서 보이는 동작은 같아야 한다.

이 구조 덕분에 자바는 다음과 같은 특성을 가진다.

• 구현체를 바꿔도 코드 수정이 거의 필요 없다
• 특정 회사에 종속되지 않는다
• 장기적으로 안정적인 언어 생태계를 유지할 수 있다

학습 단계에서는 어떤 구현체를 사용해도 무방하다.
실무에서는 운영 환경(AWS, 기업 정책 등)에 따라 선택하는 경우가 많다.

 

 

자바 프로그램은 두 단계로 실행된다

자바 프로그램은 컴파일 → 실행이라는 두 단계를 거친다.

 

1) 소스 코드 작성

개발자는 사람이 읽을 수 있는 자바 소스 코드를 작성한다.

public class Hello {
    public static void main(String[] args) {
        System.out.println("Hello Java");
    }
}

이 파일은 단순한 텍스트일 뿐이며, 컴퓨터는 아직 이를 실행할 수 없다.

 

2) 컴파일: .java → .class

컴파일 단계에서는 `javac`가 사용된다.

• 자바 문법 검사
• 타입 검사
• 소스 코드를 바이트코드(.class) 로 변환

여기서 생성되는 `.class` 파일은 특정 운영체제용 실행 파일이 아니다.
`JVM`이 이해할 수 있는 중간 표현 언어이다.

 

3) 실행: JVM 위에서 동작

실행 시에는 java 명령이 사용된다.

• `JVM`을 시작한다
• `.class` 파일을 `JVM`에 로드한다
• 바이트코드를 해석하거나 `JIT` 컴파일하여 실행한다

중요한 점은 운영체제가 아니라 `JVM`이 실행을 담당한다는 사실이다.

 

 

IDE는 이 모든 과정을 대신 처리해준다

실제로는 개발자가 `javac, java` 명령을 매번 직접 치지 않는다.
IDE(IntelliJ, Eclipse 등)가 이를 자동으로 처리한다.

 

IDE는 다음을 대신 수행한다.

• JDK 설치 및 버전 관리
• 컴파일 자동 실행
• 실행 설정 구성
• 결과 출력

그래서 개발자는 코드 작성과 로직 이해에만 집중할 수 있다.

 

 

일반 프로그램은 운영체제에 종속된다

일반적인 프로그램은 운영체제별로 다르게 만들어진다.

 

 

 

• Windows용 exe
• macOS용 app
• Linux용 binary

이 파일들은 서로 호환되지 않는다.
운영체제의 시스템 호출과 실행 포맷이 다르기 때문이다.

 

 

자바가 운영체제에 독립적인 이유

자바는 이 문제를 JVM이라는 계층으로 해결한다.

 

 

자바의 구조는 다음과 같다.

• 개발자는 `.class` 파일을 만든다
• 운영체제마다 해당 `OS`에 맞는 `JVM`이 존재한다
• `JVM`이 바이트코드를 `OS`에 맞게 실행한다

즉, 운영체제 차이는 JVM이 흡수한다.
자바 프로그램은 JVM 위에서만 동작하면 되기 때문에 운영체제 독립성을 갖는다.

 

 

 

개발 환경과 운영 환경이 달라도 되는 이유

자바의 구조는 실무에서 매우 큰 장점을 가진다.

 

 

• 개발자는 Windows나 macOS에서 개발한다
• 서버는 Linux 환경에서 운영된다
• 개발 JDK와 운영 JDK가 달라도 된다

중요한 것은 바이트코드와 JVM의 호환성이다.
이 덕분에 자바는 서버 개발에서 오랫동안 표준 언어로 사용되어 왔다.

 

 

개발자는 Windows나 macOS에서 개발한다

개발 PC는 사람마다 다르다.

• 어떤 사람은 Windows
• 어떤 사람은 macOS
• 어떤 사람은 Linux

여기서 중요한 건 개발자가 OS에 맞는 JDK를 설치해서 컴파일/실행을 한다는 점이다.

즉, macOS에서 개발하면 macOS용 JDK로 javac(컴파일러)와 java(실행기)를 쓰고,
Windows에서 개발하면 Windows용 JDK로 똑같이 javac, java를 쓴다.

하지만 이때 만들어지는 결과물은 “macOS용 실행파일”이 아니다.

개발 결과로 만들어지는 핵심 산출물은 보통:

• .class (바이트코드)
• .jar (클래스들을 묶은 패키지)
• .war (서버 배포용 패키지)

이런 것들인데, 이들은 운영체제용 실행 파일이 아니라 JVM용 바이트코드 덩어리다.

그래서 개발 OS가 무엇이든 “바이트코드 생성”까지는 동일한 흐름이다.

 

 

서버는 Linux 환경에서 운영된다

실무 서버는 `Linux`가 압도적으로 많다. 이유는 현실적이다.

• 서버용으로 안정적이고 가볍다
• 라이선스/비용이 유리하다
• 자동화/배포/운영 도구들이 Linux 기준으로 풍부하다
• 클라우드(AWS, GCP 등)에서 기본이 Linux인 경우가 많다

그래서 개발자는 `macOS`에서 개발하더라도, 배포 대상 서버는 `Linux`인 경우가 흔하다.

여기서 핵심은:

서버에서 실행되는 건 “개발자의 맥에서 돌던 그 프로그램”이 아니라
“서버 Linux 위의 JVM이 바이트코드를 실행하는 프로그램”이라는 점이다.

 

 

왜 OS가 달라도 “같은 바이트코드”를 읽을 수 있나?

핵심은 “운영체제가 읽는 게 아니라 JVM이 읽는다”이다.

• .exe 같은 건 운영체제가 직접 실행한다 → OS가 달라지면 깨짐
• .jar/.class는 JVM이 실행한다 → JVM만 있으면 OS가 달라도 됨

그리고 JVM은 OS별로 따로 존재한다.

• Windows용 JVM
• Linux용 JVM
• macOS용 JVM

각각 내부 구현은 OS에 맞게 다르지만, 바이트코드를 해석하는 규칙은 동일해야 한다(자바 스펙).

 

즉, Windows에서 만든 `jar`는 `Linux`로 옮겨도,
Linux JVM이 jar 안의 바이트코드를 그대로 읽고 실행하기 때문에 성립한다.
단, 운영 JVM 버전과 빌드 타겟 버전만 맞추는 게 핵심이다.