크레그 맥클라나한

썬 마이크로시스템즈의 웹 애플리케이션 제작용 IDE인 자바 스튜디오 크리에이터 개발툴이 이제 비주얼 개발자들을 위해 새로운 버전으로 업데이트되어 보다 강화된 사용성과 더욱 풍부한 설계 환경을 제공한다. 이 IDE는 썬 마이크로시스템즈의 수석 엔지니어인 크레그 맥클라나한(Craig McClanahna)이 창시한 JavaServer Faces 기술을 기반으로 하여 구축되었다. 크레그 맥클라나한은 오픈소스 개발자로서 1998년에 아파치 스트럿츠 프레임워크를 개발한 바 있으며, 이는 J2EE(Java 2 Platform, Enterprise Edition) 환경을 위한 표준 웹 애플리케이션 아키텍처로 선정되어 여러 가지 주요 애플리케이션 서버에 통합되는 결과를 낳았다.

크레그 맥클라나한이 썬마이크로시스템사에 합류한 2000년도에는, 웹 애플리케이션 프레임워크가 확산되기 시작면서 표준의 필요성이 명확하게 대두되었다. 웹 애플리케이션에서의 사용자 인터페이스 컴포넌트를 위한 베이스 레벨 API를 제작하는 문제를 해결하기 위해 JCP(Java Community Process)에는 JSR127이 도입되었으며, 크레그 맥클라나한이 명세작업을 공동 주관한 JavaServer Faces 1.0은 2004년 3월에 빛을 보게 되었다. JavaServer Faces가 애플리케이션 프레임워크로서 스트럿츠에 비해 상당한 개선 사항을 제공하고 새로운 버전의 자바 스튜디오 크리에이터가 더욱 생산적인 개발 환경을 제공하는 가운데, 많은 개발자들은 세 가지 모두를 최대한 활용할 수 있는 방법에 대해 알고자한다.

크레그 맥클라나한이 개발자로서 쌓은 광범위한 이력에는 코어 서블릿 엔진을 위한 차세대 아키텍처와 기능 세트 구현에 초점을 맞춘 아파치 JServ 프로젝트가 포함되어있다. 그는 또한 Tomcat 서블릿 컨테이너의 기술 분야를 주도하기도 했다.

썬의 수석 엔지니어인 그는 현재 자바 스튜디오 크리에이터IDE의 아키텍트로 일하고 있으며, 다음은 그를 만나 스트럿츠, JavaServer Faces, 그리고 자바 스튜디오 크리에이터의 새로운 버전에 관해 인터뷰한 내용이다.

JavaServer Faces API의 논리적 근거는 무엇인가?

JavaServer Faces API는 두 가지의 주된 목적을 위해 설계되었다. 첫째는 자바 개발자들에게 정교한 사용자 인터페이스 컴포넌트를 위한 표준 API를 제공하는 것이고, 그로인해 자바 툴 개발자들이 보다 풍부한 설계 환경을 제공하는 툴을 제작할 수 있도록 하는 것이 그 두번째이다. 한편, 컴포넌트는 활용 대상 툴을 위해 특별히 설계된 정보를 보유하는데, 자바 스튜티오 크리에이터 IDE는 그 정보를 이용하여 매우 친숙한 환경을 생성하게된다. JSP 페이지를 구성시, 사용자는 애플리케이션이 실행되었을 때 컴포넌트가 어떤 모습을 띠게 될지 불 수 있으며, 따라서 JavaServer Faces 또는 자바 소스 코드에 속한 모든 내용을 일일이 구성할 필요 없이 해당 컴포넌트의 속성을 GUI 메커니즘으로 처리할 수 있게 된다.

스트럿츠와 JavaServer Faces는 어떤방식으로 상호운용되는가?

짐작하겠지만, 상당히 많이 접하는 질문이다. 간단히 말하자면, 기존의 스트럿츠 애플리케이션이 한번에 한 페이지씩 JavaServer Faces 컴포넌트 태그를 사용하는 방식으로 완벽하게 마이그레이션할 수 있다. (여기서 말하는 태그 JavaServer Faces와 함께 출시되는 표준 태그 또는 제3자 컴포넌트 라이브러리의 태그이다.)

이로 인해 기존의 스트럿츠 개발자가 데이터 테이블 같은 정교하고 복잡한 컴포넌트에 액세스할 수 있게 되었는데, 이전에는 벤더별 커스텀 태그 라이브러리를 찾아서 각자의 애플리케이션에 통합을 해야했다. 이제는 기존의 애플리케이션을 변경하지 않고도 임의의 벤더가 제공하는 컴포넌트를 사용할 수 있게 되었다.

자세한 답변은 블로그 (http://blogs.sun.com/roller/page/craigmcc/)에서 확인할 수 있다.

스트럿츠와 JavaServer Faces 기술에 대한 가장 큰 오해는 어떤 것인가?

둘 중 하나를 선택해야 한다고 생각하는 것이 가장 큰 오해일 수 있겠다. 우리는 스트럿츠에 기반을 둔 기존 애플리케이션에 새로운 javaServer Faces 기술을 이용할 수 있는 방법을 제공하고자했다. 많은 사람들이 JavaServer Faces를 이용하기 위해 각자의 스트럿츠 애플리케이션을 당연히 포기해야 한다고 생각하고 있는데, 통합 라이브러리는 한번에 하나씩 JavaServer 페이지를 변경할 수 있게 해주므로 백엔드 애플리케이션 로직을 그대로 유지해도 아무런 문제가 없다.

"기존의 스트럿츠 애플리케이션이 한번에 한 페이지씩 JavaServer Faces 컴포넌트 태그를 이용하는 방식으로 완벽하게 마이그레이션할 수 있다." - 크레그 맥클라나한 썬마이크로시스템즈 수석 엔지니어

반면에 새로운 애플리케이션의 경우에는 현재 JavaServer Faces 컨트롤러와 스트럿츠가 하는 일 사이에는 상당한 중복 부분이 있습니다. 스트럿츠 커뮤니티에서는스트럿츠 2.0버전으로 무엇을 할 것인지 고민해왔다. 우리는 UI 컨트롤러로서의 JavaServer Pages를 지원하는 애플리케이션 단계의 기능을 추가하고, 해당 페이지의 모든 이벤트를 처리하는 페이지에 연결된 페이지 빈(bean)의 개념과 같이 자바 스튜디오 크리에이터에서 볼 수 있는 사용하기 쉬운 프로그래밍 기술들을 도입할 것이다.

현재 , 스트럿츠 분야에서는 그런 종류의 논리가 세 가지 자바 클래스와 하나의 페이지에 걸쳐 확산되고 있다 . 자바 스튜디오 크리에이터가 지지하는 바이자 필자가 스트럿츠 2.0에 권유하는 모델에서는 이것이 일대일 관계로 JavaServer Page에 대응하는 단일 클래스로 축소되어야할 것이다. 자바 스튜디오 크리에이터에서 JavaServer Faces가 구현되는 방식을 활용하여 차세대 애플리케이션 프레임워크가 지녀야 할 모습을 정교하게 다듬어가고 있는 중이다.

스트럿츠와 JavaServer Faces이 두 개의 프레임워크가 각각의 티어에 초점을 맞추면서 아키텍처 요구사항을 충족하도록 동반하여 활용하는 것은 어느 시점에서 적절한가?

한 가지 주의해야 할 것은 JavaServer Faces가 프론트 컨트롤러 아키텍처를 가지고 있기는 하지만 궁극적으로는MVC(Model View Controller) 아키텍처의 뷰(View) 티어라는 것이다. 따라서 이는 전적으로 사용자 인터페이스 이벤트에 초점을 맞추고 있다. 예를 들어 사용자가 트리 컨트롤을 가지고 있고 그 위에 서브 트리를 열기 위한 노드를 배치한다고 하면, 서버를 왕복하는(roundtrip) 방식으로 작동하여 클라이언트 측 JavaScript를 실행하지 않도록 구현하게 된다. 이런 시나리오에서 이벤트는 뷰 티어에만 영향을 주며 애플리케이션의 뷰 파트에 의해서만 처리된다.

반면에, form submit 같은 것은 MVC 아키텍처의 컨트롤러로 가게되며, 즉, "이 특정한 submit(전송) 버튼은 비즈니스 로직으로 처리해야 되겠음"이라고 판단하는 뷰 티어를 필수적으로 거치게 된다.

이 때가 JavaServer Faces 배후에 때때로 스트럿츠 같은 컨트롤러가 필요한 경우이며, 이는 트리 노드를 관리하고 열고 닫는 대신 이제는Java Database Connectivity rowset를 획득하고 트랜잭션을 포함하는 데이터베이스를 업데이트하기 때문이다. 따라서 사용자는, 사용자 인터페이스 이벤트가 아니라 애플리케이션 레벨의 이벤트를 처리한다. 즉 사용자 인터페이스 이벤트를 처리하는 프론트 컨트롤러로서의JavaServer Faces와 그 배후에 어떤 비즈니스 로직을 불러올 것인지 확인하는 애플리케이션 컨트롤러로서의 스트럿츠가 공존하는 것이 바로 스트럿츠/JavaServer Faces 통합 라이브러리가 제안하는 모델이다.

그렇다면 JavaServer Faces는 어는 방향으로 나아가고 있는가?

단기적과 장기적으로 볼 수 있다 . 우선, JavaServer Faces와 JavaServer Pages는 구문론(syntax)과 의미론(semantics) 면에서는 매우 유사하면서도 두세 가지의 중대한 차이점을 가지는 표현 언어를 제공한다는 점을 발견할 수 있다. 따라서 단기적으로는, JavaServer Faces 1.2와 JavaServer Pages 2.1의 전문가 그룹들이 페이지 제작자가 단지 하나의 언어만 알아도 될 수 있게 이 두 가지 표현 언어를 접목시키고 있다.

둘째 , JavaServer Faces API는 Java 2 Platform Enterprise Edition 5.0에 포함될 것이다. 따라서 JavaServer Faces로 개발된 애플리케이션은 J2EE 5.0 애플리케이션 서버에 이미 JavaServer Faces가 설치되어 있는 것으로 가정할 수 있으며, 이는 API에 대한 적법성의 징표라 할 수 있을 것이다. 따라서 장기적으로 JavaServer Faces가 제공하는 기능을 강화하고, 가능하다면 기본 API에 포함되는 표준 컴포넌트의 수를 늘리는 것이 목표이다.

자바 스튜디오 크리에이터 애플리케이션 개발 툴에 대해 설명한다면 ?

자바 스튜디오 크리에이터의 로드맵에도 단기와 장기의 목표가 있습니다 . 단기적으로 볼 때, 후속 릴리즈에 대한 우리의 초점은 초기 1.0 버전 사용자들의 피드백에서 제기된 사용성 문제를 해결하는 것이다. 우리는 또한 두 가지 흥미로운 신기능을 추가할 계획이다. 첫째, Java Database Connectivity 데이터베이스 또는 웹 서버와 커뮤니케이션하는 방법과 동일한 방식으로 세션 Enterprise JavaBeans를 데이터 소스로 소비할 수 있게 할 계획이다. 이제 우리는 EJB를 자바 스튜디오 크리에이터 IDE를 통해 컴포넌트에 바운드되는 정보에 대한 소스로 사용할 수 있을 것이다.

"자바 스튜디오 크리에이터에서 JavaServer Faces가 구현되는 방식을 활용하여 차세대 애플리케이션 프레임워크가 지녀야 할 모습을 정교하게 다듬어가고 있는 중이다." - 크레그 맥클라나한 썬마이크로시스템즈 수석 엔지니어

둘째 , 컴포넌트 개발자들이 설계 시에 풍부한 동작을 제공할 수 있도록하는 API를 발표할 계획이다. 개발자들이 자바 스튜디오 크리에이터를 흥미롭게 생각하는 점 중 하나는 풍부한 설계 환경과 관련이 있는데, 예를 들어 사용자가 Data Table 컴포넌트를 가지고 있고 그 위에 JDBC rowset 테스트를 드롭할 경우 컴포넌트는 즉시 해당 rowset에 있는 컬럼에 적응하게 되며, 이는 일련의 자바 스튜디오 크리에이터 전용의 설계 타임 API들을 통해 이루어진다. 우리는 표준 자바 스튜디오 크리에이터 컴포넌트를 채택하고 그를 중심으로 이런 멋진 설계 타임 동작을 구현했다. 앞으로 써드파티 컴포넌트 개발자들이 각자의 컴포넌트를 위해 자바 스튜디오 크리에이터 IDE와 동일한 종류의 풍부한 설계 환경을 창출할 수 있도록 API들을 발표할 것이다.

자바 스튜디오 크리에이터 포럼에서 가장 자주 등장하는 질문은 아마도 "컴포넌트를 구축하려면 어떻게 해야 하나요?"일 것이다. 컴포넌트에 대한 관심들이 엄청나기 때문에 우리는 써드파티 컴포넌트를 자바 스튜디오 크리에이터 IDE에 “가져오기”하는 기능에 초점을 맞추고 있다.

자바 스튜디오 크리에이터 IDE에서 새로 변경된 내용으로 어떤 부류의 개발자들이 혜택을 입게 되나?

자바 스튜디오 크리에이터 IDE는, 효율적인 업무 처리가 필요하면서 때로는 생산성 향상을 위해 자바 플랫폼의 우수성을 필요로 하는 기업 개발자들을 겨냥하고 있다. 그들에게 있어서 이런 우수한 오브젝트를 코드나 API를 통해서가 아니라 시각적으로 처리할 수 있다면 더욱 큰 도움이 될 것이다. 이는 우리가 자바 스튜디오 크리에이터 IDE를 처음 설계할 당시부터 초점을 맞춘 부분이기도 하며, 또한 자바 플랫폼의 우수한 기능을 액세스할 수 있도록 하기 위해 그 사용성을 대폭 개선하고있는 부분이기도 하다.

새로운 변경사항들을 통해 그동안 비주얼 개발자들이 기대했던 바와 같이 자바 스튜디오 크리에이터 IDE에 통합이 가능한 다양한 써드파티 컴포넌트를 제공할 수 있게 되었다. 이 툴은 생산적인 설계 및 개발 환경을 제공한다는 점 외에도 툴 자체와 기존의 제품 모두에서 타 벤더들이 제공하는 일련의 사전 제공 기능을 갖추고 있다. 이로써 비주얼 개발자들은 작성해야 할 코드의 분량을 크게 줄일 수 있게된다. 써드파티 컴포넌트 벤더들과 협력하고 그들로 하여금 자바 스튜디오 크리에이터 IDE를 각자의 JavaServer Faces 컴포넌트를 위한 툴로 선택하도록 하여 통합을 유도하는 과정에서 우리는 자바 스튜디오 크리에이터 IDE를 둘러싼 분야를 확고히 하고자 한다.

JavaServer Faces 기술은 자바 API와 2개의 JSP 커스텀 태그 라이브러리 등 두 가지 주요 컴포넌트로 구성되므로, 자바 스튜디오 크리에이터 IDE의 새로운 기능이 이를 잘 처리할 수 있을 것으로 생각된다. 자바 스튜디오 크리에이터는 자바 API 및 JSP 커스텀 태그 라이브러리와 관련하여 JavaServer Faces 사용자에게 어떤 이점을 제공하나? 또, 이와 관련하여 개발자들은 알아두어야 할 사항은 무엇인가?

자바 스튜디오 크리에이터 IDE는 NetBeans 상에서 구축되었으므로, 이를 기반으로 한 개발자들에게 가장 큰 도움을 준다. NetBeans는 사용자가 굳이 알 필요가 없는 것들을 감춰주는code completion과 code folding 같은 우수한 기능을 갖고 있다. 예를 들어, 일반적으로 개발자는 자기가 원하는 메소드 이름이 getF로 시작한다는 것만 알고 나머지는 모를 수 있다. 이럴 때는 getF만 입력하면 code completion 기능이 자동으로 나머지를 처리하게 된다. JavaServer Faces API는 모든 메소드 이름이 실제로 수행하는 작업을 명확하게 기술하도록 설계되었다. 그리고 이는 code completion과 결합되어 JavaServer Faces 오브젝트 처리를 위해 이벤트 핸들러에서 요구하는 코드를 쉽게 입력할 수 있게 해준다.

이는 다른 설계 원칙에도 부합되어 , HTML을 표시하거나HTTP 트랜잭션을 처리하는 일과 관련된 복잡성을 가능한한 컴포넌트 내부에 숨김으로써 애플리케이션 개발자가 이를 처리할 필요가 없도록 한다. 그리고 바로 이 때가 변환이나 검증 같은 복잡성을 처리하기 위해 JavaServer Faces가 사용되는 때이다. 한편, 비(非) JavaServer Faces 애플리케이션 환경에서는 개발자가 모든 로직을 일일이 작성하거나, 프레임워크를 이용하여 특수한 기능을 제공해야 한다.

"JavaServer Faces API는 Java 2 Platform Enterprise Edition 5.0에 포함될 것이다" - 크레그 맥클라나한 썬마이크로시스템즈 수석 엔지니어

그러므로 JavaServer Faces는 MVC 아키텍처의 복잡성을 숨긴다는 점에서 스트럿츠를 능가한다고 할 수 있다. JavaServer Faces개발자들로 하여금 그 배후에 있는 자바 API와 태그 라이브러리를 배우도록 강요하는 대신 실제로 처리할 필요가 있는 이벤트 핸들러와 자바 소스 코드의 부분들로 직접 인도하는 역할을 하게 되는 것이다.

간단한 예로 , JSP 소스를 살펴볼 때 JSP 페이지의 버튼은 커스텀 태그처럼 보인다. 그러나, 이것을 설계자(designer)에서 살펴보면 실제 버튼이 런타임 시와 정확히 동일하게 표시되는 것을 볼 수 있다. 설계자에서 버튼을 더블 클릭하면 자바 스튜디오 크리에이터 IDE가 즉시 해당 버튼의 이벤트 핸들러로 사용될 메소드로 이동시킨다. 이런 일련의 과정이 어떻게 이루어지는지 모두 알 필요는 없으며, 단지 몇 행의 코드를 작성하여 이 버튼을 눌렀다는 사실을 처리하기만 하면 JavaServer Faces가 대신 적시에 해당 메소드를 호출하게 되는 것이다.

즉 , 자바 스튜디오 크리에이터 환경에 시각적 직관성을 최대한으로 부여하는 데 초점을 맞추고 있다고 볼 수 있나?

그렇다 . 우리의 초기 목표는 표준 JavaServer Faces 컴포넌트를 택하고 그를 중심으로 시각적인 환경을 구축하는 것이었다. 따라서 우리는 사람들이 JavaServer Faces 컴포넌트를 사용할 때 어떤 점이 혼동 되는지 파악하기 위해 잠재적 사용자들을 심도 있게 조사했고 사용성 을 연구했다. JSP 페이지는 물론이고 자바 클래스를 작성할 때에도 유념할 일은 추상적으로 생각해야 한다는 것, 즉 코드를 살펴보면서 머리 속에서 아웃풋이 어떤 모습이 될지 시각화해야 한다는 것이다. JavaServer Faces에서 실제로 처리하고 있는 것이 마음속의 모델과 정확하게 일치해야 한다. 직사각 형태로 문자가 적혀 있는 버튼을 생각해 보자. 정확한 형태를 구성하고 해당 컴포넌트를 선택하여 버튼 위의 라벨을 처리하고 배경 색상을 처리하는 등의 모든 일을 시각적으로 처리할 수 있어야 한다.

우리는 이 툴의 초기 버전을 표준 JavaServer Faces 컴포넌트를 중심으로 만들었다. 이어서 우리는 이런 시각적 처리 패러다임인 WYSIWYG(위지위그, what you see is what you get)에 초점을 맞추게 될 향후 버전의 자바 스튜디오 크리에이터를 위한 일련의 추가 JavaServer Faces 컴포넌트를 계획하고 있다. 아울러 트리 컨트롤, 포터블 테이블 등과 같은 번거로운 작업들을 처리하는 백엔드 동작을 더욱 정교화할 것이다.

JavaServer Faces와 자바 스튜디오 크리에이터 기술에 관해 개발자들로부터 어떤 피드백을 얻고 있는가?

자바 스튜디오 크리에이터 IDE는 웹 애플리케이션에서 더 나은 사용자 인터페이스를 구축하여 유비쿼터스 브라우저를 활용할 수 있을 뿐만 아니라, IT 관리자들이 조직 전반에 걸친 수천 대의 PC에 대해 배치 작업을 수행하지 않고도 새로운 버전의 애플리케이션을 제작할 수 있게 해주기 때문에 많은 개발자들이 사용하고 있다. 애플리케이션 개발에 있어서 현재 대세는 복잡해지곤 하는 레거시 시스템 등에서 웹 프론트 엔드를 구축하여 인트라넷과 인터넷에 사용이 쉬운 인터페이스 제공하는 것이다.

개발자들은 프로토타이핑 (또는 신속한 애플리케이션 개발)으로부터 분야별 애플리케이션의 구축에 이르기까지 어떤 경우에나 자바 스튜디오 크리에이터를 사용하고 있으며, 일부 개발자들은 보다 정교화된 써드파티 컴포넌트를 이용할 수 있게 됨에 따라 좀더 복잡한 애플리케이션을 구축할 수 있게 되었다. 앞으로 더욱 많은 발전이 있을 것으로 기대된다.