Software Development

현재 하고 있는 일이 간단한 웹 어플리케이션을 만드는 일이라 apache + mod_ruby를 사용하고 있는데, 그냥 단순히 apache + CGI + ruby를 사용하는 것에 비해서도 좋지 못한 선택이 되고만 것 같습니다.

라이브러리 등에 이미 존재하는 클래스를 override할 수 없는 문제라든가 HTTP header와 관련해서 시키는대로 했는데도 불구하고 제대로 동작하지 않아서, Apache Runtime에 접근해서 직접 조작해주어야 하는 짜증스러움이 있군요.

아햏햏한 문제는 또 있습니다. 다른 개발자가 항상 사용할 수 있어야하기 때문에, 테스트 버전과 개발 버전을 하나의 apache 서버에서 돌리고 있습니다만, 하나의 버전에 접근한 후 다른 버전에 접근하면 알 수 없는 에러가 발생합니다.

nohmad 옹에게 문의해보니 대뜸 mongrel + Nitro + Og + amrita2을 쓰시라고 하시는군요. 굳이 Nitro나 amrita는 아니더라도, 일단 mongrel이나 webrick 같은 ruby로 된 web server를 사용해보는 것도 괜찮을 것 같습니다. RoR과 같은 web application development framework를 선택하지 않은 것은 DB를 쓸 정도로 복잡한 어플리케이션이 아니었기 때문이었는데, 차후에 DB를 사용할 필요가 생기면 그 때 정도에 고려해도 무난할 듯 하군요.

온라인 구독권을 판매하던 DDJ가 어느새 온라인으로 기사를 공개하는 정책으로 선회했나봅니다. PDF Issue Archive 까지도 제공합니다. CUJ는 폐간되고 DDJ로 흡수된 건 알고 계시죠? 따라서, The New C++ 과 같은 칼럼도 전부 DDJ에서 볼 수 있게 되었습니다.

대전에 내려가있는 동안, 구독을 온라인 구독만 하고 있었는데, 다시 종이로 구독을 시작했습니다. ;-)

Talking about logging libraries

3rd party logging 라이브러리를 사용하든 직접 만든 logging 라이브러리를 사용하든, 사용하고있던 logging 라이브러리를 다른 것으로 바꾸기는 매우 힘든 일이다. logging의 특성상 logging 라이브러리의 API가 사용된 곳들이 어플리케이션 전체에 걸쳐 얇게 퍼져있기 때문이다. 그렇다면, logging 라이브러리를 사용하지 않거나, 항상 하나의 logging 라이브러리를 사용하면 문제는 해결되지 않을까?

현실은 그리 녹록하지 않다. 일단 logging은 trivial 하지 않은 어플리케이션을 개발할 때는 거의 필수적인 요소 중의 하나다. 또한, 여러 프로젝트를 하다보면 항상 하나의 logging 라이브러리를 쓰라는 법도 없다.

Logging libraries in Java

Java와 같은 platform의 경우에는 상대적으로 운이 좋은 편이다. Java 프로그래머라면 누구나 들어보았을 log4j라는 logging 라이브러리가 어느 정도 de facto standard 수준의 위치를 점유하고 있었기 때문이다. 심지어 다른 여러 언어로 porting 되기까지 했을 정도다. (log4c, log4cpp, log4r, log4cxx, log4net, log4perl, log4php)

하지만, Java에서도 logging 라이브러리의 편재화 현상은 나타나고 있는 듯 하다. 가장 큰 주범은 Java logging 라이브러리를 표준화하기 위한 노력으로(?), Log4J를 Java API 안으로 편입시킨 java.util.logging package를 들 수 있다.

사실 logging 라이브러리의 requirement는 어느 정도 정리되어있고, 따라서, 여러가지 라이브러리를 사용함으로써 얻는 이익은 거의 없다고 봐도 무방하다. 게다가, 여러가지 라이브러리가 존재하고 서로 다른 프로젝트를 할 때마다 각각을 새로이 배워야하는 것은 불필요한 노력이다. 이런 문제에 대한 근본적인 해법은 바로 표준을 만드는 것이다. 이미 존재하는 여러가지 대안들까지도 끌어안을 수 있기도 해야할 것이다. 사실 java.util.logging의 의도도 원래 선하고 순수한 것이었겠지만, 결과적으로는 사실상 두가지의 안이 혼재하는 상황이 벌어지고 말았다.

더욱 나쁜 것은 이 두가지 라이브러리들의 facade 역할을 하는 라이브러리들도 등장하기 시작했다는 것이다. 그 중의 하나가 요즘 사용해보고 있는 SLF4J이고 다른 하나는 Jakarta Commons의 Logging 컴포넌트 (JCL)이다.

SLF4J

Simple Logging Facade for Java (SLF4J)는 위에서 언급했던대로, 여러가지 logging 라이브러리들의 facade에 해당한다. SLF4J 역시, log4j와 마찬가지로, level과 section 개념, 유연한 Handler/Formatter 구조를 가지고 있어, 기본적인 logging 라이브러리의 requirement를 만족할 뿐만 아니라, java.util.logging이나 log4j와 같은 logging 라이브러리를 wrapping 하고 있다. 물론 SLF4J의 API를 그대로 구현한 NLOG4J와 같은 native 구현들도 존재한다.

SLF4J의 API로부터 backend가 되는 logging 라이브러리의 API로의 mapping은 static하게 이루어진다. 그래서, wrapping 하고 있는 logging 라이브러리에 맞는 SLF4J 바이너리를 어플리케이션의 classpath에 넣어줄 필요가 있다. Dynamic하게 binding함으로써 쓸데없이 잃게 되는 성능을 생각하면 그리 커다란 문제는 아니다.

한가지 아쉬운 점은 logging level이나 handler 설정을 위한 설정 파일을 통합하고 있지는 않다는 것이다. 그래서, backend가 되는 logging 라이브러리의 레퍼런스를 찾아볼 필요가 생긴다는 귀찮음이 있다.

What a mess?

log4j, java.util.logging, JCL, SLF4J, … Java community가 왜 이런 짓을 하고 있는지 잘 이해가 가지 않는다. 더구나, C++ community에 표준 라이브러리의 중요성을 깨닫게 해준 Java community에서 말이다.

ZDNet Korea의 검색포털, 그들이 한 곳에 모였다! 1부 기사에 대한 요약.

상식 수준의 얘기네요. 적당히 용어를 수정하고 편집했습니다. 따라서, 내용이나 의도가 완벽하게 기사와 일치하지 않을 수 있음을 미리 경고드립니다.

용어 수정 내역: 검색 서비스/검색 엔진, 한국/외국(미국, 구글), 웹(오픈 웹), 컨텐트(데이터), 사용자(유저), 요구(니즈)

최근에는 del.icio.us를 쓰고 있는데, 기존에 쓰던 링크 블로그 데이터만 덩그러니 남겨두기가 뭐해서, 간단한 ruby 스크립트를 짜서 데이터를 이전했습니다. 아시는 분은 아시다시피, MovableType은 Blogger API와 MetaWeb API 뿐만 아니라, 최근에는 Atom Publishing Protocol까지 지원하고 있고, del.icio.us는 Web 2.0 계의 대표적인 서비스답게 del.icio.us API를 제공하고 있습니다. Blogger API와 MetaWeb API들은 MovableTypeWriter를 개발하면서 사용했었기 때문에 익숙했지만, del.icio.us의 API는 처음 보았습니다. XMLRPC나 REST 계열의 API만 보다가 HTTP GET을 사용한 API를 보니 좀 특이하더군요. (개인적으로는 그리 마음에 들지 않습니다.)

결과를 보시고 싶은 분은 제 del.icio.us 페이지를 한번 방문해보시죠. 반나절 정도의 노력을 들여서 완전히 다른 종류의 서비스 사이에서 데이터 이전이 가능하다는 것, 멋지지 않습니까?

다음은 migration에 사용한 코드입니다.

이미 어느 정도 소문이 돌고 있습니다만, YES24 웹페이지에 악성 코드(로 접근하는 코드)가 들어가있습니다. CHM을 scriptlet으로 실행하도록 하는 코드로 추정되고, IE로는 접근하지 않아야할 듯 합니다. (Firefox로는 문제가 없으리라고 생각되는군요.)

자세한 분석은 룸메이트인 처로(irtiger)군이 KLDP에 올려놓았습니다.

주의!! yes24 탑페이지 html 소스에 악성코드 박혀있습니다.

Update: 오늘 오후 5시 경에 수정되었고 현재는 관련한 문제가 없는 것으로 보입니다.

Gtalkr

Macromedia Flash는 상당히 보편화 되어있기 때문에 Macromedia 계열의 기술들(e.g. Flex)을 RIA 플랫폼의 유력한 후보로 저는 보고 있습니다만, 한번 더 이를 증명할만한 서비스가 나왔군요. 특히 Google SIG 3차 미팅에 관한 글에서 언급한 (특히, 실시간) 메시징에 관련한 어플리케이션이라서 더욱 인상적이군요. 미팅에서 남세동님은 Microsoft를 유력한 후보로 보시는 듯 했지만, 제 생각에는 Microsoft가 특별한 행보를 가지 않는한 ActiveX로 이러한 제품이 나올 가능성은 매우 낮다고 생각합니다.

Google Talk가 이미 데스크탑 어플리케이션으로 존재하는 데 굳이 웹 어플리케이션으로 나와야할 이유에 대해 의아해할 분이 계실지 모르겠는데, 어떤 사람들은 여러 장소에서 메시징을 할 필요가 있고, 따라서 대화 내용과 같은 정보나 Extension과 같은 확장 기능을 여러 장소에서 접근할 필요를 느낀답니다. (저 같은 경우, 정보를 생산/교환하는 대부분의 어플리케이션이 웹에서 동작할 필요를 느낍니다.) 이러한 면에서 Gtalkr 같은 웹 기반 메시징 서비스는 충분한 가능성이 있다고 생각합니다.

Gtalkr은 IME 관련된 문제인지 한글 입력에 좀 문제가 있고, 좀 느린 편이지만, 사용성은 웹 표준 기술로만 만들어진 것(e.g. MSN Web Messenger)보다 훨씬 낫다는 것을 생각하면, 역시 경쟁력이 있다고 생각합니다. 자체적인 Extension API가 존재한다는 것도 상당히 인상적입니다.

자세한 내용은 lunamoth님의 Gtalkr 리뷰를 참고하시기 바랍니다.

그저께, Google SIG in KAIST의 네번째 모임이 있었습니다. 모임 전에 첫눈의 기획팀장이신 남세동 님이 오셔서, 검색 서비스의 의미와 동향, 기초 기술, 앞으로의 도전 과제 등을 강연하셨습니다만, 아쉽게도 저는 참석하지 못했습니다. (개인적으로 발표 자료는 받아보았습니다. :) ) 남세동님도 서울에서 꼬박꼬박 내려오셔서 Google SIG 미팅에 참석하고 계시죠.

이번 미팅의 주제는 Google의 서비스 지도 그리기였습니다만, 내용은 주로 Google의 미래와 서비스에 있어서의 광고의 역할과 가능성에 관한 것이었던 것 같습니다. (물론 서비스 지도 그리기 자체의 목적과 부합한다고 생각합니다만.)

Google SIG 4차 정기 미팅 회의록

Google의 미래

이번 미팅에선 옆에 앉으신 남세동 님과 노닥거리느라 생각이 정리되지않은 채 거의 횡설수설했습니다만, Google의 미래에 대한 제 생각은, Google이 모든 (인터넷) 정보 서비스에 대한 플랫폼을 제공할 가능성이었습니다.

현재 Google은 정보의 생산에서 소비에 이르는 모든 부문에 관심을 갖고 있는 것이 분명합니다. 높은 수준에서의 서비스 뿐만 아니라 하위 인프라에 이르기까지 정말 방향성이 없어보일 정도로 많은 것을 하고 있죠. Google이 모든 서비스와 데이터베이스를 독점할 의지 또는 능력을 가지고 있다고는 생각하지 않습니다. 결국, 많은 사람들과 기업들은 자신의 서비스나 정보를 가지고 Google과 협업하는 과정에서, Google이 제공해주는 서비스와 인프라에 익숙해질테고, 이 때 Google이 구축해놓은 정보의 생산-가공-소비에 이르는 플랫폼에 대한 경쟁력을 갖게된다는 것이죠. Google이 현재 가지고 있는, 또 만들어 낼 서비스와 데이터베이스는 플랫폼 구축의 수단에 불과할 수 있다는 것입니다. 3차 미팅 때도 얘기를 했습니다만, Google Base의 의미를 이러한 면에서 짚어볼 수도 있습니다. 즉, 모든 상위 서비스의 인프라로서의 역할이죠.

이러한 Google의 미래는 Microsoft의 과거를 되짚어볼 때 매우 설득력이 있다고 생각합니다. Microsoft의 Windows가 어플리케이션 시장의 플랫폼을 장악한 배후에는 Windows 상에서 동작하는 Office나 Visual Studio, DirectX와 같은 강력한 어플리케이션과 인프라가 있었습니다. 물론 Microsoft가 모든 어플리케이션이나 모든 게임을 만든 것은 아닙니다. 하지만, Visual Studio와 같은 개발도구를 사용한 좋은 어플리케이션과 DirectX를 사용한 좋은 게임들이 존재하는 Windows라는 플랫폼의 경쟁력을 무시할 수 없게된 것입니다. Apache와 Linux의 서버 시장 장악의 예를 들 수도 있을 것 같군요. (현재는 이 역시 Windows라는 플랫폼의 lock-in효과로 알 수 없게 되어버렸습니다만.)

Google은 자신이 원한다면 얼마든지 서비스 회사로 남을 수 있습니다만, 서비스와 데이터베이스, 인프라가 플랫폼의 장악으로 이어질 수 있는 가능성은 Google이 선택할 수 있는 기회 중 하나입니다.

정보 서비스에 있어서의 광고의 역할

광고는 기존의 여러 매체에 있어서 중요한 수익 기반이 되어왔고 그러한 경향이 인터넷 매체에서도 마찬가지일 것이란 것이 이번 미팅의 중론이었습니다. 아직도 텍스트 광고와 배너 광고, 기껏해야 플래시 광고가 주류를 이루는 인터넷 매체를 통한 광고의 가능성은 아직 사람들이 막 상륙한 신대륙이라고 생각됩니다. 아직 나이든 세대가 기존 매체에 익숙하다는 사실은, 오히려 앞으로 인터넷 매체를 통한 광고가 상당히 밝은 시장이란 것을 반증해주기도 합니다. 물론, 정보 서비스를 비롯한 인터넷 매체의 형태가 아직은 매우 초보적인 단계이고 무한한 가능성을 가진다는 점도 또다른 이유가 될 것 같군요.

인터넷 매체에서의 광고의 중요성은 반대로 생각해서, 광고를 좀 더 많은, 좀 더 구매력 또는 구매 의지를 가진 사람에게, 좀 더 자주 구매로 연결될 수 있도록 해주는 인터넷 서비스가 성공할 것이란 결론으로 이어질 수 있습니다.

Google Ad-Sense의 성공이나 Overture의 한국 시장 장악은 이미 그러한 사실을 증명해주고 있습니다. 이러한 면에서 생각해본다면, 인터넷 매체에서의 “서비스의 분화”는 매우 당연해보입니다. 신문이나 TV를 접할 때, 소비자들은 수동적으로 광고를 접할 수 밖에 없고, 또한 광고주는 어떤 소비자를 대상으로 할 수 있는 가에 대한 정보가 거의 없습니다. 하지만, 인터넷 매체의 경우 소비자는 얼마든지 자신이 원하는 서비스를 찾아갈 수 있는 능동성을 가지고 있습니다. 결국, 분화된 서비스는 분화된 사용자-소비자를 낳고, 광고주는 불특정 다수에게 광고하는 것보다는 소비자의 구매 능력 또는 의지를 좀 더 자세히 알 수 있는 서비스를 선택할 가능성이 높습니다. 예를 들어, 게임 관련 정보 서비스에서 최신 게임에 대한 광고를 하는 것은 구매로 관련될 가능성이 매우 높다고 볼 수 있습니다. 소비자가 그 서비스에 들어오는 즉시, 그 소비자는 게임에 관심이 있다는 것이 밝혀지니까요. 물론, 소비자가 사용하는 정보(이를테면 게임 장르, 유사도)에 따른 세부적인 전략이 얼마든지 가능합니다.

결국, 단지 많은 사람이 원하는 서비스를 만들겠다는 생각만 하는 것은 부족할 수도 있다는 것입니다. 따라서, 인터넷 서비스를 기획할 때는 사용자 뿐만 아니라 광고주를 어떻게 만족시켜줄 수 있는가까지도 신경을 써야합니다.

지난주 화요일에 Google SIG in KAIST의 3차 정기 미팅이 있었습니다. 여러가지 얘기를 나누었지만, Google Base의 의미, RIA의 미래, Mobile에서의 가능성, Portable Reputation의 구현 가능성에 대한 얘기가 흥미로왔습니다. 이 토론을 하면서 제 생각도 많이 정리가 되었던 것 같습니다.

Google SIG 3차 정기 미팅 회의록

Google Base의 의미

이 블로그에 적었던 Google Base의 함의, 즉 Google Base는 semantic을 가진 정보의 수집에 대한 Google의 의지라는 얘기를 미팅에서도 했습니다만, Google Base는 말 그대로 모든 상위 서비스의 하위 서비스가 될 수 있지 않을까 하는 생각이 모임 중에 문득 들더군요. 예를 들어, Job offer에 대한 정보들이 Google Base에 충분히 축적된다면, 그것을 사용해서 Job offer에 대한 서비스를 만들어낼 수 있다는 것입니다. 반대로, Job에 대한 서비스를 만들고 싶다고 한다면, Google Base는 그런 서비스가 기본적으로 제공해야할 기능들 – semantic을 가진 정보의 생산에서 소비에 이르는 과정에 필요한 기능들을 가지고 있기 때문에 Google Base를 기반으로 해서 서비스를 만들 수 있습니다. 다시 말해서, Google Base는 모든 정보 서비스의 플랫폼이 될 수 있다는 것입니다. 물론, 사람들이 Google Base의 경쟁 대상으로 얘기하는 ebay와 같은 e-Commerce 서비스도 Google Base로부터 만들어낼 수 있겠죠.

RIA의 미래

AJAX가 richer한 user experience를 만들 수 있도록 해준 것은 사실이지만, 부족한 것도 사실입니다. 남세동 님을 개인적으로 만나면서 나눈 얘기입니다만, 현재 웹 환경에서의 양방향성과 실시간성의 부재는 매우 중요한 한계라고 생각됩니다. 남세동 님은 네오위즈 초창기에 세이클럽을 (말그대로) 기획/개발하신 분입니다. 네오위즈 내부에서는 세이클럽의 경쟁 우위 중 하나를 바로 웹환경에서의 양방향성과 실시간성으로 보고 있습니다. 세이클럽은 이를 위해서 Java applet을 이용해 사용자와의 connection을 유지하는 방법을 사용했습니다. 세이클럽의 applet은 매우 훌륭하게 작동했습니다. (이후에 세이클럽의 Java applet은 ActiveX로 바뀌었습니다.) 사용자 간의 interaction에 있어서 양방향성과 실시간성은 상당히 중요한 요소였던 거죠. 당시의 채팅들이 대부분 HTML Form을 사용했었던 것을 기억하시는 분이 얼마나 있을지 잘 모르겠습니다만, 이 후, 한국의 대부분의 서비스들이 사용자간의 interaction을 위해서 ActiveX를 채용했습니다. 현재까지도 이를 대체할만한 표준 기술은 없는 것이 사실입니다.

이는 물론 웹 환경의 기본 프로토콜이 HTTP이고 이 프로토콜이 Request-Response 모델이라는 것에 기인합니다. 웹의 성공이 이 모델의 단순성에 기인했으며, 그 한계도 이 모델에 기인한다는 것은 재미있는 일이죠. 결국, 웹 환경에서 notification을 구현하려면 polling을 사용할 수 밖에 없습니다. MSN Web Messenger가 이러한 가능성을 보여주었지만, 충분한 사용성을 보여줄 수 있는가에 대해서는 의문이며 (개인적으로 이것에 관한 실험에 관심이 많습니다), 높은 실시간성이 필요한 경우에는 역시 부족합니다.

앞으로의 대안은 여러가지가 될 수 있겠지만, 현재까지의 기술 흐름을 볼 때, 사용과 개발이 단순하면서도 충분히 실용화된 기술이 미래를 지배하게 될 것 같습니다. 그리고, Microsoft나 Macromedia가 이를 가장 잘 이해하고 있으며, 열심히 이를 추구하고 있을 뿐만 아니라 시장을 점유할 가능성이 높아 보입니다. (이 글을 참고) 하지만, 어느 이상한 대학생이 만들어낸 일견 보기에 허름한 기술이 어플리케이션 세상을 지배하게 될 지는 아직 모르는 일이죠. ;-)

Mobile device에서의 가능성

Mobile device 세계는 제 관심사에서 상당히 벗어나 있습니다만, Mobile device에서의 서비스 가능성은 두가지 측면으로 바라볼 수 있을 것 같습니다. 즉, Mobile device에서만 생산할 수 있는 정보와 Mobile device에서만 배급-전달할 수 있는 정보의 결합이죠. 예를 들어, 지나가다가 뉴스거리가 될만한 사진을 찍는 것은 정보의 생산 측면이고, 이러한 뉴스를 신문사로 바로 보낼 수 있는 것은 정보의 배급 측면입니다. Mobile device에서만 생산/배급할 수 있는 정보에는 이렇게 즉시성을 필요로 하는 정보 뿐만 아니라 GPS나 RFID와 같이 오프라인 환경과의 점접 역할에 관련된 것도 있습니다. 이러한 시각으로 바라본다면 Mobile device에 Web 2.0의 특징들을 또다시 조합해서 좋은 서비스를 만들어낼 수 있지 않을까요?

Portable Reputation의 구현 가능성

Universal한 Reputation system을 만들 수 있는가라는 문제에 대해서는 저는 상당히 회의적입니다. 왜냐하면 Reputation은 항상 평가에 기반하고 있고, 평가의 기준은 다양하기 때문입니다. 설령 분류를 통한 평가의 criteria을 통일 가능하다고 하더라도 서로 다른 평가가 어느 정도의 중요성을 가질 수 있는가는 다시 어려운 문제입니다. 결국 평가에 대한 평가가 필요하게 되는데, 이것은 서비스 boundary를 넘어갈 때 매우 어려운 문제가 될 것이라고 생각합니다. (하나의 서비스 내에서는 성공한 사례들이 있습니다.) 결국 앞으로는 서로 신뢰할 수 있고 협동하는 한정된 수(2~10)의 서비스 사이에서 Reputation을 공유하는 형태가 될 가능성이 가장 크다고 생각되는군요.