쉽게 이해하는 스프링 AOP (~작성중~)

https://jiwondev.tistory.com/151 를 이해하기 쉽게 풀어서 작성하는 글입니다.

저수준부터 시작해서 스프링 AOP가 어떻게 만들어질 수 있는지를 설명합니다.

이미 알고있는 내용이 있다면 적당히 넘기면서 보는 것을 추천드립니다.

 

# 동적 언어와 정적 언어

다만 최근에는 두가지를 섞어 사용하므로 동적/정적 바인딩으로 컴파일러와 인터프리터를 구분할 수는 없습니다.

 

@ 인터프리터는 소스코드를 행단위, 문장단위로 기계어로 번역해 바로 메모리에 올려 실행합니다.

:: Python, JS 처럼 인터프리터를 사용하는 경우에는 타입, 형태를 미리 정하지 않고 소스코드(.py .js)를 읽어들이며 메모리에 올라가는 순간 결정되죠. 그래서 자료형을 따로 지정하지 않아도 괜찮습니다. 해당 변수나 메서드를 사용할 때 실제 메모리에 어떻게 저장할지 정하면 되니까요. 이를 동적 바인딩을 사용하는 언어 라고 표현합니다.

 

@ 컴파일러는 소스코드 전체를 읽어들여 타입과 형태를 지정하고, 최적화된 기계어로 만듭니다.

:: C, CPP 처럼 컴파일러를 사용하는 경우 컴파일 시점에 객체의 타입, 메서드의 형태가 전부 고정됩니다. 위의 인터프리터와 다르게 '소스코드'를 그때 그때 번역해서 사용하는 것이 아니라, 아예 기계어로 된 프로그램(.exe)를 만들어서 사용하기 때문이죠. 그래서 프로그램 코드에 메서드의 형태나 데이터의 종류를 전부 확실하게 정해줘야합니다. 이를 정적인 바인딩을 사용하는 언어 라고 표현합니다.

 

@ 그렇다면 유연하게 사용할 수 있는 인터프리터 - 동적바인딩이 무조건 좋은걸까요?

:: 아뇨. 그렇지 않습니다. 컴파일러처럼 프로그램이 메모리에 올라가기전 메서드의 형태나 데이터의 종류를 정해주면 컴파일 시점에 프로그램이 실행될 때 어떠한 문제가 발생할지 미리 예측이 가능합니다. 또한 사용할 메모리 크기를 미리 알수 있고 개발자가 작성한 코드를 컴파일러가 더 최적화시켜 성능을 향상 시킬 수 있는 여지를 만들어 줍니다.

 

@ 하지만 컴파일러 - 정적바인딩도 단점이 있습니다.

:: 우선, [인터프리터 - 동적바인딩]의 경우에는 프로그램 배포를 소스코드(텍스트)로 할 수 있습니다. 그래서 운영체제가 바뀌어도 실행하는 시점에 번역을 하는거라 큰 문제가 없고 네트워크로 전송하기도 쉽습니다.

[컴파일러 - 정적바인딩]의 경우에는 배포를 기계어(.exe)로 하기 때문에 특정 운영체제에만 사용할 수 있는 코드가 만들어집니다. 그러면 소스코드를 전달하고 컴파일러를 운영체제마다 설치하면 되지 않냐구요? 아뇨. 컴파일러는 복잡하고 무거운 프로그램입니다. 인터프리터처럼 바로바로 읽어서 번역하는게 아니라, 전체를 다 읽어 최적화하기 때문에 컴파일 시간도 오래걸리고 컴파일러를 배포 환경마다 가지고있기에도 부담스럽죠. 만약 그렇게 한다면 프로그램 하나 실행하는데 30분씩 걸릴지도 모릅니다.

---

# 자바와 바이트코드

그렇다면 자바는 인터프리터를 사용하는 동적언어일까요? 컴파일러를 사용하는 정적언어일까요? 정답은 둘 다 입니다.자바를 만든 개발자들은 다음과 같은 장점들을 둘 다 가지고 싶었습니다.

• 컴파일러의 장점
  - 정적인 바운딩을 사용해서 컴파일 시점에 오류를 잡아 낼 수 있다.
  - 전체 프로그램 코드를 읽어들여 프로그램의 성능을 최적화 시킬 수 있다.
• 인터프리터의 장점
  - 인터프리터는 컴파일러에 비해 가볍고 번역 속도가 빠르다.
  - 배포 자체를 소스코드(텍스트)로 진행하여 네트워크 비용이 적게든다. 배포하기 쉽다.
  - 즉, 운영체제마다 같은 소스코드를 사용할 수 있다. 따로 만들지 않아도 된다.
  
  

@ 그래서 자바 개발자들은 아주 재밌는 생각을 하게 됩니다.

소스코드를 컴파일 해서 바로 기계어로 만들지 말고, 인터프리터 코드로 만들면 어때? 그럼 정적인 바운딩을 통한 오류 검출 + 성능 최적화를 챙기면서 운영체제에서 인터프리터를 이용해 해석하면 되잖아!

네, 그렇게 등장한 것이 바로 Java코드를 컴파일 한 바이트코드(.class) 입니다. 프로그램을 배포할 때 기계어(.exe)가 아닌 바이트코드를 배포하게 되며, 바이트코드는 읽어들여졌을 때 기계어로 번역되어 메모리에 올라가는 인터프리터 방식으로 동작하게 됩니다. 개발자는 자바코드를 컴파일하여 사용하고 배포할 땐 각 운영체제에 설치된 [JVM의 인터프리터]로 코드를 그때 그때 번역해서 사용하는거죠.

 

---

# JVM과 바이트코드에 대한 이해

바이트코드는 상당히 유연한 언어입니다. 꼭 Java로 작성하지 않아도 전용 컴파일러만 만들면 바이트코드로 변환할 수 있습니다. 하지만 이러한 방식도 컴파일러의 기계어수준 최적화에 비해서는 성능이 매우 느렸습니다. 실제로 C언어보다 성능이 너무 안좋다고 비판도 많이 받았죠.

 

그래서 인터프리터의 성능적인 단점을 해결하기 위해 자바는 [JIT 컴파일러]라는 개념을 사용합니다. JVM상에서 자주 사용되는 바이트코드만 선택적으로 기계어로 캐싱해두고 재사용 하는 방법이죠. 이는 자세하게 들어가면 내용이 너무 많으므로, 2021.08.16 - [기본 지식/Java 기본지식] - JVM의 원리와 바이트코드를 읽어보시길 바래요.

JVM의 원리와 바이트코드

 

• Java 언어는 컴파일러를 사용하여 바이트코드로 변역됩니다. 그래서 정적인 바운딩을 사용하기에 한번 형태가 정해진 메서드, 필드 값들을 실행시점에 마음대로 변경이 불가능합니다.
  
  
• 하지만 바이트코드는 가능합니다. 인터프리터와 동일한 방식으로 동작하고, 결국 바이트코드는 읽혀지는 시점에 기계어로 번역되고 메모리에 등록되기 때문에 내가 [int a] 라고 정했어도 실행시점에 [double a]로 형태를 바꿀 수 있다는 말이죠.

 

---

# 바이트코드를 내 마음대로 조작 할 수 있나요?

결국에는 바이트코드도 JVM이 읽어들여 실행하기 전까진 파일로 이루어진 '데이터' 입니다. 적절한 도구가 있다면 데이터를 읽어들이고 원하는데로 조작할 수 있습니다. 실제로 [아파치의 BCEL], [Objectweb의 ASM]등의 도구들을 이용하면 아래와 같은 작업을 할 수 있습니다.

 

• 분석 : 바이트코드를 읽어들여 잠재적인 버그를 찾거나 디컴파일(역공학)에 사용할 수 있습니다.
• 생성 : 기존의 자바코드로 새로운 바이트코드를 생성해낼 수 있습니다.
• 변경 : 바이트코드를 변경하여 프로그램을 최적화하거나 AOP를 구현해 성능 모니터링, 디버깅 코드를 추가합니다.

실제로 ASM 같은 것들을 활용하여 JIT 컴파일러나 AspectJ 같은 바이트코드 조작 라이브러리를 만들었답니다.

 

@ 어, 그러면 자바소스 코드를 조작할 수도 있겠네요?

이건 이미 위에서 답변을 했습니다. 당연히 가능은 하지만 컴파일러는 번역속도가 느리고 프로그램이 무거워서 실사용이 어렵습니다.

 

---

# 자바진형 (JVM)에서 제공하는 공식적인 바이트코드 조작기능은 없나요?

공식적으로 제공하는 자바 리플렉션 API (Refelction API)와 자바 컴파일러에 내장된 어노테이션 프로세서가 있습니다.

 

@ 리플렉션 기술이 등장한 이유

위에서 말했던 것처럼 바이트코드를 조작하는 건 가능하지만, [자바코드로 작성된 객체]에서 내가 원하는 부분을 바이트코드에서 찾아 읽고 수정하기는 매우 어렵습니다. 컴파일 된 바이트코드에서 내가 원하는 객체의 구조와 메서드, 필드 정보를 찾는건 말이 안되죠.

그래서 자바에서는 리플렉션 API를 제공합니다. 리플렉션이란 거울, 투영하다는 의미로 [클래스의 정보를 담는 객체]를 리플렉션 객체라고 말합니다. 실제로 자바에 모든 객체는 [클래스의 정보를 담는 객체, 즉 리플렉션 객체]를 기본적으로 가지고 있습니다.

// 리플렉션 객체 반환 (클래스 멤버)
Class reflection1 = Object.class

Book book = new Book();// Object.getClass()로 리플렉션 객체 반환
Class<? extends Book> reflection2 = book.getClass();

 

아래와 같이 문자열을 이용해서 내가 원하는 객체를 만들수 있는것도, 리플렉션 객체를 이용하기 때문입니다.

Class myObjectClass = Class.forName("me.package.className"); // 클래스를 생성 후 반환
Class.forName("oracle.jdbc.driver.OracleDriver");
 
 
// 참고 :: Class.forName() 메서드 정의. 문자열을 이용해서 해당 리플렉션 객체를 찾음.
public static Class<?> forName(String className)
                        throws ClassNotFoundException {...}

 

@ JDK 리플렉션 API

자바에서는 JVM이 바이트코드를 읽다가 [특정 객체의 코드를 읽어들였거나 조건이 발생했을 때] JVM에 인터럽트를 걸어 내가 원하는 코드가 실행되도록 만들 수 있습니다. 이를 개발자가 원하는데로 가능하게 자바 코드를 이용한 API를 제공해주는데, 이것이 바로 JDK Reflcetion API (java.lang.reflect) 입니다.

public class App {
    public static void main(String[] args) {
        Class<User> userClass = User.class;
        User user = new User("test", "name", "1234"); // 테스트용 인스턴스
        
        Arrays.stream(userClass.getDeclaredFields())
                .forEach(filed -> {// User.class에 정의된 필드를 모두 가져와서
                    try {
                        filed.setAccessible(true); // private 접근제어자 무시
                        // filed.get(인스턴스)로 해당 인스턴스의 데이터를 읽어서 반환함.
                        // 만약 .get(null)을 한다면 static인 클래스 데이터를 반환함.
                        System.out.println(filed + " " + filed.get(user));
                        
                    } catch (IllegalAccessException e) {
                        // 잘못된 접근, 해당 메서드가 없는 경우등등..
                    }
                });
    }
}

리플렉션 API를 이용해 원하는 객체의 바이트코드를 읽고 수정할 수 있습니다.

Object.class 안에는 해당 객체의 [리플렉션 객체]가 있으며 Class<?> 타입입니다. 아래와 같은 메서드들을 제공합니다. 

 

~ 스프링 AOP를 직접 사용해보고 작성할 예정~

 

- 동적바인딩의 필요성, 프록시

- 프록시란?

- 리플렉션을 이용한 다이나믹 프록시 (JDK refelct.proxy)

- 프록시 생성 라이브러리 CGLib (바이트코드를 조작하는 ASM로 만들어짐)

- CGlib와 JDK 비교, 장단점

- AOP란 무엇인가

- 스프링 AOP는 다이나믹 프록시를 이용해 만든 기능이다.

- AspectJ와 스프링 AOP의 차이 (스프링 AOP는 컨테이너 빈에만 적용시킬려고 만듬. 메서드만 조작함.)

- AspectJ, 진정한 AOP 솔루션

- RTW, CTW, LTW 의 차이

 

- 자바에서 제공하는 바이트코드조작 빌드 툴, 어노테이션 프로세서

- 어노테이션이 나온 이유와 할 수 있는일

- lombok은 특이케이스. 컴파일러 메서드 해킹