칼럼 | ‘스크럼폴’··· 워터폴이 애자일인 척 준동할 때

애자일 성전이 내부로부터 부패해가고 있다. 파격적 인간주의에 적응하기를 거부하거나 적응할 수 없었던 권위주의적 힘에 의해서다. 워터폴(Waterfall)의 망령이 숨어 있는 겉만 멀쩡한 스크럼(Scrum)이 배신의 주인공이다. 

스크럼으로 가장한 워터폴 기법을 통해(이른바 스크럼폴 ; Scrumfall) 기업들은 하향식 마이크로 관리를 재개하고, 사일로를 강화하고, 유연성을 속박하고, 소프트웨어 엔지니어를 단순히 코드를 생성하는 기계로 대상화하고 있다. 이는 애자일의 약속된 혜택을 소거하고, 아울러 신뢰, 협업, 존중, 연결, 지속 가능한 작업 환경을 강조하는 인간 중심의 원리를 해체한다. 애자일은 원래 이런 것이 아니었다. 
 

애자일의 깨어진 약속 
애자일 선언서(Agile Manifesto)는 간명하고, 아름다우며… 혁명적이다. 

•    프로세스와 도구보다 인간 및 상호작용이 우선한다
•    종합적인 설명서보다 기능하는 소프트웨어가 우선한다
•    계약 협상보다 고객 협력이 우선한다
•    계획을 추종하는 것보다 변화에 대응하는 것이 우선한다

선언서의 대표적인 서명인인 ‘엉클’ 밥 마틴(Uncle Bob Marin)은 ‘클린 코드: 애자일 소프트웨어 기술 안내서(Clean Code: A Handbook of Agile Software Craftsmanship)’의 저자이다. 그는 선언서를 상호 신뢰와 존중에 기초한 일련의 가치라고 규정했고, 사람과 협업을 근간으로 하는 조직 모델을 촉진하고 우리가 일하고 싶어하는 조직 공동체 유형을 건설한다고 말했다. 

애자일은 프로세스가 아닌 사람을 중심으로 고안됐다. 사람들은 자율과 상호 존중의 문화 속에서 문제를 해결하기 위해 긴밀히 협력한다. 이는 각 개인의 건강, 성장, 만족에 가치를 두는 지속 가능한 문화이다.

선언서에는 이 소프트웨어 엔지니어링 접근법이 필연적이고, 워터폴 같은 낡은 모델보다 우수하다는 믿음이 깔려 있다. 소프트웨어 엔지니어링에 내재된 복잡성과 불확정성 때문에 필연적이고 집단 지성의 힘을 완전히 활용하기 때문에 우수하다는 믿음이다. 그러나 이 믿음조차도 애자일의 가장 근본적인 생각, 즉 ‘사람이 중요하다’보다는 덜 중요하다. 

오늘날 이 생각에 립 서비스로나마 호응하지 않는 기업은 드물다. ‘우리는 사람들을 중요시한다’라고 입을 모은다. 그러나 자신의 인력 자원에 대해 통제를 우선시하는 기업이 많다. 소프트웨어 엔지니어링 진영에서 이를 대놓고 발설하는 일은 허용되지 않지만(현대의 미국과 흡사하다), 여러 기업에서 외형만 스크럼인 워터폴의 계층적 미세 관리가 이미 부활했다. 

스크럼이라는 가면 
특히 스토리 포인트(story points)의 오용은 스크럼 가면을 전달하는 매개체다.

원래 스크럼 스토리 포인트는 스토리의 상대적인 복잡성을 표현하도록 의도됐다. 이들은 상대적 예상 노력의 추상화(an abstraction of relative expected effort)의 근사치이고, 실제로 엔지니어링을 이행하기 전에 만들어진다. 이는 시간의 추정치가 아니며, 마감시한을 설정할 정당한 근거가 결코 아니다.

그렇지만 수많은 기업이 스토리 포인트를 이렇게 오용한다. 이를 타임라인과 연계시켜 그럴듯한 추정치를 도출한다. 그리고는 인간 자산이 계획에 적응하기를 기대한다. 인간 및 구현 시 얻은 교훈에 계획을 적응시키는 것이 아니다.

그리고는 스케줄에 맞춰 스토리를 정시에 전달할 수 있게 코딩을 하도록 재촉한다. 4시간으로 추정되었던 스토리가 실제로 16시간이 걸리는 것으로 밝혀진다면 이제 속성 코스의 시간이다. 인간성이라고는 찾아볼 수 없는 허위의 셈법을 맞추기 위해 쉼 없이 일해야 한다.  

이게 ‘프로세스와 도구보다 개인과 상호작용을 우선시하는’ 방법론처럼 들리는가? 이게 ‘계약 협상’보다 ‘고객 협업’을 우선시하는 방법론인가? 이게 ‘계획을 추종하는 것’이 아니라 ‘변화에 대응하는 것’인가? 

당연히 그렇지 않다. 이는 소프트웨어 엔지니어가 한낱 기계 부속품에 지나지 않은 미니-워터폴 스토리이다. 복잡한 문제를 해결할 때 필수적인 기술, 창의성, 비판적 사고에 대한 이해 같은 것은 팽개치고 코드 뭉치에 대한 전체가 명시된 명령으로서의 스토리이다. 

어떤 가면을 쓰고 있든 워터폴은 워터폴이다
이들 스크럼으로 위장한 미니-워터폴은 제품 팀이 요청한 것을 구현할 자율, 접근, 권한을 소프트웨어 엔지니어에게 허용하지 않는 하향식 선형 접근법이다. 실질적인 대화와 진정한 협업의 여지가 없다. 참신한 아이디어가 출현하거나, 누군가가 마음을 바꿀 여지가 없다. 

다시 말해 스크럼폴(Scrumfall)은 개발이 시작되기 전에 (인간으로 구성된) 제품 팀이 전체적이고 완전한 명세를 제공하는 구조에 의존한다. 그리고 (다시 한번 인간으로 구성된) 개발 팀이 종합적이고 완전한 구현을 계획하기 전까지 단 한 줄의 코드도 작성할 수 없다.

우리가 지금 워터폴이라고 부르는 방법론에 관한 유력한 논문의 저자인 윈스턴 W. 로이스 박사조차 이게 가능하다고 믿지 않는다. 그는 “나는 이 개념을 믿지만, 위에 서술한 구현은 위험하고 실패를 초래한다”라고 말했다. 

이후 명세와 구현에서 불가피하게 불완전함이 드러날 때 로이스는 “요구되는 설계 변경은 지극히 파괴적이어서 설계가 기초하고, 모든 것의 합당한 이유가 되는 소프트웨어 요구사항이 침해된다”라고 말했다. 

따라서 다른 접근법이 필요했던 것은 전혀 이상할 게 없다. 

스크럼폴이 도대체 효과적이기는 할까? 물론 소소한 경우라면 효과적일 수 있다. 표준 로그인 페이지가 필요한가? 대단한 협업 없이도 무리 없이 규명하고 추산하고 이행할 수 있다. 

그러나 소프트웨어 엔지니어링에서 진정으로 흥미롭고 유가치하고 심지어 혁명적인 과제라면 (복잡하고 비결정적인 작업) 참신한 해법을 함께 도출하기 위해 유의하게 협력하는 인간들이 필요하다. 

나비 효과가 버그를 양산한다 
협업은 프로세스 안으로 불가피한 불확실성을 가져온다. 스크럼의 트로이 목마 안에 숨은 워터폴 망령은 불확실성을 끔찍하게 싫어한다. 그러나 불확실성은 애자일의 버그가 아니라 특징이다. 이는 프로세스가 미지의 것을 수용할 때, 아울러 사람들이 마음을 바꿀 권리를 보호할 때만 참신한 해법이 출현할 수 있음을 인정한다.

소프트웨어 엔지니어링은 50년이 갓 넘은 매우 젊은 분야이고 급속히 변화 중이다. 이를 토목 엔지니어링의 천년 간의 발전, 정제, 표준화와 비교해보라. 우리가 하는 일의 너무 많은 부분이 새로운 것, 다시 말해 미지의 것에 대한 탐색이다. 

또한 소프트웨어는 차원이 다르게 복잡하다. 코드의 순수 줄 수는 투박한 복잡성 지표이긴 하지만 심지어 간단한 아이폰 앱조차 4만 줄의 코드로 구성되는 게 보통이고, 본격적인 소프트웨어는 100만 줄을 넘는 것이 보통이다. 구글의 코드베이스는 20억 줄의 코드를 갖는 것으로 추정되고, 이는 33억 개의 인간 게놈과 비교할 만하다.

이들 코드의 줄의 온갖 상호작용을 생각하면 혼돈 이론 영역으로 진입한다. 소프트웨어가 나비 효과에 지극히 민감해져 전혀 의도치 않은 결과가 나타난다.

간단히 말해 우리는 내재적으로 비-결정적인 프로세스를 다루고 있다. 사람들을 분리하고 격리하고 제한하더라도 이 불확실성을 없애지 못한다. 독단적인 마감시한과 경직된 계획을 준수하도록 강요하더라도 결정론적 성과가 도출되지는 않는다. 

대신 이러한 미니 워터폴의 연쇄는 혼란, 조잡한 코드, 그리고 아이러니하게도 비용 초과와 마감시한 준수 실패를 낳는다. 장기적인 성공은 스크럼폴의 임의적 지표를 충족하기 위해 희생된다. 또한 이는 엔지니어 번아웃의 확실한 경로이기도 하다. 이들은 이내 덜 바쁘고 덜 힘들고 더 만족스럽고 더 지속성 있는 기회를 찾아 떠나버릴 것이다. 

스크럼폴의 소멸이 애자일의 진정한 위력을 발현시킨다 
애자일은 프로세스의 가치보다 사람의 가치를 우선시하는 대단히 좋은 아이디어이다. 이는 소프트웨어 개발 수명 주기를 급격하게 재편하면서 계속해서 소프트웨어 개발 분야를 변혁할 것이고 우수한 해법을 생산할 것이다.

그러나 애자일이 진정한 위력을 발휘하려면 우리가 해결하는 문제의 비-결정적 복잡성을 전적으로 수용해야 한다. 새 프로젝트를 시작할 때는 모르는 것이 너무 많고, 애자일에서 이는 전혀 문제되지 않는다. 영리한 사람들이 인간 중심의 문화 속에서 협력한다면 좋은 해법에 이르는 길이 발견될 것이다. 그냥 유연성을 갖고 이들이 참신한 생각을 바탕으로 문제를 해결할 것이라고 믿어야 한다. 

도중에 길을 잘못 들게 될 것이다. 사람들이 마음을 바꿀 것이고, 더 나은 해법을 발견할 것이다. 몇몇 스토리는 완성하기까지 예상보다 시간이 더 걸릴 것이다(그리고 몇몇 스토리는 덜 걸릴 것이다). 타임라인을 변경하고, MVP를 다시 생각하고, 기능들의 우선 순위를 다시 설정해야 할 수 있다. 

애자일에서 이는 전혀 결함이 아니고 실수도 아니고 낭비도 아니다. 영리한 사람들이 복잡한 문제를 해결할 때 으레 하는 일이다. 애자일은 불확실성을 억제하려고 하지 않고 창조의 본질로서 환영한다. 

물론 유지해야 할 균형이 없지 않다. 애자일은 제품 완성에 이르지 못할 개발자 무질서일 수 없다. 적절히 이행되는 스크럼 또는 칸반은 필요한 것, 그리고 유한한 시간과 예산 내에서 원하는 성과를 도출하는 것과 팀을 계속 정렬시킨다. 

그러나 결과물의 가치가 아니라 자꾸 쓸데없는 작업 지표를 측정하는 데 집착하며 애자일의 위력을 폄하해서는 안 된다. 애자일의 진정한 잠재력을 발현시키려면 이의 핵심 원리에 다시 집중하면서 우리가 하는 모든 일에서 이를 실천해야 하고, 스크럼폴에 숨어 있는 워터폴의 끈질긴 망령을 소멸시켜야 한다. 

* Jeremy Duvall은 커스텀, 클라우드 네이티브 소프트웨어 솔루션 기업 7factor Software의 설립자다. ciokr@idg.co.kr