자바 백엔드 입문 시리즈 첫 글. 자바가 뭐고 JVM은 어떻게 도는지, 그리고 왜 한국 회사 백엔드의 압도적 표준이 됐는지를 카세트 플레이어 비유로 풀어쓴 입문자용 학습 노트.
이 글은 자바 백엔드 입문 시리즈 59편 중 1편이에요. Phase 0 자바 기초 5편 → Phase 1 Spring 시작 → IoC 컨테이너 → Web MVC → JPA → 통합·캐싱까지, Spring·JPA·PostgreSQL·Redis·Kafka를 한 흐름으로 풀어 갑니다.
채용 공고를 보다가 "Java·Spring 경력 N년" 줄을 N번 본 적 있을 거예요. 신입 백엔드 채용 절반 이상이 자바 기반인데, 특히 한국 회사가 그래요. 이번 1편에서는 자바 백엔드가 무엇이고 왜 그렇게 압도적인 표준이 됐는지 풀어 보겠습니다. 끝까지 따라오시면 자바·JVM·JDK·JRE 네 이름이 하나로 정리됩니다.
이 시리즈는 Oracle Java 공식 문서, Spring·JPA·PostgreSQL·Redis·Kafka 공식 문서와 여러 공개 학습 자료를 참고해 한국어 학습 노트로 풀어쓴 자료입니다.
JDK를 직접 설치하고 HelloWorld.java 한 개를 컴파일·실행해 보면 본문이 머리에 훨씬 잘 박혀요.
처음 자바 백엔드를 펴면 어렵게 느껴지는 이유
처음 자바 책을 펴면 두 가지가 한꺼번에 헷갈립니다.
첫째, 자바·JVM·JDK·JRE가 다 비슷한 이름인데 다른 것이거든요. 자바는 언어, JVM은 실행기, JDK는 개발자 키트, JRE는 실행 환경 — 머릿속에 정리가 안 됩니다. 책마다 부르는 이름도 미묘하게 다르고요.
둘째, "왜 자바 백엔드가 그렇게 압도적이지?" 가 안 보입니다. Python·Go·Node.js도 백엔드에서 잘 쓰이는데 왜 굳이 자바? 이 의문이 풀려야 자바 공부에 마음을 붙이게 됩니다.
이 글에서는 두 의문을 카세트 플레이어 비유 한 가지로 같이 풀어요. 끝까지 읽으면 "아, 자바 백엔드는 이런 거구나" 가 한 번에 박힙니다.
자바의 정체 — JVM이라는 가상 컴퓨터 위에서 도는 언어
자바는 1995년 Sun Microsystems(2010년 Oracle 인수)가 발표한 객체지향 프로그래밍 언어예요. 다른 언어와 결정적으로 다른 한 가지가 있는데, JVM(Java Virtual Machine) 위에서 실행된다는 점이에요.
회사 비유로 풀어볼게요. JVM은 "어디 가져가도 같은 카세트테이프를 재생해 주는 휴대용 플레이어" 같은 존재입니다. C나 C++로 쓴 프로그램은 카세트테이프 자체를 윈도우용·맥용·리눅스용으로 따로 만들어야 해요. OS마다 다시 컴파일해야 하거든요. 자바는 다릅니다. 카세트테이프(.class 파일)는 한 번만 굽고, 각 OS에 맞는 플레이어(JVM)가 알아서 재생해줘요.
이 차이 때문에 자바는 "Write Once, Run Anywhere" 라는 슬로건을 1995년부터 들고 다닙니다. 한 번 작성하면 어디서나 실행. 윈도우 노트북에서 짠 코드가 리눅스 서버에 그대로 배포되는 마법이 이 JVM 덕분이에요.
여기서 헷갈리기 쉬운 함정 하나 — 자바·JVM·JDK·JRE 네 이름의 차이.
| 이름 | 정체 | 비유 |
|---|---|---|
| 자바 | 프로그래밍 언어 그 자체 | 악보 (작곡 규칙) |
| JVM | 자바 바이트코드를 실행하는 가상 머신 | 카세트 플레이어 |
| JRE (Java Runtime Environment) | JVM + 표준 라이브러리. 실행에 필요한 최소 세트 | 플레이어 + 표준 음반 |
| JDK (Java Development Kit) | JRE + 컴파일러(javac) + 개발 도구. 코드 짤 때 필요 |
플레이어 + 음반 + 작곡 도구 |
포함 관계로 그리면 JDK ⊃ JRE ⊃ JVM이에요. 자바 코드 짤 때는 JDK, 남이 짠 자바 프로그램만 실행할 때는 JRE만 있어도 OK.
악보(자바) → 카세트테이프(.class) → 플레이어(JVM). 작곡하려면 JDK, 들으려면 JRE.
한 번 작성하면 어디서나 — 플랫폼 독립성의 정체
좀 더 구체적으로 풀어볼게요. 일반적인 C 프로그램의 흐름은 이래요.
HelloWorld.c → gcc (Linux x86_64) → HelloWorld (Linux 전용 실행 파일)
윈도우에서 돌리려면 다시 윈도우용으로 컴파일해야 해요. 자바 프로그램은 흐름이 한 단계 더 들어갑니다.
HelloWorld.java → javac → HelloWorld.class (바이트코드) → JVM이 OS에 맞춰 실행
HelloWorld.class 파일이 핵심이에요. "어느 OS인지 모르는 중간 코드" 거든요. JVM이 "내가 지금 macOS에서 도는 거니까, 이 바이트코드를 인텔 맥 기계어로 번역해서 실행할게" 하고 알아서 처리합니다.
여기서 시험 함정이 하나 있어요. 자바를 "인터프리터 언어" 로 부르는 글이 가끔 있는데, 정확히는 컴파일 + 인터프리터 혼합형이에요. javac로 한 번 컴파일하고(소스코드 → 바이트코드), 실행 시 JVM이 인터프리트해요(바이트코드 → 기계어). "자바는 순수 인터프리터 언어다" 가 보기로 나오면 X.
게다가 JVM 안에는 JIT(Just-In-Time) 컴파일러가 들어 있어요. 처음엔 바이트코드를 한 줄씩 인터프리트로 돌다가, "이 메서드는 자주 도네" 싶으면 통째로 기계어로 컴파일해 캐싱합니다. 그래서 자바 서버는 오래 돌수록 빨라지는 특이한 특성이 있어요.
한 줄 정리 — .java → javac → .class → JVM. 컴파일·인터프리트 두 단계를 다 거치고, JIT가 자주 도는 부분을 캐싱해서 점점 빨라짐.
왜 자바 백엔드가 한국 회사의 압도적 표준인가
자바 백엔드가 다른 언어 대비 한국에서 압도적인 이유는 다섯 가지로 정리돼요.
1. JVM이 30년 동안 다듬어진 성숙도
1995년 출시 이후 30년간 JVM은 GC(가비지 컬렉터)·JIT(Just-In-Time 컴파일)·메모리 관리가 극도로 정교해졌어요. 회사 시스템처럼 "하루 24시간 도는 서버" 에서 자바가 강한 이유의 절반이 이 JVM 성숙도예요.
2. 정적 타입 — 컴파일 시점에 잡히는 버그
자바는 변수 타입을 미리 선언해야 해요(String name = "Alice";). 귀찮아 보이지만 실행해 보기 전에 타입 안 맞으면 컴파일이 안 됨이라는 장점이 큽니다. 큰 회사 시스템에서는 "코드 짜다가 변수 이름 오타" 같은 실수가 컴파일 시점에 다 잡혀요. Python·JavaScript처럼 실행해 보고 나서야 알게 되는 일이 없습니다.
3. Spring이라는 거대한 생태계
자바 백엔드 = 사실상 Spring Framework예요. 데이터베이스 연결·트랜잭션 관리·웹 요청 처리·보안·캐싱 — 한국 회사 서버에서 일어나는 거의 모든 일을 Spring이 표준화했어요. 자바 백엔드 잘하는 사람 = Spring 잘 다루는 사람이라는 등식이 성립합니다. 이 시리즈가 Spring을 1편이 아니라 5편(자바 기초 끝나고)부터 깊게 다루는 이유도 그래서예요.
4. 인력 풀이 두꺼움
대학에서 자바를 기본으로 가르치고, 회사가 자바로 짜져 있고, 자바 책·강의가 매우 많고. 자바 백엔드 인력 풀이 다른 언어 대비 압도적으로 두꺼워요. 회사 입장에서 "갑자기 사람 한 명 빠져도 다음 사람 구하기 쉬운" 보험 같은 거예요.
5. 안정성·예측 가능성
큰 회사 시스템은 "트래픽 폭주에도 망가지지 않는다" 가 핵심인데, 자바는 이 영역에서 30년 트랙 레코드가 있어요. 카카오·네이버·쿠팡·은행·통신사 — 한국 대기업 백엔드는 거의 다 자바 기반이거든요.
자바가 "느리다" 는 평이 종종 들리는데, 이건 90년대 이야기예요. 현재 자바는 JIT 컴파일 덕분에 오래 도는 서버 워크로드에서 C++급 성능을 냅니다. 짧은 스크립트나 CLI 도구에선 시작 비용 때문에 느린 게 사실이지만, 하루 24시간 도는 백엔드 서버에선 자바가 가장 빠른 선택지 중 하나예요.
한 줄 정리 — 자바 백엔드의 표준 지위 = 30년 JVM 성숙도 + 정적 타입 + Spring 생태계 + 두꺼운 인력 풀 + 안정성.
자바 버전 — LTS만 알면 됩니다
마지막으로 짚어둘 게 하나 있어요. 자바 버전이에요. 현재 Oracle은 약 6개월마다 자바 새 버전을 내놓는데, 그 중 LTS(Long-Term Support) 버전만 회사에서 실제로 씁니다. "무슨 버전을 깔아야 하지?" 가 헷갈리면 LTS만 기억하세요.
| LTS 버전 | 출시 | 회사 사용 패턴 |
|---|---|---|
| Java 8 | 2014 | 한국 회사 레거시 시스템에 여전히 많음. 람다식·스트림 API 도입 |
| Java 11 | 2018 | 한동안 표준이었음 |
| Java 17 | 2021 | 현재 신규 프로젝트의 사실상 표준 |
| Java 21 | 2023 | 최신 LTS. 가상 스레드(Virtual Threads) 도입으로 화제 |
신규 프로젝트는 Java 17 또는 21, 레거시 유지보수는 Java 8·11이 대세예요. "공부할 때 어느 버전?" 물으신다면 Java 17로 시작하세요. Spring Boot 3.x도 Java 17 이상을 요구합니다.
시험 직전 한 번 더 — 자바 백엔드 입문자가 매번 헷갈리는 것
- 자바는 1995년 Sun Microsystems 출시 → 2010년 Oracle 인수
- 자바는 JVM 위에서 도는 언어 — Write Once, Run Anywhere
- JVM = 카세트 플레이어,
.class= 카세트테이프 비유 박아두기 - 자바·JVM·JDK·JRE — 포함 관계 JDK ⊃ JRE ⊃ JVM
- 자바 코드 짤 때 = JDK 설치, 실행만 할 때 = JRE만 있어도 OK
.java→javac컴파일 →.class바이트코드 → JVM 실행- 자바는 순수 인터프리터 X — 컴파일 + 인터프리터 혼합형
- JIT(Just-In-Time) 컴파일 덕분에 오래 도는 서버에서 점점 빨라짐
- GC(가비지 컬렉터) — 메모리 자동 관리. 개발자가 직접 free() 안 함
- 정적 타입 언어 — 변수 타입 미리 선언 (
String name = "Alice") - 객체지향 언어 — 모든 것이 클래스·객체로 구성됨
- 자바 백엔드의 표준 = Spring Framework
- 한국 대기업 백엔드 70~80%가 자바 기반 (카카오·네이버·쿠팡·은행)
- "자바는 느리다" 는 90년대 이야기 — 현재 서버 워크로드에선 C++급 성능
- 컴파일 시점 타입 체크 = "실행 전에 오타 잡아주는" 보험
- 자바 신입 채용은 거의 다 Java + Spring Boot 조합 요구
- LTS 버전 = Java 8 / 11 / 17 / 21. 신규 프로젝트는 17이 사실상 표준
- Spring Boot 3.x는 Java 17 이상 필수
- 자바 백엔드 = 정적 타입 + JVM + Spring + 두꺼운 인력 풀의 시너지
시리즈 다른 편 (앞뒤 글 모음)
다음 글: