java 코드는 어떻게 자동으로 만들어질까(2/2)

앞 글에서 남긴 의문, 즉 Lombok은 새 자바 파일을 만들지 않는데 getter가 어디에 있느냐에 답하는 2부다. 어노테이션 프로세서가 보통 새 파일을 만들 뿐 기존 파일을 고치지 않는다는 전제에서 출발해, Lombok이 컴파일 중간 산출물인 구문 트리를 건드린다는 데까지 내려간다. 바이트코드를 직접 조작하는 다른 경로와 그 실사용처도 함께 짚는다.

핵심 포인트

어노테이션 프로세서는 일반적으로 새 자바 파일을 생성할 뿐 기존 자바 파일을 수정하지 않는다.
Lombok은 자바 파일이 아니라 컴파일 결과인 클래스 파일 쪽에 코드를 남긴다.
컴파일은 크게 파싱과 구문 분석, 어노테이션 처리, 분석과 파일 생성 세 단계로 볼 수 있다.
1단계에서 소스가 추상 구문 트리로 파싱되고 그 트리를 기반으로 클래스 파일이 만들어진다.
그 트리에 노드를 끼워 넣는 시점이 바로 어노테이션 처리 단계다.
클래스 파일을 다루는 다른 경로로 바이트코드를 읽고 고치고 쓰는 ASM이 있다.

상세 정리

앞 글의 정리: 컴파일 과정에 어노테이션 처리 단계가 있고 거기서 어노테이션을 기반으로 코드를 생성할 수 있으며, 생성에는 JavaPoet 같은 라이브러리를 쓴다는 것까지 다뤘다.
남은 의문: 그런데 Lombok을 쓰면 새 자바 파일이 생기지 않는데 getter 코드는 대체 어디에 있느냐는 질문이다.
전제 확인: 어노테이션 프로세서는 새 파일을 만들 뿐 기존 자바 파일을 고치지는 않는다.
실제 위치: 자바 파일은 컴파일을 거쳐 바이트코드로 된 클래스 파일이 되는데, 그 클래스 파일 안에 getter가 들어 있다.
확인 방법: 클래스 파일을 디컴파일해 보면 소스에는 없던 getter가 들어가 있는 것을 볼 수 있다.
일반적인 감각과의 차이: 비즈니스 로직을 개발할 때 클래스 파일을 수정할 일은 전혀 없지만 라이브러리나 프레임워크 층에서는 종종 일어난다.
컴파일 3단계: 파싱과 구문 분석, 어노테이션 처리, 분석과 파일 생성으로 나눠 볼 수 있다.
1단계의 산출물: 소스코드가 DOM 트리 같은 형태의 추상 구문 트리로 파싱된다. 자바에만 국한된 개념은 아니다.
생성 경로: 컴파일러는 그 트리로 구문을 분석한 뒤 트리를 기반으로 클래스 파일을 만든다.
착안점: 그렇다면 그 트리에 노드를 끼워 넣으면 클래스 파일에 없던 코드가 추가되는 셈이 된다.
끼워 넣는 시점: 그 작업이 이뤄지는 곳이 1부에서 다룬 어노테이션 처리 단계다.
결론: Lombok은 이 방식으로 동작한다.
다른 경로: 클래스 파일을 조작하는 방법은 더 있으며 바이트코드를 다루는 대표 라이브러리로 ASM이 있다.
ASM의 구성: 읽기와 방문, 쓰기를 담당하는 요소들을 제공해 클래스를 직접 읽고 수정하고 쓸 수 있게 한다.
실사용처 1: 스프링 AOP가 프록시를 만들 때 쓰는 라이브러리 내부에서 ASM으로 바이트코드 수준에 코드를 심는다.
실사용처 2: 코드 커버리지 측정 도구에서도 쓰인다.
마무리 취지: 원리를 알면 어노테이션 처리 관련 에러가 나도 막연한 두려움 대신 어느 단계에서 난 문제인지부터 살펴보게 된다고 정리한다.