기술지원을 하면서 느낀 EJB-Architecture 의 단점.

spring 이라는 Lightweight 컨테이너에 대해 요새 조금씩 공부를 하고 있다.

이미 spring은 '신기술' 이라는 개념은 사라졌고
많은 사이트에서 활발히 적용되고 또한 논의되고 있는게 대한민국 SI의 현실이다.

spring 과 EJB 를 비교하면서 개념을 잡고 있는데.
일단 EJB를 실제로 사용하면서 느꼈던 불편함에 대해서 정리를 해보고자 한다.

프로젝트를 수행하면 크게 다음과 같이 3단계의 과정을 반복하게 된다.
(소프트웨어 아키텍쳐 설계등의 분석/설계 과정은 제외하고 순전히 개발자 입장에서만 바로본다면)

1. 비지니스 로직 개발
2. 개발환경에서의 테스트 및 디버깅
3. 운영환경에서의 서비스

이 3가지 과정을 무한반복하는게 개발자의 역활인데.
각 과정에 대한 EJB의 단점을 보자면 대충 다음과 같다고 생각한다.

1. 비지니스 로직 개발

- EJB Architecture 에 대한 이해가 필요하다.

(EJB Architecture는 매우 복잡하다.)

- 기반기술에 대한 이해가 없어도 코딩은 가능하기 때문에 매우 기본적인 코딩오류로 인한 문제가 발생할 가능성이 높다.

(기반기술에 대한 이해가 없기 때문에 충분히 발생할 수 있다. 예를 들자면 EJB 내에서 파일을 핸들링하는 코드를 작성하거나 Exception 발생 시 System.exit(1) 하는 사람도 있다 - 실제로 경험)

- 어디에 사용되는지도 모를 불필요한 코딩이 수반된다.

(이 부분은 Tool등으로 해결할 수도 있지만 기본적으로는 노가다의 일종이다.)

- 해당 EJB에 대한 명세를 xml 로 처리하는데 descriptor 자체를 이해하지 못해 발생하는 삽질반복이 있다.

(copy & paste 후 이름 바꾸기만 하다보면 분명 예기치 못한 오류가 발생한다.)

2. 개발환경에서 테스트 및 디버깅

- 일단 EJB 컨테이너가 있어야 하며 이에 대한 비용이 추가된다.

- 로직 개발 후 EJB 컨테이너에 배치해서 실행하기까지의 빌드 및 배치과정이 복잡하며 시간소모가 많다.

(ant 등의 Tool을 사용하는 것이 보편화 되었지만, 이 역시 새로운 기술에 대한 이해가 필요하다)

- 디버깅도 Tool을 사용하지 않으면 System.out.println() 의 무한반복이 펼쳐진다.

3. 운영환경에서의 서비스

- EJB는 분산환경을 지원하기 위해 Serialize 기술을 이용하며 이에 따른 성능감소는 엄청나다.

물론 EJB의 장점도 엄청나게 많다.
비지니스 로직개발에만 집중할 수 있도록 해준다는 그 한가지만 해도 어마어마한 매리트임에는 틀림없다.
솔직히 EJB가 도입되지 않고는 유지/보수가 거의 불가능할 정도로 복잡한 도메인이 많이 존재하며, 왠만한 기술력의 개발자가 아니면 그 복잡한 트랜잭션 처리와 예외처리, 리소스관리 및 보안처리등을 감당하기 힘들다.

하지만 대부분의 EJB 기반 사이트들이 주먹구구식으로 구축된 부분이 많으며, 기존의 C/S 사상에 젖어 있는 대부분의 개발자들에 의해 EJB가 왜곡되고 그 기본사상이 많이 훼손되고 있는게 사실이다. 따지고 보면 EJB 단점들 중에 솔직히 성능감소만 빼고는 개발자 개개인의 기술력 향상으로 모두 해결이 가능하다.

Interface와 class를 구분하지 못하며, NullPointerException 이 왜 발생하는지 모르면서 Java Program의 최고레벨이라 할 수 있는 EJB 를 만들어 낸다는게 참 희안한 풍경이긴 하지만..

이야기가 이리저리 새는 감이 있는데..
본인이 실제로 느낀 EJB의 단점은 그 Architecture가 너무 복잡하고 추상화레벨이 높기 때문에 구현하기는 쉬워도 이해하기는 어렵다는 점이다. 그래서 간단한 문제가 발생해도 쉽사리 해결하지 못하는 개발자가 많다는 것이다.

어찌되었건 위에서 나열한 많은 단점들을 보완하는 것이 바로 lightweight Architecture로 그 중 가장 대표적인 녀석이 spring이라는 framework니.. 요넘에 대해서 많이 뜯어봐야 할 듯 싶다. * spring은 framework 라는 말보다 infra 쪽에 더 가깝게 사용되고 있다.


본문과는 별상관없지만 덧붙이자면, 앞으로는 프로그래밍을 몰른다 할지라도 조금 더 쉽고 조금 더 빨리 비지니스 로직을 만들어 낼 수 있는 많은 기술이나 도구들이 대세를 이룰 듯 하다.