서버를 Rails5로 할것이냐, Meteor(nodejs)로 할것이냐

뒤늦게 Rails 5Action Cable Demo 동영상을 보았다.
동영상은 20분이 조금 넘는 런닝타임이지만 익숙해지면 3분 내외로 개발할 수 있을것 같다.
그런데 생각보다 많이 풀어져있는(풀이되어있는) 느낌으로 각 사이드별로 코드를 다 작성해야한다.
“웹소켓을 하기 위해서, 여기는 이렇게, 거기는 그렇게, 저기는 이렇게, 마지막으로 이렇게 해주면 끝. 짜잔~!! 참 쉽지?”

3591057515594fc8

공들고 뛰어가다 그냥 점프해서 골대에 공 넣으면돼

처음 시도하는 사람들에겐 개념이 명확해서 이해하기 쉬울수있겠지만..
아직까지는 복잡하다는게 내 생각이다.

그리고 사실 Rails는 쓸대없는 코드 작성을 최소화하여 빠르고 간결하게 개발하는것이 장점이자 철학이라고 생각하는데 Action Cable은 그렇지 못한 느낌이다.
뭐 아직 베타니깐 버전업이 되면 아마 조금씩 이 철학에 맞춰서 수정되지 않을까 싶다.

내가 만약 Meteor​를 해보지 않았다면 이런 생각을 안했을수도 있겠지만
Meteor는 “그냥 했을뿐인데 웹소켓통신이 되고있네?” 랄까..

restmb_idxmake

그냥했는데 펜타킬..

Meteor랑 비교하는것 자체가 어폐가 있을지모르겠지만, 그래도 이미 맛봐서 비교를 안할수가없다.

사실 Rails를 버리고 Meteor + React​ 조합으로 서비스를 꾸려나갈 생각이었는데..
Rails 5선택지가 생겨서 고민이된다.

1-kyrdrgja-esr1w8taqong

아직 당장은 웹소켓을 쓸일이 없다보니 이 옵션은 선택에 큰 영향을 끼치진 않을것같다.
다만 Rails 5의 API mode가 어떻냐에 따라 갈라지지 않을까싶다.

API mode가 내가 원하는(상상하는)모습이라면
Rails 5 API mode + React로 구성을 해도 괜찮지 않을까?

Rails, Meteor 둘중 무엇이 더 가벼운가? 무엇이 개발하기 빠른가? 등등의 이슈로 열거해놓고 선택할 수 있겠지만..
사실 Ruby할래? Javascript할래? 의 문제이지 않을까 싶다.
무엇이 더 재밌고 즐겁게 개발을 할 수 있을것인가?
선택하기 어렵다. Ruby도 Javascript도..

Ruby는 10년이 넘는 기간동안 오랜시간을 함께한 친구같고..
Javascript는 Ruby보다 훨씬 오래전부터 알았지만 서먹한 관계였다 최근 몇년동안 급 친해진 친구랄까..

1431853362247

어떤거쓰지?

 

참고링크:
http://rubyonrails.org
http://weblog.rubyonrails.org/2015/12/18/Rails-5-0-beta1/
https://github.com/rails/rails/tree/master/actioncable
https://www.meteor.com/
https://facebook.github.io/react/

 

광고

Javascript로 링크 및 AJAX구현시 Fallback Link를 제공해야 하는 이유

f1e4ccf2bb4122e22aba7f35653d5494

Javascript로 행해지는 Action의 결과물이 서버(Server)로 요청(Request)하는 행위라면 Fallback Link를 함께 제공해주는것이 안전하다.

서버로 요청한다는것은, 단순히 UI를 위한 스크립트가 아니라는 말이다.
즉 페이지 이동 하거나, 값을 전송하기 위함인데
필자는 단순히 UI변경하는것보다, 서버로 값을 전송하는게 더 비중있는 일이라고 생각한다.
그 이유는 대다수의 경우 서버로 값을 전송하는것이 Action의 Goal인 경우가 많기 때문이다.
그러므로 난 Fallback Link를 제공해야 한다고 주장하는 것이다.

예를들어
로그인 버튼을 누를시 Javascript를 이용해 서버에 값을 전송하는 환경이라고 하자.
근데 어떠한 이유에 의해서 Javascript가 동작을 안한다면
이 유저는 로그인을 할 수 없게 되는것이다.

자, 그럼 Fallback Link는 무엇이냐?
아주 간단하다. javascript로 동작하는 a태그의 href에 유효한 url을 입력하는 것이다.
그러므로 Click 이벤트가 일어나는 모든것은 Clickable한 객체로 마크업을 하는것이 바람직하다.

Fallback Link는 언제 동작하는것이냐?
이것 또한 간단하다. Javascript가 동작하지 않는 상황을 대비하는것이다.

근데 솔직히 말하면 브라우저가 자바스크립트를 지원하지 않아서, 자바스크립트가 미구동되는 경우는 거의 없다.
하지만 자바스크립트 문법 에러가 나서 동작하지 않는 경우는 꽤 있으므로, 이에 대한 대비로 봐도 된다.
뭐 사실 갖다붙이면 여러가지 이유가 있겠지만..
결론적으로 말하면 자바스크립트 미구동에 대비하는걸로 인해 생기는 부수적인 효과들이다.

돌아와서 Fallback Link제공의 간단한 예를들면

<a onclick="like('comment', 1)" href="#">Like</a>

이렇게 된걸 아래와 같이 수정하는것이다.

<a href="/like" data-action="like" data-content-type="comment" data-content-id="1">Lik</a>

$("a[data-action='like']").click(function(e) {
    # do something
});

단순히 Fallback url을 제공했다고 끝나는게 아닌다.
해당 url이 실제로 동작을 해야 한다.

서버단에서 요청된 Header정보를 보고 Ajax인지 아닌지 판단하고,
여부에 따라서 응답을 달리 해주는 작업을 해줘야 한다.

무슨말인고하니,
보통의 경우 Ajax 응답만 작업했을것이고, 해당 코드는 아래와 같을것이다.

$("a[data-action='like'][data-content-type='comment'][data-content-id='1']").addClass("selected")

하지만, url을 타고 요청이 왔을 경우 유저는 하얀 화면 혹은 위 JS코드가 출력된(?) 화면을 보게 될 것이다.
이럴경우를 대비해야 한다는것이다.

기획단에서 어떤 페이지로 렌딩(Landing)할 것 인지, 먼저 정한 다음
해당 페이지를 렌더링(Rendering) 혹은 리다이렉트(ReDirect)해주면 된다.

Rails에서는 그냥 몇글자 추가해주면 되지만..
보편적인(?) PHP로 예를들면

if(!empty($_SERVER['HTTP_X_REQUESTED_WITH']) && strtolower($_SERVER['HTTP_X_REQUESTED_WITH']) == 'xmlhttprequest') {
    // Ajax Process
}
else {
    // Page Redirect
}

이 정도?
PHP 코드 출처: http://davidwalsh.name/detect-ajax

사실 이런 내용은
Graceful Degradation, Unobtrusive Javascript
같은 방법론들이 얘기하는것과 일맥상통하기도 한다.

Click Event Binding with Clickable Elements

너무 기초적인 내용인데, 이리 저리 사이트 둘러다니다보면 생각보다 지켜지지 않는 경우가 많아서 포스팅 하기로 했지만..사실 별 내용없다.
요점은 click 이벤트는 clickable한 요소에 등록하자.

내 눈은 Clickable 하지않거든? ㅋㅋ

먼저 아래 코드를 보자.

<img onclick="like('post', 1)" alt="좋아요" src="btn_like.png" />

위 코드는 시멘틱(Semantic)하지 않고,
clickable하지 않은 요소에 이벤트를 등록해 키보드로 이용을 할 수 없다는 또 다른 문제점이 있다.
이것은 접근성적인 측면에서 큰 문제가 된다.

너무나 당연해 얘기하는것 조차 민망하지만, click 이벤트가 일어나는것들은 Clickable한 요소를 이용해 마크업을 해야한다.
클릭커블한 요소들은

  • a
  • button
  • input type=”button”
  • input type=”submit”

정도가 있다.

그러므로 위 img태그는 아래와 같이 수정되어야 한다.

<a href="#" onclick="like('post', 1)"><img alt="좋아요" src="btn_like.png" /></a>

href에 알맞은 url까지 적어주면 금상첨화.

<a href="/like?content_type=post&content_id=1" onclick="like('post', 1)"><img alt="좋아요" src="btn_like.png" /></a>

아. 물런 url은 실제로 동작을 해야한다.

이것만으로도 충분하지만, html과 js를 분리시키는게 더 나은 방법(Unobtrusive)임으로 분리를 시켜준다.

<a href="/like?content_type=post&content_id=1" data-content-type="post" data-content-id="1" class="like-button"><img alt="좋아요" src="btn_like.png" /></a>

이런식으로 필요한 정보들은 data 속성(attribute)를 이용해서 제공을 하고

.like-button에 이벤트(event)를 등록(bind)한다.

$(".like-button").click(function(e) {
  e.preventDefault();
  var content_type = $(this).attr("data-content-type");
  var content_id = $(this).attr("data-content-id");

  // ajax ...
});

CSS for iPad Orientation (화면회전)

CSS for Retina Display 에 이어 이번엔 IPad 화면 회전에 따른 CSS 적용법에 대해 간략하게 적어보겠다.
사실 화면회전에 따라 CSS를 구별해서 적용하는 경우는 드물것이나, IPad에 맞춤 웹페이지를 제작하다보면 어느순간 필요해지는 부분이다.

1. Media Query
iPad Orientation의 Media Query는

all and (orientation:portrait)
all and (orientation:landscape)

이다.
portrait는 세로화면,
landscpae는 가로화면이다.

2. 불러오기
CSS for Retina Display와 동일하다

2-1. 별도의 CSS File을 만든경우

<link rel=”stylesheet” media=”all and (orientation:portrait)” href=”/stylesheets/portrait.css”>
<link rel=”stylesheet” media=”all and (orientation:landscape)” href=”/stylesheets/landscape.css”>

2-2. style을 구분하여 불러올 경우

<style type=”text/css” media=”all and (orientation:portrait)”>
<style type=”text/css” media=”all and (orientation:landscape)”>

2-3. 일반적인 style 안에서 불러올 경우

@media all and (orientation:portrait) {
#for portrait style codes..
}
@media all and (orientation:landscape) {
#for landscape style codes..
}

3. 예제
세로용에는 portrait, 가로용에는 landscape를 부여하고, CSS를 통해 제어해보겠다.

<style type=”text/css” media=”screen”>
@media all and (orientation:portrait) {
.portrait { display: block; }
.landscape { display: none; }
}
@media all and (orientation:landscape) {
.portrait { display: none; }
.landscape { display: block; }
}
</style>

Orientation:
<div>Portrait</div>
<div>Landscape</div>

4. 확인
4-1. Portrait(세로모드)

 

 

 

 

 

 

4-2. Landscpae(가로모드)

 

 

 

 

CSS for Retina Display (background)

IPhone4에서 웹페이지를 보다보면, 이미지가 살짝 깨져 보이는 경우가 있다.
Retina Display의 해상도 때문인데, 해결책은
2배 큰 이미지 만든 후,  Retina Display용 CSS 적용하면 된다.
1. 2배 큰 이미지 만들기
Retina Display가 기존 IPhone해상도의 2배로 커졌으니, 해당 이미지들도 2배 크게 만든 후 적용 시키면 된다.
예를들어 20×20 아이콘이었다면 40×40으로 만들면 된다.
2. 불러오기
자 그럼 Retina Display용 CSS는 어떻게 불러오느냐?

핵심은 Media Query!

Retina Display용 CSS의 Media Query를

screen and (-webkit-min-device-pixel-ratio: 2)
로 해주면 된다.

아이폰에서는 Safari로 접속을 하므로 Webkit CSS를 써도 무관하지만.. 이런식으로 특정 Browser에 Dependent된 기술은 바람직하지 않다고 생각한다. 이 문제는 할일이 없어 시간이 엄청 남아돌때 포스팅 하기로 하고..
CSS 로드 케이스별로 보면.

1. Retina Display용 CSS 파일을 만들경우
<link rel=”stylesheet” href=”retina.css” type=”text/css” media=”only screen and (-webkit-min-device-pixel-ratio: 2)” title=”title” charset=”utf-8″>

2. html안에서 Retina Display용 CSS를 추가할 경우
<style type=”text/css” media=”only screen and (-webkit-min-device-pixel-ratio: 2)“>
3. 일반 CSS안에 Retina Display용 CSS를 추가할 경우
@media screen and (-webkit-min-device-pixel-ratio:2) {
    #icon {
        ….
    }
}
이런 방식으로 추가를 하면 된다.
3. 적용 방법
마지막으로 적용방법이다.
기존의 코드는 손대지 말고, Retina Display용 CSS만 추가하면 된다.
background-image: url(“icon40x40.png”);
-webkit-background-size:20px 20px;

이런식으로 2배 커진 이미지를 배경이미지로 Overwrite하고,

배경 이미지 크기를 기존 아이콘의 사이즈로 적어주면 된다.
배경이 아닌 일반 이미지 또한 2배로 크게 만들고 강제로 기존 사이즈 적어주면 되긴 하는데..
이 경우는 접속 환경의 Retina Display인지 아닌지 구분할 수 없다는 문제점이 있다.
하지만 아래 나온 class 할당 방식으로 해결할 수 있긴 하지만 바람직한 방법은 아닌듯 하며,
번거롭지만 배경이미지로 바꾸는게 나아보인다.
배경이미지외
Retina Display에만 특별히 적용을 해야 할 경우  class를 부여해서 조절하는 방법이 있다.
.forWeb { display: block }
.onlyRetina { display: none }
@media screen and (-webkit-min-device-pixel-ratio:2) {
    .forWeb { display: none }
    .onlyRetina { display: block }
}

 

헤딩 제대로 사용하기. – 후편(완)-

전편을 보고 분명 많은 분들이

뭐야? 장난해? 내가 아는거랑 똑같은데? 뭐가 틀리다는거야?

이런 반응을 보이셨을 것이다.
이건 마치 “헤딩태그는 책과 같다고 생각하시면 되요”라고 말한 것과 똑같은듯하다

여러분의 느끼실 그 허탈함에 전편을 포스팅하고 바로 후편을 쓴다.
후편에서는 무엇이 잘못되었는지 집어볼 것이다.

헤딩태그의 잘못된 사례(헤딩태그의 오해)
1. 레이아웃팅 제목으로 사용
어떤 관공서의 사이트에서 CSS를 제거한 모습과 HTML 코드이다. 지금 헤딩태그를 레이아웃팅한 영역의 제목으로 사용하고 있다.


“상단 메뉴”, “하단 정보”, “하단 링크”가 유의미한 데이터일까? 절대 아니다.
헤딩태그를 의미없는 레이아웃 영역의 제목으로 사용하고 있다. 실제로 많은 관공서의 사이트의 헤딩이 이런식으로 구성되어 있다. 이러한 방식은 올바르지 않은 사용법이다.

2. 제목이라고 하긴 애매모호한 헤딩


이건 제목이라고 하긴 애매모호한 헤딩들이다. 그 이유는 레이아웃 영역으로써의 의미도 포함이 되어 있기 때문이다. 그러므로 이러한 사용법 또한 올바르지 않은 사용법이다.

3. 메인메뉴 혹은 서브메뉴를 헤딩으로
(아래의 스샷은 재현을 위해 제가 급조한 것입니다.)

위 1번과 2번은 쉽게 이해를 했는데, 3번에 와서는 고개를 갸웃하는 분이 계실 듯하다.
유의미한 데이터를 헤딩태그로 사용했는데 왜 문제가 될까?
그 이유는 메인메뉴(혹은 서브메뉴. 이하 메인메뉴로 통일)의 링크들은 헤딩이 아니기 때문이다.
다시말해 메인메뉴는 현재 보고 있는 콘텐츠의 제목이 아닌 링크들의 집합이다.
역시 어렵다. 쉽게말해 메인메뉴는 헤딩이 아니라 목차인것이다.
그러므로 헤딩태그를 사용하지 말고 그냥 a태그로 마크업을 해야 한다.

4. 레벨링
1) 누락
##시 사이트에서, 자유게시판까지의 메뉴 구조가
##시 -> 시만참여 -> 자유게시판

라고 하자. 그런데 디자인된 페이지에는 “시민참여”가 없다.
그래서 아래와 같이 헤딩을 부여했다.

<h1>##시</h1>
<h3>자유게시판</h3>

위 헤딩의 문제점은 h2가 없다는 것이다. 헤딩은 순차적으로 내려가야한다.

<h1>##시</h1>
<h2 class=”hidden”>시민참여</h2>
<h3>자유게시판</h3>

이렇게 헤딩을 부여하고 h2를 화면에 출력안되게 하는 방법으로 해결을 하면 된다.

2) 부여
또 다른 방법으로는

<h1>##시</h1>
<h2>자유게시판</h2>

이런 식으로 자유게시판을 h2로 마크업하는 것이다.

이쯤에서 다들

“자유게시판은 3depth에 있는 제목인데, h2로 해도 괜찮은거냐?”

라는 의문을 가지실 텐데, 상관없다.
작업하는 페이지 내에서의 헤딩만 부여하면 되는 것이다.
그렇다면

<h1>자유게시판</h1>

이렇게 자유게시판을 h1으로 마크업하는 것은 어떨까?
아마 여러분들은 혼란에 빠지실 것이고, 아래 세가지 의견들일 것이다.

  1. h1에는 사이트 제목이 들어가야 하는데..? (페이지당 h1은 한번만 와야 한다)
  2. h1만 넣으면 이 페이지가 어느 사이트(혹은 어느 위치(뎁스))에 있는지 모를텐데..?
  3. 페이지에 헤딩태그가 하나만(그것도 h1) 있어도 되는건가?

먼저, 1번 h1에는 사이트 제목이 들어가야 하는데..? (페이지당 h1은 한번만 와야 한다)
이것은 논란의 여지가 많은것으로, 전편에 해석에 따라 견해의 차이가 있다고 한 그 부분에 해당되는 내용이다.
실제로 몇해전 웹 접근성/표준쪽의 유명하신 두분이 이것으로 술자리에서 다투셨던 적이 있다.
그 분들의 의견은

    • 사이트명은 책제목과 같고, GNB의 시작점이기 때문에 h1으로 해야하고, 한번만 와야 한다.
    • 아니다

개인적인 의견은 제작자 맘이라고 생각한다. 즉 “아니다”쪽에 가깝다.
그 이유는 헤딩의 목적은 콘텐츠의 제목을 제공하는 것에 있지, GNB를 나타내기 위해 있는것이 아니기 때문이다.
그렇다면 GNB로써 헤딩을 사용하는 것이 잘못된것이냐? 그렇지도 않다. 페이지의 GNB를 콘텐츠의 제목이라고 생각할 수도 있기 때문이다.
전편에서 예를 들었던 “2분기 실적”은 “2009년 A 사업의 2분기 실적”이기 때문에,
“2009 실적 보고서”, “A 사업 실적”도 헤딩이 될 수 있다.
그러므로 제작자 맘이라는 것이다

2번, h1만 넣으면 이 페이지가 어느 사이트(혹은 어느 위치(뎁스))에 있는지 모를텐데..?
이것 역시 헤딩을 GNB로써만 이해했기 때문에 생기는 오해이다.
title을 제대로 제공을 했고 정보구조가 제대로 구성되어 있다면 딱히 문제가 되지 않는다는것이 개인적인 견해이다.

3번. 페이지에 헤딩태그가 하나만(그것도 h1) 있어도 되는건가?
문제될 것 없다.

3) 단계
헤딩의 숫자가 의미하는 바는 단계(level)이라고 생각하면 된다.
대메뉴는 제일 큰 헤딩이므로 h1
중메뉴는 두번째로 큰 헤딩이므로 h2
소메뉴는 두번째로 큰 헤딩이므로 h3
이런식으로 레벨링을 하면 된다.
그러므로 대메뉴를 h2, 소메뉴를 h1 이런식으로 정보구조에 위배되게 마크업을 하면 안된다.

5. 중복된 내용
(아래의 스샷은 재현을 위해 제가 급조한 것입니다.)

간혹 보면 사이트의 제목이 헤딩에 항상 따라다니는 경우가 있다.
사이트 제작자가 얼마나 사이트를 사랑하고, 자랑하고 싶어하는지 그 마음이 전해진다.
하지만 이것은 좋은 방법이 아니다.
헤딩의 레벨이 낮아지면, 상단의 레벨에 나오는 내용은 생략해도 된다.

<h1>##시</h1>
<h2>홍보관</h2>

이렇게 마크업이 되었으면

##시의 홍보관

이라고 받아들이면 된다.
즉 레벨이 낮아지면 상위 헤딩의 내용이 접두어로 붙은 것으로 여기면 된다.


헤딩이란

하.. 그럼 도대체 어떻게 헤딩을 하란 말이냐?!

전편에서 했던것 그대로 하면 된다.
너무나도 쉬웠던 그것이 바로 정답이다.

헤딩태그가 너무 간략하다보니 오해가 많이 생기는 것 같다.
그 오해의 근본은 무엇이 헤딩인가? 즉 헤딩의 정의에 있는것 같다.
헤딩태그는 헤딩은 페이지의 제목이다.

절대 아니다. 헤딩태그는 페이지의 제목이 아니다.
헤딩은 페이지의 제목이 아니라 콘텐츠의 제목이다.
더 정확하게 이야기를 하면 섹셔닝된 콘텐츠의 제목이다.

전편에 나왔던 “2009 실적 보고서”를 가지고 예를 들어보자.
현재 내가 보고 있는 페이지는 A사업 실적의 2분기 실적을 보고있다면

대제목: 2009 실적 보고서
중제목: A 사업 실적
소제목: 2분기 실적
이게 바로 전편에서 말한 헤딩이다. 이것을 코드화하면
<h1>2009 실적 보고서</h1>
<h2>A 사업 실적</h2>
<h3>2분기 실적</h3>
이렇게 된다.
이게 아닌 다른것은 헤딩이 되면 안된다.

자, 그럼 상황을 바꿔보자
현재 내가 보고 있는 페이지에는 A사업의 모든 정보가 다 나온다고 하자.
그렇다면 어떻게 헤딩을 구조해야 할까?
대제목: 2009 실적 보고서
중제목: A 사업 실적
소제목: 1분기 실적
소제목: 2분기 실적
소제목: 3분기 실적
소제목: 4분기 실적
소제목: 전년과 비교
소제목: 총평
이렇게 될 것이고, 코드화를 하면
<h1>2009 실적 보고서</h1>
<h2>A 사업 실적</h2>
<h3>1분기 실적</h3>
~~
<h3>2분기 실적</h3>
~~
<h3>3분기 실적</h3>
~~
<h3>4분기 실적</h3>
~~
<h3>전년과 비교</h3>
~~
<h3>총평</h3>
~~
이렇게 코드화가 된다.
“총평”이 “2009 실적 보고서의 총평”인지, “A 사업 실적의 총평”인지 걱정하지 않아도 된다.
h3의 상위레벨의 헤딩태그 h2에 이미 “A 사업 실적”이라는 내용이 있으므로, “A 사업 실적의 총평”이 되는 것이다.

정리를 하면

  1. 내가 보고 있는 페이지의
  2. 콘텐츠를 섹셔닝(구분)하고
  3. 각 섹션마다 콘텐츠에 알맞는 헤딩을

부여하면 되는 것이다.

결론
여기에 나온 잘못된 사례말고도 찾아보면 더 많은 방법으로 잘못 사용되고 있을 것이다.
중요한것은, 디자인된 시안을 받고 코딩을 할때 레이아웃팅만 해야 하는 것이 아니다.
콘텐츠도 레이아웃팅을 해야한다. 그리고 그에 적절한 헤딩태그도 제공을 해야한다.

덧.
콘텐츠를 레이아웃팅 하는 것을 HTML코더만의 몫이라고 하기는 힘들다.
콘텐츠를 만든 사람(대부분의 경우 기획자)이 가장 큰 책임을 지고 있는 것이다.
설계가 이상하게 되어있는데 어떻게 올바르게 시공이 되겠는가.

하나의 페이지에 여러개의 목적을 가진 콘텐츠들이 뒤죽박죽 썩여있다면, 그것은 기획을 잘못한 것이고 UX 또한 고려하지 않은 것이다.

헤딩 제대로 사용하기(시멘틱 마크업하기). -전편-

HTML5가 회자되고 있는 이마당에, HTML의 기초중에 기초인 헤딩태그에 대해서 포스팅한다는 현실이 부끄럽기도 하고 안타깝기도 하지만.. 이렇게 포스팅을 해야 많은 분들이 올바른 헤딩태그를 사용하시리라는 희망을 품으며 몇자 적어봅니다.

전편과 후편으로 나뉘며
전편에는 헤딩태그를 사용했을 때의 장점(전반적으로 시멘틱 마크업에 대한 이야기), 해딩태그의 이해
후편에는 잘못된 헤딩태그 사용예, 헤딩태그 결론에 대해 포스팅됩니다.

2009년 하반기동안 Javascript강의를 많이 다녔는데, 이때 받았던 질문중 기억에 남는 질문은

“헤딩태그를 어떻게 사용해야 할지 모르겠어요”

라는 질문이였다. (Javascript강의인데 HTML을 질문하는 용자의 용기와 호기심에 박수를 보냅니다.;) )
알고보면 매우 간단한 것인데 이 질문을 여러번 받았었다.
아마도 원문에 헤딩태그에 대한 자세한 설명과 예제가 부족해서 그런게 아닌가 하는 생각을 해본다.
접근성을 준수했다는 사이트들도 상당수가 잘못된 헤딩태그를 사용하는 것을 목격하였다.

이제 헤딩태그에 대해 파해쳐보자. 팍팍

팍팍 파해쳐보기 전에..
지금 포스팅된(그리고 포스팅될) 이 글은 견해의 차이가 있을 수 있다.
그 이유는 원문에는 간략한 설명만 있을 뿐 자세한 설명과 예제가 적다.
이로인해 원문을 이해하는데 견해의 차이가 생길 수 있기 때문이다.
이건 마치 성경을 놓고서 사람마다(혹은 종파마다) 해석하는 바가 틀린 것과 같은 이치이다.

자. 자기방어는 이쯤으로 마무리하고, 이제 제대로 한번 파해쳐보자 팍팍.

헤딩을 올바르게 사용했을 때의 장점(시멘틱마크업의 장점)
헤딩을 올바르게 사용하면 SEO가 올라간다.
물런 국내 대형 포털의 검색에는 안걸릴 확률이 아주 높다. 실제로 검색이 되었다 하더라도 검색결과에 나올 확률은 알 수 없다. 그 이유는 다들 알겠지만 검색 방식의 차이와 광고 및 정책 때문이다.

“그렇다면 도대체 어떻게 SEO가 올라간다는 말이냐?”

라는 의문을 품은 분도 계실 것이다.
우리가 종종 착각을 하는것이..  포털의 검색만 “검색”이라고 착각을 하는데, 사실은 그렇지 않다.
크롤러(혹은 봇. 이하 크롤러로 통일)가 돌아다니면서 수집하는 모든것이 검색이라고 생각해도 무관하다.
크롤러가 정보를 수집해갔다는 행위의 시초가, “검색”이라는 이벤트가 있었기 때문에 정보를 수집해간 것이라 해석할 수 있기 때문이다.
크롤러가 무작위로 정보를 수집해 갔다 하더라도, 수집해간 정보가 언젠가는 노출이 될 확률이 높으므로 이것 또한 긍정적으로 생각할 수 있다.

엄청난 비용을 지불하여 SEO를 올릴 수도 있지만, 간단하게 HTML 코드를 수정함으로써 SEO를 올릴 수 있다는 것이다.
HTML을 수정했다고 엄청나게 SEO가 향상된다고 말하기는 어렵다. 위에 언급했듯이 국내 포털들은 검색에 안걸릴 확률이 높으므로 그렇다. 안하는 것보다 나은 정도의 수준이라고 생각하는 것이 좋을 것이다.
하지만 다행스럽게도 구글에서는 확률이 올라가니 아무 소득이 없는것은 아니다.

사람이 보는 것이 아닌 기계가 알아볼 수 있는 헤딩
그럼 크롤러가 정보를 수집해가는 원리에 대해서 알아보자.
일반적인 크롤러의 경우 HTML을 읽은 후 거기서 키워드를 인덱싱한후 저장하는 방식이다.
여기서 어려운것은 HTML을 분석하여 이 HTML이 어떤 정보를 담고 있는지, 혹은 해당 키워드가 있는지 인덱싱하는 기술이다.
수많은 text중에 어떤 것이 의미가 있는 정보이고 광고이고 쓰레기인지 구분해내야 하기 때문이다.
이 말인즉슨 유의미한 데이터(정보)가 무분별하게 쓰레기와 썩여있다면, 크롤러가 유의미한 데이터를 찾지못하고 넘어갈 수도 있다는 것이다.

시멘틱 마크업
좋은 크롤러라면 모래 속의 진주를 발견해 갈 수 있지만, 이런 기대는 감나무 밑에서 감 떨어지길 기다리는것과 같다.
우리가 유의미한 데이터라고 표시를 해주면 어떻게 될까? 당연히 크롤로가 한결 수월하게 정보들을 수집해 갈 것이다.
이렇게 표시를 할 수 있는 태그중 하나가 바로 헤딩태그이다. 우리가 헤딩태그를 올바로 사용하면 크롤러는 별 어려움없이 유의미한 데이터를 수집해 갈 수 있다.
그 이유는 기본적으로 크롤러들은 head안에 오는 태그들(title 등등)이나 헤딩태그, 강조태그들을 주로 수집해가기 때문이다. (크롤러마다 차이가 있음)
크롤러가 이해할 수 있다면 크롤러가 아닌 다른 녀석도 알아볼 확률이 높아지게 된다.
여기서 다른 녀석은 우리가 흔히 사용하는 브라우저(IE, FF, Opera, Safari, Chrome)가 아닌 다른 브라우저 및 디바이스를 의미한다.
PDA, 모바일 브라우저 뿐만 아니라 사내 터미널 등등 호환성이 넓어지는 것이다. 사실 이것은 웹표준을 준수했을때 생기는 이점이며, 시멘틱 마크업을 했을때 시너지가 생겨 그 효과가 극대화 된다.

기계(HTML을 수집하거나 분석하는 모든것들)가 이해를 해야지만이 SEO도 올라가고, 기계가 이해를 할 수 있으니 다른 디바이스(장치)와도 호환이 된다.
결국은 기계가 이해할 수 있는 마크업을 해야한다는 것이다.
이것이 바로 내가 생각하는 시멘틱마크업이다.

헤딩태그의 이해
많은 분들이 헤딩태그를 설명할 때 책과 비유를 한다. 나 또한 책에 비유를 많이 했었는데
이렇게만 설명하면 이해할거라고 생각했었는데 그것은 내 착각이었다.
많은 분들에게 “책”예를 들면 다들 그때는 고개를 끄덕거리시지만, 막상 사용할려고 했을때 감을 못잡으시는 경우가 허다했다.

하지만 이번에는 책이 아닌 다른것으로 예를 들어 설명을 해보겠다.
바로 문서로 예를 들겠다.
여기저기서 실망감을 표출하며 “그게 그거다”, “낚시하냐”라는 원성이 들리지만..
책보다는 문서가 더욱 적절한 예제여서 헤딩태그에 대한 오해를 줄일 수 있을 듯 하다.
수많은 문서 중 보고서를 예를 들겠다.

2009 실적 보고서라고 하자. 그리고 이 실적보고서의 내용을 상상해보자.
각 사업별 실적이 나올 것이고, 전년도 실적과 비교도 할 것이고, 분기별 비교도 있을 것이다.
이러한 것을 목차로 생각해보면

  • 2009 실적 보고서
    • 전체 사업 실적 요약
    • A 사업 실적
      • 1분기 실적
      • 2분기 실적
      • 3분기 실적
      • 4분기 실적
      • 전년과 비교
      • 총평
    • B 사업 실적
      • 1분기 실적
      • 2분기 실적
      • 3분기 실적
      • 4분기 실적
      • 전년과 비교
      • 총평
    • 총평

뭐 대충 이런식으로 있게 될 것이다.
그럼 여기서 A 사업 실적의 2분기 실적을 보고 있다고 가정하자.
그렇다면 이 페이지의 헤딩은 어떻게 되야할까?
바로 그렇다. 여러분이 생각한 것이 바로 정답이다.
생각대로 하면 되고~

대제목: 2009 실적 보고서
중제목: A 사업 실적
소제목: 2분기 실적

참 쉽죠잉~?

다음편에는 헤딩태그의 오해와 결론에 대해 적어보도록 하겠습니다.
ps. 왠지 다른 블로거가 헤딩태그 관련해서 글을 썻을거 같은 이 느낌.. ㅠ,.ㅠ