2021.01.26

‘교묘히 방해하기’··· 애자일화에 저항하는 7가지 책략

Bob Lewis | CIO
애자일을 향해 진군하라는 북소리가 커지고 있다. 그러나 애자일로의 변화가 싫거나 불편할 수 있다. 여기 애자일로의 변화가 실패로 귀결되도록 만드는 기똥찬 방법들이 있다.

애자일(Agile)이 본격화되기 시작한지 10년도 넘었다. <애자일 선언>이 나타난 시기가 거의 20년 전이다. 애자일 선언으로 공식화되기 오래 전에도 애자일스러운 기법이 사용되기도 했었다.

그러나, 여전히 애자일을 저지하고자 하는 저항 세력이 있다. 혹시 여러분이 그런 세력에 속해 있는가? ‘애자일화’의 압력을 받는 가운데 소행성의 충돌을 기다리는 공룡같은 기분을 느끼고 있는가? 여기 방법이 있다. 다음의 검증된 7가지 방법으로 공세를 취한다면 소속 회사의 발전과 변화를 방해한다는 비판을 듣지 않고도 IT조직에 애자일이 실행되는 것을 확실히 방지할 수 있을 것이다.
 
Image Credit : Getty Images Bank

1. 애자일이라 부를 것. 무계획적으로 만들 것
다음 번에 프로젝트를 시작할 때는 프로젝트 관리자가 ‘애자일 방식’으로 실행해야 한다고 주장하라. 팀원 전원이 매일 아침 프로젝트를 나름대로 전진시키기 위해 그 날 할 일을 알아내는 식이다.

테스트는 어떻게 하느냐고? 팀이 어떤 기능을 테스트할 준비가 되면, 그 기능을 업무 담당 직원이 내일 써야 한다고 제품 소유자에게 오늘 알려라. 내일 기능이 준비되지 않아도 괜찮다. 다음 번 스프린트로 미루면 되니까.

프로젝트의 일정이 지켜지지 않는다고 제품 소유자가 불만을 제기할 경우에는 ‘애자일 프로젝트’에는 일정이 없다고 해명하면 멋지게 해결된다. 어차피 애자일은 ‘무계획’이라는 뜻 아닌가?

2. 아키텍처를 무시할 것
프로젝트 초반에 애플리케이션 아키텍처를 정의하느라고 시간을 낭비하지 마라. 애자일이 요건의 지속적인 진화를 의미한다면 애플리케이션 아키텍처 역시 지속적으로 진화해야 하지 않겠는가?

그러니, 추상적인 원칙을 지킬 것을 고집하면서 개발자의 창의성을 제한하지 않도록 하자. 그 대신 개발자에게 힘을 실어주어야 한다. 개발자 본인이 원하는 방식으로 마음껏 개발하고 모듈과 인터페이스를 조직화하도록 내버려 두어야 한다. 개발자에 따라 모듈이 서로 달라 연결했을 때 바로 사용이 되지 않는다거나 작성한 개발자에 따라 코드가 의존하는 라이브러리가 서로 다르다고 해도 걱정할 것 없다. 바로 그럴 때를 위해 리팩토링(refactoring)이 있기 때문이다.

심지어, 개발자마다 원하는 개발 언어가 서로 다르다고 해도 괜찮다. 바로 그럴 때를 위해 컨테이너가 있는 것 아닌가?

3. 어차피 답은 스크럼
애자일은 한 가지 방법론이 아니다. 종류가 다른 프로젝트에 각각 적합한 방법론이 여러 개 모인 것이다. 그 중에서 스크럼(Scrum)이 특히 인기 있는 방법론으로 부상한 이유는 유독 융통성 없이 조직된 애자일 변종이어서 다른 것보다 워터폴(waterfall) 작업장에서 편하게 느끼는 것에 더 가깝게 만들어 주기 때문이라고 봐야 한다. 

특히, 스크럼은 IT에서 실시하는 프로젝트의 대부분을 차지하는 상용 기성품 소프트웨어(COTS)와 서비스형 소프트웨어(SaaS) 구현에 적합하지 않다. 다른 애자일 변종인 회의실 파일럿(CRP ; conference room pilot) 아니면 이와 가까운 친척 뻘인 승인 테스트 중심 개발(ATTD)이 더 나은 대안이다.

그러나 누가 그런 것을 들어나 봤겠는가? 아마도 중요한 사람치고 들어본 사람은 없을 것이다. 가장 인기 있는 애자일 변종을 선택하는 것에 대해서는 거센 정치적 반대자조차도 뭐라 하지 않을 것이다. 선택 가능한 다른 애자일 변종이 있다는 것을 알고 있다고 해도 그렇다.

따라서, 스크럼 중심의 COTS 구현이 크게 잘못되어도 여러분이 뭘 잘 몰라서 그런 것은 아닐 것이다. 설사 그렇다고 해도, 애초에 애자일이 좋은 생각이 절대 아니었기 때문에 프로젝트가 실패했다고 주장할 수 있다. 만약 반대 주장을 하는 사람들이 있다면 그들이 스스로를 보호하기 위해 트집을 잡는 것일 뿐이라고 몰아가도 무방하다.

4. 워터폴에서 SAFe까지 한 걸음에 뛰어넘을 것
애자일의 매력이자 최대 강점은 단순함이다. 애자일의 최대 약점은 확장이 그렇게 잘 되지 않는다는 점이다.

똑똑한 회사들은 애자일을 애자일하게 유지한다. 소프트웨어 구현 뿐 아니라 모든 업무 변화를 아우르도록 애자일 원칙을 확장할 정도이다. 이 관점에서 보면, 대규모 전략적 계획은 본질적으로 속성이 워터폴이며 IT 워터폴 프로젝트가 실패하는 것과 똑같은 이유로 실패한다. 직선적이고 상호 의존성과 단일한 잠재적 실패 지점이 많으며, 미래에 대한 가정 중에서 실제 미래가 현재에 이를 즈음이면 적어도 두 번은 바뀔 만한 가정을 바탕으로 구축된다.

그러나 그 모든 것을 신경 쓸 필요는 없다. CIO의 임무는 회사를 좀 더 애자일 하게 만드는 것이 아니라 회사 전략을 뒷받침하는 것이기 때문이다. 해당 전략이 실제로 성공할 확률이 있는지 여부는 상관없다. 애자일은 ‘전략적 프로그램 규모’ 계획에 맞게 확장되지 않는 경향이 있다. 따라서 IT에서는 애자일인 듯 하지만 워터폴처럼 확장하는 방법론을 채택해야 한다.

소위 확장 애자일 프레임워크(SAFe)라는 것이다. (이름 끝에 이런 식으로 ‘e’를 붙이는 전통은 어떻게 생겼는지 영원한 미스터리이다). 애자일 자체는 방법론적 단순함을 통해서 성공하는 반면, SAFe는 지독하게 복잡하다. 움직이는 부분과 잠재적인 실패 지점, 미래에 관한 가정이 워터폴만큼이나 많은데다가 익숙하지 않기까지 하다.

SAFe가 본질적으로 나쁜 것은 아니지만, 숙련된 실무자와 꽤 많은 프로그램이 필요하다.

회사에서 필요한 것이 SAFe라면 IT에서는 SAFe를 할 것이다. 즉, 위험은 아랑곳 않고 워터폴에서 SAFe까지 한 걸음에 뛰어넘는 것이다.

프로그램은 실패하겠지만 여러분의 손은 깨끗할 것이다. 애자일이 확장하지 않는다는 것을 이미 경고했기 때문이다.
 
5. 개발 협력업체의 애자일 사용과 고정 입찰가 합의를 고집할 것
당연히 개발 협력업체는 애자일을 사용해야 한다. 그 편이 낫지 않는가? 게다가 회사 내 모든 관리자에게 IT와 애자일 방식으로 일하는 방법을 교육 중이니 말이다.

업체 입찰가도 당연히 고정되어야 한다. 그 방법으로만 업체들을 정직하게 유지시킬 수 있다. 그렇게 하지 않으면 프로젝트 예산과 일정에서 슬쩍 벗어나려는 ‘삐딱한 마음’이 들게 될 것이다.

고정된 범위로 시작하고 엄격한 변화 통제 관리를 통해서만 바꾸는 것은 애자일에 반하는 것이라고 무모하게 지적하는 업체가 있는가? 만야 그렇다면 그 업체와 함께 일하는 것이 얼마나 어려울 지 작업 지시서에 서명하기 전에 알게 된 셈이니 잘된 일이다.

6. 역외 애자일(Offshore agile)
이론상으로는 업무 기획자가 매출, 비용, 위험에 대한 목표를 설정하고 회사 미션을 달성한다. 그러나 실제로는 대부분의 기업에서 실제 실행 승인을 받은 프로젝트가 비용을 삭감하는 것에 초점을 맞춘다. 

그런 측면에서 개발자 작업 시간에 지불하는 요율보다 시작하기에 더 좋은 곳이 어디 있겠는가?

따라서, 개발 협력업체를 고용할 때는 해당 팀원 대부분의 거주 및 업무 장소가 지구 반대편 정도로 멀리 떨어진 곳인지 확인해야 한다.

그렇다. 애자일 제6원칙은 개발자들 간은 물론 개발자와 업무 사용자 간 대면 대화의 중요성을 강조한다. 역외 개발자들이 대면 대화에 참여하지 않을 것이지만 괜찮다. 무시해라. 그저 이론일 뿐이다. 비용 절약과 추상적인 원칙 중에서 비용 절약을 선택하는 사람이야말로 우리에게 필요한 냉철한 사업가다.

애자일 ‘팀’이 실행한 모듈이 명중하는 과녁이 엉뚱한 과녁이라고 해도 괜찮다. 그러한 모듈은 비용이 훨씬 적게 들 것이며 IT에서는 ‘회사’가 요건에 관해 명확하지 않았다는 식으로 늘 얼버무릴 수 있다. 그러한 변명은 이미 효과가 입증된 바 있다.

요건이 명확하지 않은 것은 대면 의사소통이 너무 적었기 때문이라는 생각은 중요한 사람들이 하지도 않을 것이다. 

7. 프로세스를 가장 중요시 할 것
그렇다. <애자일 선언>이 중요시하는 것은 ‘…프로세스와 도구보다는 개인과 소통’이라는 사실을 우리는 다 알고 있다.

그러나, 지난 몇 십년 동안 경영진이 배운 것이 한 가지 있다면, 사업의 성공은 잘 규정된 반복 가능한 프로세스의 도입에 달려 있다는 점이다. 성공의 원천은 인간 관계, 또는, 더 나은 솔루션을 함께 알아내기 위해 협력하는 직원들이 아니다.

성공의 원천은 수영장 레인 모양으로 잘 정리된 도표의 지시대로 한 단계씩 프로세스를 따르는 직원들이다.

애자일 프로세스 흐름에 복잡성을 계속 더하다 보면 결국 IT에서는 EPMO의 프로젝트 관리 프로세스 실행 감시단의 범위를 확장하게 될 것이다. 워터폴 프로젝트 관리자가 규칙을 지키게끔 그 동안 통제해 온 것처럼 애자일 코치를 감시하기 위해서이다. 

 

해결책 : 프로그램에 제대로 참여해볼 것
여기에 정리된 7가지 전략이 마음에 들지 않는가? 마지막 대안이 하나 더 있다. 피할 수 없다면 굴복하면 된다. 즉, 애자일이 워터폴보다 확실히 효과가 좋다는 점을 인정하고 진솔하게 시도해 보면 된다.

물론 아픔이 동반될 것이다. 하지만 이렇게 생각해 보면 어떨까? 무릎 관절 교체 수술도 아프지만 이에 저항하면 고통만 심해질 뿐이다. 장기적으로 보면 회피하는 것이 더 나쁜 선택인 것이다. 

* Bob Lewis는 글로벌 IT 서비스 기업의 선임 관리자이자 IT 컨설턴트다. 그러나 본 기고문에 담긴 내용은 전적으로 그의 생각이다. ciokr@idg.co.kr
 



2021.01.26

‘교묘히 방해하기’··· 애자일화에 저항하는 7가지 책략

Bob Lewis | CIO
애자일을 향해 진군하라는 북소리가 커지고 있다. 그러나 애자일로의 변화가 싫거나 불편할 수 있다. 여기 애자일로의 변화가 실패로 귀결되도록 만드는 기똥찬 방법들이 있다.

애자일(Agile)이 본격화되기 시작한지 10년도 넘었다. <애자일 선언>이 나타난 시기가 거의 20년 전이다. 애자일 선언으로 공식화되기 오래 전에도 애자일스러운 기법이 사용되기도 했었다.

그러나, 여전히 애자일을 저지하고자 하는 저항 세력이 있다. 혹시 여러분이 그런 세력에 속해 있는가? ‘애자일화’의 압력을 받는 가운데 소행성의 충돌을 기다리는 공룡같은 기분을 느끼고 있는가? 여기 방법이 있다. 다음의 검증된 7가지 방법으로 공세를 취한다면 소속 회사의 발전과 변화를 방해한다는 비판을 듣지 않고도 IT조직에 애자일이 실행되는 것을 확실히 방지할 수 있을 것이다.
 
Image Credit : Getty Images Bank

1. 애자일이라 부를 것. 무계획적으로 만들 것
다음 번에 프로젝트를 시작할 때는 프로젝트 관리자가 ‘애자일 방식’으로 실행해야 한다고 주장하라. 팀원 전원이 매일 아침 프로젝트를 나름대로 전진시키기 위해 그 날 할 일을 알아내는 식이다.

테스트는 어떻게 하느냐고? 팀이 어떤 기능을 테스트할 준비가 되면, 그 기능을 업무 담당 직원이 내일 써야 한다고 제품 소유자에게 오늘 알려라. 내일 기능이 준비되지 않아도 괜찮다. 다음 번 스프린트로 미루면 되니까.

프로젝트의 일정이 지켜지지 않는다고 제품 소유자가 불만을 제기할 경우에는 ‘애자일 프로젝트’에는 일정이 없다고 해명하면 멋지게 해결된다. 어차피 애자일은 ‘무계획’이라는 뜻 아닌가?

2. 아키텍처를 무시할 것
프로젝트 초반에 애플리케이션 아키텍처를 정의하느라고 시간을 낭비하지 마라. 애자일이 요건의 지속적인 진화를 의미한다면 애플리케이션 아키텍처 역시 지속적으로 진화해야 하지 않겠는가?

그러니, 추상적인 원칙을 지킬 것을 고집하면서 개발자의 창의성을 제한하지 않도록 하자. 그 대신 개발자에게 힘을 실어주어야 한다. 개발자 본인이 원하는 방식으로 마음껏 개발하고 모듈과 인터페이스를 조직화하도록 내버려 두어야 한다. 개발자에 따라 모듈이 서로 달라 연결했을 때 바로 사용이 되지 않는다거나 작성한 개발자에 따라 코드가 의존하는 라이브러리가 서로 다르다고 해도 걱정할 것 없다. 바로 그럴 때를 위해 리팩토링(refactoring)이 있기 때문이다.

심지어, 개발자마다 원하는 개발 언어가 서로 다르다고 해도 괜찮다. 바로 그럴 때를 위해 컨테이너가 있는 것 아닌가?

3. 어차피 답은 스크럼
애자일은 한 가지 방법론이 아니다. 종류가 다른 프로젝트에 각각 적합한 방법론이 여러 개 모인 것이다. 그 중에서 스크럼(Scrum)이 특히 인기 있는 방법론으로 부상한 이유는 유독 융통성 없이 조직된 애자일 변종이어서 다른 것보다 워터폴(waterfall) 작업장에서 편하게 느끼는 것에 더 가깝게 만들어 주기 때문이라고 봐야 한다. 

특히, 스크럼은 IT에서 실시하는 프로젝트의 대부분을 차지하는 상용 기성품 소프트웨어(COTS)와 서비스형 소프트웨어(SaaS) 구현에 적합하지 않다. 다른 애자일 변종인 회의실 파일럿(CRP ; conference room pilot) 아니면 이와 가까운 친척 뻘인 승인 테스트 중심 개발(ATTD)이 더 나은 대안이다.

그러나 누가 그런 것을 들어나 봤겠는가? 아마도 중요한 사람치고 들어본 사람은 없을 것이다. 가장 인기 있는 애자일 변종을 선택하는 것에 대해서는 거센 정치적 반대자조차도 뭐라 하지 않을 것이다. 선택 가능한 다른 애자일 변종이 있다는 것을 알고 있다고 해도 그렇다.

따라서, 스크럼 중심의 COTS 구현이 크게 잘못되어도 여러분이 뭘 잘 몰라서 그런 것은 아닐 것이다. 설사 그렇다고 해도, 애초에 애자일이 좋은 생각이 절대 아니었기 때문에 프로젝트가 실패했다고 주장할 수 있다. 만약 반대 주장을 하는 사람들이 있다면 그들이 스스로를 보호하기 위해 트집을 잡는 것일 뿐이라고 몰아가도 무방하다.

4. 워터폴에서 SAFe까지 한 걸음에 뛰어넘을 것
애자일의 매력이자 최대 강점은 단순함이다. 애자일의 최대 약점은 확장이 그렇게 잘 되지 않는다는 점이다.

똑똑한 회사들은 애자일을 애자일하게 유지한다. 소프트웨어 구현 뿐 아니라 모든 업무 변화를 아우르도록 애자일 원칙을 확장할 정도이다. 이 관점에서 보면, 대규모 전략적 계획은 본질적으로 속성이 워터폴이며 IT 워터폴 프로젝트가 실패하는 것과 똑같은 이유로 실패한다. 직선적이고 상호 의존성과 단일한 잠재적 실패 지점이 많으며, 미래에 대한 가정 중에서 실제 미래가 현재에 이를 즈음이면 적어도 두 번은 바뀔 만한 가정을 바탕으로 구축된다.

그러나 그 모든 것을 신경 쓸 필요는 없다. CIO의 임무는 회사를 좀 더 애자일 하게 만드는 것이 아니라 회사 전략을 뒷받침하는 것이기 때문이다. 해당 전략이 실제로 성공할 확률이 있는지 여부는 상관없다. 애자일은 ‘전략적 프로그램 규모’ 계획에 맞게 확장되지 않는 경향이 있다. 따라서 IT에서는 애자일인 듯 하지만 워터폴처럼 확장하는 방법론을 채택해야 한다.

소위 확장 애자일 프레임워크(SAFe)라는 것이다. (이름 끝에 이런 식으로 ‘e’를 붙이는 전통은 어떻게 생겼는지 영원한 미스터리이다). 애자일 자체는 방법론적 단순함을 통해서 성공하는 반면, SAFe는 지독하게 복잡하다. 움직이는 부분과 잠재적인 실패 지점, 미래에 관한 가정이 워터폴만큼이나 많은데다가 익숙하지 않기까지 하다.

SAFe가 본질적으로 나쁜 것은 아니지만, 숙련된 실무자와 꽤 많은 프로그램이 필요하다.

회사에서 필요한 것이 SAFe라면 IT에서는 SAFe를 할 것이다. 즉, 위험은 아랑곳 않고 워터폴에서 SAFe까지 한 걸음에 뛰어넘는 것이다.

프로그램은 실패하겠지만 여러분의 손은 깨끗할 것이다. 애자일이 확장하지 않는다는 것을 이미 경고했기 때문이다.
 
5. 개발 협력업체의 애자일 사용과 고정 입찰가 합의를 고집할 것
당연히 개발 협력업체는 애자일을 사용해야 한다. 그 편이 낫지 않는가? 게다가 회사 내 모든 관리자에게 IT와 애자일 방식으로 일하는 방법을 교육 중이니 말이다.

업체 입찰가도 당연히 고정되어야 한다. 그 방법으로만 업체들을 정직하게 유지시킬 수 있다. 그렇게 하지 않으면 프로젝트 예산과 일정에서 슬쩍 벗어나려는 ‘삐딱한 마음’이 들게 될 것이다.

고정된 범위로 시작하고 엄격한 변화 통제 관리를 통해서만 바꾸는 것은 애자일에 반하는 것이라고 무모하게 지적하는 업체가 있는가? 만야 그렇다면 그 업체와 함께 일하는 것이 얼마나 어려울 지 작업 지시서에 서명하기 전에 알게 된 셈이니 잘된 일이다.

6. 역외 애자일(Offshore agile)
이론상으로는 업무 기획자가 매출, 비용, 위험에 대한 목표를 설정하고 회사 미션을 달성한다. 그러나 실제로는 대부분의 기업에서 실제 실행 승인을 받은 프로젝트가 비용을 삭감하는 것에 초점을 맞춘다. 

그런 측면에서 개발자 작업 시간에 지불하는 요율보다 시작하기에 더 좋은 곳이 어디 있겠는가?

따라서, 개발 협력업체를 고용할 때는 해당 팀원 대부분의 거주 및 업무 장소가 지구 반대편 정도로 멀리 떨어진 곳인지 확인해야 한다.

그렇다. 애자일 제6원칙은 개발자들 간은 물론 개발자와 업무 사용자 간 대면 대화의 중요성을 강조한다. 역외 개발자들이 대면 대화에 참여하지 않을 것이지만 괜찮다. 무시해라. 그저 이론일 뿐이다. 비용 절약과 추상적인 원칙 중에서 비용 절약을 선택하는 사람이야말로 우리에게 필요한 냉철한 사업가다.

애자일 ‘팀’이 실행한 모듈이 명중하는 과녁이 엉뚱한 과녁이라고 해도 괜찮다. 그러한 모듈은 비용이 훨씬 적게 들 것이며 IT에서는 ‘회사’가 요건에 관해 명확하지 않았다는 식으로 늘 얼버무릴 수 있다. 그러한 변명은 이미 효과가 입증된 바 있다.

요건이 명확하지 않은 것은 대면 의사소통이 너무 적었기 때문이라는 생각은 중요한 사람들이 하지도 않을 것이다. 

7. 프로세스를 가장 중요시 할 것
그렇다. <애자일 선언>이 중요시하는 것은 ‘…프로세스와 도구보다는 개인과 소통’이라는 사실을 우리는 다 알고 있다.

그러나, 지난 몇 십년 동안 경영진이 배운 것이 한 가지 있다면, 사업의 성공은 잘 규정된 반복 가능한 프로세스의 도입에 달려 있다는 점이다. 성공의 원천은 인간 관계, 또는, 더 나은 솔루션을 함께 알아내기 위해 협력하는 직원들이 아니다.

성공의 원천은 수영장 레인 모양으로 잘 정리된 도표의 지시대로 한 단계씩 프로세스를 따르는 직원들이다.

애자일 프로세스 흐름에 복잡성을 계속 더하다 보면 결국 IT에서는 EPMO의 프로젝트 관리 프로세스 실행 감시단의 범위를 확장하게 될 것이다. 워터폴 프로젝트 관리자가 규칙을 지키게끔 그 동안 통제해 온 것처럼 애자일 코치를 감시하기 위해서이다. 

 

해결책 : 프로그램에 제대로 참여해볼 것
여기에 정리된 7가지 전략이 마음에 들지 않는가? 마지막 대안이 하나 더 있다. 피할 수 없다면 굴복하면 된다. 즉, 애자일이 워터폴보다 확실히 효과가 좋다는 점을 인정하고 진솔하게 시도해 보면 된다.

물론 아픔이 동반될 것이다. 하지만 이렇게 생각해 보면 어떨까? 무릎 관절 교체 수술도 아프지만 이에 저항하면 고통만 심해질 뿐이다. 장기적으로 보면 회피하는 것이 더 나쁜 선택인 것이다. 

* Bob Lewis는 글로벌 IT 서비스 기업의 선임 관리자이자 IT 컨설턴트다. 그러나 본 기고문에 담긴 내용은 전적으로 그의 생각이다. ciokr@idg.co.kr
 

X