Outsider's Dev Story: JAVA/Java 카테고리 글 목록https://blog.outsider.ne.kr/Stay Hungry. Stay Foolish. Don't Be Satisfied.2024-03-15T10:11:27+09:00Textcube 1.10.7 : Tempo primoThymeleaf 사용 소감Outsiderhttps://blog.outsider.ne.kr/9692014-12-15T19:55:21+09:002013-08-12T00:54:36+09:00<p>최근에 <a href="http://www.thymeleaf.org/">Thymeleaf</a>를 프로젝트에서 사용해 봤다. Thymeleaf에 대해서 들어본 지 한 1,2년 정도 된 것같은데 실제로 써본 것은 이번이 처음이다. 아주 다양한 케이스에 하드하게 사용해 본건 아니다.(사용한 버전은 2.0.x이다.)</p>
<h1>Thymeleaf</h1>
<p>Thymeleaf는 <a href="http://tiles.apache.org/">Tiles</a>, <a href="http://freemarker.org/">FreeMarker</a>, <a href="http://wiki.sitemesh.org/display/sitemesh/Home">SiteMesh</a>처럼 자바에서 사용할 수 있는 뷰 템플릿 엔진이다. <a href="http://www.springsource.org/">스프링소스</a>에서 만든건지는 모르겠지만 스프링소스에서 열심히 밀고 있기는 하고 Spring MVC와 통합이 잘 되어 있다.</p>
<p>Thymeleaf의 가장 큰 특징이라면 <a href="http://www.thymeleaf.org/doc/Natural%20Templating%20in%20Spring%20MVC%20with%20Thymeleaf%2020120217.pdf">네츄럴 템플릿</a> 기능을 들 수 있는데 쉽게 말하면 템플릿 코드자체가 그냥 HTML이기 때문에 뷰 파일을 WAS없이도 브라우저에서 직접 띄워볼 수 있다는 점이다. 이는 Thymeleaf가 다른 템플릿 엔진처럼 전용 문법(브라우저가 해석하지 못하는)을 사용하지 않고 HTML 엘리먼트에 속성으로 적어줌으로써 동작하기 때문에 Thymeleaf는 이를 해석해서 뷰 파일을 만들어주고 브라우저는 모르는 속성은 그냥 무시하므로 브라우저에서도 동작을 하게 된다.</p>
<pre class="line-numbers"><code class="language-html"><td th:text="${name}">Oranges</td>
</code></pre>
<p>위와 같이 작성하는데 th는 thymeleaf에 대한 속성이다. 브라우저에서 이 코드를 보았을 때는 <code><td>Oranges</td></code>와 다름 없으므로 그냥 그대로 보이고 Thymeleaf는 name이라는 변수 값으로 <code><td></code>안의 값을 대체해버린다. 그래서 Thymeleaf에서 작성할 때는 예시용 코드를 위처럼 같이 넣어주는 것이 일반적이다.</p>
<p>뷰 파일을 작업할 때 그러니까 JavaScript나 CSS 작업등을 할 때 WAS를 띄워야 하는 불편함을 둘째치더라도 변경한 정적 파일이 서버에 적용되는데 까지의 지연 시간(JRebel을 쓰면 훨 낫다.)은 무척 괴로운 일이기 때문에 이 기능은 무척 장점으로 보였고 처음 이 컨셉으로 Thymeleaf를 보았을 때 다음에 꼭 써봐야지 하면서 맘에 들었다. 솔직히 그때는 "이게 바로 내가 기다리던 템플릿 엔진이야"라는 정도의 반응이었다.</p>
<h1>단점</h1>
<p>결론부터 얘기하면 써보니 별로라서 다음에 선택권이 있다면 쓰지 않을것 같다. 물론 아주 하드하게 오랫동안 써본건 아니라서 여기에 쓰는 단점들에 대한 대안들이나 해결책들이 존재할 것으로 생각하지만(이런 것들을 알려주시면 감사~) 그 해결책들이 아주 깔끔하고 근본적으로 해결되는게 아니라면 내 생각이 크게 달라지진 않을것 같다.</p>
<ul>
<li><strong>네츄럴 템플릿을 이용해서 WAS없이 뷰페이지를 작업할 수 있는게 가장 큰 장점인데 실제로는 이렇게 작업할 수 없다. 불가능한 것은 아니지만 별 의미가 없어서 그냥 WAS를 켜놓고 작업하는게 낫다.</strong>(느린게 짜증나면 JRebel로...) Thymeleaf는 자체 파싱엔진을 가지고 있기 때문에 HTML코드가 완전한 XML이어야 하고 이는 설정에서 HTML5 모드로 하더라도 마찬가지다. 즉, 태그의 속성으로 템플릿문법을 사용하므로 범위를 명확히 하기 위해서 XML을 사용하고 있는 듯 하다. HTML도 XML기반이기는 하지만 훨씬 관대하기 때문에 XHTML strict 모드가 유행하던 몇년전 외에는 그렇게 사용하지 않는다. 그래서 평소 습관처럼 브라우저에 HTML작업을 하고 WAS에서 띄우면 거의 100% 컴파일 오류를 볼 것이다. 실수로 닫는태그를 안써준 것은 당연하고 <code><img></code>태그나 <code><input></code>태그등의 단독 태그를 모두 찾아서 닫아주어야 컴파일 오류를 피할 수 있다. 별거 아닌 작업이라고 말할 수도 있지만 HTML에서 닫는태그빠지거 찾는건 나에겐 무척 고통스럽고 경험상 컴파일 오류메시지가 그렇게 정확히 찝어주진 않는다. 일반적인 경우처럼 HTML 작업해주는 사람이 따로 있다면 이는 오로지 서버사이드에서 닫는 태그를 붙혀주어야 할 일이고 UI를 변경할 때마다 해야할 것이다.(HTML작업하는 사람한테 가서 태그는 꼭 닫아달라고 하던지...) (참고로 이 엄격한 XML 파싱을 끌 수도 있다고 들었는데 Thymeleaf가 구문을 정확히 파악해서 처리하는 지를 확실히 보장하기 어려운 듯 하다.)</li>
<li><strong>템플릿을 사용한다는 것은 서버의 변수를 넣어서 동적으로 만들기 위함도 있지만 페이지의 공통부분은 헤더, 푸터등을 별도의 템플릿으로 뽑아서 재사용하는 것도 포함된다. Thymeleaf에서는 이를 <code>include</code>로 불러오게 되는데 당연히 HTML에는 그러한 기능이 없으므로 인쿨루드는 동작하지 않는다.</strong> <code>include</code>를 쓰지 않으면서 템플릿 엔진을 쓴다는 건 당연히 말도 안되고 이 문제를 해결하기 위한 <a href="http://sourceforge.net/u/jjbenson/wiki/thymol/">Thymol</a> 자바스크립트 라이브러리가 있어서 이 라이브러리를 쓰면 일단 인클루드문제는 해결할 수 있어보인다.(써보진 않았다.) 하지만 긴급한 상황에서 대안은 될 수 있지만 계속되는 작업에서 Thymol을 HTML에 넣었다가 실제 Thymeleaf를 사용할 때는 빼는 작업을(당연히 실제로는 필요없는 것이므로) 반복해야 하는 것은 별로 좋은 해결책으로 보이지 않는다.<sup style="font-family:tahoma;"><a href="https://blog.outsider.ne.kr/969#footnote_969_1" id="footnote_link_969_1">1</a></sup></li>
<li>템플릿을 쓰면 많이 쓰는 것 중 하나가 컬렉션의 데이터를 반복해서 뿌려주는 반복구문이다. Thymeleaf를 처음부터 WAS에서만 쓰고 HTML파일만 따로 브라우저에서 해본적은 없지만 구조상 반복구문을 사용한 경우 HTML을 단독으로 열면 1번 반복한 것처럼 나올 것이다. 뷰 페이지를 작업하면 처음에는 1개로 작업하지만 5개일때 10개일때의 스타일을 잡아줘야 하는데 HTML입장에서는 반복구문이 전혀 아니므로 이런 건 볼 수 없고 그냥 각 부분은 10번이고 20번이고 복사해서 테스트한 뒤에 지워야 한다.(서버에 연결되어 있다면 Mock객체에 데이터만 추가하면 되겠지.) 사실 이건 앞에 얘기한 거에 비하면 아주 큰 문제까진 아니긴 하다.<sup style="font-family:tahoma;"><a href="#footnote_969_2" id="footnote_link_969_2">2</a></sup></li>
<li><strong>숙달이 되면 나아질 지 모르겠지만 태그에 속성으로 템플릿구문을 넣는 구조에서 오는 제약이 상당히 있어서 작성하다보면 원하는 HTML 구조를 어떻게 만들어야 하는지 고민이 상당히 될때가 있다.</strong> 고민만 되면 다행이겠지만 마땅한 해결책도 없다.</li>
</ul>
<pre class="line-numbers"><code class="language-html"><div class="row">
<div class="span3">Something</div>
<div class="span3">Something</div>
<div class="span3">Something</div>
<div class="span3">Something</div>
</div>
<div class="row">
<div class="span3">Something</div>
<div class="span3">Something</div>
<div class="span3">Something</div>
<div class="span3">Something</div>
</div>
</code></pre>
<p>예를 들어 위와 같은 HTML 구조를 만든다고 해보자. 리스트에 있는 데이터를 4개씩 Row를 구분해서 출력해 주고 싶다고 할 때 일반적인 템플릿엔진에서는 다음과 같이 작성할 것이다.</p>
<pre class="line-numbers"><code class="language-html">{{#each list}}
{{#if @index % 4 == 0}}
<div class="row">
{{/if}}
<div class="span3">{{this.name}}</div>
{{#if @index % 4 == 0}}
</div>
{{/if}}
{{/each}}
</code></pre>
<p>이는 전용 템플릿구문이 있고 HTML의 여는 태그와 닫는 태그를 그냥 문자열처럼 다루기 때문에 아주 유연하게 원하는 구조를 만들어 낼 수 있다. 하지만 Thymeleaf에서는 HTML 태그의 속성으로 템플릿구문을 작성하므로 Thymeleaf를 여는태그와 닫는태그를 한꺼번에 다루기 때문에 한참을 고민해도 이 문제를 해결할 수가 없었다.</p>
<pre class="line-numbers"><code class="language-html"><div class="row" th:each="item: ${list}">
<div class="span3" th:text="${name}">Something</div>
</div>
</code></pre>
<p>Thymeleaf에서는 위처럼 작성해야 하는데 <code>list</code>와 <code><div></code>태그가 연결되어 있기 때문에 중간에 div태그를 새로 만든다거나 하기가 좀처럼 쉽지 않다. 이 문제를 <a href="http://stackoverflow.com/questions/17812372/in-thymeleaf-how-can-write-theach-to-combine-rows-and-columns">Stackoverflow</a>에 질문해서 가능한 해결책을 찾기는 했지만 Thymeleaf에 대한 인상이 좋아질 정도의 해결책은 아니고 앞으로도 이와 비슷한 문제는 많이 만날 것이라고 생각한다. (추가로 Angular.js도 Thymeleaf처럼 태그에 속성으로 작성을 하고 있지만 Thymeleaf같은 뷰템플릿의 기능은 아니고 JavaScript와 연동되기 때문에 이러한 답답함은 많이 안느껴지는듯 하다.)</p>
<ul>
<li><strong>좀 사용해 본 결과 사용자가 그리 많지 않은 느낌이다.</strong> 대부분의 문제는 유저커뮤니티만 활성화 되어 있으면 해결가능하다고 보기 때문에 이 문제가 가장 큰 문제로 다가온다. 검색을 해보면 튜토리얼이라던지 소개라던지 하는 자료들이 대부분이고 다양한 활용사례나 문제해결들에 대한 글은 많지 않다. 앞에서 스택오버플로우에 질문을 올렸을 때도 2일 지났을때 읽은 사람이 5명밖에 없었다. 문제가 생겼을때 유저 커뮤니티(꼭 그룹스나 IRC만을 얘기하는 건 아니다)에 도움을 받지 못하는 것 상당히 문제다. 결국은 Thymeleaf 사이트가서 가이드 문서를 찾아가면서 직접 연구해 보는것 외에는 아직 큰 답이 없어 보인다.</li>
</ul>
<h1>장점</h1>
<p>가장 큰 장점이라고 생각했던(다른 템플릿 엔진에서도 그리 불편하진 않았기 때문에) 네츄럴 템플릿이 기대 이하였기 때문에 딱히 Thymeleaf만의 장점이라고 하면 잘 생각나진 않지만 그래도 가장 큰 장점은 Spring MVC와 통합이 잘 되다는 장점이 있고 스프링소스에서 꽤 밀고 있는 부분에 기대를 걸어볼 수 있지만 스프링소스가 밀었지만 잘 통하지 않았던 것들도 꽤 있으므로 이는 시간을 두고 볼 일이다.</p>
<h1>결론</h1>
<p>특별한 장점을 느끼지 못한 이상 기존해 사용하던 템플릿 엔진을 대안으로 쓸 것 같다. 이 글은 Thymeleaf에 대한 초기 인상을 기록하기 위한 것이므로 아직 대안을 테스트해보거나 심도있게 고민해 보진 않았다. 장점을 안적다시피해서 너무 안좋게 얘기한것같기는 하지만 뭐 인상이 그런것이고 다른 템플릿엔진에서도 되는 것은 딱히 장점이라고 생각하지 않기 때문이다. 어쨌든 언어를 떠나서 가장 괜찮은 템플릿 엔진은 (HTML 작업에 대한 협업이 큰 고려사항이 아니라면) <a href="http://jade-lang.com/">Jade</a>인듯.. ㅎㅎㅎ</p>
<div class=footnotes><div class=footnotes_in><ol class=footnotes><li id="footnote_969_1">benelog님의 제보에 따라 <code><script th:remove="all" type="text/javascript" src="../../js/thymol.js"></script></code>와 같이 작성하면 Thymeleaf에서는 자동으로 빠지므로 넣었다 뺐다 할 필요없습니다. <a href="#footnote_link_969_1">[Back]</a> </li>
<li id="footnote_969_2">마찬가지로 benelog님이 알려주셨는데 이러한 부분도 <code><tr th:remove="all"></code>와 같이 추가해 놓으면 넣었다 뺐다 할 필요는 없습니다. <a href="#footnote_link_969_2">[Back]</a> </li>
</ol></div></div><p><strong><a href="https://blog.outsider.ne.kr/969?commentInput=true#entry969WriteComment">댓글 쓰기</a></strong></p>[Book] 자바 개발자를 위한 함수형 프로그래밍Outsiderhttps://blog.outsider.ne.kr/8622012-11-19T02:24:18+09:002012-11-19T02:24:18+09:00<div class="ttbReview">
<fieldset style="PADDING-RIGHT: 5px; PADDING-LEFT: 5px; PADDING-BOTTOM: 5px; MARGIN: 10px; WIDTH: 90%; PADDING-TOP: 5px"><legend><a class="aladdin_title" href="http://www.hanb.co.kr/ebook/look.html?isbn=9788979149678">자바 개발자를 위한 함수형 프로그래밍</a></legend>
<p>
</p><table>
<tbody>
<tr>
<td><a href="http://www.hanb.co.kr/ebook/look.html?isbn=9788979149678"><img alt="" src="http://blog.outsider.ne.kr/attach/1/1089607240.jpg" border="0"></a></td>
<td style="VERTICAL-ALIGN: top" align="left"><a class="aladdin_title" href="http://www.hanb.co.kr/ebook/look.html?isbn=9788979149678">자바 개발자를 위한 함수형 프로그래밍</a> - <img alt="6점" src="http://image.aladdin.co.kr/img/common/star_s6.gif" border="0"><br>딘 왐플러 지음<br>임백준 옮김<br>한빛미디어</td></tr></tbody></table></fieldset><br>이 책은 <a href="http://www.hanb.co.kr/ebook/about_ebook.html" target="_blank">한빛미디어에서 리얼타임이라는 이름으로 기술서적을 이북으로만 출판하는 서비스</a>로 나온 책으로 <a href="http://shop.oreilly.com/product/0636920021667.do" target="_blank">Functional Programming for Java Developers</a>의 번역서이다. 개인적으로는 페이퍼북으로 나오는 책에 비해 상당히 빠른 속도로 번역서가 나오고 있고 이북으로 기술서적을 보기 어려운 국내환경에서 볼만한 서적들이 이북으로 나오고 있기 때문에 최근에 맘에 들어하고 있다.<br><br>제목 그래로 자바의 관점(?)에서 함수형 프로그래밍을 설명해 주는 책이다. 이 책의 저지인 딘 왐플러는 오렐리의 <a href="http://shop.oreilly.com/product/9780596155964.do" target="_blank">Programming Scala</a>의 저자이기도 한데 그래서 인지 몰라도 이 책을 다보고난 느낌은 스칼라의 내부 구현에 대한 접근방법에 대한 설명을 하는 듯한 느낌이었다. 스칼라의 내부 구현을 다 보여준다는 의미가 아니라 스칼라가 함수형 프로그래밍에 접근하고 있는 방법에 대해서 자바코드로 간략하게 보여주는 듯한 느낌이 있다. 자바 개발자들에게도 도움이 되겠지만 스칼라를 공부할 예정이라면 기반지식정도로 한번 보면 도움이 되리라 생각한다.<br><br><blockquote>함수형 프로그래밍 언어는 객체지향 프로그래밍 언어를 대체하는 존재가 아니라, 객체지향 프로그래밍 언어의 외연을 확장하고 내연을 풍부하게 만들어 주는 도우미다.</blockquote>함수형 프로그래밍은 개발자로써 배워둘 가치가 충분히 있다고 생각하는데 이는 기존의 임퍼러티브(Imperative) 프로그래밍에 비해서 함수형 프로그래밍은 접근방법이 완전히 다르기 때문에 코딩을 하는 좀더 넓은 시야를 준다고 보기 때문이다. 물론 이 100페이지정도의 책으로 함수형 프로그래밍의 개념을 다 이해하는 건 무리겠지만 기본적인 내용 정도는 이해할 수 있다고 생각한다. 개인적으로 번역은 약간 거친 느낌이 나지만 내용을 이해하는데는 무리가 없어 보인다.(Gang of four를 유명한 네명의 사람들이라고 한건 그냥 gang of four로 해도 괜찮지 않았나 싶기도... 중요한 건 아니지만...)<br><br>초반에는 함수형 프로그래밍에 대한 광고를 좀 하고 함수형 프로그래밍이 가진 특징들을 설명해 준다. 이어서 함수형 프로그래밍이 데이터 구조에 대해서 접근하는 방법을 설명하기 위해서 리스트와 맵에 대해서 설명하고 액터모델도 살짝 나온다. 데이터 구조에 대해서는 map, filter, fold를 자바코드로 구현하는 방법을 설명하고 이 세 함수를 조합해서 사용하는 방법을 보여주는데 이 책에서는 가장 알찬 부분이 아닌가 생각한다. 앞에서 말했듯이 100페이지밖에 안되므로 부담없이 읽을 수 있다.<br></div><p><strong><a href="https://blog.outsider.ne.kr/862?commentInput=true#entry862WriteComment">댓글 쓰기</a></strong></p>제9회 개발자를 위한 ‘共感(공감)’ 세미나 후기Outsiderhttps://blog.outsider.ne.kr/8522012-10-23T14:36:09+09:002012-10-23T04:08:36+09:00지난 20일(토)에 강남 교보타워 23층 대회의실에서 열린 <a href="http://onoffmix.com/event/9706" target="_blank">공감세미나</a>에 갔다왔다. 공감세미나는 OKJSP, JBoss 유저그룹, KSUG가 공동주최하는 세미나로 최초에는 어도비의 주관으로 이루어졌지만 그뒤부터는 세개 커뮤니티 연합으로 정기적으로 열리고 있다. 이런 저런 사정으로 공감세미나에 참석하는 건 꽤 오랜만인듯 하다.<br><br><div class="imageblock center" style="text-align: center; clear: both;"><img src="//blog.outsider.ne.kr/attach/1/1055836100.jpg" alt="공감세미나 " height="281" width="550" /></div>일정표를 봤을 때 이번 공감세미나는 여러가지 기술 트랜드 보다는 자바 자체에 초점을 맞춘 분위기였다.<br><br><br><b><font size="5">자바 탄생 이야기</font></b> <b><font size="3">- 김영수</font></b><br>이 세션은 제목대로 자바가 만들어진 과정에 대한 이야기로 자바 10주년을 기념해서 2005년에 나온 <a href="http://www.amazon.com/Hello-World-From-Code-Culture/dp/0131888676" target="_blank">Hello World(s) -- From Code to Culture: A 10 Year Celebration of Java Technology</a>라는 책의 내용을 정리해서 발표한 세션이었다. 1991년 제임스 고슬링은 변화의 시기에 맞추어서 무언가 해보기 위해서 Green 팀을 구성해서(사무실의 문이 녹색이었다고 한다.) 네트워크 기반의 무언가를 만들려고 했다. 그리고 사무실 밖에 있는 오크나무의 이름을 따서 OAK라는 프로토타이핑 프로젝트를 시작해서 여러 다바이스를 핸들링하려고 했는데 <font color="#CC9900">고슬링의 아이디어를 위한 언어가 없어서 만들기로 한다.(NO LANGUAGE FOR HIS IDEA THEN MAKE IT.)</font><br><br><div class="imageblock center" style="text-align: center; clear: both;"><a href="http://www.flickr.com/photos/rockdoli/8113545472/" target="_blank"><img src="http://farm9.staticflickr.com/8195/8113545472_1f36cd7ecb.jpg" border="0"></a></div><br>1992년 팀의 멤버는 13명이 되고 회사의 디자이너인 Joe Palrang이 만든 캐릭터를 가져와서 Duke를 자바의 캐릭터로 만들었다. 이런 것으로 보아 단순이 코드만 짠 것이 아니라 캐릭터까지 도입해서 과감하게 진행을 했다. 고슬링이 만든 언어를 보고 C++의 빌 조이가 "C++과 비슷한 언어 아니냐"고 하자 고슬링은 "C++를 많이는 사용하지만 좋아하는 사람은 별로 없다(almost nobody liked it)라고 대답했다고 한다. OAK의 릴리즈 준비를 하는 과정에서 OAK가 이미 등록된 이름이라 여러 후보를 검토하다가 Java라는 이름으로 결정을 하고 1995년 5월 23일 SunWorld Conference에서 공개를 하고 썬의 적극적인 지원아래 이후 여러 컨퍼런스 등을 통해 홍보를 시작하고 그 뒤 부터는 커니터들이 참여하면서 퍼지기 시작한다.<br><br><div style="padding:10px; background-color:#FAFFA9"><font color="#000000">약간은 지루한 세션이었다고 생각한다. 저 책을 보지 않아서 정확한 내용은 모르고 탄생과정이 스펙타클하지 않았는지는 모르지만 그래도 흥미로운 요소들이 많았으리라고 생각하는데 세션은 좀 지루했다. 자바의 탄생 과정을 탄탄하게 엮어서 설명했다기 보다는 책의 내용은 단편적으로 짚으면서 진행하다보니 듣는 입장에서는 진행과정이 잘 안이어지고 좀 지루하게 느껴지지 않았나 싶다. 그래도 탄생과정에 대해서는 잘 몰랐던 사실들을 알게 되어서 좀 나았다.</font></div><br><br><br><b><font size="5">Java: The Good Parts</font><font size="3"> - 박성철</font></b><br>이번 세션은 더그의 <a href="http://shop.oreilly.com/product/9780596517748.do" target="_blank">JavaScript: The Good Parts</a>의 제목을 본따서 지은 제목이었고 자바의 특징을 하나씩 살펴보면서 이야기 해보자고 하셨다. 세션은 semtlnori님이 블로그에 <a href="http://npcode.com/blog/archives/124" target="_blank">프로그래밍 언어들을 한문장으로 소개한 글</a>을 시작했는데 여기서는 각 언어의 정의를 정리해놨지만 마지막에 자바는 한문장으로 정리된 글을 찾을 수 없었다고 나와있다. 여기에 대한 답변을 하기 전에 자바의 특징을 살펴보았는데 <a href="http://www.oracle.com/technetwork/java/index-136113.html" target="_blank">자바 백서</a>를 보면 앞에는 언어에 대한 이야기이고 뒤에는 JVM에 대한 이야기인데 설계당시 둘을 따로 구분하지는 않았겠지만 지금은 구분하므로 둘을 나눠서 설명하셨다.<br><br>언어로서의 자바를 먼저 살펴보면 <font color="#CC9900">자바는 단순함과 친숙함을 목표로 C/C++에서 WTF적인 요소를 뺀 것이라고 할 수 있다. 자바는 경고하고 안전하다고 할 수 있는데 여기서 견고성이란 정적(static) 타입의 언어에서 오는 장점이고 안정성은 엄격한(strong) 타입에서 오는 장점이다.</font> (정적타입과 엄격한 타입은 약간 다르지만 보통은 같이 얘기한다.) 정적 타이핑에 대한 반대의견들이 있는데 보통 정적타이핑은 버그를 탐지하기에는 불충분하기 때문에 단위테스트를 작성해야 하고 단위테스트를 작성하고 나면 정적 타입확인 과징이라는 것이다. 거기에 정작 타이핑은 유효한 프로그램을 오류로 분류하기도 하므로 오히려 해롭다고 할 수 있다. 이에 대해서 해외에서 논문으로 연구한 내용이 있는데 파인썬 오픈소스 라이브러리 중 코드양은 적으면서 테스트가 잘 작성된 것 프로젝트들을 골라서 하스켈로 변환한뒤 컴파일하자 오류가 발생했다는 연구 결과가 있다.<font color="#CC9900"> 정적 타입의 또다른 장점은 도구지원이다.</font> IDE를 통해서 자동완성/자동제안을 지원하면 쉽게 리팩토링할 수 있으며 보일러 플레이트 코드를 자동 생성하거나 정적 코드분석을 할 수 있다. <br><br><font color="#CC9900">자바의 또 하나의 특징은 객체중심의 프로그래밍이라는 것이다</font>. OOP는 시뮬라67에서부터 시작되었는데 코드를 레고블럭처럼 생각하고 구조에 신경쓰기 위해서 만든 것이고 실제로는 스몰토크부터 시작되었다고 할 수 있는데 스몰토크는 객체지향을 메시징으로 보고 각 부분을 생물의 세포로 보고 있다. <font color="#CC9900">알란 케이는 OOP에 대해서 정의해 달라는 말에서 메시징이 핵심이라고 했는데 자바에서는 그게 인터페이스이므로 인터페이스를 안쓰면 시뮤라67 스타일이 된다고 할 수 있다.</font> 패키지는 디렉토리, 이름영역, 모듈이라고 할 수 있는데 응집의 단위이다. 자바의 기본 가시성은 package-private나 package-protected라고 보통 부르는데 이름이 없어서 잊혀진 존재이다. package-private는 public < protected < package-private < private정도의 가시성을 갖는데 계층관계에서는 보이지 않지만 패키지 사이에서는 보이는 가시성이다. <font color="#CC9900">자바가 기본 가시성으로 package-private를 선택한 것을 보면 패키지를 단순한 그룹으로 보지 않았다는 것을 알 수 있다. </font><br><br><div class="imageblock center" style="text-align: center; clear: both;"><a href="http://www.flickr.com/photos/rockdoli/8113539161/" target="_blank"><img src="http://farm9.staticflickr.com/8466/8113539161_0c13007613.jpg" border="0"></a></div><br>그 외에는 자바 1.1에서 추가된 내부클래스(inner class)가 있는데 <strike>LISP에서 온 개념으로 </strike>(잘못된 내용입니다.) 클래스=파일이라는 원칙으로 스스로 위배하면서 도입한 기능이다. 그리고 열거형(Enum)은 C++에서 일부러 가져오지 않았던 특징인데 자바의 열거형은 클래스이면서 타입세이프 하기 때문에 자기 부정을 한 것은 아니고 설계패턴 중 상태 패턴(state pattern)을 적용할 수 있다. 지네릭(generics) 는 C++에서 유보해떤 특징으로 알고리즘이 처리할 타입을 사용시에 지정하는 것으로 코드재사용 기술이라고 할 수 있다.<br><br>두번째는 JVM에 대한 이야기인데 자바는 파이썬하고 똑같이 컴파일한 뒤 VM위에서 동작하는 인터프리터 언어라고 하셨다. 자바는 클래스로더로 동적로딩, 동적 바인딩을 위해서 인터프리터를 선택했고 LISP에서 가비지 컬렉터의 개념을 가져와서 도입했다. 그리고 코드의 메타데이터를 다루는 기술인 리플렉션을 통해서 다른 프로그램을 생성하거나 조작하는 프로그램을 작성하는 메타프로그래밍을 할 수 있다. 메타프로그래밍으로는 선행처리, 컴파일러 확장(Lombok 처럼), 스프링의 Di + AOP등이 있다. 그리고 JVM은 다언어 프로그래밍(Polyglot)인데 이제 JVM은 자바만의 VM이 아닌 상황이 되었고 바이트코드라면 원천을 따지지 않고 실행한다.<br><br><div style="padding:10px; background-color:#FAFFA9"><font color="#000000">자바에 대한 기초가 많이 없는 나로써는 자바에 특징에 대한 여러가지 관점을 들을 수 있어서 어느정도 흥미로왔지만 자바의 기초에 대해서 깊게 들어간 것은 아니었기 때문에 어떤 면에서는 너무 기초적이거나 추상적일 수도 있었다고 생각한다. 흥미롭다면 흥미롭지만 사람들의 반응을 보면 또 너무 뻔하다면 뻔한 얘기일 수도 있었겠다는 생각이 든다. 또 한편으로는 추상적/개념적인 얘기가 아니라 더그의 JavaScript: The Good Parts처럼 실제 코드를 이용한 좋은 점을 설명했으면 깊이도 있고 좋지 않았을까 싶기도 한다.<br></font></div><br><br><b><font size="5">챔피언이 사랑한 언어, Java</font></b> <b><font size="3">- 양수열</font></b><br>1996년에 처음 자바를 접했는데 당시에는 Java라고 쓰고 Innovation이라고 읽었다. 정적인 웹페이지만 보다가 웹에서 듀크가 춤추는 것을 처음 보았을 때는 깜짝 놀랐고 그 당시에는 새롭고 혁신적인 언어였다. 그 당시 자바는 새롬게 성장하는 기술로 웹과 함께한 언어였기 때문에 혁신을 좋아하는 젊은 엔지니어들이 많이 관심을 가졌고 좋은 취지에 공감해서 자바 개발자 커뮤니티를 만들기도 했다. 당시의 키워드로는 Distibuted Object, OOP, Garbage collector, Enterpirse, SOA, CBD등이었다. <br><br><div class="imageblock center" style="text-align: center; clear: both;"><a href="http://www.flickr.com/photos/rockdoli/8113550950/" target="_blank"><img src="http://farm9.staticflickr.com/8186/8113550950_b17a98d8c5.jpg" border="0"></a></div><br>하지만 이제는 2012년이고 이제는 Java라고 쓰고 Platform이라고 읽는다. 오늘날의 자바는 성숙한 기술이면서 언어에서 플램폼으로 바뀌었고 구식이면서 오래된 엔지니어들이 있는 기술이게 되었다. 그럼 우리는 어디로 가야하는가? 아마 WAS는 영원할 것이다. 과거 메인프레임의 시대가 끝난뒤에도 메인프레임을 유지하는 곳이 많았기 때문에 IBM은 노령의 엔지니어를 메인프레임 유지보수를 큰 비용을 주고 고용하고 있는데 WAS도 비슷하게 계속 유지될 것이다. 자바 플랫폼위에 새로운 언어를 사용할 수도 있고 요즘은 데이터 분석기술이 많이 중요해 지고 있다고 생각하기 때문에 이쪽으로 스킬업을 해도 도움이 될 것이라고 본다. 이제는 완전히 새로운 새상이 왔고 개발자가 창조가가 되었으면 글로벌 시장이 열렸고 혼자서도 회사를 할 수 있는 세상이 되었다. 개발자들이 이 과도기를 잘 헤쳐나가서 좋은 세상을 만들기를 기대한다.<br><br><div style="padding:10px; background-color:#FAFFA9"><font color="#000000">그냥 무난한 세션이었다. 한편으로는 과거에는 자바가 혁신이었다는 말에 어쩌면 당연한 말이었지만 새삼 깨닫게 되었다. 양수열님이 오랫동안 자바를 사용하면서 생각했던 내용들을 그냥 에세이처럼 들려준 세션으로 그냥 웃으면서 가볍게 이야기 듣듯이 들은 세션이었다. 그런 목적도 아니었겠지만 특별히 큰 인사이트를 주거나 하는 세션은 아니었다.</font></div><br><br><br><b><font size="5">자바 기반 시스템의 개발 및 운영에 도움이 되는 툴들</font><font size="3"> - 이상민</font></b><br>제목 그대로 여러가지 도구에 대해서 설명한 세션이었다. 우리나라에서는 이클립스만 거의 쓰지만 해외 컨퍼런스를 가면 넷빈즈를 상당히 많이 쓰고 있고 사용 IDE인 IntelliJ도 상당히 좋다. 보통은 JDK나 JRE만 설치해서 쓰지만 JDK에는 상당히 좋은 도구들이 많이 들어있다.<br><br><ul><li><font color="#CC9900">jps</font> : jps는 java process 목록을 제공하는 도구로 보통은 이름만 나오기 때문에 톰캣을 여러개 띄운 경우 구분할 수 없는데 이때는 <font color="#FF7635">jps -v</font>를 사용하면 실행옵션을 함께 볼 수 있다. <font color="#FF7635">ps -ef | grep java</font>를 하는 것보다는 jps가 훨씬 간단하고 jstat과 다른 점은 자신의 계정으로 실행한 것만 보인다는 것이다.</li><li><font color="#CC9900">jstat </font>: jvm의 상황을 모니터링하는 도구로 운영서버에 절대 영향을 안주기 때문에 리얼서버에서 사용해도 문제가 없다. 유용한 옵션으로는 gc상태를 모니터링하는 <font color="#FF7635">-gcutil</font>과 jvm의 메모리 점유 상황을 모니터링하는 <font color="#FF7635">-gccapacity</font>가 있다.</li><li><font color="#CC9900">javap </font>: 자바 클래스 파일을 분석해 준다. <font color="#FF7635">javap className</font>을 실행하면 해당 클래스에 선언된 변수와 메서드 정보등을 출력해 주고 <font color="#FF7635">javap -c className</font>을 실행하면 해당 클래스의 opcode(JVM을 위한 중간코드)를 출력해준다.</li><li><font color="#CC9900">jstack </font>: 쓰레드 덤프(thread dump)를 발생시켜서 덤프 발생시점에 어떤 쓰레드가 어떤 작업을 수행하는 지 제공하는 덤프파일을 생성한다. 하지만 jstack는 경우에 따라 프로그램에 Hang이 발생할 수 있으므로 사용하지 않는 것이 좋고 쓰레드 덤프는 <font color="#FF7635">kill -3 pid</font>를 사용할 것을 권장한다.(-3 옵션을 빼먹거나 -9를 사용하지 않도록 주의해야 한다.)</li><li><font color="#CC9900">jmap </font>: 힙덤프(heap dump)를 발생시켜서 덤프발생시점에 어떤 객체가 어떤 값을 갖고 있는지를 저장한다. 운영시에 jmap을 실행하면 자바 프로세스가 멈추므로 꼭 필요한 경우(메모리 릭 같은)에만 사용해야하고 <font color="#FF7635">jmap -dump:format=b, file=filename pid</font>같은 옵션을 사용한다.</li><li><font color="#CC9900">jhat </font>: 힙덤프를 분석해준다.</li><li><font color="#CC9900">jconsole, jvisualvm </font>: 뒤에서 얘기할 비쥬얼 vm이 낫다.</li></ul><br>테스트 도구에는 여러가지가 있는데 유닛테스트에는 JUnit이 대표적이고 UI 테스트에는 Selenium이나 NHN의 Guitar가 있다. 인수 테스트도구로는 <a href="http://fitnesse.org/" target="_blank">Fitness</a>와 NTAF가 있고 성능테스트 도구에는 Load Runner만 있는게 아니고 상용툴로는 Microfocus사의 qa load나 무료툴인 <a href="http://grinder.sourceforge.net/" target="_blank">grinder</a>, <a href="http://jmeter.apache.org/" target="_blank">jmeter</a>등이 있다. 로드러너 아니면 안되는줄 아는 사람이 많은데 참고로 로드러너는 엄청 비싸다. <br><br><div class="imageblock center" style="text-align: center; clear: both;"><a href="http://www.flickr.com/photos/rockdoli/8113553198/" target="_blank"><img src="http://farm9.staticflickr.com/8044/8113553198_5c2c69f8da.jpg" border="0"></a></div><br>프로파일링 도구는 프로그램의 성능, 메모리 사용량, 코드 커퍼리지 등을 확인할 수 있는 도구인데 성능저하를 많이 발생시키기 때문에 운영서버에서는 사용하면 안되고 개발자PC나 개발서버에서만 사용해야 한다. 크게 상용툴과 무료툴로 나뉘지만 상용툴을 쓰기를 권장하고 자바 프로그래머라면 IDE처럼 항상 옆에 끼고 있어야 하는 도구이고 대부분의 상용도구들은 IDE와 연계할 수 있고 라인단위로 걸린시간과 메모리까지 파악할 수 있다. 프로파일링 도구로는 microfocus사의 devpartner for java, quest사의 jprobe, ej-technologies의 jprofiler, yourkit 등이 있다.<br><br>모니터링 도구로는 국산제품이 많은 APM에는 Jennifer, webtune, pharos가 있다. 그 외에 JMX(Java Management Extension)를 사용할 때는 무료툴로도 충분한데 visual vm과 jconsole이 있다. visual vm은 JRE에 포함된 jvisualvm과 별도로 설치하는 visual vm으로 나뉘는데 버전업이 가능하고 사용이 편한 visual vm이 더 낫다. <br><br>트러블슈팅 도구를 보면 쓰레드덤프 분석도구에는 대표적으로 <a href="http://java.net/projects/tda/" target="_blank">TDA</a>가 있는데 어플리케이션의 성능이나 기능상에 문제가 있을 경우에 사용하면 된다. 힙덤프 분석도구에는 IBM Heap analyzer나 MAT이 있고 Tracing 도구에는 Btrace나 byteman이 있다. CI도구는 지속/반복적으로 빌드를 수행해주는 도구로 Hudson과 Jenkins가 있는데 Hudson의 핵심개발자가 나와서 만든게 Jenkins이므로 그냥 Jenkins를 사용하면 된다. 그외에 크루즈 컨트롤이 있다. 프론트앤드 도구에는 웹페이지를 최적화해주는 도구인 야후의 yslow가 있지만 요즘은 브라우저에 빌드인된 도구도 충분히 좋다. <a href="http://www.tuning-java.com/484" target="_blank">발표자료는 이상민님이 블로그에 올려주셨다.</a><br><br><div style="padding:10px; background-color:#FAFFA9"><font color="#000000">이번 공감세미나에서 거의 유일하게 기술세션이라고 할 수 있다. 뭐 워낙 발표도 잘하시고 농담도 잘 하시니 즐겁게 들었다. 상당수의 도구는 알고 있는 도구이기는 했지만 한방에 분야별로 정리를 해주었기 때문에 도구를 선택할 때 꽤 도움이 될듯하다. 특히 도구들에 대해서 잘 몰랐다면 이상민님이 좋은 도구를 다 골라주었기 때문에 아주 유용했을 것 같다. 나로써는 다른 부분보다는 JDK에 포함된 도구들을 설명해 준것이 크게 도움이 되었다. 여기 꽤 많은게 있다는 것을 알고 있지만 익숙하지 않아서 자주 쓰진 않는데 여러가지 상황별로 JDK도구들을 사용해야 할때 도움이 될 것 같다.</font></div><br><br><br><b><font size="5">자바 개발 안티 스타일 - 스프링을 이<font size="5">용</font>한 레거시 코드 중심으로</font><font size="3"> - 윤여진</font></b><br><div style="padding:10px; background-color:#FAFFA9"><font color="#000000">이 세션은 요약하지 않는다. 머 이리저리 깊게 얘기하고 싶지도 않다. 특정인을 머라하는 것 같아 신경쓰이긴 하지만 머 그냥 느낀대로 딱 까놓고 얘기하면 발표 참 쉽게 하신다 싶은 생각이 들었다. 제목과는 전혀 다르게 "토비의 스프링 3"책에 나온 초난감 DAO를 리팩토링하는 과정을 그래도 PT로 만들어서 설명해 준 세션이라서 솔직히 난 그냥 딴짓을 했다. 그냥 "토비의 스프링 3"책을 그룹스터디 한다면 초난감 DAO 장을 정리해서 보여준 발표정도였다.</font></div><br><br><b><font size="5">Epilogue</font></b><br>최근에 메일링등에서 너무 최신기술만 다루지 말고 자바 자체에 대해서도 관심을 가지자라는 말을 들었었는데 그때는 꽤 공감했었지만 막상 자바를 주제로 한 세미나를 듣자 만족감이 그리 높지는 못했다. 뭐랄까 세미나의 의도가 정확히 어땠는지는 알 수 없지만 자바에 집중하다보니 세미나가 전체적으로 추상적인 내용이나 개념적인 내용이 상당후가 되어버린것 같다. 개인적으로는 기본적인 내용(쉽다라는 의미는 아니다.)을 중심으로 기술세션들을 기대했는데 대부분이 추상적인 얘기를 하는 세션들이 되다보니 듣는 입장에서는 만족도가 좀 떨어진게 아닌가 쉽다. 그렇다고 뭐 괜히 갔네.. 이런건 아니다. ㅎ<br><p><strong><a href="https://blog.outsider.ne.kr/852?commentInput=true#entry852WriteComment">댓글 쓰기</a></strong></p>jmap으로 자바의 메모리맵 확인하기Outsiderhttps://blog.outsider.ne.kr/7932012-06-06T23:50:00+09:002012-06-06T23:50:00+09:00jmap은 자바 어플리케이션의 메모리 맵을 확인할 수 있는 도구입니다. JDK 설치시에 포함되어 있는 걸로 알고 있었는데 <a href="http://docs.oracle.com/javase/6/docs/technotes/tools/share/jmap.html" target="_blank">jmap 문서</a>를 보면 차후의 JDK에서는 포함되지 않을 수 있고 윈도우에서는 별도의 설치과정을 거쳐야 한다고 나와 있습니다.(요즘 개발할때는 윈도우를 거의 안써서 잘 모르겠군요.) 저는 최근에 톰캣어플리케이션에서 jmap으로 메모리 사용량을 확인하는 용도로 사용했습니다.(Heap dump도 뜰 수 있는 것으로 알고 있습니다.)<br><br>먼저 확인할 자바어플리케이션의 프로세스 ID를 알아야 하므로 <a href="http://docs.oracle.com/javase/6/docs/technotes/tools/share/jps.html" target="_blank">jps</a>나 ps 명령어를 사용해서 프로세스 ID를 알아냅니다.<br><br><div style="margin-left: 40px;"><span style="color: rgb(255, 118, 53);">jmap -heap 프로세스ID</span><br></div><br>위 처럼 입력하면 해당 프로세스의 메모리맵을 통해서 Heap 메모리의 각 영역별 항당관 메모리 크기와 사용량 등을 다음과 같이 확인할 수 있습니다.<br><br><div class="imageblock center" style="text-align: center; clear: both;"><img src="//blog.outsider.ne.kr/attach/1/1360465950.gif" alt="사용자 삽입 이미지" height="913" width="400" /></div><br><p><strong><a href="https://blog.outsider.ne.kr/793?commentInput=true#entry793WriteComment">댓글 쓰기</a></strong></p>제12회 한국자바개발자 컨퍼런스 후기Outsiderhttps://blog.outsider.ne.kr/7492012-02-28T02:13:09+09:002012-02-28T02:13:09+09:00지난 18일 코엑스 그랜드볼룸에서 The Future of Java Platform라는 제목으로 <a href="http://www.jco.or.kr/" target="_blank">JCO</a>에서 주관하는 <a href="http://jco.zdnet.co.kr/12th/" target="_blank">한국자바개발자 컨퍼런스 12회</a>가 열렸습니다. 국내에서 열리는 컨퍼런스 중에는 가장 큰 규모로 보통 2,000명 이상이 모이죠. <a href="http://blog.outsider.ne.kr/656" target="_blank">작년에는 발표</a>가 있어서 정신없이 참여했지만 올해는 여유롭게 참여를 했습니다. 행사는 10시부터 였지만 느즈막히 11시 반쯤 코엑스에 도착했습니다. 해외 컨퍼런스는 보통 시간이 없으면 기조연설만 맞춰서 보게 되는데 국내 컨퍼런스들은 보통 기조연설이 제일 들을게 없는지라 오전 세션은 제껴버렸습니다.(일찍 깨면 갈 생각이었지만 마침 늦잠도 자고 해서...) 개인적으로는 정부기관이나 스폰서에서 나와서 하는게 아닌 정말 알찬 기조연설이 다음부터는 진행되었으면 합니다.(뭐 이번 기조연설은 듣지도 않았기 때문에 이번에 좋았다/안좋았다고 얘기하는 것은 아닙니다.) (후기를 일주일이나 지난 이제야 올리는군요.. 지난주에 이래저래 좀 바빠서.. ㅎ)<br><br><br><br><br><font style="font-weight: bold;" size="5">지속적인 빌드와 개발</font><font style="font-weight: bold;" size="4"> - 박재성</font><br>이 발표는 자바지기님이 쓰신 <a href="http://www.aladin.co.kr/shop/wproduct.aspx?ISBN=8979148135" target="_blank">자바 세상의 빌드를 이끄는 메이븐</a>에 담긴 내용을 요약정리하는 내용이라고도 할 수 있고 얼마전에 올리신 <a href="http://slipp.net/wiki/pages/viewpage.action?pageId=950343" target="_blank">단순 반복 업무에 대한 투자</a>에 대한 고민들도 들어가 있습니다. 저희가 보통 하는 일은 비즈니스 로직을 작성하는 일과 단순반복업무로 나눌 수 있습니다. <span style="color: rgb(204, 153, 0);">단순반복업무에는 서버 셋팅, 빌드, 테스트, 배포등이 있습니다. 비즈니스 로직은 2가지로 나눌 수 있는데 사람밖에 할 수 없는 일이 있고 컴퓨터가 할 수 있는 일이 있습니다. 대개는 컴퓨터가할 수 있는 일은 사람도 할 수 있기 때문에 직접 처리하곤 합니다. 프로젝트 초반에는 비즈니스 로직작성과 단순반복업무를 섞어서 하지만 중반부터는 단순반복업무는 잘 안하고 비즈니스 로직에만 집중하게 됩니다. 프로젝트가 후반에 가면 다시 단순반복업무에 신경쓰기 시작 하지만 많은 것들이 픽스되어 있는 상태라 변경하기가 쉽지 않습니다. 그리고 프로젝트가 완료된 후에는 단순반복업무의 비중이 커지게 됩니다.</span><br><br>이후에는 위키북 프로젝트의 경험을 공유해 주셨습니다. 위키북에 대한 자세한 내용은 자바지기님의 메이븐 책을 참고하면 잘 나와있고 굳이 다른 점이라면 책은 메이븐에 초점이 맞춰져 있지만 발표에서는 전체적인 경험에 대한 이야기 였습니다. 프로젝트 처음에는 JIRA나 SVN/GIT, 데이터베이스등의 개발서버 환경을 셋팅합니다. 개발환경에서는 개발디비를 공유해서 사용하지만 개발 중에 스키마가 변경될 때 개발이 원활하지 않음을 느끼게 됩니다. 누군가 스키마를 변경하면 소스와 싱크가 맞춰질 때까진 나머지 사람은 대기할 수 밖에 없습니다. 그래서 각 개발자 PC에 디비를 설치하도록 했습니다. 이는 개발자들 사이에서 반발이 꽤 심했습니다. 개발을 하면서 배포를 하는데 배포에는 아주 많은 단계가 있습니다. 이를 개발자가 직접하면 빠뜨리는 단계가 생길 수 있기 때문에 쉘 스크립트로 자동화를 합니다. 개발자가 로컬디비로 개발을 하면서 로컬디비와 개발디비의 스키마 차이로 오류가 생기는 경우가 발생해서 동기화를 할 필요가 생겼습니다. 만약 프로젝트가 ORM을 사용한다면 스키마 변경되었을 때 간단하게 자동 업데이트를 할 수 있지만 ORM을 사용하지 않는다면 <a href="http://code.google.com/p/c5-db-migration/" target="_blank">Carbon FIve</a>가 대안이 될 수 있습니다. Carbon Five는 변경되는 스키마 쿼리를 sql 파일로 관리하고 디비의 schema_version 테이블에서 적용된 파일의 버전을 관리하다가 새로운 버전의 sql파일을 다시 실행합니다. 이는 개발 단계에서 피곤함을 줄 수 도 있지만 실서버 운영에 들어갔을 경우에는 실디비와 스키마 동기화를 해야하기 때문에 미리 연습할 수 있다는 장점이 있습니다.<br><br>테스트를 추가해서 빌드시에 테스트를 수행하도록 하였지만 시간이 지날수록 개발자들이 유닛테스트를 @Ignore 처리하는 경우가 발생할 수 있는데 이는 조심해야 합니다. 배포는 Jenkins같은 도구로 자동배포를 합니다. UI 개발자는 데이터베이스는 필요없지만 VCS는 설치해야 합니다. 그리고 새로운 개발자가 투입되었을 경우 환결설정을 해주어야 하는데 이는 무척 지루한 일이고 개선하려는 노력도 잘 하지 않습니다. 이를 위해 설정 스크립트를 VCS로 관리하면 편하고 개발환경에 따라 빌드가 되도록 프로파일 기능을 사용하면 좋습니다. 이후 서비스에 부하가 커지면 WAS를 여러대 사용하게 되고 서버 설정을 반복해야 하는데 이는 <a href="https://github.com/capistrano/capistrano" target="_blank">Capistrano</a>를 이용하면 여러 대에 쉽게 배포할 수 있습니다.<br><br><span style="color: rgb(255, 118, 53);">이러한 과정은 한번에 도입해서 해결한다기 보다는 개발중에 지속적으로 발전시키는 것이 좋습니다. 이를 위해서는 개발자사이에 신뢰관계가 형성되어 있어야 합니다.</span><br><br><div style="padding:10px; background-color:#E4E4E4"><span style="color: rgb(0, 0, 0);">메이븐 책을 본 입장으로서는 상당부분은 반복되는 내용이기도 했습니다. 하지만 자바지기님의 발표는 대부분 많은 경험과 노력이 묻어나오는 발표라서 들을때 집중이 되고 도움이 됩니다. 이 발표는 개발경력이 많거나 회사에 프로세스가 잘 갖춰져 있는 개발자들에게는 큰 내용이 아닐수도 있지만 신입이나 아직 개발 프로세스가 정립되지 않은 조직에서는 도입을 고려하거나 생각해 볼 만한 여지를 많이 주는 발표라고 생각합니다.</span></div><br><br><br><br><br><font style="font-weight: bold;" size="5">Event Driven Architecture</font><font style="font-weight: bold;" size="4"> - 이미남</font><br>프로그램에는 Event Driven Architecture라고 나와있었지만 실제 발표의 제목은 The Strategic Platform for EDA (Event-Driven Architecture) Solutions였습니다. 처음에는 이벤트 드리븐 아키텍쳐에 대해서 설명했습니다. 이벤트를 사용함으로써 각 자원의 커플링을 줄일 수 있습니다. EDA에는 사이즈가 작고 이벤트간의 상관관계가 적은 Simple Event Processing부터 사이즈가 크고 상관관계도 높은 Complex Event Processing등의 모델이 있습니다. 과거의 데이터에 근거에서 패턴들을 Complex Event Processing에 넣으면 패턴을 적용해서 예측된 상황을 감지하는 형식입니다.<br><br><div style="padding: 10px; background-color: rgb(228, 228, 228); color: rgb(0, 0, 0);">사실 제가 기대한 세션이 아니었던데다가 무슨 말인지 잘 이해도 못하던 관계로 대충 요약을 마무리 합니다. 저는 Nginx나 Node.js에서 채택하고 있는 최근에 Event Driven의 구조에 대한 세션으로 생각하고 들었습니다만 CEP인지 CQL인지 오라클의 솔루션에 대한 홍보세션이었습니다.(이래서 기업세션을 별로 안좋아합니다만 시간표에는 그런 내용이 제대로 안나와있어서... ㅠㅠ) 이벤트 드리븐 아키텍쳐라기 보다는 어떤 데이터를 프로세싱 모델에 집어넣으면 결과를 예측할 수 있는 엔진같았는데 이벤트 얘기는 왜 끼어든건지 잘 모르겠습니다. 다른 세션으로 이동하려다가 귀찮기도 하고 이미 늦었을 것 같아서 후반부에는 개인적인 일을 했네요.</div><br><br><br><br><br><font style="font-weight: bold;" size="5">대용량 고가용성 분산 캐쉬서버(Infinispan)를 활용한 웹서비스</font><font style="font-weight: bold;" size="4"> - 이용혁</font><br>이 세션은 JBoss의 분산캐시서버인 <a href="http://www.jboss.org/infinispan" target="_blank">Infinispan</a>에 대한 발표였습니다. 발표전에 다음 3가지의 의미를 정의했습니다. <br><br><ul><li>캐시 : 고속을 위해서 사용한다.\</li><li>웹서비스 : HTTP만 있다면 원격지의 내용을 공개할 수 있다.</li><li>캐시+웹서비스 : 소프트웨어 컴포넌트를 고속으로 엑세스 할 수 있다.</li></ul><br><span style="color: rgb(204, 153, 0);">Infinispan의 홈페이지의 정의에 따르자면 100% 오픈소스이고 extremely scalable합니다. 이는 scale-out을 이야기 하는데 보통 100대 정도는 작은 규모로 생각할 정도의 규모입니다. 고가용성이 있고 자바로 만들어졌으며 무료입니다. 그리고 메모리에 올라가는 분산 데이터서버로 봐도 무방하답니다.</span> Infinispan은 JSR 107에 있는 JCache를 적용했고 Replicated Mode와 Distribution Mode 두가지 모드로 사용할 수 있습니다. Replicated Mode는 모든 서버에 복사본을 생성하고 Distribution Mode는 최소 몇개의 복사본을 갖을지를 지정해서 사용합니다. <br><br>이후에는 Infinispan을 적용하는 데모를 보여주었습니다. 데모는 카테고리별로 뉴스를 모아서 보여주는 간단한 웹사이트로 데모를 위해서 자동으로 텝이 이동되면서 로딩되게 만들어졌습니다. 처음에는 각 페이지를 디비에서 가져와서 보여주도록 만들었고 이후 서비스에 이용자가 많아진 것을 가져와서 캐시를 적용합니다. ConcurentHashMap을 이용해서 로컬캐시를 적용함으로써 디비부하를 줄일 수 있었습니다. 하지만 트래픽이 더 많아지면 자연히 클러스터링을 해야합니다. 클러스터링을 쓰면 세션을 사용할 수 없으므로 서버가 죽게되면 다른 서버로 몰리면서 같이 죽어버리는 경우가 많이 있습니다. 그리고 로컬캐시의 용량이 크기 때문에 메모리를 많이 차지하고 각 서버마다 메모리가 소비되므로 효율적이지 않습니다. <br><br>그래서 외부 캐시를 적용하기 위해 Infinispan을 사용합니다. 사용자정보도 세션대신에 Infinispan에 저장함으로써 클러스터링을 할 필요도 없고 Was가 죽더라도 세션은 살아있게 됩니다. 또한 Infinispan은 자바로 만들어졌기 때문에 자바로 사용하면서 List를 통째로 저장하거나 하는 등의 장점이 있습니다.(MemCached같은 경우는 Key-Value만 저장하는 등의 제약이 있답니다.) 이후 Infinispan을 이용해서 로컬캐시보다는 약간 느리지만 디비조회보다는 빠른 데모페이지를 보여주었습니다.(말씀하신 것처럼 발표중에는 Infinispan 서버가 회사에 있어서 네트워크시간이 더 걸리지만 보통은 같은 네트워크상에 있으므로 더 빠를 것입니다.) 그리고 데모마지막에는 브라우저를 닫았다 켜도 로그인이 살아있거나 중복로그인 차단에 대한 시연을 보여주었습니다. <span style="color: rgb(204, 153, 0);">특히 서버 설정에서 Infinisapn 서버를 새로 추가해서 각 서버가 자동으로 서로를 인식하는 과정은 꽤 매력적으로 보였습니다.</span><br><br>마지막으로 Infinispan에 포함되어 있는 데모를 시연했습니다. Infinispan을 다운로드 받으면 데모가 포함되어 있습니다. bin디렉토리에 runGuiDemo를 실행하면(쉘스크립트와 윈도우용 bat을 모두 제공합니다.) 간단한 <a href="https://docs.jboss.org/author/display/ISPN/Infinispan+GUI+demo" target="_blank">GUI 데모</a>를 볼 수 있습니다. 분산캐시서버이므로 여러개를 실행하면 여러개가 실행되고 각 윈도우가 하나의 Infinispan 서버가 됩니다. 한쪽에서 데이터를 추가하면 자동으로 다른 서버에도 복사가 되는 것을 볼수 있었는데 Infinispan을 이해하는데 좋았습니다.<br><br><div style="padding: 10px; background-color: rgb(228, 228, 228); color: rgb(0, 0, 0);">이용혁님과는 개인적으로 친분도 있어서 전에 Infinispan을 적용하고 있다는 것을 들어기 때문에 관심이 가서 들었습니다. 요즘같은 트래픽에서는 캐시서버의 중요성이 점점 커지고 있는데다가 전 캐시쪽은 잘 몰라서 최근에 괌심이 많이 갔었는데 한번 써보고 싶을 정도로 인상적이었습니다. 특히 이용혁님의 발표는 작년 MongoDB발표도 그렇고 실무에서 사용하면서의 경험을 바탕으로 하고 있기 때문에 내용이 실용적이고 도움이 많이 됩니다. 마지막 질문 시간에 왜 Infinispan을 선택했냐는 질문에 무료라서... 적용할 지 안할지도 모르는 캐시서버를 회사에서 사줄리가 없기 때문이라는 대답은 웃움이 나면서도 수긍이 가는 인상적인 대답이었습니다. ㅎ</div><br><br><br><br><br><font style="font-weight: bold;" size="5">개발자가 알아야할 오픈소스 라이선스 정책</font><font style="font-weight: bold;" size="4"> - 박수홍</font><br>저작권에는 저작인격권과 저작재산권이 있습니다. 저작인격권은 저작자의 명예와 이익을 지켜주기 위한 것이고 저작재산권은 저작권을 통해서 재산적인 이익을 보장해 주기 위함입니다. 처음에는 오픈소스 라이센스의 역사를 설명했습니다. 과거에는 SW는 HW를 판매하면서 번들로 포함되는 것이었지만 PC가 보급되기 시작하면서 SW의 부가가치가 상승하게 되고 별도로 SW를 판매하기 시작합니다. 그러면서 <span style="color: rgb(204, 153, 0);">미국에서 SW를 Copy Right로 보호하기 시작하자 이에 반발하여 그 유명한 리차드 스톨만이 GNU 프로젝트를 시작하고 Free Software Foundation을 설립하고 Copyleft 운동을 시작합니다. 이어서 FSF에서 GPL1.0과 GPL 2.0을 발표합니다. </span><br><br>이후 <span style="color: rgb(204, 153, 0);">1998년에 Eric Raymond와 Bruce Perens가 OSI(Open Source Initiative)를 설립하고 Open Source Movemont를 시작하게 됩니다. GPL에는 반환의무가 있는데 이는 소스코드를 변경하면 다시 사회에 내놓으라는 의무입니다. 하지만 반환의무 때문에 원작자의 명예가 흩어지는 현상이 나타났고 오픈소스 운동은 저작자와 개작자를 기록함으로써 그 명예를 유지하는 운동입니다. </span>공개소프트웨어 라이센스 계약의 특징은 제3자가 가져가서 허락된 어떤 활동을 시작하는 순간 라이센스가 적용되게 됩니다.<br><br><span style="color: rgb(204, 153, 0);">GPL은 소프트웨어의 확산을 위한 것이었지만 반드시 공개해야하는 강력한 조항때문에 오히려 잘 안쓰게 되는 역효과가 나타나게 됩니다. 그래서 너무 강력하지 않은 비 CopyLeft 라이센스들이 등장합니다.</span> 비 CopyLeft라이센스는 완전 자유이고 라이센스의 유지의무도 없습니다. 그외 Apache는 상표명만 표시하면 자유롭게 쓸 수 있고 MIT는 정말 맘대로 쓸 수 있습니다. 개발시에 가장 어려운 부분은 양립성의 문제입니다. 양립성의 문제라는 것은 2가지 소프트웨어를 사용할 때 두가지 라이센스를 모두 만족해야 한다는 것인데 이는 무척 어렵습니다.<br><br><div style="padding: 10px; background-color: rgb(228, 228, 228); color: rgb(0, 0, 0);">뒷부분은 회사에서 개발을 할 때 라이센스를 어떻게 검증해야 하는가에 대한 이야기였지만 제 관심사가 아니었으므로 따로 정리하지는 않았습니다. 라이센스는 법적인 부분이라서 꽤 어렵습니다. 과거에 이에 대한 내용을 많이 찾아보았지만 제대로 정리된 내용을 찾기어려웠습니다. 각 라이센스의 세부사항에 대해서는 못 들었지만 전체적인 라이센스의 구분이나 흐름에 대해서 파악할 수 있어서 좋았습니다.(MIT가 짱!!) 개인적으로 라이센스에 대해 궁금증이 생겼을 때 해결할 수 있는 어떤 곳이 없을까 했는데 그에 대한 내용은 듣지 못했습니다.</div><br><br><br><br><font style="font-weight: bold;" size="5">Epilogue</font><br>중간에 한 세션은 다른 볼일이 있어서 한시간 제꼈네요. 평소보다는 여유있게 참관한 느낌이고 작년에는 발표자로 참가해서인지 올해는 약간 다른 느낌이었습니다. 저는 뭐 그럭저럭 만족은 했지만(세션중 단 하나라도 건지는게 있으면 충분하다고 보기 때문에...) 다른 사람 얘기를 들어보면 전체적인 발표의 질을 높여야 할 필요가 있겠다는 생각도 들었습니다. 그리고 무엇보다 최근 컨퍼런스나 세미나에서 느끼는건데 쉬는시간이나 점심시간이 너무 짧다는 생각을 많이 합니다. 커뮤니티 세미나도 아닌 이정도 규모의 커뮤니티에서는 10분의 쉬는 시간은 나와서 다른 세션들으러 이동하기도 버겨운 시간입니다. 많이들 신경 안쓰는 기조연설 중 하나빼고 쉬는 시간을 좀 더 여유있게 주면 다른 개발자하고 커뮤니케이션할 수 있는 시간도 더 주어지지 않을까 합니다. 그리고 발표하는 입장에서 발표를 하기로 결정했을 때 이미 발표자료가 다 만들어 진것이 아니기 때문에 쉽지 않다고 하더라도 참관자 입장에서는 당일날 세션을 변경하는 것이 어려운 일은 아니므로 어느 세션을 들을 지 선택할 수 있는 정보가 좀더 많이 제공되었으면 합니다.<br><p><strong><a href="https://blog.outsider.ne.kr/749?commentInput=true#entry749WriteComment">댓글 쓰기</a></strong></p>