developerWorks : Java technology : Extreme Programming을 밝힌다: 진정한 XP 고객

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


	Extreme Programming을 밝힌다: 진정한 XP 고객

소프트웨어 프로젝트를 운영하는 방법 배우기

Level: Introductory

Roy W. Miller
소프트웨어 개발자, RoleModel Software, Inc.
2002년 12월

지난 달 XP로 작업하기 위해 필요한 마음가짐에 대해 배웠다. 팀에 속한 모든 사람은 생각하는 방식을 바꿔야 한다. 이 글은 사용자(비지니스 정책 결정자)가 이러한 변화로 인해 힘들어하는 이유를 설명한다. 그들이 생각하는 방식을 바꾸지 않은 채 소프트웨어 프로젝트에 참가하는 한 결과는 어떤 누구도 만족시킬 수 없다.

XP는 비지니스를 하는 사람들의 사고방식에 근본적인 변화를 요구하고있다. 지난 30년 동안, 소프트웨어 개발 방식은 기술력이 없는 사람들이 특정한 방식으로 생각하고 행동하도록 하였다. 그러한 전통적인 방식은 사람들이 원하는 결과를 만들어낼 수 없었다.

어려운 문제부터 이야기해보자. 전통적인 소프트웨어 개발은 일관성있게 수행되지 않았다. 주요 원인 중 하나는 낮은 기대이다. 고객은 그들이 할 일을 하지 않았다. "고객(customer)"이 XP 프로젝트에게 있어서 어떤 존재인지를 이해해야한다.

불가능한 꿈?
XP는 좋은 이야기를 하고있다. 고객은 프로그래머에게 어떤 소프트웨어를 만들어야 할지를 말한다. 고객은 기능들을 지정하고 그 이유를 설명한다. 고객은 기능을 정량화한다-기능에 대한 하한선도 있다는 의미인가? 기능을 정량화하는 것은 언제나 가능한 것은 아니지만 가치있는 목표이다. 만약 불가능하다면 계속해서 노력해보길 바란다.

비지니스 필요는 소프트웨어를 구동해야하는 것이지만 프로젝트를 이끄는 것은 개발자들이다. 개발자들은 그들이 원하는 것을 구현한다. 일단 프로젝트가 시작하면 고객은 관심을 끄거나 프로그래머들은 고객에게 설명하지 않는다.

Taylorism
Frederick W. Taylor는 1880년대에 기계 회사의 대표였고 30년이 넘도록 공장 제품을 연구하였다. 그는 비효율성이라는 문제에 주목했다. 그는 "한 가지 최상의 방법"을 찾아서 비효율성을 없애려고했다. 그리고 관리자들이 그러한 방법을 찾을 수 있는 시스템을 고안하기 시작했다. 1950년대 까지 Taylorism은 기본적인 관리 철학이였다. 소프트웨어 개발은 바로 그 시기에 등장하였고 기업을 운영하는 사람들은 같은 관리 철학을 받아들여 소프트웨어에 적용하였다.

자동차 생산라인을 생각해보자. 한쪽 끝에서는 부품과 원료가 들어오고 다른 한쪽에서는 완성된 차가 나온다. 라인에 참여한 모두가 함께 모여 대신 자전거를 만들고 싶을 수도 있다. 생산 라인상에는 창조의 여지가 없다. 언제나 정확하게 똑같이 라인이 정확히 작동하는 것이다. 이 세계에서는 문제와 솔루션은 언제나 같고 프로세스를 효과적으로 최적화할 수 있다. 물론 모든 것을 최적화하고 원활히 실행시킨 후에는 변화라는 것은 적(enemy)이 된다. 물론 환경이 근본적으로 동적이라고 해도 모든것은 예견 가능하다.

"효율성" 모델은 소프트웨어에는 나쁘게 작용할 수 있다. 소프트웨어의 경우, 문제는 항상 다르다. 한번 겪었던 문제일수는 있지만 결코 같지 않다. 솔루션도 같을 수 없다. 올바른 대답을 얻기위해서 단순히 매뉴얼을 따라갈 수도 없다. 문제가 다르고 솔루션이 다르면 최적화라는 것은 잊어야 한다. 이것은 존재하지 않는다. 변화는 지속적이다.

그런 의미에서 소프트웨어 개발팀들은 어셈블리라인 사고에 갇혀있다. Taylorism은 기업 문화에 깊게 새겨들었다. 소프트웨어 프로젝트의 고객들은 사용자 그룹을 대표하는 사람들이거나 소프트웨어 사용자들이다. 그들이 사용자들을 대표하고 있다면 그들은 관리자들일 것이고, 사용자라면 그들은 관리자들에게 통제를 받는 환경에 있다. 두 경우 모두 생산라인 사고는 하나의 표준이다.

소프트웨어 개발에 개입되어있는 비지니스 피플(business people--고객)은 그들의 역할이 프론트 엔드 역할이라고 믿게 되었다. 초기 개발 사이클에서 그들은 프로그래머들에게 불변의 요구사항을 지정한다. 그리고 뒤로 물러나 결과를 기다린다. 물론 그들은 그 프로세스에 대한 제어권을 가져야 한다. 결국은 그들은 대가를 지불하고 이에 따라 요구사항을 제시하고 결국 결과물에 만족해야하는 사람들이다. 그러나 고객은 소프트웨어를 좀처럼 구동하지 않는다. 프로그래머들은 소프트웨어가 완벽하지 않는한 배포하기를 원하지 않는다. 그리고 고객은 새로운 소프트웨어가 사용자들에게 파괴적인 영향을 끼치는것을 원하지 않는다. 이 두 가지 대립으로 인해서 프로젝트가 시작한 후 몇년이 지난후에 소프트웨어는 릴리스된다.

이 사이클의 끝에 나오는 것은 고객이 필요로하지 않는 소프트웨어이다. 이것은 프로젝트가 시작할 때 고객이 필요하다고 생각했던 것이다. 대부분의 고객들은 그와 같은 "시대에 뒤진" 소프트웨어를 사는데 흥미가 없다. 개발자들은 이와 같은 소프트웨어를 내보이기를 원치 않지만 다른 방법이 없다고 믿는다. 모든 사람들은 좌절하고 지쳤으며 화가나있고 부족함을 느낀다.

이 라인을 따라가면 소프트웨어를 만드는 사람들은 타협한다. 아마도 직업을 유지하거나 충돌을 최소화할 것이다. 게으름을 피울 수도 있다. 사람들은 질 나쁜 흥정을 한다. 변화보다는 제품 그 자체를 가지는 것이 낫다고 생각한다. 우리는 그 길에서 되돌아 가야한다. 최상의 출발점은 고객과 함께하는 것이다.

변화의 노력
소프트웨어 개발은 지난 30년이 넘도록 일관성을 유지했다:

사용자들은 그들이 원하는것이 무엇인지 모른다. 따라서 개발자들은 무엇인가를 만들어내기 위해서 그들에게 말해야만 한다.
변화는 상처를준다. 따라서 우리는 어떤 대가를 치르고서라도 이를 진압해야한다.
변화를 억누르는 방법은 시작할 때 모든 것을 기록한 후 여기에 서명하도록 하여 계획을 고수한다.
시작 단계에서 모든 요구사항들을 정의하는 한 가지 방법은 고객들이 일련의 요구사항에 헌신하도록 하여 나중에 완성된 제품이 그러한 요구사항들과 일치하는지를 확인하게 하고 중간에서 손을 댈수 없게 한다.

결과적으로 대부분의 소프트웨어 프로젝트는 소프트웨어 사용자들이 궁극적으로 바라는 것이 아닌 시작단계에서 원했던 소프트웨어를 만들어낸다. 원하는 바는 아니지만 관례에서 벗어나지 않은듯이 보인다. 책임을 맡고 있는 사람들은 변화를 지시할 수 없다. 과거에는 물론 앞으로도 그럴것이다. 왜 우리가 이러한 상태를 고수하고 있는가?

무엇보다도 XP 고객이 되고자하는 사람들은 이 부분을 변화시켜야한다. 누가 고객이 될 수 있는가? 보통 충분한 도메인과 엔드유저 지식이 풍부한 누군가가 기능의 우선권에 대해 결정할 수 있다. 이것은 사용자들이 진정으로 원하는 것이 무엇인지를 아는 수퍼 유저가 될 수도 있다. 시장이 요구하는 것과 경쟁사들이 어떤일을 하고 있는지를 알고 있는 마케팅 책임자가 될 수도 있다. 드물지만 기본적으로 작업을 수행하는 매니저가 될 수 있다. 누군가는 작업을 감당해야하고 헌신해야한다.

둘째, 고객을 대표하는 누구든지 프로젝트 팀의 일부로 생각해야한다. 그는 기꺼이 나머지 팀원과 많은 시간을 보내어 올바른 소프트웨어를 만들어야한다.

세 번째로 고객들은 불신을 중지하고, 프로젝트 팀의 노력이 더 나은 결과를 얻을것이라고 믿는대로 행동한다. 이는 프로그래머나 고객 모두에게 힘든일이다. 프로그래머는 모든 단계에 걸쳐 갈등 없이 훌륭한 소프트웨어를 만들고 싶어한다. 그들은 모든 것이 미리 정해져있고 이 스팩에서 어긋나지 않는것이 이를 보장한다고 생각한다. 고객들도 두려워하기는 마찬가지이다. 그들은 모든 가능한 요구사항을 내보이기를 원한다. 실제로 원하지 않는 것임에도... 협상의 여지를 많이 남기길 원한다. 이는 팀이 훌륭한 소프트웨어를 만드는데 도움이 되지 않는다. 고객들은 어떤 소프트웨어가 진정으로 필요한지를 말해야한다. 무엇이 가장 중요한 것인지를 말해야한다. 그때 그들은 프로그래머를 믿어주고 그들이 충실히 일을 수행할 수 있도록 해야한다. 물론 프로그래머는 고객들이 말한 것을 충실히 수행함으로서 신뢰를 얻어야한다.

네 번째로 고객은 소프트웨어에 대한 사고 방식을 바꿔야한다. 어떤 소프트웨어가 진정으로 필요한지 어떻게 알 수 있는가? 단지 두 가지의 접근 방식이 있다. 당신이 옳다고 생각하거나 소프트웨어를 일부분 보여주어 고객이 진정으로 필요로하는 것이 무엇인지 이해하도록 하라. 실제로 어떤 소프트웨어도 사용하지 않은 채 필요한 소프트웨어에 대해 많은 시간을 이야기하는 것은 어리석다. 요구사항을 진정으로 이해하는 유일한 방법은 팀 멤버들이 예제를 실행하도록 하는 것이다. 피드백은 좋은 방법이다. 따라서 팀은 빠르게 그리고 자주 릴리스해야한다. 소프트웨어가 "완벽"할 때까지 기다리는 것은 당신이 옳지 않다는 것을 드러내는 증거이다.

대부분의 조직들은 이러한 프로세스를 채택할 수 없다. 소프트웨어를 만드는데 XP를 사용하는 것에 대한 반대가 거세다. 유력한 몇몇 사람들은 이것의 타당성에 대해 우려를 합법적으로 표시할 수 있기 때문이다. 유력한 사람들은 고집스럽다.

조직이 문제이다!
XP 고객은 그가 속한 조직이 이를 불가능하다고 판단하면 작업을 수행할 수 없다. 이는 두 가지를 의미한다:

XP 팀은 속해있는 고객을 위해 존재해야한다.
고객의 책임자는 고객이 프로젝트 팀의 일원이 되도록 해야한다.

프로젝트 팀은 XP 고객이 작업을 수행하기 전에 XP를 사용하고 있어야한다. 팀이 XP를 사용하는 것처럼 가장하거나 고객의 권한을 제한한다면 작업할 수 없다. 불행히도 대부분의 조직들은 XP를 반대할 준비가 되어있다. 기본적으로 그리고 적극적으로! 조직의 아주 작은 부분이라도 XP를 시도할 준비가 되어있지 않다면 불가능하다. 하지만 당신이 작은 것을 시작할 수 잇다. 한 명의 고객이, 몇몇 개발자들이, 아주 작은 애플리케이션들이야말로 당신이 원하는 전부이다. 그 팀이 대단한 결과를 낸다면 다른 팀이 그와 같은 행동을 하도록 자극을 줄 수 있는 기회가 된다.

대부분의 조직들은 이 같은 일이 거의 불가능하다. 그렇다고 해서 멈춰버릴 것인가? 아마도 그렇게 해서는 안된다. 상황을 변화시키는 것은 용기이다.

변화하려는 용기
IT 기업이 관습에 젖어있는 이유는 다음의 세 가지 이다:

습관(Habit)
소심함(Cowardice)
비전의 부족(Lack of vision)

습관은 깨기 힘들다. 그렇게 행동해서는 안된다는 것을 의식하고는 있지만 이것은 삶의 자연스런 현상이다. 이것은 흡연을 하거나, 과식하거나 또는 아이들에게 소리지르는 이유가 되기도한다. 일단 습관을 갖게되면 이를 깨는데에는 의식적인 노력이 필요하다. 대부분의 기업들이 소프트웨어를 만드는 방식은 그러한 조직을 구성하는 사람들의 습관에서 직접 기인한다.

기업내의 많은 사람들은 줏대가 없다. 어떤 일이 실제로 발생하고 조직이 그릇된 방향으로 가고 있다고 생각할 때 그들은 숨거나 도망간다. 조직안에서의 삶이 충분이 나쁘고 최선의 노력에도 불구하고 이를 향상시킬 수 없다면 떠나야할 시기이다. 하지만 부딪쳐야할 신호에도 도망가는 것은 문제해결이 아니다. 당신은 비슷한 문제들이 다시 재발할 어딘가로 갈 것이고 그리고 새로운 장소를 찾는다. 이제 조직이 변하지 않는 이유를 알겠는가? 모든 사람은 도망가고 깨어진채로 방치하고 있다.

기술력을 갖춘 사람이든 그렇지 않은 사람이든 차세대 기업 리더가 필요하다. 그는 진실을 말할 줄 알아야한다. 전통과 관습의 벽에 부딪치더라도 말이다. 우유부단하거나 뒤로물러서는 전략은 힘을 발휘하지 못한다. 기술력이 없는 리더는 XP 팀에 대해서 고객으로서 작용해야하고 필요하다면 모든 시간 참여해야한다. 기술력이 있는 리더는 스팩을 좌지우지하는 권리를 기꺼이 포기하고 훌륭한 소프트웨어를 만들 수 있는 방법을 모색해야한다.

좀더 용기있는 사람들이 필요하지만 비전 없는 용기는 가치가 없다. 확신있는 비전과 용기를 갖춘 사람이 필요하다.

참고자료