Agile at 20: The Failed Rebellion by Al Tenhundfeld를 번역했습니다.

번역: 박성렬(sungryeolp@gmail.com)

애자일 선언이 올해 20주기를 맞이했다. 아래 두 가지 사실이 이제는 매우 당연하게 되었다.

1. 애자일의 브랜드화는 성공했다. 아무도 애자일이 아닌 것(non-agile)을 원하지 않는다.
2. 실무에서 애자일이 적용되는 형태는, 창시자들의 혁명적이었던 생각에 비하면 터무니 없이 부족하다.

어떻게 하다가 이런 꼴이 되었을까? 모두가 애자일을 한다고 말하는데, 거의 누구도 애자일을 하지 않는 상황이다.

선언문의 기원

2001년 2월, 17명의 소프트웨어 실무 전문가들이 유타주 와사치 산에 있는 스노우버드 스키 리조트의 "산장"(The Lodge)에 결집했다. 전문가들은 며칠 간의 토론과 대화를 거쳐 "애자일 소프트웨어 개발 선언문(Agile Software Development Manifesto)"을 공동으로 집필했다.

우선은 이 전문가들이 실무자였다는 점에 주목할 필요가 있다. PM도 아니었고, CTO나 팀장급(VP) 엔지니어도 아니었다. 개발자였으며 프로그래머였고, 과학자이자 엔지니어였다. 문제를 해결하기 위해 주주들과 협업하며 열정적으로 코드를 생산했다는 점이 중요하다.

그 뿐만이 아니다. 애자일은 어느 날 갑자기 무(無)에서 나타나지 않았다. 전문가 대부분은 이미 자신이 만든 방법론을 적용하거나, 어디에선가 배운 방법론을 적용해보는 중이었다. 시기로 따졌을 때 아주 정확하지 않을 수는 있지만, 아마도 방법론들 자체는 "애자일"이라는 단어 이전에 존재했을 가능성이 있다: 익스트림 프로그래밍(이하 XP), 스크럼, DSDM, 적응형 소프트웨어 개발(Adaptive Software Development), 크리스탈 소프트웨어 제작 방법론, FDD(Feature-Driven Development), 실용적 프로그래밍(Pragmatic Programming) 말이다. 켄 슈와버(Ken Schwaber)와 제프 서덜랜드(Jeff Sutherland)가 1995년에 이미 스크럼을 공개적으로 천명했고, 켄트 벡(Kent Beck)과 론 제프리스(Ron Jeffries)가 익스트림 프로그래밍 방법론을 언급하기 시작한 것이 1996년이었다.

역주: 익스트림 프로그래밍은 테스트코드와 퍼포먼스 튜닝, 빠른 릴리즈 주기, 긴밀한 코드리뷰 등을 통하여 프로그램의 퀄리티를 극대화(extreme) 하고자 하는 개발 방법론이다. 지금의 애자일과 상당히 유사하다.

산장에 모인 전문가들은 소프트웨어 개발에 매우 높은 일가견이 있었다. 모두들 당대를 지배하고 있던 문서 중심의, 무거운 소프트웨어 개발 시스템에 대해 대체제를 찾고 있었다. 아래 4가지 문장이 선언문의 핵심을 집약하여 보여준다.

우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:

• 공정과 도구보다 개인과 상호작용을
• 포괄적인 문서보다 작동하는 소프트웨어를
• 계약 협상보다 고객과의 협력을
• 계획을 따르기보다 변화에 대응하기를 가치 있게 여긴다.
• 이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.

역주: 애자일 선언문 한국어판에서 발췌

새로운 희망

역주: 스타워즈 초기 3부작의 첫 제목. New Hope.

2021년의 관점에서는 오늘날의 소프트웨어 개발 방식을 당연한 것으로 여기기 쉽다. 그러나 2001년에는 이런 생각이 매우 급진적으로 분류되었다: 모든 기능 상세를 정리하고 일정이 완전히 정리되지 않은 상황에서 개발을 시작한다는 것 자체를 받아들이기 어려웠다. 그랬다면 완전 미친놈 취급을 받았을 것이다!

사람들이 쉽게 잊어버리는 사실이 있다. 애자일은 태초부터 관리자로부터 통제 받는 것을 아주 공개적이고 전투적으로 반대(anti-management)했다. 예를 들자면 켄 슈와버는, 모든 프로젝트 관리자(이하 PM)들을 없애겠다는 주장을 아주 열성적이고 공개적으로 드러냈다. 그냥 단순히 자신이 연루된 프로젝트에서 없애버리겠다는 것이 아니라, 소프트웨어 개발 시장에서 아예 직업 자체를 없애버리겠다는 것이었다.

민첩함과 PMI(Agility & PMI): 켄 슈와버의 블로그 글

PM의 역할은 창조적이고 복잡한 작업에 있어서 매우 비생산적입니다. PM은 자신의 생각을 프로젝트 계획이라는 것으로 나타내어, 문제를 해결하기 위해서 다른 사람들의 지성을 자극하지는 못할 망정 프로젝트에 연루된 모든 사람의 창조력과 지성을 제한하게 됩니다.

켄 슈와버, 애자일 선언문 서명자 겸 스크럼 공동 고안자

당시 스크럼 마스터는 거의 아무런 권한도 없었다. 문제에 대해 투표권을 행사할 권리도 없었다. 단순히 서번트 리더십에 따라 타인을 위한 봉사자에 지나지 않으면서 팀 내에 문제가 생기면 해결해 주거나 외부로부터 방어해주는 역할만을 맡을 뿐, 팀을 지휘하지는 않았다.

역주: 서번트 리더십=명령 하달보다 설득 및 지원을 통하여 팀을 보조하는 리더십

크리스탈 방법론(Crystal Methodology) 및 육각형 설계(Hexagonal Architecture)을 고안했으며, 애자일 선언문에 서명을 남겼던 앨리스테어 콕번(Alistair Cockburn)은 최근에 인터넷 커뮤니티에 매우 뛰어난 인사이트가 담긴 트위터 쓰레드를 남겼다. 대략 아래와 같은 내용이다.

스크럼은 적대적인 환경에서 상당한 협의를 도출해냈다:

• 관리자는 1 달에 한 번, 매 스프린트가 끝날 때마다 원하는 방향 대로 목표를 재설정할 수 있게 되었다.
• 팀은 1 달 동안 아무런 외부의 방해 없이 작업에 온전히 집중할 수 있게 되었다.
• 팀은 관리자의 간섭 없이 1 달 안에 할 수 있는 것과 없는 것들을 통보할 수 있게 되었다. 임원들은 이렇게 뛰어난 제안을 받아본 적이 없다. 개발자들도 이렇게 뛰어난 제안을 받아본 적이 없다.

나(앨 텐훈드펠드)는 공인된 스크럼 마스터이고, 애자일 팀에 15년 이상 몸을 담았으며, 언급되는 유명한 서적들을 탐독해 보았다. 하지만 아래 콕번이 남긴 말처럼 애자일의 정신에 대해 명확하고 오류 없이 설명하는 글은 본 적이 없다.

스크럼은 적대적인 환경에서 동작하도록 고안되었다. 스크럼은 매우 요구사항이 많은 관리자들과, 생각하고 탐구할 시간이 필요한 개발자들의 상호 계약이다.

제국의 역습

스타워즈 초기3부작의 두 번째 제목. Empire Strikes Back

어떤 의미에서 애자일은 풀뿌리 노동 운동이라고 할 수 있다. 명명백백하게 일터의 실무자들이 시작한 운동이면서도, 관리자들에게까지 전파된 운동이다. 어떻게 이런 일이 가능했을까?

부분적으로는 이렇게 설명이 가능하다. 개발자들이 몸담고 있는 산업의 크기와 가치가 증가했으며, 몸집이 충분히 커졌기 때문이라고. 하지만 개인적으로는 이런 이유보다는 수직적인 의견 전달 방식(폭포수 개발)이 별 효과가 없었던게 진짜 이유가 아닐까 한다. 소프트웨어는 더욱 복잡해졌고, 개발의 속도는 빨라졌으며, 사용자들의 요구는 첨예해졌고 모든 것을 미리 계획하기는 사실상 불가능에 가까워졌다. 반복적으로 개선해 나가는 개발 원칙을 수용하는 편이 훨씬 논리적이었고, 예전처럼 관리자들이 모든 것을 미리 계획하는 것은 다소 무시무시한 이야기였다.

기억을 더듬어 보면 2000년대 중반에 경험했던 회의들 중에, 관리자들이 별로 의견을 수용하지도 않으면서, 그렇다고 새로운 의견도 별로 제시하지 못한 경우가 많았다.

제기랄, 모르겠네요. 엔지니어들이 이야기하는 미친 짓을 한 번 시도해 보죠. 어차피 기일은 못 지킵니다. 이미 상황이 최악이예요.

그리고 놀랍게도 이러한 관점이 먹혀 들어갔다. 실제로 환경에 들어맞았고 작업이 진척되기 시작헀다. 팀은 한 동안 다투다가 서서히 속도를 내기 시작했다. 개개의 팀이 어떤 패턴에 들어맞는 지를 탐색하고, 가속력이 붙었다. 스프린트를 몇 번 거듭하자 어떤 진가를 지니고 있는지 깨닫게 되었다. 작동하는 소프트웨어에 무게를 두고 협력하는 것이나, 시간을 두고 관찰하여 적응하는 것 등이 가진 진정한 가치 말이다.

이후 5년간, 애자일은 "들어보기는 했지만 아마 익숙하지는 않은" 방법론에서, 모두가 시도해 본 것이 되었다. 2005년 이직중이던 시절에, 애자일이나 TDD를 안다고 하면 상당히 눈에 띄었다. 2010년에는 사실상 개발팀이라고 하면 어떤 방식으로든 애자일의 영향을 받은 것이었다. 적어도 내가 컨설팅을 해주던 곳들에서는 전부 그랬다; 큰 회사는 언제나 느리게 움직이니까 말이다.

🎉🎉🎉 축하합니다. 우리의 승리예요!🎉🎉🎉

그리고 여기서 이야기가 끝난다. 이제 창을 닫고 원래 일로 돌아가도 된다.

젊은이여, 승리는 쉽소. 하지만 감독은 어렵다오. (연극 "해밀턴"에서의 조지 워싱턴)

하지만 많은 혁명들이 그렇듯, 애자일의 역사는 고안자들이 꿈꾸던 것과는 반대로 흘러갔다.

• 개인을 중시하고 쌍방향 소통을 중시하는 관습은 생각보다 정착시키기 어렵다. 방법과 도구를 돈 주고 판매하는 것이 훨씬 쉽다.
• 비현실적인 계획을 산정하고 산더미같은 문서를 만드는 것보다 작동하는 소프트웨어를 만들어 내는 것이 더 어렵다.
• 고객과 협력하는 것은 신뢰를 필요로 하고 약점을 드러낸다. 업계 여건상 항상 준수하기 어려운 부분이다.
• 임원들이 통제력을 느끼고자 하는 것이 변화에 반응하고자 하는 것보다 우선하며, 사업을 위해서는 기획단계가 길어질 필요가 있다.

역주: 방법과 도구를 돈 주고 판매한다=애자일용 SaaS와 각종 유료 컨설팅을 두고 말함

엉망으로 진행된 애자일은 혼란스럽게 느껴진다.

그렇다고 애자일의 4가지 덕목이 잘못된 것은 아니다. 다만 덕목들을 준수하는 데에는 어느정도 노력이 필요하고, 소프트웨어라는 것 자체가 간혹 혼란스럽고 지저분하다는 것을 받아들일 용기가 필요할 뿐이다. 계속 새로운 것을 배워나가면서 적응하고 프로그램을 릴리즈(shipping)하다 보면, 결국에는 예전보다 더 나은 위치에 있게 될 것이다. 그런 이후에는 폭포수 개발로 도달할 수 있는 것보다, 훨씬 솔직하고 현실적이며 생산적인 위치에 도달할 수 있게 된다는 것을 이해해야한다.

애자일 운동은 방법론을 무너뜨리고자 나타난 것이 아닙니다. 오히려 우리 모두는 방법론이라는 단어를 다시 신뢰할 수 있기를 바랍니다. 균형을 되찾고자 하는 것입니다. 우리는 추상적인 세계관을 받아들이고 싶은 것이지, 아무도 살펴보지 않는 회사 문서에 있는 도표를 작성하고자 하는 것이 아닙니다. 우리는 문서화를 받아들이고자 할 뿐, 수백 페이지의 관리되지 않고, 거의 사용되지 않는 문서들을 무덤으로 보내고자 하는 것이 아닙니다. 우리는 계획하고 싶지만, 전쟁통같은 환경에서 계획한다는 것에 한계가 있음을 인지하고자 합니다. XP나 스크럼 혹은 애자일의 어떤 방법론을 고안한 사람들을 "해커"로 낮잡아 보는 것은, 해커라는 의미와 방법론 모두 폄하하는 것입니다. 애자일 선언문의 역사(History: The Agile Manifesto)에서 발췌, 짐 하이스미스(Jim Highsmith)

역주: 순리나 규칙에 적응하지 않는 사람이라는 뜻으로 해커를 언급하고 있다

모두 중요한 이야기다. 우리는 여전히 계획과 문서화를 해야 한다. 애자일도 준수해야 한다. 결국엔 균형이 중요하다.

그러나 당신의 조직이 애자일 적응에 어려워하고 있으며, 혼란에 빠지고 있는 중이라면 이야기가 다르다. 자격증과 각종 도구를 가지고 구명보트를 탄 채 누군가가 접근해 오기만 해도 무작정 뛰어들게 될 것이다. 임원들은 스스로 운영되는 팀이라는 것은 제대로 이해하지 못하지만, 외부의 방법론과 도구는 잘 이해하는 경향이 있다.

반역자

역주: 스타워즈 스핀오프 제목. Rogue One.

3장으로 구성된 극적인 요소가 여기서 부터는 다소 어긋난다. 아쉽게도 담대한 기상을 지닌 반란가들은 이제 돌아올 낌새가 보이지 않는다. 특히 애자일에 관련해서는 말이다.

역주: 필자가 제목을 빌려온 스타워즈 3부작은 줄거리의 흐름이 발단-위기-결말(해소)로 진행된다. 따라서 여기에 해피엔딩에 해당하는 "제다이의 귀환" 제목이 와야한다. 이 마지막 편은 또한 주인공이 악당을 처리하고 평화를 다시 수립하는 줄거리이다. 그러나 3부작의 진짜 마지막이 아니고 스타워즈 스핀오프의 제목이 사용된 것은 애자일이 원래의 목적과 다르게 사용되면서 결국 행복한 마무리가 되지 못하고 있기 때문이다. 이 스타워즈 스핀오프는 3부작의 마지막보다 좀더 암울한 분위기로 마무리되지만, 시간순으로는 3부작의 2편과 마지막 3편 사이에 위치하고 있어서 결국 글쓴이는 3부작의 마지막이 도래했듯 애자일에 있어서 평화로운 결말을 기원한다는 의미이다.

이제 세상은 애자일 도구 판매자들이나, 방법론 컨설턴트들 그리고 절대 지킬 수 없는 약속을 하는 전문가들로 넘쳐나고 있다. SAFe(Scaled Agile Framework)과 기업형 스크럼(Scaled Scrum) 및 각종 기업형 애자일 변종들이 나타난 이유이다. 이 체계(framework)들은 무턱대고 나쁜 의도로 만들어진 것도 아니고, 적재적소에 사용된다면 쓸모가 있을 수도 있다. 그러나 애자일이라고 하기는 어렵다. 개개인과 쌍방 소통에 중점을 둔 방법론을 스케일 업 하려고 하면 결국에는 문제가 발생할 수밖에 없다. 해당 방법론의 원래 의미는 퇴색된다.

역주: 기업형 스크럼=기업의 규모에 맞게 스케일을 확장한 스크럼

애자일 선언문 서명자이자 익스트림 프로그래밍(XP) 방법론의 공동 고안자인 론 제프리스는 결국 2018년에 아래와 같이 유명한 발언을 남겼다.

개발자는 애자일을 버려야 한다. "애자일"이라는 사상이 잘못 적용되면 오히려 개발자들은 더욱 많은 방해물에 직면하게 됩니다. 작업할 시간은 줄어들고, 압박은 가중됩니다. 개발자들에게는 결국 좋을 게 없고, 결국 기업에는 악영향입니다. "애자일"을 엉성하게 하면 원래 가능한 것보다 버그는 더 많아지고 작업 속도는 더욱 늦춰지게 되기 때문입니다. 좋은 개발자는 그러한 조직을 떠나게 되어 있으며, 기업은 "애자일"을 적용하기 전보다 더 비효율적인 집단이 됩니다.

애자일 선언문 서명자이자 실용적 프로그래밍(Pragmatic Programming)의 공동 고안자인 데이브 토마스(Dave Thomas)는 결국 2014년에 아래와 같이 유명한 발언을 남겼다.

애자일은 죽었다(속도는 영원하라) "애자일"이라는 단어는 이제 사실상 무용한 수준이 되었으며 애자일 커뮤니티라는 것이 컨설턴트와 서비스 판매자들의 결투장이 되어 서비스와 제품을 노리는 것을 당연한 것으로 보고 있습니다. 선언문이 유명해지고 나서, 애자일이라는 단어를 신뢰하는 사람들에게 애자일은 곧 시간당 가격이 되었고, 판매할 품목이 되었습니다. 마케팅 용어가 된 것입니다. 그래서 이제 "애자일"이라는 단어를 퇴역시킬 때가 되었습니다.

회고

정말 안타깝다. 젊은 개발자들은 애자일을 폄하한다. 애자일은 경영진이 비현실적인 약속을 받아내고, 개발팀이 말도 안되는 시간동안 일하도록 하기 위한 수단이 되었다. 이해한다. 젊은 개발자들이 겪어본 애자일 이라고는 오로지 개발자들을 통제하는 원리일 뿐, 기쁜 마음으로 스스로의 권한을 증진시키기 위해서 받아들인 도구가 아니다. 하지만 역사에 대한 토론해 보고 원래 가치를 되돌아 보면 원래 애자일의 방향을 다시 기억해낼 수 있을 것이다.

다행스럽게도 애자일 선언문은 20년이 지난 지금도 유효하다. 애자일의 포교자였던 론 제프리스나 데이브 토마스도 같은 생각이다.

론 제프리스는 앞서 언급한 글에서 말한 바 있다. "애자일 소프트웨어 개발 선언문의 덕목과 핵심 가치는 내가 아는 한 여전히 소프트웨어를 만들기 위한 가장 좋은 방법이며 내 오랜 경험상, 조직에서 어떤 방법론을 사용하든 나는 애자일의 가치를 따를 것이다."

맞는 말이다.

애자일에 대해 말하는 것은 더 이상 쿨하거나 힙하지 않다. 애자일은 따분해졌다. 모두 애자일을 하고 있기 때문이다. 지금이 20년 전을 되돌아보고 몇 가지를 다시 질문해보기 가장 좋은 때다.

• 무엇이 제대로 진행되었는가?
• 무엇이 잘못 진행되었는가?
• 다음에는 어떤 것을 바꿔 보고자 하는가?

혁명을 직접 겪은 심플 스레드의 우리 중 몇 명은, 앞으로 몇 달동안 원래의 12가지 애자일 원칙을 반영하고, 원래 의미를 현재의 맥락에 맞도록 생각해보며 오늘날의 소프트웨어 개발환경에서 그 가치를 다시 되새겨 볼 것이다.

역주: 심플 스레드는 글쓴이가 소속된 디자인 회사명이다.

창립 원칙이 어떤 것이었는지 알아보면서 과거로부터 배울 수 있다면 좋을 것이다. 데이브 토마스의 말처럼, 우리는 "애자일"이라는 단어를 버리더라도, 여전히 속도(Agility)를 유지할 수 있을 것이다.