고기맛을 알아버린 스님

지난달 보도됐듯이 BEA는 웹 애플리케이션 개발 프레임워크인 웹로직 워크샵을 오픈소스 커뮤티니에 공개하기로 했다. 하지만 이번 BEA 결정이 과연 닷넷에 대한 J2EE 진영의 경쟁력에 도움이 될지에 대해서는 논쟁의 여지가 있다.

BEA가 오픈소스로 공개한 웹로직 워크샵은 현재 ‘비하이브(Beehive)’로 불린다. BEA는 이같은 결정이 "전세계 자바 개발자들(이들은 자바 커뮤니티의 핵심이다)이 J2EE 기반 애플리케이션 서버에 더 쉽게 접근할 수 있도록 하기 위한 것"이라고 밝혔다. 하지만 조금 더 생각해보면 그 이면의 목표도 알아차릴 수 있을 것이다.

비하이브는 단순히 ‘자바 개발을 더 쉽게 하기 위한 것’만이 아니다. 생각해보면 BEA는 자사의 웹로직 워크샵만으로도 이미 ‘자바 개발을 더 쉽게 하고있다’고 주장할 수 있다. 지금까지 웹로직 워크샵은 웹로직 제품군의 유력한 구매요건이었으며, BEA의 경쟁력 제고에 기여해왔다.

BEA는 웹로직 워크샵 기술을 오픈소스로 공개하는 것은 “고객들의 J2EE 개발 부담을 덜어주는 프레임워크를 (BEA의 개발 툴과 애플리케이션 서버를 사용하지 않는)J2EE의 나머지 세계에도 제공하기 위한 것”이라고 주장했다. 이와 같은 맥락에서, BEA는 “웹로직 워크샵은 복잡한 웹 애플리케이션이나 독립형(stand-alone) 웹 서비스, 완전한 서비스 기반 아키텍처(SOA) 등을 구동하는데 웹로직을 이용하는 방법을 알려줬다”며 “이제 (이를 공개한 만큼) 모든 J2EE 애플리케이션 서버에 대해서 동일한 방식으로 동작할 수 있다”고 강조했다.

어쨌든 BEA는 IBM, 썬, 오라클을 비롯한 자바 진영 기업들이 무슨 생각을 하고있는지 인식한 것이다. 이들은 세력을 강화하고 있는 MS 닷넷 플랫폼에 대응하기 위해서는 자바 개발을 더 쉽게 만들어 자바 개발자 커뮤니티 규모를 키워야 한다는 점을 인식하고 있다.

가 트너에 따르면 MS 비주얼 스튜디오 닷넷은 기업 개발자들 사이에서 점유율을 늘려나가고 있으며, 보편적으로 윈도우 클라이언트를 사용하고 있는 중소기업 시장으로도 그 영역을 확대해 나갈 전망이다. 게다가 이제 비주얼 스튜디오에서는 자바 바이트코드 생성 기능까지 제공하고 있는 상황이다. 비주얼 스튜디오용으로 출시될 메인소프트의 비주얼 메인윈 J2EE 애드온은 개발자가 어려운 자바 프로그래밍을 배울 필요 없이 손쉽게 자바 바이트코드를 생성할 수 있는 기능을 제공할 예정이다.

자바의 성장 정체는 여러 시스템적 문제들의 결합이 그 원인이다. 예를 들어, 애플리케이션 서버를 활용해 현재 직면한 비즈니스 문제를 해결하는 방법을 직관적으로 파악하기 위해 필요한 기술과 배경 지식을 갖춘 인력이 부족할 수 있다. 분명히 J2EE 개발을 쉽게 하는 것은 웹 애플리케이션, 웹 서비스, SOA를 막론하고 중요하며 실제로 필요한 조치다.

자바 진영에서는 J2EE 개발을 쉽게 하려는 시도를 여기저기서 쉽게 볼 수 있다. IBM은 래쇼날 툴셋을 통해 개발 용이성을 추진 중이며 오라클 역시 비하이브와 유사한, 자바 개발자들의 부담을 덜어주는 애플리케이션 디벨롭먼트 프레임워크(ADF)를 보유하고 있다.

지난해 당시 썬 개발 플랫폼 부문 부사장이었던 리차드 그린은 “비교적 간단한 서버 프로그램은 MS 비주얼 스튜디오 닷넷을 사용할 때와 비슷한 시간대에 개발할 수 있도록 하기 위해 노력중”이라고 말했다. 그린이 말했던 것은 썬의 ‘레이브’ 프로젝트다(레이브는 애플리케이션 개발 기술로, 현재 자바 스튜디오 크리에이터로(JSC) 명칭이 변경됐다). 또 썬 사장인 조나단 슈워르츠는 자바를 “비주얼 스튜디오 닷넷 수준으로 쉽게 하는 것”을 수시로 강조했다.

BEA 디벨로퍼 마케팅 그룹 부사장인 코넬리어스 윌리스는 “현재 J2EE 개발은 지나치게 복잡하다”면서 “비하이브는 J2EE API 최상위에 추상계층(abstraction layer)을 갖고있어, MFC가 윈도우 애플리케이션 개발을 쉽게 하는 것과 유사한 기능을 (J2EE에서) 하는 프레임워크를 제공한다. 비주얼 베이직에서처럼 코드에 드롭만 하면 된다”고 설명했다.

비하이브의 정체는?
자바 개발자들 사이에서 중요한 역할을 하는 이클립스나 넷빈즈와 달리 비하이브는 IDE가 아니다. 사실 비하이브가 소프트웨어 개발 스택에서 어느 부분에 위치하는지조차 분명하지 않다. IBM이 이클립스를 오픈소스화했을때 자바 개발자들은 즉시 이것이 썬의 넷빈즈 IDE와 경쟁관계임을 알 수 있었다. 비하이브가 자바 생태계에서 어디에 속하는지, J2EE의 어느 기술을 대체할 것인지, 그리고 무엇을 보완할지에 대해서는 지금 자바 커뮤니티에서 논쟁이 한창이다.

윌리스는 “비하이브와 다양한 J2EE API의 관계는 자바와 자바가 수행되는 운영체제의 관계와 같다”고 말했다. 여러 운영체제들이 사실상 같은 기능을 수행하기 위해 서로 다른 고유의 API를 두는 것이 다중 운영체제로 소프트웨어를 개발하는 것을 어렵게 만들듯이, J2EE API간의 이질성이 J2EE 개발을 어렵게 한다는 것이다. 이같은 상황은 자바 개발을 어렵게 해 필요 이상으로 가파른 학습곡선을 낳았으며 결과적으로 자바 커뮤니티의 성장을 억제해왔다.

자바 진영의 썬, 오라클은 J2EE에 대한 윌리스의 비판에 대해서 특별한 이견이 없었다. 비하이브는 J2EE API의 상이한 인터페이스에 대해 일정한 프로그래밍 모델을 개발자에게 제공하기 위해 런타임 환경을 사용한다.

웹 로직 플랫폼을 통해 이 문제를 해결한 BEA가 비하이브를 통해 그 코드와 런타임을 오픈소스화함으로써 이제 웹로직 뿐 아니라 모든 J2EE 서버에서도 API 문제를 해결할 수 있는 기회가 열린 셈이다. 물론 다른 업체들의 애플리케이션 서버와 개발 툴이 이를 지원해야 한다는 조건이 있다.

자바 커뮤니티에 가중되는 혼란
이제 갓 시작한 단계치고 비하이브는 상당한 지지를 얻고 있다. 아파치 소프트웨어 재단(ASF)이 비하이브 프로젝트의 관리를 맡은 것을 비롯해 여러 실력자들이 비하이브에 참여 의사를 밝혔다. 레드햇, 볼랜드, 비즈니스 오브젝트, 컴퓨웨어, 컴퓨터어쏘시에이츠(CA)가 프로젝트 위원회를 구성했으며 아마존, 이베이, E.피파니, 페덱스, 구글, 페이팔, 세일즈포스닷컴, UPS의 비하이브용 드롭-인 컴포넌트도 이미 나와있다. 자바 서블렛/JSP 부문에서는 톰캣이 비하이브를 지원키로 했다.

이정도면 비하이브가 자바 커뮤니티에 기여한다는 BEA의 주장을 충분히 뒷받침할 수 있을 것 같다.

하 지만 문제는 비하이브 지원 목록에 J2EE 진영의 최상급 업체들인 썬, IBM, 오라클이 빠져있다는 점이다. 이는 이 기업들이 (BEA의 주장처럼) 비하이브를 J2EE의 희망으로 보고있지 않음을 시사한다. 필자는 전화 인터뷰를 통해 이같은 사실을 확인했고, 본의 아니게 업체들간 기술 논쟁의 한 가운데 서게 됐다. BEA가 자사 기술을 오픈소스화한 이유부터 비하이브의 기술적인 이점까지, 다양한 주제에 대한 논쟁이다.

윌리스는 BEA가 썬, IBM과 비하이브에 대해 이야기하고 있다고 말했지만 두 회사에 확인한 결과 이들 사이에는 ‘해결할 수 없는 차이점’이 존재하는 것으로 보인다. 썬의 자바 웹서비스 마케팅 부문 부사장인 조 켈러는 “개발 툴 제공업체들은 이러한 솔루션을 계속해서 제공하고 있다”면서 “우리는 BEA와는 다른 방법으로 JSC를 통해 새로운 API를 동원할 필요가 없도록 하고있으며 J2EE 개발을 쉽게 하고 있다”고 말했다.

그는 이어 BEA의 비하이브가 JCP의 승인을 받은 JSF와 어떤 부분에서 기술적인 충돌을 일으키는지 설명했다. 켈러는 “JCP를 통해 최근 승인된 JSF는 자바 애플리케이션 구축을 위한 프레임워크이며 썬 JSC의 기반”이라고 덧붙였다.

설령 비하이브에 J2EE 개발에 투명성을 가져다 줄 잠재력이 있다해도, 업계를 이끌 견인력을 갖지 못한다면 아무런 의미가 없다. 이가운데 자바 커뮤니티 안에서는 전혀 득될 것이 없는 비하이브 기술에 대한 정치적 논쟁이 벌어지고 있다.

IBM은 대변인을 통해 “BEA가 개방적이 되려고 하는 것에 박수를 보낸다. 우리는 여전히 BEA가 이클립스 프로젝트에 합류하기를 기대한다”고 전했다. 애매모호한 발언이다. 필자는 IBM으로부터 비하이브에 대한 더 구체적인 의견을 들으려 했지만 “IBM은 BEA의 비하이브와 관계된 어떤 글에도 의견을 밝히지 않을 것”이라는 답만 얻을 수 있었다. 결국 IBM은 비하이브를 거부하지도, 그렇다고 지지하지도 않았다.

오라클 수석 아키텍트인 테트 파렐은 JSF와 비하이브의 상충을 자세히 설명하면서, 더불어 스트럿을 지원에 있어서 이 두 기술의 충돌에 대해서도 지적했다.

이 와같은 비하이브의 문제점 지적에 대해 BEA 웹로직 워크샵 부문 제품 디렉터인 칼 조그린은 JSF와 비하이브간에 존재한다는 기술적 충돌을 강력히 부인하면서 BEA가 이 둘의 호환을 위해 모든 노력을 기울이고 있음을 알려준다는 증거를 필자에게 내보이기도 했다.

만일 필자에게 한달 정도 시간이 주어지고, 자바 최고 전문가들의 도움을 받을 수 있다면 누구의 말이 옳은지 가려낼 수 있을지도 모른다. 아마 필자보다 더 혼란스러운 것은 고객들일 것이다.

JSF, 비하이브, 스트럿 등 비하이브 논쟁에 휘말린 기술들도 물론 중요하지만, 진정한 문제는 자바의 커뮤니티 기반 운영방식 자체가 이슈가 되고 있다는 점이다. 확실히 자바 업체들은 MS에 대항해 개발자들의 마음을 사기 위해 노력하고 있다. 웹 애플리케이션, 웹서비스, SOA에 대해 애플리케이션 서버 기반 개발이 아직 본격화 되지는 않았지만 사실상 모든 업체가 이를 목표로 움직이고 있다.

자바 커뮤니티 역시 앞으로의 성장 여부는 중소기업 시장에 달려있음을 인지하고 있으며, 많은 기업들에게 자바와 닷넷의 선택은 ‘둘 다’가 아닌 ‘둘 중 하나’가 되리라는 것도 알고 있다.

가 트너에 따르면 중소기업 시장에서는 클라이언트 시스템을 지배하고 있는 MS 닷넷이 자바 플랫폼보다 유리한 상황이다. 또한가지 MS에게 유리한 점은 비주얼 스튜디오 닷넷은 현재 대부분의 중소기업이 보유하고 있는 윈도우 애플리케이션을 서비스 지향의 웹 친화적 애플리케이션으로 마이그레이션할 수 있는 적절한 경로를 제공한다는 것이다.

자바 진영은 워크플로우, IDE, 비즈니스 로직, 프레젠테이션 계층 등 모든 기술적인 문제에 대해 위원회를 거쳐 대처해야 하지만, MS는 최고소프트웨어아키텍트(CSA)인 빌 게이츠의 서명 하나면 즉시 통일시킬 수 있다.

‘한 번 개발하면 어디에서든 동작한다’는 자바의 약속을 깨뜨리지 않고 기술적인 문제를 해결하려면 자바의 공식 표준제정 기구인 JCP를 통과해야만 한다. 즉, 이 말은 MS가 닷넷에 대한 결정을 하루, 심지어 몇시간 만에 내릴 동안 자바는 수개월에서 몇 년까지 걸릴 수 있다는 의미다. 이같은 속도와 유연성에 있어서의 불리함에 더해, 이를 해결하기 위한 방안에 있어서도 자바 커뮤니티 소속 기업마다 이견을 보이면서 자바는 닷넷과의 경쟁에서 점차 뒤쳐지고 있다.

오라클의 파렐은 자바의 진화에 대한 결정은 여전히 JCP를 통해 결정돼야 한다고 믿는다. 파렐은 오라클이 (표준을 위해) ADF 기술의 일부를 JCP에 제공했음을 강조하면서 “BEA에 문제가 있다면 JCP를 통해 이를 해결해야 할 것”이라고 말했다.

이에 대해 BEA의 조그린은 JCP의 느린 속도를 지적하며 “표준 기구보다 빠르게 움직이는 혁신 동력이 필요하다. 우리는 오픈소스 커뮤니티가 어떻게 빠른 속도로 혁신을 이루는지 지속적으로 관찰해왔다. 오픈소스에서는 필요한 것이 있으면 이를 실행에 옮기고 그 결과를 확인한다. 자바 커뮤니티는 바로 이러한 오픈소스 커뮤니티의 빠른 대응 방식을 도입할 필요가 있다”고 말했다.

BEA는 이러한 믿음 하에 비하이브를 JCP에 제출하는 대신 광범위한 업계 지원을 받을 수 있으리라는 희망을 품고 오픈소스 방식을 택한 것이다. 조그린은 “비하이브는 스트럿에 의존하고 있는데 스트럿은 JCP 표준이 아니다. 따라서 비하이브는 JCP 표준을 추진하기 어렵다”고 덧붙였다.

불행하게도 BEA의 경우처럼 업체가 오픈소스 방식을 선택했다는 것은 조만간 긴장 국면이 조성되고 FUD가 시작되며 J2EE의 조화를 이루는 이음새가 터지기 시작할 것임을 의미한다. 순수 상용 소프트웨어 업체들에게 오픈소스 라이선싱은 경쟁의 새로운 무기가 되고있다. 결국 기업들은 IBM의 전략을 모방하고 있는 것이다. 그 전략이란 것은 오픈소스 커뮤니티에 기술을 제공할 때에는 자사의 목표를 달성하는데 도움이 되는 방식으로 이뤄져야 한다는 것이다.

여타 J2EE 기반 애플리케이션 서버 업체들에겐 괴로운 일이지만 IBM 웹스피어는 지난 2년동안 강력히 부상해 일부 리서치 기관에서는 이를 애플리케이션 서버 부문 1위로 파악하고 있다. 웹스피어가 부상하기 전까지는 BEA의 웹로직 애플리케이션 서버가 장기간 동안 선두를 유지하고 있었다(BEA는 웹스피어가 선두라는 주장을 인정하지 않고있다).

어쨌든 웹스피어의 부상에 힘입어 IBM은 J2EE 시장에서 강세를 보이게 됐고, BEA를 포함한 경쟁업체들은 그만큼 어려운 상황에 처했다.

IBM도 개발 스택의 상당부분을 오픈소스화한 것이 이러한 놀라운 점유율 상승의 동력이 됐다는 점을 부인하지 못한다. 이클립스로 불리는 IBM의 오픈소스 코드는 경쟁업체 제품에서도 동작하지만 웹스피어와 결합될 때 가장 효율적이다.

업 체들은 소스 일부를 오픈소스화하면 오픈소스 개발 모델이 기술 향상에 도움을 준다고 말한다. 사실 이러한 효과는 오픈소스 커뮤니티에 지적재산권을 헌납하는데 대한 부차적인 효과일 것이다. 그럼 일차적인 효과는? 더 많은 개발자들을 오픈소스화한 기술과 함께 사용되는 자사 기술로 끌어들일 수 있다는 것이다. 물론 그 기술은 오픈소스화되지 않은 기술이며, 해당 업체의 제품전략에 있어서 중요한 위치를 차지하고 있다.

일례로 CA는 최근 잉그레스 데이터베이스를 오픈소스화했다. 이 회사 리눅스 기술그룹 수석 아키텍트인 샘 그린블라트는 인터뷰에서 “CA가 인수한 RTI가 사유화했지만 원래 잉그레스는 오픈소스에서 비롯된 기술이다. 이제 우리가 이를 다시 커뮤니티로 환원하면 커뮤니티는 잉그레스를 더 개선시킬 것”이라고 말했다.

그는 그 과정에서 CA가 얻는 이익을 인정했다. “잉그레스는 CA가 출시하고 있는 모든 관리제품의 중심이다. 잉그레스가 오픈소스화 되면 더 많은 협력업체들이 이를 선택할 것이고, 결과적으로 우리의 여타 관리 툴에 대한 시장을 형성할 것이다.”

그린블라트는 기업들이 비즈니스 애플리케이션 용으로 잉그레스를 도입하게 되면 결국 기업내 표준에 대한 (CA의) 관리 솔루션에 흥미를 갖게 될 것이라고 말했다.

필자는 이와같은 전략을 '기만'이라고 말하려는 것은 아니다. 사실 이는 오픈소스를 포용하고 발을 넓히면서 동시에 사유제품에 기반한 비즈니스를 영위하는데 있어 실용적인 방법이다.

오픈소스 전략을 잘 이용하면 시장점유율을 급속히 끌어올릴 수 있다는 사실이 널리 알려진 지금 (특히 웹로직이 불리한 상황에 처해있는) BEA가 오픈소스에 기반한 시장 창출을 추진하는 것은 놀라운 일은 아니다.

BEA 자신도 오픈소스화 발표가 회사 비즈니스에 탄력을 주기를 희망한다고 인정했다. 윌리스는 “요점은 오픈소스의 인기를 이용해 우리의 기술 혁신을 시장에 확산시킨다는 것이며, 이를 통해 매출기회를 창출한다는 것”이라고 말했다.

BEA 는 비하이브가 자사의 야심보다는 닷넷과의 경쟁 차원에서 다뤄지길 원한다. BEA는 다른 J2EE 솔루션 업체들과 마찬가지로, 자바 커뮤니티가 (JCP를 통하든 안통하든) 혁신의 속도를 MS와 동일하게 유지하면서 협력할 수 있는 방안을 마련하지 못한다면 표준기구가 아예 없는 (그래서 빠른) 닷넷이 더욱 세력을 확장해 일부 비즈니스 시장에서 J2EE를 꺾고 승리를 거머쥘 것이라는 점을 잘 알고있다.

비하이브의 사례에서 볼 수 있지만 아무리 그 취지가 좋다해도 과도한 JCP 통제(특히 오픈소스에 있어서)는 자바 커뮤니티를 오히려 분열시킬 수 있다. 이로 인해 자바는 여러가지 잡음과 FUD를 극복하고 경쟁력을 유지하는데 어려움을 겪고 있다. 자바 진영에 이러한 균열이 존재하는 한 MS는 자바 커뮤니티를 각개격파 할 방법을 고민하지 않아도 된다. 자바 커뮤니티는 이미 속도 면에서 닷넷보다 불리한 위치에 있으며, 알아서 MS의 걱정을 덜어주고 있는 것으로 보인다. @

출처: http://zdnet.co.kr