바다(bada)는 2010년 삼성전자가 "Smartphone for Everyone"이라는 모토 아래 발표한 스마트폰 플랫폼이다. 일부에서는 삼성전자의 "바다(bada)"와 구글의 "안드로이드(Andriod)", 애플의 "iOS"를 스마트폰 OS의 경쟁자로 묘사하고 있지만, 삼성전자가 바다(bada)를 발표하면서 내건 모토처럼 일단은 기존의 사용자를 스마트폰으로 끌어들이는 역할을 할 것으로 기대 된다.

바다(bada)에 대한 설명을 보다보면 "cost-effective"라는 단어가 자주 등장하는데, 이 역시 가격 경쟁력으로 기존의 스마트폰 플랫폼들과 경쟁을 하겠다는 의미보다는, 기존의 중고가 하이엔드 피처폰이 차지하던 시장을 대상으로, 가격적인 거부감을 최소화하면서 사용자들을 스마트폰 영역으로 끌어들이겠다는 의미가 강하다고 할 수 있다.
삼성 바다 홈페이지(http://www.bada.com)에서도 아래와 같은 도표로 확인할 수 있다.



현존하는 모바일 플랫폼 중 가장 늦게 출발하고, 또 기존의 플랫폼과는 다른 시장을 대상으로 하고 있지만, 삼성 바다(bada)를 무시할 수 없는 이유 중에 하나가 바로 위와 같은 사실에서 기인한다.

삼성 바다 홈페이지에 따르면 삼성전자는 2009년 약 2.2억대의 휴대폰을 판매했고, 이 중 터치폰이 4천만대 정도를 차지하고 있는데, 앞으로는 이 사용자들이 모두 바다(bada) 플랫폼을 사용한 단말기의 잠재적인 수요자 역할을 하게 될 가능성이 높으므로 바다(bada) 어플리케이션 개발자 등에게도 충분히 매력적인 비지니스 모델을 제시할 수 있다. 

바다(Bada)는 스마트폰을 위해 새로 만들어진 플랫폼이 아니라, 기존의 삼성 피처폰에 쓰이던 RTOS를 개선해서 만들어진 플랫폼으로, 기존의 RTOS에 스마트폰의 기본 기능인 프로그램 다운로드와 설치를 가능하게 하고 멀티터치 기능 추가, 3D 그래픽 지원, UI 개선 등을 통해 만들어진 플랫폼이다. 이를 바탕으로 Flash 지원, 각종 센서 지원, 통합 SNS 등을 통해 사용자 편의성을 기본적으로 최대한 제공하려 했다.


스마트폰 플랫폼 열풍이 불면서 등장한 또 하나의 화두로 'Eco system'을 들 수 있다.
'생태계'라는 우리말로 번역되는 'Eco system'은 그 시스템을 구성하는 구성 요소들이 얼마나 많은 상호 작용을 하고, 그 상호 작용을 통해 얼마나 많은 부가 가치를 생산해 내는지를 통해 그 시스템의 우월성을 평가 받는다.

삼성이 바다(bada) 구현하고자 하는 Eco system은 사용자와 개발자 사이를 'Samsung Apps', 'bada platform', 'Developer support' 등으로 연결하는 모양을 갖추고 있다.


이 중 가장 관심을 받고, 또 가장 중요한 부분이 'Samsung Apps'라 이름이 붙여진 어플리케이션 스토어이다.
스마트폰 또는 스마트폰 플랫폼의 경쟁력을 평가하는 아주 중요한 요소 중의 하나로 어플리케이션의 양과 질적인 면을 들 수 있는데, 삼성의 바다(bada)는 후속 주자이니 만큼 아직은 이 분에서 열세를 면치 못하고 있다. 하지만 수개월이 걸리기도 하는 타 플랫폼의 어플리케이션 등록 기간을 삼성 바다(bada) 어플리케이션 스토어는 7일 이내로 규정하고, 개발에 Tool부터 관련 정보를 쉽게 얻을 수 있는 통합 사이트를 운영하는 한편, 어플리케이션 개발 대회 Samsung bada Developer Challenge(http://developer.bada.com/challenge/index.do) 개최, 개발자들에게 바다(bada) 플랫폼을 알리기 위한Samsung bada Developer Day(http://developer.bada.com/apis/event/developerDayInfo.do?menu=MC01160100) 실시, 개발자들의 실제적인 문제 해결에 도움을 주기 위한 '삼성 바다 One Day Clinic' 실시, 오프라인 개발 지원 센터 OCEAN(http://developer.bada.com/developercenter/ocean/index.do) 운영 등 개발을 위한 지원을 아끼지 않고 있다.

바다(bada) 어플리케이션 개발 환경을 간단히 살펴보면, 이에서도 개발자의 편의를 위한 많은 고려가 있었음을 알 수 있다. 공식적으로 릴리즈 되는 SDK에는 통합 개발 환경(IDE)가 포함되어 있어 별도의 IDE 설치 과정이 필요 없으며, IDE를 포함한 SDK, 분리된 언어팩(LP) 지원, SDK 및 LP 통합 지원 등 작은 부분에서도 초기 개발자의 편의성에 신경을 썼다.


바다(bada) 플랫폼을 기존의 RTOS에서 발전해 나온 플랫폼이니만큼 초기 플랫폼임에도 불구하고 어느 정도의 안정성을 갖추고 있고, 잠재적 수요층의 규모가 엄청나다는 장점을 가지고 있는 반면, 어플리케이션의 수가 부족하고 아직은 지원하는 단말이 많지 않아 개발자의 입장에서는 규모의 경제를 실현하기에는 시기상조라는 단점 또한 가지고 있다.

바다(bada) 플랫폼이 기존의 모바일 플랫폼 양대 산맥인 구글 안드로이드와 애플 iOS와 경쟁하기는 버거워보이나, 처음 세웠던 전략이 먹힌다면 적어도 수적인 면에서는 모바일 플랫폼의 한 축을 담당할 수 있을 것으로 예상되고, 향후에는 이 양적인 세력을 바탕으로 질적인 성장 또한 이뤄낼 수 있을지도 모른다. 

댓글을 달아 주세요

IT/Web Dev | Posted by 철규님(최규철) 2011. 2. 21. 23:27

[펌/번역] Intelligent Site Structure for better SEO


특정 사이트를 검색 결과의 상단부에 나타내기 위한 노력은 예전부터 있어왔다. 이를 SEO(Search Engine Optimization, 검색 엔진 최적화)라고 하는데, 더 나은 SEO를 위한 사이트 구조에 대한 글이 있어서 참고하려고 한다.


[ 원문보기 : Intelligent Site Structure for better SEO (http://yoast.com/site-structure-seo/)  ]



Intelligent Site Structure for better SEO
더 나은 검색 엔진 최적화(SEO)를 위한 지능적인 사이트 구조
by Joost de Valk on 9 February, 2011 at 16:00




Search engines are still one of the most important traffic drivers to sites these days, which is why Search Engine Optimization (SEO) is incredibly important.
검색 엔진은 최근에도 여전히 가장 중요한 트레픽 유발 요소 중의 하나이며, 이점이 왜 검색 엔진이 그토록 중요한지를 말해주고 있다.
While SEO is often thought to be just a set of some technical tricks - and as a professional SEO, I confess to spending a lot of time with clients fixing technical issues - a site's structure, is just as important.
SEO는 종종 단순한 기술적 트릭의 모음으로 생각되지만, 전문적인 SEO로는 사이트 구조 또한 중요하다. (고백하건데 나는 고객과 많은 시간을 기술적 이슈를 해결하는데 소모한다.)
Your site's structure determines whether a search engine understands what the topic of your site is and how easily it will find and index content relevant to your site's purpose and intent.
당신의 사이트의 구조는 검색 엔진이 사이트의 주제가 무엇인지를 이해하고 얼마나 쉽게 당신의 사이트의 목적과 주제에 대한 정보를 찾고 정리할 수 있는지를 결정한다.


By creating a good structure, you can use the content you've written that has attracted links from others, and use your site's structure to spread some of that "linkjuice" to the other pages on your site.
좋은 구조를 만들어냄으로써, 당신은 다른 곳으로부터의 관심 링크를 가진 당신이 작성한 컨텐츠를 사용할 수 있고, 당신의 사이트 구조가 그러한 링크 가치를 당신 사이트의 다른 곳으로 확산시키게 할 수 있다.
On a commercial site, that means that you can use the quality content you've written to boost the search engine rankings of your sales pages too.
상업적 사이트에서는 당신이 작성한 고품질의 컨텐츠를 당신의 판매 페이지의 검색 엔진 순위를 높이는데 사용할 수 있다는 것을 의미한다.
Did I get your attention now? Ok, now we've covered what and why, let's get on to how.
어느 정도 관심이 생기는가? 그럼 '무엇'과 '왜'에 대해서 알아봤으니, '어떻게'에 대해서 이야기 해보자.



Developing a good site structure
좋은 사이트 구조 개발하기

When developing a new site, or restructuring an existing one, it helps to draw out your site's structure in something like Visio, or even putting it in Excel.
새로운 사이트를 개발하거나 기존의 사이트를 구조변경할 경우에는 Visio와 같은 툴을 이용하거나 Excel을 이용해서라도 사이트의 구조를 그려보는 것이 도움이 된다.
What you'll want to do is put all the pages and sections in there as a tree, something like that shown in Figure 1 (based on my own old site structure):
당신이 해야할 일은 Figure 1에서 보여지는 바와 같이 모든 페이지와 섹션을 트리 형태로 구성하는 것이다.


Now as you can see this structure is unbalanced, as the Code section constitutes more than half of the entire site.
당신도 볼 수 있듯이, 코드 섹션이 전체 사이트의 반정도로 구정되어 있어서, 이 구조는 비균형적이다.
You should make sure your site structure looks like a reasonably balanced pyramid.
당신은 당신의 사이트 구조가 적절하게 균형잡힌 피라미드처럼 보이도록 해야한다.
I'd advise you to have something between 2 and 7 main sections, depending on how content heavy your site is, and no section should be more than twice as large as any other section.
나는 당신에게 당신의 사이트의 컨텐츠 비중이 얼마나 큰지에 따라서 2~7개의 메인 섹션을 가지라고, 또한 어떠한 섹션도 다른 섹션보다 두 배 이상의 크기를 가져서는 안된다고 충고하고 싶다.


As well as the code section being way too big, there's another couple of points to consider about Figure 1.
Figure 1과 관련해서는 코드 섹션이 너무 크다는 점 뿐만 아니라 다른 몇 가지 고려할 사항도 있다.
First, there are three pages that are basically about me: "About Me", "Projects" and "Websites".
첫째, 기본적으로 나와 관련된 세개의 페이지, "About Me", "Project", "Websites"가 존재 한다.
In addition, upon checking out my site statistics I found that the WordPress pages were responsible for about 30% of my site traffic, yet they were down on the third and fourth level.
게다가 내 사이트의 통계를 확인해보니 'WordPress' 페이지가 내 사이트 트래픽의 30% 정도를 차지하고 있었는데, 이 페이지들은 3단계나 4단계 레벨까지 내려가 있었다.


The benefit of using a tool like Visio or OmniGraffle, as I did, is that it's quite easy to rearrange stuff, and it's easy to get a good "feel" for whether the new structure is going to work.
내가 그랬듯이 Visio나 OmniGraffle 같은 툴을 사용하면, 이런 것들을 정리하기가 꽤나 쉽고, 새로운 구조가 제대로 동작할지에 대한 느낌을 받기가 쉽다는 장점이 있다.
 I've often used a desk or a wall and a lot of post-it notes for this purpose too, and that has also worked fine for me.
나는 이런 목적으로 종종 책상이나 벽에 많은 포스트-잇을 이용하기도 했었는데, 이것 또한 좋은 방법이었다.


So I started to rearrange the sections and came up with the section structure seen in Figure 2.
그래서 나는 섹션들을 재정렬하기 시작했고, Figure2와 같은 섹션 구조 결과물을 얻었다.


As you can see I decided to move some pages "up" the tree, and I removed some pages.
보는 것과 같이 나는 일부 페이지를 트리의 상위로 옮기기로 하고, 일부 페이지는 삭제했다.
When you're rethinking your site structure you'll often find that some pages are not really beneficial to your users.
당신의 사이트 구조를 재고해보면, 일부 페이지는 사용자들에게 실제로 전혀 유익하지 않다는 것을 알게 될 것이다.
Deleting them is the best thing you can do if that's the case.
이러한 경우에는 그것들을 삭제하는 것이 최선의 방법이다.


Another choice I made was to move the blog to the homepage.

내가 선택한 또 다른 것은 블로그를 홈페이지로 옮기는 것이었다.
My homepage was utter nonsense, and basically yet another "About Me" page.
내 홈페이지는 완전히 넌센스였고, 기본적으로 또 다른 "About Me" 페이지였다.
And though I like myself, that's not what I was hoping people came to my site for.
비롯 내가 내 자신을 좋아하지만, 그것이 내가 사람들이 내 사이트를 방문하는 목적이길 바랬던 것은 아니다.
My blog is the basis of my site, so I decided to make it the cornerstone of this structure too.
내 블로그는 내 사이트의 기반이어서, 나는 이것을 이 구조의 초석으로 만들기로 했다.



Naming your sections
섹션 이름 붙이기

Once you're satisfied with your site structure, have a look at the names you've come up with for your sections.
일단 사이트 구조에 만족하게 되면, 섹션에 붙인 이름을 살펴보라.
If you have enough content about a subject for it to be able to have its own section, you can bet people are searching for it as well.
만약에 한 주제에 대해서 하나의 섹션이 될만한 충분한 컨텐츠를 가지고 있다면, 사람들 또한 그것을 찾는다고 할 수 있다.
That's why it's very wise to make sure your section names use the keywords people are searching for!
이것이 바로 사람들이 검색하는 키워드를 이용해서 섹션의 이름을 짓는 것이 얼마나 좋은 방법인지를 알려주는 점이다.
 

For example, if you're like me and you've written WordPress plugins and created a section for them, you should not call that section "WordPress".
예를 들어, 만약에 당신이 나와 같이 WordPress plugin에 대해서 글을 쓰고 이를 위한 섹션을 만들었다면, 그 섹션을 "WordPress"라고 하면 안된다.
What would you search for? "WordPress plugins", right?
당신이라면 뭐라고 검색하겠는가? "WordPress plugins" 아닌가?
So name it that (which doesn't mean you can't call it WordPress in your menu structure if that works better, just make sure the page title and breadcrumb links are "WordPress plugins").
그럼 그렇게 이름을 지어야 한다.(만약 그게 더 낫다면  메뉴 구조에서 WordPress라고 부르면 안되는 것은 아니다. 단지 페이지 제목과 네비게이션 링크의 이름이 "WordPress plugins" 이게만 하면 된다.)
You can do quite a bit of research on which keywords people search for.
상신은 어떤 키워드를 사람들이 검색하는지 약간의 조사를 할 수 있다.
Some freely available tools are:
무료로 사용 가능한 툴은 다음과 같다.

Pick the right names for your sections and subsections, and you're halfway there.
당신의 섹션과 부섹션에 맞는 이름을 고르면, 절반은 온 것이다.
Now use the same techniques to pick the titles for your pages, and make sure to keep them short and clean.
이제는 페이지의 타이틀을 고르는데 동일한 방법을 사용하라. 그리고 그것들은 간단명료해야 한다.
My sections now have names as shown in Figure 3.
이제 나의 섹션들은 Figure 3과 같이 되었다.


Now we've covered the two most important parts of defining your site structure, we'll turn our attention to some other important points to consider.
사이트 구조를 정의하는데 있어서의 가장 중요한 두 가지를 알아보았다. 이제 관심사를 또 다른 중요한 고려사항들로 옮겨보자.



Other Things to keep in mind
고려해야할 또 다른 사항들



There are another couple of things to keep in mind when working out the structure of your site.
당신 사이트의 구조에 대한 작업을 할때 기억해야할 몇 가지 사항이 더 있다.


Forums, and other user-controlled content:
포럼이나 다른 사용자 제어 컨텐츠:

If one part of your site is producing way more content then another part, and the quality of that highly productive part is poorer, you may not wish to mix the two.
만약 한 파트가 다른 파트들보다 더 많은 컨텐츠를 만들어 낸다면, 그리고 고생산적인 부분의 퀄리티가 더 낮다면, 두 개를 합치고 싶지느 않을 것이다.
For instance, let's say your front page is like A List Apart, updating every few weeks with very high quality articles gathering loads of links.
예를 들어서 당신의 전면 페이지는 'A List Apart;와 같이 링크 로드를 모으는 고품질의 기사를 몇주마다 업데이트 한다고 하자.
Another section of your site is your forums section, which produces loads of new threads every day, of questionable quality.
사이트의 다른 섹션은 포럼 섹션인데, 이것은 미심쩍은 질을 가지고 매일 새로운 몇 개의 쓰레드를 만들어낸다.

Your forum is probably going to deteriorate the rankings for your front page, because you're constantly "flowing" ranking strength from your high quality front page into your forums.
포럼들은 아마도 당신의 메인 페이지의 랭킹을 낮출 것이다. 왜냐하면 당신이 고품질의 메인페이지부터 포럼에 이르기까지 계속해서 랭킹 강도를 낮추고 있기 때문이다.(?)
So the best thing you can do with them is move them to a subdomain of your site.
당신이 할 수 있는 최선의 방법은 당신 사이트의 서브도메인 영역으로 그것들을 옮기는 것이다.

This is less of a problem when you have a blog on your site, which you control.
이것은 당신이 컨트롤하는 사이트에 블로그가 있을 때는 덜 심각한 문제점이다.
The quality of that will be less questionable, and you may want those blogposts to rank well.
그것의 질 또한 덜 의심스럽고, 당신은 그 블로그의 포스트들도 순위가 좋게 하고 싶을지도 모른다.



Redundant categories and tags:
불필요한 카테고리와 태그들:

Sooner or later you're going to fall into this trap - I know I have - of having multiple categories on your site/blog, and constantly assigning the same two categories to certain posts.
조만간 당신은 사이트나 블로그에 여러개의 카케고리가 있고 특정 포스트에 동일한 두 개의 카테고리를 계속해서 지정해야되는 함정에 빠져들 것이다. - 내가 해봤으니 안다 -
Let's say you have the "browsers" and "Opera" categories, and Opera is the only browser you write about.
당신 사이트에 "browser"와 "Opera" 카테고리가 있다고 하자. 그리고 브라우저 중 오페라에 대해서만 당신은 글을 쓴다.
Now when you look at the category overview page for the "browsers" category, you will be seeing the exact same content as when you look at the "Opera" category page - the two tags are basically redundant.
이제 당신이 "browser"의 카테고리 오버뷰를 보면, "Opera" 카테고리 페이지를 볼 때와 정확히 동일한 컨텐츠를 보게될 것이다. 이 두 태그는 기본적으로 불필요하다.

When you're using tags, this happens even more.
태그를 이용할 때는 이러한 문제가 더 자주 발생한다.
You're probably wondering "what's wrong with that?"
"뭐가 문제지?" 라고 생각할지도 모르겠다.
Well, let's say a few people wanted to link to all those posts, because they liked them so much.
몇몇 사람들이 모든 포스트가 매우 마음에 들어서 모두에 대해서 링크를 걸기를 원하는 경우를 생각해보자.
You've just lost control over which category they will link to - the first one might pick the "browsers" category, and the second person might pick the "Opera" category.
당신은 이미 그들이 어떤 카테고리에 링크를 걸고 싶어 하느냐에 대한 컨트롤을 잃어버렸다. 첫번째 사람은 "browser" 카테고리를 선택할 것이고, 두번째 사람은 "Opera" 카테고리를 선택할 것이다.
If this happens multiple times, you're "throwing away" good links.
이러한 일이 여러번 발생한다면, 당신은 좋은 링크들을 버리고 있는 셈이다.

Let's say you have 2 links to your "browsers" category page, and 2 links to your "Opera" category page.
당신이 "browser" 카테고리 페이지에 2 개의 링크가 있고, "Opera" 카테고리 페이지에 2개의 링크가 있다고 하자.
A less popular competitor has 3 links to his single "browser category" page, because he doesn't have a redundant "Opera" category.
덜 유명한 경쟁자 한 명은 불필요한 "Opera" 카테고리가 없어서 하나의 "browser category" 페이지에 세 개의 링크를 가지고있다.
In a real simple world where every link is equal, your competitor would now rank above you.
모든 링크가 동등한 실세계에서는, 당신의 경쟁자가 당신 위에 랭크될 것이다.

It's very important to make sure you're not showing the same content on multiple pages, because that's not helping your rankings.
동일한 컨텐츠를 여러 페이지에 보여주지 않도록 하는 것이 매우 중요한데, 그렇게 되면 당신의 랭킹에 아무런 도움이 되지 않기 때문이다.



Internal link structure
내부 링크 구조

If you did it all right with your new site structure, it should look like a pyramid.
새로운 사이트 구조를 잘 만들었다면, 피라미드처럼 보여야 한다.
Now you should consider how you're going to connect the sections of this pyramid together.
이제는 이 피라미드들을 하나로 어떻게 합치느냐를 고민해야 한다.
Look at those sections as small pyramids inside your larger pyramid.
당신의 큰 피라미드 안에 작은 피라미드 같은 섹션들을 살펴보자.
Each page in the top of that pyramid should link to all its sub pages, and the other way around.
그 피라미드의 상단에 있는 각 페이지는 그들의 서브 페이지로 모두 링크가 있어야 하고, 다른 부분으로도 있어야 한다.

Because you're linking from pages that are closely related to each other content-wise, you're increasing your site's possibility to rank.
컨텐츠가 밀접한 연관이 있는 페이지로부터 링크를 함으로써, 사이트의 순위를 올릴 수도 있다.
You're "helping" the search engine out by showing it what's related and what isn't.
당신이 검색 엔진에게 무엇이 연관이 있고, 무엇이 연관이 없는지를 보여줌으로써 검색 엔진을 도와주는 것이다.

Take figure 4 as an example.
Figure 4를 예제로 참고하라.


You should make sure you keep your links between each page relevant to those pages.
연관이 있는 페이지들 간에 링크를 만들어 주는 것도 필요하다.
For example, if you linked from subpage 3 to plugin 2 all the time, the search engine might think that subpage 3 was related to plugin 2, whereas it's only related to plugin 4.
예를 들면, subpage 3에서 plugin 2로 항상 링크를 건다면, 검색 엔진은 subpage 3이 plugin 2와 관계 있다고만 생각할 것이다. 그런데, plugin 2는 단지 plugin 4로만 연관이 있다.

 

From your new site structure to URLs
새로운 사이트 구조부터 URL 까지

Once you've created your new site structure, you can go forth and create the URLs for this structure.
일단 새 사이트 구조가 완성이 되면, 4단계로 가서 이 구조를 위한 URL을 만들어야 한다.
Each page's URL should describe the content of that page, yet be as short as possible.
각 페이지의 URL은 그 페이지의 내용을 가장 잘 설명하면서도 최대한 짧아야 한다.
If you have determined what keywords you want to rank for, you might include the most important ones in your URLs.
랭킹에 올리고 싶은 키워드들이 무엇인지 결정하면, URL에 가장 중요한 것을 포함시켜야 한다.

Things to keep in mind while implementing your new URLs:
다음은 새 URL을 만들면서 염두할 사항들이다:

  • If you're using multiple words, separate them with hyphens.
  • 여러 개의 단어를 사용하면, 하이픈으로 구분하라.
  • Mixed case URLs are an absolute no-no, as Unix and Linux servers are case sensitive. Having mixed case URLs drastically increases the possibility of typos - have you ever tried remember a URL that /LoOks/LiKe/ThiS/ ?
  • Unix와 Linux server 등은 대소문자를 구분하기 때문에, 대소문자를 섞어서 쓴 URL은 절대 안된다. 대소문자를 섞어서 쓴 URL은 오타 입력을 급증시킨다. - /LoOks/LiKe/ThiS/와 같은 URL을 기억할려고 해봤나?
  • Numbers might be easy for your CMS, but not for your users. Remembering a URL with a number in it is hard, so the chance people will remember it and link to it is smaller - don't use numbers in URLs.
  • 당신의 CMS에는 숫자가 쉬울지 모르지만, 사용자들에게는 아니다. 숫자가 있는 URL을 기억하는 것은 어렵다. 그러므로 사람들이 기억하고 링크를 걸 가능성은 더 적다. - URL에는 숫자를 쓰지 마라.
  • Make URLs guessable if you can. If people can remember your URLs they can also talk about it with their friends more easily.
  • 가능하면 URL을 추론 가능하게 만들어라. 사람들이 당신의 URL을 기억할 수 있다면, 그들의 친구들과 더 쉽게 그것에 대해서 이야기 할 수 있다.
  • Make sure you redirect all your old pages to their new equivalents using 301 redirects. A 301 redirect is a permanent redirect, and this way search engines will move all the link value from the old URL to the new one.
  • 301 reditect를 이용해서 모든 오래된 페이지는 새 페이지로 전환되게 하라. 301 recirect는 영구적인 전환이고, 이 경우에 검색 엔진이 링크 벨류를 구URL에서 신URL로 옮진다.
  • Make sure content is available under one URL and one URL only, for example by implementing print stylesheets on your pages. There's no valid reason anymore to have a different page for printing purposes because all major browsers support print stylesheets.
  • 페이지 내에 프린트 스타일시트를 구현하는 등을 통해 하나의 URL에서 컨텐츠를 볼 수 있게 하고,하나의 URL에서만 가능하게 해라. 모든 브라우저가 프린트 스타일시트를 지원하므로 프린팅을 위해 다른 페이지를 가져야될 이유는 없다.

For more info on URLs and the problems they can cause, see my article on duplicate content.
URL에 관한 더 많은 정보나 문제점을 위해서는, 나의 "duplicate content" 본문을 참고하며 된다.

 

Conclusion: work on your site structure
결론: 사이트 구조에 대한 작업

A good site structure is a requirement for Search Engine Optimization.
좋은 사이트 구조는 '검색 엔진 최적화'의 필요 조건이다.
It allows both your users and search engines to find content within your site more easily.
당신의 사이트에서 사용자들과 검색 엔진이 더 쉽게 컨텐츠를 찾을 수 있게 해준다.
A good structure is well categorized, and pages within it only link to other pages on the same topic.
좋은 구조는 잘 분류되어 있고, 그 안의 페이지들은 동일한 주제에 대해서만 링크를 가진다.

Using the right URLs for the pages within that site structure increases the chance that people will remember and link to your URL, and heavily increases your ability to rank in the search engines as well.
사이트 구조 내에서 페이지에 올바른 URL을 사용하는 것은 사람들이 링크를 기억하고 당신의 URL로 링크를 추가할 기회를 높여주고, 검색 엔진 내에서의 순위를 높이는 역할 또한 한다.




 

댓글을 달아 주세요

IT/Web Dev | Posted by 철규님(최규철) 2011. 2. 18. 01:54

HTML5의 시맨틱 태그(Semantic tag)가 가지는 의미


HTML5로 넘어오면서 많은 변화가 있었는데, 그 중 의미적으로는 가장 큰 변화이지만 와닿지 않는 것이 '시맨틱 태그(Semantic tag)'의 도입이 아닐까 생각한다.
어떤 변화가 있으면 그 변화 내용을 아는 것도 중요하지만, 그 변화의 의미를 알아야 실제로 그 의도에 맞게 변화된 내용을 받아들이고 사용할 수 있으므로, HTML5가 등장하면서 변화가 생긴 태그들에 대해서 한번 쯤은 알아 볼 필요가 있겠다.

HTML5에 시맨틱 태그가 도입됨으로써 사용자에게 보이는 화면 뿐만 아니라, 그 화면을 구성하는데 사용되는 소스 레벨에서도 의미를 가지게 된다. 어떻게 보면 사용자의 입장에서는 태그가 의미를 가진다는 것이 큰 차리를 나타내지는 않겠지만, 검색 엔진의 레벨에서는 전혀 다른 차원의 문제가 된다. 검색 엔진은 사용자에게 보이는 화면이 아니라 소스를 대상으로 정보를 검색하기 때문에, 소스가 의미를 가지게 되면 검색 엔진은 더 정확한 검색 결과를 내놓을 수 있을 것이다.

시맨틱 태그의 도입으로 HTML5의 태그에 어떤 변화가 있는지, 그리고 이것들의 의미가 무엇인지 간단하게 정리해보자.


1. 문서 구조를 정의하는 태그

HTML4에서는 문서를 구분할 때, <div></div>태그를 사용하고, 각 div 태그에 idclass 속성을 부여해서 CSS를 적용했다. 예를 들어, 헤더 부분에는 <div id='header'>, 푸터 부분에는 <div id='footer'>, 본문 부분에는 <div id='contents'>등을 사용하는 식이었다.

HTML5에서는 다음과 같은 태그가 추가되었다.

  • header : 헤더 부분. 사이트 소개, 로고, 메뉴, 머리글 등
  • footer : 푸터 부분. 사이트 제작자나 저작권 관련 정보 등
  • nav : 네비게이터 부분. 사이트내의 메뉴 등
  • section : 실제 문서 내용 등
  • article : 문서 내용이 많을 경우 하나의 section을 여러개의 article로 나눔
  • aside : 블로그 등에 있는 사이드 바와 같은 형태

위와 같은 태그들의 도입으로 검색 엔진은 실제로 필요한 부분만을 대상으로 검색을 실행할 수 있게 된다.

예를 들어 설명하면, HTML4에서는 메뉴에 있는 'HTML5'라는 단어와 본문에 있는 'HTML5'라는 단어의 중요도를 검색 엔진이 판단할 수 없었지만, HTML5에서는 메뉴에 있는 'HTML5'라는 단어는 <nav></nav>태그 사이에 존재하고, 본문에 있는 'HTML5'라는 단어는 <article></article> 또는 <section></section> 내에 존재하므로 어떤 단어가 더 중요한 의미를 가지는 지 알 수 있다. 즉, 검색 엔진은 필요에 따라 <nav></nav>태그 사이에 존재하는 'HTML5'라는 단어는 결과에서 제외할 수도 있다. 이와 같이 HTML5의 시맨틱 태그를 사용하면 검색 엔진의 입장에서는 불필요한 검색 결과를 걸러낼 수 있으므로, 더 정확한 검색 결과를 내놓을 수 있게 된다.


HTML5에는 제목, 부제목 등을 묶어주는 <hgroup> 태그도 있다. <header> 태그가 문서의 구조적인 면을 정의하는 태그라면, <hgroup> 태그는 문서의 내용적인 면을 정의하는 태그라고 할 수 있다.

즉, <header>태그는 그 내부에 메뉴를 나타내는 <nav>태그를 가지기도 하고, 문서의 제목, 부제목을 나타내는 <hgroup>태그를 가질 수도 있다. <hgroup>태그는 필요에 따라 <h1>,<h2> 태그를 이용해 주제목, 부제목을 나타내기도 한다.

물론 <hgroup>태그는 문서 뿐만 아니라 하나의 <section>이나 <article>의 제목, 부제목을 나타내기 위해 사용될 수 도 있다. 이처럼 <hgroup>태그를 이용하면 그 페이지나 본문이 나타내는 바를 명확하게 할 수 있으며, 활용하기에 따라서는 다수의 페이지나 본문을 대상으로 인덱스 페이지를 생성해 내도록 할 수도 있다.




2. 의미를 명확히 하는 태그

(1) <figure>, <figurecaption> 태그

HTML5에서는 이미지와 그 이미지에 해당하는 캡션을 묶어서 관리할 수 있는 태그가 제공된다. HTML4에서는 이미지를 첨부하고 그 상하단에 관련 설명을 첨부하여도 검색 엔진의 입장에서는 알아낼 수 없었지만, HTML5의 <figure> 태그와 <figurecaption>태그를 이용한 페이지에서는 검색 엔진이 포함된 이미지가 어떤 것인 가에 대해서 보다 정확하게 알 수 있다.



(2) <time>태그와 <address>태그
HTML5에서는 페이지나 본문을 작성한 시각을 나타낼 때에는 <time>태그를 사용하고, 사이트 제작자나 본문 작성자의 이메일 주소나 우편 주소 등을 나타낼 때에는 <address> 태그를 사용한다. 마찬가지로 검색 엔진은 페이지 내에서 <time>태그를 만나면 그 시각을 페이지 작성 시각 또는 본문 작성 시각으로 인식하고, <address> 태그를 만나면 그 이후를 우편 주소나 이메일 주소로 인식을 한다.


(3) 문자열 관련 태그 : <mark>, <b> & <strong>, <i> & <em>
위의 태그 모두 본문의 내용 중 일부분을 강조하는데 사용되지만, 약간씩 역할과 효과가 다르다. 우선 다음의 예제를 보자.


결과만을 놓고 본다면 간단하게 다음과 같이 분류 할 수 있다.

  • <storng>, <b> : 굵은 글씨
  • <i>, <em> : 기울어진 글씨
  • <mark> : CSS를 이용한 강조 표시

HTML5에서는 <strong> 태그는 의미적으로도 중요한 의미를 가진다는 것을 나타낼 때 사용되고, <i> 태그는 외국어, 전문 용어, 대명사, 인용문 등을 나타낼 때 사용된다. 즉, 사용자에게는 동일한 굵은 글씨, 기울어진 글씨로 보일지 모르지만 검색 엔진은 <strong>태그와 <i>태그로 둘러쌓인 내용을 더 비중있게 처리하게 된다.



더 많은 내용이 있지만, 기본적으로 가장 눈에 띄는 내용들은 위와 같다. 세부적인 예를 몇 가지 들었지만, 공통적인 흐름은 태그 자체가 의미를 가지게 되어서 문서 구조나 내용을 정확하게 분석할 수 있게 되었다는 점이다.

그동안 생성되는 정보의 양은 엄청나게 증가해왔지만, 이 정보들에서 유용한 정보를 추출해내는 기술은 상대적으로 발달이 더딘 것이 사실이었다. 하지만 HTML5가 적용되면 해당 문서에 대한 기계적 분류 작업이 훨씬 용이해 질 것이도, 잘 디자인(well designed)된 문서의 수가 늘어날 수록 잘 정련된(well refined) 정보의 수와 그의 질 또한 늘어날 것이다.

댓글을 달아 주세요

  1.  댓글주소  수정/삭제  댓글쓰기 YesDitto(twitter) 2011.10.26 10:58

    정말 감사히 잘 읽었습니다. 유익한 자료 감사합니다. ^_^
    Semantic Element가 무슨 목적으로 생겼는지 궁금해하고 있었는데 정말 명쾌한 답이 되었습니다.
    근데 CSS에서 디자인할때 시멘틱 엘리먼트 자체를 선택하는게 좋은 방법일까요? 아니면 div를 써서 선택하는게 좋은 방법일까요?

    •  댓글주소  수정/삭제 철규님(최규철) 2011.11.16 12:51 신고

      안녕하세요? 관심 가져주셔서 감사합니다.
      미약한 지식이나마 간단히 의견 남겨드릴께요..
      (아는게 없어서 답변이라고 하기엔 부끄럽네요..)

      HTML5로 넘어오면서 HTML 문서 자체의 구조를 정의하는 DIV 태그는 권장하지 않는 사용 방법이라는 것이 제 개인적인 생각입니다. 어쩔 수 없이 DIV 태그를 사용해야하는 경우라면 모르겠지만, 가능한 범위 내에서는 CSS에서 시멘틱 엘리먼트 자체에 대한 접근을 하는 것이 낫지 않을까 싶습니다.

      저도 공부 중이고 관련 업무 경험이 적어서 명확한 답변을 드리지는 못하는 점 양해 부탁드립니다. 참고 정도로 받아들여 주시면 감사하겠습니다.

  2.  댓글주소  수정/삭제  댓글쓰기 뱀이 2012.02.27 14:25

    잘 읽고 이해하고갑니다.^^
    html5 공부 이제 시작하려는데요..
    시맨틱태그가 먼가 검색하다가 여기까지왔네요.ㅎㅎ
    좋은하루되세요.

IT/Computing | Posted by 철규님(최규철) 2011. 2. 15. 00:20

구글 크롬 OS 이야기



얼마전 구글에서 크롬OS(Chromium OS)를 발표하고, 얼마지나지 않아 크롬OS를 탑재한 크롬PC 테스트 제품이 등장했다.

그렇다고 구글이 일반 PC의 OS 시장에 적극적으로 뛰어들었다고 보기는 무리일 것 같고 크롬OS를 탑재한 PC를 새로운 이동형 디바이스에 대한 시도로 보는 것이 더 나을 것 같다. 실제로 시제품으로 나와서 테스트 중인 크롬PC를 살펴보면, 가장 특징적인 것이 3G 모뎀을 내장해서 이동통신사의 통신망을 이용한다는 점인데, 제조사의 소형화/경령화 기술만 추가된다면 기존의 태블릿이 가지는 입력의 불편성과 일반 PC사용 환경과의 차별에서 오는 거부감을 동시에 해소할 수 있는 디바이스가 될 것이다.

일반 사용자들이 많이 쓰는 문서 편집, 스프레드 시트, 프리젠테이션 관련 작업은 클라우드 컴퓨팅을 베이스로한 웹 어플리케이션을 통해서 지원이 가능할 것이니 기존의 태블릿보다는 활용도가 더욱 높을 것이고, 3G 통신망을 바로 사용할 수 있으니 기존의 넷북이 가지는 무선 통신의 제약에서도 충분히 벗어날 수 있을 것이다. 단순한 작업을 하기 위해서 수분에 달하는 부팅 시간을 기다리고, 쓸수록 느려지는 OS를 사용해온 사용자들에게는 여러모로 크롬OS가 반가운 존재일 것이다.


[ 그림 : Federico Fieni , 출처 : http://www.loleg.com/blog/2008/10/29/8517/ ]

클라우드 컴퓨팅을 기반으로 하는 OS이니만큼 대부분의 프로그램과 데이터는 서버에 저장이될 것이고, 이로 인해 크롬PC는 최소한의 용량을 SSD 타입으로 지원한다. 덕분에 제조사는 제조원가를 낮출 수 있으며, SSD의 장점으로 인해 베터리 사용 시간도 더욱 늘릴 수 있다. 물론 3G 통신망 사용으로 인해 아껴둔 베터리 사용량은 그만큼 다시 소모 되겠지만..

이동통신사 입장에서도 줄어만 가는 음성통화량/문자메세지 송수신량을 메우기 위해서는 데이터 통신으로 인한 수익성을 도모해야되는데, 이러한 크롬OS/크롬PC의 등장은 반갑기만 할 것이다. 즉, 이제는 PC도 이동통신사에서 약정을 맺고 구입해서 사용하게 될 수도 있다는 것이다.

이러한 눈에 직접적으로 보이는 효과 말고도 주목해야할 부분이 또 있는데, 바로 새로운 시각을 가진 시장 참여자가 시장을 크게 흔들어 놓을 수도 있다는 점이다. 기존의 하드웨어 제조업체가 판을 치던 휴대폰 시장에서, 소프트웨어에 강점을 가진 애플이 스마트폰 열풍을 일으키고 기존의 시장 질서를 파괴했듯이, 크롬OS를 내세운 구글의 OS 시장 등장은 또 다른 충격이 될지도 모를 일이다. 복잡한 프로그램을 실행해야되는 사용자의 경우는 별 영향이 없겠지만, 단순히 인터넷 서핑을 하고 음악을 듣고, 영화를 보고 문서를 작성하는 용도로 PC를 사용하는 사람들은 크롬OS의 매력에 충분히 빠져들 수 있을 것이다. 더군다나 하드웨어적인 발전도 크롬OS에 긍정적인 신호를 보내주고 있는데, SSD의 보급화, 4G 통신망의 확대, 저전력 디스플레이 개발 등 여러모로 크롬OS가 성공할 수 있는 하드웨어적인 기반이 갖춰져 가고 있다.
앞서 말했듯이 크롬OS가 기존의 PC OS들과 전면전을 펼치는 일은 없겠지만, 새로운 시장을 창출하는 과정에서 일부 기존의 시장 영역을 잠식하는 일은 충분히 벌어질 수 있는 일이라 예상할 수 있다.

구글 크롬OS는 'Chromium Project - Chromium OS'라는 이름으로 아래의 사이트에서 자세한 정보를 제공하고 있다.

구글 크롬OS를 직접 사용해보고 싶은 경우, torrent의 magnet 형식으로 구할 수 있으니 구글링을 하면 된다. ^^; 구글로 검색을 하니 VMWare 이미지 형태로 된 파일을 찾을 수 있었는데, 지금 내 컴의 uTorrent가 열심히 다운을 받고 있다. 조만간 간단한 preview 정도는 올릴 수 있지 않을까 생각한다. ^^

아래 구글 크롬OS 동영상을 보면 포스팅에서 적지 못한 자세한 사항을 잘 알 수 있을 것이라 생각한다.
어떻게보면 클라우드 컴퓨팅이라는 생소한 개념이 적용된 무거운 주제인데... 이런 것을 이처럼 쉽고 가볍게 이해시키는 것도 구글의 또 하나의 경쟁력이 아닐까?





 

댓글을 달아 주세요

IT/Web Dev | Posted by 철규님(최규철) 2011. 2. 11. 00:22

[WebKit] 웹킷(WebKit) 개발 환경 구축하기


# 웹킷이란?

웹킷(WebKit)은 웹 브라우저를 만드는데 필요한 기능을 제공하는 오픈 소스 프레임워크다. 최초 Konqueror 브라우저의 KHTML 라이브러리였으나, 맥OS에서 사파리 브라우저 제작을 위해 차용해왔고, 최근에는 다양한 플랫폼에 이식되어 사용되고 있다.
웹킷 공식 홈페이지는 http://webkit.org/ 로 이곳에서 개발과 관련한 대부분의 정보를 얻을 수 있다.



# 웹킷 개발 환경 구축하기

웹킷 개발 환경을 구축하는 방법 또한 위 사이트에서 확인 할 수 있다.
 이 포스팅에서는 윈도7을 중심으로 간단한 순서와 링크만 제공하려고 한다.


[Installing Developer Tools]

웹킷 개발자 툴은 Visual Studio 2005 버전만 지원하고 이후 버전을 지원하지 않는다.
VIsual Studio 2005 버전 소유 여부에 따라 아래 과정 중 선택해서 따르면 된다.

1-1. VIsual Studio 2005가 있는 경우

1-2. Visual Studio 2005가 없는 경우
(7) (5)단계의 Step 3에서 path를 설정할 때 아래의 path도 같이 설정한다.
 C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include\mfc

2. Cygwin 설치
(1) cygwin-downloader.zip. 다운로드 후 압축을 풀고 cygwin-downloader.exe 파일을 실행 시킨다. 해당 파일을 실행 시키면 WebKit 개발을 위한 툴이 포함된 Cygwin utility들을 로컬 디렉토리로 다운 받는다.
(2) 다운로드가 완료되면 해당 폴더에 setup.exe가 생기는데, 이 파일을 실행 시키고 Install from Local Directory를 선택한다.
(3) 설치 완료 후에  command 창을 열고 다음 커맨드를 입력한다.
C:\cygwin\bin\ash -c /bin/rebaseall
(4) Cygwin 을 실행한 후, /home/[username]/.bashrc 파일에서 아래 부분을 삭제한다.
unset TMP
unset TEMP
 
3. QuickTime SDK 설치
멀티미디어 파일 지원을 위해서 Apple 홈페이지에서 QuickTime SDK를 설치한다.
http://developer.apple.com/quicktime/download/

4. DirectX 설치

Microsoft의 DirectX를 다운받아 설치한다. 2010년 2월 이후의 버전은 지원하지 않으므로 2010년 2월 버전을 받도록 한다.

5. Debugging 툴 설치


[Getting the Code]

- WebKit 받아오기 : pre-built된 최신 WebKit을 다운받기 위해서는 WebKit Nightly Builds를 참고한다.
- Code 보기 : WebKit Trac을 이용하면 온라인에서 소스코드를 볼 수 있다.
- 소스코드 Check Out : Subversion을 이용해 서버로부터 소스코드를 받아온다.
(1) Cygwin 실행 후 아래 명령어를 실행해서 repository에서 최신 소스를 받아온다.
svn checkout http://svn.webkit.org/repository/webkit/trunk WebKit
(2)  WebKit Support LibrariesC:\cygwin\home\<username>\WebKit다운로드 받는다. 파일명은 WebKitSupportLibrary.zip이어야 하고, 압축을 풀 필요는 없다.
(3) 소스 트리를 업데이트 하기 위해서는 WebKit/Tools/Scripts 디렉토리에서 update_webkit 스크립트를 실행시킨다.


[Building WebKit]


- WebKit/Tools/Scripts
디렉토리에서 build-webkit 스크립트를 실행시킨다.
- 빌드 결과물은 기본적으로 WebKit/WebKitbuild 디렉토리에 생성된다.
- build-webkit --debug 옵션으로 빌드를 실행하면 debugging symbol과 assertion이 포함되어 빌드된다.
- Debug mode나 Release mode는 아래의 명령어를 실행하여 default 옵션을 지정할 수 있다.
- set-webkit-configuration --debug
- set-webkit-configuration --release


[Running WebKit]

- 빌드가 완료된 후 웹킷을 실행 시키기 위해서는 run-safari 스크립트를 실행시킨다.
- Debug mode로 빌드를 할 경우에는 run-safari --debug 를 실행한다.

댓글을 달아 주세요