애자일, 애잡을일? 성공의 지름길?

오랜 기간 여러 기업의 IT 최고 책임자인 CIO(Chief Information Officer)나 CTO(Chief Technology Officer) 롤을 수행하면서 필자가 견지한 원칙 중 하나는 사용자들의 상세한 요건정의와 빠른 개발 요구 사항의 확정이다. 그것은 시스템 런칭 일자가 고정된 상황에서 개발 요구 사항이 확정되지 않으면 개발 시간과 테스트 시간이 줄어들기 때문이다. 그래서 프로젝트 마다 항상 시스템 런칭 일자를 기준으로 역산하여 Production 런칭-UAT-통합테스트-단위테스트-코딩-설계-요구 사항 분석의 최소한 IT 소요 시간을 제시하며 요구 사항 확정 due date를 현업에 제시하곤 했다. 그러나 이 due date가 지켜지는 경우는 거의 없다. 그것은 이 프로젝트의 여러 stakeholder가 각기 서로 다른 view 와 이해관계를 가지고 있기 때문이다.

예를 들어 어느 보험 회사에서 신 상품을 런칭 하고자 할 때 영업부서는 타사와의 경쟁력을 위해 더 싼 보험료를 요구하는 반면 재무관리 부서는 회사의 마진 확보를 위해 적정 수준 이상의 보험료를 원하며 위험 관리 부서는 미래 위험을 회피하기 위해 보장 내역을 축소하길 원하고 상품을 만드는 부서는 보험개발원 인가를 위해 여러가지 제약 조건을 내건다. 따라서 신상품 개발에 가장 기본적인 보험요율 table을 생성하기 하는 것부터 쉽지가 않다. 이런 상황에서 모두가 동의하는 개발안을 확정하기란 결코 쉽지 않은 것은 사실이고 IT의 입장에서도 각 stakeholder의 입장 또한 이해가 간다.

그러나 시스템 런칭 타겟 일자는 정해져 있고 그 타겟 일자는 하루하루 다가오는데 개발시작도 하지 못하고 있는 IT부서의 답답한 심정은 이루 말할 수 없다. 그리하여 어쩌다 개발 일정 지연으로 타겟 일자를 늦춰야 하거나 빡빡한 일정 때문에 런칭 후 오류라도 발생하게 되면 그 비난의 화살은 대부분 IT부서가 받게 된다. 심지어 전후 사정을 잘 모르는 경영진은 다른 회사 IT는 금방 개발하는데 왜 우리회사 IT는 개발이 항상 오래 걸리느냐고 IT부서를 질책하면 IT직원의 사기는 땅에 떨어지게 된다. 그런데 이런 일들은 소설속에서만 일어나는 것이 아니라 현실세계에서 흔히 일어나고 있다. 그리고 불행히도 이런 현상은 가끔 일어나는 것이 아니라 프로젝트를 할 때마다 매번 반복되는 악순환의 고리이다.

이런 전통적인 개발 방법론을 “Waterfall”방식이라고 말한다. 즉, 폭포수가 위에서 아래로 이어져 내려
오듯이 앞부분이 선행되어야만 뒷부분을 시작할 수 있어서 붙여진 이름이다. 개발 요구 사항이 정해져야 이를 바탕으로 시스템 설계를 하고 코딩하고 테스트할 수 있는 순차적 방식인 것이다. 이는 선행주자가 바통을 넘겨 주어야만 다음 주자가 뛸 수 있는 400m 계주 경기와 같은 방식이다. 이 때 뛰는 주자 1명을 제외하고 나머지 주자 3명은 모두 대기하고 있어야 한다. 이들은 바통을 이어받을 때를 제외하고는 뛰는 주자를 도와줄 방법이 없다. 이는 마치 기업에서 영업부서 재무부서 상품부서 IT부서와 같이 silo화 되어 “one team”의 시너지 효과를 보기가 쉽지 않은 것과 같은 형태이다.

따라서 이런 계주 방식의 개발 방법론은 인적자원의 극대화와 빠른 제품 출시를 위해서는 일면 불합리한 점을 가지고 있다고 볼 수 있다. 특히 고객과 시장의 요구가 빠르게 변하고 4차 산업 혁명 시대의 첨단 기술이 빛의 속도로 발전하고 있는 현대 사회에 있어서 계주 방식과 같은 “Waterfall”방식으로는 더 이상 경쟁우위에 서기 힘든 것은 엄연한 사실이다.

이런 전통적인 개발 방법론의 단점을 개선하기 위해 탄생된 방법론이 바로 “Agile”방법론이다.
Agile 방법론 중 가장 대표적인 방식은 스크럼인데 이는 미식 축구의 스크럼에서 유래되었다.
미식 축구는 스크럼이라는 팀을 짜고 이 팀이 공을 앞뒤로 패스하며 팀을 중심으로 포괄적 방식으로 경기를 진행한다. 즉, 개인 플레이에 의존하는 계주방식과는 달리 스크럼은 팀중심으로 같이 작전을 짜고 실행한다. 럭비의 스크럼 같이 Agile의 스크럼도 사용자의 요구사항을 결정할 수 있는 Product Owner, 스크럼팀이 잘 전진하도록 조율하는 Scrum Master, 그리고 IT개발자를 한 팀으로 더 이상 silo가 아닌 “one team”을 구성하여 팀 전체가 같이 계획을 짧은 단위로 세우고 실행의 사이클을 자주 반복함으로써 사용자의 요구변화에 유연하고 신속하게 대응한다. 심지어 실패를 해도 비난 보다는 다음 사이클을 위한 Lesson-learn으로 간주하고 실패를 두려워하지 않도록 하며 과감한 시도를 권장한다. 여러가지 면에서 전통방식인 “Waterfall”과는 정반대의 가치기준을 가지고 있다.

Waterfall 방식은 요구사항을 먼저 결정하고 이 요구사항의 size에 따른 인력과 비용 및 개발기간을 예측
하여 결정한다. 이를 Plan-driven 방식이라고 한다. 이 방식은 요구사항을 확정하기가 쉽지 않을 뿐 아니라 한번 확정된 요구사항을 변경하기도 매우 어렵다. 왜냐하면 확정된 요구 사항을 기준으로 설계된
시스템과 DB구조, 응용 프로그램의 구조 등을 중도에 바꾸려면 더 많은 인력과 개발기간이 필요하고 이를 위해서는 더 많은 비용이 소요되기 때문이다. 따라서 IT는 요구사항의 변경을 매우 꺼려하고 이는 사용자 부서와 잦은 갈등을 야기한다. 이는 사용자 부서의 더 경쟁력 있는 시스템 구축 갈망과 IT 부서의 프로젝트 on-time, on-budget, zero-fault 완수와의 충돌이다. 어찌 보면 서로 추구하는 목표가 다르다. 사실 이는 어느 부서의 잘못이 아니라 “Waterfall”방식이 갖는 태생적 한계이기도 하다.

Waterfall 방식과는 달리 Agile방식은 인력과 개발기간을 고정하고 확정된 기간과 비용만큼 달성가능한 비전과 가치를 구현하는 방식이다. 그래서 Value/Vision driven 방식이라고 한다. 가치와 비전을 실현하기 위한 요구사항을 정의하고 우선 순위를 정하고 이 우선 순위대로 팀이 구현할 수 있는 만큼만 가져와 구현하고 더 나은 가치를 위해 언제든지 요구 사항의 변경을 환영한다. 이를 위해서는 요구 사항의 size를 가능하면 작게 하고 프로젝트 기간을 짧게 하여 자주 delivery하여 사용자의 피드백을 받아 지속적으로 시스템을 개선하는 방식이다.
어떤 프로젝트의 궁극적인 목적은 그 프로젝트를 통하여 매출액 증대나, 고객 만족, 신규 고객 확보 등 가치를 창출하는 것이지 프로젝트의 완수 그 자체가 아니다. 따라서 어느 영화의 명 대사처럼 “뭣이 중한디?”를 따져 보면 Agile 방식이 Waterfall 방식 보다는 그 본연의 취지에 부합하는 방법론이라고 볼 수 있다.

그런데 왜 이론적으로나 현실적으로나 더 유리할 것 같은 Agile 방식이 널리 사용되지 못하고 대부분의 기업들은 Waterfall 방식을 사용하고 있을까? 그리고 Agile을 도입한 기업 들은 대부분 왜 성공하지 못하고 중도에 포기하거나 흐지부지 되었을까? 애자일은 정녕 애 잡을 일이었던가? 아니면 정말 현대 사회에 있어서 성공으로 가는 지름길인가? 2001년 “애자일 선언문”이라는 이름으로 인간 중심의 반복적 소프트웨어 개발 방법론을 구성하는 4개의 핵심가치와 12개의 원칙에 대한 선언으로 시장의 주목을 받게 된 애자일은 상의하달식(Top-down) 의사 결정, 관료적 행정 처리, 빅뱅 방식의 SI 개발, Fixed cost 방식의 계약 등에 익숙한 기업들에게 신선한 충격을 주었다. 그리고 Agile Transformation이라는 명목으로 애자일을 도입하는 기업이 늘어나고 있다.
그러나 많은 기업들이 애자일에 대한 완벽한 이해 없이 애자일을 성공한 일부 디지털 기업들을 섣부르게 벤치마킹하여 도입하여 오히려 기존 조직, 문화, 프로세스와 충돌하며 애자일 전환에 실패했다.

Waterfall이 잘못된 방식이 아니듯이 애자일 또한 만능키가 아니다. 기업의 특성에 따라서 트라이브, 스쿼드, 챕터, 길드 등으로 불리는 cross-functional 애자일 조직이 맞을 수도 있고 기존의 본부, 부문, 팀 조직이 더 맞을 수도 있다. 고객과의 접점이 많지 않은 프로젝트나 애자일 방식의 프로젝트의 경험이(개발방법, 계약방식) 없는 SI업체를 사용해야 하는 프로젝트, 그리고 요건의 변경 가능성이 없는 목표가 확고한 프로젝트의 경우에는 애자일 방식 보다는 waterfall 방식이 더 적합 할 수 있다. 또한 단순 반복적인 업무는 애자일 프로세스 보다는 기존의 프로세스가 더 합리적 일 수 있다.

현대 사회에 있어서 Agile transformation은 그저 스크럼, 칸반, XP, 스프린트와 같은 소프트웨어 개발 방법론, 프로젝트 관리 방법론만을 도입하는 것이 아니라 해당 기업에 가장 적합한 애자일 조직, 애자일 문화, 애자일 프로세스를 구축 또는 재구축 하고 이에 따른 성과 평가까지도 연동해야 하는 아주 어렵고도 중요한 과제이다. 그래서 Agile transformation을 Mindset transformation, Culture transformation이라고도 부르는 이유이다.

위에서도 언급했듯이 애자일의 이론이나 개념은 아무 문제가 없다. 또한 4차 산업 혁명 시대의 빠른 첨단 기술의 수용과 슈퍼 스마트 사회에서 고객에 대한 민첩한 대응이 기업의 생존을 결정하는 현대 사회에서 고객의 빠른 피드백을 받아 더 나은 가치 창출을 위해 빠르게 실행하고 반복하여 시장에 유연하게 대응하는 애자일 방식의 도입은 거스를 수 없는 물결로 다가오고 있다. 그리고 애자일을 도입하는 기업은 증가할 수밖에 없다.

각 기업이 왜(why) 애자일을 도입하고 어떤(what) 애자일 요소를 어떻게(how) 언제(when) 도입 하느냐에 대한 치밀한 전략, 전술 그리고 과감한 실행이 필요한 시점이다. 이에 따라 차라리 애자일을 도입하지 않은 것 보다 못한 애 잡을 일이 될 수도 진정한 성공의 지름길이 될 수도 있다.