[Tool]Eclipse Helios와 JDK 6u21를 사용할 때 OutOfMemory 오류가 발생하는 문제..

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

지난 6월 23일에 발표된 Eclipse 3.6 Helios를 슬슬 사용해 보려고 새로운 마음으로 JDK도 JDK 6 Update 21을 다운받아서 설치하고 기존에 사용하던 프로젝트를 저장소에서 Checkout받자 프로젝트를 생성하던 도중 이클립스가 죽어버리는 현상이 발생했습니다. (Subclipse, m2eclipse 사용중)

기존에도 종종 이클립스는 메모리오류가 발생하였기 때문에 아무생각없이 eclipse.ini파일을 수정하여 주었지만 좀처럼 해결되지 않고 계속 프로젝트를 받아오다가 번번히 죽어버렸습니다. 로그파일을 확인하니(.log파일은 workplace안에 .metadata폴더 안에 있습니다.) 아래와 같은 오류가 발생하였습니다.

java.lang.OutOfMemoryError: PermGen space

[해당 오류는 나도 많이 보던 것들인데 난 지금 환경으로 따지면, 보통 서버 로그에서 많이 봤다.. 이클립스는 단순히 소스 관리와 개발을 조금 편하게 하기 위한 툴 정도로만 사용하기 때문에 서버 연동하고는 거리가 멀다..]

기존의 eclipse.ini파일의 수정으로는 도저히 해결이 되지 않아서 Helios가 안정적이지 않은 것으로 막연히 생각하고 있었는데 트위터를 통해서 해당 문제에 대한 해결책을 얻을 수 있었습니다.

이 문제는 JDK 6u21에서 발생하는 문제인데 6u21에서 vendor명이 기존의 Sun에서 Oracle로 변경이 되었습니다. Eclipse 런처가 JVM의 벤더를 읽어서 Sun JVM일 경우에는 추가적으로 이클립스의 동작을 위해 필요한 XX:MaxPermSize 설정을 추가하는데 6u21에서는 Sun이 아닌 Oracle로 변경이 되어 이 설정이 먹히지 않는 것입니다. 이 내용은 이클립스의 버그로 등록은 되었지만 9월에 예정된 Helios SR1에서 수정될 예정은 없어보인다고 합니다.

이클립스의 폴더안에 있는 eclipse.ini파일을 열어서 아래의 부분을 삭제합니다.

--launcher.XXMaxPermSize
256m

그 다음에 -Xmx설정뒤에 -XX:MaxPermSize=512m 를 추가하면 위의 OutOfMemoryError를 피할 수 있습니다.

아래 내용은 참고용으로 올리는 저의 eclipse.ini파일입니다.

C-like

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

-startup plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar --launcher.library plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.1.0.v20100503 -product org.eclipse.epp.package.jee.product --launcher.defaultAction openFile --launcher.XXMaxPermSize 128M -showsplash org.eclipse.platform -vm C:\Program Files\Java\jdk1.6.0_21\bin\ --launcher.defaultAction openFile -vmargs -Dosgi.requiredJavaVersion=1.5 -Xms40m -Xmx512m -XX:MaxPermSize=256m

이 문제는 Windows플랫폼에서만 발생한다고 합니다.

추가로 봄싹의 김성호님이 공유해 주신 이클립스 위키에 위 문제의 해결법에 대해서 잘 나와있습니다.

1. 6u20으로 다운그래이드
2. eclipse.ini에  -XX:MaxPermSize=256m 추가
3. 수정된된 이클립스용 dll을 다운받아 사용

이렇게 3가지 방법숭 하나를 사용하라고 권하고 있습니다.

[EP]2010 한국 자바 개발자 페스티벌 #2..

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

Jetty - Continuation - 이상민
Track 3의 두번째 세션입니다. 공식적으로는 Track간의 이동이 허용치 않았지만 자리의 여유도 있었고 해서 관심있는 세션으로 이동했습니다. Comet등을 이용할 때 필요한 Jetty서버의 Continuation에 대한 내용이었습니다.

일반적인 웹서버인 아파치 같은 경우는 쓰레드 기반이기 때문에 요청마다 쓰레드가 생성되지만 NGinX같은 경우는 이벤트 드리븐 방식이기 때문에 DDoS공격에 대한 대처로 NGinX와 Jetty 조합도 괜찮은 편입니다.

현재 많이 사용하는 Servlet Spec 2.5기반인 WAS들은(Tomcat 6은 2.5기반, Tomcat 5.5는 2.4기반) 쓰레드 풀을 사용하는데 이런 경우에 쓰레드플의 갯수를 어느 정도로 할 것인가 하는 것은 어려운 결정입니다. 커넥션을 연결할 때 하나의 쓰레드를 차지하게 되고 기본적으로 동기적(Synchronously)이고 이를 비동기적으로 만들기가 어렵기 때문에 일반적으로 풀링을 사용하거나 Ajax같은 경우로 연결할 때도 롱풀링같은 기술을 사용합니다. 서버는 모든 각 클라이언트마다 한개 이상의 쓰레드를 할당하게 됩니다.

Jetty Continuation
일반적으로 실무에서는 JEUS나 WebLogic를 사용하는데 Tomcat이나 Jetty도 성능이 좋습니다. 하지만 현업에서는 책임을 전가(?)할 대상이 필요하기 때문에 오픈소스보다는 상용을 선호합니다. Jetty는 버전 6과 7이 있는데 7부터는 Eclipse로 넘어갔습니다.

Jetty는 HTTP Server이고 javax.servlet container를 제공하며 Small Footprint(메모리를 아주 적게 사용한다는 의미)하며 비동기적(Asynchronous)합니다. Jetty가 사용하는 Asynchronous Servlets은 동기IO나 NIO를 사용하는 것과는 약간 다르고 Asynchronous Wait라고 생각하면 됩니다. Jetty의 Continuation은 Suspended되고 Restarted되는 구조입니다.

클라이언트가 요청을 하면 Servlet이나 Filter를 탄 후 suspend()가 호출되고 비동기적 호출(Async.call : 직접 구현해야 하는 부분입니다.)을 하게 됩니다. Async.call을 한 다음에는 클라이언트의 Connection은 끊기지 않은 상태에서 쓰레드는 반납이 되고 다른 요청을 받을 수 있게 됩니다. Async.call은 complete()되거나(종료) resume()되거나(되돌아옴) timeout이 발생(시간초과)하게 되고 다시 Servlet이나 Filter를 통해서 클라이언트에게 결과를 돌려주게 됩니다.

물론 이렇게 구현하여도 쓰레드를 새로 생성하는 것은 엄청난 비용이 들기 때문에 쓰레드풀은 계속 사용해야 합니다. 컨티뉴에이션을 이용하면 하나의 쓰레드가 많은 요청을 처리할 수 있게 되고 가장 많이 쓰이는 곳은 채팅입니다. Jetty에서는 QosFilter(Quality of Service Filter), DosFilter(Denial of Service Filter), GzipFilter(Compress response objects), ProxyServlet를 제공하고 있습니다.

하얀색으로 표시된 부분만 구현하면 되며 Continuation은 Interface이기 때문에 객체를 생성할 수 없고 Continuation continuation = ContinuationSupport.getContinuation(req);처럼 요청을 넘겨주고 Continuation의 인스턴스를 받아와야 합니다. continuation .addContinuationListener(new AListener);에서 리스너를 지정하고 setTimeout()으로 타임아웃을 밀리세컨드로 지정합니다. 여기서 타임아웃이 0보다 작거나 같으면 절대 expire가 되지 않기 때문에 절대 사용하면 안되고 이렇게 사용할 경우 Out of Memory 혹은 Thread Pool이 발생할 수 있습니다. continuation.suspend()를 호출한뒤에 asysnchronous call 부분에서 로직을 작성하고 resume()이나 complete()가 호출되면 종료되게 됩니다.(resume()은 suspende된 것을 다시 시작합니다.) 여기서 리스너는 ContinuationListener를 구현해야 하고 onComplete, onTimeout을 작성해야 합니다. onComplete는 종료시에 무조건 호출되며 onTimeout이 호출될 때도 onComplete가 같이 호출됩니다.

Servlet 3.0
2009년 12월 10일에 파이널 릴리즈가 되었으면 JSR 315를 따릅니다. Glassfish 3가 Servlet 3.0 기반으로 Sun에서는 사용은 공짜로 하지만 기술문의를 할 때는 요금을 지불해야 합니다. 테스트 결과 대부분의 경우에서는 Tomcat과 Jetty가 빠르고(Jetty가 약간 더 빠릅니다.) 특수한 경우에만 Glassfish가 빠른 것으로 나타났습니다. 최근 베타릴리즈된 Tomcat 7에서 Servlet 3.0을 지원하고 있습니다.

주요 특징으로는 비동기 서블릿과 Comet을 지원하고 Web Framework Pluggability하며 @WebServlet, @WebFilter, @WebInitParam, @WebListener, @MultipartConfig의 애노테이션을 지원하여 web.xml에 설정하지 않고 소스코드에서 바로 적용할 수 있습니다. java.servlet.asyncContext의 AsyncContext 인터페이스를 제공하고 있으면 Jetty와 용도는 같지만 메서드명은 약간 다른 setTimeout(), addListener, complete를 제공하고 있습니다. java.servlet.ServletRequest의 startAsync()를 호출해서 비동기를 시작할 수 있습니다.

Servlet 3.0에 대해서는 JavaOne에서 공개한 PDF에서 자세한 내용을 볼 수 있습니다.

올 초에 매쉬업준비하면서 윤군이 일부구현해서 Comet서버용으로 Jetty 테스트를 하면서 알게되었던 Continuation에 대한 부분에 대해서 따로 공부할 여유를 갖지 못했는데 전체적인 흐름과 Servlet 3.0에 대해서도 알게 되어 나름 알차게 들었습니다. 그리고 튜닝을 주업무로 하시는 이상민님의 설명이었기에 추천해 주시는 부분에 대해서 성능에 대한 걱정을 따로 하지 않아도 되는 점이 좋았습니다. 다만 중간에 Comet에 대한 언급을 하시면서 Client의 연결없이도 클라이언트에 데이터를 푸쉬한다는 얘기를 하셨었는데 정확히 의도하신 의미는 몰라도 Comet도 최초의 요청을 통해 Connection 연결은 해야 되는 것으로 알고 있어서 이부분은 잘못 전달된 내용이 아닌가 싶습니다.

Java용 구글 앱 엔진과 스프링 - 박성철
Track 4의 세번째 세션입니다.
스프링의 전략은 "Next evolution for java is to better integrate the techs"로 표현할 수 있으며 생산성을 향상하고 VMware로 인한 클라우딩 컴퓨팅에 대한 것입니다. 그동안 엔터프라이즈 자바의 고민은 생산성에 대해서는 관심이 없고 소위 얼마나 뽀대가 나는가 얼마나 팔리느냐에만 관심이 있었습니다. 여기에 두가지 솔루션이 있는데 오랫동안 지원해왔고 자바의 자산은 그대로 이용하면서 동적언어가 좋은 경우에는 Groovy + Grails, 그리고 동적언어에는 별로 관심이 없으면 SpringRoo입니다.

SrpingRoo
SpringRoo의 생산성 전략의 특징은 수분안에 기본 애플리케이션의 뼈대를 생성하는 극적인 생상선 향상과 RoR로부터 취한 관례 우선(CoC), 프로젝트를 자동으로 구성하고 보일러플레이트문제를 해결함으로써 반복작업을 제거하고 스프링을 기반으로 하고 있다는데에 있습니다. 스프링소스와 구글앱진의 기술적 제휴는 5월 19일에 발표를 하고 Spring Tools Suite에서 구글앱엔진을 지원하고 SpringRoo(and Grails)와 Google Web Toolkit를 연동했으면 Spring Insigt와 Google Spped Tracer로 모니터링을 하는 것이었습니다. 이 기술적 제휴는 구글은 앱엔진을 Biz영역에까지 사용하고 싶었고 VMware는 Open PaaS 영역까 진입하고 싶은 데서 이루어졌습니다.

SpringRoo는 단순작업을 최소화하고 양방향(Round Trip)인 코드생성기이며 엔티티 중심의 DDD스타일[보통은 로직을 서비스레이어에 두어 소스가 중복되고 서비스레이어가 복잡해 지는데 이 로직을 도메인 객체에 두자는 것이 DDD입니다. 정확히 DDD라고 할 수는 없지만 DDD에 기반을 두고 있습니다.]로 레이어가 단순화 된 기본 아키텍쳐를 두고 있습니다. 특징으로는 SpringRoo는 컴파일단계에서만 관여하기 때문에 실제 소스에 SpringRoo에 대한 코드는 없어서 실행시의 자원을 차지하거나 하는 성능에 대한 문제가 전혀 없으며 Spring, JPA, Log4j, Maven, AspectJ등 일반적인 자바기술을 이용하고 있으면 자유롭게 제거가 가능하고 오픈소스입니다.

SpringRoo는 아주 쉬운 사용법을 가지고 있고 Shell기반으로 동작을 하면 Hint라는 명령어를 입력하면 현재 단계에서 무엇을 해야하는지 가이드 해주면 탭! 탭! 탭!을 통해서 명령어를 쉽게 완성할 수 있습니다. 프로그래밍은 디자인입니다. 개발자는 설계를 하는 사람이지 단순히 코드를 찍어내는 작업이 아니기 때문에 단순작업은 컴퓨터가 하게 하는 것입니다. 프로젝트 구성/생성, 빌드스크립트 생성/관리, 의존성라이브러리 관리는 자동화하고 개발자는 설계에만 집중하도록 하자는 것입니다. 이번에 추가된 것이 GWT이고 GWT를 사용하면 기본적인 CRUD가 되는 GWT앱을 간단히 생성할 수 있습니다.

SpringRoo의 아키텍쳐는 엔티티 계층은 JPA, AspectJ를 사용하고 웹계층은 Spring MVC, Tiles를 사용하며 서비스계층은 선택사항으로 제공하고 있습니다. 레파지토리는 선택사항이기 때문에 DAO계층은 게저했으면 차후 1.1.0버전에서 RIA에 대한 지원을 할 예정입니다.

GAE/J
GAE는 클라우드 컴퓨팅 서비스로 구글이 내부에서 사용하던 인프라와 관리기술을 공개적으로 열어준 플래폼 서비스(PaaS)로 처음에는 파이썬을 지원하고 이어서 Java를 지원하였습니다. 클라우드라는 것은 갑자기 튀어나온 개념은 아니고 이전부터 얘기가 있었던 것으로 LISP를 만든 John McCarthy는 "Compuation may someday be organized as a public utility."(전산자원은 언젠가 공공재가 될 것이다.)라고 했으며 John Gage의 "The Network is the Computer"라는 말은 유명합니다.

클라우드의 핵심 특징은 기민성과 확장성이고 적은 돈으로 위기에 대응할 수 있으며 보안에 강하며 장비(지역)에 독립적입니다. 또한 유지보수가 안정적이고 전문가가 대신 관리해주기 때문에 신뢰할 수 있습니다. 클라우스 서비스의 구성요소는 클라이언트와 애플리케이션( SaaS)가 필요하고 플랫폼은 Paas로 제공되며 구글 앱엔진이 이 역할을 하고 있습니다. 하부구조는 IaaS(Infrastruct as a Service)로 제공됩니다.

GAE/J의 특성으로는 구글애플리케이션과 동일한 인프라와 관리기술을 그대로 이용할 수 있으며 수평 확장성[하드웨어를 업그래이드 하는 것이 아닌 추가로 서버를 추가하여 확장하는 것을 의미하며 한계가 매우 높습니다.]이 좋으며 JDK 6, JPA, JDO, Servelt등의 고유 자바기술을 이용할 수 있고 서비스 기반이며 구글의 빅테이블을 이용할 수 있다는 점입니다. 빅테이블은 스키마가 없는 데이터 저장소로 GAE에서는 매우 중요하지만 GAE를 사용할 때 가장 어려워 하는 부분중 하나입니다. 기본적인 사용은 무료로 할 수 있다는 장점도 있습니다. 개발환경은 이클립스에 구글 플러그인을 설치만 하면 되며 로컬 개발서버에서 테스트를 할 수 있고 GWT와 통합되어 있습니다.

개인적으로는 세션의 제목이 직관적으로 정해지지 않은게 아닐까 하는 생각이 들었습니다. 올해 공개된 스프링소스와 구글의 협력에 대한 부분인데 구체적으로 보자면 5월 Google I/O에서 벤알렉스가 SpringRoo와 Google App Engine의 연동에 대해서 보여준 내용이 주된 내용이라고 할 수 있는데 대부분의 내용이 Spring과 SpringRoo에 대한 설명이었고 제목을 보고 제가 기대했던 Google App Engine에 대한 내용은 다소 적었었습니다. 이 부분은 마지막 부분에 GAE와의 연동 시연을 준비하신 것 같았는데 시간조절의 실패로 연동 시연이 이루어지지 않아 더 그렇게 느껴졌을 수도 있습니다.

스프링 3.0을 활용한 RESTful 웹서비스 개발 - 백기선, 김성윤
제가 속해있는 봄싹의 세션으로 스프링 3.0에서 추가된 RESTful에 대한 세션이었습니다. 주로 라이브 코딩 및 코딩데모를 위주로 진행이 되었기 때문에 내용상 정리할 수 있는 부분은 많지 않아 간략하게 정리합니다.

요청 URL을 클래스등에 매핑시키는 @RequestMapping을 put, delete등의 메서드등을 받을 때 사용할 수 있으면 @PathVariable은 요청 URL의 아이디 같은 부분을 변수에 할당할 수 있습니다. 현재의 웹브라우저들에서는 대부분 Get/Post밖에 사용할 수 없기 때문에 스프링의 폼태그에서 method라는 이름의 히든필드에 PUT등의 원하는 메서드를 적어서 REST를 사용할 수 있습니다.

ContentsNegotiatingViewResolver
ViewResolver는 View를 찾아내는 역할을 하는데 미디어타입을 이용해서 어떤 뷰를 찾아야 할지를 결정하는 기능을 합니다. 이때 미디어 타입의 결정은
URL 확장자 -> format 파라미터 -> Access 헤더정보 -> defaultContentType
순으로 결정하게 됩니다. 뷰의 후보를 선정할때는 viewResolvers를 사용하지 않으면 서블릿 콘텍스트에 등록된 모든 ViewResolver을 사용해서 뷰 후보를 선정하고 ViewResolvers를 사용하면 모든 ViewResolvers가 돌려주는 뷰를 후보 목록에 추가합니다. 이때 defaultView속성을 설정한 뷰는 무조건 후보목록에 추가가 됩니다.

RestTemplate
RestTemplate는 Spring 3.0 M2에서 추가된 것으로 스프링의 Template 시리즈(JDBCTemplate, JmsTemplate 등)와 비슷한 형태를 가지고 있습니다. RESTful스타일의 URL을 지원하고 HTTP access를 단순화 해줍니다. 현재 베이직 인증만 지원하고 있고 OAuth인증은 Spring 3.1 M1에서 지원예정에 있는 상태입니다.

발표자료 링크

시연귀신이 유독 괴롭혔던 세션이었습니다. 대부분의 세션내용을 라이브코딩으로 준비하였는데 백기선님의 발표에서는 Java파일을 수정하여도 WAS의 재기동없이 적용할수 있게 하여 개발속도를 빠르게 할 수 있는 JRebel이 수시로 제대로 동작하지 않았으며 김성윤님의 발표에서는 심지어 IntelliJ가 얼어버리는 사태까지 발생한 관계로 진행자체가 깔끔하게 흘러가지는 않았지만 라이브코딩은 일반적인 발표와는 또다른 매력이 있기 때문에 전달해야 할 부분은 어느정도 전달되었던 듯 합니다. 깔끔히 시연이 되었다면 더 명확했겠지만 시연귀신은 어쩔수 없는 일이라고 생각하고 있습니다.(팔이 안으로 굽는 것일지도요 ㅡㅡ;;)

덧) 작년 이맘때만 해도 세미나는 항상 혼자 왔다갔다 했는데 언젠가부터는 세미나를 가면 아는 사람이 많아졌습니다. 이번에도 의도한 것은 아니지만 전 세션을 개인적으로 아시는 분들의 세션을 들었습니다. 개인적으로 알다보니 세션 주제에 관심이 가게 된 것인지 관심갖고 있는 주제의 사람들과 친분을 갖게 된것인지 명확하지는 않습니다. 이전에는 항상 3자의 입장이었던데 비해 요즘은 지인에 대한 후기를 쓰게되는 일이 최근에 많아지게 되어 후기를 적다보면 항상 100% 만족할 수는 없기 때문에 안좋은 얘기를 하는 부분에 대해서는 전에 비해 신경이 많이 쓰이는 것은 사실입니다.
좋은 말만 하는 것은 서로에게 그다지 도움되는 일도 아니고 평소에도 많이 배우고 있는 그분들은 그정도의 비판(?)은 충분히 받아들일 수 있는 분들이라고 생각하기 때문에 신경은 쓰이지만 왠만하면 느낀대로 쓰려고 하고 있습니다. 전 시크하거든요...

덧2) 나름 테크니컬 블로그를 지향하지만(수준을 떠나서) 요즘은 후기전문이 되어가는 것인가 하는 느낌이 없잖아 있기는 하지만 그렇다고 쓰던 후기를 안쓸수는 없으니 더 기술적인 부분에 대해서 노력해야겠습니다.

[EP]2010 한국 자바 개발자 페스티벌 #1..

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

지난 10일(토)에 JCO에서 주관하는 2010 한국 자바 개발자 페스티벌이 이화여대 ECC에서 개최되어서 갔다가 왔습니다.

운영의 아쉬움
JCO의 컨퍼런스는 작년 10회 컨퍼런스 [해당 포스팅은 옮겨오지 않았다.. 이유는 잘 모르겠넹;;] 때 처음 참가해 보았다가 올해는 언제하나 많이 기다려던 행사였지만 좀 짚고 넘어갈 건 짚고 넘어가야되겠습니다. 사실 저는 컨퍼런스나 세미나는 주목적이 세션을 들으러가는 것이기 때문에 괜히 거창하게 하는 행사에는 그다지 관심은 없는 편입니다. 하지만 이번 JCO의 행사는 운영이 좋다 나쁘다 말하기를 떠나서 운영자체가 없는 느낌이었습니다. ㅡㅡ;;

멋진 ECC에 도착해서 "오~ 좋다~"는 감탄을 했지만 어디서도 자바 개발자 페스티벌이 개최된다는 포스터등은 볼 수가 없었고 다같이 ECC를 미로처럼 돌아다닌 끝에 겨우 A4지에 "Track 2"라고 적혀져있는 것을 찾아냈습니다. 겨우겨우 물어서 제가 신청한 Track 4를 찾을 수 있었습니다. 각 세션이 이뤄지는 장소 앞에 책상만 하나 있었을 뿐 JCO 행사라는 표시는 전혀 붙어있지 않았고 특히 ECC라는 건물이 대칭적으로 내부는 다 비슷비슷하게 생겨서 처음가보는 사람은 원하는 장소를 찾기가 어려웠음에도 행사장에 대한 표시같은 것은 전혀 없었습니다. 저는 아는 사람들도 꽤 있어서 물어물어 트랙을 찾아다녔지만 혼자서 처음 오신 분들은 꽤 고생을 하셨지 않을까 합니다.(저만 헤메인건 아니겠죠? ㅡㅡ;;) 그럴만한 장소도 아니었지만 당연히 있을꺼라고 생각했던 출판사나 업체들의 부스도 없더군요.(이건 꼭 있어야 하는 것은 아니지만 없으니 행사자체가 너무 조용한 느낌이 있었습니다.)

멋지게 생겼던 이대 ECC

사전에 등록을 할때 트랙을 선택을 하기는 했지만 비공식적으로 그냥 수요도파악정도라는 얘기를 들었길래 이전에 참가해봤던 다른 컨퍼런스와 마찬가지로 당연시 시간별로 트랙을 옮겨다닐 생각을 하고 있었지만 막상 도착을 하니 각 트랙이 장소가 꽤나 떨어져 있었고 공식적으로는 트랙간의 이동을 허용하지 않는다는 얘기를 들었습니다. (운영상의 이슈인지는 모르겠지만 별도의 관리조차도 없는 상황에서 이건 상당히 무리한 요구라고 생각되었습니다. 어떻게 관심사가 한 트랙에 다 집중될수가 있을런지요.)

가서 분위기를 파악해 보니 전체 트랙을 다 맡지는 않더라도 각 트랙을 주도하는 커뮤니티들이 있었습니다.(제가 참가한 Track 4는 KSUG의 주도하고 있었습니다.) 트랙별 신청명단과 장소만 커뮤니티에 제공되고 해당 커뮤니티에서 알아서 운영하는 분위기였는데 명단에 이름만 있고 소속도 써있지 않은 관계로 동명이인의 경우 등록에 어려움도 있었고 등록한지 몇주 되었기 때문에 자신이 어느 트랙으로 신청했는지 정확히 기억해내지 못하는 사람들은 자신의 이름을 찾아 멀리떨어져있는 트랙 발표장들을 돌아다녀야 했습니다. 각 트랙은 그냥 각 커뮤니티가 운영을 하는 분위기였기 때문에 미처 알지못하고 커뮤니티에서 도와줄 사람들을 모집해오지 못하신 곳은 발표자분들이 등록데스크를 직접 지키고 계시더군요.(안타까움과 그분들의 헌신에 눈물이... ㅠㅠ)

올해 제가 속해있는 봄싹이 JCO에 합류하게 된 관계로 이름만 알고 있던 작년에 비해서는 JCO에 상황을 약간이나마 알고 있기는 했지만 JCO는 외부에 거의 드러나지 않는 조직(제가 느끼기에)인데다가 그래도 Java에서 JCO라는 이름의 위치가 있기에 기대하고 오신 분들에게 생각치 못했던 이런 운영은 좀 실망스럽지 않았을까 생각합니다.(시간표에는 폐회도 있었는데 그냥 4세션끝나면 그냥 집에가는거더군요.) 물론 이번 페스티벌을 위해서 TFT가 조직 된 것으로 알고 있고 다들 본업이 있으신 가운에 이런 규모의 행사를 준비하는 것이 보통일은 아닐 거라고 생각하고 있지만 이번 행사의 운영에 대한 부분은 여러가지로 아쉬움이 많이 남았습니다.

테스트가능한 소프트웨어 설계와 TDD작성패턴 - 채수원
Track 4의 1세션이면서 얼마전에 TDD 책을 출간하신 채수원님의 세션이었습니다. 책을 출간하신지 얼마 안되었기 때문에 발표는 TDD책에 포함된 내용의 프리뷰 혹은 축약적인 형태의 발표였고 전 얼마전에 책을 읽고 참가를 했기 때문에 복습하는 기분으로 가볍게 들었습니다.(책을 쓰면서 세션발표를 위해서 비기를 숨겨두진 않았을때니 이런 책의 축약형태의 발표는 당연한 부분이라고 생각하고 있습니다.)

토요일날 이렇게 세션을 듣기 위해서 이자리에 나와있는 이유는 "보다 더 나은 소프트웨어와 보다 더 나은 삶을 만들기 위해서..."입니다. 일반적으로 개발을 하면 먼저 언어를 공부하고 프레임워크를 공부한 뒤에는 컴퓨터 공학을 공부하면서 객체지향 원칙이나 디자인 패턴등을 공부하게 됩니다. 더 나은 소프트웨어를 만들기 위해서 이지만 이런 것들을 공부해도 잘 되지 않습니다. 간단한 예제 소스를 보고 의존성이 더 많이 들어있는지에 대한 여부는 파악하기 쉽지만 어렵고 복잡한 소스들에서는 쉽게 파악하기 어렵고 경력이 쌓여도 어디가 문제라도 바로 짚어내기 어렵습니다. 이런 것은 이론으로만 공부를 해서입니다.

이 간극을 가장 쉽게 해결할 수 있는 것이 경험상으로 TDD입니다. TDD는 TDD를 하는 것 자체가 목적이 아니라 더 나은 디자인을 하기 위해서 이며 TDD를 하면 쉽게 어디가 문제라는 것을 찾을 수 있게 됩니다.

안좋은 디자인의 징후

• 단위 테스트 케이스 작성이 어렵다.
• 단위 테스트 케이스가 자주 깨진다.
• 단위 테스트 케이스 실행을 위해 준비해야 할 것이 많다.
• 다른 사람의 테스트 케이스를 읽기가 어렵다.(코드를 읽기 어려운 것이 자신의 실력이 떨어져서인 경우는 많지 않습니다.)

프로그래밍 언어는 계속 발전을 하는데 이것은 인간을 위해서입니다.

기초 점검

• 프로그램을 작성하기 전에 테스트를 먼저 하라 (Test the program before you write it.)
• 잘 동작하는 깔끔한 코드 (Clean code that works) : TDD의 목표를 자동화된 테스트를 만드는 것으로 하는 경우도 많은데 TDD의 목표는 잘 동작하는 깔끔한 코드를 만드는 것입니다.
• 질문 -> 응답 -> 정제 -> 반복 (Ask -> Respond -> Refine -> Repeat)

기본 코스
생성자 메소드 테스트 (Constructor Method Test)
처음 TDD를 할 때 여러가지 걸리는 부분들이 있는데 생성자가 가장 먼저 걸리는 부분 중 하나입니다. 꼭 정답이 있는 것은 아니지만 일반적으로 생성자 테스트는 포함시키지 않고 생성자에 비즈니스 로직이 들어가 있을 경우에만 테스트를 합니다.

동치 비교
TDD는 자신이 원하는대로 동작을 하는가에 대한 테스트인데 인스턴스에 대해서 assertEquals로 비교할 경우 레퍼런스이기 때문에 일반적으로 실패를 하게 됩니다.
이에 대한 해결책은 아래의 방법들이 있습니다.

• 내부 상태를 꺼내와서 각각 비교
• toString을 오버라이드해서 비교(약간의 꼼수같은 느낌이 있습니다.)
• 객체에 equlas메서드를 구현(하지만 이것은 제대로 만들기가 어렵습니다. Effective Java에 보면 여러장에 걸쳐서 자세하게 설명하고 있을 정도지만 의도상은 이렇게 비교하는 것이 가장 적합합니다.)
• Unitils의 assertReflectionEquals를 이용

배열 비교

• JUnit 4의 assertArrayEquals를 이용
• Unitils의 assertReflectionEquals나 assertLenientEquals를 이용
• List로 변환해서 비교

몇가지 오해

• TDD와 UnitTest는 다르다. : UnitTest는 자동화에 대한 부분이고 TDD는 개발방법론입니다.(그렇다고 다른 사람이 같은 의미로 사용한다고 지적질(?)하는 것은 한번쯤 생각해 보고 하기를 권하셨습니다. ㅎ)
• (Do) All or Nothing : TDD를 하기로 하면 모든 것을 다 TDD로 하려고 하는데 그러지 않는 것이 좋습니다. 다 적용하지 말고 로직이 복잡하거나 만들기 어려운 것 위주로만 해도 충분합니다.

Skeleton vs Incremental
테스트 케이스마다 메서드 하나씩 만드는 것을 권장합니다. 스켈레톤은 테스트가 깨지지 않을 정도의 껍데기 클래스를 만드는 것으로 나쁜 방법은 아니지만 숙련자가 아니면 권하지 않는 방법이고 숙련자라고 하여도 간단한 부분에만 쓰는 것이 좋습니다.

One method one assert : 이렇게 만드는 것이 좋지만 실제로 하기는 약간 어렵습니다.

Anti-pattern
테스트를 만들 때 테스트 메서드 하나가 그 안에서 완결되고 시나리오가 되는 것이 좋습니다. setUp의 픽스쳐를 이용할 수도 있지만 문맥을 이해하기 어려우면 각 테스트안에 초기화부분이 포함되는 것이 좋을 수도 있습니다.

상태기반 vs 행위기반
결과값을 비교하는 것이 상대기반의 테스트이고 간단하게 읽히고 가장 많이 쓰이는 방법입니다. 행위기반은 결과값이 아닌 특정메서드가 호출되었는가를 확인하는 방법입니다.

항상 생각만 하고 있던 TDD인데 최근에 자극도 많이 되었고 개발에 적용할때 도움이 될 책도 나왔기에 올해는 좀 적극적으로 적용을 하고 수련을 해봐야겠습니다.(말로만 끝나지 않아야 할텐데요. ㅎ) 그동안 막연히만 알고 있고 좀 잘못알고 있던 내용들도 있는데 최근에 많이 정리가 되어서 좋군요.

[jQuery]jQuery CDN 속도 비교..

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

2년 정도 전에 Google에서 CDN을 통해서 배포하고 있는 Javascript 라이브러리들에 대해서 포스팅 한 적이 있었는데 요즘 많이 쓰이는 jQuery도 CDN을 통해서 배포되고 있습니다. 이렇게 CDN을 통해 배포되는 javascript 라이브러리를 사용할 때의 이점은 (회사에서는 좀 그렇지만)개인적인 프로젝트는 더 좋은 성능의 CDN을 통해서 JS파일을 내려줄 수 있게 되고 또 캐싱되어 있을 경우 빠르게 사용자가 이용할 수 있다는 장점이 있습니다.(다만 개발할때 오프라인에서는 개발을 못하겠죠. ㅎ)

jQuery 다운로드페이지에 보면 현재 jQuery는 Google, Microsoft, jQuery CDN(Edgecast)을 통해 배포되어 있는 것을 알 수 있습니다. 각각의 URL은 아래와 같습니다.

Google Ajax API CDN : http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js
jQuery CDN : http://code.jquery.com/jquery-1.4.2.min.js
Microsoft CDN : http://ajax.microsoft.com/ajax/jquery/jquery-1.4.2.min.js

3월에 pingdom에서 속도테스트의 결과가 올라왔었습니다.(생각만 하다가 이제야 포스팅을...) 이 테스트의 결과로는 유럽을 제외하고는 일반적으로 jQuery CDN(Edgecast)이 제일 빠르더라는 것이었는데 Asia쪽에서는 테스트도 이뤄지지 않은것 같고 또 국내와는 사정이 다를것도 같아서 테스트를 해보았습니다.

테스트는 3번 진행하였고 Fiddler를 이용해서 요청에 대한 시간으로 계산했으며 각 테스트당 10번씩 요청하여 평균값으로 계산하였습니다.(머 통계를 내기에는 적은 수치기는 하지만 그 이상 테스트 하기엔 좀 귀찮아서요.) 집 - 회사 - 집 이렇게 3번 진행하였는데 첫번재 테스트때는 네트워크 사정이 안좋았는지 전체적으로 수치가 높게 나타났습니다.

(통계적 수치라기 보다는 그냥 참고용으로만 봐주세요.) 전체적으로는 그래도 인프라가 좋은 Google이 가장 안정적으로 제공하고 있고 네트워크가 안좋을때 제외하고는 MS CDN도 좋은 성능을 보여주고 있습니다. 아시아쪽에는 CDN서버가 없는 것인지 Edgecast는 영 맥을 못추고 있습니다.

파일 용량

Google : 72,322 Bytes
Edgecast : 72,174 Bytes
Microsoft : 72,413 Bytes

압축된 jQuery파일이기 때문에 각 CDN별로 약간의 차이가 있기는 했지만 신경쓸만한 용량의 크기는 아닙니다. 원본소스가 같으니 당연한 결과이겠지만요.

Content-Type

Google : text/javascript; charset=UTF-8
Edgecast : application/x-javascript
Microsoft : application/x-javascript

Content-Type의 경우는 Edgecast와 Microsoft는 application/x-javascript를 사용하고 Google는 text/javascript에 캐릭터셋까지 지정하여 내려주고 있습니다. 표준(?)은 application/javascript지만 현실적으로 이걸 지원하고 있는 브라우저는 거의 없는 상황이고 text/javascript와 application/x-javascript를 사용하고 있는 상황입니다 둘의 차이는 그다지 없는것 같습니다.(Stackoverflow에서 논의된 내용을 참고해보셔도 좋을것 같습니다.)

Caching

Google : Caching public, max-age=31536000 expires: 2011 Jun 20
Edgecast : no caching
Microsoft : Caching public, max-age=31536000 expires: 2011 Mar 25

Google과 MS는 1년짜리 캐싱을 해주고 있습니다. 내용이 바뀔일도 없고 공통으로 사용할 수 있으므로 이왕이면 캐싱이 있는 것이 더 낫다고 생각되는군요.

[EP]HTML5 오픈컨퍼런스 #2..

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

HTML5 API 소개 - 경준호
네번째 세션은 HTML5의 Javascript API에 대한 세션으로 현재 같이 활동을 준비하고 있는 프론트앤드 개발자 커뮤니티인 FRENDS의 firejune님이 발표하시고 일부 데모를 AJ가 시연하기로 되어 있어서 가장 기대하고 있던 세션이었습니다.(다른 세션들의 주제보다 Javascript에 더 관심이 많기도 하고요.)

HTML5의 PPT를 HTML5로 만들어서 인기를 끌었던 것을 그대로 이용해서 발표를 해주셨습니다. (Dog Food 같은 느낌일까요? ㅎ) HTML5의 능력도 보여주면서 PT내에서 바로 Demo도 시연해 볼 수 장점이 있기 때문에 HTML5 발표에는 아주 효과적이라고 생각하고 있습니다. Audio와 Video는 기본적으로 컨트롤을 제공하고 있으며 Javascript를 이용해서 제어할 수 있지만 현재 코덱등의 지원여부가 브라우저마다 달라서 사용하는데는 아직 어려움이 있습니다.

Canvas의 핵심은 비트맵을 동적으로 Javascript를 이용해서 생성할 수 있다는 것입니다. Mr. doob사이트의 데모를 보여주면서 "웹개발자가 이런것까지 해야 싶기도 하다"고 하셔서 사람들의 웃음을 자아내셨습니다.(여러가지로 firejune님의 발표는 많이 유쾌한 발표였죠.) IE9 preview 3에서 Canvas를 지원하게 됨으로써 이제 모든 브라우저 벤드들이 Canvas를 지원하게 되었습니다. Canvas를 이용하면 인터렉티브한 UI를 만들어 낼 수 있고 리소스를 이용하는 것이 아니라 직접 만들어 낼 수 있다는 것이 특징입니다.(jsdo.it)

SVG(Scalable Vector Graphic)의 사용법은 HTML마크업과 유사한 방식으로 사용하고 벡터그래픽이기 때문에 확대를 하여도 깨지지 않습니다. (SVG JS라이브러리 Raphael) 기존에 이미지를 이용하던 것들을 직접 만들어 낼수 있으며 SVG가 없을때는 Canvas로 그래프등을 구현하였지만 사실 적절한 용도는 아니었습니다.

HTML5에서는 새로운 셀렉터들이 추가되었는데 오래 기다리던 클래스명으로 가져오는 getElementsByClassName가 드디어 Native로 추가되었으면 CSS셀렉터로 가져오는 querySelectorAll, querySelector도 Native화 되었습니다. Notification은 현재 크롬에서만 지원하고 있으며 Notification 창은 브라우저의 최상단에 표시가 됩니다.

Web Workers가 추가되여 부하가 심함 Javascript에 대한 처리를 빠르게 할 수 있으면 어쩔수 없이 무거웠던 Drag & Drop도 네이티브화 되어서 이전의 무거움은 사라져버렸습니다. File API를 이용하면 input file의 바이너리내용을 서버에 업로드하지 않은 상태에서도 파악할수 있기 때문에 파일에 대한 유효성체크를 쉽게 할 수 있고 파일내부의 id3나 exif같은 정보의 추출도 할수 있고 이미지의 일부만을 잘라서 업로드 하는 것도 가능해졌습니다. Web GL은 현재로써는 안전적인 버전의 브라우저에서는 제공하지 않고 개발중인 버전에서만 사용가능한 상태입니다.

Key-Value로 저장할 수 있는 Web Storage가 추가되었으며 Web SQL Database가 추가되어 웹브라우저가 Database를 보유하게 되었습니다. SQLite를 사용하고 있으며 항상 비동기적으로 처리하기 때문에 결과는 콜백으로 받아야 하고 공식명세로 잘 지원되고 있습니다. IndexedDB는 Web SQL Database보다 사용법이 훨씬 Javascript다우며(Web SQL Database는 SQL쿼리를 이용합니다.) 아직 개발버전으로 거의 지원이 안되고 있어서 파이어폭스의 개발버전에서 테스트해 볼 수 있습니다. Application Cache API는 로컬 스토리지등의 내용은 오프라인상태에서도 사용이 가능한데 이 데이터를 이용하기 위해서는 웹페이지의 Javascript나 이미지등이 필요하기 때문에 이 API를 이용해서 필요한 파일을 캐시하도록 지정할 수 있습니다.

Server-Send Event는 일종의 Push기술로 지속적으로 풀링을 하지 않고 이벤트를 받을 서버 주소를 작성하여 놓고 사용합니다. 헤더에 Conntent-type:text/event-stream를 지정해야하고 data에 값을 넣어서 클라이언트쪽에 전달합니다. 그리고 WebSocket과 Geolocation 기능이 추가되었습니다.

발표자료 보기

발표의 마지막은 AJ의 DICOM 시연으로 이어졌습니다.(지난번 FRENDS 첫 모임에서 이미 보았기 때문에 공개적으로 발표하는 부분에서 큰 기대감을 가지고 있었습니다.) DICOM이란 것은 저도 자세히는 모르지만 의학쪽에서 MRI를 신체의 단면을 몇미리단위로 촬영을 하게 되는데 이 수십,수백장의 사진들을 보면서 의사들이 병을 진단하게 됩니다. 이 시스템을 순수 웹기술만으로 구현한 것입니다.

제가 아는 범위 내에서는 node.js를 이용해서 서버에서 이미지를 바이너리로 전달하고(아마도 Web Socket) Web Worker가 3개가 돌아가면서 이 바이너리들을 이미지로 처리해서 보여주는 것으로 알고 있는데 그 크기와 복잡함에 비해서 이미지가 전환되는 자연스러움은 가히 입이 딱 벌어질 만한 충격적이라고 생각합니다. 컨퍼런스에 오신 분들의 반응은 정확히 모르겠지만 개발자가 아니신 분도 상당수있는 것으로 보였고 시간 관계상 자세한 설명까지는 되지 못해서 얼마나 전달이 되었는지 모르겠습니다.(더 자세한 내용은 Ajaxian.kr을 참고하세요.)


HTML5 기반 모바일 웹 - 권정혁
모바일에서 웹이 중요한 이유는 구글조차도 모든 플랫폼에 대한 모바일 앱을 만들 돈을 없다고 할정도로 플랫폼별 앱을 만드는 것은 어려우며 모바일웹은 간단히 모든 플랫폼을 지원할 수 있기 때문입니다.

모바일 웹 앱의 장점은 다양한 플랫폼을 동시에 지원이 가능하고 서버기반의 앱이기 때문에 신속한 업그래이드를 할 수 있으며 웹개발자들에게 친숙한 환경이라는 것입니다. 현재 Camera와 Device등에 대한 지원은 준비중에 있습니다.

Gmail 사이트를 보면 로컬저장을 사용하고 있으며 단하나의 HTML파일만을 사용하고 있어서 CSS, Javascript파일도 HTML내에 임베디드되어 있고 이미지조차도 base인코딩으로 처리해놓아서 단한번의 Request만으로도 페이지를 로딩할 수 있다는 것이 인상적입니다.

모바일웹앱을 위한 라이브러리로 WebApp, jQTouch, Sencha Touch등이 있으면 Apple에서 제공하고 있는 iAD JS도 있습니다. 발표에 대한 내용은 발표자인 xguru님께서 아래 링크에서 잘 정리해 주셨습니다.

발표자료


한국형 웹 콘텐츠 접근성 지침 2.0 - 현준호
사실 이 세션은 저한테는 큰 관심을 끌지 못했었습니다. 웹 접근성이 중요하지 않다는 것이 아니라 발표전에는 공무원이 와서 발표하는 것으로 생각되었기 때문입니다.(과거 공공 SI에 있었던 선입견으로 인하여 현실에는 말도 안되는 탁상공론만 하겠구나 하는 생각이었습니다.) 하지만 이 분은 공무원도 아니었고 내용자체가 상당히 충실하고 알찼습니다.(접근성은 중요한 내용인데 잘 몰라서 적용하기가 쉽지 않은 부분이죠.)  요약하기가 쉽지 않은 내용이므로 발표자료로 대신하겠습니다.

발표자료


Eplilogue
저는 10만원씩 하면서 거창한 타이틀을 달고 있는 세미나등은 잘 가지 않습니다. 가본적은 있는데 보통 무료 혹은 저가 세미나보다 못한 경우도 허다했으며 두리뭉실한 얘기나 하는 경우가 많았기 때문입니다. 이 세미나는 10,000원짜리 세미나인데 이정도면 유료라는 느낌보다는 참가에 대한 책임감 정도로 생각하고 있습니다. 발표자들도 나름 초호화로 생각되었기 때문에 기대감을 가지고 참가했는데 아주 만족스러운 발표였다고 생각합니다.

사전에 발표자들이 준비한 책자를 준다고 해서 사실 일반적으로 하는 발표자료를 인쇄해주는 정도로 생각했습니다만 발표자료 외에 발표자들이 자신이 맡은 주제들에 대해서 따로 내용을 정리한 부분을 책으로 만들어서 나누어주었습니다. 책 내용을 다 보진 않았지만 상당히 알차서 HTML5를 공부할 때 많은 도움이 될듯 합니다. 이 실전 HTML5 가이드는 참가한 사람들에게는 책으로 나누어 주고 참가못한 사람들에게는 PDF버전으로 무료로 공개해주는 아름다운 모습까지 보여주었습니다.

개인적으로 현재 HTML5는 써먹기 어려운 부분도 있고 브라우저의 지원여부에 대한 문제도 있기 때문에 앞으로도 갈길이 많기는 하지만 HTML5가 앞으로 보여줄 혁신은 언제고 간에 반드시 올 것이기 때문에 웹개발자라면 꼭 준비해야 하는 부분이라고 생각하고 있습니다. HTML5가 아이폰때문에 이슈화도 많이 된 관계로 HTML5에 대한 관심이 모바일 때문인 경우도 많고 이때문에 웹표준이라는 취지에 대한 오해를 갖는 모습도 보이기는 하지만 이전보다는 확실히 나은 위치에 있기 때문에 문제점들은 차차 해결해 나갈수 있으리라 기대하고 있습니다. 어차피 기술은 기술이고 중요한 것은 어떻게 어디에 사용하냐는 것이겠지요.

아무튼 보면 볼수록 흥미로운 HTML5 입니다. 올해 꼭 차근차근 준비해야겠네요. ㅎ

[EP]HTML5 오픈컨퍼런스 #1..

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

지난 2일 강남구 학동에 위치한 건설회관에서 한국 웹표준 프로젝트의 주최로 HTML5 오픈 컨퍼런스가 개최되었습니다. 10,000원 정도의 책임감정도의 적은 참가비를 받은 유료세미나였는데 650석 정도의 좌석이 24시간도 지나지 않아 마감될 정도로 HTML5에 대한 사람들의 관심정도를 알 수 있었습니다. 각 발표자들도 프론트앤드쪽에서는 이름대면 알만한 분들로 구성이 되어 주저없이 참가신청을 하고 갔다가 왔습니다.

HTML5 소개와 현황   윤석찬
첫 세션은 다음커뮤니케이션의 윤석찬님이 HTML5에 대한 전체적인 소개를 하는 세션이었습니다. 웹표준이 HTML5까지 어떻게 흘러왔고 HTML 5의 전체에 대한 프리뷰같은 시간이었습니다.

1995년부터 2000년까지 HTML 2.0부터 해서 HTML 4.01, XHTML 1.0이 만들어졌기 때문에 현재 쓰고 있는 웹표준들은 모두 10년 정도가 된 것입니다. 2000년부터 웹브라우저 전쟁과 웹2.0이 시작되고 2010년부터 HTML 5가 시작되었다고 합니다.(스펙정의가 시작되었다는 의미는 아닙니다.)

2005년에 오페라와 모질라와 사파리는 W3C와 의논을 하기 시작합니다. 이 당시에 W3C는 XHTML을 기반으로 한 마크업 문서화에 대해서 집중하고 있었고 브라우저벤더들은 기존의 잔재들을 없애는 데에 더 신경을 쓰고 있었기 때문에 둘의 의견이 맞지 않게 되어 웹브라우저벤드들을 주축으로 WHATWG(Web Hypertext Application Technology Working Group)를 만들면서 W3C와 갈라서게 됩니다. 이 당시에 세 브라우저 벤더들의 웹브라우저 점유율은 2%정도밖에 되지 않아서 영향력이 그리 높지 않았습니다.

이런 WHATWG의 활동으로 W3C의 팀 버너스 리는 2006년 Reinventihg HTML라는 글을 올리면서 HTML Working Group을 다시 만들고 각 브라우저벤더들도 이 워킹그룹에 참여하게 되었습니다. HTML 워킹그룹에 다른 사람들도 넣어달라는 요구를 W3C가 받아들여서 각 업체들의 추천으로 600명 정도의 개발자들이 HTML 표준 작업에 참여를 하게 됩니다.

자봉분들이 있고 있던 이 티셔츠 정말 탐났습니다. ㅠㅠ

HTML5는 개발자의 삽질을 줄이는데 상당히 중점이 되어있다고 합니다.(이부분은 boxersb님하고도 잠시 얘기했지만 HTML5에서 그런 영향은 있을지 몰라도 딱히 중심적인 내용인지는 잘 모르겠습니다. 일부분일 뿐이죠.)  HTML5 워킹그룹에서는 HTML5, Canvas 2D, Microdata, RDFa, AppCache등을 만들었고 Web Apps 워킹그룹에서는 Server-Sent Event, WebSocket, Web Storage, Web SQL Database, IndexedDB, Geolocation을 만들었습니다.

참고할 사이트로는 HTML5doctor (소개하실때는 http://kr.html5doctor.com/, 로 소개하셨는데 작업중인지 접속하면 인증창이 뜨더군요.) html5gallery, HTML5 TEST, Modernizr 등이 있습니다.

발표자료 보기

HTML5 마크업 - 신현석
두번째 세션은 HTML5 마크업에 관련한 주제로 Opera Software의 신현석님이 발표를 해주셨습니다.(신현석님이 오페라에 계신건 이날 처음 알았네요. ㅎㅎ)

내용을 떠나서 Javascript나 CSS에 비해서 마크업을 비쥬얼적인 요소가 아니므로(중요하지 않다는 얘기가 아닙니다.) 약간은 지루한 부분이 있기도 했습니다. 발표자체가 그랬다기보다 마크업이라는 것 자체가 약간 건조하고 공부하기에 지루한 면이 있는 주제이기는 합니다.

현재 HTML5는 아직 초안이기는 하지만 W3C에서는 이제 마무리 단계이기 때문에 대부분은 확정 상태라고 말하고 있습니다. HTML5 마크업은 현재 웹브라우저의 작동방식을 스펙화하였기 때문에 처음부터 하위호환성을 고려하여 만들어졌습니다.(이전에 추진되던 XHTML 2는 거의 호환성이 없었습니다.)  문법이 대폭 간소화되고 새로운 컨텐츠 모델이 추가되었습니다.

DOCTYPE이 외울수 없었던 이전의 DTD URL까지 적어줘야 했던 부분에서 <!DOCTYPE html> 으로 간소화되었고 Character Set에 대한 설정도 <meta charset="UTF-8">로 간단해 졌습니다. <style>, <script>태그에서도 항상 써주어야 했던 text/css, text/javascript가 디폴트로 설정되어 css와 javascript를 사용할 때는 굳이 type속성을 적어주지 않아도 되게 되었습니다.

구조를 나타내는 요소가 많이 개편이 되어 nav, article, aside, header, footer등의 요소가 추가되었으며 여기서 header와 footer는 섹션을 나눠주는 요소는 아닙니다. 이전에는 h1~h6의 태그가 순서대로 나와야 했는데(이건 처음 알았네요 ㅡ..ㅡ) HTML5에서는 자유롭게 사용이 가능합니다. 섹션태그가 생겼다고 해서 div 태그를 사용하지 말라는 것은 아니기 때문에 여전히 div태그를 사용할 수 있으며 기존의 div태그들을 굳이 섹션태그들로 바꾸어 주어야 할 필요가 업습니다. article 과 section 태그는 거의 동등관계기 때문에 적적한 용도를 판단하기 어려울수도 있고 또 서로 포함관계로 할 수도 있습니다.

새로운 의미를 갖는 요소들로는 명확한 시간을 나타내는 time태그, 의미는 없지만 다르게 보여주는 용도로 b태그등이 있습니다. 상호작용을 하는 요소로는 동적인 progress태그와 스태틱한 meter태그가 추가되었으며 datalist태그를 사용하여 셀렉트박스와 유사한 옵션그룹을 보여줄 수 있습니다. video태스의 소스에 코덱별로 2가지를 작성해 놓으면 브라우저가 알아서 사용자 PC이 있는 코덱을 재생하게 됩니다. 그리고 Canvas태그에서는 canvas가 없는 브라우저를 위해서 반드시(MUST) 대체컨텐츠를 제공해야 합니다.

발표자료 보기

발표후에 트위터를 통해서 신현석님께 질문을 드렸었습니다. 현재 HTML5의 Video가 PC의 코덱을 이용해서 플레이를 하고 있고(없으면 실행 안되죠) 신현석님의 발표에도 그렇게 얘기하셨는데 이렇게 동작하면 기존의 플러그인 방식과 무엇이 다른가였습니다. 신현석님의 답변으로는 이렇게 웹브라우저가 원하는 기능을 제대로 작동할 수 없을때 대체안으로 동작하는 기능을 폴백기능이라고 하는데(이미지 없을때 텍스트 보여주는것도 폴백기능) 현재 폴백기능으로 그렇게 동작하는 것이고 후에 HTML5가 제대로 지원되는 브라우저가 나오면 PC의 코덱설치여부에 상관없이 동작할 것이라고 합니다.


CSS 실전 예제 - 정찬명
세번째 세션은 NARADESIGN이라는 블로그를 운영하시는 정찬명님이 발표해 주셨고 발표자료도 HTML5와 CSS3이용한 웹페이지로 만들어서 발표해 주셨습니다. 현재 모두 CSS3의 지원을 기다리고 있는 상태인데 기다리고만 있을 수는 없습니다. 현재 IE 6,7,8은 CSS3를 지원하지 않고 있고 실제로 그런 날은 오지 않을 것입니다. 컨셉은 좋은 도구를 사용하는 사람들에게 더 향상된 경험을 제공한다는 것이고 경험의 질을 높이는 것이지 어떤 사용자를 포기하자는 것이 아닙니다. 그런 면에서 IE6을 지원하지 않는다고 하면서 자랑스럽게 내세우는 행동을 그리 옳은 행동은 아니라고 생각하고 이건 웹표준의 취지와는 어긋난다고 하셨습니다.(그래도 IE6은 버려야 된다고 생각하고 있지만 취지 자체는 동감하고 있습니다.)

CSS3를 사용할때 CSS에 대한 밸리데이션을 통과해야 하는가에 대한 질문들이 있는데 HTML 밸리데이션은 통과해야 한다고 생각하지만 CSS는 꼭 밸리데이션을 통과해야 하는 것은 아니라고 생각하고 있습니다. 이미 W3C의 사이트에서도 CSS3 속성들을 사용하고 있고 당연히 이는 CSS 밸리데이션은 통과하지 못합니다. 공식적인 표준은 아직 워킹 드래프트인 상태인데다가 CSS3는 사실상의 표준이 되었으므로 적용해도 문제가 없다고 생각한다고 하셨습니다. 현재 css3 속성에서 -o-, -moz-, -ms-, -webki- 등은 표준이 확정되기 전에 각 브라우저가 실험적인 지원을 할때 사용하는 것이고 차례대로 오페라, 모질라, IE, 웹킷에서 사용하는 것입니다.

현재 사용할 수 있는 CSS속성으로는 text-overflow는 Firefox빼고는 모두 지원하고 있으면 IE는 6부터 준비해놓았던 부분인데 여태까지는 서버사이드에서 글자수를 잘라주었지만 이젠 CSS로 박스크기에 따라 잘라줄 수 있습니다. word-wrap같은 경우는 IE가 지원하고 다른 브라우저가 모두 지원하기 시작했으면 opacity는 IE에서는 filter로 적용가능합니다. border-radius는 IE는 지원하지 않고 gradient는 현재 표준은 아니지만 오페라빼고는 모두 지원하고 있습니다. 그밖에 text-shadow, box-shadow등이 있습니다.

CSS3나 Canvas, Web Socket등과 같이 시각적 혹은 기술적으로 인상적인 부분에 대해서는 빠르게 지원되고 있지만 현재 HTML5 form에 대해서는 아쉽게도 지원이 미비한 편입니다.

발표자료 보기

[Hobby]나의 취미 온라인 게임..

오늘 새로운 카테고리를 추가했다.. 카테고리 명칭은 [Hobby] 대부분 아는 영어 단어 일것이다.. 

취미라는 카테고리고 추가하게 된 것은 내가 IT 쪽 일을 하긴 하지만, 그것만 관심이 있는 것도 아니고, 가끔은 내가 취미삼아 하는 것들을[현재는 게임과 헬스 정도] 기회가 된다면, 올리고 싶기도 해서 만들었다..

처음 올리게 된 것은 과거에 몇 번 언급했던 FIFA Online 3 게임이지만, 나중에는 헬스가 될 수도 있고, 등산이 될 수도 있고, 기타 다른 것이 될 수도 있다고 생각한다..

이 게임은 울산에 내려갔다가 동서, 처남과 같이 노는 와중에 PC 방에서 할 것이 없어서 찾던 중 우연하게 접하게 되었는데 생각보다 재미나서 서울에 와서도 계속 하게 되었다..

잘 모르고 시작해서 FC 바로셀로나를 첫 팀으로 했다.. [처음 ID 를 만들고 들어가면, 디폴트로 지정되어 있던 팀이었다..] 맨 첨에는 아무것도 모르도 시작하다가 지금은 어느정도 팀의 특성도 알고 팀을 어떻게 꾸려야되는지도 알고 하게 되었다..

아는게 없다보니 웹 개발도 그렇지만 모르면 어떻게 하라..?? 열심히 검색해보면 된다.. ㅋㅋㅋ.. naver 누님에게 열심히 물어보면서 다른 유저들의 블로그도 보고 하면서 지금의 팀 구성 및 전술 등을 정하게 됬다..

아래 왼쪽이 지금 현재 내 팀 주전 및 교체 선수다.. 후보도 있는데 후보는 안보여주는군.. 오른쪽은 게임에서 제공하는 선수들에 대한 정보여서 나랑은 상관없고.. ㅎㅎ..

게임을 더 열정적으로 하는 친구들을 보니 실제 온라인에서 1 vs 1 로 경기하고 그러는데.. 나는 그정도 성의는 없어서 그냥 컴퓨터와 대결하고, 게임 내에서 제공하는 리그만 하고 있다.. 이벤트 하면 그런것도 참가하고 그러면서 조금씩 선수 바꾸고 하는 소소한 만족감이라고 해야될까.. 그래서 요새는 시간이 나면, 접속해서 즐기고 있다..

처음 팀을 선택하면 2015년 기준이어서 선수들 가치가 0원이었다.. 그래서 0원인 선수를 방출하면서 선수도 뽑고, 트레이드도 하고 해서 지금의 선수 구성을 한건데.. 어제 메시와 수아레스를 이적시켜왔다..

비록 2015년은 아니고 메시는 14년, 수아레스는 10년 기준의 선수를 이적했지만, 써보니 상당히 좋았다.. ㅋㅋㅋ.. 앞으로 돈을 더 모아서 MF 와 DF 쪽도 괜찮은 선수를 이적시켜와야겠다..

그리고 내가 언제까지 이 게임을 할지 모르겠지만[실증을 금새 내는 스탈이기 때문에.. -_-;;] 하는 동안은 선수들을 Best Player[팀 배치를 보면 반짝 거려서 좀 이쁘다능.. +_+..] 로 좀 모으고, 그 다음에는 강화가 최소한 2 또는 3 이상[+1 강은 너무 평범하자나.. ㅋㅋ] 되는 선수들로 구성을 해봐야겠다..

[Book] 테스트 주도 개발 : 고품질 쾌속개발을 위한 TDD 실천법과 도구..

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

테스트 주도 개발 : 고품질 쾌속개발을 위한 TDD 실천법과 도구 - 채수원 지음 한빛미디어

TDD라는 말을 들으면 누구나 가장 먼저 떠오르는 사람은 창시자인 켄트 벡(Kent Beck)일 것이고 그 다음은 명저중의 하나인 TDDBE(Test Driven Development: By Example)라는 책일 것입니다. 물론 TDDBE에서는 TDD에 대한 소개부터 어떻게 TDD를 이용해서 개발을 하는지 예제와 함께 다양하게 설명해 주고 있기는 하지만 책을 읽고 TDD 해야겠다라는 생각이 들더라도 막상 실제 개발에 써먹으려면 어디서부터 어떻게 적용을 해야할지 막막한 것이 사실입니다.(저같은 경우가 그랬습니다. TDD의 사상은 공감하지만 정작 적용까지는 쉽지 않은...)

현재 국내에는 일부 테스트관련 툴에 대한 책이나 테스트 패턴관련 책들은 있지만 TDD에 대한 책은 TDDBE가 거의 유일한 상황에서 이 책은 가뭄속에 단비와 같은 책이 아닌가 생각합니다. 운좋게 이 책의 베타리더로 참여를 하게 되면서 미리 읽을 기회를 가질 수 있었는데 베타리팅때의 거친 느낌에 비해서 전체적으로 학습하기에 좋은 깔끔한 흐름으로 완성이 된 듯 합니다.

책의 내용은 TDD의 소개와 함께 간단한 예제를 통해서 어떻게 TDD로 어떻게 개발을 해야하는가에 대한 설명부터해서 TDD를 더 쉽게 적용하고 극대화할 수 있도록 하는 JUnit과 Matcher라이브러리 Hamcrest를 이용하는 방법들, 그리고 의존성을 없애고 테스트를 할 수 있는 Mock에 대한 설명 및 Mock 프레임워크들, 데이터베이스 테스트를 위한 DBUnit과 단위 테스트 라이브러리 Unitils까지 실무에 적용할 수 있는 아주 넒은 범위에 대해서 설명을 해 주고 있습니다. 또한 이번에 출시된 책된 책 답게 JUnit 3,4를 모두 설명해 주는 등 최신 버전의 라이브러리에 대해서 설명을 해주고 있기 때문에 바로 적용을 해보는데 큰 어려움이 없을 것으로 보입니다.

개인적인 생각으로는 이 책은 초중급정도를 타게팅으로 하고 있다고 생각합니다. 기본적으로 TDD에 대해서 전혀 모르는 사람도 적용할 수 있도록 자세하게 설명을 해주고 있으며 단순히 TDD에 대한 부분 뿐만 아니라 실제 개발에 적용할 때 도움이 될 수 있도록 이클립스를 기준으로한 상황별 어떤 기능 및 단축키를 이용하면 되는지까지 친절하게 알려주기 때문에 초급자라도 어렵지 않게 예제를 따라하면서 많은 것을 배울 수 있을듯 합니다. (사실 이클립스 사용법에 부분만으로도 이클립스가 익숙치 않은 사람들에게는 많은 도움이 되리라고 생각됩니다.)

너무 친절하게 설명하는 것은 자칫 초급을 벗어난 개발자들에게는 지루한 내용이 될수도 있는데 아무래도 TDD에 대한 관심을 갖게 되는 것이 약간 개발경험을 갖은 뒤인 경우많아서(처음부터 TDD로 습관이 들어있는 축복받으신 분이 아니라면) TDD자체가 약간 중급자를 위한 내용인데다가 책이 커버하고 있는 영역역이 꽤 넓기 때문에 친절하고 자세하게 설명하고 있는 부분에 대해서 초급자타게팅이라는 얘기를 한 것이지 책이 다루고 내용자체를 보면 중급(급을 나누는것 자체가 모호하긴 하지만요)개발자에게 더 적합하다고 생각합니다.

그리고 무엇보다 좋은 점은 단순히 라이브러리의 사용법과 TDD에 대한 가이드만 제공하는 것이 아니라 오랫동안 애자일 및 TDD에 힘써온 저자의 경험이 책에 그대로 묻어나있기 때문에 각 설명마다 장단점을 알려주고 현업에서의 문제점과 한계점에 대해서도 알려주고 있기 때문에 책을 읽으면서 여러가지로 생각해 볼만한 부분 많았다는 것입니다. TDD라는 것 자체가 방법을 알고난 뒤에라도 실제 적용까지는 어느 정도의 수련이 필요한 부분이고 각 상황마다 정답이라고 할 만한 방법은 없기 때문에 TDD와 리펙토링을 하는 방법에만 너무 집중하지 않고 현실적으로 스스로 고민해 볼만한 여러가지 화두들을 던져주어 생각해보게 하고 어느정도의 대안과 경험을 제시해 주는 것은 상당히 좋은 접근이라고 생각하고 있습니다.

문체는 약간 블로그스러운 편한 문체로 되어 있어서 호불호는 있겠지만 저는 오히려 읽기가 좀 편했던 것 같고 지면한계상 어쩔수 없었지만 뒷부분의 실습예제가 좀 더 자세하게 나왔었으면 하는 아쉬움은 있습니다만 TDD를 적용하고 싶은데 어떻게 해야할 지 감이 잘 안오는 개발자들에게는 충분한 도움이 되리라고 생각됩니다.

[Book] 시작하세요! 아이폰 3 프로그래밍..

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

시작하세요! 아이폰 3 프로그래밍 - 데이브 마크 외 지음, 이준호 외 옮김 이창신.정상일 특별부록 저자 위키북스

아이폰 프로그래밍을 공부하면서 처음으로 읽은 책입니다. 3기반으로 된 책이 많지 않고(올해 엄청 나게 나오긴 했네요.) 여러가지로 봤을때 괜찮아 보여서 골랐습니다만 이것저것 같이 진행하느라고 거의 2달을 읽었습니다.(다 읽고나니까 새버전이 출시되었군요. ㅋ)

다 읽고 난 느낌은 아주 초심자용 책은 아닙니다. 책이 어렵다라고 말하는 것은 아니지만(책은 친절합니다.) 타게팅이 무작정따라하기 식의 완전 초심자용보다는 약간 초중급자를 노린 것으로 생각됩니다. 이부분은 아마도 아이폰 개발을 하는 사람들이 개발을 아예 모르기 보다는 다른 언어개발은 알지만 아이폰의 Objective-C는 처음 해보는 사람들이 많기 때문에 그런 점을 고려한 부분이라고 생각되고 저는 이 부분이 더 좋다고 생각하고 있습니다.(무작정따라하기 식은 다보고 나면 다시 볼일이 별로 없어서...)

제가 이렇게 생각하는 이유는 이 책의 나오는 예제들은 모두 Windows-Based Application 템플릿을 이용해서 프로젝트를 생성합니다. xcode에서는 각 상황에 맞는 여러가지 탬플릿등을 제공하고 있지만 목적에 맞는 Navigation Based나 Tab bar application 템플릿을 사용하지 않고 모두 윈도우베이스드로 만들어서 소스를 수정해서 네비게이션과 탭바를 만드는 식으로 진행이 됩니다. 이 부분은 초반에는 접근하기가 약간 어려울수도 있기는 하지만 결과적으로 로우레벨(이걸 로우레벨이라고 하긴 어렵지만)을 이해하는 것은 꽤 중요하기 때문에 자동생성되는 코드대신 이 접근방식은 iPhone개발을 이해하는데 큰 도움이 될 것이라고 생각합니다.(그렇다고 제가 이해했다는 것은 아닙니다.)

C나 C++은 거의 안해본 저로써는 특히 코드 컨벤션이 다른 랭귀지들과 상당히 다른 Objective-C의 코드 컨벤션을 읽는것조차 익숙해 지는것이 쉽지 않았는데 아이폰의 여러 소스코드들이나 책들을 보면 코드를 작성하는 스타일이 약간씩 다름에도 불구하고 이 책에서 나오는 소스코드들은 상당히 Apple이 제공하고 있는 예제코드들의 기반을 하고 있고 코드 컨벤션도 거의 모두 따라하고 있기 때문에 Objective-C의 초기 코딩습관을 익히는데 도움이 된다고 생각합니다.(각자 코딩하는 스타일이 있지만 각 언어의 다른 코드컨벤션들은 그럴만한 이유가 있어서 그렇기 때문에 언어가 바뀔때는 그쪽언어의 문화를 따라주는 것이 좋다고 생각하고 있습니다.)

또한 아이폰 개발의 기본기에 약간 치중을 하고 있다고 생각합니다. 기본적인 아이폰 개발의 구조적인 부분과 UI만들기, 멀티뷰, 탭바, 네이게이션 컨트롤러와 가장 많이 쓸만한 테이블뷰에만 책에 반 이상을 할애하고 있고 그 외에 부분은 셋팅 번들과 여러가지 데이터 저장 방법, 쿼츠와 OpenGL을 이용한 드로잉들을 찬찬히 소스코드와 함께 각 사용법들을 친절하게 설명해 주고 있기 때문에 이해하기가 쉽습니다. 그외 가속도 센터나 지코어 로케이션, 카메라 등에 대해서는 간단히 설명하고 있어서 전체적으로 봤을 때 아이폰 개발에 기본적이고 공통된 부분에 집중하고 미디어등의 부가적인 부분은 소개정도를 해주는 듯한 느낌입니다.(아이폰 개발이 워낙 범위가 넓은 느낌이라서 다 다루려다가 이도저도 안되는것 보다는 훨씬 좋은 접근인듯 합니다. 그외부분에 대해서 보려면 다른책이나 레퍼런스를 좀더 봐야겠죠.) 어째보면 중요하다고 할수도 있는 아이폰앱 배포에 대한 부분에 대해서는 거의 설명이 없습니다.(배포하는 것도 꽤나 복잡하더군요.)

책이 출간후 출시된 아이폰 3.1버전에서 바뀐 점들에 대해서는 역자가 부록으로 제공하고 있기 때문에(양이 아주 많지는 않지만) 거의 3.1위주로(아직은...) 개발할 아이폰 개발에서 어떤 추가사항이 있는지를 아는 부록도 꽤나 유용하게 생각됩니다.

다른 아이폰책은 아직 안본 상태라 비교해 본 것은 아니지만(아이폰 개발 책은 요즘 워낙 많기도 하고요) 아주 초심자라면 더 쉬운책을 한번 보고 이 책을 보는 것도 나쁘진 않겠지만 일반적으로는 기본을 공부하기에는 꽤 충실한 책인듯 합니다.

My Comment..
해당 글은 아이폰 관련 서적이라 안갖고 올까 하다가.. 사람일은 모르는 것 아닌가 싶어서 우선은 가져와서 후기를 다 읽어보긴 했다.. 지금 회사에서 모바일 웹을 좀 다루기는 하지만, 어디까지나 모바일 기반으로 한 웹일 뿐 안드로이드나 iOS 같은 것을 토대로 하는 것은 아니다.. 햄처럼 방대하게 관심이 있는 것은 아니지만, 혹시 진짜 혹시나 해서.. ㅎㅎ..

[Book] Slack 슬랙..

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

Slack 슬랙 - 톰 드마르코 지음, 류한석.이병철.황재선 옮김 인사이트

제목만 봤을때는 어떤 내용인지 감이 잘 안왔던 책입니다.
Slack이라는 단어는 사전적 의미로는 "늘어진, 느슨한(loose)"등의 의미가 있습니다만(사전상으로는 positive한 의미만은 아니군요.) 책의 서두에 나오는대로 다중의미로 사용되어서 번역에도 슬랙이라는 단어를 그대로 사용합니다. 이 책에서 말하는 슬랙은 "일종의 여유"정도의 의미를 가지고 있다고 생각되며 IT환경에서 항상 초과근무를 하고 일정에 쫓겨서 여유로움이 없이 진행되는 업무 환경에 대해서 어떤 문제가 있는지에 대해서 얘기하고 있습니다.

사실 이 책은 10년정도 전에 지어진 책으로 10년이 지난 지금에야 번역서로 나온 것인데 이 책이 묘사하고 있는 10년전 해외의 IT환경이 지금 우리가 겪고 개발자라면 누구나 고민할 만한 문제들과 거의 흡사하다는 점에서 좀 아이러니하기도 합니다. 저로써는 제가 고민하고 있는 것을 보면서 얘기하는 것 같은 느낌이 들 정도였습니다.  계속되는 일정의 압박, 야근 및 초과근무의 강요, 비효율적인 프로세스, 자기개발의 기회의 부족, 리스크에 대한 부담 등 딱 보면 무슨 얘기인지 알만한 것들에 대해서 아주 잘 정리가 되어서 읽고 있으면 속이 풀리는 기분마저도 들었습니다.

책의 맨 처음에 이야기 하는 것은 효율성과 유연성에 대한 부분입니다. 오른쪽에 보이는 숫자퍼즐같은 경우 [더 이상 이미지가 보이지 않아서 취소 표시 해놨다.. 다만, 그 뒤 내용은 약간의 상상을 하면서 읽을 수 있기도 하고, 문맥상 있어야 된다고 판단이 되어 남겨둔다..] 16칸 중의 한칸이 비어있습니다. 이 한칸의 여유가 이책에서 말하는 슬랙인데 효율성을 높이기 위해서 남은 빈칸을 채워버리면 낭비하는 공간이 없어서 효율성은 아주 높아지겠지만 유연성은 떨어지게 된다는 것입니다.

회사에서는 직원들에게 바쁘게 일하기를 요구합니다. 이는 마치 높은 효율성을 가지는것 같지만 실제로는 그렇지 않는데 이는 우리가 협업을 하기 때문이라고 얘기합니다. 모두가 슬랙이 없이 바쁘게 일하게 됨으로써 슬랙이 있을때는 다른 사람으로부터 요청한 결과물을 바로 받아서 일할 수 있던 것이 모두가 바쁘게 되면서 다른 사람으로부터 어떤 작업결과를 받기까지 시간이 걸리게 됩니다. 더군다나 이런 문화에서는 바쁘지 않은 사람은 필요없는 사람이 되기 때문에 자신보다 선행작업을 하는 사람에게 업무가 많이 밀려서 자신에게 여유가 생기면 여유가 생겼다는 것을 윗사람에게 들키지 않기 위해서 적당히 느리게 일하게 됩다는 것입니다.(느리게 일한다는게 티나지 않을 만큼...)

더군다나 이런 분위기 속에서 사람들은 이용당한다는 기분을 느끼게 되고 이직이 많아지게 됩니다. 회사에서는 마치 직원의 교체에 비용이 들지 않는 것처럼 생각하지만 실제로는 많은 비용이 들게 됩니다.

그리고 IT는 지식노동이기 때문에 기본적으로 장기간 같은 생산성으로 일을 할 수가 없습니다. 빨리빨리의 문화가 직원들에게 공격적인 일정과 추가근무를 강요하게 되고 자신의 자리를 지키기 위해서 직원들은 무리한 일정이라고 하더라도 쉽게 안된다고 말을 할 수 없게됩니다. 일정의 실패는 일정을 계획한 사람이 책임져야함에도 일정을 수행한 사람한테 책임을 지는 경우가 허다하면 초과근무를 통해 품질의 저하, 개인의 탈진, 이직 증가, 정상근무시간의 낭비등이 발생하게 됩니다.

또한 이 책에서는 관리자가 단순 노동을 하는 것을 아주 큰 실수로 지적하고 있습니다. 팀에 업무가 많아지고 관리자가 팀원의 업무를 덜어주기 위해 단순작업을 직접 수행하는 경우가 많은데 이는 관리에 대한 조롱이며 관리가 어렵기 때문에 자신은 단순작업에 할당하여 정말 중요한 관리를 수행하지 않게 되는 것입니다. 이렇게 될경우 대부분의 프로젝트는 실패를 하게 됩니다.

회사는 모두 프로세스에 대한 강박증을 가지고 있다고 합니다. 물론 표준은 물론 좋은 것이고 이 프로세스 강박증은 테일러주의에 기반하고 있지만 지식근로는 공장근로와 달리 테일러주의가 전혀 필요없다고 말하고 있습니다. 지식근로는 고정적인 규칙이 없고 그 가치가 주관적이라 정략적 측정이 어렵기 때문입니다. 이는 품질검증에도 적용이 되는데 품질을 너무 중요시한 나머지 제품이 출시될 시기를 놓치는 사태까지 발생하고 있습니다. 때로는 품질보다 변화에 빠르게 대응하는 것이 좋을 때가 있습니다.

또하나의 문제는 MBO(목표관리)입니다. 회사들은 각 팀에 목표를 정하게 하고 그 목표를 위해서 움직이게 하고 있습니다만 이는 오히려 변화에 대응하기 어렵게 만들고 있으며 MBO의 기본 전제가 모든 일을 정확하게 측정해 낼수 있다는잘목된 믿음에 기인하고 있으며 각 팀의 목표향상이 전체의 향상으로 이어질 것이라는 가정인데 현실적으로 그렇지 않다고 합니다. 오히려 사람들은 목표만 채우기 위해서 일을 함으로써 오히려 효율이 떨어지는 역기능이 나타나고 있습니다.

내부경쟁에 대해서도 얘기하고 있는데(사실 전 이부분은 좀 긍정하고 있었습니다만) 경쟁은 무조건으로 좋다고 생각하며 각 직원에게 경쟁을 할 수 있는 구조를 만드려고 합니다. 하지만 이는 오히려 다른 사람의 성공은 나에게 마이너스라는 인식을 가지게 함으로써 기대한 효과보다는 오히려 마이너스가 되는 결과가 되어버립니다.

이 책을 읽으면 누구나 같은 생각을 할 것입니다. "내 위의 사람이 이 책을 읽었어야 하는데...." 저도 이 생각을 하면서 책을 읽고 있었는데 마치 마음을 읽듯이 이 부분에 대한 얘기가 나옵니다. 저자가 강연을 할때 강연이 끝나면 모두가 와서 자신의 상사가 꼭 들어야 하는 강연이었다고 해서 초기에는 타게팅이 잘못되었나 해서 강연 대상의 직급을 올렸다고 합니다. 하지만 아무리 직급을 올려도 동일하게 "상사가 이 강연을..."이라는 말을 했다는 것입니다. 슬랙이 얘기하는 것은 수동적인 애기가 아닙니다. 꼭 팀장이나 임원급만 변화를 만들어 내는 것이 아니라 그 어떤 위치에 누구나 변화를 만들어 낼 수 있다는 것입니다. 물론 그 변화는 쉬운 일은 아닙니다.

슬랙을 읽으며 인상적이었던 부분만 대충 정리해보았습니다. 직장생활을 하면서 먼가 효율적이지 않다. 라고 느끼던 대부분에 대해서 지적하고 왜 문제인지를 얘기해주고 있습니다.(저만 공감하는건 아니겠죠? ^^) 한편으로는 누군가 내 얘기를 들어주는 것 같아서 속시원하기도 하면서 그만큼 쉽지 않은 복합적인 문제이기에 많은 생각을 하게하는 책이었습니다. 무슨 책인지도 잘 모르면서 읽었는데 예상외의 수확이군요. ㅎㅎ

My Comment..
내가 그동안 햄의 글을 가져오던 것을 생각하면, 몇일만에 글을 가져왔다.. 그동안은 내 글도 좀 올리고 하다보니 그렇게 됬는데 이 부분 또한 뿌듯한 부분이다.. 매번은 아니더라도 가끔이라도 내 글을 올리느라고 햄의 글을 좀 늦게 갖고 오는 것은 좋은 현상이라고 생각을 한다..

그리고 이 책을 보면서 불연듯 생각이 난건데 보통 햄의 [Book] 카테고리 글을 가져오면, 기술서적이 많기 때문에 이 책에서는 이러한 것을 서술하는구나 하고 넘어가는편이 대부분이다.. 그런데 만약 위 글처럼 나 스스로도 후기를 보면서 생각하거나 판단할 수 있는 경우에는 공감이 되거나 반박을 할 수 있는 문장 뒷 부분에 [나의 생각 블라블라..] 이런식으로 적어볼까 한다..

무작정 가져오기만 하는 것보다는 나의 생각을 적으면서 그 글을 읽기만 하는것이 아니고, 비록 후기로만 책을 접하더라도 나 스스로 정리를 할 수 있는 기회라고 생각되기 때문이다..

[Talk]SPRING CAMP 2016..

블로그 통계 자료 올리고나서 어제 알게 된 정보를 바로 또 올려본다..

어제 친구와 카카오톡을 하다 알려주더란.. "너 스프링 캠프 갈래??" 이런 쓰읍.. 내가 멀 알아야지.. 왠 스프링 캠프..?? 라고 생각했는데 가만 생각을 하니 혹시 JAVA Spring 을 뜻하는건가 싶어서 Google 에서 찾아봤다.. 그랬더니 죄다 과거 정보만 나오긴 하는데 내가 생각한 그 Spring 이 맞긴 하더라 세미나였던 것이다.. 그래서 혹시나 싶어서 과거년도 url 을 가져다가 뒷 부분만 2016으로 바꿔봤다.. 그게 바로 http://www.springcamp.io/2016/ 요거란 말이지.. 들어가보니 정식 명칭대로 하면 SPRING CAMP 2016 였다..

들어가서 첫 페이지가 바로 아래 페이지다.. 그런데 보면 알겠지만, 신청은 4월 1일부터라는거.. 그래서 나도 달력에 표시 해뒀다능.. 실제 참관은 나온것처럼 4월 30일이다..

첫 페이지를 보고서 전체적으로 사이트를 살펴봤는데 ABOUT 은 해당 세미나의 목적 및 취지라고 해야될까..?? 간략한 소개와 TOPIC 이 간단히 적혀있다..

공개적으로 스피커를 모집하는게 스프링 캠프의 패턴이였나보다.. 난 처음 보는거라 머 알지도 못하공.. 지금은 스피커 모집 기간인듯 지원할 수 있는 페이지도 있더라.. 페이지 들어가봤는데 본인이 강의할 주제, 초급 과 중급 등 누구를 상대로 할 것인지 강의시간 등등의 정보를 적어서 제출하는 페이지였다.. 아마도 그 중에서 해당 세미나와 부합하는 사람을 선택하는 듯 하다..



커리큘럼 페이지도 있는데 아직은 스피커 모집 기간이고 해서 그런지 대략적인 패턴만 나와있다.. 아마도 4월 1일 이후에는 확정된 커리큘럼이 공지 될듯하다.. 그 때쯤해서 다시 봐야겠다..



과거년도 스케쥴을 보면, 오전 10시쯤 부터 오후 5시정도까지 하던데.. 올해에는 어떻게 할런지 궁금하넹.. 마지막으로 파트너 소개 및 위치 정보.. 광화문인데 지도상으로만 보면, 위치가 역에서 가까운게 아니고, 좀 애매하다.. ㅋㅋㅋ..



근데 아무리 비영리 단체라고는 해도 MS 와 파트너쉽을 갖고 있다는건 대단한 듯하다.. 그리고 내가 카테고리를 [Talk] 로 한 것은 세미나 후기도 아닐 뿐더러 내가 본 페이지를 소개하는 개념이기도 하고, 아직은 참관한게 아니자나.. 그래서 [EP] 로 올릴수가 없다..

무엇보다 4월 1일날 신청을 하면, 100% 참석이 가능한것도 아니다.. 나로써는 첫 세미나인데 꼭 뽑혀서 참석을 하고, [EP] 도 올릴 수 있었으면 좋겠다.. 아 그리고 친구가 말한건데 햄도 여기 참석한다고 하더라.. 원래는 연락을 해볼까하다가 혹시라도 햄한테 부담아닌 부담이 될 수도 있을거란 생각이 들어서 참석을 하게 되서 그 자리에서 보게되면 인사하고 하는게 더 좋을듯하다..

부디 참석할 수 있기를 바래본다.. +_+..

[Talk]처음으로 올려보는 내 블로그의 통계..

아침에 출근해서 항상 하던 것처럼 가습기에 물 갈아주고, 커피 뽑아오고, 따뜻한 물을 텀블러에 가득 담아오면, 어느덧 시간은 9시가 거의 다 되어간다..

그래도 아침에는 특별한 날 아니면, 여유가 좀 있다.. 바로 일을 하는것이 아니기 때문에 말이지.. ㅎㅎㅎ..

오늘은 여태껏 걍 나만 구경해온 Google Blog 의 통계를 올려보려고 한다.. 이게 머 특별한 의미가 있는건 아니고, 햄이 올린것을 종종 봤는데 나도 나름 블로그를 한지 2달이 다 되어가다보니 어느정도의 통계가 조금 쌓여서 봐줄만해서 기록삼아 올려본다.. 햄은 순위라도 있었지.. 난 그런것도 아니고 그냥 블로그 내에서 통계를 자체적으로 내주는듯 하다..

통계 개요라고 해서 첫 페이지에 나오는 건데.. 뷰, 게시물, 트래픽 소스, 독자 등 정보를 한눈에 보여준다..

게시물을 읽은 뷰를 보여주는 통계다.. 특별한 것은 없는 듯.. 어차피 내가 클릭해서 들어가도 카운팅이 되니 객관성이 있긴 한건가 의심스럽다.. ㅡㅡ.. 

참조 URL 이라고 하는데 내가 언제 저런 사이트들을 다 들어간거지 딱히 기억이 안난다.. 걍 참조 했다니까 그런가보다 해야지.. ㅋㅋㅋ..

마지막 정보인데.. 개인적으로 제일 신기하게 생각하는 정보라고 할 수 있다.. 왜냐믄.. 우선 국가별 페이지뷰.. 미국과 대한민국은 그렇다치고, 기타 나라들을 보면, 오잉..??? 하게 된다.. ㅋㅋ.. 글구 그 옆에는 브라우저 및 운영체제 별로 접근한 통계를 보여주는 듯 하다.. 구글 블로그이기도 하고, 외국에서 접속을 많이해서 그런지 몰라도 확실히 크롬이 많긴하다는 점..

이상..!! 현재 블로그 통계에서 보여주는 내용들인데 위에도 말했지만, 특별한 의미라기보단 신기해서 올려본다.. 앞으로는 획기적인 변화가 있는게 아니라면, 올릴일은 없지 않을까 싶다.. 크게 볼만한것도 없고 해서 말이지.. 아 근데..!!! 원래 이미지 업로드가 안됬는데 된다.. 정책이 바뀐건가.. 올릴 수 있을 때는 회사에서 이렇게 캡쳐해서 포스팅 하곤 해야것당..