December 2007 Archives

갑자기 자다 깨는 바람에, DDJ의 지난 10월 기사인 Silverlight 1.0: Getting Started을 읽었다.

이 기사는 Silverlight의 소위 Hello, World를 수행하기 위한 과정을 설명하고 있는데, 쓸데없이 장황한 면이 있다. Microsoft가 제공하는 Silverlight 1.0 Quickstarts를 읽는 것이 나아보인다. 요점은 Silverlight 플러그인을 HTML 내에 삽입하기 위해서는 OBJECT나 EMBED/NOEMBED element를 사용하지말고, Silverlight SDK에서 제공되는 javascript(Silverlight.js)를 사용해야한다는 것이다.

한편, 요샌 RIA 기술에 별로 신경을 쓰지못해서 깨닫지 못하고 있었는데, Microsoft의 Silverlight는 XAML + Javascript(+.NET languages) 기술, Adobe의 Flex는 MXML + Actionscript 기술이 SDK와 다른 SDK들로부터의 지원, 개발 도구, 미디어 기술 등과 함께 포장되어나온 것이다. 오래 전에 강문식 군이 XAML을 가지고 놀던 기억이 난다.

Silverlight든 Flex든 XAML/MXML+Javascript/Actionscript의 장점을 고스란히 지니게 된다. 별다른 개발 도구 없이도 서버사이드에서 텍스트 파일을 살짝 수정하는 것만으로도 바로 브라우저에 UI 변경사항이 반영된다는 것이다. 기존의 RIA 기술인 ActiveX나 Flash와 비교해보면 RIA 개발 효율이 상당히 높아질 수 있을 것같다. C로 CGI를 만들던 시절과 Perl/PHP로 Web App을 개발하는 현재를 비교해보면 말이다. Web App을 만들 일이 생긴다면 한번 시도해보고 싶다.

섣불리 얘기하기는 꺼려지지만, XAML/MXML+Javascript/Actionscript들을 서버사이드에 두고 HTTP 프로토콜로 접근한다면, 이들의 용도는 한정될 수 밖에 없는 것 같다. 이를테면 중요한 비즈니스 제약들을 여기에(만) 넣을 수는 없다는 것이다. - 예전에 Flex Architecture를 흘끗 본 기억으로는 서버사이드에서 실행되는 컴포넌트 기술도 포함하고 있었던 것 같고, Silverlight를 아우르는 ASP.NET도 당연히 그러한 기술을 포함하고 있겠지만, 여기서는 Silverlight와 Flex의 핵심 기술들만 얘기하자. - 하지만, 궁극적으로는 클라이언트 상에서 동작하는 RIA 기술 자체가 그런 문제를 가지고 있는 것이지 이 기술들이 가지고 있다고 볼 수는 없는 것 같다. 실질적으로도 (적어도 현재는) RIA 기술들은 주로 Presentation 위주로 사용되며, 중요한 트랜잭션 (이를테면 신용카드 결제) 들은 다른 방법으로 (예를 들어, 서버사이드에서 실행되는 로직) 해결하는 것이 일반적인 상황인 것 같다. 다시 말하면, RIA 기술은 Presentation 위주로 사용하고, 중요한 비즈니스 로직은 서버사이드에서 실행하는 식으로 이러한 문제는 해결되고 있는 것 같다. 다른 해결책도 물론 있다. 정말 필요하다면 암호화와 신뢰를 보장하기 위한 보안 모델을 사용할 수도 있다. 이 방법 역시 ActiveX에서 사용하고 있는 것이다 (ActiveX의 인증서!). 하지만, 사람들은(개발자든 사용자든) 보안으로 인한 비용들(귀찮음이든 개발 비용이든)을 별로 좋아하지 않는다는 것이 이 방법의 문제점이다.

잡설이 길었다. RIA 기술들의 실제적인 필요성은 점점 부각되고 있다. Microsoft와 Adobe가 열정적으로 RIA 기술을 지원하고 있으며, 특정 부문에서 이들을 대체할만한 기술 (e.g. HTML 5)이 단기간 내 - 3년 내에 - 나오기는 하더라도 - 성숙하기는 힘들지 않을까 예상된다. 이런 환경에서 RIA와 관련이 없는 개발자라고 하더라도 Silverlight 또는 Flex는 한번쯤 주목해볼만한 기술일 것이다. 과연, 어느 쪽이 주도권을 잡을 것인가? 어쩌면 HTML 4일지도. 후훗.

부록 1: Silverlight는 Microsoft의 구현 만 있는 것이 아니라 Mono 팀의 구현인 Moonlight도 있다.

부록 2: XML의 응용인 XAML보다 IronRuby를 이용한 Silverlight DSL이 훨씬 읽기편하고 예뻐보인다. 인간이 읽고 써야하는 선언적 코드(e.g. Configuration, Markup, Schema, ...)에서 XML보다는 Agile 계열의 언어를 활용한 DSL을 사용하는 프랙티스들이 요즘 많이 나오고 있다. 아직은 실험적인 단계라고 해야겠지만, 내겐 긍정적으로 보인다.

최근 들어 삶이 그다지 유쾌하지 않음을 느껴, 문제점들을 나열해보았다.

• 피곤해서, 작업 관리에 소홀해지고, 업무 집중도가 현저하게 떨어졌다.
• 야근이 너무 잦고 쓸데없이 길다.
• 책을 읽는 양이 한 달에 한 권 이하로 줄어들었다.
• 공부를 하는 시간이 없다.
• 체중이 늘어나기 시작했다.

이러한 문제들에 대해 다음과 같은 fix를 적용하기로 했다.

• 스트레스 컨트롤을 할 것.
• 출근 후 작업 체크를 정확히 하고, 작업 로그를 좀 더 엄격히 남길 것.
• 가능한 한 야근을 하지 않도록 하고, 야근 시간의 threshold를 정할 것.
• 의식적으로 책읽는 시간을 배정하고, 책읽기 로그를 다시 적을 것.
• 공부할 주제나 책을 정해 집중적으로 하고, 스터디나 블로깅을 활용할 것.
• 저녁 식사는 회사에서 하지 말고 가능한 한 간단하게 할 것.

일반적으로 여러 DBMS 벤더 별로 플랫폼 또는 언어에 따라 접근할 수 있는 서로 다른 API들을 제공한다. 이들을 한꺼풀 덮어씌워 공통적인 방법으로 접근하도록 해주는 API를 Database Access Layer 또는 Database Abstraction Layer라고 부른다.

JDBC, ODBC, ADO.NET, Perl의 DBI, PHP의 PDO, Pear::MDB2 (Pear::DB, Pear::MDB) 등은 모두 Database Access Layer에 해당하는 것들이다. 각자 특정 플랫폼 또는 프로그래밍 언어에서 표준적인 위치를 가지고 있다. 물론 이외에도 이들과 경쟁하는 API들이 있으며, 이 외의 플랫폼 또는 언어들도 이러한 API를 가지고 있다.

Jeremy Zawodny는 LtU에서도 이슈가 된 모양인 Database Abstraction Layers Must Die!라는 글에서,

• 성능을 떨어뜨리고 복잡도를 증가시킨다.
• 데이터베이스를 쉽게 바꿀 수 있다는 이점은 별로 중요하지 않으며, 실제로는 쉽게 바꿀 수 없다.
• 데이터베이스 기능을 완전하게 활용할 수 없고, 튜닝도 제대로 할 수 없다.

는 점에서 Database Abstraction Layer를 사용하기 보다는, 데이터베이스에 접근하는 부분을 '라이브러리'를 사용해서 모듈화하고, 만일에 하나라도 데이터베이스를 변경할 일이 생긴다면, 이를 수정하면 된다고 설명하고 있다. 그의 주장은 일견 옳다.

이 외에도

하지만, 여러 사람이 지적한대로, 그가 얘기하는 '라이브러리'가 바로 Database Abstraction Layer다. 그리고,

• 성능은 떨어질 수 있지만, scalability도 떨어지는 것은 아니다.
• 여러 데이터베이스를 지원해야하는 소프트웨어도 존재한다.
• 하나의 소프트웨어에서 데이터베이스를 바꾸지 않더라도, 프로그래머는 여러 소프트웨어에서 서로 다른 데이터베이스를 접근해야한다.
• Database Abstraction Layer 라기보다는 Database Access Layer다. 즉, 데이터베이스의 공통적인 기능에는 공통적인 방법으로 접근할 수 있도록 하지만, 특정한 데이터베이스가 지원하는 기능을 접근하도록 만들 수도 있다.

는 면에서 Database Access Layer는 유용하다.

JDBC를 예로 들어보면,

• 많은 Java 프로그래머들은 특정 데이터베이스 API를 익힐 필요없이 JDBC만을 알아도 데이터베이스에 접근하는 기본적인 프로그램을 짤 수 있다.
• 특정한 데이터베이스가 지원하는 대부분의 기능은 SQL이라는 불투명한 데이터를 전달하는 API를 통하거나, 설정을 통해 동작방식을 제어하는 방식으로 접근할 수 있다.

'왜 PHP 개발자들은 Pear::MDB2 또는 PDO를 아직 사용하지 않는가'라고 물어보면 분명 위와 같은 이유로 반대하는 사람들이 많을 것이라고 생각한다. 이 글이 그에 대한 대답이다. 그리고 한가지 더, JDBC, ODBC, ADO.NET, Perl DBI 등의 성공은 결정적으로 Database Access Layer의 유용함을 반영하고 있다. JDBC를 한번이라도 사용해본 사람들이 PHP의 mysql이나 mysqli 모듈로 돌아갈 것이라고 절대 상상할 수 없다.

Microsoft의 MapReduce라고 부를 수 있는 Dryad의 Google Tech Talks 비디오를 보았다.

MapReduce와의 가장 큰 차이점은 acyclic graph 모델을 사용한다는 것이다. 강연에서는 계속 optimization에 관해 얘기하는데, 내가 가장 궁금한 점은 이러한 프로그래밍 모델이 사용자에게 어떻게 보일 것인가 하는 것이다. 분명 acyclic graph 모델이 유용하게 쓰일 수 있는 경우는 있을테지만, 너무 복잡한 프로그래밍 모델은 현실적으로 많은 프로그래머가 접근하지 못하게 만든다. 게다가 acyclic graph 모델이라는 아이디어 자체는 그리 새로운 것은 아니다. MapReduce 페이퍼에서도 인용하고 있는 Condor가 훨씬 generic한 분산 환경이다.

요즘 팀에서 주로 하는 일이 대용량 데이터 처리다보니 이런 문제들에 대해 많이 고민하게 되는데, 현재는 단순한 파이프라인 (정확히는 Pipeline & Filter) 모델을 분산된 멀티프로세서 환경에 최적화하면서, 동시에 사용자가 쉽게 프로그래밍할 수 있는가를 고민하고 있다. 물론, 후자가 더욱 어려운 일이다.