보통 어떤 공개되지 않은 웹 서비스를 디버깅해야 한다면, 우선 노출된 소스를 벗겨보거나 Web Inspector 혹은 Firebug와 같은 웹 브라우저에 내장된 디버거를 통해 일부나마 수집된 자료를 일일이 확인하고 자료의 시작점을 추적하는 작업을 거쳐야 하는데, 이는 무척이나 번거롭고 시간도 많이 잡아먹기 마련이다.

그런데 이런 일에 특화된 애플리케이션으로 웹 디버깅용 Proxy 애플리케이션인 Charles를 구독 중인 블로그 글에서 우연하게 발견하였다. Charles는 HTTP proxy를 구성해서 웹 클라이언트와 서버 사이를 오가는 통신을 가로채서 둘 사이의 모든 요청과 응답 그리고 HTTP headers를 적나라하게 보여주는 아주 막강한 웹 디버깅 애플리케이션이다.

비슷한 무료 애플리케이션으로 Wireshark라는 놈이 있는데 Mac에선 X11을 통해 실행되고 여러 가지 추가 설정이 필요해서 사용이 번거롭지만, 이에 반해 Charles를 실행하면 proxy 설정도 자동으로 해주고 덤으로 HTTPS 통신도 지원하는 이점이 있다.
Shareware($50)로 trial은 실행할 때마다 15분의 사용시간 제약이 있다.

이렇게 기능이 훌륭해서 좋은 의도를 가지고 쓰면 아주 생산적인 도구가 되겠지만, 반면 혹시 있을지 모를 보안상 취약점도 들출 수 있으므로 웹 서비스는 항상 보안에도 신경을 써야 함을 일깨워주기도 한다.

색다른 단지 모양의 로고가 이채로운데, 주로 웹 form에 POST 되는 정확한 요청 값을 알아내거나 JSON/XML 행태의 서버 응답 내용을 확인할 때도 아주 유용할 듯.

W3C의 Internationalization Core Working Group에서 Internationalization Best Practices: Specifying Language in XHTML & HTML Content라는 제목의 문서를 새로 갱신해서 올려놓았다.

이 문서는 HTML 문서 내용을 다루는 저자나 프로그램 개발자들에게 세계 각국 언어에 맞는 현지화를 위한 일종의 안내서로 사용될 수 있도록 관련 권고 사항들을 전해주고 있다.
문서 내용을 요약하면 먼저 HTML 문서에 사용 언어를 선언할 때 주의할 사항으로 character encoding과 글이 읽히는 방향(direction of text)을 언어 선언과 혼동해서 쓰지 말라고 경고하고 있다. Character encoding 값과 사용 언어는 일대일로 바로 적용될 수가 없는데, 그 이유로 어떤 하나의 인코딩 값이 여러 다양한 언어를 대표할 수도 있기 때문이다. 글이 읽히는 방향도 한 언어 안에서 문서 내의 문맥에 따라 서로 다른 방향으로 읽히고 해석되어야 할 필요가 생길 수도 있고, 대표 언어를 선언하는 것만으로는 이런 상황을 제대로 표현해 줄 수가 없게 된다.

위 문서에는 웹 브라우저나 화면 해독기와 같은 user agents가 문서에 쓰인 언어를 올바로 해석할 수 있게 하려고 (X)HTML 문서 안에 사용 언어를 선언해 주는 대표적 방법들을 다음과 같이 소개하고 있다.

첫 번째 방법으로는 XHTML 요소에 langxml:lang 속성을 사용하는 방법으로, 문서 전체의 언어를 지정할 땐 html 태그에 정의해 준다. 물론 문서 안에 포함된 특정 요소에 다른 언어가 사용되었을 땐 해당 요소에 따로 적당한 언어 속성을 지정해 줄 수도 있다.

<!-- 보기 1: text/html mime type으로 전달되는 XHTML 1.0 문서 안에 언어 속성을 사용해서 선언해 준 예.-->
<html lang="ko" xml:lang="ko" xmlns"http://www.w3.org/1999/xhtml">

여기서 주의할 것은, HTML일 경우 lang 속성만 사용되며, XML로 전달되는 XHTML의 경우에는 xml:lang 속성만 사용한다.

두 번째 방법은 아래처럼 meta 요소의 http-equiv를 Content-Language로 지정해 주는 방법이 있다.

<!-- 보기 2: meta 요소의 Content-Language 선언. -->
<meta http-equiv="Content-Language" content="ko" />

여기서 문서에 사용된 언어와 의도된 독자의 사용 언어가 여럿일 경우 각 언어를 모두 나열해 줄 수도 있지만, 문서의 언어 해석을 위한 용도로는 적절치 않거니와 아직 이곳에 지정된 정보의 이용 상황은 극히 낮은 수준이다.

마지막으로, 언어 해석 정보는 문서와 함께 전달되는 HTTP header에서도 얻을 수 있는데, 이것도 대부분의 웹 브라우저들은 문서의 올바른 언어 해석을 위해서 이 곳의 정보를 참고하지는 않고 있다.

결과적으로, 지금까지는 첫 번째로 소개된 html 언어 속성을 이용한 방법이 HTML 문서의 언어 해석을 위해 가장 일관성 있고 효과적인 방법이라 할 수 있다.

추가 참고 문서: W3C I18N FAQ: Why use the language attribute?

Yahoo! User InterfaceBlog의 글에도 나와 있듯이, 웹 브라우져에서 특정 웹 페이지를 읽어드리는데 가장 많은 시간이 소요되는 부분은 html 문서를 생성해서 전달하는 과정보다도 그림 파일들이나 스크립트, 스타일쉬트들과 같은 기타 부분들을 읽어드리는 데에서 대부분의 시간이 소요되는 것으로 알려져 있다.
그렇다면, HTTP의 요청 횟수를 적당한 수준으로 줄일 수 있다면, 여기서 얻어지는 성능의 향상은 서버 튜닝이나 DB 최적화에 의해 얻어지는 성능의 향상보다 훨씬 손쉽게 더 큰 이득을 볼 수도 있다는 얘기가 된다.

하지만, HTTP의 요청 휫수를 줄이고자 무턱대고 멋드러진 웹 유저 인터페이스를 포기할 수도 없는 노릇.
그래서, 불필요한 HTTP 요청들을 즐이면서도 효과적이고 멋진 유저 인터페이스 환경을 제공하기 위한 노력으로서, 관련 자바스크립트나 CSS 파일들을 압축해서 한 데 묶고 캐쉬 기술을 사용하거나 메뉴의 Rollover 이미지들을 하나로 묶는(Pixy rollover) 등의 기법들이 사용되기도 한다.
물론, 여기서 더 나아가 사용자들이 취할 수 있는 조치로, 웹 페이지의 로딩 속도를 단축하기 위해 특정 웹 브라우져의 HTTP의 Pipelining 기능커놓는 작업도 할 수 있겠지만, 아직 모든 브라우져들이 이 기능을 지원하지도 않고, 또한 대부분의 서버들은 아직 pipeline된 요청들에 대해 편차가 심한 반응들을 보여주는 것으로 알려지고 있다.

따라서, 적당한 HTTP 요청 횟수를 판단하는 것은 웹 사이트별 사용 환경과 요구 사향에 따라 차이를 보일 수 밖에 없으며, 결국은 개발자 경험에 의한 판단이 중요하다고 말할 수 있다. 여기서 판단의 기초 자료로 사용될 수 있는 도구로 마침 BETA 딱지를 붙이고 새로 갱신되면서 추가된 Firebug의 Network Monitoring 기능을 빼놓을 수 없다.

FireBug의 Net 항목을 보여주는 창 그림

위에 보이는 창에서처럼 FireBug의 Net 항목을 선택하면, 현재 접속한 웹 페이지를 읽어드리는데 소요된 HTTP 요청들의 횟수와 크기, 시간을 파일별로 한 눈에 살펴볼 수가 있다. 여기서 얻은 자료는 유별나게 웹 페이지 로딩 속도를 지체하게 만드는 불필요한 병목 요인을 끄집어내서, 추가 최적화 작업이 필요한지를 판단하는 중요한 단서가 될 수 있을 것이다.

결국, 웹 개발자들에게 FireBug는 찰떡궁합이라는 얘긴가?