31 Dec 05 맥과 윈도우스의 이미지 디스플레이 차이
맥 미니가 느려서 새 PC를 사기는 했지만, 맥은 항상 켜두는 탓에 그다지 CPU 파워를 요구하지 않는 일은 그냥 맥을 사용하고 있다. 최근에 블로그에 글을 올릴 때 별 생각없이 맥에서 포스팅한 후 나중에 윈도우스에서 다시 보니 이미지의 디스플레이되는 퀄리티가 맥과 달랐다. 맥에서는 원래 이미지 파일의 크기보다 브라우저에서 작게 리사이즈해서 보여줄 때에도 괜찮은 퀄리티로 보이는데, 윈도우스에선 그렇지 않았다. 예를 들면, 이 사이트에서는 600×600의 이미지를 미리 150×150으로 Paint Shot Pro로 리사이즈해서 올린 이미지와 그냥 으로 브라우저가 리사이즈해서 디스플레이하는 이미지를 비교하고 있는데, 이걸 맥에서 보면 (캡쳐한 이미지)
이렇게 선의 굵기가 좀 다르지만 비슷한 정도의 퀄리티로 보이는데 비해 윈도우스에서는
이렇게 보인다. 두 경우 모두 Firefox 브라우저를 사용했으므로 브라우저의 차이라기 보다는 OS가 이미지를 리사이즈해서 디스플레이할 때 알고리즘의 차이일 것이다. 물론 윈도우스의 경우에도 더 좋은 퀄리티로 디스플레이할 수 있는 방법이 있겠지만, 퀄리티와 속도 중 어느쪽을 기본적으로 선택할 것이냐에 있어 맥과 윈도우스의 차이를 잘 보여주는 예인 것 같다.
추가:
맥보다 아주 약간 퀄리티가 떨어지긴 하지만 오페라 브라우저를 사용하니까 윈도우스에서도 괜찮게 보이네요. 아래 코멘트에 이올로님이 지적해주셨습니다.
30 Dec 05 웹의 이중성
웹의 이중성을 이렇게 명확하게 설명해 놓은 것을 이제야 봤다니.
그렇다면 앞으로 information-oriented, web as hypertext system을 위해선 계속 HTML이 사용되고 task-oriented, web as software interface는 점차 XAML과 같은 기술로 대치되어 갈 것인가? Software interface를 위한 표준화되면서 동시에 효율적인 플랫폼이라는 것이 애초에 가능한 것인가? X-Windows도, Citrix Metaframe도, Network Computer도, Sun Ray도, VNC나 Java Webstart도 한정적으로 쓰이고 있을 뿐인데 과연 world-wide 규모의 remote software interface를 위해 앞으로 어떤 기술이 이용될 것인지 궁금하다.
25 Dec 05 iTunes에서 Podcast CD-ROM 굽기
Podcast 클라이언트로 이것 저것 써보다가 지금은 그냥 iTunes를 쓰고 있다. iTunes의 경우 설정을 세세하게 할 수는 없지만 아무래도 쓰기 편하고 podcast directory도 잘 되어 있으며, 기능이 간단하다고는 하지만 꼭 필요한 기능은 대충 있기에 이걸 쓰고 있다. 내가 사용하는 거원 U2로 이걸 들으려면 그냥 podcast 폴더를 MP3 드라이브에 복사만 하면 되기 때문에 iPod에 비해 그다지 불편할 것은 없지만, 언젠가부터 차의 오디오에서 듣기 위해 그냥 일주일에 한번 정도 MP3 CD-ROM을 굽게 되었다.
처음에는 podcast 디렉토리를 CD-ROM으로 그대로 구웠다. 다해서 700MB가 안되기도 했지만, podcast 소스별로 별도 디렉토리로 구우면 나중에 찾아듣기 쉬을 것이라고 생각했기 때문이다. 그런데 한동안 이런 방식으로 구워서 이용하다보니, 이미 들은 podcast와 아직 듣지 않은 것을 분간해서 찾아 듣는 것이 귀찮았다. 그냥 하나의 디렉토리에 podcast 소스 구분하지 않고 시간순으로 쭉 나열되는 것이 더 나을 것 같았다. 조금 들어보다가 재미없으면 그냥 skip하면 되고, 지난 주에 구은 CD-ROM의 내용이 이번 주에 구은 것과 일부 중복되더라도 처음 몇 podcast를 skip하면 되니까.
이렇게 MP3 CD-ROM을 굽기 위해 처음에는 맥의 automator로 시도를 했으나 잘 되지 않았다. 역시 visual programming은 일단 시작하기는 쉽지만 세세한 제어를 하기엔 더 어렵다. 좀 하다가 대충 포기하고 Python 스크립트로 만들었다. 700MB 한도 내에서 가장 최근에 다운로드된 podcast를 찾아 시간순으로 소팅한 후 파일 이름 앞에 00, 01, 02 등과 같이 숫자를 붙이는 것은 쉬웠는데, MP3 파일을 복사/rename하지 않고 symbolic link를 만들었더니 이걸 쫓아가서 CD-ROM에 굽기는 하는데 구워진 파일 이름도 symbolic link의 이름이 아니라 원래 파일 이름으로 구워져버렸다. 결국 link를 만드는 대신 copy하도록 해서 성공은 했지만, 700MB 정도를 쓸데없이 복사하는 것 같아서 찜찜했다. “진짜 엔지니어”는 실용주의적이지 않다^^. 아무리 실용적으로 잘 동작하더라도 비효율적인 것 같으면 참지를 못한다.
그러다가 iTunes의 스마트 플레이 리스트의 “최근 추가된 항목”을 보면서, 그냥 이걸 쓰면 되는 것 아닌가 하는 생각이 들었다. 역시 700MB 한도의 최근 podcast를 보여주는 리스트는 아래와 같이 쉽게 만들었졌고
이 리스트의 화면에 보여지는 순서를 다운로드받은 시간 순으로 하는 것도 쉬웠는데, 과연 CD-ROM으로 구워질 때 이 순서가 유지되는 것일까? 웹을 검색해보니 될 것 같아서 몇백원 날리는 셈치고 CD 한장을 구워봤더니 과연!
위와 같이 파일 이름 앞에 제대로 숫자를 붙여주는 것이었다. 역시… 사람들이 iTunes를 괜히 많이 쓰는 것이 아니었고 Apple이 이유없이 회생한 것이 아니었다.
오늘의 교훈: Do not reinvent the iWheel!
15 Dec 05 워드다이얼 서비스
(Disclaimer: 워드다이얼 서비스는 제가 다니는 회사와 관련되어 있는 서비스입니다. 개인적 의견을 쓴 글이지만, 객관적이지 않을 수 있음을 밝힙니다.)
워드 다이얼 서비스가 드디어 오픈되었다. 미국 등지의 광고를 보면, 전화번호를 문자로 표현하는 경우를 흔히 볼 수 있다. 예를 들면, 전화 및 인터넷으로 PC를 판매하는 Dell사의 대표번호는 1-800-WWW-DELL 이다. 물론 자판의 해당 문자가 표시되어있는 번호를 누르는 것이므로 실제 숫자로 된 번호는 1-800-999-3355 이지만, “WWW-DELL”이 “999-3355″보다 훨씬 기억하기 쉽다. 문제는 이렇게 적당한 단어로 나타내어질 수 있는 번호를 확보하기가 어렵고 특히 우리나라의 경우 한글 이름은 길이가 길고 제조사에 따라 자판의 자모 할당이 달라서 동일한 방법으로 숫자 번호를 표현할 수 없다는 점.
워드다이얼은 휴대폰에 문자를 입력하면 문자열을 해싱(hashing)한 후 일정한 자릿수의 10진수로 변환하고 특정 prefix에 이 값을 붙여 만들어진 번호로 전화를 걸고, 교환기에서 이 번호를 등록된 실제 번호로 돌려주는 방식이다 (실제로는 조금 더 복잡함). 충분히 긴 번호를 사용하기 때문에 hashing collision이 일어날 가능성은 거의 없고, 수백만개의 상호나 이름을 얼마든지 수용할 수 있으며 데이터 네트웍 접속과정 없이 바로 음성 통화가 이루어진다는 점이 유사한 다른 서비스 대비 장점이다. 물론 이를 위한 프로그램이 휴대폰에 설치되어야 하지만 앞으로 신규폰의 경우 메뉴에 기본 내장될 계획.
사실 100MHz가 넘어가는 32 bit CPU에 수십MB의 메모리를 가진 휴대폰에서 디지털 네트웍을 통해 전화를 하는데도 전화걸 대상을 숫자로만 명시할 수 있다는 것은 모든 웹 사이트 주소를 IP 주소로 직접 입력해야 하는 것만큼이나 비합리적임에도 불구하고, 수십년전 유선 애널로그 전화의 체계를 그대로 디지털 휴대폰에 가져온 때문이다.
SKT 휴대폰만 사용 가능한 점, 휴대폰 대기화면에서 바로 숫자 대신 입력이 안되는 점 등의 걸림돌이 있어 얼마나 성공적일지는 앞으로 두고 봐야겠지만, 사용자들에게 아무런 부담없이 편의를 제공하면서 아이디어와 기술로써 새로운 BM을 만들어 내었다는 점에서 매우 바람직하고 기대가 되는 서비스이다.
01 Dec 05 Podcast도 검색이 된다
“Podcast Chaos Be Gone“이라는 와이어드의 기사를 보면, Podcast의 내용을 미리 음성 인식으로 텍스트로 바꿔 인덱스해두었다가 검색할 수 있도록 해주는 서비스가 등장했다. 기사에 언급된 사이트 중 Podzinger는 기사 때문에 트래픽이 몰려서인지 지금 접속되지 않았지만, blinkx는 몇몇 단어로 검색해보니 과연 이 단어를 언급하는 podcast를 찾을 수 있었다.
Podcast를 검색할 수 있게 되었다는 것은 매우 중요한 것으로서, podcast의 유용성을 향상시켜 더 많은 podcast가 생산되고 또 검색되어 이용되도록 하는 positive feedback 효과를 가져올 뿐만 아니라, 같은 기술이 podcast 외에도 TV나 라디오 프로그램 등 모든 음성 검색에 응용될 수 있기 때문이다. 물론 이게 가능해진 것은 그동안 발전한 음성인식 기술 덕분으로서 현재 우리나라 음성인식 기술 업계의 상황을 보면 이와 같은 기술이 우리말에 대해선 한동안 가능하지 않을 것 같다. 하긴 기사 내용을 보면 Podzinger에서 사용하는 기술은 원래 미국 정보기관이 아랍에서 감시용으로 사용하기 위해 개발된 것이라고 하니, 같은 목적으로 미국이 북한 때문에 우리말에 대한 인식 기술을 개발할 지도 모르는 일이다. 그렇게 개발된 음성인식 엔진은 북한 사투리를 더 잘 인식하겠지만.
미국 영화를 보면 주인공들이 녹음기에 음성 메모를 하는 것을 자주 볼 수 있다. 물론 이건 주인공의 생각을 관객에게 전달하기 위해서이고 실제로는 그렇게 흔한 일은 아니라고 하지만, 아뭏튼 그런 용도의 녹음기가 꽤 팔리고 있고, 우리나라에선 거의 이용되지 않는 자동 응답기나 음성 사서함이 널리 이용되는 것을 보면, 미국 사람들은 녹음기에다 음성을 남기는 것에 익숙한 것 같다. 그렇다면 남들에게 들려주기 위한 podcast 뿐만 아니라 그냥 자신의 메모 용도로 녹음을 남기고, 나중에 이를 텍스트로 (혹은 음성으로) 검색할 수도 있지 않을까? 더 나아가서, 마이크로소프트가 MyLifeBits 프로젝트에서 시도하는 것처럼 항상 휴대하고 다니는 포터블 장치가 나 뿐만 아니라 나와 얘기하는 상대방의 말까지 – 또는 전화 대화까지 – 모두 녹음하고 이를 텍스트로 변환하고 인덱싱하여 검색할 수 있다면 수첩이나 메모장이 필요없어질 것이다. 물론 이런 일이 실현되면 이 때문에 기억력이 나빠진다고 투덜대는 사람들도 있겠지만.
