[펌] EJB는 언제 사용해야 하는가?

EJB는 언제 사용해야 하는가?

2004-03-25
조병욱

EJB 는 J2EE의 기술의 하나로, 분명히 편리하고 강력한 첨단 기술임에는 틀림이 없다. 그렇지만, EJB의 특징과 장단점을 제대로 인식하고 EJB 사용하는 개발자는 많지 않다고 느껴진다.
특히나 대부분의 EJB로 이루어지는 부분에 대해서는 EJB가 아니라 일반 Java Beans로도 구현이 가능하다. 그렇다면 언제 EJB를 사용해야 되는것인지에 대해서 알아보도록 하자.

일반 Servlet/JSP는 Presentation 즉 데이타를 화면에 나타내기위한 부분을 위해서 디자인 된 부분이다. 종종 웹개발자들이 개발을 하면서 Business Logic이나 SQL문장까지 Servlet/JSP에 들어가는 일이 있는데, 이렇게 되면 Presentaion과 Logic의 분리가 불가능하다. 즉 둘중 하나만 바뀌더라도 코드를 수정해야된다.

EJB를 사용하지 않더라도
Servlet/JSP (Presentation) -> Java Beans (Business Logic) -> DBMS
이런 방식으로 구현하는게 좀더 모범답안이다.
대부분의 Web Application은 이런 방식으로 개발이 가능하다.
그 외에도 간단한 WebService의 개발이나, 또는 3 Tier가 아닌 위에서 제시한 2 Tier 모델인 경우에도 굳이 EJB를 사용할 필요가 없다.

EJB 선택에 있어서 잘못된 상식
그렇다면 EJB는 언제 사용하는가?
개발자들과 EJB에 대해서 이야기 해보면 몇가지 잘못된 상식이 있다. 하나하나 집어 보도록 하자.

EJB server는 비싸다?
EJB 도입에 있어서 망설이는 부분중 하나가 WAS의 가격문제이다. WAS 자체의 가격만으로만 보면 절대 싼 가격은 아니다. 그러나 프로젝트 전체를 봤을때는 반대로 비싼 가격이 아니다. 프로젝트 전체란 단순히 개발 비용만을 말하는것이 아니라 유지 보수 비용을 포함한다. 더군다나, J2EE Framework (EJB, Load Balancing,Failover,Transaction 처리 등)을 직접 구현하지 않고 이미 표준화되고 안정화된 환경을 사용하는것에 대하면 오히려 개발비용을 효과적으로 줄일 수 있는 방안이기도 하다.

단, 국내 개발자들이 WAS선택에 있어서 고려해야할점은 합리적인 선택이 필요하다는 것이다. 같은 WAS라도 지원하는 Feature에 따라서 가격이 틀리기 때문에 구현하고 사용하고자 하는 Feature를 갖추고 있는 WAS Version을 구입할 필요가 있다.

그리고 구입전에는 용량 산정작업 (Capacity Planing)이 필요하다. 주먹구구식으로 HW성능과 WAS의 개수를 선택하다보면 쓸데없이 비용만 낭비하기 마련이다. 용량 산정에 대한 사전 작업과 컨설팅에 비용을 투자한다면 그로 인해서 쓸데 없이 사양만 높은 HW와 많은 수의 WAS를 사는 일을 줄여서 프로젝트 비용을 많이 조정할 수 있을 것이다. ( 실제로도 4CPU만으로도 충분한 프로젝트를 12CPU이상으로 진행하는 경우도 많이 봤다. 국내에서는 컨설팅 문화가 정착되지 않은 이유도 있겠지만, 효과적인 컨설팅은 프로젝트의 위험요소 제거와 정확한 진행에 많은 도움을 준다. 물론 컨설팅 회사가 그만한 노하우를 가져야 함은 두말할나위 없는 사항이다.)

그외에 방안으로는 공개 WAS를 사용하는 방법도 있다. 대신 중요한 업무를 다루는 프로젝트의 경우 공개 WAS는 기술지원의 한계와 가이드의 부제등 때문에 절대 추천하고 싶지 않다.

EJB로 나누면 Component 모델이나 각 Tier를 구분하기가 훨씬 편리하다?

물론 EJB를 사용하면 Business Logic이나 Data Model을 분리하기도 좋고, Component 화 하기도 좋다. 그러나 이런 이유만으로 EJB를 선택하는것은 합당하지 못하다. EJB를 사용하지 않더라도 Java Beans 만으로도 충분히 Component Model이나 Tier 구분이 가능하다.

그럼 EJB 는 언제 사용해야 하는가?

EJB를 언제 사용하느냐는 것은 EJB의 장점과도 연관이 된다.

좀더 빠르고 안정적인 시스템을 위하여…
EJB는 instance pooling,transaction 처리, 보안,CMP,CMR 그리고 데이타 캐슁과 클러스터링을 통한 Load Balancing과 Fail over 기능들을 이미 다 구현해놓은 frame-work이다. 간단하게 Session Bean을 통해서 SQL문을 하나 처리한다 하더라도 그 안에는 이런 기능이 이미 구현되어 있고, 이런 기능들은 이미 vendor들에 의해서 최적화 되고 안정성이 검증된 기술들이다.

이런 기능들을 일일이 구현하기 위해서는 framework등을 만들어야 하는데, 여기에 소요되는 시간과 기술 그리고 시행 착오에 드는 비용이 매우 크다. 프로젝트 하나를 위해서 Clustering 기능을 직접 구현한다고 생각해보자… 필자로서는 상상이 안가는 일이다.

담당자가 바뀌었을때도 안정적인 운영이 가능하다.
Framework을 만들어서 운영을 했다고 하자, 그후에 운영 담당 기술자가 바뀌면 그 Framework을 설명과 별도의 교육 작업이 필요하다. 그렇지만 J2EE 기술은 표준 기술이기 때문에 J2EE 기술을 가지고 있는 기술자를 뽑는다면 Framework 자체에 대한 기술 교육은 필요없이 바로 시스템을 인수 받을 수 있게 된다.

표준기술이기 때문에 많은 자료들을 구할 수 있다.
또한 잘 알다 싶이 J2EE는 이미 표준화되고 많은 검증된 솔루션(J2EE Pattern)과 Article들이 많기 때문에 EJB 솔루션을 사용하기 위한 도움을 받기가 용이하다.

RAD Tool을 통해서 개발 생산성을 극대화할 수 있다.
이미 EJB는 표준화된 기술이기 때문에 각종 RAD에서 EJB를 만들기 위한 Process를 자동화해서 지원하고 있다. 그래서 빠르게 EJB를 이용하여 프로그램을 제작할 수 있고 , RAD 이외에도 ant와 같은 command line tools를 이용해서도 개발에 도움을 받을 수 있다.

Tier 구분이 매우 편리하다.
Tier 구분은 위에서 말한 단순한 Servlet/JSP->Java Bean 이런 Tier 구분이 아니라, EJB는 Remote Call로 Invoke가 가능하기 때문에 Presentation (Servlet/JSP)와 Business Logic(EJB)을 물리적으로 완전히 분리하는것도 가능하다. 또한 Servlet/JSP가 아니라 Applet, RMI/IIOP를 이용하여 일반 Client까지 연동이 가능하기 때문에, Presentation Layer에 대해서 독립성을 가지는 Tier 모델을 작성할 수 있다.

그렇다면 EJB를 사용하는게 언제나 좋은가?

결론부터 이야기 하자면, 대답은 NO이다.
특히 가장 하고 싶은말중 하나는 EJB의 특징을 제대로 알고 필요한 요소에 제대로 사용하자는 것이다. ( 예를 들어 EJB의 Transaction 모델을 쓰면서 dbconn.commit()을 한다던지와 같은 일을 하는건 없어져야한다는 말이다. )

물론 EJB 기술이 쉬운 기술은 아니다.그러나 한국 IT 특성상 신기술을 따라가는 경향이 심한것 같다. EJB의 특징이나 문제점을 제대로 파악하지 않는 상태에서 EJB를 사용하는것은 오히려 득보다는 실이 많다.

RMI나 Beans 기술에 익숙하다면 이미 익숙한 기술을 사용하기 바란다. 프로젝트는 공부를 하기 위해서가 아니라, 이미 알고 있는 기술을 안정적으로 구현하는 것이 되어야 한다.


그외에도 JNI를 사용하는 구조나 Multithread 모델을 사용하는 구조, static 변수를 사용하는 구조를 EJB로 구현하는것은 해서는 안될일이다.

그리고 simple한 application을 굳이 EJB를 써서 구현할 필요는 없다. (EJB는 Deployment Descriptor도 만들어야하고, 생각보다 할일이 많다.)

결론적으로 EJB는 매우 유용한 Architecture이고 개발자가 해야할 많은 부분을 자동으로 처리해주는 안정화되고 최적화된 개발 framework이다. 그러나 EJB를 사용하기 위해서는 그에 알맞은 적절한 지식이 필요하며, 적재적소에 사용하지 않는 다면 득보다 실이 많을 수 있는 기술임을 인식하는것이 중요하다.

참고 자료 http://www.theserverside.com/articles/article.tss?l=Is-EJB-Appropriate