요새 틈틈히프로젝트 제로(Zero)로 간단한 코딩을 하고 있습니다. 제로 프로젝트는 경량의 미들웨어이자 웹기반 개발환경입니다. 개발 언어는 PHP, 그루비, Java를 지원하고 런타임이 약 40M밖에 되지 않는데다가 Request가 있을 경우에만 그 런타임이 동작하고 request가 없으면 런타임은 사라지고 약 100k 정도의 메모리를 차지하는 리스너만 동작하여 더이상 작아질래야 작아질 수 없을만큼 경량화되면서도 웹애플리케이션을 개발하기 위한 대부분의 것들을 모두 포함하는 미들웨어입니다.

게다가 가장 많이 쓰이는 PHP와 자바 그리고 그루비같은 스크립트 언어등을 지원하다보니 개발하는 것도 쉽고 재밌기까지 합니다.

이렇게 제로 프로젝트로 놀다보니 떠오르는 생각은,

어째서 미들웨어는 그토록 무거워지고 복잡해져버렸을까? 무슨 업보라도 지고 있듯 언젠가는 필요하리라 생각하는 그 모든 것들을 짊어지고 있는 근래의 자바 미들웨어들을 보고 있으면 곧 무너질 바벨탑처럼, 혹은 스타워즈의 제국군이나 데스스타처럼 위태위태해보입니다.

혹자는 말합니다. 우리가 비즈니스적으로 개발하려던 핵심 말고는 다른 모든 것을 알아서 해주기 위해 그런 라이브러리나 프레임워크가 필요하고 어차피 컨테이너가 알아서 해주니 개발과는 상관없지 않느냐고, 모든 것을 서비스로 만들어주면 어차피 밑의 부분은 신경 안쓰고 살 수 있다는 이상적인 이야기들.

수없이 많은 레이어들 그 위에 만들어진 애플리케이션, 과연 우리의 애플리케이션중 얼마나 많은 것들이 그 수많은 레이어에 부끄럽지 않을 정도의 고급 기능을 사용하고 있을까요?

프로젝트 제로를 접하면서, 기존의 미들웨어들의 큰 덩치에 의문을 품은 아침이었습니다.

---

댓글

가짜집시 · 2009/08/28 11:18

범인은 J2EE아닐까요?

Yozz · 2009/08/28 11:35

예. 주범이죠. 하지만 아키텍처적으로 어떤 근본적인 흐름 자체가 문제가 아니었을까 생각합니다.

** · 2009/08/28 11:24

써니 · 2009/08/28 11:28

저는 EJB가 싫어서, RMI로 직접 만들어서 썼습니다. 그런데 막상 해보면 오히려 개발 기간과 투입 인력이 줄더라구요.

EJB가 필요 없는 건 아닌데, 닭 잡는데 소 잡는 칼 쓰면 번거로와요. 소 잡는 칼로 닭 잡으려면, 칼을 고정하고 닭을 내리쳐야 하거든요… ^^;

가짜집시 님 말씀에 슬쩍 공감…

가짜집시 · 2009/08/28 12:11

자바의 딜레마- 같은게, “무거운 것을 가볍게 만들기 위해서는 더욱 복잡해져야 한다” 가 아닐까 싶습니다. 써니님이 말씀하신 EJB VS RMI 같은 경우도 좋은 예가 되겠네요. 대부분의 경우 복잡한 시스템이라도 쓰는 기능이 많지 않으면 가볍게 동작해야 하는데, Java는 계속 그런 개념들을 지원하는데 약했습니다. 임의로 클래스나 jar를 load/unload 하는 매커니즘이 언어적으로 간단히 지원되었더라면 (물론 덕분에 runtime error 를 엄청나게 양산한다고 하더라도) 어땠을까, 라는 생각도 듭니다.

Yozz · 2009/08/28 12:33

저는 자바가 아니라 어떠한 개발 언어가 엔터프라이즈에 쓰였더라도 그 무거움은 달라지지 않았을 것이라고 생각합니다. 쓰는 사람의 문제라고 생각합니다. 비즈니스 로직 개발 이외의 부분을 자꾸 레이어를 두고 추상화를 하는 트렌드가 결국 엔터프라이즈 자바를 무겁게 한 것이 아닐까요? 비즈니스 애플리케이션 하부에 여러 레이어를 만들어서 계층화시키는 것이 아니라 아예 다른 영역으로 독립시키는 방법의 아키텍처였다면 어떠했을까요?