빨간 네모안에 윈도우, 맥, 리눅스용이 각각 따로 다운로드 받을 수 있게 되어 있는 거 보이시죠?
저는 윈도우용 아두이노를 다운로드 받았어요!
■ 드라이버 설치
USB를 연결하면 드라이버 설치창이 뜨지요?
거기에서 책에 나온 대로 경로를 지정해 주었습니다. 이 과정을 2번 반복! ^ ^
■ 포트 지정
저는 책과 마찬가지로 포트가 COM3로 나오는 군요.
아두이노를 실행해서 확인해보았습니다.
■ 스케치 시작
드디어 코딩이군요.
첫 번째 예제는 보드의 LED를 깜빡거리게 만드는 것입니다.
죠기~ 조그맣게 'L'이라는 글자 앞에 LED 보이시죠? ^ ^
자, 그럼 '스케치'에 들어가 볼까요?
(* 아두이노에서는 코딩을 '스케치'라고 하는 군요. 왠지 마음에 드는 용어입니다.)
코드가 아주 아주 짧아서 좋군요! ^ ^
책에 전문이 실려 있고, 혹은 여기에 가셔도 코드파일을 다운받으실 수 있습니다.
자, 그럼 보드에 업로드를 해보겠습니다~!
쨘! 불이 들어왔군요!
깜빡-! 깜빡-!
손으로 적은 스케치가 신호로 바뀌어서 하드웨어를 조종하였습니다.
간단하지만 역시 놀랍군요.
(촌스럽지만 신기한 마음에 동영상까지 찍어 봤습니다. 우후훗-)
책을 따라 해보니 프로그래밍 지식이 없어도 쉽게 따라할 수 있겠다는 생각이 드네요.
뒷부분에는 스케치한 것에 대한 설명이 한 줄, 한 줄 친절하게 나와 있습니다.
(프로그래머가 본다면 속터질정도로 친절한 대목이죠! ^ ^;)
이 과정에서 흥미를 느끼면 다음 챕터들도 무리없이 따라해 볼 수 있겠습니다.
왠지 뭔가 창조적인 아~ㄹ트(Art)를 만들어보고 싶다는 건 저만의 욕심일까요? (죄송...;)
개인적으로 기발한 작품 찾기 포스팅에서 봤던 알람용 침대를 실습해 보고 싶네요!
(아침잠이 많아 괴로워요. ㅠ_ㅠ)
조광센서라든지 온도감지센서를 이용하면 정말 재밌게 놀 수 있겠다는 생각이 들어요!
요렇게 놀다 보면 뇌도 자극되고, 자극되면 창의력도 퐁퐁 샘솟지 않을까...하고 생각합니다. ^ ^
안녕하세요? 저랑 같은 병을 앓고 계시네요 ^^ 반갑습니다.
저는 가만히 있는 사람의 허점빈곳모순을 잘 까고
또 까는 사람의 모순을 또 까서 모두를 적으로 만드는 병을 가지고 있습니다.
특히 저명한 사람을 까서 한꺼번에 많은 적을 만들기도 합니다.
네또노우에에서 또 뵈었으면 좋겠네요.
미군 부대에서는 latrine이라는 단어를 사용해 "화장실"을 가리키는데, 미군 부대에서 2년 정도 근무하고 나오니까 일반 사회에서 화장실을 말할 때도 자꾸 "latrine"을 썼더랬어요;; 지금 생각해도 참 이상한. 그냥 rest room이라고 하면 될 걸 ㅠㅠ 본문과 관련없는 글 죄송합니다 ㄷㄷ
-. 팀 내에서 어떤 위치를 차지하고 있을지 자신은 없는데, 그래도 팀에 어떤 기여를 하면서 신뢰도 얻고 숙련된 프로그래머로 성장할 수 있는 방법을 찾고 싶다거나(바닥을 쓸어라 패턴)
-. 실제로 나는 업무에 필요한 필수적인 기능 중 몇 가지는 그리 익숙하지 않은데, 관리자나 팀의 다른 사람들은 내가 그 일을 아주 잘 해낼 거라고 믿고 있어 부담을 느낀다거나(무지를 드러내라 패턴)
-. 노력한 덕에 팀의 누구보다도 높은 수준에 도달했지만, 더 이상 배움에 진전이 없어 보이거나(가장 뒤떨어진 이가 되라 패턴)
-. 도무지 내가 가는 길 앞에는 향후 어떤 풍경이 펼쳐질지, 또 거기에 어떻게 대비해야 좋을지 모르는 상태라 막막해져서 도움과 안내가 필요하다고 느낀다.(멘토를 찾아라 패턴)
이 대목에서 ‘오, 맞아맞아’라고 외치셨다면, 지금 숙련된 프로그래머가 되고자 노력하는 과정에 있는 것일 테지요. ^^
숙련됨에 이르는 과정은 다양할 테고, 거기에 이르는 바른 길들에는 저마다의 특색이 있습니다. 어느 길을 택하든 자기도 모르게 엉뚱한 곳으로 가는 일은 없어야 하겠지요. 그렇기 때문에 많은 사람들은 궁금해 합니다. ‘내가 과연 제대로 하고 있는 것이 맞아?’ 하고요.
프로그래밍이라는 긴 여정의 초입에 서서 고민하고 방황하는 이들을 위한 책, 『프로그래머의 길, 멘토에게 묻다』가 나왔습니다. 번역에는, 깊이 있는 문장력으로 편집자에게도 큰 가르침을 주신 사이냅소프트의 강중빈 님이 수고해 주셨습니다. ^^
저자인 Dave H. Hoover와 Adewale oshineye가 다양한 사람을 만나서 직접 이야기를 듣고 인터뷰하고 자신들의 경험을 일목요연하게 정리한 다음, 초보에서 숙련 프로그래머까지 다양한 수준과 경험을 지닌 프로그래머들의 검증을 거쳐 ‘프로그래머라는 거대한 여정’의 방향을 잡아 줄 책을 만들었습니다.
원서 제목은 『Apprenticeship Patterns』인데, 직역하면 ‘견습과정 패턴’으로 말 그대로 프로그래머 생활에서 ‘견습생’이라 불릴 만한 시기에 흔히 겪을 수 있는 시행착오와 거기에 대처하는 실천법을 실었습니다.
목차보기 ↓
목차
소프트웨어 장인정신 선언
1장 들어가는 글
소프트웨어 장인정신이란 무엇인가?
견습과정이란 무엇인가?
견습과정 패턴이란 무엇안가?
패턴들은 어디서 비롯되었는가?
여기서 이제 어디로 가는가?
2장 잔을 비우다
첫 번째 언어
흰 띠를 매라
열정을 드러내라
구체적인 기술
무지를 드러내라
무지에 맞서라
깊은 쪽
한발 물러서라
장을 마치며
3장 긴 여정을 걷다
긴 여정
예술보다 기예
지속적인 동기 부여
열정을 키워라
자신만의 지도를 그려라
직위를 지표로 이용하라
전장에 머물러라
또 다른 길
장을 마치며
4장 정확한 자기 평가
가장 뒤떨어진 이가 돼라
멘토를 찾아라
마음 맞는 사람들
팔꿈치를 맞대고
바닥을 쓸어라
장을 마치며
5장 끊임없는 학습
능력의 폭을 넓혀라
연습, 연습, 또 연습
부숴도 괜찮은 장난감
소스를 활용하라
일하면서 성찰하라
배운 것을 기록하라
배운 것을 공유하라
피드백 루프를 만들어라
실패하는 법을 배워라
장을 마치며
6장 학습 과정의 구성
독서 목록
꾸준히 읽어라
고전을 공부하라
더 깊이 파고들어라
익숙한 도구들
장을 마치며
7장 결론
부록 A 패턴 목록
부록 B 견습과정의 개설을 요청함
부록 C 옵티바 견습과정 프로그램의 첫 일 년을 회고하다
부록 D 온라인 자료
IT가 3D니 4D니 하는 얘기가 그다지 새롭지 않은 지금, 머릿속에 떠돌던 로직 한 토막이 자신의 손을 거쳐서 전기 배선을 타고 실리콘의 힘을 빌어 가상세계에 현현하고, 마침내 현실의 사람들과 의미 있는 관계를 맺는 존재가 되는 그런 경험, 무엇과도 견줄 수 없는 그 짜릿함을 떠날 수 없어서 개발자들은 오늘도 키보드 앞에 앉습니다.
이렇게 같은 길을 가는 사람들 중에서 먼저 이 길에 대해 진지하게 고민하기 시작한 이들이 있었습니다. 그 고민의 결과는 애자일, 실용주의, 소프트웨어 장인정신 같은 여러 가지 시도들로 나타났고, 우리가 걷는 이 길에 의미 있는 이정표가 되고 있습니다.
이 책은 그런 맥락에서 특히 경험이 많지 않은 프로그래머들에게 길잡이가 되기를 희망합니다. 원 제목인 Apprenticeship(견습 과정) Patterns에서 보듯이, 이 책은 초심자들이 참고할 만한 여러 가지 조언들을 패턴이라는 형식으로 엮어 낸 일종의 조언 모음집이라고 할 수 있습니다. 조언들은 구체적인 상황을 상정한 다음에 그럴 때 어떤 행동을 취하면 좋을지를, 먼저 그 길을 한번 지나간 멘토의 목소리로 들려줍니다.
비록 개발자라는 존재가 ‘인력’이나 ‘리소스’로 지칭되는 것이 당연시되는 불유쾌한 현실이지만, 글을 읽는 여러분이 여기 실린 조언들을 발판 삼아 아직은 미숙한 우리 업계의 수준을 한 단계 높이는 데 기여할 수 있게 되기를 기원합니다.
- 옮긴이의 글 중
이 책은 견습 프로그래머가 느낄 어려움과 해결법이라는 형식을 취하면서, 자신의 경력을 설계하고, 이 분야의 탁월한 개발자가 될 수 있도록 자기 자신을 세우는 일에 관해 말하고 있습니다.
언제나, 중요한 것은 실천 같습니다. 이 책으로 그간 한 단계 도약하는 프로그래머가 되고자 노력하며 느꼈던 답답함이 해소되기를 바랍니다 :)
꽂아 놓기만 하더라도 일 년 후쯤 보면(아주 나쁠 경우 몇 달 후) 황사를 뒤집어 쓴 것 마냥 누렇게 색이 변색되거나 네모반듯하던 모양이 휘어진 것을 볼 수 있죠. 더군다나 프로그래밍 책들은 두께도 만만치 않으니 관리하기가 여간 힘든 것이 아닙니다.
책을 사랑하는 독자님들을 위해 책 관리법을 몇 가지 소개할까 합니다. ^^;
1. 눕혀서 보관합니다.
보통 책은 책장에 '세워서' 꽂아두죠.
그런데 책은 원래 '눕혀서' 보관하는 거라고 하네요.
왜 그런지 볼까요?
세워서 보관할 경우, 책이 양장으로 제본되었다면, 바로 섭니다.
책에 힘이 없으면 이렇게 아래와 옆이 구부러집니다.
대다수 책이 이렇습니다. 양장 제본조차 제본 상태가 불량이거나, 삐뚤게 놓인 채 습기를 먹으면 마찬가지로 휘어지죠.
(사실 '북앤드'라는 도구가 있어서 의미 없는 우려일 수도 있겠네요.ㅠ 용어는 생소하지만 모두 본 적이 있으실 겁니다. 또 사무실에서 많이 쓰는 슬라이드 책꽂이도 있겠구요)
또 책을 읽다 보면, 오래 갖고 다니게 마련이고(네, 제가 그렇습니다요..-_-;;)
그러다 보면 책 모양이 망가지는 현상이 일어납니다.
눕혀서 보관할 경우, 휘어짐도 덜할 테고, 벌어진 책도 눌러주어 네모난 모양을 잡아줍니다. 단점이라면 이렇게 보관하면 책장 자리를 많이 차지하고, 책을 꺼낼 때 약간 수고스럽다는 점이죠.^^
2. 너무 깊숙이 꽂아 놓지 않습니다.
무슨 말이냐 하면, 말 그대로 책장에 책을 쑥 밀어 넣어 꽂지 않는 편이 좋다는 겁니다.
보통 책을 책장에 꽂을 때 책장 안쪽에 책이 닿을 때까지 밀어 넣지요?
그런데 이렇게 하는 것보다는, 끝에서 살짝 공간을 띄운 채로 꽂아 놓아야 책에 습기가 차는 걸 막아 준다고 하네요.
단점이라면, 책을 넣고 뺄 때마다 일렬로 정렬하려면 신경을 써야 한다는 점
책에 습기가 차면 곰팡이와 책벌레 등이 스멀~스멀~(-_-+) 음험한 자태를 드러내니 습기가 없을수록 좋습니다. 3. 북 커버를 씌워 관리하자.
북 커버를 아시나요?
주변 사람들에게 물어보니 아는 사람도 있고, 모르는 사람도 있더군요. 북 커버가 아직까지는 크게 대중화되지 않은 듯합니다.
북 커버는 우리말로 하면 '책싸개' 정도가 되겠습니다.^^
말 그대로 책 겉면에 커버를 덮어 표지가 상하는 것을 방지하는 것인데, 파는 곳이 생각보다 많습니다. 다만 모양과 크기가 한정된다는 것이 단점이라고나 할까요-_-;; 흔히 나오는 북 커버는 보통 신국판이라고 하는, 가로 152mm 세로 226mm 정도 크기의 소설책을 감싸기 좋습니다. 그러니 프로그래밍 도서처럼 큰 책들을 보호하기가 힘들지요.
(그런데 왜 소개했냐고 물으신다면, 그냥 화~악...상처 입습니다.ㅠ_ㅠ)
또 개인적으로는 이 북 커버들이 너무 ‘예쁘다’는 불만이 있습니다. 네, 너무 예쁘죠. 사진을 보시고, 스스로 이 커버를 씌운 책을 손에 든 모습을 상상해 보세요!
오옷.. 정말 좋은 정보네요.^^
책을 눕히면 단점이 하나 더 있더군요.
공간 효율을 위해 마구 올려서 사용했더니 책장이 무너지는 불상사가..;;;;
거기에 뺄 때마다 위의 것을 신경써야해서 '아.. 이래서 큐와 스택이 random access에 안 좋구나.'라며 컴공과 출신 티를 내는 생각까지 합니다.;;;;
결론 : '책은 소모품이다.'(응?!)
현재 책벌레 알레르기가 있어서 종이 질이 안 좋은 오래 된 책을 만지면 손과 팔이 빨갛게 변하면서 간지럽더군요.
그렇기에 더더욱 책은 소모품이라는 생각을 하는 것인지도...;;OTL...
22. Alistair Cockburn / Agile Software Development: The Cooperative Game (2nd Edition) / 2006 (절판 - Agile 소프트웨어 개발 / 2002)
23. Gary McGraw / Software Security: Building Security In / 2006
24. Gregor Hohpe, Bobby Woolf / Enterprise Integration Patterns / 2003
25. Tom DeMarco / The Deadline: A Novel About Project Management / 1997 (데드라인 / 인사이트 / 2004)
26. Craig Larman / Agile and Iterative Development: A Manager's Guide / 2003
27. Eric A. Marks, Michael Bell / Service-Oriented Architecture: A Planning and Implementation Guide for Business and Technology / 2006 (SOA 서비스지향아키텍처 / 엠플래닝 / 2007)
28. Thomas H. Cormen, etc. / Introduction to Algorithms, Second Edition / 2001 (Introduction to Algorithms / 한빛미디어 / 2005)
29. Thomas Erl / Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services / 2004 (SOA : 서비스 지향 아키텍처 / 성안당 / 2007)
30. Martin Fowler / UML Distilled: A Brief Guide to the Standard Object Modeling Language (3rd Edition) / 2003 (UML Distilled / 홍릉과학출판사 / 2005)
31. Kent Beck / Extreme Programming Explained: Embrace Change (2nd Edition) / 2004 (익스트림 프로그래밍 2판 / 인사이트 / 2006)
32. Alan Shalloway, James Trott / Design Patterns Explained: A New Perspective on Object-Oriented Design (2nd Edition) / 2004 (절판 - 알기 쉬운 디자인 패턴 (1판) / 피어슨 / 2003)
33. Grady Booch, etc. / Object-Oriented Analysis and Design with Applications (3rd Edition) / 2007
93. Douglas Schmidt, etc. / Pattern-Oriented Software Architecture Volume 2: Patterns for Concurrent and Networked Objects / 2000
94. Michael Lopp / Managing Humans: Biting and Humorous Tales of a Software Engineering Manager / 2007 (IT 개발자가 쓴 통쾌한 인간관리 이야기 / ITC / 2009)
95. Paul Graham / Hackers and Painters: Big Ideas from the Computer Age / 2004 (절판 - 해커와 화가 / 한빛미디어 / 2005)
96. Philippe Kruchten / The Rational Unified Process: An Introduction (3rd Edition) / 2003
(The Rational Unified Process: An Introduction 2판 / 인터비젼 / 2003)
97. Joel Spolsky / The Best Software Writing I: Selected and Introduced by Joel Spolsky / 2005 (조엘이 엄선한 소프트웨어 블로그 베스트 29선 / 에이콘 / 2006년)
98. James O. Coplien, Neil B. Harrison / Organizational Patterns of Agile Software Development / 2004
99. Esther Derby, etc. / Agile Retrospectives: Making Good Teams Great / 2006 (애자일 회고 / 인사이트 / 2008)
100. Henry S. Warren / Hacker's Delight / 2002 (해커의 즐거움 / 피어슨 / 2006)
당첨되신 분들 모두 축하드리고, 키트를 받으실 주소와 전화번호(!)를 비밀 댓글로 남겨주세요~!
아울러, Twtpoll에 참여한 분들 중 『손에 잡히는 아두이노』를 받으실 세 분을 추첨해야 했는데... 제가 twtpoll.com의 서비스를 잘못 이해하여 투표하신 분들의 명단을 파악하지 못하게 되어버렸습니다. 나중에라도 업그레이드 플랜을 사용하면 명단을 파악할 수 있는 줄 알았으나, 플랜 적용 이후부터 기록이 남는다는 사실을 알았을 땐... oTL...
하여 투표를 하신 분들이 양심 선언으로 비밀 댓글을 달아주시면 추첨을 통해 책을 보내드리겠습니다. 번거롭게 해드린 점 사과드립니다.
리스프 언어 가운데 흔히 접할 수 있는 것이 커먼 리스프(common lisp)와 스킴(Scheme)이지요. 아마 클로저(clojure)를 생소하다 느끼는 분들이 많을 듯합니다.
클로저가 특징으로 내세우는 점을 설명하면...
-. 자바 가상 머신에서 활용 가능하다.
-. 최신 리스프라는 이점을 최대한 살려, 리스프가 지닌 표현력과 확장성은 그대로 유지하면서 괄호가 적은 리스프로, 리스프 언어를 처음 접하는 사람이 겪는 어려움을 덜었다.
커먼 리스프와 어떤 차이가 있는지 (유찬우 님의 답변을 빌려) 간단히 설명하면...
-. 커먼 리스프가 지니고 있는 개념들은 대부분 지녔고, 오히려 커먼 리스프가 내장하고 있지 않은 개념들(lazy evaluation, concurrency, pure functional language)을 추가로 포함한다. 그렇기 때문에 클로저를 먼저 보고 커먼 리스프를 본다면 새롭게 익혀야 되는 개념이 OOP 정도가 전부인 반면, 커먼 리스프를 보고 클로저를 보면 익혀야 할 새로운 개념들이 조금 더 있는 편이다.
-. 클로저에서 자바에 접근하는 것이 커먼 리스프에서 C에 접근하는 것보다 훨씬 편하고 직접적이다.
클로저가 자바 상용구를 그대로 갖다 쓰듯이 커먼 리스프도 C 라이브러리를 사용할 수 있다. 그러나 커먼 리스프의 경우 C 라이브러리를 호출하는 부분의 앞뒤에 어떤 처리를 해야 하는데, C와 리스프 코드를 섞어 코딩하게 되어 코드가 장황해지는 면이 있다. 반면 클로저는 자바를 바로 호출하는 느낌이다.
요는 리스프가 지닌 대다수 개념이 담겨 있으니 리스프를 이해하기에 좋다는 것, 자바에서 쓰던 상용구들을 그대로 갖고 와 쓸 수 있어 실용성이 높다는 것이지요.
클로저를 보며 드는 느낌은 ‘리스프에서 느끼는 두려움을 한층 수월하게 넘게 해주는 리스프 언어’였습니다.
클로저를 통해 ‘리스프는 어렵다’ ‘실용성이 없다’는 생각에 변화가 있기를 기대해 봅니다. :)
덧: clojure가 과연 무슨 뜻일까요? 어디를 봐도 clojure라는 단어의 뜻을 명료하게 밝혀주는 자료를 찾기가 힘들더군요. 아시는 분 계시다면 알려주세요~!
(『프로그래밍 클로저』의 번역자이신 유찬우 님께서는 함수형 언어에서 가장 많이 쓰이는 데이터 타입인 closure에 Java 기반의 리스프라는 의미를 덧대어 Clojure라고 한 것은 아닐까 추측해 주셨어요.)
덧2: 유찬우 님께서 '클로저 실행환경 설정하기'라는 글을 직접 써 주셨습니다. 상단에 파일을 첨부했습니다. 클로저를 공부하기 전 잊지 말고 꼭 참조하세요 :)
"""It's a pun on the closure programming construct (and is pronounced identically). I wanted a name that involved C (CLR), L (Lisp) and J (JVM). There were no search hits and the domain was available - what's not to like?"""
책이 잘 나갔으면 하는 바램입니다. Common Lisp과의 비교는 절반만 맞다고 볼 수 있습니다. 만일 JVM 에서 Lisp이 필요하면 Clojure가 답이겠지만, 그럴 필요가 없다면 Common Lisp이 더 나을 수 있겠죠. 더군다나 현존하는 구현들은 꽤 오랜 세월동안 광범위하게 검증되며 향상되었기 때문에 Clojure와 Common Lisp 구현물들을 비교한다는 것은 별 의미가 없다고 할 수도 있습니다.
아~~ 매니아스러운 책을 발간하려던 건 아니었는데... ㅜㅠ
Lisp을 다루는 책이 한권은 있었으면 했습니다.(물론 뒤지면 오래전 발간된 책이 있지만)
Common Lisp과 Clojure를 두고 이리저리 고민/검토하다 Clojure 책을 발간하긴 했는데, 사람마다 조금씩 이견은 있을 듯합니다.
하루가 다르게 수많은 제품이 쏟아져 나옵니다. 저마다 멋진 광고 카피와 문구로 치장하고 말이죠. 사용자의 삶을 더욱 편하게 해주고 복잡한 문제를 해결해 준다고도 합니다. 세상을 더 나은 곳으로 이끈다고 떠들어 댑니다. 하지만 정작 살아남는 제품은 많지 않다는 걸 깊게 생각하지 않아도 우린 금방 압니다. 약속을 지키는 제품도 거의 없다는 것도요. 왜 그럴까요? 제품의 개발과정에서 기술에만 너무 지나치게 집착하는 건 아닐까요? 사용자 경험이 충실히 살아 있는 우아한 디자인의 상실 혹은 부재 때문은 아닐까요?
디자인이 중요하다는 시선은 이미 오래된 시점입니다. 그러나 그 중요성에 비추어볼 때 우리의 디자인은 아직도 과거를 살고 있습니다. 설상가상으로 다가오는 미래의 디자인 문제는 훨씬 더 복잡할 거라고 합니다. 미래의 디자인은 전통적인 디자인과는 다른 무언가가 필요하다고 들 합니다. 그에 맞는 디자인 방식을 찾느라고 분주합니다. 그렇다고 과거의 디자인 방식을 모두 버릴 필요가 있을까요? 과거의 것이라도 새로운 기술을 더하고 배우고 익힌 능력을 보태, 더욱 발전시켜야 하지 않을까요?
무어라도 중요한 건 디자인이 바람직해야 한다는 것일 겝니다. 디자인이 과학적이고 합리적이어야 하고 인간의 감성에 충실해야 한다는 말이겠죠. 디자인이 그럴려면 접근하는 방식도 그래야 합은 불문가지죠. 사용자경험이 개발 과정에서 효과적으로 융화되려면 아이디어를 내는 과정에서부터 주의를 기울여야 합니다. 스케치 기법은 번뜩이는 아이디어가 새로운 기술과 만나 이런 디자인으로 탈바꿈하는 데 아주 좋은 방법입니다.
또한 여기서 중요하게 집고 넘어가야 하는 게 있습니다. 사회와 문화에 좋은 가치를 부여하고 공동체에 공헌하는 디자인을 찾고 만들어내는 일 말입니다. 빌은 한 인터뷰에서 이렇게 말했습니다.
디자인과 이노베이션이 우리의 삶의 질을 향상시키는 게 목적이라면 사회, 문화, 현존하는 생태계를 생각하지 않고는 그 목적을 달성할 수가 없다. 이노베이터라면 이런 문제를 자신의 DNA에 새겨 넣을 정도가 되어야 한다... 그러면 혁신으로 가는 길은 환하게 밝을 것이다.
『사용자 경험 스케치sketching user experience』에 이 모든 내용이 포함되어 있습니다. 훌륭한 제품을 디자인하는 바른 방식 말입니다. 그리고 디자인과 디자인적 사고를 깊이 있게 하는 것 말입니다. 저자의 다양한 경험과 풍부한 통찰 그리고 깊은 학문적 성찰이 넘쳐납니다. 멋진 상상력을 발휘하도록 자극도 합니다. 새로운 기술로 멋진 사용자경험을 설계할 수 있게 합니다. 디자이너는 물론 디자인 과정에 함께 참여해야 하는 모든 이에게 아주 유익합니다. 디자이너와 사용성 전문가, HCI 전문가, 프로젝트 관리자, 경영진 모두에게 말이죠. 내용은 대략 이렇습니다.
스케치와 초기 프로토타입을 제작하는 디자인 방법론을 소개한다. 인터랙티브 제품을 디자인할 때 필수적인 방법론이다. 다른 기계와 직접 소통하는 핸드폰이나 스스로 생각하는 가전제품 등 상상만 하던 제품을 풍성하게 디자인한다.
여러 스케치 방법론을 알아본다. 경험 프로토타입을 쉽게 제작할 수 있는 방법이다. 시간과 비용이 많이 들어가는 정교한 프로토타입을 만들지 않고도 사용자경험 디자인을 체험해 볼 수 있다.
다양한 분야의 디자이너에게 도움이 되는 정보를 제공한다. 사용자 인터페이스 디자이너는 물론 산업 디자이너, 소프트웨어 개발자, 사용성 전문가, 프로젝트 관리자 등 누구나 참고할 수 있다.
다수의 케이스 스터디와 예시, 연습, 프로젝트를 소개한다. 디자인 문제에서 제기되는 중요한 원칙과 방법을 설명한다. 직접 감상할 수 있는 동영상도 있다.
마지막으로 번역하시느라 무척 고생하신 고태호, 유지선 님의 글 올립니다. 수고 많으셨습니다.
----
어릴 적 매달 초에는 항상 즐거운 고정 행사가 있었다. 지난달 달력을 주욱 찢어내는 일이다. 마루바닥에 커다란 달력 종이를 엎어놓고 연필로 이것저것 그려대곤 했다. 구석에 조용히 괴어 있는 바위 같은 것을 그린 적은 한 번도 없다. 선과 도형이 한데 엉켜 지구를 지키는 로봇이 되기도 하고, 공주를 구하러 가는 용사가 되기도 했다. 낙서는 항상 움직이고 역동적인 것이었다. 사용자 경험의 스케치도 마찬가지다. 사용자 인터랙션은 시간에 따른 행동의 변화를 다룬다. 책상에 앉아 정지된 인터페이스 화면 두어 장을 그리는 것이 과연 진정한 UX 디자인이라 할 수 있을까? UX 디자이너에게 있어 스케치란 과연 무엇일까?
사용자 경험 스케치에서 저자 빌 벅스턴은 야생에 뛰어드는 것이 사용자 경험 스케치의 출발점이라고 주장한다. 디자인의 실제 상황 속으로 뛰어들어 사용자를 직접 만나고 관찰할 때 진정한 UX 디자인이 시작되는 셈이다. 사용자 경험을 고려하는 제품과 서비스가 많아지면서 기쁜 마음을 감출 수 없다. 하지만 한편으로는 UX라는 말만 유행처럼 번지면서 제대로 된 방법론은 도입하지 않는 현실이 씁쓸하기도 하다. 저자는 “UX 디자인은 아무나 하는 것이 아니다”라며 속 시원하게 꼬집는다. 디자인 중간 작업물을 개인의 예술 작품처럼 여기면서 공유를 꺼려하는 디자이너의 어리석은 태도에도 신랄한 비판을 가한다.
이미 인터랙션 분야에 충분한 지식을 갖춘 전문가에게도 새롭게 생각할 만한 주제를 던져준다. 일례로 저자는 ‘미래’라는 말이 복수형으로 쓰여야 한다고 주장한다. 우리 앞에 놓여 있는 미래는 결코 하나가 아니기 때문이다. 가능성은 얼마든지 열려 있다. 여러 ‘미래들’이 가능하다. 저자는 다시 말한다. 깨어서도 꿈을 꾸자고. 1부의 제목 ‘꿈을 쫓는 디자인’이란 그런 의미를 담고 있다. 많은 미래를 꿈꾸고 그려내는 것이 스케치라면, 그 가운데 우리가 진정으로 원하는 미래를 ‘선택’하는 것이 디자인의 최종적인 목표일 것이다.
더보기
책의 2부에서는 전문적인 UX 디자이너가 숙지해야 할 유용한 방법론을 소개한다. 평범한 학생 작품부터 저명한 디자이너의 기념비적인 프로젝트까지 무척이나 다양한 실무 사례가 담겨 있다. 얼마나 많은 이들이 얼마나 ‘별난’ 미래들을 꿈꿔왔는지, 그리고 얼마나 기발한 방법으로 실현해나갔는지 현학적 말투로 설명하기보다는 디자이너의 생생한 ‘경험담’으로 들려준다. 경험을 디자인하는 과정 그 자체가 바로 흥미로운 경험인 셈이다.
빌 벅스턴은 상당히 예술적인 관점에서 UX 디자인의 방법론을 소개하고 있다. 하지만 컴퓨터공학 분야에 깊은 조예가 있어, 이를 바탕으로 휴먼 컴퓨터 인터랙션HCI, Human-Computer Interaction분야에 ‘피츠의 법칙’을 도입한 장본인이기도 하다. 멀티터치 기술로 유명한 퍼셉티브 픽셀Perceptive Pixel의 제프 한Jeff Han은 빌 벅스턴이 70년대 후반에 소개한 터치 인식 인터페이스에서 큰 영감을 받았다고 소개한 바 있다. 이 책은 기술적으로 깊은 수준의 정보를 제공하는 한편, 디자인 측면에서도 날카로운 눈을 유지할 수 있는 효과적인 접근법을 제시한다. 동시에 이 책은 UX의 대가가 들려주는 한 편의 즐거운 수다이기도 하다.
사용자 경험 스케치와 함께 전문적인 UX 분야에 한 걸음 더 다가서 보자. 사용자 경험의 새로운 도약을 기대한다.
기억은 불완전한 것이다. 심지어 변조되기도 한다. 기억을 소재로 하는 몇몇 영화를 보면 기억이란 것을 정말 믿을 수 있나 하는 의문이 들 때도 있다.
이런 관점에서 보면 기억의 효용성은 0에 가까울 것이다. 하지만 기억을 떠올린다는 것이 과거 경험을 단순히 반복 재생하는 것만은 아닌 것 같다. 대부분의 경우 현재의 필요와 연관되어 있고 때로는 기억에 대해 의미나 가치가 부여되고 재해석되기도 한다.
근대적인 역사 서술 형태가 나타나기 이전, 역사에 해당한다고 볼 수 있는 형태의 텍스트들은 신화나 전승이었다. 그저 상상 속의 옛이야기일 뿐이라고 가볍게 넘길 수도 있지만 이런 형태의 텍스트들이 수세기에 걸쳐 살아남을 수 있었던 힘은 IT 세계 용어를 빌려 표현하자면 풍부한 상상과 재해석의 여지를 주는 ‘확장성과 유연성’에 있지 않나 하는 생각이 들 때가 있다.
며칠 전 짠 코드도 가물가물한 마당에 20여 년 전 이야기를 끄집어낸 매킨토시(이하 맥) 개발자들에게 그 시절 그 일들은 어떤 의미를 지니고 있는 것일까?
‘민간전승’이 활자로
『미래를 만든 Geeks』(원제:Revolution in The Valley)는 1984년 출시된 첫 번째 맥 개발팀의 일원이었던 앤디 허츠펠드(Andy Hertzfeld, 맥 운영체제의 주요 시스템 소프트웨어 개발자)의 프로젝트였던 folklore.org에 실린 글이었다. folklore.org는 ‘역사적인 한 사건을 여러 사람이 함께 이야기하는(collective historical storytelling)’ 사이트로 그 첫 번째 프로젝트가 맥 개발 일화였다. folklore란 이름 그대로 당시 역사의 한가운데 있던 사람들의 ‘민간전승(傳承)’이었는데 이를 오라일리에서 출판한 것이다(편집 과정에서 앤디 허츠펠드가 생각했던 제목은 『Macintosh Folklore』였는데 오라일리 편집팀의 아이디어로 『Revolution in The Valley』으로 정해진 것이라고 한다). 참고로 책으로 옮기는 과정에서 몇몇 일화들은 빠졌기 때문에 좀더 관심이 있는 독자들은 folklore.org와 책을 비교해 보는 것도 좋을 것이다
국내에 수입될 가능성이 없어 보여 미국에 출장 가는 분을 통해 이 책을 입수했다. 책을 받아 펼치자 박물관 같다는 느낌이 들었다. 그 때 그 시절 개발진 사진들과 지은이앤디가 당시에 썼던 노트에 적힌 그림과 메모를 스캔한 사진들, folklore.org에 참여한 다른 필진들의 커멘트 등 나름대로 손색이 없는 ‘1차 사료’가 아닐까 하는 생각도 들었다.
책은 크게 다섯 부분으로 나눠져 있다. 첫 번째 부분에서는 앤디가 베스트 프렌드인 버렐 스미스(Burrell Smith, 맥의 하드웨어 부분 핵심 설계자, 이하 버렐)를 알게 되고 앤디가 맥 팀으로 옮기기까지의 과정을, 두 번째 부분에는 수차례 중단될 뻔한 보잘 것 없던 프로젝트가 자리를 잡기까지의 이야기들을, 세 번째와 네 번째 부분에는 각각 개발 중후기 일화들을, 다섯 번째 부분에는 열정의 시대의 종언을 다루고 있다.
전설의 이면
월간 마이크로소프트웨어 「안윤호의 IT 인물 열전」에서도 몇 차례 소개됐지만 맥 개발은 처음부터 대단한 후광을 업고 시작된 것이 아니었다. 1980년 당시 팀원 네 명뿐이었던 이 프로젝트는 그 해 가을에 아예 중단될 위기에 처하기도 한다. 노련한 엔지니어와 조직적 마케팅 인력이 투입된 리사와 사라와는 인적 구성도 비교할 수 없었다. 보드 개발자인 버렐은 애플의 서비스 테크니션이었고 핵심 그래픽 컴포넌트를 개발한 빌 앳킨슨(Bill Atkinson)은 리사 팀 소속으로 틈틈이 맥 팀을 돕는 1인 2역을 하고 있었다. 개발자들의 매니저 격인 버드 트리블(Bud Tribble)은 휴학중인 대학원생이었다.
승부 근성과 감각을 갖춘 도박사(?) 스티브 잡스(Steve Jobs)가 끼어들면서(비록 원래 팀 리더였던 Jef Raskin이 쫓겨나기는 했지만) 프로젝트는 스티브 잡스의 전폭적인 지지 속에 추진되고 악전고투를 거쳐 그 유명한 슈퍼볼 시합의 ‘1984’ 광고와 함께 맥은 세상에 그 모습을 드러낸다.
하지만 책 제목과 달리 세상에 혁명이란 것은 일어나지 않았다. 회사 조직이 커지면서 생긴 불협화음으로 인해 앤디와 버렐을 비롯한 맥 핵심 개발자들이 애플을 떠났고 이후 맥 역시 초창기의 인기를 계속 이어가지 못했다.
워너비들의 철없는 열정
이 책을 관통하는 일관된 주제는 무엇 하나 변변하게 내세울 것 없는 ‘이들을 움직였던 원동력’에 있다. 앤디가 회상하듯이 그들의 작업은 1960년대의 이반 서덜랜드(Ivan Sutherland)와더글라스 엥겔바트(Doug Engelbart)의 비전, 1970년대의 제록스 PARC와앨런 케이(Alan Kay)의 노력, PC라는 몽상을 꿈꾸었고 실현한 홈브루 클럽의 스티브 워즈니악(Steve Wozniak), 맥 프로젝트를 시작한 제프 라스킨(Jef Raskin)의 연장선에 있고 이들은 모두 그들과 같이 되기를 꿈꾸는 워너비들이었던 것이다.
물론 이 워너비들이 바라던 세상은 오지 않았다. 더욱이 1960~70년대의 비저너리들이 꿈꾸던 세상에 되려면 가야 할 길은 멀어 보인다. 그럼에도 불구하고 옛 이야기를 다시 꺼내는 이유는 아마도 스티브 워즈니악이 쓴 『미래를 만든 Geeks』의 추천사에서 찾을 수 있을 것 같다.
그들이 쓴 글과 그림을 보며, 혁신의 규칙이 돈이 아니라 내면의 보상에 의해 이끌어지던 매우 좋았던 시절로 돌아갈 수 있었다.
거대기업과 자본으로 공고해진 이 세계에서 지금도 어느 한 구석에는 새로운 워너비-뉴비-들이 등장하고 있고 역전의 워너비-올드보이-들 이 해줄 수 있는 이야기는 그들에게 새로운 영감이 될 것이다.
아마도 스토리텔링의 마력(또는 매력)이 무언가를 끊임없이 전염시키며 자신을 확대, 재생산하는 데 있다면 『미래를 만든 Geeks』는 그러한 측면에서 가치가 있는 책이다. 진정한 혁명은 아직 오지 않았지만 혁명을 꿈꾸는 자들은 곳곳에 숨어있다.
P. S. 위의 글은『미래를 만든 Geeks』를 번역하신 송우일님이 월간「마이크로소프트」에 쓰신 내용을 옮긴 것입니다.
원서의 제목은 『Revolution in the Valley』입니다. 기록을 뒤져보니, 2007년 7월 경 원서를 입수해 검토를 시작했더군요. 어느 책이라고 사연이 없겠습니까만, 이 책에도 기억할 만한 몇 가지 에피소드가 있습니다.
1. 발간 유보 - 2007년 8월
샘플 책을 받아들고 스티브 워즈니악의 추천사, 저자 후기 등등 몇 개 장을 샘플로 번역(요청)해 검토를 시작했으나 맥 개발과 관련한 재미있는 에피소드의 나열 정도로 판단했던 듯합니다.
그렇다고 제목에서 뭔가 '필'이 오지도 않고 - Valley에서 일어난 혁명 - 맥 사용자가 아닌 저희 같은 사람들에게 부제가 확~ 다가오는 것도 아니어서 - The Insanely Great Story of How The Mac Was Made, 매킨토시는 어떻게 만들어졌나 - 말입니다.
아시다시피 국내의 맥 사용자는 극히 소수이고, 2007년 당시엔 요즘 같이 화제의 중심에 있진 않았고, 인사이트가 2007년 9월 『코코아 프로그래밍(1/E)』을 발간하자, 이런 책도 국내에 나오는구나 하고 신기해 하신 분이 계실 정도였으니까요.
게다가 몇 안되는 맥 사용자 중 다수는 그래픽, 편집 등등의 영역에 계신 분들이어서 매킨토시가 어떻게 만들어졌는지 관심을 가질만한 사람이 얼마나 될까 하는 생각이었거든요. (프로그래머 층에서 맥북 사용자가 조금씩 늘고 있는 건 눈에 띄었습니다.)
실제 매킨토시 사용자 층을 잘 아시는 분께 여쭤보니
대략 국내 맥 사용자 수는 15만 명, 그 중에서 진짜 맥 사용자 수는 5만 이하. 아직 맥을 하나의 컴퓨터라기보다는 작업용 컴퓨터로 생각하는 사람이 많은데 그런 층에서 'Revolution in the Valley' 같은 책을 사주리라 기대하기는 힘들 것 같다.
라는 답을 들었구요.
책 내용이 워낙 좋아 분명 다른 층에서도 깊은 관심을 가질 만하고 적절한 홍보만 곁들여진다면 저번에 민음사에서 출간했던 'iCon'처럼 잘 팔릴 가능성도 없지는 않다.
라는 의견이 덧붙어 있긴 했지만, 저희가 민음사 같이 '적절한 홍보'를 해낼 조건은 아니지요. ㅎㅎ
대상독자가 좁을 것 같다는 의견도 중요했지만, 당시로선 소위 콘셉트를 잡지 못했던 듯합니다. 즉, 독자는 이 책에서 어떤 가치를 얻게 될지(인사이트는 어떻게 제시할지)까지 정리하지 못했다는 거죠.
그러면서 책 검토는 일단락 되었습니다. 발간 않기로 한 거였죠.
그렇다고 완전히 포기한 것도 아니라 원서는 출판사 이곳저곳을 떠돌고 있었습니다. 이 편집자의 손에서 저 편집자의 손으로....
2. 제목 논란 - 매킨토시를 전면에 내세울 것인가?
『미래를 만든 Geeks(긱)』은 매킨토시 탄생을 배경으로 이야기를 전개합니다. 1979년 제프 라스킨이 아이디어를 내고 프로젝트를 시작했을 때부터, 1985년 스티브 잡스가 존 스컬리에게 쫓겨날 때까지.
(스티브 잡스는 펩시콜라 CEO이던 존 스컬리를 다음과 같은 유명한 말로 설득해 데리고 왔다고 하죠. "남은 일생 동안 아이들에게 설탕물이나 팔 건가요, 아니면 세상을 바꿀 기회를 붙잡고 싶은가요?")
때문에, 매킨토시를 전면에 내세운 수많은 제목 시안들이 검토 회의에 올라왔습니다. 몇 가지만 소개하면,
열정으로 혼을 불어넣은 매킨토시 탄생 비화
미친 열정으로 탄생한 매킨토시
매킨토시, 위대한 탄생
한편으로 다른 의견이 제기되었습니다. '매킨토시' 자체보다는 '그걸 만든 사람'을 얘기해야 하는 거 아닐까? Geeks이 나온 이유입니다. 한글로 '긱 혹은 긱스'라고 표기하면 너무너무 어색할 듯해 할 수 없이 영문으로.
한편 이 논란은 현재진행형이기도 합니다.
1984년 매킨토시의 탄생은 개인용 컴퓨터 역사에 혁명적인 사건이라 할 수 있는데, 원제가 더 나았다.(맥 관련 잡지 전 편집장님 등)
애플 바깥의 사람들이 취재해 만든 여타 책들과 달리 (어쩌면) Revolution in the Valley는 매킨토시의 정사(正史)라 할 수 있는데, 매킨토시를 전면에 세웠어야 하는 거 아닐까.
원서 자료들은 애플의 창고를 뒤져 나온 귀중한 자료들인데, 그걸 온전히 살렸을 때만 의미가 깊다. (트위터에 올라온 댓글)
등등 말입니다. (잘 뒤지면 "인사이트 책이라 역시 제목부터 맘에 안듭니다."는 의견까지 있습니다. ㅜㅠ)
주로 매킨토시를 개인용 컴퓨터로 오래 사용하고 애정이 깊은 분들께서 제기하시는 듯합니다.
3. 제목 변경 - 세상을 뒤흔든 Geeks
혼선을 거듭하며 수차례 제목/부제를 논의하던 중, O'Reilly는 왜 Revolution이라고 표현했을까 하는데 시선이 갔습니다. 컴퓨터의 역사에 밝은 분들이라면 바로 아하! 하겠지만, 저희가 제목 논의를 할 때만해도 그 의미가 바로 들어오진 않았거든요.
'혁명적인 변화' 그걸 표현할 수 있는 단어는 뭐가 있을까 논의 끝에 '세상을 뒤흔든'이란 아이디어가 나왔고, 드디어 제목이 완성되었습니다. ('세상을 뒤흔든'이란 수식이 역사서 등엔 몇몇 쓰였기에 완전히 독창적이라 얘기할 수는 없지만, 그대로 써도 무리 없겠다는 판단을 했죠.)
제목이 결정되었으니, 표지를 발주하고, 마감을 서두르는데 청천벽력 같은 소식이 날아들었습니다. 『세상을 뒤흔든 프로그래머들의 비밀』이란 책을 정보문화사에서 발간한 겁니다. 순간 아득해졌습니다. 세상을 뒤흔든 Geeks이란 제목을 뽑기 위해 얼마나 많은 시간 고생했는데, 그걸 처음부터 다시해야 한다니.... 그리고 더 나은 제목이 과연 나올까 하는 의문.
시간은 지나고 아이디어는 없고, 마감은 다가오고, 새로 회의를 해도 맥이 빠지기만 하던 어느날 하릴없이 편집 최종본을 넘기는 데, 문득 앨런 케이(Alan Kay)의 글이 새삼 크게 다가 왔습니다.
'미래를 예측하는 가장 좋은 방법은 미래를 만드는 것이다(The best way to predict the future is to invent it).
----
난산 끝에 책이 나왔습니다. 꽤 방황하기도 하고 고전하기도 했고.
다행히 이 책에서 얘기하고자 한 내용은 편집(제목, 디자인 등)에서 나쁘지 않게 정리된 듯합니다. 매일경제, 서울경제, 한겨레 등에서 톱 혹은 면톱으로 기사를 실었고, 한국일보, 동아일보, 세계일보, 전자신문에서는 꽤 비중있는 기사로 처리했습니다. 인사이트로서는 처음으로 교보문고 메인 화면을 장식할 예정이구요.
책 내용은 여러 기자님들께서 정리해 주신 기사들이 검색에 올라오니 그걸 참조하시면 될 듯합니다.
무엇보다도 경험은 부족했으나 위대한 일을 하려고 했던 이 젊은이들이 오늘날 일상에서 쓰이는 핵심 기술을 어떻게 만들었는지 회상하는 것은 가슴 떨리는 일이다. 그들이 쓴 글과 그림을 보며, 혁신의 규칙이 돈이 아니라 내면의 보상에 의해 이끌어지던 매우 좋았던 시절로 돌아갈 수 있었다.
- 스티브 워즈니악(Steve Wozniak)
맥이 탄생한 지 올해로 27년째다. 시장은 고도화됐고 개발자들의 기술도 성장했지만 그 시절만큼의 낭만을 찾기란 쉽지 않아 보인다. 아직 100년도 되지 않았는데 IT 세상이 노쇠한 것일까? 특히나 각박하다는 한국에서는 1960~70년대 비저너리들이 무슨 생각을 했는지 되새길 여력도, 같은 꿈을 꿀 여유도 없는 것 같다. 하지만 IT 세계에서 흥미진진한 일들은 여전히 몽상을 좇는 다소 무모한 낭만에서 시작되는 것 같다. 직접 확인할 길은 없지만 어쩌면 아이폰 개발자들도 자신들의 선배 개발자들과 비슷한 꿈을 품었는지도 모르겠다. 한국 개발자들은 무슨 꿈을 꾸고 있을까?
하하하 제목을 뽑느라 고생 많이 하셨군요.
사실 원제가 이런데 왜 이런 타이틀로 제목을 냈을까?
하는 의문점에 구글링하다가 여기까지 왔습니다.
출판사 입장이야 책이 더 많이 읽혀지길 바라는 마음에서 나온 고육지책이겠지만요.
-죄송합니다만 현재진행형의 논란에 동감을 더 하는 편입니다.^^
-만약 제목만 봤다면 이 책을 안사게 되었을 수도 있던 사람 입장에서는요.
제목이야 어찌 되었든 오늘 교보로 책사러 갑니다.
컴 관련해서 인사이트의 좋은 도서들이
계속 많이 나오길 기대하겠습니다.
Slack. 그리 익숙치는 않은 단어죠. 느슨함, 여유 등으로 번역될 수 있는 단어인데, 일상생활에서까진 그리 널리 입에 오르진 않는 단어였죠. 그런데... 어젠 하루종일 트위터에서 Slack이란 단어를 엄청 본 듯합니다. 바로 류한석 님의 트위팅 한 줄 때문입니다.
오늘(5월 4일) 오전에 세어보니 223개의 RT가 달려 있더군요.
이 트윗 한 줄이 얼마나, 어디까지 파급되었을까요?
출판사에서 책을 발간하면서 제일 고민되는 게, 책이 발간되었다는 사실 자체를 알리는 일입니다. 아무리 좋은 책이라 해도 세상에 그 책이 있다는 사실을 독자들이 알아주지 않으면 쉽게 묻혀버리고, 실제 많은 책이 그리 사라졌으니까요. 그걸 알기에 출판사에서도 이러저런 노력을 기울이게 됩니다. 책의 성격에 따라 다양한 방식이 있겠지만 그중에서도 기본은 다음 몇 가지라 할 수 있습니다.
1. 인터넷 서점 홍보. 광활한 온라인 공간이라지만 실제는 첫눈에 보이는 한 페이지의 화면을 갖고 수많은 출판사들이 각축하게 됩니다. 어떻게든 메인 화면(분야별 메인이라도)의 스크롤 없는 첫 페이지에 노출될 수 있도록 MD들을 설득하려 하죠. 각종 광고나 이벤트가 뒤따르면 설득 가능성이 높아지긴 하겠지만, 돈이 따르지 않는 상태에서 순전히 콘텐트의 힘만으로 메인에 오르긴 그리 쉽지 않습니다.
2. 오프라인 서점 홍보. 주요 오프라인 서점, 도매서점을 방문해 책 구매 협의를 합니다. 서점은 진열공간이 창고 역할까지 하기에, 각 서점이 몇 권을 구매하는가가 홍보에 중요한 역할을 하게 됩니다. 책을 많이 구매(소위 매절이라고 하는 현금 구매)해 갖고 가게 되면, 그 책은 그만큼 해당서점에서 더 많이 노출되는 거죠. 대형서점에 가보시면 똑같은 책이 여럿 놓인 걸 보실 수 있을 겁니다. 해당 책을 많이 구매했다는 얘기죠. 물론 그렇게 하려면 책을 각 서점 담당자들에게 '설득'해야 하고, 또 공급률을 협의해야 합니다. 평상시 10,000원짜리 책을 7,000원에 공급했다면, 서점이 책을 갖고 가는 수량에 따라 6,000원이나 5,500원까지(때론 그보다도 더 낮게) 공급률 낮춰야 하죠. 오프라인 서점이 구매하는 부수 역시 '말'로 되는 게 아니라 광고/이벤트가 어떻게 붙느냐에 많이 좌우됩니다. (아~ 우울한 얘긴데.... 매대를 구입하는 경우도 있답니다. 광고비 명목으로 말이죠.)
3. 언론사 홍보. 지금은 파급력이 예전만 못하다는 얘길 하지만, 그래도 돈을 들이지 않는 가장 유력한 홍보 방식이라 할 수 있습니다. 책이 발간되면 기자들이 참조할 수 있도록 보도자료를 정성껏 만들어 각 언론사에 보냅니다. 여산통신 같이 언론사 배송대행을 이용해 책을 발송하죠. 책을 보내도 아무 때나 보내는 게 아니라 시간을 맞춰야 합니다. 보통 화요일 오후 각 언론사 서평면 편집회의가 잡히기 때문에 화요일 오전엔 기자 책상에 책이 올라갈 수 있도록 시간을 조절하죠. 그런데... 문제는 기자들 책상에 올라오는 책이 한 주에 수백 권이라는 점입니다. 출판사야 좋은 책이라고 생각해 발간했고, 자신만의 책에 자부심을 갖겠지만, 어디 세상이 그리 녹녹한가요. 흔히 하는 얘기로 기자들은 수백 권의 책을 앞에 놓고, 오른쪽 왼쪽하고 구분한답니다. 책을 열어보지도 않고, 오른쪽(혹은 왼쪽)은 보도자료라도 읽어볼 책, 왼쪽(혹은 오른쪽)은 그냥 신문사 자료실로 직행할 책. 이런 식으로 말이죠. 이 1차 관문을 넘어서야 간신히 서평면에 1단 기사라도 나올 가능성이 생기는 겁니다.
다행히 Slack은 중앙일간지 중에서는 중앙일보의 이은주 기자님께서 잘 봐주셔서, 4단 기사로 비중 있게 처리되었고,
국제신문에선 톱을 차지했다고 하는데, 아직 신문을 입수하지 못했습니다. ㅜㅠ 그 밖에 아래 신문들에서 기사가 나왔구요. 전자신문 서울경제신문 연합뉴스
트위터와 서평의 반응이 각각 어느 정도 영향을 미쳤는지는 계량할 수 없지만, 뭔가 바글바글 입소문이 생긴 효과는 분명히 있는 듯합니다. YES24에선 바로 컴퓨터 인터넷 베스트 4위로 올랐고(경제/경영으로 분야 변경을 요청했기에 내일이면 달라질 수 있습니다.) 각 서점의 주문도 조금씩 반응이 있어 보입니다.
1주일만에 1위로 올랐습니다! 감사합니다! ^^
참. 책 소개를 하지 않았군요. 저자인 톰 드마르코는 너무나 잘 아실 테고, 책 내용은 아래 두 문장으로 바로 파악하실 수 있을 겁니다.
빨리빨리 문화, 두려움(공포)의 문화를 가진 조직은 직원들에게 여러 형태로 압박을 가하는데 그런 관리 방식을 통해 단기적으로는 성과를 만들어낼 수 있을지 몰라도, 점차 많은 것을 잃게 되며 결국 조직을 망치게 됩니다. 좀 더 천천히 일하더라도 제대로 일하자는 것이 본 서적의 핵심 메시지입니다. - 류한석
웹 페이지 역할에 맞게 필요한 기능을 노출시키는 것. 그래서 사용자가 자연스러운 흐름 안에서 그 기능을 발견하고 사용하게 하는 것.
'드래그 앤 드롭'이라는 행위 못지 않게 중요한 인터페이스 디자인 고려사항이겠지요. ^^
문맥 도구는 웹 페이지의 흐름에 맞게 디자인된 기능을 뜻합니다. 사용자 입장에서 항상 보여야 편한 기능(상시 노출 도구), 마우스 오버 했을 때 노출해야 가장 적합한 기능(마우스 오버 노출 도구) 등일 텐데, 상시 노출 도구에는 대표적으로 디그 사이트의 추천 기능이 있고, 마우스 오버 노출 도구에는 플리커의 프로필 보기 기능이 있습니다.
백문이 불여일견! 웹 인터랙션 패턴 공개 그 2탄! 책에 담긴 문맥 도구 가운데서 '상시 노출 도구' 패턴과 '마우스 오버 노출 도구'를 PDF에 담아 소개합니다. :)
함께 등장하는 '안티패턴'도 놓치지 말고 꼭 살피시길 권합니다. 백배 공감 하실 겁니다^^;
문맥 도구의 가장 간단한 형태는 상시 노출 도구(Always-Visible Tools)다. 디그는 문맥도구를 상시로 노출하는 대표적인 예다(그림4-3).
눈에 보이는 도구
각 게시물 옆에는 디그 득점표가 있고, 그 아래에는 ‘추천(digg it)’ 버튼이 있다. 추천 버튼은 모든 게시물에있다. 다른 기능은 눈에 덜 띈다.
유인 요소
디그 버튼에 마우스를 올리면 테두리가 어두운 색으로 바뀌고, 버튼의 글씨도 검은색으로 바뀐다. 하이라이트는 인터랙션이 가능하다는 신호로 사용하기에 아주 효과적이다.
추천 완료
사용자가‘추천(digg it)’버튼을클릭하면, 추천수가집계된다. 현
재까지의 득표수는 희미해지고, 방금 클릭한 추천이 포함된 새로운
숫자가즉시나타난다. 추천(digg) 버튼은‘추천됨(dugg)’으로바
뀌고, 글씨가회색으로바뀌어이제는클릭할수없음을나타낸다.
그림4-3. 디그의 ‘추천(digg it)’ 버튼은 상시 노출되는 간단한 문맥도구다.
고려사항
‘추천(digg it)’ 버튼과 디그의 득점표는 각 게시물 옆에 제공되는 상시 노출 도구다.
명확한 유인 요소
도구를 감춰두었다가 게시물 위에 마우스를 올렸을 때만 보여주는 방식을 택하지 않은 이유는 무엇일까? 게시물 추천이 디그(Digg)에서 중심 태스크이기 때문에 추천 기능을 상시 노출하여 사용자 행위를 확실하게 유인하기 위함이다. 새 게시물에 적용할 수 있는 다른 기능(댓글, 공유, 반대 등)들도 있지만, 디그의 디자이너들은 이런 기능을 상시 노출하는 대신 눈에 덜 띄게 표현하였다. 기능을 보여주지 않다가 마우스를 올렸을 때나타나게 하는 방법도 있다. 이 방법에 대해서는 다음 ‘상대적 중요성’ 부분에서 다룰 것이다.
도구를 상시 노출하는 방법은 투표와 순위 시스템에서 가장 많이 사용되는 것처럼 보인다. 넷플릭스는 클릭한 번으로 이루어지는 순위 시스템을 처음으로 선보인 사이트다(그림4-4).
댓글을 달아 주세요
그래도 한 줄, 한 줄 친절하게 나와 있다니 다행이네요
다름이 아니라 상단에 이미지 몇개가 나오질 않아 댓글 남겨요
앗, 이렇게 빨리 리플이...^ ^
알려주셔서 감사합니다. 수정했는데 잘 보이나요? ^ ^
스케치 시작 부분과 짠~ 불이 들어왔다는 부분이 여전히 안보이지 않나요?
아이공, 다시 수정했습니다. ^ ^
파이어폭스에서 이미지 업로드하면 안 되겠군요; ㅠ_ㅠ
번거로우실 텐데 친절하게 덧글 남겨주셔서 정말 감사합니다. 좋은 하루 되세요~!
저는 JavaScript를 이용해서 아두노이를 제어해보려고 책을 구매해서 보고있는데
조만간 멋진 성과물 기대해주세요 :)
좋은책 번역해주신분에게도 감사드리고 인사이트에도 감사드려요.
와우~ 기대하겠습니다.