Spring의 IoC적인 특징은 AOP를 구현하는 핵심적인 원리가 되어 왔습니다.
AOP란 무엇입니까? 사실, AOP는 그닥 어려운 개념은 아닙니다. AOP는 그동안의 전통적인 프로그래밍에서 개발자들이 느끼고 있던 불편함을 개선한 새로운 프로그래밍 패러다임이라고 보여집니다.


AOP가 필요한 이유를 설명하기 전에 일반적인 형태의 프로그램을 작성하는 방식을 살펴보겠습니다.


우리가 은행업무를 위한 프로그램을 작성한다고 가정해 보겠습니다. 은행업무에는 기본적인 입/출금업무가 있을 것이고 계좌이체업무도 있을 것입니다. 이러한 업무들이 바로 은행업무에 있어서 본질적인 비즈니스 기능이라고 할 수 있을 것입니다. 하지만, 이런 업무들만 있는 것은 아니지요. 누군가 돈을 찾아갔다면 그 정보도 남겨야 할 것이고 ID도용이 발생했다면 원인을 밝혀내야 하며, 온라인 뱅킹이 발생했다면 정상적으로 거래은행에 입금이 되었는지도 체크해야 합니다.


이와같이 은행업무를 위한 프로그램에는 핵심 비즈니스 기능뿐 아니라 부가적이라고 말할 수도 있는 보안, 인증, 로그 , 중복체크등과 같은 기능들도 통합되어 있어야만 비로소 완전하게 구현되었다고 말할 수 있습니다. 어쩌면은 은행 본연의 업무를 위한 코드들보다 부가적인 측면을 다루는 코드가 더 많아질수도 있겠습니다.


하지만 이 부가적인 기능을 다루는 코드는 비즈니스 로직과는 상관관계가 없는 경우가 많아서 여러업무에 중복적으로 사용되는 것이 일반적이지요. 보통 개발이 진행되면 진행될수록 사실 핵심 비즈니스로직보다는 이러한 부가적인 처리에 사용되는 코드가 문제가 되기도 합니다. 시스템 전체에 걸쳐서 사용되고 있기 때문에 수정도 힘들고 관리도 힘들게 됩니다.


AOP세계에서는 상기 설명했던 기능중에서 비즈니스로직을 구현한 기능들을 Primary(Core) concern이라고 부릅니다. 보안, 인증, 로그등과 같은 부가적인 기능으로서 시스템 전반에 산재되어 사용되는 기능들은 Cross-cutting concern이라고 부르고 있습니다. 바로 AOP의 핵심이 여기에 있습니다. 바로 AOP는 우리에게 있어서 골치거리인 Cross-cutting concern을 어떻게 다룰 것인가에 대한 새로운 패러다임을 제고하고 있습니다.


사실 AOP가 등장하기 전에는 Primary concern과 Cross-cutting concern이 같이 하나의 프로그램에 구현되어져 왔습니다. 당연히 비즈니스 로직과 상관없는 코드들이 여기저기 산재해 있게 되었기에 가독성과 유지보수성에 악영향이 있을 수 밖에 없었을 것입니다. 생산성 저하와 비용증가는 당연한 결과였겠지요.


하지만, AOP세계에서는 다릅니다. AOP는 Primary concern과 Cross-cutting concern을 별도의 코드로 구현합니다. 최종적인 프로그램은 이 둘을 조합하여 완성하게 되는 것이죠. 이것은 하나의 프로그램에 각각의 코드들이 혼재해 있는 것과는 명확히 다른 것입니다. 사실 이렇게 되기를 많은 개발자들이 마음속으로 바래마지 않았을 것이지만 그 방법을 몰랐었습니다. AOP는 모든 개발자들이 바랬던 이상을 구현해 놓은 것에 불과(?)한것이지요.

이제, AOP세계에서 새로운 용어들이 등장하게 되었습니다. 바로 Advice와 Code , Point-Cut 그리고 Weaving입니다.


Code는 Primary(Core) concern을 구현해 놓은 코드를 이야기합니다. Advice는 Cross-cutting Concern을 구현한 코드를 지칭하고 있습니다. 그럼, Point-cut은 무엇일까요? 바로 Advice와 Code를 연결해주는 설정 정보를 말합니다. 다시 말하면 Point-cut은 Code의 어느 위치에 Advice를 위치할 것인가에 대한 것입니다. 마지막으로 Weaving은 이 둘(Code와 Advice)를 조합하여 완성된 어플리케이션을 만드는 과정을 이야기합니다.


정리해 볼까요?

  • Code : Primary(core) concern을 구현한 코드
  • Advice:  Cross-cutting concern을 구현한 코드
  • Jointpoint:Code와 Advice를 연결해주는 설정 정보, Advice가 적용 가능한 지점(메소드 호출, 필드값 변경)
  • Point-cut: Jointpoint의 부분집합으로서 실제 Advice가 적용되는 Jointpint
  • Weaving : Code, Advice, Point-cut등을 조합하여서 어플리케이션을 만들어 가는 과정

이 용어들을 이해하는 것으로도 벌써 AOP세계의 절반은 여행하셨다고 볼 수 있습니다. 사실 이 용어를 이해한다면 AOP는 그닥 어려운 것이 아닐 수 있습니다. 따라서 위의 용어들은 반드시 숙지하시길 권면드립니다.


그럼 왜 AOP(Aspect Oriented Programming)이라고 하는 걸까요?

AOP의 Aspect는 Advice와 Point-cut을 함께 지칭하는 단어입니다. 따라서 AOP는 Advice와 Point-cut에 대한 이야기를 하고 싶었던 것이네요.

Spring의 AOP패키지는 이러한 AOP개념을 멋드러지게 구현한 것으로서 그 배경에는 IoC 또는 DI가 자리하고 있습니다.


Spring AOP도 여러 AOP 프레임워크중의 하나입니다. 따라서 나름의 특징이 있습니다. 간단히 소개를 해보자면 다음과 같습니다.

  • 자체적인 프록시 기반의 AOP 지원

필드값 변경과 같은 Joinpoint는 사용할 수 없고 메서드 호출 Joinpoint만 지원합니다. Spring AOP는 완전한 AOP를 지원하는 것이 목적이 아니라 엔터프라이즈 어플리케이션을 구현하는데 필요한 정도의 기능 제공을 목적으로 하고 있습니다.

  •  Spring AOP는 자바 기반

AspectJ는 별도의 문법을 알아야 하지만 Spring AOP는 자바를 기반으로 하고 있기때문에 다른 언어를 익힐 필요가 없습니다.


Spring AOP는 내부적으로 프록시를 이용하여 AOP가 구현되기 때문에 메서드 호출에 대해서만 AOP를 적용할 수 있다는 점이 아쉬운 점이라고 할 만하지만, 크게 문제될 것은 없다는 개인적인 생각입니다.


참조 - http://blog.naver.com/go828258/112903221

2010/03/04 13:53


Posted by linuxism
,