** 본 글은 EJB기술을 폄하하기 위해서 작성한 글이 절대 아님을 밝혀 둡니다. 
엔터프라이즈 기술을 발전시키고 있는 수많은 훌륭한 개발자/연구원들에게 존경을 표합니다.

POJO의 등장

POJO란 Plain Old Java Object의 줄임말입니다. 꽤 오래된 단어죠. 최근 자바의 엔터프라이즈 기술을 필연적으로 사용할수 밖에없는 분야에 발을 들여놨기때문에 다시 보게 되었는데 느끼는게 참 많은 개념입니다. 그 등장과 발전되는 양상이 시사해주는 점들은 특별한 의미를 가지고 있습니다.

POJO의 등장은 다음과 같습니다. Refactoring의 저자이며, 식견있고 훌륭한 오피니언 리더로서 이름나 있는 마틴 파울러(Martin Fowler)가 2000년도에 한 컨퍼런스에서 다음과 같이 말을 하면서 POJO는 세상에 나타났습니다.

“We wondered why people were so against using reqular objects in their systems and concluded that it was because simple objects lacked a fancy name. So we gave them one, and it is caught on very nicely”

이 말을 의미는 아마도 그 철학적인 완전성을 위해 마구 비대해지고 있던 J2EE에 대한 일침이었습니다. 즉, EJB보다는 단순하고 원시적인 Java Object에 해당 도메인 로직을 넣어 사용하는것이 더 좋다. 어째서 사람들은 EJB가 아닌 평범한 Java Object를 사용하지 않는가? 아무래도 그건 단순한 Java Object에는 멋진 이름이 없기 때문이다. 개발자들은 기술에 있어서 멋들어진 이름 또한 중요하기 때문이죠. 새로운 기술이 었기 때문에 뒤쳐지지 않기 위해서 앞뒤양옆을 보지 못하고 더 첨예하고 완성도 높은 기술만을 바라보면서 달려 나왔습니다. 마틴 파울러는 멋져보이는 이름을 다시 원시 Java Object에 붙임으로써 사람들이 객체지향에 대한 반성을 다시 할수 있게 해주었습니다.  – (아주 단순하면서도 이렇게 멋진 발표는 역사상 별로 없을것만 같습니다.)

EJB와 POJO

POJO가 등장하게 된 기술적인 배경을 조금 더 보자면 아주 논리 정연하고 소프트웨어 진화에 대한 한 단면을 볼수 있습니다. 아주 훌륭한 모범예제라고 할수 있죠. 먼저 EJB가 먼저 오래도록 사랑(?) 받아온 이유를 돌아보자면 다음과 같습니다. EJB는 J2EE의 살아있는 화신이라고 할 만큼 자바의 엔터프라이즈 기술을 선도해 왔습니다. EJB의 장점은 엔터프라이즈 애플리케이션에서 필연적으로 요구하는 다양한 기능들을 거의 빠짐없이 제공한다는 것입니다. 특히, 더 멋진 점은 애플리케이션에서 분리해서 서비스 형태로 제공하는 점입니다. (요즘은 안 그런 기술이 없습니다만, 이 당시는 EJB의 자태가 독보적이고 참 아름다웠다고들 합니다.) EJB는 응용 서비스에 대한 컨테이너 기능 및 데이터베이스와 연산 리소스들을 관리하는 기능 등을 제공해주었고 ‘개발자들이 여러가지 환경적인 문제들 보다는 비지니스 로직 자체에 대해 집중하여 개발할수 있다’는 것을 실현시켜주었습니다.

엔터프라이즈 기술에서 종합선물세트와 같은 거대한 능력을 가진 EJB는 아주 불행한 실수를 저지르고 말았습니다.

- EJB는 극소수의 애플리케이션에서만 필요로하는 다중 데이터베이스를 위한 글로벌 분산 트랜잭션(JTA)과 같은 복잡하고 무거운 기능을 강요하는 경향이 있습니다.

- 보통의 중소형 프로젝트에서 사용하기에는 단가가 너무 쎈 WAS를 요구합니다. (요즘에는 활발히 발전하고있는 Geronimo를 쓰면 되긴 하죠. 글을 작성하고 있는 지금에도 Dev-Mailing List로 JIRA Comment가 마구 쏟아져 들어옵니다.)

- 제일 문제라고 생각하는 것은 훌륭한 IDE없이는 (사실 요즘에는 이클립스 플러그인들이 너무 훌륭해서요.. 괜찮긴 합니다만,.. ) 엄청나게 복잡한 설정 파일속에서 개발자들의 정신이 아찔해진다는 점입니다. 저는 표준적인 스펙과 다양한 팁이 있는 훌륭한 문서들을 가지고 있지만 직접 작성할라면 한 세월 걸립니다. (사실 저는 XML 다루는데 재주가 없습니다.)
자동화된 툴들이 해주는 일가지고 왜 바보같이 하고 앉았냐? 라고 하실수 있지만 제 개발 철학상 손으로 다 하진 않더라도 머리속에는 다 그려야 합니다. 조금 더 복잡해지면 전 더이상 개발을 할수 없는 시대의 탈락자가 될지 모르죠.^^

- EJB로 제작된 컴포넌트는 컨테이너 밖에서는 정상적으로 동작하지 않습니다. 앞서 말한것과 이어지는 맥락입니다. 아주 간소화한 컨테이너 환경을 작성해서 수행해도 되지만, 결국 개발중에 만나는 수정-빌드-배포-테스트의 되풀이 속에서 우리는 제정신을 유지 하기 힘들거나, 도를 깨우치게 됩니다.

결국 EJB는 엔터프라이즈 응용 개발자들에게 완벽한 환경을 제공해주며 “비지니스 로직”에만 집중할수 있게 해주겠다!라는 야심찬 포부와 함께 등장했지만 너무 무거워져 버렸습니다. 다양한 요구들이 섬세한 고찰 없이 합해져왔기 때문입니다.

무분별한 기술적 완성도를 추구하는 가운데 EJB는 객체지향이라는 근본도 잃어버린 모습을 갖추게 되었습니다. 결국 마틴 파울러와 레베카 파슨과 같은 Opinion Leader들이 EJB의 발전에 대해 반성하고  객체지향 원리에 따라 기본에 충실하게 비지니스 로직을 구현하는 POJO방식으로 회귀하자고 주장하면서 다시 훌륭한 진화의 길로 접어들게 되었습니다.

오늘 이런 오래된 내용을 포스팅 한데에는 두 가지 이유가 있습니다. 첫째로, 소프트웨어 (비록 모든 소프트웨어 개발분야에 적용할순 없을지라도) 개발에 대한 진화의 정말 멋진 예라고 생각되었기 때문입니다. 사실 Computer Science/Engineering 에 국한되지 않고 그저 발전방향/진화양상 이라는 면만봐도 꽤 멋집니다.

둘째로는, 많은 사람들이 EJB와 SPRING을 Versus관계로 보는 경향이 있어서 한번 쯤 이런 내용을 정리하고 가고싶었기 때문입니다. 사실 EJB vs SPRING으로 비교하는것이 아니라 EJB 와 POJO를 비교한 후에 POJO를 효과적으로 지원하는 Framework로서의 SPRING을 바라봐야 한다고 생각합니다.
EJB가 가진 기능을 SPRING에서 많이 커버해주기 때문에, ’EJB가 더 낫다. SPRING이 더 낫다.’ 라는 분쟁이 넷상에 꽤 많은데 제가 생각하기에 좀 더 본질적인것은 EJB에 대한 고민과 POJO의 등장이 보여준다고 생각합니다.

혹시 어떻게 지나가시다가 들리셨는데 2010년에 이런 글을 썻다고, 기분이 얹짢아 질수도 있는 컴퓨터 공학도 및 개발자 분들을 위해 PS를 넣자면,

P.S : 사실 EJB 3 부터는 많은 부분이 수정 보완되었고 훌륭한 개념도 많이 추가되었습니다. 일례로 엔티티 빈 대신에 JPA를 이용한  데이터 영속성 처리등이 있습니다. 앞으로 다양한 프레임워크(struts, SPRING, iBatis, Hibernate)들과 비지니스 툴(BPEL2J)등을 정리할 것인데 그전에 단편적으로 제 생각을 조금 끄적여 본것뿐입니다 ^^. 물론 EJB 3.1 에 대해서도 객관적으로 정리해서 포스팅 할 생각입니다.