기고 | 애자일 기법이 유효하지 못한 이유 ‘그리고 해결책’

CIO

애자일(Agile) 기법이 성공한 이유의 상당 부분은 예산과 시간이 부족한 프로젝트, 팀의 효율성 부족, 진정한 협업 부족, 떨어지는 제품의 품질, 불만 고객 등 지속적인 IT 부문의 문제에 대한 해결책을 약속함에 따라 잘 ‘팔려’나갔기 때문이다.

그러나 팀 구성원, 책임 설계자, 전체 관리자 등 다양한 역할로 여러 애자일 프로젝트에 참여한 경험이 있는 필자는, 결론적으로 애자일이 한 때 유행했던 다른 방법론들처럼 실패했을 뿐 아니라 IT 상황을 더욱 악화시켰다고 생각한다.

그렇다. 이미 잘 통합된 팀이 참여하는 POC(Proof of Concept) 등 경우에 따라서는 애자일이 유용한 경우도 있지만 여기에서는 나머지 80%의 경우에 대해 이야기하고자 한다.

애자일 기법의 3가지 결점
애자일 기법은 약속된 효과와 반대 방향의 결과를 가져온다. 여기에는 여러 가지 이유가 있지만 가장 파급력이 큰 3가지 애자일 원칙에 초점을 맞출 것이다 (아래 굵은 글씨로 표시된 명칭은 필자 나름대로 선택한 것이다).

우선 품질보다 제공을 우선시하면 애자일의 원칙인 "가치 있는 소프트웨어의 조기 연속 제공" 이라는 원칙이 다른 의미를 갖게 된다. 그렇다. 고객 협업에 있어서 조기 가시성은 중요한 툴이다. 하지만 지속적인 제공에 초점을 맞추면 개발자들이 고객들에게 제공할 무언가를 개발하는 동안에 관리가 어려운 결함 백로그(Backlog)가 발생하게 된다.

필자가 참여한 대부분의 애자일 프로젝트에서는 결함이 처리할 수 있는 수준보다 더욱 빠르게 확대되곤 했다. 한 중간 규모의 프로젝트에서는 첫 18개월 동안 엄청난 결함 백로그가 발생하여 이를 관리할 전담인력이 필요할 정도였다. 우리는 백로그 해결을 위해 계속해서 인력을 확보해야 했다. 이 때문에 새로운 기능이 손상되었을 뿐 아니라 새로운 결함이 발생하면서 결함 해결의 업무 부담만 가중되었다.

프로젝트에서 대형 결함 백로그가 발생하는 것은 새로울 것이 없지만 애자일로 인해 결함을 무시하는 상황이 발생하게 된다. 이 때문에 백로그 관리가 불가능해지고 결국에는 개발의 의미가 없어진다.

필자는 처음에 협업에 대한 희열에 사로잡혔다가 결국에는 끝없는 결함 목록에 지쳐 정신적으로 피폐해진 개발자들을 여럿 보았다. 애자일 프로젝트로 인해 많은 좋은 개발자들이 지쳐가고 있으며, 이는 프로젝트가 "언제까지나 일정한 속도로 유지될 수 있다"고 약속하는 애자일과는 거리가 멀다 하겠다.

두 번째 결점은 기획보다 개발을 중시하는 것이다 이는 "계획을 따르면서 변화에 대응"이라는 애자일의 원칙이 손상된다. 이론적으로 개발자들을 프로젝트가 진행되면서 요건을 정의, 개선, 변경할 이해당사자들과 협업하면서 코드를 작성한다. 하지만 이 방법론에서는 크게 작은 변화 사이의 차이가 없다.

모든 변화에는 비용이 수반되지만 애자일은 이를 고려하지 않는다. 결과는? 사람들은 종종 애자일 프로젝트에서는 가능하다는 생각에 근거하여 늦은 시점에 매우 큰 변화를 적용한다. 프로젝트에서 이것을 처리할 수 있는 유일한 방법은 신판(iterations)을 추가하는 것이다. 그러면 코드 기반이 계속해서 바뀌기 때문에 어떤 시점에서는 쉽게 수정할 수 있었던 결함이 점차 수정하기 어려워진다.

이 원칙으로 인해 효과는 모호해지면서 형편 없고 무책임한 계획이 난무하게 된다. 신판이 계속 개발되고 결함이 증가하면 고객은 품질뿐만이 아니라 공급에 대한 기대치가 충족되지 못하면서 더욱 불만족을 느끼게 된다.

이는 잘 정의된 요건에 기초한 프로젝트에서 가끔은 복잡 미묘하지만 최소한 시간과 비용이 더욱 명확한 변화관리 프로세스를 통해 변화를 관리하는 더욱 전통적인 방식과 크게 다르다.

결함이 있는 애자일의 세 번째 원칙은 관리보다 협업을 중시하는 것이다. 애자일은 일련의 혁신적인 방법으로 "제대로 된 일을 하는" 자기 관리 팀을 강조한다. 많은 전통적인 프로젝트들이 사람들을 제대로 활용하지 못하기에 개인에게 힘을 실어주는 것에 반대하는 것은 아니지만 애자일이 항상 책임감 있는 관리를 보장하는 것은 아니다.

굳이 단일 사용자로부터 권한을 빼앗아가는 방법론은 필요 없다. 굉장히 많은 프로젝트에서 스크럼(Scrum) 관리자는 절망에 몸서리치는 불운한 카우보이에 지나지 않지만 그 책임은 한 번에 너무 많은 방향으로 분산된다. 자기관리라는 미숙한 유토피아적 신념 때문에 신뢰할 수 있으며 책임감 있는 프로젝트 관리를 저버릴 수는 없다. 그렇게 되면 성공과는 거리가 멀어진다.

3가지의 상식적 원칙을 통해 애자일적 사고 바꾸기
애자일의 매력적인 특징 중 하나는 이름이다. 우리는 민첩한 사고력이라는 아이디어를 좋아한다. 하지만 애자일은 하나의 기법으로써 민첩한 사고력을 제공할 수 없으며 불가피하게 그 반대의 결과를 낳게 된다.


‘애자일’을 예산, 시간, 디자인 패턴, 재사용성, 고객의 필요, 기업의 필요, 선례, 기준, 기술 혁신, 한계 등 프로젝트의 모든 가변적인 투입요소를 취할 수 있는 능력으로 생각하고 빠른 시일 내에 제품이 제대로 제공되도록 문제를 해결하는 실용적인 접근방식을 제시하는 것이 바람직하다.

무리한 요구로 들리겠지만 결국에는 상식적인 원칙에 도달하게 될 것이다.

좋은 프로젝트 관리자에게 필요한 한 가지 핵심적인 자질이 있다면 그것은 바로 우선순위 정하기이다. 이것은 모든 프로젝트 요소의 압박을 견디며 무엇을 가장 중요하게 달성해야 하는지에 기준하여 어떤 방향으로 나아갈지 결정하는 것이다.

목표는 시간과 예산에 맞추어 양질의 제품을 제공하는 것임을 기억해야 하며, 다른 것들을 충족시키기 위해서는 반드시 일부 요소를 희생할 수 밖에 없음을 염두에 두어야 한다. 이것은 프로젝트의 우선순위를 정의하고 유지하여 팀원들이 업무를 수행하는 동안 의사결정 프레임워크로 작용할 수 있도록 하는 프로젝트 관리자의 차세대 프로젝 관리자의 역할 수립 방법이다.

많은 개발자들이 겪고 있는 어려움 중 하나는 실용주의의 부재다. 그들은 실용적으로 생각하기보다는 문제에 대한 추상적인 접근방식에 빠져 허우적거릴 수 밖에 없다. 필자는 한 때 모든 것의 재사용이 가능해야 하며 동적으로 연계될 수도 있어야 하는 순수주의 디자인에 기반한 매우 값 비싼 프로젝트에 참여한 적이 있다. 이것은 추상화의 경이였다. 하지만 문제는 성공하지 못했다는 것이다. 자바(Java) 시스템에서 이전에 목격하지 못한 최악의 성능을 목격했으며 필요한 부하를 전혀 지원할 수 없었다.

핵심적인 문제는 해당 팀이 추상적인 접근방식으로 실제 세계의 문제를 해결하려 시도했다는 점이다. 가상의 기술이 얼마나 대단하던, 궁극적으로 인간이 살고 있는 물리적 세계에 기반한 것이다.

물리적인 문제는 추상적으로 해결할 수 없다. 공장의 기계에 사용되는 이상한 모양의 부품들을 보면, 각각 하나의 매우 중요한 물리적 기능에 적합하도록 설계되어 있다는 것을 알 수 있다. 소프트웨어도 이와 다르지 않다. 때로는 한 가지 이상의 용도가 의도되기도 한다. 수 년 동안 제대로 작동하여 목적을 달성한다면 문제될 것이 없다.

마지막으로, 다이너미즘(Dynamism)은 현재의 전략에 문제가 있을 때 전략을 전환할 수 있는 능력이다. 괜찮아 보이는 프로젝트에서 최선을 다해 계획을 세우더라도 디자인 또는 개발 전략이 벽에 부딪히는 경우가 여러 번 있었다. 이런 상황에서 가장 중요한 것은 언제 철수할지를 아는 것이다.

문제가 단순해서 하루 또는 이틀 밤을 새워 해결할 수 있다면 문제가 되지 않는다. 하지만 문제가 심각하다면 프로젝트 전체를 위험에 빠뜨리는 대신에 다른 방안을 찾는 것이 좋다. 단순하게 들리겠지만 수 주 동안 프로젝트에서 팀 구성원들이 심각한 문제를 해결하기 위해 머리를 맞대었다가 다른 접근방식을 취하기에는 이미 너무 늦어버렸다는 결론을 내리는 경우를 종종 목격했다.

애자일은 불가능한 해결책을 약속한다. 애자일은 엉성한 요건을 홍보하면서 개발의 진정한 비용을 감추고 효과적인 관리를 어렵게 만든다. 우리가 기대하는 것과는 달리 이로 인해 프로젝트가 장기화되고 고객들의 불만이 속출하며 IT 전체의 효율이 저하된다.

하지만 우리가 여기에서 민첩한 사고를 통해 달성할 수 있는 것을 찾고자 한다. 이런 사고를 통해 우리는 실제로 IT 프로젝트 관리의 문제를 해결하고 안정적인 제품을 시간과 예산에 맞추어 제공할 수 있는 방법을 알게 된다. 프로젝트 팀이 효과적으로 사고하고 일하는 방법을 알고 있다면 프로젝트 실패를 해결할 방법을 찾아볼 필요가 없어진다. 우리는 우리 스스로 할 수 있다.

* Lajos Moczar은 선임 기술 전략가이자 컨설턴트다. ciokr@idg.co.kr