기업용 자바: Seam에서 하나되다

개빈 킹은 기업용 자바 개발자들의 인생을 조금 더 편하게 만들어 주기 위한 목적으로 만들어진 오픈 소스 프로젝트인 하이버네이트(Hibernate)와 JBoss Seam을 시작한 사람이다.

킹은 최근 한 때 ZDNet에 속해 있던 Builder AU 기자들과 만나 기업용 자바, 오픈소스, 등을 비롯 자바와 관련된 이런 저런 이야기를 풀어놓았다.

Seam JBoss가 엔터프라이즈 2.0의 해답이 될 수 있을까?

Seam은 현지 J2EE(자바 2 엔터프라이즈 에디션) 환경에 존재하는 다양한 기술 간의 통합 부족 문제를 해결할 수 있는 이상적인 답이다.

엔터프라이즈 에디션 환경에는 특정 기술적인 문제들을 해결할 수 있는 기술, 또는 항목들은 많지만, 이것이야말로 당신의 사업 로직을 개발할 수 있는 쉬운 방법이다라고 내세울만한 통일된 컴포넌트 모델이 없어 이들 기술을 효과적으로 사용할 수 없다는 사실이 한계점으로 지적되고 있다.

특정 부문의 기술적 문제를 해결하기 위해 특화된 컴포넌트 모델들은 매우 다양하게 분포하고 있다. 서블릿(servlets)은 HTTP 사용 관련 문제를 해결해주고, EJB(엔터프라이즈 자바빈스(JavaBeans))는 트랜섹션 리소스 접근과 관련된 문제를 해결해 준다.

JSF(자바서버 페이스)는 좀 더 풍부한 유저 인터페이스를 이용해 페이지를 개발할 수 있게 해준다. 하지만 이들 모두 각각의 개별 전문가 그룹에 의해 독립적으로 개발된 것이어서 호환성 면에서는 상당히 부족하다.

J2EE를 이용해 개발할 경우 루비 온 레일스(Ruby on Rails)보다 불편한 점이 있다면?

자바 시스템 환경은 매우 풍부하다. 매우 다양한 기술들이 있다. 이러한 기술들을 쉽게 같이 활용할 수 있기 때문에 굳이 엄청난 양의 코드를 적어 내려갈 필요가 없다. 하지만 상대적으로 축약된 코드에 내포되어 있는 의미들을 모두 파악하기 위해서는 다양한 기술에 대한 이해가 바탕이 되어야 한다.

다양한 기술을 제공한다는 의미는 곧 배워야 할 것도 많다는 의미. 자바EE를 처음으로 접해 본 사람이라면 학습하는데 시간이 좀 걸릴 수 있다.

JSF를 학습하는 데 소요되는 시간은 확실히 루비의 RHTML을 학습하는 데 드는 시간보다 길다. JSF는 내용면에서 풍부함을 자랑하지만, 그 패러다임을 이해하는 데 시간이 좀 걸린다.

스크립트 언어 환경은 확실히 자바에 비해 코드 전개 과정에서의 이점을 지니고 있다. 클로저(closure)나 다이내믹 타이핑(dynamic typing) 등이 바로 그런 이점들 중 하나라고 할 수 있는데, 그렇다고 마냥 좋은 것은 아니고 장단점이 있다.

더 이상 PHP나 루비 쪽 사람들도 자바에서 CRUD 애플리케이션을 실행시키는 데 3주 이상 걸린다고 놀리지 않는다. 이는 이미 과거 이야기가 되어 버렸다.

스크립트 언어 프로그래머들이 자바를 새로운 시각으로 바라보게 된 것 아닌가?

요즘 스크립팅이 중요하다는 생각에 이를 적용, 프로젝트에 시도했는데, 처음 몇 달간은 잘 돌아가는 것 같았고 그래서 이를 알맞게 사용하려고 하니 의외로 사용 용도에 많은 제약이 있더라는 내용의 이야기를 많이 듣는다. 그들은 코드가 리팩토링(refactoring) 없이 장기간 유지되기는 힘들다는 사실을 깨달은 것이다.

자바의 특징 중 하나는 상대적으로 제한된 언어라는 것이다. 일정 한계선을 넘나들기 위해서는 상당한 작업 시간이 소요된다. 하지만 이를 거꾸로 돌려 생각해보면, 그만큼 사람들이 예상치 못한 방향으로 일을 전개해 나갈 수 없다는 이야기가 된다.

큰 규모의 팀에서 다양한 경험을 가지고 있는 사람들과 일하다 보면, 이러한 제약 사항이 오히려 작업 효율을 늘리는 효과로 돌아온다는 사실을 알 수 있을 것이다.

JSR(Java Specification Requests) 위원회에 참여하는 기분은 어떤지?

매우 유익하다. 공식적인 느낌이 강하면서도 가끔은 감정적으로 다가가는 무언가가 있다. 서로 치열한 경쟁자의 위치에 있는 20여 개의 각각 다른 회사의 대표로 나온 20명의 회원들의 의견들을 취합하는 작업이 쉽지 많은 않다. 하지만 JSR에서 도출되는 결과물들은 한 개인 회사가 개별적으로 만들어 낼 수 있는 결과보다 훨씬 가치 있고 튼실한 것 같다.

예를 들어 개인적으로는 JPA(the Java Persistence API)가 하이버네이트나 톱링크(TopLink) 등과 같은 솔루션들 보다 더 깔끔하고 훌륭하다고 생각한다. 현재 내가 이끌고 있는 JSR인 웹빈스(Web Beans)도 Seam이나 구글의 주스(Juice)보다 더 낫다고 생각한다.

여러 이해 관계를 조정하는 과정은 매우 고통스러울 수밖에 없다. 하지만 그 자리에 적합한 전문가 그룹이라면, 이러한 과정이 결국에는 더욱 훌륭한 결과물로 돌아온다.

현재 JSR의 문제점이라고 한다면, 리더십의 부재를 들 수 있다. 서로 이해관계가 다른 전문가 그룹을 한데 뭉쳐 가치 있는 플랫폼을 개발해 내도록 유도하는 것이 개별 회사에서 자체적으로 프로젝트를 진행하는 것보다 힘든 것이 사실이다.

나의 가장 큰 바람은 웹 빈스(Web Beans)가 EE 개발 표준 모델로 인정받는 것이다.

자바의 오픈 소스화가 당신의 일에 어떤 영향을 미쳤는가?

별로 영향을 미치지 않았다. 근본적으로 JVM(Java virtual machines)은 C/C++을 이용하는데, 나는 이들 언어를 이용해 개발하지 않는다.

하지만 장기적인 관점으로 봤을 때 잠재적으로 영향을 미칠 수 있다고 생각한다. 컴파일러와 JVM의 오픈 소스화는 곳 새로운 개발자들이 언어를 이용해 새로운 기능들을 창출해 낼 수 있는 기회를 제공해 주기 때문이다. 확실히 자바에 새로운 진화에 영향을 줄 것이라 생각하고 더불어 forking에 대한 잠재력도 더욱 높이는 계기가 될 것이라 생각한다.

현재 자바는 매우 애매모호한 상황에 있다. 기존의 언어에 새로운 기능들을 속속들이 추가해야 할지, 아니면 같은 JVM 내에서 새로운 언어를 만들어 낼지 불명확한 상황이기 때문이다.

최근 JRuby와 같은 JVM 내 새로운 대체 언어에 대한 관심이 증가하고 있는 것은 사실이다. 반면에 클로저(closure) 기능과 같은 새로운 언어들이 가지고 있는 장점들을 자바로 옮겨 쓰고 싶어하는 사람들도 있다.

어떤 길을 선택해야 할지 아직 불명확 상태이다. 나조차도 어떻게 해야 할지 모르겠다. 자바에 클로저와 같은 기능을 추가해야 한다고 생각하는 사람들이 있다. 나도 한 때 그런 의견을 제시하는 사람들 중 하나였다. 그런데 갈수록 과연 자바에 클로저 기능을 추가할 필요가 있을까라는 생각이 든다.

클로저 기능을 보유한 새로운 언어가 자바를 대체해도 괜찮을 것 같다는 생각도 요즘 한다. 새로운 기능을 자바에 붙인다고 해서 효용성이 있을까 의문이 드는 것이 사실이다.

레드햇과 JBoss가 쓰는 오픈 소스 프로젝트와 차별화된 점은 무엇인가?

우리는 항상 급격하게 변화하는 오픈 소스의 특성으로 인한 부작용을 감내하고 있다. 이러한 문제들은 긍정적인 의미로 해석될 수 있고, 또 부정적인 의미로 해석될 수 있다.

오픈 소스 프로젝트를 개발하는 데 발생하는 가장 흔한 문제들이 있는데, 개발자들이 중간에 지쳐 나가떨어지는 경우가 하나, 또 1년 전에 공개된 버전의 에러를 고쳐놓고는 이를 2.0 버전이라고 이야기하며 모든 걸 무너뜨려 버리는 경우가 또 하나이다.

거의 모든 소프트웨어들은 역호환과 실수에 대한 수정 사이에서 고민한다. 오픈 소스 세계에서는 보통 역호환보다는 실수를 수정하는 방법을 선택한다.

이런 부분은 긍정적이라고 생각한다. 당장은 사용자들에게 피해를 입힐지 모르지만, 실수를 수정하는 것이 장기적으로는 바람직하다고 본다.

결국, 우리가 필요한 것은 프로젝트를 5년, 7년 장기적으로 관리, 지원해 줄 수 있는 레드 햇과 같은 회사이다. 오픈 소스가 기업용 시장에서 성공하려면, 상업성이 반드시 갖추어져 있어야 한다. 기업용 시장의 소비자들은 10년 이상의 수명을 가진 프로젝트를 계획하기 때문이다.

사람들은 RHEL(Red Hat Enterprise Linux)와 페도라(Fedora)로 나누어 기업용과 일반용으로 굳이 구분을 한 레드 햇에 의문을 제기한다. 기업용 버전이 더 낫다는 의미인가?라고 질문하는 사람들도 있다. 하지만 사실 페도라가 더 나은 버전이다.

페도라는 사람들이 아침에 일어나 샤워를 하면서 정말 최고야라고 말하며 흐뭇한 미소를 지을 만큼 최신의 그리고 최고의 기능들을 보유하고 있다. 하지만 문제는 이러한 기능들을 7년 동안 한결같이 사용할 수 없다는 점이다.

레드햇은 용도에 따라 제품을 분리함으로써, 훌륭한 기능들에 대한 활용도를 극대화 함과 동시에 이로 인해 발생하는 부작용을 최소화하려 했다고 볼 수 있다.

또 다른 문제 중 하나는 바로 포킹(forking)이다. 자유로운 포킹이 가능하다는 점은 오픈 소스의 경쟁력을 뒷받침하는 주요한 포인트 중 하나라 할 수 있다. 하지만 주변을 둘러보면, 제대로 돌아가는 프로젝트들은 대부분 포킹 경험이 거의 없다는 사실을 알 수 있다. BSD의 세계에서는 엄청난 포킹이 오갔던 것으로 기억한다.

JBoss는 지금까지 한 번도 포킹된 적이 없다. 하이버네이트도 마찬가지. 우리가 진행 중인 프로젝트들은 포킹에 대한 경험이 거의 없다고 봐도 무방하다.

이러한 현상이 발생하는 이유 중 하나는, 바로 포킹에 대한 위협이 본 소유주들을 정직하게 만들기 때문이 아닌가 생각한다. 커뮤니티가 가지고 있는 문제들을 사전에 수정함으로써, 커뮤니티 구성원들을 항상 만족시켜야 한다는 강제성을 부여하는 것이다.

만약 문제를 빨리 해결하지 않는다면, 구성원 중에 하나가 당장 하이버네이트를 포킹하여 문제를 해결한 후 경쟁자로 돌아설 수 있기 때문이다.

개인적으로 포킹의 존재가 상당히 긍정적인 영향을 미친다고 생각한다. 위협으로 인한 부작용을 야기하기 보다는 오히려 더 바람직한 방향으로 프로젝트를 이끌어 나가게끔 유도하기 때문이다.

하지만 언어는 하이버네이트나 JBoss와는 다르다. 언어는 더 복잡하고 API에 비해 안정성도 떨어진다. 이미 수많은 소프트웨어가 그 언어를 사용하고 있기 때문에 이들에 미칠 영향을 생각하지 않을 수 없다. @