Martin Fowler, Prefer Design Skills
소프트웨어 개발자를 고용할 때, 플랫폼 지식(platform knowledge) 보다 여러 영역에 걸친 디자인 능력(broad design skill)을 중요하게 보자는 얘기다. 디자인 능력을 갖춘 사람이 플랫폼 지식을 가지기 쉽지만 그 역은 쉽지도 않고 확실하지도 않기 때문이라고 얘기한다.
물론 그가 플랫폼 지식의 중요성을 간과하는 것은 아니다. 여기서 그가 가정하고 있는 것은 바로 배우려고 하는 욕구(desire to learn)와 배우는 능력(learning skill)이다.
Egoless Programming이란 개념은 얼마전에 한국어로도 번역된 Gerald Weinberg의 The Psychology of Computer Programming에서 등장한 개념이다.
간단하게 얘기하면, 프로그래머라면 누구나 자신의 프로그램에 대한 애착을 가지고 있는데, 이 때문에 프로그램에 대한 비판을 받아들이지 못하는 것은 피해야한다는 것이다. 사실 프로그램 뿐만 아니라 지식 노동자의 모든 지적 작업의 결과물에는 이러한 경향이 있을 것이라고 생각한다.
팀 환경에서 프로그램에 대한 애착은 나쁜 영향을 미치게 된다. 코드가 아닌 사람을 향하는 비판 때문에 감정을 상하게 되고, 감정이 상할 까봐 비판을 하지 않게 되는 현상이 일어난다. 다른 사람의 잘못을 지적하기가 또는 받기가 두려워서 서로 협력하는 것에 미온적이거나 미루게 된다. 아예 협력하지 않기 위해서 했던 일을 새로 하기도 한다. 코드 리뷰나 회고 같은 활동도 정상적으로 할 수 없다.
이러한 문제는 Ego가 강한 한 개인의 문제라기보다는, 팀 문화의 문제라고 생각한다. 어떤 잘못이 있을 때 원인과 해결 방법에 집중해서 논의가 일어나기 보다는 그 사람의 성격 탓으로 돌리는 행위나 감정을 자극하는 언행들이 팀원 하나하나로부터 조금씩 보이면서 팀의 문화로 형성되는 경향이 있는 듯하다.
이를 방지하기 위해서는 팀 형성 초기 단계부터 세심하게 신경을 쓸 필요가 있다. 의식적으로 팀원의 언행을 살피고 Egoless Programming에 반하는 언행이 보일 경우, 그것을 바람직한 방향으로 수정해주는 것이 필요하다. 누군가가 잘못을 했을 때, 우리는 그에게 잘못을 추궁하는 것이 아니라 더 좋은 방법을 찾고 있다고 얘기해주어야 한다. 애초에 굳이 필요하지않다면 누구의 잘못인가를 공개적으로 찾아보는 행위도 나쁘다. 문제의 내용이 제대로 밝혀졌다면 누구의 실수 였는지는 고의적으로 모호하게 하는 방법도 생각해 볼 만하다. Egoless Programming에 익숙해질 수 있는 코드 리뷰나 회고 같은 활동도 유익한 것 같다. 실제로 코드 리뷰를 해보기 전엔 모두들 그것이 서로에게 감정적인 상처를 줄 것이라고 생각하지만, 적절하게 진행하기만 하다면, 그것이 자연스러울 수 있고 팀원들간의 신뢰를 높여줄 수 있는 방법임을 깨달을 수 있다.
신입 개발자일수록 팀이 어떻게 동작하는 것인지를 잘 이해하지 못하고 있으며 Ego도 강한 편이다. 이러한 점을 말로 지적하는 것도 필요하긴 하겠지만, 경험이 부족한 상태에서 주어진 규칙이란 것은 교장 선생님의 훈화 같은 것이나 다름없다. 오히려 권위가 있는 직책의 개발자나 경험이 많은 개발자가 모범을 보여주는 것이 좋은 것 같다. 그러한 것이 바로 잘 형성된 Egoless한 팀 문화다.
Ten Commandments of Egoless Programming이란 글은 Egoless Programming을 위한 좋은 가이드라인이니 읽어보기 바란다.
다음은 Paul Graham의 글, Holding a Program in One’s Head의 요약입니다.
프로그래밍을 잘하려면, 프로그램 전체를 머리 속에 담아두어야 한다. 이를 위해서는 다음과 같은 규칙이 도움이 된다.
이 항목들을 지키는 것은 일반적인 프로그래머로서는 쉽지 않다. 신기하게도 이러한 항목들에 맞아떨어지는 것은 비공식적인 개인 프로젝트에서 우연히 이루어진다. 반대로 공식 프로젝트에서는 위의 항목 모두를 만족시키지 못하는 경우도 있다.
이는 개인을 부품으로 보는 것이 미덕인 조직의 특성 자체에 기인한다. 프로그램은 바로 생각인데, 생각(idea)는 분업할 수 있는 것이 아니다. 조직이 프로그래머가 갈구하는 것을 막는다 하더라도 좋은 프로그래머들은 많은 것을 해낼 수 있다. 하지만 그러기 위해서는 종종 조직에 대해 반항하는 행위를 필요로 한다.
좋은 프로그래머들이 혼자서 일하기를 좋아하는 것은 그들이 비우호적이어서가 아니다. 그 이유는 바로 프로그램을 머리 속에 담아두어야 하기 때문이다. 이 점을 이해하는 것은 어떤 조직에도 도움이 되겠지만, 큰 회사들은 프로그래머 개개인이 커다란 일을 하게 놔두지 않기 때문에, 그들의 경쟁자, 스타트업이 비집고 공격할 수 있는 구석이 된다. 하나의 뛰어난 두뇌 (one big brain)에서 풀어야 할 문제를 찾아라.
Software Engineering 수업에서 Software Crisis를 언급하면서 소프트웨어 프로젝트의 성공율은 극히 낮다는 얘기를 한번쯤은 들어보았을 것이다. 그렇다면 소프트웨어는 언제 성공했다고 얘기할 수 있을까? DDJ 2007년 10월호의 ‘Defining Success‘라는 글은 소프트웨어 IT 종사자들의 프로젝트의 성공에 관한 관념을 조사한 결과를 보여준다.
조사 중 하나는
라는 설문이었는데, 평균적으로 전자의 대답이 다수를 차지한다.
절대적인 수치보다도 재미있는 사실은, 관리자나 주주들에 비해 소프트웨어 프로젝트의 최전방에 있는 프로젝트 관리자는 전자를 택한 비율이 현저히 낮다는 점이다. 어째서 이런 역설적인 결과가 나올까? 이 글에서는, 그 이유가 조직의 보상 체계에 있을지도 모르겠지만, 그게 사실이라면 왜 관리자의 결과와 align되어있지않을까 하는 의문을 던진다.
일반적인 IT 조직 구조 특성상 ROI와 같은 상위 목표는 상급 매니저가 고민하고 미리 결정하기 마련이고, 프로젝트 매니저들에게는 하위 목표인 스케줄과 예산만 주어질 뿐이기 때문에 이러한 결과가 나온 것 같다. 하지만, 조직 구조상의 문제에도 불구하고 주어진 목표를 그대로 수용하는 프로젝트 관리자보다 ROI, 품질과 스케줄, 예산 사이의 밸런스를 고민하는 프로젝트 관리자가 훌륭한 관리자임은 말할 것도 없다.
어젯밤에 Sun의 MySQL AB 인수와 Oracle의 BEA 인수라는 소식을 들었다.
Sun과 Oracle은 더이상 언급할 필요도 없는 대기업인데다, MySQL과 BEA 모두 각자의 제품 시장에서는 잘 나가는 플레이어들이라 놀라울 수 밖에 없는 소식이다. 인수가는 Sun의 경우 옵션까지 포함해서 10억 달러, Oracle의 경우엔 85억 달러다.
Sun의 MySQL 인수합병에 대해서 약간 더 얘기해보면, 평소에 구독하던 MySQL 관련 블로그들에서 이 건을 보는 시각은 대체로 비슷하다. 바로 Sun이 그동안 일관되게 보여준 Open Source 지향 정책과 MySQL의 시장성이 시너지를 보여줄 것이라는 것이다.
이 인수 합병건의 평가는 결국 Solaris-MySQL 제품이 얼마나 시장에서 경쟁 우위를 차지할 수 있느냐로 가름이 날 것이다. 엔터프라이즈급 서버 시장은 대체로 소프트웨어에 많이 의존하고 있고, 특히 데이터베이스 서버들도 그러하다. 다시 말해, 하드웨어만 팔거나 소프트웨어만 팔지는 않는다는 것이다. 이러한 면에서 Solaris 플랫폼에 MySQL이 얹혀 엔터프라이즈급 데이터베이스 서버로 판매되는 날도 점쳐볼 수 있을 것이다.
역시 흥미로운 부분은 Oracle과의 경쟁이다. Oracle은 명실상부한 데이터베이스 시장의 탑 플레이어지만 2위인 Microsoft SQL Server의 추격과 나름대로 선전하고 있는 MySQL의 추격 모두 무시할 수는 없는 노릇이다. 얼마전에는 InnoDB 엔진의 기반이라고 할 수 있는 InnoBase를 인수함으로써 MySQL이 가지고 있는 시장에도 관심이 있다는 사실을 내비쳤다. 이러한 사실만 가지고 아직 어떤 예측이 나오기는 힘들지만 이제서야 규모가 비슷해진(?) 데이터베이스 벤더들의 전쟁은 아무튼 흥미진진할 것 같다.
한편, MySQL은 세계적으로 널리 쓰이는 데이터베이스 제품이지만, 어느 정도 규모가 있는 데이터 플랫폼으로서는 아직 부족한 점이 많다. 분산에 대한 해결책으로 Replication과 Clustering이 존재하지만, 아직 걸음마 단계라고 볼 수 밖에 없고, DRDB나 LVM, InnoDB Hot Backup, MySQL Proxy 같은 외부 기술에 의존하는 경우도 많다. 이러한 솔루션들이 성숙하려면 아직 시간이 필요하고, Sun의 지원하에서 아마도 좀 더 쉽게 이루어질 수 있을 것이다.
MySQL 사용자로서 앞으로 MySQL의 발전에 거는 기대는 크다. Sun과 MySQL의 인수합병이 좀 더 나은 세상을 만드는데 도움이 되었으면 좋겠다.
Bruce Eckel의 The Mythical 5% (Via Steve Vinoski)라는 글을 읽었다.
최상의 프로그래머가 최악의 프로그래머에 비해 28배의 생산성을 보여준다는 사실은 people factor를 강조하는 사람들에 의해 꾸준히 인용되는 사실이다. 5%라는 숫자가 어디서 나왔는지는 모르겠지만, 여기서 mythical 5%는 그러한 최상의 프로그래머들을 일컫는다.
Bruce Eckel은 이 숫자에 대해 재미있는 가설을 세운다.
Let’s say that this follows the 80-20 rule. Roughly 80% of programmers don’t read books, don’t go to conferences, don’t continue learning, don’t do anything but what they covered in college. Maybe they’ve gotten a job in a big company where they can do the same thing over and over. The other 20% struggle with their profession: they read, try to learn things, listen to podcasts, go to user group meetings and sometimes a conference. 80% of this 20% are not very successful yet; they’re still beginning, still trying. The other 20% of this 20% — that’s about 5% of the whole who are 20x more productive.
즉, 전체 프로그래머들 중 20%만이 뭔가를 배우려고 애쓰고, 그 중에서도 20%만이 성공을 거두어 mythical 5%가 된다는 것이다. Bruce Eckel에 따르면, 이 5%의 사람들은 엄청나게 읽어대며, 새로운 어떤 개념이 쓸만하다면 언제든지 시도해보며, 가장 좋은 도구와 기술, 생각들을 채용한다. 결정적으로 그들은 항상 최선을 다한다.
숫자들은 무시하도록 하자. 분명 프로그래머들 중 소수의 사람들만이 뭔가를 배우려고 애쓰고, 역시 소수의 사람들만이 뛰어나다는 것은 인정할 수 밖에 없는 사실이다. 그런 면에서 Bruce Eckel의 직관은 옳은 것 같다.
적어도 나는 뭔가를 배우려고 애쓰는 20%에 속한다고 말할 수 있다. 아마 이 글을 읽는 사람들도 그러한 20%에 속한 사람들일 것이다. 나는 모든 프로그래머가 그 20%가 되어야한다고는 생각하지 않는다. 각자 어떤 삶을 원하는가는 다른 법이기 때문이다. 어쩌면 묵묵히 자신이 할 일을 하는 80%가 있기에 다른 20%가 존재할 수 있을지도 모른다. (물론 80% 모두가 자신이 할 일을 하지는 않겠지만.)
내가 mythical 5%가 되기에 성공한 20%인지는 아직 모르겠다. 아마도 그 주변부에서 맴돌고 있는 듯하다. 여러 practices들을 접하고 어떤 것들이 best practices인지는 어느 정도 알지만 아직 그것들을 체계화하고 모두 습관화하지는 못한 단계다. Bruce Eckel은 배우려고 하지 않는 80%를 위한 조언을 했을 뿐, mythical 5%가 되기 위해 노력하고 있는 80%를 위한 조언은 하지 않았다. 그 답은 내가 스스로 찾아가야할 것이다. 내가 잊지 않아야하는 태도는 ‘최선을 다한다‘는 것일테다.
이 글의 나머지는 Code Readability의 중요성, Code Review의 유용함, 짧은 역사를 가진 소프트웨어 산업의 한계, 프로세스와 인간의 중요성, management의 어려움과 중요성, 소프트웨어 산업에 있어서의 비결정적인 요소, 경제와 비즈니스의 중요성에 대한 짤막하지만 현재 소프트웨어 산업의 지혜들을 담고 있는 심원한 문장들로 채워져있다. 소프트웨어 산업에 뛰어드는 신입자들로부터 5~10년 정도의 경력자들까지도 이 글을 한번씩 읽어보기를 권장한다.
Java 프로그램에서 외부 프로그램을 실행하고 싶을 때, Runtime.exec() 또는 Java 1.5에서 추가된 ProcessBuilder를 사용해 Process 객체를 얻을 수 있다. 처음으로 이런 프로그램을 짤 때, 실수한 것이 없어보이는데도 실행한 프로그램이 종료되지 않는 경우가 있다. 더군다가 어떤 경우엔 정상적으로 종료되고 어떤 경우엔 종료가 되지않는 경우도 보인다.
원인은 바로 Process 클래스의 API Reference에 있는 다음과 같은 설명에서 찾을 수 있다.
The created subprocess does not have its own terminal or console. All its standard io (i.e. stdin, stdout, stderr) operations will be redirected to the parent process through three streams (getOutputStream(), getInputStream(), getErrorStream()). The parent process uses these streams to feed input to and get output from the subprocess. Because some native platforms only provide limited buffer size for standard input and output streams, failure to promptly write the input stream or read the output stream of the subprocess may cause the subprocess to block, and even deadlock.
즉, Java에서는 Child 프로세스로의 표준 입출력을 Parent 프로세스가 다루어주어야 한다. 당연하게도, Child의 출력을 언제까지고 버퍼링할 수 없기 때문에, 다른 프로그램을 실행할 때는, 특히 표준 입출력이 존재하는 프로그램을 실행할 경우에는, 항상 이 스트림들의 입력 또는 출력을 제대로 다루어주어야 한다.
이러한 동작은 일반적으로 프로그래머들이 익숙한 시스템콜들, 이를테면 UNIX 계열의 fork()/exec()나 Windows의 CreateProcess()처럼, parent 프로세스의 터미널/콘솔을 공유하는 동작과는 다르기 때문에, 프로그래머들이 쉽게 간과하고 실수하기 쉽다. 더군다나 API Reference가 이러한 점을 명확히 설명하고 있지도 않다.
해결책은 당연하게도 표준 입력이 필요할 때는 Process.getOutputStream()을 이용하여 필요한 입력을 해주고 스트림을 닫아주어야하고, 표준 출력이 필요할 때는 Process.getInputStream() 그리고 Process.getErrorStream()을 이용하여 스트림을 비워주어야한다. 드물겠지만 만약 실행할 프로그램이 interactive한 프로그램일 경우에는 입출력에 좀 더 신경을 써야한다.
다음은 표준 출력을 비워주기 위한 코드가 들어간 간단한 예다.
Runtime rt = Runtime.getRuntime();
try {
Process proc = rt.exec("cmd /c dir");
// Process proc = new ProcessBuilder().command("cmd", "/c", "dir").start();
InputStream is = proc.getInputStream();
BufferedReader reader = new BufferedReader(new InputStreamReader(is));
String line;
while ((line = reader.readLine()) != null) {
System.out.println(line);
}
int exitVal = proc.waitFor();
System.out.println("Process exited with " + exitVal);
} catch (Exception e) {
System.err.println("Failed to execute: " + e.getMessage());
}표준 출력 뿐만 아니라 표준 에러까지도 처리를 할 수 있어야 좀 더 일반적인 코드일 것이다. 표준 에러의 버퍼가 차버리면 표준 출력을 비우려고 해도 블럭될 수 있다. 이러한 문제는 Java World의 When Runtime.exec() won’t 라는 글에서 StreamGobbler라는 클래스를 도입해서 약간 더 우아하게 해결하고 있다. 하지만, 간단한 작업을 하기 위해 쓰레드를 사용하고 있기 때문에 좀 오버킬이라는 생각이 든다.
표준 출력과 표준 에러를 간단하게 무시하고 다른 프로그램을 실행할 수 있도록 하는 옵션이 있다면 자주 사용할 수 있으며 편리할 듯 하다. 또는, 디폴트 동작을 일반적인 시스템콜의 동작과 비슷하게 만들어주는 것도 괜찮을 듯하다. 시간이 나면 이런 방식의 Wrapper를 찾아보거나 만들어보아야겠다.
스무아홉이 되면 서른이 된다는 생각에 무척이나 우울해진다는 얘길 선배들로부터 자주 들었는데, 실은 별로 그렇지 않았다. 이유는 잘 모르겠지만, 너무 바빠서 그렇거니 하고 생각하고 있었다. 그러다 어젯밤에 케이블에서 ‘싱글즈‘를 봤다.
며칠 있으면 새해다. 난 서른살이 되기전에 인생의 숙제 둘중 하나는 해결할 줄 알았다. 일에 성공을 하거나 결혼을 하거나. 난 여전히 일에 성공하지 못한 싱글이다. 그럼 어때? 마흔살쯤에는 뭔가 이루어지겠지, 뭐~ 아님 말고. 어쨌든 서른살… 이제 다시 시작이다. 나난~ 화이팅!
‘싱글즈’는 맘에 드는 영화라서 볼 기회가 생길 때마다 끝까지 보게되는데, 나난의 마지막 독백이 어제만큼 마음에 와닿은 적은 없었던 것 같다. 그리고, 스무 남짓의 내게 서른살은 무엇이었나 기억이 떠올랐다.
’20대에 나에 대해, 세상에 대해 알게 될거야. 그리고 서른살이 되면 세상을 바꾸겠어.’
지금 생각하면 피식 웃음이 나올 정도로 너무 용감한 생각이었다. 나에 대해, 세상에 대해 알게되기는 커녕, 일과 사랑에 있어서도 뭔가 이루어지거나 해결된 것 하나 없다. 부질없이 시간만 보내다 20대가 끝나버린 느낌이다. 나나 주변의 친구들을 보아도 하나 같이 어설퍼 보인다. 단지 잘하는 것처럼 보이려고 애쓰고 있을 뿐인 것 같다.
하지만, 아무것도 변하지 않은 것은 아니다. 나에 대해 속속들이 아는 대신에, 난 나를 받아들일 수 있게 되었다. 많이 부족하지만, 마치 갓 태어난 아기같던 20대 초의 나에 비하면, 지금은 세상에 대해서 훨씬 많이 알고 있다. 난 내가 잘하고 좋아하는 일을 찾았고, 더이상 다른 유혹에 넘어가지 않을 수 있다. 성공했다고는 장담할 수 없지만, 나름대로 주변 사람들에게 인정받고 있고, 스스로의 능력에 대한 자신감은 넘친다. 가까운 미래에 어떤 모습으로 일하고 있을지도 그릴 수 있다. 술 한잔 하며 추억할 수 있는 좋은 인연들도 만났고 헤어졌다. 이성 앞에서 당당해졌고, 더이상 감정에 휘둘리지 않고 초연해질 수 있게 되었다. 결혼에 성공할지는 모르겠지만, 앞으로도 좋은 인연을 만날 수 있을거라는 자신은 있다.
지금 어설픈 것은 어쩔 수 없다. 어차피 모두들 그런거니까. 지금 어설픈 것은 괜찮다. 모두들 열심히 살아갈거고 언젠가 더이상 어설퍼보이지 않을테니까.
그래서, 그리고, 안녕, 나의 20대.
갑자기 자다 깨는 바람에, 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를 적용하기로 했다.