디지털 시대의 변화 속도는 더욱 빨라지고 있다. 환경 변화에 빠르게 대응하는 능력이 강조되면서 애자일 방식이 주목을 받고 있다. 기획과 실행 그리고 적용의 사이클을 통합하고 반응에 따라 신속하게 대응하는 조직 문화와 역량을 갖추는 것은 아마존이나 애플, 삼성전자와 같은 IT 기업들의 과제였다. 2017년 우리나라 카드회사에도 애자일 프로세스가 도입되어 성공한 사례가 등장했고, 2018년에 들어서는 KB금융지주와 하나금융지주의 총수들이 아마존의 애자일 프로세스를 언급하기도 했다.

애자일 방식은 원래, 소프트웨어 개발 과정에서 분석이나 설계 등 문서화 작업보다 개발과 테스트에 집중하는 접근법으로 시작되었다. 요구 사항을 확정하거나 프리징하기가 어려운 환경에서 효과적인 방법이다. 지금은 소프트웨어 개발뿐만 아니라 비즈니스 서비스 및 상품 기획에도 폭넓게 적용되는 추세이다. 전통적으로 보수적인 금융회사들도 IT기업들의 운영방식에 적용하였던 ‘애자일 방식’과 ‘애자일 조직’ 개념을 적극적으로 도입하고 있다.

애자일 방법론은 2001년 애자일 소프트웨어 개발 선언 이후 20년이 가까운 시간 동안 많은 성공과 실패 사례를 가지고 있으며, 역방향으로는 안티 애자일을 외치고 있는 개발자들도 볼 수 있다. 혹자는 애자일은 IT를 죽이는 방법론이라고 언급하기도 하였다. 하지만 애자일은 소프트웨어 개발 방법론으로부터 조직 경영으로 확산되고 있으며 더 다양한 분야에서 갑론을박의 대상으로 부상하고 있다.

간략하게 살펴보면, 고객의 요구사항이 처음부터 명쾌할 수 없다는 전제하에 변하는 요구사항을 시스템에 반영하기 위해 반복적이고 점진적인 개발을 진행하는 것으로 이해하고 있을 것이다. 반복적이고 점진적이라는 것은 수정, 추가, 삭제가 동반하는 요구사항의 변화를 지속적으로 반영한다는 의미로 해석되어 진다. 또한 요구사항 뿐만 아니라 개발자의 소스코드도 반복적으로 수정되고 점진적으로 완성되어져 나감을 의미하기도 한다.

모나리자를 완성하는 과정의 비유로 애자일 프로세스를 이해하여 보자.
 

[그림 1] 애자일 방법론을 잘못 이해한 사례
(출처 : https://www.safaribooksonline.com/library/view/user-story-mapping/9781491904893/ch04.html)

 
[그림 2] 애자일 방법론을 잘 이해한 사례
(출처 : https://www.safaribooksonline.com/library/view/user-story-mapping/9781491904893/ch04.html)

사례를 통해 알 수 있듯이 애자일 방법론은 퍼즐 맞추기가 아니라 스케치를 통해 이미지를 확인하고, 잘못된 부분을 수정하고 원하는 모습으로 완성하도록 하는 방법론이다.

이렇게 진행되기 위해서는 스케치 단계부터 참여자 모두가 의견을 제시하여야 하며 서로 다른 의견이라 하더라도 협의에 의해 혹은 반영 후 수정을 통한 방식의 수용이 전제되어야 한다. 특히, 가장 중요한 것은 요건의 변화가 발생했을 때 빠른 의사결정이 필요하다는 것이다.

금융사 시스템을 개발하고 운영하는 현장의 목소리를 들어보면 새로운 비즈니스 요건을 반영한 시스템이 필요한 스타트업 기업들의 경우는 애자일 방법론을 통한 신속한 대응이 효과적이겠지만 이미 안정적으로 운영하고 있는 시스템 고도화에는 적합하지 않다는 의견이 다수이다. 현장의 소리를 경청하여 애자일 방법론의 실제 적용을 위한 성공 요소를 정의해 본다.

1. 기준을 제공하는 업무와 유연함이 보장되어야 하는 업무가 구분되어야 한다.
애자일 방법론은 다양하게 변하는 요건 반영을 위한 방법론이므로 오랜시간에 걸쳐 정리되어 온 업무 시스템은 애자일 방법론의 효과가 감소될 것이다.
보험회사의 계약(계좌)관리와 운용은 오랫동안 그 원칙을 고수하며 운영되고 있으며, 약관(표준약관, 특별약관 등)을 통한 기준이 관리되고 있다. 채널과 같이 디지털화를 위해 변화를 신속하게 수용하여야 하는 경우는 짧은 개발 사이클을 통한 요건 확인이 필요하다.

2. 개발팀은 현업, 내부개발자, 외부개발자를 참여자로 하나의 팀(OneTeam)을 구성해야 하며 업무 특성에 따라 참여자의 특성 고려가 필요하다.
계약시스템과 채널시스템과 같이 서로 다른 성격의 시스템 개발시에는 참여자의 인사이트를 충분히 고려하여야 한다. 기준이 되는 시스템의 경우에는 업무 인사이트가 많은 참여자가 필요하겠지만, 변화의 수용이 우선되는 시스템의 경우에는 업무 인사이트가 오히여 걸림돌이 될 수 있으므로 창의적 아이디어를 중요시 할 필요가 있다.
애자일 조직 구성의 성공사례로 회자되고 있는 글로벌 ING의 경우 애자일 조직 선언 이후 약 40%의 직원이 원래 직무와 다른 영역에서 근무하고 있다고 한다.

3. 철저한 계획 수립, 공유 및 관리를 위한 시스템을 갖춘다.
개발주기를 짧게 할수록 더욱 치밀한 계획 수립이 필요하다. 계획 수립은 최소한의 시간을 소요하지만 수립된 계획은 철저히 지켜져야 하며 계획에 차질이 생길 경우 바로 계획을 수정하고 공유할 수 있는 명시적 관리도구가 필요하다.
일정에 맞추기 위한 관리가 아니라 요건 반영을 위한 일정관리가 필요한 것이다. 애자일 방법론의 가장 중요한 요소인 의사소통이 명쾌하게 이루어져야 하는 대목이기도 하다.

4. 개발팀에게 의사결정 권한과 책임을 부여한다.
개발 프로젝트는 다양한 리스크 요소를 가지고 있으므로 대부분 PM에게 의사결정 권한이 몰려있기 마련이다. 그러나 이러한 의사결정 체계를 가지고는 수정되는 요건 반영을 위한 조치(Action)는 늦어질 수 밖에 없고, 선행작업의 지연(delay)은 후행 업무에 더 많은 지연요소로 작용하게 될 것이다. 여기에서 발생할 수 있는 오류는 권한이 없는 책임부가이다. 권한이 없는 책임만 있으면 각 개발팀은 소극적인 운영을 할 수 밖에 없기 때문이다.

5. 각 참여자간의 협업체계가 감시도구로 전략하는 것을 방지하여야 한다.
각 팀에 권한과 책임이 부여되고 협업을 위해 도입된 공유체계가 각 팀의 업무 진행 경과와 오류 발견, 책임 전가를 위한 감시도구로 전략되는 것을 방지하기 위한 목표 관리가 필요하다. 기본적으로 사람간 협업은 우호적 감정을 기반으로 형성되는 것이므로 서로의 표적 또는 감시대상이 되는 순간 협업은 깨어질 수 밖에 없다.

6. 개발팀 리더를 위한 교육이 필수적으로 선행되어야 한다.
애자일 방법론은 자유를 보장하는 듯 하지만 더욱 철저한 관리를 필요로 하며, 창의적 아이디어가 필요하지만 현실세계 적용을 위한 고려가 사전에 이루어져야 하며 나의 목소리를 내는 것이 중요하지만 반드시 다른 목소리에 대한 경청이 필요하다. 이렇게 서로 상반된 요소들을 조화롭게 운영하기 위해서는 감초와 같은 능력을 가진 리더가 필요하며, 이러한 리더는 교육을 통해 양성하는 과정이 필수적으로 동반되어야 할 것이다.

애자일 방식이 전통적 폭포수 방식(Waterfall Approach) 보다 항상 우월한 것은 아니다. 비즈니스 환경의 변화 폭이 크고 속도가 빠른 경우에 보다 적합하다. 또한 애자일 방식을 도입하기 위해서는 탁월한 리더와 훈련된 개발자들이 반드시 필요하다. 디지털화한다는 것은 기존과 다른 상품과 서비스를, 그것이 무엇인지 잘 알지 못하더라도 만들어내야 한다는 뜻이다. 디지털경제가 발전될수록 애자일이 장착된 조직이 앞서 갈 것임은 명확하다.

- 끝 -