내 코드는 어떤 바이트코드가 되고, 프레임워크는 그걸 어떻게 조작할까?

javac가 만든 .class는 엄격하게 정의된 바이너리 포맷이에요. JVM 명세가 정한 순서대로 필드가 늘어서 있고, 어떤 JVM이든 이 구조를 읽어 클래스를 복원합니다. 큰 줄기는 다음과 같아요.

javap -c(또는 javap -v)로 컴파일된 바이트코드를 사람이 읽을 수 있어요. 예를 들어 int r = a + b;는 대략 이렇게 풀립니다.

// $ javap -c Sum.class
int add(int a, int b) {
    return a + b;
}
//   0: iload_1        // 지역변수 1(a)을 피연산자 스택에 push
//   1: iload_2        // 지역변수 2(b)를 push
//   2: iadd           // 스택 top 두 값을 pop, 더한 뒤 push
//   3: ireturn        // 스택 top을 int로 반환

JVM은 스택 기반 가상 머신이에요. CPU처럼 레지스터에 값을 넣고 연산하는 게 아니라, 각 메서드 프레임마다 있는 피연산자 스택(operand stack)에 값을 push/pop하며 계산합니다. 프레임에는 스택 외에도 파라미터·지역변수를 담는 지역변수 배열(local variable array)이 있어요.

대표 명령을 몇 갈래로 묶어두면 javap 출력이 훨씬 잘 읽혀요.

흔한 오해: "람다는 컴파일 시 익명 클래스로 바뀐다." 아니에요. 자바 8부터 람다는 invokedynamic 명령 하나로 컴파일되고, 그 자리에 실제 구현 객체를 만드는 일은 런타임 첫 실행 때 LambdaMetafactory가 담당합니다.

동작을 단계로 보면 이래요. 컴파일러는 람다 본문을 private static 합성 메서드로 만들어 두고, 호출 지점엔 invokedynamic을 심습니다. 이 indy는 BootstrapMethods attribute에 적힌 부트스트랩 메서드(LambdaMetafactory.metafactory)를 가리켜요. 최초 실행 시 부트스트랩이 함수형 인터페이스를 구현한 클래스를 만들고 CallSite에 연결하며, 이후 호출은 이 링크를 그대로 씁니다.

리플렉션은 실행 중에 Class·Method·Field·Constructor를 조회하고 호출·접근하는 API예요. 프레임워크의 의존성 주입, ORM의 필드 매핑, 직렬화가 모두 이걸 씁니다.

Class<?> c = Class.forName("com.example.User");
Object u = c.getDeclaredConstructor().newInstance();

Field f = c.getDeclaredField("name");
f.setAccessible(true);          // 접근 제어 우회(모듈 규칙 허용 시)
f.set(u, "Alice");

Method m = c.getDeclaredMethod("greet", String.class);
Object r = m.invoke(u, "hi");   // 이름으로 메서드 호출

스프링 AOP, 트랜잭션, 모킹, APM — 이들의 공통 무기는 런타임에 새 클래스를 생성하거나 기존 바이트코드를 조작하는 것이에요. 크게 두 계열로 나뉩니다.