애자일(Agile)은 이제 IT업계의 핵심 프로세스로 자리 잡았습니다. 다양한 이슈에 빠르게 대응할 수 있다는 장점 때문인데요.
그런데, 이러한 이유 때문에 대부분 사람들이 애자일을 단순히 빠르다고만 인식하기도 합니다. 하지만, 이러한 생각은 굉장히 위험합니다.
이런 위험한 생각을 막기 위해서는 결국 다시 애자일의 기본부터 살펴볼 필요가 있다 생각합니다. 무엇이든 기본이 탄탄하게 잡힐수록 좋기 때문에 이번 글에서는 애자일에 대한 기본적이고, 본질적인 이야기를 해보려 합니다.
애자일 선언
우선, 애자일의 기본인 애자일 선언을 천천히 살펴봅시다
1 | Individuals and interactions over processes and tools
개인, 상호작용 > 프로세스, 도구
2 | Working software over comprehensive documentation
소프트웨어 > 복잡한 서류
3 | Customer collaboration over contract negotiation
고객 협업 > 계약, 협상
4 | Responding to change over following a plan
변화에 대한 대응 > 계획
애자일을 단순히 빠르다고만 인식하는 것은 애자일 선언 4가지를 담기에 충분하지 않습니다. 개인을 도구에 우선시하고, 복잡한 서류를 작성하지 않으며, 계약보다는 협업을 중심으로 하며, 모든 것을 계획하는 것보다 변화에 대한 대응을 더 중요하게 생각하는 것입니다.
기존 금융권과 비교하여 핀테크 기업이 가지는 이미지를 떠올리면 좀 더 쉽게 이해하실 수 있을 겁니다.
애자일 vs. 워터폴
애자일의 반대 방법은 그럼 무엇일까요?
워터폴(Waterfall)입니다. 계획적으로 진행하는 것을 폭포처럼 위에서부터 쏟아진다는 것으로 비유한 것입니다.
워터폴도 다양한 방법론이 있지만, 그 중 한가지 방법론을 살펴보면 요구사항 > 분석 > 디자인 > 개발 > 테스트 > 유지 순으로 되어 있습니다. 이 과정을 계획에 맞춰 수행하는 것을 워터폴이라 합니다.
애자일이 진행속도가 빠른 개발 환경에서 잘 적용되는데 반해 워터폴은 변수가 적은 환경에서 정해진 절차에 맞게 진행하는 것에 잘 맞습니다.
애자일과 워터폴은 무엇이 좋다 하는 것이 없습니다. 프로젝트 환경에 맞게 적절한 방법론을 선택해야 합니다.
애자일 방법론
애자일과 워터폴을 살펴보았으니 이제 애자일의 다양한 방법론을 한번 볼까요?
애자일도 하나의 방법만 있는 것은 아닙니다.
eXtreme Programming(XP), Scrum, Lean Software Development, DevOps.
모두 애자일의 방법인데요. 이 중 애자일 프로젝트 관리에 자주 사용되는 스크럼(Scrum)을 한번 알아보고자 합니다. 스크럼은 반복적인 개발 관리에 초점을 맞춘 방법입니다. 흔히 반복적으로 진행되는 주기를 스프린트(Sprint)라고 하는데요.
계속해서 스프린트 주기대로 돌아가는 방식입니다. Product Backlog > Sprint Planning Meeting > Sprint Backlog > Sprint > Finished Work 순으로 진행됩니다.
여기서 핵심은 스프린트인데요. 이 단계에서는 세분화된 항목에 초점을 맞추고 1~4주 정도의 기간을 거쳐 진행됩니다. 스크럼의 핵심인 스크럼 마스터(Scrum Master)는 개발자들이 외부 다른 환경에 방해받지 않고 개발에 집중하도록 만들어주는 역할을 수행하게 됩니다.
은행, 애자일에 스며들다
고객과의 접점이 많은 은행의 경우는 애자일의 필요성이 대두되고 있습니다. 다만, 보수적인 금융권에서 조직의 특성을 바꾸기는 쉽지 않죠. 그럼에도 디지털 전환(DT)의 일환으로 애자일 조직 변화를 서두르고 있습니다.
우리은행은 ACT(Agile Core Team), 국민은행은 ACE(Agile Centrific Efficient), 하나은행은 셀(Cell) 조직을 도입하는 등 이름은 다르지만, 각자 애자일 방식을 도입하기 위해 애쓰고 있습니다.
Summary
애자일을 단순히 빠르다고만 인식하면 안 됩니다. 애자일 선언에서는 워터폴과 비교해 애자일이 무엇을 중시하고 있는지 보여주고 있는데요. 기본적이고 당연한 이야기지만 새겨둘 필요가 있습니다.
다만, 애자일이 무조건 좋다는 것은 아닙니다. 조직과 프로젝트의 상황에 맞게 적절한 프로젝트 방법론을 사용할 필요가 있습니다.