[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년 3월 22일 화요일

[Tool]Eclipse에서 Tomcat실행시 SetPropertiesRule 경고 메세지..

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

Eclipse에서 Tomcat실행시 콘솔에 아래와 같은 경고메시지가 나타났습니다.

경 고: [SetPropertiesRule]{Server/Service/Engine/Host/Context} Setting property 'source' to 'org.eclipse.jst.jee.server:Example' did not find a matching property.

이클립스 Helios버전에 Tomcat 6.0을 사용중이었는데 찾아보니 6.0.16부터 source라는 프로퍼티가 추가되었는데 WTP가 source라는 속성을 프로젝트의 context에 추가해서 발생하는 것으로(참고) 문제를 일으키지는 않는다고 합니다.(자세한 이유와 영향은 잘 모르겠네요.)

Tomcat의 설정화면

이 문제를 해결하려면 Eclipse에서 Tomcat서버를 더블클릭해서 설정부분의 Server Options에 있는 Publish module contexts to separate XML files를 체크한 뒤에 다시 톰캣을 구동하면 경고메시지가 사라집니다. 



[Tool]Eclipse에서 Tomcat실행시 validateJarFile - jar not loaded 메시지..

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

자바에 대해서 업무를 하고 있지는 않지만 자바를 놓지 않으려고 하고 있었지만 그렇다고 딱히 깊게 학습하고 있지도 않았습니다. 모르고 있던 바는 아니었지만 주위에 자바를 하는 사람들이 워낙 많다보니 그냥 그사람들과 자바얘기를 지속적으로 접하고 듣는 것을 통해서 어느새 안주해버린 상태에 들어갔었던 듯 합니다. 제 자바 수준은 바닥인데 주변 사람들로부터 너무 높은 수준의 얘기만 듣다보니 어느 순간 현실을 제대로 자각하지 못했던 것 같고 그동안 자바로 프로젝트를 했음에도 항상 잘하는 친구들이 셋팅 다 해주면 그 위에서만 개발했기 때문에 막상 혼자 뭔가 해보려고 하니까 간단한 것도 제대로 못한다는 현실을 깨닫고 약간 당혹감에 빠져있는 상태입니다. 정작 중요한 것은 제가 원하는 걸 얼마나 만들어낼수 있느냐 하는 것인데요. 다시 초심으로 돌아가서 기초부터 다시 쌓아올라가려고 합니다.

사설은 머 간단히 하고 이클립스에서 Spring을 얹어서 Tomcat으로 띄우는데 Tomcat 콘솔에 아래와 같은 오류가 찍혔습니다.

정 보: validateJarFile(D:\Project\STS\.metadata\.plugins\org.eclipse.wst.server.core\tmp1\wtpwebapps\Example\WEB-INF\lib\com.springsource.javax.servlet-2.5.0.jar) - jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class: javax/servlet/Servlet.class

이 문제는 javax.servlet.Servlet.class가 중복으로 로드되어서 발생한 문제입니다. <TOMCAT_HOMT>\lib 폴더 안에 servlet-api.jar안에 javax.servlet.Servlet.class가 있는데 프로젝트의 lib에도 javax.servlet.Servlet.class가 있어서 발생한 문제이므로 프로젝트의 WEB-INF/lib에 있는 javax.servlet-2.5.0.jar를 삭제해 주어야 합니다.

의존성 라이브러리 관리를 위해서 Maven을 사용하고 있었는데 SpringSource Enterprise Bundle Repository에서 Spring Framework 전체를 한번에 끌어오고 있었기 때문에 아래와 같이 exclusions을 사용해서 javax.servlet을 제거했습니다.



Xml
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
<dependency>
     <groupId>org.springframework</groupId>
     <artifactId>org.springframework.spring-library</artifactId>
     <type>libd</type>
     <version>${spring.version}</version>
     <exclusions>
         <exclusion>
             <groupId>javax.servlet</groupId>
             <artifactId>com.springsource.javax.servlet</artifactId>
         </exclusion>
     </exclusions>
</dependency>

이렇게 프로젝트의 라이브러리에서 javax.servlet을 제거하고 Tomcat을 실행하면 앞의 나오던 오류메시지가 없어진 것을 볼 수 있습니다. 

[Book] 성당과 시장(The Cathedral and the Bazaar)..

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

The Cathedral and the Bazaar (Revised, Paperback) - 10점
Raymond, Eric S.
Oreilly & Associates Inc

읽어보지는 않았어도 개발자라면 이름정도는 들어봤을 법한 에릭 레이먼드의 그 유명한 성당과 시장(The Cathedral and the Bazaar)입니다. doortts님의 포스팅 을 보다가 생각해 보니 단편적으로만 몇번을 보고 성당과 시장을 전체적으로 본적은 없다는 생각이 들어서 짬짬이 왔다갔다 하면서 읽어보았습니다. 당연히(?) 원서를 읽은 것은 아니고 성당과 시장에 대한 번역전문GNU Korea 에서 제공되고 있습니다.

이 책은 오픈소스의 철학을 얘기하고 있는 에릭 레이먼드의 대표적인 글이 성당과 시장이라는 글에 대해서 후에 책으로 출간이 되면서 "성당과 시장" 외에 "인지권의 개간"과 "마법의 솥"에 대한 글까지 포함되었습니다. 분량은 그렇게 많지 않아서 그리 어렵지 않게 읽을 수 있으며 이젠 10년도 더 된 글이기는 하지만 역시 그 명성대로 많은 것을 느낄 수 있는 책입니다. 책을 읽는 내내 나는 왜 이 글을 이제야 읽고 있는 것인가라는 생각이 계속 들었습니다.(인지권의 개간 부분은 현재 GNU Korea의 사이트에서는 그 내용이 소실되어 있는 상태이고 오픈소스프로젝트의 사이트에 인지권의 개간이 업로드 되어 있습니다.

이 책에서 레이몬드는 리눅스의 발전을 보면서 성당스타일과 비교될 시장스타일의 개발방식에 깊은 인상을 받고 패치메일을 시장모델로 개발하면서 얻은 생각들을 아주 분석적으로 풀어가고 있습니다. 인지권의 개간에서는 시장문화의 해커들이 어떤 동기부여로 프로젝트에 참여하고 그 내부의 해커문화가 어떻게 이루어져 있는지 아주 자세히 설명하고 있고 마법의 솥에서는 오픈소스모델이 클로즈소스에 비해서 어떤 장점을 가지고 있고 오픈소스의 모델이 수익단계를 위해서 어떻게 진행되고 방향을 잡아야 하는지를 설명해 주고 있습니다.

레이먼드가 성당과 시장을 리눅스 회의에서 발표한 것이 1997년이고 책으로 나온 것이 1999년이므로 이 책은 이제 10년도 넘은 글이라고 할 수 있습니다. 저는 오픈소스에 상당히 매료되어 있는 편인데 비록 10년이 지났음에도 레이먼드가 분석하고 설명해 놓은 내용과 예측들은 놀랄 정도로 정확하다는 생각입니다. 개발을 하기 전에도 FSF나 리차드 스톨만, 오픈소스에 대해서 대충은 알고 있었고 개발을 하면서 수많은 오픈소스를 사용하게 되었지만 딱히 오픈소스라는 의식을 가지고 있었던 것은 아니었습니다. 그냥 사람들이 많이 쓰고 좋다는 것을 써보고 스스로 좋음을 느끼면서 어느순간에 보니 제가 매료되는 대부분의 것들은 오픈소스들이었고 이런 것들을 자유롭게 사용할 수 있고 그들의 문화와 그들의 완성도에 흠뻑 빠져버렸습니다.

이런 부분은 사실 딱히 공부하거나 하지 않더라도 느낄수 있는 부분이라고 생각하고 어떤 면에서는 머리로 공부하는 것 보다는 직접 오픈소스사용해 보고 (어떤식으로든)참여해 보면서 직접 몸으로 느끼는 것이 더 좋다고도 생각하고 있긴 하지만 성당과 시장이 주는 영감들은 오픈소스에 관심있는 사람들이라면 꼭 읽어볼 만한 가치가 있다고 생각합니다. 막연히 오픈소스그룹들의 활동들을 알고 있던 것만에서 시장모델이 갖춰지지 않은 상황에서 리누스 토발즈를 중심으로 한 리눅스의 성공으로 시장모델을 보게되고 거기서 레이몬드가 패치메일로 직접 경험하면서 나누는 얘기들. 그리고 해커들이 어떻게 커뮤니티에 참여하고 무엇때문에 시장모델에서 프로젝트를 개발하는지 그들에게는 어떤 것이 보상으로 느껴지고 무슨 문화를 가지고 있는지를 아주 명쾌하게 설명해 주고 있으며 오픈소스가 상업적으로 어떤 모델을 가져야 하고 클로즈소스와 어떤 차이가 있는지를 명확하게 설명해 주고 있는데 전혀 모르고 있던 내용이 아님에도 불구하고 깔끔히 정리된 내용에 먼가 후련하게 생각이 열리는 듯한 기분이 들 정도였습니다.

따로 자세한 내용을 설명하기 보다는 안읽어보셨다면 직접 읽어보시길 권해드립니다.(사실 1번이상은 두고두고 읽어봐야할 책으로 느껴집니다.) 저는 확실히 시장쪽으로 마음이 가는군요 ㅎ



[JS]input [type=text]의 text에 있는 커서 이동하기..

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

요즘 재미삼아 만지고 있는 거에서 input [type=text]에 있는 문자열의 커서를 이동시켜야할 필요가 있었습니다. 커서를 다뤄본 적은 별로 없어서 검색을 했더니 역시나 좋은 예제를 Stackoverflow에서 찾을 수 있었습니다.


JavaScript
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
$.fn.selectRange = function(start, end) {
    return this.each(function() {
         if(this.setSelectionRange) {
             this.focus();
             this.setSelectionRange(start, end);
         } else if(this.createTextRange) {
             var range = this.createTextRange();
             range.collapse(true);
             range.moveEnd('character', end);
             range.moveStart('character', start);
             range.select();
         }
     });
 }; 

// use like this 
$('#elem').selectRange(3,5);

위 함수는 jQuery에서 사용할 수 있도록 한 것이고 jQuery를 쓰지 않는다면 따로 함수로 정의해서 타겟이 되는 엘리먼트도 아규먼트로 넘겨주어야 합니다. 이름에도 알 수 있듯이 이 함수는 문자열의 원하는 범위의 text를 선택하는 코드입니다. 단순히 커서의 위치를 이동하고자 한다면 start와 end 파라미터를 동일한 값으로 지정하면 됩니다.

IE6,7에서는 테스트 해보지 않았지만 그 외의 브라우저에서는 잘 동작합니다. 


[Talk]Social Network를 보고..

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

이 블로그에서 영화 얘기같은건 안하는 편이긴 하지만 "소셜 네트워크"라는 영화는 포스트구글이라고 불리는(이젠 거의 확정이죠 ㅎ) 페이스북의 마크 주커버그 이야기이기 때문입니다. 보기 전에도 기대를 했고 보고 나서 역시 보길 잘했다는 생각을 했습니다. 그냥 마크 주커버그가 하버드에서 페이스북을 만들고 창업해서 성공하기까지의 얘기를 영화로 담은 것 이지만 그 안에서 참 많은 생각을 한 것 같습니다. 이 책의 원작은 The Accidental Billionaires라는 책으로 그 내용은 여기에 잘 정리가 되어 있더군요.

아래 내용에는 스포일러가 포함되어 있을 수 있으니 영화를 안 보신 분은 아래글을 마저 읽기전에 참고하시기 바랍니다.

하버드커넥트와 더페이스북
영화가 나오기 전에 소셜네트워크라는 영화가 약간 마크 주커버그를 비난하는 것으로 들었었고 영화 개봉 전에 주커버그가 1억불을 사회에 기부한 것도 곧 이어질 비난흐름에 대한 이미지를 위해서 그랬다는 얘기도 있었는데 사실 영화를 보면 그런 쪽에 초점이 있다는 느낌은 저로써는 그다지 들지 않았습니다. 물론 아이디어를 훔치고 친구를 내치고 하는 그런 부분에 대한 내용은 나왔지만 이런 것은 사실에 기반한 것으로 영화에서 그다지 주커버그를 나쁜 캐릭터로 비추고 있다는 느낌은 주지 않았습니다. 약간의 나쁜 이미지를 주고 반대로 인간적인 면모도 보여주고 하는 등....

비난의 핵심은 주커버그가 Winklevoss형제의 하버드커넥트의 아이디어를 훔쳤다는 것인데 저는 별로 그런 생각이 들지 않았습니다. 영화이므로 어느정도의 픽션은 들어갔겠지만 영화상만으로 봤을 때 주커버그가 윙클보스형제의 하버드커넥트를 만들어 주겠다는 얘기를 하고는 연락을 피하면서 "더페이스북"을 만들고 어느정도 만들어지자 하버드커넥트에 회의적인 반론을 제기하면서 일하기를 꺼려하고 더페이스북을 오픈한 것은 도의적으로 문제가 있고 주커버그도 더페이스북에 확신(?)을 할수 없었기에 어느정도 진행되기 전까지는 하버드커넥트에도 양다리를 걸치고 있었던 것은 확실한 것 같습니다. 근데 이 문제는 이 문제고 아이디어를 훔쳤냐 하는 것은 좀 다른 얘기로 생각됩니다.

더 정확히 말하자면 주커버그가 하버드커넥트의 아이디어를 듣고 "더페이스북"의 아이디어를 생각해 낸것은 명확하지만 그게 머 큰 문제냐하는 것이 제 생각입니다. 아이디어가 중요한 시대이긴 하지만 "괜찮네"정도의 아이디어는 널려있다고 생각하고 핵심을 그것을 실체화하는 데 있다고 생각합니다.(아이디어가 중요치 않은건 아닙니다. 그 아이디어에서 혁신이 일어나니까요.) 주커버그가 하버드커넥트를 윙클보스형제와 같이 만들었다면 지금의 페이스북의 위치에 페이스북대신에 하버드커넥트가 그 위치에 있었을까요? 저는 절대 그렇게 생각하지 않습니다. 사실 하버드 커넥트도 아주 새로운 아이디어도 아니었습니다. 주커버그가 처음 아이디어를 듣고 한 질문 "Myspace랑 Frendster랑 머가 다른데?"(Frendster는 자막으론 해석도 안해주더군요 ㅠㅠ)에도 나타나있듯이 나머지 개념은 이미 기존의 SNS가 가지고 있는 아이디어였고 주커버그의 눈을 반짝거리게 한 "하버드 생만 이용가능하다"는 부분만 가져온 것이었습니다.

Image by Paul Walsh via Flickr

나머지 아이디어는 Myspace랑 Frendster의 아이디어를 가져온것은 괜찮고 "하버드 생만 이용가능하다"를 가져온 것은 도둑질이므로 안된다 하는 것은 좀 이상하다고 생각합니다. 이것을 훔쳤다고 얘기한다면 피카사는 플리커의 아이디어를 훔쳤고 마이스페이스는 싸이월드를 훔쳤고 버즈는 트위터의 아이디어를 훔치고 미투데이도 트위터를 훔치고 다시 요즘은 미투데이를 훔쳤다고 해야 맞는게 아닐까요? 그렇지 않다면 가까운 사람의 아이디어를 훔친게 문제라는 건데 아이디어의 훔친 것의 여부를 가깝냐아니냐로 판단한 것은 저로써는 좀 이상해 보입니다. 영화내의 대사대로 주커버그는 하버드커넥트의 코드를 단 한줄도 가져오지 않았습니다. 만들던 서비스를 가져다가 개량해서 자신의 것인 것처럼 만들었다면 모를까 얘기만 듣고 만들어낸 것을 도둑질이라고 한다면 IT에서 창업을 생각하시는 분들은 남의 아이디어를 듣지 않도록 귀를 막고 다녀야 할지도 모르겠습니다.

중요한 것은 실행력이라고 생각합니다. 회사등에서 수없이 듣는 다른 회사의 성공한 서비스같은 것을 보고 "별거 아냐 우리도 맘만 먹으면 할 수 있어"라던가 "우리도 생각했는데 뒷통수 맞았다"라는 말들을 저는 "능력없음을 보여주는 대표적인 발언"이라고 생각하고 있고 그냥 생각으로 있는 아이디어와 그걸 구체화하고 실체까지 만들어낸 능력 조차 구별하지 못하는 것이라고 생각하고 있습니다. 몇년전에 미투데이가 국내에 서비스를 시작했을때 그보다 몇주전에 나온 플레이톡이라는 서비스가 미투데이를 배꼈다고 논쟁이 일어났던 적이 있습니다. 어떤 모임에서 만박님이 얘기하신 서비스에 대한 얘기를 듣고 플레이톡의 운영자가 배껴서 만들었다느 것이 논란의 핵심이었습니다. 결국은 미투데이가 성공적으로 살아남았지만 이건 미투데이가 원조라거나 해서가 아닙니다. 그냥 미투데이의 운영능력이나 미투데이만의 문화를 만들어내는 능력이 더 뛰어났기 때문이죠. 영화에서 무임승차를 하려는 것은 주커버그가 아닌 오히려 윙클보스형제라는 생각입니다. 아주 구체적인 부분이 아니라면 IT에서는 아이디어는 공유되고 더욱 발전해야 한다고 생각하고 있습니다.

이런 저런 생각들...
영화내내 실리콘밸리의 문화가 자연스럽게 영화속에 묻어납니다. 우리나라가 갖지 못한... 우리나라의 벤쳐가 성공하지 못하는 핵심중의 하나라고 생각하는 실리콘밸리의 문화.. 성공하려면 실리콘밸리로 가란 말이 괜히 있는 것은 아니겠지요. 이것을 보는것 만으로도 개발자로써 영화를 보는 재미가 꽤 있는것 같습니다.

페이스북의 히스토리는 잘 모르고 있었지만 냅스터의 숀파커는 페이스북에 지대한 영향력을 끼칩니다.(그 결과로 주식의 7%를 가지고 있더군요.. 7%면 얼마야 덜덜덜) 사실 영화내에서 숀파커는 그렇게 좋은 캐릭터로 비쳐지지 않습니다. 놀기 좋아하고 약간은 허풍도 치는 캐릭터이고 노골적이진 않지만 영화내에서는 은연중에 숀파커가 더페이스북의 CFO인 알도를 내쳐버리는 것으로 비쳐집니다. 주커버그는 그 사이에서 고민에 빠져있는 것으로 표현이 되죠.(따로 반대행동도 하지 않지만요.) 약간은 좋지 않은 이미지로 비쳐졌지만 숀파커가 끼친 영향은 대단합니다. 영화속에서 숀파커는 주커버그의 우상처럼 비쳐지는데 초기단계에서 더페이스북의 미래를 내다보고 이건 정말 크게될 사업이라는 생각을 심어준 것이나 "더페이스북"에서 The를 빼버리라고 한 것이나 벤쳐캐피탈에서 투자를 받아내도록 하고 페이스북을 확장하게 해준 것은 지금의 페이스북을 만드는데 엄청난 공헌을 했다고 생각합니다. 그가 없었다면 영화속에서 숀파커가 빅토리아시크릿에 대한 얘기를 한 것처럼 지금처럼 크기전에 군침을 삼키고 있던 구글이나 MS에 페이스북을 헐값에(지금의 가치에 비하면 헐값) 팔아버렸을 수도 있습니다.

꽤 기분좋게 보았던 영화입니다. 실리콘밸리의 문화도 영화속에 잘 묻어있는 것 같고 너무 픽션이 가미되지도 않고 아주 현실적으로 잘 표현한 것 같습니다. 제가 느끼기엔 주커버그를 비난했다기 보다는 엄청난 성공을 한 주커버그를 둘러싼 비난, 불미스런 일들, 소문들에 대해서 사실적으로 잘 엮어놨다는 느낌입니다. 영화는 딱히 한쪽의 편을 들지 않고서요. 오덕스런 개발자의 마인드로 세계 최고의 성공까지 이루어내는 그 과정에서 상당히 많은 공감대를 느낄 수 있었고 한편으로는 모든 것을 퍼부을 만큼 매료된 아이디어를 가졌다는 것도 부러웠습니다. 
광고를 다는 것은 쿨하지 못해 스탠포드에도 오픈하자. 팔로알토에도 우리를 알려야지 냅스터는 실패한게 아냐. 음악산업의 패턴을 완전히 바꿔버렸으니까

영화내의 위와 같은 대사들은 개발자로써 왠지 마음을 동하게 했습니다. 뭔가 동질감 비슷한 거라고나 할까요? 어쨌던 재밌는 영화였습니다. 마지막으로 영화를 보면서 주커버그는 저때부터 슬리퍼를 신고다녔구나 하는 생각이 들더군요 ㅎ

My Comment..
영화에 대한 글이어서 넘어가려다가 다 읽어보고서 가져왔다.. 그 때 당시 '소셜네트워크' 라는 영화가 나왔다는 것은 알았지만, 딱히 내 관심사도 아니고해서 넘겼던 영화다.. 내 관심사는 액션쪽을 선호하기 때문에 영화를 보면서까지 IT 에 관련된 생각 혹은 관심이 가거나 그러지는 않았으니 말이다..

그런데 글을 보니 봤다면, 재미있었을 법한 영화 같다.. 기타 루트를 통해서 영화를 한 번 봐야될듯하다.. 과거에 나라면 모르겠지만, 지금은 그래도 과거랑 비교하면 나름 IT 에 대한 말을 하면, 대략이라도 알아듣고 판단은 서는 시점이기 때문이다..

그 때 봤다면, 재미 없는 영화 지루한 영화였을테지만, 지금 보면 현실과 좀 맞춰가면서 여러가지 생각을 할 수 있는 상황이 나올수도 있겠다 싶다..

[EP]제11회 한국 스프링 사용자 모임 세미나 후기 #2..

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

SpringOne 2010 참관기 - 정상혁
얼마전에 열렸던 Spring과 Grooby를 주제로 하는 컨퍼런스인 SpringOne2GX 2010에 참석하셨던 내용을 생생하게 공유해 주셨습니다.

Keynote
로드 존슨이 키노트를 진행하였는데 J2EE Design and Development를 쓸 당시가 31세 정도였다고 하니 정말 대단하는 생각을 했습니다. 로드 존슨은 현재는 코딩은 안하고 있고 스프링소스의 전략과 개념적인 부분에 대해서만 집중하고 있는 것 같았습니다. 로드 존슨은 Portability, Pruductivity, Innovation에 대해서 얘기했는데 Portability는 이번 컨퍼런스에서 가장 중요하게 다뤄진 개념으로 여러 실행환경에서도 동작하게 하는 것을 목표로 하고 있으며 Productivity는 STS와 SpringRoo에 대한 부분이고 Innovation은 NoSQL에 대한 지원과 메시지큐등의 준비에 대한 부분이었습니다.

SpringOne 2010 참관후기 발표발표하시는 정상혁님

Spring 3.1
기존의 일관성을 그대로 유지하면서 최근 경향을 반영하였습니다. Cache Abstraction을 위해서 @Cacheable가 추가되었으며 <cache:annotation-driven />와 같이 기존의 Transaction과 유사한 시맨틱을 가지고 있습니다. 디폴트는 ConcurrentHashMap이며 모든 시나리오를 커버하려는 것은 아니고 80%정도의 시나리오를 커버하는 것이 목표입니다. 개발환경등을 분리할때 기존처럼 폴더를 나누거나 하는 등의 어려움을 없앨 수 있도록 Bean profile로 프로파일 개념을 도입하였습니다. Custom namespace에서 Java Config 확장을 지원하여 하위프로젝트들에서 설정의 간편화를 기대할 수 있게 되었습니다.

과거에는 XML을 사용하는 것이 컴파일도 안해도 되서 더 좋다는 추세였는데 이제는 Maven등으로 컴파일과 관리도 편해졌기 때문에 애노테이션등을 이용해서 다시 자바로 들어가고 있는 추세입니다.  3.1 GA는 2011년 3월경 3.2는 2011년말로 발표되었지만 여태 그랬듯이 출시일정은 그다지 믿지 않고 있으며 질의시간에서도 자신들은 일정보다는 완성도를 더 중시하고 있다고 대답하였답니다.

Spring과 Java EE6
인터넷에서 많은 논쟁이 있었던 내용으로 "시너지냐 경쟁이냐"라는 제목으로 유겐휠러가 발표를 했습니다. 시너지냐 경쟁이냐는 부분에서 유겐휠러는 시너지 관계라고 답했으며 JavaEE6 스펙을 잘 사용하는 방법이 스프링이고 스펙을 쓸수 없는 곳에서도 적용할 수 있도록 하고 있으며 스프링은 여전히 많은 선택권을 제공하고 있습니다.
왜 REST표준을 사용하지 않고 따로 쓰고 있냐는 비난도 많이 있었는데 스프링소스는 기존의 스프링 유저들의 경험을 중요하게 생각하고 있기 때문에 억지로 표준을 끼워맞추기 보다는 여러가지 선택권을 주는 쪽으로 진행하고 있습니다. 스프링은 거의 대부분의 경우에 젠틀하고 여유로운 모습으로 항상 다양한 선택권을 주는 쪽이었지만 유일하게 양보하지 않는다고 느껴지는 부분은 DI에 대한 부분이었습니다. DI의 표준은 JSR299이지만 유겐휠러도 이 표준에 대해서는 별로 좋지 않다는 식으로 회의감을 표명했습니다.

분산캐쉬
메모리를 Heap에 두지 않고 외부에 두어 GC가 필요없도록 하는 BigMemory라는 솔루션을 Teracotta가 내놓았으며 이것은 모든 경우에 적용되는 것은 아니고 캐쉬를 많이 쓸 경우 GC시간이 비약적으로 늘어나서 문제가 되는 경우에 대한 대안입니다. Gemfire는 스프링소스가 인수한 솔루션으로 유명한 곳의 레퍼런스들을 가지고 있으며 약간 Eh캐쉬랑 경쟁관계에 있지만 스프링은 이 2가지 모두 지원하고 있습니다.

NoSQL
Spring data 프로젝트를 통해서 NoSQL을 지원하며 Hadoop도 지원예정에 있습니다. 스프링으로 NoSQL을 사용하는 방법으로는 GORM으로 Redis나 Gemfire를 사용할수 있으면 SpringRoo에서도 Neo4j 애드온으로 지원하면 개발자가 선택적으로 로우레벨 API도 사용가능하도록 제공하고 있습니다.


RabbitMQ
RabbitMQ는 스프링 소스가 사들인 솔루션으로 Protocol기반의 메시징 큐이며 Active MQ같은 API기반의 JMS 메시지 표준이 있지만 다른 환경에 대한 지원을 위한 것입니다.

SpringRoo
SpringRoo에는 GWT, GAE, DB 리서브 엔지니어링이 추가되었으며 이번 컨퍼런스에서 편애라는 생각이 들 정도로 SpringRoo를 띄워주려는 분위기가 느껴졌는데 SpringRoo를 Grails급으로 격상시키려는 의도인듯 합니다. SpringRoo는 샘플코드의 전파경로로도 의미가 있다고 생각합니다.

Demo
SpringRoo에 대한 Demo는 지난 공감세미나에서 보여주셨던 MVC기반의 데모를 GWT기반으로 간단하게 시연해서 보여주셨습니다. 물론 이렇게 화면까지 만들어졌다고 다 끝난것은 아니고 여기에 스프링과 GWT와 ORM을 이해할 수 있어야 하지만 샘플코드로 공부하기에도 좋습니다.
이번 컨퍼런스에서 나온 Spring Insight 데모를 이어서 보여주었는데 Spring Insight는 모니터링 툴로써 구글과 협력하여 Speed Tracer 브라우저 플러그인으로 웹사이트의 동작을 녹화할수 있고 이에 대한 성능모니터링을 볼 수 있습니다. 성능 및 네트워크에 대한 모니터링도 제공하고 있으며 네트워크 모니터링에 대한 부분을 보면 JDBC사용에 대한 부분도 Trace가 되며 이를 클릭하면 Spring Insight와 연결되어 클라이언트와 서버의 모니터링을 한꺼번에 할 수 있습니다. 현재는 개발환경에서 무료로 쓸 수 있는데 성능저하 없이 Production모드에 적용하려는 시도가 있으며 현재 스프링에서도 JRebel과 비슷한 자동로딩을 지원할 수 있도록 개발하고 있습니다.

Spring Insight로 프로파일링을 하는 화면

분석 - 스프링을 둘러싼 전략들
지난 10년을 돌아보면 현재의 스프링은 공존(co-located) 아키텍쳐로 모든 티어가 함께 있지만 과거 EJB시절에는 웹티어와 비즈니스 티어의 물리적인 분리를 하고 이것이 더 확장성이 있다는 주장이었습니다. 분산의 제1법칙은 분산하지 말라입니다. 로드 존슨이 이 분산아키텍쳐를 실제로 써보니 별로라는 인상을 받았고 미들티어가 따로 존재하지 않아도 수평적인 확장에 아무런 문제가 없다는 주장을 하였습니다.
과거 이렇게 분산했던 이유중에 하나는 이렇게 해야 미들웨어를 더 많이 팔수 있었기 때문이고 벤더들을 위한 구조이지 개발자와 사용자가 필요한 구조는 아니었습니다. 농담(?)으로 톰캣을 사용하지 않는 이유는 CTO가 벤더들과 골프를 치기 때문이라는 얘기가 있을 정도였습니다. 최근 EJB 3.1스펙도 스프링과 동일해졌습니다.

스프링의 프로그래밍 모델은 이미 보편적인 프로그래밍 모델이 된 Dependency Injection과 핵심로직에 침범적이지 않은 인프라성 코드인 AOP, 소비쪽에서는 변경할 필요가 없는 Portable Service Abstraction입니다. 이제는 DI는 스프링만의 것이 아니고 Eclipse 4.0이나 Android에서도 쓰이고 있으며 나중에 스프링을 안쓰게 되는 때가 오더라도 DI는 스프링이 프로그래밍에 남긴 것이 되지 않을까 생각합니다.

오픈프레임웍만으로는 돈이 되지 않기 때문에 비즈니스 모델에 대한 고민을 하게 되었습니다. 회사도 설립하고 투자도 받아서 수익을 발생시켜야 하는데 프레임웍만으로는 쉽지 않았기 때문에 Tomcat주도 업체인 Covalent등을 인수하고 2009년 VMWare에 인수되었습니다.

저장소는 분산되고 서비스는 통합되는 등 기술환경이 많이 변화되어 메시지큐도 필요해지고 모니터링 도구들도 더 발전한 것들이 필요하게 되었습니다.

실행환경에 Portability를 제공하는 레이어를 PaaS 클라우드를 준비합니다. OS수준의 가상화 환경에서 이미 JVM이 Portability를 가지고 있는데 프레임웍차원에서의 Portability가 어떤 의미가 있는가에 대해서 의문이 있을 수 있는데 그외 환경에서 필요하다고 주장하고 있으며 이는 서블릿스펙만 지원하고 있는 GAE이 가장 반길것으로 생각하고 있습니다.

논란이 있긴 하지만 점점 클라우드에 대한 요구는 늘어나고 있습니다. 클라우드 서비스에 올려서 Lock-in이 되면 업체입장에서는 리스크가 있지만 여러 클라우드 업체가 생겨나 옮겨다닐수 있게 되면 업체입장에서는 리스크가 줄어들고 스프링이 이 역활을 하려고 하고 있습니다. 이렇게 기능적인 부분을 스프링이 제공하면 PaaS 제공자는 안정성, 편의성, 가격정책으로 경쟁력을 가질 수 있습니다.

SpringOne2GX 2010에 대한 더 자세한 내용은 정상혁님이 블로그를 통해서 계속 올려주고 계십니다. 정상혁님의 발표자료는 KSUG블로그에 올라와 있습니다.

정상혁님의 발표는 저번에 SpringRoo에 대한 발표이후 두번째인데 약간 산만한 느낌을 주시면서(내용이 산만하다는 건 아닙니다.) 딱히 유머를 던지지 않아도 왠지 발표가 유쾌하게 느껴지는 매력이 있는것 같습니다. 스프링의 전략이나 각종 기술에 대한 얘기등 자칫 지루해 지기 쉬운 주제임에도 불구하고 중간중간 정상혁님의 경험이나 생각을 잘 섞어서 집중해서 들을수 있었던 것 같습니다. 값비싼 세미나의 내용을 공짜로 생생하게 전해듣게 되어 스프링 소스가 생각하고 있는 방향에 대해서 꼽씹어 볼 수 있는 시간이었던 것 같습니다.(전 특히 이런 총체적인 트랜드를 좀 이해하려고 하는 편이라...) 왠지 듣고나면 기분이 좋아지는 발표였네요.

Spring Framework 3.0을 이용한 RESTful 웹 서비스 구현 - 박찬욱
Spring 3.0이 나온지 어느새 1년 가까이 되었고 3.0에서의 큰 변화중 하나가 REST에 대한 지원이었습니다. REST는 JAXRS라는 표준이 있는데 스프링은 그 이전에 이미 애노테이션을 적용하고 있었기 때문에 JAXRS를 도입할 것인가 그대로 진행할 것인가에 대한 논의가 있었지만 현재는 스프링의 기존 애노테이션을 그대로 재사용하고 있습니다.

Spring Framework 3.0을 이용한 RESTful 웹 서비스 구현 발표발표하시는 박찬욱님

URL Template Variable Mapping을 지원하여 @RequestMapping에 템플릿 변수를 매핑할 수 있게 되었습니다. 뷰에도 변화가 있었는데 ContentNegotiatingViewResolver가 Request의 정보를 가지고 응답을 보낼 뷰를 결정하게 됩니다. RestTemplate으로 클라이언트사이드의 지원이 추가되어 JDBCTemplate처럼 사용할 수 있으면 테스트코드를 작성할 때도 유용합니다.

기존의 MVC코드에서는 일반적으로 상당히 긴 URL을 가지는 경우가 많습니다. 리소스기반으로 REST로 변경하면 URL을 줄일수 있고 view.jsp같은 액션은 HTTP 메서드로 구분하게 됩니다. ContentNegotiatingViewResolver가 뷰를 결정하는 방법은 .json이나 .xml같은 URL확장자를 통해서 하거나 ?RESPONSE_TYPE=JSON처럼 파라미터를 이용하거나 [application/json]같은 미디어타입(MediaType)을 이용해서 결정하게 됩니다.

MVC와 REST의 URL을 비교한 모습HTTP Method와 Resource URI와 Message Type의 연결 화면

REST를 통해서 JSON이나 XML로 데이터를 클라이언트에 내려주게 되고 이렇게 할 경우 서버측에 View는 존재하지 않게 됩니다. 때문에 데이터를 가져오기 위해서 jQuery등으로 Ajax로 데이터를 가져오게 되면 @RequestBody를 통해서 클라이언트가 body로 보낸 데이터를 받을 수 있습니다.

마지막으로는 REST개발시에 어려운 부분에 대해서 나누어 주셨는데 URL Design의 어려움, 요청단위 수립의 어려움등이 있었으며 Server Stateless, CLient Stateful 모델을 구현해야 했으며 아직 개발패턴이 정립되지 않았습니다. 반면 보안에 대한 부분으로 Resource에 대한 인증 및 접근 권한관리는 현재 나와있는 OAuth나 Digest같은 기술로도 이미 충분하다고 생각합니다.


유독 마지막 세션에 대한 정리가 좀 적은 것은 제가 집중해서 듣지 못했기 때문인데 이는 세션발표준에 나오던 설명의 흐름중 일부가 오해의 여지가 있다는 생각이 들어서 그 생각에 휩싸이면서 집중해서 듣지 못했습니다.

제가 생각에 휩싸인 부분은 설명 중에 나왔던 "REST는 뷰가 없이 JSON/XML로 프론트에 데이터를 내려주는 형태라서 프론트앤드에서 Ajax로 데이터를 가져와야 한다" 라는 부분 때문이었는데요 REST에는 Response의 형태는 따로 강제되지 않고 있기 때문에 REST에 대한 오해의 여지가 있다고 생각이 들었고 위 시나리오가 발표의 주흐름이었기 때문에 맞는가 아닌가하는 생각에 빠져서 그 뒤부터는 많이 집중을 못했었습니다.

하지만 이 부분은
KSUG 메일링을 통해서 세미나 후에 약간의 의견을 주고 받았었는데 한정된 발표시간에서 박찬욱님이 REST를 이용했을 때 View를 페이지마다 두지 않고 처리하는 하나의 예시를 설명하는 부분으로 강조되었던 부분이지 REST라는 기술에서 응답의 형태를 강제한다는 한정을 지려는 의도는 없으셨음을 확인했습니다.  알고 보니 이부분에 집착한 건 저뿐이고 대부분은 융통성있게 해석해서 받아들이셨더군요. ㅠㅠ

이 부분에 대한 논의에 구체적인 내용은 KSUG 그룹스에 있으므로 참고하시기 바랍니다.

뒷부분 세미나에 많이 집중하지 못한 것은 약간 아쉽지만 그래도 메일링을 통한 논의를 통해서 여러가지를 다시 생각해 보게 되었던 것 같습니다.

Epilogue
개인적으로 KSUG와 약간 연관이 있기에(더 정확히는 KSUG 운영진 분들과..) 너무나 당연한듯 참석한 세미나였지만 정말 얻은게 많은 알찬 세미나였다고 생각합니다.(이래서 10만원씩 하는 쓸데없는 컨퍼런스 보다는 이런 커뮤니티 세미나를 훨씬 좋아하게 되는...) 업무를 자바로 하고 있지는 않지만 그래도 봄싹에서 이런저런 활동하면 자바를 놓지는 않고 있었는데 올해 이런저런 많은 것들에 손을 대면서 자바에 상당히 소홀히 하게 되었었습니다. 알고는 있었지만 주변에 자바하는 사람들이 너무 많다보니 마치 저도 그 일원인양 크게 의식하지도 못하고 있었던 듯 한데 최근에 자바를 제가 얼마나 모르고 있는지에 대해서 크게 느끼고 있는 가운데 이번 KSUG세미나 많은 생각과 함께 동기부여에 대한 어느정도 기폭제가 되는 듯한 기분입니다. 듣고 넘어가는 게 아닌 스프링을 좀 더 적극적으로 배워봐야겠습니다. ㅎ

[EP]제11회 한국 스프링 사용자 모임 세미나 후기 #1..

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

지난 13일 명동에서 KSUG가 주최하는 제11회 한국 스프링 사용자 모임 세미나가 열려서 갔다가 왔습니다. 10회 세미나가 4월 17일에 열렸으니 6개월여만이군요.

Keynote
시작은 KSUG의 회장이신 fupfin님이 Keynote(?)로 시작되었습니다. 보통 컴퓨터 사이언스라고 부르는데 이 단어는 약간 이상하게 들립니다. 사이언스라는 것은 무언가 발견해내는 과정인데 프로그래밍은 문제를 해결해 나가는 과정입니다. 


스프링은 스프링이 복잡한 것이 아니고 스프링이 해결하려는 문제가 기존의 스트럿츠가 해결하려고 했던 문제 들에 비해서 훨씬 복잡한 문제를 해결하려고 하기 때문이고 각 문제별로 해결하는 방식을 보면 오히려 아주 단순합니다.

프레임워크를 어떻게 정의하는지 보겠습니다.

프레임워크는 공통적인 고수준의 패턴이고 클래스이다. - Larry Best

문제를 해결하려는 사고방식이고 그것을 코드로 만든 것이다. 그래서 한가지 문제를 여러가지로 해결 할 수 있다. - Kent Beck

애플리케이션의 뼈대를 구축하는 것이다. - Mary Shaw


발표하시는 fupfin님Kent Beck의 Framework에 대한 정의

그러면 아키텍쳐란 무엇일까요? 켄트벡은 패턴으로 문제를 해결하려고 하면서 아키텍쳐가 발현되는 것이고 한번에 나오는 것이 아니라 작은 스텝을 통해서 점점 진화하게 되는 것이라고 했습니다. 초반에 아키텍쳐를 잡아놓은 것이 후반에 변경사항에 대처를 못하게 되고 이것이 개발자를 어렵게 만드는 경우가 많이 있습니다.

스트럿츠2 역시 좋은 프레임워크라고 생각합니다. 여기서 스트럿츠2는 앞에서 얘기한 Larry와 Mary의 생각을 적용하고 있다고 볼 수 있습니다. 이는 총체적으로 문제를 해결하려고 하고 있는 반면에 스프링은 문제해결을 위해서 여러가지 중에 선택해서 사용할 수 있도록 하고 있습니다. 또한 스트럿츠2는 특정 패턴을 적용하려고 하고 이 부분의 문제가 발견되면 다른 패턴으로 변경하는 식으로 대처하고 있지만 스프링은 이렇지 않습니다. 핸들러 같을 것을 보면 그냥 Object이고 내부적으로는 버전이 올라가면서도 거의 달라지지 않았습니다. 스트럿츠가 표준을 잡고 강제하려고 하고 있다면 스프링은 선택권을 개발자에게 주기 때문에 발전 가능성이 많이 있습니다.

Spring Trouble Shooting - 백기선
백기선님의 최근 교육을 진행하면서 받은 여러가지 질문과 트러블 케이스들의 경험을 모아 스프링 트러블 슈팅이라는 주제로 발표를 했습니다.

Spring Trouble Shooting 발표발표하시는 백기선님

@Autowired
같은 타입의 빈이 등록되어 있을 경우 @Autowired하였을 때 의도치 않은 결과가 나오는 트러블 상황을 보여주었습니다. @Autowired의 동작원리를 이해해야 하는데 해당 타입의 빈이 1개있으면 바로 찾고 여러개일 경우에는 같은 이름의 빈이 있어야 동작합니다. 때문에 의도치 않은 장애를 피하려면 같은 타입의 빈이 여러개 일경우 명시적으로 이름을 설정하고 주입받을 곳에서 @Autowired 대신 @Resource를 사용하라고 하였습니다.

또한 컴포넌트 스캔( <context:component-scan default-package="easy"/> )과 <bean/> 설정을 혼용해서 쓰지 않아야 합니다. 혼용해서 쓸 경우 컴포넌트 스캔뒤에 XML의 DI정보로 덮어쓰기 때문에 XML로 등록할 빈은 @Component를 사용하지 말아야 합니다.

@Transactional
트랜잭션을 사용하기 위해 @Transactional 애노테이션을 붙힌 클래스에 인터페이스를 사용하려고 추가하니까 Bean을 제대로 찾지 못하는 트러블 상황을 보여주었습니다. @Transactional을 사용하면 프록시가 만들어지게 되는데 인터페이스가 없을 경우에는 클래스를 가지고 프록시를 만들지만 인터페이스가 있게 되면 클래스가 아닌 인터페이스로 만들기 때문에 프록시 타입은 인터페이스의 타입이 됩니다.
@Transactional을 사용하면 이미 스프링의 AOP를 사용하고 있는 것이고 <tx:annotation-driven />는 인터페이스가 있으면 JDK프록시를 사용하고 인터페이스가 없으면 CGLib프록시를 사용합니다. 인터페이스를 만들었다면 인터페이스를 사용하고 클래스기반으로 하고 싶다면 클래스기반 프록시를 명시적으로 선언해햐 하지만 별로 권하지는 않습니다.
ApplicationContext의 상속구조는 부모 ApplicationContext는 자식 ApplicationContext에 있는 빈에는 접근할 수 없고 자식 ApplicationContext는 부모 ApplicationContext에 있는 빈에 접근할 수 있습니다. 이때 AOP에 대한 설정과 AOP를 적용할 빈은 같은 ApplicationContext에 있어야 가능합니다. 부모에서 제대로 설정했다고 하더라도 자식 ApplicationContext에더 덮어쓰면 AOP가 되지 않기 때문에 부모에 등록할 것과 자식에 등록할 것을 잘 구분해야 합니다. 만약 패키지로 구분하는 것이 어렵다면 애노테이션으로 구분합니다.

DispatcherServlet 매핑
최근에는 DispatcherServlet의 URL 패턴에 /app/*를 사용합니다.
DispatcherServlet에 아무것도 등록하지 않으면 기본전략 빈들이 모두 등록 되지만 명시적으로 하나를 등록하게 되면 나머지 빈들은 등록이 되지 않게 됩니다. 때문에 기본 전략에 의지하다가 추가등록을 하게 되면 잘 돌아가던 서비스가 제대로 돌아가지 않는 문제가 생길수 있기 때문에 기본전략에 의지하기 보다는 필요한 전략을 등록하는 것이 좋습니다.

발표가 끝나고 깜짝 이벤트(?)로 토비의 스프링3의 저자이신 Toby님과의 iChat연결을 통한 질답시간이 있었습니다.

토스3을 공부하면 스프링을 잘할수 있는가에 대한 질문에 Toby님은 스프링을 공부하는데는 여러가지 방법이 있는데 개별 기술을 따로 공부하게 되면 새로운 것이 나올때마다 서로 연결이 안되서 어렵게 느껴질 수 있는데 오히려 전체를 이해하면 더 나을 수 있다고 하셨습니다. 스프링으로 만들어 놓은 것을 가져다가 쓰는 수준이 아니라 스프링의 개념과 철학을 이해하고 개발할 수 있도록 하는 것을 목적으로 쓴 책입니다. 중요한 것은 스프링 전문가가 되는 것이 아니라 스프링의 개념과 철학을 이용해서 자신이 개발하는 애플리케이션을 잘 구축하는 것이 더 중요하고 스프링보다 애플리케이션에 더 초점을 맞추어야 합니다.

분책에 대한 질문에 대해서는 분책을 하게되면 지금과 같은 종이를 사용할 수 없기 때문에 기대처럼 얇아지지 않아서 소용이 없을것 같다고 하셨고 후속책에 대한 질문에는 현재는 구체적인 것은 없고 당초 스프링의 이해, 실제로 어떻게 사용하고 선택하는가, 어떻게 확장하는가의 3부작으로 생각했었는데 마지막 확장에 대한 부분은 쓰지 못했다고 얘기하셨습니다.


간디 코스프레(?)도 하는 쇼맨쉽과 Head First시리즈가 생각나는 PPT가 상당히 인상적이었습니다. 저는 현재 스프링으로 업무를 하고 있지는 않기 때문에 트러블슈팅부분에 대해서는 바로바로 와닿지는 않았지만 트러블 슈팅으로 인한 스프링 개발의 권장사항을 미리 염두에 두고 있어도 충분히 도움이 될 만한 부분이라고 생각했습니다. 특정기술에 대한 설명같은 부분도 좋지만 이렇게 실제 개발할때의 실용적인 부분도 참 유용한것 같습니다.

Rich Domain Model - 조영호
리치 도메인을 이해하려면 리치도메인의 반대되는 개념을 먼저 이해하는 것이 쉽습니다.

Rich Domain Model 발표발표하시는 조영호님

1. 온라인 영화 예매 시스템
이해를 돕기위해 영화 예매시에 여러자기 조건에 따라 할인율이 적용되는 온라인 영화 예매 시스템을 구축하는 시나리오를 준비하셨습니다.
영화(Movie)가 첫번째 도메인 컨셉이며 상영(Showing)정보가 두번째 도메인 컨셉입니다. 세번째로는 할인정책(Discount)가 있는데 절대가격으로 할인하는 Amount Discount와 비율로 할인을 하는 Percent Discount가 있으며 할인규칙(Rule)이 네번째로 몇회차 영화에 할인해 줄것인가 하는 Sequence Rule과 무슨 요일 몇시에 할인할 것인가에 대한 Time Rule이 있습니다.
이 도메인들을 가지고 영화 예매를 할때 적당한 룰을 찾아 할인을 적용하여 그 결과로 예매(Reservation)을 생성하게 됩니다.

2. 데이터 - 지향 설계
데이터를 먼저 생각하고 무엇을 저장할 것인가를 생각하게 됩니다. 그러면 자연스럽게 ERD를 그리게 되는데 이것은 Anemic Domain Model이라고 부르며 테이블의 컬럼과 1:1매핑되는 클래스를 만들게 됩니다 이 클래스는 속성만 가지고 있고 getter/setter만 노출하게 됩니다. 그 후에 이 객체들이 어떻게 동작하는 가(프로세스)에 대해서 고민하게 됩니다. ReservationService를 만들고 예약정보를 보여주는 메서드를 만들고 구현체에서 데이터를 끌어오기 위해서 DAO를 만들게 됩니다. Movie와 Showing정보를 가져오고 Rule정보를 가져와서 적용여부를 판단하고 어떤 할인이 적용되는지 찾아서 적용한뒤 Reservation을 생성해서 디비에 저장하게 됩니다.

데이터 모델에 대한 ERD중앙집중식 제어 스타일의 흐름도

이게 일반적으로 개발하는 방식이고 데이터와 프로세스를 분리하게 되어 프로세스는 모두 서비스레이어에 몰아넣게 됩니다. 이걸 아키텍쳐 패턴으로 보면 Transaction Script 패턴이라고 부르며 실무에서 가장 많이 사용하는 아키텍쳐 패턴입니다.

3. 책임 - 주도 설계
우리가 처음 OOP를 공부할 때 배웠던 "상태와 상태를 처리하는 로직을 같이 두는 것이 OOP이다"라는 개념을 적용한 것이 Rich Domain Model입니다. 이는 데이터 기반이 아닌 책임기반(Responsible Driven)개발입니다. 데이터 - 지향 설계의 중앙집중식에서는 책임이 서비스에 모두 몰려있지만 책임주도에서는 책임이 분산되어 있으며 설계의 관점이 데이터와 프로세스가 아니라 책임기반으로 설계를 하게 됩니다. 그리고 보통 얘기하는 캡슐화는 책임기반으로 설계할 때 달성할 수 있습니다.

책임에 대한 CRC카드위임식, 분식식 제어스타일의 흐름도Rich Domain Model에 새로운 할인 객체를 추가한 모습

책임기반으로 설계할 때는 데이터와 프로세스는 생각하지 않고 이 시스템에 어떤 책임이 있는가를 고민해야 합니다. 시스템의 책임을 결정한 뒤에 어떤 도메인 컨셉에 할당할지를 고민하는 것입니다.
위 예제에서는 예매를 생성할 책임이 있는데 이는 Showing이 상영정보를 알고 있기 때문에 Showing에 할당합니다.(이때 CRC카드를 사용하는데 상단에는 클래스명을 적고 좌측에는 책임을 오른쪽에는 연관클래스를 적습니다.) 여기서 예매정보를 생성하려고 하니 가격을 알아야 하는데 가격을 가장 많이 알고 있는 Movie에 할당하고 필요한 할인율을 위한 책임을 위해 전략개체를 추가해서 DiscountStrategy로 전략패턴을 Movie에 적용하고 Rule을 추가해서 할인여부를 판단하게 됩니다.

설계는 What을 결정하고 구현은 How를 결정하는 것이라고 봤을 때 이 단계는 What을 결정하는 단계입니다. 클래스를 어떻게 만들고 데이터는 어떻게 가져올 것인가 하는 데이터에 대한 생각은 일단 여기서는 하지 않습니다. Anemic Domain Model은 실제적으로 보면 객체지향 설계는 아니고 객체지향 언어를 사용할 뿐입니다. Transaction Script의 단점은 수정이 어렵기 때문에 새로운 할인율이 추가되면 기존 코드를 수정해야 하며 그때문에 if-else구문이 많이 생기게 됩니다. Rich Domain Model의 장점은 OOP의 다형성의 활용이 가능하기 때문에 객체를 추가하고 구성을 바꾸는 것만으로 가능해지게 되고 이것이 Open Closed Principle입니다.

4. 아키텍쳐 & 프레임워크
Rich Domain Model로 설계했을 때 어떻게 구현을 해야하는 가는 프레임워크에 도움을 받을 수 있습니다. 레이어는 정해진 것은 없고 시스템마다 다르지만 앞서 얘기한 부분은 Domain 레이어에 대한 부분입니다. 여기서 중요한 점은 Domain 레이어는 최대한 캡슐화시키고 고립시켜야만 하고 그렇게 해야 POJO기반으로 할 수 있기 때문에 Domian레이어를 바로 노출하지 않고 그 위에 Service레이어를 두어 Service 레이어가 노출되도록 합니다. 여기서 서비스레이어는 Anemic Domain Model에 비해어 아주 간단해 지며 이 경우에는 Operation Script방식으로 코딩하는 것을 선호합니다. 당연히 레이어는 한방향으로만 의존성을 가지도록 해야하며 도메인레이어는 서비스레이어에는 의존하지 않고 하위의 Infrastructure에도 제한적으로만 의존하도록 합니다.

우리가 프레임워크를 쓰는 이유는 POJO로 개발할수 있어서 쓴다고 해도 과언이 아니며 POJO의 3대요소는 DI, AOP, Annotation입니다. 이 3가지 요소를 적용하면 비침투적인 프레임워크를 만들수 있으며 Lightweight 프레임워크라고도 부릅니다.(EJB는 아주 침투적입니다.) DI는 객체간의 의존성 관리이슈로부터 도메인 레이어를 보호하고 수성-사용의 분리 원칙을 적용한 것이며 스프링은 이를 지원하고 있습니다.

POJO의 3대 요소Data Mapper로 DB스키마와 객체모델을 연결한 화면

Rich Domain Model을 적용했을 때 객체모델과 DB스키마간의 불일치를 Impedance Mismatch라고 부르는데 이건 디비 설계과 객체지향 설계의 포커스는 완전히 다르기 때문에 당연한 결과입니다. 디비는 중복의 제거가 목적이고 객체지향은 행위의 효율성에 목적이 있습니다. 이 Impedance Mismatch를 해결하는 것은 아주 어렵기 때문에 데이터지향 설계를 주로 하게 되는 것입니다. 보통 Data Mapper를 사용해서 중간역할을 하도록 하는데 직접만들지는 않고 프레임워크를 사용하는 것이 일반적이며 Data Mapper를 가장 많이 사용하는 것이 Hibernate입니다.

결론
Rich Domain Model은 기술관점이 아닌 설계관점입니다. 자신이 정말 OOP로 설계를 하고 있는가를 먼저 생각하고 그 다음에 기술이 나와야 합니다. 물론 그렇다고 기술이 중요하지 않은 것은 아니며 비침투적인 프레임워크를 사용하지 않고 POJO를 사용하는 것은 거의 불가능합니다. Rich Domain Model을 자제해야 하는 경우는 비즈니스 로직이 단순하고 개발기간이 짧은 경우, 비침투적 프레임워크를 사용할 수 없는 경우, 개발 경험이 부족한 경우, O/R매퍼를 사용할 수 없는 경우나 OOP 설계 경험이 없다면 시도하지 않는 것이 좋습니다. Rich Domain Model을 적용하기 전에 이런 부분에 대한 학습이 필요하며 무조건 좋다는 것은 아니지만 Rich Domain Model이 실무적인 관점(Be Progmatic)에서 어느 경우에 유용할 수 있는 역략을 가질수 있도록 연마해야 합니다.

Q & A
실무에서 팀으로 할때는 어떻게 적용해야 합니까?

회사에서는 주로 성능위주로 많이 하게 되기 때문에 실무에서는 프로토타입정도로만 해봤습니다. 현실적으로는 팀원들의 지식 수준이 어느정도 유사할 경우에는 개발이 좀 빨라지게 됩니다.

관련해서 도움될 만한 책을 추천해 주세요.

객체 지향 - Applying UML and Patterns, 소프트웨어개발의 지혜(Robert C. Martin, Agile Software Development, Principles, Patterns, and Practices)
패턴 - Patterns of Enterprise Application Architecture(Martin Fowler)


저한테는 이번 세미나에서 가장 인상깊었던 세션이었습니다. Rich Domain Model이라는 저한테는 어렵게만 느껴지던 개념을 너무나 쉽고 논리정연하게 설명해 주셨던것 같습니다. 전해 주시는 내용들도 그 내용의 깊이를 알 수 있을 정도로 알찼지만 개념을 이해하기 위한 간단한 예시부터 Rich Domain까지 이어지는 흐름이 너무 자연스러워서 Rich Domain에 대해서 전혀 모르고 있던 저도 그 개념을 이해하기에 너무 좋았던 것 같습니다.
물론 저는 내공이 안되서 Rich Domain을 당장 쓰거나 하지는 못하겠지만 이 개념을 항상 염두에 두고 있는 것 만으로도 큰 도움이 될것 같다는 생각입니다. 언젠가는 Rich Domain Model을 적용해서 개발해 봐야겠지요 ㅎㅎ

[JAVA]데이터 타입에 대한 정의..

데이터 타입에 대해서 간략하게 정리를 하고자 한다.. Java 를 처음 배우면, 초반에 배우는 기초적인 내용들이다.. 하지만, 지금에 와서 이런것을 왜 올리느냐라고 한다면..

우선은 나에게 필요해서이고, 기초에 대해서 무시하고 넘어갔었음에 대한 후회이고, 일 하면서 데이터 타입 비교를 하면서 아주 작은 차이로 인해 그놈의 기초 때문에 오류를 겪었던 것이 기억나고 기타 등등의 이유로 인해서 정리해둔다..

네이버나 구글에 자료가 꽤 많긴 하지만, 내가 좀 알아보거나 이해하기가 쉽고, 내 스타일에 좀 맞는 자료를 찾았다.. 바로 asebn7 님의 블로그에 정리된 자료였다.. 해당 자료를 토대로 정리를 하되 내 스타일에 맞게끔 정리하였다.. 

자료형에 대한 간략한 패턴을 보고 본격적으로 들어가면 될 듯하다..



기본 자료형[Primitive Data Type]

자바 컴파일러에 의해서 해석되는 자료형태를 기본 자료형이라고 한다.. 기본 자료형에는 위 그림에서도 나오지만, 논리형 boolean, 문자형 char, 정수형 byte, short, long, float 그리고 실수형 double 이 있다.. 한 눈에 알아볼 수 있는 표로 보자면 아래와 같다..

그럼 하나씩 살펴보도록 하자..

boolean
boolean 은 true 와 false 두 가지 값만을 갖는 타입이다.. 해당 타입을 사용할 때는 아래처럼 선언을 해줘야 된다..

boolean testBool = true;
boolean testBool = false;

본인이 사용하고자 하는 메소드 내에서 선언 후에 위처럼 특정 선언을 안할 경우에는 false 가 자동 할당되어 에러가 발생하니 유의하도록 해야된다.. 또한, true 또는 false 에 따옴표[" "] 내지는 작은 따옴표[' ']를 사용하면 안된다..

char
char 는 2byte 의 문자하나를 입력하는 데이터 형이다.. 문자로 하면, 한글자를 뜻한다고 보면된다.. 즉, 문자 1개를 저장하는 데이터 형인 것이다..

char testChar = '1';

char testChar = 'a';

위처럼 선언을 해주면 되며, 자료형 중 유일하게 음수타입이 존재하지 않는다..

byte, short, int, long 정수 데이터형
기본적인 패턴은 char 와 똑같다고 보면된다.. 다만, 각각 표현할 수 있는 byte 가 틀리기에 그 부분을 주의 해야 된다..


byte 는 1byte 이며, 정수형 자료중 가작 작은 범위의 수치를 저장한다.. 주로 배열이나 데이터 전송의 기본이 된다..

short 는 2byte 이며, C 언어 등의 int 자료형과의 호환성을 위해 많이 사용한다..

int 는 4byte 이며, 모든 언어에서 기본이 되는 자료형이다.. 모든 정수 수치의 기본 구조라고 보면 된다.. 또한, + 연산자가 사용되면, int 형으로 바뀐다..

long 은 8byte 이며, int 자료형보다 큰 정수형 데이터를 저장하기 위한 자료형으로 초기화할 때는 소문자 l 이나 대문자 L 을 붙여줘야 된다.. 아래처럼 말이다..

long testLong = 123456L;

위 내용과 아래 메모장을 같이 참고하면, 조금 이해가 쉬울 듯 하다..

float, double 실수 데이터형
소수점을 가진 수를 표한하기 위해서 사용된다.. 그게 바로 float = 4byte, double = 8byte 다.. 단, float 선언시에는 조금 주의가 필요하다.. 아래 메모장을 보면 1.014f 또는 (float) 1.014 라고 되어 있는데 해당 부분을 좀 주의하면 된다.. 아래 메모장에는 없지만, 대문자 F 도 사용한다..


참조 자료형[Reference Data Type]
참조 자료형은 클래스 형태의 데이터 타입을 말하는 것으로 변수를 선언할 때 자바 API 에서 제공되거나 프로그래머에 의해서 만들어진 클래스를 자료형으로 사용할 때 이런 데이터 타입[클래스]를 지칭한다.. 해당 부분은 내가 정리하고자 했던 부분은 아니기에 간략하게 정의만 내리고 지나간다..

이상 정리가 끝났다.. 정리를 하면서 이곳 저곳 보면서 공부아닌 공부를 하다보니 조금 더 머리에 남게 되는 듯하다.. 이것이 포스팅의 장점일지도 모르겠다.. 과거에는 왜 몰랐는지.. ㅎㅎㅎ.. 내용이 좀 빈약하거나 그럴수 있겠지만, 나 스스로에게는 만족하는 내용이다.. 애초에 그랬던것처럼 어차피 나 스스로의 공부와 이해도를 높이기 위함이 목적이니 그런 부분에서 만족한다는 뜻이다..

항상 느끼지만, 세상 모든 범위에 있어서 기초라는 것은 참 중요하다.. 중요해..