우리는 왜 애자일을 적용하지 못하는가?
디지털 트랜스포메이션에 대하여- 1
작성된 내용은 필자가 보고, 듣고, 경험한 내용에 기반으로 하고 있으므로 지극히 개인적이고 좁은 견해일 수 있습니다. 논쟁의 여지가 있는 내용이 있을 수 있으며, 서로 다른 견해에 대한 토론 및 내용의 오류에 대한 비판을 지향합니다.
이 글에서는 애자일(Agile) 방법론에 대한 필자의 개인적인 이해와 이를 실제 비즈니스 환경에 적용할 때의 문제점 등을 고민해보려 합니다. 그리고 보다 더 나아가서, 애자일에 국한되지 않고 기업의 개발 프로세스를 실용적으로 변화시키기 위해 필요한 노력에 대해서도 논의해보겠습니다. 특히, 전통적인 IT 개발 조직이 아니라 현업과 개발자의 협업을 통해 비즈니스를 운영하는 대다수의 유지보수 조직에서 발생할 수 있는 문제점을 이야기한다는 것도 참고해주시면 좋을 것 같습니다.
애자일(Agile)?
애자일 방법론의 적용을 논하기 전에, 간단한 정의에 관해 알아보겠습니다.
애자일의 사전적 정의는 ‘날렵한’, ‘민첩한’ 등이며 2001년 ‘애자일 소프트웨어 개발 선언’에 의해 공식적으로 명명됐습니다. 이는 완전히 새로운 개념은 아니며, 스크럼, 칸반 등 산재해 있던 실용주의 개발 방법을 포괄하는 역할을 했다고 볼 수 있습니다. 다음은 ‘애자일 소프트웨어 개발 선언문’의 번역된 전문입니다.
애자일 소프트웨어 개발 선언
우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:
공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를
가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.
‘형식’ 보다는 ‘실용’
저는 글을 읽고 위와 같은 한줄평이 떠올랐습니다. 그리고 선언문의 내용을 국내 기업 업무환경에서 사용하는 개념으로 표현하면서 나름대로 애자일에 대해 이해하려고 노력해봤습니다.
비즈니스 담당자(현업)와 개발자의 상시 협업
개발 도중 주기적인 중간 산출물(프로토타입 등)을 통한 의사소통
고객 피드백 기반의 더 많은 릴리즈
요구사항 변경에 대한 유연한 대처
즉, " 애자일은 고객만족을 위해 더 짧은 개발 주기를 요구하며 이를 위해 현업과 개발자 등, 업무 담당자 간의 실용적인 의사소통이 필수적이다."라고 정리해볼 수 있겠습니다.
물론 이 정도 내용으로 애자일을 완벽히 이해하기엔 부족하지만, 많은 조직에서 애자일 적용에 실패하는 몇 가지 원인을 살펴볼 수는 있을 것입니다.
애자일 도입이 어려운 이유가 뭘까?
글의 도입부에서 언급한 것처럼, 이 글은 태생이 IT기업인 카카오, 네이버 같은 기업보다는 은행, 증권사와 같은 비즈니스 중심의 기업 상황에 좀 더 적합하다고 생각합니다. 이런 형태의 비즈니스를 운영하는 기업들은 현업이 정의한 요구사항을 개발자가 구현하는 전통적인 개발방식에 익숙하며, 신규 서비스의 개발보다는 레거시 시스템의 유지보수가 차지하는 비중이 압도적인 특징이 있습니다.
최근 이런 기업들은 ‘디지털 트랜스포메이션’, ‘핀테크’ 등의 전략을 강조하며 IT부분에서 많은 변화를 시도하고 있으며, 그중에서 애자일 방법론 등 좀 더 유연한 개발 문화를 도입하려는 시도는 빼놓을 수 없는 부분입니다. 하지만 기업 임원들의 의지에 비해, 애자일 방법론을 성공적으로 도입했다는 기업은 좀처럼 찾아보기 힘듭니다. 저는 이런 문제의식으로 그 원인이 될 수 있는 몇 가지 문제점을 생각해봤고, 개인적인 경험을 더해서 정리해봤습니다. 이 문제점들은 단독으로 존재하는 경우는 많지 않을 것이고 복합적으로 존재하면서 기업에 애자일이 적용되는 것을 쉽지 않게 할 것입니다.
"현재 우리의 방법론은 뭔가요?"
많은 기업에서 애자일 방법론을 적용하려는 주체는 기업의 임원들이며, 이들은 몇 가지 서적, 기사 등 이론적인 설명에 매료돼 “우리 IT에도 도입하면 Cool하겠는데?”라는 식의 막연한 기대감으로 전략을 추진합니다. '막연함'이라는 표현이 조금 과하게 느껴질 수는 있으나, 애자일의 개념이 정립된 지 20년이 돼가는 시점에서 신대륙을 발견한 듯한 임원진의 리액션에는 젊잖은 표현일 수도 있습니다.
그렇다고 이런 임원진을 마냥 비난할 수는 없습니다. 이들은 IT를 해본 적이 없거나, 손으로 코딩해서 입력하던 시대의 개발자 일 수 있기 때문입니다. 그러므로 이들의 기대감에 구체적인 설계를 제공하거나, 필요하다면 찬물을 끼얹는 것은 실무진이 해야 할 역할일 것입니다. 하지만 제 경험에 빗대어 기업에서 애자일을 도입하는 과정을 주관적으로 정리해보면 아래와 같습니다.
임원: "한 번 해봐!"
기획 및 개발팀
- 스크럼, 칸반 등 개념 검토 및 현황조사
- 개발팀 교육용 자료 제작 및 교육 실시
- 화이트보드/포스트잇 활용 등 문화 정착을 위한 노력
- 애자일 툴 제작 업체 섭외 및 도입 회의 진행
- 개발자 대상 툴 테스트 요청
- 커스터마이징을 위한 개발자 의견수렴 등
이런 과정으로 진행되는 프로젝트는 겉보기에는 정상적이고 체계적인 업무절차로 보이니 임원 보고용으로는 제격일 수 있습니다. 물론 몇몇 의지가 강한 팀장이 이끄는 팀에서는 어설프지만 기획팀의 의도에 맞춰 개발방식의 변화를 시도하기도 합니다. 그럼에도 불구하고 마음처럼 조직 전체로 활성화되지 못하고, 팀마다 적용하는 방식도 제각각이 되기 일쑤입니다.
임원들의 막연한 이상주의에서 시작된 ‘애자일 도입 프로젝트’가 흐지부지되는 것은 어쩌면 당연한 결과일 수 있습니다. 위에서 진행된 절차에는 아주 중요한 노력이 결여돼있기 때문입니다. 무엇이든 변화하기 위해서는 기존 방식 및 문제점을 정확히 인지해야 하고, 이를 바탕으로 구성원이 명확한 목표의식을 공유할 필요가 있습니다. 하지만 애석하게도 기업에서 기존의 방식을 명확히 정의하고 있는 경우는 거의 없으므로, 실무진들은 애자일에 대해 파악하기 전에 기존의 프로세스를 단계별로 정의하는 지루한 노력을 먼저 기울여야 합니다.
많은 기업의 리더들은 자신들의 기존 개발 방법론이 ‘폭포수 방법론’이라고 이야기합니다. 즉, 요구사항 정의부터 개발, 유지보수까지 전 단계의 완료 후 다음 단계가 진행된다고 이야기하는 것입니다. 반면에 실제 개발을 하는 개발자들은 이 얘기를 공감하지 못하는 경우가 많습니다. 개발 도중 요구사항이 변경, 추가되는 경우가 비일비재하고, 테스트 단계에서 설계가 변경되는 경우도 많기 때문입니다.
이처럼 사실상 기업에서 명확한 개발 방법론이 존재하는 경우는 드뭅니다. 그렇기 때문에 기업의 임직원은 덜 체계적인 상태에서 일하고 있다는 불편한 사실과 마주할 용기를 내야 합니다. 현재 기업의 일하는 방식을 단계별로 정의하고 문제점을 도출하는 것은 상당히 불편하지만 꼭 해야 할 일이며, 단순히 임원 보고용으로 조사해서는 안됩니다.
임원은 조사 결과가 "우리는 ‘OO방법론’을 사용합니다."라고 명확하기를 바라겠지만, 앞서 얘기한 것처럼 많은 기업의 개발 프로세스는 방법론으로 명명할 만큼 체계적이지 못합니다. 그러니 이런 불편한 사실을 인정하고, 단지 기존 프로세스를 세분화해서 분석하고 실용적으로 변화시키기 위한 고민을 해야 합니다. 애자일에 끼워 맞춰 모든 프로세스를 재정의하는 '변화를 위한 변화'는 지양해야 하며, 그저 조직 구성원들이 자연스럽게 받아들일 수 있을만한 단계적 프로세스 프로세스 개선을 목표에 둬야 할 것입니다.
"현업과 IT는 협업하도록 교육받지 않았다"
애자일 방법론이 전제하는 것은 현업과 IT가 함께 근무하며 요구사항을 빠르게 반영하는 것입니다. 하지만 많은 기업에서 현업은 IT 개발 프로세스에 참여하는 것을 주 업무로 생각하도록 교육받지 않으며, 개발자 또한 현업과 함께 근무하면 회의가 늘어난다는 부정적 인식을 가지는 경우가 많습니다.
이러한 기업의 특성은 평소 운영에는 큰 문제점이 되지 않을 수 있으나, 새로운 개발 문화 정착에 장애물로는 1등 공신이 될 수 있습니다. 기존 방식 변화에는 언제나 일정량의 관성이 작용하기 마련이고, 그 기간에 인내심을 가지고 직원들이 합심하여 노력했을 때 기업의 문화로 정착될 수 있습니다. 하지만 애자일 방법론 도입으로 인해 얻을 수 있는 효용을 체감하지 못하는 상황에서의 변화 시도는 추가적인 업무 부담으로 느껴질 수 있고, 기존 기업이 애자일을 정착시키기 위한 기간은 임원들이 기대하는 것보다 훨씬 길어질 것입니다. 대부분은 임직원 모두 이 과도기를 견디지 못하며 그 기간이 길어질수록, 그리고 임직원이 타성에 젖어있는 정도가 심할수록 기존 방식으로 돌아가게 될 가능성이 높아집니다.
이런 문제점을 해결하려면 변화를 기획할 때, IT뿐만 아니라 임직원 모두의 인식 변화를 목표로 해야 합니다. 그 과정은 쉽지 않을 것이고, 어떤 기업에서는 불가능할 수 도 있을 것입니다. 이런 기업의 IT는 내부에서조차 서비스를 제공하는 입장으로 인식되는 경우가 많고, 임직원들은 이런 인식을 변화시키려는 노력을 거의 하지 않아왔을 가능성이 큽니다. 그런 만큼 수직적인 명령에 의한 변화가 아니라, 충분한 공감대 형성을 통한 기업문화 변화를 인내심 있게 추진할 필요가 있다고 생각합니다.
"대부분의 개발자는 레거시 시스템의 유지보수 인력이다"
IT 대기업이 아니고서야 대부분 기업의 IT인력은 레거시 시스템을 유지 보수하는 역할을 할 것입니다. 이런 개발자들에게 애자일 방법론을 적용하는 등의 대대적인 방법론 변화는 너무 거창한 일로 느껴질 수 있습니다. 흔히 볼 수 있는 애자일 적용사례는 신규 서비스의 릴리즈와 관련돼 있으므로 기획하는 입장에서도 유지보수 조직에 애자일을 적용하는 것을 크게 공감하지 못한 상태에서 기획하는 것도 비난할 수는 없습니다.
그래서 어떤 조직은 유지보수 업무에서는 기존 방식을 고수하고, 해당 팀에 신규 개발 건이 생길 때 애자일 방법론을 사용하도록 가이드를 내립니다. 하지만 평소 애자일에 익숙하지 않은 개발자가 신규 프로젝트에 애자일을 적절히 적용할 것이라는 기대부터가 잘못된 가정입니다. 그리고 위에서 언급한 것처럼 애자일은 개발자뿐만 아니라 현업 또한 공감대를 형성하고 참여해야 하는 만큼, 평소 사용하지 않았다면 더욱 힘든 일이 될 것입니다.
이렇게 대부분의 개발이 유지보수 성격의 업무라면, 오히려 근본적인 질문이 필요해 보입니다.
“정말 새로운 방법론의 적용이 필요한가?”
임원의 성과 욕심에 의해 추진되는 변화가 아니라 진짜 방법론의 변화가 필요한지를 질문할 용기가 필요하며, 이를 성역 없이 논의할 필요가 있는 것이니다.
"애자일 방법론 vs 직장생활 방법론"
위에서 언급한 문제들이 해결돼서 현업과 개발자가 빠르게 요구사항을 협의하면서 개발을 진행했다고 가정해보겠습니다. 그런데 중간 또는 최종 결정 단계에서 상사가 탐탁지 않아한다면? 그리고 현업과 개발자는 상사를 설득해 본인들의 생각을 관철할 용기가 부족하다면?
이 문제는 위의 문제들보다는 좀 더 근본적인 기업문화에서 기인합니다. 애자일은 태생적으로 수평적이며 민첩한 의사결정을 전제로 하고 있지만, 한국의 기업들은 태생적으로 수직적인 조직문화를 가지고 있습니다. IT 중심의 조직이 아니라면(IT 중심의 조직도 마찬가지일 수 있지만...) IT의 방법론을 혁신하는 것보다는 리더의 결정을 고수하는 것이 더 중요한 가치가 될 수 있고, 그런 경우 직원들은 애자일 방법론 적용에 회의감만 커질 수 있습니다.
애자일 방법론을 적용하겠다는 기업의 IT리더들이 수평적 문화를 확산시키지 않은 상태에서 애자일을 시도하는 것은 근본적인 문제 해결 없이 겉치장만 하는 꼴이 될 수 있고, 결국 업무 프로세스의 혼란만 가중하는 결과를 낳을 수 있습니다.
"기업 문화의 핵심은 내부 직원이다"
국내의 많은 대기업은 SI업체를 통해 IT 개발 프로젝트를 진행하며, 이런 개발인력은 정해진 개발 기간이 끝나면 대부분 철수하고 기존 인력의 유지보수를 통해 운영됩니다. 지금 언급하려는 문제는 이런 개발 프로세스로부터 발생할 수 있습니다. 애자일 방법론은 단순한 개발 방법론을 넘어서 그 기업의 개발 문화라고 할 수 있습니다. 즉, 모든 기업이 동일하지 않으며, 평소 직원들의 긴밀한 협의 끝에 정착되는 프로세스입니다. 하지만 외부 업체를 통해 개발을 진행하는 경우 그 기업 나름의 프로세스와 충돌이 있을 수밖에 없고, 그런 프로젝트가 빈번하다면 나름의 애자일 방법론을 정착시키는 것은 무리일 것입니다.
이런 문제는 근본적으로 기업의 개발인력이 유지보수인력으로 남게 하는 요인이 되기 때문에 앞서 말한 유지보수 업무에서의 동기부여 부족 문제가 발생하는 악순환이 될 수 있습니다. 물론 많은 기업에서 SI, SM 등 외부 업체를 통한 개발을 안 할 수는 없습니다. 하지만 내부 인력으로도 충분히 가능한 상태에서 일정상의 문제 등으로 외부업체와 협업하는 것과 내부 인력 자체가 부족하여 외부업체 위주로 프로젝트를 진행하는 것은 질적으로 큰 차이가 있습니다. 진정한 디지털 트랜스포메이션을 전략으로 하기 위해서는 내부 인력 확보 및 육성이 가장 큰 과제일 수 있다고 생각합니다.
지금까지 개인적인 관찰 및 고민을 통해서 애자일 방법론이 정착되지 않는 이유를 정리해봤습니다. 물론 많은 요인 중 일부일 것이고, 수많은 기업 중 일부에 해당하는 이야기일 수 있다고 생각합니다. 이 글에 대한 이견이나, 다른 사례들을 댓글로 공유해주시면 좋은 토론 주제가 되지 않을까 생각합니다.
