Extreme Programming을 밝힌다: 돌아온 "XP distilled", Part 1

IBM 홈 | 제품 & 서비스 | 고객지원 & 다운로드 | 회원가입

IBM developerWorks > 자바


	Extreme Programming : 돌아온 "XP distilled", Part 1

XP의 진실

Level: Introductory

Roy W. Miller
Software Developer, RoleModel Software, Inc.
2002년 8월 13일

자바 언어의 객체 지향 프로그래밍은 상당히 유명해졌다. 소프트웨어 개발에 혁명을 가져왔다고 해도 과언이 아니다. 최근 조사 결과에 따르면 소프트웨어 개발 프로젝트의 절반가량이 늦어지고 있고, 3분의 1 정도는 예산 초과이다. 기술이 문제가 아니다. 소프트웨어를 개발하는 방식이 문제인 것이다.

Chris Collins와 내가 "XP distilled"를 쓴 이후 일년이 지나고 그 이후 약간의 변화가 생겼다. Extreme Programming (XP)는 약간 성장했고 더 많은 사람들이 이를 구현하는 사례가 전 보다 늘었다. XP가 이루어 놓은 것도 있는 반면 XP냐 아니냐에 대한 혼란과 논쟁이 여전히 남아있다. 심지어 Microsoft 조차 최신 OS를 "Windows XP"로 칭하면서 이 혼란에 가세했다

다음 달에는 이 칼럼을 사용하여 XP를 둘러싼 과대 광고, 근본적인 혼란을 파악할 것이다. XP와 조직에서 이를 구현하는 방법에 대한 아이디어에 대한 질문에 대한 답이 여러분에게 실제적인 자료가 될 수 있기를 희망한다. 이 칼럼의 여러 글들은 "XP distilled"의 확장 버전이 될 것이고 현재 관행과 XP 생각들을 다룬다. 나의 목표는 XP의 심화 연구를 지원하는 좋은 기초를 마련해주고 각자의 조직과 경력에 차이를 만들어주는 것이다.

나는 거의 10년 동안 소프트웨어 업계에 종사했다. 그 시간동안 XP 같이 나를 흥분하게 만든 소프트웨어 개발 방식을 접해본적 이 없다. 내 생각에 이것은 자연스러운 프로그래밍 방식이다. 물론 누구나 다 자연스럽다고 느끼는것은 아니다. 하지만 이를 경험해보면 다른 접근방식을 사용해 어떻게 살아왔는지가 의아해 질 것이다.

물론 XP가 훌륭한 소프트웨어를 만드는 유일한 방법은 아니지만, 나는 두 가지 측면에서 확신하는 점이 있다:

XP가 실현되는 원리는 올바른 것이다.
XP처럼 모든 조각을 하나로 묶는 소프트웨어 개발에 대한 접근방식을 경험해 본적이 없다.

"XP distilled" 시리즈
Part 2: "How programmer practices fit into the picture" (2002년 9월)

Part 3: "Customer and management practices" (2002년 10월)

아직 눈치를 채지 못한 사람들에게 밝히지만 나는 당당히 XP 광신자이다. 결국 여러분들도 그렇게 될 것이다. 하지만 이것이 교활한 마케팅 수법은 아니다. 다른 사람을 확신시키는 최상의 방법은 XP를 '있는 그대로' 드러내고 그런다음 사람들로 하여금 XP 접근방식이 그들이 사용하는 방식보다 나은지의 여부를 결정하도록 하는 것이다.

비지니스 문제
"XP distilled"가 나온 해에 IT 안팎의 기업 관리가 직면한 가장 큰 문제는 변하지 않았다. 어떻게 경영자들이 그들의 IT 자산과 기능을 이용하여 경쟁력있는 이득을 얻을 수 있는가? 많은 경우 이러한 "자산과 기능"에는 소프트웨어와 소프트웨어 개발이 포함되어 있다. 여기에서 바로 문제가 시작된다.

프로그래머들은 50년 넘게 코드를 만들어냈다. 그 당시 코드 '산맥'은 쓰여졌다. 이중 어떤 것은 좋게, 대부분은 나쁘게.. 이렇듯 형편없는 결과가 나온 이유는 간단하다. 소프트웨어 개발의 전통적인 접근방식이 프로젝트를 실패로 이끌기 때문이다. 가장 나쁜 부분은 좋은 의도, 부단한 노력, 명민한 사람들이 그들의 프로젝트의 대부분이 실패로 끝난다는 것을 경험한다는 것이다. "XP distilled"에서 우리는 프로젝트 성공 관련 숫자를 제공했다. 그림 1은 2000 Group CHAOS Report가 발표한 내용이다

그림 1. 소프트웨어 프로젝트 성공과 실패, 과거와 현재
Success and failure

나는 먼저 소프트웨어 잡지에서 이와 비슷한 그래프를 봤다. 그 작가는 이 그래프를 "꾸준한 성장을 보이는 프로젝트(Projects Show Steady Improvement)"라는 제목을 달았다. 그리고 1994년, 단지 16%의 프로젝트가 성공한 반면 2000년에는 28%의 프로젝트가 성공했다고 설명했다. 28% 는 분명 16% 보다는 많은 숫자지만 결과는 여전히 나쁘다. 전에도 언급했지만, 여러분이 표준 소프트웨어 개발 접근방식을 사용할 때, 자바 애플리케이션을 개발한다해도, 실망할 준비를 해야한다. 1994년의 첫 번째 CHAOS Report 이후 약간 향상된 부분은 잇지만 거의 75%의 프로젝트가 실패하고 있다. 조직의 리더들이 소프트웨어 프로젝트에 투자하기를 주저하는 것은 이상한 일도 아니다.

이유가 무엇일까? 많은 의견들이 분분하지만 다음과 같은 기본적인 이유 때문일 것이다.

사람들은 문제가 있다는 것을 인식하지 못한다.
문제가 있다는 것을 알지만 이를 해결하기 위해 다른 어떤 것을 시도하기를 두려워한다.
문제가 있다는 것도 알고 이를 적극적으로 해결하려고 하지만 해결하고자 하는 문제를 잘못 이해한다.
문제가 있다는 것을 알고있으며, 적극적으로 해결하려는 마음도 있고 문제도 이해하지만 상황의 제약을 받는다.

문제가 있다는 것을 인식하지 못한다!
인간에게는 자기 기만이라는 놀라운 능력이 있다. 기업과 프로젝트 리더들도 예외는 아니다. 모든 것이 잘 되고 있다고 모두가 확신하는 동안 소프트웨어 개발 프로젝트는 수포가 되어간다. 앞서 언급한 숫자는 조직에서의 소프트웨어 개발이 잘 되고 있지 않다는 것을 명확히 보여주고 있다. 물론 예외도 있다. 하지만 많은 조직들은 그들이 문제를 갖고 있다는 것을 자주 망각한다.

당신의 조직도 IT와 기업내 사람들 사이 적대적 관계를 갖고 있는가? 당신 조직의 비지니스 리더들이 다음과 같이 말하지는 않는가? "기술이 좀더 좋았다면 IT로부터 노우(NO)라는 소리를 듣겠는가?" 만일 그렇다면 해결이 필요한 문제를 갖고있는 것이다. 이 문제를 해결하지 않으면, 관성이 오랫동안 지속되면 실패가 멀지 않았다.

문제가 있다는 것은 알지만 이를 해결 할 위험을 감수하기 두렵다!
조직내의 보다 상식적이고 지적이며 예민한 사람들은 현재의 소프트웨어 개발 방식이 먹히지 않는다는 것을 인식한다. 그들은 단지 다른 방식을 시도해야 하는 모험을 두려워하는 것이다. 충분히 이해할 수 있는 일이다. 새로운 일을 시도할 때에는 용기가 필요하고 종종 위험도 감수해야 한다. 빠르게 무엇인가를 얻고 즉각적인 기쁨을 얻는 문화속에서 실패는 사람들의 경력에 큰 위험을 끼칠 수 있고 심지어 치명적이다.

대부분의 사람들은 가장 편한 방법을 택한다. 이러한 접근방식은 경력을 단기간 유지시켜 줄 수는 있으나 문제를 연기하거나 복잡하게 만들 뿐이다. 너무 오래 기다린다면 작은 문제는 해결불능의 것이 되고만다. 사람들이 용기를 갖게 하거나 위험을 감수하도록 하는 방법은 없다. 하지만 이 칼럼의 생각과 포럼들로 사람들에게 실패의 두려움을 지나가도록 하는데 도움이 되길 바란다.

문제를 인식하고 이를 해결할 의향도 있지만 문제 해결을 잘못 이해하고 있다!
가끔씩 사람들은 그들이 문제가 있다는 것을 알고 적극적으로 이를 해결하려고 한다. 하지만 잘못된 문제를 해결하려고 한다. 예를 들어 제품상의 문제를 해결하면서 무의식적으로 소프트웨어 개발이란 것은 어셈블리 라인 상의 제품을 찍어내는 것이라고 생각한다. 소프트웨어는 다르다. 소프트웨어에서 우리는 종종 새로운 영역을 탐험하고 한번도 시도하지 않은 것들을 한다. 이는 소프트웨어 개발을 다른 솔루션을 필요로하는 전혀 다른 유형의 문제로 만든다.

소프트웨어 개발 과정을 "기계화"하거나 제어하려한다면 통제력을 잃을 것이다.

문제가 있다는 것을 알고있으며, 적극적으로 해결하려는 마음도 있고 문제도 이해하지만 상황의 제약을 받는다!
문제가 있다는 것을 알고, 이를 적극적으로 해결하려고 하며, 해결하고자 하는 문제를 이해하지만 조직 내에서 행동을 취할 수 없다. 이러한 상황은 슬프고도 어렵다. 하지만 극복할 수 없는 문제도 아니다. 불행히도 비상한 용기가 필요하다. 변화를 위해서라면 다른 영역을 침범해야 한다. 하지만 당신이 조직의 건강을 해롭게하는 문제에 대한 언급을 거절할 리더쉽을 갖춘 조직의 일원이라면 선택권이있다. 있는 힘을 다해 변화를 이룩하거나 아니면 조직이 이것의 무게에 짓눌리기도 전에 떠나거나.

XP 가치
XP는 소프트웨어 개발자들이 최고로 잘 해야하는 것(코드 작성)을 할 수 있도록 하는 가치와 방법을 처방해준다. XP는 개발 인력들을 지치게 하는 모든 불필요한 것을 제거한다:

의사소통: 프로젝트와 관련한 문제들은 누군가에 의해 트레이스 될 수 있다.
단순함: XP는 프로세스와 코드 작성과 관련된 작업을 할 수 있는 가장 간단한 것을 수행할 수 있다고 장담한다.
피드백: 고객, 팀, 실제 엔드유저로 부터의 즉각적인 피드백은 자신의 노력을 조정할 더 많을 기회를 제공한다. 수렁에서 건질 수도 있다.
용기: 용기는 다른 세 개의 가치의 정황에서 존재한다. 그들 모두는 서로를 지원해준다. 언제나 구체적인 피드백이 모든 것을 알고 있는 것보다 낫다고 신뢰하기 위해서는 용기가 필요하다. 팀내의 다른 사람들에게 무지함을 노출시킬 때도 용기가 필요하다. 시스템을 단순하게 유지하는데에도 용기가 필요하다. 그리고 단순한 시스템, 지속적인 커뮤니케이션, 피드백 없이 용감해 질 수 없다.

XP 방법
XP의 19 가지 방법(표 1 참조)은 팀의 다양한 멤버들이 갖춰야 하는 습관을 정의하고 있다.

표 1. XP의 19 가지 방법

Joint practices 반복
공통 어휘
열린 작업공간
반추

Programmer practices 테스트 지향 개발
페어 프로그래밍(Pair programming)
리팩토링
단체 소유권
지속적 통합
YAGNI

Management practices 책임감
Air cover
분기별 리뷰
Mirror
타당성있는 진행

Customer practices 스토리 텔링
릴리스 플래닝
수락 테스트
수시 릴리스

Joint practice: 하나의 팀 만들기
이 그룹의 방법들은 모두에게 적용된다. 팀의 모든 사람들(프로그래머, 고객, 관리자)은 이러한 것을을 언제나 수행해야 한다. 이들은 하위 팀들도 함께 모아 하나의 팀으로 만들어야 한다.

공통 어휘
팀의 모든 사람들은 시스템에 대한 공통 이해가 필요하다. 해석하는데 오랜 시간이 걸리는 메타포는 필요없다. 모든 사람들이 사용할 수 있는 공유된 어휘를 갖는것에 주력하라.

열린 작업공간 (New)
비형식적 의사소통은 형식적인 것 보다 효과적이다. 작은 방을 가르는 칸막이는 비공식적 의사소통을 더 어렵게 만든다. 가장 좋은 방법은 열린공간이다. 여기에서 사람들은 무엇인가를 주워들을 수 있고 좋은 생각을 내놓을 수 있고 토론도 가능하다. 이러한 종류의 그룹 인터랙션은 놀라운 결과를 만들어 낼 수 있다. 벽을 없애라 .

어떤 사람들은 개방된 작업공간이 XP가 큰 팀에서는 효율적이지 못하다는 것을 의미하는 것으로 생각한다는 것을 들었다. 그들 말이 맞을지도 모른다. 하지만 솔직히 말해서 잘못되었다. 그들은 아마 두 가지를 생각할 것이다. 그들이 큰 팀을 필요로하는데 이들을 지원할 협업 환경이 없다는 것을 가정하는 것이다.

아마 여러분도 큰 팀이 필요할 것이다. 하지만 생각만 그렇게 하는 것인가 아니면 실제로 성장하고 있는가? 아마도 위대한 일을 수행하기에 좋은 환경에서 작업하는 좋은 개발자들 그룹은 큰 팀들 보다 빠르고 더 좋은 일을 할 수 있다.

반복(New)
XP를 채택하는 사람들은 프로젝트의 리듬에 대해 이야기한다. 이 리듬은 다양한 차원으로 존재한다. 하지만 반복은 실제로 중심에 있다. 1주에서 3주 마다 팀은 고객이 요구하는 새로운 기능으로 작업 시스템을 제공한다. 이것은 과격한 생각이다. 사람들은 이러한 방식으로 소프트웨어를 만드는 것에 익숙하지 않다. 대부분의 접근방식은 코드를 작성하기 전에 많은 것들을 수행하는 것에 초점이 가 있다. XP는 코드를 작성하고 사람들이게 이 코드를 사용하게 한다. 그리고 그들의 피드백이 프로젝트를 조정 할 수 있도록 한다.

반복은 일종의 계획으로 시작한다. 나는 이것을 반복 플래닝이라고 부른다. 이 플래닝은 릴리스 플래닝과 닮았다. 하지만 보다 상세하다. 우리는 다음 반복에 대해서만 주의를 기울인다. 고객에게 묻는다. "프로젝트가 다음 반복 뒤에 끝나면 어떤 기능을 얻고싶으십니까? 그때 우리는 그러한 기능을 구현하기위해서 작업을 평가한다. 고객은 우선순위 대로 몰고간다. 프로그래머는 비용을 정한다. 어떤것은 현재의 반복 안에서 떨어져 나가야 함을 의미한다 .

여기에서 timeboxing이란 단어가 중요하다. timeboxing이란 어떤 작업의 시간 제한을 설정하는 습관이다. 해당 시간까지 작업하고 그런다음 평가한다. 이것은 팀이 너무 오래 작업하는 것을 막는다. 반복 습관은 timeboxing 보다 우위 개념이다. 반복은 사람들로 하여금 과감한 결정을 내리도록 요구한다. 고객들은 가장 중요한 기능을 선택하게된다. 프로그래머들은 구현 방법과 노력에 대해 결정을 내린다. 관리부서는 프로젝트의 전략 방향을 정한다.

반추(New)

반추 없는 작업은 실패의 반복만을 초래한다. 팀의 각자가 자신의 작업을 돌아보고 무엇을 배웠는지를 돌아보고 팀의 나머지 사람들과 나누는 것이 좋은 방법이다.

프로젝트에서 배운 교훈에 대해 생각해보자. 잘 한것은 무엇이고 못한 것은 무엇인지 생각해보라. 팀이 어떻게 일을 수행했는지를 생각해보고 팀이 종합적으로 무엇을 생산했는지를 생각해보라. 일이 더 나아질 수 있겠는가? 왜 그런가? 어떻게 하면 더 나아질 수 있는가? 지금 하고 있는 것을 보다 잘 하기 위해 무엇을 해야 하는가? 어떻게 해야하는가? 이런 종류의 종합적 리뷰는 하나의 릴리스 후에 발생한다. 대체로 매번 반복이 끝날때 이런 일을 수행한다. 긴 시간이 필요없다. 이전 반복에 대해 반추하는 데는 한 두 시간이면 족하다. 지금 상태에서 팀을 보다 낫게 만들면서 가치를 끌어올릴 수 있다. 또한 재미도 함께 가져올 수 있다. 이는 매우 중요하다.

대부분 사람들과 나는 하루 작업 후에 "미니 반추" 시간을 갖는것이 도움이 된다는 것을 알았다. 몇 분 정도가 소요된다. 공유할 만한 것을 배우면 팀과 다음날 나눈다. 이러한 방식으로 많은 것을 얻었다.

반추에는 반드시 몇 가지 용어를 보다 효과적으로 해야 할 필요가 있다. 이에 대한 보상은 보다 통합된 팀이 된다는 것이다. 모든 사람이 이러한 소급 과정에 참여해야 한다. 기술팀과 비 기술팀 모두 참여해야 한다. 한 장소에 모이는 사람들이 너무 많으면 하위 팀들은 자신들의 반추 시간을 갖는 것이 좋다. 중요한 것은 같은 실수를 되풀이 하지 않는 것이다.

참고자료