레이블이 일하다인 게시물을 표시합니다. 모든 게시물 표시
레이블이 일하다인 게시물을 표시합니다. 모든 게시물 표시

2010년 4월 19일 월요일

알라딘 아이폰 앱 유감

기대가 크면 실망이 크다지만, 이건 실망이라기 보다는 허탈에 가까운 앱이라 하겠다.

알라딘 앱 기획자가 누구인지 모르겠으나 진짜로 물어보고 싶다. 어떤 소비자를 대상으로 하냐고.

"음, 우아하게 스타벅스에서 한잔 마시면서, 혹은 버스타고 집에 가는 도중에 왠지 심심해져서 아이폰을 꺼내들고 알라딘 앱을 띄운 다음 베스트셀러나 신간특선이나 추천도서나 특가도서나 대충 훑어보다가, 어, 웬지 이거 끌리네, 하고 장바구니에 담은 다음, 결제를 한다..."

세상에, 누가 그렇게 책을 사나? 얼핏 책이 충동구매 같아 보여도, 책이야 말로 사람들이 가장 심사숙고(?)하는 상품이다.

(아이폰에 알라딘 앱을 설치할 만큼 도서구매에 관심있다면) 책을 구매하는 사람들은 대개 다음 패턴 중의 하나로 책을 구매한다.

1) 이미 사야 하는 책을 알고 있다. - 업무용이든, 교재든, 누군가의 추천이든, 정확하게 무엇을 사야한다라는 것을 알고 있는 경우들. 이런 경우 필요한 기능은, 해당 책에 얼마나 정확하고 빠르게 도달시켜주느냐가 중요하다.

2) 비슷한 책을 찾는다. - 좁게는 카테고리에서, 넓게는 다른 사람의 선택이나 관련있는 책 목록까지. 무언가에 대한 책이 필요는 한데, 정확하게 알지는 못한 상태에서는 검색으로부터 시작하여 관련 책들을 찾아나가는 탐색경로 및 평가지표가 필요하다. 알라딘은 특히 이 부분에 대해 웹서비스가 아주 강한 장점을 보이는데, 앱에서는 전혀 그러한 장점을 살리지 못했다.

3) 이미 경험했던 작가나 시리즈, 장르를 찾는다. - 1),2)가 목적성이 강하다면, 유희나 취미의 단계에서의 책의 구매는 이러한 패턴을 보인다. 따라서 해당 작가의 신간이라든가, 혹은 비슷한 취향의 다른 사람들의 데이터라든가 하는 정보가 가장 중요하다.

4) 개인화가 중요하다. - 알라딘 앱을 자발적으로 설치할만큼의 열성적인 독자/구매자라면 베스트셀러라고 해서 무조건 구매하지도 않고, 사은품을 많이 준다고 구매하지 않는다.(사려고 하는 책에 사은품이 들어있으면 고마울뿐.) 남들이 무엇을 보건 간에, 나에게 그 책이 어느 정도의 가치를 가지느냐가 책 구매에 중요한 지표가 된다. 1Q84가 아무리 많이 팔리건, 하루키를 싫어하는 사람이라면 쳐다보지 않을 것이며, 한편 하루키 팬이라면 1Q84가 베스트셀러가 아니라 하더라도 구매할 것이다. 물론 베스트셀러라 하여 혹하는 독자들도 있겠으나, 그런 정도의 독자가 과연 알라딘 앱을 설치할 것인가?
기존 알라딘 웹에서는 보관함 및 마이서재가 그 역할을 담당했고, 지금은 사라졌지만(?) 마이알라딘도 톡톡한 역할을 했었는데 흠....



사실 실제로 카드번호 입력하는 결제 단계는 도서구매자에게는 그다지 중요하지 않다. 결제를 결심하게끔 만드는 게 중요한 것이지. (뭐, 지금 정도의 불편함이라면 아무리 결심을 해도 때려치우겠다만.)

알라딘 앱의 목표는 책을 많이 팔려는 것인가? 아니면 회원들을 알라딘에 lock-in 시키는 것을 목표로 하는가? 전자라면... 글쎄. 일단 이정도 수준의 인터페이스로 그 고단한 구매과정을 구매자에게 요구한다면 책을 많이 팔기는 커녕 알라딘에 대한 혐오감만 불러일으키지 않을까?
후자라면 처음부터 방향이 틀렸다...


일단, 구매가 거의 불가능할 정도로 어렵다. 뭐하러 앱을 만들었는지 모르겠는데, 실제 결제과정은 그냥 PC용 웹페이지를 가져다 붙였다. 눈알빠지는 줄 알았다. 게다가,유용하게 사용했던 각종 정렬기능들도 사용할 수 없고, 평가나 리뷰 등도 한 눈에 안들어온다. 그냥 묻지마 구매하라는 뜻인가? 쿠폰할인은 사용법을 추측하는 데에만 10분 걸렸다. ThanksTo 적립도 안되고 적립금사용도 복잡하며 웹과의 장바구니 연동도 안된다. 결제 안되는 카드가 수두룩 한데다, 제휴카드마저도 제한이 걸려있다다. 편의점배송도 안된다. 이런 XXX!!!!
욕이 나올만도 한게, 알라딘에 나름 충성을 바쳐온 소비자로써(플래티늄회원인데 말이지...) 그동안 누려왔던 알라딘의 모든 장점을 단 한가지도!!!!!!!! 이용할 수 없다. 아니, 그런 불이익을 감수하면서까지 앱으로 꼭 결제를 해야할 만큼의 필요성은... 글쎄다. 그정도로 급하다면 차라리 버스에서 내려서 PC방비 1000원 지불하는 쪽이 적립금이라도 더 많이 쌓을 수 있겠다.


그냥 모바일 웹페이지나 잘 만들어 제공하는 쪽이 더 낫지 싶다. 진심으로.



그럼 현재 같은 모습이 아니라면, 인터넷 서점에는 어떤 앱이 필요할까?
Mobile이니까, Wireless니까, iPhone이니까 가능한 무언가를 찾아야 하지 않을까?
아래의 기능을 꼭 하나의 앱에서 구현할 필요는 없을테다. 가볍고 유용하고 재미만 있다면 알라딘 앱 시리즈를 여러개 까는 걸 불평할 사람은 없을테니.

1) meat-world에서의 검색/탐색
일단, 기껏 아이폰용 앱인데도 불구하고 타이핑이나 클릭으로 뭔가를 조작하려는 생각은 버려주시길.
올라웍스의 스캔서치인가 하는 앱을 보니, 표지만으로 책 검색이 되더구만. 그게 아니라면 에그몬 같은 앱은 바코드 촬영으로 책 검색이 된다. 문자 검색을 아예 배제할 수는 없겠지만, 모바일환경에서의 아이폰이라면 그에 맞게 오프라인의 책을 그대로 검색할 수 있어야겠다. (표지검색이든, 바코드 스캔이든, 타이틀 스캔이든... 기왕 촬영해서 스캔이 가능하다면 작가 이름이나 출판사 이름도 스캔 가능할 테고...)

이게 되면 다음과 같은 시나리오도 가능하다는 말씀.
"옆자리 동료가 읽고 있는 책이 좋다길래 슬쩍 들고와서 사진한방 찍어주고 돌려주면 그 책이 검색이 된다"

이 시나리오가 어떻게 확장되는지 다음의 유스케이스를 가정해보자.
"약속시간이 남아 교보문고에서 얼렁뚱땅 시간을 때우고 책을 구경하다가, 맘에 드는 책 발견! 아이폰을 꺼내 사진 한방 찍으면 알라딘에서 구매시 교보보다 얼마나 싼지 계산해주고 자동으로 내 보관함에 담기게 된다."

아예 캐치프레이즈로 만들어도 되겠다. "아이쇼핑은 교보에서, 구매는 알라딘에서."
쪼그만 iPhone 화면, 타이핑 요구하면 피곤하다.

2) 내 서재를 아이폰으로.
책을 많이 사는 사람들은 늘, 자기가 가지고 있는 책을 DB화 하고 싶은 욕구에 한번씩은 빠지게 된다. 스스로도 대견해보이니까.
그러나 대부분 조금 시도해보고 포기한다. 왜? 무지하게 손이 많이 가고, 귀찮기 때문에.
책장에서 책 꺼내서 사진 한방씩 찍어주면 자동으로 마이서재에 차곡차곡 담겨준다면 마이서재 활성화 및 마이리뷰 작성에 크게 도움되지 않을까?
더불어, 내가 책을 올해 얼마나 샀고, 얼마나 읽었고 또 목표를 세워서 얼마를 읽어야 하고... 등등의 독서일기 내지는 독서 계획관리등의 기능이 추가된다면 항상 몸에 지니고 다니는 아이폰의 특성상 개인의 독서도우미 역할을 톡톡히 할 수 있겠다. 책을 많이 읽으면, 많이 사게 되기 마련이니... 책을 많이 팔고 싶으면 독자가 책을 많이 읽도록 먼저 만들자.
아, 생각난 김에, 책을 다른 사람에게 빌려줬다든가 하는 기록도 남길 수 있다면 금상첨화. 이거 독서가나 장서가들에게는 언제나 풀리지 않는 골치거리였으니까.

3) 포토리뷰/밑줄긋기/리뷰남기기
네.네. 간단한 겁니다. 그냥 아이폰에서 포토리뷰 쉽게 작성하도록만 해줘도 되는 것. OCR 기능을 탑재해서 아예 책읽다가 책 페이지를 찍은 후에 문자인식 후, 필요한 부분만 긁어서 밑줄긋기라든가, 북마크(브라우저 북마크 말고)할 수만 있어도 좋겠다.
조금 나아가면, 버스안에서든 어디든, 책의 마지막 페이지를 덮은 후에, 그 감회가 잊혀지기 전에 리뷰를 작성한다든가. (장담하건데, 버스 내리면 그 때의 그 기분은 어느새 까먹게 된다니까.)
"마지막 책장을 덮고 나서, 책 뒷면의 바코드를 아이폰으로 찍은 후, 리뷰작성 버튼 누르고 한 줄 소감을 남긴다..." 음... 내가 생각해도 너무 자연스럽네.

4) 지역정보/Social Network
이 책을 산 사람들은 어디에 살고 있을까. 혹은 이 근처에 있는 사람들이 많이 사본 책은 무엇일까. 같은 것.
혹은,
"우리 동네 나와 같은 나이 또래에 미혼인 여성 중에 코맥 맥카시를 좋아하는 여자가.... 어라, 바로 옆 커피숍에 지금 있네..."
네. 알라딘제공 사랑의 짝대기 서비스도 농담은 아닐 수도...
취향, 그것도 책에 관한 취향은 개인의 성향과 아주 밀접한 것. 그러니까, 르 귄을 좋아하는 독자치고 나쁜 사람은 없다던가...
반대로 "아, 저 분은 겉은 멀쩡해보이는데 알고보니 양판소 매니아... 웁스." 같은 것도 가능하다는.

또는, 어차피 알라딘이 설마 중고판매 수수료를 엄청난 수익원으로 생각하지 않는다면, "이 책을 중고로 파는 사람들 중 가장 가까운 사람은 어디에??" 같은 서비스도 제공할 수 있겠지. 어차피 중고거래시의 문제는 애스크로처럼 복잡한 방법으로 해결하는 것보다는, 그냥 대면해서 그자리에서 거래해 버리면 그만이니까. 뭐, 알라딘이 중고판매 수수료로 한몫 벌 생각이라면 좀 어렵겠지만 설마 그럴라고. 품절이나 절판된 책을 찾는 독자들에 대한 lock-in 효과를 노렸던 것 아니었나?

5) 다 떠나서...
iPhone이나 iPad용 전자책 솔루션이나 만들어주시길. 얼마든지 구매해줄테니.


ps. 이 중 일부는 하신다고 하시더라... 하시거든, 다시 마주합시다. 아이폰에서는.

2010년 3월 23일 화요일

IE Error : KB927917

IE는 다른 브라우저들과는 달리, 자신이 속한 DOM 트리의 부모 엘리먼트를 조작하지 못하게 되어있다. 즉, 다음과 같은 코드는 에러를 만든다.

<div id="something">
  <script type="text/javascript">
    document.getElementById("something").appendChild(anything);
  </script>
</div>
자식엘리먼트에 속한 script블록이 자신의 부모엘리먼트에 대한 조작을 하려하고 있는 상태이다. 이 경우 다른 브라우저에서는 아무런 문제없이 정상작동하지만, IE에서는 KB927917 에러를 발생시킨다. 대표적인 조작 메쏘드는 appendChild, removeChild, innerHTML 등.

이 문제를 해결하기 위해서는 해당 스크립트를 조작대상 엘리먼트(이 경우에는 "something")의 바깥으로 빼면 된다. (애초에 모든 스크립트를 head 섹션안에 두고, body안에는 script 태그를 없애고, onload를 이용해서 Late Binding을 시켜주면 아예 발생하지 않는다만, 이렇게 리팩토링하라고 하면 모두 좌절할 듯. 게다가 텍큐는 내가 안짰다규... T_T)

MSDN을 보면 IE8에서는 이 버그가 해결되었다고 하는데(아주 자랑스럽게, 해결책을 "Upgrade to IE8"이라고 내놓고 있다.), 여전히 발생하는 걸 보면 안고쳐진게 틀림없는 듯.

아무튼 어제 쓴 포스팅에 대한 AS 차원의 글.



2010년 1월 25일 월요일

접근성 및 모바일 환경을 위한 메일 작성가이드라인(광고메일, DM 등)

1. 메일 클라이언트는 사용자마다 다릅니다.

Naver 웹메일, Outlook 2007, Gmail, iPhone 메일함다종 다양한 환경에서 이용자들은 메일을 봅니다. 메일 클라이언트들은 벤더에 따라 다르며, 또한 버전 및 사용자의 환경설정에 따라 또 달라집니다. 따라서 특정 메일 클라이언트에서는 문제없는 메일이라 하더라도 다른 메일 클라이언트를 사용하는 사용자에게는 문제가 될 수 있습니다.

 

2. CSS 지원여부

메일 클라이언트가 HTML을 지원하는 것은 필수가 아닙니다. 따라서 메일 클라이언트마다 다 다른 형태로 HTML 렌더링을 지원합니다. 예를 들어 Outlook 2007 Internet Explorer에 탑재된 렌더링엔진대신, MS-Word 2007에 들어있는 렌더링엔진을 사용합니다. 그러나 Outlook 2003 IE 6 렌더링엔진을 이용합니다. 따라서 HTML 태그가 똑 같은 모양으로 렌더링될 거라는 보장이 없습니다.

 

2-1. <style> & <link>

현재 유통되고 있는 메일 클라이언트 (웹메일 포함)의 일부는 Style 태그나 link 태그를 사용할 수 없는 경우들이 있습니다. 따라서 외부 CSS 혹은 내부 CSS 사용이 될 거라는 보장이 없습니다.

 

2-2. CSS Selectors

선택적 CSS 셀렉터가 안되는 경우들이 많습니다. (어차피 style, link 태그를 못쓰는 경우들을 고려한다면 불필요한 이야기)

 

2-3. 문제가 있을 수 있는 CSS 속성들

background-color, background-image, background-position, background-repeat, border, border-collapse, border-spacing, bottom, caption-side, clip, cursor, clear, direction, display, empty-cells, float, font-family, font-variant, height, left, letter-spacing, line-height, list-style-image, list-style-position, list-style-type, margin, opacity, overflow, padding,  position, right, table-layout, text-indent, text-transform, top,vertical-align,  visibility, white-space, width, word-spacing, z-index…

 

사실 엄밀히 말하자면 모든 CSS에 다 문제가 있을 수 있습니다. 이메일은 HTML문서가 아니기 때문에 정상적으로 렌더링될거라는 보장을 하면 안됩니다.

 

Inline-css (HTML style attribute를 이용)의 경우는 상대적으로 잘 지원되지만, 이 경우에도 단축형은 지원하지 않는 케이스들이 있습니다.

 

결론 : inline-css를 제외하고는 CSS 사용에 문제있음. 가능하면 CSS를 이용하여 디자인하지 말 것. Inline-css 에서도 모든 속성이 제대로 지원될 거라는 보장없음.

 

3. 폭과 정렬

일부 메일 클라이언트의 경우, 표시되는 메일 본문의 폭이 매우 좁을 수도 있습니다. 특히 모바일 환경에서 볼 경우에는 메일 클라이언트에 따라 그 폭이 200pixel 미만일 수도 있습니다.

, 대부분의 메일 클라이언트는 가운데 정렬이 지원되지 않을 수 있으며, 시도할 경우 레이아웃이 매우 이상하게 바뀔 수 있습니다. 좌측정렬을 기본으로 삼아야 합니다.

결론 : 장폭의 이미지, URL의 링크 등을 그대로 제공하지 말 것.

 

4. table 태그의 이용

Table이 반드시 지원될 거라는 보장은 없지만, 그나마 레이아웃을 잡기 위해서는 table 태그를 사용할 수 밖에 없습니다.

HTML 4.0 기준의 Table 관련 태그들은 제법 다양한 메일 클라이언트에서 지원되며, css property를 사용함에 제한이 있으므로 table이나 td 태그의 html attribute (border, valign, align, cellspacing, cellpadding )을 이용하면 레이아웃을 잡을 수 있습니다. 그러나 colspan이나 중첩 테이블 등의 경우 제대로 표시된다는 보장이 없습니다. 100% 보장되는 것은 아니므로 가능한 다단 편집대신 1단으로 컨텐트를 구성하는 쪽이 바람직합니다.

혹시 table 관련 태그를 사용할 경우, width를 지정하겠다면 가능한 한 픽셀단위 고정폭을 사용하지 말고, %단위의 가변폭을 사용하는 쪽이 바람직합니다.(사용자 환경을 알 수 없으므로 렌더링될  넓이를 정확히 추측할 수 없기 때문.) 또한 가장 바깥쪽 넓이를 100%로 잡을 경우 몇몇 웹메일 클라이언트에서는 제대로 렌더링되지 않는 문제가 발생할 수도 있으므로 주의해야 합니다. (그러나 반대로, 몇몇 메일 클라이언트에서는 %단위를 사용하는 것 자체가 문제가 될 수도 있음. 어쩌란 말이냐… -_-a)

 

5. 각종 embed 요소

심지어는 img 태그마저도 제대로 안 걸릴 수 있습니다. 나아가 플래시 등을 로딩하기 위한 embed 태그나 javascript 등은 사용하지 마세요. (특히, 버튼이나 링크등을 javascript로 작성하지 말 것!)

결론 : embed, javascript.. 이런 거 전부 쓰지 말 것.

 

6. background image

백그라운드 이미지는, 없어도 되는 이미지가 백그라운드 이미지입니다.

1) 전달해야할 텍스트 컨텐트가 없는 이미지라면 백그라운드 이미지입니다.

2) 전달해야할 텍스트 컨텐트가 포함된 이미지라면 img 태그를 사용하세요.

3) 백그라운드 이미지는 table td 태그의 background-image attribute를 이용하여 표시할 수 있지만, 이 경우에도 제대로 표시될 거라 확신할 수 없습니다. 따라서 백그라운드 이미지는 없어도 메시지 전달에 지장없는이미지여야 합니다.

 

7. image

<img> 태그는 제법 잘 쓸 수 있습니다. 주의할 점은, sliced image를 남발하지 마세요. 제대로 된 위치에 출력되리라는 보장이 없습니다. 꼭 복잡한 이미지를 써야겠다면 table 태그를 이용하여 레이아웃을 잡고, 가능한한 백그라운드 이미지로 통이미지를 쓰는 쪽이 더 나을 수 있습니다. , 이렇게 잡은 이미지와 레이아웃이 반드시 생각대로 표시된다는 보장이 없으므로 중요한 핵심메시지를 img 태그 혹은 백그라운드 이미지로 넣으면 안됩니다.

이미지가 표시되지 않는 경우, 해당 이미지가 전달하려던 메시지가 안보이게 되므로 반드시 alt 속성을 이용해서 대체텍스트를 제공해야 합니다. , width,height 속성을 정확히 사용해서 이미지가 표시되지 않더라도 해당 영역을 확보함으로써 레이아웃이 깨지지 않도록 처리해줘야 합니다.

결론 : 브라우저의 이미지 표시 옵션을 끄고서도 메일의 내용이 이해될 수 있도록 해야 함.

 

8. 사용해서 안전한 HTML 요소

결론은 없습니다. Plain Text를 제외한 모든 HTML 요소들의 이용을 보장할 수 없습니다. 그러나 통계상 다음 HTML 요소들의 순서대로 제법 많은 메일 클라이언트에서 지원되므로 최소한으로 사용은 가능합니다.

-      <a> : 그러나 hyper-text 링크가 표시안되는 경우가 있으므로 사용자가 복사해서 이용할 수 있는 대체 URL 문자열을 같이 출력시켜주는 쪽이 좋습니다. 또한, 가능한한, 링크의 오픈 타겟은 target=”_blank”를 사용해서 새 창에서 열리도록 하는 것이 좋습니다. 그렇지 않은 경우 일부 웹메일 사용자에게는 매우 불쾌한 경험이 될 수 있습니다.

또한, 문서내 anchor가 먹지 않는 경우가 있으니 #을 이용한 anchor 사용은 자제해야합니다.

-      <img> : 일부 속성이 적용되지 않을 수 있습니다. 이미지 자체의 출력이 안되는 경우도 있습니다. 특히 모바일 환경의 메일 클라이언트에서는 네트웍사용량을 줄이기 위해 img를 선택적으로 로딩하는 경우도 있습니다. 이런 경우 등을 대비하기 위해 “alt=” 속성을 이용해서 이미지의 내용을 보여주는 대체텍스트를 작성해야 합니다.

Ex) <img src=”http://somewhere.com/image/order_confirm_message.gif” alt=”고객님의 주문이 접수되었습니다.”/>

-      <p>, <div>, <span>, <a>, <td>, <h1>,<blockquote> : 이런 류의 block/group element 들은 제법 잘 지원되는 편이며, 심지어 style attribute도 일부 지원합니다. 오히려 <font> 태그가 제대로 지원안되는 경우들이 있으니, <p style=”font-family:Tahoma”> 같은 형태가 더 안전할 수 있습니다.

 

 

9. 수신확인은 불가능하다.

RFC3798 등의 규약에서는 메일 헤더에 Receipt 정보를 요구할 수 있게 되어 있으나, 이를 적용하지 않는 메일 클라이언트가 더 많은 현황입니다.

따라서 일부 웹메일에서는 별도로 자체서비스 이용자들간에서만 수신확인을 DB접근 기록등을 토대로 제공하기도 하나 전체 서비스에서는 적용되기 어려운 방법입니다.

한동안 안보이는 작은 이미지 등을 써서 HTTP Request 정보를 이용하여 오픈 여부를 확인하는 방법들을 쓰기도 했었으나 이러한 방법 역시 이미지 출력이 제한되어 있거나, POP/IMAP 등을 이용하는 사용자에게는 작동하지 않는 경우가 있으므로 별로 신뢰할 수 없으며, 마찬가지 이유로 JavaScript를 이용하는 방법도 사용할 수 없습니다.

결론 : 수신확인을 위해 애쓰지 말 것.

 

10. 결론

1) 고객에게 반드시 전달되어야 할 모든 메시지는 반드시 텍스트로 만들어져야 합니다.

2) 텍스트 밑에 백그라운드로 이미지를 까는 것은 상관없습니다. ( CSS로 제어는 안된다고 가정해야 함.)

3) 일부 컨텐트가 반드시 강조되어야 해서 이미지로 메시지를 작성할 경우, alt, width, height를 반드시 작성해야 이미지가 표시되지 않는 환경에서도 사용할 수 있습니다.

4) 모바일 환경에서는 특히 이미지를 표시안하는 경우가 디폴트나 다름없으므로 반드시 주의해야 합니다.

5) script를 절대로 쓰지 마세요.

 

 

Reference

 

http://www.email-standards.org/

http://www.birdhouse.org/etc/evilmail.html

http://www.mailchimp.com/articles/how_to_code_html_emails/

http://mailchimp.blogs.com/blog/2006/01/im_a_web_design.html

http://www.w3.org/TR/1998/NOTE-HTMLThreading-0105

http://msdn.microsoft.com/en-us/library/aa338201.aspx

http://articles.sitepoint.com/article/code-html-email-newsletters

http://www.campaignmonitor.com/templates/

http://www.xavierfrenette.com/articles/css-support-in-webmail/

 

2010년 1월 4일 월요일

아드레날린 중독증

- Adrenaline Junkies and Template Zombies (프로젝트가 서쪽으로 간 까닭은) 은 작년에 읽은 책 중 가장 가치있는 책이라 할 만하다. 86개의 프로젝트 진행 패턴 모두 언급할 가치가 있어, 하루에 1개정도씩 내가 처한 상황과 맞춰서 포스팅할 예정...

1. 아드레날린 중독증

첫 패턴이 이것이라는 것이 의미심장. 내가 이 책에 꽂히게 된 이유이기도 하고.

내가 이끌고 있는 기획1팀은 현재 8명이 소속되어, 이미 오픈된 3개의 서비스를 책임지고 있고, 1개의 서비스가 오픈 예정이며, 4개의 서비스를 추가로 준비하고 있고, 3개의 서비스가 보류중이다. 그외로 2개의 서비스가 곧 통폐합 예정이며, 2개 정도의 프로젝트를(서비스 모델은 아닌) 별도로 진행하고 있다.

8명이다.
하나의 팀으로서는 결코 작다고 할 수 없는 팀이긴 하나, 그렇다고 위에 언급된 업무들을 모두 해내기에 충분한 인력은 아니다.
그럼에도 불구하고 흘러가게 되는 이유는, 우리 회사의 전체적인 분위기가 전형적인 아드레날린 중독증세를 보이기 때문이다.

1) 정시퇴근이 죄악시된다. - 물론 어느 누구도 야근을 강요하지 않는다. 그러나 비즈니스 기회, 고객만족, 당장 던져진 과업 등의 명목은 자발적인(?) 추가근무를 강요한다.
2) 슈퍼맨을 원한다. - 100% 효율은 당연한 것이고 120%, 130% 효율을 요구한다.
3) 의사결정이 빠르다. - 단지, 의사결정이 빠른 것이 나쁘다는 것은 아니다. Agile 스타일의 '준비, 발사, 조준' 정도가 아니라, 아예 '발사, 준비, 조준' 형태로 일이 진행된다는 것.
4) 모든 것이 유동적이다. - 다른 말로는 기민하다고 표현하겠지만, 반대로 준비한 것 없이 진행하면서 닥치는 대로 수습해야 한다는 뜻이기도 하다.

솔직히 고백하자면, 사장님이 가장 심한 아드레날린 중독증세. 여기에 제동을 걸어야 할 팀장인 나 자신도 '프로젝트 매춘부' 스타일이다보니 설상가상.

일은 많이 하는데, 성과는 크지 않고, 만족도는 떨어지고, 위험도는 증가한다. 나자신을 포함한 팀원 모두 불만이 쌓여가는 형태.

어째서 강력하게 반대하지 못하냐고? 사장님은 똑같은 스타일로 이미 '성공'을 한 상태. 반대로 '성공'의 키워드가 이런 아드레날린 중독증이라고 생각하시고 있음. 그 경험칙이 깨어지지 않는 한 어떠한 반대도 통용되지 않음. 반대의 방법으로 동등한 실적을 쌓지 못하는 한 고양이 목에 방울 달기 임.

책에서는, 아드레날린 중독증은 치료할 수 없다고 되어 있음. 이 문제를 어떻게 해결할 것인가가 남은 회사생활의 가장 큰 화두인 셈이다.



프로젝트가 서쪽으로 간 까닭은 - 10점
톰 드마르코 외 지음, 박재호 외 옮김/인사이트

2009년 8월 10일 월요일

보안을 위한 타임아웃

가끔 어떤 웹서비스를 이용하다보면,
일정시간동안 새로운 액션이 없으면 사용자를 강제로 로그아웃하게 하는 기능이 있는 경우가 있다.

보안상, 웹페이지를 열어둔 채로 장시간 자리를 비우지 말라는 서비스 기획자의 고마운 배려.

과연 그럴까?

"외근 중 급한 용무로 PC방에 들려서 업무를 보던 중, 갑작스럽게 찾아온 아랫배의 싸늘한 신호... PC를 내팽개쳐둔 채 부랴부랴 터질 것 같은 배를 끌어앉고 간신히 화장실을 찾아 세이프, 30분간 폭발하는 설사와의 악전고투 동안, 내 옆자리에 앉았던 산업스파이가 내 자리에 앉아 회사기밀을 훔쳐보다..."

요정도가 조금 과장되긴 했어도 기획자가 상상한 시나리오.

그러나 실제 업무에 이러한 경우가 존재할 리 없다. 우선, 이런 습관의 사용자라면 구멍이 이것 하나일리 없기 때문에 전반적인 보안의식부터 고치는 것이 우선.
그 다음, 브라우저 창을 닫는 것은, 일반 어플리케이션을 종료하는 것보다 훨씬 간단하다. 일반 어플리케이션이야 경우에 따라 작업문서를 저장하라는 둥 이런 저런 잔소리를 하며 종료되지 않고 버티는 경우가 있긴 하다. 아마 모두들 '컴퓨터 끄기'를 하고는 안심하고 자리를 떴다가 돌아와보니 저런 메시지를 띄운 채 컴퓨터가 그대로 있던 경험이 있을 것이다.
그러나 웹브라우저는 닫으면 닫긴다. (브라우저가 '죽어서' 안닫기는 경우는 예외) 즉, 필요하다면 언제든지 '기밀'을 '보호'할 수 있다. 오히려 필요한 것은 다운로드한 파일들이라든가, 캐시에 저장된 내용들에 대한 보호일 테다. 물론 이런 것은 타임아웃으로는 어차피 해결되지 않는 문제이다.

또다른 문제점은, 의도와는 달리 이러한 기능은 사용자의 자연스러운 업무흐름을 방해한다는 것이다. 자리를 비우지 않고 단지 '다른 작업'과 같이 하는 것만으로도 이 타임아웃기능은 치명적인 업무방해를 일으킨다.

예를 들어 우리 회사의 사내 게시판은 일정시간 이후에 자동로그아웃된다. 그 결과는 보안성의 강화가 아니라, 몇십분동안 공들여 작성한 사내 공지물의 날아감이다.
내가 쓰고 있는 텍스트큐브 역시 일정시간 이후 자동으로 로그아웃된다. 왜 로그아웃을 시키는지 모르겠다. 그러나 한가지 확실한 건, 내가 글을 쓰기 위해 여러 창을 띄워놓고 자료를 모으고 조사하다 보면 어느새 타임아웃에 걸려 있다는 점이다. 아마도 내가 너무 창을 오래 띄워놓는 것이 이유이긴 하겠다.
물론, 이런 사용자를 위해 '임시저장' 기능이 있으니 그나마 텍스트큐브는 양반이겠다. 가끔 임시저장 버튼이 저 혼자 활성화되었다, 비활성화되었다 하는데 나는 그 이유를 아직도 모르겠다. 그저 안전하게 글을 완료할 때까지는 스톱와치를 놓고서 글 작성중 알람이 울릴 때마다 비공개상태로 저장해두는 것이 더 좋은 습관이라는 것을 구글 텍스트큐브팀이 가르쳐주는 친절함인지도.

트윈캠프라는 서비스를 매우 편리하게 사용하고 있는데, 주지하다시피, 팀관리어플리케이션이란 종류는 문자그대로 '배경화면'처럼 늘 화면에 띄워두는 편이 좋다. 그래야 업무도중 수시로 확인해보며 팀관리를 할 수 있기 때문이다.
그러나, 트윈캠프 창을 열어 둔 채 다른 업무를 보다보면 어느새 트윈캠프가 정해놓은 타임아웃 시간을 훌쩍 넘기기 일쑤. 그러면 다시 부랴부랴 새로 로그인을 해야한다. 아, 재로그인에 소요되는 나의 업무시간 로스와 집중도 방해는 트윈캠프가 보상해주는가.


내 생각에, 타임아웃은 보안을 위해서가 아니라, 계속적으로 자동으로 서버와의 통신이 수행되어야 하는 종류의 웹어플리케이션에서 서버의 부하를 줄이기 위한 케이스를 제외하고는 타임아웃을 통한 로그아웃은 아무런 가치가 없다. 사용자를 생각하는 척 하는 기획자와 개발자의 집단자위행위일 뿐.

2009년 7월 21일 화요일

재밌는 정부

http://www.etnews.co.kr/news/detail.html?portal=001_00001&id=200907200191

지난번 실명제나 메일 검열이나 저작권법도 그렇고...
아무리봐도 이 정부는 네이버가 망하길 바라는 게 틀림없어.

2009년 7월 8일 수요일

화이트노이즈 핑거프린팅을 이용한 저작권 워터마크 크롤링

일단, 나 자신은 지적재산권에 대해  70%정도 반대하는 입장임을 미리 밝혀두고.
둘째, 그렇지만, 인터넷 생태계를 무시한 채 홀로 카피레프트를 주창하는 거야 말로 손해보는 짓이라 생각함을 또한 밝혀두고.
셋째, CCL등은 한국에서는 회수를 건너온 탱자나 다름없다는 생각도 밝혀두고.
넷째, 이제부터 할 이야기들은 이미 쌔고 쌘 이야기인데다 특허권도 이중삼중으로 이미 남들이 걸어놓은 것임을 미리 밝혀두고.

우선 아래 이미지부터.
왼쪽 이미지와 오른쪽 이미지사이의 차이를 구별할 수 있을까?
아마도 육안으로 식별이 가능하다는 사람들은 상당한 민감성의 소유자겠다. (자세히 보면 알 수 있을 만큼 해놓았음.)

그럼 다음 이미지.
이제는 그 차이를 못보는 사람은 없겠지.

화이트노이즈란 원래 음향기기에서 소스의 음향과는 상관없이 기기자체의 기계적인 특성에 의해 발생하는 잡음신호를 일컫는 것으로써, 아무것도 틀지 않은 스피커에서 들리는 '치~'하는 미세한 잡음을 생각하면 되겠다.
그런데, 이러한 화이트노이즈는 정작 음악을 들을 때면 크게 신경쓰이지 않게 되는데, 최근 음향기기의 성능이 좋아져서 화이트노이즈 자체를 많이 잡기도 했거니와, 화이트노이즈의 특성상 랜덤하면서도 평탄하게 반복되기 때문에, 대조적으로 강한 가청성 특징을 가지고 있는 소스의 음향과 함께 들리면 상대적으로 묻혀서 잘 드러나지 않는다.

위의 이미지들이 이런 화이트노이즈의 특성을 이용한 워터마크핑거프린팅의 예시라고 할 수 있겠다. 물론, 이것은 어디까지나 모식도일 뿐이고, 실제로는 디지털신호처리 알고리즘을 이용해서 좀 더 교묘하고 티가 안나게 된다.

국내외에 출원되어 있는 특허라든가 기타 기술문서들을 살펴보면 상당히 높은 수준까지 되어있음을 알 수 있는데, 단순히 사람의 감각으로는 구별할 수 없을 뿐더러, 일부를 샘플링한다거나, 확대, 축소, 회전, 변형이 이루어져도 워터마크를 추출할 수 있다고 한다. 이미지뿐만 아니라 음성파일, 그리고 최근에는 동영상에도 이러한 워터마킹 기술이 많이 개발되어 있다.

보통 이러한 워터마크를 이용하여 저작권 정보라든가 기타 여러가지 응용이 가능한 메타정보를 숨겨놓기 마련.

뭐, 여기까지는 조금만 웹 검색을 해보면 다 알게 되는 내용이고.

비즈니스 모델로써 이걸 활용할 방법이 없을까?

아무래도 영향력이 큰 네이버나 구글 등에서 이러한 워터마킹을 소비자에게 서비스로 제공한다고 하자. 즉, 네이버 블로그에 그림이나 음악, 동영상등을 올릴 때 저작권관련 워터마킹이 자동으로 삽입된다는 가정.

1) de facto 표준
워터마킹의 가장 큰 문제점은 사용하는 솔루션마다 삽입/검출 방식이 다 다르다보니 범용적으로 활용될만한 표준방식이 없다는 점.
시장의 지배적 사업자가 선도하거나 최소한 영향력있는 사업자들의 컨소시엄의 형태로 이러한 범용 알고리즘을 채택하면 파급력과 활용도가 더 커지리라.

2) 저작권의 확인
사실상 사용자의 저작권에 대한 무지가 가장 큰 원인이나 다름없는 상황. 이것을 캠페인이나 계몽만으로 정화하기는 사실상 어렵다. 그렇다면, 솔루션 차원에서 접근해보면 어떨까?
사용자가 자신의 블로그에 그림 파일을 업로드할 때, 업로드된 이미지에서 워터마크를 추출하여(만약 있다면), 해당 라이센스에 대한 경고를 사용자에게 해줄 수 있다면. 즉, 웹에서 돌아다니는 이미지를 내 계정에 올리려고 하니 "해당 이미지는 홍길동님에게 저작권이 있으며 홍길동님은 이 이미지를 비영리적 목적과, 원본을 변형하는 않는다는 조건하에서만 웹 게시를 허가하였습니다."같은 경고 메시지를 띄워준다는 시나리오.
이른바 고지 및 경고의 기능을 수행하는 동시에, 원저작자의 의도와 정보를 충실히 전달하며, 오용의 가능성을 줄여줄 수 있겠다.

3) 저작권의 삽입
뿐만 아니라, 자신의 창작물의 경우에는 자신의 저작권 정책에 따라 자신의 워터마크를 삽입해줄 수 있다.
대개 개인의 경우 자신의 저작권에 대한 이해가 부족할 뿐더러, 저작권을 보호할 수 있는 장치를 개인적인 수준에서는 마련하기 어렵기 때문에, 이러한 장치들을 개인에게 사용할 수 있도록 제공해주는 것은 상당한 가치가 있다.
지금은 고작해야 우클릭금지라든가, CCL 마크를 아래에 써놓는다든가 정도. 효용도 그다지 높지 않을 뿐더러 귀찮기까지 하다. 그러니, 창작자가 별다른 수고없이도 이용할 수 있는 저작권 보호 솔루션의 필요성은 높다 하겠다.

4) 저작권의 추적
네이버같은 검색엔진을 보유하고 있는 사업자가 빛을 발하는 경우인데, 검색크롤러가 파일들을 크롤링을 하면서 워터마크를 검출하여 원저작권자에게 해당 컨텐트가 어디에서 어떻게 사용되고 있는지를 알려주는 서비스 같은 것이 가능하겠다. 뭐, 잘못사용하고 있는 경우라면 고소대행서비스까지 곁들이거나. ^_^
사람들은 평판과 명예에 민감하기 때문에, 자신의 저작물이 어떻게 쓰이고 있는지를 알고 싶어하는 욕구는 상상이상으로 강력하다. 해당 저작물을 퍼블릭 도메인으로 풀어놓은 경우라 하더라도.
네트워크의 특성상 컨텐트의 전파는 링크를 따라 흐르기 마련이고, 크롤러의 동선도 링크를 따라가기 때문에 저작물의 추적은 그다지 맨땅에 헤딩하는 정도의 어려움은 아니다.

5) 퍼블릭 도메인 아카이브
이런 식으로 각 저작물에 대해 명시적으로 저작권을 부여할 수 있다면, 그 중에는 저작권 행사를 포기하는 퍼블릭 도메인 컨텐트들도 생길 것이다. 이러한 퍼블릭 도메인 컨텐트들을 자동으로 모아 많은 사람들이 저작권 걱정없이 이용할 수 있는 퍼블릭 도메인 아카이브 서비스도 가능하겠다.


뭐, 이래저래 역시 네이버나 구글 정도가 아니면 좀 엄두가 안나는 규모이긴 하지만...


ps. 텍스트는 그 특성상 워터마킹이 불가능한 게 옥의 티.

2009년 7월 3일 금요일

XHTML의 종말

http://www.w3.org/News/2009#item119

XHTML2는 이제 역사속으로...

ps. XHTML2가 HTML5보다 '엄밀'하다는 이유에서 내심 XHTML쪽이 이기길 바랬는데...

2009년 6월 2일 화요일

이런, Project NATAL


XBox 360 팔아버렸는데... 다시 사야 하나.
Wii에서 깜놀 했는데, NATAL 이건 뭐 10년전 SF영화보다 더 뛰어난 테크놀로지이니...

역시 MS가 H/W는 잘 만든단 말이지.


사실 XBox 컨트롤러로만 쓸 게 아니라면, 새로운 입력도구로서의 가능성이 보임.
교육이나 강연, 발표시에 대형 프로젝터와 결합하면 좀 더 역동적인 시연이나 발표가 가능할 테고...
매장이나 길거리의 키오스크기기에서 터치스크린 대신의 더 나은 사용자 입력 컨트롤러의 가능성이 있겠음.
PC용 디바이스 드라이버와 API가 나와주면 재미있을 것 같다.

2009년 5월 15일 금요일

한겨레 리뉴얼

한겨레가 하니TV개국과 함께 디자인 리뉴얼 되었다.

나는 인상비평을 좋아하는 편인데...  첫 소감은 전에 비해 쫌 구려진 듯.

1) 중앙정렬, 좌우 오픈형
왠지 naver나 daum 비슷하기도 한데,  가장 큰 차이는 중앙정렬된 Content영역과 좌우여백사이에 분리선이 없는 구조인데다 Content영역도 흰색, 좌우여백도 흰색. 경계가 지어지지 않는다. 그러다보니 시선이 Content영역으로 집중되지 않고 자꾸 좌우 여백 바깥으로 흩어져 버린다.

개인적인 기호문제일 수도 있겠지만, 가능하다면 Content영역은 확실하게 집중할 수 있도록 시선의 동선의 움직임경로를 제한하는 쪽이 좋겠다.
WSJ처럼 Content영역과 여백영역을 확실히 구별해주면 독자의 시선은 Content영역에만 효율적으로 머무를 수 있어서 집중력을 유지하고, 눈의 피로를 덜 수 있다. 색으로 구분하기가 싫다면 최소한 daum이나 naver, NYT처럼 분리선을 명확하게 그어주는 쪽도 바람직하다.

2) 프로포션의 불균형
신문 사이트는 text를 주의깊게 읽기를 요구하기 때문에 독자의 시야각이 좁아지고 눈의 피로가 매우 심한 특징이 있다.

새로 개편한 메인화면에서 3단 배치에 기사들을 좌단에 배열한 것 자체는 나쁘지 않다. 그런데 비율이 대략 좋지 않다.
눈대중으로 보기에는 3:2:2 정도.  기사:기타 영역으로 치면 비율이 3:4
가장 핵심이 되는 기사단의 폭이 너무 좁다. 사이트 중앙지점에 기사가 위치하지 않기 때문에 시선을 자연스럽게 가운데 두지 못하고, 의도적으로 시선을 좌측으로 향하게해야 한다. 이럴 경우, 기사 영역 외의 우측 공간으로는 초점이 도달하지 못하는데, 그 영역이 지금 읽고 있는 기사 영역보다 더 넓다. 한참 기사제목들을 집중해서 읽고 있다보면 촛점이 닿지 않는 시선 우측 부분이 마치 개미가 바글바글 기어다니는 느낌으로 피로해진다. 게다가 우측 영역에는 번쩍거리는 플래시 광고들도 있다. 시선 바깥쪽에서 뭐가 어른거릴때 얼마나 신경쓰이는지는 다들 경험해본 일일테다.

3) 기사영역보다 튀는 기타영역
짧게 말하자면... 기사쪽에는 순 텍스트뿐. 사진썸네일도 간혹 있지만 천편일률 똑같은 자리 똑같은 크기. 기사간의 구획도 없고 강조도 없다. 헤드라인을 제외하면 타이틀의 크기도 다 똑같다. 섹션구별도 없고 이 기사가 스포츠 기사인지 정치 기사인지 타이틀만 가지고는 판단하기도 어렵다. 한마디로, 별로 재미가 없다.
신문읽는데 왠 재미냐고 하겠지만, 신문이 학위논문도 아닌바에야 일단을 읽혀야 하지 않겠나. 지금은 그냥 까만건 글자요 하얀건 여백일 뿐.
 
오른쪽의 기타 영역은 섹션이나 기능에 따라 박스를 쓴다든가, 색을 달리한다든가 하는 게 있는데 왼쪽의 기사 영역은 별 특징이 없다. 당연히 시선은 오른쪽으로 자꾸 유혹된다.



개편된 메인화면이 얼마나 가독성이 떨어지는지는, 개별기사페이지와 비교해보면 알 것이다. 개별기사페이지는 개편되지 않은 듯 한데, 그래서 불행 중 다행. 개별기사페이지의 특징은...

- 기사영역이 전체 폭의 절반 이상이라 기사에 확실히 집중할 수 있고,
- 전체영역의 중앙부에 기사영역이 걸쳐있기 때문에 시선을 편안하게 중앙부에 둘 수 있고,
- 좌우여백쪽으로 시선이 흘러나가지 않게 정확히 구획되어 있고,
- 좌측에 성가시게 따라다니는 광고배너를 제외하고는 시선 바깥쪽에 걸리적거리는 게 별로 없다.

여하튼, 그래서 이번 한겨레 리뉴얼은 완전 엉망인 듯.

2009년 4월 17일 금요일

성공적인 사내 제안을 위해

회사의 어린 개발자 한 명은 가끔 나에게 자신이 생각한 '아이디어'들을 들려준다. 사업부서는 다르지만 명색이 기획사업부에 속해있는지라 그 이야기를 열심히 들어주고 있는 편인데...

문제는, 그의 '아이디어'를 들을 때마다 내가 부정적으로 답변하고 있구나... 라는 생각이 어느날 들어버렸다는 것. 왠지 '말이 통하지 않아...'라고 생각하고 있을까 하는 기우.

고리타분한 꼰대가 되어버린 느낌.
그러나 반대로, 그 친구 역시 단상적인 아이디어가 아닌, 제대로 된 사내 제안을 할 줄 알 필요가 있겠다.

그 친구의 첫 제안은 아마도 일본워크샵때로 기억하는데, 그 때 우리 회사에도 사내제안제도가 있었으면 좋겠다는 것. 그 때부터도 나는 그 의견에 반대(?)를 했었는데, 내 생각은, 사내제안제도가 없는 것이 문제는 아니라는 것... 

그럼 무엇이 문제일까?

단편적인 아이디어 개진 수준에서 머무르지 않고 진정으로 통용될만한 사내제안을 하기 위해 알아야할 것들...을 다룬 책 두 권 소개로 갈음해본다.


The One Page Proposal - 8점
패트릭 G. 라일리 지음, 안진환 옮김/을유문화사
...
기획파트가 아니거나 경험이 부족한 친구들의 가장 큰 문제점은, 
'자기 자신이 뭘 말하고 싶은지 전달을 못한다는 점'.

대개 이렇다. 어떤 아이디어가 생각난다. 스스로 생각해도 괜찮다고 생각한다. 그냥 생각난 대로 입밖에 내고 만다. 끝.
정반대의 경우는 이렇다. 어떤 아이디어가 생각난다. 스스로 생각해도 괜찮다고 생각한다. 가능한한 모든 근거를 끌어들여 2백페이지의 제안서를 만들어 제출한다. 끝.

이 두가지 경우 모두 적절하지 않다. 전자는 피상적이고 즉흥적인 결론을 통해 그 속에 숨겨진 진의를 스스로도 깨닫지 못한 채 표면적인 부분만 말하고 만다. 예컨대, 야근수당을 지급하면 야근효율이 올라가지 않을까요.. 라는 제안은 애초에 최근 늘어난 야근이 정규근무시간에서의 업무 비효율때문이라는 것을 잊고 있는 상태일 수도 있다.
후자는, 대부분 그러한 제안을 받아들이는 입장이 자신보다 상급자라는 점을 고려한다면 대개 쓰레기통으로 쳐박히는 지름길이다. 아마도 상급자는 자신보다 기술적으로 뒤쳐지거나, 상대적으로 고루할 수는 있겠으나, 한가지 더 나은 점이 있으니, 그건 바로 무엇이 중요한지 판단할 수 있는 능력. 무엇이 중요한 것인지 판단하려면 그것에 대해 콕 찝어줘야 한다. 대개 상급자의 시간비용은 제안자의 시간비용보다 비싸기 마련. 심지어 2백페이지의 제안서를 만드는 데 제안자가 사용한 시간비용보다 상급자가 그걸 읽는데 드는 시간비용이 더 비쌀 수도 있다. (연봉이야기가 아님.)

한 페이지로 정리되지 않는다면 방향을 잃어버렸다고도 할 수 있다. 한 페이지 안에 자신이 하고자 하는 이야기를 모두 담지 못할까 걱정할 필요는 없다. 한 페이지로 줄이느라 이런 저런 요소들이 빠지는 것을 두려워 말 것. 대개 상급자가 월급을 더 받는 이유는 그런 부분을 감안하여 의사결정을 할 줄 알기 때문이다. 
한 페이지로 상급자의 관심을 끌어낼 수 있다면 추가되어야 할 부가요소들은 추후에 잘 정리해서 2백 페이지쯤으로 해서 실무자에게 전달할 때에나 필요한 것.



당신의 기업을 시작하라 - 6점
가이 가와사키 지음, 김동규 옮김/랜덤하우스코리아
...
대개 사내제안의 경우 '무책임'으로 흐르기 쉽다. '이런 상품을 만들면 좋지 않을까요?' 수준. 
물론 제안자 본인은 스스로 확신을 가지고 제안하는 것이겠지만, 회의적인 상급자를 설득시키려면 확신 이상의 무언가를 가지고 있어야 한다. 

보통 그 무언가는 '실증'이 될 텐데, 예를 들어 제안을 뒷받침하기 위한 통계, 시뮬레이션, 프로토타입 기타 등등 여러가지가 될 터이다.
이런 것이 뒷받침되지 않는다면 제안은 그저 제안일 뿐.

'우리 회사에서도 SNS 서비스를 만들면 좋을 것 같습니다.'라는 제안을 상급자에게 설득시키기 위해서는,
서비스를 만들고 유지하는데 필요한 비용과 리소스, 수요예측, 예상 실적, 마케팅 방안... 여러 가지 자료들이 필요한데, 이런 것들을 아무리 삐까뻔쩍한 기획서로 만들어봤자 돌아오는 대답은,
'그건 니 희망사항이고...'

그렇다면 어떻게 하는 것이 좋을까?
가장 확실한 방법은, 1/10 혹은 1/100 사이즈로 모형을 만들어 제시하는 것. 
업무 외 시간에 약간의 개인 시간을 희생해서 자신이 만들고 싶던 SNS 서비스를 작게 한번 만들어보는 것. 완성이 되지 않아도 좋고, 성공하지 않아도 좋다. 미완이면 미완인 대로 가능성이 보일 단계가 되면 그 때,
'저 혼자 틈틈히 30시간의 투입으로 간단히 만들어본 모형입니다. 현재 제 개인친구들한테만 공개해두었고 사용반응은 이 정도로 호의적입니다. 이 결과로 미루어 만약 회사에서 8명의 팀을 조직해서 정식으로 개발해본다면 4개월 후 이러저러한 형태로 오픈하여 성공가능성이 있을 것 같습니다.' 라고 이야기하면 아마도 90%는 채택될테다. (당연히 해당 팀조직의 책임위치로 승진할 것이고.)
만약 그 가치를 몰라보아서 채택이 안된다면, 퇴사해서 독립하거나, 경쟁사에 팔면 됨... :)

그러려면 혼자서 스타트하는 방법을 알아야 한다. 이 책은 사내제안용 실무서는 아니지만, 사내제안을 하려거든 최소한 창업하는 마인드로 시작하라는 바램으로 권해본다.

2009년 4월 7일 화요일

PM과 PL

규모가 작은 팀이라면 PM과 PL의 역할 구분없이 대충 뭉뚱그려 '팀장'이 다 하기도 하지만...

일의 효율을 위해서라면 PM과 PL을 구분지을 필요가 있다. (...라고는 하지만 PM과 PL이 교과서에 딱 정의되어 있는 말도 아니고... 어디에서는 프로듀서와 디렉터라고 부르기도 하고...)

PM - Project Manager
프로젝트의 모든 책임을 지는 사람. 만약 프로젝트가 실패한다면 모든 1차 책임은 PM이 져야 한다. 가끔보면 PM을 '그 팀중 가장 고참'이 맡는 경향이 있는데, 대체로 그런 게 통하기도 하겠지만, 그보다는 해당 프로젝트에 가장 목매는 사람... 이 하는 게 맞을 듯. 프로젝트의 성공을 위한 모든 것의 얼굴마담.
PM이 해야할 일은 조직의 외부와 조직을 매개해주는 역할로써, 외적으로는 클라이언트나 보스에게 조직을 대표하여 협상이나 회의를 하고, 내적으로는 스케쥴과 리소스조달, 품질에 대한 지휘를 한다.
따라서 PM은 세부적인 기술지향적인 인재보다는, 경영이나 관리쪽의 적성에 맞는 이들이 하는 것이 적합.

PL - Project Leader
PM이 외부로의 대표자라면, PL은 내부에서의 인솔자로써, 업무의 분담, 작업지시, 리소스 배분, 문제 해결방안의 도출 등의 역할을 기대받는다. 설계자로서의 자질도 필요하겠지만, 그보다는 현장감독의 의미가 강하다. PL이 해주길 바라는 역할은, 적재적소적시에 조직내 리소스를 효율적으로 할당하기.

PM도 PL도 각각 독립적인 role로써, 그 업무만으로도 1인분씩에 해당하기 때문에, 규모가 작은 팀에서 가끔 보이는 '기획자가 PM도 맡아하기'라든가, 'PL이 메인 프로그래머로 일하기'같은 조직은 아주 잠깐은 가능할지 몰라도 장기적으로는 오래 버티기 곤란하다. 비효율적이기도 하고.

PM과 PL이 제 역할을 발휘할 수 있으려면 몇 명의 보조 직군이 필요한데...

Ace
기술적으로 가장 뛰어날 필요는 없지만(보통 PL이 가장 기술적으로 뛰어날 경우가 많다.), 가장 의지할 수 있는 현장인력이어야 한다. Ace의 존재가 있어야만 PL이 안심하고 업무를 배분할 수 있다. PL의 조언자이자, PL이 구상한 계획을 실천하는 핵심인력.

Utility
개발자간의 생산성 차이야 익히 알려져 있는 사실이기에, 프로젝트 내에 Ace가 존재한다면 조직의 생산성을 담보하는 가장 확실한 방법은, Ace가 저수준의 작업으로 방해받지 않도록 해주는 것. 그러기 위해서는 Ace가 필요로 하는 여러 도구나 라이브러리, 테스트작업 등을 대신 개발, 수행해줄 Utility 플레이어가 있으면 좋다. Ace가 핵심부분, 혹은 문제가 되는 부분에 집중할 수 있도록 세밀한 부분에서 서포트해주는 것이 관건.

리소스 관리자
팀내의 리소스(인력배분, 문서, 코드, 중간결과물, 작업재료) 등에 대해 누군가는 계속 관리하고 있어야 한다. PM은 리소스를 외부에서 조달해줄 뿐이고, PL은 리소스를 내부에서 배분해줄 뿐. 그렇다면 누군가는 리소스를 언제든지 사용가능하도록 계속 관리하고 있어야 한다. 어떤 테스트셋이 필요하다고 누군가 요청을 할 때, 그것이 어디에 있었는지 모두가 찾아 해메는 대신, 리소스 관리자가 요청즉시 꺼내어 줄 수 있도록 정리해두어야 한다.
대개 이러한 리소스 관리는 도구의 도움을 받기도 하고, 개개인이 일정부분 스스로 관리하는 것도 있곤 해서 굳이 프로젝트당 한명씩 둘 필요는 없으나, 어쨌든 누군가는 지속적으로 담당하고 있어야 하는 것.


대개 규모가 작은 회사에서의 개발팀, 혹은 프로젝트팀을 보면, 시니어 개발자 한명이 설계하고 나머지 개발자들은 대충 적당히 잘라서 일을 나눠갖고는 한다. 개발자간의 능력이 서로 다르다는 것을 인정하지 않는 경우인데, 이러한 수평적 구성보다는 수직적 구성이 효율은 더 좋은 편이다.

막말로 일정규모 이하의 프로젝트의 개발은 Ace 혼자서도 충분하다. 만약 일정을 당기고 싶다면, 개발자를 투입하는 대신, Ace가 식사시간에도 문제해결에 집중할 수 있도록 밥을 떠먹여줄 보모를 투입하는 쪽이 훨씬 효율적이다. 더 싸기도 하고.

2009년 3월 12일 목요일

집단지성

오늘 팀원과의 회의중에서...


"그러니까, 집단지성이란 건 분신사바나 다름없다고. 모두가 힘을 빼고 의식하지 않아야 신이 내리는 거라니깐? 만약 누군가 의도를 가지고 액션을 취하려 한다면 그 순간 신님과의 대화는 끊어지는 거지...."

아 띠바, 내가 말해놓고 너무 완벽한 비유라고 생각.

2009년 3월 9일 월요일

웹사이트 가입으로 똥개훈련하기

맥유저지만 그래도 증권이나 인터넷뱅킹에서는 Windows를 써주는 센스. 그러니까 왜 맥에서 안되냐고 유감스럽다 뭐 이런 건 아니고. 아니, 그것도 유감스러운 게 사실이긴 하지만.

적립금 쌓는 재미에 알라딘 플래티늄 회원등급을 유지하려 도서구입 과소비를 매달 실천하는 나로서는 추가 3% 적립에, 할인까지 해주는 A1 알라딘제휴카드가 매력만점...
그래서 신청하고 오늘 발급받아서 겸사겸사 가입까지 시도해보았다.

1) 회원가입을 하려면 먼저 카드를 받았는지 수령확인 과정을 거쳐야 한단다.
그래서 주민번호와 카드번호를 입력하는데...
네자리-네개의 필드로 구현된 카드번호 입력은 자동으로 자리수를 채우면 자바스크립트를 이용하여 다른 칸으로 넘어가는데... 자칫 숫자 오타를 내면 수정이 조금 번거롭다. 그나마 다른 사이트보다는 나은게 어떤 것들은 onFocus 이벤트에서 자리수를 체크하여 아예 해당 필드에 진입도 못하게 해놓는 경우도 있으니까.
여하튼 중요한 건 그게 아니고, 
입력이 끝나고 다음 단계...를 누르면 팝업 블록에 의해 팝업이 막혀있다. 브라우저 기본 설정인 셈이니 어쩔 수 없이 팝업블록 해제를 선택하면 페이지를 다시 로딩... 즉 아까 입력한 내용을 또 입력해야 한다는 소리. 그나마 임시로 이번만 해제를 하면 다음번에 또 똑같은 과정을 거쳐야 하므로 대개 무심한 마음으로 자비를 바라며 이 사이트에서의 전체 팝업 블록 해제를 선택할 정도의 노하우는 있다는 것. 다만 늘 팝업블록을 당하고 나서야 블록해제를 하고 다시 재로딩해야한다는... 약간 시지프스적인 원초적 고난을 감수해야 하겠지만.

2) 그래서 팝업블록을 해제하고 다시 입력을 하면...
이번에는 해당 팝업내에서 보안관련 ActiveX를 설치하라는 메시지가... 해당 ActiveX를 설치하고 나면 다시 페이지 로딩. 다시 처음부터....  -_-a 뭐, 이쯤이야 한두번 겪는 일도 아니고.

3) 첫번째 ActiveX를 거치면 두번째 ActiveX가....
이 두번째 ActiveX (솔직히 첫번째와 두번째가 뭐하는 놈인지도 모르겠다. 아무도 안읽잖아?)는 첫번째 놈보다 독한 놈인데, 왜냐하면 설치를 위해 브라우저를 전부 종료시키라는 메시지를 내뱉기 때문이다.
결국 브라우저를 전부 닫고, ActiveX를 설치하고나서... 다시 브라우저를 띄우고(자동으로 띄워주지도 않는다.) 다시 회원가입부터 시작.

이쯤 되면 진짜 똥개훈련. -_-a

ActiveX가 필요악이라는 것쯤은 이해하지만 조금만 생각해보면 아예 회원가입페이지로 진입할 때 ActiveX를 설치하도록 한다면 불필요한 재입력은 막을 수 있지 않을까? 사용자에게 입력받을 건 다 받아놓고 정작 마지막 순간에 ActiveX가 없다며 다시 입력해달라는 건... 우웅... (ActiveX가 설치안되어 있는게 내 잘못은 아니잖아.)

은행에 가서 기껏 번호표받아 줄서서 창구앞에 갔더니, 담당직원이 자기 화장실 좀 다녀와야겠다고, 그러니 다시 처음부터 번호표부터 받아오라는 소리처럼 들린다.
이러면 그 행원은 잘릴텐데, 웹마스터는 이런다고 잘리지는 않을테니 역시 금융권IT가 짱. 이건 아닌가?
한가지 확실한 건, 이거 만든 사람들은 이거 안써봤다에 백원. 아니면, 개발자들에게만 테스트를 맡겼거나. (유일하게 이런 거에 둔감한 사람들이 개발자들이니까.)

ps. 원래 목표했던 멤버십연결 메뉴 페이지에 접근했으나 순간 당황. 영화 섹션밖에 안보여서 도대체 어디서 알라딘 제휴멤버십을 살펴볼 수 있는지 알 수가 없다는. 보통 이런 섹션으로 진입시에는 섹션별 서브메뉴를 제공해주거나, 하다못해 전체 섹션을 조감할 수 있는 맵페이지가 존재해야 하는데 다짜고짜 타겟페이지로 이동시키면 어쩌라고. (모두들 영화만 본단 말인가?)
자세히 보니 섹션 바깥쪽, 사이트 좌측 메뉴에 Partner라고 되어 있는 부분이 있어서 거기에서 해당 페이지로의 진입이 가능하고, 또 최상단의 서비스 메인메뉴 중 멤버쉽파트너라는 메뉴에서 드롭메뉴로 서점섹션으로의 진입이 가능하기는 했지만...
그래도 브라우저를 닫아야 하는 건 아니기 때문에 이 정도는 너그럽게 봐줄 수 있다능.

2009년 3월 6일 금요일

개발괴발

지금 다니는 회사는 IT업계 중에서도 굴뚝산업이라고 할 만한 업종에 속합니다. 솔직히 말해 입사하기 전까지는, 저기는 개발자의 막장이라는 편견을 가지고 있었을 정도.

지금은 그런 편견은 없습니다만(월급은 소중한 것이여...),
확실히 이전에 비해 개발이슈에 대해서는 화려함은 없습니다.

(네게 화려하다는 말이 어울린다고 생각하나?넌 가자미다. 진흙 투성이가 되라 -변덕규)


한참 web 2.0이니 신기술트렌드니 하는 것만 쫓아다녔던 때에 비하면 세상이 어떻게 돌아가는지도 모를 정도...
그나마 입사후 보직변경으로 개발도 아니고 전략기획만 하다보니 요즘엔 개발감이 무지 떨어지는 듯.

여하튼 요즘은 잠시 회사내 개발팀중 팀장 결원이 생긴 한 곳에 임시로 팀장대리로 개발아키텍트를 겸임하고 있습니다. 오전에는 A서비스 기획을, 오후에는 B서비스 개발을...

그러나 어디 그게 맘먹은 대로 쉽게 2인분을 할 수 있나요.

오늘 작업한 설계를 리뷰해보니 그야말로 진짜 개발괴발... 도대체 내 머리에서 나온건지조차 의심스러워 모두 깨끗이 날려버렸습니다.
심기일전하고, 책들 좀 꺼내서 복습 좀 하고... 머리 좀 맑게 해서 개발쪽의 감을 되찾아야 겠습니다. 벌써 1년째 시작만 하고 끝을 못냈던 아이폰 SDK도 좀 만져보고... 개인적으로 만들고 싶었던 서비스도 틈틈히 개발을 하고...

아. 참... 유부남에게는 그럴 자유가 없지. T_T

2009년 2월 9일 월요일

OSX에서의 PHP 개발도구 10선

개발현업을 떠난지 6개월. 그동안 paper work만 하다가 다시 개발에 어쩔 수 없이 발담그게 되었습니다.

RoR, Python, Jsp, .NET... 여러가지 작업 환경이 있겠지만, 역시 Rapid 개발에 PHP만한 것도 없는 것도 사실. 10년 전에, "나에게 C 컴파일러만 다오, 모든 걸 만들어 주겠오..." 라고 했던 것 만큼이나, 요즘은 "나에게 PHP 계정만 다오..." 를 외치는 중입니다. 네, 물론 이건 말도 안되는 개소리.

PHP 기반 개발 작업을 OSX로 할 때 어떤 도구들을 쓰는지 정리해봅니다.

1)
MAMP (http://www.mamp.info/en/index.html)

OSX에 APM설치하기 에서도 쉽네 어쩌네 이야기 했었지만, 실은 MAMP 하나면 OSX에서의 PHP 사용준비는 끝나는 셈입니다. 원클릭으로 AMP 개발환경이 준비됩니다.

2) Terminal.app
다른 이들은 여러가지 터미널 어플리케이션을 쓰지만, 저에게는 이걸로 충분. 적당한 SIMBL 플러그인을 사용하면 굳이 별개의 터미널 프로그램이 필요없더라는...

3)
TextMate(http://macromates.com/)
두말하면 잔소리인 TextMate 입니다. 아니, 이거 외에 다른 에디터가 존재한다는 소문이 사실인가요? 유료라는 점, 적절한 한글폰트가 마땅치 않다는 점이 단점. 물론 해결책은 있긴 합니다.

4)
Zend Studio (http://www.zend.com/en/)
...라고 말하긴 했으나, 실제로 PHP개발에 필수나 다름없는 IDE입니다. 도대체 옛날에는 어떻게 개발했는지 이해가 안된다능. JavaDoc/PHPDoc 구문과 결합하면 활용도 150%, Zend Framework과 결합하면 활용도 200%, XDebug, Zend Platform과 결합하면 효율 300%를 낼 수 있는 무서운 물건입니다. 유일한 단점은 유료라는 것. (그것도 엄청나게 비싸다는 점)

5)
Aptana (http://www.aptana.com/)
Zend Studio가 너무 비싸다면 Aptana를 대안으로 생각할 수 있습니다. Zend Studio의 기능과 90%정도 호환되며 나름 장점도 많지요. Zend Studio 6.X나 Aptana 모두 Eclipse를 기반으로 합니다. Zend 제품군과의 협업이 아니라면 Aptana도 훌륭한 대안이 될 수 있습니다. Aptana Pro는 유료이긴 하지만 그 값은 하는 물건. Jaxer 엔진을 통해 서버가 아닌 로컬에서의 JavaScript Front-end 개발이 용이하다는 점도 장점.

6)
PEAR (http://pear.php.net/)
DRY (Don't Repeat Yourself) 원칙을 명심하세요. PHP에서 무언가 하려고 고민중이라면, 일단 PEAR부터 뒤져봐야합니다. 분명히 PEAR에서는 그에 대한 솔루션이 준비되어 있을 겁니다.

7)
Firefox / FireBug / Yslow
심지어 IE 전용 웹서비스를 만든다 하더라도 위의 세가지 콤보는, 웹서비스를 제대로 만들고 있는지에 대한 반증입니다. Aptana / Zend Studio의 디버깅 기능과 연동하면 효과 double!

8)
SVN (http://subversion.tigris.org/)
CVS도, Git도 다 좋습니다만... 형상관리 또는 버전관리 도구로 SVN을 쓰는 이유는 따로 있습니다... 뭐냐 하면...

9)
Trac (http://trac.edgewall.org/)
바로 Trac과 연동되기 때문이지요. 비록 9번째에 꼽히긴 했습니다만, 비중 및 업무 효율로 따지면 프로젝트의 절반을 차지할 만한 놈입니다.

10)
Doxygen / PhpDocumenter
Doxygen은 좀 더 예쁘고 강력하지만 JavaDoc 기반의 범용도구로써 PHP 특화로써는 약한 면이, PhpDocumentor는 PHP전문이지만 좀 오소독스한 면이...
어찌 되었건 소스 문서화를 위한 최고의 솔루션이자 Zend Studio나 Aptana 등의 IDE환경에서의 사용자 편의를 위한 최강 코딩팁인 셈입니다.



그 외에 여러 도구가 있겠지만(예를 들어 PHP TDD 관련 툴이라든가... ) 일단 최소한 이정도...
다음 번에는 OSX에서의 기획작업을 위한 도구들 이라든가, OSX에서의 프로젝트 관리를 위한 도구들... 을 한번 올려보겠음. 안 귀찮다면.






2009년 2월 2일 월요일

보안이란...



전산보안에서 가장 큰 취약점은 포스트잇에 적어 모니터에 붙여놓은 패스워드.

가끔 보면,

1) "반드시 N자리의 숫자로 패스워드를 구성"하라거나,
 : 보통 4자리 숫자 패스워드는 익숙하지만, 갑자기 7자리 숫자로 입력라고 하면 패스워드 만들어내는 게 고역이 된다. 7자리라는 숫자단위는 자주 사용되지 않는 단위라서 만들어내기도 어색하고 기억하기에도 어색하다. 차라리 자릿수 제한을 없애고 X자리 이상이라는 조건만 둔다면, 개인에 따라 각자 자신이 기억하기에 편리한 자릿수로 결정할 수 있을텐데...

2) "반드시 숫자나 특수기호를 하나 포함하여..."
사전 대입법을 이용한 해킹시도에 대한 방어법이긴 한데, 이렇게 하면 대개의 경우 그냥 숫자 0을 덧붙이거나 ! 정도를 덧붙이기 마련이다. 즉 "lullaby"라는 패스워드가 사전대입법에 취약해서 안된다고 하면 대부분의 사용자는 그냥 "lullaby0"이라는 패스워드를 만들고 만다. 기존 해킹방법에 비해 2배(대부분 0을 붙이고 마니까)~10배(고작해야 한자리 숫자만 더 붙이고 나니까.) 정도의 시간만 더 투자하면 뚫리게 된다는 소리. 물론 "jx7d%Q#~" 같은 패스워드를 만드는 사람도 있고 이런 경우 안전하지 않겠냐 하겠지만(저걸 기억할 수 있는 사람이 있다는 가정하에), 해커입장에서는 "lullaby0" 형태의 패스워드가 더 많으니 대략 마지막에 숫자 한자리 붙여서 시도해보고 안되면 다른 계정에 대해 시도해보면 그만이다. 결국 시스템의 해킹가능성에 대해서 열려있다는 점에는 변함없다.
아예 원천적으로 패스워드 오류시 재입력 횟수 제한(패스워드 5회이상 틀릴 시 계정 블록)을 두는 쪽이 사용자에게도 편하고 또 보안에 대한 경각심을 불러일으킬 수도 있다. 내 계정이 블록당했다면(혹은 블록위험이 있다면), 최소한 해킹시도가 있었음을 알게 될테니까.

다 떠나서, 각각의 서비스 단위에서는 나름 안전한 해킹방어를 한다쳐도, 대부분의 사람들이 여러 서비스에 대해 같은 패스워드를 쓰는 마당에 어떤 한 서비스만 뚫리면 다른 서비스에도 무방비가 되는 셈.

전산보안은 풀리지 않는 숙제...

2008년 12월 4일 목요일

사장이 디자인을 맘에 안들어할 때

임원들이 디자인을 맘에 안들어한다면 어떻게 해야할까?

어떤 상품을 만들기 위해서 필요한 프로세스 단계에서 당연히 고객을 우선해야 한다는 명제는 누구나 수긍할 것이다.
흔히 간과하는 부분중에 하나는 고객이 단지 우리 상품의 사용자, 구매자만을 가리키는 것은 아니라는 것. 이런 외부고객외에도, 실제로 같은 회사에서 일하는 관계자들도 일종의 내부고객인 셈이다.
즉, 기획자라면 단순히 실제 서비스를 이용할 소비자만을 대상으로 기획안을 만드는 것 뿐만이 아니라, 그것을 실제로 만들 개발자나 디자이너, 경영진들, 심지어 같은 기획팀의 다른 팀원들까지도 감안한 기획을 해야 한다는 점. 물론 이건 개발자도, 디자이너도, 경영진들에게도 모두 해당되는 이야기.

예컨데, 이 웹페이지에서 어째서 폰트가 14pt인 것인가... 아, 물론 디자이너는 당연히 '사용자의 시각에 대한 사용자경험을 고려하여'라고 대답하겠지만. (그런데 솔까말 대개는 그냥 그순간 디자이너의 삘아닌가?)

폰트사이즈가 맘에 안든다는 사장님의 말씀에, "이 웹서비스의 타겟 고객은 이미 보고드린 것 처럼 빨강머리 왼손잡이들을 대상으로 하고, 이들에 대해 한국갤럽연구소에서 1200명을 상대로 표본조사한 결과, 이들의 시상하부에서의 호르몬 대사의 특징상 생리학적인 반응속도의 지연이 공통적으로 발견되는 바, 이로 인한 이들의 모니터구매패턴이 대개 삼성패널을 이용한 LCD 21"를 사용하는 것으로 판단되어 이에 가장 최적인 14pt 궁서체를 사용했습니다."라고 즉석에서 술술 말할 수 없다면 그냥 조용히 다시 디자인하는 게 정신건강안녕 및 명랑조직생활을 위해 최적.


나의 경우는 대개,  "아, 좋은 의견이십니다. 여러분들의 의견을 수렴해서 다시 반영하도록 하겠습니다." 라는 멘트를 날려주고, 대충 요구사항을 정리한 후에,  다시 한번 내맘대로 만들어서 들이대면 대개 두번째에는 매우 만족하면서 OK된다. 심한 경우에는 날짜를 좀 두고, 처음 만들었던 것을 다시 들고가도 통과되는 행운도 있다.

사실, 이런 케이스들은 뭐랄까, 자기 자신이 상급자라는 것을 보여주기 위한 의도적인 딴지인 경우들이 많아서. 실상 임원진급이 실무자도 아닌바에야 실무자보다 더 정확한 판단을 내릴 수는 없는것임. 실제로 그들은 아마츄어니까. 임원진의 간섭에 의한 대표적인 참사가 몇년 전 코리아닷컴의 무지개디자인 사태아니었나...
그렇다고 그들의 권위 및 권력에 반항하거나 하는 건 역린을 건드리는 것이니, 그들이 필요한 건 진짜로 사용자에게 적합한 폰트 사이즈를 찾는 게 아니라, 그들의 존재가치를 인정해주고(하긴 임원진들은 골프나 치라고 있는 직책아니던가) 그들이 여전히 현역만큼이나 뛰어난 능력자라고 추켜세워주는 것. 그 조건만 맞춰준다면 똑같은 디자인을 또 들고 가도 통과될 수 있다니깐...


이런 지경까지 오는 게 귀찮다면, 애초에 두가지 시안 - 하나는 통과되기를 바라는 공들인 작업물, 또 하나는 일부러 못만든 탈락후보물 - 을 들고 들어가면 된다. 그러나 그렇게 까지는 잘 안하는데, 그 이유는 두가지를 만드는 게 귀찮을 뿐더러, 대개 그런 지경까지 가는 조직이라면 의외로(?) 탈락후보물을 선택하는 케이스가 왕왕 있기 때문에. 그러면 더 난감하기에.

아, 물론 위에 말한 건 지금 회사 이야기는 절대 아님. :D


ps. 여담인데, 그런데 실제로 사장님보다 능력이 떨어지는 개발자라든가, 이사님보다 디자인 못하는 디자이너가 실제로 있으니 그것도 난감한 일이긴 하더라.

ETRI 글로리 사업 발표회

ETRI GLORY 사업 발표회에 다녀오다.

기념품으로 고작 볼펜 하나 주다니 췠.

발표회라서 기술적인 내용도, 전략적인 내용도 없었다. 그저, 간단한 소개와 시연 뿐.
30분만에 나왔음. 자세한 내용을 알려면 나중에 전화로 연락하라 하길래.

구글 스타일의 저비용고용량 웹서비스를 준비하는 회사라면 기술이전신청하면 됨. 우리는 당장 써먹을 건 아니라서 그냥 나왔음.

아무리 생각해도 볼펜 하나라니 매우 불쾌함. 주차비도 지원안되는데 말이지.

2008년 12월 3일 수요일

실전! ROI 높이기


어떤 서비스의 회원가입프로세스에 개선되어야 할 부분이 좀 많았다.

0) 서비스 전체적으로 체계적인 통계나 분석이 전무했다.

1) 평일 평균 방문수가 32000명 수준인데, 이중 99.9%는 재방문자이고 신규가입을 위한 방문자는 매우 적은 상황이다.

2) 그럼에도 불구하고 서비스 메인페이지는 각종 알림(?)으로 빡빡하게 채워져 있으나... 99.9%의 재방문자는 다른 서브 페이지들은 들어가보지도 않고 바로 로그인해서 본인의 페이지로 이동한다. 참고로 서비스 메인페이지에서 가장 클릭률이 높은 링크(로그인을 제외하고)의 클릭률은 고작 0.03% 수준이다. 이는 방문자들의 목표가 너무 명확하기 때문이다.

3) 여러 경로를 통하여 가입이 가능한데 모두 스크립트로 띄워지는 팝업 가입창으로 연결된다. 브라우저에서 팝업 스크립트가 막히는 경우도 있고, 브라우저에서 스크립트 오류로 팝업이 작동안할 가능성도 있으며, 사용자는 팝업창으로 인해 혼란을 느끼거나, 혹은 배경에 깔려있는 메인 브라우저창에 유혹되어 가입프로세스를 미처 끝내지 못하는 경우가 있었다.

4) 또한 가입시 입력받는 내용이 많고, 입력 오류 등에 대해 명확한 지시와 즉각적인 알림이 부족했다.


그래서...

변경가능한 점을 찾아보았다.

0) 일단 Google Analytics를 설치하여 데이터 수집 후 분석

1) 원래 서비스 컨셉 자체가 가입한 회원대상이므로 컨셉은 넘어가고... 신규가입 유도는 광고등의 트래픽 증가로 해결해야 하는 부분이기 때문에...

2) 메인을 변경하고 싶었지만 일단 너무 위험하다는 판단하에 상부에서 기각.

3) 대신 팝업 가입창말고 가입페이지를 만들기로 결정, 그러나 스크립트를 사용하여 로딩하는 부분은 변경하지 못했음(이미 너무 많은 곳에서 쓰고 있기 때문에 변경하기가 어려움)

4) 대신 ROI를 높이는 것을 목표로 가입페이지를 리디자인하기로 함.


그리하여

 * 사용자의 주의를 분산시킬 수 있는 모든 장식용 이미지, 링크 등을 없앰. (심지어 메인 메뉴등도 없앰)

 * 불필요한 입력항목들은 빼거나 감춰버림. 가입 후 등록할 수 있거나 변경할 수 있는 내용들은 최대한 가입단계에서는 받지 않도록 함.

 * 사용자의 입력오류를 즉석에서 알려주고 교정을 유도함으로써 입력오류로 인한 실패경험을 줄이도록 함.

을 반영하도록 했다.


그 결과,

개선전에 비해 가입전환에 대한 ROI가 30.0%에서 35.6%로 상승.


원래 신규방문수가 적기 때문에 가입자 수가 왕창 뻥튀기 될 수는 없는 상황이지만, 5.6%의 상승은 충분히 유의미한 수치임.


이 말은, 상대적으로 비용이 많이 드는 트래픽 증가(키워드광고, 제휴, 배너, 영업, 지식인노가다, 카페, 블로그 이벤트 기타 등등)대신, 내부적인 작은 개선 만으로 같은 효과를 올릴 수 있다는 뜻. 즉, 기존 32000명 정도의 트래픽을 34000명으로 늘리기 위해 추가적인 트래픽 유도 비용을 지출하는 대신 개발자와 디자이너의 간단 수고로 그만큼의 효과를 볼 수 있다는 것.


게다가 내부개선을 통한 ROI 증가는, 실제로 유입되는 트래픽을 늘렸을 때 그 효과가 더 크게 증폭되게 된다.


주절주절 쓰긴 했는데, 실제로 실천방안이나 효과 이런 건 다음 책을 참고하는 게 가장 낫겠다. 사실 아래 책에 나와 있는 내용 그대로를 실천했을 뿐이니까. (이 정도는 리뷰로 안쳐주는 건가?)




ROI를 높이는 웹 사이트 - 10점
Lance Loveday.Sandra Niehaus 지음, 박재곤 옮김/이한디지털리(프리렉)