EJB 를 아시나요? (1)
    - 자바 백 앤드 프로그래밍의 흑역사

아마 EJB라는 걸 아는 분보다 모르는 분이 더 많을 겁니다. 요즘 자바 개발자라는 친구들도 잘 모르는 판국인데, 하물며 일반인이 알 리가 있겠습니까? 이것은 Enterprise Java Beans의 약어로, 10여년쯤 전에 유행했던 분산객체 환경을 구축할 수 있게 해주는 자바 진영의 기술 스펙 중 하나입니다. (이게 다 뭔 소리라요?) 1999년 SUN사가 J2EE 표준을 발표할 때 가장 핵심적인 기술 중 하나였습니다. 그런데… 그런데… 이제는 아무도 EJB는 하지 않습니다. 어느 프로젝트에서도 사용하지 않고요. (흑… 잘 가 EJB) ORACLE(SUN사가 ORACLE에 인수됐어요)은 계속 새로운 EJB버전을 내놓고 있지만 아무도 거들떠 보지 않고 있습니다. 한 때는 EJB를 해보지 않은 사람은 자바 개발자 취급을 해주지 않던 시절도 있었는데 말입니다. 왜 한 때 각광받던 기술이 순식간에 시장에서 사라진 걸까요? 도대체 무슨 일이 있었던 걸까요? 제 경험과 추측과 통찰(?)로 한 번 알아보려 합니다. (지극히 개인적인 통찰이므로 재미로 보시고 너무 믿진 마세요. 신뢰는 학술적 자료들의 몫으로~ )

0. 역사, 그 이전

이 이야기를 풀어나가기 위해서 우선 웹 개발 언어의 역사를 아주 간단히 짚어 보겠습니다. 인터넷이 뿅(?) 하고 나타난 이후 어떤 규약이 많이 사용됩니다. 그것은 HTTP(Hyper-Text Transfer Protocol)입니다. 물론 그 외에도 메일, FTP 등 몇 가지가 더 있습니다. 이 정도는 다들 아시죠?(^^) 이 http라는 게 뭐냐 하면 하이퍼텍스트 즉, HTML(Hyper-Text Markup Language)로 작성된 문서의 전송규약입니다. 그러니까 우리가 홈페이지에 내걸고 싶은 내용이 있으면 HTML로 작성해서 서버의 특정 영역에 놔두면, 사람들은 웹 브라우저의 주소 영역에 ‘http://어쩌구저쩌구’ 라고 입력해서 접근할 수 있다는 말입니다.

그런데 말입니다, 사람들이 이렇게 html만 작성하니까 말입니다, 재미없어 합니다. Html은 정적 리소스, 다시 말해서 한 번 만들어 두면 계속 그 내용만 보여주는 문서이기 때문입니다. 이미지 파일과 별다를 게 없는 거죠. 덕분에 동적 페이지의 필요성이 대두되게 됩니다. 예를 들면 방문자 카운트가 하나씩 증가하는 거 말입니다. (요새야 갖가지 방법이 있지만, 이때는 지금으로부터 30년쯤 전입니다. 이게 제가 제일 처음 짠 동적 페이지였습니다.) 그래서 고안한 기술이 CGI(Common Gateway Interface)입니다. 이게 뭐 하는 녀석이냐 하면, HTML을 만들어주는 C나 perl로 작성된 프로그램입니다. 즉, 우리가 특정 url을 브라우저 주소 영역에 빵하고 치면, 어떤 프로그램이 돌아서 html을 내뱉고 우리는 그 html을 보게 되는 거죠. 이른바 동적 페이지의 구성을 가능하게 해주는 기술이었습니다.

문제는 이 CGI가 접근이 쉽지만은 않은 기술이라는 점이었습니다. C(혹은 perl)로 짜야 하니깐요. 그래서 이후 웹 프로그래밍 시장에 쉬운 언어로 CGI처럼 구동시킬 수 있는 몇 가지 기술들이 출현합니다. 그들이 바로 PHP와 ASP 입니다. 그리고 이 넘들이 돌아가는 WEB 서버가 있었습니다. 아파치와 IIS가 그들입니다. 초기 동적 웹 시장은 이 PHP-아파치, ASP-IIS가 짱 먹었죠. 짜기 쉽고 … 아무튼 쉬웠기 때문입니다. 아시다시피 PHP는 리눅스/유닉스 계열에서, ASP는 MS 계열에서 맹위를 떨치게 됩니다. 이때가 90년대 말, 2000년도 초반쯤인가 그렇습니다. 인터넷이 대중화되어 보급되던 바로 그 시기입니다.

PHP와 ASP가 잘 나가는 걸 옆에서 보던 자바 진영은 밸이 꼬이기 시작했습니다. 나름 웹 시대에 맞추어 내놓았던 애플릿이라는 자기네 주력 기술이 별 힘을 못 쓴 덕이었죠. 애플릿은, 간단히 설명하자면 지금의 액티브 엑스 비슷한 겁니다. 다만 브라우저에서 윈도우 실행파일이 아닌 자바 클래스가 실행되는 것일 뿐이지요. 여러 가지 문제로 자바 진영의 애플릿 기술은 거의 사장됩니다. 대신에 ‘서블릿’이라는 새로운 기술 표준을 제시합니다. 이것은 서버 사이드 애플릿의 준말이라고 합니다. 다시 말하자면 서버에서 실행되는 애플릿이란 말이죠. 다른 동적 웹 기술과 마찬가지로 이 서블릿 역시 프로그램이 생성한 html을 클라이언트로 전송하는 겁니다. 그리고 좀 나중에 그걸 좀 더 쉽게 할 수 있도록 JSP(Java 서버 페이지)라는 기술 표준이 제공됩니다.

그런데 말입니다. (이 말을 김상중씨가 자주 쓰는 이유를 알겠네요.) 초창기에 자바 진영의 서블릿, JSP는 성능이 구렸습니다. 속도가 PHP >= ASP >>>>> JSP 이랬습니다. 이렇게 된 원인 중 하나는 자바에서 데이터베이스 연결에 대한 기반 기술이 별로 였기 때문입니다. 초창기 자바의 데이터베이스 연결에 대한 기반 기술인 JDBC의 성능은 아주 악명이 높았습니다. 그 다음에는, JVM의 성능 탓이었습니다. Html을 생성하는 자바 프로그램이 JVM이라는 녀석 위에서 돌아야 하는데, 이놈의 성능이 당시에는 그닥 이었습니다. 버전이 올라가면서 조금씩 나아지긴 했지만 그래도 나머지 두 기술에 비하면 별로 였습니다. 그도 그럴 것이 그 둘(PHP, ASP)은 이미 오랫동안 꾸준히 웹 관련 성능을 개선해왔지만, 자바는 아직 초창기였으니까요. JDBC 2.0에 이르러서야 여전히 모자라긴 했지만, 비로소 경쟁이 가능한 정도로 따라잡을 수 있었습니다. 그것이 2000년대 초반의 일입니다.

그런데 역설적으로 이 구리디 구린 DB접속 성능 때문에 자바는 새로운 기회를 잡게 됩니다. 그냥 PHP나 ASP가 하는 방식으로는 그들을 이길 수 없었던 자바 진영의 사용자들은 Connection Pool 이란 개념을 도입하기에 이릅니다. 사실, DB연결은 상당히 비싼(High Cost) 작업입니다. 그런데 기존 프로그램에서는 필요할 때 연결하고 필요 없으면 끊고 … 하는 식으로 사용했습니다. 웹 시대 이전의 client-server 구조에서 쓰던 방식이었습니다. 그런데 이 짓을 하기에는 너무도 성능이 구렸단 자바는 (흑 ㅜㅜ) 일정한 숫자의 DB연결을 미리 해놓고 사용하면서 그 연결들을 다시 돌려쓰는 방식을 웹 프로그램의 기본 아키텍쳐로 도입합니다. 일정 숫자의 연결은 해제하지 않고 계속 돌려 쓰는 거죠. 이 방식은 웹 프로그램의 성능을 드라마틱하게 향상시킵니다. PHP = JSP > ASP 이렇게 만들어 놨으니까요. 심지어 어떤 때는 구린 PHP 보다는 오히려 성능이 좋았습니다. 웹 프로그래밍 시장에서 자바는 새로운 기회를 잡게 된 겁니다. (흑흑 눙물이…)

때맞추어 자바 진영은 J2EE 스펙을 발표합니다. 이것은 Java 2 Enterprise Edition을 뜻합니다. 자세한 설명은 머리 아프니까 접고, 자바가 엔터프라이즈급, 즉 전사 레벨의 시스템을 구축할 수 있는 프로그래밍 언어가 되고자 하는 야욕을 드러냈다고 할 수 있습니다. 전사 레벨의 시스템을 구축할 수 있는 프로그래밍 언어이란, 단지 언어일 뿐 아니라 아주 다양하고 복잡한 요구사항을 소화할 수 있는 기술 스펙이라 할 수 있습니다. 이 층짜리 집을 짓기 위한 설계 개념이나 기술과, 수십, 수백 층짜리 빌딩을 짓기 위한 설계 개념이나 기술은 당연히 다릅니다. SW에서도 엔터프라이즈급 시스템을 위한 개념이나 기술이 필요하다고 보고 자바진영에서는 그러한 청사진을 제시한 겁니다. PHP나 ASP는 그런 프로젝트를 수행할 기반 기술의 세트가 아직은 없는 상태였습니다.(MS 계열에서는 이후 엔터프라이즈급 설계 개념을 내놓습니다. COM+, DCOM등이 그 중 일부입니다.) EJB는 이 지점에서 핵심적인 역할을 담당합니다. 그것은 분산객체 환경의 제공입니다.

1. 잘못된 만남, EJB와 CBD

그러면 분산객체 환경이란 무엇일까요? (원래는 객체지향에 대한 이해가 필요하지만, 그것 너무나 엄청난 이야기라서 난중에 기회가 된다면 해보겠습니다.) 간단한 예를 들어 보겠습니다. 어떤 유통 회사에 회계 모듈이 설치된 서버와 물류 모듈이 설치된 서버가 각각 따로 있을 때, 물류에서 입출고가 일어날 때마다 회계 쪽에 데이터를 전송해줘야 합니다. 이 물리적으로 다른 서버 간의 데이터 전송에 대한 기술은 또 다른 맥락으로 오랜 역사를 가지고 있습니다. 그 중 제가 아는 가장 오래된 것은 바로 EDI(Electronic Data Interchange)입니다. 그런데 이것은 주로 사외에 위치한 외부 서버와의 통신에 이용됩니다. 신뢰성을 기반으로 최소한의 데이터만 주고 받기 때문에 이런 사내 서버 사이의 통신에는 적합하지 않습니다. 그럼 실무에선 주로 무엇을 사용했느냐. 여러 방법이 있었지만 DB를 통해 인터페이스하는 것을 제일 무난하게 여겼습니다. 비용이 싸고 특별한 기술이 필요 없으며 안정적이었으니까요. 그런데 SW설계 측면에서 이런 방법은 그렇게 환영 받지 못하는 방법이었습니다. DB에서 시작해서 DB로 끝나는 시스템, 이른 바 DB중심의 시스템이 되기 때문입니다. 시스템에서 프로그래밍은 별로 중요해지지 않고 DB가 가장 중요해 집니다. 객체 지향 언어를 표방한 자바에게 이런 DB중심의 설계는 설계 사상 측면에서 적합하다고 할 수 없었습니다. 그래서 분산객체라는 개념이 중요해집니다. 원격의 객체를 call하는 방식이니까요.

그러면 이것을 도입한 사람들은 이런 개념을 이해하고 필요해서 도입한 걸까요? 아닙니다. 그들에게 ‘객체 지향’이란 사실 그렇게 중요하게 여겨지는 가치가 아니었습니다. 보통 시스템을 도입할 때 가장 중요시 여기는 사항은 이러한 설계 개념들이 아닌 성능, 안정성, 유지보수의 용이성 등입니다. 다시 말해서 시스템을 구축해 주겠다는 사업자들은 그들의 고객에게 ‘탁월한 성능’의 ‘안정적’이면서 유지보수가 ‘쉬운’ 시스템을 주겠다고 단언합니다. 덧붙여 ‘싸고’, ‘빠르게’요.

이것이 가능하지 않다라는 사실은 약간의 경력이 있는 SI 개발자라면 누구나 알고 있습니다. 아마 고객들도 이미 알고 있었는지도 모릅니다. 다만 그들은 의도했던 아니던 간에 속아 넘어가 줘야 합니다. 속아 넘어가 주기 위해서는 몇 가지 번드르르한 문구가 필요합니다. 분산객체 환경으로서 EJB는 그 번드르르한 문구 중 하나였습니다. 게다가 그것이 CBD와 결합하면서 더욱 번들번들하게 됐습니다. 이른 바 EJB-CBD 커넥션입니다.

CBD란, 컴포넌트 기반 개발(Component Based Development) 방법론을 말합니다. 이 말이 의미하는 바는 프로그램을 컴포넌트로 개발하여 조립하겠다는 말입니다. 이 단어를 들으면 프로그래밍을 모르는 사람들은 두 가지 반응을 보입니다. “아, 그렇구나 좋은 방법인가 보다,” 와 “응? 그럼 지금까지는 어떻게 만들었다는 거야?” 입니다. 여기서 SW에서 말하는 컴포넌트의 의미에 대한 이해가 필요합니다. 컴포넌트란, 어떤 프로그램 모듈이 내부적으로 요청에 대한 처리를 어떻게 하는 지 전면적으로 드러내지 않고 오직 제한된 방법으로만 요청에 대한 결과를 알려주는 프로그램 단위입니다. 이런 것을 블랙박스 타입이라 합니다. 블랙박스 타입의 컴포넌트를 사용하는 사람 역시 컴포넌트 내부적으로 어떻게 구동되는 지 굳이 알 필요가 없으며 알려 하지도 않습니다. 오직 인터페이스라 불리우는 제한된 방법을 통해 접근/통신/구동합니다. 그리고 이 컴포넌트들을 조합하여 어플리케이션을 만드는 방식입니다.

일견 당연한 방식인 듯 보이지만 그렇지 않습니다. 대부분의 프로그램, 특히 웹프로그램은 절차적으로(procedural) 작성됩니다. PHP, ASP 모두 이 절차적 프로그래밍의 방법을 사용합니다. 이 절차적이라는 의미는 그냥 데이터가 흐르는 방법대로, 프로세스가 흐르는 대로 프로그램을 작성하는 방법입니다. 이렇게 프로그램을 작성하다 보면 재사용성이 현저히 떨어집니다. 내가 어디선가 작성했던 로직을 다시 사용하는 게 쉽지 않다는 겁니다. “뭐 어려워, 카피해서 쓰면 되지.” 맞습니다. 일반적으로 카피해서 다시 사용하는 게 일반적입니다. 그런데 카피해서 사용한 로직의 일부를 변경해야만 한다면 어떨까요? 그 로직이 사용된 모든 부분을 찾아서 변경해야겠죠. 많은 프로그램 기능이 수정될 테고, 그 말은 테스트되어야 하는 기능도 많아 진다는 이야기입니다. 개발자들이 지옥이라 생각하는 상황이 펼쳐집니다. 그래서 되도록이면 이 재사용성이라는 걸 높이는 쪽으로 작성하려 합니다. 그 끝판왕이 바로 CBD라 할 수 있습니다.

이 말은 CBD 방법론 하에서는 프로그램을 절차적으로만 작성해서는 안 된다는 것을 의미합니다. 중요한 것은 컴포넌트의 설계였습니다. 재사용성이라는 것이 단순히 인터페이스만을 제공한다고 해서 획득되어질 수 있는 성질은 아닙니다. 그 목적에 맞게 컴포넌트를 설계해야 할 필요가 있습니다. 어떤 기능을 컴포넌트로 설계할 것인지를 정한 후에, 그 기능을 컴포넌트로 만들려면 어떻게 구현해야 할 지 상당히 구체적으로 설계해야 합니다. 여기서 CBD의 최대 약점이 나옵니다. 설계나 구현이 그리 쉽지 않다는 점입니다.

절차적 프로그래밍이 무조건 나쁘기만 하느냐? 당연하게도 그렇다고 할 수 없습니다. 비록 재사용성은 현저히 떨어진다고 말할 수 있지만 그것의 가장 큰 장점은 쉽다는 점입니다. 프로그램에서 해야 하는 일들을 차근차근 순차적으로 처리해 가면 되기 때문에 작성하는 게 크게 어렵지 않습니다. 다시 말하자면 배우기가 쉽다는 말입니다. 이른 바 러닝 커브(Learning Curve)가 작습니다.

이것은 SW 개발에서 대형 SI 프로젝트 개발과 일반적인 SW개발을 가르는 중요한 구분점이 되기도 합니다. SI 개발(특히 대형)에서는 여러 가지 측면에서 러닝 커브가 중요한 고려 요소입니다. (실상은 거의 고려를 안 하지만) 우선 SI 프로젝트의 경우, 프로젝트 구성원이 갖고 있는 기반 지식의 종류와 정도에 있어 그 다양함이 거의 지옥 급입니다. 생각해 보십시오. 대형 SI 프로젝트에서는 이름도 몰라 성도 몰라 하는 사람들이 어떤 특정 시스템을 개발하기 위해 구름 같이 모인 겁니다. 물론 참여하기 위해서는 사전에 기술 면접을 통과해야 하긴 합니다. 그러나 대부분의 기술 면접이 요식행위로 진행되는 경우가 많습니다. 이전에 그 기술을 경험해봤느냐가 질문의 대부분인 경우가 많습니다. 어떻게, 얼마나 경험했는가는 기대도 안 하고 고려도 안 합니다. 반면 제가 단기간이 아닌 장기간에 걸쳐 SW개발을 진행하는 팀을 꾸린다 치면, 구성원들의 기술 종류뿐 아니라 기술 수준과 이해도 역시 중요하게 여기게 됩니다. 만일 기술 수준과 이해도가 역할에 맞지 않은 멤버가 있다면 충분한 교육 등을 통해 필요한 수준까지 올리려 할 것입니다. 그렇다면 SI에서는? 그럴 시간이나 여유가 없습니다. 프로젝트의 마감은 언제나 촉박하니까요. SI에 있어서는 얼마나 짧은 시간에 얼마나 많은 화면을 찍어내는가가 중요합니다. 설계나 품질 등의 질적 요소는 대부분의 경우 세 번째, 혹은 네 번째 고려 사항입니다.

삼천포로 빠져 버린 이야기를 건져 올려, 다시 CBD로 돌아오겠습니다. 그런데 EJB는 CBD로 프로젝트를 수행하는데 있어 몇 가지 유리한 지점을 제공해 줍니다. 분산객체 환경의 구성이라는 목적 때문에 EJB에서는 ‘반드시’ 인터페이스를 정의해야만 했고 그런 면에서 자연스럽게 컴포넌트처럼 프로그램을 작성하게끔 해줍니다. 그래서 EJB는 자바로 CBD로 프로젝트를 수행하는데 있어 가장 필요한 기술적 요소가 됩니다. 비즈니스 모듈을 EJB로 작성하면 CBD로 프로그램을 작성하게 된 것이라 생각하게 되는 인식이 일반화됩니다. 아마도 어디선가 그러한 성공사례가 있었던 듯싶습니다. 아시다시피 어떤 경우에는 성공사례가 이후의 많은 경우(case)들을 망치는 계기가 되기도 합니다.

SI에서 방법론으로 CBD를 채택했을 때 문제는 무엇일까요? 수많은 문제점들이 있겠지만 그 중 하나는 구성원들이 대부분 그 사상이나 방법을 구체적으로 이해하지 못하고 프로젝트를 수행하게 된다는 점입니다. 대부분 절차적 프로그래밍에 익숙한 구성원들에게 CBD나 객체지향에 대한 전환 교육도 제대로 하지 않고 프로젝트를 수행하게 합니다. 그 이후의 일은 … 굳이 설명하지 않겠습니다. 그냥 EJB로 프로그램을 작성하라고만 합니다. 그러면 컴포넌트가 된다고. 하지만 이것은 사실이 아닙니다. 절차적 프로그래밍에 익숙한 인력들이 EJB로 프로그램을 구성한다고 해서 그것이 컴포넌트가 될 수 있다면 이 세상엔 어려운 일이 별로 없을 겁니다. ㅜㅜ

다시 처음으로 돌아가 도대체 왜 CBD를 수행하려 했는가를 생각해 봅시다. 목적은 재사용성입니다. 더 나아가 재사용성을 왜 담보하려 했는가를 생각해 봅시다. 그것은 유지보수의 용이함입니다. 컴포넌트를 재사용하려 한 이유는 이후 시스템의 유지보수에 있어 보다 쉽게 수행할 수 있을 것이라 예상했기 때문입니다. 그런데 사실 EJB에 있어 유지보수는 최악입니다. 기능을 추가하거나 수정했을 때 절차적으로 프로그램을 작성하는 경우, 추가하거나 수정해야 하는 파일이 3~4개라면 EJB의 경우 많게는 십 수개의 파일을 수정하거나 추가해야 합니다. 이건 솔직히 미친 짓이지요. 제가 처음 EJB로 프로그램을 짰을 때가 기억납니다. 느낀 점이 “우와 겁나 최신 기술을 써서 너무 기쁘고 멋져요!”가 아니라 “아… 이게 무슨 병신 짓인가?”였습니다. 그때 당시에는 1도 이해할 수 없었습니다. 아무도 그 이유를 설명해 주지 않았고, 어쩌면 아무도 알고 싶어하지 않았을 수도 있습니다. 뭐 좋습니다. 컴포넌트를 재사용할 수 있으면야 파일을 수백 개 고쳐야 한들 뭐가 문제겠습니까만, 그것도 쉬운 문제가 아닙니다. 앞서 말했듯이 컴포넌트의 품질을 담보하는 것이 쉽지 않기 때문입니다. SI 프로젝트에서 그런 작업은 거의 불가능에 가깝습니다. 물론 QA 롤과 조직이 있기도 하지만, 결국 막판에는 오픈에 집중해야 하기 때문에 재사용성 따윈 개에게나 줘 버립니다. 프로그램은 돌아만 가면 되고 시스템은 다운만 안되면 됩니다. 재사용성은 그 누구의 관심도 끌지 못합니다. 저주받은 EJB-CBD 시스템이 탄생하게 됩니다.

(2편으로 계속)