[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년 2월 17일 수요일

[AJAX]Google AJAX Libraires API를 이용해서 자바스크립트 프레임워크 사용하기..

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

이전에 파이어준님의 포스팅에서 보고는 담에는 써야지 하다가 이번에야 써봤다. 쉽게 말하면 자바스크립트 프레임워크를 구글이 제공해서 자신의 사이트에 올리지 않고 구글에서 끌어다가 쓸 수 있게 한다. 머 이건데... 회사에서는 쓸 일 있을지 모르겠고 블로그에서 예제파일 돌릴려고 몇개 올려두기는 했는데 버전도 계속 바뀌고 그래서 신경이 쓰였는데 이 서비스는 내가 써먹기는 딱인듯 하다. ㅋ 그래서 바로 전의 포스팅을 하면서 한번 써봤다. 잘된다.(당연하지. ㅡ..ㅡ)

파이어준님의 포스팅에도 나와있긴 하지만 다시 정리하자면
제공하는 라이브러리는 jQuery, prototype, script.aculo.us, mootools, dojo이다.(2008년 8월 1일 현재...) - 2개씩 적혀 있는 것은 위의것은 압축된(compressed) 버전이고 아래쪽은 압축되지 않은 버전이다.)

jQuery (1.2.3, 1.2.6 지원)

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js"></script> 
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.js"></script> 


prototype (1.6.0.2 지원)

<script src="http://ajax.googleapis.com/ajax/libs/prototype/1.6.0.2/prototype.js"></script> 


script.aculo.us (1.8.1 지원)

<script src="http://ajax.googleapis.com/ajax/libs/scriptaculous/1.8.1/scriptaculous.js "></script> 


mootools (1.11 지원)

<script src="http://ajax.googleapis.com/ajax/libs/mootools/1.11/mootools.js"></script> 
<script src="http://ajax.googleapis.com/ajax/libs/mootools/1.11/mootools.js"></script> 


dojo (1.1.1 지원)

<script src="http://ajax.googleapis.com/ajax/libs/dojo/1.1.1/dojo/dojo.xd.js "></script> 
<script src="http://ajax.googleapis.com/ajax/libs/dojo/1.1.1/dojo/dojo.xd.js.uncompressed.js"></script>


머 사용법이고 말고 할것도 없다. 그냥 script 인클루드의 링크를 구글로 건거다. ㅋㅋ 구글 API써서 하는 방법도 있지만 평소에도 이런식이 익숙하니까 이게 더 편한 것 같다. 이렇게 블로그에 올리거나 잠시 테스트할 때 프레임웍 불러내는게 은근 귀찮은데 이렇게 쓰니까 참 편하다.



그냥 구글이 갔다 쓸수만 있게 했겠는가? ㅋ Ajaxian의 포스트에 따르면 다음과 같은 장점이 있다고 한다.

  • 개발자가 아무짓도 안해도 캐싱이 잘 된다.
  • Gzip으로 동작한다.
  • 최소화된 버전으로 제공할 수 있다.
  • 세계곳곳의 CDN을 통해서 구글이 파일을 호스팅하기 때문에 사용자가 빨리 받을 수 있다.
  • 서버가 빠르다.
  • 같은 URL을 사용하기 때문에 구글의 인프라가 커지면 사용자가 당신의 어플리케이션에 처음왔을 때 이미 프레임워크가 로드되어 있을수도 있다.
  • 당신이 보내고 받는 헤더관련 미묘한 성능 및 보안 이슈가 해결된다. 당신이 특별한 도메인(구글말고)을 사용한 이래 쿠기가 없거나 다른 장황한 헤더가 보내질 것이므로 귀중한 바이트를 아낄수 있다.
개발하는 사이트에서 자신의 사이트에 라이브러리가 없는게 좀 신경쓰일 수도 있지만 많은 장점이 있는데도 굳이 안 쓸 이유도 없을것 같다. 나야 개인적으로만 쓰겠지만.. ㅎㅎㅎㅎ



위에처럼 직접 인클루드하는 방법 외에도 Google AJAX API Loader를 이용해서도 라이브러리 파일을 인클루드 할 수 있다.  구글과으 매쉬업을 위해서 구글 api를 사용한다면 google.load()방식이 더욱 유용할 것이다.


<script src="http://www.google.com/jsapi"></script>
<script type="text/javascript">
    // jQuery 압축, 비압축
    google.load("jquery", "1.2.6");
    google.load("jquery", "1.2", {uncompressed:true});

    // prototype, scriptaculous
    google.load("prototype", "1.6.0.2");
    google.load("scriptaculous", "1.8.1");

    // mootools 압축, 비압축
    google.load("mootools", "1.11");
    google.load("mootools", "1.11", {uncompressed:true});

    // dojo 압축, 비압축
    google.load("dojo", "1.1.1");
    google.load("dojo", "1.1.1", {uncompressed:true});
</script>

[JS]script.aculo.us의 Effect의 callback 함수에 대해서..

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

script.aculo.us의 Combination Effects 사용하기에 대해서 포스팅을 한 적이 있었는데 오늘 OKJSP에 놀러갔다가 콜백함수에 대해서 질문을 하는 글을 보았다. 많이는 아니지만 약간 만져본 부분이기도 했고 콜백 함수는 앞으로 script.aculo.us를 만지게 되면 반드시 만나게 될것 같은 이슈라서 이것저것 찾아보면서 테스트를 해봤다.

안가본 사이에 script.aculo.us사이트가 많이 달라졌다. API 문서도 좀더 충실해졌고.... 이펙트가 필요하면 Combination Effects를 주로 사용하지만 이것은 기본직인 Core Effects를 조합해 놨기 때문에 기본적인 것은 Core Effects를 따른다. Core Effects에 대한 레퍼런스를 보니까 callback함수에 대한 부분에 대한 정리가 잘 되어 있었다.

다음과 같은 4가지의 callback을 지원한다.
beforeStart : Called before the main effects rendering loop is started. 
beforeUpdate: Called on each iteration of the effects rendering loop, before the redraw takes place. 
afterUpdate : Called on each iteration of the effects rendering loop, after the redraw takes place. 
afterFinish : Called after the last redraw of the effect was made.
Fade를 예로 설명하면 다음과 같이 사용하면 된다.

JavaScript

function startEffect() {
    $("contentPlace").fade({
        duration:3.0, 
        beforeStart:function(){alert("BeforeStart");},
        //beforeUpdate:function(){alert("BeforeUpdate");},
        //afterUpdate:function(){alert("AfterUpdate");},
        afterFinish:showMessage
    });
}
   
function showMessage() {
    alert("AfterFinish");
}

script.aculo.us Effect Callback 예제
(prototype.js 1.6.0.2 & script.aculo.us 1.8.1 Based)

 combination Effects를 사용하면서 JSON형태로 옵션 파라미터를 넘길때 callback에 대한 부분을 같이 넘겨주면 된다. 직접 function형태로 써주어도 되고 다른 펑션을 불러오면 된다.
beforeStart과 afterFinish는 해당의 시작과 전에 발생하기 때문에 해당 부분에 원하는 동작을 넣어주면 된다. beforeUpdate와 afterUpdate은 이벤트의 각 렌더링 루프의 시작과 끝에 발생한다.라고 API문서에 나와 있는데 여기서 렌더링루프라는 정확한 개념을 모르겠다.
위의 Fade에서는 Update가 2번 일어난다. 시작하자마자 beforeUpdate와 afterUpdate가 각 한번씩 일어나고 beforeUpdate가 발생하면서 페이드가 시작되고 페이드가 끝나고 afterUpdate발생한다. fade의 내부 구동에서 렌더링 이터레이션의 영향을 받는 것 같다. 이부분은 주석을 빼면 확인은 되는데 alert때문에 Effect효과가 제대로 먹지 않아서 주석처리를 했다.




덧) Textcube 1.5.4 Fermata를 계속 사용하다가 어제 왠지 업그래이드를 하고 싶어서 최신버전인 1.7.3 Risoluto로 넘어왔다. 어제 오늘 약간 어긋낫 셋팅을 맞추느라 고생을... ㅎ 이상하게 이전에 쓰던 후리자님의 소스코드 하이라이터가 돌아가지 않아서 Gendoh님의 Code HighLighter로 옮겨왔다. 파폭3에서는 줄번호까지 같이 복사되는 문제가 있어서 Syntax Highlight를 한번 바꾸려고 생각하고 있었는데 이것저것 봤는데 이게 제일 나은듯... 스타일 좀 먹여주니까 보기에도 괜찮아보이는듯...

[JAVA]요청 Method와 Referer 알아내기..

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

보통 먼가를 처리하기 위해서 페이지를 호출할때는 2가지 GET하고 POST가 있다. 근데 작업을 하다보니까 이 둘중 한가지만 처리하고 싶을 때가 있더라 이거지...

예를 들어서? 글지우기를 하는데 DeleteProc.jsp같은 파일이 이전 페이지에서 비밀번호를 넘겨받아서 확인되면 처리하는데 이런 경우 GET방식으로 악의적인 시도를 막아야 한단 말이지 물론 로그인 다른 처리로도 할 수 있겠지만 내가 POST로 넘겨주니까 GET방식은 아예 거절해버리고 싶은 거라서 찾았더니 있었다.



String whatMethod = request.getMethod();

이 메서드를 사용하면 GET방식으로 왔는지 POST방식으로 넘어왔는지 확인할 수 있다. 내 환경 Tomcat 5.5에서는 post를 소문자로 사요하더라도 여기서 찍힐때는 모두 대문자로 찍혔다. 다른데서도 다 똑같은지는 모르겠지만 더 정확히 하려면 toLowerCase()라든지 toUpperCase()를 써주면 확실하겠지. 어떤 방식으로 넘어왔는지 알았으니까 필요없는 건 거절하면 처리 할 수 있다.




더불어

String Referer = request.getHeader("referer");

이 메서드를 사용하면 리퍼러를 알 수 있다.

http://localhost:8090/TestWTP/index.jsp 와 같은 형태로 출력이 된다. 원하는 형태로 앞쪽의 URL만 체크해서 해당 서버 외에서 온 리퍼럴은 거절해 버리면 어느정도의 악의적인 시도는 막을 수 있다.

[Book] 자바 성능을 결정짓는 코딩 습관과 튜닝 이야기..

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

자바 성능을 결정짓는 코딩 습관과 튜닝 이야기 - 10점
이상민 지음/한빛미디어



제목이 인상적이어서 관심을 약간 가지고 있었지만 Blog2Book란 시리즈가 처음 나온 시리즈라 그냥 이름정도만 알고 있던 책이었는데 친한 형의 동생분이 썼다고 해서 관심을 더 가지게 되었었는데 얼마전에 OKJSP에서 이상민님이 Performance and Java Tuning 세미나를 하셔서 갔다가 왔는데 관심을 많이 가지고 있던 내용이라(내가 튜닝쪽으로 나가겠다는 것은 아니지만...) 무척 맘에 들어서 오자마자 책을 읽었다.

지금 동시에 여러가지 책을 보고 있긴 했는데 책의 내용은 너무 맘에 들었다. 제목에서 느껴지는 대로 이책은 레퍼런스책이나 자바 성능에 대해서 세세하게 설명하고 있는 책은 아니다. 자바가 성능을 내는데 있어서 꼭 필요한 부분이나 주의해야 하는 부분을 팁처럼 제공하는 책인데 약간은 에세이같은 느낌으로 편히 다가갈수 있게 되어 있어서 출퇴근시간에 부담없이 읽을 수 있었다. (책읽을때는 코딩을 따라하는 편은 아니라서...)



내가 가장 좋았던 점은 내가 궁금해 하던 부분을 속 시원히 긁어 주었다는 것이다. 그리고 마침 JSP프로젝트 하나가 막바지인데 내가 무엇을 잘못했는지 내가 사용한 것과 다른 방법으로 했을때에 어떤 차이가 나는지... 그리고 웹사이트 성능을 파악하기 위해 어떤 것을 해야 하는지 피부로 확 다가왔다는 점이 크다.


때때로 망각하고 있기는 하지만 자바에 대해서 얼마나 쌩초보인지 체감하고 있는 상황인데 단순 팁에 대한 부분으로 그치는 것뿐만 아니라 J2EE에 대한 패턴이나 MVC같은 기본적인 부분에 대한 지적도 등한시 하지 않았고 다른 데서는 보기 어려운 GC(Gabage Collect)에 대한 자세한 정리와 성능을 테스트 하기 위해서 어떤 방법으로 접근해야 하는지 세세하게 설명해 주고 있다.


특히 나는 성격이 까칠한 편이라 남을 잘 안믿는 탓에 머가 좋다. 그러면 "왜?"라는 궁금함을 많이 가지는 편인데 항상 그렇게 해야 된다는 걸 읽으면서 세부 내용을 잘 알지 못했던 String사용에 있어서 +를 이용한 결합법과 StringBuffer의 차이점등을 메모리와 시간으로 보여주니까 여실히 느낄수 있었다. 그리고 Collection은 다 비스므리 해 보이는데 어떤걸 쓰는게 좋을지에 대한 부분들을 속도로 비교해 주니까 그냥 인터넷에서 머가 좋아요 하는 것보다 훨씬 마음에 와닿았다.

내가 맨날 놓치는 소스 곳곳에 남겨진 System.out.println의 리소스 낭비나 Resultset이 돌아가는 방식, XML의 성능비교 include 방식에 따른 차이등에 대해서 실제적인 비교 데이터를 제공하니까 이해하기가 너무 좋았다. 내가 이해하기 어려웠던 부분이 없었던 것은 아니지만 초보자들도 이해하기 아주 쉽게 되어 있고 항상 궁금했던 내부의 돌아가는 방식에 대해서 바로 적용할 수 있는 또는 가장 많이 접하는 부분위주로 설명이 상당히 잘 되어 있다.




내가 필요한 부분에 대해서는 확실히 이해하고 나중에 적용하려면 좀더 다양한 테스트를 돌려보고 정리해서 포스트를 하게 되겠지만 책한권 읽은 것 만으로도 적용할 수 있는 부분이 너무 많이 느껴져서 행복할 따름이다.

솔직히 회사에서 책을 사준다길래 구입했는데 줄을 많이 그어서 어차피 한번에 적용할 수는 없기 때문에 두고두고 볼라면 따로 사서 회사책이랑 바꿔치기해야겠다. 별 5개가 아깝지 않은....

[EP]Performance and Java Tuning 세미나 후기..

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

올해와서는 자바를 주로 만지고 있기는 하지만 공부는 책위주로 하고 필요한 것들은 검색위주로 하다보니 특별히 Java쪽 커뮤니티나 사이트들을 다니는 곳들이 없었는데 블로깅을 하다가 세미나 정보각 눈에 띄어서 신청했다.(그러고나서 보니 내가 놓친 괜찮은 세미나들이 많더군... 난 주로 MS나 Sun등의 업체들이 하는 세미나 위주로 다녔었는데 커뮤니티들에서도 괜찮은 세미나를 많이 하고 있었다. 생각해 보면 당연한건데 왜 여태는 그런 생각을 못했었는지.. ㅡ..ㅡ 오히려 더 현실적이고 실무에 도움이 될만한....

암튼 이번 세미나는 OKJSP에서 진행한 세미나로 자바 성능을 결정짓는 코딩 습관과 튜닝 이야기를 지으신 이상민님이 "Performance and Java Tuning"라는 주제로 진행이 되었다.



본 세미나 전에 kenu님의 TPTP에 대한 설명이 약간 있었다. TPTP는 Test & Performance Tools Platform의 약자로 이클립스 프로젝트의 하나이다. kenu님은 All-in-one버전을 추천하셨고 kenu님의 블로그에 가면 TPTP의 자료를 얻을 수 있다. 쉽게 말해 이클립스 상에서 테스트를 하고 성능진단을 할 수 있는 플랫폼을 얘기한다.

개발하면서 성능에 대한 부분까지 확인할 수 있는 것인데 아직 그런 수준까지는 가지도 못했지만 내가 관심이 있는 분야였기 때문에 이런 것이 있다는게 꽤 흥미로웠다. 이번 프로젝트 끝나면 설치해서 좀 만져봐야겠다. 현재버전은 4.5라고 한다. (디밸로퍼웍스에도 TPTP에 대한 강좌들이 있다.) 퍼포먼스에 대한 테스트를 할 수 도 있고 실행할 때의 클래스가 호출되는 시퀀스도 볼 수 있고 Diagram도 볼 수 있는데 적응되면 아주 편할듯 싶다.





어쨌든 본 세미나가 시작되었다. 이하에 나오는 모든 내용은 이상민님의 발표자료를 바탕으로 되어있습니다.

퍼포먼스라 하면 응답시간과 TPS로 나눌 수 있다.

응답시간은 보통 성능을 얘기할때 개발자들이 많이 얘기하는 부분이다. 리퀘스트를 보내고 리스폰스가 올때가지의 시간이고

Network Connection -> Send Request data -> Wait Time(ServerTime) -> Receive Response Data -> Network close

의 순서로 이루어지는데 실제 튜닝이 가능한 부분은 가운데 Server Time뿐이다. 나머지는 컨트롤 할 수가 없으면 여기서 패킷이 전송된 후에 브라우저가 처리하는 시간은 성능에 포함시키지 않는다.

Server Time은 WAS에서 잡아먹는 시간인 Thread time과 그 외에서 잡아먹는 Wait Time으로 나눌수 있다. 이상민 님은 XML로 전송하는 것을 별로 좋아하시지 않는데 XML로 전송하는 것이 성능에 영향을 많이 끼치기 때문에 되도록 쓰지말기를 권하지만 절대 쓰지 말라는 것은 아니무로 당연히 필요한 부분에서 써야한다. 그 외에도 GCsk String도 영향을 많이 끼친단다. 그리고 Wait Time에서는 여러가지가 있지만 역시 DB Time이 가장크게 차지한다.

TPS는 Transaction Per Second의 약자로 서버의 처리능력인데 객관적인 수치이다. 1TPS면 서버로서는 상당히 적은 수치로 듀얼코어의 놋북정도면 커버가 가능하고 20TPS정도면 300명정도가 이용하는 사이트 정도는 충분히 커버가 가능하다고....

성능 테스트 툴로는 제일 유명한 머큐리사의 Load Runner, 그리고 이상민님이 추천하시는 Performance suite enterprise, SkilPerformer, Web LOAD가 있고 무료툴로는 Swing기반의 JMeter와 2002년 이후로는 Update가 없지만 아직은 쓸만하다는 MS Web application stress tool등이 있다. 무료와 상용툴의 큰 차이점은 무표툴들은 내가 쏜 URL로만 테스트를 하지만 사용툴들은 내 PC의 모든 패킷을 캡춰해 준다고 한다.



성능문제를 해결하고자 할때는 가장 중요한것은 병목현상이 일어나는 부분을 찾는 것이다.

병목현상을 찾을 때 가장 좋은 방법은 툴을 사용하는 것이다. 툴을 사용하면 될일을 일일이 System.out.println()을 사용할 필요가 없어진다. 만약 툴이 없다면 System.currentTimeMillis()나 JDK 5이상이라면 System.nanoTime()을 사용할 수도 있다. 그게 아니면 Access Log를 분석해야 하는데 기본적으로 응답시간은 찍히지 않기 때문에 설정에서 응답시간이 찍히도록 설정해 주어야 한다. 그리고 css, js, 이미지파일같은 Static한 것들은 성능하고는 상관이 없기 때문에 분석에서는 제외한다.


분석하는 툴로는 크게 APM과 Profiling Tool로 나눌수 있는데 APM은 전반적인 큰 그림을 볼 수 있으면 Jenifer등의 툴이 있고 Profiling Tool은 세밀한 부분을 볼 수 있으면 Dev Partner, Jproove, TPTP, Jprofiler등이 있다.

자바 튜닝의 대상들로는 Pattern, XML, I/O, String JDBC, GC Setting, Log등이 있다.

보통 튜닝을 해야하는 문제점에는 너무 느리거나 서버가 매일 죽거나하는 것이 가장큰 주요인이다.

이유야 너무 많긴 하지만 체크해야할 부분을 얘기하자면 응답이 너무 느리면 일단 환경을 체크해봐야하는데 환경에는 DB, Network Storage등이 있고 그 다음으로는 WAS Setting을 체크하는데 여기에는 쓰레드수, DB커넥션풀, Web Server설정들이 있다. WAS의 Keepalive설정(각 파일마다 연결을 새로하는지에 대한 여부인데 on으로 되어있으면 static한 파일들을 하나의 연결상태로 계속 받을수 있어서 기본적으론 on이 좋다고 한다.) 서버가 자주 죽는 경우는 메모리 문제(out of memory나 memory leak)나 너무 많은 유저로 발생할 수가 있다.



JVM설정을 볼때 -xx는 비표준이기 때문에 플랫폼이 바뀌면 안될 가능성이 있고 -x는 표준이다.

마지막으로 개발자는 T자형이 되는게 좋다는 말은 크게 와닿았다. 다른 부분은 얇게 많이 알고 한 부분에 대해서는 깊게 아는 것이 좋다는 것인데 난 아직 일자형 인간이라.... 이제 메인으로 집중해서 팔께 있어야지.. 지금 상태로는 Java로 갈 생각이지만.. ㅎㅎ


발표자료는 이상민님의 글에 있으며 위에 말한대로 위의 모든 내용은 발표자료와 이상민님이 발표하신 내용을 바탕으로 작성되었습니다. (내가 잊어버리지 않고 나중에 참고할 수 있도록....)

[Talk]One hundredth article..

One hundredth article..

어느덧 그렇게 시간이 흘렀다..
ㅋㅋ.. 하지만 정작 시간이 그렇게 많이 흐르지는 않았다..

그리고 또한 백번째의 글이라고 해서 큰 의미를 두기에는 가소롭다..
왜냐공.. 내 글은 주절대는 것이 다이고, 형의 블로그에서 다 퍼왔기 때문이다..

어차피 이러면서 조금씩 나의 것을 찾고 또한, 형한테서 많은 패턴을..
배우기 위해서이긴 하지만서도 약간 부끄럽네.. ㅎㅎ..

그래도 2월 4일날 만들어서 약 2주간 글을 퍼 나르면서.. 약간의 변화도 생겼다..
진짜 아주 약간의 변화.. 회사 점심시간이나 혹은 일이 별로 없는 때에는..
노상 웹 서핑.. 연예 가쉽거리.. 오늘의 유머.. 스마트폰 게임에 열중했었다..

그러나 지금은.. 그 시간이 되면, 형의 블로그를 보고.. 나에게 옮기고..
문구 혹은 단어.. 생소한 것들을 찾아보면서 시간을 많이 보낸다..
그러한 변화라도 생긴것이 어디인가.. 나중에는 조금 더 변하것지..

글구 형의 글을 보면서 또하나 느낀점이 있는데..
이러한 글을 많이 써서인지 혹은 원래 그러셨던건지는 몰라도..
글의 표현력이 상당히 좋다는 것이다..
아마도 그렇기 때문에.. 책도 쓰실 수 있었던게 아닐런지..
내용들을 보면 표현 + 구성 + 본인의 생각이 적재적소에 들어가있다..

지금은 100 이지만, 200.. 300.. 400.. 계속해서 조금씩 좋아지길..그리고 항상 하는 얘기지만, 이렇게 가져오는 것만이 아닌..
나의 생각과 나의 정리.. 나의 노하우가 담긴 글들도 생겨나길 바란다..

나의 좌우명 처럼.. "흐르는 물이 되자" 처럼..
한 곳에 머무르기보단 계속해서 흐르고 또 흐르는 사람이 되자..

아자 아잣.. 화이팅..
[난 이정도도 힘든데.. 햄은 어떻게 그렇게 길게 글을 쓰지 ㅡ;;ㅡ.. 아직 머러썽.. ㅠㅜ]

[EP]Data Link & Semantic Web 후기..

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

지난 7월 16일 기묘에서 시맨틱웹에 대한 세미나가 열렸다. 유료행사였지만 팀장님이 가자고 해서 갔다가 왔다. 웹이 2.0의 시대를 넘어가서 나아가야할 시맨틱은 이전에도 종종 세미나나 발표를 들었었지만 항상 너무 개념적이고 어려워서 다가가기가 어려웠다.

처음에 팀장님이 갈꺼냐고 세미나링크를 주었을때 약간 고민했다. 위에 말했던 대로 시맨틱은 항상 어렵게 느껴졌었고 요즘 겁나 바쁘기도 한데다가 세미나를 이것저것 가보았지만 유료세미나가 유료의 값어치를 한다고 느낀적은 아직까지 없었다. 항상 너무 추상적인 주제로 개념적인 뻔한 얘기만 하다가 끝나는 것이 일수였다. 차라리 기술적인 무료세미나들이 나한테는 훨씬 도움이 되었다. 그런 맘이었는데 이번 세미나는 확실히 괜찮았다. 머 내가 이해 봇하는 부분이 대부분이었지만 시맨틱에 대해 먼가 보이고 약간의 기대감이 생겼다고 할까나...

솔직히 말하자면 약간 피곤해서 세미나 초반에 좀 조는 바람에 귀한 정보를 좀 흘렸다. 지금 생각하니 좀 아쉽네..





세션 1. 시맨틱 웹과 링크의 진화 - 김홍기

처음에 세션 들을때는 몰랐는데 진짜 교수구나 하는 생각이 들었다. 처음에는 치대교수가 왜 시맨틱을... 이라는 생각을 했는데 계속 보면서 시맨틱에 대한 열정이나 그런게 보였고 이런 사람이 진짜 교수구나 하는 생각이 들었다.

시맨틱에 대한 전체적인 얘기를 해주었다. RDF와 SPAQL에 대한 설명들... 개념적인 부분이 많아서 좀 어려웠다. 시맨틱은 역시 들어도 정리하기가 쉽지 않아서..

아무리 구글이 최강이라지만 이젠 양이 너무 많아져서 확실히 검색에 한계가 다가오고 있다. 이를 해결해 줄 수 있다는 것에는 꽤 동감.. ㅎㅎ





세션 2. 데이터를 웹으로 - 김광섭

지금의 웹은 Documents중심으로 되어 있기 때문에 모든 link가 문서중심이고 자신만의 일회성 데이터이기 때문에 데이터처리를 하는데 불편함이 있다. 이게 시맨틱 웹이 되면 데이터를 공유하고 재사용할 수 있게 된다. 이걸 할 수 있는 것이 RDF, URI, HTTP이다. 이 3가지를 계속 강조하셨고 이 3가지를 이용해서 시맨틱웹을 이룰수 있다.

Linked Data는 데이터를 표현하고 공유하고 연결하는 방법이다.  그리고 Vocabularies에 대해서 얘기했는데 아마 내가 이해하기로는 이게 Ontology인것 같다. RSS, 사람에 대한 정보를 가지고 있는 Friend of a Friend, FOAF, 디지털매체를 표현하기 위한 Dublin Core, 온라인 커뮤니티의 의미적 연결을 위한 SIOC (Semantically-Interlinked Online Communities), 기구축된 지식시스템내의 Concept를 표현, 연결, 조합하기 위한 SKOS (Simple Knowledge Organization System), 태깅된 데이터를 설명하기 위한 SCOT등에 대해서 얘기했는데 Vocabularies라는 개념 자체를 아직 못잡아서 이해하기는 쉽지 않았다.





세션 3. 우리 곁의 데이터 웹 - 정지웅

정지웅님도 동일하게 현재 문서중심의 웹의 문제점을 얘기했습니다. 문서와 문서간의 링크로 존재하기 때문에 우리는 정보를 찾기 위해서는 어느 곳에 있는지를 알기 위해서 검색엔진의 도움을 얻어야 했지만 메타데이터와 데이터링크를 통해서 시맨틱웹을 이룰 수 있다. 시맨틱 웹의 핵심은 데이터들간의 연결이다.

최근 최고의 이슈는 SNS라고 하시면 SNS에 대해 설명했다. 이 닫힌 SNS들이 정보를 공유하기 위해서 Open Social이 등장했고 FOAF XFN (XHTML Friend Network), Microformat에 대해 설명을 하셨고 데이터 유통을 위한 구글의 Friend Connect에 대해서 얘기하셨다.  자유로운 인증을 위한 OpenID와 Oauth.. 그리고 데이터의 소유권을 사용자에게 돌리려고 하는 Data Portablity에 대해서도 설명하였다.

그럼 시맨틱에 대한 전망은 어떠한가 문서중심의 웹으로 인한 검색의 한계가 이미 가까워졌고 검색 2.0에 대한 관심과 투자가 커지고 있다. 그래서 시맨틱 검색인 PowerSet, Haki, Y!OS등에 많은 관심이 쏠리고 있다.

그럼 어떻게 만들어야 하는가. 데이터를 웹에 연결하기 위해서 XML 웹서비스가 등장했지만 목표는 좋았지만 너무 어렵고 무거워서 절반의 실패를 했고 이보다 더 쉬운 방법이 REST이고 ATOM프로토콜로 REST를 구현하자는 ATOMPub도 있다.

들을 때는 꽤 고개를 끄덕였는데 큰 그림을 아직 보지 못하고 있으니까 확실히 정리하기가 만만치 않다. ㅡ..ㅡ





세션 4. Semantic Social Network - 김학래

DERI에서 시맨틱을 연구하는 김학래 연구원이 발표한 세션인데 나한테는 가장 인상적인 세션이었다. DERI에서는 백여명이 시맨틱만 연구한다는데 그런 기관이 있다는 것이 놀랍기도 하고 부럽기도 했다. 김학래님은 아주 어렵고 간지나는 그런 것이 아닌 시맨틱의 기본적인 부분에 접근을 했다.

웹에서 데이터와 데이터를 연결하는 것이 가장 중요한데 여기서 시맨틱의 관점은 이 연결이 어떤 연결이냐 하는 것이다. A란 사람이 B란 사람이 연결이 되어 있는 것을 알아낼 수 있는데 이게 친구인지, 애인인지 그냥 알기만 하는 사람인지는 도대체 알 수 있는 방법이 없기 때문에 이걸 알아낼수 있게 하려는 것이 Sementic Web이다. 심플하게 link에 의미를 주자는 것이다. 시맨틱의 가치는 표현에 있는 것이지 분석에 있는 것이 아니다.

이런 면에서 태깅은 상당히 괜찮은 시스템이다. 지금의 태깅은 Struct도 없고 Semantic도 없는 오직 Data만 존재하고 있는 상태이다. 각 사이트에서 태깅된 데이터를 어떻게 공유하고 재사용할 수 있는가. 이것을 해결하기 위한 것이 SCOT이다. (김학래님은 SCOT를 만드신 분이다.)

이런 부분에 접근하기 위해서 어떻게 해야 되는가.. 현재 있는 기술로 가자... Linked Data와 Data Portability가 있다. 난 처음 들었지만 Linked Data가 점점 큰 이슈가 되어가고 있다고 한다. 하지만 여기에 문제도 있다. Data는 가져갈 수 있지만 링크는 가져갈 수가 없다. 이부분을 해결하기 위해서 Open Tagging이란 것을 준비하고 있다고 한다.

사용자 삽입 이미지
마지막으로 시맨틱웹이란 것 자체에 대한 얘기를 좀 하셨다. 웹2.0에 대한 기대감이 63%정도라고 하는데 그럼 시맨틱 웹은 어떠한가? 오른쪽 사진이 가장 최근에 완성된 시맨틱웹의 레이어케이크 그림이다. 여기서 사장 좋은건 RDF가 제 위치를 찾은것이라고 한다.

어쨌든 시맨틱웹에 대해서 거부감이 드는 것은 시맨틱웹을 전체적으로 보지 않고 각 부분을 직접 접근하기 때문이라고 한다. 바로 RDF, SPARQL, Proof등을 바로 도입하려고 하니까 문제점이 나타나고 허상이니 잘못됐느니 하는 얘기가 나오는 것이라고 한다. 현재 상태에서는 Trust나 Proof는 아주 먼 얘기가 Bottom Up 형태로 접근을 한 것이 옳다고 생각하신다고....(내 기억이 좀 가묾가물해서 전달이.. ㅡ..ㅡ)

시맨틱 웹은 도입한다고 바로 갑자기 효과가 나고 돈을 버는 그런 달콤한 것이 아니다.

그러면서 우리가 시맨틱웹을 대하는 자세로 취해야 할 몇가지를 제시하셨다.

1. 킬러 어플리케이션을 기대하고 기다리자 말아라.
2. 우리는 참여의 시대에 살고 있다.
3. 시맨틱 웹과 관계를 만들고 그것을 유지하라.


그러면서 마지막으로 보여주신 PPT가 인상에 남는다.

I Hope It is NOT just My Dream.




물론 이 세미나를 듣고도 시맨틱에 대한 내 지식 수준은 크게 나아지지 않았다. 원체 아는 것이 별로 없다보니.... 물론 SCOT이니 FOAF니 전혀 몰랐던 것을 알게 되긴 했지만 그냥 그렇게 있구나 정도 뿐이니...

하지만 내가 제일 좋았던 것은 시맨틱에 대한 기대감을 가지게 되었구나. 이런것을 생각하는 사람들이 있구나 하는 생각들.... 이게 현실로 이루어진다면 어떨까.... 특히 오픈태깅프로젝트에 대한 김학래님의 포부를 얘기했을때는 약간의 떨림까지 있을 정도였다. 시맨틱은 관심은 있었지만 그냥 먼 얘기로만 생각하고 있었는데.... 내가 잘못 생각하고 있었던것 같다. 시맨틱에 대해서 좀더 적극적인 자세를 취해야 할듯 싶다.


 
사용자 삽입 이미지

어도비와 IBM의 협찬으로 받은 참가상품들.... ㅎ