17 Jul 07 iPhone
회사에서 업무 때문에 iPhone을 구하게 되었다. 미국에서 개통하고 바로 한국으로 가져와서 비록 통화는 안되지만 WiFi를 이용하여 대부분의 데이터 애플리케이션은 사용해볼 수 있었다.
사진에는 웬지 액정에 격자 무늬가 보이지만 실제로는 그런 것은 없고, 매우 깨끗한 화면에 한글 폰트도 볼만하게 렌더링한다. 물론 플래시를 지원하지 않고 한글을 입력할 방법도 없으므로 한국에서 사용하긴 많이 불편하겠으나 듣던대로 UI는 스무스했고 테스트하는 동안 한두번 애플리케이션이 죽는 것을 보긴 했으나 OS 자체가 불안정해지는 것은 보지 못했다.
RAZR2와 비교했을 때 두께는 거의 같고 폭과 길이가 약간 더 길다. 바지 주머니에 넣어보면 길이가 약간 부담되는 정도. 손에 들고 사용하기엔 전혀 문제 없다 (물론 내 손이 좀 큰 편이긴 하지만. 우리 사장님이 비닐도 못떼게 했음^^).
멀티 터치는 편리하기는 했으나, 구글 맵스에서 간혹 줌인을 하다가 다른 곳으로 튀는 경우가 있었다. 그냥 화면 한구석에 스크롤 바를 두는 것에 비해 그다지 실용적이진 않은 것 같다. 그에 비해 그 유명한 “관성에 의한 스크롤”은 아주 잘 동작했고 매우 편리했다. iPod 기능에서 cover flow도 거의 지연 시간 없이 아주 자연스럽게 동작했다.
사파리는 생각보다 잘 보여주기는 했으나 WiFi에서도 대부분의 우리나라 사이트는 좀 무겁게 느껴졌다. 몇년 지나 모바일 프로세서가 이런 사이트들을 부담없이 보여줄 때가 되면 많이 사이트가 FLEX나 Silverlight를 사용하고 있지 않을까? 사이트들이 모바일 디바이스를 보다 적극적으로 고려해주지 않는 이상, 아무래도 모바일 디바이스에서의 일반 인터넷 이용은 계속 문제가 있을 듯 하다. 단, 가로 모드로 했을 때 화면의 폭은 그런대로 넓고, 작게 렌더링된 폰트도 그런대로 볼만하여 가로 스크롤을 많이 할 필요는 없었다.
전반적으로 볼 때 지금 당장이라도 사용하는데 별 문제는 없겠으나 조금씩 개선의 여지는 보인다. 과연 HSDPA 모델이 나오면 우리나라에도 도입될 수 있을까? 그보다는 폰 기능을 제외한 OS X 기반의 iPod라도 빨리 나왔으면 좋겠다.
12 Jun 07 Safari on Windows
아직 한글 윈도우스에선 문제 많고 듀얼 모니터 관련 버그도 있으나, 그런대로 렌더링은 잘 하는 것 같다.
재밌는 것은 폰트 렌더링을 포함해서 모든 것을 자체적으로 해결한다는 점인데, 그 때문에 한글 폰트와는 좀 문제가 있다. iTunes를 윈도우스에 포팅한 것이야 iPod를 더 많이 팔기 위한 것이지만, 굳이 사파리를 윈도우스에 포팅한 이유는 무었일까? 그냥 MS의 심기를 불편하게 하는 것이 재밌어서 그 노력을 들이는 것은 아닐거고, iPhone의 SDK 용도로도 말이 안된다. 그냥 그 용도로만 한정된 에뮬레이터를 릴리즈하는 것이 훨씬 쉽고 개발에도 도움이 될테니까. 어쩌면 맥 OS X의 dashboard widget을 윈도우스에 포팅하기 위해서가 아닐까? Google과 마찬가지로 애플 역시 윈도우스의 데스크탑을 차지할 이유야 많이 있으니까.
04 Feb 07 iPhone 벨소리
iPhone에 대한 글을 또 쓰긴 싫지만… 스티브 잡스가 시연에서 사용했던 iPhone의 벨소리를 Craig Reynolds란 사람이 멋지게 리믹스했다. 아래는 이걸 휴대폰 벨소리용 mmf 파일로 변환한 것.
iphoneremix.zip (첫 23초, 22.05KHz, 260KB)
11 Jan 07 iPhone을 한국에서 쓰게 될지도…
이찬진씨가 쓴 iPhone을 한국에서 쓰게 될지도…라는 글에서는 예측이라기보다는 어떻게든 한국에서 iPhone을 써보고 싶다는 소망이 엿보인다. 신문을 보니 “저런 기능은 다른 폰에서도 되던 것이다”라고 어떤 업계 관계자가 말했다던데 딴 건 몰라도 그 “관계자”는 소프트웨어 개발이나 usability에 대해서는 “관계”하지 않는 모양이다. 예전에 대학 동기들 만나서 맥주 한잔 마시다가 “클릭휠 못지 않은 입력 장치를 몇 달동안 고민했는데 생각이 안나더라”고 했더니 국내 굴지의 MP3 회사의 연구소장인 친구가 “난 일년동안 고민했는데도 답 없더라”고 했었다. 그런데 iPhone에서 손가락으로 쓱 밀어 관성으로 스크롤시키는 것을 보면서 “난 왜 저렇게 간단한 것을 생각하지 못했던가…”라고 할 수 밖에 없었다.
과연 이찬진씨의 바램이 이루어질지는 모르겠으나 iPhone이 기능과 UI는 다 고만 고만하면서 뚜껑이 어떻게 열리는지만 고민하는 국내 제조사와, 단기수익을 극대화시키는 것만 고민하는 이통사에게 신선한 충격이 되었으면 한다.
10 Jan 07 iPhone
팀사람들과 함께 iPhone을 소개하는 맥월드 키노트 비디오를 보고난 후의 감동으로부터 아직도 헤어나지 못하고 있다.
나라 전체가 테스트베드임을 자처하는 우리나라의 휴대폰은 특히 소프트웨어 부분에 있어 왜 시간이 갈수록 점점 더 뒤떨어져간다는 생각이 들까? Q사가 만든 칩셋과 펌웨어 위에 S통신사가 사업상 필요할 때마다 API를 추가하는 I사의 OS(?)를 제조사 하청업체 사람들이 대충 포팅해서 만들어지는 수백개의 휴대폰의 서로 다른 버전과 버그와 제약 위에 뭔가 획기적으로 새로운 것을 구현한다는 것은 불가능에 가까운 일이다.
iPhone으로 인해 이러한 구조적인 문제에 돌파구가 생겼으면 좋겠다.
04 Mar 06 iTunes에서 Podcast CD-ROM 굽기 #2
지난 글에서 애기했듯이, iTunes를 써서 Podcast의 다운로드와 MP-3 CD-ROM 굽는 것을 자동화하여 사용하고 있었으나, 한가지 문제가 있었다. iTunes는 일정기간동안 한편(트랙)도 듣지 않은 podcast feed의 다운로드를 중지하도록 되어 있는데, CD-ROM을 굽는 것 만으로는 그 트랙을 “들은”것으로 인정해주지 않는 모양이다. 다른 podcast 클라이언트를 쓸까도 생각해봤지만, 워낙 iTunes가 편해서 차라리 모든 다운로드한 podcast 트랙을 “들은”것으로 자동으로 설정하는 스크립트를 만들어보기로 했다. 아래는 생전 처음 만들어본 AppleScript (이글루스에서
를 사용하기가 힘들어 이미지로 올림):대충 비슷한 예제 가져다고 고친 것이라 제대로 했는지 모르겠지만 일단 동작은 한다. 애플 스크립트의 문법은 영어 문법과 비슷하도록 되어 있는 것 같은데 그냥 Python 같은 문법을 사용하는 것이 낫지 않았을까? (애플 스크립트의 Python binding(?)이 있는지 알아봐야겠다). 윈도우용 iTunes은 COM 인터페이스를 지원한다고 하니 윈도우에서는 VB나 Python COM binding을 이용하면 될 것 같다. 그 다음엔 이걸 매일 실행시켜야 하는데, 그냥 익숙한 cron을 이용할까 하다가 아무래도 애플 스타일이 아닌 것 같아 찾아보니 애플이 권장하는 방법은 iCal에 반복 일정을 만들고 이를 이용하여 스크립트를 실행시키는 것. 배보다 배꼽이 커보이긴 했지만 (하긴 GUI는 대부분 그렇지 않던가...) 일단 그냥 그렇게 써보기로 했다.
31 Dec 05 맥과 윈도우스의 이미지 디스플레이 차이
맥 미니가 느려서 새 PC를 사기는 했지만, 맥은 항상 켜두는 탓에 그다지 CPU 파워를 요구하지 않는 일은 그냥 맥을 사용하고 있다. 최근에 블로그에 글을 올릴 때 별 생각없이 맥에서 포스팅한 후 나중에 윈도우스에서 다시 보니 이미지의 디스플레이되는 퀄리티가 맥과 달랐다. 맥에서는 원래 이미지 파일의 크기보다 브라우저에서 작게 리사이즈해서 보여줄 때에도 괜찮은 퀄리티로 보이는데, 윈도우스에선 그렇지 않았다. 예를 들면, 이 사이트에서는 600×600의 이미지를 미리 150×150으로 Paint Shot Pro로 리사이즈해서 올린 이미지와 그냥 으로 브라우저가 리사이즈해서 디스플레이하는 이미지를 비교하고 있는데, 이걸 맥에서 보면 (캡쳐한 이미지)
이렇게 선의 굵기가 좀 다르지만 비슷한 정도의 퀄리티로 보이는데 비해 윈도우스에서는
이렇게 보인다. 두 경우 모두 Firefox 브라우저를 사용했으므로 브라우저의 차이라기 보다는 OS가 이미지를 리사이즈해서 디스플레이할 때 알고리즘의 차이일 것이다. 물론 윈도우스의 경우에도 더 좋은 퀄리티로 디스플레이할 수 있는 방법이 있겠지만, 퀄리티와 속도 중 어느쪽을 기본적으로 선택할 것이냐에 있어 맥과 윈도우스의 차이를 잘 보여주는 예인 것 같다.
추가:
맥보다 아주 약간 퀄리티가 떨어지긴 하지만 오페라 브라우저를 사용하니까 윈도우스에서도 괜찮게 보이네요. 아래 코멘트에 이올로님이 지적해주셨습니다.
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!
