[Info]Tags categorized posts and contents patterns..

[AJAX] Ajax Code E xamples.. [Book] About the book.. [CSS] CSS Code E xamples.. [DB] Sql Code E xamples.. [DEV] All development stor...

레이블이 봄싹인 게시물을 표시합니다. 모든 게시물 표시
레이블이 봄싹인 게시물을 표시합니다. 모든 게시물 표시

2016년 4월 6일 수요일

[EP]봄싹 스웨거 세미나 후기..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

지난 26일 토요일에 올해 매달 마지막주에 진행하던 봄싹 스웨거의 마지막을 장식하는 세미나가 있었습니다. 스웨거는 기존에 하던 그룹스터디와는 약간 다른 형태로 한달에 한번씩 다양한 주제로 누구나 나와서 발표하는 형태로 진행되었었습니다.(Whiteship님의 스웨거에 대한 글) 자유스러운 모임이 의도였었고 여러가지 수확도 있기는 했지만 당초기대만큼 진행되진 않았던 것 같습니다. 의도는 아무나 자신이 공부한 걸 들고나와서 나누는 형태가 의도였지만 아무래도 자발적인 발표자가 스웨거를 원활하게 진행할 만큼 많지 않았고 그러다 보니 봄싹의 주축멤버가 계속 발표를 하는 형태가 되었습니다.

봄싹의 모두가 같은 생각을 했는지는 모르겠지만 저는 지식을 서로 나누는 형태가 의도였지만 결과적으로는 단방향으로 전달하는 형태가 된듯합니다.(뭐 크게 불만까지는 없습니다. 서로 나누는게 그렇게 쉽다면 누가 고민하겠습니까.) 어쨌든 올해 중순부터는 장소도 제대로 확보하지 못하면서 어려움이 있다가 이번 세미나를 통해서 2011년 스웨거를 마무리하게 되었습니다.

SpringOne 2011 키노트 요약 - 백기선
10월 25~28일에 시카고에서 진행된 SpringOne 2GX 2011에 갔다온 내용을 간단히 요약해서 정리해 준 시간이었습니다. SpringOne은 SpringSource에서 진행하는 컨퍼런스로 Spirng 프레임워크에 대한 가장 대형 컴퍼런스입니다. 스프링원의 발표자료는 [SpringOne 2011] Spring 발표 자료에 올려져 있습니다. 스프링원에 대한 얘기라 다양한 얘기가 오갔기 때문에 기억나는 것만 적습니다.

스프링원의 첫째날 이야기 부터 시작했습니다. 키노드는 로드존슨이 다친 관계로 아드리안 콜리어가 진행했다고 합니다. 아드리안 콜리어는 스프링이 인기 있는 이유를 Simple + Powerful로 이야기 했습니다. 여기서 Simple은 간단하다는 이야기가 아니고 사용하기 쉽다는 것입니다. 그리고 스프링을 사용하면 테스트하기 쉬운(Testable) 코드를 작성할 수 있고 스프링은 오픈소스입니다.

스프링 3.1에 추가된 기능은 C:Namespace와 환경에 따라 다른 프로파일을 적용할 수 있는 Environment Profiles, 그리고 Web.xml 없이 Java로 설정을 할 수 있습니다. Cache Abstaction이 추가되었고 Java 7을 지원하고 JPA지원이 개선되었습니다. 그리고 스프링 프로젝트가 Github로 저장소를 이동하였습니다.(잘못된 내용이었습니다. 스프링 저장소의 미러를 Github에 만들었을 뿐 저장소자체가 이동한 것은 아닙니다.) 더 자세한 내용은 아드리안 콜리어의 발표자료를 참고하면 됩니다.

둘째날에 들은 세션은 Jeremy Grelle의 You want to do *WHAT* in the browser!? A heretic’s guide to building the “impossible” on the modern web이었는데 웹의 역사와 앞으로의 웹에 대해서 이야기 했다고 합니다. 앞으로 주목해야 할 기술로 HTML5와 자바스크립트를 꼽았으면 자바스크립트에서도 AMD를 특히 강조했다고 합니다.


AMD는 Asynchronous Module Definition의 약자인데 비동기로 관련모듈을 불러오는 것을 이야기하고 최근에 크게 각광받고 있습니다. 그리고 Rossen Stoyanchev의 What’s New in Spring MVC 3.1세션을 들었는데 @MVC가 2.5버전에서 소개되고 3.0에서 REST를 지원했는데 3.1에서는 consume과 produce가 추가되어서 사용하기가 좀더 편해졌습니다.(제가 스프링을 자세히 모르는데 기존에 쓰던기능을 따로 분리해서 쓰기 편하게 한 기능이었습니다.) 다음은 Keith Donald의 Modern JavaScript세션을 들었는데 자바스크립트의 핵심개념과 인기있는 자바스크립트 라이브러리에 대해서 이야기 했답니다.


그리고 노드와 스프링을 연동한 예제를 보여주었습니다. 앞단은 스프링으로 만들었고 노드의 매력적인 모듈중 하나인 Socket.IO의 리얼타임기능을 사용하기 위해서 둘을 조합한 예제였습니다. 사용자가 요청을 보내면 스프링이 RabbitMQ에 넣고 노드가 RabbitMQ에서 꺼내서 Socket.IO를 통해서 사용자한테 푸쉬하는 구조였는데 사실 현업에서 노드를 쓴다면 노드만 쓰기보다는 이런식으로 레거시 플랫폼에 섞어서 쓸 가능성이 높기 때문에 인상적인 예제였습니다.

이 다음부터는 점심준비하느라고 뒷부분은 못들었네요 ㅡㅡ;; 이 세션에 대한 예제는 백기선님의 블로그에 올라와 있습니다.

스프링 어디까지 써봤니? - 박용권
@MVC로 간단한 쇼핑몰을 만들면서 중복코드를 제거하고 어떻게 개선해나가는지 보여주는 세션이었습니다. 저한테는 수준도 딱 좋고 직접 시연하면서 보여주어서 가장 좋았던 세션입니다. 먼저 컨트롤러에서 각 요청마다 클라이언트를 생성하는 코드가 반복되는 부분을 WebArgumentResolver를 이용해서 중복을 제거했습니다.(3.1에서는 WebArgumentResolver가 다른 이름으로 바뀐것 같다고 했는데 이름이 기억나지 않는군요.) 그리고 습관적으로 @Autowired를 쓰고 있었는데 이는 DI에 대한 표준이 없을때 스프링이 만든 어노테이션으로 현재는 JSR 330에서 정의된 @Inject 어노테이션을 쓰는 것도 인상적이었습니다.

다음은 쇼핑몰이 책, 음반, 영화를 파는 쇼핑몰인 관계로 각 요청별로 전체로직은 거의 동일하지만 책/음반/영화에 대한 서비스만 달라지는 부분을 해결하기 위해서 타입을 @PathVariable로 변환해서 여러개의 메서드를 하나로 합쳤습니다. 상품 타입에 대한 변수를 String으로 받던 것을 GenericConverter인터페이스의 구현클래스를 만들어서 상품에 대한 서비스를 리턴해주도록 만들어서 Enum을 이용해서 비교하도록 리팩토링 했습니다.

이렇게 하면 내부에서 타입을 구별하기 위해서 if-else 구분이 생기는데 요구사항은 항상 변경될 수 있기 때문에 새로운 상품이 추가될 경우 if문마다 추가상품에 대한 코드를 매번 추가해 주어야 합니다. 이를 해결하기 위해서 Service Locator를 만들어서 if-else문을 제거하고 상품의 타입을 넘기면 serviceLocater가 상품에 맞는 서비스를 리턴해 주도록 리팩토링해서 아주 깔끔한 코드가 되었습니다.

그리고 일반적으로 하듯이 컨트롤러에서 @RequestMapping에서 뷰를 결정하기 위해서 보통 뷰에 대한 문자열을 리텅해 주는데 박용권님은 컨트롤러가 뷰를 선택해야 하는가에 대한 의문을 가졌습니다. 표현을 그대로 빌리자면 Spring MVC의 라이프 사이클에서 컨트롤러와 뷰리졸버가 나누어져 있기 때문에 박용권님의 고집으로는 이를 용납할 수 없었다고 합니다. 그래서 컨트롤러는 뷰리졸버에서 상품종류만 전달하고 ContentsNagotiationViewResolver를 이용해서 클라이언트에 따라서(최초 요구사항에 폰/테블릿/기타에 따라 다른 화면을 보여준다는 내용이 있었습니다.) 다른 뷰화면을 선택하도록 했습니다.전달하는데 약간의 모호함이 있었습니다. 정확히는 뷰는 컨트롤러가 선택하는게 맞고 뷰의 형태를 선택하는 것은 뷰리졸버라는 의도였습니다. 그래서 ContentsNagotiationViewResolver를 이용해서 뷰이름을 선택하고 ClientViewResolver로 요청클라이언트에 따라 다른 형태를 보여줍니다.



MVC를 사용할 때 흔히 만날 수 있는 이슈들을 어떻게 리팩토링 하는지 보여주었기 때문에 상당히 유용한 세션이었습니다. 발표자료와 예제소스는 박용권님의 블로그에 올라와 있습니다.

Spring Data - 백기선
제가 스프링도 잘 모르긴 하지만 JPA에 대해서는 더욱 잘 모르기 때문에 듣고도 다 이해하기는 어려웠던 세션입니다. 먼저 앞의 스프링원 키노트세션에서 살짝 언급했던던 XML설정 없이 자바설정만으로 프로젝트를 구성하는 예제를 보여주었습니다. 먼저 일반적인 web.xml, applicationContext.xml등으로 간단한 프로젝트를 구성하고 이를 자바설정으로 모두 대체해서 XML을 제거한 다음에도 프로젝트가 정상적으로 동작하는 것을 보여주었습니다. 그리고 자바 컨피그를 사용할 때는 컴포넌트 스캔에서 Configration과 Controller를 제외시켜주어야 한다더군요. 저는 코드로 하는 것을 더 좋아하긴 하지만 XML설정이 좋은가 자바설정이 좋은가는 호불호가 있을텐데 둘다 지원이 되니까 편한 것을 사용하면 될듯 싶더군요.

Spring Data에 대해서는 주요기능중 하나인 QueryDSL에 대해서 먼저 설명했습니다. QueryDSL을 사용하면 SQL을 다음처럼 작성할 수 있습니다.


Java
1
2
3
query.from(customer)
.where(customer.firstName.eq("Bob"))
.list(customer.lastName);

함수형태로 사용하는 것이기 때문에 자동완성을 사용할 수 있고 컴파일단계에서 오류를 발견할 수 있기 때문에 SQL을 작성할 때 흔히 하는 오타로 인한 오류를 줄일 수 있습니다. 그리고 이러한 함수들은 제공되는 것 외에 spec을 이용해서 원하는 함수를 만들어서 재사용할 수 있습니다. 그리고 쿼리를 직접 사용해야 할 때는 Custom Repo를 쓰면 됩니다. 전 SQL을 잘 못하기 때문에 이런 부분은 무척 좋아보이더군요.(못해서 안좋아하는 건지 안좋아해서 못하는건지 잘 모르겠네요 ㅎ)

더 자세한 내용은 백기선님이 올리신 발표자료와 예제소스를 참고하시면 될듯 합니다.

Epilogue
마지막으로 박용권님의 Spring Social발표가 있었는데 이 프로젝트는 개인적으로도 관심이 있어서 듣고 싶었지만 오후에 집에 일이 좀 있어서 마지막 발표는 듣지 못하고 세미나장을 나왔습니다. 저도 봄싹에 속해있는 멤버인 관계로 세미나를 준비할 때 발표에 대한 고민을 했었지만 요즘 개인적으로 바쁜 일이 있어서 발표는 하지 않았습니다.(11월에 정신없었던거 생각하면 발표했으면 민폐끼칠뻔했네요.) 백기선님과 박용권님이 수고해준 덕분에 알찬 내용으로 세미나가 진행된것 같습니다. 사람들도 꽤 많이 오셨고 다들 반응이 좋은걸 보니 기분이 좋군요.


2016년 3월 24일 목요일

[JAVA]Spring Framework에서 SLF4J의 설정 문제..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

간단하게 Spring MVC설정을 하려고 해서 아주 간단한 프로젝트였으므로 Spring Framework와 로깅, JUnit만으로 간단하게 구성하려고 하였으나 의존성 라이브러리 설정에서 문제를 겪으면서 잘 설정이 되지 않았습니다. 이것때문에 엄청난 삽질을 했는데 일단 해결을 하고 나니 로깅 프레임워크에 대한 지식이 전무했기 때문에 발생한 일이었습니다.(그래도 삽질 해보고 나니 어렴풋이나마 이해를 하게 되었습니다. 역시 개발은 삽질부터인가요? ㅎㅎㅎ)


Xml
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
<!-- Spring dependencies -->
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>org.springframework.spring-library</artifactId>
    <type>libd</type>
    <version>3.0.5.RELEASE</version>
    <exclusions>
        <exclusion>  <!-- declare the exclusion here -->
            <groupId>javax.servlet</groupId>
              <artifactId>com.springsource.javax.servlet</artifactId>
        </exclusion>
    </exclusions> 
</dependency>

<!-- logging -->
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>com.springsource.slf4j.org.apache.log4j</artifactId>
    <version>1.6.1</version>
</dependency>
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>com.springsource.slf4j.jcl</artifactId>
    <version>1.6.1</version>
</dependency>

위는 프로젝트에 제가 설정한 pom.xml의 일부입니다. SpringSource Enterprise Bundle Repository에서 Spring Framework 3.0.5.REASE 전체를 가져왔으며 로깅을 위해서 slf4j를 가져왔습니다. 결과적으로는 이상한 의존성을 끌어와 버린 것인데 왜 이런 의존성라이브러리를 가져왔냐 하면 이전에 여러번 했던 프로젝트에 있던 pom.xml을 참고했는데 그 pom.xml에 slf4j가 있었기 때문에 그대로 slf4j를 사용했던 것입니다. 사실 처음에는 앞의 com.springsource.slf4j.org.apache.log4j부분만 있었는데 제가 구성한 것에는 이상하게 LogFactory오류가 나서 그것을 해결하던 와중에 com.springsource.slf4j.jcl을 추가했던 것입니다.

여기서 사용되는 각 로깅 라이브러리에 대한 이해도가 전혀 없다 보니 그냥 문제를 해결하기 위해서 막 끼워넣다보니 위와같은 상황이 발생했고 위와 같이 의존성을 가진 상태에서 WAS를 실행시키면 서버를 실행시키다가 엄청난 랙이 걸린 후에 OutOfMemory : Java Heap Space 오류가 로깅쪽에서 발생하면서 죽어버립니다. Arawn의 도움으로 문제를 파악한 바로는 slf4j와 jcl의 바인딩이 꼬여서 인스턴스 생성이 무한루프에 빠지면서 결국 메모리 오류까지 이어지는 것으로 보입니다.

  • Log4j : Apache의 프로젝트로 Ceki Gulcu가 만든 자바기반의 로깅 유틸리티입니다.
  • JCL (Jakarta Commons Logging) : Log4j, LogKit, JDK1.4같은 다른 로킹툴에 대한 추상화 계층을 제공하는 로그 인터페이스입니다.
  • SLF4J (Simple Logging Facade for Java) : log4j나 logback, java.util.loggin같은 여러가지 로깅프레임워크를 위한 간단한 facade나 추상화를 제공합니다.

각 라이브러리의 특징을 보면 JCL과 SLF4J의 역할이 동일한 것으로 보이는데 (봄싹 메일링에 질문해보니) 저같은 경우에는 slf4j의 log4j와 jcl 바인딩을 둘 다 사용해서 문제가 된 것이었습니다.

log4j바인딩과 jcl바인딩이 모두 존재하는 의존성 그래프

slf4j 의존성 그래프를 보면 JCL에 대한 의존과 Log4j에 대한 의존성이 동시에 존재하는 것을 볼 수 있습니다.(그렇게 셋팅했으니 당연한 얘기지만요 ㅡㅡ;;)

이 부분에 대해서는 Whiteship님의 블로그에 아주 잘 정리가 되어 있습니다. 처음 봤을때는 무슨 말인지 잘 몰랐는데 좀 삽질하고 찾아보고 나니 상당히 명확해 졌습니다. JCL을 사용하던지 Log4j를 사용했어야 했던 것이었는데요. 저같은 경우에는 스프링이 JCL에 의존하고 있는 관계로 SLF4J만 가져왔을때 JCL에 대한 의존성 때문에 오류가 난 것은 해결하려고 JCL을 가져온 것이 문제였던 듯 합니다.

새로 pom.xml을 설정한 뒤의 slf4j 의존성 그래프

Whiteship님의 블로그에 나온대로 의존성을 설정하고 나면 이제 의존성 그래프가 JCL에 대한 의존성은 SLF4j가 받아주고 Log4j만 사용하도록 사용하도록 되었습니다.(아직 다 이해못해서 제대로 설명(?)한건지 잘 모르겠군요.)


2016년 3월 14일 월요일

[EP]제10회 KSUG 세미나 #2..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

스프링 by 봄싹
- 백기선 (봄싹)

이 세션은 봄싹스터디에서 스터디를 운영하면서 스프링등의 기술을 이용해서 사이트를 구축하면서 생긴 노하우를 가지고 봄싹사이트에 대한 구조 설명과 간단한 기능추가에 대한 라이브코딩으로 진행되었습니다. 스프링의 DispatcherServlet, HandlerMaping, HandlerAdapter, ViewResolver의 동작에 대한 것을 소녀시대멤버로 맵핑하여 설명해서 사람들에게 큰 흥미를 이끌었습니다.

DispatcherServlet, HandlerMaping, HandlerAdapter, ViewResolver의 동작DispatcherServlet, HandlerMaping, HandlerAdapter, ViewResolver의 동작

라이브 코딩은 봄싹에서 사용중인 아틀라시안의 컨플루언스 위키에 새로운 글이 올라왔을때 관리자가 수동으로 리플래시를 실행하면 봄싹사이트에 최신글이 뜨도록 가져오는 기능을 개발하였습니다. 이미 존재하는 시스템이기 때문에 URL맵핑 및 Controller부터 DB나 시큐리티등까지 한 사이클의 전체적인 라이브코딩을 볼 수 있었습니다. 추가적으로 앞의 세션에서 시큐리티를 실행하면서 어플리케이션 컨텍스트의 수정을 적용하기 위해서 WAS를 계속 리스타트했던 것과 비교하여 이번 시연에서는 JRebel을 적용하여 WAS의 재기동없이 수정내용이 바로바로 적용되는 것도 꽤 흥미로운 부분이었습니다.(머 완전한 해결법은 없는것처럼 JRebel사용중에도 바로 적용이 안되어 재기동이 필요한 상황이 생기기는 했습니다.)

발표하시는 백기선님봄싹 코드 살펴보기

발표자료는 여기 있습니다.

봄싹에 소속되어 있기는 하지만 아직 봄싹사이트 개발에는 참여를 하지 않았기 때문에 꽤나 더 관심있게 지켜본 것 같습니다. 하나의 특별한 주제에 대한 것도 중요하시만 실제 개발할때는 여러가지 기술을 한꺼번에 다루기 때문에 한 사이클을 모두 진행해 본다는 점에서 큰 의미가 있었습니다. 참 공부할께 많구나 하는 생각과 함께 다른 사람은 어떤 식으로 코딩하는지에 대해서 볼 수 있는 좋은 시간이었습니다. ㅎ


소프트웨어 개발자로 살기
- 안영회 (아이티와이즈)

KSUG의 전 회장이시었던 안영회님의 세션이었습니다. 다른 세션들이 모두 기술세션이었던 데에 반해 이번 세션은 좀더 인간적(?)인 세션이었습니다.

얼마전에 호주로 여행을 갔다오셨는데 그동안 열심히 일했다고 생각을 했음에도 여행을 가기전까지의 과정이 너무 힘들었다고 하셨습니다. 여행은 모았는데 여행후 일상으로 돌아오니 다시 예전과 같아졌습니다.  항상 일을 하다보면 미리미리 해둘걸 하는 후회를 하게 되고 계획한 것처럼 잘 되지 않습니다. 프래클린 플래너나 GTD에 대한 책도 읽어보았는데 도움은 되었지만 해결은 되지 않았습니다.

그러다가 유명한 책인 켄트벡의 TDDBE에서 답을 찾았습니다. 자신의 보폭은 자신이 정하는 것이고 작은 보폭으로 반복을 한다는 부분이었는데 이 TDD를 삶에 적용하여 일을 할때 작은 단위로 나누어 일을 하고 환경에 지배당하지 않도록 노력하였습니다. 하루이상 걸리는 작업은 무조건 나누도록 팀원들에게 요구했습니다. 처음에는 무척 어렵지만 시간이 지나면 가능해지고 빠르게 갱신을 할 수 있습니다. 어떤 일을 할때 막판에 가서 후회를 하게 된다면 주기를 빠르게 해서 매일 후회하도록 하는 것입니다.

발표하시는 안영회님 긍정적인 화학반응을 기대하며3계층으로 나누어보면

사람들은 흔히 이분법으로 많이 생각하게 되는데 이분법에는 한계가 있습니다. 현실에는 0과 1로 나누어지는 것이 하나도 없습니다. 예전에는 관심있는 것과 없는 것을 나누었었는데 지금은 후회하고 있고 전체적으로 균형잡힌 삶이 필요하다고 생각합니다. 컨설턴트가 다른 사람들과 다른 점이라면 이론과 현장을 구분할 수 있다는 것입니다. 이론은 단지 현실의 공통적인 것을 축약해 놓은 것일 뿐이고 이것을 현실로 만드는 것은 좀처럼 쉽지 않습니다. 컨설턴트는 단지 추상적인 사고를 좀 더 잘 할 뿐입니다.

애자일 방법론을 통해서 점진적으로 개선을 할 수 있습니다. 항상 완전히 서로 다른 체계간의 만나기 때문에 모든 일에는 어려움이 있습니다. 애자일을 적용하려고 해도 보통 고객은 정형화된 WBS를 원하고 개발자들은 WBS를 가지고 어떻게 애자일을 하는가에 대한 고민이 있습니다. 하지만 고객과 협의해서 적절한 선의 마일드스톤을 정하고 그 안에서 백로그를 작성하여 이터레이션 되도록 할 수 있습니다. 이런 부분은 서로간의 인정에서 출발해야 하며 상대에게 맞추어 주어야 합니다.
중요한것은 끈질기게 버티는 것입니다.

개발자도 사람이므로 삶에 대한 부분과 애자일로 좀 더 효율적으로 일할 수 있는 부분에 대해서 다양한 얘기를 해 주셨습니다. 개인적으로는 TDD의, 혹은 애자일에서 항상 강조하는 이터레이션을 삶에도 적용한다는 부분이 인상적이었습니다. 애자일이나 TDD가 접근했던 것 처럼 처음부터 실패안하도록 계획하는 것 보다는 점진적으로 개선한다는 것을 삶에까지 적용한다는 것은 미처 생각하지 못했었는데 나름 괜찮겠다는 생각이었습니다. 한번에는 어려워도 좀 익숙해 지면 살을 많이 효율적으로 할 수 있을것 같습니다.


엔터프라이즈 환경에서 Maven 활용 전략
- 박재성 (자바지기)

메이븐에 대한 세션이었습니다. 프로젝트를 하면서 계속해서 항상 반복하는 일들이 있는데 프로젝트 환경을 구축하고 유지하는 일들이 대표적입니다. 소스들간에 라이브러리들간의 의존성 문제들... 또한 자바에는 오픈소스 라이브러리가 많기도 하고 서로간의 의존성도 심한 편입니다. 거기에 프로젝트 진행중 버전이 바뀔때마다 새로 다운받아서 적용하는 일을 반복해서 해야했습니다. 관리자의 일을 하면서 처음에는 개발을 직접 하려고 했지만 관리자가 가장 시간이 많이 있어야 한다는 생각이 들어서 그래서 팀원들이 개발만 하게 하고 환경구축 같은 부분을 맡아서 했습니다.

엔터프라이즈 환경에서 Manven활용 전략발표하시는 박재성님일반적인 프로젝트의 의존성

기본에 많이 쓰던 Ant와 Maven을 비교하면 JDBC와 Spring JDBC를 비교하는 듯한 느낌이었습니다. 메이븐은 사용하기 전에는 메이븐과 비슷한 antlib을 사용했었는데 CoC(Convention over Configuration)의 사상이 메이븐에는 많이 녹아있습니다.

메이븐에는 archetype이라는 것이 있어서 mvn archetype:generate 명령어를 통해서 프로젝트를 생성할 수 있습니다. archetype이라는 이름으로 여러가지 설정의 프로젝트가 정의되어 있고 원하는 아키타입을 선택해서 간단하게 프로젝트를 생성해 낼 수 있는데다가 추상화되어 잘 되어 있어서 오히려 Ant보다 쉬울 수 있습니다. 메이븐은 내부적으로 super-pom을 가지고 있는데 각 pom.xml이 이 super-pom을 상속받고 있어서 각 pom파일들은 아주 심플합니다. 하위 pom에서 재정의하면 자바처럼 설정이 재정의 됩니다. Goal을 위한 단계별 Phases가 정의되어 있는데 각 Phases사이에 원하는 작업을 자유롭게 끼워 넣을 수 있기 때문에 필요한 작업들을 자동화안에 구성할 수 있습니다.

Maven의 동작 구조Dependency

프로젝트의 라이프 사이클과 플러그인들, 의존성을 관리해 주게 되고 중앙저장소에서 제공되는 모든 라이브러리들이 관리되고 있으며 Maven Repository에서 중앙저장소의 라이브러리들을 쉽게 검색할 수 있는데다가 설정에 대한 xml정의까지 제공해주어서 쉽게 이용할 수 있습니다. 다운받은 라이브러리들은 로컬저장소에 저장이 되면 이클립스의 설정으로 소스파일을 볼 수 있도록 설정하면 이클립스에서 외부 라이브러리들에 대한 소스보기가 바로 가능합니다. 이부분은 개발은 하면서 외부 jar의 소스를 참고해야 할 일이 있을때 아주 편리합니다. 단위별로 모듈로 정의한 뒤에 통째로 빌드하는 것도 가능합니다.

사용자가 archetype을 만들수 있기 때문에 사내에 레파지토리를 구성하고 전용 아키타입을 만들어서 팀에 적용을 하면 전사표준으로도 쉽게 적용할 수 있습니다.

설정은 다 되어 있는 메이븐을 사용만 해 보았습니다만 메이븐은 여러가지 면에서 매력적인 툴이었습니다. m2eclipse로만 사용해보았는데 사실 command로 사용하고 아키타입이 있다는 것은 처음 보았습니다. 메이븐은 좀 공부(?)하기는 해야해서 맘에만 두고 있었는데 전체적인 메이븐의 아키텍쳐에 대해서 이해할 수 있었습니다.  사용법과 함께 구조에 대해서 설명해 주니까 전체적인 동작을 이해하기가 좋았습니다.


세미나를 들으러 간 것이기는 하지만 봄싹에서 다수가 함께 가기도 했고 KSUG와도 약간 연관이 있어서 아는 사람도 많아서 좀 더 편하게 세미나에 참가했던것 같습니다. KSUG가 업체가 아닌 커뮤니티인데다가 온라인에서 주로 활동되는 터라 KSUG의 운영진은 있지만 KSUG의 멤버라는 소속감을 가진 사람들은 아직 좀 적은 상황이라서 그런지 행사에 대한 스태프는 좀 부족하지 않았나 싶은 생각은 약간 들었습니다만(회사 퇴근해서 이런 행사 준비한다는게 쉬운 일은 아니긴 하죠 ㅎ) 각 세션의 스피커분들이 워낙 발표를 잘 해 주셔서 저뿐만 아니라 다른 분들도 많은 것을 얻어간 시간이었을듯 합니다. 저로써는 KSUG라고 해서(스프링의 사상도 그렇기는 하지만요) 스프링이라는 주제에 한정되지 않고 다양한 주제의 세션이 진행된 것이 오히려 더 좋았던 것 같습니다. ㅎ