* 1편을 올린 지 너무 오래 됐네요. 그동안 많은 일들이 있어 2편이 늦어 졌습니다. 죄송함돠. ㅜㅜ
다음 번엔 꼭 다 쓰고 올려야겠습니다.  

EJB 를 아시나요? (1)  

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


2. 고객들의 착각 혹은 묵인

이 무렵이 2000년대 초반쯤일 겁니다. 너도나도 SI 프로젝트에 EJB-CBD를 도입해 댑니다. 기존 CS 기반의 레거시 시스템을 웹 기반으로 전환하는 것이 당시 SI의 트랜드였는데, 다른 웹 기반 기술들은 아직 엔터프라이즈 레벨의 설계 개념을 채 완비하지 못한 상태였습니다. (MS에서 닷넷 기반의 설계 개념이 나온 건 몇 년 후였습니다.) 그런데 이 설계 개념이 시스템 구축에 잘 적용되어 순조롭게 프로젝트가 진행됐다면야 뭐가 문제이겠습니까? 불행히도 태생적으로 EJB나 CBD의 개념은 SI, 특히 이 나라의 SI 프로젝트에 그렇게 잘 어울리는 개념이라 할 수 없었습니다.

사실 고객 입장에서는 최신 기술로 구축된 시스템을 주겠다는데 마다할 리 없었죠. 지금 생각해보면 그때 고객들이 품었던 환상은 두 가지였을 것으로 짐작됩니다. 하나는 최신 기술 트랜드에 대한 환상, 다른 하나는 앞으로 자신이 유지보수 하는데 있어 무지하게 쉽게 될 것이란 환상. EJB가 첫 번째는 만족시킬 수 있을 지 모르나, 두 번째 것은 특히나 만족시키기 힘들었습니다. 그 당시 SI 사업자들의 제안서를 보면 정말 사업만 주면 정말 손에 물 한 방울 안 묻히게 해주께 입니다. 아시겠지만, 이런 류의 약속은 열에 열, 백에 백, 천에 999 의례적인 말입니다. 제안서는 많은 부분이 그럴듯한 말로 채워지기 마련이니 이걸 같고 뭐라 말할 만한 것도 못됩니다. 하지만 그 프로젝트를 수행해야 하는 사람들은 그 제안서대로 시스템을 구축해야 했던 게 문제였던 겁니다. 아니, 시스템을 구축해야 하는 사람은 적어도 그 비슷하게 흉내라도 내야만 했습니다.

그렇습니다. 불행하게도 대부분 흉내로 채워졌습니다. 흉내로 인식했던, 아니던 간에 그건 흉내 차원을 벗어나지 못했습니다. 그것이 왜 흉내냐, 스펙에 맞춰 제대로 구현한 것인데 흉내라니 너무 심한 거 아니냐라는 반론이 있을 수도 있습니다. 분명 시스템의 설계 자체를 흉내라 말할 수는 없습니다. 당시 SUN사가 제시한 EJB 스펙에 맞추어 제대로 설계한 프로젝트도 적지 않았으니까요. 다만 문제는 그것이 SI 프로젝트에 적용되었다는 게 문제였습니다. SI가 아닌 인바운드 소프트웨어 개발, 즉 사내에서 자체의 인력으로 수행하는 SW 개발에서는 EJB-CBD의 성공 사례가 없지는 않을 겁니다. 하지만 SI 프로젝트는 일반적인 SW 개발과 조금 다른 특성이 있다는 사실을 프로젝트의 수행주체들은 간과했습니다. 그것이 의도적인지 아닌지는 알 수 없지만요.

단지 ‘그 당시는 그랬다’고 그냥 넘어갈 수는 없는 노릇입니다. SI 프로젝트의 불합리함이야, 그때도 그랬고 그전에도 그랬고 지금까지도 별로 크게 달라지지는 않았으니까요. 적어도 EJB-CBD 설계 개념의 도입이 누구의 획책이었는 지에 대한 추측이라도 해봐야 속이 좀 풀릴 듯 합니다. 그 추측을 위해 조금은 결과주의적이긴 하지만, 누가 EJB-CBD의 도입으로 이익을 보았는지 생각해 보려 합니다.

아마도 추측이지만, 가장 큰 이득을 본 사람들은 주로 외국계 회사인 SW/HW 벤더사들일 겁니다. 이들은 많은 하드웨어와 소프트웨어를 팔아먹었습니다. 서버와 스토리지뿐 아니라 WAS에서 DB, 각종 개발 솔루션에서부터 서드파티툴까지… 이 무렵 외국계 벤더사들은 한국에서 꽤 많은 이득을 올렸습니다. 웬만한 벤더사의 영업사원들은 인센티브를 톡톡히 챙겼습니다. 아는 영업사원 하나는 부상으로 그 회사의 본사 회장과 같이 헬기 타고 골프 치러 갔다고 합니다. 국제적으로도 한국 시장에서 얻은 수익은 작은 편이 아니었습니다. 2000년대 초중반에 외국계 SW/HW 벤더사의 대표격인 한국 I*M사가 상당한 영업이익을 챙겼다는 건 아는 사람은 다 아는 사실입니다. 유일한 국산 WAS 제조사였던 티*스는 WAS 시장의 점유율을 바탕으로 M$에 도전하여 윈도우 호환 OS를 만들겠다고 큰소리까지 쳤습니다.

기업들이 이익을 취하겠다는데 그것을 뭐라 할 수만은 없는 노릇입니다. 그러나 그것이 잘못된 아키텍쳐의 적용을 통해서라면 문제가 없다고 만은 할 수 없어 보입니다. 그들은 이렇게 개발된 시스템이 대략 어느 정도의 성능을 발휘할 지는 이미 대략적으로 알고 있었습니다. 그러나 이 문제를 해결하기 위한 방안으로 그들은 고객에게 아키텍쳐의 수정이 아니라 비싼 하드웨어와 소프트웨어를 제시합니다. 이것은 또다른 부작용을 불러일으킵니다. 프로젝트에 할당된 예산은 이미 한정되어 있는데 하드웨어/소프트웨어 구매로 비중이 쏠리게 된 겁니다. 당연히 개발 인력을 투입하기 위한 비용은 줄어들게 되고, 그것은 인력 부족과 무리한 일정으로 연결됩니다. 거기다가 방법론과 설계는 교육과 감사 등 일정이 더 필요한 CBD에다가 역시 일정이 더 필요한 EJB이니 프로젝트가 헬이 되는 건 시간 문제였던 겁니다.

이 무렵부터 갑자기 SI프로젝트의 주기가 짧아지기 시작했습니다. 그래도 예전에는 6개월 이상 주던 구현 기간을 3개월 정도로하자, 이런 식으로 줄이는 겁니다. 그에 따라 전체 프로젝트 일정도 당연히 줄어들고요. 이때 대형 SI 프로젝트가 초단기로 많이 수행되었습니다. 사람들(고객과 주사업자)의 마인드가 어땠는가 하면, 어차피 M/M(Man/Month) 단위로 작업을 하는 것이니 기간을 줄이고 투입하는 인력을 늘리면 되는 거 아냐? 이런 식이었습니다. 예를 들면 이전에는 10명이서 1년 하던 작업입니다. 그러면 120M/M으로 산정이 되는 거죠. 그럼 120M/M만 투입하면 되네? 하고 20명을 투입해 6개월에 끝내자 라고 합니다. 나중에는 40명, 아니 50명을 투입할 테니, 3개월에 시마이하자! 라고까지 합니다.

그것이 비록 절차적 프로그래밍으로 이루어진 SI 개발이라 하더라도 그들이 SW개발을 어떻게 바라보고 있는 지를 드러내는 대목입니다. 다들 눈치 채셨겠지만, SW개발에 있어 시간은 자원을 마구잡이로 투입한다고 해서 무한정 줄일 수 있는 요소가 아닙니다. 그 이유는 대부분의 일들이 사람이 하는 일이라 그렇습니다. 대상도 수행도 관리도 모두 사람이 하는 일입니다. 사람을 더 많이 투입하면 당연히 사람에 대한 관리 비용도 같이 올라갑니다. 다시 말해서 10명을 관리할 때 2명의 관리자가 필요했다면 20명을 관리할 때는 4명의 관리자로는 충분하지 않다는 겁니다. 당연하게도 사람이 늘어날수록 조직 내 커뮤니케이션 비용은 기하급수적으로 증가합니다. 프로젝트의 수행 주체의 기대와는 달리, 두 배의 리소스를 투입한다면 비용은 두 배 이상이 발생하지만 아웃풋은 두배가 나올 수 없는 구조입니다. 사업 수행 주체들도 바보가 아니었기에 아마도 이런 사실 역시 알고 있었을 겁니다. 하지만 그들 중 많은 이들은 의도적이던, 의도적이지 않던 아무튼 이 사실을 무시했습니다. 어떤 면에서는 무시해야만 했습니다. 그들이 추구해야 하는 것은 최고의 소프트웨어가 아닌 납기 내 요구사항 구현이었으니까요.

어찌 보면 그때를 대한민국 SI 산업의 전성기였다고 말할 수 있습니다. 공공, 금융, 통신, 물류, 이커머스 등 각 분야에서 엄청나게 많은 수의 프로젝트들이 발주되었으니까요. 프로젝트의 수행주기가 짧아진 이유에는 보다 많은 수의 프로젝트를 수행하고자 했던 수행사의 욕심도 있었습니다. SI 회사들은 한정된 인력으로 많은 수의 프로젝트를 수행해야 했습니다. 당연히 프로젝트를 길게 가는 것보다 짧게 가는 게 이득인 게 사실이었습니다. 발주한 측에서도 빨리 끝내 준다는 데 마다할 이유가 없었습니다. 하지만 이들이 간과한 것은 자신들이 해야 하는 일이 어떤 것이냐에 대한 고려였습니다. 그들은 그들이 수행해야 하는 것 중에 최소한의 것만 합니다. 그리고 그 최소한을 채웠을 때 그 프로젝트를 성공했다고 합니다. 사실 그 이상을 할 여력도 마음도 의무도 책임도 없었습니다. 당연히 그 사업의 산출물이 훌륭할 리 없습니다. 그럼에도 불구하고 계속 프로그램 개발을 외주로 맡기는 이유는 인식의 문제입니다. 프로그램이라는 것을 어떤 것으로 보는가의 차이 말입니다.
프로그램을 외부인력으로 만들 수 있다고 생각하는 것은 시스템을 마치 건물처럼 생각하기 때문입니다. 아시다시피 SI산업은 건설업을 벤치마킹한 면이 많습니다. 그러나 『실용주의 프로그래머』이란 책에서는 프로그래밍은 건설보다 원예를 닮았다고 말합니다. 이 말은 프로그램이 빌딩처럼 한 번에 빵하고 건설하는 것이 아니라 정원의 나무처럼 점차 키워 나가고 계속 가꾸어 나가야 한다는 말입니다. 이러한 인식이 전체된다면 외주를 통한 프로그램 개발은 당연히 지양될 수밖에 없습니다. 외주를 통해 시스템을 구축하는 것은 건설사가 빌딩을 지어 납품하는 것과 똑같은 방식입니다. 이런 환경에서 프로그램을 마치 나무를 키우고 가꾸어 나가는 정원사의 마음으로 대할 수는 없을 것입니다. 벽돌을 올리고 공구리치는 노가다의 마음으로 대할 수는 있어도요. 이것은 단지 환경의 문제를 넘어선 인식의 차이 문제입니다. 이 인식의 차이는 프로그램을 개발하는 이가 자신이 개발하는 프로그램을 어떠한 태도로 대해야 하는가를 결정하는데 영향을 미치게 됩니다.

3. 겨울, 그리고 봄(Spring)

이 때 개발된 EJB 시스템은 이후 많은 수가 개비되거나 재개발됩니다. 물론 대부분의 경우 다시 개발하는 표면 상의 이유가 EJB 아키텍쳐의 문제점 때문은 아니었지만요. 그 어느 누가 설계가 잘못되어 다시 개발해야 된다고 말할 수 있겠습니까? 그들도 구축 프로젝트에 발을 담궜던 사람들이고, 계속 직장을 다녀야 하는 사람들이니까요. 이렇게 EJB-CBD 설계는 급격히 자바 SI시장에서 퇴출되고 맙니다. 그 자리를 대신 차지한 것은 경량 컨테이너를 추구했던 Spring 프레임워크입니다. 2000년대 후반부터 사용되기 시작한 Spring은 이제 자바 SI 시장에서 거의 표준으로 자리잡았습니다. 경량 프레임워크답게 이전에 비해 날씬해진 스프링은 JDK의 업그레이드와 맞물려 자바 웹어플리케이션의 설계 형태를 최적으로 잡아갑니다. 공식적인 것은 아니지만, 스프링이라는 이름은 엄혹한 EJB의 겨울을 끝내는 프레임워크라는 의미로 붙여진 것이라는 설도 있습니다.

스프링 기반의 자바 웹어플리케이션은 여러 가지 측면에서 많이 최적화되어 있습니다. AOP나 MVC, Security, Log, Exception 등 많이 인프라 스트럭쳐를 프레임워크 레벨에서 처리할 수 있도록 마련되어 있습니다. 이것도 사실 단 시일 내 이루어 진 것은 아닙니다. 그간 수많은 프로젝트에서 수많은 시행착오를 거쳐 끊임없이 최적의 설계 형태를 찾아온 것이라 해야 할 겁니다. 많은 개발자들의 땀이 서려 있는 결과죠. 덕분에 자금의 자바 SI 시장의 설계방법은 많이 안정되어 있습니다. 설계, 구축, 테스트, 프로젝트 관리 등에 있어서 어느 정도 제법 안정된 모습을 갖추게 되었습니다.

하지만 계속 SI산업 위주로 SW 개발 업계가 돌아가는 것이 적절한 방향일까요? 한국의 SW개발이 SI에 일정부분 의존하고 있는 게 사실입니다. 다행히 점차 그 비율이 줄어들고 있는 추세인 것은 확실합니다. 물론 앞으로도 외주 개발이 아주 사라질 수는 없을 겁니다. 그래도 점차 줄어드는 것은 어쩔 수 없는 추세입니다. 없어질 수는 없지만 줄어들긴 해야 합니다. 계속 SI가 SW업계를 주도하게 만들었다간 아마 신규 유입 인력의 고갈로 외국인 개발자 수입국가가 될 겁니다. 뿐만 아니라 개발자들의 행동양식도 소프트웨어의 품질 위주가 아니라 여전히 납기 내 기능 구현에 매달리게 될 겁니다. 그렇다면 SI, 즉 외주 개발의 대안은 뭘까요? 당연히 인바운드 개발입니다. 사내 인력을 통한 개발이죠. 개발자가 정규직으로 안정된 지위에서 전문가로서 역량을 키워나갈 수 있는 방향입니다. 단지 외주가 없어진다고 해서 바로 이렇게 될 수는 없을 겁니다. 개발자 자신들도 스스로를 바꿔 나가야 할 필요가 있습니다. 그것은 단지 구사할 수 있는 언어의 종류를 늘리거나, 파악하고 있는 업무를 다양하게 한다고 확보되는 변화는 아닙니다. 그렇게 변화하기 위해서는 개발자 자신들의 행동 양식을 어떻게 변화시켜야 할 지 고민해야 합니다. 그 행동 양식의 변화란, 자신이 작성한 프로그램을 조금 더 좋은 프로그램으로 바꾸려 하는 바로 그 행동 양식으로의 변화입니다.

이러한 개발자의 행동 양식을 바꿀 수 있는 방법 중 하나는 개발자로 하여금 도전적이고 진취적일 수 있게 하는 환경을 만들어 주는 것입니다. 그런데 불행히도 SI 개발 업계에서는 그렇게 할 수 없습니다. 그러한 환경에서는 나무를 가꾸듯 프로그램을 가꾸어 나갈 수 없습니다. 개발자로 하여금 최우선 가치를 납기 내 기능 구현에 두게 하는 것은 프로그램에게 못할 짓을 하는 겁니다. 왜냐하면 개발자는 프로그램이 그저 어떻게든 돌아가게만 하는데 집중할테니깐요. 납기를 지키는 것, 고객이 요구한 기능을 모두 구현하는 것 모두 중요한 일입니다. 그것이 중요하지 않다는 것이 아니라 그것은 개발자에게 있어서 첫 번째 가치가 되어서는 곤란하다는 겁니다.

진정한 봄은 어떤 기술을 사용하느냐에 따라 오거나 오지 않는 게 아닙니다. 대신 그 기술에 대해 어떠한 태도를 취하는가에 따라 봄은 오거나 오지 않을 수 있습니다. EJB라는 자바 웹어플리케이션 설계기법에 대해 고민하던 사람들이 없었다면 아마 이후 Spring은 나타나지 못했을 것입니다. 중요한 것은 기술을 대하는 태도입니다. 그 당시 가장 잘나가는 기술이 있다, 그런데 그것을 무작정 따라갈 것인가, 아니면 적어도 한 번쯤은 의심해 볼 것인가라는 문제입니다. 지금은 최적화된 것처럼 보이는 설계에 대해서도 혹시 트랜드나 기법에 따라 맹목적으로 따라가는 부분은 없는가를 한 번쯤은 의심해 봐야 합니다. 이런 과정은 그 기술에 대해 미처 몰랐던 부분을 파악하는데 도움을 주기도 합니다.

어떤 설계에서 과연 그것이 정말 필요한 요소인가 다시 검토하고 검증해 보는 것, 설계에 그 요소를 적용해서 얻을 수 있는 것은 무엇이고 잃는 것은 무엇인지 살펴보는 것, 이러한 과정을 겪어야 비로소 진정으로 그 기술을 자신의 것으로 만들 수 있는 게 아닐까 싶습니다. 물론 SI 바닥에서는 요원한 일일테지만요.

* 다음에는  OO(Object Oriented) 개념을 실제 SI개발에 어떻게 적용할 수 있을 지에 대해서 한번 써보겠습니다.