2013.06.07

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

Lajos Moczar | CIO

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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




2013.06.07

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

Lajos Moczar | CIO

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


X