오늘(29일) 다음에서 열린 런치2.0 모임에서 다음의 석종훈 대표의 인사말에서 기존 웹과 모바일 서비스의 중요성과 이에 대한 다음의 준비에 대한 언급이 있었다. 이처럼 모바일 웹, 유.무선의 통합은 거스를 수 없는 대세임은 분명하다. 특히, 스마트 폰으로 대표되는 핸드폰은 기존의 오프라인과 온라인을 손쉽게 연결해주는 플랫폼이 될 것이다.  그렇다면 이러한 플랫폼하에서 오프라인과 온라인간의 고리는 무엇일까?

자동으로 인식되는 RFID 칩, 온라인 컨텐트에 대한 고정된 식별자로서 오프라인의 온라인인과 연결해 주는 퍼머 링크.

아마 현실세계에서 가장 온라인과의 긴밀한 연결고리는 QR 코드일 것이다.  내가 QR 코드를 처음으로 접한 것은 몇 년전 일본 파트너들의 명함에서 였다. 핸드폰 카메라를 통해 QR 코드를 읽으면 자동으로 명함내의 정보를 인식하여 핸드폰 주소록에 등록을 해주는 용도로 일본에서 널리 사용된다.

QR 코드는 일본 (주)덴소웨이브 에서 개발한 코드로서 기존의 바코드를 메트릭스 방식으로 겹쳐서 만든 2차원 바코드를 말한다.   현재 일본 산업계 표준(JIS-X-0510)이자 국제 표준(ISO/IEC18004)으로 하나의 바코드 심볼에 7,089개의 숫자와 4,296 알파뉴메릭 ,2,953 바이너리,1,817 간지나 중국 문자를 표현할 수 있으며 에러감지 코드(ECC, Error Correction Code)를 갖고 있어 신뢰성있는 처리가 가능하다.

이러한 QR코드는 실제 일본에서는 다양하고 광범위하게 사용되고 있으며 대부분의 핸드폰에 QR 코드의 디코더가 포함되어 있다.  다음은 일본에서 QR 코드의 활용 기사이다.

- 건물에 붙은  QR 코드

히로시마시 아키구에 건설중인 13층건물 맨션에 휴대 전화용 거대 QR코드(2 차원 바코드)가 출현했다. 위 아래로 크기가 약 11미터로 기네스 북에 기록신청중이다. 사업주인 현지 대기업 부동산 회사가 약 100만엔을 들여 설치했다.이 코드를 휴대 전화를 가져가면 모델 룸의 안내도등이 게재된 홈 페이지에 접속 할 수 있다.

이러한  QR 코드가 블러그에 들어왔다.

- 내 블러그의 QR 코드

카이와는 QR 코드의 생성 서비스를 제공하고 있다. 블러그의 URL을 입력하면 아래와 같은 QR 코드나 이에 대한 스크립트를 제공해 주고 있다.



이 QR 코드를 디코딩해주는 프로그램으로 돌리면 아래와 같이 해당 QR코드에http://wisefree.tistory.com 라는 URL 정보가 들어 있다는 것을 알 수 있다.



















위의 QR디코딩 프로그램은 오픈 소스 QR  코드용 자바 라이브러리로 작성된 것이다. 다음은 이용가능한 오픈 소스들이다. 실제 라이브러리를 이용하면 QR코드의 인코딩과 디코딩을 손쉽게 할 수 있다. 특히, 에러 검증이 자체에서 가능하기 때문에 신뢰도도 높다.

오픈소스 QR 코드 라이브러리 - http://qrcode.sourceforge.jp/
Zxing - http://code.google.com/p/zxing/

현재 웹 세계에서 기존 URL 에 보다 많은 시멘틱을 부여하고 이 정보를 바탕으로 보다 자동화된 웹을 만들려는 노력들을 많이 하고 있다. 이러한 노력만큼이나 오프라인의 객체를 온라인화 하는 것은 아주 중요하다. 가령, QR 코드에 실행(표현)가능한  프로그램을 올리고 이를 핸드폰으로 인식하여 수행할 수 있다면 오프라인 객체에 보다 많은 지능을 부여할 수 있지 않을까!! 이런거 한번 해 보면 좋겠다...명함의 QR 코드에 페이스북과 플리커 등의 정보를 자동으로 매쉬업되어 자신을 소개하면 재미나지 않을까...!!

 
초기 SaaS는 CRM이나 웹 오피스 그리고 그룹웨어 등 기존 데스크탑 기반의 애플리케이션을 웹 서비스로 제공하고 사용한 만큼 비용을( Pay as you go ) 지불하는 모델을 의미했다. 최근 들어, SaaS는 애플리케이션의 범위를 넘어 그 영역을 확대하고 있다. 특히, 웹 애플리케이션을 손쉽게 개발, 테스팅, 배포, 관리하는 분야를 서비스하는 분야를 비롯하여 컴퓨팅 리소스와 데이타베이스, 그리고 파일 시스템 등 서비스의 인프라 자체를 서비스하는 분야가 확산되고 있는 실정이다.

이러한 추세를 반영하여 SaaS를 다시 3계층으로 분류해 보았다. SaaS는 크게 애플리케이션 서비스, 플랫폼 서비스로 구분하고 , 다시 플랫폼 서비스는 개발 지향플랫폼 서비스와 인프라 서비스로 분류해 보았다. 특히, 개발 플랫폼 서비스의 경우 구글 앱 엔진과 번지 커넥트 처럼모든 개발 환경을 종합적으로 제공하는  접근 방법과  페이스북의 F8,  세일즈포스의  앱익스체인지처럼 서비스의 통합 플랫폼을 지향하는 것으로 구분해 볼 수 있다.


PaaS의 서비스 스택

웹을 플랫폼으로 서비스를 제공하는 SaaS의 특성상  실제 SaaS서비스를 개발,운영하는 데 에는 많은 비용이 발생하다. 이러한 문제를 해결하고 웹 플랫폼 자체에서 직접 서비스를 개발,운영하는 PaaS는 일반적으로 다음과 같은 서비스 스택을 지향한다.


기존의 손쉽게 설치하고 운영할 수 있어 널리 사용되고 있는 LAMP ( Linux - Apache - MySQL - PHP ) 환경과 스토리지와 서비스를 위한 네트웍 밴드위스 등 컴퓨팅 자원을 서비스화 하여 제공하고 있다.

구글 앱 엔진

PaaS 중에서 구글앱 엔진의 서비스 스택은  다음과 같다. 구글의 대용량 인프라인 빅테이블로 구성된 스토리지 중 500MB와 서비스를 위한 네트웍 밴드위스를 제공한다. 개발 환경으로는  Physon 런타임과 웹 응용 서버 그리고 SDK를 제공하여 각종 관리 환경과 Deplay환경을 제공하고 있다.

개인적으로 토이 프로그램을 작성하여 테스트 하면서 기존의  LAMP보다는 훨씬 편하고 손쉽게 서비스를 개발하여 Deplay할 수 있었다. 특히, 내부 웹 애플리케이션 서버도 중앙의 브로커에 RequestHandler를 개발하여 이를 등록하면 자동으로 처리되는 Front Controller 패턴으로 되어 있어 구조를 이해하기 무척 쉬웠다. 구글 웹 엔진과 동일한 패러다임의 서비스로는 번지 커넥트가 있다.


구글 웹 엔진과 달리 페이스북 F8은 웹 개발 종합 플랫폼을 제공한다기 보다 페이스북의 정보를 활용할 수 있는 API 및 질의어를 제공하고 이렇게 개발된 외부 서비스를 들을 페이브북에 통합할 수 있는 구조를 제공하고 있다. 세일즈포스의 앱 익스체인지도 페이스북 F8과 동일한 구조이다.

새로운 것이 나타나서 일반적인 것이 되기까지 많은 장벽과 과정이 필요하다. 지금은 흔하디 흔한 전화지만 전화도 최초 발명가로 알려진 벨이 고안한 이후 일반화 될 때 까지 생산화 단계를 거쳤다. 물론 이 과정에서 벨은 큰 돈을 벌지는 못했다고 알려졌지만...

XTech에서 만난 Simon Wardley는 이 과정을 다음과 같이 정리했다. 새로운 것을 발견하거나 발명한 후 제품화(Commoditisation) 과정을 거쳐 일반화된다.

발명가가 자신의 특허를 제품으로 양산하는 게 쉬운 일일까? 가장 큰 문제는 당연히 제품화를 할 만한 자금과 인프라가 없다는 것이다.  일반 제품 뿐만 아니라 새로운 인터넷 서비스의 창업자도 발명가와 같은 문제에 빠진다. 개발하여 서비스를 운영할 자금과 인력 등 인프라가 없다는 것이다.

온라인 서비스 발명가들에게 이러한 인프라를 가능하게 해주는 것이 바로  PaaS(Plaform As A Service)이다. 구글의 앱스 엔진이나 번지 커넥트는 직접 온라인 서비스를 개발에서 배포,관리까지 가능한 플랫폼을 제공하며 페이스북이나 Salesforce.com은 개발된 온라인서비스를 통합하여 상품화할 수 있는 플랫폼을 제공한다. 이 들 뿐만 아니라  MS의 오피스 라이브도 플랫폼 서비스를 제공하고 있고 어도비도 할 것으로 예상한다. 이들을 이용하면 능력만 된다면 글로벌 사업도 가능하다...

마이크로소프트가 ODF/PDF/XPS 포맷을 오피스 2007의 기본 포맷중의 하나로 지원한다고 발표했다.( 참고로 XPS는 XML Paper Specification을 말하는 데 MS에서 PDF를 겨냥해서 만든 포맷이다 ).

Ms Office 2007의 Service Pack 2에서 지원하며 PDF,XPS의 플러그인의 경우 애드온으로 다운로드 받아 설치해야 한다. OpenXML 포맷이 ISO 표준화으로 확정된 이후 오피스 시장에 대한 MS의 발빠른 움직임이 더욱 빨라 진듯한다.

이미 아파치의 아파치 포이 라이브러리오픈소스에 OLE 객체와 OOXML을 포함한 MS 오피스 문서를 손쉽게 할 수 있는 코드를 제공했으며 , OASIS 등 문서 표준화 활동에 더욱 박차를 가하고 있는 것으로 보인다.

더불어 Open Office도 OpenXML을 지원하고 상황을 보면 이제 본격적으로 바이너리 포맷과 특정 오피스 제품에서 벗어나 새로운 오피스 시장이 만들어지기 시작했다고 보는 것도 무리가 아닌 것 같다.

현재 씽크프리의 경우 OpenXML은 이미 지원하고 있고 ODF 를 지원할 예정이다. 참으로 할일도 많고 어려운 시장임은 분명하다!

2008/05/01 - [Hot Issues] - 마이크로소프트 새로운 행보 - 라이브 메쉬
2008/04/23 - [Office2.0] - 마이크로소프트의 알바니 비지니스 모델
2008/03/30 - [Office2.0] - ODF,OOXML이 가져올 새로운 기회들
2008/03/28 - [Office2.0] - 오피스 문서 표준화를 둘러싼 잔상

직원이 보내 온 메일 중에서... ㅎㅎ
그 간 개인적으로 회식때 내 앞자리에 앉았던 직원들 , 미안합니다.

오늘 매일 아침 받아 보는 메일에  이외수 시인의 "하악하악"중에서 "운이 꼬일 때" 이란 시귀가 실렸다.   운이 꼬일 때는 하는 일 마다 안되는 법, 여기서 헤어나기 위해서는 사람들에게 무조건 베풀면 된다는 것이다.

이 방법 보다 좋은 방법은 운이 꼬이기 전에 미리 미리 베풀면서 사는 것이다. 전적으로 동감.

간혹 나에 대해 사람들이 어떻게 평가할 까? 라고 반문해 본다. 항상 결론은 동전의 양면처럼 긍정적인 평가와 부정적인 평가가 공존하지 않을 까 싶다. 과거 창업 시절 , 다른 회사와의 합병을 통해 실망한 직원들이 그럴 것이고 사업을 하며 본의아니게 피해를 입은 사람들은 서운한 감정을 부정적인 평가로 표출할 것이다.

창업 초창기 , 제품을 개발한 후 사업 파트너를 찾아 동분서주할 때 과감하게 나를 보고 사업 파트너 계약을 해준 회사의 사장님이 계셨다. 너무도 감사드렸고 좋은 관계에서 사업을 하기 위해 여러 노력을 했다.

시간이 흐르고  안타깝게도 그 분의 회사는 사정이 어려워졌다. 당시 계약에 의해 파트너사로 부터 대금을 받아야 하는 상황이고 나의 회사 역시 자리를 잡아 가는 과정에 넉넉한 형편은 아니었다. 내부 직원들과 주변 사람들은 이구동성으로 그 회사가 문닫으면 정말 돈을 받을 수 없다라는 이야기를 해 주었다. 결국 , 절차를 거쳐 대금을 받았고 그 분의 회사는 정리되었다.

그 뒤로 , 나는 그 분을 볼 수 없었다.

잘했는지 , 잘못했는지는 모르겠다.  하지만 지금도 무척 가슴이 아프고 후회된다.

베풀며 살아 가는 여유를 찾는 삶을 위해!

오늘보니  FireFox3 RC1이 공개되었네요. 치열하게 펼쳐질 브라우져들의 경쟁이 기대됩니다. 그리고 이 포스팅을 마지막으로 XTech 2008의 정리를 마칩니다.

5. XSLT/XPath, SVG, ARIA

- Cient-side XSLT/Xpath
 
오페라는  XML 문서를 클라이언트측 스크립트로 처리하기 위해 document()를 제공하고 있다. 웹킷도 오페라에 동참 한 상태이고  IE도 같은 목적을 위해 node-set() 을 지원하고 있다.

현재 주요한 브라우져 엔진들내에는 XSLT/XPath를 포함하고 있다. - XSLTProcessor, DOMParser|loadXML , XMLSerializer.

- SVG

• 오페라에서는 강력하게 지원중이고 , 모질라는 양호하게 지원중이다.
• 웹킷의 경우 SVG 기능을 크게 향상시키고 있다. 최근에는  SMIL기반의 SVG 애니메이션까지도 지원하고 있다.
• IE7과 마찬가지로 IE8에서는 지원하지 않을 예정이다. 구글이 IE용 SVG를 만든다는 이야기가 있었는데 어떻게 되가는지..

자바 개발자들은 바틱(Batic) 라이브러리를 사용하면 SVG 를 손쉽게 다눌 수 있다. 더불어 다양한 포맷으로 출력 변환을 원할 경우 아파치 FOP (Formatting Objects Processor)를 사용하면 편리하다. 참고로 OLE 객체와 OOXML을 포함한 MS 오피스 문서를 손쉽게 처리하려면 아파치 포이 라이브러리를,  ODF 문서를 처리할 경우 ODFDOM 라이브러리를 활용하면 된다. 요즘은 정말 밑바닥 부터 개발하는 것은 어리석은 일인 것 같다. GPL/LGPL 등으로 배포되는 멋진 작품이 많기 때문이다.


6. 기타 다른 변화들

-HTML5 registerProtocolHandler()
mailto: 에 대한 처리를 특정 웹 메일 애플리케이션이 수행하게 할 경우  registerProtocolHandler()를 사용한다. Firefox 3에 구현되어 있다(2008-04).

-JavaScript Getters 와 Setters
• 데이타 필드의 암호화(encapsulation)를 가능하게 함
• Mozilla, Safari 3, Opera 9.5 betas 지원
• IE8 은 지원하지 않음

-HTML5 <video> 엘리먼트
• 비디오의 로딩과 플레이를 위한 스크립트 API
• 태그 예 : <videosrc="foo.ogg" id="foo_video">

- <video> 태그 지원 브라우져
• Safari 3.1 and WebKit nightlies
• Mozilla/Firefox trunk build + patch for bug 382267
• Opera experimental build
• IE8은 아직 지원 없음

- IE8 <meta> versioning switch
• <meta http-equiv="X-UA-Compatible" content="IE=7"/>
• IE8에서 사용할 렌더링 엔진을 지정할 수 있게 해주는 태그
• 특별히 명시하지 않으면  IE8을 기본으로 사용한다. IE8과 이전 버전의 차이가 크기 때문에  IE 렌더링 호환성을 위해서는 필요해 보인다.

- Acid2 와 IE8
• IE8은 Acid2 테스트를 통과함 
• Safari, Mozilla, Opera는 이미 오래전에 통과되었음^-^

- 브라우져에서 Acid3 지원 현황
• WebKit nightly: 100/100
• Opera dev build: 100/100
• Opera 9.5: 78/100
• Safari 3.1: 75/100
• Firefox 3/Minefield: 71/100
• IE8: 18/100

7. WebKit CSS의 멋진 기능들 , 아이폰에서 정말 멋집니니다^-^.
WebKit에서 제안한 CSS의 추가 기능들을 보면 HTML의 표준을 유지하면서 멋진 스타일과 효과를 제공할 수 있는 혁신적인 기능이 포함되어 있습니다.

• Reflections: -webkit-box-reflect
• Alpha masks: -webkit-mask
• Canvas images: -webkit-canvas
• Gradients: -webkit-gradient
• Transitions: -webkit-transition
• Transforms: -webkit-transform
   
Web on the Move, 플랫폼으로서의 웹이 모바일과 기존 데스크탑, 그리고 기타 플랫폼을 하나로 아우르는 플랫폼으로 자리잡아 가면서 웹 브라우져 또한 보다 다양한 기능과 패러다임으로 발전하고 있습니다. 웹 브라우져는 기존의 단순히 HTML을 렌더링하기 위한 응용 프로그램이 아니라 HTML5,ARIA,CSS, XML 기술 등 다양한 클라이언트 개발 기술을 사용하여 클라인트측의 웹을 개발할 수 있는 독립적이자 스마트한 플랫폼으로 진화하고 있는 것이 지금의 현실로 보입니다.  참! 할수 있는 게 너무 많아지는 뭘 해야 할 지 고민되는 세상입니다.^-^

이번 XTech 2008 컨퍼런스중 개인적으로 가장 도움이 되는 발표중의 하나였다. 한 분야의 흐름과 동향을 정리하는 만으로도 많은 노력이 필요하기 때문이다. 특히, 웹 브라우져의 경우 FireFox와 IE, 그리고 아이폰의 확산과 더불어 시장을 넓혀가고 있는 웹킷 계열, 그리고 마지막으로 숨은 강자 오페라 등이 치열하게 표준과 업그레이드 전쟁을 벌이고 있다. 이처럼 웹 브라우져 분야의 최신 동향을 정리하는 데 많은 시간이 걸린다.

운좋게도  W3C 모바일 분야에서 일하고 있는 Michael Smith가 모바일 플랫폼을 중심으로 웹 브라우져의 현황에 대한 정리를 해 주었다. 관심갖는 분들이 많을 것 같아 좀 자세히 정리해 본다.

1. 모바일 브라우져 현황

[  오페라  - Presto 렌더링 계열 ]

-오페라 미니4 (2007/11) / 오페라 9.5와 동일한  엔진
       : 향상된 자바 스크립트 엔진 지원
       : 프록시 모델(풀브라우징 아님)
-오페라 미니 / 안드로이드 포팅 버전
        : J2SE로 구현한  J2ME 구현체인  MicroEmulator로 포팅함
        : J2ME/MIDP Call을 안드로이드 Call로 변환
        : 데모로 확인해 보세요 -> 오페라 미니 데모

[  모질라  - Getko 렌더링 계열]

-모질라 Fennec
       : 2008-04 pre alpha 빌드 릴리이즈
       : 2008-08 첫번째 알파 버전 릴리이즈
       : 현재 플랫폼으로는 리눅스(ARM,X86)
       : 노키아의 Miamo를 위한 모질라 기반의 브라우져인 microB보다 6배 빠름
       : 향후 윈도우 모바일도 지원할 계획임
-  SkyFire
       : 모질라를 기반으로 하여 오페라 미니같은 프록시 아키텍쳐
       : 2008년 1월 발표 이후 큰 변화 없는 상태임

[  웹킷 렌더링 엔진 계열 ]

-아이폰 사파리(웹킷)
      :풀브라우징
      :데스트탑 사파리와 동일한 웹킷 엔진  사용
    -안드로이드 + 웹킷(2007.11)
       : 안드로이드의 렌더링 엔진은 웹킷
    - Trolltech의 크로스플랫폼 응용 개발 프레임웍인 Qt4.4 + 웹킷
      :트롤텍은 노키아가 M&A 했음
    - 노키아 S60 웹킷 포팅
       : 2007-08 이후 공식적으로 언급된 바는 없음
       : 들리는 루머로는 사파리3.1을 포팅하고 있다고 함
    -윈도우 모바일 , 웹킷 포팅 관련
       : Iris browser , Wake3

풀부라우징, 아이폰의 확산, 안드로이드 등을 고려할 때 웹 부라우징의 렌더링 엔진으로는 웹킷이 가장 유력한 선두주자로 판단된다. 현재 웹킷의 경우 CSS를 강력히 확장하고 있는 것으로 알려져 있다. 물론 HTML5의 지원과 더불어..
   
2. CSS/DOM

웹 프로그래밍을 할 때 CSS,DOM 프로그래밍은 가장 중요한 부분이자 다중 브라우져 지원을 위해서는 고생을 많이 하는 부분이다. 왜냐하면 브라우져마다 지원하는 CSS 스펙과 DOM 관련 메소드가 다르기 때문이다. 몇가지 주요한 차이점은 다음과 같다.

- 네이티브 자바 스크립트 getElementsByClassName 메소드
      현재 IE만 네이티브 지원이 안되고 Mozilla, WebKit/Safari 3+, Opera 9.5에서는 네이      티브로 지원을 하고 있다. 또한 HTML5에 포함되어 있다.
 
- DOM의 특정 엘리먼트를 추출해 오는 CSS3 Seleccors 지원 현황
       Opera 9.5 and Safari 3.1/WebKit은 43개의 css3.info 테스트를 통과됨
       Mozilla/Minefield는 43개 중에 36개가 통과됨
       IE8은 43개 중에 14개만 통과됨

- DOM의 특정 엘리먼트를 추출해 오는 CSS3 Seleccors API 지원 현황
      querySelector/querySelectorAll 메소드는 현재 웹킷과  IE8에서 지원하고 있음
     
3. 웹 개발 툴 지원 현황

- Firebug for Mozilla : 가장 강력한 개발 환경을 제공하고 있으며 다른 툴들의  교본이다.
- new tools in IE8 : DOM/CSS inspector , script debugger
- WebKit Web Inspector 와 Drosera(script debugger)
- Opera Dragonfly : DOM/CSS inspector , script debugger , Remote Debugging

4. Cross-doc/site 과 로컬 스토리지

- Cross Document Messaging
  HTML5표준에서 postMessage 메소드 정의
  현재 IE8,Opera,WebKit,Mozilla에 구현되어 있다.
  Cross-site 요청시 iframe내에서 기본적으로 사용한다.

- Cross-Site request
  W3C Access control Spec : 모질라에는 구현되어 있으나  FF3에는 모호한 부분이            있어 빠져 있음
  MS IE8의  XDR(XDomainRequest)
  JSON request : 현재 브라우져 업체들은 관심을 갖고 있지 않음

- 오프라인 웹 어플리케이션
  현재  HTML5 Draft recommendation , 2008년 5월  16일자
  ApplicationCacheAPI
  각 응용 프로그램은 저장을 위한 캐쉬와 데이타 추출을 위한 manifest를 갖는다.
  현재 Mozilla/Firefox 3에 구현되어 있고 웹 킷에서는 개발중에 있다.

- HTML5 Client-Side Persistent storage(name/value pair)
  Storageinterface, sessionStorage  와 localStorage 속성
  현재 Mozilla와 IE8에서  지원하고 웹 킷에서는 개발중이다.

- Client-Side SQL API 
  HTML5내에 구글 기어와 유사한 스펙이 정의되어 있음
  웹킷에 구현되어 있음 - 데모 : http://webkit.org/misc/DatabaseExample.html
  ( 사파리로 테스트 해야 함 ^-^ )


앗! 시간이 벌써 많이 지났네요. 벌써 주말 오후입니다. 눈치가 보여서.. 나머지 내용은 다음 포스팅에서..

컨퍼런스를 마치고 떠나는 날 , 더블린에는 오전부터 비가 내렸다. 비를 맞으며 더블린 공항에서 프랑크푸르트 공항으로 가는 비행기에 올랐다.  비행기에서 제공하는 아일랜드 일간지에서 아일랜드를 자동차로 여행할 경우 추천 코스가 있어 열심히 사진을 찍었다.


총 5개의 자동차 여행 코스를 소개하고 있다. 그중 첫번째는 아일랜드의 서쪽인 골웨이 중심의 코스. 골웨어는 유명한 절벽이 있는 데 .. 아 가보고 싶다...

두번째 추천 코스 , 딩글 페닌슐라
세번째 추천코스, 밴트리에서 킬라니까지

네번째 추천코스 ,

다섯번째 추천코스 ,

그런데 중요한 점이 아일랜드는 운전할 때 주의가 필요할 것 같다. 먼저 운전석이 오른쪽이고 도로고 무척 좁다. 2층 버스를 타고 다닐때 항상 사고가 나는 줄 알고 깜짝 놀랐다. 어쩌면 그리도 앞에 차 뒤에 붙이는 지... 그래도 기회가 나면 렌트해서 위의 코스를 돌아 봤으면 좋겠다.

더블린 시내는 아주 넓은 지역은 아니지만 곳곳에 볼만한 것들이 많이 있다. 아무래도 짧은 시간에 짬짬히 돌아보기 위해서는 전략이 필요한 것 같다.

-공식 추천 코스들
더블린 여행 안내소 등에서 손쉽게 구할 수 있는 지도를 보면 아래와 같이 23개의 코스를 안내하고 있다.


이들 23개 코스를 지도로 보면 더블린을 동서로 가로지르면 전체를 돌아 볼 수 있다. 아래 두장의 사진을 왼쪽에서 오른쪽으로 이어서 보면 된다.




-더블린 패스
앞서 소개한 23곳의 경우 무료인 경우도 있으나 유료인 경우가 많다. 이 때, 매번 입장료를 지불하는 것보다 더블린 패스를 구매하면 저렴하게 입장할 수 있다. 인터넷으로 구매하면 할인을 받을 수 있으며 구매후 아일랜드 공항내에 위치한 여행 안내소나 시내(7번 근처)에 위치한 여행 안내소에서 받으면 된다.

-더블린 버스 패스 구매
위에 소개한 곳을 걸어서 돌아다니려면 많은 시간을 투자해야 하고 거리도 잘알아야 한다. 그러나 다행히도 더블린 버스 패스를 1일권, 또는 3일권 등 구매해서 언제고 원하는 곳에서 타고 내릴 수 있다. 사무실은 오코넬 거리에 위치하고 있으며 버스 패스는 더블린 여행 안내소를 비롯해 더블린 버스 티켓을 파는 곳에서 구매할 수 있다.


-더블린 근교 여행
더블린 버스에는 더블린 시내를 운행하는 무려 패스외에 더블린을 중심으로 다양한 곳을 투어할 수 있는 프로그램이 존재한다. 가장 가까운 곳으로 2시간 가량 소요되는 코스로 더블린의 남과 북 해변을 돌아보는 투어 프로그램이 있다.

다음은 더블린에서 출발하여 북쪽의 말라하이드성까지 돌아보는 버스 투어 코스이다.

아래 코스는 더블린에서 남쪽의 파워스코트 정원까지 다녀오는 코스이다.


여유로운 일정을 갖고 있다면 시간을 갖고 천천히 이들 코스를 돌아보면 즐거웠을 것 같다. 바쁜 일정을 쪼개 보려니 역시 한계가 있는 것 같다. 언제 다시 기회가 온다면 더블린 시내는 도보로 , 외곽은 차를 렌트하여 이용하면 좋을 것 같다.

다시 아일랜드를 찾을 기회가 올 수 있을지...^-^