내 블로그, 광고 유치하면 얼마를 받아야 하나?

이삼구글 블로그의 스폰서 광고 프로그램을 진행하면서 한달에 얼마의 금액을 받아야 할 지에 대한 근거를 계산해 보았습니다. 이 계산법은 블로그 만이 아니라 여타 홈페이지에도 동일하게 적용될 수 있는 일반화된 방법입니다.

1. 우선 카운터를 달자
태터툴즈에 내장된 카운터는 허수가 많기 때문에, 추천하는 카운터로는 구글 웹로그 분석기(Google Analytics)와 SiteMeter 이 두가지 입니다. 개인적으로는 이 두가지 프로그램을 동시에 사용하고 있고, 최근에 나온 인사이드 다음이라는 카운터도 직관적인 테이터를 표시해주기 때문에 국내 서비스로 추천합니다. 이 세가지 서비스는 모두 무료입니다.

2. 한달 간의 유입 데이터를 측정하자
페이지뷰는 얼마인지, 유니크 유저는 몇명인지를 알아봅니다. 페이지뷰는 말 그대로 몇번 보여졌느냐 하는 것이고, 유니크 유저는 몇 명의 유저가 다녀갔나 하는 데이터입니다. 이 두가지 데이터는 거의 모든 카운터에서 제공하는 필수적인 데이터입니다.

3. CPM 얼마로 할지 상상하자
CPM은 1000번 노출할 때의 광고비입니다. 예를 들어, 만번의 노출이 있고, 광고 가격이 CPM 2,000원이라고 할 때, 총 광고비는 20,000원이 됩니다.

일반적으로 다음이나 네이버와 같은 상위 포털의 경우, 위치에 따라서 CPM 1,000원 부터 CPM 5,000원까지 다양합니다. 멀티미디어 광고의 경우 CPM 10,000원까지도 받는 경우가 있지만, 예외적이라고 할 수 있습니다.

페이지뷰당 광고비는 상위 포탈이 굉장히 저렴한 편입니다. 평균적인 자리일 경우 CPM 2,000원을 받고 있는데, 2순위 포탈의 경우 그보다 조금 더 비쌉니다. 그리고, 외국 언론의 경우 CPM 5,000원 이상인 경우가 많습니다. 일반적으로 타겟팅 된 웹사이트의 경우가 그렇지 않은 경우보다 비쌉니다.

4. 가격을 계산하자.
이삼구글의 예를 들면, 한달 페이지뷰는 4만번이 조금 넘고, 유니크 유저는 만 육천명이 조금 넘습니다. 제가 정한 CPM 2,500원의 가격을 적용하면 이렇습니다.

40,000 * 2500/1000 = 100,000(원)

CPM 2,500원이라는 금액은 타케팅 된 웹사이트의 경우 비싸지 않은 금액입니다. 그리고, 광고의 크기는 125*125로 작은 편이지만, 우측 최상단에 위치해 있기 때문에, 방문자들은 항상 이미지 광고를 보게 되는 좋은 자리입니다.

광고를 유료로 게시할 때 주의할 점은 좋은 자리를 주어야 한다는 점입니다. 이렇게 생각하면 좋습니다.

“내가 광고주라면, 저 자리를 저 금액으로 들어갈 것인가?”

5. 자동 계산 프로그램
숫자에 약한 분들을 위해, 리플넷에서 제공하는 블로그 광고 단가 계산하기 페이지를 방문해 보세요. 두가지 정보를 가지고 있다면, 자신의 블로그에 적합한 광고비를 계산할 수 있습니다.

제로보드(zb5) 그리고 MetaBBS

멋진 솔루션을 만들어 놓고도 “이제 시작입니다”라고 말할 수 밖에 없을 정도로 제로보드의 새로운 버젼인 zb5는 꽤 커다란 프로젝트가 아닐 수 없습니다. 또한, 많은 사람의 기대를 받고 있는 프로젝트 이기도 하고, 이 프로젝트가 성공적일지 아니면 실패로 끝날지 개인적으로 기대가 되기도 합니다.(성공이라하면 역시 몇년간의 주기적인 개선이 되겠지요.)

zb5는 게시판이라기 보다는 실질적으로 하나의 웹 제작 플랫폼이라고 볼 수 있습니다. 그 정점에는 로그인을 포함한 회원관리가 들어가 있습니다. 기술적으로 본다면 인증이 상호 교류가 되면 게시판 연동이라는 것도 부수적인 요소가 될 수도 있습니다. zb5는 인증을 중심으로 전혀 다른 솔루션을 포함할 수 있는 그야말로 모든 웹 제작의 플랫폼이 될 가능성도 있습니다. 다만, 한국에선 전례가 없던 일이고, 사이트빌더를 표방한 몇개의 프로젝트는 소유욕이 강한 한국에선 무참히 실패해 버렸습니다. 하지만 제로보드라면 가능할지도 모르겠습니다.

zb5가 나온 후 제 눈길을 끄는 프로젝트라면 단연 MetaBBS입니다. MetaBBS의 중심을 이루는 CN님과 디토님의 다른 BBS와의 차이점에 관한 코멘트를 보도록 하죠.

디토님 답변 인용:

일단 phpBB와는 목적 자체가 다릅니다. metabbs는 제로보드에서 확립된 이른바 ‘한국형 게시판’의 구현을 목적으로 하고 있습니다.
jsboard도 물론 좋은 게시판 엔진입니다. 하지만 metabbs는 전통적인 PHP 웹 애플리케이션의 개발 방식이 아닌, 재사용이 가능한 프레임워크의 형태를 취하고 있는 차이점이 있다고 할 수 있겠죠.
사실 그리고 fork를 하게 되면 원래 프로그램의 구조를 파악해야 하는데 이것 또한 귀찮은 일이 아닐 수 없습니다.;;;

CN님 답변 인용:

기존의 게시판 시스템 중 MVC 패턴을 취한 게시판을 찾아보기는 힘들었습니다. 가끔 볼 수 있는 JSP 게시판에서 모델 2라는 형태로 구현된 경우를 볼 수 있었습니다만 국내에서는 JSP 서적이면서 모델 2를 다루지 않거나 잘못된 내용을 다룬 경우가 많았습니다.MetaBBS는 재사용성과 MVC 패턴의 적용이라는 점에서 마음에 들었습니다. PHP로도 이런 시도가 많아진다면 점점 프레임워크에 대한 관심이나 응용이 많아질 것이라고 생각합니다.

즉, MetaBBS는 게시판 제작의 프로세스를 실험하는 프로젝트라고 볼 수도 있을 것 같습니다. MVC 패턴을 프로젝트에 가미하게 되면 유지보수가 극적으로 향상될 수 있어서 실제 프로젝트에도 적용되고 있습니다.(약간 오래된 이야기지만…)

제로보드의 전통적인 지지자가 디자이너라고 보면 zb5의 성공은 확실하지 않을지도 모릅니다. zb5의 새로운 모듈 개발이 기존 제로보드의 스킨을 만드는 것 처럼 만만하지 않게 될 가능성이 크기 때문입니다. 따라서, 중급 이상의 프로그래머 투입이 요원한데, 그런 관점에서 보면 MetaBBS의 장점은 zb5의 장점과 비교해도 손색이 없습니다.

MetaBBS의 소스를 들여다보면 기능별 클래스가 매우 깔끔하고, 여러가지 기능을 효율적으로 결합하려 노력한 프로그래머의 노력이 엿보입니다. 물론 이런 것들은 프로그래머의 실력차가 중요하기 보다는 설계를 어떤 식으로 했냐 라는 정책적인 문제가 중요하기 때문에 꼭 무엇이 옳은 방향이다 라고 말하기는 어렵습니다.

웹 제작에 관련된 분들이라면 zb5 고려와 함께 MetaBBS도 함께 고려할 필요가 있어 보입니다.

연관 링크

zb5 베타버전 공식 사이트
MetaBBS 공식 사이트
MetaBBS 개발 사이트(KLDP)

아이베키님의 구글(Google) 체크아웃 사용기

아이베키 블로그 인용:

구글에서 얼마 전에 론칭한 ‘체크아웃’ 서비스를 며칠간 사용해 본 소감입니다. 지극히 개인적인 소감이고 개인적인 문제도 있어 코멘트를 하기가 약간 꺼려지기도 하네요.

구글 체크아웃은 현재 미국에서만 서비스 되고 있기 때문에 이삼구글 웹로그에서 테스트를 할 수가 없습니다. 고맙게도 아이베키님이 몇일간의 사용기를 올려주셨습니다.

구글 체크아웃은 GBuy로 알려져 있었는데, 구글에선 부인하지만 굉장히 포괄적으로 사용될 수 있는 서비스입니다. 그 중 직격탄을 맞을 수 있는 회사가 ebay의 PAYPAL 서비스입니다. 현재의 페이팔은 경쟁상대가 없을 정도로 관련 시장을 점유하고 있습니다. 구글 체크아웃은 페이팔 기능을 일부 흡수 할 수 있고, 수수료도 약간 저렴합니다. 얼마전 이베이에서 구글 체크아웃 사용자는 밴(Ban)시킬 수 있다는 기사도 나왔었을 정도로 이베이는 예민합니다.

이삼구글 블로그에서 이 부분에 신경을 많이 쓰지 않는 이유는 한국에 들어올 가능성이 매우 희박하다고 판단해서 입니다. 정보통신부의 권고로 공인인증서를 쓰거나 해야 할 필요가 있는데, 그런 부분을 만족시키면서까지 페이팔을 한국에서 서비스 할 필요가 있을지 회의적입니다. 이베이의 자회사인 옥션도 이베이의 결제 서비스는 이용하지 않고 있지요.

아무튼 구글이 세계를 상대로 구글 체크아웃 서비스에 들어간다면 이삼구글 블로그에서도 심층적으로 알아보겠습니다.

리플라드 애드(replad ad) 기획 변경

최고의 광고효과를 최저의 페이지뷰로 구현한다는 취지에 개발하고 테스트 중인 리플라드 애드가 세달의 테스트를 마치고 기획 변경에 들어갑니다.

이번 테스트로 광고주와 매체 사이에 발생하는 심리적인 부분이 광고비에 영향을 준다라는 사실을 알게 되었습니다. 즉, 광고주는 자신의 선택이 있을 경우 더 많은 광고비를 지불할 가능성이 있다라는 사실입니다.

리플라드 애드의 테스트 후기

리플라드 애드에서 가장 염두에 두었던 광고 형태가 CPA 였고, 광고를 클릭해서 결제가 이루어 진다면 광고주와 매체사 모두에게 이익이 될 것이라는 가정이 프로젝트의 출발이었습니다. 하지만, 상식적인 이야기지만 광고비는 매출이익보다 작을 수가 없습니다. 만약 광고비가 매출이익보다 작다면 광고비를 한없이 올리면 매출이익이 더욱 커지는 상태가 됩니다. 다시 말하면 블루오션이 생길 수 있다는 것이고, 제가 바란 것이 블루오션이었던 것입니다.

과거 인터넷 광고를 진행할 때, Daum, Naver, Yahoo!에 배너를 올렸을 때 회원 가입 당 비용은 최저 16,000원에서 70,000원이었습니다. 그리고, 현재 제휴마케팅의 회원 가입 당 수수료는 500원, 많게는 1000원 정도 됩니다. 오버추어의 경우면 특별히 25,000원을 책정하고 있지만, 결제를 통해 계정을 만들어야 합니다.

일반적으로 포탈사이트의 배너 광고비는 CPM 2000원입니다. 즉, 1000번 노출에 2000원을 지불해야 된다는 이야기지만, 제 테스트 상으로 CPA 광고를 적용했을 경우 54원이었습니다. 이것은 매체에 맞는 제품이나 서비스를 위한 최고 클릭율의 배너를 제작해서 한 테스트였다는 점을 감안해 본다면 매우 실망스러운 결과입니다.

따라서, CPA의 수익쉐어가 대폭 늘어나지 않는 한은 리플라드 애드에서는 더이상 CPA를 이용한 솔루션 제작을 하지 않을 예정입니다.

현재 제휴마케팅의 머천트(광고주) 들이 수수료를 줄이고 있다는 점을 감안해 본다면 아마도 다시 한번 테스트를 할 기회는 기대하기 힘들 것 같습니다.

앞으로의 계획

광고 솔루션을 제작하면서 광고주의 선택권이 있어야 함을 알게 되었습니다. 말 그대로 Sponsor Link로의 전환을 계획하고 있습니다.

광고비가 대부분의 수익을 차지하는 웹사이트 운영자는 자신의 웹사이트 신뢰도를 높이는 것에 신경을 써야 합니다. 방문자가 웹사이트를 믿지 못하면 광고 효과도 높지 않습니다. 일반적으로 신문를 예로 들자면 부수가 많은 신문에 광고비가 높다는 것을 알 수 있습니다. 하지만, 실제 광고를 수주할 때는 부수에 비례해서 광고비가 책정되지는 않습니다. 즉, 신뢰도가 높은 신문이 높은 광고비를 받게 됩니다. 이 부분은 소비자가 느끼는 광고의 신뢰도와 매우 높은 관계가 있습니다. 쉽게 말하자면, “야동 웹사이트엔 광고가 걸리지 않는다”라는 맥락과 같습니다.

따라서, 광고주가 느끼는 매체 신뢰도의 측정 모델을 개발할 것이며, 부가적으로 매체에 최적화되고 누구나 가입할 수 있는 오픈형 솔루션을 제작할 것입니다. 또한 가능하다면 광고가 매체 신뢰도에 미치는 영향을 분석하고 싶습니다만, 여기에 대한 분석 모델을 전혀 알지 못해서 시간이 걸릴 수도 있을 것 같습니다.

목표 수익률은 가장 신뢰도가 높다고 알려진 키워드 검색 광고의 1/2입니다. 즉, CPM 2000원이 됩니다. 이 가격은 포탈사이트 중 가장 저렴한 상위 3사(Naver, Daum, Yahoo!)와 같습니다.

Google이 태그를 무시하는 이유

PRAK’s Blog 인용:

구글 노트북 같이 자료를 모으고 분류하는 애플리케이션에 왜 애시당초 태그기능을 넣지 않았을까요? 정말 궁금해 죽겠습니다. 누구 아시는 분 좀 알려주세요.

Google이 처음 PR(페이지랭크)로 검색엔진을 개발했을때 백링크의 갯수를 등차수열로 점수를 메겨 랭크를 매긴다는 매우 간단하면서도 신뢰성있는 알고리즘을 사용했습니다. 하지만, 최근 Google의 알고리즘을 보면 PR보다는 트랜드를 적용하는 개인화 데이터를 더 많이 적용하는 것 처럼 보입니다. 이 부분은 이삼구글 웹로그에서 몇번 언급한 적이 있습니다.

Google만이 아니더라도 웹페이지의 태그 시스템이라고 일컬어지는 메타태그의 Keywords는 현대의 어떤 검색엔진도 주의깊게 보지 않고 있습니다. 몇가지 이유가 있겠지만, 태그라는 것의 단점은 태그를 작성하는 표준을 만드는 것이 사실상 불가능해 보이기 때문입니다. 그리고, 웹 2.0에서 흔히 나오는 태그, 트랙백은 구조상 스팸을 막는 것이 불가능합니다.

태그의 작성 표준은 단어 한개로 만들어져 있을 경우 말 그대로 집단지성이 작동할 가능성도 있긴 합니다. 그렇지만, 스팸의 경우는 해결 방법이 있을 것 같지가 않습니다. 자동화를 지향하는 Google도 악질적인 SEO(검색엔진 최적화)는 수작업으로 검색 리스트에서 삭제해 버립니다.

Google에서 운영하는 Blogger의 경우 트랙백과 태그 둘 다 허용하지 않습니다. Blogger의 구조상 그 둘을 구현하는 것은 복잡하지 않습니다. Blogger에서 해 주지 않아도 스크립트가 작동되는 서버를 FTP로 설정할 경우 태그와 트랙백 시스템을 구현할 수 있습니다. 그리고, Blogger 자체로도 그 구현은 어렵지 않을 것 같지만, Blogger는 백링크만을 허용하고 있습니다.

이삼구글에서는 Google이 태그, 트랙백 등에 가중치를 부여하지 않는 것이 스팸 때문으로 보고 있습니다.

Google판 지식인 서비스, 질문 삭제

비교적 공정하다고 평가받고 있는 Google에서 미국판 유료 지식인 서비스인 Google Answers의 질문이 삭제되는 일이 발생했습니다. 그런데, 문제가 되는 부분은 질문 자체가 Google에 대한 것이라는 사실인데요, Google 전문 블로그인 Google Blogoscoped는 이 사실을 자세히 설명하고 있습니다.

발단은 이렇습니다. Steve Hall은 미화 20불을 걸고 다음과 같은 질문을 올렸습니다.

Northwest VC 인용:

“What percentage of Google searches are contextual?”

이 질문이 삭제되어 Steve Hall과 Google Blogoscoped의 운영자 Philipp Lenssen이 Google에 메일을 보냈는데, 아래와 같은 메일을 받았다고 합니다.

“We’d like to clarify the reason for removal of this question. Please note that Google Answers researchers are not employees of Google. They are independent contractors, and they only have access to information about Google and Google Search that is publicly available. Therefore, all users with questions about Google and/or Google Search are directed to these Google support pages.”

말하자면, 답변자는 Google 직원이 아니기 때문에 Google과 Google 검색에 대해서는 답변을 할 수 없다는 이야기입니다.

위의 글에서 Google Answers researchers라는 단어가 나오는데, Google Answers는 researchers라는 전문가가 답변하는 형식입니다. 말하자면, 유료 질문이기 때문에 일반 회원은 코멘트를 달 수는 있지만, 답변을 할 수는 없습니다.

Google 툴바 4.0 한글판 버그

Google 툴바 도움말 인용:

툴바를 설치한 다음부터 Internet Explorer를 열려고 하면 런타임 오류가 발생합니다.이 문제로 불편을 드려 죄송합니다. Google 엔지니어들이 이 문제에 대해 이미 알고 있으며 현재 조사를 진행 중입니다. 협조해 주셔서 대단히 감사드리며, 다음 정보와 함께 저희에게 문의해 주시기 바랍니다.

영문판을 소개한 글에서 치명적인 버그로 사용하지 않을 것을 권고한 적이 있는데, 이번 한글 버젼도 버그가 존재합니다. 이번 버그는 IE를 제대로 작동하지 못하게 하기 때문에 치명적이네요. 데이터를 날린다던가 하는 부분은 없으나, 브라우져 렌더링 부분에 오작동을 일으킵니다.

반면 FireFox용인 Google 툴바 2.0은 매끄럽게 작동하는군요.

메일발송과 문자셋 문제

예전 PHPSCHOOL에 적은 글을 이삼구글에 질문을 하시는 분이 계셔서 참고로 올립니다. 메일과 인코딩에 대한 정리입니다. 개발자 커뮤니티에 올린 글이니만큼 개발자가 아닌 분들에게는 다소 어지러워 보일 수도 있습니다.

아래의 내용은 메일 발송시 참고해야 할 사항을 정리한 것입니다.

1. 인코딩
; 메일의 본문은 인코딩을 할 필요는 없습니다. 어짜피 클라이언트쪽에서 지원하지 않으면 인코딩을 했건 그렇지 않건간에 볼 수가 없으니까요. 문자셋만 제대로 써 주면 됩니다.
단, UTF-8의 경우는 hotmail에서 볼 수 없고, 다음메일에서 클릭 한번 더 해줘야 하는 일이 발생합니다. 다른건 몰라도 메일은 유니코드쪽 보다는 로컬셋을 이용하는 것이 좋을듯 합니다.
본문 외에 보내는 사람, 받는 사람 이름과 제목은 반드시 인코딩을 해 줘야 합니다. 클라이언트에서 디폴트문자셋으로 지정되어있지 않으면 깨져서 보여버리죠.(최근 파란닷컴 메일이 보내는 이 이름이 깨져서 옵니다.)
인코딩하는 방법은 다들 아시다시피

‘=?ks_c_5601-1987?B?’.base64_encode($subject).’?=’

요거 되겠습니다. 가끔 ks 대신 euc-kr로 하는 경우도 있습니다. 네이버가 그런식으로 하는것 같더군요. 구글멜은 utf-8 되겠습니다. 🙂

2. text인가 html인가?
; 개인적으로 보내는 것은 몰라도 메일링리스트나 멜로봇이 보내는 것이면 둘 다 써주는 것이 좋습니다. 클라이언트 쪽에서는 자동으로 세팅을 보고 text쪽으로 보여줄지 html쪽으로 보여줄지를 결정합니다.
이 것이 중요한 이유는 보통 보는 쪽은 html로 하는 경우가 많지만, 보내는 쪽에서 text로 세팅이 되는 경우도 많은데(저 같은 경우) 리플라이 버튼을 누를 경우 text로 세팅이 되면 하단에 붙는 받은 메일 본문이 text에 있는 메세지가 붙어버립니다.
구글멜과 인터넷제국의 멜같은 경우가 둘 같이 보냅니다.

3. 헤더와 스타일 그리고 이미지
; HTML의 head태그나 body태그를 쓰는 경우가 있지만 전혀 필요없는 짓입니다. body 태그가 있다 치고 메세지를 작성하면 됩니다.
스타일의 경우 외부 파일을 링크시켜버리면 웹메일에서 적용되지 않는 경우가 많습니다. 야후닷컴 멜은 외부 스타일을 인정하지 않습니다. 따라서, 커스텀태그를 적용하는 편이 가장 편합니다.(템플릿언더바 사용자라면 포스트필터를 적용하면 편합니다.)
이미지의 경우 SP2부터 기본적으로 보여지지 않기 때문에 이미지를 링크시킬 경우엔 크기와 타이틀이나 alt속성을 넣어주면 좋고, 최상단의 경우 배너형식 보다는 이미지 따로 텍스트 따로 넣는 편이 좋습니다. 구글멜도 기본적으로 그림을 보여주지 않고, 다음의 경우는 메일마다 틀립니다.
스크립트의 경우는 넣어봤자 대부분 실행되지 않습니다. 야후의 음악멜의 경우 실행되는 웹메일을 거의 본적이 없네요. 플래쉬도 마찬가지로 실행되지 않습니다.

4. 확인 스크립트
; 보통 투명이미지로 확인했는지를 체크하는데, 광고의 효과면에서 볼때 그렇게 측정하는 것 보다는 모든 링크를 리다이렉트 시켜서 처리하는 것이 훨씬 정확합니다. 메일을 확인한 것이 중요한게 아니라 메일을 확인하고 클릭을 유도하는 것이 훨씬 중요합니다. 또한, 투명이미지의 경우 SP2나 구글멜, 다음 처럼 보여주지 않는 경우도 많기 때문에 정확도 면에서 신뢰할 수 없습니다.

5. 기타
; 다음의 우표정책을 시도 하시는 분들은 알아두시면 좋습니다. 정보성 메일로 신경써서 발송할 경우 대부분 정보성메일로 판명납니다. 하지만 응답자가 적을 경우 정보성의 유무에 상관없이 한달간 발송한 메일 전체에 과금됩니다. 우표정책에 대한 글을 다음에서 모두 읽어봤지만, 그 부분에 대해서 나온 부분은 1군데 밖에 없었고(회원가입 후의 화면) 그 메세지 마져 왠만하면 과금되지 않는다는 형식으로 쓰여져 있습니다.

그 외에 보내는 메일을 정확하게 작성한다던지, IP소유의 메일서버의 호스트명을 제대로 넣는다던지 하는 것은 다 아시리라 생각되네요.

덧글. 5번의 다음 우표정책은 지금은 시행되지 않습니다.

표준은 어디에나 존재한다. but…

nmind님의 언급처럼 표준이라는 것은 기술적인 것 보다는 약간은 정치적인 면이 있습니다. 시장이 커지면 보통 미국에서부터 표준화 작업이 이루어 집니다. 비영리 단체에서 그러한 일을 하고 있으며, 웹에서는 보통 W3C에서 관련 표준화 작업을 진행합니다.

마이크로소프트에서 만드는 OS도 표준이 존재하고, 비쥬얼 스튜디오에서 지원하는 언어들도 표준이 존재합니다. 심지어는 종교도 표준이 존재합니다.

일반적으로 표준은 처음엔 많이 쓰이는 부분을 묶는 것부터 시작하고, 시간이 지나면 선도적인 권고를 내놓습니다. 지금은 쓰이지 않아도 이렇게 하면 모든 이에게 이롭다는 식입니다. W3C에서 현재의 표준으로 삼는 XHTML1.1+CSS2.0이 과연 모든 이에게 이로울까요?

CSS 레이아웃의 표준

CSS 레이아웃을 만드는 것에 가장 불리한 점은 “쉽지 않다”라는 점입니다. 무슨 이야기냐 하면 W3C에서 제공하는 레퍼런스만을 보고 디자인을 할 수가 없습니다. 즉, 브라우져에 띄우기 전까지는 어떻게 나올지 알 수 없다는 이야기입니다.

즉, 테이블 레이아웃을 적용할 때에는 IE, FireFox, Safari 등의 태그 레퍼런스를 참고하지 않아도 디자인이 가능합니다. 그 이유는 테이블이라고 하는 것은 웹이 처음 생길 때 부터 존재했던 것이기 때문이죠. 하지만, CSS는 여러가지 브라우져가 나온 이후에 생긴 것으로 브라우져마다 적용 방법이 약간씩 틀립니다.

우리는 왜 브라우져 핵을 사용해야 하는가?

저도 과거에 CSS만으로 웹페이지를 구성한 적이 있습니다. 코드와 디자인의 분리는 만드는 입장에서는 꽤나 매력적인 것이 사실입니다. 즉, 코드는 DIV로 쌓여져서 그 자체로 데이터만 넣고, 디자인은 style.css 등의 파일 안에 넣습니다. 디자인을 고칠때에는 style.css파일만 수정합니다. 정말 매력적입니다.

하지만, 오래 지나지 않아서 브라우져 별로 CSS를 적용하는 것이 쉽지 않다는 것을 알게 되었습니다. 그리고, 전혀 불필요하지만 CSS만으로 디자인 할 때 필요한 것, 즉 브라우져 핵을 써야한다는 사실도 알았습니다. 브라우져들이 CSS를 적용을 달리하는데 우리는 한개의 CSS로 둘 다 제대로 나오게 해야 합니다. 프로그래머의 경우는 보통 동일 API를 사용할 수 있는 라이브러리를 만들어서 코딩을 하는데, 하나의 프로그램 코드가 유닉스던 리눅스던 윈도우던 동일한 출력을 보장하게 하는 가장 편한 방법입니다. Google이 Picasa 리눅스 버젼을 만든 방법이 이것입니다.

하지만, CSS는 단순한 상속의 개념은 있지만, 클래스처럼 그것을 자유롭게 활용하기가 구조적으로 불가능합니다. CSS 3.0에서는 해결이 될 것 같지만, 현재는 모든 브라우져에서 동일한 출력을 보장하는 CSS 파일은 불가능합니다.

따라서, 선택은 세가지로 압축됩니다. 브라우져 핵을 이용하거나, 브라우져 별 별도의 CSS를 만들거나 아니면 디자인 자체를 핵이 필요없는 것으로 바꾸거나…

방금 검색을 해서 알아본 두가지 CSS 코드를 소개합니다.

<style type=”text/css”>
#mydiv {
color: blue;
drdoc: “;
drdoc: “”;
color: red;
background: silver;
/*”;/* IE */
font-weight: bold;
}
#nextdiv {
color: red;
}
body {
background: navy;
}
</style>Note: IE will continue parsing after /* IE */

그리고,

<style type=”text/css”>
#mydiv {
color: blue;
/*/*/
drdoc: “;
drdoc: “”;
/* NN4 */
color: red;
background: silver;
/*”;/* IE */
font-weight: bold;
}
#nextdiv {
color: red;
}
body {
background: navy;
}
</style>

이것은 라운드 박스를 구현하는 CSS입니다.

border: 2px solid gray;
-moz-border-radius: 25px;
width: 400px;
height: 200px;
padding: 15px;

브라우져 호환성을 갖게 하기 위한 노력으로 이런 코드는 레퍼런스도 없습니다. 해보고 되면 블로그등에 올려서 전파됩니다. 그러고보니 집단지성이군요.

이 글을 보시는 관계자 분들은 위의 코드를 해석하실 수 있습니까? 만약 전임자가 이런 코드를 넣었다면 수정하실 수 있겠습니까?

CSS로 잘 만든는 것은 무엇을 의미하는가?

CSS가 쉽지 않다는 것은 누구나 알고 있습니다. 보통 CSS가 레이아웃을 잡는데 “잘 만들면” 더 생산적이고 편하고 빠르다라는 말을 하는 분도 있습니다. 물론 실력이 있어서 브라우져 핵을 자유롭게 쓰는 분일 것입니다.

여기서도 문제는 있습니다. 브라우져 핵이 필요한 CSS파일을 누군가는 만들어야 합니다. 프로그래머? 디자이너? 컨텐츠 제작자? 만약 웹디자이너가 한다고 하면 기업에서 면접을 볼 때 브라우져 핵을 하지 못하면 뽑지 말아야 하나요?

XHTML은 1.1버젼에서 HTML4.0과 양립할 수 없습니다. 어떤 해결방법이 있을까요? 전 현실적인 문제로 인해 찾을 수가 없습니다.

난 XHTML1.1+CSS2.0을 반대하는 것이 아니다. 하지만 불편한걸 어쩌나?

CSS를 설명하는 블로그를 보면 보통 팁으로 설명합니다. 브라우져 핵도 마찬가지구요. w3schools.com은 CSS 초기버젼을 잘 설명해 주고 있습니다.

제가 의문을 제기하는 것은 CSS 레이아웃에 한정하는 문제입니다. 어떤 분은 가능하다, 어렵지 않다 라고 합니다. 우리는 CSS로만 레이아웃을 할 때 아래와 같은 기능을 해야 합니다.

1. 모든 브라우져에서 같은 디자인이 출력되어야 한다.
2. 디자이너가 디자인 한 것 그대로가 화면에 나와주어야 한다.
3. CSS는 화면 크기를 변경했을 때 원하지 않는 동작을 하면 안된다.
4. 가로 길이가 %로 정해졌을 때도 3번은 지켜져야 한다.

제 경험으로는 위의 것을 CSS 레이아웃만으로 구현하는 것은 가능은 할 지언정 절대 쉽지 않습니다.

이렇게 되면 하겠다.

아래의 것들이 완벽히 작동된다면 CSS 레이아웃은 사용할 가치가 충분하지 않을까 합니다.

1. 브라우져별 공통의 CSS 레퍼런스가 존재하고, 그것이 제대로 작동된다.
2. 1번이 안된다면 공통 스타일 파일이 존재하고, 파일 레퍼런스만 지키면 대부분 브라우져에서 작동한다.

이 글은 Jay G님의 글에서 반론을 제기받고 답변으로 쓴 글입니다.

XHTML, HTML, CSS 그리고 테이블

용어의 혼돈으로 단문으로 쓰는 것이 좋을 것 같아서 차분하게 정리해 봅니다.

사실

1. XHTML1.1+CSS2.0은 현재 표준이라고 불리우지만, 영문으로는 권고라고 한다.

2. XHTML은 HTML의 확장판이며, HTML을 포함하고, XML형식의 모든 언어를 포함하는 구조를 지칭한다.

3. CSS에서 말하는 접근성은 일반적으로 시작장애자나 마우스가 없는 컴퓨터에서 쓸 수 있도록 만든다는 의미의 접근성과는 틀리다. 사람이 대상이 아닌 프로그램이나 기기(device)가 인식하기 쉽도록 한다는 의미이다. 예를 들어서 제목을 H 태그로 쓰면 다른 프로그램은 그 문단이 제목 혹은 중요한 문단이라는 것을 알고 가중치를 부여하는 등의 행위를 할 수 있게 된다.

4. CSS만으로 레이아웃을 하는 것은 어려운 작업이다. 하지만, 불가능한 것은 아니다. 일반적으로 테이블로 디자인 했을 경우 같은 디자인이라도 CSS만으로 만들면 경우에 따라서 뉴스가 된다.

주장

1. 테이블 레이아웃은 생산성 면에서 CSS 레이아웃보다 뛰어나다.

2. 유지 보수 측면에서도 CSS 레이아웃은 테이블 레이아웃보다 나은 점이 없다. 왜냐하면 테이블 레이아웃은 그 자체로 문서와 하나가 되지만, CSS는 보통 별도의 파일에 레이아웃이 스타일만으로 들어가 있기 때문에 다른 사람이 만든 디자인을 분석하는 것은 쉽지 않다. Yahoo!은 선도적으로 XHTML과 CSS만으로 첫페이지를 꾸몄는데, 그 소스를 보고 디자인을 수정하는 것을 상상해보자.

3. XHTML과 CSS레이아웃은 경우에 따라서 양립하기가 쉽지 않다. 왜냐하면 XHTML은 모듈의 결합을 추구하는데, 여기서 모듈이란 컨텐츠 만이 아니라 디자인까지 포함된다. 10가지 모듈이 DIV태그에 쌓어여 존재할 때, 디자인에 따라서 모듈간 감싸는 DIV 태그는 틀리다. 이 말은 CSS파일의 수정 만으로는 디자인 변경이 불가능하다는 의미다. 원래의 XML은 완벽하게 디자인과 문서가 분리된다. 하지만, XHTML은 그렇지 못하다.

4. 경험상 가장 편한 제작방법은 레이아웃을 테이블로 잡고, 각각의 모듈만을 DIV로 감싸는 것이다. 특별한 디자인이 필요할 경우(메뉴나 라운드가 들어간 사각형), 일부러 CSS만으로 디자인 할 필요는 없다. 보통 이런 경우 익스플로러와 사파리, 혹은 파이어폭스 간의 호환성을 맞추기 위해서 많은 시간이 투자되어야 하기 때문이다.

5. 이종기기간 호환성은 환상이다. 마치 컴퓨터를 살 때 CPU 교환이 되어 미래에도 사용할 수 있다고 홍보하는 것과 마찬가지이다. 컴퓨터가 구형이 되면 CPU와 램 확장만으로 원하는 성능을 얻는 것은 사실상 불가능하다. 마찬가지로, 어떤 웹사이트에서 모바일용 웹사이트를 런칭한다고 하면 그것은 새로 제작되어야 한다. 디자인, 프로그램 그리고 비지니스적인 면에서 봐도 마찬가지다.

6. 이종기기간 호환성과는 별개로, 브라우져간 호환성은 매우 중요하다. 특히 돈을 받고 이미지 광고 같은 것이 있을때는 더욱 그렇다. 만약 브라우져간 호환성이 없어서 페이지가 제대로 보이지 않을 때에는 세이클럽처럼 호환성이 없는 브라우져에서 아예 서비스를 하지 말아야 한다.

7. 브라우져간 최고의 호환성은 CSS를 쓰지 않는 것이다. 브라우져 호환성은 익스플로러나 사파리, 파이어폭스 만을 말하는 것이 아니라 각 브라우져 별 버젼 호환성을 포함한다. Google의 검색 첫화면의 소스를 보도록 하자. 테이블 레이아웃이고, XHTML이 아닌 HTML로 제작되어 있다. 현재까지 하휘 호환성은 브라우져별 호환성과 마찬가지로 중요하다.

8. 흔히 말하는 접근성은 CSS로 레이아웃을 잡느냐 테이블로 잡느냐와는 상관이 없다. 보통, 키보드만으로 사용이 가능한지 혹은 800*600의 256컬러로도 제대로 보이는지 등을 말하고, 그것은 디자인 자체와 HTML 코드의 사용에 기인한다.

9. XHTML에서 말하는 표준과 파이어폭스에서 제대로 안보인다 라고 할 때의 표준은 전혀 다른 말이다. 일반적으로 표준이 아니다라고 말 할 때에는 익스플로러에만 있는 Javascript나 태그를 사용하는 것을 지칭한다.

다음 부터는 어이없는 예측

W3C가 HTML, XHTML 그리고 CSS를 포함만 많은 부분에서 권고를 발표하는 것은 제 생각에는 웹페이지 제작자가 참고해야 될 부분이 아니라 브라우져 제작자가 참고해야 할 부분입니다. 연구&개발이 아닌 다음에야 원하는 디자인을 보여주는 것이 목적이 아닐까요?

표준을 따르는 것 자체가 목적이 되면 앞뒤가 바뀌는 것이 아닐까 합니다.