애자일 ver01

애자일 방법론(기민한, 민첩한) 

개념 : 

애자일 방법론은 소프트웨어 개발 방법에 있어서 아무런 계획이 없는 개발 방법과 계획이 지나치게 많은 개발 방법들 사이에서 타협점을 찾고자 하는 방법론.

그러므로 계획을 통해서 주도해 나갔던 과거의 방법론과는 다르게 앞을 예측하며 개발을 하지 않고, 일정한 주기를 가지고 끊임없이 프로토 타입을 만들어내며 그때 그때의 필요한 요구를 반영하여 커다란 소프트웨어를 개발해 나가는 adaptive style이라고 할 수 있다.

애자일 개발 프로세스의 상당수는 객체지향 기술을 기반으로 한다.

애자일 처리방법은 반복적인 일과 경험에 의거한 피드백을 통해서 예층 불가능한 일에 대응할 수 있도록 도와준다.

애자일 개발 과정의 하나로 단순함과 융통성 때문에 가장 인기있는 방법론은 스크럼이다.

스크럼의 정확한 정의는 경험에 의거한 피드백, 팀의 자가적인 관리, 그리고 짧은 반복을 통해서 적합한 제품 테스트에 중점을 두는 개발방법론이다.

(출처: en.wikipedia.org)

전통적 방식은 디자인이나 코딩 전에 프로젝트에 필요한 모든 요인들을 다 파악할 수 있다고 가정 했을 시 과연 소프트웨어가 실행되기도 전에 필요한 모든 부분을 개발자 팀에게 알려줄 수 있을까?

또한 요구된 소프트웨어를 다 만들었을 때 원하던 소프트웨어이지 않을 때 많은 돈과 시간이 투자된것을 어떻게 되돌릴 수 있을까?

이런 문제점을 해결하기 위해 애자일 방법론을 사용하는데 중점이 있다.

잘못된 개발 흐름과 요구사항 변경 및 일정에 맞추기 위한 질 낮은 소프트웨어가 시장에 출시되는 것을 막고 많은 반복과 순간순간의 피드백으로 제품을 최적화 하기 위한다.

장점이라 생각되는 부분은 여기까지이고 단점을 알아보자.

왜 “애자일”, 특히 스크럼이 끔찍한가.

이 글은 Michael O. Church의 ‘Why “Agile” and especially Scrum are terrible’을 글쓴이의 허락을 받고 번역한 글이다. 퍼가는 것은 보는 사람 맘대로지만, 가끔 번역이 마음에 안든다 싶은 부분은 수정될 수도 있다.

프로그래밍을 감염시킨 “애자일”의 유행을 내가 싫어하는 것은 비밀도 아닐 것이다. 그 중 최악의 종류인 스크럼은 악몽과도 같은데, 나는 이것이 실제로 기업을 살해하는 것을 본 적이 있다. 여기서 “살해”란 “나중에 보니 별로 좋지 않은 문화였다” 정도가 아니라, 기업 주가가 실제로 85% 이상 폭락했다는 것이다. 이 잡것은 유독하며, 예전에 없어졌어야 했다. 여기에 익숙하지 않은 사람들을 위해, 우선 용어를 정의하자. 그리고 왜 이것이 끔찍한지, 그리고 진짜 ‘민첩함’(agility)을 해치는지를 다룰 것이다. 그리고 “애자일” 개발이 실제로 유용한 하나의, 임시적인 사용 사례(use case)를 논할 것이며 그 사례를 통해 왜 이것이 “영구적 합의” (permanent arrangement) 만큼 유해한지 설명하겠다.

그래서 “애자일”이란 무엇인가?

“애자일” 유행은 웹 컨설팅 업계가 키웠는데, 그 업계에서는 어느 정도 가치가 있었다. 스스로 뭘 원하는지도 모르는 까다로운 고객을 다룰 때, 두 가지 정도의 선택지가 있다. 하나는 고객을 관리하는 것이다. 기대치를 설정하고, 수정 요청에 적절한 비용을 부과하고, 고객에게 굴종하지 않고 동등한 관계를 유지하는 것이다. 두번째는 고객의 진상짓을 감수하고 (그러니까.. 많은 그래픽 디자이너들이 그래야 하는 것처럼) 작업 방향을 고객 입장에서 문제라고 생각하는 것을 해결하는 쪽으로 맞추는 것이다. 프로그래머들은 - 고객을 관리하는 - 첫번째 선택지에 능숙하지 못하다. 그런 것을 잘 하려면 사회적 감각이 엄청 요구되는데다가, 두번째 선택지가 이제 막 승진했고, 실제 업무를 처리하지 않아도 되는 의사결정권자에게 매력적이기 때문이다.

“컨설팅”이라는 이름을 가진 업무의 범위는 매우 다양하다. 훌륭한 컨설팅 회사도 있고, 가장 질 낮은 업무를 떠맡는 곳도 있다. 기업은 컨설팅 회사에 두 가지 종류의 업무를 주곤 한다. 내부에서 일을 맡을 사람이 없는 최고 수준의 업무이거나, 그런 업무에 1년 정도 사람을 투입하면 사기가 박살나는 종류의 쓰레기같은 질 낮은 업무이다. 스크럼은 그런 질 낮은 업무를 처리하는 곳을 위한 것이다. 프로그래머를 쥐어짜고, 고객과의 관계를 제대로 관리하지 못하고 있으며, 아무도 하고 싶어하지 않고 경력이 꼬이는 저질 업무를 떠맡는 그런 곳 말이다.

자 그래서 스크럼과 “애자일”이란 무엇인가? 여러 종류의 미팅이나 (“회고”, “백로그 다듬기”, “계획”) 이론을 들 수 있겠으나, 핵심적인 공통 특성은 보통 일방적인 지독한 투명성 이다. 프로그래머는 대부분의 경우 자신의 업무 내용과 시간에 대한 굴욕적일 정도의 가시성을 제공해야 한다. 즉 실제 업무량에 더해서 생산성을 보여주는 일방적인 게임을 해야만 한다는 것이다. 사람을 신나게 하는 실질적인 장기 프로젝트에서 일하는 대신, 그들은 세분화된, 기능 단위의 “유저 스토리” 작업으로 격하되고, 단기간의 (보통 윗선에서 떨어지는) 사업적 요구와는 관련없는 개선사항을 처리하는 것은 허락되지 않는다. 애자일은 오너십이라는 개념을 없애버리고, 프로그래머를 교체 가능한 일반적인 부품처럼 다룬다.

사람을 어린애 취급하고 역겨운데다가, 스크럼은 개인의 생산성이 미세하게 요동치는 것에 대해 쓸데없는 걱정을 하게 만든다. 폭력적인 투명성이란, 이론적으로 사람의 매 시의 생산성 변동이 모두에게, 아무런 이유 없이 보이게 된다는 것이다. 이런 종류의 가짜 만병통치약이 실제로 일을 빠르게 끝내게 하거나 결국엔 더 낫게 한다는 아무런 증거가 없는데도. 평균 장기 생산성을 측정했을 때 괜찮은 성과를 내고 프라이버시 침해에 굉장히 민감하며, 불안증이나 감정 장애가 있는 사람들에게는 이것은 노골적인 차별이다.

“애자일"과 스크럼의 구체적인 결함

1. 사업부 주도의 엔지니어링

“애자일”은 종종 “폭포수(Waterfall)”라는 소프트웨어 설계 방법과 비교하여 팔리곤 한다. 둘 다 똑같이 끔찍한 허수아비다. 애자일과 폭포수 모델이 공유하는 것은 (그리고 둘 모두의 장애 원인) 사업부 주도의 개발이라는 것이다. 폭포수 모델에서 프로젝트는 회사 경영진이 처음 정의하고 중간 관리자와 아키텍트들이 설계하며, 그 다음에야 여러 층의 말단 노동자들이 구현과 운영 및 테스트를 수행하는데, 각 기능은 하나가 끝나야 다음을 진행할 수 있는 여러 단계를 거쳐서 구현한다. 폭포수 모델이 제대로 동작하지 않는 것은 악명 높고, 애자일 진영의 아무도 여기에 이의를 달지 않는다. 폭포수 모델에서 엔지니어들은 어떤 설계를 구현하는 역할로 격하되는데, 이 설계의 모든 중요한 결정은 이미 끝났고 되돌릴 수 없다. 따라서 재능 있는 엔지니어라면 그러한 프로젝트를 맡고 싶어하지 않는다.

폭포수 모델은 명확한 계급구조가 있는 문제 조직의 사회적 모형을 복제한다. 가장 흥미로운 업무를 먼저 진행하고 작업 완료가 선언된 다음, 지저분한 나머지는 아래 사람들에게 넘긴다. “폭포수”라고 불리는 까닭은 의사 소통이 단방향이기 때문이다. 설계에 잘못이 있더라도 반드시 구현되어야 한다. (아마도 설계한 사람들은 이미 다른 프로젝트로 넘어갔을 것이다) 그리고 애자일은, 문제 조직의 사회적 모형을 복제하는데, 명확한 계급구조를 빼고 복제한다. 이것은 꽤 명백하게 다른 모든 이의 아래에 엔지니어를 두는데, “프로젝트 소유자”와 “스크럼 마스터”는 “팀 구성원”보다 계급이 높고, “팀 구성원”은 하위 계층에서도 가장 낮은 위치에 있다. 이러면 시니어급의 능력있는 엔지니어에게 주니어를 위한 보고 구조를 (나눠준 티켓을 처리할 것, 상태 보고 회의에 주당 5-10시간씩 참가할 것) 충실히 따르도록 하여 그들의 자존감을 박탈하는 효과가 있다. 빈곤을 전파하여 모두를 동등하게 만드는 실패한 공산주의 국가처럼, 가장 순수한 형태의 스크럼은 모든 엔지니어링을 동일한 가장 낮은 계층에 둔다. 잘 설명하지는 않지만, 분명히 ‘무슨 일을 먼저 해야 하는가’에 대한 완전한 결정권을 쥐고 있는 사업부 조직의 밑으로.

“애자일”은 엔지니어에게 아무런 권력을 주지 않으면서 업무보고의 빈도를 늘린다. 이것은 손해인데, 일정이 필요한 만큼보다 늘어지는 것처럼 “보이면” 엔지니어들이 곤란해지거나 처벌받을 수 있기 때문이다. 이러한 결정은 언제나 사업부 사람들이 내리는데, 그들은 기술적 난제나 개발 업무의 특성에 대한 깊은 통찰 대신 그들의 감정에 기반하여 상황을 지휘할 것이다.

실리콘 밸리에서 특히 지난 5년간 잘못 생각한 것도 많지만, 제대로 하고 있는 것중 하나는 ‘엔지니어가 주도하는 회사'라는 개념이다. 엔지니어가 모든 회사를 이끄는 것이 항상 최선은 아니지만, 엔지니어가 엔지니어링을 주도하고 우선 순위를 세우면 모두가 승리한다. 엔지니어는 자신에게 할당된 일에 (스스로 정한 것이면 더 좋고) 만족하고, 사업부는 훨씬 질이 높은 결과물을 얻는다.

2. 주니어로 끝남

“애자일”은 주니어로 끝나는 (terminal juniority) 문화이며, 프로그래밍은 “젊은 남성들의 게임”이라는 (엄청 잘못된) 생각에 신빙성을 더해준다. 대부분의 최고급 엔지니어들은 그렇게 젊지도 않고, 일부는 남자도 아닌데 말이다. 애자일에는 출구 전략이 없다. “이걸 했으니 이제 더이상 이렇게 할 필요가 없다”는게 없다. “유저 스토리”와 사업부가 주도하는 엔지니어링과 끝없는 상태 미팅은 사라지지 않으며, 그 자리에 항상 남아있게 되어 있다. 구조 잡기(아키텍쳐), 연구 개발, 제품 개발은 프로그래머가 할 일이 아닌데, 그런 것은 세분화된 “유저 스토리” 또는 2주 단위 스프린트에 맞지 않기 때문이다. 따라서 프로그래머들이 한 분야의 기초를 익힌 다음에 맡고 싶어하는 그런 프로젝트는 무시되는데, 세분화할 수 없거나 세분화하는 것이 그냥 하는 것보다 훨씬 더 어렵기 때문이다.

스크럼 팀에 실제 시니어 엔지니어의 역할은 없는데, 문제는 스크럼을 도입한 많은 회사에서 보통 전사적으로 시행한다는 것이다. 관리직으로 넘어가는 것 말고는, “스크럼 마스터”가 되어 이것을 말단에 도입하는 책임을 지는 선택지가 있다. 권한이 없는, 헛소리에 불과한 가짜 관리직 말이다. 스크럼 팀을 떠나서 해로운 마이크로매니지먼트를 받으면서 살지 않으려면 괴물 안으로 깊숙히 파고들어서 다른 사람에게 유해한 마이크로매니지먼트를 강요하는 수 밖에 없다. “애자일”과 스크럼이 나에게 말하는 것은 시니어 프로그래머는 반드시 필요하지 않다고 여겨지므로, 무시해도 좋으며, 마치 프로그래밍이란 35세 이전에 접어야 하는 유치한 것이라고 하는 것 같았다. 나는 그런 사고방식에 동의하지 않는다. 사실 해롭다고 생각한다. 나는 30대 초반이 되어서야 이제 프로그래밍 좀 하는 것 같다고 느끼기 시작했다. 이런 “애자일”/스크럼 쓰레기가 컴퓨터 과학과 아무런 상관이 없고, 아무런 가치가 없다는 것을 알게 된 경험 많은 연장자들을 내쫓는 것은 끔찍한 생각이다.

3. 어리석고, 위험할 정도의 짧은 주기

애자일은 한계에 달한 컨설팅 회사들을 위해, 그들에 의해 만들어졌다. 즉, 고객과 동등한 위치에서 협상할 수 있는 신뢰도를 갖추지 못하였으므로 빠듯한 데드라인에 맞춰야 하고, 각 고객 프로젝트가 실존의 위기인 회사들을 위한 것이다. 그러니까 “헝그리한” 약자(underdog)들을 위한 것이다. 자 여기서 문제: 흔히 큰 회사, 또는 펀딩받은 스타트업에서도 스크럼을 사용한다. 그런데 (고용자가 가져가도록 금전적 조건이 적힌 서류를 남기고) 이런 회사에 입사하는 사람들은 패배자(underdog)가 되고 싶지 않아서 입사하는 것이다. 아무도 타당한 개인적 보상이 없다면 뒤치닥거리를(play from behind) 하고 싶어하지 않는다. 기업 업무에서 “애자일”이란 보상이 없는 고통과 위험을 말한다.

각 개별 프로젝트가 실존 문제이거나 심각한 평판 위험에 해당할 때, 애자일은 괜찮은 선택지일 수도 있다. 회사가 위기에 처했을 때 반복적인 단기 목표에 집중하는 것은 유용하며 오랫동안 지속되지는 않을 것이기 때문이다. 비상 시에 공격적인 프로젝트 관리는 이치에 맞다. 영구적인 합의로써는 적절하지 않다. 적어도 스트레스를 덜 받고 더 즐거운 선택지가 있는 인재들에게는 말이다.

애자일 하에서, 기술적 부채는 쌓이기만 하지 처리되지 않는다. 명령권을 가진 사업부서 사람들은 너무 늦거나, 고치려니 너무 비용이 많이 드는 지경에 처하기 전까지는 문제를 보지 못할 것이기 때문이다. 게다가, 엔지니어 개인은 오로지 2주 단위의 현재 “스프린트”를 완료했는가 하지 못했는가에 따라 보상을 받거나 처벌을 받으므로, 아무도 한 다섯번 뒤의 “스프린트”를 내다보지 않는다. 애자일은 단지 아무 생각없는 근시안적인 “스프린트”의 연속일 뿐이다. 진척도 없고, 개선도 없고, 단지 티켓에 티켓이 이어질 뿐이다.

4. “경력 일관성”을 전혀 고려하지 않는다

세분화된 유저 스토리는 엔지니어의 경력에 좋지 못하다. 사람들은 당신이 30세가 되기 전에 프로젝트 전체를 담당할 수 있다는 것을 보여주길 기대한다. 또한 적어도 기반 인프라, 구조(아키텍쳐), 연구 또는 리더십 등의 분야에서 어느 단계를 뛰어넘을 준비가 되었기를 바란다. 애자일/스크럼 경험은 주니어 일자리를 잡을 때는 어느 정도 도움이 되지만, 중간 정도나 시니어 엔지니어에게 적합한 일자리를 구할 가능성을 없애버린다.

비상시에, 그러니까 컨설팅 회사가 중요한 고객을 달래려고 안간힘을 쓰고 있든 기업의 “위기 상황실”(War Room) 상황이든, 경력 일관성은 잠시 유보할 수 있다. 자신이 일하고 있는 회사에게 정말 필요한 일이라면, 몇 주 동안 불쾌하거나 경력이 꼬이는 업무를 못하겠다고 거부하는 사람은 거의 없을 것이다. 최소한 그 작업의 중요성이 경력에서 인정된다. 그러나 비상 상황이 아닐 때는, 프로그래머들은 자신의 경력 증진을 중요하게 여겨주길 바라고, 그렇지 않으면 떠날 것이다. 모두가 싫어하고, 누구의 경력에도 가치가 없는 밑바닥 작업을 “잡일(Fish Frying)”이라고 하자. 비상시 또는 모두의 주목을 받아서 누구도 개의치 않는 “잡일”이라면 (조직 안팎으로) 경력에 충분한 가치가 된다. “나는 상황실에 있었고, CEO랑 하루에 20분씩 같이 있었다”고 하면 잡일은 정당화된다. 이것은 당신은 귀중하고 중요한 인재라는 뜻이다. 자 “나는 스크럼 팀에 있었다”는 어떨까, “나 좀 잘라줘”이다. “유저 스토리”를 할당 받았기 때문에 잡일을 처리했다는 것은 당신이 패배자로 보였다는 것을 알려준다.

5. 저성과자를 가려내는 것이 목적이지만, 잘못 판단할 가능성이 높아서 써먹을 수가 없다

스크럼을 팔아먹는 쪽에서는 “장애물을 없애는” 과정이라고 하는데, 이 말은 “게으름뱅이 가려내기”를 좀 부드럽게 말한 것이다. 문제는 뿌리뽑는 것보다 더 많은 저성과자를 만든다는 것이다. 이는 각 엔지니어들이 자신의 업무와 생산성 척도를 세밀하게 관찰할 수 있도록 제공해야 하는 감시 상태이다. 이를 “꺼리는게 없으면 숨길 것도 없다”는 식의 주장으로 무마하려고 하는데, 조직의 대들보에 해당하는 고성과자들에게도 감시 상태는 불안감을 주는 상태인 것이 사실이다. 누가 나를 관찰한다는 사실에 사람들은 일하는 방법을 바꾼다. 특히 창의성이 필요한 분야에서는 상황을 악화시킨다.

여기서 떠오르는 첫번째 주제는 지위 민감성 (status sensitivity)이다. 프로그래머들은 자신들이 사회적 지위에 대해 영장류의 수백만년 진화를 초월했다고 믿고 싶어한다. 그러나 사실은: 사회적 지위는 중요하다. 그 사실을 인정하기 전까지는 당신은 “정치적”일 수 없다. 나이든 사람들, 여성, 소수 민족과 장애인들은 자신들의 지위에 민감한데, 생존의 문제이기 때문이다. 누군가의 업무를 지속적으로 감시한다는 것은 그 사람을 신뢰하지 못하고 사회적 지위가 낮다는 것을 나타내며, 대부분의 “지위에 민감한” 사람들이 (그들이 최고의 직원이라고 해도) 제일 먼저 위축될 것이다. 반면 스크럼과 “애자일”은 “지위에 민감하지 않은” 사람들이 대부분인 집단을 위해 만들어졌다. 즉 시험이나 도전을 받아보지 못했거나 아직 업무에 치여보지 않은 (burned) 젊은 특권층 남성들을 위한 것이다. HR과 관리 업무는 시간낭비이며 이 사람들은 모욕을 당하거나 비하를 당해도 그저 알랑거려야 한다고 생각하는 그런 사람들 말이다.

애자일/스크럼이 소개되면 최고의 직원들이 제일 심하게 추락하곤 하는데, 연구 개발이 사실상 제거되었기 때문이고, 단기간의 “반복” 또는 스프린트에 대한 강박이라는 것은 실패할지도 모를 작업을 시도할 틈이 없다는 것이기 때문이다.

저성과자에 대한 진실은 그들이 누구인지 찾아내기 위해 “애자일”을 도입할 필요는 없다는 것이다. 사람들은 스스로를 안다. 어떤 팀이 한가하거나, 무능하거나, 유해한 사람들로 가득 차는 것은 그들에게 아무런 조치를 하지 않기 때문이다. 사람에 대한 관리 문제이지, 작업 흐름과 절차에 대한 문제가 아니다.

6. 주정뱅이 효과 (The Whisky Goggles Effect)

(주: 술에 취하면 앞에 있는 사람이 더 멋있어 보이게 된다는 뜻임)

애자일과 스크럼이 살짝 무능한 사람을 간당간당하게 쓸만한 사람으로 만든다는 증거가 일부 있는 것처럼 보인다. 나는 이것을 주정뱅이 효과라고 부르는데, 3점이나 4점짜리를 5점으로 바꾸지만, 당신을 너절하게 보이게 하여 7점이나 9점짜리 사람은 당신이 별볼일 없다고 여길 것이다. 공격적인 마이크로매니지먼트 환경에서 그들의 흘러넘치는 창의력을 짜내는 것은 불가능하고, 최고의 프로그래머들은 떠나게 된다.

'관리자는 소프트웨어가 어떻게 동작하는지 알지 못한다'는 관점에서 보면 이것은 해볼만한 거래로 보인다. 7점 이상의 “프리마돈나”들은 '멋진 스크럼'을 받아들이지 못하고 떠날테지만, 3점이나 4점짜리 직원들은 딱 아슬아슬한 5점짜리 직원이 된다. 문제는 7점짜리 프로그래머와 5점짜리 프로그래머의 차이는 5점과 3점짜리의 차이와 비교하면 꽤 크다는 점이다. 최고의 직원들과 (조직도 상의 관리직으로는 올라가지 않은) 리드들을 잃는다면, 무능력자들을 살짝 업그레이드할 수 있다는 스크럼의 장점은 아무런 쓸모가 없다.

스크럼과 애자일은 내가 '상황 이득 편향’ (Status Profit Bias) 이라 칭하는 것에 빠진다. 기본적으로 많은 사업부 사람들은 객관적으로 (in objective terms) 성공과 실패를 평가하는게 아니라, 성취한 상황 변화를 근거로 평가한다. “3"점 프로그래머의 시장 가치가 연 $50,000이라 하고, "5"점 프로그래머는 $80,000이라 하자. (실제 프로그래머 급여는 중구난방이다. 나는 3점짜리가 $200,000을 버는 사례도 알고, 7점이 $70,000 아래인 경우도 알고 있지만 무시하자) "5"점짜리 프로그래머에게 "3"점짜리의 급여를 주는 것을 납득시킨다면 심리적으로 와닿을 것이다. 겨우 $30,000 이득이 아니라 2점이나 이득이기 때문이다.

애자일/스크럼과 연령 차별 문화는 보통 실제 경제적 이득보다는 제일 인상적인 상황 이득을 얻는 방법에 대한 것이다. 젊은이들은 자신이 “실제로 대접 받아야 하는” 사회적 지위에 대해 거의 알지 못한다. 자신이 3점 정도라고 생각하는 22세 6점짜리를 찾아서 스크럼에 합류시킬 수 있겠지만, 50세 9점 프로그래머는 마지못해 8.5점 대우를 받아들일지도 모르지만 6점짜리 대접을 받으려고 하지는 않을 것이다. 그러나 상황 이득을 찾는 것은 매우 근시안적이다. 업계 전체적으로 5점 엔지니어를 데려와서 4점처럼 대접하려고 (급여도) 하겠지만, 현재 시장 상황에서는 8점 엔지니어를 데려와서 8점 대접을 해주는 것이 훨씬 이득이다.

7. 거짓으로 팔아먹고 있다

이 점을 다루기 전에, 나는 “스크럼”이라 알려진 특급 애자일 프로세스가 특정 상황 조건에서는 잘 작동한다는 점을 인정해야겠다. 거짓 약팔이들은 이것이 '영구적인 합의'처럼 모든 상황에 잘 맞는다고 말한다.

스크럼이 잘 맞는 경우

애자일이 유행하기 전에는 “스크럼”이란 말은 회사가 “적색 경보” 또는 “위기 상황”이라 부르는 상황에서 사용되곤 했다. 이것은 조직경계를 넘어 (cross-cutting) 대응팀을 빠르게 꾸려서 예상치 못한, 보통 빠르게 퍼져나가는 문제에 대처하는 것이다. 정해진 관리자를 두지는 않지만 리더를 (“스크럼 마스터”같은) 선출하고 권한을 부여하는데, 보통 공식적인 "관리직"이 아닌 사람이 제일 적합하다. (가능한 공정해야 하므로) 위기는 단기간이므로, 각 개인의 경력 목표는 잠깐 보류할 수 있다. 이것을 “전력질주”(sprint)라고 할 수 있는 까닭은 최대한 빠르게 일해서 문제를 해결해야 하기 때문이고, 상황이 종료된 다음에는 평상시의 작업으로 돌아갈 수 있기 때문이다.

두 가지 시나리오를 생각할 수 있다. 첫번째는 기업의 “위기 상황실”에 대한 것인데, 어떤 사람이 (경영진 말고) 1년에 6주 이상 '위기 상황'에 있었다면, 이것은 회사에 뭔가 문제가 있는 것이다. 위기가 그렇게 잦으면 안되기 때문이다. 두번째는 컨설팅 회사가 자리잡으려고 애쓰고 있는 상황이거나, 고객 관리나 독자적인 평판 구축에 실패하여 항시 비상 상황으로 운영해야 하는 경우이다.

두 가지 문제

스크럼과 애자일은 비상시에 리더를 "떠맡은” 사람에게, 빠르게 일을 처리하기 위해 그가 필요하다고 생각하는 모든 것을 할 수 있도록 우선 비상 지휘권을 부여해야 한다는 생각을 대변한다. 시시비비는 일단 나중에 따지더라도 말이다. 예로부터 비상 지휘권에 대한 문제는, 가끔 없어지지 않는다는 것이다. 대부분의 경우 지휘권을 가진 사람은 이것을 유지해야 한다고 생각한다. 그리고 틀림없이, 관리의 문제가 된다. 장애 상황, 비상 상황에는 평상시 잘 돌아가던 때보다 더 많은 경영상의 노력이 필요하다.

출세지향적인 선동가 (“스크럼 마스터”) 에게는 우선 마을에 드래곤이 꼬이지 않게 하는 것보다 “드래곤 슬레이어”가 되는 것이 더 멋져 보일 것이다. 스크럼의 사업부 주도 엔지니어링에 대한 공격적인 주장의 문제점은, (“요구사항”이라 하는) 용을 꾀어내어 처치하는 것을 (“고객의 협력”이라는) 미덕으로 삼는 것이다. 처음부터 동굴에서 용을 꾀어내지 않는 편이 더 사려깊었을 것이지만.

“애자일”과 스크럼은 비상시를 미화한다. 그게 첫 번째 문제이다. 그것은 비디오 게임 업계에서 “크런치”라고 하는 것의 재발명일 뿐이다. 지속 가능하지 않다. 공세적으로 개인의 성과에 집중하고, 업무 할당에서 개인의 경력 목표를 배제하고, 최우선 순위로 정해진 것만 작업하도록 강요하는 것은 단기간의 비상 상황에서나 가치가 있지, 장기간으로 보면 독이 된다. 사람들은 자신의 자율성을 돌려받게 될 명확한 목표가 눈앞에 있어야 그러한 변화를 감내할 것이다.

두 번째 문제는 이러한 사례가 거짓으로 팔리고 있다는 것이다. 회사들의 소프트웨어 개발 업무에 “애자일”을 도입하도록 교육하면서 성장한 가내 수공업 업계가 있다. 문제는 핵심 아이디어에 새로운 것이 없다는 것이다. 용어는 신선한데, 개념은 대부분 진부하고, 실패한 “과학적 관리법”이다. (과학적이지도 않았고, 잘 되지도 않았다)

“애자일”과 스크럼의 장단점이 모두 다뤄졌다면 나는 이러한 개념이 그렇게 문제라는 생각을 갖지 않았을 것이다. 주니어 개발자들 뿐인 회사에서 어떤 기능을 빠르게 제공해야 한다면, 이러한 기법을 잠시동안 사용해보고, 구성원들이 성장하고 납기일에 조금 여유가 생기면 이후에는 쓰지 않는 것을 생각해볼 수 있을 것이다. 그러나 스크럼이 '있는 그대로’ - 생산성 향상을 위해 긴급히 써볼 수 있는 몇 가지 방법이지만 영구적으로 쓸 수는 없는 - 팔렸다면 이런 방법론을 도입하는 고객은 훨씬 적었을 것이고, “애자일” 컨설팅 업계는 없었을 것이다. 이러한 기법에 대한 거짓 약팔이 수법으로만 (항시 수정(permanent fixes)으로 포장된 “크런치"에 대한 미화) 팔아먹을 수 있는 것이다.

앞으로의 기대

이제 대부분의 “애자일”, 특히나 스크럼은 없어져야 한다. 이들은 그냥 나쁜 생각이기만 한게 아니다. 한 세대의 소프트웨어 엔지니어들이 이보다 더 나은 것을 알지 못하고 받아들이고 있기 때문이다. 너무나 많은 젊은 프로그래머들이 사업부 주도 엔지니어링과 “유저 스토리”를 마땅히 따라야 하는 것으로 받아들이고, 단지 평범한 회사원이 되어버릴 운명이다. 이것을 막아야 한다. 우리 업계가 앞으로도 얼마나 멀쩡하게 남아있을지가 여기에 달려있다. “애자일”은 양동이에 가득찬 헛소리에 불과하며, 프로그래밍 및 컴퓨터 과학과도 아무런 상관이 없고, 원래 튀어나왔던 똥덩어리 속으로 다시 던져넣어야 한다.