내 맘대로 보는 세상

webdevmobile에서 3회(1, 2, 3)에 걸쳐 개최한 열린 세미나가 성공적으로 끝이 났습니다. 웹은 예전부터 관심을 가지고 지켜보고 있었지만 최근 HTML5 등의 이슈에 대해서는 제대로 follow up 하지 못하고 있어서 약간의 죄책감을 가지고 있었는데, 덕분에 HTML5에서 지향하는게 무엇인지에 대해 약간이나마 알 수 있어 재밌었습니다. :)

아무래도 HTML이란 이름 때문에 웹퍼블리셔 분들이 많이 참석하셨던데 (특히) 3회째 세미나는 웹퍼블리셔 분들보다 앱 개발자 분들이 좋아하셨을 것 같네요.

HTML5: API

첫 세션은 요번에도 이원석 박사님께서 담당해주셨습니다. 초점은 HTML5에 추가된 API 들에 초점이 맞춰져 있었고, Canvas 2D, Video API, Web Socket, Local storage, Local database 등에 대한 간략한 소개 위주였습니다.

이 정도 API면 왠만한 애플리케이션을 구현하는데는 거의 지장이 없을 것 같더군요. :)

그리고 AJAX의 경우 Cross domain에 대한 쿼리가 불가능했기 때문에 결제 모듈처럼 타 서버로 값을 넘겨주고 그 결과를 리턴받아 사용해야 하는 경우에는 JSON나 로컬 프록시 등의 편법을 사용해야 했는데요, Web Socket에선 이런 제약이 사라졌기 때문에 편법을 사용하지 않고도 훨씬 많은 일들을 할 수 있게 되었습니다.

시작은 플랫폼에 구속받지 않는 문서로 시작되었지만, 이제는 그 굴레를 벗어나 앱으로의 확장을 꿈꾸고 있는 것으로 생각됩니다.

HTML5: Device API

모바일 디바이스를 위한 확장으로 Device API라는 것도 소개를 해주셨는데, 거기에 포함된 것들은 Geo Location(GPS), Filesystem, … 등이 있었습니다.

다만 Geo Location 이라거나 Filesystem 등의 경우 사용자의 Privacy가 노출될 수 있는 문제가 있기 때문에 이를 보완하기 위한 것들이 아직 논의되고 있는 중이라고 하더군요. :)

Java servlet에서 하는 것처럼 signed javascript의 경우 geo location, filesystem 등에 접근하는데 제약이 없도록 하는 건 어떨까 하는 생각이 들었습니다.

HTML5: Worker

Worker는 운영체제의 Thread에 해당되는 기능이라고 합니다. 특정 js 파일을 인자로 new Worker(‘…js’)를 실행시키면 이 js 파일을 처리하기 위한 thread가 생성됩니다.

어떤 복잡한 (시간이 오래 걸리는) 자바스크립트 로직이 있을 경우 이 로직이 처리될 때까지 사용자의 인풋이 블럭될 수 있는 문제가 있습니다. Worker는 이런 문제를 피해가기 위해 추가된 기능이라고 하며, 역시나 실시간 앱 시장을 HTML5에서 얼마나 욕심내고 있는지를 확인시켜주는 기능이라고 생각합니다.

쓰레드 간의 통신을 위해서는 메시징을 이용하면 된다고 하네요.

HTML5 웹을 넘어 플랫폼으로…

이원석 박사님의 세션이 끝나고 든 생각은 ‘HTML5는 문서도 앱도 아니고 플랫폼이구나‘란 생각이었습니다.

그래픽/통신/데이터베이스/파일시스템/쓰레드/Inter-thread communication 등 운영체제들에서 제공하는 대부분의 기능이 HTML5에 정의되어 있는 것을 확인할 수 있었으며, 이 규격만 제대로 구현해도 하나의 운영체제로써의 역할을 할 수 있지 않을까 하는 생각마저 들었습니다.

삼성 등에서는 수없이 많은 휴대폰 모델을 개발하고 있으며, 각각을 위해 앱을 새로(완전히 새로는 아니더라도) 개발하고, 수정하는 과정을 거치고 있습니다. 이런 노력을 줄이기 위해 바다라는 플랫폼을 만들어냈고, 안드로이드라는 플랫폼을 차용하고 있는데요. 앞으로는 안드로이드나 바다 등의 플랫폼보다 웹 플랫폼이 더 사랑받을 수 있지 않을까 하는 생각이 들었습니다.

웹은 이제 옵션이 아닌 필수가 되어가고 있으며, webkit 같은 오픈소스 Web Library를 이용할 경우 쉽고 빠르고 안정적으로 웹 플랫폼을 제공할 수 있을 것으로 생각됩니다.

필수적으로 제공되야 한다면 차라리 이를 플랫폼으로 하고, 전화 App, DMB App 마저도 HTML5로 구현하면 어떨까 하는 생각까지 들더군요. (CDMA 모듈이나 DMB 모듈과 통신하기 위한 plugin을 제공하면 됩니다. 인터페이스만 동일하게 규격화 한다면, App은 재활용이 가능할 것입니다.)

조만영님의 얘기처럼 이제 곧 Web Engineer라는 직종이 새롭게 정의되지 않을까 하는 생각이 듭니다.

그럼에도 HTML5에 아쉬운 점…

최근 화두 중 하나는 3D입니다. 하지만 Canvas에서 2D에만 초점을 맞추고 있다는 점은 조금 아쉬웠습니다. 2D API로도 3D를 그려낼 순 있습니다. 하지만 3D API가 제공되지 않는다면, 하드웨어 가속 기능을 사용할 수 없고 이는 파워가 약한 모바일 디바이스에게 (실행 속도, 전력소모 두가지 측면에서 모두) 치명적인 문제가 될 수 있습니다.

다행히도 WebGL이라는 이름으로 (이원석 박사님 표현에 따르면 실험적인) Canvas 3D 규격이 준비가 되고있기는 한 것으로 보입니다만 아직 HTML5의 기본 기능으로는 분류되지 않고 있는 것 같네요. 조금 아쉬운 부분입니다.

또한 매번 문법을 파싱, 검사, 실행해야 하는 HTML5는 모바일 디바이스에서 약간의 부담일 수 있다고 생각합니다. 그렇기 때문에 java에서 그랬듯이 플랫폼에 무관한 바이너리로 변환해주는 기능(컴파일러)이 필요하지 않을까 하는 생각이 들었습니다.

물론 표준에 포함되지 않더라도 브라우져의 캐쉬단에서 파일을 컴파일해 저장해둔 뒤 다시 보여줘야할 땐 컴파일된 파일을 바로 로딩해서 보여주는 방법을 활용할 수도 있을거라 생각합니다.

에필로그

HTML5가 나오더라도 IE가 또 발목을 잡지 않을까 하는 이야기가 들려옵니다. HTML5, CSS3를 언제쯤 실무에 적용하면 좋을지에 대한 이야기도 들려옵니다.

저는 이렇게 이야기하고 싶습니다.

아직 PC를 위한 페이지에 적용하기는 조금 이를지 모르겠습니다. 하지만 모바일을 위한 페이지에는 적극적으로 HTML5를 활용해보아도 좋다고 생각합니다.

재작년말, 작년초 다음 커뮤니케이션 면접 때 ‘앞으로 웹이 어떻게 변할 것이라고 생각하시나요?’란 질문을 받았습니다. 그 때 전 이렇게 대답했습니다.

‘스토리지를 담당하는 서비스가 나오고, 이 서비스를 활용하는 어떤 매쉬업이 나올 것으로 생각됩니다. 웹은 이런 서비스들이 거미줄처럼 얽혀 무한한 가능성을 만들어낼 수 있는 플랫폼이 될 것으로 생각됩니다.’

그 때 제가 생각했던 것들이 점점 현실이 되어가고 있는 것 같습니다. 점점 더 재밌어지네요. 오랫만에 가슴이 두근두근 거리는 것 같습니다.

덧: 좀 게으름을 피다보니 그 때 나눴던 이야기들 중 까먹은 이야기가 너무 많네요… 메모라도 했음 좀 나았을텐데, 맨 몸으로 참석해서 맨 몸으로 돌아와버렸더니… OTUL

덧2: 다른 분들이 올려주신 후기들입니다. 역시 관점이나 생각에 따라 다들 느끼는 점이 다른 것 같습니다. :)

1. Wise님의 후기
2. Na!님의 후기

예전부터 방관자 입장으로 멀찍이에서 웹을 바라보고 있었는데, 최근 이슈가 되고 있는 HTML5에 대한 열린 세미나에 참석할 기회가 생겼습니다.

사실 기술 세미나는 잘 참석하지 않는 편인데, 요번 세미나 및 뒷풀이를 통해 재밌는 이야기를 많이 해볼 수 있었던 것 같습니다.

제가 이해한 내용, 그리고 사석에서 이야기 해봤던 내용은 다음과 같습니다. 다만 음주 토크가 좀(?) 있었고, 따로 HTML5에 대해 공부를 해보진 않았기 때문에 잘못된 내용이 있을 수도 있습니다.

좀 더 세분화된 컨텐츠 구조화를 위해 정의된 태그들

html4에서는 문서의 구조화를 위해 heading element(h1 ~ hx) 태그만을 활용할 수 있었습니다. 하지만 html5에서는 문서 컨텐츠의 구조화를 위해 article, aside, header, section 등의 태그가 새롭게 정의되었습니다.

문서 하나에 여러 가지 주제의 글들이 있을 경우 각각을 article로 묶어주고, 그 안에서 독립적인 구조(section, h1~hx)를 가질 수 있는 구조가 되었으므로, 기계 입장에서 조금 더 쉽게 문서를 분석해낼 수 있을 것으로 생각됩니다.

HTML5: 웹을 넘어 앱으로…

구글 애플리케이션, EyeOS, 구글 OS 등에서는 이미 웹을 이용한 애플리케이션의 가능성을 보여주고 있었습니다. HTML5에서는 드래그앤 드롭, Video, Audio, Canvas, Device API 등의 기능을 제공하고 있고, 이를 통해 네이티브 애플리케이션에 버금가는 기능들을 제공할 수 있게 될 것으로 생각됩니다.

열린 세미나에서는 W3C 위젯을 이용한 애플리케이션 개발 데모를 볼 수 있었는데요. 정말 간단하더군요. :)

HTML/CSS로 UI를 구성하고 javascript로 사용자 인터렉션을 구현하고, config.xml을 통해 시작 페이지나 윈도우 사이즈 등을 정의한 뒤 zip으로 묶으면 끝입니다. (사실 확장자를 zip에서 widget으로 바꿔주는 과정이 추가로 필요하긴 합니다.)

사실 어떻게 보면 안드로이드 앱 개발 과정과 크게 달라보이진 않습니다. 참고로 안드로이드 앱 개발 과정은 XML로 UI를 구성하고, JAVA로 사용자 인터렉션을 구현하고 패키징을 하는 과정으로 구성됩니다. Widget을 만드는 방법과 동일하죠? (사실 둘 다 개발툴로 이클립스를 사용하다 보니 더욱더 거기서 거기가 아닐까 싶은데…)

하지만 아무래도 특수하게(그리고 빡빡하게) 정의된 XML보단 아주 유연하게 정의된 HTML 쪽이 진입 장벽이 쉽다고 생각됩니다. 그리고 이미 파이어폭스, 사파리, 오페라 등등 아주 훌륭한 에뮬레이터(?)들이 수없이 존재한다는 점은 큰 장점이죠.

안드로이드에서도 앱(웹?) 스토어를 준비하고 있고, 휴대폰 시장에서도 대동단결하여 W3C Widget을 지원할 예정이라고 하네요.

하지만 그 이면에서 생각해볼만한 문제들…

분명 HTML5는 표현에 머물러있던 HTML4를 확장하기 위해 많은 노력을 하고 있는 것으로 보입니다. 웹을 넘어 앱으로 나아가기 위한 준비에 특히나 초점을 맞추고 있는 것으로 생각되구요.

하지만 조금 생각해봤을 때 몇 가지 생각해볼만한 문제를 발견할 수 있었습니다.

HTML을 통한 Widget 개발은 쉽다. 그런데 소스 노출 문제는 어떻게?

HTML을 통한 widget 개발은 분명 쉬워보입니다. 하지만 zip이라는 아주 범용적인 압축 포멧을 사용하고 있다보니 widget을 소스로 다시 풀어내기도 쉽습니다.

제가 어떤 widget을 개발해서 판매한다고 하면 누군가 제 widget을 압축 해제하고 조금만 수정한다면 무슨 일이 일어날까요?

뒷풀이 자리에서는 이런 내용에 대해 논의해볼 수 있었고, 이런 문제 때문에 digital signature 기능이 새롭게 추가되고 있다는 이야기를 들을 수 있었습니다만 digital signature가 이 문제를 해결할 수 있을 지에 대해서는 조금 더 생각을 해봐야할 것으로 생각됩니다.

Video Tag… Open Codec은 답이 될 수 없는건가?

W3C에서 HTML5 표준화와 관련해서 난항을 겪고 있는 점 중 하나가 Video Tag에 어떤 코덱을 사용해야하는지를 결정하지 못해서라고 들었습니다.

하지만 Video tag를 보니 아래와 같이 fall back을 제공할 수 있는 구조로 되어 있었습니다.

<video width="320" height="240" controls>
  <source src="pr6.mp4"  type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"'>
  <source src="pr6.webm" type='video/webm; codecs="vp8, vorbis"'>
  <source src="pr6.ogv"  type='video/ogg; codecs="theora, vorbis"'>
</video>

다시 말해 Codec 이슈를 open codec으로 해두고, 서비스 프로바이더에서 타겟에 맞춰 알아서 파일들을 제공하면 안될까 하는 생각이 들었습니다.

사실 DMB, DVB 등의 서비스를 지원하는 장치에는 이미 H.264/AVC 코덱이 포함되어 있습니다. 이런 장치들은 이미 하드웨어 코덱을 가지고 있을테므로 (혹은 라이센스된 코덱을 가지고 있을테므로) 이와 링크된 WebView library에서 따로 라이센스를 지불할 필요는 없을거라고 생각됩니다.

OS 위에 올라가는 브라우져라면? 윈도우에서는 DirectShow를 이용하면 됩니다. 맥에서는 퀵타임을 이용하면 됩니다. 리눅스에선 Xine, vlc, gstreamer 등을 이용하면 됩니다. 이렇게 할 경우 미디어 플레이어/Quicktime/Totem 등에 코덱을 설치하게 되면 브라우져에서도 이 코덱으로 인코딩된 영상을 재생할 수 있습니다.

게다가 이 기능을 브라우져 자체에서 제공하는 것이 아니므로 따로 라이센스료를 낼 필요는 없을 것이라 생각되므로 이후 어떤 코덱이 더 많이 사용될 지는 시장의 선택에 맡기면 될 것이라 생각합니다.

WebM 코덱이 많이 사용된다면 WebM 코덱을 지원하는 Consumer Device도 점점 늘어날 것입니다. Ogg Theora도 마찬가지겠죠.

이원석 박사님께서 막차 시간 문제로 일찍 돌아가셔야 했던 관계로 이 이야기를 길게 나누지 못해 조금 아쉬웠네요.

에필로그

하여튼 오랫만에 재밌는 이야기를 나눌 수 있었던 자리였던 것 같습니다. :)

세미나 일정이 이원석 박사님의 출장 일정에 맞춰지기 때문에 다음 일정이 어떻게 될 지는 아직 잘 모른다고 하네요. 다음에도 또 재밌는 이야기들을 나눌 수 있었음 좋겠습니다.

이만 후기 끝!

p.s) 막상 써놓고 보니 제 블로그 제목대로 정말 제 맘대로만 보고 온 것 같네요.

참고 자료

1. Future Web Accessibility: HTML5 Semantic Elements
2. HTML5 articles and sections: what’s the difference?
3. Video on Web – Dive into HTML5
4. 제 2회 열린 세미나 후기

UNIX를 사용할 때 보안을 위해 가장 먼저 해야하는 행동이 무엇인지 아시나요?

답은 ‘root(슈퍼 관리자) 권한으로 사용하지 않는 것‘ 입니다.

1. 관리자 권한으로 사용하지 않는다면 시스템의 중요한 파일들이 변경될 위험을 최소화할 수 있습니다.
2. 관리자 권한으로 사용하지 않는다면 스니퍼 등은 실행될 수 없습니다.

관리자로 시스템을 사용하는 것은 매우 위험합니다. 그렇기 때문에 irc 등에선 사용자 아이디가 root인 경우 접속을 차단해버리기도 합니다.

관리자로 사용하는 것이 위험하다는 사실은 윈도우에도 동일합니다. 그렇기 때문에 얼마 전 시스템을 윈도우7 기반으로 설치하면서 약간의 불편함을 감수하고 일반 유져 계정을 만들었고, 이 계정을 통해서만 시스템을 사용하기 시작했습니다.

정말 보안에 신경을 쓰고 있는 시스템에선 사용할 수 없는 인터넷 뱅킹!

관리자 권한을 최소한으로 사용하기 위해서는 다음과 같은 불편을 감수해야만 했습니다.

1. 인터넷 뱅킹을 위해 은행 사이트에 접근하면 관리자 권한으로 ActiveX를 설치하기 위해 관리자 비밀번호를 요구합니다.
2. 인터넷 뱅킹을 위해 은행 사이트에 접근하면 관리자 권한으로 ActiveX를 업데이트하기 위해 관리자 비밀번호를 요구합니다.

물론 전 관리자의 비밀번호를 알고 있기 때문에 권한 상승을 통해 아쉽게나마 인터넷 뱅킹을 사용할 수 있었습니다.

하지만 만약 시스템의 보안을 열심히 신경쓰고 있는 어떤 관리자가 있고, 다른 가족들에게는 보안을 위해 일반 유져 권한만을 제공해주는 경우라면 어떨까요? 이 경우 관리자 외에는 인터넷 뱅킹을 사용할 수 없습니다.

재밌죠? 정말 보안에 철저히 신경쓰고 있는 경우에는 사용할 수 없는 인터넷 뱅킹이라니…

보안 등급을 *낮음*으로 설정해주세요?

게다가 관리자로의 권한 상승을 요구하는 것 뿐만이 아닙니다. 대부분의 경우 ‘인터넷 보안 등급을 *낮음*으로 설정해줄 것’을 요구합니다.

아이러니하지 않나요?

보안을 위해 사용된다고 얘기하는 프로그램을 설치하기 위해, 사용하기 위해 인터넷 보안 등급을 낮춰야 하는 상황이라니…

게다가 OS 차원에서 제공하는 보안 기능을 최대화 하기 위해 ‘일반 유져’로 시스템을 사용하고 싶음에도, 이런 보안 기능을 제대로 사용할 수 없게 ‘관리자 권한’으로 시스템을 사용해줄 것을 강요하는 상황이라니…

버그 투성이 브라우져, 버그 투성이 운영체제는 문제가 되지 않습니다.

얼마 전 h은행에서 제공한 iPhone용 app에서는 보안을 위해 jailbreak된 iPhone에서는 해당 app을 사용할 수 없도록 하고 있습니다.

왜 이런 기능은 iPhone을 위해서만 제공하고 있는걸까요?

키보드 보안 프로그램을 설치하기 전에 최소한 윈도우 서비스팩만이라도 최신 버젼을 설치할 것을 요구해야하는 것 아닌가요?

피싱 방지 프로그램, 안티 바이러스 프로그램을 설치하기 전에 버그 투성이의 인터넷 익스플로러 6대신 인터넷 익스플로러 8을 사용할 것은 요구하지는 않는걸까요? ^[1]

인터넷 뱅킹/카드 결제? 윈도우 XP를 쓰세요. 윈도우 7? Vista? 특히나 64bit 윈도우라면 우린 테스트하지 않습니다.

혹시나 64bit용 윈도우 7을 사용하신다면 우리은행 홈페이지에 접속해보시기 바랍니다. 아 그 전에 아직 북마크 하지 않은 사이트가 있다면 미리 북마크해두시기 바랍니다. XecureWeb Updater가 인터넷 익스플로러 8을 죽여버릴것이거든요.

XecureWeb Updater만 문제일까요? 며칠 전 카드 결제를 위해 어떤 사이트에서 권한 상승을 위한 비밀번호를 수십 번이나 입력했지만 결국 전 카드 결제를 더이상 진행할 수 없었습니다. 결국에 nProtect로 인해 인터넷 익스플로러가 죽어버렸거든요.

인터넷에서의 카드 결제를 진행하기 위해 제가 마지막으로 선택한 방법은 Mac OS X에 설치된 Parallel(가상 컴퓨터 프로그램)에서 실행된 윈도우 XP를 사용하는 것이었습니다. 윈도우 7이 아무리 혁신적이면 뭐하나요. 인터넷 뱅킹, 인터넷 카드 결제 뭐 하나 제대로 할 수가 없는데…

아 맞다. 무제한의 Wideband 인터넷이 아니라면 인터넷 뱅킹은 꿈꾸지 마세요.

모두들 알고 있는 사실이겠지만 국내 인터넷 인프라는 매우 훌륭합니다. 집집마다 광랜이 설치되어 있고 Nespot, Wibro 등을 통해 밖에서도 굉장히 빠른 속도로 인터넷을 이용하는 것이 가능합니다.

이런 훌륭한 인프라 덕분에 무거운 플래쉬, 고용량의 ActiveX 설치 파일 등을 전송받는 비용을 무시하고 있는지도 모르겠습니다.

하지만 국내를 벗어나 국내의 인터넷 뱅킹을 사용하기 위해서 지불해야 하는 비용은 절대 저렴하지 않습니다. ActiveX 하나를 다운받는데 수 분을 기다리게 될 수도 있고, 호텔에서 비싼 돈을 주고 구입한 인터넷 사용량을 ActiveX 하나를 다운받기 위해 사용해야할 지도 모릅니다.

그나마 ActiveX 하나를 모두 다운 받지 못하고 내가 구입한 사용량을 넘어설 경우 다시 비싼 돈을 주고 인터넷 사용량을 구매해야합니다. 다운로드는 처음부터 다시 시작될테니 앞에서 낭비된 사용량은 무의미해지겠네요.

아 해외가 아니라더라 iPhone 테터링 등을 통해 인터넷을 사용하는 경우라면 인터넷 뱅킹을 시도하지 마세요. 한 달동안 무료로 사용할 수 있는 용량이 많아보였을지 모르겠지만 이 정도 용량을 사용하는 게 얼마나 간단한 일인지 알게되는데는 많은 시간이 필요하지 않을 겁니다. ;)

병주고 (가짜) 약주고… 언제까지 이래야하는건가요?

보안을 위해 가장 중요한 것들은 하지 못하게 만들고, 그럼으로써 생긴 보안 구멍은 당신들 보안 업체가 막아주겠다? 언제까지 이렇게 병 먼저 주고, 자신들 때문에 생긴 병을 치료하기 위한다는 이름으로 가짜 약을 제공할 셈인가요?

당신들 프로그램을 설치하기 전에는 아무 문제 없던 내 윈도우 7에서 당신들 프로그램을 설치한 후로는 인터넷 익스플로러가 죽어버리고, 블루스크린과 함께 리붓되어버리는 상황이 정말 ‘까마귀 날자 배떨어진 격’인건가요?

당신들이 제공하는 그 프로그램들을 설치하기 위해, 그리고 당신들이 제공하는 그 프로그램을 설치한 덕분에 오늘도 내 윈도우 7은 골병이 들고 있습니다.

덧: ‘인터넷 뱅킹’이란 이름에 오랫동안 속아왔습니다. 생각해보니 국내 금융권에서 제공하는 ‘인터넷 뱅킹’은 ‘인터넷 익스플로러 뱅킹’을 의미한 것이었는데, 이를 ‘인터넷 뱅킹’이라고 착각한 제 무지가 부끄럽습니다.

하긴 7살난 조카가 제 리눅스 데스크탑을 사용해보더니 그러더라구요. 인터넷 어떻게 쓰냐고… 파이어폭스, 사파리로 접근할 수 있는 웹은 인터넷이 아닌걸 이제야 깨달은 제가 부끄럽네요.

1. 구 버젼의 인터넷 익스플로러(IE)가 얼마나 위험한지는 이 글의 각주 1에 링크되어 있는 글을 읽어보시기 바랍니다. [↩]

제가 번역한 책인 CSS 완벽 가이드 (원제: CSS Definitive guide)가 드디어 출판됩니다. 작년 4월 쯤에 마지막 원고를 보냈고, 얼마 전 2월 11일 최종 원고를 받았습니다. 요번 주 월요일에 인쇄에 들어가서 3월 9일쯤에 출간될 예정이라고 하네요.

원 저자는 Eric Meyer입니다. 수년 전 CSS Zen Garden과 CSS/Edge를 봤을 때가 생각나네요. CSS만으로 만들어진 이 화려한 페이지들은 테이블 태그만을 활용하고 있던 제게 신선한 충격을 안겨줬습니다. 세월이 흘러 이 분의 책을 제가 번역하게 될 줄은 상상도 못했네요.

Read the rest of this entry »