정말 오래간만의 포스팅입니다. 아직도 끝나지 않은 골프장 프로젝트 때문에 그동안 이리저리 바빴습니다.

위키 소프트웨어를 모니위키에서 미디어위키로 변경하였습니다. 미디어위키가 기능이 많고 관리가 편리한 것 같습니다. 그리고 초기 버전의 성능 문제도 충분히 개선된 듯 합니다.

이전 위키 페이지들은 리다이렉트(redirect) 이용해서 링크를 유지시켰습니다.

2007년 모든 업무가 종료하였습니다.

2007년은 개인적으로 그동안 잊고 지냈던 것들을 찾은 해였고, 회사는 비상(?)을 준비한 해였습니다. 그리고 내년에는 꼭~ 그 결실을 봤으면 합니다.

2007년 잘 마무리 하시고, 새해 복 많이 받으세요~

지난 번에 같이 일하기로 하신 분이 개인적인 사정으로 못 오게 되어 다시 사람을 모집합니다.

내용을 약간 수정하긴 했습니다만, 이전과 크게 달라진 점은 없어서 그냥 링크만 걸도록 하겠습니다. DRY하기 위함이니 성의없다고 보시지 않으셨으면 합니다^^;

• 레일스(Rails) 및 Ajax 프로그래머를 모집합니다
  

아울러 단기간 같이 일하실 웹디자이너와 C# 프로그래머도 모십니다.

• 골프장 홈페이지 리뉴얼해주실 웹디자이너를 모집합니다
  
• C# 프로그래머 모집합니다
  

비록 단기간이지만, 좋은 분들 만나고 싶습니다~

오늘도 프로젝트에 익스트림 프로그래밍(XP)를 적용하기 위해서 나름 열심히 고민하고 있습니다^^; 그러다 보니 애자일 방법론을 채택하고 있는 다른 국내 개발사들이 궁금해져서, 웹서핑을 하던 중 떠오른 생들을 몇 자 정리했습니다.

컴포넌트 비전에서 일하는 분들이 《Extreme Programming Installed》를 번역한 걸로 알고 있습니다. 2002년에 발행되었습니다. 켄트 벡의《익스트림 프로그래밍》가 XP의 철학에 관한 책이라면, 이 책은 실천 대한 책입니다. 모든 분이 추천하는 좋은 책이긴 하지만, 개인적으로 최근에 나온 《애자일 프랙티스》를 더 선호하는 편입니다.

모비젠에서는 짝 프로그래밍을 제외한 XP를 적용하고 있다고 합니다. 개인적으로 짝 프로그래밍은 XP의 꽃이라고 생각합니다. 저도 처음엔 익숙하지 않아서 어색했었지만, 차츰차츰 짝 프로그래밍의 생산성 체감할 수 있었습니다. 짝 프로그래밍 적극 추천합니다~!!

오픈마루는 대표적인 애자일 실천 기업이라고 생각합니다. 스프링노트를 개발할 때 김창준씨가 참여했다는 사실이 부러웠습니다. 저희 회사도 돈만 많으면...ㅡ.ㅡ 그리고 엔씨소프트의 캐주얼 게임 개발 팀 중에서 XP를 일부 도입했던 것으로 알고 있습니다. (지금은 엔씨에 연줄이 닿질않아서...)

마아에트 엔터테인먼트에서는 그래픽 팀이 XP를 조금씩 사용 중이라고 합니다. 그래픽 작업에서 어떻게 XP가 적용되고 있는지 정말 궁금합니다.

그리고 델리마운트에서도 XP를 적극적으로 도입하고 있습니다. 현재 의사 소통, 짝 프로그래밍, 사용자 스토리, TDD, 리팩토링 등을 적용하고 있으며, 앞으로 지속적으로 애자일의 방법론을 애자일스럽게 적용할 예정입니다. 앞으로 저희가 경험하게될 수많은 삽질(?)들을 블로그와 위키에 열심히 정리하도록 하겠습니다. 많은 관심 부탁드립니다~ ^_^

최근 두번의 스팸 댓글 공격(?)이 있었습니다.

처음 스팸 댓글을 봤을 때 조금 반갑기까지 했습니다. 스팸의 대상이 된다는 것이 유명(?) 블로그의 반열에 올라서기 위한 과정이 아닐까라는 생각에... ^^; 그래도 스팸을 삭제하는 것은 귀찮은 일이더군요.

스패머님, 스팸은 정중히 사양합니다~!!

아래 내용을 잡코리아에 올렸습니다. 관심있으신 분 메일 주십시오~

---

레일스(Ruby on Rails) 및 Ajax 프로그래머를 모집합니다.

저희가 진행하는 프로젝트는 크게 2가지 입니다.

1. 웹기반 그래픽 에디터
2. ERP 솔루션

요구 사항은 다음과 같습니다.

1. 열정과 자부심이 있으신 분
2. 팀웍을 중요하게 생각하시는 분
   

프로그래머라는 직업에 자부심이 없으신 분은 정중히 사양합니다. 열정과 근성이 있는 분을 원합니다. 만약 다른 언어나 환경에 익숙하신 분이라면 레일스와 Ajax를 모르셔도 괜찮습니다.

저희 회사에서 진행하는 모든 프로젝트는 익스트림 프로그래밍(XP)를 적용하고 있습니다. 따라서 팀원들 간의 신뢰와 의사 소통을 매우 중요하게 생각하고 있습니다. 혼자서 일하시기 좋아하는 분 역시 정중히 사양하겠습니다.

시작한지 얼마되지 않은 기업이라 별로 내세울 것은 별로 없습니다만, 저희 회사가 가지고 있는 장점 몇 개를 정리해보았습니다.

1. 합리적이고 즐겁다. (XP, 레일스, 좋은 팀 분위기 등)
2. 주 35시간 근무입니다. (월~금 / 10시 ~ 18시 / 야근 없음)
   

그리고 여러 가지 좋은 경험을 할 수 있을 것이라고 생각합니다. XP를 적극적으로 도입하여 테스트 주도 개발(TDD), 리팩토링 등을 실전 경험하실 수 있습니다 . 그리고 Ajax 부문에서는 상당히 높은 수준에 올라있다고 생각합니다.

저희 회사의 단점이라면 -짐작하시겠지만- 규모가 작고 모험적(risky)이라는 것입니다. 그러나 사람에 따라선 이러한 단점이 오히려 매력적으로 다가올 수 있다고 생각합니다. (적어도 저의 경우엔 그러합니다. ^_^)

온라인 접수도 가능합니다만, 저희 회사를 위해서 특별히 이력서와 자기 소개서를 준비해서 메일로 보내주신다면 감동적일 것 같습니다.

궁금하신 점은 webmaster@delimount.com으로 메일 주십시요.


그럼... 안녕히 계십시오~

저희 팀의 자바스크립트 개발 환경을 소개하도록 하겠습니다.

우선 IDE는 앱테나(Aptana)를 이용하고 있습니다. 앱테나 이외에도 코모도, 이클립스 WDT 등이 있습니다. 제품의 완성도는 코모도가 뛰어나지만, 이클립스 기반에 오픈 소스인 앱테나가 더 매력적인 것 같습니다. 게다가 코모도 IDE 버전은 유료입니다. 이전에는 이클립스 WDT가 이클립스 기반의 대표적인 IDE였지만, 요즘은 앱테나쪽의 움직임이 더욱 활발합니다. 아마도 앱테나가 대세될 것 같습니다.

디버깅은 기본적으로 파이어폭스(Firefox)와 파이어버그(Firebug)를 이용합니다. 그런데 파이어버그는 예외가 발생했을 때 함수 스택 추적이 안되는 단점이 있습니다. 그래서 예외가 발생한 경우 앱테나를 디버깅 기능을 이용하고 있습니다. 앱테나의 디버그 기능은 파이어버그보다 강력하지만, 디버그 모드를 시작하는데 다소 시간이 걸리기 때문에 평소에는 가벼운 파이어버그로 디버그하고 있습니다. 자세한 내용은 앱테너 페이지에 정리하고 있는 중입니다.

IE 디버깅은 MS 비주얼 웹 디벨로퍼(Visual Web Developer)를 이용하고 있습니다. 비주얼 웹 디벨로퍼 익스프레스가 무료인 것은 다들 알고 계시죠? 참고로 익스프레스 에디션은 학습용으로 배포되고 있지만 상업적인 용도로도 사용 가능하답니다. 비주얼 웹 디벨로퍼 익스프레스로 디버깅하는 방법은 자바스크립트 디버그 페이지에 정리해두었습니다.

단위 테스트는 JsUnit를 이용하고 있습니다. JsUnit은 setUp과 tearDown 기능을 지원하며, suite 기능도 지원합니다. 이클립스 플러그인이 있지만, 런칭 속도가 느리고 사소한 버그도 있고해서 그냥 앱테너의 실행(Run) 기능을 이용하고 있습니다. 자세한 내용은 JsUnit 페이지에 정리해두었습니다.

GUI 테스트는 무툴스와 셀레늄 사이의 문제 때문에 현재 보류 중인 상태입니다. 현재 임시적으로 셀레늄을 대체할 수 있는 라이브러리를 찾고 있는 중입니다. 조사가 완료되면 다시 정리해서 글을 올리도록 하겠습니다.

서브버전(Subversion) 클라이언트는 서브클립스(Subclipse)를 이용하고 있습니다. 아무래도 이클립스를 IDE로 이용하고 있기 때문에 톨토이즈(Tortoise)보다는 서브클립스가 편리합니다. 자세한 내용은 서브클립스 페이지에 정리해 두었습니다.

끝으로 크로스 브라우징을 위해 무툴스를 이용하고 있습니다. 무툴스에 대한 자세한 내용은 무툴스 적용하기라는 글을 참고하시면 됩니다.

Ajax 프로그래밍의 가장 껄끄러운 문제 중에 하나는 바로 크로스 브라우징(cross-browsing)입니다. 그리고 이 문제를 해결하는 방법은 크로스 브라우징을 지원하는 프레임워크(framework)를 사용하는 것입니다.

가장 대표적인 자바스크립트 프레임워크는 프로토타입과 스크립타큘러스의 조합입니다. 특별한 문제가 없는 이상 가장 범용적으로 사용되는 라이브러리를 사용한다는 원칙 아래 저희 팀에서도 프로토타입을 기본 프레임워크로 사용하였습니다.

그러나 개발이 진행되면서 프레임워크의 크기에 대한 우려는 가시지 않았습니다. 아무래도 사용 환경이 웹이기 때문에 크기 문제에 민감해질 수 밖에 없었습니다. 그러던 와중 프로토타입을 떠나는 결정적인 계기가 있었습니다. 자바스크립트는 클래스 및 상속의 개념을 충분히 지원하지 않기 때문에 프레임워크 레벨에서 이를 보완하고 있습니다. 프로토타입 역시 이 부분의 지원하기는 합니다만, 그 기능이 매우 제한적입니다. 그래서 결국 다른 대안을 찾아보기 결심하였으며, 어렵지 않게 프로토타입을 대체할 수 있는 무툴스라는 프레임워크를 찾게되었습니다.

무툴스(Mootools)의 가장 큰 장점은 가볍다는 것입니다. 프레임워크 전체 크기도 작을 뿐만 아니라 전체 라이브러리에서 필요한 부분한 다운 받을 수 있도록 했기 때문에 크기 문제는 매우 만족스럽습니다. 그러나 무툴스의 진정한 위력은 클래스 및 상속을 실용적인 수준까지 지원한다는 것입니다. 자세한 내용은 무툴스 위키에 정리하도록 하겠습니다.

아무튼 무툴스의 매력에 흠뻑 빠져들면 들수록 걱정꺼리는 늘어갔습니다. 프로토타입이 이미 적용된 상황에서 무툴스를 적용한다는 것은 처음부터 새로 코딩을 해야하는 것을 의미하기 때문입니다. 그러나 늦다고 생각할 때가 가장 빠른 법이라 과감하게 소스 변경 작업을 진행하였습니다. 처음 예상과 달리 2배에 가까운 3주라는 시간이 소요되었습니다. 이는 소스의 대부분이 리팩토링되었기 때문인데, 프로토타입과 비교해서 무툴스를 이용하는 경우 상당히 높은 수준의 객체 지향적인 프로그래밍이 가능했습니다.

그런데 무툴스를 사용함에 있어 몇 가지 불편한 점들이 있습니다. 우선 대부분의 IDE(또는 편집기)들이 무툴스의 문법을 지원하지 않기 때문에 코드 어시스트 기능을 사용할 수 없습니다 (참고로 주요 웹 개발 IDE들은 프로토타입을 지원합니다). 그리고 셀레늄(Selenium)을 사용할 수 없다는 점도 아쉬운 점입니다. 이는 셀레늄이 크로스 브라우징을 위해서 프로토타입을 이용하기 때문인데, 추후에 프레임워크에 의존성을 줄일 예정이라고 합니다. 끝으로 무툴스 소스에 약간의 버그가 있는데, 오픈 소스라는 점을 고려해볼 때 큰 문제는 아니라고 봅니다.

현재 무툴스를 적용한지 약 1달의 시간이 흘렀습니다. 처음 무툴스를 채택할 때에는 무툴스가 가볍기 때문이었지만, 지금은 높은 수준의 객체 지향 프로그래밍이 가능해져 생산성이 좋아졌다는 점이 더욱 만족스럽습니다. 약간의 불편한 점들은 있지만, 전체적으로 훌륭한 프레임워크라고 생각합니다.

아직 프레임워크를 결정하지 못하신 분들은 무툴스를 고려해보는 것도 좋을 것 같습니다~

이지킨 프로젝트를 시작한지 약 1년의 기간이 흘렀습니다. 1년이라면 짧은 기간이 아닌데, 별로 한 것도 없이 흘러가버렸습니다. 지난 1년간 한 것이라곤 고작 시행착오를 겪은 것이 다일 정도입니다.

작년 5월 처음 이지킨에 대한 아이디어를 구상하고 있을 때 플랫폼을 뭘로 할지 고민하였습니다. 웹으로 하자는 의견이 있었는데, 자바스크립트로 원하는 성능을 내기 힘들것이라고 결론 내려졌습니다. 이는 저의 지난 프로젝트 경험에서 비롯된 것인데, 이것이 아마도 이지킨 프로젝트의 가장 치명적인 시행착오인 듯 합니다. 아무튼 당시 플랫폼은 자바로 결정되었는데, 이유인즉 크로스 플랫폼(cross-ploatform)을 지원하기 위해서였습니다.

플랫폼을 자바로 결정한 후 개발을 위한 여러 가지 사전 작업이 있었습니다. 정석적인 프로젝트 진행을 위해서 스티브 맥코넬의 《소프트웨어 프로젝트 생존 전략》을 참고하였으며, 약 1달 가량 2명의 인원이 투입되어 프로토타입을 제작하고 예상 사용자들의 반응을 조사하였습니다.

여기에서도 시행착오가 있었습니다. 《소프트웨어...》은 소프트웨어 개발 프로젝트 진행의 교과서라고 할 수 있습니만, 그 내용은 저희가 진행하는 프로젝트에 적합하지 않았습니다. 이 책에 정리된 내용은 중/대형 프로젝트에 적합한 것으로서, 저희와 같이 소규모 인원이 투입된 프로젝트에 적용하는 경우 프로젝트 진행 속도가 느려지는 문제점을 발견하였습니다.

초기 개발 스펙이 그다지 크지 않고 개발에 참여한 인원이 적기 때문에 프로젝트의 참여자 모두가 제품에 대해서 속속들이 알고 있는 상황에서 프로토타입은 필요하지 않았습니다. 오히려 프로토타입 작업 자체가 무거워서 전체 일정이 지연된다고 판단하였습니다. 물론 프로토타입을 통해서 실 사용자들의 반응을 살펴보고 그것을 제품에 반영한 것은 잘한 점이지만, 사용자의 요구 사항을 조사하는 과정에 프로토타입이 반드시 필요한 것은 아니라고 생각합니다.

그래서 프로젝트 진행 방법을 익스트림 프로그래밍(eXtream Programming)으 로 전환하였습니다. 사용자 스토리(user story)를 작성하고 1~2주 단위의 반복 계획을 작성하였습니다. 테스트 주도 개발을 적용하였으며, 지속적으로 소스를 리팩토링하였습니다. 그리고 이 모든 것들은 서브버전(Subversion)과 트랙(Trac)으로 관리되었습니다.

XP는 저희 팀과 프로젝트에 적합한 프로세스였습니다. 그런데 XP를 적용함에 있어 한 가지 어려운 점이 있었는데, 바로 짝 프로그래밍(pair programming)입니다. 짝 프로그래밍의 생산성은 놀라웠습니다. 프로그래밍을 할 때 두명이서 공동으로 작업하기 때문에 시스템 설계에서 디버깅까지 실시간으로 진행되었습니다. 별도의 디자인 문서나 코드 리뷰 작업이 필요하지 않았습니다.

그러나 모든 프로그래머가 짝 프로그래밍에 적응하지는 못했습니다. 한명의 프로그래머가 대화식 진행에 어려움을 겪었습니다. 짝 프로그래밍을 효율적으로 진행하기 위해서 자신의 의견이 틀린 경우 빨리 자신의 실수를 인정하는 용기가 필요했습니다. 하지만 이는 자신의 생각이 뚜렷하고 자존심 강한 젊은 프로그래머에게는 쉽지 않은 일이였습니다. 결국 현재는 짝 프로그래밍과 코드 리뷰 작업을 병행하고 있습니다. 그렇지만 이는 현실을 고려한 일시적인 조치로써 점차적으로 풀 타임 짝 프로그래밍으로 전환할 계획입니다.

열심히 적다보니 내용이 너무 길어지는 것 같군요. 나머지는 다음에 적는 걸로 하고, 프로젝트 뒤돌아보기 1부는 여기에서 마무리하도록 하겠습니다~ ^_^

Ajax 위키

개발 플랫폼을 Ajax로 변경하면서, Ajax 프로젝트 진행에 필요한 내용들을 정리 중입니다.

델리마운트 위키

지금까지 프로젝트를 진행하면서 많은 시행착오가 있었습니다. 그 때마다 그 과정을 위키로 하나씩 정리해보았습니다. 아직 정리해 놓은 것이 얼마되지 않지만, 같은 어려움을 겪게될 개발자들에게 작은 도움이 되었으면 합니다.

프로젝트 개발 플랫폼이 플렉스(Flex)로 변경되면서 앞으로는 플렉스 중심으로 정리가 될 것  같습니다~

Hello world~ ^_^