일관성 있고 최적화된 Ajax 응용 프로그램
브라우저, 시스템, 사용자에 내재하는 차이점을 고려하자
브라우저, 컴퓨터 시스템, Ajax 응용 사용자가 모두 똑같다면 개발자가 얼마나 편할까요? 안타깝게도 현실은 그렇지 못합니다. 개발자는 다양한 브라우저, 컴퓨터 시스템, 사용자 환경에서 일관성 있게 동작하는 응용 프로그램을 구현하느라 온갖 골칫거리에 시달립니다. 사용자가 Ajax 프로그램을 한 브라우저 유형에서 다른 브라우저 유형으로 옮기면 (특히 웹 서비스 포털로 옮기면) 각 브라우저 본래의 제약으로 인해 프로그램이 똑같이 돌아간다는 보장이 없습니다. 이 기사에서 필자인 Judith Myerson은 브라우저, 시스템, 사용자에 내재하는 제약을 간략히 설명합니다. 또한 프로그램을 짜면서 주의할 함정, 브라우저 차이를 최적화하는 방법도 소개합니다.
시작하면서
다양한 브라우저, 컴퓨터 시스템, 사용자 환경에서 일관성 있게 동작하는 Ajax 프로그램을 구현하려는 개발자는 다양한 난관에 부딪힌다. 사용자와 개발자가 여러 브라우저를 차별없이 사용하는 경우가 흔하기 때문이다. 사용자가 프로그램을 한 브라우저 유형에서 다른 브라우저 유형으로 옮기는 경우도 흔하므로 Ajax 개발자는 다양한 시나리오를 고려해야만 한다. 하지만 브라우저마다 고유한 제약이 존재하는 탓에 모든 브라우저에서 완벽하게 돌아가는 프로그램을 내놓기는 매우 어렵다. 브라우저에 내재하는 제약은 Ajax 프로그램이 웹 페이지를 표시하는 방식에 (심지어 Ajax 프로그램이 동작하는 방식에) 영향을 미치기도 한다.
많이 사용하는 브라우저는 마이크로소프트 인터넷 익스플로러(Microsoft® Internet Explorer®), 오페라(Opera), 파이어폭스(Firefox), 컨쿼러(Konquerer)다. 리눅스에서만 돌아가는 컨쿼러를 제외한 나머지는 모두 윈도, 리눅스, 애플 맥 OS X에서 돌아간다. 현재 인기 있는 브라우저가 여러 개이므로, 개발자로서 인기 브라우저를 비교하여 차이점을 익혀두면 유용하다. 이 기사에서는 먼저 컴퓨터 시스템의 (메모리, 디스크 크기, USB 포트 수 등의) 하드웨어 차이점, (글꼴 가용성, HTML 확장 기능, 폼 요소 같은) 소프트웨어 제약을 살펴본다. 다음으로 브라우저 성능 문제를 고려한다. 마지막으로, 사용자가 Ajax 프로그램을 특정 브라우저 유형에서 다른 브라우저 유형으로 옮기거나 웹 서비스 포털로 옮길 가능성을 대비하여 브라우저 차이를 최적화하는 해결책 몇 가지를 제안한다. 이 과정에서 Ajax 개발자가 흔히 빠지는 함정(또한 피하는 방법)을 소개한다.
컴퓨터 기종은 많고 시간은 없다!
많은 개발자가 PC에서 웹 페이지를 Ajax 포털로 변환하지만, 매킨토시 사용자도 같은 변환을 수행한다. PC와 매킨토시에서 같은 브라우저 최신판으로 웹 페이지를 열어보면 두 컴퓨터에서 페이지가 다르게 보인다는 사실을 알아챌 것이다. 게다가 같은 기종이라도 모델이 다르면 화면 크기와 캔버스 크기가 달라지기도 한다. 어떤 매킨토시 모델은 PC 모델과 똑같이 설정해도 캔버스 크기와 해상도가 크게 차이난다. 컴퓨터 기종과 모델에 내재한 차이점은 단순히 글꼴 크기나 외양만이 아니라 다른 설정에도 영향을 미친다.
다양한 브라우저, 운영체제, 컴퓨터 기종에서 사용자 인터페이스가 적절히 표시되고 동작이 일관성 있는 Ajax 응용 프로그램을 만들려면 개발자가 고려할 사항이 아주 많다. 응용 프로그램을 최적화하여 성능과 사용 편의성을 높이려면 이 기사에서 제공하는 팁을 명심한다.
Ajax 응용 프로그램을 구현하는 개발자는 페이지 폭/높이와 프로그램이 화면에 표시되는 모양새를 고려해야 한다. 사용자 환경에 따라 800x600, 1024x768 등 해상도가 크게 달라지기 때문이다. 해상도가 높은 화면에 프로그램 크기를 맞추면 해상도가 낮은 화면을 사용하는 사용자는 스크롤하느라 불편함을 겪는다. 스크롤이 불편하다면 사용자는 사이트를 떠난다.
메모리와 디스크 공간
복잡한 계산을 수행하려는 데 메모리가 부족하다면 컴퓨터는 디스크 공간을 확보하여 계산을 진행한다. 계산 과정을 완료하기 전에 메모리나 디스크가 바닥나면 사용자는 메모리나 디스크 공간이 부족하다는 오류 메시지를 받는다.
Ajax 프로그램에서 이런 오류 유형이 발생하는 근본 원인은 프로그램이 메모리, 디스크 공간, 기타 시스템 자원을 제대로 운용하지 못했기 때문이다. 이 때 개발자가 취할 대응책은 두 가지다. 하나는 시스템 자원에 걸리는 부하를 경감하는 방법이고, 다른 하나는 프로그램을 고치는 방법이다. 시스템 자원에 걸리는 부하를 경감하려면 예를 들어, 필요하지 않는 파일을 삭제하거나 큰 Ajax 프로그램을 외부 USB 디스크 드라이버로 옮긴 후 실행한다. 프로그램을 고치려면 예를 들어, 여러 모듈로 나눈 후 각 모듈 단위로 예외를 처리하여 문제 원인을 찾는다.
USB 포트
컴퓨터에 USB 포트가 많을수록 동시에 사용이 가능한 USB 디바이스도 많아진다. 일반적으로 적어도 두 개는 있어야 적당하다. 그래야 (Y 케이블이 있는) 휴대용 120MB USB 외부 디스크 드라이브처럼 강력한 USB 디바이스를 연결한다. 이러한 디바이스는 내부 디스크 공간이 부족할 때 Ajax 프로그램을 저장하고 실행하기에 유용하다. 컴퓨터가 제공하는 USB 포트로 부족하다면 USB 허브를 사용하는 방법도 있다. 허브는 Y 케이블이 따라오므로 두 커넥트를 USB 포트에 연결하면 된다.
참고: 어댑터가 없는 허브에 커다란 외부 하드 드라이브를 장착하면 드라이브도 웹 서비스 포털도 동작하지 않는다. 외부 드라이브가 필요한 전력을 허브가 제공하지 못하기 때문이다. 제대로 돌아가려면 적절한 전력을 제공하는 허브와 어댑터가 필요하다.
글꼴
글꼴 문제 두 가지를 살펴보자. 하나는 가용성이고 다른 하나는 호환성이다.
글꼴 가용성
윈도에서 돌아가는 IE가 표시하는 텍스트는 매킨토시에서 돌아가는 IE나 내비게이터(Navigator)가 표시하는 텍스트와 달라 보인다. 구체적으로 말하자면, 글꼴 크기를 똑같이 지정해도 매킨토시 글자가 PC 글자보다 작아 보인다. 그러므로 개발자는 일반적인 방법으로 텍스트 크기를 조정할 때 PC와 매킨토시가 실제로 사용하는 크기 중 최대 값을 알아야 한다. 특정 PC에서 사용자가 선호하는 글꼴이 다른 PC 모델이나 매킨토시에 없는 경우도 있다. 시스템에 원하는 글꼴이 없다면 시스템 기본 글꼴을 사용한다. (PC 윈도에서 글꼴 가용성을 확인하려면 시작->제어판->글꼴 아이콘을 선택한다.)
글꼴 호환성
많은 개발자가 모든 브라우저와 플랫폼에서 텍스트 크기를 동일하게 만드느라 골치를 앓는다. 그런데 브라우저마다 사용자가 글꼴 크기를 조정하는 방법은 다양하다. 예를 들어 윈도에서 IE는 가장 크게(Largest), 크게(Larger), 보통(Medium), 작게(Smaller), 가장 작게(Smallest)라는 다섯 가지 크기를 제공한다. 모질라 파이어폭스는 글꼴 크기를 확대하거나, 축소하거나, 재설정하는 메뉴를 제공한다. 반면, 오페라 사용자는 목록에서 백분율을 선택하여 글꼴 크기를 조정한다. 그러므로 응용 프로그램이 사용하는 글꼴 크기가 변했을 때 서로 같은 결과를 보여주는 브라우저는 없다.
심지어 글꼴 크기를 똑같이 보통(medium)이라 설정해도 브라우저마다 다른 결과를 내놓는다. 다양한 브라우저에서 텍스트 크기를 일관적으로 유지하는 방법 중 하나가 CSS(Cascading Style Sheet)다. CSS에서 글꼴 크기를 정의할 때 백분율이나 em을 사용하면 된다. 정말로 다른 방법이 없다면 마지막 수단으로 픽셀 크기를 사용한다. 단, 픽셀 크기를 사용하면 화면 해상도에 따라 텍스트 크기가 달라진다.
HTML 표준
Ajax 응용 프로그램은 자바스크립트와 XML 외에도 HTML, DHTML, DOM(Document Object Model)을 사용한다. HTML로는 웹 폼을 만들고, DHTML로는 HTML 마크업으로 폼을 동적 갱신한다. DOM은 서버가 반환하는 XML이나 HTML의 구조를 분석하고 참조한다. 그런데 모두가 똑같은 표준과 똑같은 폼 요소를 사용하지 않으므로 문제가 생긴다.
최신 HTML 버전
최신 HTML 표준은 최신 브라우저에서 더욱 잘 표시되므로 대다수 사용자가 자신의 브라우저를 최신 버전으로 판올림한다. 하지만 일부 브라우저는 최신 버전이라도 새 표준을 완벽하게 지원하지 못한다. 실생활에서 표준이 브라우저 개발 속력을 앞서가기 때문이다. 최신 HTML 표준을 100% 지원하는 브라우저는 아직 없지만, 브라우저마다 표준을 지원하는 정도에는 차이가 있다.
최신 HTML 태그를 지원하지 못하는 브라우저도 있으므로, 개발자가 최신 HTML 태그를 사용한다면 브라우저가 페이지를 인식하지 못하는 사태도 발생한다. 브라우저가 페이지 일부를 인식하지 못하면 페이지는 제대로 표시되지 않는다. 예를 들어, IE에서 레이어를 겹쳐 사용했다면 다른 IE 버전이나 다른 브라우저 유형이 페이지를 올바로 인식하지 못할지도 모른다. 오페라나 파이어폭스는 겹쳐진 레이어를 일부라도 표시할지 모르겠지만 IE는 아니다. 그러므로 프로그램을 출시하기 전에 마이크로소프트 익스프레션 웹(Microsoft Expression® Web) 같은 웹 개발 소프트웨어를 이용하여 여러 브라우저 환경에서 페이지를 미리 확인하는 편이 바람직하다.
폼 요소
브라우저와 HTML 버전에 따라 폼 요소는 크기와 간격과 모양새가 많이 달라진다. 구체적으로는 풀다운 메뉴, 텍스트 입력 필드, 기타 폼 요소가 차지하는 공간이 달라진다. 어떤 브라우저에서는 멋지게 보이던 폼 요소가 다른 브라우저에서 볼품없어 보이는 경우도 많다.
성능
프로그램을 출시하기 전에 몇 가지 성능 요소도 고려해야 한다. 예를 들면 브라우저 속력, XML 파일 크기, 추가 기능이 미치는 영향 등이다.
브라우저 속력
윈도 응용 프로그램이라면 오페라가 가장 빠르다고 생각한다. 속력 면에서는 파이어폭스와 IE가 비슷하지만, 표준이나 보안이나 기능 면에서는 파이어폭스가 낫다. 그래도 오페라만큼 빠르지는 않다. 리눅스 응용 프로그램이라면 KDE 환경에서 기본 페이지를 시작하고 표시하는 속력 면에서 컨쿼러가 가장 빠르다. 그러나 페이지에 스크립트나 이미지가 있다면 오페라가 더 빠르다. 파이어폭스도 전반적으로 우수하지만 스크립트 실행 속력, 캐시 처리 속력, 이미지가 있는 페이지 처리 속력 등이 오페라에 미치지 못한다. 맥 OS X에서는 오페라와 사파리(Safari) 둘 다 아주 빠르다. 사파리 2는 CSS를 시작하고 표시하는 속력이 빠른 반면, 오페라는 테이블과 스크립트와 이력을 표시하는 속력이 빠르다.
브라우저 속력은 오페라가 가장 빠르지만, 글꼴 크기를 조정하는 기능은 IE의 크기 메뉴나 파이어폭스의 Ctrl 옵션이 더 편리하다. 마이크로소프트 익스프레션 웹 설계 도구로 웹 페이지를 미리 살펴보려는 경우 오페라는 옵션으로 제공되지 않는다.
XML 파일 크기
크기가 아주 큰 텍스트 XML 파일은 꼭 필요한 경우에만 신중하게 사용한다. XML 파일이 크면 브라우저 응답 시간이 느려지고 심지어 네트워크도 느려진다. 텍스트 XML 파일 대신 이진 XML 파일을 사용하는 방법도 고려한다. (웹 서비스 취약성을 피하면서 Ajax 응용 프로그램 속력을 높이는 방법은 참고자료에서 제공하는 기사를 읽어본다.)
브라우저 추가 기능
팝업 차단기, 탭 관리자, UI 테마 등 브라우저에 추가하는 기능도 때때로 예상치 못한 방식으로 Ajax 프로그램에 영향을 미친다. 예를 들어, 팝업 차단기를 설치하면 새 브라우저 창이 열리지 않는다. 하지만 팝업 차단기가 브라우저 화면 일부를 사용하면서 프로그램을 가리기도 한다. 브라우저 화면 일부가 가려지는 바람에 Ajax 프로그램이 페이지를 의도대로 표시하지 못하는 경우도 생긴다.
developerWorks Ajax 참고자료 센터
Ajax 참고자료 센터에서는 Ajax 프로그래밍 모델에 관한 기사, 튜토리얼, 토론 포럼, 블로그, 위키, 행사, 뉴스 등 다양한 정보와 자료를 제공한다. 웬만한 자료는 다 있다.
열 가지 팁과 함정
다음은 최적화된 웹 페이지를 작성할 때 유용한 팁과 피할 함정이다. Ajax 프로그램을 사용하는 사용자에게도 마찬가지로 유용한 정보다.
개발자: 가능하면 HTML 확장 기능을 사용하지 말라. 최신 언어 기능은 주의 깊게 사용하라. 주요 브라우저가 최신 기능을 지원하지 않을지도 모른다.
개발자: 브라우저 최신 버전이 지원하는 HTML 기능으로 페이지를 제작하겠다고 서둘러 덤비지 말라.
개발자: 주요 브라우저마다 최신판 두 개에서 올바로 동작하도록 페이지를 설계하라.
개발자: 메모리, 디스크, 기타 시스템 자원에 걸리는 부하를 줄이라. 최대한 적게 사용하라.
개발자와 사용자: (필요하다면) Ajax 프로그램을 다시 시작하거나 (다른 방법이 없다면) 컴퓨터를 다시 시작해 Ajax 프로그램을 갱신하라.
개발자와 사용자: 사용하지 않는 파일이나 필요없는 파일은 주기적으로 삭제하라. 프로그램이 사용할 디스크 공간을 늘리라.
개발자와 사용자: 메모리를 늘리거나 120MB짜리 외장 하드 드라이브를 사용하라.
개발자: Ajax 포털용으로 웹 페이지를 설계할 때는 레이어 옵션을 단순화하라.
개발자: 문제를 디버깅하기 쉽도록 Ajax 프로그램을 모듈로 분리하라. 프로그램에 예외 처리 기능을 추가하라.
개발자: CSS를 사용하여 텍스트 크기 문제를 없애라. CSS에서는 글꼴 크기를 백분율이나 em으로 지정하라. 다른 방법이 없다면 마지막 수단으로 픽셀 크기를 사용하라.
결론
개발자, 테스터, 시스템 관리자, 잠재적인 사용자로 이루어진 팀에 의견을 구해도 좋겠다. 그러면 개발자가 Ajax 프로그램을 개발하고 웹 서비스 포털로 변환할 때 브라우저 차이로 발생하는 문제점을 최적화하기가 쉬워진다. Ajax 프로그램에서 브라우저가 미치는 영향을 최소로 줄이려면 프로그램을 개발하고 테스트하고 배포하는 과정에서 상당한 계획이 필요하다. 꼼꼼히 계획해야 프로그램 성능이 좋아지고 일관성이 높아진다.
출처: IBM닷컴
