[Java] 바이트 조작(ASM, ByteBuddy)의 개념

이전 포스팅에서 디스크에 잠들어 있던 .class 파일이 어느 시점에 클래스로더를 타고 JVM 메모리(Metaspace)로 올라오는지 알아보았다.

 

https://hsunnystory.tistory.com/273

[Java] JVM 클래스로더(ClassLoader)의 동작 방식과 동적 클래스 로딩

 

그렇다면 클래스가 메모리에 올라오기 직전, 혹은 올라와 있는 상태에서 그 바이트코드를 내 맘대로 뜯어고칠 수 있다면 어떨까?

 

우리가 흔히 사용하는 Pinpoint, New Relic 같은 APM(애플리케이션 성능 모니터링) 도구나, 스프링의 @Transactional 같은 마법들은 개발자가 작성한 원본 코드를 단 한 줄도 건드리지 않고 어떻게 성능을 측정하고 트랜잭션을 열고 닫을까?

 

이번 포스팅에서는 자바 생태계의 가장 강력한 마법이라 불리는 바이트 코드 조작(Bytecode Manipulation)의 원리와 아키텍처적 가치에 대해 알아본다.

 

1. 왜 남의 코드를 조작해야 하는가?

애플리케이션을 운영하다 보면 비즈니스 핵심 로직(Domain) 외에 인프라성 로직(Logging, Security, Metrics 등)이 필연적으로 추가 된다. 이를 횡단 관심사(Cross-cutting Concerns)라고 부른다.

 

문제는 이 공통 관심사들이 핵심 도메인 코드를 심각하게 오염시킨다는 점이다. 수백 개의 API 엔드포인트마다 실행 시간을 측정해야 하는 요구사항이 들어왔다고 가정해 보자.

 

2. [Bad vs Good Code] 도메인을 보호하는 바이트코드 조작

[Bad Code] 공통 관심사가 도메인 로직을 침투하여 오염시킨 아키텍처

가장 원시적인 방법은 모든 서비스 클래스의 메서드 앞뒤로 시간 측정 코드를 하드코딩하는 것이다.

 

@Service
public class PaymentService {
    
    public void processPayment() {
        // [Infra] 비즈니스와 무관한 성능 측정 코드 침투
        long startTime = System.currentTimeMillis(); 
        
        try {
            // [Domain] 진짜 비즈니스 로직은 단 한 줄
            System.out.println("결제 처리가 완료되었습니다.");
        } finally {
            // [Infra] 비즈니스와 무관한 성능 측정 코드 침투
            long endTime = System.currentTimeMillis();
            System.out.println("실행 시간: " + (endTime - startTime) + "ms");
        }
    }
}

 

문제점

단일 책임 원칙(SRP)이 붕괴된다. PaymentService는 결제만 처리해야 하는데 시간 측정 책임까지 떠안았다. 만약 시간 측정 로직이 밀리초(ms)에서 나노초(ns)로 변경된다면 수백 개의 클래스를 일일이 찾아다니며 수정해야 하는 대참사가 벌어진다.

 

[Good Code] ByteBuddy를 활용해 런타임에 인프라 로직을 주입하는 아키텍처

원본 클래스는 철저하게 도메인 로직만 유지한 채 방치한다. 대신, 서버가 기동될 때 ByteBuddy나 ASM 같은 바이트코드 조작 라이브러리를 사용해 메모리상에서 가짜(Proxy) 서브클래스를 찍어내어 공통 관심사를 덮어씌운다.

 

// 1. [Domain] 원본 코드는 비즈니스에만 집중 (침투 0%)
public class PaymentService {
    public void processPayment() {
        System.out.println("결제 처리가 완료되었습니다.");
    }
}

// 2. [Infra] 시스템 초기화 시점에 바이트코드를 조작하여 래핑(Wrapping)
public void init() throws Exception {
    Class<? extends PaymentService> dynamicType = new ByteBuddy()
            .subclass(PaymentService.class) // PaymentService를 상속받는 가짜 클래스 생성
            .method(ElementMatchers.named("processPayment"))
            .intercept(MethodDelegation.to(PerformanceInterceptor.class)) // 측정 로직으로 위임
            .make()
            .load(PaymentService.class.getClassLoader())
            .getLoaded();

    // 이후 프레임워크는 원본 객체 대신, 조작된 가짜 객체(Proxy)를 클라이언트에게 주입한다.
    PaymentService proxy = dynamicType.getDeclaredConstructor().newInstance();
}

 

결과

개발자는 비즈니스 로직만 작성하면 된다. 트랜잭션, 로깅, 성능 측정 등의 횡단 관심산느 프레임워크가 런타임에 바이트코드를 조작하여 찰흙 붙이듯 덧붙여 준다. 이것이 바로 객체지향 설계의 꽃, 관심사의 완벽한 분리다.

 

3. 바이트 코드를 조작하는 기술들

자바에서 바이트코드를 조작하는 기술은 크게 로우레벨과 하이레벨로 나뉜다.

 

 - ASM : 가장 로우레벨의 라이브러리다. JVM Instruction Set(옵코드)을 직접 다뤄야 하므로 학습 곡선이 매우 높지만, 성능이 가장 빠르다. 스프릉 내부적으로 깊숙이 사용된다.

 

 - CGLIB : ASM을 한 단계 추상화한 라이브러리로, 스프링이 인터페이스가 없는 클래스의 프록시를 만들 때 오랫동안 사용해 왔다.

 

 - ByteBuddy : 최근 가장 각광받는 하이레벨 라이브러리다. 직관적인 Fluent API를 제공하며, CGLIB를 대체하는 추세다. 모던 프레임워크(Hibernate, Mockito 등)의 표준응로 자리 잡았다.

 

4. 실무 도입 시 주의 사항(디버깅 지옥)

바이트코드 조작은 마약과도 같다. 한 번 맛을 들이면 모든 중복 코드를 이런 식으로 처리하고 싶어지지만, 실무에서 직접 다루는 것은 극히 조심해야 한다.

 

가장 큰 문제는 디버깅 불가능성이다. 런타임에 메모리에서 동적으로 생성된 코드는 물리적인 .java 소스 파일이 존재하지 않는다. 장애가 발생해서 스택 트레이스(Stack Trace)를 까보면 내가 작성하지도 않은 기괴한 클래스명(PaymentService$ByteBuddy$1xyz)들이 수십 줄씩 찍혀 있는 것을 보게 될 것이다. 따라서 프레임워크나 사내 공통 라이브러리(Platform)팀의 영역으로 남겨두고, 일반적인 비즈니스 개발에서는 사용을 지양하는 것이 좋다.

 

5. 결론

3개의 포스팅에 걸쳐 어노테이션과 리플렉션, 클래스로더, 바이트코드 조작까지 자바가 제공하는 동적 아키텍처의 근간인 3가지에 대해 살펴보았다.

 

스프링 프레임워크는 결국 이 세 가지 기술의 결합체다.

클래스로더로 컴포넌트를 스캔하고, 리플랙션으로 객체를 생성하며, 바이트코드 조작을 통해 AOP(트랜잭션 등)를 덧씌운다.

 

다음 포스팅 부터는 스프링의 심장이라 불리는 DI에 대해 알아본다.