본문 바로가기

카테고리 없음

한국스프링사용자모임2회(KSUG) 참가 후기 (스프링 달인의 한수 가르침)


객체는 세상의 사물을 표현했기 때문에 살아있는 세상과 비슷하다. 만약 어떤 사람이 자주적인 생활을 못하고 부모님이나 주변 사람들에게 의존하기만 한다면 도와주는 사람들이 갑자기 외면했을때 그 사람은 제대로 살수가 없을것이다. 객체역시 사람과 비슷하여 만약 다른 객체의 기능에 크게 기대기만 한다면 도와주는 객체가 변경, 손상, 심술을 부렸을때 기대는 객체 역시 제대로 살수가 없을것이다.

그러나 세상은 결코 혼자서만 살수가 없고 누군가의 지원이 필수적이라서 그 지원을 밑바닥 에서 도와주는 무엇인가 있으면 크게 도움이 될 것이다. 스프링은 객체들의 상호 의존을 보이지 않게 관리하여 객체 자신이 무엇에 의존하고 있는지 신경 쓸 필요 없게 만든다. 사람 사는 세계와 비유하면 국가가 주도하는 복지, 교통의 사회적 인프라를 잘 구축하여 시민들이 불편함을 모르는 국가의 지원들이, 객체의 의존성을 별도로 다루는 전지전능한 스프링과 비슷하다 할 수 있겠다.

객체의 의존성을 스프링이라는 전지전능한 요소가 별도로 관리 한다. 관리 한다는 의미는 이 객체가 무엇에 의존될 것인가를 객체가 결정하는것이 아니라 스프링이 결정한다/주입한다. 이것이 IoC(Inversion of Control:제어역행) 개념 이다.

내가 정리한 IoC 개념이 맞는지 애매할 정도로 스프링에는 처음에 접근하기 어려운 개념들이 존재 한다. 내가 스프링에 대해 알고 있는 것은 일단 여기까지이다.

사용자 삽입 이미지

그동안 스프링에 대한 온갖 찬사를 들어왔고 최근 우리 프로젝트에서도 본격적으로 도입을 앞두고 있어 관심이 높아가던중 '스프링 열혈 매니아'인 친구의 추천으로 '한국 스프링 사용자 모임(KSUG) 2회'에 참가하게 됐다.

사용자 삽입 이미지

세미나 장소인 국민대로 가는길은 불편했다. 대신 국민대는 산뜻했다. 오랜만에 젊음의 장소로 오니 내 마음이 산뜻해진다. 대학교란 곳이 세상에서 제일 역동적인 곳이라는 생각을 해보았다.

사용자 삽입 이미지


+ 첫번째 순서, Inside Spring MVC, 안영회님
스프링 열혈 매니아 친구의 말로는 이일민님과 안영회님이 스프링 전문 컨설팅 회사인 Eprill이란 회사를 차렸는데 두분의 실력이 스프링 세계에서 제일 출중하다는 얘기를 해주었다. 안영회님은 목소리가 차분하고 멋있었다. 그런데 얼굴은 내 또래로 동안이었다. 안정되고 차분한 진행이 돋보였다.

내용은 웹개발에서 Spring의 MVC 기능을 활용하는 방법을 설명하였는데 단순히 PPT 발표에 그치는게 아니라 실습가능한 내용 대부분을 이클립스로 시현하여 참가자들이 직관적으로 내용을 이해할 수 있도록 최대한 배려해 주었다.

MVC란, 개발의 주요 요소를 모델, 뷰, 컨트롤러로 명확하게 나누어 각 영역간 의존성을 최대한 줄임으로써 깔끔하고 재사용이 가능한 개발을 가능하게 하는 개발 요소의 분리 방법이라고 나름대로 정의해보았다.

사용자 삽입 이미지
출처 : http://blog.empas.com/ahnyounghoe/9699609

MVC 개발 요소 분리 방법의 핵심은 FrontController라는 모든 요청을 한곳으로 받아내어 해당 처리를 지시하는 클래스라고 본다. 스프링은 DispatcherServlet이라는 놈이 이 역할을 수행하고 기타 처리 요소들 대부분이 스트럿츠 등의 MVC 프레임워크와 비슷하게 수행하는 것 같다.

다만 특이점은,
폼검증, 폼을 검증하는 방법이 풍부한 것 같다.

뷰리졸버, 요청을 처리할때 출력할 뷰를 JSP뿐만 아니라 벨로시티, 프리마커 등의 다양한 뷰 기술로 별도 선택할 수 있다는 것을 알았다. 스프링의 확장성을 염두해둔 막강한 설계 역량이 돋보이는 기능 이였다.

스프링 고유장점인 IoC 와 AOP의 이점 얻기,
사실 위의 특이점 외에는 스트럿츠등의 모델2프레임워크와 크게 다른 점을 발견하진 못하였다. 다만 스프링MVC 설정 역시 스프링 애플리케이션 컨텍스트에서 자바빈으로 설정된다는 것이다. 이는 다른 빈을 사용할 때와 마찬가지로 의존성 주입과 스프링 AOP의 이점을 모두 얻을 수 있다는 의미일것이다.

부가적으로 얻은것,
막강한 이클립스 편집 기능, 안영회님이 이클립스로 시현했을때 진정한 개발 고수의 편집 능력을 보는 즐거움이 있었다. 단축키 몇번 누르면 의도하는 코드가 반듯하게 정렬되어 출력된다. 이런 기능이 있다는 것은 알긴 알았지만 최근에는 귀찮아서 쓰질 않았다. 다시 공부하여 이클립스의 막강한 편집 기능을 활용해 봐야 겠다.

UnsupportedException의 활용, 최근 JUnit로 TDD흉내를 부지런히 내볼려고 하는데, 메소드만 만들고 기능은 구현하지 않았을때 UnsupportedException을 throw하면 명확한 테스트가 가능하다는 설명을 듣고 무릎을 딱 치면서 이해했다.

사용자 삽입 이미지

+ 두번째 순서, Inside Spring DAO, 이일민님
이일민님은 위엄있으면서도 편안한 팀장님 같은 이미지였다. 빠르면서 안정된 목소리가 인상적이었다. 무엇보다 스프링을 비롯한 개발 기술에 대해 깊은 성찰을 한 달인만이 말할수 있는 내공 가득한 설명이 나를 압도하였다.

DAO란, DB접근하는 로직을 별도로 분리하여 서비스 객체가 특정한 데이터 접근 구현에 크게 의존되지 않음으로써 테스트와 유연한 설계와 확장이 가능하다~ 라고 정의해 보았다.

스프링은 그 뛰어난 기능만큼 이해하기 난해한 요소도 있었는데 이일민님이 설명하신 스프링 DAO는 바로 써먹어도 되겠다 싶을정도로 간단하고 명쾌하게 이해됐다. 스프링에서 바로 써먹어도 되는 '이것들을' 알았다는것이 이번 세미나 최대의 성과였다.

템플릿JDBC 기능, 자바의 최대 단점이 JDBC작성 코드가 몹시 지저분하고, 위험하고, 복잡하다는 것에 있다.

1. 자원선언
try {
    2.연결개시
    3.질의문 생성 및 실행
    4.트랜잭션 성공 요청
} catch(SQL Exception e) {
    5.예외처리
    6.트랜잭션 실패 요청
} finally {
    7.자원반환
}

간단하게 'select * from mckdh;' 'insert into mckdh values('산골소년');' 한문장을 수행할려고 해도 자바JDBC는 1번부터 7번까지 반드시 중복 작성해야 하며 한가지 과정이라도 어긋나면(특히 7번) 해당 어플리케이션을 치명적으로 망가트리는 지저분하고 위험하기 짝이없는 자바 최대의 허약한 급소이다.

이중 개발자가 집중해야될 순서는 3. 질의문 생성 및 실행 하나뿐이다. 그 외는 어느 JDBC코드에서나 똑같은 실행 순서이다. 스프링의 JdbcTemplate는 저 동일한 실행 순서를 떠안고 관리해준다. 디자인 패턴의 Template패턴과 비슷하다. JdbcTemplate에 저 지저분하고 위험한 실행 코드를 맞기고 개발자는 콜백 클래스를 활용하여 3. 질의문 생성 및 실행을 요청하면 된다.

이일민님은 스프링 도입을 망설이는 팀이 있다면 JdbcTemplate을 시범적으로 써볼 것을 권유하셨다. 이 기능은 라이브러리 쓰듯 바로 가져다 쓸 수 있고 바로 효과를 확인 할 수 있기 때문에 스프링을 이용하기 위한 샘플약으로 쓰면 좋다고 하였다. 나도 명쾌하게 이해되는 이 기능을 바로 활용해 봐야겠다 라고 무릎을 치면서 이해했다.

사용자 삽입 이미지
진정한 Excpetion 처리 가능(?), 자바에서 SQLException이 발생하면 에러 추적이 어렵다. 에러 코드가 특정 벤더에 의존적이고 오로지 SQLException으로만 출력되는 에러 메시지는 나보고 도대체 어떻게 해결하냐는 짜증을 불러일으킨다. 이것 역시 자바 반대 진영으로부터 맹공을 받았다고 한다.

스프링과 하이버네이트는 DB관련 작업중 발생하는 수많은 상황에 발생하는 연결 실패, 자원 반환 실패, 교착상태, 데이터select실패, 데이터 타입 맵핑 실패등의 다양한 에러를 Exception으로 명쾌하게 명시화하여 개발자가 에러 추적을 용이하게 해준다.

기타,
하이버네이트 연동 실습, SQL 문장의 저수준에 의존적인 JDBC 코드를 객체로 끌어올릴 수 있다면 객체지향의 효과를 골고루 누릴 수 있다. 스프링과 하이버네이트를 연동한 간단한 실습은 바로 이해 될 수 있었다.

AOP를 이용한 트랜잭션 실습, 동시에 DB 접근이 성공해야지만 트랜잭션이 성공해야 되고 하나라도 실패하면 롤백해야 된다는 트랜잭션 처리는 개발자가 신경쓰지 않을수록 좋지만 그렇게 하기가 어렵다. AOP를 이용하면 트랜잭션관리가 필요한 객체를 스프링이 별도 처리하여 트랜잭션이라는 어렵고 귀찮은 처리를 개발자가 신경 쓸 필요 없게 해준다. 지금 당장은 이해되지 않았지만 기억에 남았다가 나중에 나도 써먹을 날이 있을 것이라 몇번 되새김질 하였다.

ORM과 JDBC을 써야 할때, 처음부터 개발자가 DB설계에 참여할수 있다면 ORM을 쓸수록 좋다고 하고, 수많은 트래픽이 요구되는 SQL은 JDBC가 좋을수 있다고 한다. ORM을 쓰면 객체지향의 장점(아마 유지보수, 확장성 등의 요소가 아닐까), 캐싱(매번 Db에서 긁어올 필요 없이 한번에 가져와 객체로 저장하여 성능향상)등의 장점을 골고루 누릴 수 있기 때문에 ORM을 쓰면 쓸수록 좋은것이라 생각해보았다. 이일민님은 ORM과 JDBC 하나만 선택하는 것이 아니라 둘다 골고루 쓸 수 있기 때문에 각각의 장점을 취하여 쓸것을 조언해 주셨다.

+ 쉬는 시간, 상품 퀴즈
쉬는 시간에 퀴즈를 맞추면 상품을 주는 재미있는 휴식 시간이 있었다. 퀴즈 역시 “스프링의 명저 록스 출판사의 Professional Java Development with the Spring Framework라는 책의....[어려운 책 제목 처럼 어려운 질문이 나올것 같은 분위기]...표지 색깔은 무슨 색일까요? [터지는 폭소...당연히 빨간색이지~]”라는 재밌는 퀴즈들 이었다.

추첨에서 친구가 뽑혔다.

사용자 삽입 이미지

'스프링 열혈 매니아' 인 내 친구는 iBATIS 책을 받았다.

사용자 삽입 이미지

나도 받았다. 나는 '마이크로소프트4,6월호'를 받았다. 비싼 상품은 아니지만 즐거웠다.

사용자 삽입 이미지

+ 정리
내가 우리팀을 상대로 작게나마 세미나를 개최한 적이 있다. 그때 어떻하면 내가 아는 내용을 모르는 사람에게 제대로 전달할 수 있을까. 어떻하면 실수하지 않고 창피당하지 않고 제대로 진행할 수 있을까. 라는 압박감 때문에 고3 수능 때의 고생 처럼 탈진할정도로 생고생 한적이 있다.

그래서 세미나는 발표자가 혼신의 노력을 기울여 준비할수 밖에 없기 때문에 세미나야 말로 알찬 지식을 습득할 수 있는 유익한 기회라고 생각하였다.

그러나 다음 참가한 세미나에서 제품 광고에만 몰두하는 내용에 크게 실망하고 보란듯이 내내 잠만 자서 세미나에 대한 불신이 생기기도 했다.

다행히 이번 세미나는 땡볕의 콜라 한잔처럼 유익 했다. 스프링 최고의 달인들이 부드럽게 진행하는 한수 가르침은 수많은 기능과 높은 이상 때문에 접근하기 어려운 스프링 고수의 길을 스스로 걷게 만드는 동기부여를 제공해 주었다.

스프링을 조금씩 알아갈수록 스프링에는 단순한 기능 이상의 무엇인가가 있다는 생각이 든다. 신입사원때 스트럿츠에 열광하던 때와는 다르다. 이제 겨우 3년 경력이지만 스프링에는 수많은 개발자들이 고민하던 개발의 이상과 철학이 담겨 있다는 느낌이 든다.

마치 달마 대사가 홀연히 소림사를 창건하여, 이상과 철학이 담긴 수많은 무술과 수행법을 창조하였듯이 스프링에도 개발 요소 전체를 아우르는 수많은 기능이, 단순한 라이브러리 를 뛰어넘는 어떤 이상과 철학으로 개발 노가다로 고생하는 개발자를 구원하는 어떤 효과가 있을 것이라는 기대가 든다. 단 그 효과를 깨닫기 까지 '고된 수행'이 필요할 것이다.

(개발 노가다로서의 짜증의 '고됨'과, 수행을 통해 얻는 성찰을 위한 '고됨'은 분명히 구별되어야 한다.)

스프링을 창시하고 발전시키는 오픈소스 개발자와 개발 노가다로 고생하는 개발자들을 위해 이런 유익한 세미나를 개최해준 관계자 분들은 개발자의 행복과 IT기술 발전에 기여하는 훌륭한 선각자 들이다. 그래서 유익한 세미나 였다.

+ 참고 사이트
한국 스프링 사용자 모임 http://www.springframework.co.kr
스프링 컨설팅 회사 Eprill http://www.epril.com
이일민님 블로그 http://toby.epril.com
안영회님 블로그 http://younghoe.info/