Smart 한 생활이 아닌 똑똑한 사용자가 되는 지름길

현대 사회는 정보가 빠르게 생성되고 빠르게 유통되는 사회에 와 있으며 뿐만 아니라 빠르게 정보를 소비하는 사회이기도 하다.

불과 10년전만 하더라도 전자수첩이나 PDA를 가지고 다니는 사람은 스마트한 생활을 영위할 수 있는 몇 안되는 소비자이기도 했지만 PDA나 전자수첩은 그 자체로 정보를 쌓아놓을 수는 있었지만 정보의 백업이나 다른 사람들과의 정보 공유는 어려웠던 것이 사실이었다.

한 때는 이런 PDA 시장에서 Cellvic이라고 하는 국산화된 PDA도 있었지만 애플이 주도하다 싶이한 스마트폰이 나오기 전에 모두 잊혀져버렸다.

사실 지금의 스마트폰과 아이폰은 시대를 잘 잡은 제품들이다. 무엇보다 구글은 폭발적으로 증가하는 인터넷 사용자를 흡수하며 성장했고 애플은 인터넷을 기반으로 한 소프트웨어가 증가하는 시점에 시장에 나왔기 때문이다.

하지만 시대를 잘 잡았다고 해도 제품이 사용하기 어려울 정도로 불편하다면 결코 성장할 수 없었겠지만 그 역시도 사용자 경험을 중시한 스티브 잡스와 같은 사람들 덕분에 아이폰은 개인 사용자 시장에서 놀라울 정도로 성공을 거두었으며 구글은 애플이 주도하다싶이 한 시장에서 뿌리를 내리기 위해 클라우드 기반의 메일이나 문서도구, 캘린더, 주소록에 이르기까지 편리한 사용자 경험을 사용자에게 제시했다.

이처럼 애플과 구글이 시대를 잘 잡은만큼 구글 서비스와 아이폰과의 만남도 업무적으로 쓰기엔 편리하게 구성되어 있다.

한빛미디어의 "구글 + 아이폰 200% 업무 활용법"은 아이폰과 구글 서비스를 이용해 업무를 보다 편리하게 처리하기 위해 여러가지 앱과 사용방법을 소개한다.

총 8개 장으로 나누어 메일, 일정, 문서, 아이디어, 정보 수집, SNS 활용, 외근, 원격제어로 구분하여 아이폰을 활용하는 방법을 소개한다.

스마트워커..?

서론에서도 잠깐 PDA에 언급했었지만 PDA의 출현은 스마트워커의 시작을 알렸다. 하지만 최근의 스마트폰 대비 PDA는 선 입력 후 동기화의 형태를 지니고 있었기 때문에 외부에서 실시간의 데이터 확인은 어려웠었다. 그런데 일부 휴대폰 제조사가 휴대폰에 PDA OS를 설치하고 판매하면서 외부에서도 제한적이나마 업무를 볼 수 있게 되었다.

하지만 그 당시의 휴대전화에 PDA OS를 탑재한 형태의 휴대전화는 쓸만한 기능이라곤 주소록과 지하철 노선 확인과 음악 감상에 한정되어 있었다.

최근의 스마트폰에서는 인터넷이 실시간으로 연결되어 있어서 언제 어디서든 데스크탑 환경이 갖춰지기도 했다. 스마트폰을 가지고 다니기만 하면 스마트워커라는 존재가 될까? 애석하게도 그렇지는 않다. 스마트폰도 사용하고자 하는 목적에 맞는 앱과 앱의 사용방법을 알아야 한다.

당신은 스마트폰으로 무엇을 주로 합니까?

스마트폰을 구입하기는 했는데 스마트폰으로 할 수 있는 다양한 사례를 알지 못한다면 스마트폰은 값비싼 오락기기로 변신하기 마련이다. 독자가 스마트폰을 구입했다면 틀림없이 그것으로 하고자 했던 것이 있었을 것이다. 그 목적을 살려 업무에도 이용한다면 틀림없이 좋은 동반자가 될 것이다.

우리는 컴퓨터를 켰을때 가장 많이 활용하는 것이 메일과 일정관리 용도이다. 하지만 조금만 시각을 넓혀보면 PC와 스마트폰 양쪽에서 활용할 수 있는 것들이 다양하다.

스마트워커의 필수 도구 - 메일과 일정

메일은 스마트워커가 되기 위한 가장 전략적인 도구이면서 가장 불편한 도구 중 하나다. 어찌보면 사람과의 관계는 직접 얼굴을 대면하고 이야기하는게 가장 효과적이기 때문이다. 그럼에도 불구하고 메일은 기록을 남기거나 얼굴을 보고 대면하는게 어려울때 가장 효과적인 의사 소통 도구이기도 하다.

일정은 자신이 쓰는 시간을 아낌없이 쓸 수 있도록 도와주는 도구다. 저자는 메일과 일정을 관리하기 위해서 아이폰에서 사용 가능한 서비스 뿐만 아니라 PC에서도 함께 사용가능한 도구들을 함께 소개하여 언제 어디서나 업무를 볼 수 있는 환경을 제안한다.

스마트워커의 두번째 무기 - 문서관리, 아이디어 관리, 정보수집

업무상 외부에 자주 나갈 수 밖에 없는 직장인은 노트북을 들고 다니기도 하면서 업무를 본다. 하지만 정작 고객을 만나서 자료를 보면서 말을 해야 하는데 자료를 프린트하고 회사에 두고 왔거나 집에서도 업무를 봐야 하는 경우 어떻게 대처해야 할까?

몇년전에 이와 같은 이슈는 PC 원격제어 기술로 해결할 수 있는 것으로 포장되어 마케팅되었다. 지금은 이와 같은 이슈는 클라우드 도구 중에 문서 작성은 구글의 문서도구, 네이버 오피스나 스마트폰이나 스마트 패드에서 사용할 수 있는 프로그램들이 그 자리를 대체해 가고 있는 중이다.

뿐만 아니라 자료를 외부사람에 공개해야 할 경우는 드롭박스나 다음 클라우드, 네이버의  N-Drive 등에 올려서 공개하는 것도 가능해졌다.

클라우드 도구들은 언제 어디서나 사용이 가능하지만 전사적으로 사용할 수 없는 이유와 환경도 분명히 존재한다. 가장 대표적으론 최근에 불고있는 정보보안 바람은 이런 클라우드 도구의 사용을 가로막는 대표적인 장애물에 속한다(물론 이와 같은 흐름이 나쁜것만은 아니다).

클라우드 도구는 여러 단점과 장점들을 보완하여 사용하면 직장인에게 날개를 달아줄 것이다.

한편, 아이디어는 예전부터 시도때도 없이 생각난다고 해서 이러한 아이디어 보관 창고로 많은 사람들은 수첩과 펜을 들고 다니는 것을 제안하기도 했고 아이디어는 잠자리에서 가장 많이 생각난다고 해서 머리맡에 종이와 펜을 두는 사람도 많았다.

하지만 수첩과 펜을 목걸이 삼아서 들고 다니는 사람은 많지 않고 머리맡에 종이와 펜을 두는 사람도 많지 않을 것이다.

그렇다면? 최근엔 스마트폰 사용자가 많아졌다. 정보기기 사용에 능숙하지 못한 분들이야 어쩌지 못하더라도 이제 중학교 2학년인 외사촌 동생마저도 스마트폰을 들고 다니는 것을 보노라면 스마트폰이 아이디어 관리에도 사용될 수 있지 않을까 하는 생각이 든다.

저자는 아이디어 관리 도구로 마인드맵과 에버노트를 추천한다. 물론 2개 모두 만만한 도구는 아니지만 익숙해지면 아이디어를 언제 어디서든 엮어 나갈 수 있는 좋은 도구가 될 것이라고 믿는다.

직장인들은 대부분의 정보를 어디에서 얻을까? 내 경우 언론 사이트나 포털 사이트를 통해 들어오는 뉴스나 구글 검색을 통해 정보를 가장 많이 얻는다. 최근엔 사용자가 능동적으로 정보를 수집하지 않아도 원활하게 많은 정보를 수집할 수 있는 방법이 제시되고 있다. 저자는 정보를 수집하는 방법으로 RSS와 구글의 알리미 서비스 등을 제안한다. 저자가 제안한 RSS는 비교적 많은 사이트에서 제공하고 있는 최신의 정보 맛배기를 제공한다.

그래서 RSS로는 전체 정보를 얻을 수 없는데 이것은 해당 정보 제공 사이트의 조회율을 높이기 위한 수단으로 볼 수 있다. 따라서 최신의 소식을 빠르게 훑어보는 용도로는 RSS는 무척 뛰어난 기능을 제공한다.

구글 알리미나 저자가 소개한 딩동뉴스는 독자가 설정한 부류에 해당하는 정보들을 서버에서 수집되면 스마트폰의 푸시 서비스를 이용해 보내주거나 이메일로 보내주는 서비스를 제공한다.

이런 서비스를 독자의 입맛에 맞게 사용한다면 많은 비용을 들이지 않고 정보가 손안에 들어올 것이다.

한가지 주의해야 할점은 정보가 수집되더라도 정보의 수집과 활용은 전혀 다르기 때문에 클라우드 도구와 아이디어 도구로 수집한 것을 분류하는 활동은 필요하다는 점이다.

더 넓은 세상에서 나를 드러내기 - SNS와 위치 정보 사용하기 그리고 테더링

스마트폰으로 할 수 있는 일은 앞서 제시된 것뿐만 아니라 많은 사람들과 만날 수 있는 방법도 있다. 많은 사람들과 만날 수 있는 대표적인 방법은 SNS을 사용하는 방법인데 SNS는 개인의 생활을 노출하는 개방적인 공간이므로 지극히 사적이지 않다면 많은 사람들과 관계를 맺을 수 있는 공간이라고 저자는 이야기한다.

내 생각도 이와 다르지 않다. 하지만 SNS의 두 축이라고 말할 수 있는 페이스북과 트위터는 그 성격이 매우 다르므로 사용에 주의해야 한다. 그렇지만 많은 사람들과 함께 정보를 교류하고 의견을 모아가고 하는 것은 예전에 메일링 리스트로만 할 수 없었던 일들이 가능하므로 틀림없이 좋은 도구가 될 것이라고 조심스레 생각해본다.

PC는 보통 특정적인 공간에서 사용되어지고 있고 무엇보다 이동중에 사용할 수 없으므로 노트북 또한 가볍고 얇은 것이 선호되어지곤 했다. 스마트패드의 등장으로 PC 시장에서도 이와 유사한 기기가 발표되어지고 있는데 최근엔 LG전자가 출시한 탭북이란 것이 PC와 스마트 패드의 공간을 아찔하게 타고 있는 기기 중에 하나다.

스마트패드를 포함한 스마트 기기는 이동하면서 쓸 수 있고 내가 지금 어디에 있고 어디로 가야할지를 알아야 할때 사용할 수 있는 다양한 앱과 서비스가 존재한다. 저자는 이럴때 사용할 수 있도록 서울버스와 하철이, 구글 맵등을 소개한다. 아쉽게도 본 도서가 2012년에 출간된 도서라서 현재와는 달리 권장되는 앱이 다르기도 하지만 충분히 이런 점을 커버할 수 있으리라 생각한다.

번외적인 이야기지만, 개인의 위치 정보를 사용한 커뮤니티 서비스로는 한국에선 아임IN, 미국에서는 Foursquare와 같은 서비스가 있다. 사실 나중에는 위치 정보를 이용한 커뮤니티에 있는 기능은 대부분이 페이스북나 트위터에도 부가기능으로 붙었지만 아직도 위치 정보를 이용해 이벤트를 열거나 혜택을 주기도 한다.

앞에서 잠시 원격제어에 관해 간단히 언급했었는데 스마트 기기가 PC로 할 수 있는 일을 대부분 지원하지만 PC만큼 완전하게 지원하지 않는 것도 사실이다. 이에 따라 저자는  Teamviewer 등의 서비스를 소개하며 언제 어디서나 PC가 인터넷에 접속할 수 있는 기능인 테더링 서비스를 함께 소개한다.

테더링은 스마트 기기에서 제공하는 인터넷 접속을 공유하는 기능을 달리 일컫는 말이다. 2000년대 중반에는 T Login과 같은 2G 모뎀을 별도로 PC에 꽂아 인터넷을 이용했었지만 요즘의 스마트 기기엔 핫스팟 또는 테더링 이란 이름으로 스마트 기기에서 인터넷 공유 기능을 제공하여 언제 어디서든 PC로도 인터넷을 할 수 있는 환경으로 발전되었다.

어쩌면...

어쩌면 우리는 이미 스마트폰을 사용하지 않더라도 스마트 시대에 접어들어서 살고 있었는지 모른다. 과거 지도 서비스를 제공했던 콩나물이나 Windows Mobile 또는 Palm등이 적용된 PDA를 쓰지 않았더라도 도시 생활 내 반경 500m 이내에는 시간제로 PC를 사용할 수 있었던 PC방이 있었던 감안한다면 이는 부인할 수 없는 사실일것이다.

"구글 + 아이폰 200% 업무 활용법"은 저자가 직접 경험하고 업무에 도움이 될만한 것을 가득 담았다. 물론 아이폰에 한정되어 설명되어있고 업무에 활용할 수 있는 다양한 것을 함께 설명함으로서 다소 책의 편집 방향과 다른 부분도 눈에 띄기도 하지만 저자의 경험과 함께 하나씩 업무에 적용하면 성과를 얻을 수 있는 방법도 분명 있을 것이다.

본 도서는 스마트 기기로 업무를 봐야 할 사람들이 아니라 아직은 스마트 기기가 업무로 쓰기에 낯선 사람에게 추천해주고 싶은 책이다. 나는 다 안다고? 세상에 가장 무서운게 이거다.

책을 본다고 해서 지식은 체화되지 않는다. 스마트 시대를 가장 잘 살아가는 방법은 스마트 기기를 잘 사용하는 것만은 분명 아닐 것이다. 이제 걸음마를 띈 스마트 시대에 동참하고 싶다면 지금 여기에서 시작하길 바란다.

리뷰 - 이것이 편집디자인이다

사회에 진출하고 나서 내가 가장 어려움을 겪었고 지금도 그리 실력이 좀처럼 늘지 않는 분야가 문서를 만드는 일이다.

사실 모든 직장인들이 이런 어려움을 겪었을 테고 게중에는 밤낮으로 제안서를 써대는 통에 문서 작성의 달인이 된 경우도 적잖아 있을것이다.
하지만 적어도 IT 분야에서 일하고 있는 내 경우는 일반 직장인들과 달리 문서 쓰는걸 참 게을리 했을 뿐만 아니라 쓰는 문서도 보고용이 아니라 앞으로 어떻게 해야 할지 정리하는 것에 집중되어 있었다.

"이것이 편집디자인이다"는 사실 일반적인 직장인군을 대상으로 한 책은 아니다. 편집 디자이너라는 직군을 가진 사람들에게 그 노하우를 일일이 코칭해주는 것이 그 목적인 책이다.

그래서 편집 디자이너도 아닌 내가 본 책에 대한 기대치와 어디까지 그 기대가 충족되었는지 살펴보려고 한다.

당신의 이름은..? 편집 디자이너 이십니까?

이 책이 편집 디자인에 관한 책인줄은 알았지만 편집 디자이너를 대상으로 했던 책인지는 꿈에도 생각하지 못했기에 디자이너라는 이름표 목차를 봤을 때 적잖게 당황했다. 그래도 독자가 편집 디자이너를 꿈꾸거나 진입할 예정이라면 이 장의 내용이 소중하게 다가올 것이다. 하지만 나는 여기서 느낀 바가 없다는 것! 결론부터 말하면 디자인에 대한 열정을 체크하는 곳에서는 0점을 매겨버렸다.


디자이너가 간직하고 내보이지 말아야 할 이야기

편집 디자이너는 자신의 디자인에 대해 말할 줄 알고 겸손해야 한다. 그러면서도 의뢰자를 만족시키는 일이 무엇보다 중요하다.

저자는 Chapter 2를 통해 10가지의 비밀노트를 슬며시 꺼내어 책상에 내어준다. 당신이 어떠한 기준에 있는 편집 디자이너이든 이 장을 통해 사악한 편집 디자이너로 가기 위한 지식을 배울 수 있을 것이다.


디자인, 스텝을 밟다. 우리 지르박이라도?

Chapter 3부터 내가 이 책을 리뷰 대상으로 고른 가장 큰 이유였다. 어떠한 일이든 순서가 있듯이 편집 디자인에도 의뢰자를 만족시키기 위한 일련의 절차가 존재한다.

Concept(이야기) -> Process(표현하다) -> Flow(리듬을 타다) -> Get the Gist(대상을 만나다)

이야기를 통해선 디자인이 어떤 이야기를 하고 싶은지를 결정한다. 굳이 편집 디자이너의 손을 거치지 않는 작품이 아니더라도 최소한 만드는 저작물이 어떠한 이야기를 하고 싶은지는 알아야 할테니까 말이다.

어떠한 이야기를 펼쳐내기로 생각했다면 이제 그것을 멋들어지게 만들어내어 독자를 유혹할 수 있도록 꾸며야 한다.  여기서 알게된 가장 큰 깨달음은 여백도 내용이다! 편집 디자인 물로서 끊임없이 독자를 이끌 수 있는 표현 방법을 써야 한다는 것이 Process에서 가장 주요하게 다뤄지고 있다

독자가 편집 디자인물을 보고 조용히 시선을 옮겨주어 모든 내용을 보아주면 고맙겠지만 어디 독자가 그런 사람들인가? 독자들은 청개구리가 많다. 혹시 필자도 아니냐고 묻는다면 강하게 부정하고 싶지 않다.

그래서 편집 디자인물에도 독자가 편하게 볼 수 있도록 리듬을 내어줄 필요가 있다. 음악에서 평이한 음이 계속된다면 지루하게 느껴지겠지만 강약을 조절한다거나 어느 한쪽을 적절히 내어주면 느낌이 다른 것처럼 편집 디자인물도 이와 같다.

이처럼 편집 디자인을 마쳤다면 이제 편집 디자인이 실제 대상을 만날 차례다. Step 04를 통해 다양한 편집 디자인 대상을 만나보자. 이 스텝을 통해 독자는 대상이 편집 디자인과 만났을 때 어떤 구성을 해야 할지 감!을 잡을 수 있을 것이다.


소품도 잘 활용하면 아름다울 美가 된다.

친구들 집이나 잘 꾸며진 모델 하우스 또는 온라인 쇼핑몰엔 해당 상품을 받쳐주는 여러가지 보조 기구를 볼 수 있다. 우리는 흔히 이것을 소품이라 한다.

편집 디자인에서도 작은 소품은 편집 디자인 결과물을 돋보이게 하기도 하고 독자의 이해를 돕기도 한다. 이 장을 통해 편집 디자인 뿐만 아니라 프레젠테이션 자료에서 충분히 응용 가능한 기법을 배울 수 있을 것이다.

선, 박스, 배경, 공간 구성, 트리밍(IT동네 이야기로 말하면 사진의 클리핑이라고 번역할 수 있지 않을까?), 그래프(언제까지 딱딱한 그래프만 쓰시겠어요?), 약도와 지도로 나누어 소품의 활용 방법과 장점, 단점을 설명한다.

8가지 Detail 소품을 응용하면 어디에 내놓아도 손색없는 좋은 작품이 나올것이다. 개인적으로도  소품 활용은 크게 생각치 못했던 내용이었기에 깜짝 놀랬던 부분이었고 가장 많이 배웠던 부분이 아닐까 자평하고 싶다. 그렇지만 소품 활용이 어디 그렇게 쉬운 문제일까..

한번은 온라인에서 본 어떤 라디오가 그렇게 맘에 들기에 구입하고 책상 위에 올려놓고 쓰던 중에 구입했던 라디오가 잘 구성된 소품으로 다른 상품 사진에 쓰인 것을 보고 책상을 보니... 그야말로 난.장.판


설명해줘도 잘 모르지만 도움이 되는 디자인 결과물 분석 결과 보기

편집 디자이너도 아닌 까막눈 직장인이 "이것이 편집디자인이다"를 정독했다고 해서 편집 디자인을 완벽히 이해할리... 없다.

아니 그럼 그렇지란 말이 절로 나올만큼이다. 하지만 편집 디자인에서 훔쳐올 수 있을 만큼은 배웠지만 여기서 지식 흡입을 그만하기엔 마지막 Chapter의 내용은 정말로 뜨끈뜨끈하다.

리플릿, 봉투, 레터지, 명함, 포스터와 책표지, 페이지물 편집 디자인과 표지 디자인에 대한 사례를 다룬 5가지 Project 이야기는 편집 디자인을 어떻게 했을 때 어떤 어려움이 있고 어떠한 것을 고민해보게 되는지 그런 문제들을 어떻게 잡아나가는지 이야기를 펼쳐낸다.


결론만 요약합시다.

"이것이 편집디자인이다"는 사실 온라인 편집 디자인 물에 사용하기에는 어렵다. 그러나 필자가 원했던 편집 디자인이란 관점(어떻게 하면 문서를 예쁘게 만들 수 있을까?)에선 소기의 성과를 이뤄냈다.

그렇지만 디자인에 대한 열정은 0 이다보니 책에서 설명한 모든 말과 단어가 익숙할리 없고 샘플을 보아도... 읽다보면 아 그렇구나 싶다가도 설명없는 샘플만 보면 하아~ 하고 한숨만 나왔던 것은 어쩌지 못했던 부분이 아닌가 싶다.

이 책을 읽어야 하는 독자층? 많은 분들이 본 도서에 대해 후한 평가를 내려주셨는데 그분들은 모두  디자이너라는 것!

그래서 편집 디자이너도 아닌 필자는 이 책을 편집 디자이너라면 초심을 잃어버렸다 싶을 때 봐야 하는 책으로 생각한다.

그럼에도 불구하고 Chapter 3, 4의 내용은 하루종일 멋들어진 문서를 만들어내야 하는 우리의 애달픈 직장인들에게 권하고 싶다.

참, 필자가 이 책을 읽고 싶었던 가장 큰 이유!!
  - "나는 나중에 도서 편집자가 될지도 몰라서 이 참에 읽어둬야 겠어!!"

정보를 쉽게 알아보도록 도와주는 D3

한 해가 지나가면 주식 시장에서는 많은 기업들이 실적 발표를 하는데 이 때 가장 많이 사용되는 발표 요소 중에는 시각적인 이해를 도와주는 그림과 그래프가 있다.

그림과 그래프는 시각적인 이해를 쉽게 도와주는데 그 목적이 있지만 웹에서는 이런 목적 조차도 달성되지 않았던 것이 사실이다. 웹의 태생이 정보 링크에 있다는 것을 감안한다면 웹에서의 이미지 표현이 그리 발전하지 않았던 것 또한 사실이다. 부분적으로나 서버 프로그램을 이용한 이미지 표현이 이루어지기는 했지만 브라우저 차원에서는 여전히 불가능했다. 이는 HTML의 최신 버전인 4.01을 보더라도 HTML 요소 중에는 img 태그 하나와 그나마 내용과 표현의 분리를 제창해온 덕에 발전한 CSS 3에서 작게나마 이미지 표현 방법이 발전했다.

한빛미디어에서 출간된 "웹 기반 데이터 비주얼라이제이션 D3"(ebook)은 HTML 5대에 이르러 웹에 자유롭게 그림을 그리기 위한 요소인 svg 요소를 사용하여 그림을 표현하는 자바스크립트 라이브러리인 d3에 대한 소개서이다.

HTML 5에서 화면에 바로 그림을 그릴 수 있는 요소로 잘 알려져 있는 것은 canvas 요소인데 canvas 요소와 더불어 웹 화면에 그림을 그릴 수 있는 요소가 바로 svg이다.

물론 svg와 canvas 요소는 그래픽 표현 방법에 있어서는 다르다. 보통 canvas와 svg는 비트맵 방식과 벡터 방식으로 부르기도 한다. 이는 canvas가 그림 등을 표현하는데 적합한 반면 svg는 로고 등을 표현하는데 적합하다.

D3는 svg를 그림을 그리는데 사용하는데 여기에는 canvas와 달리 svg의 개별 요소가 dom으로 관리할 수 있고 dom 조작을 통해 사용자와 인터랙션 할 수 있는 그래프를 만들 수 있기 때문이 아닐까 짐작된다. canvas도 이미지 조작이 가능하지만 점(point)을 기준으로 하는 동작 방식이어서 상대적으로 이미지 조작이 어렵다.

"웹 기반 데이터 비주얼라이제이션 D3"는 웹에 데이터를 표현하기 위해 샘플 데이터로 뉴욕 교통청의 데이터를 이용해 D3를 사용하는 방법을 안내한다. D3를 배우는데 이와 같은 샘플 데이터는 유용하게 사용된다.

D3는 사용방법에 있어 문법적 형태가 자바스크립트 라이브러리인 jQuery와 유사한 형태를 띄고 있어서 jQuery를 사용한다면 D3의 문법을 배우기가 그다지 어렵진 않다.

D3를 사용하기 위해 알아야 할 것들

D3가 웹에 데이터를 쉽게 표현하는데 도움을 주기는 하지만 그 사용 방법이 결코 쉽지만은 않다.  먼저 엔터 셀렉션 개념을 이해해야 한다. 엔터 셀렉션은 D3의 핵심 개념으로 웹 페이지 요소를 선택한 후 데이터 집합의 항목을 수정, 추가, 제거하는데 이용된다.

뉴욕 교통청에서 제공하는 지하철 상황 정보를 받아 그림을 그리게 되는데 이 때 데이터는 D3가 이용할 수 있는 json 객체로 먼저 생성되어 있어야 한다. 책에서는 이미 가공된 json 데이터를 처리하지만 아쉽게도 책 전반에서 뉴욕 교통청에서 제공하는 데이터를 json으로 가공하는 실질적인 데이터 구성방법이 나와있지 않다. 

그러나 엔터 셀렉션을 사용하기 위해선 json 데이터도 "미카의 황금률" 법칙을 따라야 하는데 D3에선 이 법칙이 지켜지지 않은 데이터가 들어올 경우 그래프를 표시할 수 없다.(6p 참고)

그래프의 단짝 요소인 축, 선 그리기

그래프에서 빠지지 않는 시각적 요소 중의 하나는 축과 선이다. 물론 여기에 더해서 축에 들어가는 레이블도 시각적 요소에 속한다.

그래프는 보통 통계 데이터를 나타내는데  시각화하는데 자주 사용되는데 이때 그래프에 표시되는 데이터의 상한 값과 하한 값을 구하여 그래프를 그려야 한다. 보통 이와 같은 값 종류을  스케일 값이라 하는데 스케일 값은 직접  산출하려면 아주 복잡할 수 있다.

책에서는 먼저 뉴욕 교통청에서 제공하는 버스 고장, 사고, 상해 데이터를 가지고 와서 D3에서 제공하는 스케일 값 산출 방법을 써서 스케일 값을 산출하고 여기에 축과 선을 그리는 D3 라이브러리의 메서드 사용 방법을 친절히 안내한다.

사용자와 상호 작용하는 그래프 만들기

보통 사용자는 그래프가 만들어졌다면 이를 조작해보고 싶어하기도 한다. 4장에서는 D3를 이용하여 그래프에 간단한 상호 작용(이후 interaction. 인터랙션이라고 표기)을 구현하고 나서 뉴욕 교통청이 제공하는 지하철 지연 정보를 이용해서 그래프에 툴팁과 지연시간을 이용한 진입 애니메이션을 구현하여 사용자 인터랙션을 경험해볼 수 있다.

4장에서 안내하는 것과 같이 D3를 이용하면 그래프에 쉽게 사용자 인터랙션을 구현하여 반응하는 웹 프로그램을 쉽게 만들어볼 수 있어 이후 사용자의 인터랙션이 필요할 때 적절한 구현 방법을 찾을 수 있을 것으로 기대된다.

다양한 그래프 그려보기

데이터를 표시하는데 사용하는 그래프는 그 종류가 다양하다. 통계 분포를 알아보기 위한 점 그래프와 변화를 추적하기 위한 선 그래프 외에도 다양한 데이터를 한 그래프에 보일 때 사용하는 스택 그래프(막대 그래프가 세로로 여러개로 구성되어 있는 막대 그래프를 생각해보면 이해가 쉽다) 등을 그려보기 위해서도 D3에서는 레이아웃 기능을 이용하여 쉽게 이 같은 그래프를 그릴 수 있도록 도와준다.

5장에서는 이와 같은 레이아웃이 적용된 그래프를 그리보며, 보다 쉽게 사용자 인터랙션 등을 추구하는데 있어서 자주 사용되는 포스 다이렉티드 알고리즘을 적용한 그래프와 히스토그램 레이아웃과 스택 레이아웃을 사용한 그래프를 소개하여 D3의 활용 영역을 보다 넓혀준다.

마지막으로...

"웹 기반 데이터 비주얼라이제이션 D3"는 웹 페이지에 쉽게 구현할 수 없었던 이미지 영역중에서 그래프나 통계 데이터를 보여주는데 특화되어 있는 D3 라이브러리를 소개하여 서버 영역에 부담을 덜 주며 반응성 높은 웹 애플리케이션을 쉽게 만들 수 있도록 하는데 그 의미를 둔 책으로 보인다.

하지만 도서가 번역서이다 보니 사용되는 샘플 데이터도 해외 데이터인 것은 아쉽게 보인다. 국내서였다면 괜찮은 데이터가 나오지 않았을까 싶기도 했고 한국에서 D3를 사용하려면 다양한 종류의 데이터 타입을 D3가 이용할 수 있는 JSON 데이터로 변환하는 방법을 부록으로 첨가 했더라면 하는 아쉬움이 진하게 남았다.(국내에서 자주 사용되는 자바 환경과 PHP, Python 환경을 이용해서)

개인적으로는 책에서 JSON 변환에 사용하는 파이썬 언어가 그렇게 맘에 들지 않을 수가 없었다. 그러고 보면 나 역시 특정 프로그램 언어에 대해선 팔불출이 아닐까 싶었다.

"웹 기반 데이터 비주얼라이제이션 D3"가 eBook이다 보니 한 가지 더 아쉬움이 남는건 D3의 다양한 사례를 실어주었더라면 학습자에게 도움이 더 되지 않았을까?

웹에서 데이터를 표현하는데 보다 적절한 방법을 찾고 있었거나 웹에서 재미있는 기능을 찾고자 했던 개발자라면 "웹 기반 데이터 비주얼라이제이션 D3"를 통해서 호기심 충족과 함께 효과적인 해결책을 찾아낼 수 있을 것이다.

좋아한다면 해야 한다. 프로그래머로 사는 법!

지구가 태양계에서 태동한 이후 인간이 발명한 최고의 발명품이 컴퓨터라면 컴퓨터를 인간이 쉽게 사용할 수 있도록 도구를 만드는 것 역시 인간이 수행한다. 우리는 이러한 직업을 프로그래머라고 부른다.

직업에 귀천이 없다지만 유독 한국에서는 컴퓨터 프로그래머는 3D 직종으로 분류되기도 한다. 아마 이렇게 된데에는 잦은 야근이 많은게 아닌가 생각된다.

하지만 프로그래머의 도움이 없이 컴퓨터는 아무런 일도 하지 않는다. 오직 깡통일 뿐이다.

잠깐만 우리는  TV를 바보상자라고 부르기도 한다. 그런데 컴퓨터가 깡통이라고? 쉽게 납득이 되지 않을수도 있다. 그러나 곰곰이 생각해보자. 운영체제가 설치되어 있지 않은 컴퓨터에 전원을 연결해서 전원 공급 버튼을 눌러도 컴퓨터는 아무것도 보여주지 않는다.

우리는 학교에 다니면서 혹은 직장에 다니면서 컴퓨터를 만지게 되고 컴퓨터를 이용해 공부하거나 업무를 보게 된다. 이렇게만 놓고 보면 컴퓨터는 인간의 삶을 윤택하게 해주는 도구이다. 그러나 우리가 이렇게 윤택한 삶을 만들어나가려면 컴퓨터에서 동작하는 프로그램 또한 필요하다.

지난 2011년 10월 세상을 떠난 애플의 최고경영자였던 스티브 잡스. 그가 스티브 워즈니악과 애플사를 공동 창립한 이후 잡스는 경영자로뿐만 아니라 프로그래머로도 꽤 이름을 알렸다. 공동 창립자였던 스티브 워즈니악도 같다.

이번에 한빛미디어에서 나온 "프로그래머로 사는 법"은 우리의 삶을 조금 더 윤택하게 만들어주는 프로그램을 만드는 사람들에 관한 이야기다. 착하기만 한 순둥이들이라고 생각하지만 실은 뒷 책임을 지기 싫어해 고객에게 단점을 누설하는 그런 프로그래머들 말이다(유영창님 기고문중에서)

프로그래머는 컴퓨터에서 동작하는 프로그램. 즉 소프트웨어를 개발하는 사람을 일컫는다. 소프트웨어 개발자로 살아가기 위해서 우리는 무엇에 집중해야 할까?

내가 프로그래머로 직업을 선택하게 된건 순전히 GW-Basic을 잘하는 친구들 때문이었다. 그 뒤 서점에 들렀을 때 어디서 좀 들어봤다고 베이직 책과 난생 처음 들어보는 C라는 단어에 꽂혀서 어린 마음에 터보C가 좋다더라.. 이런 얘기를 하고 다니긴 했다. 그러다 보니 컴퓨터 좀 안다하는 사람에겐 내가 얼마나 유치찬란해보였을까? 지금도 누군가는 날 그렇게 생각할지도 모른다.

프로그래머는 사람들의 머리속에 각인되어 있는 것처럼 컴퓨터에 광적이고 무인도에서도 컴퓨터만 주면 사시사철을 컴퓨터 앞에서 보낼 사람들이다. 프로그래머로서 살기 위해서는 무엇보다 성공의 욕심을 버려야 한다. 프로그래머로 성공한 사람들.(마리사 메이어, 스티브 워즈니악, 제임스 고슬링, 다이앤 그린 등)도 다 이와 같은 말을 한다.

"돈은 부수적이다"

돈을 벌고자 프로그래머란 직업을 선택했다면 그건 크게 잘못한 일일지도 모른다. 많은 경우 프로그래머는 열정을 바쳤던 부분에서 유명세를 타게 되어 돈을 벌게 된 경우가 더 많다.

우리 시대의 개발자 중 한 분은 "백창우"님도 기고문에서 이런 말을 한 부분이 있다. "J는 취향이 없다" 개발자에게 있어서 취향은 분명히 필요하면서도 필요하지 않은 부분인데, 독자와 필자, 그리고 나 조차도 무엇을 좋아하는지 취향은 다를 수 밖에 없다. 자신이 좋아하는 것과 싫어하는 것은 명확하다. 하지만 소프트웨어 개발자로 사는 이상 우리는 분명 취향을 가리지 않아야 한다.

흡사 언어를 배우는 아이들처럼 음식을 골고루 먹도록 말하시는 부모님들처럼 말이다.

그건 소프트웨어 개발자로 사는 이상 자신에 대한 예의라고 볼 수 있다. 독자가 루비 프로그래머라고 해서 파이썬이나 Eiffel을 알 필요가 없다는 게 아니다. 개발환경이 달라진다고 해서 투덜될 필요가 없다.

프로그래머는 책에서도 언급되지만 프로그래머로 사는 동안엔 끊임없이 학습해야 한다. 마치 시냇물이 흘러 바다로 나아가는 것처럼 말이다.

한편 소프트웨어 개발은 잔디깍이에도 비교되곤 하는데 그만큼 섬세한 작업을 하기도 한다로 받아들여주면 좋겠다. 프로그래머는 일본에서 회자되는 단어 중 오타쿠라는 단어에 가장 가깝게 해석될 지 모르겠다. 그러나 한국에선 이를 다음과 같이 부른다. 이런 "괴짜" 같으니라고

프로그래머는 창의성이 뛰어난 사람이 많다. 하루종일 컴퓨터와 붙어산다는 인상을 주는 직업이니만큼 프로그래머들은 대인관계가 엉망이거나(심지어 나조차도) 생각만 많은 그런 사람으로 분류되기 쉽다.

"프로그래머로 사는 법"에서는 프로그래머로 살기 위해서 중요한 점을 자신의 경험과 함께 풀어낸다.

햇병아리 프로그래머로부터 시작해서 전문가로의 여정에 함께 할 수 있는 수 많은 조언들이 이를 반증한다.

이 책을 읽는 동안 나는 스스로 프로그래머로서 어떤 부분에 안주했을까.. 새삼스럽게 많은 고민을 했다. 다른 한편 나는 프로그래머가 맞기는 한걸까.. 우연히 발견한 한 권의 도서에 내 삶 전부를 고민해보게 될 줄도 몰랐다.

프로그래머로 이제 막 발을 떼기 시작한 사람과 이미 어느정도 사회생활을 한 프로그래머와 전문가에 이르기까지 이 한 권의 도서가 프로그래머로서의 여정에 함께할 것으로 기대한다. 반드시 생각날때 책상위에 놓아두시길 바라며 이 서평을 마무리 짓는다.

늘 좋은 책을 많이 만들어주시는 한빛미디어 편집자 여러분 정말 감사합니다..

클라우드 실전 구축을 통한 Private Cloud 구축하기...

컴퓨팅 세계에서 가장 뜨거운 감자는 무엇일까? 사실 이 질문보다는 기업 전산팀에서 일반적으로 가장 뜨거운 화두는 무엇일까?

어느 기업이던지 24시간 무중단 시스템이 필요할 수 있다. 적어도 이런 단편적인 기능하에서 클라우드 시스템은 별 볼일 없을지도 모르지만 기업의 전산 자원을 효과적으로 활용할 수 있는 방법이 있다면 이는 분명 달콤한 제안일 것이다.

또는 데이터 연구자 입장에서도 대규모 컴퓨팅 자원을 활용하고자 할 때는 클라우드 만큼 매력적인 자원인 경우도 없지 않다.

동출판사의 자회사인 한빛비즈의 <클라우드 혁명>에서도 이와 같은 개념적인 사례를 드는 것은 쉽게 찾아볼 수 있다.

그러나 클라우드를 사용하는 것과 구축하는 것은 분명 천지차다. <가상화 구축 기술>은 클라우드를 이용하는 것이 아니라 클라우드를 구축하는 방법에 대해서 다룬 책이다.

처음 책을 받아볼 때와 달리 책을 덮을 때쯤엔 그저 클라우드 구축으로 안내하는 입문서로밖에 생각이 안되게 되어 실망스러웠지만, 적어도 이 책은 국내에서 컴퓨팅 자원으로서의 클라우드 구축에 대해 다룬 국내서로는 첫번째 책이 아닐까 싶다.

무엇보다 이 책의 장점은 다음과 같지 않을까 생각된다.

1. 단어만 무성한 클라우드 구축에서의 개략적인 소개
2. 깊게는 아니더라도 클라우드 구축을 따라하기 식으로 소개
3. Private Cloud 구축의 시작

하지만 장점이 있는 책이라고 해서 단점이 없다면 그것도 좀 말이 안된다.

1. 깊이 있는 설명보단 개략적인 설명에만 그친 점
2. 구축과 관리를 모두 담으려다 실패한 중간 설명
3. 컴퓨팅 서비스만 다룬 점

클라우드가 분명 최근에 떠오르고 있는 뜨거운 감자인 것은 틀림없는 사실이지만 <가상화 구축 기술>만으로 클라우드의 범주에 묶이는 기술들을 설명해내지 못하는 것처럼, 보다 작은 독자 타겟이 필요하지 않을까 싶다.

아쉬운 것이야 아쉽다고 해도 <가상화 구축 기술>이 가지는 독보적인 상징성만 놓고 보면 틀림없는 최고의 책이다.

적어도 리눅스든 윈도우든 가상화 구축을 맛보는 것만큼은 조용히 따라가본다면 의외의 수확을 얻을 수 있겠다.

참, <가상화 구축 기술>은 리눅스에서의 가상화 구축기술을 주로 설명하기 때문에 리눅스와 조금은 "친구하자~" 해야 될 필요가 있다. 이렇게 첨언을 하는데엔 QEMU를 제외하곤 모두 윈도우에서는 테스트 할 수 없기 때문이다.

클라우드를 통한 전산 자원의 효과적인 활용은 이제 시작이다.  클라우드 구축을 염두에 둔 기업 담당자나 연구자에게 클라우드 구축의 시작으로서 <가상화 구축 기술>을 추천한다.

물감의 캔버스? 아니 브라우저의 캔버스!

HTML 5는 웹 페이지를 표현하는데 있어서 HTML 4에 비해서 눈부신 발전을 한 마크 업 언어입니다. HTML 5에 앞서서는 웹의 미래는 Semantic 웹이란 개념이 대두되면서 XML로 기술된 XHTML 2가 있었습니다.

그러나 XHTML 2는 웹 브라우저 제작 회사들의 지지를 받지 못하게 되었고 HTML 5는 HTML 4에 비해 프로그래머에게 보다 친숙하게 설계되었습니다. 그러면서도 웹 페이지 사용자에게도 다양한 사용자 경험을 제공하게 되었습니다.

이러한 사용자 경험의 확대엔 HTML 5의 신기술 중 Canvas가 자리잡고 있습니다. Canvas는 웹 페이지에서 바로 그림을 그리고 표현할 수 있는 기술입니다.

<HTML 5 Canvas>는 HTML 5의 Canvas로 할 수 있는 모든 기술은 아닐지라도 이것이 캔버스다!를 외칠 수 있을 정도의 내용을 게임을 예로 들어 설명합니다.

캔버스의 테스트는 아직 모든 브라우저가 캔버스를 지원하는 것이 아닌 만큼 IE에서의 캔버스 테스트보다 구글 크롬에서의 테스트를 추천합니다.

캔버스에 그리기
HTML 5에서 Canvas 영역은 브라우저 전체가 아닙니다. 그래서 Canvas 태그가 위치한 영역과 넓이, 높이에 따라 캔버스 영역이 달라지지요.

Chapter 2에서는 캔버스에 그림을 그리는 기본 방법에 대해서 알아봅니다. 캔버스만 웹 페이지에 올려놓기만 하면 그림이 그려지면 좋겠지만 그렇지 못하니 캔버스 위에서 선을 그리고 원호와 캔버스 변환 등을 통해 원하는 그림을 어떻게 만들어 내는 기본 방법을 배우게 됩니다.

문자, 이미지, 애니메이션 그리기
Chapter 3 ~ Chapter 5까지는 캔버스에 문자와 이미지, 수학과 물리학을 적용한 애니메이션을 표현하는 방법을 배우게 됩니다. 문자 API와 이미지 API를 통해 문자를 표현하고 이미지를 불러들여 조작하는 것은 캔버스에서 중요한 요소로 분류될 수 있습니다.

특히 Chapter 5에서는 수학과 물리학을 적용해 캔버스에서 애니메이션을 구현해봅니다. 이 장을 통해서 독자는 애니메이션을 직접 표현하는 방법을 자세하게 배우게 됩니다.

캔버스와 비디오 그리고 오디오
HTML 5엔 다양한 비디오와 오디오 파일을 읽어들 일 수 있도록 되어 있습니다. 그런데 이런 비디오나 오디오 파일을 읽어들 일 수 있는 시중의 플레이어들은 겉모습도 화려하고 기능도 많습니다. 물론 HTML 5에 이르러서 모든 브라우저에서 플러그인 없이 비디오나 오디오가 재생된다는 점은 훌륭한 장점에 속합니다.

Chapter 6 ~ Chapter 7에서는 캔버스의 그리기와 Video, Audio 태그를 자바스크립트로 제어해서 브라우저에서 기본 제공하는 플레이어보다 겉모습도 예쁘고 잘 동작하는 멋진 플레이어를 만드는 방법을 배우게 됩니다.

이제 것 배운 기술을 발산하기 – 게임을 만들어 보자!
<HTML 5 Canvas>의 Chapter 1에서 Chapter 7까지는 Canvas 기본 사용 방법을 배웠다면 Chapter 8 ~ Chapter 9까지 “지오 블라스터”의 기본 구성 및 비트맵과 사운드를 구현합니다. Chapter 9까지 충실히 따라왔다면 브라우저에서 동작하는 게임이 독자를 기다리고 있을 것입니다.

Chapter 10에선 BS Bingo 게임을 폰갭 프레임워크로 모바일 기기로 포팅하게 됩니다. 모바일 브라우저도 HTML 5 Canvas를 부분 지원한다는 것을 본다면 HTML 5 Canvas의 활용은 모바일에서도 유용하지 않을까요?

Canvas 저 편 너머로 할 수 있는 것! – 3D, 다중 사용자 애플리케이션
아직 캔버스는 2D 그래픽만 표현할 수 있지만 일부 브라우저에선 실험적으로 3D 객체를 그리거나 표현해낼 수 있습니다. 이 장의 내용은 구글 크롬을 통해서만 테스트할 수 있습니다.

그리고 ElectroServer 를 통해서 다중 사용자간에 캔버스에 그릴 객체(말은 이렇게 해도 캔버스는 즉시성을 가지고 있기 때문에 객체 단위로 그림을 관리할 수 없습니다)를 사용자간에 보내 채팅 애플리케이션을 만들거나 화이트 보드 애플리케이션을 만들어 볼 수도 있겠습니다.

<HTML 5 Canvas>는 HTML 5의 Canvas를 지금 알려진 것보다 더 깊이 더 많이 알게 도와줍니다. 무엇보다 저자와 번역자들이 이 책을 통해 쏟아낸 지식들은 국내 웹에서도 쉽게 찾아보기 어려운 것이 많으므로 캔버스에 대해 깊게 공부해보고 싶은 분들에게 추천합니다.

제게도 본 도서는 HTML 5의 캔버스가 단순히 물감만 표현할 수 있었던 캔버스가 아님을 알게 되기도 했습니다. Canvas의 알파부터 오메가까지! 알고 싶은 모든 분들 어서 오세요~!

버그있는 소프트웨어를 만드는 행동이 가져오는 용감함의 끝을 보고싶다면...?

소프트웨어를 만드는데 중요한 것은 무엇일까요? 이 질문에 대한 답은 답변을 요구받은 사람마다 제 각각 다를것입니다. "버그 없는 안전한 소프트웨어를 위한 CERT 자바 프로그래밍"은 보안적인 측면에서 바라본 소프트웨어의 중요한 점을 실제적인 관점에서 예시와 코드를 함께 제시한 책입니다.

책의 부제인 "당신의 코딩 습관은 안전하지 않다"는 본 도서가 어떤 부분에 초점을 두고 있는지 알게 합니다. 바로 우리가 배운 프로그래밍 습관에서 보안 문제가 가장 쉽게 검출된다고 보는 것이지요.

자바 언어의 창시자인 "제임스 고슬링"은 추천사에서 보안은 지난 수십 년 동안 심각한 주제로 다루어졌고 자바 역시 보안을 염두에 둔 언어라고 소개합니다.

PHP와 같은 스크립트 언어에서도 보안(동 출판사의 PHP 보안: 몇 줄의 코드로 안전하게 참고)이 다루어지는 것을 보면 보안이 컴퓨팅 세계에서 중요한 키워드로 자리 잡은건 사실로 받아들여야 할 것 같습니다.

책의 내용 자체는 자바로 멀티 플랫폼, 멀티 스레드 프로그램을 만드는 개발자에게도 도움이 될만한 Lock, Sanitization, 가시성과 원자성, Thread API, Thread Pool, Thread 안전 등이 다수 기술되어 있습니다.

자바로 안전한 프로그램을 짜는 법과 규칙이 아닌 안전한 프로그램을 만드는데 자바 언어에선 어떻게 할 수 있을까? 이 질문에 대해서 답을 찾아가 보겠습니다.

신뢰할 수 없는 곳에서 데이터가 넘어오면 신뢰해선 안된다.

프로그램에서 가장 믿을 수 없는 건 어떤 부분일까요? 바로 데이터입니다. 외부에서 입력받는 데이터는 모두 오염된 데이터이고 심지어 프로그램 내부에서 조차도 데이터를 주고 받는 코드가 신뢰할 수 있는 코드인지 아닌지에 따라서도 검증하고 규제해야 한다고 말합니다.

한동안 웹 세계를 떠들석하게 했던 SQL Injection 공격도 바로 입력에 대해 검증하지 않아서 발생했던 문제였습니다.

자바 역시 다른 언어와 마찬가지로 SQL, 인자 공격 등을 받을 수 있습니다. 바로 이런면에서 데이터는 적절히 규범화와 Sanitization이 되어야 하는데 이는 특히 시스템에 치명상을 입힐 수 있으므로 각별히 주의해야 합니다.

선언과 표현식. 그 미묘한 틈으로 해오는 공격 막아내기

자바 언어는 객체지향 언어 중에서도 선언이 꼭 필요하며 표현식에 있어서도 다른 언어와 차별되는 특징을 가지고 있습니다. 다른 언어에도 있는 특징이라고 본다면 대수롭지 않게 넘길수도 있는 부분이겠지만 안전을 고집하는 프로그램에서는 간과할 수 없는 내용입니다.

예를 들어 문자열의 비교와 같은 부분도 다른 언어가 == 와 같은 연산자를 사용하더라도 자바에선 == 연산자는 문자열 내용의 비교가 아니라는 점에 주의해야 합니다.

해커와 크래커가 타격을 줄 수 있는 지점은 사전에 제거해야 합니다. 문법적으로는 맞더라도 보안 코딩이 필요한 지점이 바로 선언과 표현식에 관한 부분입니다.

이 보다 더 위험할 수 없다. 수치 다루기

일본 애니메이션 중 공각 기동대엔 어떤 악당이 정부의 재정 창고에서 사이버 상으로 돈 일부를 계속해서 훔쳐내는 장면이 나옵니다. 그런데 정부는 이걸 모르지요.

어떻게 이런 일이 가능할까요? 이유는 컴퓨터가 가지고 있는 수치 연산 특징 때문인데 이 문제는 수치를 다루는 프로그램에서 수치 연산이 특히 중요한 문제로 다뤄집니다.

그런데 수치를 다루는 프로그램이 부정확하다기만 하면 정확성을 높이면 되겠지만 이 문제는 보안 버그를 발생시키는 지점이기도 합니다. 따라서 수치를 다루는 프로그램일수록 정밀도와 보안 버그가 발생하지 않도록 각별히 신경써야 합니다.

객체. 그 영원한 손님과 메서드를 잘못 놀리기

객체는 데이터와 데이터를 처리할 수 있는 메서드가 함께 들어가 있습니다. 하지만 자바 언어에서 객체는 크게 2종류로 나뉘어집니다. 불변과 가변 객체로 말이죠. 불변 객체는 말 그대로 변경할 수 없지만 가변 객체는 변할 수 있는 객체입니다. 저는 그래서 가변 객체를 손님 객체라고 부르기도 합니다.

보안적인 측면에 있어서도 객체를 수정할 수 있거나 상속해서 기능을 고칠 수 있다면 해당 객체를 사용하는 코드는 보안 위험에 노출될 수 밖에 없습니다. 혹은 해커의 코드로부터 전달받은 데이터에 위험이 있을거란 건 자명한 사실입니다.

한편, 메서드 사용에 있어서도 해커는 폐지 예정이거나 상속 등을 통해서 프로그램을 공격할 수 있습니다.

프로그래머가 의도하든 의도하지 않았던 메서드를 사용하거나 정의하는 일은 신중해야 합니다.

잠자면서 침흘리지 말고 항상 보이는데 있을 것

에러는 어떤 프로그램이던지 항상 발생할 수 있습니다. 하지만 사용자에게 에러 내용을 내보이는 일은 해커에게 공격해달라는 것과 다를바 없습니다. 프로그램 사용성에 있어서도 에러를 내보이는 일은 좋지 않다고 합니다.

무엇보다 에러가 해커에게 공격정보를 제공할 수 있으니 제품 개발 중을 제외하고 에러 처리는 적재 적소에 적절하게 사용되어야 함을 설명합니다.

뿐만 아니라 스레드 프로그램이 안정적으로 동작하기 위해서 전재되어야 하는 가시성과 원자성에 대한 이야기가 담겨 있습니다. 하지만 가시성과 원자성은 이후 나오는 Lock과 스레드 관련 기술과 밀접한 관련이 있으니 9장부터 13장까진 함께 보시는게 좋습니다.

하드 디스크 동작 램프가 꿈벅이고 있을때 왜 그럴까?

많은 프로그램에서 프로그램이 더 이상 사용자의 요청에 응답하지 않을 때 우리는 블럭되었다라고 말합니다. 블럭되었다는 말은 프로그램이 뭔가를 하고 있지만 사용자의 요청에 불응하고 있는 상태를 말하지요.

이런 현상은 디스크에 대한 입출력과 네트워크에 대한 입출력 그리고 시간이 오래 걸리는 일을 수행했을때 생깁니다.

입출력에 대한 블럭 문제는 단지 사용자의 요청에 반응하는 것 뿐 아니라 프로그램의 동작과 해커의 공격을 유도할 수 있기도 합니다. 따라서 이러한 입출력에 대한 내용을 주도 면밀하게 따져봐야 합니다.

데이터 다시 갖다 쓰기의 위험성

어떤 프로그램에서든 이진화된 포맷으로 데이터를 저장한다면 그 데이터를 읽는 프로그램은  후속작업이 쉬워집니다.

물론 사용자가 알아볼 수 있는 데이터로 출력되는 것도 있기도 합니다. 이렇게 프로그램에서 데이터를 바로 파일로 저장하거나 다른 네트워크로 보내거나 하는 것들을 우리는 직렬화된 데이터라고 부릅니다.

15장에선 바로 이런 데이터의 올바른 직렬화 방법과 직렬화로 발생할 수 있는 보안 버그를 설명합니다.

상태를 가지고 있는 직렬화 데이터나 높은 권한을 가지고 있는 직렬화 데이터는 보안 공격의 우려를 지니고 있으니 한번쯤은 데이터 직렬화/역직렬화시 주의할 필요가 있습니다.

샌드박스안에서 동작시키기

16장과 17장은 자바 프로그램이 샌드박스 안에서 안전하게 동작할 수 있는 방법을 제시합니다. 자바 언어가 이미 샌드박스 모델인데 무슨 또 샌드박스냐 하겠지만 자바 언어에선 클래스를 로드하는 로더를 통해서도 보안 문제가 발생할 수 있기도 합니다.

본 도서에서는 톰캣과 아파치 제로니모의 예를 들어서 클래스 로더에서도 문제를 발생시킬 수 있음을 지적합니다.

한편 자바 실행에 있어서도 어떤 권한을 어디에 줄것인지 명시하거나 런타임에서 보안 문제를 일으킬 수 있는 문제도 피해야죠.

뻔하거나 뻔하지 않은 것들 다루기

마지막으로 다루는 내용은 어느 부류에 속하기도 애매한 것들만 모아놓았습니다. 데이터 통신을 SSLSocket을 사용하거나 난수 생성, 기밀정보의 하드 코딩 금지, 메모리 누수 등에 대한 내용을 다룹니다.

이런 내용들은 프로그래머라면 당연히 알고 있거나 그렇게 해야 하는 내용이 다수입니다. 하지만 그렇게 알고 있어도 실천은 어렵지요.

어쩌면...

어쩌면 우리가 프로그램을 작성하고 있는 동안에도 해커는 끊임없이 우리의 프로그램을 공격할 준비를 하고 있을 겁니다. 설령 운이 좋아 공격당하지 않는다고 해도 마찬가지입니다.

"버그없는 안전한 소프트웨어를 위한 CERT 자바 프로그래밍"도 우리 프로그래머의 코딩 취약성에 대해 설명하고 있는 것으로 본다면 우리가 품질 좋은 소프트웨어를 만들어내는데 한걸음 더 나아가있을 겁니다.

책을 덮으면서 아쉬웠던건 책의 코드에 대한 상세 설명이 부족했다는 점인데, 이는 본 도서의 독자층을 고려한다면 쉽게 넘어갈 수 있는 부분일겁니다.

끝으로 번역하시느라 고생하셨던 역자 "강권학"님에게도 특별한 감사 말씀 드려요. 보안에 관련된 내용은 어떻게 해서든 어려운 축에 속하는 내용이라 애로가 많으셨을텐데 매끄럽게 번역하시려고 고생하신게 눈에 보입니다.

자바 언어로 먹고 사시는 분들에게도 이 책을 통해 보안 코딩이 한 걸음 더 나아가기를 진심으로 바라봅니다.

자바스크립트로 웹 사이트를 구성하는 혁신적인 방법!

자바스크립트는 넷스케이프로부터 개발된 웹 브라우저 기반의 프로그래밍 언어이다. 엇? 잠깐만.. 웹 브라우저 기반의 프로그래밍 언어? 이렇게 잠시 갸우뚱 할지 모른다.

그도 그럴것이 자바스크립트는 그 태생이 초기 브라우저 전쟁 당시 있었던 넷스케이프사로부터 개발된 것이기 때문이다. 사실 자바스크립트의 옛 이름은 라이브스크립트였다. 하지만 넷스케이프사 임직원들은 이 이름을 내켜하지 않았고 1995년 당시 제임스 고슬링이 만들었던 자바 언어와의 통신 기능을 추가해서 자바스크립트로 이름이 변경되었다.

역사까지 세세하게 따져본다면 자바스크립트는 자바 언어를 스크립트 형태로 만든 녀석은 분명 아니라는 건데, 이름이.. 뭔가 자바의 영향을 심하게 받은 듯한 느낌을 받게 한다. 실제로는 아니지만 말이다.

자바스크립트는 브라우저에서 동작하는 만큼 브라우저마다 자바스크립트를 동작시키는 엔진이 다 다르다.

Microsoft Internet Explorer : JScript
Google Chorme: V8
Mozilla Firefox: Rhino, TraceMonkey, JagerMonkey
Apple Safari: JavascriptCore(renamed Nitro)

우리가 알고 있는 자바스크립트는 하나인데 자바스크립트 엔진이 다 다르니 자연스럽게 브라우저 사이에 자바스크립트의 동작 속도가 구현 기능이 다 달라지게 되었다.

이런 이유로 자바스크립트의 표준을 제정하자는 의견이 있어서 ECMAScript가 제정되기 했지만 아직까지는 자바스크립트 엔진에 따라 구현이 다른 경우가 종종 있다.

"자바스크립트 웹 애플리케이션"은 단순히 폼 검사 용도가 아니라 실제로 완전하게 동작하는 자바스크립트 기반의 웹 애플리케이션을 만드는데 필요한 기초 기술과 응용 기술을 소개한다.

자바스크립트로 완전한 웹 애플리케이션 개발은 가능한가?

실제 웹 애플리케이션은 자바스크립트 뿐만 아니라 HTML과 서버 기술(PHP, .NET, Java, Python 등)이 함께 맞물려야 한다.

이와 같음에도 불구하고 HTML과 서버 기술로만 웹 애플리케이션을 구현하기엔 사용자의 요구가 조금 더 고급을 지향하며 반응성이 뛰어난 웹 애플리케이션 수요가 높아지고 있다. 게다가 응용 애플리케이션에서 항상 고민되는 것은 데이터와 뷰의 분리가 강조되고 있다는 사실이다.

데이터와 뷰의 분리는 MVC(Model-View-Controller)로 불리우는 애플리케이션 모델이 선호되는데 데이터는 뷰에 간섭하지 말아야 한다는 것이 이 모델의 핵심적인 내용이다.

"자바스크립트 웹 애플리케이션"은 바로 이 MVC 모델을 기본으로 풀어나간다.

MVC와 이벤트

1장에선 MVC에 대해 이야기하며 자바스크립트에서 MVC를 어떻게 구현할 수 있는지 그 예를 들어 설명해보인다.

자바스크립트에서 MVC는 Model은 데이터, View는 HTML, Controller는 데이터를 읽어서 뷰에 출력해주는 역할을 하는 것으로 구분해볼 수 있다.

뷰에 출력해줄 데이터는 그 종류가 무척 다양하며 그 데이터를 일관된 하나의 방법으로 다룰 필요가 있는데 이를 Model이라는 이름의 구조를 생성하여 데이터를 하나의 일관된 구조의 객체에 담아 데이터를 읽거나 쓰고 서버에 데이터를 저장할 수 있는 구조를 가지게 한다.

이처럼 데이터를 모델을 통해 자유롭게 조작할 수 있게 되었다면 뷰를 생성해야 한다. 뷰는 HTML로 구성하는 것이 일반적이지만 자바스크립트로 동적인 뷰를 구성하는 방법도 있다.

뷰에서 하는 역할은 컨트롤러에서 데이터를 보내주면 이를 표시해주는 역할을 한다. 뿐만 아니라 모델에 변경사항이 생기면 뷰는 이 변경사항을 반영하기도 한다. 그 역도 가능하다.

컨트롤러는 뷰와 모델을 연결하며 상태 등의 관리를 하는 역할을 맡는다.

그렇다면 이벤트는 무엇일까? 윈도우 프로그래밍을 해본 사람이라면 클릭, 이벤트라는 말에 익숙할텐데 이벤트는 어떤 것의 행동을 표현하는 말이다.

가령 승마를 한다고 했을때 말에 올라타 말을 때리면 말이 움직인다. 이것을 이벤트라는 용어로 풀어내면 다음과 같아진다.

행동 : 말을 때린다(때찌 이벤트 발생)
때지 이벤트 : 말이 달린다(둥둥둥둥)

설명이 유치한가? 설령 그렇더라도 애플리케이션에서 이벤트는 무척 중요한 부분을 차지한다. 이벤트는 한국어로 '사건'으로 번역된다(프로그래밍을 처음 배울때 이 용어 때문에 경찰의 사건을 말하는 줄 알았다).

MVC 모델을 적용한 애플리케이션에서 모델의 데이터를 변경하거나 뷰의 데이터를 변경할 경우 이를 서로에게 알려야 하므로 이벤트는 MVC에 있어 필수 요소라고 볼 수 있다.

자바스크립트의 모듈화와 파일 관련 작업하기

자바스크립트는 웹 브라우저 내에서 동작하도록 설계되다보니 모듈화에 어려운 점이 있었는데, 이점을 개선하기 위하여 사용되는 여러 라이브러리를 소개한다. 게중엔 실제로 프로젝트에 적용하여 사용중인 라이브러리가 있는데 이러한 라이브러리를 "자바스크립트 의존성 라이브러리"라고 한다.

의존성 라이브러리가 개발되지 않았더라면 아직도 하나의 웹 페이지에서만 동작하는 자바스크립트를 만들 수 밖에 없었을 것이다.

그리고 웹 애플리케이션은 브라우저 내에서의 드래그앤드롭과 파일 업로드 작업이 무척 제한적으로 구현하거나 구현이 어려웠으나 HTML 5에선 드래그앤드롭 이벤트와 파일 업로드를 바로 할 수 있도록 여러 자바스크립트 API를 제공한다.

이러한 자바스크립트 API의 제공은 실시간 웹을 만드는데 큰 공헌을 한 것이 사실이다.

물론 파일 업로드에 있어선 자바스크립트의 특성상 파일의 읽기 작업만 제공하고 있으나 앞으로 제한적인 접근을 통해 쓰기도 가능하지 않을까 하는 개인적인 바람도 있다.

웹 애플리케이션의 영원한 화두인 실시간 웹

웹이 전통적인 응용 애플리케이션의 텃밭을 하나씩 시도함에 따라서 사용자들은 응용 애플리케이션에서 제공하는 실시간 서비스를 웹 애플리케이션에도 바라기 시작했다.

그러나 Ajax 이전에선 실시간 웹은 브라우저 플러그인을 통해서만 제한적인 구현만 가능해졌을 뿐더러 여전히 웹 자체적으론 구현이 불가능했었다.

그러던 것이 Ajax 의 출현으로 화면의 새로고침없이 데이터를 주고받는 것이 가능해졌다. 완전한 의미에서의 실시간 웹은 아니었지만 대부분 Ajax를 거부감 없이 받아들이게 되었다.

이후 클라이언트와 서버간 연결 유지를 위해선 Ajax 요청을 서버로 계속 던져야 하는 부담이 있었다. 이는 다수의 요청을 주고받을때 요청량이 많다는 문제가 있고 서버에서 데이터를 클라이언트(브라우저)에게 보내어 클라이언트가 바로 데이터를 갱신할 수 없다는 문제가 발견되었다.

이후, 이 문제를 해결하기 위해 Long Ajax로 불리우는 Comet 기술이 먼저 나오고 HTML 5에서 이를 규격으로 만든 웹소켓 기술이 제정되기도 했다.

8장에선 바로 이러한 웹소켓 기술과 Comet 기술 등과 같이 실시간 웹을 구성할 수 있는 방법을 알아본다.

테스팅, 디버깅, 배포는 개발자의 오랜 벗

어떤 언어로 애플리케이션을 제작하든 중요하게 부각되는 것은 테스트, 디버깅, 배포이다. 테스트는 애플리케이션이 제대로 동작하는지 원하는 대로 행동하는지 알아볼 수 있다.

디버깅은 애플리케이션 개발에 있어 가장 중요한 요소로 특히 자바스크립트로 개발함에 있어선 이는 피할 수 없는 숙명적 요소가 아닐까? 디버깅도 IE 5, 6, 7까진 Firefox의 Firebug를 통한 스크립트 디버깅처럼 쉽지 않았다. 물론 IE에서도 필요하다면 Script Debugger를 쓸 수 있었지만 일반 웹 애플리케이션 개발자가 쓰기엔 다소 어려웠던 것이 사실이니 말이다.

개발이 완료되면 애플리케이션을 배포해야 한다. 특히 자바스크립트 기반의 웹 애플리케이션은 브라우저에 기반하여 동작하므로 캐싱을 통해 성능을 강화하고 Gzip을 통해 크기를 줄이고 감사 프로그램을 사용하여 제대로 동작하는지 검사해볼 필요가 있다.

자바스크립트 웹 애플리케이션을 도와주는 프레임워크와 함께 하기

맨손으로 자바스크립트 웹 애플리케이션을 개발할때 우리는 조금 더 쉽게 개발을 도와주는 여러 프레임워크와 만나서 친구 관계를 맺을 필요가 있다.

저자가 직접 개발한 스파인 라이브러리와 백본, 자바스크립트MVC 라이브러리를 통해 자바스크립트 웹 애플리케이션을 조금 더 쉽게 구현할 수 있도록 안내하며 독자는 여러 프레임워크와의 만남을 통해 자바스크립트 웹 애플리케이션을 만드는데 도움을 얻을 것이다.

jQuery 그리고 CSS에 익숙해지기

jQuery는 현존하는 자바스크립트 라이브러리 중에 가장 널리 쓰이는 라이브러리가 되었다. 본질적으로 jQuery는 DOM을 조작하는 라이브러리며 다른 여러 자바스크립트 프레임워크와 함께 사용할 수 있어 자바스크립트 기반의 웹 애플리케이션 개발시에 조금 더 빨리 프로그램을 개발할 수 있을 것이다.

그리고 CSS는 웹 페이지를 조금 더 아름답고 예쁘게 구성할 수 있는 언어이다. 부록을 통해서 저자는 CSS의 확장과 CSS 3 사용을 통해서 웹 애플리케이션을 보기 좋게 만드는데 필요한 기술을 소개한다.

앞으로 웹은... 어떻게 변할까?

"자바스크립트 웹 애플리케이션"은 자바스크립트로 웹 애플리케이션을 만드는 새로운 방법을 제시한다. 하지만 HTML 5가 뒷받침되지 않는다면 Ajax가 그래왔던 것처럼 정체기에 접어들지도 모른다.

웹의 미래는 아직 무궁무진하다. 독자가 꿈꾸는 만큼 구현하는 만큼 이루어지는 새로운 세상이니 한번 쯤 도전해 보는 것이 좋다고 생각한다.

웹은 어떻게 변할까?라는 화두보다 웹은 독자 자신의 성장과 함께 변하지 않을까? 라는 새로운 화두를 던져본다.

코드는 당신 자신을 위해 존재한다. 인간적인 코드 만들기

소프트웨어 개발자에게 있어서 소프트웨어가 폐기되는 것보다 더 무서운 것은 무엇일까? 개인적인 생각은 소프트웨어 유지보수가 소프트웨어 폐기보다 더 무서운 일이 아닐까 생각해본다.

지난 시간에 열심히 코드를 만들어서 기껏 동작하게 해놨더니 오류 투성이에 동작도 제대로 안한다. 밤을 새든, 주말 출근을 하든 코드가 동작하게 해도 더욱이나 중요한 것은 내가 다시 그 코드를 볼 때다.

하루도 아니고 조금이라도 시간이 흐른 다음 본 코드는 광역시 쓰레기 매립장과 그 모습이 흡사하다.

비단, 내가 만든 코드가 아니라 할지라도 그건 변함 없는 사실이다.

그러면 소프트웨어는 어떻게 해야 잘 개발할 수 있을까? 아니 그 보단 어떻게 해야 만들기도 쉽고 유지보수도 쉽게 하게 할 수 있을까?

"읽기 좋은 코드가 좋은 코드다"의 저자인 더스틴 보즈웰과 트레버 파우커는 자신들이 경험한 나쁜 코드와 좋은 코드를 어떻게 구분하는지 그 해결책은 무엇인지 찾아본다.

이 코드를 누가 볼꺼야?

소프트웨어는 개발하는 사람과 유지보수 하는 사람이 작은 회사의 경우에는 같다. 하지만 회사의 규모가 커지고 개발하는 인력이 많아지면 자연스럽게 개발 인력과 유지보수 인력이 나뉘어진다.

물론 이런 구조가 조직 운영의 측면에선 훌륭한 운용 방법이겠으나 소프트웨어 개발에 있어서도 정말 행복한 운용 방법일까?

사람에 따라서 이 질문에 대한 대답은 다를 수 밖에 없을 것 같으니 쓸데없이 진 빼지 말고 코드를 누가 볼것인지 생각해봐야 한다.

내가 생각하는 대답은 이렇다.

자신이 소프트웨어 개발자라면 자신이 만든 코드는  자신이 볼 가능성이 70% 이상이다.

근데 내가 만드는 코드를 내 맘대로 만들면 되지. 왜 읽기 편하게 만들어야 하느냐고 묻는다면 코드는 온전히 본인의 것이기 때문이다.

코드는 미학이다!

코드를 읽기 좋게 만든다면서 자신만 알아볼 수 있는(심지어 자신도 잊어먹는) 코드를 만들어놓고 와! 이건 완전 예술이야! 라고 자신이 감탄하는 코드를 만들어 놓고 나 잘났다~

독자는 이런 종류의 행동을 하면 안된다! 물론 읽기 좋은 코드는 보기에 아름다워야 하니 미학적인 모습을 가지고 있어야 하기는 하지만 그렇다고 해서 무슨 미술관의 추상화 그림처럼 코드를 만들라는건 아니다.

읽기 좋은 코드는 명확한 이름들을 가지면서 코드 정렬을 맞추고 의미있는 순서로 재배치하며 명확한 주석을 기록해야 한다. 그러면서도 소프트웨어 개발에 정해져있는 코딩 규칙이 있으면 그를 따라줘야 한다.

잘 동작하는 코드 vs 명확한 코드

나도 코드를 만들다 보면 명확한 코드보단 그저 잘 동작하는 코드에 집중하게 된다. 그런데 잘 동작하는 코드가 항상 명확한 것은 아니다. 오히려 명확한 코드가 잘 동작하는 코드인 경우가 많다.

잘 동작하는 코드에서 명확한 코드로의 변경은 코드의 제어흐름의 조정과 거대한 표현은 잘개 쪼갠다. 그리고 무엇보다 변수는 말 그대로 자주 변할 수 있으니 그 사용범위가 제한되어야 한다.

이 코드 다른데서도 쓸 수 있을까?

리팩토링에서도 나올 수 있는 이 주제는 코드에 있어서도 프로그램에 완전히 종속하는 기능인지 다른 코드에서도 쓸 수 있는지 확인해보아야 한다. 

이와 같은 이유로 코드에서 분리될 필요가 있는 문제를 찾아서 코드를 분리하는 작업이 필요하다. 또한 작업은 한 번에 하나씩 하도록 코드를 만들어야 한다.

개발자들이 항상 하는 일 중 하나는 있는 라이브러리를 다시 생성한다거나 하는 일인데 우리가 만드는 프로그램은 항상 작은 코드 크기를 유지해야 한다. 그럼으로서 우리는 코드를 조금 더 쉽게 유지보수하고 명확한 문제 해결책을 가지게 된다.

코드만 읽기 쉬워선 안된다 - 선택된 주제들

많은 경우 우리는 소프트웨어 개발에 있어서 기능은 개발하지만 기능에 대한 면밀한 테스트는 잘 해보지 않는다. 그리고 하나의 잘 독립된 소프트웨어를 개발하는 경우도 별로 없다.

많은 경우의 소프트웨어 개발자들은 하나의 잘 설계된 소프트웨어 개발이 아닌 시간에 쫓기는 개발을 하기 때문인데, 이와 관련해서 저자는 한 가지의 해결방법을 제시했다.

테스트 케이스 작성을 통한 테스트를 해결책으로 제시했는데 많은 경우 소프트웨어 개발에서 테스트는 겉핧기 식이 다수다.

테스트를 제대로 할 경우 우리는 명확하고 읽기 쉬운 코드로 만들어진 잘 동작하는 코드를 생성할 수 있게 될 것이다.

우리가 해야 할 일...

소프트웨어 개발에서 코드 작성은 개발자가 해야 할 가장 중요한 일이지만 막상 우리는 이런 책을 보고 그냥 지나가는 경우가 많다.

필요할때 책 속의 지식을 머리속에서 끄집어내서 바로 활용해낼 수 있다면 좋겠지만 사람의 머리는 그 크기가 정해져 있으니 기억할 수 있는 것도 자주 보지 않으면 기억해 낼 수 없다.

"읽기 좋은 코드가 좋은 코드다"는 책 제목이면서 결코 빈 말이 아니다. 우리가 소프트웨어를 앞으로도 지속적으로 개발해야 한다면 이 책을 회사 책상이나 연구실 책상에 비치해두어라.

독자의 코딩이 혼돈 상태에 있을 때 많은 도움을 줄 것이다

누구나 쉽게 출판할 수 있는 새로운 방법

인간에게 있어서 책은 잘 알지 못하는 세상의 탐험기를 담고 있습니다. 그런데 이와 같은 책이 만들어지기 위해선 책 내용을 기술하는 저자와 책으로 나올 수 있도록 기획하는 기획자와 책 편집을 담당하는 편집자와 표지를 담당하는 출판 그래픽 디자이너와 책을 찍어내는 인쇄소 담당자와 우리가 책을 만날때까지 서점에 배송해주는 물류 업종에 종사하시는 분들과 서점에 배치하는 분들, 서점에서 계산을 도와주는 분들까지.. 우리는 책 한권과 마주하기 위하여 여러 사람들의 피땀 어린 노력이 필요합니다.

적어도 지금까지는 이러하였습니다. 하지만 디지털 콘텐츠가 기하 급수적으로 늘어나면서 출판에 있어서도 이러한 디지털화의 영향을 받기 시작했습니다.

요즘 출판업계에서 디지털 도서의 포맷으로 각광받고 있는 epub과 어도비가 개발한 pdf 포맷 등의 디지털 콘텐츠를 포맷하는 여러 방법이 나오고 있지요.

하지만 디지털 콘텐츠를 만드는 방법 그 자체에 대해선 그다지 연구되지 않거나 아직까지 열악한 현실에 있는 것이 사실입니다.

예를 들어 DocBook 이라고 하는 콘텐츠를 마크업하는 언어는 특정 구조에 맞춰 내용을 기술하면 다른 여러가지 형식(pdf, rtf, latex 등)으로 다시 만들어주는 기능을 별도의 프로그램으로 제공합니다.

적어도 이러한 방법이 스마트폰과 아이패드와 같은 태블릿이 나타나기 전까지는 유효했던 방법입니다.

그러나 사용자의 경험을 제일 크게 여기는 스마트폰과 태블릿은 디지털 도서를 보는 방법을 바꿔버렸습니다. 자! 상상을 해보세요. 한국의 역사를 배우는 디지털 도서일때 참고자료로 이순신의 한산대첩을 드라마의 한 장면으로 제공한다면 적어도 인쇄되어서 나오는 그런 정적인 모습이 아니라 영상으로 제공한다면 교재로서 조금 더 가치있을 겁니다.

이 책은..

최근의 애플에서 멀티미디어 자료를 적극적으로 활용하면서 디지털 도서를 편집할 수 있는 프로그램이 발표되었습니다. 바로 iBooks Author가 앞에서 언급한 내용을 담고 있는 디지털 도서의 제작 프로그램입니다.

<iBooks Author>는 애플의 iBooks Author 프로그램을 사용하는 방법을 담은 책입니다. 

책의 내용은 프로그램의 기본 기능을 먼저 설명하고 실전 프로젝트를 통해서 iBooks Author에 익숙해지도록 구성되어 있습니다.

프로그램의 기본 기능에서는 디지털 도서(전자책)의 개념과 iBooks Author(아이북스 오서)의 기본 메뉴를 알아보고 도서를 쉽게 제작하기 위한 템플릿의 적용과 책 표지, 글자 입력과 내용의 레이아웃, 장, 섹션, 페이지를 구성하는 방법, 사용자와 1:1대로 마주하는 멀티미디어 콘텐츠(이미지, 도형, 표, 차트, 갤러리, 동영상, 음악, 복습위젯, 키노트 위젯, HTML 5 위젯, 3D 콘텐츠)등을 구성하고 디지털 도서에 넣는 방법을 안내합니다.

실전 프로젝트를 이용한 부분에선 종이책을 그대로 디지털 도서로 만드는 것이 아니라 전자책이 가진 점을 활용하여 디지털 도서를 만드는 방법과 다양한 멀티미디어 요소를 이용한 전자 교과서, 회사 업무용 제안서를 만들어 봄으로서 독자를 iBooks Author와 쉽게 접할 수 있도록 도와줍니다.

조금은 아쉽다..

iBooks Author는 디지털 콘텐츠를 가지고 쉽게 디지털 도서를 만들 수 있습니다. 이러한 점에선 1인 출판사를 경영하고자 하는 사람이나 자신이 정리한 내용을 디지털 도서로 만들고자 하는 사람에겐 새로운 경험을 제공할 수 있다고 봅니다.

그러나, iBooks Author는 애플의 생태계 환경(iTunes, iPad, Mac)에서만 쓸 수 있고 제작에서도 Mac이 없으면 제작할 수 없는 등의 문제가 걸려 있습니다.

<iBooks Author>가 1인 출판에 대해 다루는 것이 아닌 만큼 저작권 등의 이야기가 빠져있기도 합니다.

분명 iBooks Author는 독자들에게 디지털 도서를 제작하고 볼 수 있는 새로운 경험을 해볼 수 있지만 iBooks Author의 생태계 환경은 아직 닫혀 있습니다. 이러한 환경이 다른 생태계도 반영된다면 분명히 경쟁력을 제공할 겁니다.

iBooks Author가 탐나지 않으세요? 지금 바로 <iBooks Author>를 통해서 새로운 디지털 도서 제작 방법에 대해 알아보세요!

고객과의 Fight. 이익은 없다.

지난 2009년 3월 17일인가.. 19일인가 한빛미디어에서 주최하는 이벤트에 응모했다. 물론은 아니지만 이벤트에서 리뷰를 대상으로 했던 책을 구입해뒀던 상태였다. 그럼에도 불구하고 아무런 제재를 갖지 않는 참가 자격 덕분으로 생각지도 않았던 도서 리뷰 기회를 얻게 되었다.(나중에 이 증정 서적은 사내의 좋아하는 아가씨에게 넘겼다.)

사회에서 나 이외의 사람과 살아야 하는 건 사람의 피할 수 있는게 아니라고 본다. 또한 그렇게 본다면 사람과의 조합인 조직에서 다른 조직과의 공존을 목적으로 또 다른 조직을 설득하거나 싸움을 벌여야 한다.

작은 의미에서 큰 의미로까지 나 아닌 사람은 설득의 대상일 수 있다. 이 중에서 설득을 가장 효과적으로 할 수 있는 방법은 무엇이 있을까? 말로? 카리스마로? 둘 다 아닐 것이다. 말로 설득할 수 있다면 그(그들)는 사기꾼일 것이오. 카리스마로 설득할 수 있다면 그는 조직의 보스일 것이다.

이도 저도 아니라면 설득의 방법은? 열과 성의를 다해 고객을 설득하는 것이다. 어떻게? 바로 이 질문에서 시작하여 답을 찾아가는 방법을 알려주는 것이 이 책이다.

이 책은 삼성 SDS에 계신 2분의 제안의 고수들이 동시대의 고민을 같이 하고 있는 제안가들에게 던지는 메시지가 가득 담긴 책이다.

저자인 류현주씨와 박민영씨는 제안에 대해 나꼼수씨와 정도만씨(X트라로 한가닥씨도 등장한다)의 이야기를 중점으로 이야기를 풀어나간다.

잠시 뒷길로 빠지는 이야기가 하나 있는데 난 저자 2분 모두 여자분인줄 알았는데, 박민영씨는 남자분이시고, 게다가!! 내가 속해 있는 사내의 부서명과 이름이 일치해서 깜짝 놀랐다.(내가 속한 부서는 민영사업부문)

이 리뷰를 쓰기 전에 나는 야후! 코리아에서 제안이라는 단어에 대해 살짝 검색해 봤는데 한자로 다음과 같은 단어가 검색되었다.

"提案" 끌 제, 책상 안

이것만 보고서는 영 感이 없다. 책상을 왜 끈다는 건지? 내가 몇 해 전에 기획서, 제안서 관련 서적들을 읽으면서도 느끼지 못했던 건 내가 실천을 하지 않았기 때문이었겠지만 IT라는게 생긴지 채 100년도 안되는 역사 속에서 IT의 제안은 내가 생각하고 있던 것. 나 혼자 하는게 제안이 아니라는걸 몰랐기 때문이기도 하다.

"고객으로부터 출발하라. 고객 마음을 사로잡겠다면..."

책에 있는 목차의 한 구절인데, 두 해 전에 작성했던 50여장의 제안서가 문득 떠올랐다. 난 RFP도 뭔지 잘 모르고 그 당시엔 단순히 개념도 없었으니 그 사업에 이미 진출했었던 업체의 제안서를 고객사에서 얻어와서 거의 고대로 복사해서 약간만 고치고 제출했었다.

지금 생각해보면 개발자로서 했던 그 제안은 정말 쓰레기 중의 쓰레기가 아니지 않았을까 싶다. 난 RFP를 분석하는 방법으로부터 시작해야 했던 것 아닐까? 아니면 제안서를 쓰기엔 너무 나이가 어렸던 것 아닐까? 노! 당시 26이었으니 나이가 어렸던 것도 아니다. 단지 너무 개념이 없었을 뿐이었던거다.(이 리뷰를 통해 그 당시 분들께 사과 드린다.)

도서 한 페이지씩 글귀를 통해 나를 종아리 내려치듯 하는 글귀는 나를 부끄럽게 했는데, 그 절정은 "제안서 작성, 준비 없는 시작은 뒤로 반걸음 가기"였다.

그랬다. 2007년 초기에 제안서를 작성한답시고 까불거렸던 나는 제안서를 작성하지도 않고 빈둥대기만 했다. RFP는 그저 참고 항목이었을 뿐.. 반성의 계기를 가지게 되었다.

2007년에 시작했었던 그 제안서 작업을 엉망으로 망쳐놓고서도 그 사업에 참여한 컨소시엄이 없던 덕분에 난 사업을 통째로 말아먹었고 그 다음해에 병역 이행을 마치기 위해 병특 업체에 들어오게 되었는데, 회사 특성상 영업과 제안이 동시에 이루어져야 했다.

한 번은 내가 속한 팀의(그땐 개발팀) 부장님이 밤새도록 집에도 안가시고 손잡고더불어(내가 속한 회사의 방 이름은 한글로 정겹게 지어져 있다.)에서 나오시지도 않고 이것저것 서류를 보시며 발음 연습을 하고 계셨는데 5-6차례의 강의 경험이 있던 나로서는 그런 모습이 영 익숙치 않았다(내가 하지 않았기 때문이었다.)

이 책을 읽고 난 다음에야 "고객을 위한 쇼를 하라. 쇼!"를 위해 준비한다는걸 알게 되었다. 무엇때문에 우리는 그토록 리허설을 하는가? 그 질문에 대한 답은 제안은 "고객을 설득하는 것" 아니 그 이상의 것이기 때문이다.

지금도 계속해서 제안서 작업 때문에 밤을 새시거나 늦은 밤 회사에 call 당해서 오시는 사우들을 보면 안쓰러울때가 있다. "제안의 자산화, 밤 안 새는 지름길이다" 가 안되어 있어서 그런것일까? 필시 그것은 아닐 것이다.

책이 알려주는 여러가지 길에도 불구하고 결과적으로 나는 아직 제안이 두렵고 무섭다. 하지만 나 자신조차 설득하지 못하고 고객과 Fight를 버린다면 나는 아무런 이익도 얻지 못할 것이다.

책의 끝머리엔 저자과 독자에게 던지는 문장 하나가 있다. 그 문장에서와 같이 나 역시 내 자신을 위한게 아니라 고객을 위해 회사를 위해 제안 작업을 두려워하지 않고 저자분들과 함께 했으면 좋겠다.
(진심으로 그럴 마음이 있다.)

하지만! 아직 제안 작업에 나서기엔 나 자신이 너무 초라하지 않나? 오늘도 제안이 아닌 일로 고객을 설득하러 나서본다.

ps. 도서 내용은 참 유익했지만 중간중간 나오는 오타와 책 내용 끝에 제품의 이름들이 노출되는 과정에서 특정 DBMS사의 제품명이 완전히 잘못되어 있다는 건 조금 아니었다. 제품명 오류는 쉽게 눈에 띄는 부분이었을 텐데..(Qubrid -> Cubrid) 그럼에도 불구하고 전반적으로 책의 품질은 우수하다.