[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월 14일 월요일

[Book] 초고속 웹사이트 구축 : 좀 더 빠른 차세대 웹사이트를 위한 성능 최적화 기법..

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

초고속 웹사이트 구축 : 좀 더 빠른 차세대 웹사이트를 위한 성능 최적화 기법
스티브 사우더스 저
박경훈,신형철 공역
위키북스

일단 책얘기를 하기 전에 책 제목에 대해서 얘기하겠습니다. 이 책은 상당히 좋은 책이지만 책제목은 좀 아쉽습니다. 원문 제목은 괜찮지만 이것을 한국말로 그대로 번역을 하다보니 약간의 의미가 모호한 제목이 되어버렸습니다. 부제는 눈에 별로 안띄기 때문에 큰 의미는 없을것 같고 "초고속 웹사이트 구축"이라는 제목은 책을 고르는 관심 정도에 따라 "빠른 웹사이트를 구축하는 방법"으로 해석할 수도 있고 "웹사이트를 빠르게 구축하는 방법"으로 해석할 여지가 있습니다. 이 책은 "웹사이트 최적화 기법 - UI 개발자를 위한 필수 지침서"의 후속편이라고 할 수 있는 책으로 웹사이트의 속도를 향상시키는 프론트앤드 튜닝에 대한 내용입니다.

스티브 사우더스는 웹사이트 퍼포먼스부분에 대한 전문가로(전에 읽을때는 야후에 있었는데 구글로 이직을 했더군요.) 블로그를 통해서도 웹사이트 퍼포먼스 향상에 대한 많은 내용들을 공유하고 있습니다. 처음 책을 읽을때는 이전 책과 내용이 거의 중복되는게 아닐까 하는 걱정이 있었습니다만 그의 네임밸류대로 전작의 후속작답게 전작에서는 다루지 못했던 내용들을 더 심도있게 다뤘다는 생각입니다.

더욱이 이책은 스티브 사우더스외에도 각 분야의 전문가인 더글라스 크록포트, 벤 겔브레스등등이 각 챕터를 작성함으로써 내용이 정말 알찹니다. 웹사이트 퍼포먼스 튜닝을 할 때 이 2권의 책은 반드시 숙지를 해야할 내용들로 채워져 있습니다. 웹사이트의 속도향상을 위한 자바스크립트 기법들, 스크립트 블록킹을 막는 방법이나 개인적으로는 쉽게 테스트 할 수 없는 각 브라우저별로 어떤 스크립트를 썼을때 어떻게 반응하는지에 대한 표까지 제공하고 있어서 참고하기에 아주 좋습니다. Gzip을 사용했을때의 발생할 문제들이나 이미지 최적화, 도메인공유에 대한 심도깊은 내용들은 미처 알기 어려웠던 부분들에 대해서 자세하게 설명해 주고 있습니다. CSS 셀렉터가 우측에서 좌측으로 읽는다는 것은 이책을 통해서 처음 알게 된 내용이군요.

번역은 중간중간 약간씩 어색한 부분이 보이기는 하지만 전체적으로는 내용을 파악하기에 전혀 무리가 없습니다. 내용의 복잡함에 비해서 설명은 상당히 자세하게 되어 있기 때문에 난이도 자체가 어렵게 느껴지지는 않습니다. 아래는 이책에서 말하는 기법중 핵심부분만 정리한 내용으로 세부적인 적용을 하려면 해당 책을 참고하세요.

  • 반응속도는 0.1초면 사용자는 직접 조작한다고 느끼고 1초정도까지는 자연스럽게 명령을 내리며 컴퓨터가 일을 한다고 느끼고 10초가 현재 작업에 열중할 수 있는 최대시간으로 작업진행상태를 퍼센트로 표시해 주어야 합니다.
  • 스크립트를 블로킹없이 사용하기 위해서는 XHR Eval, XHR Injection, Iframe에 스크립트 넣기, 스크립트 DOM Element, 스크립트 Defer, document.write 스크립트 태그등의 방법이 있습니다.
  • 비동기 방식으로 스크립트를 로드할때 순서를 보존하기 위해서는 하드 코딩된 콜백, Window Onload, Timer, 스크립트 Onload, 나쁜 스크립트 Tags(Degrading Script Tags)가 있습니다.(마지막은 번역이 좀 그렇네요. 나쁘다는 의미는 아닌것 같은데요.)
  • 인라인 스크립트 바로 다음에 오는 스타일시트는 피해라.(혹은 그 반대)
  • JS에서 전역식별자가 가장 비용이 비싸다.
  • DOM을 속성값을 사용할때는 사용할때마다 DOM쿼리를 실행하기 때문에 변수에 저장하여 사용해야 한다.
  • 최신 브라우저는 문자열을 최적화해주기 때문에 +대신 배열을 쓸경우 오히려 더 느린 경우도 많다. 아주 많은 경우가 아니면 +연산자를 사용하면 된다.
  • 15%정도의 사용자가 GZip을 사용하지 못하는데 이 범인은 웹프록시와 PC보안소프트웨어이다.
  • 이미지 최적화 툴을 통해서 이미지의 용량을 상당히 줄여줄 수 있다.
  • 하나의 도메인으로 너무 많은 자원을 받아서 크리티컬 경로가 생긴다면 여러 도메인으로 나눠주는 도메인 공유를 통해 빠르게 할 수 있다.
  • IE 6, 7나 파폭2는 HTTP1.0에서는 커넥션을 4개로 늘릴수 있기 때문에 상황에 따라 HTTP1.0으로 다운그래이드를 통해 속도를 빠르게 할 수 있다.
  • 서버에서의 시간이 오래걸릴경우에는 큰용량의 스크립트나 CSS후에 Flush를 통해서 클라이언트가 빠르게 다운로드를 시작하게 할 수 있다.
  • 아이프레임은 가장 큰 비용이 드는 DOM객체이며 아이프레임이 Onload이벤트를 지연시킬 수 있다.
  • CSS 셀렉터는 오른쪽에서 왼쪽으로 읽어들이기 때문에 하위선택자가 구체적이지 않다면 성능에 문제를 일으킨다.


[EP]HTML5, Flash에 대한 생각들..

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

올해 초에 HTML5, Flash에 대한 생각들...라는 포스팅을 올렸었는데 제가 느끼기에는 사람들이 좀 오해하고 있지 않나 하는 생각이 들어서 비슷한 주제의 포스팅을 올립니다. 그 3달사이에 상황은 크게 달라지지 않았고 스티브 잡스는 여전히 플래시를 거부하고 있고 어도비가 CS5로 액션스크립트 개발자에게 아이폰개발을 할 수 있게 하려고 했지만 애플의 저지로 막힌 상태입니다. 잡스가 왜 플래시를 거부하는지에 대한 편지도 공개한 상태이고 큰 이변이 없는한 이런 상황은 계속 될 것입니다. 그러다 보니 사람들이 저랑은 좀 다른 생각을(어찌보면 오해) 가지고 있는 것 같아서 정리해봅니다.

지금 액션스크립트를 공부하는 건 멍청한 짓이다?
지금 약간의 어두운 그림자가 드리웠고 어도비의 나태함은 저도 긍정하고는 있지만 솔직히 액션스크립트 만한 기술도 없습니다. 기본적으로 HTML5는 플래시를 대체하기 위해 나왔다기 보다는 HTML4가 너무 오래됐기 때문에 HTML4의 기능을 확장하기 위해서 준비되고 있는 것입니다. 이는 플래시의 일부분을 충분히 대체할만한 기술이기는 하지만 그렇다고 플래시전체를 대체하지는 않을 것입니다.

DSC_0022.JPG
Image by alexmuse via Flickr

순식간에 HTML5 코앞에 다가오기는 했지만 아직도 워킹드래프트상태이고 언제 Final이 나올지 알수 없습니다. 현실적으로 HTML5로 이런것도 할 수 있다 정도이지 실제 서비스로 적용하려면 많은 고민과 노력이 필요할 것이고 그것을 할 수 있는 개발자들도 아직은 많지 않은 상태입니다. 물론 적용할려면 HTML5를 지원하지 않는 브라우저에 대한 대안이 있어야 하기 때문에 실제 작업하면 부딪힐 난관들도 꽤 있는 편입니다.

하지만 액션스크립트는 현재도 꽤 많은 개발자들이 존재하고 있고 실서비스에도 오랫동안 적용을 하고 있었기 때문에 노하우가 꽤 축적되어 있기 때문에 현재 바로 사용이 가능합니다. 사용자의 Needs는 계속해서 달라지고 있고 HTML5가 확정된다고 하더라도 웹으로써의 한계는 계속 존재할 것있니다. 그동안 HTML4시대에 웹으로써 하지 못하던 부분들을 많이 충족해 준것처럼 앞으로도 그러리라고 생각합니다. 다만 달라진 것은 앞으로 플래시가 가지려고 했던 큰 파이의 일부분을 HTML5의 내어주어야 하는 상황이 되었다는 것 정도일 것입니다. 순식간에 플래시가 몰락하는 일은 없을 것입니다.


플래시는 웹표준이 아니다.

Dear Steve,
구도가 이상하게 HTML5와 플래시의 대립형태로 되면서 표준과 비표준 얘기가 나오는것 같습니다. 물론 플래시는 웹표준이 아닙니다만 웹표준이 아니므로 쓰면 안된다라는 것과는다른 얘기인것 같습니다.웹표준은 현재도 존재하고 이제 HTML5도 제정될 예정이긴 하지만 그렇다고 표준아닌 기술은 쓰면 안된다는 것은 아닙니다. 좋은 표준이 있는데도 표준외의 방법을 사용하는 것이 문제인 것인데 플래시같은 부분의 아예 표준의 영역외의 것입니다.

웹표준이 아니라는 것은 레이아웃을 잡는데 Div를 쓰지 않고 Table을 쓰는 것이 문제라는 얘기이지 표준외의 부가적인 기술을 쓰지 말라는 얘기가 아니라는 것입니다. 웹표준은 웹기술의 올바른 사용법에 대해서 제정되어 있는 것이지 표준에 정의되어 있는 기술외에는 웹에서는 쓰지 말라고 하는 것은 아닙니다. 그렇다면 Strict하다면 웹은 너무 딱딱하겠지요. 표준의 영역이 아닌것은 플래시외에도 많이 존재하고 있습니다.

플래시가 웹표준아니라는 말을 할려면 그전에 HTML4나 XHTML부터 올바르게 사용하고 웹표준을 크게 저해하고 있는 IE6과 엑티브엑스부터 걷어내는 것이 훨씬 맞을듯 합니다. 이런부분은 내버려둔채 아이폰이 대세가 되었다고 플래시를 적대시 한다는 것은 좀 앞뒤가 안맞게 느껴집니다.(순식간의 악의 축이 된듯한 분위기군요.) 플래시는 이런 것에 비하면 아주 괜찮은 솔루션이라고 생각하고 있고 엑티브엑스도 웹표준이 아니라서 쓰지말자는게 아니라 플랫폼과 브라우저 종속적인데다가 과도한 남용으로 웹표준으로 충분한 영역까지도 침범했기 때문에 문제라는 것입니다.


각자의 역할이 있습니다
HTML5는 HTML5로서의 역할이 있고 플래시는 플래시로써의 역할이 있는것입니다. HTML5이 아무리 강력하게 나온다고 하더라도 커버못하는 부분이 있을 것이고 5년, 10년전에 현재의 웹을 상상도 못했으니 앞으로 5년, 10년뒤에 어떤 세상이 올지 모릅니다. HTML5가 지금은 강력하지만 시간이 지나면 웹표준은 사회의 Needs를 따라가면서 제정될 수는 없을 것이니 당연히 플래시나 실버라이트같은 기술들이 메꿔주어야 할 부분이 있을 것이라고 생각합니다. HTML5가 나오기 이전인 웹에서 플래시가 준 혜택은 충분히 인정해 줄만하다고 생각합니다. 물론 잘못된 사용과 과도한 사용으로 인한 폐혜가 없는 것은 아니지만 멀티업로드라든지 플래시게임, 동영상플레이라든지 하는 플래시등의 기술로써만 가능한 부분을 통해서 혜택을 입고있었고 앞으로도 그럴 것입니다.

저는 당연히 HTML5를 지지하고 HTML5의 큰 기대를 걸고 있지만 이는 제가 액션스크립트 개발자가 아니기 때문이지 플래시는 사라져야 할 기술이라고 애기하는 것은 아닙니다. 그동안 웹이 할수 있는 일이 10이라고 했을때 웹표준기술로 5, 플래시등의 기술로 5를 할 수 있었다면 HTML5가 생김으로써 웹표준이 커버할 수 있는 영역이 7이나 8정도로 늘어난 것입니다. 물론 플래시가 할수 있는 영역은 줄어들었고 이제 HTML5가 정식으로 자리잡으면 이런 부분은 플래시가 아닌 HTML5로 처리하는 것이 더 맞다고 생각합니다만 시장은 점점 커가게 마련이고 웹이 할수 있는 일이 10이 아닌 20, 30으로 늘어갈것입니다.

웹표준으로 가능한 것은 웹표준기술로 커버하고 웹표준으로 안되는 부분들은 플래시나 실버라이트가 대안으로 자리 잡는 것이 맞다고 생각하고 있습니다.



[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라고 해서(스프링의 사상도 그렇기는 하지만요) 스프링이라는 주제에 한정되지 않고 다양한 주제의 세션이 진행된 것이 오히려 더 좋았던 것 같습니다. ㅎ


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

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

한국 스프링 유저그룹(KSUG)에서 지난 4월 17일에  LG CNS본사(명동 프라임타워) 9층 대회의실에서 제10회 세미나가 12시부터 6시까지 총 5가지 세션으로 진행되었습니다. KSUG를 알고 관심있게 된지는 그렇게 오래되지는 않았지만 제 기억으로는 꽤 오랜만에 진행된 세미나인 것 같습니다. 작년에 새 운영진과 함께 새로운 모습의 KSUG로써는 처음 진행된 세미나였습니다.

세미나의 시작은 현 KSUG회장이신 fupfin님의 인사말로 시작되었습니다.

간단한 스프링에 대한 소개와 함께 인터넷에 돌아다니는 유머러스한 언어별로 시각의 차이를 비교해 놓은 사진과 함께 자바의 모습에 대해서 설명하셨습니다. Haskell Fans이 바라본 자바의 모습을 특별히 강조하셨는데 구조적으로 잘 쌓았지만 블럭을 너무 많이 쌓아서 쓰러져버린 트럭에 비유한 자바의 모습을 스프링이 등장하기 전의 자바의 모습이라고 하셨습니다.


SCALAbility - scala를 통해 scalability 곱씹어보기
- 이동욱(LG CNS)

Martin Ordersky가 만든 Scala라는 언어(스칼라가 맞는 발음이랍니다.)를 통한 Scalability(확장성)에 대한 세션으로 내용도 그렇지만 특히나 깔끔한 PPT(aka 장표)가 인상적인 세션이었습니다.(딱 제가 좋아하는 스타일의 PPT였습니다. ㅎ)

Scalability는 "애플리케이션이 사용자의 요구에 맞추기 위해 크기나 용량을 변경해도 그 기능이 계속하여 잘 동작할 수 있는 능력"으로 정의하였습니다. 시작은 스칼라와는 상관없게 느껴지는 여러가지 얘기로 시작되었는데 실제 언어의 단어의 수와 프로그래밍언어의 단어의 갭은 상당히 크기 때문에 프로그래밍 언어로써 현실세계의 문제를 해결하는데는 어려움이 있습니다. 언어가 문제에 접근하는 방법에는 2가지가 있는데 단어의 증가와 규칙의 증가입니다. 너무 간단하면 접근은 쉬우나 문제해결에 어려움이 있으며 너무 증가하면 문제에 접근은 쉽지만 진입장벽이 큰 어려움이 있습니다.

Scalability를 설명하기 위해 여러가지를 보여주셨는데 개미집을 지상으로 6미터나 짓는 흰개미나 자기유사성(Self-Similarity)를 갖는 Fracktal을 보여주었습니다. 얼핏보면 주제와 전혀 상관없는 부분 처럼 느껴지기도 했지만 모두 확장성이란 것에 대한 이해를 돕기위한 내용들이었습니다. 언어에서 확장성(Scalability)이란 것은 "문제영역의 크기나 복잡도가 증가하여도 유사한 방법으로 문제 해결이 가능한 것"이라고 설명하셨습니다.

스칼라라는 언어는 처음부터 확장성을 고려해서 만들어진 언어고 상당히 많은 언어의 영향을 받았지만 그 많은 것들을 상당히 이쁘게 스칼라라는 언어안에 담았다고 합니다. Scala는 컴파일하면 .class로 떨어지는 Groovy, Clojure처럼 native to JVM으로 JVM을 속이며 JRuby, Jython은 ports to JVM입니다.  객체지향과 함수형 언어의 통합하여 간결하면서도 강력한 언어입니다. 플러그인만 설치하면 Eclipse, IntelliJ, NetBeans에서 모두 개발이 가능하며 스칼라에서 모든 것은 객체입니다.(Uniform Object Model)

그 뒤로는 변수와 클래스를 정의하는 것부터해서 분수 클래스를 만들어서 만들어진 분수클래스를 +로 더할수 있게 간단하게 확장하는 시연을 보여주면서 Currying에 대한 설명까지도 보여주었습니다. 클래스를 아주 간단하게 확장할 수 있어 Seamless합니다. 그 뒤로는 Scala의 인터페이스와 같은 Trait를 설명해 주시면 Trait로 객체를 조합하는 것을 보여주셨습니다. Trait는 Rich Interface인데 Rich Interface라는 말은 메서드가 많다는 의미이고 자바는 보통 Thin인터페이스입니다. 인터페이스가 리치인터페이스이면 사용자가 구현해야 할 것이 많기 때문에 피곤한데 Trait는 리치하면서도 사용자가 구현할게 많지 않도록 설계되었으며 마틴 오더스키가 제시한 크기비교를 하는Trait를 보여주셨습니다. 크기비교를 하는 경우 거의 비슷한 코드인데도 >, <=, >=를 모두 구현해야 하지만 Trait에서는 compare만 구현하면 됩니다.

값으로 주고 받을 수 있으면 First Class객체인데 Scala에서는 함수도 퍼스트클래스객체이므로 주고 받을 수 있습니다. 함수형의 2번째 특징은 부작용이 없다는 것으로 Referentially Transparent(투명한 참조)를 실현하고 있습니다. 이말은 대체를 하더라도 다른 문제가 발생하지 않으면 투명한 참조라고 합니다. 자바의 for문은 아무리 익숙해 져도 값을 추적하고 해야하는데 이를 foreach함수로 대체하고 함수를 아규먼트로 넘기도록 변경하였으며 Loop대신 Recursive를 하도록 하였기 때문에 더 자연어에 가까워서 익숙해 지면 이해가 쉽습니다. imperative style는 기존 자바개발자들에게 익숙하며 imperative command위주이고 side-effect가 있지만 functional style은 이해가 쉽고 에러가능성을 낮춰주는데 Scala는 functional style에 가깝게 설계되었습니다.

Alan Kay가 한 말
I'm not against types, but I don't know of any type systems that arent't a complete pain, so I still like dynamic typing. -Alan Kay

Scala는 정적타입을 가진 언어인데 정적 타입은 컴파일시에 타입 검증이 가능하고 리팩토링이 더 안전하며 코드자체가 Documantation이 되는 장점이 있습니다. Scala는 타입추론(Type Inference)을 도입하였는데 이는 되도록 간결함을 유지하면서 정작타입 시스템의 장점을 누리려는 노력입니다. 리터타입이 따로 없는데도 사람이 Integer끼리 더하면 결과도 Integer라고 생각하듯이 타입추론을 해냅니다.

자바에서의 캐스팅인 타입변환을 Scala에서는 형변환을 컨트롤 할 수 있습니다. int를 앞에서 만든 분수객체인 Rational로 변환해 주도록 선언하면 자동으로 변환이 되며 import해야만 사용되기 때문에 한번 형변환하면 전체가 변환되는 Ruby와는 다르게 개발자가 제어가 가능하다는 장점이 있습니다.

발표하시는 이동욱님스칼라 멀리서 보기Scala is not silver bullet

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

이번 세미나에서 제가 가장 크게 흥미를 가지고 보았던 세션이었습니다. 스칼라라는 언어는 들은 적은 있었으나 그 자세한 내용은 몰랐었는데 스칼라라는 언어에 대해서 많이 알 수 있었고 저뿐만 아니라 다들 스칼라는 생소한 주제였을텐데 거기에 어려운 주제인 Scalability를 아주 쉽게 설명해 주셨던것 같습니다. 특히 Ruby가 어느정도 한계를 보여주었던 것을 모두 해결하려는듯 자바가 쌓아놓은 안정적인 기반을 그대로 이용한채 Functional의 장점을 가지고 개발할 수 있다는 것은 상당히 관심이 갔습니다. 자바스크립트에 꽤 흥미를 가지고 있어서인지 Functional이라면 왠지 더 관심이 가게 되더군요. 당장 쓰지는 않아도 조만간 헬로 스칼라를 찍어보게 되지 않을까 싶습니다. ㅎㅎㅎ


스프링 시큐리티를 이용한 웹보안
- 고종봉 (제너시스템스)

스프링 시큐리티는 스프링 개발자들의 메일링에서 스프링 기반의 보안구현체가 있어야지 않겠냐는 이야기가 나오면서 2003년 "스프링을 위한 아씨지 시크리티"로 출발하여 2004년 3월에 정식출범하여 스프링의 공식 서브 프로젝트가 되었습니다. 2007년 후반에 공식적으로 스프링 포트폴리오 프로젝트가 되면서 "스프링 시큐리티"로 이름이 변경되엇습니다.

이 세션은 라이브코딩(시간 낭비를 위해서 Copy & Paste)로 진행되었으며 웹페이지에 시큐리티를 적용하며 보안관리를 하는 것을 아주 간단한 예제를 통해서 설명되었습니다. 스프링 시큐리티의 보안에는 인증과 인가가 있는데 인증은 신원을 확인하는 것이고 인가는 접근할 권한이 있는지를 검사하는 것입니다. 스프링 시큐리트를 적용하려면 관련 jar파일들을 추가하고 web.xml에 filter를 추가하고 applicationContext-security.xml에 내용을 추가하면 바로 적용가능합니다.

스프링 시큐리티를 이용한 웹보안 발표하시는 고종봉님스프링 시큐리티 아키텍쳐

라이브 코딩은 웹페이지에 스프링 시큐리티 적용하고 로그인 폼을 원하는 폼으로 변경한 뒤에 로그아웃기능을 추가하고 로그인/아웃의 상태를 표시해준지 권한없는 페이지에 접근한 403 access is denied페이지를 원하는 페이지로 변경하였습니다. 그뒤로는 추가적인 응용을 위해서 특정 URL은 보안을 통과하도록 설정하고 한계정으로 동시에 한명만 접속하도록 한뒤 사용자를 DB에서 가져오도록 수정하였습니다. 아주 간단한 예제였지만 스프링 시큐리티를 이해하기에는 부족함이 없었습니다. 추가적으로 심화실습인 MVC를 적용하여 @Secured 애노테이션으로 권한을 제어하는 시연까지 보여주셨습니다.

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

시스템을 개발하면 거의 필수적으로 포함되어야 하는 보안에 관한 이슈가 수년간의 오픈소스개발로 인하여 많은 노하우가 녹아있는 스프링 시큐리티에 대해서 스프링을 잘 모르는 저로써도 쉽게 이해할 수 있었던 세션이었습니다. 아주 간단한 예제를 통해서 시연을 보여주었기 때문에 이해하기가 쉬웠고 재미있었던데다가 스프링 시큐리티의 편리한 점을 이해하기 좋았습니다. 그 이상에 대해서 공부하는 것은 각자의 몫이겠죠 ㅎ