2010년 4월 19일 월요일
알라딘 아이폰 앱 유감
2010년 3월 23일 화요일
IE Error : KB927917
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일 월요일
아드레날린 중독증
![]() | 프로젝트가 서쪽으로 간 까닭은 - ![]() 톰 드마르코 외 지음, 박재호 외 옮김/인사이트 |
2009년 8월 10일 월요일
보안을 위한 타임아웃
2009년 7월 21일 화요일
재밌는 정부
2009년 7월 8일 수요일
화이트노이즈 핑거프린팅을 이용한 저작권 워터마크 크롤링


2009년 7월 3일 금요일
XHTML의 종말
2009년 6월 2일 화요일
이런, Project NATAL
2009년 5월 15일 금요일
한겨레 리뉴얼
2009년 4월 17일 금요일
성공적인 사내 제안을 위해
![]() | The One Page Proposal - ![]() 패트릭 G. 라일리 지음, 안진환 옮김/을유문화사 |
![]() | 당신의 기업을 시작하라 - ![]() 가이 가와사키 지음, 김동규 옮김/랜덤하우스코리아 |
2009년 4월 7일 화요일
PM과 PL
2009년 3월 12일 목요일
집단지성
2009년 3월 9일 월요일
웹사이트 가입으로 똥개훈련하기
2009년 3월 6일 금요일
개발괴발

(네게 화려하다는 말이 어울린다고 생각하나?넌 가자미다. 진흙 투성이가 되라 -변덕규)
2009년 2월 9일 월요일
OSX에서의 PHP 개발도구 10선
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 글로리 사업 발표회
기념품으로 고작 볼펜 하나 주다니 췠.
발표회라서 기술적인 내용도, 전략적인 내용도 없었다. 그저, 간단한 소개와 시연 뿐.
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를 높이는 웹 사이트 - ![]() Lance Loveday.Sandra Niehaus 지음, 박재곤 옮김/이한디지털리(프리렉) |