오랫동안 Chrome 브라우저를 사용하고 있었고 모든 북마크가 Chrome에서 동기화되어 관리되고 있기에, iOS기기에서도 Safari 대신 Chrome을 써보려고 최근 몇달간 노력하고 있었다. 한편, 데스크탑에서 가볍게 브라우징 하는 용도로 Edge를 써봤더니 메모리 사용량도 적어 보이고 UI도 깔끔해 보여서 별 생각없이 아이패드에도 설치해서 사용해보았다. 그 결과, 아이패드에서 Chrome 브라우저를 사용할 때 불편했던 포인트 몇 개는 알 것 같다.
새 탭 열기
아이패드 Edge에서는 새 탭을 여튼 버튼의 위치가 항상 가장 오른쪽에 있어서 탭할 곳이 항상 일정하다. 마지막 탭 오른 쪽에 새 탭 버튼을 배치하는 아이패드 Chrome에 비해서 조금 더 편리한 것 같다.
데스크탑에서는 새 탭을 열 때는 브라우저에 관계 없이이 키보드나 마우스로 하니까 문제가 없는데, 터치 UI에서 비교적 자주 해야하는 일을 스크린의 안쪽에서, 그리고 매번 다른 장소에서 하도록 하는 것이 상당히 불편한 UI인 것 같다.
한편, 아이패드 Edge는 키보드 숏컷(Cmd+T)을 아직 지원하지 않는 것 같다.
새 탭에서 검색 또는 URL 입력
아이패드 Chrome의 중앙에 있는 검색 UI에 입력을 하면 위쪽에 URL바가 나타나서 입력을 이어가도록 한다. 물론 실제로는 키보드를 입력하면 되니까 손가락을 사용하는 위치는 달라지지 않지만, 봐야할 곳이 전환되는 것에는 영 적응이 안된다.
아이패드 Edge도 동일하게 동작하는 중앙의 검색 UI가 존재하지만, 새 탭을 열자마자 URL바도 함께 보여주기 때문에 익숙한 URL 바를 사용하게 되기 때문에 훨씬 나은 것 같다.
이 글을 적으면서 테스트하다보니, 아이패드 Chrome에서도 감춰져있는 URL 바 위치를 탭하면 URL 바가 나타나는 것을 알게 되었지만…
이 외에도 여러가지 차이점이 있는 것으로 보이지만, 아직은 잘 모르겠다. 당장은 아이패드에서 Edge 브라우저를 좀 더 활용해 볼 생각이다.
집에서는 Windows Vista를 사용하기 때문에, 터미널 작업을 할 때는 보통 PuTTY를 사용한다.
Lucida Console이나 Consolas 폰트 (Consolas Font Pack)를 좋아하기 때문에, PuTTY에서도 보통 Lucida Console이나 Consolas로 설정해서 사용하는데, 문제는 한글이 나오지 않는 것이었다. 그래서, 간혹 한글을 봐야 할 때는 그 때 그 때 다른 폰트로 변경하면서 사용해 왔다.
문제는 일반적으로 영문 폰트에는 한글 문자 영역에 대한 폰트가 들어 있지 않다는 것이다. 일문 영역도 얘기는 마찬가지다. 물론, 폰트마다 문자 영역의 커버리지는 다르다. 굴림체 등에는 한글 뿐만 아니라 히라가나, 가타가나 등이 들어 있기도 하다. (일문에서 사용하는 한자 영역이 들어가 있지는 않다.)
Font Fallback과 Font Linking
Windows에서는 이러한 문제를 해결하기 위해서, Font Fallback과 Font Linking이라는 개념을 사용한다. 이러한 기능은 Uniscribe라고 불리는, Unicode 영역의 문자들을 표시하는 방법을 제공하기 위한 목적으로, Windows 2000 이후로 지원하기 시작한 Windows의 기능 중 하나다.
Font Fallback은 어떤 폰트를 사용할 때, 폰트가 커버하는 영역에 해당하지 않는 문자가 있을 때, 언어별로 지정된 fallback font (일반적으로 Miscrosoft Sans Serif)에 해당하는 폰트를 이용해서 표시하는 기능이다.
Font Linking은 언어별로 지정된 하나의 fallback font가 아니라 여러 fallback 폰트를 폰트 별로 지정할 수 있는 기능이다. 폰트 별로 지정할 수 있으므로 그 폰트에 가장 어울리는 fallback 폰트를 지정할 수 있고, 여러 fallback 폰트를 지정할 수 있으므로, 여러 언어로 폰트의 커버리지를 확장할 수 있다. 이를테면 영문 폰트에 한글 폰트와 일문 폰트를 지정해서, 영문, 한글, 일문을 모두 표시할 수 있는 식이다.
Font Linking을 설정하기 위해서는 직접 레지스트리를 수정해야 한다. HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionFontLinkSystemLink에 폰트 이름에 해당하는 다중 문자열 (Multi-String) 키를 추가하고, <링크할 폰트 파일 이름>, <링크할 폰트 이름>의 형식으로 적는 방식이다.
Font Linking Bug in PuTTY 0.58
문제는 PuTTY는 Font Linking을 지원하지 않는 것 같다는 것이었다. 위와 같이 Font Linking을 설정해도 PuTTY에서는 제대로 표시해 주지 않았다.
이 문제를 조사할 당시, PuTTY의 한글 표시 문제가 Font Linking으로 해결되지 않는다면, Consolas에서 한글을 보기 위해서는, FontCreator 등의 상용 도구를 이용해서 영문 폰트와 한글 폰트를 조합해서 물리적으로 하나의 폰트로 만드는 방법 밖에는 없다는 것이 나의 결론이었다. 그러고 나서 한동안 포기하고 있었는데, 우연히 PuTTY의 Change Log를 보다가 다음과 같은 항목을 보게 되었다.
Bug fix: font linking (the automatic use of other fonts on the system to provide Unicode characters not present in the selected one) should now work again on Windows, after being broken in 0.58. (However, it unfortunately still won’t work for Arabic and other right-to-left text.)
내가 들어가는 사이트는 한정되어있고, 느린 사이트는 아예 들어가지 않아서, V8의 벤치마크 등에서 나타나는 Javascript 엔진의 이점을 100% 누리기는 힘든 것 같다.
실제로 빠른 것은 사실이지만, ‘빠르다’는 느낌이, 페이징이나 스크롤 방식의 차이에서도 오는 것 같다.
Convenient
Google Chrome은 나의 취향과 일치한다. 말하자면, Firefox를 처음 설치했을 때, 내 입맛에 맞도록, 설정하고, Firefox Extension들을 설치해야하는 과정들을 생략해도 된다는 점이 편리하다. 하지만, 기존의 브라우저들을 넘어서는 획기적인 개선이 있는가 하면 잘 모르겠다.
Final Thoughts – Yet Another Browser
일단, Javascript가 더욱 더 보편화 되어가고 있고, 성능 문제가 되어가고 있는 시점에서, Javascript 엔진의 성능이라는 과제를 모든 브라우저 벤더에게 던져준 것을 칭찬하고 싶다.
하지만, 성능의 개선이나, 사용자 인터페이스 개선에도 불구하고, 내겐 또 하나의 브라우저일 뿐이다.
또한, 브라우저를 사용한 작업은 단순히 브라우징에만 국한되지 않고 다양하기 때문에, Firefox의 Extension으로 인한 여러가지 이점은 버릴 수 없다.
결국, 내가 원하는 것은 Google Chrome의 이점들이 Firefox에 잘 흡수되었으면 하는 것이다.
앞으로, 주로 웹 브라우징만 하는 곳 – 내 경우엔 노트북 – 에서는 Google Chrome을 사용해 볼 생각이다. 어차피 리눅스 버전은 없으니…
국내에서도 인기있는 히어로즈(Heroes)의 22화가 현지시각으로 2007년 5월 14일 오후 9시에 방영되었습니다. 그러니까 우리나라 시간으로는 대략 오늘 오전 11시 정도라고 보면 되겠죠. 한글 자막은 오후 5시 30분 경 디씨 히갤에 올라왔습니다. 그렇다면 우리의 웹검색 서비스들은 어떨까요? 다음은 한국 시각으로 2007년 5월 14일 오후 9시 30분경에 검색한 결과의 첫페이지들입니다. (이러한 결과를 처로군이 처음으로 제보해주었습니다.)
결과를 요약하면, 네이버는 웹검색을 통해 씨즐 게시판의 글(오후 7시 30분경)에서, 다음은 블로그 검색을 통해서 (오후 6시 30분경)자막을 얻을 수 있었지만, 엠파스와 구글, 다음의 새로운 웹검색은 검색에 실패했습니다.
네이버와 다음은 2, 3시간 정도 내에 국내의 웹을 검색 결과에 반영할 수 있다는 얘기지요. 네이버의 지식인과 같은 자체 커뮤너티 효과를 무시하더라도 말입니다. 네이버 지식인을 고려하면 더욱 차이가 날 수 밖에 없습니다. 최근의 박지윤 아나운서 사건의 경우에도 사건 후 4시간 정도 경과 시점에서 구글 검색에서는 전혀 알 수 없지만, 네이버에서는 지식인을 통해서 그 사건을 알 수 있었죠.
다음의 결과는 상대적으로 손쉬운 블로그 검색에서만 원하는 결과를 얻을 수 있고 웹 검색결과에서는 얻을 수 없다는 점(웹 검색결과에 히갤 결과가 나온 것은 좋았지만, 원하는 결과가 아닐뿐더러 12시간 이전의 결과입니다.)이 네이버 쪽에 손을 들어주게 만드는군요. 엠파스는 네이버나 다음의 수준을 전혀 따라가지 못해서 실망스럽습니다.
이러한 결과는 단편적이고, 하나의 현상에 불과하지만 그 원인은 국내 검색엔진들이 국내 웹의 freshness에 좀 더 신경을 쓰고 있거나, 국내 웹의 특성(이를테면 게시판 위주)에 잘 맞추어 작동하고 있다고 볼 수도 있을 것 같습니다.
시간이 나는대로 이러한 테스트를 여러번 반복해서 좀 더 객관적인 결과를 도출해낼 수 있어야할 것 같습니다.
Wiki는 널리 사용되는 웹 애플리케이션 형태 중 하나다. 내가 Wiki를 사용하는 용도를 적어보면 참으로 다양하다는 것을 알 수 있다.
메모: 단순한 형태의 정보를 저장.
수정하기 쉬운 목록: 할 일, 살 물건들의 목록.
리서치: 특정 주제에 대한 정보를 (지속적으로) 수집, 정리.
소프트웨어 프로젝트 문서화: 설계 및 구현 문서, 토론의 기록, 기술적인 사실의 기록, 사용자 매뉴얼, 프로젝트에 관련된 리소스로의 접근.
이 글에서 Wiki의 특성에 유래하는 편리함들을 새삼스레 다룰 필요는 없을 것 같다.
스프링노트를 처음 본 사람들은 누구나 Wiki를 떠올릴 것이다. 당연하게도 Wiki의 특성들을 공유하고 있기 때문이다. 스프링노트는 애초에 Wiki를 목표로 만들어 졌으리라고 생각한다.
Wiki나 스프링노트 모두 정보의 생산 도구에 해당한다. 이러한 도구들의 혁신은 반 정도는 "얼마나 쉽게"라는 구호에 달려있다고 본다. 전통적인 Wiki의 formatting 문법은 직관적이지 않는데다가 Wiki 구현에 따라 서로 다른 문법을 사용하는 바람에 보통 사람들은 물론 Wiki를 자주 쓰는 사람들조차도 사용하기 쉽지 않았던 것이 사실이다. 이러한 점에서 BackPack, Writely 또는 Google Docs가 스프링노트를 언급할 때 빠질 수 없을 듯 하다.
스프링노트가 오픈된 지 어느 정도 지난 시점에서 기능적인 면들을 세세하게 짚고 넘어갈 필요는 없을 듯하다. (이를 위해서는 JayZ님의 개인 위키 서비스의 등장이란 글을 참고.)
스프링노트는 기능적인 면에서는 너무 마음에 들어서 내가 사용하는 Wiki를 버리고 스프링노트로 옮겨갈지도 모르겠다는 생각이 든다. 그럼에도 불구하고 스프링노트는 아직 부족한 점들이 많다. 베타 테스트 당시에는, 정말 멋지긴 하지만, 사용 가능한가 하는 의문이 들 정도였다. 스프링노트 개발자들의 노고를 어느 정도는 들어서 알고 있기 때문에, 이러한 지적을 하는 것은 대단히 꺼려지는 일이지만, 이러한 지적을 통해 좀 더 나은 모습의 스프링노트 더 나아가서는 후속작들을 기대해본다.
페이지 로딩이나 단축키 반응 등이 느리다. 베타 테스트 당시에는 서비스가 굉장이 느렸는데, 지금은 많이 나아진 것 같다.
WYSWYG 에디터의 버그가 많다. 잘 동작하지 않는 경우도 있고, 브라우저에 따라 다르게 동작하는 경우도 있다.
WYSWYG 에디터의 사용자 인터페이스 (버튼, 단축키)가 충분히 편리하지 않다. 버그에 해당할 지도 모르겠지만, Bold나 Italic과 같은 텍스트 속성을 토글할 수 없다든가, Undo에 해당하는 Ctrl-Z를 두번 눌러야 하는 경우가 많다는 것들은 자잘하지만 상당히 불편함을 야기한다.
사용자 인터페이스가 충분히 편리하지 않다. 예를 들면, 상대적으로 자주 사용될 것이라 생각되는데도 불구하고 공개되어있지 않은 페이지를 공개하기 위해서는 세번이나 클릭해야한다.
추가할만한 기능이라면 다음을 들고 싶다.
맞춤법 검사: 불행하게도 아직 국내 웹 서비스 중에서 맞춤법 검사를 해주는 곳이 없다.
외부 블로그 포스팅: 이미지 업로드 등이 걸리긴 하겠지만, 맞춤법 검사가 된다면 아마 텍스트 지향 사용자들은?
CSS 테마: 모양새 까지는 아니더라도 색상이나 폰트를 변경할 수 있었으면 좋겠다. 개인적인 취향이지만, XHTML 포맷에서도 굴림 폰트로 고정해놓아서 마음에 안든다. (나는 브라우저 기본 설정을 사용할 수 있도록 하는 것을 선호한다.)
공개된 페이지의 URL에 페이지 제목을 사용하기: 한글 URL에 관한 복잡한 이슈 때문에 스프링노트와 같은 서비스에서 한글을 URL에 사용하는 것은 아직은 힘들 것 같다.
함께 위키 만들기: 혼자서 쓰는 위키라는 느낌이 강하다. 다른 사람들의 공개된 페이지에 좀 더 쉽게 접근할 수 있도록 하고 링크하기도 쉽게 만들었으면 좋겠다.
릴리즈 노트에도 크게 놀랄 만한 사실은 없고, 사실 크게 달라진 점은 느끼기 힘든 것 같습니다. 다만 한가지, 저는 탭을 보통 수십개씩 쓰는데, 기존에는 윈도우 너비를 넘어서는 탭은 탭을 닫는 버튼 뒤에 가려졌었는데, 이제는 탭을 닫는 버튼이 탭에 가려지는 것이 좀 이상한 것 같습니다. 그 외에는, Canvas element를 사용한 3D FPS 게임(?) Canvascape 정도를 즐길 수 있게 되었다는 정도?
Extension과의 호환성
모든 Extension이 자연스럽게 1.5에 호환되는 것은 아닌 것 같습니다. Google Toolbar나 Adblock, Onfolio, IE View, IE Tab, del.icio.us Extension 같은 것은 별 문제가 없었으나, 제가 중요하게 사용하는 SessionSaver Extension은 호환이 되지 않는다고 하더군요. (GreaseMonkey나 StarDownloader 같은 것들은 그다지 중요하게 사용하고 있진 않습니다) 따라서, 자신이 사용하고 있는 중요한 Extension이 아직 Firefox 1.5에 호환되지 않는다거나 그다지 확신이 서지 않는다면 1-2주 정도 Firefox 1.5 설치를 미루는 것이 좋은 선택이라고 생각되는군요.
한가지 해결책은 직접 Extension의 Firefox 버전 요구사항을 수정하는 겁니다. 자신의 Documents and Settings 폴더에서 Mozilla/Firefox/Profiles/YOUR_PROFILE/extensions 폴더를 뒤져서, 특정 Extension의 install.rdf 파일을 적절하게 수정해주면 됩니다. 물론 Extension에 따라 동작하리라는 것은 보장할 수 없습니다. (이와 관련해서 Extension 관련 변경사항을 알아보면 좋겠군요. 만약 있다면.)
대충 위와 같은 항목에서 em:maxVersion element를 수정해주면 되는거죠. 호환되지 않는 extension의 install.rdf를 잘 찾아낼 수 있다면, 고치는 것은 그리 어렵지 않습니다. extensions 폴더 아래에는 extension의 특정한 GUID를 이름으로 가지는 폴더들이 있는데, 그 아래의 chrome 폴더를 보면 실제 extension 이름을 알아볼 수 있는 경우가 대부분입니다.
Update 2005/12/1: 프리버즈님 말씀대로 del.icio.us extension의 최근 버전에서는 Firefox 1.5를 지원합니다. 이에 관한 내용을 수정하였습니다.
