Unit 3.1 — 바이트코드란 무엇인가
F-LAB JAVA · 2주차 · Phase 3 · 바이트코드와 상수 풀
🎯 2주차의 정점 시작 —.class파일을 눈으로 읽기 시작한다
📌 학습 목표
이 Unit을 끝내면 다음을 답할 수 있어야 한다.
- 바이트코드와 기계어의 결정적 차이는?
-
.java→.class컴파일 후, .class 파일의 내부 구조는? -
javap -c -v명령으로 무엇을 볼 수 있나? - 바이트코드 명령어가 약 200개라고 하는데, 어떤 카테고리로 나뉘는가?
- "Write Once, Run Anywhere" 의 비밀이 정확히 무엇인가?
- Magic Number
0xCAFEBABE의 의미는? - ILIC 운영에서 바이트코드를 직접 읽어야 할 순간은 언제인가?
🎯 핵심 한 문장
바이트코드는 "JVM이라는 가상 CPU의 기계어" 다.
실제 CPU(x86, ARM)의 기계어보다 한 단계 추상화되어 있고, 그 한 단계 위에서 자바의 모든 마법(플랫폼 독립성, JIT 최적화, AOP, 동적 프록시)이 일어난다.
Phase 1~2에서 본 모든 메모리 메커니즘이 바이트코드 명령어로 표현된다.
비유 — 만국 공통 악보
| 시스템 | 비유 |
|---|---|
.java 소스 | 작곡가가 자기 언어로 쓴 메모 |
.class 바이트코드 | 국제 표준 악보 (오선지) |
| JVM | 악보를 해석하는 지휘자 |
| x86/ARM 기계어 | 각국 악단이 자기 악기로 연주 |
작곡가가 한국어로 작곡해도(자바), 국제 표준 악보(바이트코드)로 변환되면 미국 악단(x86)도, 유럽 악단(ARM)도 같은 음악을 연주할 수 있다.
→ "Write Once, Run Anywhere"의 정체.
🧭 9개 섹션 로드맵
1. 바이트코드의 본질 — 기계어와 무엇이 다른가
2. .java → .class 컴파일 과정
3. .class 파일의 구조 — 10개 섹션
4. javap 도구 마스터하기
5. 바이트코드 명령어 카테고리 — 200개 명령어 분류
6. Write Once Run Anywhere의 비밀
7. ILIC 실무 — 바이트코드 분석이 필요한 순간
8. 흔한 실수 + 디버깅
9. 면접 질문 + 자기 점검1️⃣ 바이트코드의 본질 — 기계어와 무엇이 다른가
1.1 컴파일 단계 비교
C 언어:
.c → 컴파일 → .exe (x86 기계어)
↑
이 .exe는 ARM에선 못 돌림
자바:
.java → 컴파일 → .class (바이트코드)
↓ JVM이 해석
x86 / ARM / RISC-V / ... 어디서든C는 타겟 OS/CPU의 기계어 로 직접 컴파일.
자바는 JVM이라는 가상 CPU의 기계어 로 컴파일.
1.2 같은 코드의 두 가지 모습
자바 코드:
int sum = a + b;바이트코드 (JVM이 이해):
iload_1 // a를 스택에 push
iload_2 // b를 스택에 push
iadd // 더하기
istore_3 // sum에 저장x86 기계어 (CPU가 이해):
mov eax, [rbp-4] ; a를 eax 레지스터로
add eax, [rbp-8] ; eax에 b 더하기
mov [rbp-12], eax ; eax를 sum 위치에 저장ARM 기계어 (다른 CPU):
ldr w0, [sp, #8] ; a를 w0 레지스터로
ldr w1, [sp, #12] ; b를 w1 레지스터로
add w0, w0, w1 ; w0 = w0 + w1
str w0, [sp, #16] ; sum에 저장→ 자바의 바이트코드는 하나의 표현, 기계어는 CPU별로 다름.
1.3 4가지 결정적 차이
| 항목 | 바이트코드 | 기계어 (x86 등) |
|---|---|---|
| 대상 | JVM (가상 CPU) | 실제 CPU |
| 모델 | 스택 기반 | 레지스터 기반 |
| 이식성 | ✓ 어떤 OS든 JVM 있으면 실행 | ❌ CPU별로 다름 |
| 레벨 | 추상화 (객체, 메서드 개념 보존) | 저수준 (메모리 주소만) |
1.4 스택 머신 vs 레지스터 머신
Unit 1.4에서 봤듯이 JVM은 스택 머신.
스택 머신 (JVM):
iload_1 → 스택: [a]
iload_2 → 스택: [a, b]
iadd → 스택: [a+b]
istore_3 → 스택: []
레지스터 머신 (x86):
mov eax, a → 레지스터 eax = a
add eax, b → 레지스터 eax = a + b
mov sum, eax → 메모리 sum = eax스택 머신의 장점:
- 단순함: 명령어 적음 (200개 정도)
- 이식성: 레지스터 개수 다른 CPU에 무관
- 컴파일러 단순: 표현식 → 스택 명령 일대일 변환
스택 머신의 단점:
- 명령어 수 많음 (메모리↔스택 이동 필요)
- → JIT 컴파일러가 런타임에 레지스터 기반 코드로 변환
1.5 객체 개념의 보존
바이트코드는 단순한 어셈블리 명령보다 고수준.
바이트코드:
new #2 // class com/ilic/Shipment ← 클래스 이름 보존
invokevirtual #15 // calculate(I)BigDecimal ← 메서드 시그니처 보존
getfield #8 // blNo ← 필드 이름 보존x86 기계어:
call 0x401234 ; 함수 주소
mov rax, [rdi+8] ; 메모리 오프셋→ 바이트코드는 클래스, 메서드, 필드의 의미적 정보를 그대로 유지.
→ Reflection, AOP, 디버거가 가능한 이유.
→ 사람도 읽을 수 있는 이유.
2️⃣ .java → .class 컴파일 과정
2.1 컴파일러의 역할
javac App.java
# 결과: App.classjavac가 하는 일:
.java 소스 코드
↓
1. Lexical Analysis (어휘 분석)
소스를 토큰으로 분리: int, sum, =, a, +, b, ;
↓
2. Syntax Analysis (구문 분석)
토큰을 AST(Abstract Syntax Tree)로 구성
↓
3. Semantic Analysis (의미 분석)
타입 검사, 변수 선언 검증, 메서드 시그니처 매칭
↓
4. Bytecode Generation
AST → 바이트코드 명령어 시퀀스
↓
5. Constant Pool 생성
문자열, 클래스 참조 등을 풀에 모음
↓
.class 파일 작성2.2 컴파일러가 자동으로 추가하는 것
자바 컴파일러는 사용자가 안 쓴 코드도 자동 삽입:
// 사용자 코드
public class Shipment {
private String blNo;
}// 컴파일러가 실제로 만드는 것 (개념적)
public class Shipment extends Object { // ← extends Object 자동
private String blNo;
public Shipment() { // ← 기본 생성자 자동
super(); // ← super() 자동
}
}자동 추가되는 것:
extends Object(명시 없으면)- 기본 생성자 (다른 생성자가 없을 때)
super()호출 (생성자 첫 줄)- 필드 초기값을 생성자에 삽입
- 인스턴스 초기화 블록을 생성자에 삽입
- enum의 values(), valueOf() 메서드
- inner class와 outer class의 합성 메서드
2.3 컴파일러의 최적화
자바 컴파일러는 최소한의 최적화만 수행:
- 상수 폴딩(Constant Folding):
1 + 2→3 - 죽은 코드 제거: 사용 안 되는 if-false 블록
- String 리터럴 결합:
"a" + "b"→"ab"
대부분의 최적화는 JIT 컴파일러가 런타임에 수행 (Unit 2.3 7장).
→ .class 파일은 의외로 소스 코드의 직역에 가깝다.
2.4 디버그 정보
javac -g App.java-g 옵션은 추가 정보를 .class 에 포함:
- LocalVariableTable: 지역 변수 이름 (Unit 1.4)
- LineNumberTable: 소스 줄 번호 매핑
- 디버거가 변수명/줄번호를 보여주는 비밀
배포용 코드에는 보통 -g:none 으로 제거 (파일 크기 감소).
하지만 운영 디버깅 어려워지므로 trade-off.
3️⃣ .class 파일의 구조 — 10개 섹션
3.1 한눈에 보는 구조
.class 파일 (바이너리)
┌─────────────────────────────────────────┐
│ 1. Magic Number (4 bytes) │ ← 0xCAFEBABE
│ 2. Version Number (4 bytes) │ ← JDK 버전
│ 3. Constant Pool │ ← Phase 3.2의 주역
│ 4. Access Flags │ ← public, abstract 등
│ 5. This Class │ ← 자기 클래스 참조
│ 6. Super Class │ ← 부모 클래스 참조
│ 7. Interfaces │ ← 구현 인터페이스
│ 8. Fields │ ← 필드 선언
│ 9. Methods │ ← 메서드 + 바이트코드
│ 10. Attributes │ ← 추가 메타데이터
└─────────────────────────────────────────┘3.2 Magic Number — 0xCAFEBABE
파일 시작 4 bytes: CA FE BA BE왜 0xCAFEBABE?
- 1991년 James Gosling이 자바 개발 시 정함
- 16진수로 영어 표기 가능한 값 (Cafe Babe)
- 자바 = 커피 이름 → 카페 아가씨 농담
- 모든
.class파일이 이 값으로 시작 - JVM이 첫 4바이트로 "유효한 .class 파일인가?" 확인
# 직접 확인
hexdump -C App.class | head -1
# 출력:
# 00000000 ca fe ba be 00 00 00 41 ...
# ↑ Magic Number ↑ Version3.3 Version Number
Magic 다음 4 bytes: Minor + Major| Major | Java 버전 |
|---|---|
| 52 | Java 8 |
| 55 | Java 11 |
| 61 | Java 17 |
| 65 | Java 21 |
호환성 규칙:
- 높은 버전으로 컴파일된 클래스를 낮은 JVM에서 실행 →
UnsupportedClassVersionError - 낮은 버전 클래스는 높은 JVM에서 OK (forward compatibility)
javac -target 8 App.java # Java 8 호환으로 컴파일
javac --release 11 App.java # Java 11 API + 호환으로ILIC 운영 시 흔한 함정: 빌드 환경 JDK와 런타임 JDK 버전 차이 → 이 에러.
3.4 Constant Pool — 다음 Unit의 주역
Constant Pool: 이 클래스가 참조하는 모든 상수의 풀
- String 리터럴
- 클래스 참조
- 메서드 참조
- 필드 참조
- 숫자 상수→ Phase 3에서 다음 Unit (3.2) 전체가 이것.
→ 바이트코드의 #2, #15 같은 인덱스가 모두 여기 가리킴.
3.5 Methods 섹션 — 바이트코드의 거주지
각 메서드 정보:
├─ 접근 플래그 (public, static 등)
├─ 이름 인덱스 → Constant Pool의 메서드 이름
├─ 시그니처 인덱스 → "(I)Ljava/math/BigDecimal;" 같은 디스크립터
└─ 속성:
└─ Code 속성:
├─ max_stack (Operand Stack 최대 크기)
├─ max_locals (LVA 크기)
├─ 바이트코드 명령들 ★
├─ Exception Table (try-catch)
└─ LineNumberTable, LocalVariableTable (선택)→ 메서드의 바이트코드는 여기에 저장.
→ Unit 1.3의 Non-Static Zone, Static Zone의 실체.
3.6 Attributes — 메타데이터
클래스 레벨, 필드 레벨, 메서드 레벨 모두 attribute 가질 수 있음.
주요 attribute:
SourceFile: 원본.java파일명InnerClasses: 내부 클래스 정보Signature: 제네릭 정보 (Type Erasure 보존)RuntimeVisibleAnnotations: 런타임 어노테이션Synthetic: 컴파일러가 생성한 합성 멤버
→ Reflection이 어노테이션을 볼 수 있는 이유 = 여기에 보존됨.
4️⃣ javap 도구 마스터하기
4.1 기본 사용법
# 가장 기본 — 메서드 시그니처만
javap Shipment.class
# 출력:
# Compiled from "Shipment.java"
# public class Shipment {
# public Shipment(java.lang.String);
# public java.math.BigDecimal calculate(int);
# }4.2 옵션 모음
| 옵션 | 효과 |
|---|---|
-c | 바이트코드 출력 (가장 자주 사용) |
-v (verbose) | 모든 정보 (상수 풀 포함) |
-p (private) | private 멤버도 표시 |
-l (lineNumber) | 줄 번호 + LocalVariableTable |
-s (sigs) | 내부 시그니처 출력 |
조합:
javap -c -p -v Shipment.class
# 모든 정보 + 바이트코드 + private 멤버4.3 실전 — 간단한 클래스 분석
public class Calculator {
private int counter = 0;
public int add(int a, int b) {
counter++;
return a + b;
}
}javac Calculator.java
javap -c -p Calculator.class출력:
Compiled from "Calculator.java"
public class Calculator {
private int counter;
public Calculator();
Code:
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: aload_0
5: iconst_0
6: putfield #2 // Field counter:I
9: return
public int add(int, int);
Code:
0: aload_0
1: dup
2: getfield #2 // Field counter:I
5: iconst_1
6: iadd
7: putfield #2 // Field counter:I
10: iload_1
11: iload_2
12: iadd
13: ireturn
}이걸 읽을 수 있게 되는 것이 Phase 3의 목표.
4.4 한 줄씩 해독
public Calculator(); ← 기본 생성자 (컴파일러 자동 생성)
Code:
0: aload_0 ← this 로드
1: invokespecial #1 ← super() — Object의 <init> 호출
4: aload_0 ← this 다시
5: iconst_0 ← 0 (counter의 초기값)
6: putfield #2 ← this.counter = 0 (필드 선언 초기값)
9: return ← 생성자 종료→ Unit 2.4에서 본 "필드 초기값을 컴파일러가 생성자 시작에 자동 삽입" 의 증거.
public int add(int, int);
Code:
0: aload_0 ← this
1: dup ← 복제 (다음 putfield용)
2: getfield #2 ← this.counter 읽기 → Stack: [this, counter값]
5: iconst_1 ← 1 push → Stack: [this, counter, 1]
6: iadd ← + → Stack: [this, counter+1]
7: putfield #2 ← this.counter = counter+1 (이게 ++)
10: iload_1 ← a → Stack: [a]
11: iload_2 ← b → Stack: [a, b]
12: iadd ← a + b → Stack: [a+b]
13: ireturn ← 반환→ counter++ 가 어떻게 5개 명령으로 풀리는지 직접 확인.
4.5 verbose 모드 — 상수 풀까지
javap -c -p -v Calculator.class추가로 출력되는 것:
Constant pool:
#1 = Methodref #4.#11 // java/lang/Object."<init>":()V
#2 = Fieldref #3.#12 // Calculator.counter:I
#3 = Class #13 // Calculator
#4 = Class #14 // java/lang/Object
#11 = NameAndType #15:#10 // "<init>":()V
#12 = NameAndType #6:#7 // counter:I
#13 = Utf8 Calculator
#14 = Utf8 java/lang/Object
...→ 바이트코드의 #2 가 정확히 무엇을 가리키는지 풀이됨.
→ Phase 3.2에서 Constant Pool을 본격적으로 다룬다.
5️⃣ 바이트코드 명령어 카테고리 — 약 200개 정리
5.1 카테고리 개요
JVM 바이트코드는 약 200개의 명령어. 카테고리로 묶으면 단순:
1. 상수 로드 (constant loading)
2. 변수 로드/저장 (load/store)
3. 산술/논리 (arithmetic/logic)
4. 타입 변환 (type conversion)
5. 객체 조작 (object manipulation)
6. 메서드 호출 (method invocation)
7. 제어 흐름 (control flow)
8. 예외 처리 (exception)5.2 카테고리 1 — 상수 로드
iconst_0 ~ iconst_5 ← 0~5 정수 push
iconst_m1 ← -1 push
bipush <byte> ← -128 ~ 127 push
sipush <short> ← short 범위 push
ldc <index> ← 상수 풀의 작은 값
ldc_w <index> ← 상수 풀의 큰 값 (16-bit 인덱스)
ldc2_w <index> ← long, double 상수
aconst_null ← null push예:
int x = 100;bipush 100
istore_1String s = "hello";ldc #2 // 상수 풀에서 "hello" 로드
astore_15.3 카테고리 2 — 변수 로드/저장 (LVA 접근)
iload_0 ~ iload_3 ← LVA[0~3]의 int 로드
iload <index> ← 임의 인덱스
istore_0 ~ istore_3 ← LVA[0~3]에 int 저장
istore <index>
aload_0 ~ aload_3 ← LVA의 참조 로드
astore_0 ~ astore_3 ← LVA에 참조 저장
lload, lstore ← long
fload, fstore ← float
dload, dstore ← double→ 첫 글자: 타입 (i=int, a=ref, l=long, f=float, d=double, b=byte, s=short).
→ Unit 1.4에서 본 LVA 접근의 정체.
5.4 카테고리 3 — 산술/논리
iadd, isub, imul, idiv, irem ← int 사칙연산 + 나머지
ineg ← 음수화
iinc <index> <const> ← LVA[index] += const (특수)
예: counter++ → iinc 1 1
ishl, ishr, iushr ← 시프트
iand, ior, ixor ← 비트 연산
lcmp, fcmpl, fcmpg, dcmpl, dcmpg ← 비교 (long/float/double)흥미로운 명령: iinc.
counter++;일반 방식:
iload_1 // 로드
iconst_1 // 1
iadd // 더하기
istore_1 // 저장iinc 사용:
iinc 1, 1 // LVA[1] += 1 ← 한 명령으로 해결→ 단, LVA 변수에 대해서만. 필드는 일반 방식.
5.5 카테고리 4 — 타입 변환
i2l, i2f, i2d ← int을 long/float/double로
l2i, l2f, l2d ← long을 다른 타입으로
f2i, f2l, f2d ← float
d2i, d2l, d2f ← double
i2b, i2c, i2s ← int을 byte/char/short로 (좁히기)
checkcast <class> ← 참조 타입 캐스팅 검증
instanceof <class> ← 타입 검사예:
long x = (long) intValue;iload_1
i2l
lstore_25.6 카테고리 5 — 객체 조작
new <class> ← 객체 생성 (Unit 2.4)
newarray <type> ← primitive 배열
anewarray <class> ← 참조 타입 배열
arraylength ← 배열 길이
getfield <field> ← 인스턴스 필드 읽기
putfield <field> ← 인스턴스 필드 쓰기
getstatic <field> ← static 필드 읽기
putstatic <field> ← static 필드 쓰기
iaload, aaload, ... ← 배열 원소 읽기
iastore, aastore, ... ← 배열 원소 쓰기
dup, dup2, swap, pop, pop2 ← 스택 조작5.7 카테고리 6 — 메서드 호출 (Unit 1.5에서 본 4 + 1종)
invokestatic <method> ← static 메서드
invokespecial <method> ← 생성자, private, super
invokevirtual <method> ← 일반 인스턴스 메서드
invokeinterface <method> ← 인터페이스 메서드
invokedynamic <bootstrap> ← 람다, String concat, switch 패턴 (Java 7+)
ireturn, lreturn, freturn ← 값 반환
dreturn, areturn, return ← void 반환5.8 카테고리 7 — 제어 흐름
ifeq, ifne, iflt, ifle ← int 비교 분기 (0과 비교)
ifgt, ifge
if_icmpeq, if_icmpne, ... ← int 두 값 비교 분기
if_acmpeq, if_acmpne ← 참조 비교
ifnull, ifnonnull ← null 비교
goto <offset> ← 무조건 점프
tableswitch ← 빽빽한 switch
lookupswitch ← 듬성한 switch
athrow ← 예외 던지기예:
if (x == 0) return;iload_1
ifne 7 // 0이 아니면 7번 명령으로 점프
return // 4번
... continue ... // 7번5.9 카테고리 8 — 동기화/모니터
monitorenter ← synchronized 진입
monitorexit ← synchronized 종료synchronized (lock) {
process();
}aload_1 // lock
monitorenter
... process() 호출 ...
aload_1
monitorexit5.10 명령어 학습 전략
200개 다 외울 필요 없음.
기본 30개 정도 익히면 대부분 코드 읽기 가능:
iconst_*, bipush, ldc (상수)
iload_*, istore_*, aload_*, astore_* (변수)
iadd, isub, imul, idiv, iinc (산술)
new, dup, getfield, putfield (객체)
invokestatic, invokespecial, invokevirtual (메서드)
ifeq, if_icmpeq, goto, return (제어)→ Phase 3.4에서 이걸로 실전 분석.
6️⃣ Write Once Run Anywhere의 비밀
6.1 슬로건의 진정한 의미
"Write Once, Run Anywhere" (WORA)
1995년 Sun Microsystems 슬로건.
의미:
- 한 번 작성한 자바 코드를
- 어떤 플랫폼에서든 (Windows, Mac, Linux, ARM, x86, ...)
- 다시 컴파일 없이 실행
→ 가능한 이유: 바이트코드 + JVM 추상화.
6.2 동작 메커니즘
개발자 코드 (.java)
↓ javac (플랫폼 무관)
바이트코드 (.class)
↓ JAR로 패키징
배포 (어디든)
↓
플랫폼 A의 JVM ─→ 바이트코드 해석 → x86 기계어 실행
플랫폼 B의 JVM ─→ 바이트코드 해석 → ARM 기계어 실행
플랫폼 C의 JVM ─→ 바이트코드 해석 → RISC-V 기계어 실행핵심:
- 컴파일 결과물(
.class)는 단일 - JVM이 각 플랫폼에서 자기 CPU의 기계어로 변환
6.3 JVM 구현체들
표준 사양: JVM Specification (Oracle)
구현체:
- HotSpot (Oracle, 가장 흔함)
- OpenJDK (오픈소스)
- GraalVM (다국어 + AOT)
- Eclipse OpenJ9 (IBM)
- Amazon Corretto (AWS)
- Azul Zulu, Zing
- SAP Machine모두 같은 .class 파일을 실행 가능.
→ "바이트코드 사양" 이 표준의 핵심.
6.4 다른 언어들도 JVM 위에서
바이트코드를 만드는 컴파일러:
- javac (Java)
- kotlinc (Kotlin)
- scalac (Scala)
- groovyc (Groovy)
- clojure (Clojure)
- jython (Python)
- jruby (Ruby)→ Kotlin 코드도 결국 .class 바이트코드. JVM이 실행.
→ Spring Boot 앱에서 Java + Kotlin 혼용 가능한 이유.
// Kotlin
fun add(a: Int, b: Int) = a + bjavap -c MyKotlinFile
// → 일반 Java 바이트코드와 거의 동일6.5 한계 — Native Image
"Write Once, Run Anywhere" 의 trade-off:
| 항목 | JVM (전통) | Native Image (GraalVM) |
|---|---|---|
| 이식성 | ✓ 어디든 | ❌ 빌드 시 타겟 결정 |
| 시작 시간 | 느림 (수 초) | 빠름 (수십 ms) |
| 메모리 | 많음 | 적음 (1/5) |
| JIT 워밍업 | 필요 | 불필요 |
→ 서버리스, CLI 도구는 Native Image 가치.
→ 일반 서버는 여전히 JVM이 우월 (워밍업 후).
6.6 ILIC에서의 의미
ILIC 빌드 환경: Linux (CI/CD)
ILIC 운영 환경: Linux (서버)
ILIC 개발 환경: macOS, Windows (각자)
→ 같은 JAR 파일이 모두에서 실행
→ "내 컴퓨터에선 되는데" 같은 OS 의존 문제 거의 없음→ WORA의 실무 이점.
→ 네이티브 라이브러리 호출 (JNI) 사용 시에만 OS 의존성 발생.
7️⃣ ILIC 실무 — 바이트코드 분석이 필요한 순간
7.1 시나리오 1 — 라이브러리 버그 의심
상황: 외부 라이브러리의 메서드가 예상과 다르게 동작.
// SomeLib.process가 무언가 이상함
SomeLib.process(input);
// 결과가 이상한데, 소스 코드는 안 줘서 못 봄해결:
# JAR 추출
unzip somelib.jar -d somelib/
# 바이트코드 분석
javap -c -p somelib/SomeLib.class→ 라이브러리 내부 로직을 바이트코드로 파악 가능.
7.2 시나리오 2 — 컴파일러 옵션 효과 확인
상황: final 키워드가 정말 최적화에 도움 되나?
// 버전 1
class A {
public int method() { return 100; }
}
// 버전 2
class A {
public final int method() { return 100; }
}javap -c로 둘을 비교 → 바이트코드는 사실 거의 동일.
→ 차이는 JIT 런타임에 나타남.
→ "왜 같지?" 의문이 풀림.
7.3 시나리오 3 — AOP가 생성한 코드 확인
@Service
public class ShipmentService {
@Transactional
public Shipment save(Shipment s) { ... }
}Spring AOP가 만든 프록시 클래스는 어떻게 생겼나?
# Spring Boot 실행 시 옵션
-Dorg.springframework.cglib.debugLocation=/tmp/cglib
# 생성된 .class 확인
javap -c /tmp/cglib/com/ilic/ShipmentService\$\$EnhancerBySpringCGLIB*.class→ AOP self-invocation 함정의 메모리적 원인 (Unit 2.1) 직접 확인.
7.4 시나리오 4 — 람다의 정체
Runnable r = () -> System.out.println("hello");이 코드의 바이트코드:
0: invokedynamic #2, 0 // BootstrapMethod for lambda
// LambdaMetafactory가 클래스 동적 생성
5: astore_1invokedynamic 명령. 런타임에 람다 클래스 동적 생성.
→ "람다가 익명 클래스와 어떻게 다른가?" 의 답.
7.5 시나리오 5 — switch의 진화
// 전통 switch
switch (status) {
case "DRAFT": return 1;
case "ACTIVE": return 2;
default: return 0;
}
// Java 14+ switch expression
return switch (status) {
case "DRAFT" -> 1;
case "ACTIVE" -> 2;
default -> 0;
};javap -c로 보면 둘 다 비슷한 lookupswitch 또는 tableswitch.
→ "표현식 switch가 더 빠른가?" → 사실상 차이 없음. 가독성 차이.
7.6 시나리오 6 — 컴파일 산출물 검증
ILIC CI/CD 시나리오:
.java → javac → .class
.class → SpotBugs, ErrorProne 등 분석 도구 입력
.class → JAR 패키징분석 도구가 .class 를 직접 읽어 패턴 검출.
→ 우리도 가끔 .class 직접 확인해 도구 결과 검증.
7.7 도구 모음
# javap — 표준 도구
javap -c -v -p File.class
# CFR (Java Decompiler)
java -jar cfr.jar File.class
# JD-GUI (그래픽)
jd-gui File.jar
# bytecode-viewer (다양한 디컴파일러 통합)박승제씨가 IntelliJ IDEA를 쓴다면:
.class파일 더블 클릭 → 자동 디컴파일 (Fernflower)- Tools → "Show Bytecode" → javap 결과
- → 별도 명령어 없이 IDE에서 바로 가능
8️⃣ 흔한 실수 + 디버깅
실수 1 — 바이트코드를 어셈블리로 착각
"바이트코드는 어셈블리네!" → 부분적으로 맞지만 다름.차이:
- 어셈블리: CPU 명령에 1:1 대응
- 바이트코드: JVM 가상 명령. 실제 실행은 JIT가 네이티브로 변환
→ "이 바이트코드가 느림?" → 사실 의미 없음. JIT 후의 코드가 진짜 실행.
실수 2 — 바이트코드 줄 수로 성능 판단
// 코드 1: 1줄
int sum = a + b;
// 코드 2: 3줄
int x = a;
int y = b;
int sum = x + y;바이트코드:
코드 1:
iload_1, iload_2, iadd, istore_3 (4 명령)
코드 2:
iload_1, istore_3 (저장 x)
iload_2, istore_4 (저장 y)
iload_3, iload_4, iadd, istore_5 (계산)
(8 명령)명령 수는 다르지만, JIT 후엔 사실상 같음 (Escape Analysis로 변수 제거).
→ 가독성 위해 짧게/길게 쓰는 건 자유. 성능 영향 거의 없음.
실수 3 — final 이 항상 빠르다는 신화
public final int method() { return 100; }바이트코드:
iconst_100 (또는 ldc)
ireturn같은 메서드의 non-final 버전도 바이트코드는 동일.
차이는 JIT 시점:
- final: 인라이닝, devirtualization 더 적극적
- non-final: 보수적
→ final은 JIT 힌트이지 바이트코드 차이가 아님.
실수 4 — synchronized 의 비용 과대평가
public synchronized void method() { ... }바이트코드:
- 메서드 진입 시 monitorenter
- 메서드 종료 시 monitorexit
- 예외 시 자동 monitorexit
→ 짧은 메서드의 synchronized 비용은 ~10ns.
→ "synchronized 빼야 함" 의심 전에 측정. 대부분 다른 곳이 병목.
실수 5 — 디컴파일러 결과를 원본으로 착각
java -jar cfr.jar SomeClass.class디컴파일러는 바이트코드 → 자바 소스 변환.
- 원본과 100% 같지 않음
- 변수 이름 손실 (디버그 정보 없으면)
- 일부 패턴은 다르게 표현
- 람다, switch 등은 특히 차이
→ 디컴파일은 참고용, 진짜는 바이트코드.
실수 6 — .class 파일 직접 수정 시도
# ❌ 절대 하지 말 것
vim Calculator.class.class 는 바이너리. 일반 텍스트 에디터로 열면 깨짐.
바이트코드 조작 도구 사용:
- ASM (Apache, 가장 일반)
- ByteBuddy (높은 수준 API)
- Javassist (Hibernate 등이 사용)
→ 실무에선 거의 안 함. 라이브러리 개발 시 가끔.
디버깅 — 운영 환경에서 클래스 버전 확인
# 실행 중인 JVM의 클래스 정보
jcmd <PID> VM.class_loader_stats
# 특정 클래스 정보
jcmd <PID> GC.class_stats # (JFR 활성화 필요)
# JAR 안의 클래스 버전 확인
unzip -p somelib.jar SomeClass.class | head -c 8 | hexdump -C
# 00 00 ca fe ba be 00 41 ← 41 = Java 17운영 사고 시 "이 라이브러리 어느 Java 버전이야?" 빠르게 확인.
9️⃣ 면접 질문 + 자기 점검
9.1 면접 단골 질문 매핑
| Q | 핵심 답변 |
|---|---|
| 바이트코드와 기계어 차이? | JVM 가상 CPU vs 실제 CPU. 스택 머신 vs 레지스터 머신. 이식성 |
Magic Number 0xCAFEBABE 의미? | .class 파일 시작 확인용. James Gosling이 1991년 정함 |
| WORA의 메커니즘? | 바이트코드(.class) → JVM이 각 플랫폼 기계어로 변환 |
| .class 파일의 주요 섹션? | Magic, Version, Constant Pool, Methods, Attributes |
| javap의 주요 옵션? | -c (바이트코드), -v (상수 풀), -p (private) |
| 바이트코드 명령어 카테고리? | 상수/변수/산술/타입변환/객체/메서드/제어/예외 |
| Kotlin이 JVM에서 도는 이유? | kotlinc가 .class 바이트코드 생성. JVM은 언어 무관 |
| Java 8 → 11 → 17 의 .class 차이? | Major version 변경. 새 명령어 추가 (invokedynamic 확장 등) |
| 디컴파일러 결과를 원본으로 신뢰? | 참고용. 변수명/주석/일부 패턴 손실 |
iinc의 특수성? | LVA 변수에 대해 한 명령으로 +N. 필드는 불가 |
9.2 자기 점검 체크리스트
기본 이해
- 바이트코드가 기계어와 다른 점을 설명할 수 있다
-
.class파일의 10개 섹션을 안다 - Magic Number와 Version의 의미를 안다
- javap의 주요 옵션을 사용할 수 있다
- 바이트코드 명령어 카테고리를 안다
실전 적용
-
Calculator.class같은 간단한 클래스를 javap로 읽을 수 있다 -
aload_0,iadd,putfield등 기본 명령을 해독할 수 있다 - 라이브러리 바이트코드를 분석해 버그 디버깅 가능
- AOP 프록시 클래스를 직접 확인 가능
- 람다의 invokedynamic 패턴을 안다
면접 대비 — 5분 답변
- 바이트코드와 기계어의 결정적 차이
- WORA의 메커니즘
-
.class파일의 구조 - 200개 바이트코드 명령어를 카테고리로 정리
- javap로 코드 분석하는 능력
🎯 핵심 요약 — 3줄 정리
1. 바이트코드 = JVM이라는 가상 CPU의 기계어
- 스택 머신 기반 (레지스터 머신 x86과 대비)
- 객체/메서드 개념 보존 (저수준 어셈블리와 차이)
- ~200개 명령어, 8개 카테고리
2. .class 파일의 표준 구조
- Magic Number
0xCAFEBABE로 시작 - Version (Java 8 = 52, Java 21 = 65)
- Constant Pool (다음 Unit 주역)
- Methods (바이트코드 거주지)
3. WORA의 비밀
- 한 번 컴파일된
.class→ 모든 JVM 구현체에서 실행 - Kotlin, Scala 등도 같은
.class생성 → JVM 위에서 동작 - Native Image는 trade-off (이식성 vs 시작 속도)
📚 다음으로...
Unit 3.2 — 상수 풀(Constant Pool)의 생성과 구조
이번 Unit에서 .class 파일의 큰 그림을 봤다면, 다음은 상수 풀에 집중.
지금까지 본 모든 #1, #2, #15 인덱스가 정확히 무엇인지 풀이.
- 상수 풀의 14가지 항목 타입 (Class, String, MethodRef, FieldRef, ...)
javap -v로 상수 풀 직접 확인- 컴파일러가 상수 풀을 만드는 과정
- 같은 String 리터럴이 상수 풀에 1개만 들어가는 이유
Phase 3 진행 상황
🎯 Phase 3 — 바이트코드와 상수 풀 ★ 2주차의 정점
✅ Unit 3.1 바이트코드란 무엇인가 ← 여기
⏭ Unit 3.2 상수 풀의 생성과 구조
⏭ Unit 3.3 심볼 참조
⏭ Unit 3.4 바이트코드 실전 분석Phase 3 학습 후 갖게 될 능력
javap -c -v Shipment.class이 한 줄의 출력을 완전히 이해하고, 다음을 할 수 있게 됨:
- 라이브러리 버그를 바이트코드로 디버깅
- Spring AOP 프록시 클래스 분석
- 람다와 익명 클래스의 차이 직접 확인
- 컴파일러 옵션의 효과 검증
- 면접에서 "바이트코드 본 적 있어요?" 에 자신 있게 대답
Software Developer