애자일의 미래

<소개글>

1부에서는 애자일의 과거를, 2부에서는 현재를 다뤘다면, 3부에서는 미래를 다루도록 하겠

다. 여기서는 애자일의 장점보다는 단점, 당면 과제, 그리고 앞으로의 발전 방향 등을 집중

적으로 살펴보도록 한다.

<필자 소개>

김창준 juneaftn@gmail.com | 현재 기업과 일반인 대상으로 애자일 방법론을 교육하고 코

칭, 컨설팅하고 있다. 2000년경부터 애자일을 사용해오고 있으며, 한국 XP 사용자 모임

(http://xper.org)을 설립했다. 애자일 이야기(http://agile.egloos.com)라는 블로그를 운영하

고 있다.

양적 확산

2002년도에 웹 포탈 회사에 컨설팅을 할 때였다. 당시(지금도 그런 편이지만) 애자일이나

XP라는 말은 무척 생소한 단어였다. 클라이언트 회사의 사원들과 토론을 하거나 강연 후

질문을 받을 때면 종종 이런 이야기를 듣곤 했다. “애자일은 SI개발에나 어울리지 우리 같

은 웹 회사에는 맞지 않아요.”

XP 자체가 크라이슬러사의 임금 지불 시스템을 개발하면서 만들어진 것이기 때문에 그런

이야기가 나왔던 것 같다. 당시 필자는 “웹에도 적용 가능한 부분이 있을 것이며, 외국에서

도 조금씩 사례가 나오고 있다. 올해(2002년도 당시) 웹 프로젝트를 위한 『 Extreme

Programming for Web Projects』(Addison-Wesley)라는 책도 나왔다”는 식으로 다소 궁색

한 답변 밖에 할 수 없었다. 사실 필자도 XP는 SI 프로젝트를 전제로 하고 만들어진 것 같

다고 느끼고 있긴 했다(고객, 즉 Customer라는 용어부터가 부쩍 그런 느낌을 준다).

이제 시간은 2004년경으로 건너 뛴다. C 언어를 사용하는 임베디드 업체와 네트워크 장비

업체들에 교육과 컨설팅을 하던 시기였다. 당시 자주 듣던 불평은 조금 달랐다. “애자일은

웹 프로젝트에나 어울리지 임베디드에는 어울리지 않아요.”

2년 사이에 뭔가 좀 변화가 있었나 보다. 지금은 2007년이다. 그때 이후로 다시 2년 남짓

지났다. “애자일은 임베디드에나 어울리지 X에는 어울리지 않아요”라는 말을 듣게 될까(임

베디드 쪽은 변화 수용의 속도가 느린 것 같긴 하지만, 요 몇 년 사이 애자일을 임베디드에

적용해 성공한 사례들이 속속들이 발표되고 있다1). 다음 X는 무엇이 될까?

애자일은 퍼졌다(애자일의 확산에 대한 내용은 1부 참고). 애자일이라는 딱지를 달지 않은

개별 실천법들은 더 널리 퍼졌다. XP의 아버지인 켄트 벡(Kent Beck)이 에리히 감마(Erich

Gamma)와 함께 만든, 자바용 단위 테스트 프레임워크 JUnit은 테스트 주도 개발을 하건

안 하건 자바 세계의 단위 테스트 프레임워크 표준이 되었다. 또한 리팩토링을 이용한 디자

인 개선은 OOP를 공부하는 사람이라면 누구에게나 필수 교양이 되었다.

그렇다면 국내 IT 프로젝트들의 성공률이 더 높아졌을까? 필자가 아는 한 국내 프로젝트에

대한 정량적인 조사가 아직 없으니 아직은 필자의 직간접 경험에서 이야기할 수 밖에.

약간은 독특한 프로젝트를 하나 소개하겠다. 그 프로젝트는 XP를 사용했다. 거의 모든 실천

법을 충실하게 지켰다. 수 천 개의 단위 테스트를 갖추었고, 코드를 수정함에 두려움이 없

었다. 사용자 스토리가 구현되는 속도도 만족스러웠다. 모두 짝 프로그래밍을 했고 아침마

다 기립 회의를 했다. 팀원들간의 인간 관계는 가족 같았고 팀의 사기는 회사에서 둘째가라

면 서러울 정도였다.

자 이제 슬픈 이야기이다. 이런 면에서 볼 때 그 프로젝트는 성공적인 XP 프로젝트였다. 하

지만 비즈니스 측면에서 그 프로젝트는 실패했다. 프로젝트와 팀이 공중 분해되었다.

한마디로 말해, 기술적으로는 성공했으나 사업적으로는 실패한 프로젝트이다. 왜 이런 모순

이 발생했을까? XP는 현실적으로 위태로운 방법론인가? XP의 약점을 보여주는 사례인가?

실패의 원인

애자일 방법론을 사용하는 팀들 중에는 성공하는 팀도 있고 실패하는 팀도 있다. 무엇을 기

준으로 한 성공과 실패인가? 필자는 성공을 다음과 같이 정의한다. 그 사람들의 노력이 자

신들이 속한 조직과 고객(사용자)에게 충분한 가치를 창출했다면 성공이다. ‘충분한 가치’라

는 말 자체의 모호함이 있긴 하지만 상식적으로 받아들여서, 예컨대 제품을 개발해서 시장

에서 많이 판매되고, 그것이 회사에 이익으로 돌아오고, 또 사용자는 그 제품에서 가치를

얻는다면 성공이라고 할 수 있다.

필자의 경험으로는 애자일 방법론, 특히 XP를 사용하는 팀 중에 실패하는 팀들은 많은

경우 기술적 성공에 집중했다. 기술적 성공은 작은 성공이다. 개발자들끼리 뭔가 오손도손

1 http://xper.org/wiki/xp/EmbeddedSoftwareDevelopment 참고

할 수 있다. 껄끄러운 사람들과 대면할 필요도 없다. 이런 위험은 모든 방법론이 내포하고

있는 것이지만, 기술적 지침을 가장 상세하고 친절하게 제시하는 XP의 특성상, 아무래도

XP가 그런 종류의 위험에 더 노출되어 있다고 생각한다.

아이러니하게도 XP에는 이런 기술적 경도에 균형을 맞춰주는 요소들이 이미 갖추어져 있다.

전체 팀이나 일주일별/분기별 주기, 진짜 고객 참여, 사용별 지불2 등이 그것이다. 켄트 벡

은 『익스트림 프로그래밍 2판』에서 말한다.

XP를 만들면서 처음에 나는 프로그래머들에게 치우쳐 생각했다. 내 배경이 프로그

래머이기 때문이다. …(중략)… 이제 내 목표는 팀이 기술 쪽의 관심사와 비즈니스

쪽의 관심사를 조화시킬 수 있도록 돕는 것이다. <p. 216>

필자는 어떤 방법론 자체의 약점을 이야기한다는 것은 별로 유용하지 않다고 생각한다. 대

신 그 방법론을 실천하려고 노력하는 사람들이 자주 처하는 어려움에 대해 이야기하는 것은

유용하다. 왜냐하면, 방법론 자체의 단점을 이야기하다 보면 현실을 배제한 탁상공론이 되

기 쉽기 때문이다. 뒤집어 생각하면 “아, 그건 그 사람들이 잘못해서 그렇습니다, 방법론은

완벽한데 말이죠”라는 식의 오류에 빠질 수도 있다.

XP에 기술적 치우침을 균형 잡는 힘이 있다고 하더라도 XP를 실천하는 팀들 중에 그렇게

하지 못하는 팀이 있다면 그것은 실존적인 문제이다. 완벽한 방법론의 오류에 빠져서는 안

된다.

성공의 원인

전세계적으로 가장 많이 인용되는 IT 프로젝트 성공/실패 통계 자료가 있다(필자가 본지에

몇 번 소개를 한 바 있다). 스탠디쉬 그룹(Standish Group)에서 발행하는 카오스 보고서

(CHAOS Report)이다. 1994년부터 발행을 시작해서 매년 갱신되어 오고 있다. IT 프로젝트

역사상 가장 방대한 통계로 수 만 개가 넘는 프로젝트에 대한 정보가 들어있다. 이 통계는

IT 프로젝트의 성공률과 실패율에 대한 분석뿐만 아니라 왜 실패를 했는지, 또 반대로 성공

요인은 무엇이었는지도 함께 분석을 한다.

스탠디쉬 그룹에서 뽑은3 성공의 원인 탑 104에서 상위 여섯 가지만 보도록 하자.

2 자세한 내용은 『익스트림 프로그래밍』(김창준, 정지호 공역, 인사이트) 참고 3 http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS 참고 4 카오스 보고서에서는 이 탑 10에 각기 점수를 부여한다. 총합은 100점인데 프로젝트 성

공의 확률(최고 100%)을 말한다. 순위가 높을수록 성공 확률이 높다. 현 프로젝트에 해당하

1. 사용자의 관여

2. 경영진의 지원

3. 분명한 비즈니스 목표

4. 범위(Scope) 최적화

5. 애자일 프로세스

6. 프로젝트 관리자의 전문성

1위가 사용자의 관여이다. 성공의 원인은 부재시 실패의 원인이 된다. 사용자가 관여하지

않은 프로젝트는 실패 확률이 매우 높다. 실패하는 프로젝트들의 가장 큰 실패 원인이 사용

자의 불참이라는 이야기이다.

2번째는 경영진의 지원이다. 경영진의 관심과 지원이 프로세스나 PM의 역량이 뛰어난 것보

다 프로젝트 성공의 확률을 더 높여준다.

3번째는 분명한 비즈니스 목표. 우리가 얻고자 하는 것은 HTML과 서블릿, 데이터베이스가

아니다. 비즈니스 목표가 분명하고 그것이 공유되어야 한다.

다섯번째가 눈에 띈다. 애자일 프로세스. 그렇다. 애자일 프로세스는 통계상으로 프로젝트

성공 요인 탑 10에 들어간다. 자그마치 5위.

그렇다고 애자일 프로세스를 하면 프로젝트의 성공이 보장되는 것은 아니다. 적어도 위 순

위의 다른 항목들도 함께 갖추어야 한다. 사용자의 참여는 애자일 프로세스에서 적극적으로

장려하는 것이기 때문에 비교적 쉬울지도 모른다. 하지만 제대로 참여해야 한다. 이에 대해

서는 조금 후에 상술하도록 하겠다. 2번 경영진의 지원과 3번 비즈니스 목표를 놓친 애자일

프로젝트를 본 적이 있다. 그런 상황 하에서 성공하려면 정말 많은 노력과 희생, 또 운이

필요하다.

XP 팀들을 보면 2번과 3번의 부재 상황에서 어떻게 해야 할 지 방법을 몰라 하는 팀들이

많다. 이럴 경우 설상가상으로 1번까지 제대로 되지 않는다. 그들은 일종의 반사 작용으로

단위 테스트와 짝 프로그래밍 같은 것에 더 집중하기 쉽다. 스트레스를 받으면 익숙하고 안

전한 것으로(결과적으로는 반대이지만) 회귀하려는 본성 때문이다.

는 항목들의 확률 점수를 더하면 프로젝트 성공률이 나온다. 통계적 결과이다. 여러분은 위

여섯가지 항목 중 몇 가지에 그렇다고 답할 수 있는가?

조각 케익

이런 경우 필자는 소통할 것을 권한다. 될 수 있으면 개발자라는 울타리를 넘어서서 소통해

볼 것을 권한다. 그 과정 중에 경영진의 지원을 얻을 수 있고, 비즈니스 목표가 분명해질

수 있으며, 고객이나 사용자의 참여를 유도할 수 있다.

마케팅 팀과도 이야기 해보고, 전략 팀과도 이야기를 해보라. 사장님과도 대화의 자리를 마

련하도록 노력하고, 고객과 같이 고민하라. 내부에서 이런 자리를 마련하는 것이 쉽지 않다

면 외부인의 손을 빌리는 것도 효과적인 방법이다. 싸움은 중재인이 끼어야 화해가 쉬운 것

과 비슷한 원리이다.

이것이 어렵다면?

신뢰 관계를 형성해야 한다. 그러려면 지속적인 가치의 흐름을 만들어야 한다.

<그림 1> 두가지 변화의 양상

<그림 1>을 보자. 왼쪽과 오른쪽의 그래프를 비교해 보면 왼쪽은 시간의 흐름을 따라 볼

때 거의 변화가 없다가 어떤 시점에 큰 변화를 보인다. 오른쪽은 시간의 흐름에 따라 점진

적으로 바뀌어 가고 있다. 어느 쪽이 더 애자일적인가?

세로축이 발견된 누적 결함수라고 생각해 보자. 이제까지 결함을 하나도 발견 안했다가 출

시 한 달 전에 통합을 했더니 엄청난 양의 결함이 와장창 나온 경우(왼쪽)와 점진적으로 계

속 결함을 발견해서 제거해온 경우(오른쪽)가 될 것이다.

소프트웨어 공학에 DCI(Defect Cost Increase, 결함 비용 증가)라는 법칙이 있다. 결함이

삽입된 시점과 그 결함을 제거하는 시점 사이의 간격이 멀수록 비용이 커진다는 법칙이다.

개발 초기에 삽입된 결함을 프로젝트 후기에 고치려고 하면 삽입 시점 근방에 고쳤을 경우

에 비해 통상 20배에서 50배 정도 비용이 높아진다고 한다.

따라서 결함을 미리 미리 발견하고 제 때에 고치는 것이 전체 비용을 낮추는 방법이다. 이

경우, 발견된 누적 결함수는 <그림 1>의 오른쪽 그래프와 같이 점진적인 변화를 보일 것이

다.

이번에는 세로축이 가시성이라고 해보자. 개발 기간 6개월 동안 그 프로젝트가 어떤 상태에

있는지 전혀 알려져 있지 않다가 1주일 전에 고객을 찾아와서는 말한다. “죄송합니다. 지금

어쩌고 저쩌고에 문제가 있어서 해결 중입니다. 한 달만 연기해 주세요.” 왼쪽의 그래프이

다. 어떤 시점에 가시성이 팍 높아졌다. 1주일에 한번씩 현 프로젝트의 상태를 보고했다면?

오른쪽 그래프처럼 가시성은 시간의 흐름에 따라 부드럽게 증가했을 것이다.

마지막으로 세로축에 비즈니스 가치를 놓아보자. 대다수의 전통적 프로젝트는 다음과 같이

진행된다. 데이터베이스를 맨 밑에 깐다. 그 위에 퍼시스턴스 추상화 레이어를 깐다. 그 위

에 다시 도메인 모델 레이어를 깔고, 다시 그 위에… 케익을 만드는 과정과 흡사하다. 밑에

서부터 층층이 쌓아 올려서 마지막에 인형 꽂고 장식하면 완성이다. 케익의 비즈니스 가치

는 그 케익이 완성된 시점에 비약적으로 증가한다. 10단 레이어 케익인데 3단만 쌓아올린

상태에서는 시장에 내다 팔 수가 없다. 좌측의 그래프이다.

시간에 따른 비즈니스 가치 변화에 대해 우측의 그래프가 가능할까? 가능하다. 케익을 레이

어 단위가 아니라 조각 단위로 만들면 된다. 애자일에서 말하는 기능5 단위 개발이다. 이렇

게 하면 더 자주 더 일찍 피드백을 받게 된다.

5 제품 포장 상자에 인쇄되는 제품 특징(feature)들을 모두 광의의 기능으로 볼 수 있다. 좀

더 정확하게 정의하자면, 최소 시장성 기능(Minimum Marketable Feature, MMF)이라는 용

어를 쓸 수 있다. 그 자체로 시장에서 가치를 갖는(따라서 사용자에게 가치를 주는) 최소

기능 묶음을 일컫는다. 이 MMF가 필자가 말하는 케익 조각과 유사하다. MMF에 대해서는

<Software by Numbers, Prentice Hall>를 참고하라.

1000개의 기능이 각기 50%씩만 구현된 경우와, 그 1000개 기능 중 가장 중요한 것 순서

대로 상위 500개의 기능이 전부 100%씩 완료된 경우를 비교해 보자. 당연히 후자의 가치

가 크다. 그리고 그 상위 500개의 기능이 만들어져 가는 과정 역시 좀 더 중요한 기능을

먼저 완성하는 식으로 이루어진다. 덕분에 이자 이득을 얻을 수 있고 ROI(투자 대비 회수)

가 높아진다.

이 방식을 추구하면 경영진은 물론 고객 및 사용자의 관심과 지원을 얻기가 쉽다. 또, 비즈

니스 목표가 불분명한 경우 그 문제를 덮어 두는 것이 아니고 더 드러내서 이슈화하고 공론

화해 주며, 더 나은 목표를 찾아나가는 효과가 있다.

조각 케익 방식은 프랙탈(fractal)적으로 적용 가능하다.

<그림 2> 조각 케익 방식의 프랙탈적 적용

여러 시간 스케일에서 매 마디마다 피드백을 통한 재조정을 하고 있다. 1달에 네 번씩 가치

를 얻고 또 그 가치를 통해 계획을 조정한다. 다시 1주일이라는 시간 스케일에서는 총 다섯

번(매일) 가치를 얻고 계획을 조정한다. 이것은 10분, 1분, 10초까지도 내려갈 수 있다. 반

대로 1달은 3개월, 6개월로 확장할 수도 있다.

필자는 이 프랙탈적인 마디별 피드백과 조각 케익의 개념이 애자일의 핵심이라고 생각하고

있다.

XP를 담금질한다

글렌 반데어버그(Glenn Vanderburg)는 2005년도 OOPSLA 컨퍼런스에서 흥미로운 에세이

를 발표했다. ‘애자일 소프트웨어 프로세스의 단순한 모델 혹은 익스트림 프로그래밍 담금질

(annealed)’6이라는 긴 제목이다. XP의 12가지 실천법이 서로 의존관계가 촘촘한 것을 두고,

데이브 토마스(실용주의 프로그래머 중 한 사람)가 “회사에서 이렇게 커플링이 긴 한 소프

트웨어를 만들었다면 아마 쫓겨날 겁니다”라는 이야기를 한 것이 논문의 발단이 되었다.

글렌은 XP의 12가지 실천법을 독특한 방법으로 분석해서 단순한 모델을 제시하고, 이것은

단순한 의존성이 아니고 상호 강화의 상생 관계라고 주장한다.

그는 XP의 12가지(논문에서는 단위 테스트와 승인 테스트를 구분해서 13가지로 했다) 실천

법을 환형 위상 정렬(circular topological sorting) 해보았다.

<그림 3> 13가지 실천법의 정렬 전(左)과 후(右)

<그림 3>에서 보는 것처럼 의존 관계는 방향성이 있는 화살표로 연결되어 있다. 왼쪽의 그

래프는 정렬 전이고 오른쪽은 정렬 후이다. 뭔가 패턴이 보이지 않는가?

6 http://www.vanderburg.org/Writing/xpannealed.pdf

글렌은 여기에서 흥미로운 사실을 발견했다. XP의 실천방법들은 적용 스케일별로 그룹 지어

볼 수 있다는 점이다. 예를 들어 코드의 실행문 레벨이 있는가 하면, 설계 레벨이 있고, 아

키텍처 레벨이 있으며, 기능이나 우선 순위의 레벨도 있다. 또 시간이라는 축에서 보면, 수

초가 있고 수 분이 있으며 수 시간이 있고 수 개월도 있다. 강력한 관계를 맺고 있는 실천

방법들은 유사한 스케일에서 작동한다. 왜 이런 스케일별 구분이 필요할까? 피드백은 자주

있으면 좋다. 하지만 거기에 따른 비용 증가도 있다. 따라서 비용이 큰 것은 더 큰 스케일

에서 가끔 하도록 하고, 비용이 작은 것은 작은 스케일에서 자주 하도록 한다. 그러면 작은

스케일에서 걸러내지 못하고 통과한 문제점, 결함 등은 나중에 큰 스케일에서 잡아낼 수 있

다. 여러 개의 안전망이 존재하는 것이다. 자연 시스템이 이와 유사하다.

하지만 어느 스케일에도 속하지 않는 실천방법들도 있다. 코딩 표준, 리팩토링, 단순한 설계,

주당 40시간이라는 네 가지 실천법이다. 글렌은 이것들을 노이즈 필터라고 부른다.

저자는 논문 후반부에서 이 연구를 현실에 적용하는 방안을 몇 가지 제안하고 있다. 프로젝

트 별로 프로세스가 달라야 한다. 그렇다면 XP의 실천법 같이 상호 의존성이 강한 프로세

스는 어떻게 적용해야 할까. 스케일을 축으로 두고 교환, 대체하라고 한다. 예를 들어 몇몇

프로그래머의 반대로 짝 프로그래밍을 도입하기 어렵다고 치자. 대신 일주일에 한번씩 코드

리뷰를 하면 될까? 그러면 XP가 작동할 수 없다. 왜냐하면 짝 프로그래밍은 수 초라는 스

케일에서 동작하는 실천법이기 때문이다. 똑같은 스케일에서 적용되지는 않더라도 비슷한

수준에서 적용될 수 있어야 한다. 그래서 예를 들면 한 차례의 코딩(한두 시간이라고 치자)

을 시작하기 전과 끝난 후에 한 사람이 코드 리뷰를 하는 것은 짝 프로그래밍을 대신할 수

도 있다고 한다.

비록 『익스트림 프로그래밍 2판』이 출간되기 전에 쓰여진 논문이라서 새로운 실천방법

체계가 반영되지는 않았으나 통찰력이 있는 분석이라고 생각한다. 그리고 이 통찰은 앞서

필자가 주장한 마디별 피드백과 공명한다.

프로젝트와 프로덕트의 성공

애자일 프로세스를 사용하면서 항상 전체 그림을 보려는 노력을 끊임없이 해야한다. 애자일

의 성공은 이 노력의 정도에 크게 좌우된다. 사전에 설계 투자를 많이 하지 않는 대신 진행

과정 중에 끊임 없이 자신의 위치를 확인하고 지도를 보고 향후 경로를 재조정 해야 한다.

때로는 목표지점까지도.

프로젝트와 프로덕트의 성공이라는 것은 절대 쉽지가 않다. 아주 많은 것들이 모두 맞아들

어가야 한다. 기술적 성공은 단순히 일부분일 뿐이다.

번다운(Burn-Down) 차트라는 것이 있다. 애자일 방법론, 특히 XP와 스크럼(Scrum)에서

많이 사용하는 차트이다.

<그림 4> 번다운 차트7

구현해야 할 사용자 스토리들의 스토리 포인트(사용자 스토리의 크기에 대한 추정 단위, 시

간과 유사) 총합을 세로축에 두고 시간을 가로축에 둔다. 시간이 지나면서 완료되는 스토리

에 대해서는 전체 스토리 포인트 총합에서 해당 스토리 포인트를 차감한다. 정상적인 프로

젝트라면 점점 Y값이 내려올 것이다. 때로는 새로운 스토리가 추가되면 Y값이 올라가기도

한다. 그러다가 X축과 만나는 지점이 프로젝트 완료 지점이다.

번다운 차트는 유용한 정보 방열기이다. 프로젝트 진행 상태를 한 눈에 볼 수 있고, 이제까

지의 곡선의 기울기에서 대충 점선을 그어보면 언제쯤 프로젝트가 완료될지 약식으로 회귀

분석까지 할 수 있다.

하지만 가끔 이 번다운 차트를 사용하는 팀이 빠지는 함정도 보았다. 맹목적이 되기 쉽다.

우리가 얼마만큼의 사용자 스토리를 구현했는가에만 집중한다. 애자일 프로세스를 하면서

7 출처는 http://www.xprogramming.com/xpmag/BigVisibleCharts.htm

오히려 계획을 되도록 고치지 않으려고 한다8. 당장 우리에게 주어진 스토리들을 구현하는

것이 우리의 최대 목표가 되어 버린다.

댄 노스(Dan North)는 작년 자신의 블로그에 애자일에 다섯번째 가치가 필요하지 않나 하

는 글을 썼다9. 제목은 ‘기능보다 성과(Outcomes over Features) – 다섯번째 애자일 가치?’

이다. 프로젝트나 프로덕트의 성공은 기능 구현에도 의존하지만 그보다도 성과와 결과가 더

중요하다는 주장이다. 필자도 여기에 깊이 공감한다.

어떤 기능이 구현되었느냐 아니냐보다, 그로 인해 고객과 사용자가 어떤 가치를 얻느냐가

더 중요하다. 하지만 종종 구현된 기능의 개수에만 매달리는 팀들을 보았다. 그런 조직은

기술적으로 성공하지만 비즈니스적으로 실패하기 쉽다.

그런데 이 주장은 앞서 필자 자신이 내세운 조각 케익과 충돌하지는 않는가? 조각 케익에서

는 레이어보다 기능 단위의 개발을 추천하는데? 필자는 ‘가치’를 중요하게 이야기했다. 그리

고 그 가치를 얻는 구체적 방법이 기능이라고 본다. 따라서 어떤 기능이 더 많은 가치를 가

져오는지 알 수 있어야 하고, 또 더 많은 가치를 갖는 기능을 고안할 수 있어야 한다.

훌륭한 고객

필자가 그래디 부치(Grady Booch)를 인터뷰한 기사가 마소 2002년 11월호에 실렸다. 그래

디 부치는 ‘UML의 아버지’ 중 한 사람이고 RUP와도 관련이 깊지만 애자일 연합(Agile

Alliance) 위원회 소속이고 스스로 “애자일을 믿는다”고 표현하는 사람이다. 그에게 XP에서

가장 취약한 부분이 무엇인지 물었다.

XP에서 가장 약한 부분은 -- 이 의견은 랄프 존슨(Ralph Johnson)과 함께 하는

것인데 – ‘고객’이라고 하는 개체에 믿을 수 없을 정도로 많은 책임을 덩어리 째

맡기면서, 어떻게 그 고객이 성공적일 수 있는지에 관해서는 대부분 아무런 가이

드도 제공해주지 않는다는 점입니다. 개발자의 일이 간단해질 수 있게 상당한 양

의 책임이 고객 역할에 전가됩니다. 하지만 실제는, 그 복잡성은 대체로 그대로 남

습니다(하지만 XP는 이것을 은폐합니다). –그래디 부치

8 마틴 파울러(Martin Fowler)는 다음과 같이 말했다. "계획이 상시 바뀌고 있지 않다면, 적

응적 계획하기(adaptive planning)를 하고 있지 않을 확률이 매우 높기 때문에 결국 애자일

하지 않은 겁니다." (출처는 http://www.martinfowler.com/bliki/FeatureDevotion.html) 9 http://dannorth.net/2006/10/outcomes-over-features-the-fifth-agile-value 참고. 애자

일의 네 가지 가치는 애자일 선언문(http://agilemanifesto.org/)에 명시되어 있다.

XP는 개발자가 뭘 해야할 지 시간, 분, 초 단위까지 가이드가 있다. 이런 방법론은 거의 전

례가 없다. 동시에 고객의 중요성도 설파한다. 하지만 고객이 구체적으로 어떤 일을 어떻게

하면 좋을지에 대해서는 가이드가 충분하지 못하다. 주 단위, 분기 단위로 개발자와 계획을

하고, 사용자 스토리를 작성하고, 승인 테스트를 하고 등등의 실천사항은 있으나 어떤 사용

자 스토리를 작성하는 것이 좋은지에 대해서는 별 말을 하지 않는다10.

훌륭한 개발자가 되는 방법은 XP에 있다. 하지만 훌륭한 고객이 되는 방법은 XP에 없다.

그런데 XP는 훌륭한 고객에 의존한다. 무엇을 만들어야 할 지의 의사 결정과 그걸 어떻게

만들어야 할 지의 의사 결정을 분리하고, 또 크게 보면 결정자와 건설자의 책임을 분리하고

있다. “고객이 사용자 스토리를 잘 만들어주면, 우리는 그 때부터 시작이다. 프로젝트가 실

패하면 고객이 사용자 스토리를 잘못 만들어서 그런 것이다.”

이 위험을 예방하는 방법은 앞서 소개한 소통하기, 그리고 조각 케익과 마디별 피드백이다.

고객에게 실제 가치를 전달하고 여기에서 계획을 조정하고 하는 일을 재빨리 반복하다 보면

일반적으로 고객은 학습을 하고 더 훌륭한 고객이 된다.

하지만, XP에서는 지나칠 정도로 고객의 책임과 개발자의 책임을 분리하는 경향이 있는 것

만은 사실이다. 필자가 보아왔던 성공적인 프로젝트, 프로덕트들은 결정자와 건설자의 구분

이 모호한 팀에서 나왔다.

개발자도 훌륭한 고객의 역할을 할 수 있어야 한다. 부담이 하나 더 늘었다고 생각할지 모

르겠으나 모두가 훌륭한 고객이 되는 학습 기간을 단축할 수도 있다. 하지만 그렇다고 해서

모두가 고객이요, 아무도 고객이 아니다라는 이야기를 하자는 것은 아니다. 고객도 일종의

전문성이 필요하다(하지만 그 전문성은 다른 사람들과 공유될 수 있어야 한다).

XP에서는 고객이 어디로 갈지를 결정한다. 여기에서 고객(Customer)이라는 말은 모호하다.

실제 하게 될 일보다 훨씬 좁은 역할을 암시한다. 그래서 우리는 대체어가 필요하다. 브라

이언 매릭(Brian Marick)은 프로덕트 디렉터(Product Director)를 제안한다 11 . 번역하자면

제품 감독(영화의 감독을 연상하라) 정도 되겠다.

고객, 아니 프로덕트 디렉터는 그 역할의 중요성을 인식해야 한다. 그리고 더 나은 프로덕

10 몇 년 전에 고객 역할에 대한 서적이 두 권 출간되었다. 모두 마이크 콘(Mike Cohn)의

저서인데 이제까지 XP에서 비어있던 구멍을 충실히 채워준다. 한 권은 『사용자 스토리』

라는 제목으로 인사이트에서 작년에 번역 출간되었고, 다른 한 권은 『Agile Estimating

and Planning』인데 아직 번역되지 않았다. 두 권 모두 탁월하다. 11 http://www.testing.com/cgi-bin/blog/2006/02/07

트 디렉터가 되기 위해 노력해야 한다. 하지만 이것은 절대 쉬운 일이 아니다.

고객이 원하는 것

사용자 혹은 고객이 원하는 것이 있다. 비즈니스 분석가가 그들과 대화를 통해 그걸 문서로

옮긴다. 그리고 아키텍트는 그걸 보고 설계를 하고, 프로그래머는 코딩을 한다. 테스터가 시

험을 해보고 마지막에 고객에게 갖다 줬다. 고객의 반응. “어 이건 아닌데…” 어디에서 잘못

된 것일까? 첫번째 가설. 커뮤니케이션 과정 중에 놓친 것이 있고 와전된 것이 있다.

하지만 정말 완벽한 커뮤니케이션이 된다고 치자. 그래도 고객은 만족하지 못할 수 있다.

왜? 고객이 생각하는 것과 말로 표현하는 것의 차이가 있기 때문. 우리의 음성 언어는(문자

언어는 훨씬 더) 현존하지 않는 것을 묘사하는 데 형편없다. 자, 고객이 자신의 생각을 그대

로 표현할 수 있게 되었다고 치자. 그러면 만족이 보장될까? 그렇지 않다. 대다수의 고객은

자신이 무엇을 원하는지 그 생각 자체가 흐리멍텅하다. 고객의 생각을 명료하게 해주는 기

똥찬 발명품을 만들었다. 그럼 이제 만족할까? 아니다. 원하는 것과 필요로 하는 것은 다를

수 있기 때문이다.

제트 스키를 개발한 가와사키(Kawasaki)사는 제트 스키 경험을 개선하기 위해 무엇을 해야

할지 사용자들에게 물었다. 사용자들은 측면에 여분의 패딩을 추가해서 제트 스키를 서서

탈 때 자세가 더 편안하기를 원했다. 회사는 고객들이 요청한 것을 제공하는 데 집중을 했

다. 그 동안 다른 제조사들은 앉아서 타는 모델을 개발했고, 가와사키를 시장 최고 자리에

서 끌어내리게 되었다. 고객들이 원한 것은 제트 스키 이용시 더 편한 기립 자세였지만 그

들은 앉아서도 탈 수 있다는 생각은 해내질 못했다. ‘앉아서 타는’ 모터싸이클 제조 업체였

던 가와사키까지도.

그렇다면 고객이 필요로 하는 것을 알면 해결될까? 또 그렇지가 않다. 시장이 바뀌고 고객

의 마음과 상황이 바뀔 수 있기 때문이다. 플라톤 식의 천상의 해답은 없다. 계속 찾아나가

는 수 밖에 없다. 대화(비유적 표현이다)를 통해.

더 나은 대화를 이끌어 나가는, 더 훌륭한 프로덕트 디렉터가 될 수 있는 비 무기를 소개

하겠다. 역시 지나치게 협소한 의미로 쓰일 수 있는 단어를 말해야 하겠다. UX(User

eXperience). UX라고 하면 뭔가 시각 디자이너의 전유물 같다. 실제로도 디자이너(시각 디

자이너) 배경을 가진 분들이 이 역할을 많이 하는 것 같다. 하지만 UX의 실천법들은 그 폭

이 무척 넓다. 우리가 어느 길로 가야할 지, 올바른 길로 가고 있는지를 찾는 데 많은 지혜

를 준다. 프로젝트와 프로덕트 성공에 지대한 영향을 끼칠 수 있다.

UX 역시 전통적인 폭포수 방식으로 사용할 수도 있고, 애자일 방식으로 사용할 수도 있다.

당연히 필자는 후자를 추천한다. 최근 UX 전문가들 사이에서 애자일과의 결합을 반기는 사

람들이 많고, 성공 사례도 발표되고 있다12. 필자는 조만간 애자일이 UX를 적극 포용할 것

이라고 예측한다.

지면의 제한 때문에 상세한 내용을 소개하지 못하는 것을 무척 아쉽게 생각한다. 본인의 블

로그(http://agile.egloos.com)나 향후 마소 기사를 통해 더 많은 정보를 드릴 것을 약속한

다.

끝과 시작

이제까지의 내용을 정리해 보자. 애자일을 실천하는 팀들이 쉽게 빠지는 함정이 있다. 기술

중심적이 되기 쉽다. 고객의 역할을 등한시할 수 있다. 그리고 이 함정을 예방하는 방법들

도 어느 정도 있다. 개발자 외부와 소통하기, 조각 케익 방식과 여러 스케일에서의 프랙탈

적인 마디별 피드백, 그리고 훌륭한 프로덕트 디렉터와 UX.

애자일은 이제까지 많은 길을 걸어왔다. 『XP 1판』이 출판된 것이 1999년도이다. 하지만

앞으로 가야할 길이 더 멀다. 성공적인 프로젝트/프로덕트는 좀 더 온전하고 통합적인 프로

세스에서만 가능하다.

12 린 러(Lynn Miller)의 다음 논문을 강력 추천한다.

http://www.agile2005.org/XR19.pdf