Category Archives: 번역

더 효과적인 피어 코드 리뷰를 위한 여섯가지 방법

한빛미디어에서 당신의 동료가 더 효과적으로 코드리뷰를 할 수 있게 만드는 여섯 가지 방법 라는 좋은 글을 접했습니다. 그런데 읽다보니 번역문이 이해하기 어려운 점이 많아서 원문을 다시 읽게되었고 요약하게 되었습니다. 아래 그 내용을 공유합니다.

디자이너에겐 크리틱(critique – 비평) 이 있고, 개발자에겐 코드리뷰가 있다.

좋은 비평이란 나쁜 피드백을 좋은 피드백으로 감싼 샌드위치같은 것이 아니다. 좋은 비평을 위해서는 아래 세가지가 필요하다.

  1. 합의된 검토 수단
  2. 리뷰어의 객관성
  3. 자신의 작업물을 객관적으로 바라볼 수 있는 작성자

정량적 검토

논쟁이 생기기 어려운, 대부분 쉬운 결론이 나는 검토. 한쪽은 옳고, 다른쪽은 그르다. 적절한 정량적 검토수단을 가지면 작업물을 적절한 자동화 테스트에 넣으면 되므로 리뷰어들을 자유롭게 함. 예를들면 코딩 규칙을 지켰는지 등이 정량적 검토에 속함.

정성적 검토

의견들로 가득한, 들어보면 모두 옳은, 쉽게 결론이 나지 않는 검토. 매우 어렵기 때문에 정성적 평가 수단을 만드는 것은 시도조차 하지 않는 경우가 많음. 하지만 작성자, 리뷰어 모두의 스킬을 올려줄 만하다. 정성적 평가 수단은 비 전문가인 리뷰어에게 코드에서 어떤 요소를 찾아야 하는지 알려줌.

정성적 검토에는 아래와 같은 질문들이 포함됨:

  • 이 코드가 이 프로젝트에서 사용된 적 있는 패턴을 구현했는지?
  • 이 코드가 다른 상황에서도 사용할 수 있을 정도로 충분히 추상화 되었는지?

커뮤니케이션의 어려움

평가라는 것은 결국 도덕적인 평가와 닮아있음. 좋은 리뷰어는 위에 언급된 평가 방법 내에서 다른 것을 많이 더하지 않고도 피드백을 표현할 수 있음. 이건 결국 작성자들에게 (항상 비슷한 수준으로) 중립적으로 대응할 수 있도록 함.

이론적으로는 리뷰어가 말하는 의도를 작성자는 완벽하게 알아들을 수 있음. 하지만 사람들이 모국어가 아닌 외국어로 읽고 쓰는 경우가 많기 때문에 그런일은 잘 없음. 커뮤니케이션은 어렵고, 특히나 중립적인 커뮤니케이션은 더더욱 어렵다. 사실 중립적인 의사소통은 종종 적대적 편향 – 모호한 의사소통을 적대적으로 해석하는 인간의 특성 – 때문에 망가진다.

유용한 팁들

아래 가이드 라인을 따르기 전에 평가가 적당한 유형으로 이뤄지는지 확인해야함. 일단 커뮤니티가 기능과 광범위한 세부 구현에 대해 동의하면 코드를 작성하고 그 후엔 리뷰가 진행되어야 한다

리뷰 중에는 아래 사항들을 따르는지 확인할 것:

  1. 리뷰를 작업의 영역으로 제한하기. 효율적인 리뷰는 문제에 대해 레이저로 쏘는 것처럼 한다. 추가적인 고려사항이 필요한, 범위를 넘어서는 문제는 여기에 딸린 액션 아이템(이슈트래커의 티켓 같은)으로 만들것.
  2. 리뷰를 특정하기. 특정 라인에 대해, 컴포넌트에 대해서만 언급할 것. 일반적인 문제로 만들지 말고 명확하게 표현할 것.
  3. 리뷰를 실천가능하게 할 것. 리뷰한 것을 어떻게 변경구현할지 매우 명백해야 함. 그렇지 않으면 해당 리뷰는 지울것.
  4. 빠른 시간 내로 리뷰를 전달할 것. 리뷰를 전달하는데 오래걸리면 자신의 작업물을 왜 그렇게 개발했는지에 대해 잊어버리기 쉽다. 필자는 리뷰하는 시간을 동료와 미리 정해 놓고 함께 작업함. 잘 안되는 경우도 있지만 작은 팀에서 효율적임.
  5. 해당 문제에 대해 코더가 소요할 시간을 리뷰의 일부로 고려해야 함. 세줄을 고치는데 몇시간이 소요될 수도 있다. 인내하고 이슈를 해결하는데 시간이 걸릴 수 있음을 인지해야함.
  6. 감사하라. 오픈소스 프로젝트라면 일반적으로 기여자들에게 기여의 의무는 없었다. 특히 직장에서는 정말 싫어하는 프로젝트의 일원이 되어서 일할 것을 강요받는 경우도 있다. 감사하다고 이야기하라. 이 모든 것이 달라질 것이다.

JS프로그램의 압축(Compression of JavaScript Program)

원문은 http://j.mp/gl4jDq 에서 보실 수 있습니다. 오역의 가능성이 있으니 원문과 비교하며 보세요~

왜 자바스크립트를 압축해야 할까?

JS파일을 압축해야하는데에는 여러 이유가 있을 수 있을 수 있습니다. 네트워크 대역폭을 줄이고자 하는 것이 가장 명백한 이유가 될 수 있는데, 이는 HTTP 압축을 통해 달성할 수 있습니다. 그러나 HTTP 압축에 의존할 수 없거나 허용되지 않는 예외적인 경우가 있을 수 있습니다. 제 흥미를 끈 것은 JS파일 크기에 강제적인 제한을 둔 몇몇 데모 공모전이었습니다. 예를 들어, WebGL 64k Contest 에는 다음과 같은 규칙이 있습니다.

  • 제출되는 파일의 사이즈는 64k 이하일 것(65536바이트)
  • 외부요청이 없을 것, 모든 것은 JS내에 인라인으로 포함시킬 것.

두번째 포인트를 보면, 모든 이미지나 음악 등의 자원들이 JS 소스코드로 인라인되어야 하고, 첫번째 포인트에 따르면 소스코드는 65536바이트를 넘지 않아야 합니다. 꽤 도전적이네요! 재미있는 프로그램을 만들기 위해 여러분은 주어진 용량을 효율적으로 사용해야 합니다. 따라서 압축이 필요합니다.

The Google Closure Compiler

가장 중요한 것을 먼저 봅시다. Google에서 공개한 Google Closure Compiler라는 도구가 있습니다. 이 도구는 기본적으로 아래와 같은 방법을 통해 JS코드의 용량을 최소한으로 줄입니다.

  • 모든 주석과 불필요한 공백 제거
  • 변수명과 프로퍼티명을 더 짧게 변경
  • 표현문과 구조를 더 압축된 형태로 리팩토링

말할 것도 없이 JS소스코드를 압축하려는 모든 시도는 closure compiler를 사용하는 것으로부터 시작됩니다. 아울러 이 글에서는 이미 closure compiler로 압축되어있는 코드에서 더 나아가 바이너리 압축을 적용시키는 것에 초점을 맞출 것입니다.

압축방법 결정하기

우리가 당면한 주요문제 중 하나는 JS 프로그램이 스스로 압축해제가 가능해야 한다는 것입니다. 따라서 압축해제 루틴이 너무 많은 공간을 차지하면 압축의 이득을 잃게 됩니다. 또다른 문제는 바이너리로 압축된 데이터 스트림이 JS소스로 저장이 가능한 형태여야 한다는 것입니다.

기존의 라이브러리들

압축해제 루틴이 작아야 하므로, 기존의 (효율적이지만 크기가 큰) JXGraph, js-deflate와 같은 압축해제 라이브러리들은 실격입니다.

liblzg 사용하기

저의 첫번째 해결책은 liblzg 압축 라이브러리를 사용하는 것입니다. 이 라이브러리는 경량화된 압축해제 루틴을 가질 수 있도록 특별히 디자인되었습니다. 압축해제루틴은 불과 450바이트 정도에 불과하며(조금 손을 보면 더 작아질 수 도 있습니다) 우리의 필요에 잘 맞습니다.

바이너리 데이터 다루기

이제 다른 문제가 있습니다. 어떻게 바이너리 데이터를 js 소스 파일로 담을 수 있을까요?

Base64

바이너리 데이터를 텍스트 파일로 저장할 수 있는 검증된 방법은 물론 base64 를 통한 방법입니다. 그러나, 이 방법은 텍스트 한글자마다 6비트밖에 사용할 수 없기 때문에 33%의 용량(8비트 문자 인코딩인 경우)을 더 써야 합니다. 이런 용량증가는 압축률에 심각한 영향을 미칠 것 이므로 더 좋은 방법을 찾아봐야 합니다.

Latin 1

첫번째로 시도해봤던 방법은 Latin 1 인코딩을 사용하는 방법이었습니다. 즉, 압축된 바이트 데이터를 Latin 1으로 인코딩해 JS 문자열로 저장한 것입니다. 물론, 인코딩의 한계로 몇몇 바이트 값이 금지(더 정확하게 말하면, 0~31, 39, 92, 127~159번)되어 있기 때문에 조금 손보지 않으면 작동하지 않습니다. 사용할 수 없는 바이트코드를 2바이트 문자로 대체시키고, (liblzg로 압축된 데이터의 통계에 기반해) 자주 쓰이지 않는 바이트코드를 사용할 수 없는 코드와 교환하게 되면 용량을 증가시킬 요소는 5~10% 정도로 줄어들 수 있습니다. 자, 이것보다 더 줄일 방법은 없을까요?

UTF-16

할 수 있습니다! Latin 1 인코딩을 사용했을 때 0~255번 코드 사이의 26%는 사용할 수 없다는 것에 주목하면, UTF-16 인코딩의 사용할 수 없는 코드는 3%에 불과 합니다(0~65535번 코드 사이에 2151개의 코드). 그럼 UTF-16를 사용해 JS 프로그램을 줄여봅시다. 브라우저가 UTF-16을 이용하는 것을 인지할 수 있도록 파일 시작 부분에 2바이트의 BOM이 추가됩니다(사실 클라이언트 프로그램이나 텍스트에디터에서 Latin 1 인코딩을 UTF-8로 혼돈하는 경우가 있기 때문에 UTF-16이 Latin 1을 사용하는 것보다 더 안전합니다). 이제 압축된 데이터 스트림 2바이트를 1개의 UTF-16 글자로 줄일 수 있게 되었고, 다시 한번 사용할 수 없는 코드에 대한 처리를 하고 나면, (사용할 수 없는 코드를 사용할 수 있는 UTF-16 코드 2글자로 대체), 4%미만의 용량이 증가합니다 (liblzg 압축된 데이터의 경우에는 거의 1%미만 입니다).

UTF-16 인코딩의 단점

UTF-16인코딩을 사용하는 데에 심각한 문제가 하나 있습니다. 압축해제 루틴도 UTF-16으로 저장되어야 한다는 것입니다. 즉, 압축해제 로직이 2배의 용량을 차지하게 된다는 뜻입니다.(900바이트 이상). 작은 파일에서는 최종 파일의 크기가 Latin 1 인코딩을 사용하는 것보다 더 크게 될 겁니다. 하지만 걱정할 것은 없습니다. 해결책은 가까이 있으니까요. 압축해제 루틴도 줄일 수 있습니다. 어떻게 가능할까요? 바이너리 데이터에 했던 것과 같이 2개의 글자를 UTF-16 글자 한개로 만들어봅시다. 압축해제 루틴은 순수한 ASCII코드(36~126번 사이의 글자들)이라는 좋은 특징을 가지고 있습니다. 이것은 두개의 연속된 바이트를 한개의 유니코드로 합치면 “언제나” 유효한 글자가 된다는 뜻입니다(2020-7e7e 사이의 UTF-16코드는 전부 유효합니다). UTF-16 문자열로 표현된 압축해제 루틴이 사용할 수 없는 코드를 만들지 않기 때문에 공간을 전혀 낭비하지 않게 되고, 이 루틴을 다시 되돌리는 작업도 매우 간단합니다. 네, 되돌리기 위해 또다른 루틴이 필요하고, 이 루틴은 순수한 UTF-16 형식이어야 합니다. 하지만 새로 만들 루틴은 그렇게 많은 코드가 필요치 않고 아주 간단합니다. 이 루틴은 아래와 비슷할 겁니다(closure compiler를 통하지 않은 모습입니다).

liblzg를 통한 접근의 결론

지금까지 우리는 스스로 압축을 해제할 수 있는 JS 프로그램을 만들기 위해 최대한으로 liblzg 압축을 활용했습니다. 요약하면 :

  • 스스로 압축해제가 가능한 JS 모듈(약 600바이트)
  • (원래의 바이너리 크기보다 3%정도 더 큰) 아주 잘 압축된 바이너리 데이터
  • (크로스 브라우징이 아주 잘 되는) 순수 ECMAScript 구현
  • (DEFLATE, Bzip2, LZMA 등 보다는 떨어지지만) 적절한 압축률

좋은 결과에 도달하긴 했지만, 더 잘할 수도 있습니다.

더 잘 해보기 – PNG

JS로 브라우저 API에 접근해 DEFLATE로 인코딩 된 데이터를 풀어낼 수 있으면 얼마나 좋을까요? 대부분의 브라우저는 여러가지 작업을 위해 내부적으로 zlib을 사용하지만, zlib을 JS로 직접접근하는 방법은 아직 없습니다. 하지만 우리가 IE 6,7, 8과 같은 기존 브라우저에 대한 호환성을 희생시키면 엘리먼트를 사용한 다른 멋진 트릭을 사용할 수 있습니다. JS프로그램을 PNG 이미지 파일 내에 저장시키는 것입니다. 이 방법은 어떤 장점이 있고, 어떻게 사용할 수 있을까요?

PNG 아이디어

자, PNG 이미지 파일 포맷에 대해 약간의 배경지식을 가져볼까요.

  • PNG는 압축하는데에 DEFLATE알고리즘을 사용합니다(이것은 이를테면 ZIP과 gzip에 사용되는 것과 비슷합니다).
  • 무손실 파일 포맷입니다(어떤 픽셀도 왜곡시키지 않습니다).
  • 모든 최근의 브라우저들은 Image 객체로 로딩 될 때 PNG 이미지를 해석할 수 있습니다.
  • PNG 이미지를 canvas 엘리먼트로 그릴 수 있고, getImageData() 메서드를 통해 픽셀들을 다시 읽어들일 수 있습니다.

다시 말하면, canvas 엘리먼트의 도움으로 PNG 이미지를 압축해제할 수 있고 그 내용을 (eval을 사용해)실행 가능한 JS의 String 객체로 풀어낼 수 있다는 것입니다. 우리는 다시한번 원래의 PNG 이미지 데이터를 JS 문자열로 바꾸는데 너무 많은 용량 증가 없이 UTF-16트릭을 사용할 수 있습니다.

압축해제 로직

liblzg 해결책을 사용했을 때는 압축해제 코드가 별도로 필요했습니다. 이번에는 실제 압축해제 알고리즘은 필요가 없고, 다만 대략 아래와 같은 순서를 따르는 작은 프로그램이 필요합니다.

  1. UTF-16 문자열을 바이너리 문자열로 디코드
  2. btoa()메서드를 사용해 바이너리 문자열을 Base64로 인코드
  3. “data:image/png;base64,”라는 작은 헤더를 앞에 붙인 data URI를 생성
  4. data URI를 Image 객체로 로드
  5. 이미지의 onload 핸들러에서
    1. 이미지를 canvas 엘리먼트로 그리기
    2. pixel 값을 읽어들여 새로운 문자열로 할당
    3. 문자열의 내용을 실행

이 압축해제 프로그램의 크기는대략 liblzg 디코더와 비슷하지만, 다른 측면에서 DEFLATE 압축 방법은 더 좋은 압축률을 보입니다(주요 원인은 liblzg는 오직 LZ77 압축만을 사용하는데 반해, DEFLATE는 LZ77과 Huffman 압축을 조합해 사용하기 때문입니다).

PNG를 통한 접근법의 결론

지금까지 위에 설명된 PNG를 통한 방법은 압축률과 관한한(압축해제 루틴을 압축된 컨텐츠의 일부로 포함했을 때), 주어진 목표 내에서 현재의 브라우저 기술을 최대한으로 이용했습니다. 이 방법의 장점들은

  • DEFLATE 압축해제 루틴을 브라우저 내에서 재 사용
    • 일반적으로 사용 가능함(PNG를 지원하는 모든 브라우저)
    • 매우 좋은 압축률(JS 코드가 잘 압축됨)
  • 순수한 PNG 데이터를 유효한 UTF-16 문자열로 인코드
    • 바이너리 데이터를 문자열로 인코딩할 때 매우 낮은 오버헤드(Base64의 33%에 비교했을 때 3~4%에 불과)
    • 브라우저가 잘못 해석할 가능성이 매우 낮음

끝내기 – CrunchMe

여기 설명된 압축방법들이 여러분께 유용하고 흥미로웠으면 합니다. 여러분이 자신의 JS 프로그램을 압축하고자 한다면, CrunchMe 라는 오픈소스 커맨드 라인툴이 있습니다. 참고 : 이 글을 쓰고 있는 현재 CrunchMe는 아직 개발중입니다. 하지만 일반적인 사용에는 충분히 안정적일 겁니다. (그렇긴하지만, 스스로 컴파일 해야할 겁니다).

위지윅(WYSIWYG) 에디터를 만들고자 할 때 고려할 사항

원문은 http://bit.ly/ksonHb 에서 보실 수 있습니다.

1. iframe docs vs. contenteditable divs

위지윅에디터를 제작하고자 할 때 iframe을 사용할 지, 어느 엘리먼트에나 존재하는 contenteditable 속성을 이용할 지 고민될 수 있습니다. 답변자는 iframe을 추천합니다. 그 이유로:

iframe내에서는 문서 타입, CSS, script 등을 이용해 완전한 제어를 할 수 있습니다. 여러 다른 페이지내에서 통일된 액션과 모습을 보여주는 데에 꼭 필요합니다. 특히 Firefox에서 contenteditable 속성을 가진 엘리먼트가 매우 버그가 많은데, 이것은 몇 년 전부터 있어왔고 아주 잘 동작하는 document의 designMode속성에 비해(pre-1.0 부터인가? 확실하지 않습니다) 이 속성이 비교적 최근에(3.0버전부터) 도입되었기 때문입니다.

2. Cross browser styling

execCommand는 볼드, 이탤릭 등 엘리먼트에 스타일을 입히도록 하는 역할을 합니다. 문제는 각 브라우저 마다 이 메서드를 실행했을 때 어떤 브라우저는 볼드를 <b>로, 어떤 브라우저는 <strong>으로 표시하는 것과 같은 문제가 발생할 수 있습니다. 이것을 통일 시키는 방안에 대해 답변자는 이렇게 이야기 합니다.

만약 여러 다른 브라우저에서 통일된 결과물을 얻는 것이 중요하다면, 아마 자기만의 스타일링 코드를 작성해야 할 겁니다. 그렇지만, 이렇게 하면 브라우저에 내장된 되돌리기(undo) 작업을 불가능하게 할 것이므로 자기만의 되돌리기(undo)/다시실행하기(redo) 코드를 만들어야 할 겁니다.

3. adding items to the undo chain

Q:브라우저에 내장된 되돌리기/다시실행하기 작업이 저장된 배열이 있을까요? 그리고 그것을 수정할 수 있을까요?

A: 브라우저 내장의 되돌리기 스택에 접근할 수 있는 방법은 없습니다. 스스로 작성하셔야 합니다.

4. keeping the text selection

Q: 글자체를 선택하는 것과 같이 포커스가 이동하면서 블럭지정이 풀려버리는데, 블럭지정한 텍스트를 어떻게 유지할 수 있을까요? Rangy나 Google closure 외에 다른 라이브러리가 있습니까?

A: 이 질문이 가장 흥미롭습니다. 바로 제가 Rangy를 작성했거든요. 이와 같은 일을 하는데에 더 좋은 라이브러리는 없다고 생각합니다. Google Closure는 범위/선택과 관련한 API를 가지고 있지 않지만 DOM Range와 일반적인 브라우저의 Selection 객체보다 더 우선한 자신만의 인터페이스를 사용한다고 생각합니다. IERange는 Rangy와 비슷한 아이디어를 가진 라이브러리이지만 구현된 범위가 적으므로 지금당장은 고려대상이 아니라고 생각합니다.

p.s. 재미있는 것은, 그 아래의 답변입니다. “진심으로 말하는데 그냥 나와있는 것을 쓰세요” 라는데, 무려 3명이나 추천했군요 🙂

더 나은 SEO를 위해 알기쉬운 사이트 구조 작성하기

원문: Intelligent site structure for better SEO!

검색엔진은 오늘날 사이트에 방문자를 이끌어주는 가장 중요한 방법 중 하나이다. 따라서 검색엔진 최적화(Search Engine Optimization)은 매우 중요하다. 하지만 SEO는 종종 기술적 꼼수 모음으로 오해받곤 한다. – SEO전문가로서 고객들과 기술적인 이슈를 고치는 데에 많은 시간을 들였음을 고백한다. – 사이트의 구조는 검색엔진이 사이트의 주제가 무엇인지, 그리고 얼마나 쉽게 사이트의 목적과 의도에 맞는 컨텐츠를 찾고 색인화 할 수 있는지를 결정한다.

좋은 구조를 만듦으로써 다른 사람들로부터 링크를 받은 여러분의 컨텐츠를 활용할 수 있고, 사이트의 구조를 이른바 “링크주스(linkjuice)”와 같이 여러분 사이트의 다른 페이지에 배치해 놓을 수도 있다.

상업적인 사이트라면 질 좋은 컨텐츠를 여러분의 판매 페이지의 랭킹을 높이는데 사용할 수도 있다. 왜 필요한지 이제 관심이 좀 생겼을까? 지금까지 무엇을 왜 할지 알았으니 이제는 어떻게 하는지 알아볼 차례다. 

좋은 사이트 구조 만들기

새로운 사이트를 개발하거나 개편할 때, Visio나 하다못해 엑셀에 집어넣더라도 사이트의 구조를 그려보는 것이 도움이 된다. 여러분이 할 것은 그림 1과 같이 모든 페이지와 섹션을 트리로 만들어내는 것이다. (저자의 옛 사이트 구조에 기초함):

그림 1: 전형적인 사이트 구조

그림 1: 전형적인 사이트 구조

Code섹션이 전체 사이트의 반이상으로, 현재 균형이 맞지 않음을 볼 수 있다. 사이트 구조를 합리적이고 균형잡힌 피라미드 모양으로 만들어내야 한다. 사이트 내의 컨텐츠 양에 따라 2개에서 7개 사이의 메인섹션으로 구성하고 다른 섹션 대비 2배 이상 큰 섹션이 있으면 안된다.

또 다른 몇몇 포인트들이 있다. 먼저, “About Me”, “Projects”, “Websites”와 같은 기본적인 자기 소개 페이지가 3개나 있다. 또한, 내 사이트의 통계를 검토해보니 3레벨과 4레벨에 있는 Word Press 페이지가 사이트 트래픽의 30% 가량을 차지하고 있음을 알았다.

Visio나 OmniGraffle 과 같은 툴의 이점은 재정렬을 매우 쉽게 해주고, 새로운 구조가 잘 작동할 것인지 좋은 느낌을 받을 수 있게한다는 것이다. 나는 가끔 책상이나 벽에 포스트 잇을 붙여놓고 사용하기도 하는데, 둘다 나에게는 잘 맞는다.

그림 2는 재정렬한 결과이다.

그림 2: 개선된 섹션 구조

그림 2: 개선된 섹션 구조

그림에서 보듯 몇몇 페이지는 트리의 상단으로 이동시켰고, 또 몇몇 페이지는 제거했다. 사이트 구조를 다시 생각하다보면 어떤 페이지들은 사용자들에게 별로 이롭지 않은 것을 자주 발견하게 될 것이다. 그런 경우에는 없애는 것이 최선이다.

또 블로그를 홈으로 옮기기로 결정했다. 내 홈페이지에는 터무니없는 이야기도 많고, 그리고 또 본질적으로는 또 다른 “About Me” 페이지의 하나이다. 나 자신에 대해 부끄러운건 아니지만 블로그가 내 사이트의 방문목적이 되는 것을 원치는 않는다. 내 블로그는 내 사이트의 토대이므로 블로그도 이 구조의 중요한 위치에 배치했다.

섹션에 이름 짓기

사이트 구조에 만족했다면 섹션의 이름들에 대해 생각해 볼 차례다. 만약 섹션을 구성할 수 있을만큼 각 주제의 컨텐츠의 양이 충분하다면, 그만큼 많은 사람들도 검색을 통해 찾아올 것이라고 확신할 것이다. 이것이 바로 섹션의 이름을 사람들이 검색어로 활용하는 키워드로 만들어야 하는 이유가 되는 것이다!

예를 들어, 여러분이 나처럼 워드프레스 플러그인을 만들고 다른 사람들을 위해 섹션을 만들었다고 해보자. 이 섹션의 이름이 “워드프레스” 여서는 안된다. 여러분은 어떻게 검색할 것인가? “워드프레스 플러그인”으로 검색하지 않을까? 그러므로 “워드프레스 플러그인”과 같은 이름을 지어야 한다(이것은 “워드프레스”라고 부르지 말라는 의미가 아니고, 페이지 타이틀과 네비게이션 링크를 “워드프레스 플러그인”으로 만들라는 의미이다). 사람들이 어떤 검색어로 검색하는지를 알고자 한다면 아래 도구 들이 도움이 될 것이다.

섹션과 하위 섹션에 알맞은 이름을 결정한다. 이제 반 정도왔다. 이제 같은 방법으로 각 페이지들의 이름을 짧고 간결하게 결정한다. 내 섹션들은 이제 그림 3과 같은 이름을 가지게 되었다.

그림 3: 알아보기 쉬운 섹션이름을 가진 사이트 구조

그림 3: 알아보기 쉬운 섹션이름을 가진 사이트 구조

지금까지 우리는 사이트 구조 정의에 가장 중요한 두가지를 해왔다. 앞으로는 또 다른 몇몇 중요한 포인트에 대해 생각해보고자 한다.

숙지해야 할 몇가지 사항들

다음은 사이트 구조를 결정할 때 숙지해야 할 몇가지 사항들이다.

포럼과 같이 사용자가 조정하는 컨텐츠

만약 사이트의 한 부분이 다른 부분보다 훨씬 더 많은 컨텐츠가 있고, 더 많이 생산 되는 곳의 질은 상대적으로 떨어진다면, 아마도 두 곳을 섞는 것이 꺼려질 것이다. 예를 들어, “A List Apart”의 같은 초기화면을 생각해보면, 몇 주마다 아주 양질의 글들이 업데이트되고 이 글들은 다른 사이트들에 많이 링크된다. 또 다른 섹션은 포럼이다. 포럼은 그 질이 보장되지 않는 글들이 매일 몇개씩 올라오는 곳이다.

여러분의 포럼은 아마도 사이트 첫페이지의 검색 순위를 떨어뜨릴 것이다. 왜냐하면 사이트의 ranking strength 가 양질의 컨텐츠에서 포럼으로 흘러가기 때문이다. 따라서 이 둘을 함께 유지하기 위해서는 포럼을 사이트의 서브도메인으로 옮기도록 하라.

여러분이 운영하는 블로그는 상대적으로 문제가 되지 않는다. 블로그의 글들은 상대적으로 질이 보장되어 있고 여러분은 블로그 글 또한 검색 순위에 오르는 것을 바랄 것이기 때문이다.

중복된 카테고리와 태그

여러 카테고리를 갖는 사이트나 블로그가 빠지기 쉬운 함정은 특정 글들에 대해 지속적으로 비슷한 두 개의 카테고리를 배정하는 것이다. 예를 들어 사이트에 “브라우저”와 “오페라”라는 카테고리가 있다고 하고, 여러분은 오페라에 대해서만 글을 작성한다고 하자. 이제 브라우저 카테고리의 리스트를 보게되면 아마도 오페라 카테고리의 페이지들과 완전히 같은 컨텐츠가 존재하게 된다. 이 두가지는 기본적으로 중복이다.

태그를 사용하면 이 문제는 더 자주 일어나게 된다. 아마도 “이것이 왜 문제가 되나요?” 하고 놀라게 될텐데, 몇몇 사용자가 컨텐츠가 너무 마음에 들어 모든 포스트를 링크하려고 한다고 해보자. 이제 여러분은 그들이 어떤 카테고리의 것들을 링크하게 되는지 통제할 수 없게 된다. 어떤 사람은 “브라우저” 카테고리를 링크하고, 또 어떤 사람은 “오페라” 카테고리를 링크한다. 이런 일이 여러 번 일어나게 되면, 여러분은 good link를 던져버리는 꼴이 된다.

만약 2개의 링크가 “브라우저”카테고리로 연결되고, 2개의 링크는 “오페라” 카테고리 페이지로 연결된다고 해보자. 인기가 덜한 경쟁자의 사이트에는 “오페라”카테고리가 없고 한 개의 “브라우저”카테고리에 3개의 링크를 가지고 있다. 모든 상황이 같다고 단순가정하면 경쟁자가 당신보다 상위에 랭크되게 된다.

내부 링크 구조

구조를 잘 만들었다면, 피라미드처럼 보여야 한다. 이제 이 피라미드 사이에서 어떻게 연결할 것인지를 결정해야한다. 섹션들을 큰 미라미드 내의 작은 피라미드처럼 생각해보자. 각 미라미드의 꼭대기는 그 서브페이지들과 모두 연결되어야 하고, 서브페이지들도 꼭대기와 연결되어야 한다.

컨텐츠 관점에서 각 페이지들이 긴밀히 연결되어 있으므로, 사이트가 검색에 걸리게 될 확률이 높아진다. 여러분은 검색엔진에게 어떤 것이 관련되어 있고 어떤것이 연관되지 않는지를 알려주게 된다.

그림 4를 보자.

그림 4: 각 섹션 내에서 페이지들을 서로 어떻게 연결해야할지 고려해야 한다.

그림 4: 각 섹션 내에서 페이지들을 서로 어떻게 연결해야할지 고려해야 한다.

각 페이지가 잘 연관되어 링크되도록 해야한다. 예를 들어, 서브페이지 3이 플러그인 2를 항상 링크하고 있다면, 사실은 플러그인 4와 연관됨에도 불구하고 검색엔진은 서브페이지 3이 플러그인 2와 연관되어있다고 여길 것이다.

새로운 사이트구조에서의 URL

새로운 사이트 구조를 만들어냈으면, 이제 다음단계로 이 구조에 맞는 URL을 만들어야 한다. 각 페이지의 URL은 그 페이지의 컨텐츠를 나타내야 한다. 어떤 키워드로 노출 될지를 결정했다면, 가장 중요한 한 개의 키워드를 URL에 포함시켜야 한다.

새 URL을 결정할 때 기억해야할 것들은

  • 여러 단어는 하이픈(-)으로 분리하라.
  • Unix나 Lunux서버는 대소문자를 구분하기 때문에 대소문자를 섞으면 절대 안된다. 대소문자가 섞인 URL은 오타의 가능성을 엄청나게 높인다 – /LoOks/LiKe/ThiS/ 와 같은 URL을 잘 기억할 수 있을까?
  • 숫자는 여러분의 CMS에게나 쉽지 사용자에게는 어렵다. 숫자가 섞인 URL은 사람에게는 어렵기 때문에 기억하거나 링크될 확률을 줄인다. – 숫자를 사용하지 마라.
  • 될 수 있으면 URL은 추정하기 쉽게 만들어라. 사람들에게 기억되기 좋은 URL은 그들이 친구들과 이것에 관해 이야기하기도 쉽게 만든다.
  • 301 Redirect를 통해 이전 페이지에서 새 페이지로 리디렉트 시켜라. 301 Redirect는 완전한 이동을 뜻하고, 검색엔진은 이전 링크 값을 새로운 페이지로 대치시킬 것이다.
  • 컨텐츠가 한 URL에만 있도록 하라. 예를 들어 프린트 스타일시트를 사용한다고 하면 인쇄를 위해 또 다른 페이지를 가져야 할 아무런 이유가 없다.

주소와 관련한 정보나 일어날 수 있는 문제에 대해 더 알고 싶으면 저자의 중복된 컨텐츠라는 글을 참고 한다.

결론 : 여러분의 사이트 구조에 적용하기

좋은 사이트 구조는 검색엔진 최적화에 꼭 필요하다. 이는 사용자와 서치엔진 모두에게 사이트 내의 컨텐츠를 찾기 쉽게 한다. 좋은 구조는 카테고리가 잘 나뉘어 있고, 카테고리 내의 페이지들이 같은 주제끼리만 연결되는 것을 의미한다.

올바른 URL을 사용하는 것은 사용자들이 기억하고 링크하는 기회를 늘리고, 서치엔진에서 상위에 랭크될 가능성도 매우 높인다.

참고 : 나는 이 글을 2007년 10월 dev.opera.com에 기고했다. 이 주제에 대한 글이 필요하다는 결론을 내렸을 때, 오래 전 작성했던 이 글을 발견했다. 몇몇 참고링크를 더했을 뿐 중요하게 변경된 것은 없다.

회원가입 프로세스를 심플하게 만드는 17가지 방법

xguru님의 이번 주 기술뉴스에 포함된 “회원가입 프로세스를 심플하게 만드는 17가지 방법” 에 대한 간단한 번역입니다. 원문에는 이해가 쉽도록 이미지 등도 있으니 참고하세요~ 오역의 가능성은 다분합니다 -_-

  1. 이메일을 아이디로 만들어라
  2. 사용자가 항상 쓰는 비밀번호를 쓸 수 있게 하라. (복잡한 규칙을 설정하지 마라. 은행, 개인정보 등 민감한 사항을 다루는 웹사이트들은 예외.)
  3. 추가 정보는 우선 계정을 만든 다음에 받도록 해라.
  4. 만약 내 아이디(이메일)가 사용되고 있다면 (Ajax등을 사용해서) 바로바로 알려줘라. 만약 아이디(이메일)가 사용되고 있다면 바로 비밀번호를 타이핑하고 로그인할 수 있도록 비밀번호 필드를 보여주고, “이 이메일 주소로 비밀번호 찾기 메일 보내기” 와 같은 링크를 달아주자.(이미 가입한 사람이 가입했는지 잊어먹은 경우의 편의를 고려함.)
  5. CAPTCHA가 꼭 필요할까?
    • A/B 테스트를 통해 CAPTCHA가 제거 되었을 때 스팸 가입자가 증가하는지 살펴보라.
  6. 회원 가입 후에는 자동으로 로그인 되게 하라.
    • 뭔가를 필요로 해서 회원가입을 하는 것이므로 바로 접근가능하게 할 것.
  7. 환영 이메일을 찾기 쉽게 만들라
    • 예를 들어 Your [app name] account details 와 같은 제목을 사용하고 암호와 같은 보낸 사람 이메일 대신 보낸사람이름을 활용하라.
  8. 회원가입폼을 홈페이지에 드러나게 하라
    • 회원 유치가 주 목적이라면 facebook과 같이 회원가입폼을 드러나게..
  9. 회원 가입을 했을 때의 이점을 알려줘라

— 이 아래부터는 의견들.

  1. 회원 가입과 로그인을 한번에..
    • 이메일만 입력하게 하고 가입되어있으면 로그인 폼을 보여주고, 되어있지 않으면 회원가입폼을 보여줌
  2. 이메일만 받자
    • 이메일만 회원 가입시 받게 하고, 자신의 정보를 수정할 수 있는 링크가 포함된 메일을 보낸다. 언제나 이 메일의 링크는 자기 정보를 수정할 수 있도록 만듦으로, 패스워드 찾기 시에도 활용될 수 있다.
  3. 그냥 오픈아이디를 사용하자.
  4. 뉴스레터는 opt-out이 아닌, opt-in 방식으로 보내라 여기서 opt-in은 받겠다고 요청한 사람 opt-out은 거부하지 않은 사람.
  5. 내 브라우저가 자동으로 폼을 채워넣도록 해주세요. 브라우저의 자동완성 기능을 활용하는 사용자들을 위해 자바스크립트 등으로 초기값을 조정할 때는 신중하게.
  6. 사용가능한 비밀번호 형식을 미리 보여줘라.
  7. 어디서 가입이 가능한지를 알려줘라.
    • 로그인보다 회원가입을 강조하라
  8. 패스워드를 두번 넣게 하지마라.
    • 그냥 인풋 텍스트로 한번 받고 말지, 비밀번호 형식으로 2번 받을지 가입자에게 고를 수 있게 하라. (이것은 좀.. 그래도 트위터는 비밀번호 한 번 입력으로 가입이 가능하죠!)