익스트림 프로그래밍(XP)은 최근 개발방법론 중에서 급부상하고 있는 애자일 소프트웨어 개발론(Agile Software Development)의 하나로, 단순성, 상호소통, 피드백, 용기 등의 원칙에 기반해서 "고객에게 최고의 가치를 가장 빨리" 전달하도록 하는 경량 방법론이다. 요구사항 등의 변화가 자주, 많이 있거나 개발자가 소규모(10명 내외)이고 같은 공간을 사용하는 경우에 높은 효과를 볼 수 있다고 알려져 있고, 다른 규모나 원거리 XP 등의 적용이 꾸준히 시도되고 있다. [From 김창준, ExtremeProgramming, 월간 마이크로소프트웨어 6월호 컴퓨터 용어 사전2]
see also XperDotOrg
여기서 말하는 개발 방법론이란 프로그램을 개발하는 전체 과정(process)을 형식화해 놓은 것을 말한다. 예를 들어, 하루 동안 고객과 "원하는 프로그램"에 대해 이야기를 하고 다음 일주일 동안 컴퓨터랑 씨름을 하고, 다음날 고객에게 일차 데모를 한 뒤에 "불만 사항"을 받고, 다시 삼일간 프로그램 수정을 해서 최종 데모를 하고, 고객이 만족하면 제품으로 포장해서 넘긴다.는 하나의 과정을 좀 더 구체적인 부분을 언급하면서 일반화 되도록 하면 원시적이긴 하나, 개발 방법론의 하나라고 말할 수 있다.
지난 (2002년) 3월 Giga Information Group Inc.는 응용 소프트웨어 개발 컨퍼런스에서 18개월 이내에 전세계 IT 기업의 2/3 이상이 일종의 Agile Methodology를 사용하게 될 것이라고 예측했다. (![[http]](/ns/imgs/http.png)
기사)
기사)see also :
패턴이 프로그래밍의 정석이라면(정석대로만 바둑을 두면 진다.),XP는 철학이라고 생각한다. 철학을 몰라도 바둑을 이길 수 있지만 발전할 수는 없다. 프로그래밍을 하다 보면 철학의 필요성을 절실하게 느낀다. 하루 종일 멍청하고 도대체가 하나 가르키면 그 하나도 제대로 이해하지 못하는 컴퓨터와 씨름하다 보면 철학없이 나은 프로그래밍을 할 수 없음을 느낀다. XP는 제대로 된 프로그래밍을 하기 위한 철학의 출발점이다. 그와 동시에 인터넷과 프로그래밍의 결과물의 축적에 따른 자연스러운 산물이 아닐 수 없다(기계어 프로그래밍 시절에 XP란 방법론이 제기될 수 있겠는가?). 아래 KentBeck의 프레젠테이션을 읽고 절반넘게 번역하여 보았다. 파워포인트로 되어 있어 저자의 의도를 파악하여 번역하기가 어려웠지만, 역시 철학은 공간을 넘어서 통함을 느꼈다(이는 결코 고수에 자신을 비교하여 자신을 고수와 동일한 반열에 넣기 기법이 아님~.~). XP는 큰 길이다.---이정호
위키위키와 ExtremeProgramming의 관계 ¶
(?)를 이해하기 위해서는 우선 위키위키를 처음 만든 WardCunningham의 사상 궤적을 따라가 볼 필요가 있다. 그가 처음 위키위키를 만든 것은, 건축가 ChristopherAlexander의 패턴언어를 컴퓨터 프로그래밍에 적용하는 시도를 하면서 다양한 사람들의 소프트웨어 개발 관련 경험을 한군데 모아서 그 지혜의 공통분모를 증류해 내려는 생각에서였다. 그래서 OriginalWiki의 본래 이름인 Portland Pattern Repository라는 말이 생기게 되었다.
그런데 패턴언어는 말 그대로 언어일 뿐이지, 그것이 글을 쓰는(즉, 프로그램 개발을 하는) 과정을 안내해 주는 것은 아니었다. 따라서, 수년에 걸쳐 많은 사람의 경험을 축적한 PPR은 스스로(집단적으로) 어떤 개발 방법론의 필요를 느끼고 있었다. 이때, WardCunningham과 KentBeck은 자신이 평소에 사용해오던 방법들을 잘 엮으면 하나의 체계화된 방법론이 나올 수도 있겠다는 가능성을 보았다. 그것은 Ward와 Kent가 평소에 가진 철학과 사상에서 우러나온 것으로 위키위키와 패턴을 일관되게 관통하는 것이었다. 그것이, ExtremeProgramming으로 현현하게 된 것이다 -- 위키위키라는 모체에서의 성장을 통해. Ward와 Kent가 이렇게 시작한 ExtremeProgramming은 대부분 PPR에서 자체진화해 나가기 시작했고, 이러는 과정에서 위키위키의 도움을 크게 받았고, 그 철학을 포함하게 되었다.
이런 공통점 중 몇가지만 예를 들자면,
CollectiveAuthorship은 XP에서 CollectiveCodeOwnership이라는 말로 바뀌고, 마치 위키의 텍스트가 공유되듯이 프로그램을 함께 공유해서 개발하고, 남의 것 내 것 구분없이 마음대로 수정하는, 또 그것을 환영하는 개념으로 발전되었다. (이것은 현재 프로그래머들이 갖고 있는, 자신의 프로그램에 대한 집착이나 프라이드 등을 볼 때 완전히 난센스로 받아들여질 수 있을 만큼 혁명적인 패러다임 쉬프트다. 위키위키 역시 현재의 인터넷 게시판 문화와는 정반대 가치를 추구한다. 사람들이 하지 말라고 하고, 하기 싫어하는 것을 "적극적으로 장려하고, 추구"해서 그런 제약은 물론 그 너머의 문제까지도 해결하거나, 초월하는 것이다.)
또 이러한 Collective-X를 할 때 가능하면 표준(CodingStandard)을 지키도록 해서, 결국에는 이 부분을 누가 썼는지 분간할 수 없는 상태가 되도록 하는 것이 양자의 지향점이기도 하다. (현재의 개발론 전통으로 봤을 때, 이렇게 책임소재가 불분명한 방식은 늘 전근대적인 것으로, 피해야할 무엇으로 인식되어 왔다)
그리고, IncrementalDevelopment에 대한 선호도 공통적이다.
하지만 XP에서 위키위키라는 기술적인 시스템을 이용하는 것은 아니다. 대신 그 바탕이 되는 철학이 비슷하고, 추구하는 가치에 교집합이 많으며, 실행법에 있어 유비적으로 대응되는 것이 상당수 있고, 또 역사적 사실 관계 때문에 연관이 있다고 할 수 있는 것이다.
질답 ¶
Q : Pair 가 아닌 혼자서 XP를 진행하는 것이 의미가 있을까요?
.png ":)")
Q : ExtremeProgramming을 보다 넓게 적용해서 ExtremeDoing 이라는 개념을 두어도 괜찮지 않을까요? 삶을 살아가는 새로운 방법이 생길지도 모른다고 봅니다. -- 최종욱
Q: XP에 빠른 feedback에 의한 테스트 위주의 개발방법이 있는것으로 알고 있습니다만, feedback을 빨리 얻을수 없는 embeded 개발 환경 같은 경우 어떤 방법을 사용할수 있을까요? dgon71