스프링 AOP 사용시 효율적인 개발전략과 고려해야될 사항

1) AOP 를 이용한 효율적인 개발 전략

AOP를 적용하지 않았던 지금까지의 프로젝트같은 경우에는 애플리케이션 전체에 영향을 미치는 Exception 처리, Logging 처리, Transaction 처리 방안에 대하여 프로젝트 초기에 확정하고 추후에 변경하지 않는 것이 프로젝트를 성공시키는게 큰 요인이 된다. 이 같은 정책이 프로젝트 초기에 수립되지 않은 상태에서 프로젝트를 진행하거나, 초기에 수립된 정책들이 수시로 바뀐다면 개발자들의 생산성은 저하될 수 밖에 없으며, 프로젝트의 위험요소는 증가하게 된다. 따라서 AOP를 적용하지 않는 프로젝트에서는 프로젝트 개발 초기에 Exception 처리, Logging 처리, 트랜잭션 처리 방안에 대한 정책을 확실하게 수립하는 것이 무엇보다 중요하다.

지금까지 국내에서 실행되고 있는 대부분의 프로젝트를 보면 프로젝트 내부에 일정한 명명규칙(Naming Convention)을 가지고 있다. 그러나 실질적으로 프로젝트를 진행할 때 이 같은 명명규칙은 단지 문서작업에 불과할 뿐 제대로 지켜지는 경우가 많지 않았다. 그러나 지금까지 프로젝트를 진행하는데 큰 실패요인이 되지 않았다. 그 이유는 변경사항이 발생할 때마다 개발자들의 희생이 있었기 때문이다. 무수한 밤을 세워가면서 변경된 정책을 소스코드에 반영하는 작업을 해왔기 때문이다.

그러나 AOP를 적용할 경우 프로젝트 초반에 Exception 처리, Logging 처리, 트랜잭션 처리를 어떻게 구현할지에 대해서는 프로젝트 중, 후반으로 미루어도 된다. 단, 구현하는 애플리케이션에 대한 명명규칙을 확립하고 이에 따라 프로젝트를 진행해야 한다. 이와 같이 일정한 명명규칙에 따라 프로젝트를 진행하지 않을 경우 추후에 AOP를 적용하려고 해도 힘들어 지는 상황이 발생하기 때문이다. 따라서 프로젝트 초반에 명명규칙을 확립하고 개발자들이 명명규칙을 따르도록 교육하는 단계가 필요하다.

물론 프로젝트 초반에 Exception 처리, Logging 처리, 트랜잭션 처리와 같은 기능들을 어떻게 처리할지에 대한 정책을 수립하는 것도 중요하지만 AOP를 적용할 경우 이 과정은 프로젝트 중, 후반에 결정해도 늦지 않게 된다. 또한 이 같은 정책을 변경할 경우에는 모든 클래스가 아닌 Aspect만을 변경하면 가능하기 때문에 프로젝트 중,후반에 정책을 변경하는 것도 힘들지 않다.

AOP를 적용한 프로젝트와 그렇지 않은 프로젝트에서 Infrastructure 정책이 변경되었을 때와 명명 규칙이 변경되었을 때 프로젝트에 미치는 영향을 보면 다음과 같다.

그림1 AOP 사용이 프로젝트에 미치는 영향을 도식화한 그림

이 같은 점이 AOP의 가장 큰 장점이라고 볼 수 있다. 역시 중복 코드를 제거함으로서 얻을 수 있는 가장 큰 장점중의 하나라고 볼 수 있겠다. 국내와 같이 프로젝트 초반에 Infrastructure가 제대로 수립되지 않은 상태에서 진행하거나, 프로젝트 도중에 이 같은 Infrastructure가 흔들리는 경우가 많은 곳에서는 AOP의 적용으로 더 큰 효과를 볼 수 있을 것으로 생각한다.

그러나 하나의 Target 클래스에 너무 많은 Aspect를 적용할 경우 실행속도의 저하를 가져올 수 있다. 또한 이 장에서 개발한 Logging Aspect가 애플리케이션의 모든 클래스에 적용되도록 구현한다면 이 또한 애플리케이션 실행속도 저하의 원인이 될 수 있다. Aspect의 사용이 중복 코드를 방지함으로서 많은 부분에서 중복된 개발을 방지하는 것은 사실이지만 무분별한 사용으로 인해 애플리케이션의 실행속도가 저하될 수 있다는 것을 명심하기 바란다. 따라서 Aspect는 애플리케이션 개발에 있어서 꼭 필요한 부분에 제한된 범위를 두고서 사용하는 것이 바람직하다.

새로운 기술이 등장하면 지금까지의 모든 문제점을 해결할 수 있는 것처럼 과대 광고를 한다. AOP 또한 좋은 기술이고 지금까지 해결하지 못했던 많은 문제들을 해결해주는 것이 사실이다. 그러나 대부분의 기술이 그렇듯이 좋은 점이 있다면 그에 따르는 부작용도 있기 마련이다. 프로젝트에 AOP를 적용할 때 이와 같은 부작용까지 고려하면서 사용할 때 좋은 애플리케이션을 개발할 수 있을 것이다.

*reference

• http://wiki.javajigi.net/pages/viewpage.action?pageId=28016657