통에 들어간 OrderService 는 내가 쓴 클래스가 아니라, 그것을 상속한 자식이다

장면

컨트롤러가 주입받은 OrderService 의 클래스 이름을 찍어 봤더니 OrderService$$SpringCGLIB$$0 이 나왔다. 내가 만든 적 없는 이 클래스는 누가, 왜 만들었을까?

먼저 알아야 할 말

프록시: 원본을 대신 받아 주는 객체다. 겉모습은 원본과 같아서 쓰는 쪽은 눈치채지 못하고, 안에서 원본의 일을 시키기 전후에 일을 더 한다.
CGLIB: 클래스를 상속한 자식 클래스를 프로그램이 도는 중에 만들어 내는 라이브러리다. 스프링이 프록시를 만들 때 쓰는 방법 중 하나다. 이름 끝의 $$ 는 사람이 짓는 이름과 겹치지 않게 기계가 붙이는 표시이고, 마지막 0 은 그 클래스로 몇 번째 만든 자식인지를 뜻한다.
상속: 이미 있는 클래스를 물려받아 새 클래스를 만드는 것이다. 자식은 부모가 가진 메서드를 그대로 갖고, 필요한 것만 다시 쓴다.
@Transactional: 메서드나 클래스에 붙이는 표시다. 붙은 메서드가 시작될 때 트랜잭션을 열고, 끝나면 커밋하고, 도중에 예외가 나면 되돌린다. 그 일을 하는 코드는 내 클래스가 아니라 프록시 안에 있다.
트랜잭션: DB 작업 여러 개를 한 묶음으로 묶는 것이다. 「연다」는 DB 에 「지금부터 하는 것들을 한 묶음으로 봐 달라」고 말해 두는 일이고, 다 성공하면 커밋(묶은 작업을 확정해 DB 에 진짜로 반영), 하나라도 실패하면 롤백(전부 없던 일로 되돌림)한다.
빈: 스프링이 대신 만들어서 들고 있다가 필요한 곳에 넣어 주는 객체다. 내가 new 로 만들지 않고 「이게 필요하다」고만 적으면 스프링이 찾아서 넣는다.
통: 빈을 만들어 담아 두는 곳이다. 제대로 된 이름은 애플리케이션 컨텍스트이고, 이 페이지에서는 통이라고 부른다. 여기서 「무엇이 필요하다」는 요청을 받아 담긴 빈을 꺼내 준다.
의존성 주입: 빈이 필요로 하는 다른 빈을 스프링이 찾아서 넣어 주는 일이다. 나는 생성자에 「무엇이 필요한가」만 적는다. 자바는 클래스 파일 안에 생성자의 매개변수 타입까지 적어 두기 때문에, 스프링은 프로그램이 도는 중에도 그것을 읽어 「무엇이 필요한지」를 알아낼 수 있다.
aspectj: 메서드를 감싸는 일을 하는 다른 라이브러리다. 이것이 클래스패스에 있으면 스프링은 감쌀 대상을 더 잘게 고를 수 있는 그쪽 장치를 함께 쓰고, 없으면 상속만으로 감싼다(CGLIB). 이 실측에서는 넣지 않았다.
super: 자식 클래스 안에서 부모의 메서드를 부를 때 쓰는 말이다. 자식이 place() 를 덮어쓰고 그 안에서 원래 구현을 부르려면 super.place() 라고 적는다.
AOP: 트랜잭션이나 로그처럼 여러 곳에 똑같이 들어가야 하는 일을, 원래 코드는 그대로 두고 밖에서 감싸 붙이는 방식이다. 스프링은 그 감싸는 일을 프록시로 한다. 「AOP 프록시」는 그렇게 만들어진 프록시라는 뜻이다.
실행 중에 만드는 클래스: 자바는 .java 파일을 컴파일해 클래스를 만드는 것이 보통이지만, 클래스 파일의 바이트 배열만 있으면 프로그램이 도는 중에도 그것을 클래스로 읽어들일 수 있다. CGLIB 은 「OrderService 를 상속한 자식」에 해당하는 바이트 배열을 그 자리에서 만들어 건네준다. 그래서 내 프로젝트를 뒤져도 그 .java 파일은 없다.
자기 호출: 한 객체 안에서 this 로 자기 자신의 다른 메서드를 부르는 것이다. 밖에서 부르는 호출은 프록시가 먼저 받지만, 이미 원래 구현 안으로 들어온 뒤의 자기 호출은 프록시를 지나갈 일이 없다. 그래서 그 메서드에 @Transactional 을 붙여도 아무 일이 일어나지 않는다.
빈 후처리기: 빈이 만들어진 직후에 끼어들어 손을 보는 부품이다. 통이 빈을 하나 만들 때마다 한 번씩 부른다. 4단계에서 프록시로 감쌀지 정하는 것이 이 자리다.
DB: 데이터를 표 모양으로 저장해 두고 꺼내 쓰게 해 주는 별도의 프로그램이다. 표 하나에 줄이 쌓이고, 무엇을 넣거나 꺼내려면 SQL 로 말을 걸어야 한다. 프로그램이 꺼져도 남는다는 것이 변수와 다른 점이다.

아래 재생기의 ▶를 누르면 한 스텝씩 진행된다. 금색 테두리가 방금 바뀐 곳이고, 캡션이 무슨 일이 일어났는지 말해 준다. 굵게 밑줄 친 말은 누르면 뜻이 나온다.

장면 · 프록시로 감싼다 0 / 9

3단계에서 orderService가 만들어지던 그 순간을 확대한 장면이다. 내가 쓴 OrderService는 필드 하나(JdbcTemplate)와 메서드 둘뿐이다 — place()는 @Transactional이 붙어 있고 주문을 한 줄 넣은 뒤 개수를 세어 돌려주며, count()는 개수만 센다. ▶를 누르면 이 객체가 통에 들어가기까지 사이에 무엇이 끼는지 9스텝으로 따라간다.

키보드 · ← → 한 스텝 · Space 재생/멈춤 · Home 처음

@Transactional 한 줄이 클래스 하나를 통째로 바꿔 끼운다. 내 코드에는 트랜잭션을 여는 문장이 없는데도 트랜잭션이 열리는 이유가 이것이다. 대신 대가가 있다 — 통에 든 것이 내 클래스가 아니므로, 같은 객체 안에서 this 로 다른 메서드를 부르면 자식을 거치지 않아 트랜잭션이 열리지 않는다. 이 실측에서는 317개 중 감싸인 것이 orderService 하나뿐이었다.

어떻게 확인했나

클래스 이름 · 부모 클래스 · isCglibProxy · aopProxied 1건은 기동이 끝난 뒤 도는 러너가 찍은 값이다.
aspectj 가 없어서 상속으로 감쌌다는 것은 2단계의 조건 검사 결과(ClassProxyingConfiguration 켜짐 · AspectJAutoProxyingConfiguration 꺼짐)와 이어 붙인 것이다. 두 사실은 각각 로그로 확인했지만, 둘을 잇는 「그래서」까지 실험으로 갈라 확인하지는 않았다.
같은 객체 안에서 부르면 트랜잭션이 안 열린다는 것은 이 실측에서 확인한 것이 아니라, 자식이 부모를 감싸는 구조에서 따라 나오는 결과로 적었다.

‹ 이전 다음 단계 ›