4장. 애자일 전환#3
#4-3 애자일 적용 전략
#4-3 애자일 적용 전략
* 워터폴과 애자일의 비교
현장에 일하는 실무자를 대상으로 애자일 방식을 제안할 때 사람들이 가장 많이 하는 '실수'가 바로 “워터폴"과 “애자일" 프로세스를 비교하는 것이다. 필자는 이것을 '실수'라고 생각한다. 왜 그렇게 생각하는지 이번 절에서 다루어 보겠다. (사실, 필자도 과거 이렇게 했었다.)
보통 애자일을 한다는 사람들은 아래와 같은 방식으로 워터폴과 애자일의 차이를 설명한다.
“워터폴은 전통적인 방식이고 단계가 종료되어야만 다음 단계로 진행된다. 늘 프로젝트의 마지막에나 제대로된 제품이 나오기 때문에, 고객과 협의가 어렵고, 잘못 만들어진 기능이라도 이를 고치기에는 너무 늦다. 이에 반해 애자일은 프로젝트 초기 동작하는 기능을 만들어 고객과 쇼케이스를 통해 실물을 통해 함께 고민하기 때문에, 워터폴에 비해 훨씬 리스크를 줄일 수 있다. 이제는 애자일을 써야 한다.”
<워터폴 vs 애자일 그림>여러분은 이 비교에 대해 어떻게 생각하는가?
위 대화의 전개 방식은 나쁘지 않아 보인다. 하지만, 이 방식으로 대화를 하면, 대화 상대에게 부정적인 느낌을 줄 가능성이 높다.
이 접근법은 두 가지에서 잘못되었다. 먼저, '워터폴은 잘못되었다'라는 가정에서 대화를 시작하는 것이다. 워터폴은 잘못된 프로세스가 아니다. 가장 합리적인 방법이 될 수 있는 현실의 상황들이 분명히 있다. 그리고 두 번째로, 실제 현장을 다녀보면, 전통적인 워터폴 프로세스는 거의 찾아보기 어렵다. 워터폴 프로세스를 그대로 쓰는 사람들은 대부분이 경험이 부족한 초보자이다.
경험 많은 프로젝트 관리자들은 이미 고객과 오랜 기간 일하면서 체득한 노하우로 워터폴을 변형하여 사용하고 있다. 그들은 끊임없는 고민 끝에 스스로만의 방법을 터득하여 프로젝트의 성공률을 높여왔고, 지금도 그러한 과정을 반복하고 개선하고 있다. 이렇게 하지 않은 프로젝트 관리자는 도태되고 만다. 이들은 불확정성이 극대화된 프로젝트 수행환경에서 치열한 고민을 하고 살아남은 사람들이다.
쉽게 볼 수 있는 몇 가지 현실의 예를 들어 보자. 요구정의 또는 분석 단계동안 화면을 먼저 그린 뒤 고객에게 검증하여 후에 발생할 화면에 대한 논쟁을 감소시키거나, 화면 개발 안을 3~5가지 정도 만들어 점 투표를 통해 논의를 하는 경우 등은 모두 제품의 최종 모습을 고객에게 먼저 보여주고 향후 리스크를 줄이는 방법들이다.
그리고, 신기술을 활용하는 경우는 늘 먼저 POC(Proof of concept)를 수행하고 이를 기반으로 계획에 추가 반영한다. 변덕이 심한 고객을 만나는 경우는 기능이 만들어지는 동안 쇼케이스를 하되 그 변덕쟁이 고객의 상위 관리자를 늘 대동하여 향후 발생할 문제를 조기에 해결하는 쇼케이스를 하는 경우들도 있다.
현장의 잔뼈가 굵은 프로젝트 관리자들에게 여러분은 워터폴을 사용하고 있고, 지금까지 했던 것은 구시대적인 패러다임이라고 이야기하며 애자일을 적용하자는 제안은 쉽게 통하지 않는다.
그렇다면 어떻게 말 하는 것이 더 좋은 대화방법 일까?
필자는 예전에 애자일을 적용하라라는 지시가 내려간 조직의 여러 프로젝트들을 코치로서 찾아간 적이 있다.
어느 여름날, 열 곳 정도의 광화문 주변의 프로젝트들을 찾아 애자일에 대해 설명하고 그곳의 프로젝트 관리자들에게 애자일이 프로젝트에 어떤 도움이 될 수 있는지 이야기했다.
그때의 일화를 잠시 소개하고자 한다. 프로젝트 A에 찾아갔다. 필자는 늘 하던 대로 그 프로젝트 관리자에게 애자일이 어떤 것인지, 이전과의 방법론적의 차이가 무엇이고, 일하는 방법이 이 실제로 어떻게 달라지는지 설명했다. 나의 이야기를 끝까지 잠자코 듣던 프로젝트 관리자는 다음과 같이 이야기했다.
“그 방법도 좋은 방법인 것 같긴 합니다. 하지만, 저는 제 프로젝트의 성공 확률을 최대한 높이는 방법을 알고 있습니다. “
그 프로젝트 관리자는 말을 이었다.
프로젝트 관리자의 역할“우선 제게는 7년 이상 저와 함께 일해온 인력들이 있습니다. 이들은 제가 어느 프로젝트를 가든, 얼마나 힘든 프로젝트를 해야 하건 저를 믿고 따라옵니다. 심지어 제가 회사를 그만두어 다른 회사에 가더라도 저를 따라 함께 할 것으로 굳게 믿고 있습니다. 이 사람들을 전 정말로 신뢰합니다. 그들도 저를 믿고 있고요. 전 이들과 은퇴할 때까지 함께 할 것입니다.
제가 말씀주신 내용을 잘 이해했는지 모르겠지만, 아마도 이 애자일이라는 것은 그 사람들이 서로를 믿을 수 없을 때 계속해서 확인하는 게 아닌가 싶습니다. 계속해서 뭔가를 하면서 확인하는 방식이잖아요?
우리 프로젝트는 그럴 필요가 없습니다. 우리는 함께 WBS를 최대한 상세하게 만듭니다. 이것을 어떻게 활용하는지 이야기하면요… (벽으로 이동하며) 여기 보이시죠? 왼쪽은 사람들의 이름이 있습니다. 그리고 오른쪽은 특정 기능에 관련된 설계 산출물과 소스코드, 그리고 테스트 결과를 담은 표가 있습니다. 제게는 7년간 매일매일 스티커를 붙이는 습관이 되어 있는 사람들이 있습니다.
그리고 그들은 문제가 생기면 스스로 해결해 보다가, 이를 해결하지 못할 것 같으면 가장 빠른 시기에 저를 찾아옵니다. 솔직히, 지금 가져오신 일하는 새로운 방법이 제가 지금 수행하는 방법보다 성공을 높여줄 것이라 생각되지는 않습니다. 왜냐하면 2~3주 단위로 진척을 체크하는 것이 하루 단위로 진척 관리하는 것에 익숙한 사람들의 일하는 흐름을 더 느리게 만들 것이기 때문입니다. “
필자는 프로젝트 관리자를 만난 후, 그와 함께 일하고 있는 팀원들 몇 명을 더 인터뷰했다. 그리고 그들이 가진 프로젝트에 대한 생각도 프로젝트 관리자와 크게 다르지 않음을 확인했다. 프로젝트 관리자가 말한대로 팀 전체가 똘똘 뭉쳐 한 방향을 보고 있었고 매일매일 효과적으로 진척관리가 되고 있었다.
위와 같은 프로젝트에는 어떻게 애자일을 적용해야 할까? 일반적으로 애자일은 현재의 문제점을 기반으로 해결방안을 찾고, 그 해결방안을 애자일 프랙티스들과 연결하여 결과를 본다. 이 프로젝트는 어떠한 문제점이 있는가? 과연 위와 같은 상황에 릴리즈 플래닝이, 스탠드업 미팅이, 페어 프로그래밍이 도움이 될까? 그렇다면 어떻게 필요를 찾을 수가 있을까? 과연 이러한 팀에 애자일이 필요하긴 한 것일까?
이 팀은 팀원들 간에 신뢰가 있다. 그리고 스스로 문제를 해결하기 위해 움직인다. 한 명 한 명의 팀원들이 한 가지 일을 처음부터 끝까지 오너십을 가지고 진행한다.
팀원들은 관리자를 믿고 따른다. 혹시나 본인들이 해결하지 못하는 문제들이 발생하면 관리자가 해결해주기 위해 노력하는 모습을 늘 보기 때문이다. 이러한 신뢰를 기반으로 투명하게 현재 일이 진행되는 상황을 팀 전체가 함께 관리한다.
칸반 보드 같은 보드를 활용하여 한 명 한 명의 액티비티와 산출물들을 관리한다. 아마도 10년 전에는 이 내용이 누군가의 강요에 의해 무조건 했었어야 하는 액티비티였는지도 모른다. 하지만 이제는 모두가 당연한 듯이 이 표준화된 프로세스를 지키고 이 내용을 기반으로 문제점을 이야기하고 해결방안을 찾고 있다. 또한 병목이 되는 일이 있으면 함께 이야기한다. 먼저 관리자에게 이야기하고 이 내용을 팀원들과 곧 공유한다.
오랫동안 노하우를 통해 축적된 프로젝트 관리 방식을 가지고 있고, 팀원들은 이를 중심으로 유기적인 협업을 수행하고 있다. 관리적으로 보면 명령과 제어 중심의 관리방법을 사용하고 있으나, 그것이 실제 프로젝트에 어떠한 해가 되는지 알기 어렵다.
심지어 이러한 방법을 써서 7년간 다수의 성공사례를 만들었다. 위와 같은 경우, 억지로 애자일로 적합한 방법을 팀원들과 찾고, 공감대를 공감대를 얻는 것은 아마도 꽤나 어려운 일이 될 것이다. 아마도 애자일 적용을 하지 않고 그대로 두는 편이 사실 프로젝트 구성원들에게 더 나을 수도 있다.
필자는 그 프로젝트 관리자에게 그의 프로젝트 관리 방식에 대해 많이 배울 수 있었다고 감사함을 표현했다. 그리고 그 프로젝트는 애자일 적용대상에서 제외했던 기억이 있다. 그는 워터폴로 보이는 지속적인 개선을 하고 있었다.
* 애자일 적용 전략
프로젝트 단위로 애자일 적용 방식에 대해 고민하는 것도 중요하나, 전사의 관점에서 애자일 적절한 적용 대상을 찾아야 할때도 있다. 이 경우 애자일 적용을 한다고 하면 이러한 반응을 보이는 경우가 대부분이다.
“명확한 적용 기준을 제시해주세요.”
이러한 반응을 보이는 사람들은 보통 애자일을 누군가에게 설득해야 하는 위치에 있거나, 스스로가 새로운 프로세스의 적용에 대해 부정적인 경우들일 가능성이 높다. 둘 중 어느 경우에나, 전략은 필요하다. 상황을 보다 객관적으로 판단하여 어떠한 방식으로 애자일을 적용할 지를 선택할 수 있는 체계가 필요하다. 천편일률적으로 기법 중심의 스크럼이나 XP를 적용할 수는 없다.
이러한 경험 때문에, 애자일을 상황에 맞게 적합하기 위해 우리는 3단계로 나누어 접근했다. 먼저 프로젝트의 특성을 분석했다. 프로젝트의 성격에 따라 이 프로젝트가 SI 구축형인가, 유지보수형인가에 따라 프로젝트 특성을 분리했다.
애자일 적용전략두 가지를 비교해보면, SI 구축형은 일반적으로 납기, 업무 범위, 리소스 중 납기가 가장 중요하다. 그 다움으로 업무 범위, 리소스가 중요하다. SI 구축형은 약속한 날짜에 약속한 업무 범위를 구현하여 고객에게 전달해야만 성공한 프로젝트로 인지가 된다. 반면에 유지보수형은 정해진 리소스 안에서 할 수 있는 일의 양을 고객과 협상하여, 개별 건마다 정해진 리소스 기반으로 기간을 정하기에, 리소스 > 업무 범위 > 납기 순으로 중요도가 정리된다.
이 중요도를 먼저 파악하고 다음으로 프로젝트에 애자일 적용성을 평가했다. 애자일 적용성은 크게 7가지를 가지고 기준을 잡았다.
애자일 적용의지: 프로젝트 애자일 스폰서십을 본다.
고객 특성: 고객이 프로젝트 현장에 고객이 상주할 수 있는지, 쇼케이스에 대한 관심도가 높은지 또는 실제 만드는 기능과 비즈니스 시나리오에 대해 가진 도메인 지식의 깊이 등을 본다.
프로젝트 인력 특성: 전체 투입과 지원 형태, 풀 타임 인력 비율 등을 본다.
프로젝트 제약사항: 업무 범위에 대한 최초에 정해진 업무 범위를 무조건 다 만들라고 고객이 주장하는 상황인지, 상황에 따라 기존의 업무를 다른 것으로 변경 대체하는 것이 가능한지 여부 확인한다. 또한 무조건 기간을 맞춰 딜리버리 해야 하는지 고객과의 협상을 통해 계획의 변경이 가능하고, 고객이 추가 금액을 지불할 용의가 있는지 확인한다.
프로젝트 복잡도: 이해관계자의 복잡도 정도를 살피고, 타 시스템과의 의존성 정도, 프로젝트 투입 인력 규모를 12명 이하/50명 이하/50명 이상으로 나누어 프로젝트 규모를 파악한다.
아키텍처의 복잡도: 개발 시작 전 표준 아키텍처 수립이 가능한지, 개발을 지원하는 아키텍트의 역량을 본다.
프로젝트 수행환경: 단계를 합쳐 이터레이션이 가능한지 여부를 확인한다. 또한 조기부터 테스터를 투입하여 함께 일할 수 있는 정도를 확인한다.
이 7가지 항목을 기반으로 5점 척도화 하고, 이를 기반으로 점수가 높은 경우에는 순수 애자일 방식을, 점수가 중간인 경우는 워터폴과 애자일의 중간 정도를 제안하는 하이브리드 타입을, 점수가 낮은 경우는 애자일을 적용하 할 수 없다고 결론 지을 수 있게 했다.
;10년 당시를 회상해 보면, 위 요소들 중 가장 애자일 가장 큰 요인은 역시나 관련된 이해관계자들이었다. 프로세스나 기법은 어떻게든 적용할 수 있다. 이것은 시스템적인 영역이기 때문이다. 하지만, 사람은 마인드셋과 문화의 영역에 있기에 변화를 요구하기 매우 어려웠다. 때문에 7가지의 애자일 적용성 평각 기준 중에 가장 중요한 것 3가지를 꼽으면 그것은 애자일 적용의지, 고객 특성, 프로젝트 투입 인력이었다. 그 상세 내용을 조금 더 설명해 보자.
* 애자일 적용기준의 상세 내용
애자일 적용 의지는 애자일 적용에 가장 중요한 요소이다. 프로젝트를 다녀보면, 팀원들이 새로운 것을 적용해보고자 하는 의지가 있더라도 이를 막으려는 리더들이 있는 경우들이 가장 많았다. 이들은 늘 이슈를 최소화하기 위해 모든 것을 자신이 제어할 수 있는 범위에 두는 것을 원했는데, 이는 관리의 단순화와 연관이 되었다. 정해진 범위와 정해진 프로세스로 해야 할 일을 했느냐만 체크하는 형태로 일을 진행하기 원했다. 또한 가장 상위의 관리자에게 스폰서십을 받더라도, 관리자들 사이에서도 커뮤니케이션이 원활하지 않은 경우들이 많아, 그 아래의 관리자들은 이를 적용해야 하는 이유를 모르거나, 거부하는 경우들도 많았다. 이 같은 경우 가장 위부터 또는 가장 아래부터 한 명씩 설득하고 다니는 방법밖에 없었다. 중간관리자까지 설득이 되더라도 팀원들 중 회의론자들이 있는 경우 이들을 설득하기 매우 어려웠다. 이들은 자신의 일을 그저 빨리 끝내고 프로젝트를 뜨기 원하는 사람들이었다. 배움이나 열정이 없는 사람들에게는 이를 적용하는 것이 쉽지 않다.
그 다음으로 중요한 요소가, 고객의 특성이다. 사업이 만들어지는 구조를 보면 실제 비즈니스를 잘 이해하는 고객들이 있는 경우들도 있었지만, 그렇지 않은 경우도 있었다. 그냥 예산을 전달하고, 과정과 결과에 대해 함께 고민하지 않는 경우도 많이 있었다. 이러한 경우, 문제가 생길 때만 관심을 갖는 구조가 되었는데, 이는 고객과의 불신으로 이어졌다. 고객과 쇼케이스를 하면 할수록 문제가 생기는 경우도 있었다. 쇼케이스를 하면 할수록 요구사항 변경이 발생하는 것은 당연한 일인데, 이러한 일이 발생할 때마다, 다음과 같이 반응하는 고객들이 있었다.
“최초 정의를 잘못한 것도 개발팀의 잘못이니, 이 부분까지 책임지고 납기 맞추세요. 내가 언제 이렇게 개발하라고 했나요?"
이러한 고객을 만나는 경우는 늘어나는 변경을 기존의 업무 범위를 고려하여 업무 범위를 변경하거나 하는 일이 매우 어려웠다. 또한 고객의 계층이 너무 복잡한 경우도 있었다. 실무자와 조율이 잘되어 정리가 되더라도, 고객사의 상위 관리자는 이를 동의하지 않는 경우도 있었다.
마지막으로 중요한 요소가 프로젝트 인력 특성이다. SI 구축형 사업에서 프로젝트 인력 대부분이 파트타임인 경우, 다음 프로젝트에서도 이 사람들과 일을 할 수 있는 가능성이 매우 적어지기 때문에, 지속적인 개선이 진행되기 어렵다. 때문에 배움에 중심을 두기보다는 유기적인 협업 방법에 집중하고 제한적으로 이를 적용하는 것을 고려해야 했다. 그리고 하도급 업체를 보호하기 위한 법인 하도급법은 애자일 프로젝트를 하는 경우 협업을 통한 시너지를 방해하는 요소가 된다.
애자일을 적용하고 싶은 팀은 그들 자체의 지속적으로 개선하려는 의지가 있어야 한다. 남이 시켜서 하거나 모양을 내기 위해 하는 경우는 대부분 3~4개월 뒤 사라지기 마련이다. '10년 당시 이러한 요소들을 고려하여, 애자일 적용 프로젝트를 선정했다. 그리고 정말 많은 실험적 시도들이 진행되었다.
