'2009/01'에 해당되는 글 6건
- 2009/01/19 스프링배치 국내 자료 모음
- 2009/01/13 Winter of Code 행사 공지
- 2009/01/12 [Spring batch] 스프링배치 연재(16) DB to XML 파일 만들기 예제
- 2009/01/05 [Beta 1.0] Spring Web-Flow 프레임웍 레퍼런스 한글화(편역). (3)
- 2009/01/02 올해의 스프링 기술 top5, 내년 유망 스프링 기술 top5 (박찬욱 편)
- 2009/01/01 2008년 스프링의 아쉬웠던 것들, 2009년의 기대 top 5 (2)
정상혁
이미 35개 이상의 Accenture 고객사에 Spring batch가 적용되고 있다
스프링배치 연재(2) 대용량 처리 배치 프로그램을 만들 때 유의할 점
스프링배치 연재(3) 스프링배치 프로젝트와 주요 기능들
스프링배치 연재(5) ItemReader와 ItemWriter
스프링배치 연재(8) JDBC를 이용한 Cursor 기반의 DB 조회
스프링배치 연재(10) JobLauncher와 Job, Step
스프링배치 연재(12) 이벤트 처리, 유효성 검사, 변환, 기존 클래스 활용
스프링배치 연재(14) 드라이빙 쿼리와 iBatis의 활용
스프링배치 연재(15) 하이버네이트 활용과 여러파일 읽기
스프링배치 연재(16) DB to XML 파일 만들기 예제
박찬욱님
[Beta 1.0]Spring Batch 프레임웍 레퍼런스 한글 편역 버전.
[Beta 2.0] Spring Batch 프레임웍 레퍼런스 한글 편역 버전.
[Beta 3.0] Spring Batch 프레임웍 레퍼런스 한글 편역 버전.
제 1부. 스프링 배치 기본 아키텍처와 잡(Job) 직접 실행해보기
제 2부. FlatFileItemReader와 그 친구들(파트1)
제 2부. FlatFileItemReader와 그 친구들(파트2) (소스 및 PPT)
제 3부. FlatFileItemWriter와 아이템 변환하기 (소스 및 PPT)
제 4부. StAX 기반 아이템 처리 (소스 및 PPT)
제 5부. 데이터베이스에 아이템 쓰고, 읽고~ (소스 및 PPT)
Spring Batch 쓰임새 분석 - 단순한 배치 반복하기
Spring Batch 쓰임새 분석 - 자동적인 재시작
Batch Processing Strategies at Spring Batch
Spring Batch 1.0에서 2.0으로 진화하기- 1. ItemReader/ItemWriter(1)
Spring Batch 1.0에서 2.0으로 진화하기- 1. ItemReader/ItemWriter(2)
Spring Batch 1.0에서 2.0으로 진화하기- 3. JobExecutionLisneter & 4. ItemProcessor
Spring Batch 1.0에서 2.0으로 진화하기- 5. Configuration
백기선님
The Domain Language of Batch - Spring Batch Chapter 2
ItemReader - Spring Batch Chapter 3
경구사님
김승권님
- [Spring batch]차세대 배치시스템 구축 성공전략 - JCO컨퍼런스
박재성님
KSUG포럼
Spring Batch ItemReader 구현체에 대한 궁금증
그리고 XStream으로 XML파일을 생성할 때 특별한 설정을 안 하면, 태그 명 중에 들어간 언더바 1개(_)가 언더바 2개(__)로 바뀌어버리는데, 처음 써보는 사람들이 공통적으로 겪을 수 있는 시행착오일 것입니다.
DB에서 2개 테이블을 엮어서 XML파일로 쓰기 예제
DB에서 부모-자식 간의 관계로 된 테이블을 읽어서 하나의 XML로 만드는 작업은 실무에서 흔하게 만날 수 있는 배치처리 사례이다. 다음의 예제에서는 팀 테이블(team)과 선수(player)테이블에 DB에 있다고 가정하고 이를 하나의 XML로 만드는 작업을 진행해보고자 한다. 팀 테이블과 선수테이블은 당연히 1대 다 관계로 이루어져 있다. 테이블을 생성하고 테스트로 몇 개의 데이터를 넣어주는 스크립트가 첨부파일(imaso-batch.zip)에 포함되어 있다. (src/main/resources/data 폴더)
먼저 부모 테이블인 팀 테이블을 읽어오는 ItemReader를 작성해 보자. JdbcCursorItemReader클래스를 이용해서 쿼리와 그 결과를 Team의 도메인 오브젝트로 매핑할 수 있는 mapper를 지정한다. (리스트12)
<bean id="teamMasterReader" class="org.springframework.batch.item.database.JdbcCursorItemReader">
<property name="dataSource" ref="dataSource" />
<property name="mapper">
<bean class="org.springframework.jdbc.core.BeanPropertyRowMapper" >
<property name="mappedClass" value="imaso.batch.domain.Team"/>
</bean>
</property>
<property name="sql">
<value> SELECT team_id, team_name, symbol, rank FROM team</value>
</property>
</bean>
리스트 12 : JDBC커서 방식으로 Team테이블 조회
간단한 코딩을 위해서 mapper에 BeanPropertyRowMapper를 사용하고 mappedClass속성을 team테이블의 내용을 담는 도메인 오브젝트인 Team클래스로 지정했다. Team 클래스는 team 테이블의 컬럼명이 그 멤버변수로 선언되고 있고, getter,setter를 가진 단순한 클래스이다. Java의 일반적인 명명규칙에 맞추어서 언더바(_)가 없이 camel casing으로 표기되어 있다. BeanPropertyRowMapper는 언더바와 camel casing간의 변환을 자동으로 해 주기 때문에 team_id의 컬럼도 setTeamId메소드를 통해서 값이 채워지게 된다. 만약 성능을 조금이라도 향상시키고 싶다면 다소의 추가 코딩을 하더라도 별도의 RowMapper를 구현해서 사용하기 바란다.
이제 team의 자식 테이블인 player를 읽을 차례다. 여러가지 방법이 있겠지만, DrvingQuery방식과 비슷하게 team 1건마다 그 팀에 소속하는 선수를 조회하는 쿼리를 던지는 방식을 사용해 보았다. 이를 위해 상위테이블만 읽어온 item object에서 그 자식 테이블을 읽어서 채워줄 수 있는 경우를 추상화하여 ItemWithChildrenReader라는 클래스를 작성해 보았다.
public abstract class ItemWithChildrenReader extends DelegatingItemReader{
public Object read() throws Exception {
Object item = super.read();
if(item==null) return null;
setChildren(item);
return item;
}
protected abstract void setChildren(Object item);
public ItemWithChildrenReader() {}
}
리스트 13: 부모-자식 테이블 조회기능을 추상화한 클래스
이를 상속한 클래스에서 setChildren메소드를 구현하여 자식 테이블을 읽어서 넣도록 설계된 것이다.
Team테이블에서 읽어온 값에서 Player테이블을 채워줄 수 있는 ItemReader는 리스트 14와 같이 구현하였다.
public class TeamReader extends ItemWithChildrenReader {
private RowMapper mapper;
private JdbcTemplate jdbcTemplate;
private String sql;
protected void setChildren(Object item) {
Team team = (Team)item;
Object[] params = new Object[]{team.getTeamId()};
@SuppressWarnings("unchecked")
List<Player> playerList = jdbcTemplate.query(sql, params, mapper);
team.setPlayerList(playerList);
}
// private 멤버 객체에 대한 setter 생략
}
리스트 14ㅣ Player를 읽어서 Team에 넣어주는 클래스
setChild메소드 안에서 JdbcTemplate, RowMapper를 이용하여 player테이블의 건들을 읽어와서 team객체에 넣어준다. 만약 두 테이블을 연결시키는 키 속성명, 결과가 들어갈 속성명까지도 설정파일로 빼고 BeanUtils클래스의 setProperty, getProperty들을 활용한다면 보다 일반화시킨 클래스를 만들 수도 있다.
TeamReader의 설정에는 앞에서 나온 Team테이블을 읽어오는 TeamMasterRead를 itemReader속성으로 지정해 준다.
<bean id="teamReader" class="imaso.batch.item.TeamReader">
<property name="itemReader" ref="teamMasterReader" />
<property name="sql">
<value>
SELECT team_id, player_id ,player_name, main_position
FROM player WHERE team_id = ?
</value>
</property>
<!-- mapper, jdbctemplate에 대한 설정은 생략 -->
</bean>
리스트 15 : TEAM과 PLAYER를 같이 읽어오는 클래스의 설정
만약 위의 구현처럼 쿼리를 건마다 하나씩 던지고 싶지 않다면, 다소 구현이 복잡해 지더라도 team과 player 테이블 모두 team_id를 기준으로 정렬해서 조회한 후에 sorted merge 방식과 유사하게 양쪽 item들의 team_id값을 비교해 가면서 team에다 player를 붙여주는 구현도 가능하다.
그 다음은 읽어온 내용을 XML파일로 쓰는 기능은 StaxEventItemWriter와 XStream 라이브러리를 같이 사용해서 구성했다. XStream 라이브러리를 보다 잘 활용하기 위해서 반드시 프로젝트가 의존하고 있는spring-oxm을 최신버전인 1.5.4로 참조해서 쓰기 바란다. 스프링배치의 샘플 프로젝트에서는 1.0.0버전을 참조하고 있는데, 당연히 최신버전에 비해 기능이 많이 빠져있다. 그리고 앞으로 설명한 아노테이션을 이용한 태그명 설정을 사용하기 위해서는 spring-oxm-tiger 라이브러리도 포함시켜야 한다. 예제에서 사용한 Maven2의 pom.xml파일은 첨부파일 내에 포함되어 있다.
생성시킬 XML파일의 형태는 team태그 밑에 team 컬럼의 속성들이 들어가고 player테이블의 내용은 team 태그 밑에서 player태그로 여러 번 반복된다. (리스트 16)
<content>
<team> <team_id>1</team_id> <team_name>Lotte</team_name>
<symbol>Giants</symbol><rank>1</rank>
<player>
<playerId>0</playerId> <player_name>이대호</player_name>
<main_position>3루수</main_position>
</player>
<player>....</player> <player>....</player>
<team>...</team>
<team>...</team>
</content>
리스트 16 : 생성할 XML파일
앞의 teamReader에서 읽어온 내용을 쓰기 위한 StaxEventItemWriter을 리스트17과 같이 설정한다.
<bean id="teamXmlWriter" class="org.springframework.batch.item.xml.StaxEventItemWriter">
<property name="resource" value="file:target/team.xml" />
<property name="serializer" ref="teamSerializer" />
<property name="rootTagName" value="content" />
<property name="overwriteOutput" value="true" />
</bean>
<bean id="teamSerializer" class="org.springframework.batch.item.xml.oxm.MarshallingEventWriterSerializer">
<constructor-arg ref="teamMarshaller"/>
</bean>
리스트 17 : StaxEventItemWriter의 설정
루트태그명을 rootTagName에서 content로 지정하고 xml을 생성하는데 필요한 요소들을 serializer속성-> MarshallingEventWriterSerializer 클래스-> teamMarshaller 빈으로 연결시켜 주는 것까지는 기본적인 사용법과 별차이가 없다.
여기서 도메인 오브젝트인 Team과 Player클래스에서 태그를 연결하기 위한 설정을 편하게 하기 위해서 아노테이션을 사용했다. AnnotationXStreamMarshaller를 사용하면 도메인 오브젝트 내에서 리스트18처럼 태그를 지정해 줄 수 있다.
public class Team {
@XStreamAlias("team_id") private int teamId;
@XStreamAlias("team_name") private String teamName;
private String symbol;
private int rank;
@XStreamImplicit private List<Player> playerList;
리스트 18 : 태그명을 어노테이션으로 지정
@XStreamAlias 어노테이션을 이용해서 멤버변수의 이름과 태그명이 다른 경우에는 태그명을 명시해 준다. playerList필드처럼 Collection이면서, 그 필드의 이름 자체는 태그로 옮기어 지지 않을 경우에는 @XStreamImplicit 어노테이션을 이용한다. 즉, 우리가 만들고자 하는 샘픔에서 playerList속성과 대응되는 부분이 <playerList><player/><player/></playerList> 의 형식처럼 player태그를 playList태그가 한번 감싸고 있는 것이 아니고 바로 <player/>가 반복되는 형태이기 때문에 @XStreamImplicit가 붙어야 하는 것이다. Player클래스에서는 team_id 멤버 변수는 아예 태그로 옮기어 지지 않으므로 @XStreamOmitField 어노테이션을 붙여서 이를 명시했다. XStream의 annotation에 대한 자세한 설명은 http://xstream.codehaus.org/annotations-tutorial.html페이지를 참고하기 바란다.
어노테이션을 사용하지 않는다면 AnnotationXStreamMarshaller의 상위클래스인 XStreamMarshaller 를 사용하고, implicitCollection, omittedFields의 속성에 Map의 형태로 생략할 필드들을 지정할 수 있다.
또 하나 주의할 점은 태그명에 언더바(_)가 들어가면 XStream에서는 디폴트로 그것을 언더바2개(__)로 바꾸어 준다는 점이다. 이 것은 XStream의 XmlFriendlyReplacer라는 클래스에서 하는 작업인데, 불행히도 현재의 AnnotationXStreamMarshaller클래스에서는 이 클래스를 바꿔치기 할 수 있는 기능이 없다. 그래서 AnnotationXStreamMarshaller를 상속하는 별도의 클래스를 만들고 XmlFriendlyReplacer를 끼워넣을 수 있도록 구현을 했다.
public class ExtendedXStreamMarshaller extends AnnotationXStreamMarshaller{
private XmlFriendlyReplacer replacer;
protected void marshalSaxHandlers(Object graph,
ContentHandler contentHandler, LexicalHandler lexicalHandler)
throws XmlMappingException {
SaxWriter saxWriter = new SaxWriter(replacer);
saxWriter.setContentHandler(contentHandler);
getXStream().marshal(graph, saxWriter);
}
//replacer에 대한 setter 생략
}
리스트 19 : XmlFriendlyReplacer 를 지정할 수 있는 확장 클래스
XmlFriendlyReplacer상속한 DummyReplacer를 만들고 여기서는 언더바를 더블언더바로 바꾸는 동작을 수행하지 않도록 만든 후 이를 setter로 설정했다.
<bean id="teamMarshaller" class="imaso.batch.item.support.ExtendedXStreamMarshaller">
<property name="annotatedClasses">
<list><value>imaso.batch.domain.Team</value>
<value>imaso.batch.domain.Player</value>
</list>
</property>
<property name="replacer">
<bean class="imaso.batch.item.support.DummyReplacer"/>
</property>
</bean>
리스트 20 : Marshaller설정
annotatedClasses속성으로 Team과 Player클래스를 지정해서 어노테이션을 XStream에서 인식할 수 있도록 해준다.
StaxEventItemReader에는 이 밖에도 다양한 형태의 Xml 생성을 돕는 속성들이 있다. Root태그 밑에 여러 속성들이 있다면 rootElementAttributes 속성에 Map형식으로 이를 지정할 수 있다. 예들 들어 “<content id=”baseball”>”으로 XMl이 시작한다면 id가 key이고 baseball이 value인 Map을 지정해 주면 된다. 그리고 headerItems속성으로는 루트 태그 아래에 추가로 들어갈 다른 태그들을 넣을 수 있다. 이와 함께 XStream에서 제공하는 Converter인터페이스를 구현하고 XStreamMarshaller 의 converters 속성으로 그것을 등록해 주면, 객체가 태그로 바뀌는 형식을 보다 정교하게 구현할 수도 있다. 자세한 내용은 첨부파일에 있는 예제를 참고하기 바란다.
ItemReader와 ItemWriter를 연결시키는 Step과 Job의 설정을 하면 모든 작업은 끝이 난다. 주의할 점은 SimpleStepFactoryBean에서는 ItemReader가 Writer가 바로 동시에 ItemStream이라면 자동으로 stream속성에 등록이 되는데, 다른 ItemStream객체가 있다면 따로 지정을 해 주어야 한다는 것이다. DelegatingItemReader안에 감싸져서 들어가는 itemReader와 같이, Step에 직접 등록되는 ItemReader가 아닌 경우도 여기에 해당한다. 리스트12와 15에서 보이듯이, teamMasterReader도 teamReader에 감싸져 있는 클래스인데, itemStream인 JdbcCursorItemReader클래스이므로, Step설정에서 streams에 지정되어 있어야지 open,update,close와 같은 메소드들이 제대로 호출될 수 있다.
<bean id="teamDbToXmlStep" parent="simpleStep">
<property name="itemReader" ref="teamReader"/>
<property name="itemWriter" ref="teamXmlWriter"/>
<property name="streams" ref="teamMasterReader"/>
</bean>
리스트21: Step의 설정
첨부파일
SWF 2.x에서는 EL과 플로우 정의 언어도 더 풍부해졌고, 통합, 특히 MVC와 통합도 훨씬 깔끔하게 통합 할 수 있는 것을 볼 수 있습니다. 이제 MVC와 좀더 유기적으로 맞물려서 사용할 수 있게 됐습니다. 스프링 자바스크립트는 좀더 살펴봐야겠습니다. 그래도 기본 구조는 1.x와 거의 동일하기 때문에 1.x를 학습하셨다면, 쉽게 2.x를 보실 수 있을 것 같습니다.
본 문서는 1, 8, 12, 13, 15을 제외한 전 장을 포함하고 있습니다. 빠진 내용들이 핵심적인 내용은 아니니 중요한 내용은 충분히 학습하실 수 있습니다.
감사합니다.
spring-webflow-reference-kr-beta-1.0.pdf1. Spring Web Flow(SWF)
개인적으로 SWF를 살펴 봤던 시점이 작년의 1.x였는데 어느덧 2.x가 공개가 됐습니다. 작년 1.x일 때 로드 존슨이 SWF는 앞으로 SpringSource의 주력이 될 것이라는 말을 했었는데요, 역시나 그 말처럼 지금 SWF의 위상은 상당히 높아졌습니다.
1.x가 위자드 형식의 흐름(flow)를 갖는 conversation 구현에 집중 됐다면, 2.x부터는 Spring MVC, JavaScript, Faces 등 다른 모듈과의 통합을 기반으로 한 Client와의 통합 프레임웍으로 발전하고 있습니다. 특히 spring mvc와 java script와의 통합 강화로 이제 Spring MVC와 유기적으로 협력해서 적용할 수 있게 됐습니다.
특히 Spring-js는 서버 단 프로그래밍 모델 제시가 주를 이웠던 과거에 비해 클라이언트 단의 프로그래밍 모델까지 제시하는 좋은 기회가 될 것으로 보입니다. 사실 Controller+form tag로는 부족했었죠^^. 다양한 Ajax 프레임웍들과의 통합이 지원되고, 사용사례 등이 공유되기 시작하면 Spring-mvc 도입 시 자연스레 Spring-js로 클라이언트 단 로직을 처리(역할이 어느 정도까지 갈지는 모르겠습니다. 현재는 Dojo toolkit 기반 Ajax 요청 처리와 유효성 검증 등이 제공 됩니다.)하고, 여기에 더해서 SWF로 conversation 구현과 flow 제어를 구현하게 될 수 있겠죠. 3.0에서는 Spring-js가 core로 넘어 온다니 역시 다음 한 해에도 기대를 갖고 지켜볼만한 것 같습니다.
2. Spring core 발전
올해 공개된 Spring 2.5에서는 애노테이션 기반 설정이 보다 심하되고, 강화됐습니다. 설정의 단순화만을 강조하는 것이 아니라, @MVC 처럼 프로그래밍 모델 자체를 개선해주는 효과를 얻고 있습니다. '설정'이라는 말이 주는 부담과는 달리, 애노테이션을 사용해서 최소한의 설정으로 최대의 효과를 얻을 수 있는 모델을 제시하고 있습니다. 단지 설정 기법이 XML에서 애노테이션 기반으로 변경된 것이 아니라, 메타 정보를 활용한 새로운 프로그래맹 모델을 제시하는 기회로 활용하고 있는 것이죠.
이번 Spring One America에서도 밝혀 졌듯이 3.0에서는 많은 내용이 개선될 것 같습니다. REST지원, EL 지원 등 3.0에서 도입되거나 개선된 다양한 특징에 대해서는 이미 다녀오신 분들의 글을 참조하시면 될 것 같습니다.
여기서 제가 주목하는 점은 Spring 3.0 도입에 대한 Spring 포트폴리오들의 의지입니다. 아직 3.0 정식버전이 나오지도 않았지만, 포트폴리오의 주요 프로젝트에 해당 하는 프로젝트들(SWF, Spring Security, Spring batch 등)이 이미 3.0에 맞는 기능을 소개하거나 조만간 공개되는 버전에 바로 적용하는 모습을 보여주고 있습니다. 발빠른 행보를 보이고 있으니 3.0은 보다 빠르게 현장 도입 수준에 오르지 않을까 생각됩니다^^.
3. Spring batch
Spring의 다른 프로젝트들도 마찬가지지만, Spring batch는 특히 현장의 경험을 추상화해 이를 기반으로 프레임웍을 구성했다는 점이 가장 인상적입니다. 특히, Job, Step과 배치 실행과 관리에 대한 추상화된 개념을 통해서 처음 배치 업무 구성에 접하는 사람도 개념적인 판단기준을 가지고 학습할수 있는 상황을 제공한다는 점에서 매력적입니다. 아직 첫 번째 돌도 안된 프로젝트지만, 조만간(2009년 3월)이면 벌써 2.0 정식 버전이 나오고, 이미 현장에서도 여러모로 적용했다는 소식을 접할 수 있습니다.
2.0이 나오면 커스텀 네임스페이스나 애노테이션 기반 설정이 가능해져 근본적으로 복잡한 배치 잡 구성을 조금은 쉽게 구성할 수 있을 듯 합니다. 또한 Scalability 측면에서도 Spring Batch 기반의 다양한 구현 패턴(Partitioning, Chunking processing, parallel processing 등)의 공유로 Spring Batch의 활용성이 더 높아질 것으로 기대됩니다. 또한 API도 훨씬 직관적이고, 개발이 편리하도록 개선되었고, 관리 인터페이스 또한 추가 됐습니다.(또는 정식버전 전까지 추가될 예정입니다.) 현재는 2.0M3가 나온 상태고, 정식 버전은 3월에 나올 예정이라니 조금만 기다려 주시죠^^.
4. Spring dm server
올 한해 가장 큰 화두 중 하나로 OSGi를 꼽을 수 있습니다. 임베디드 시장에서 이미 확고한 위치를 점령한 OSGi가 본격적으로 엔터프라이즈 시장에 진출하게 된 시점이 됐습니다. 물론 아직까지는 실험적인 단계라고 생각합니다. 현장 적용을 통해서 쌓여진 노하우(베스트 프랙티스)가 거의 없고, OSGi 환경에서 OSGi의 장점을 누리면서 개발할 수 있는 환경이 아직은 부족하다고 생각합니다. Maven이나 PMD 등이 있지만, 둘 다 엔터프라이즈 환경에서 개발을 지원하기에는 불편하거나, 부족한 상황입니다.
이런 상황에서 Spring dm server의 존재는 엔터프라이즈 환경에서의 OSGi 지원 가능성을 옅볼 수 있게 해줬습니다. 내부적으로 OSGi 환경을 제공하거나 단순히 배포 가능한 컨테이너 제공만 하는 것이 아니라, OSGi 프로그래밍 모델과 Spring의 프로그래밍 모델을 통합할 수 있는 기반을 제공(Spring-DM과 함께) 합니다. dm server는 SSTS와 SpringSource Enterprise Repository 등을 활용해서 OSGi 기반 개발 환경을 지원하고 있습니다. 이에 더불어 별도의 manifest 헤더와 배포 단위를 제공하는 등, 저수준 OSGi 명세를 기준으로 개발할 때 느끼는 불편함을 해결할 방법을 제시하고 있습니다.
물론 이마저도 아직은 많이 불안한게 사실입니다. dm server를 사용해서 개발하고, 배포해보려면 단순히 따라하기도 쉽지 않습니다^^. 올 한 해는 OSGi의 엔터프라이즈 환경 적용을 시험한 무대였다면, 내년에는 본격적으로 적용하는 다양한 방안에 대해서 연구되고, 공유될 수 있는 한 해가 될 것 같습니다. 역시 기대되는 내년 한 해가 될 것 같습니다.
5. tc server
이제 SpringSource는 아파치 톰캣(Tomcat)의 가장 '큰 손'이 됐습니다. 최근 2 년간의 톰캣 개발/버그 수정 중 대부분을 SpringSource가 제공했다고 합니다. 내년에 Spring tc server가 공개되면 어쩌면 Spring 기반으로 개발하면서도 WAS를 사용해야 하는 요구사항이 줄어들 수 있는 기회가 될 지도 모르겠습니다. 아직 내용 공개된 내용이 거의 없지만, 내년 초 가장 큰 관심사임은 분명해 보입니다.
6.Grails와 함께하는 Spring
올 해 말을 가볍게 강타한 내용입니다. Spring One America를 다녀오신 분들의 소감을 들어보면 감동이었다는 표현까지도 들을 수 있습니다. 이 역시 향후 전망을 가능케 할 수 있는 자료가 전무하지만, Grails로 기존 프로그래밍 모델을 개선할 수 있는 방안을 어떻게 도출해낼지 너무나 기대됩니다. 스크립트 언어의 장점을 Spring에 어떻게 접목시킬 지 기대되는 바입니다.
1. 스프링소스
로드존슨이 프리랜서 시절부터 사용하던 회사명인 Interface21을 SpringSource라고 바꾸고 재작년과 작년에 두번에 걸처서 VC로부터 큰 투자를 받았습니다. 투자사가 돈을 낼 때는 큰 수익을 기대하고 있는 것이고, 대부분 기업의 수익을 통한 배당보다는 IPO나 대형 기업에 인수되어져서 큰 차익을 얻는 것이 목표입니다. 그런면에서 VC에 투자를 받은 기업이 망하지 않고 버틴다면 언젠가 JBoss, MySQL 등과 같이 합병되거나 RedHat처럼 상장을 해야합니다. 오픈소스제품을 기반으로 한 비즈니스라는 가장 힘들고 도전적인 일을 시작한 스프링개발자들도 같은 선택을 해야했고, 그 과정에서 VC의 투자는 필수적이지요. 문제는 VC의 투자 이후에 상당한 경영상의 태클이 들어온다는 것입니다. JBoss가 VC투자 이후에 Apache의 Geronimo개발팀이 JBoss코드 일부를 무단 사용했다고, 변호사를 통해서 경고서한을 보낸 것은 충격적인 일이었습니다. 오픈소스라고 해도 저작권이 있고, 지켜야 할 라이선스 조항이 있다는 것은 알고 있지만, 그렇게 거칠고 딱딱한 방법을 동원해야했나는 생각이 들어서 JBoss에 한참 정이 떨어지기도 했죠. 원인은 VC로부터의 압박이 아니었을까 생각했습니다. 마찬가지로 스프링소스 또한 VC의 투자를 받고 덩치를 키우고 관련업체들을 인수하기 시작하면서부터 VC로부터 많은 압박을 받았을게 분명합니다. 가장 중요한 것은 상장이든 인수든, 그에 필요로 하는 성장하는 수익구조를 가지고 있어야 한다는 것이죠. 스프링소스의 컨설턴트들이 스프링을 사용하는 각국의 대형프로젝트에 가서 컨설팅을 하고 그로부터 댓가를 받는 것으로는 규모를 무한하게 키우지 않는 한 큰 이익을 내기 힘듭니다. 몇년전 ThoughtWorks가 상당히 성공한 최신 IT컨설팅업체임에도 상장할만큼의 성공적인 수익을 내지 못해서, 초기 투자자들이 투자비를 회수한다고 난리를 쳤다는 얘기를 듣기도 했지요. 스프링 소스는 그에 비하면 아직 작은 업체입니다. 그렇다고 무작정 컨설턴트 숫자를 늘리면 질은 떨어지겠지요. 결국 선택은 상용제품과 지속적인 서비스를 판매하는 것입니다. 그래서 등장한 것이 Spring Tool Suite을 비롯한 Spring Enterprise입니다. 또 service subscription을 판매하는 것을 통해서 안정적인 수입을 만들어 내는 것입니다. 로드 존슨이 재작년 TSE에서 앞으로 스프링 소스의 주력 마케팅 타겟은 포츈500 기업이라고 얘기했습니다. 그를 위해서 본부를 실리콘벨리로 옮기고 로드 존슨은 주로 그 오피스에서 일을 하고 있죠. 문제는 오픈소스가 아무리 성공적으로 도입되었다고 한들, 모든 기업이 다 그 개발업체에게 상용 서비스를 받으려하지 않는 다는 것이죠. JBoss가 전체 WAS순위 4위인가 하던데.. JBoss를 도입한 업체 중, 상용 서비스를 받고 있는 곳은 7% 정도라는 얘기를 들은 적이 있습니다. 상용서버라면 아마도 90% 이상이겠죠(기한이 지나서 서비스를 갱신 안하는 곳정도를 제외하면..). 기본적인 라이선스 비용도 없는데다, 상용서비스의 비율도 사실 매우 작기 때문에 단순하게 오픈소스공개 후 상용서비스라는 공식은 사실상 이미 실패한 것이나 다름없습니다. 그래서 뭔가 오픈소스에는 없는 부가기능과 가치를 가지는 전용제품이 필요한 것이고, 그것이 바로 Spring Enterprise입니다. 과연 얼마나 많은 기업이 스프링소스로부터 서비스를 받고 있을까요? 잘 모르겠습니다만, 생각보다 그리 많지는 않아보입니다. STS같은 경우는 개인적인 사용만 무료로 허용되어있지만, 사실 회사에서도 그냥 다 쓰지요. 왠만한 기술적인 질문은 자체적인 온라인 커뮤니티나 수많은 공개된 자료에서 답을 찾을 수 있습니다. 요청하면 로드 존슨이 달려와서 해주는게 아니라면 구지 돈을 주고 조금 더 전문적인 서비스를 받을만한 절박함이 없습니다. 또 기술력이 있는 대형기업이라면 스스로 스프링을 개선하고 확장해서 사용합니다. TSE등에서 사례발표를 한 많은 대형 금융기관이나 LInkedIn등의 적용사례를 보면, 자체적인 기술력으로 스프링을 얼마든지 편리하게 사용하도록 개선하고, 관련 툴을 만들어서 적용하고 있습니다. 아직까지 스프링소스가 제공하는 상용제품과 서비스가 그런 업체들에게 줄 수 있는 특별한 부가가치가 없어보입니다. 반면에 보수적이고 덩치가 큰 기업은 안정적이고 지속적인 서포트가 관건입니다. 스프링이 구버전 호환성이 뛰어나다고 해도 구지 꼭 필요하지 않으면 신규버전으로 업그레이드 안하는 것이 보수적인 기술정책을 가진 회사들의 사고방식입니다. 얼마전까지 Spring1.x를 고집했던 atlassian과 같은 ISV도 마찬가지지요. 그러기 위해서 구버전의 지속적인 유지보수가 보장되야 하는데, 각 브랜치를 계속 디버깅하고 관리한다는 것은 오픈소스 개발업체로는 큰 부담입니다. 그만큼의 보상이 필요하죠. 그래서 스프링소스가 올해 큰 악수를 하나 둡니다. 바로 유지보수정책의 변화이죠. 구버전도 3년간 유지보수 버전을 제공하지만, 바이너리 릴리스는 상용서비스 업체에만 제공하고 오픈소스로는 맨 프로젝트 소스만 제공한다는 것이죠. 어떻게 생각하면, 상용서비스를 받는 업체에게는 그만큼의 만족감을 주고, 오픈소스로 찾는 이들에게는 조금의 수고만으로 더 안정적인 유지보수 서비스를 제공한다는 면에서 사실 윈-윈하는 정책이었습니다. 하지만, 스프링소스의 정책의 변화에 대한 친절한 홍보 부족과 스프링을 시기하는 인간들의 비열한 공격으로 스프링소스의 정체을 오해한 많은 개발자들이 생겨났고, 상처 받은 스프링의 신뢰를 회복하느라 로드 존슨이 꽤 땀을 빼야 했습니다. 연말에 열린 S1A에서 느낀 점은 그런면에서 스프링소스의 긴장감을 잘 보여줍니다. 이전과 다르게 딱딱해진 컨퍼런스도 그랬고, 많은 참석자들이 "왜 돈을 내고 와서 마케팅 발표를 들어야 하는지 모르겠다"는 푸념도 참 안타까웠습니다. 그들의 열정과, 오픈소스와 비즈니스를 동시에 지켜야 하는 현실적인 고민, 그리고 최선의 정책도 다 이해합니다만... 개발자들은 그렇게 이해심많고 착하지만은 않으니 걱정이지요.
고군분투하는 스프링소스의 비즈니스와 그에 휘둘릴지도 모르는 오픈소스 스프링을 올해의 안타까웠던 스프링관련 첫번째로 꼽습니다.
2. KSUG
KSUG는 스프링사용자들의 만남을 명분으로 한, 공개세미나 팀이었죠. 그러다 오프라인의 한계를 넘기 위해, 또 오프라인 행사준비에 점점 한계를 느끼는 운영팀의 이런 저런 핑계 때문에 올해 온라인 커뮤니티로 변신을 꾀했습니다. 원래 목표는 포럼과 블로그, 그리고 스크린캐스트의 활성화였죠. 포럼은 그럭저럭 자리를 잡고, 한동안 스프링관련 좋은 토론과 질의응답이 이어졌습니다만, 홍보의 부족으로 아직도 대부분의 스프링개발자들은 이런 공간이 있는 줄도 모르고 있는 상황이고, 쉽고 편하게 질문과 생각을 나누기에는 아직 분위기가 그렇게 잘 형성되어있지 않습니다. 반쯤의 성공이라고 봐야 할까요.
KSUG블로그는 새로운 필진의 등장으로 좋은 글들이 많이 올라옴에도 불구하고 역시 홍보의 문제 때문인지 방문자가 적고, 올라오는 글에 대한 포럼에서의 피드백과 토론이라는 기대에는 거의 부합하지 못하고 있습니다. 주제의 어려움도 한 이유이고, 근본적으로 온라인에서의 기술적인 토론이 점점 사라져가는 그런 추세 때문인지도 모르겠습니다. 어쩌면 다들 너무 마음이 바쁘기 때문일지도...
스크린캐스트는 몇분이 올려준 것을 제외하면 사실 처음 생각했던 것을 거의 진행하지 못했습니다. SpringOSGi/DM을 주제로 잡고, 일단 IBM DW에 유료(하지만 그쪽 정책에 따라 시간은 짧은 심플한) 버전을 올려서, 툴이나 운영비를 위한 수익을 만들고, 바로 뒤이어 KSUG에 길고 충분한 내용을 담은 풀 버전을 올리자는 것이 처음 계획이었습니다. 물론 못했죠. IBM DW에만 좋은 것을 제공하고 끝났습니다. 물론 순서대로 보면 안녕회 회장이 먼저 시리즈를 시작해야 하기 때문에 뒤를 따라야 하는 저는 시작도 못했다고 변명할 수 있습니다만, 어쨌든 게으름 내지는 무성의 함이 원인이었던 것 같습니다. 특히, 오프라인 세미나때 못했던 @MVC의 온라인 스크린캐스트 제공은, 별다른 관심도 받지 못한채로 그냥 흐지부지 되었습니다.
여러모로, KSUG의 올 한해는 아쉬움이 많이 남습니다. 스프링 보급이나 홍보의 시대는 지났고, 진정으로 스프링을 사용하는 사람들끼리 효과적인 교류를 가지자는 취지의 KSUG가 그냥 가까운 몇 사람들과의 친목을 다지는 수준에서 머물른 것이 아닌가 하는 아쉬움이 큽니다. 물론 KSUG를 통해서 본격적으로 등장하신 여러 분들이 있다는 면에서 보람도 있긴합니다만... 지켜지지 않는 약속을 남발한, 저를 포함한 운영진의 반성이 필히 요구되는 한해였습니다.
nhn과의 후원관계에 대한 상호 오해에서 일어난 사건은 가장 씁쓸한 기억으로 남습니다.
3. 애니프레임과 기업의 기술공개
애니프레임에 대해서는 사실 아쉬움은 없습니다. 기술적인 아쉬움이야 일정 부분 있을 수 있겠습니다만, 현장에서의 치열한 논쟁과 부딫침 속에서 어쨌든 만들어지고 사용되어진 제품을 오픈소스 프로젝트로 공개했다는 점에서 일단 90점을 먹고 들어가기에 애니프레임 공개은 2008년 스프링관련 최고의 사건이 아니었나 생각합니다. 사실 애니프레임의 공개를 바라보면서 기대했던 것은 다른 경쟁 기업이나 대형업체들이 자신들의 애플리케이션 프레임워크나 플랫폼을 덩달아 공개하지 않을까 하는 것이었습니다. 여기저기서 SDS의 그런 깜짝 공개에 놀라서, 자신들의 프레임워크도 공개하려고 추진한다는 소식도 들어왔습니다만, 작년 말까지 별다른 공개는 없었습니다. 그런면에서 애니프레임은 여전히 독보적입니다. 하지만, 스프링관련 프레임워크의 공개를 통한 경쟁과 상호발전을 기대했던 분들에게는 여전히 아쉬움이 남습니다. 세계적으로도 기업의 표준 프레임워크가 오픈소스로 공개된 예는 거의 없습니다. 스프링소스가 보유하고 있는 ROO도 몇년째 비공개 상태죠. 사실 뒤를 이어서 기선님이 주도해서 OSAF2.0의 마일스톤 버전이 공개됐습니다만, 정말 아무런 관심도 못끌고 잊혀져버렸습니다.
애니프레임과 관련해서 주변의 KSUG멤버들의 모습을 관찰해 본 결과, 대부분은 애니프레임을 제대로 공부하거나 사용해보지 않고, 겉으로 나타난 몇가지 사실만 가지고 그냥 비판만 하기에 급급하더군요. 엔지니어로서 참 안좋은 태도였던 것 같습니다. 좀 더 진지하게 공개된 오픈소스 프로젝트에 대해서 살펴보고, 부족한 부분은 제안하고, 기여하려는 마음을 가진 개발자들이 없다면, 앞으로 어떤 기업에서 어떤 프로젝트가 공개된다 할지라도 별 의미가 없지 않을까 하는 생각이 들기도 했습니다.
4. OSGi/SpringDM
1.0정식버전이 공개가 된 SpringDM이 2008년의 아쉬움의 4위입니다. 솔직히 SpringDM1.0은 1.0이 아닙니다. 적어도 엔터프라이즈 개발에서의 OSGi 적용을 명분으로 둔 SpringDM이라면 웹을 포함한 full layer의 지원을 완성하고 1.0을 릴리스했어야 한다고 생각됩니다. 하지만 1.0은 SpringMVC나 Web레이어의 지원이 없는 채로 공개되었고, 현재 1.2마일스톤 버전이 나온 지금도 아직 그 부분에서의 지원은 완벽하다고 보여지지 않습니다. 물론 기술적으로는 충분한 제공이 되긴 했지만, 부족한 문서나 샘플도 그렇고, SpringIDE에 통합되지 않은 면도 그렇고, 아직도 많은 이슈를 남겼다는 면에서 SpringDM이 진정한 OS-JEE-i를 위한 기술로 자리 잡기에는 아직도 한계가 있어 보입니다. 그 와중에 tomcat과 결합해서 손쉽게 OSGi 애플리케이션을 서버환경에서 사용하게 만들어주는 SpringDMServer가 공개되었습니다. 역시 1.0이 공개되긴 했지만, 아직도 현장에서 사용하기에는 한참 부족합니다. 핵심은 구현은 되었다고 보이지만, 사용의 편의성도 불편하고, 아직 계획만 되어있고 만들어지지 않은 기능도 엄청납니다(Rop Harrop의 키노트 발표에 보면 한 50가지 정도가 남았더군요...).
플랫폼의 변경이라는 이 커다란 변화가 쉽게 오리라고 생각하지는 않지만, 수많은 기업들이 OSGi에 뛰어들고 매진하고 있는 마당에 가장 앞서있다고 하는 SpringDM과 관련 기술이 이 정도 레벨에서 머물고 빠르게 발전하지 못하고 있는 것은 아쉬움입니다. 그나마 좋은 소식은 SpringDM 2가 OSGi의 엔터프라이즈 컴포넌트 기술의 차기 표준이 되었다는 점인데.. 그부분에 SpringDM개발팀의 여력이 많이 뺐긴 것은 아닌지 하는 의심도 좀 들긴합니다.
5. 준비안된 스프링의 도입열풍
스프링이 이제 메인스트림 기술로 완전히 자리잡은 듯 합니다. 국내의 보수적인 대형 SI들이 적극 사용하거나, 사용을 고려하고 있다는 면에서 이미 충분히 주류기술이 된 것처럼 보입니다. 하지만 이런 열기 속에서 정작 스프링을 스프링 답게 사용하지 못하는 모습이 자주 눈에 띕니다. 스프링을 2주 공부하고 책에 나온 예제 정도 배낀후, 자신이 이전에 개발하던 스타일로 나머지는 멋대로 떡칠한 코드를 가지고 고급 스프링 컨설턴트로 현장에 들어가는 사람들을 본적이 있습니다. 스프링을 도입했지만 귀찮게 새로운 기술을 공부해야 했던 것 말고 뭐가 좋은지 모르겠다는 현장의 푸념도 들려옵니다. 살펴보면 스프링을 그저 가져다 넣기만 했지, 스프링의 기본적인 개발철학조차도 이해못한 채로 엉망으로 사용을 한 경우들입니다. 주위에 그런 얘기가 너무 많이 들려옵니다. 시중에 공개된 스프링책의 어떤 것도 스프링의 진정학 개발원리와 철학, 목표를 얘기해주고 있지 못합니다. 스프링을 그저, 가져다가 넣고 예제 몇개 살펴보고, 샘플 카피해서 사용하면 되는 툴로 이해하는 경우도 많이 보았습니다. 그런 준비안된 스프링 도입, 무비판적인 수용이 결국 스프링에 대한 반감을 많이 키우기도 해서인지, 최근에는 스프링을 도입하는 것을 "감정적으로" 꺼려하는 사람들의 이야기도 들었습니다.
기술적으로 보자면, 애플릿을 제외하면 자바에서 스프링을 도입하지 않을 곳이 없다고 생각합니다. 하지만, 기술적인 적합성만으로 무엇이든 가져다 사용할 수 없는 것이 현장의 현실입니다. 충분한 학습과 전략수립 없이 사용해봐야 큰 효과를 못보는 것이 스프링입니다. 그런면에서 과열된 스프링의 인기는, 얼마 지나지 않아서 스프링에 대한 거부감 내지는 오해를 크게 불러오지 않을까 하는 우려를 낳게 합니다.
그러면에서 좋은 스프링의 교육과 가이드 서적, 안내들이 아쉬웠던 2008년 이었습니다.
다음은 내년의 스프링관련 기대종목을 꼽아봅니다.
1. Spring 3.0
누가 뭐래도 내년 스프링관련 가장 큰 소식은 Spring3.0의 발표입니다. 스프링이 처음으로 크게 진화하고 변화한 모습을 보여주는 것이 바로 3.0입니다. 지겹게 끌고 다녔던 JDK1.4도 이제 EOSL되버렸고, 스프링도 과감하게 Java5+로 변신합니다. 그동안 오래 지연했던 애노테이션의 도입도, 2.5에서 본격적으로 사용하기 시작하면서 3.0에서는 거의 애노테이션 만으로 기존의 XML에서 했던 것을 대부분 수용할 수 있는 단계로까지 발전합니다.
물론 이전 버전과의 API레벨에서의 완벽한 호환은 보장합니다. 이전 설정방법도 당연히 보존됩니다. 하지만 Controller 계층구조가 deprecate되버리는 과감한 변신이 들어갑니다. 또 웹과 관련된 부분이 대폭 지원이 되며, SWF와 JavaConfig이 core에 대거 합병되버립니다. 릴리스 일정은 아직은 올 4월입니다.
2. SpringDMServer
SpringDM/OSGi의 성공여부는 SpringDM Server에 달려있다고 생각해도 좋을 정도로 서버환경의 중요성은 매우 높습니다. 친절한 WAS가 없고 버그 투성이던 시절에의 악몽이 다시 되풀이 된다면 누구도 OSGi로 갈아타려고 하지 않을 것 같습니다. STS가 툴에서의 지원을 완벽하게 해주고, SpringDMServer가 서버로서의 안정성을 보장해 준다면, SpringDM 방식의 개발이 본격화 되지 않을까 싶습니다. 동시에 관련 서적도 빨리 등장하면 좋겠다는 기대를 해봅니다. 국내에 SpringDM 서적을 출간하려고 진행하는 분이 있다는 소식을 들었는데... 과연 어떤 내용일지 기대반 우려반입니다.
3. SpringBatch 2.0
스프링배치의 약진이 놀랍습니다. 이토록 빨리, 스프링관련 기술이 현장에 보급이 된 예는 batch말고는 없었던 것 같습니다. 그만큼 현장의 수요가 많고, 필요성이 높다는 것을 알 수 있는 것 같습니다. 누군가 배치 개발은 SI의 꽃이다라고 했던 것 같은데, 최초의 배치 프레임워크라는 캐치프레이즈와 함께 등장한 스프링배치가 그동안 빠르고 많은 변화를 거쳐서 본격적인 2.0시대로 들어갑니다. 액센추어라는 세계최고의 SI업체와의 합작으로 발전하고 있는 스프링배치 프로젝트가 좋은 결과를 가져와서, 대형 IT업체가 오픈소스 발전에 깊이있게 관여하는 것이 더욱 많아질 것을 기대해봅니다.
4. 스프링 스터디와 교육
KSUG에서 만남을 통해서 시작된 스프링관련 스터디 그룹(http://springstudyclub.tistory.com/)의 활동이 안정적인 단계에 다다른 것 같습니다. 사용자의 교류중 가장 깊이있게 지속될 수 있는게 있다면 바로 스터디그룹입니다. 하지만 바쁜 일정과 참여자의 선지식의 격차, 경험의 차이가 가져오는 한계가 있을 텐데 그것을 어떻게 잘 극복하고 효과적인 스터디 문화를 만들어 나갈지 주목해 볼만합니다. 다음 스터디 기수의 주제는 TDD라고 합니다. 스프링 스터디인데 왠 TDD? 라고 생각할지 모르겠지만, TDD는 아주 좋은 스프링스터디의 주제라고 생각합니다. 러퍼런스 매뉴얼과 책에 다 나와있는 내용을 그저 반복해서 나누는 것이 스터디가 아니라, 참여자 스스로 고민하고 발전할 수 있는 기회를 가지는 것이 스터디의 바른 모습이라고 보입니다. 더군다나 테스팅은 스프링의 백미입니다. 테스트없는 스프링은 상상도 할 수 없고, 스프링 없는 TDD 또한 생각하기도 끔찍합니다.
동시에 스프링과 관련된 고급레벨의 좋은 교육프로그램이 많이 등장하기를 기대해봅니다. 애니프레임과 같은 스프링을 적용한 실용제품에 대한 교육도 좋고, 스프링을 알고 사용하기는 하지만 스프링의 철학과 전략을 깊이 이해하기를 원하는 사람들을 위한 중고급 레벨의 교육도 등장할 때가 아닌가 생각이 됩니다. 개인적으로 생각하고 있는 것이 있기는 한데, 여러가지 여건상 때가 되면 공개를 해보겠습니다.
5. 스프링 서적
이건 순전히 개인적인 기대입니다만.. 올해는 스프링의 철학과 개념에 충실하면서, 스프링의 다양성을 이해하고 전략적인 접근을 할 수 있도록 도와주는 멋진 책이 출간될 것 같습니다. :)
기타 탈락한 후보들...
- Grails : 다른 분들의 기대와 다르게 저는 Grails가 올해 크게 주목받을 기술이라고 생각하지 않습니다. 물론 Grails가 얼마나 뛰어난 제품이고 스프링과 잘 접목된다는 것을 알지만, 언어가 바뀐 다는 것이 주는 갭은 생각보다 크고, 그것을 뛰어넘기에는 아직은 충분한 준비가 되어있지 않습니다. 그런면에서 Grails는 찻잔 속의 돌풍으로 끝나지 않을까 하는 우려가 있습니다. RoR조차도 기대와 다르게 확산되고 있지 못하는게 현실이죠.
Grails가 성공하려면 Groovy라는 언어가 먼저 빠르게 자바 개발자들에게 확신이 되는 것이 우선이라고 봅니다. 또한 현재는 형편없는 툴의 지원이 확실하게 발전해야 하겠죠. 그만큼의 발전이 빠르게 일어날 수 있을 만큼의 커뮤니티가 형성되는 것이 관건으로 보입니다. 오라클이 Grails를 지원하겠다는 발표를 했다고 하는데.. 글세요.
- KSUG: 큰 변화는 없을 것이라고 생각됩니다. 웨비나 얘기가 오고 가기는 하는데, 비용문제도 그렇고 헌신적으로 발표할 사람도 그렇고, 사실 아직은 부정적입니다. 그래도 포럼이 서서히 알려지고 커뮤니티로서의 기능은 꾸준히 올라갈 것 같습니다.
휴.. 이제 끌입니다.
Prev
Rss Feed