가끔 개발자분들께서 어설프게 나무를 보고 "본인은 숲을 보았노라"라고 이야기하는 걸 많이 봅니다. 나무 한 그루가 소나무라고 해서 그 숲 전체가 소나무일 것이라고 생각하는 것, 즉 추측은 절대 있어서는 안됩니다.
또한 남이 본 숲을 마치 자신이 본 것처럼 이야기하고 다녀서도 절대로 안됩니다.
삼성SDS의 Anyframe는 프레임워크라고 하는 데 진짜 프레임워크일까? 아무래도 유틸리티성 컴포넌트, 플러그인 정도로밖엔 안보이는데 왜 이렇게 계열사에 목숨을 거는 걸까?뭐 저런 생각을 해보았습니다.
제가 조사해 본 결과 Seam은 OSGi를 지원치 않는 것으로 알고 있습니다.
Web 개발에는 장점은 있는데 OSGi 처럼 Modular Loading과 Versionning 기능이 필요 합니다.
이 부분 확인 부탁 드립니다.
기본적으로 EJB를 전혀 사용치 않고 Spring 처럼 Light한 체제로 이동하는 것이 개발성이 좋은데 이에 대해 Seam 관점에 장점을 무엇 일까요?
우선 궁금해하신 사항을 요약해보겠습니다.기선님의 코멘트로 Spring MVC를 Spring Web Flow로 변경하였습니다.
1. JBoss Seam의 장점이 무엇인가?
2. JBoss Seam과 Spring의 차이점.
3. JBoss OSGi 지원(현재 및 향후) - JBoss OSGi 1.0.0.Beta4는 현재 OSGi Release 4.2(R4.2)를 지원하고 있으며 Seam과는 별개입니다.
우선 2, 3번은 technical 하게 다시 정리하도록 하겠습니다.
글이 조금 장황하게 쓰여질 수도 있으나 우선 Seam이 Java EE 기술중에 환영받지 못했던 JSF와 EJB를 사용한다는 점에서 lightweight를 표방하고 있는 Spring에 비해 사용률이 적다는 것은 충분히 공감할 수 있는 사항입니다. 하지만 JVM의 기술이 올라가고 Java EE의 스펙에 바뀌면서 EJB는 더 이상 사용하기 어려운 애플리케이션 프레임워크가 아니라고 보시는 편이 좋을 것 같습니다. EJB 자체도 이미 POJO 형태로 넘어온 상태이며 성능 테스트를 진행하더라도 차이는 거의 없다고 보시면 됩니다. EJB가 무겁고 사용하기 어렵다는 것은 그저 EJB 2.0의 폐해(리모트 구조, 수많은 인스턴스 생성 등)로 인한 근거 없는 통념(myth)에 불과하다고 볼 수 있습니다.(Seam에서 애플리케이션과 퍼시스턴스 레이어에 EJB는 선택사항일 뿐입니다.) 따라서 이는 Seam을 도입해도 되는 충분한 이유가 될 수 있다고 여겨집니다.
하지만 Seam은 웹 애플리케이션 개발시에 모든 레이어를 일관되게 연결시키는 것으로써 Spring자체보다는 Spring Web Flow와의 비교에 초점을 맞춰야 하는 것이 맞을 것 같습니다. 즉 Spring의 애플리케이션 프레임워크를 생각하신다면 비교 대상은 Seam이 아니라 오히려 JBoss Microcontainer로 보는 편이 훨씬 더 타당할 것이라는 의견을 드립니다.
즉 질문하신 내용 중 '기본적으로 EJB를 전혀 사용치 않고 Spring 처럼 Light한 체제로 이동하는 것이 개발성이 좋은데 이에 대해 Seam 관점에 장점을 무엇 일까요?' 의 답변이 JBoss MicroContainer라고 결론으로 귀결이 됩니다.
JBoss Microcontainer는 EJB를 사용하지 않으면서 Spring과 유사한 구조를 가지는 애플리케이션 런타임 엔진으로 보시면 됩니다. JBoss OSGi는 Seam이 아닌 JBoss MicroContainer를 활용하여 대상 번들을 deploy, undeploy, redeploy하는 것이 가능합니다.
제가 이해한 바로 원하시는 결론(저는 웹이 아닌 애플리케이션 프레임워크 + OSGi로 이해했습니다)에 도달하시려면 JBoss MicroContainer + JBoss OSGi가 원하시는 내용이 아닌가 싶습니다.
간략하게 요약하자면 다음과 같습니다.
Spring Core == JBoss MicroContainer
Spring Web Flow== JBoss Seam
SpringDM == JBoss OSGi
첨부드리는 파일은 Gavin King이 Seam의 핵심 기능으로 발표하는 Web Beans(JSR-299)에 대한 슬라이드입니다. 기술적으로 작성한 슬라이드이지만 도움이 되셨으면 합니다.
도움이 되셨을지 모르겠습니다. 금요일에 오시면 Gavin으로부터 자세한 내용을 들으실 수 있도록 하겠습니다.
Sorry for my silence. I have been translated "Seam in Action" into Korean for the last three months. It quite knocked me out and made me crazy.
Three employees who are related in JBoss took part in translation work. 'Seam in Action' in Korean will come out on Nov. 4 before Gavin King, founder of Hibernate and Seam, comes to Korea.
Below is Dan's greeting message to Korean developers. Dan Allen is the author of "Seam in Action".
Since Seam in Action was first published, I've been approached by many developers gushing with enthusiasm to share with me that my book has fundamentally changed their understanding of Seam. They reported that, as a result, they've witnessed a huge boost in their productivity. Their one regret: they didn't discover it sooner. Each time, all I can manage to say in return is, "That's exactly why I wrote this book." And that's why I want you to read it. I want you to receive the same benefits. I'm so grateful to Ji-Woong Choi and his colleagues for translating this text into Korean and beginning to diffuse the knowledge packed inside Seam in Action around the global.
I was a fairly early adopter of Seam and I immediately recognized it as the missing piece of Java EE. It patches many of the technical gaps in Java EE, such as invoking an EJB directly from JSF and properly managing the extended persistence context. But it also reveals a lot of academic gaps in developers' understanding of Java EE concepts and technologies.
When you learn Seam, you aren't just learning about this one framework, which is hard enough, but rather Java EE as a whole. That's why Seam can appear so daunting. With this delimma in mind, I wrote this book. It walks through the JSF life cycle and it's shortcomings. It explains how Facelets fits into the picture. It carefully molds your understanding of the persistence context and teaches you how to respect it properly. It demystifies EJB JNDI names and how Seam resolves them. Finally, with all of these core concepts covered, the book broadens your development skills by covering Seam's third party integrations with libraries such as iText for PDF generation and jBPM for business process management.
I believe it's because I was once in your position, a person trying to learn about all the pieces of Java EE and how Seam helps them fit together, that readers have found this book to be an invaluable resource. Take this book, now translated in your native language, and use it to learn how to drive your Seam applications further.
Dan Allen
Senior Software Engineer
Red Hat, Inc.
Seam이란?
JBoss Seam은 J2EE 5.0에 대한 lightweight 프레임웍입니다. 이것의 의미는 무엇일까요? J2EE 5.0 자체가 "프레임웍"들의 모임아닙니까? J2EE 표준이외에 또 다른 것이 왜 필요할까요?
JBoss Seam은 J2EE 5.0에서 간과한 프레임웍이라고 할 수 있습니다. Seam은 J2EE 5.0 프레임웍 위에서 엔터프라이즈 웹 어플리케이션의 모든 컴포넌트에 대한 일관적이며, 이해하기 쉬운 프로그래밍 모델을 제공합니다.
또한 Stateful 어플리케이션과 프로세스-기반 어플리케이션 개발이 쉽도록 합니다. 다시 말해, Seam은 개발자의 생산성과 어플리케이션 확장성을 위한 것입니다.
1. J2EE 프레임웍의 통합과 확장
J2EE 5.0의 중요 프레임웍은 EJB(Enterprise JavaBeans) 3.0과 JSF(JavaServer Faces) 1.2 입니다. EJB 3.0은 POJO(Plain Old Java Objects)기반의 비지니스 서비스와 데이터베이스 저장을 위한 lightweight 프레임웍입니다.
JSF는 웹 어플리케이션을 위한 MVC(Model-View-Controller) 컴포넌트입니다. 대부분의 J2EE 5.0 웹 어플리케이션은 비지니스 로직을 위한 EJB3 모듈과 사용자 인터페이스를 위한 JSF 모듈로 구성되게 될 것입니다. EJB3와 JSF가 서로 에 대해 보완하는 역할을 하지만, 각각 다른 철학에 따라 각자 설계되어진 프레임웍입니다. 예를 들면, EJB3는 서비스를 구성하기 위해 주석(annotation)을 사용합니다. 반면에 JSF는 XML파일들을 사용합니다. 게다가 EJB3와 JSF 컴포넌트는 프레임웍 레벨에서 서로에 대해 인식하지 못합니다. EJB3와 JSF를 함께 사용할 수 있게 하려면, 비지니스 컴포넌트를 웹페이지에 연결시켜주는 JSF backing Beans같은 facade 객체들과 프레임웍에 걸쳐서 메소드콜을 하는 판에박힌 코드들을을 만들어야 합니다.
EJB3와 JSF같은 기술들을 결합시키는 것이 Seam의 목표 중에 하나입니다. Seam은 일관된 주석(annotaion)기반의 방식으로 EJB3와 JSF를 연결합니다. EJB3에 간단한 몇개의 주석을 추가하여 Seam에서 EJB3 비지니스 컴포넌트를 JSF 웹 폼에서 직접사용하거나 웹 UI 이벤트를 처리할 수 있게 됩니다. Seam은 EJB3 뿐만 아니라 같은 방식으로 POJO에 주석을 달거나, 어플리케이션 컴포넌트에 대해서 사용할 수 있습니다. 다른 웹 프레임웍으로 개발한 어플리케이션과 비교할 때, Seam 어플리케이션은 같은 기능에 대해, 단순하고 적은 양의 Java/XML 코드가 필요합니다.
Seam은 JSF에서 하기 힘들었던 일들을 쉽게 할 수 있도록 합니다. 예를 들면, JSF의 주요 불만중의 하나는 HTTP POST에 너무 많이 의존한다는 것인데, 이렇케 하면 JSF 웹 페이지를 북마크하기하기 힘들어집니다. Seam에서는 북마크가 가능한 RESTful 웹페이지를 쉽게 생성해낼 수 있습니다. Seam은 또 JSF 어플리케이션을 만드는데 필요한 많은 JSF 컴포넌트 태그와 주석을 제공합니다.
동시에 Seam은 EJB3 컴포넌트 모델을 POJO로, Stateful 컨텍스트를 웹 계층에서 비지니스 컴포넌트까지 사용할수 있게 합니다. 게다가 Seam 은 jBPM, JBoss Rules(Drools), JBoss Portal, JBoss Microcontainer등 뛰어난 오픈소스 프레임웍들을 통합합니다. Seam은 단순히 이런 프레임웍을 연결하는 것이 아니라 JSF + EJB3 결합과 같은 방식으로 프레임웍을 확장합니다.
비록 Seam이 J2EE 5.0에 기반하였지만, J2EE 5.0 서버에서만 국한되어 사용되는 것은 아닙니다. Seam 어플리케이션은 Tomcat과 같은 J2EE 1.4 어플리케이션 서버에서도 사용할 수 있습니다.
1 + 1 > 2
여러가지 프레임웍들을 연결하는 또 다른 통합 프레임웍으로 생각하는 것은 Seam을 잘못 이해하는 것입니다. Seam은 주석, EL(Expression 언어) 표현식등을 통해서 프레임웍들을 긴밀히 연결할 수 있게 하는 프레임웍으로 자신의 Stateful 컨텍스트를 관리하고 있습니다. 이런 통합 수준은 Seam개발자들의 다른 프레임웍들에 대한 전문 지식이 있기에 가능했던 것입니다.
2. ORM을 이해하는 웹 프레임웍
객체 관계 매핑(ORM) 솔루션들은 현재 엔터프라이즈 어플리케이션에 널리 사용되고 있습니다. 그러나, 대부분의 현재 비지니스나 웹 프레임웍은 ORM이 설계에 고려되지 않고 있습니다. 대부분의 프레임웍들은 요청이 들어오는 것부터 결과가 완전히 렌더링 될때 까지의 전체 웹 상호작용(interaction)동안 persistence 컨텍스트를 관리하지 않습니다. 그결과 지긋지긋하게 보는 LazyInitializationException을 포함해서 다양한 종류의 ORM에러들을 발생시킵니다. 그래서 "데이터 전송 객체(DTO)"같은 이상한 방식을 사용하게 합니다.
Seam은 세상에서 가장 유명한 ORM 솔루션중 하나인 Hibernate를 만든 Gavin King에 의해서 만들어졌습니다. Seam은 기반부터 ORM의 Best Practice를 사용하도록 장려하게 설계되었습니다. Seam을 사용하면, DTO같은 객체를 작성할 필요가 없으며, lazy 로딩도 잘 작동합니다. 그리고 persistence 컨텍스트가 데이터베이스까지 가는 횟수를 줄이는 캐시처럼 동작하여 ORM 성능이 매우 향상될 수 있습니다.
또한, Seam이 ORM 계층과 비지니즈, 프리젠테이션 계층을 통합하기 때문에, ORM 객체를 직접 표시할 수 있고, 데이터베이스 검사 주석(validator annotation)을 입력 폼에 사용할 수 있고, ORM 에러를 사용자 에러 페이지로 redirect할 수 있습니다.
3. Stateful 웹 어플리케이션을 위한 설계
Seam은 Stateful 웹 어플리케이션을 위해 설계되었습니다. 웹 어플리케이션은 본래 멀티-사용자 어플리케이션이며, 전자상거래 어플리케이션은 본래 stateful이며 트랜잭션인 특성이 있습니다. 그러나, 대부분의 웹 어플리케이션 프레임웍들은 기본적으로 stateless 에플리케이션을 만들도록 하고 있습니다. 사용자 상태를 관리하려면 HTTP 세션 객체로 직접 작업해야 했습니다. 이런 작업은 핵심 비지니스 로직과는 상관없는 일이며, 성능이슈도 일으킬 수 있습니다.
Seam에서는 모든 기본 어플리케이션 컴포넌트들이 본래 stateful 입니다. 명시적으로 Seam에서 상태가 관리되기 때문에 HTTP 세션을 사용하는 것 보다 훨씬 편리합니다. 복잡한 상태 관리 코드를 작성할 필요가 없습니다. 범위, 생명주기(lifecycle) 메소드, 다른 stateful 프로퍼티에 주석을 사용하기만 하면 Seam이 나머지는 처리합니다. Seam의 Stateful 컴포넌트는 일반 HTTP 세션보다 더 상세한 상태를 관리해 줍니다. 예를 들어 HTTP 세션내에 일련의 웹 요청과 비지니스 메소드 호출로 구성되는 여러 개의 "conversations"을 가질 수 있습니다.
또, 데이터베이스 캐시와 트랜잭션은 어플리케이션 상태와 연결됩니다. Seam은 자동으로 데이터베이스 update를 메모리에 가지고 있다가, conversation이 끝나면 데이터베이스에 commit 합니다. 메모리내 캐시는 복잡한 stateful 어플리케이션의 데이터베이스 부하를 상당히 줄여줍니다.
웹 어플리케이션내의 상태관리는 오픈소스 JBoss jBPM 비지니스 프로세스 엔진과 연결을 지원함으로 큰 진전 있습니다. 조직내의 다른 사람들의 워크 플로우를 지정할 수 있거나, UI 이벤트 핸들러와 데이터베이스에만 의존하지 않고 어플리케이션이 진행하는데 워크플로우를 이용할 수 있습니다.
4. 웹 2.0 지원
Seam은 웹 2.0 스타일 어플리케이션에 최적화되어 있습니다. AJAX(Asynchronous JavaScript And XML) 기술을 다양한 방법으로 지원합니다. JavaScript없는 AJAX 컴포넌트, AJAX가능한 기존 JSF 컴포넌트, JavaScript 객체로 브라우저에서 Seam 서버 컴포넌트로 직접 접근할 수 있는 사용자 JavaScript 라이브러리를 사용할 수 있습니다. 내부적으로 Seam은 같은 사용자로 부터의 여러개의 AJAX 요청을 효율적으로 관리할 수 있는 진보된 동시처리 모델을 제공합니다.
AJAX 어플리케이션의 큰 도전은 데이터베이스 부하의 증가입니다. AJAX 어플리케이션은 일반 어플리케이션 보다 서버에 훨씬 더 자주 요청을 보냅니다. 이런 AJAX 요청을 데이터베이스에서 처리해야만 한다면, 데이터베이스가 이런 부하를 감당할 수 없을 지 모릅니다. Seam의 Stateful 저장 컨텍스트는 메모리내 캐시로 동작합니다. 오랜시간 지속되는 conversation 정보를 보관하여 데이터베이스까지 가는 것을 줄일 수 있습니다.
웹 2.0 어플리케이션은 그 데이터 측면에서 복잡한 관계 모델을 사용하는 경향이 있습니다. 예를 들어 소셜네트워크 사이트는 "사용자"간의 관계 정보를 관리하고 표현해 주는 일을 합니다. 이런 사이트에 대해서는 ORM 계층의 lazy 로딩은 결정적인 것입니다. 안그러면, 하나의 쿼리가 전체 데이터베이스를 단계적으로 로딩하는 결과를 낳을 수 있습니다.
Seam은 웹 어플리케이션에 대한 lazy 로딩을 정확히 지원하는 유일한 웹 프레임웍이라고 할 수 있습니다.
5. Dependency Bijection을 통한 POJO서비스 사용
Seam은 POJO(Plain Old Java Objects)를 서비스 컴포넌트로 사용할 수 있기 때문에 더욱 "lightweight 프레임웍"이라고 할 수 있습니다. 어플리케이션에 컴포넌트를 포함시키기 위한 프레임웍 인터페이스나 추상 클래스가 필요하지 않습니다. 물론, 이 POJO가 어플리케이션을 구성하기 위해 어떻게 서로 상호작용하는지 질문이 있을 것입니다. 어떻케 데이터베이스 저장(persistence) 서비스와 같은 컨테이너 서비스와 상호작용할 수 있을까요? Seam은 POJO 컴포넌트들을 잘 알려진 "Dependency Injection(DI)"라는 디자인 패턴을 사용하여 연결합니다. 이 패턴을 사용하여 Seam 프레임웍은 모든 컴포넌트의 생명주기(lifecycle)을 관리할 수 있습니다. 컴포넌트가 다른 것을 사용하고 싶으면, 주석을 사용하여 Seam에 dependency을 선언합니다. 그러면, Seam은 현재 어플리케이션 상태에서 의존하는 컴포넌트를 어디서 가져올 지를 판단하고, 요청한 컴포넌트에 "injects(주입)"해 줍니다.
Dependency injection 개념을 확장하여, Seam 컴포넌트 A는 또 다른 컴포넌트 B를 생성할 수 있으며, 생성된 컴포넌트 B를 컴포넌트 C 같은 다음에 사용할 다른 컴포넌트를 위해 Seam에게 "outjects"해 줍니다.
이런 형태의 양방향 dependency 관리는 가장 간단한 Seam 웹 어플리케이션이더라도 널리 사용됩니다.
Seam에서는 이것을 "Dependency bijection"이라고 합니다.
6. 예외로 설정(Configuration by Exception)
주요 설계 원칙중에 Seam을 사용하기 편리하게 하는 것이 "예외로 설정"하는 것 입니다. 아이디어는 컴포넌트에 대한 기본 동작 집합을 가지고 있는 것입니다. 개발자는 원하는 기본 동작을 하지 않을 때에만 명시적으로 컴포넌트를 설정하면 됩니다. 예를 들어, 컴포넌트 A가 컴포넌트 B의 프로퍼티를 inject한다면, 컴포넌트 A의 Seam 이름은 받는 컴포넌트 B의 프로퍼티가 기본값이 됩니다.
Seam에는 이런 사소하지만 편리한 것들이 많습니다. 전반적으로 Seam의 메타데이터 설정은 다른 Java 프레임웍과 비교하여 훨씬 단순해집니다. 결과로 대부분의 Seam 어플리케이션은 적은 개수의 Java 주석으로 충분히 설정될 수 있게 됩니다. 개발자는 복잡성이 감소하고, 결론적으로 다른 프레임웍에서 개발한 같은 기능과 비교하면 훨씬 더 작은 양의 코딩만 하면 됩니다.
7. XML 남용을 피한다
이미 설명했던 것처럼, Java 주석은 Seam 설정 메타데이터를 표현하고 관리하는데 중요한 역할을 합니다. 설계상에 프레임웍을 사용하기 편리하게 만들어 줍니다.
J2EE의 초기엔 XML은 설정 관리을 위한 "성배(holy grail)"로 여겨졌습니다. 프레임웍 설계자들은 Java 클래스와 메소드이름 등 모든 종류의 설정 정보를 개발자에게 돌아갈 일에 대해 많은 생각없이 XML파일에 넣었습니다. 돌아보면 이것은 큰 실수라고 할 수 있습니다. XML설정은 매우 반복되는 작업입니다. 개발자들은 이미 코드에 있는 정보를 반복적으로 코드와 설정을 연결하기 위해 사용해야 했습니다. 이런 반복작업은 에플리케이션에서 사소한 에러들을 만드는 경향이 있습니다. 설정파일의 클래스 이름 타이핑 오류는 Runtime시 매우 디버그하기 힘든 오류로 나타납니다.
적당한 기본 설정이 부족한 것도 이런 문제들 더 복잡하게 합니다. 사실, 어떤 프레임웍에서는 상당한 양의 틀에 박힌 XML 코드들이 실제 Java 코드와 비슷하거나 더 많을 수도 있습니다. J2EE 개발자들은 이런 XML의 남용을 "XML hell"이라고 말합니다.
엔터프라이즈 Java 커뮤니티는 XML 남용을 인식하고, XML 파일들을 Java 소스내의 주석으로 성공적으로 대체하고 있습니다. EJB3는 공식적인 Java 표준화 기구의 Java 엔터프라이즈 Java 컴포넌트에서 주석을 장려하는 노력의 성과입니다. EJB3에서 XML 파일들을 사용하는 것은 선택사항입니다. 이런 작업은 확실히 올바른 방향으로 나아가는 것이라 생각합니다. Seam은 EJB3 주석에 추가하여 주석-기반 프로그래밍 모델을 전체 웹 어플리케이션으로 확장합니다.
물론, XML은 설정 데이터에 대해 전적으로 나쁜 것 많은 아닙니다. Seam 설계자들은 XML을 웹 어플리케이션의 페이지 플로우나 비지니스 프로세스의 워크 플로우를 정의하는데 사용하고 있습니다. 반대로 Java 소스내에 분산되어 있는 정보들을 XML파일에서 전체 어플리케이션의 워크 플로우를 중앙에서 관리하게 합니다. 워크플로우 정보는 Java 소스코드와 덜 연결되도록 합니다. 그래서 XML 파일에는 소스 코드에 이미 있는 정보를 중복해서 입력하지 않도록 합니다.
8. 테스트를 위한 설계
Seam은 기반부터 쉽게 테스트할 수 있도록 설계되어 있습니다. Seam의 모든 컴포넌트는 주석붙인 POJO이기 때문에 Unit 테스트를 실행하기 매우 쉽습니다. POJO 인스턴스를 Java의 new 키워드를 이용하셔 생성하고 JUnit, TestNG같은 테스팅 프레임웍에서 어떤 메소드나 실행하면 됩니다. 여러 개의 Seam 컴포넌트들 간에 상호작용을 테스트하고 싶다면, 각각의 컴포넌트를 초기화하고 각 컴포넌트 간의 관계를 직접 설정해 주면 됩니다. Seam의 Dependency Injection기능에서 사용하는 것 대신에 setter 메소드를 사용하시면 됩니다.
전체 Seam 어플리케이션의 통합 테스팅을 위해선, Seam 컨테이너내에서 어플리케이션을 실행해야 하기 때문에 좀더 복잡해집니다. Seam은 임베딩가능한 lightweight 컨테이너를 제공하여 이런 형태의 테스팅을 도와줍니다.
사용하시는 테스트 프레임웍에서 Seam 컨테이너를 프로그램에서 로딩하고 테스팅을 실행하시면 됩니다.
9. 개발툴 지원
개발툴 지원은 어플리케이션 프레임웍에 대해선 개발 생산성 측면에서 필수적인 것입니다. Seam은 명령행 어플리케이션 생성기인 "Seam Gen"이 포함되어 배포됩니다. Seam Gen은 Ruby-On-Rails의 툴과 매우 유사합니다. 데이터베이스에서 완전한 CRUD 어플리키에션을 생상할 수 있는 기능을 제공합니다. "수정 /저장 / 리스트", 테스팅 지원 등 웹 어플리케이션 개발을 빠르게 합니다.
더 중요한 것은 Seam Gen은 널리 사용되는 Java IDE인 이클립스와 넷빈즈에서 사용할 수 있습니다. Seam Gen으로 쉽게 Seam을 시작할 수 있습니다.
또, JBoss Tools 프로젝트에서 이클립스에서 사용가능한 Seam 개발툴들을 제공합니다.
10. NO벤더 Lock-in
Seam은 J2EE 어플리케이션 개발자의 오버헤드를 단순화 할 수 있고, 동시에 J2EE 5.0에 새로운 기능을 추가합니다. 그러면, Seam은 JBoss에서만 동작하는 특별한 프레임웍일까 궁금증을 갖게 됩니다.
Seam은 어떤 WAS에서나 동작할 수 있습니다. JBoss 뿐만 아니라, WebLogic, WebSphere, Glassfish 같은 WAS에서도 사용하실 수 있습니다. 뿐만 아니라 EJB3 때문에 Tomcat에서는 사용하지 못할 것이라 생각하실 수 있지만, JBoss의 Embedded JBoss기능을 이용하면 Tomcat에서도 JBoss Seam을 사용하실 수 있습니다.
오늘은 프란시스 베이컨의 우상론이 갑자기 생각이 나서 개발자와 어떤 관계가 있을까 곰곰히 생각을 해보았습니다. 학교 다닐 때 배우신게 기억나실 것 같네요. 베이컨의 우상론은 4가지 오류에 대하여 이야기하고 있는데 종족의 우상, 동굴의 우상, 시장의 우상과 극장의 우상입니다.
개발자 혹은 IT와 관계된 우상론과 그것을 어떻게 타파할 수 있을지에 대한 궁금증이 슬그머니 나오게 되어 만득이(http://www.mandki.com)로 정리하고 글을 쓰네요.
첫째로 종족의 우상을 살펴볼까요. 우리의 인식 능력이 가진 한계로 인하여 사물을 판단하는 잣대를 동질감을 느끼는 종족에게 한정시켜 버리는 오류를 이야기합니다. 보통 개발자분들이 개발자 특유의 고집과 편견을 가지고 있는 게 많이 보입니다. 그저 개발자 집단은 늦게까지 일하고 청바지에 남방이나 티셔츠를 입는 모습을 상상하는 것 자체부터가 종족 오류가 아닐까 하는 생각이 듭니다. 그렇지 않은 사람이 더 많아진다고 해도 이미 사람들 사이에 그렇게 인식이 되어있기 때문에 선입견을 깨기란 상당히 힘이 들게 되겠지요. 문제는 이런 점을 타파하기가 상당히 어렵다는 것이죠. 스스로 인터넷이라는 거대 공간에 개발자 종족을 만들어 버렸기 때문입니다. 변화가 쉽지 않아보이는 영역 중에 하나입니다.
둘째는 동굴의 우상입니다. 개인의 좁은 경험, 습관, 생활 환경, 지식 등으로 인하여 생기는 인식의 오류 현상입니다. "역시 프레임워크는 스프링밖에 없어", "웹 프레임워크로 왜 Struts를 안쓰는데? 무조건 그게 최고야", "그 기술을 왜 쓰니? 쓸데 없어" 등등의 말이 될 수도 있겠습니다. 단순히 개발자 본인이 알고 있는 지식이나 경험에 의하여 프로젝트에 더욱 적합한 솔루션들이 있음에도 불구하고 본인 시야에 비친 일부를 전체라고 이야기하는 분들도 있을 겁니다. 이 세상은 항상 다양함이 존재하고 있고 스스로 보지 못한 더 넓은 영역이 존재할 수 있습니다. 결국 동굴이라는 곳에 갖혀 바라보는 창(window)의 크기가 동굴의 입구밖에는 안되는 문제가 발생을 합니다. 개발자의 아픔이라고 하면 새로운 프레임워크 지식들이 상당히 쏟아져 나온다는 겁니다. 내가 했던 것만을 할 것인지 아니면 시간을 내어 천천히 그것들을 살펴보고 프로젝트에 맞는 성격은 무엇인지 되돌아볼 수 있는 것은 상당한 차이가 있습니다. 나무를 바라보는 것에서 벗어나 숲을 볼 수 있는 능력을 키워야 하겠습니다.
세째는 시장의 우상입니다. 언어를 통해 의사 소통하는 과정에서 모호한 말이나 개념적인 설명이 틀릴 경우 나타나는 오류입니다. 스타 블로거나 유명 개발자가 이 오류에 빠졌을 경우 일반 개발자들은 이후에 설명하는 극장의 우상으로 변질될 수 있지 않을까 합니다. 개인적인 생각으로 한참 유행을 탈뻔(?)했던 SOA가 그 대표적인 케이스가 아닐까 합니다. 각 벤더의 마케팅 선전 문구의 SOA는 사실 추상적인 개념입니다. 소위 조직적인 체계가 만들어지지 않으면 구현하기도 어려울 뿐더러 프로젝트간 연결관계에서 재사용에 대한 상세 레벨을 어디까지 만들어야 하는지도 모릅니다. 결국 뜬 구름을 잡을 수도 있는 개념인데 벤더들이나 컨설팅 펌에서 마치 SOA를 적용하면 모든 것이 다 되는 것마냥 이야기함으로써 고객이 실제 구현체를 손쉽게 만들 수 있다고 착각속에 빠지게 합니다. 이제 SOA를 외치는 벤더는 국내에서 하나밖에 남지 않았습니다. 이 오류에서 벗어나려면 경험과 실험을 통해 얻은 결과가 무엇인지를 먼저 분석하고 자신의 회사에 맞게 적용하는 수밖에는 없습니다.
네째는 극장의 우상입니다. 정의를 말 그대로 옮기면 전통이나 권위에 의지한 지식이나 학문을 아무런 비판없이 받아들이는 현상입니다. 얘기가 조금 빗나가겠지만 대표적인 케이스가 조중동에 의한 휩쓸리기일 수도 있겠네요. 조작임을 알면서도 실제처럼 믿어버리는 현상이 대표적일 겁니다. 앞서 이야기한 것처럼 "이 프레임워크에서 이 사람이 유명하니까 이 사람이 한 이야기는 무조건 맞을 거야~"라고 생각하는 게 대표적일 겁니다. 문제는 스스로 객관적인 지식을 얻으려 하지 않는 사람들이 이러한 오류에 빠지기 쉽다는 겁니다. 만약 groovy와 ruby를 가지고 고민을 하게 되었을 때 유명한 누군가의 글에 ruby가 최고입니다라는 이야기를 마치 진리인 것처럼 착각하고 믿어버리는 경우는 없어야겠습니다. 이 오류에서 벗어나려면 대상을 보는 자신만의 관점을 가지고 여러 면을 나름 객관적으로 분석할 수 있는 기술이 필요합니다. "왜?"라는 질문을 만들어내고 그것에 대한 해답을 얻지 못하면 스스로 판단의 오류에 빠질 수밖에 없을 겁니다. 의구심을 생활화하여 극장에서 빠져나올 수 있는 방법을 찾아야 하지 않을까요.
되도록 제가 가진 문제를 찾아보려 노력하는데 쉽지 않습니다. 제가 보기엔 이미 4가지 우상을 모두 경험하고 혹은 빠져있지 않나 생각합니다. 어떻게 하면 좋을까요.
|
