August 2008 Archives

Empire: Total War는 2009년 2월 경에 릴리즈 될 Total War 시리즈의 후속편입니다.

기본적으로 실시간 전략 시뮬레이션(RTS)인 Total War 시리즈의 가장 큰 강점은 역시 실제적인 전투입니다. 스타크래프트나 C&C와 같이 가상적인 전투 유닛이 아니라 실제로 그 시대에 존재했던 보병이나 궁병, 기병이 등장하고, 일반적인 RTS에 흔하지는 않은 지형과 피로, 돌격 개념이 들어가 있습니다. 하지만, Total War는 전투 뿐만 아니라, 팩션의 통치, 외교, 무역까지도 포함하고 있기 때문에 전투만 한다고 해서 게임의 목적을 달성할 수 있는 것은 아닙니다. 게다가, 실제 역사를 배경으로 하고 있기 때문에, 역사를 좋아하신다면, 여러 재미를 느낄 수 있습니다.

Medieval II: Total War가 11세기부터 16세기 유럽의 중세시대를 다루었다면, Empire: Total War는 18세기부터 19세기에 이르는 유럽의 제국들이 형성되어가는 시대를 다루고 있습니다. 현재까지 릴리즈된 Total War 시리즈에는, 일본 전국 시대를 다룬 Shogun, 로마 시대를 다룬 Rome, 유럽의 중세 시대를 다룬 Medieval, Medieval II이 있습니다. 다음은 WW2: Total War 아니냐는 얘기들이 많이 있는데, WW2를 다룬 걸출한 게임들이 많아서 어떨지는 모르겠습니다. Total War만의 매력은 역시 중세 역사를 배경으로 한 것이 아닐까 생각이 드네요.

아시다시피, 식민지 경쟁이 불 붙던 이 시기에 역시 해상력은 국가의 우위와 향방을 결정 짓는 빼놓을 수 없이 중요한 요소였죠. 다음은 Empire: Total War에서 3D로 구현된 해전 영상입니다.

게임을 좋아하시는 분이라면, 대항해시대는 한번씩 플레이해보셨을 텐데요. 대항해시대 해전의 이상적인 모습을 Total War 시리즈에서 보게되리라곤 생각못했습니다.

다음은 Empire: Total War의 트레일러입니다.

해전만 있는 것은 아닐텐데, 영상에서 차지하는 비중을 볼 때 역시 해전에 초점이 맞추어져 있다는 느낌이 드네요. 그리고 저택인지 왕궁인지 몰라도 시민들이 횃불을 들고 진입하는 장면이 나오는데, 프랑스 혁명과 같은 장면 연출이 왕정을 공화정으로 바꾸는 형태로 가능할지도 모르겠네요. 어쨌거나 벌써부터 기대가 되니 큰일입니다.

Ship It by Jared Richardson, William Gwaltney

Ship It은 소프트웨어 개발에 관한 가이드라인을 담은 책이다. '도구와 인프라스트럭처', '실용주의적 프로젝트 기술', '예광탄 개발', '일반적인 문제와 해결방법'의 네 부분으로 나뉜다.

'도구와 인프라스트럭처'는 CVS 또는 Subversion과 같은 코드 저장소, 빌드의 자동화, 이슈 및 기능 추적, 테스트 자동화와 같은 이슈를 다루고 있다. 사실 이러한 도구들을 사용하라는 가이드라인은 흔히 들을 수 있는 이야기지만, 이 장의 마지막 가이드라인인 '실험하지 말아야 할 때'에서는 '핵심적인 기술을 기술 실험 대상으로 삼아선 안 됩니다'라는 중요한 교훈을 얘기하고 있다. 의욕에 찬 하지만, 경험은 부족한 개발자들이 흔히 하는 실수다.

'실용주의적 프로젝트 기술'에서 소개하는 목록 사용은 오래 전부터 나나 내가 일하던 팀, 내 주변의 사람들이 실제로 활용하면서 훌륭한 습관임이 증명된 프랙티스다.

일일 회의나 모든 코드의 검토, 코드 변경 통지 등은 내겐 약간 적용하기 힘들어보이는 프랙티스들인데, 각각의 프랙티스는 나름의 장점들을 갖고 있다는 것에 동의하기 때문에 조금씩 적용해 볼 생각이다.

내가 맡고 있는 조직에 주간 회의를 적용하기 시작한지가 수개월 지났고, 현재는 어느 정도 정착이 되어가고 있다. 하지만, 어차피 작업이나 문제 관리를 위한 의사 소통이 매일 일어나는 것을 생각하면, 일일 회의는 의사소통이 예측 가능하게 일어나게 해주고, 때문에 효율적인 의사소통이 가능하게 해주리라 생각한다. (이는 주간 회의를 포함한 '정기적인 회의'의 장점일 것이다.) 하지만, 일일 회의를 시행하기 위해서는 주간 회의라는 익숙한 프랙티스를 포기해야 한다. 이와 같이, 어떤 프랙티스가 좋고, 현재의 프랙티스를 대체하자는 얘기는 너무나 쉽지만, 이것을 적용하기 위한 사람들의 지지를 얻고, 대체 과정의 비용을 줄이고, 실제로 잘 적용하는 것은 여러 고민과 많은 노력이 필요한 일이다.

코드 검토의 경우, 이 책에서는 변경을 포함한 모든 코드를 검토해야 한다고 나와있지만, 그보다 온화한 (덜 진보적인) 단계로, 새로운 모듈이나 프로그램, 시스템이 완성되었을 때, 코드 검토를 하는 프랙티스가 경험적으로는 상당히 좋았던 것 같다. 아마도 이를 코드 검토를 시작하는 팀의 마지노선으로 잡으면 될 것 같다. 코드 검토는, 이 책에서 얘기하는대로, 작은 단위로 할 수록 효율과 정확성이 높아지는데, 작은 단위로 리뷰하는 문화를 정착시키는 것은 또 다른 과제다.

현재 팀에는 기술 리더라고 할만한 사람들이 몇 명 있는데, 팀의 한 파트를 책임지고 있는 나도 그 중의 한명이라고 볼 수 있다. 간단하게 말해서, 기술 리더는 기술 업무와 관리 업무를 수행해야 하는데, 둘 다를 수행하는 것은, 한가지만을 수행하는 것에 비해 절대 쉬운 일은 아니다. 가장 중요한 책임 중 하나는 역시 우선 순위의 조정이다. 업무의 목록은 팀원들 각자가 결정할 수 있지만, 우선 순위의 문제는 항상 기술 리더의 책임이다. 요즘 내가 생각하고 있는 것은, 우선 순위 결정을 주간 보고나 주간 회의와 같은 과정에 자연스럽게 연결해 프로세스화 하는 것이다.

'예광탄 개발'은 일반적인 애자일 개발과 얼마나 크게 차이가 있는지 모르겠고, 굳이 '예광탄 개발'이라는 이름표를 달아주어야 하는지 의문인데, 이 글에서는 설명을 생략하도록 한다.

'일반적인 문제와 해결 방법'은 분류하기 힘든 가이드라인을 모아놓은 부분이라고 볼 수 있는데, 그 중 '불한당 개발자'에 대한 대처 방법을 다룬 항목이 흥미로웠다. 고삐를 채울 수 없는 불한당의 경우, '불한당의 행동을 문서화하고, 반항적 행동을 문제 삼아 해고해야 한다'는 것이다. 그리고, '대부분의 경우엔, 문서화 과정을 시작하는 것만으로도 충격받아 제자리로 돌아온다'라고 한다. 실제로도, 문제를 일으키는 팀원의 경우, 문제점을 지적당하면, 그 근거를 제시하라는 답이 돌아오기도 한다. 이에 대한 정당한 답변은 다른 사람에게 어떻게 얘기했는가, 어떤 예절 바르지 못한 행동을 했는가 등이 아니라, 잘 문서화된 작업 목록 뿐이다. 이런 수단이 악의적으로 사용되어서는 물론 안되겠지만 말이다. 한편, Jeff Atwood의 'Dealing With Bad Apple'이란 글에서는 불한당 또는 Bad Apple은 팀 전체에 악영향을 미치며, 어떤 사람의 능력은 발전할 수 있어도 태도는 변하기 어렵다는 이유로, 빨리 제거하는 방법밖에 없다고 얘기하고 있다.

이 책 전체에서 드러나는 실용주의적 태도 - 어떤 프랙티스가 절대적으로 옳다고 주장하기 보다는 적합한 것을 적용해나가자는 태도 - 는 상당히 마음에 드는 편이다.

내용이나 태도 뿐만 아니라, 구성 면에서도, 하나의 가이드라인마다 마지막에 '어떻게 시작하면 될까요?', '제대로 사용하고 있는 걸까요?', '경고 신호'와 같은 섹션을 두어, 이 책에 나온 가이드라인을 실제로 행동에 옮길 수 있는 지침으로 활용하기 좋게 만들어져 있다.

번역은 따로 언급할 필요가 없을 정도로 잘 되어 있는 편이다. 최근에 출판되는 해외에서 유명한 기술 서적들은 평균적인 번역 품질이 예전보다는 많이 좋아진 것 같다.

Head First Javascript by Michael Morrison

Head First 시리즈는 따로 언급하지 않아도 너무나 유명한 입문서 시리즈다.

그동안 여러 간단한 웹 애플리케이션을 개발하면서, 불편하지 않을 정도로는 Javascript를 익히고 사용해왔기 때문에, 내게 적합한 책이라고 생각한 것은 아니었지만, Head First 시리즈의 유명세를 직접 경험해보고 싶은 마음이 강했다.

이 책을 읽고 나서, 과연 이 책에 대한 소문이 헛소문이 아님을 확인할 수 있었을 뿐만 아니라, 입문서로서의 본보기를 볼 수 있었다.

일반적인 프로그래밍 서적들은 흔히 커다란 분류 체계를 세워놓고 각각의 분류에서 세부사항을 하나씩 설명하는 방식을 취한다. 분류 체계는 물론 중요하다. 분류 체계를 이해하는 것은 그 분야 전체를 이해하는 것을 의미한다. 하지만, 어떤 분야 (이를테면, 프로그래밍 언어)에 익숙하지 않은 입문자에게는, 그러한 분류 체계(이를테면, 변수(variable), 자료형(type), 연산자(operator), 표현식(expression), 클래스(class) 등과 같은 분류)는 이해하기 어려울 뿐만 아니라 학습에 방해가 될 수도 있다.

이 책은, 먼저 목적 또는 필요를 제시하고, 그것을 충족시키기 위한 방법 (이를테면, Javascript의 문법, 라이브러리 요소)을 설명하는 방식을 취하고 있다. 이러한 방식은 입문서로 추천한 적이 있는 Essential C++과 같은 책에서도 보인 적이 있다.

또다른 중요한 요소는 방법을 설명한 후에는 이를 실제로 연습해볼 수 있도록 하는 것이다. 이 책에서는 '연습'이라는 중요한 단계를 건너뛰지 않도록 책에 직접 프로그램을 작성할 수 있도록 해두고 있다.

마지막 단계는, 여러가지 방식을 통해서 학습자가 학습한 내용을 여러 번 정리할 수 있도록 하여 마음 속에 새기는 과정이다.

이러한 Head First의 학습 방식 자체는 특별한 것은 아니지만, 기술 입문서에서만은 독특하다고 할 수 있을 것 같다. 그것이 바로 Head First 시리즈가 유명해진 비결일 것이다.

그리고, 한가지 언급하고 넘어가야할 점은, 상당히 낮은 선행 지식을 요구한다는 점이다. 설명 자체가 선행 지식을 거의 필요로 하지 않을 정도로 쉽게 되어있다. 적절한 비유를 사용해 이해를 도와주는 것도 인상 깊다.

한편, 이러한 입문서는 반대로, 입문자가 아닌 학습자에게는 오히려 좋지 않다. 분류 체계가 없는 것은 입문자에게는 이점이지만, 익숙한 분류 체계에 끼워맞추기만 하면 되는 학습자에게 분류 체계가 제시되지 않는 것은 오히려 학습 효율을 떨어뜨리는 것이다. 반복적인 내용도 마찬가지다. 물론, 입문자가 아닌 학습자가 Head First 시리즈를 고르는 것은 잘못된 일이다.

현재 번역되어 있는 Head First 시리즈는, 국내 출간일 순으로, Java, EJB, Servlets & JSP, Design Patterns, HTML with CSS & XHTML, Object Oriented Analysis & Design, PMP, SQL, Javascript (서명에서 Head First 생략) 로 총 9권이다. Moviemaking, Algebra, C#, Physics, Statistics이 아직 번역되지 않았고, Ajax, PHP & MySQL, Rails, Web Design등과 같은 주제로도 출간될 예정이다. C#, Statistics 같은 경우에는 아직 번역되어 나오지 않은 것이 아쉽다.

앞으로 입문서 추천을 누군가가 부탁한다면, Head First 시리즈를 강력하게 추천할 생각이다.

지난 번에는 Visual Studio 2008을 이용해서 Silverlight 2 애플리케이션을 개발하는 과정을 따라가봤는데, 이번에는 Scott Guthrie의 'First Look at Using Expression Blend with Silverlight 2'라는 튜터리얼을 보면서 Expression Blend를 사용해 Silverlight 2 애플리케이션을 개발해보았다.

Microsoft Expression 제품군은 디자인에 초점이 맞춰진 웹/데스크탑 애플리케이션 개발 도구인데, 그 중 Expression Blend는 WPF와 Silverlight 애플리케이션 개발 도구다. 현재 출시되어 있는 Expression Blend 2는 Silverlight 1 애플리케이션 개발만을 지원하기 때문에, Silverlight 2 애플리케이션을 개발하기 위해서는 Expression Blend 2.5 Preview (June 2008 버전)을 설치해야한다.

저번 글에서 언급했던대로, Expression Blend에서는 Silverlight 애플리케이션의 Interactive Design View를 제공한다. WYSIWYG 방식으로 디자인이나 컨트롤의 속성을 변경할 수 있도록 해준다. Visual Studio 2008을 이용할 때와 비교해, 손으로 마크업을 작성해주어야 하는 번거로움이 훨씬 줄어들었지만, 다음과 같은 단점들이 보인다.

첫번째는 코드 작성에 대한 지원이 부족하다는 것이다. 특히, Intellisense 지원이 없는 것으로 보인다. 따라서, Expression Blend로 디자인하고 Visual Studio 2008로 프로그래밍하는 것이 편리하다. 애초에 제품이 분화되어 있는 이유가 원래부터 디자이너와 개발자의 역할 분담을 위한 것으로 보이지만, Intellisense와 같은 기본적인 기능은 있어야 할 듯 하다.

두번째는 아직 Silverlight 기능에 대한 지원이 불완전하다는 것이다. 특히, Silverlight의 주요한 디자인 요소 중 하나인 스타일 지원이라든가, 애니메이션 지원이 아직 없다. 즉, 현재는 손으로 작성해야한다는 얘기다.

이러한 여러 상황들을 볼 때, Microsoft의 Silverlight 출시는 Microsoft 답지 않게(?) 급하게 서두른 감이 있다. 아직은 부족하나, 소프트웨어 개발 도구 제품에 있어서 뛰어난 역량을 보여온 Microsoft인만큼, 베타 버전이 아닌 정식 릴리즈를 기대해본다.