애자일이 모두에게 좋은 게 맞는 걸까?
이 세상에 절대반지는 없습니다.
2001년도에 애자일 선언이 있은 후, 벌써 20년도 더 넘은 시간이 흘렀습니다. 일을 더 효과적으로 진행하자라는 측면에서 야기된 개념인 애자일(Agile)은 초기에는 소프트웨어 프로세스에서 주로 사용되었지만 지금은 여러 업계에서 그 개념을 확장하고 있습니다.
소프트웨어 공학에서는 개발 프로세스 중 하나로 애자일 방법론을 소개하며 늘 워터폴(Waterfall) 방식과 비교를 하며 더 빠른 결과물을 이끌어낼 수 있는 방법이라고 말하고 있습니다.
IT업계를 들어와 애자일에 대한 수많은 이야기를 들었습니다. 스프린트(Sprint) 단위로 일을 하거나 스크럼, 칸반 보드를 활용하고 진행한 일에 대해 회고를 수행하며 다음 할 일을 서로 확인하며 진행하는 이 형태. 변화가 많고 속도가 빠른 업계가 이에 대한 기민한 대응을 하기 위해 적절하고 시시각각 변하는 고객들의 피드백을 빠르게 수집하여 시장의 니즈(Needs)를 알아챌 수 있다는 장점을 이야기합니다.
그래서 저는 애자일의 형태를 따라 하면 더 나은 형태의 작업물이 나온다고 생각하게 되었습니다. 아니, 애자일 프로세스가 다른 어떤 프로세스보다 훨씬 좋은 것이라고 생각했습니다. 심지어 한국에서 애자일 프로세스가 정착이 잘 안 되는 이유는 그 방법론의 문제가 아니라 문화의 차이이기 때문에 문화를 받아들일 수 있는 마인드셋(Mindset)도 정착이 되어 있어야 한다는 이야기도 들었습니다. 우리가 애자일을 잘 받아들일 수 있는 준비가 되어야만 생각의 전환이 쉽게 일어날 수 있고 그래야 애자일에 대한 문화 정착이 이뤄진다는 말이었습니다. 결국 우리의 업무가 힘든 형태는 변화하고자 하는 마음이 정착되지 않아서라는 이야기인 걸까 하고도 생각해 보았습니다.
그런데 최근에 애자일이 모두에게 좋은 게 맞는 걸까?라는 생각이 들기 시작헀습니다. 저는 모든 것에는 장점과 단점이 있다고 생각합니다. 프로세스도 마찬가지라고 생각합니다. 어떤 프로세스는 제조업에 맞지만 그 프로세스는 게임 업계에서는 맞지 않을 수 있습니다.
시기도 마찬가지입니다. 과거에 비해 우리의 기술은 너무나도 달라졌습니다. 20년이라는 시간 안에는 SNS 등이 활발해지며 사람들의 관계가 더 긴밀해졌고 생성형 AI가 등장하며 우리의 일하는 패턴도 달라지고 있습니다. 과거에는 여러 사람이 논의하면서 적합한 방법을 찾아내곤 했지만 지금은 여러 사람들이 학습시킨 하나의 AI와 토의를 하며 나은 답안을 찾아내곤 합니다.
사람들의 생각도 과거에 비해 많은 차이를 갖고 있습니다. 과거에는 경력이 오르면서 그에 수반하는 경험과 지식이 쌓여갔지만 지금은 경력에 비례하여 올라가지 않습니다. 새로운 지식이 출현하는 시기가 과거에 비해 더 빠른 속도로 나타나고 사람들의 사회적 인식도 과거와도 많이 달라졌습니다.
그래서 과거의 기준에서 세워진 프로세스에 계속 맞춰서 보는 게 나은 걸까라는 생각이 들게 되었습니다.
실제 애자일을 겪어가며 일을 진행해 보니 꼭 좋은 부분만이 있는 것은 아니었습니다. 우선 너무 커져있는 회사는 애자일의 형태가 이상적으로 작동하지 않았습니다. 새로운 영역의 업무가 들어올 때마다 기존의 목적 조직 형태로 운영되는 구조에서는 업무의 R&R이 정의되지 않아 혼란스러워하는 모습을 볼 수 있었습니다.
또, 업무의 우선순위 정의 등을 핑계로 진행되지 않는 일의 모습들도 많이 보게 되었습니다. 심지어는 애자일을 표방했을 뿐, 실제로는 워터폴 방식으로 진행되지 모습들도 많이 보게 되었습니다. 그 결과, 누군가에게는 애자일이 좋지 않은 것으로 될 수 있었고 일을 더 진행하지 못하게 하는 제약이 되기도 했습니다.
애자일 선언은 소프트웨어 개발의 효율을 이끌어내기 위해 어떤 가치의 우선순위를 두어야 하는지를 명심하자는 측면에서 만들어졌다고 생각합니다. 그리고 그 가치를 기준으로 내 업무를 진행해 혼란을 없애 업무에 집중할 수 있게 하여 결과적으로는 각자가 만족할 수 있는 수준의 제품을 만드는데 도움을 주었다고 봅니다. 즉, 일이 잘 되게 하고자 하는 것이 이 선언의 핵심이라고 생각합니다.
PMBOK 7판에서는 하이브리드 형태의 방법론을 이야기합니다. 워터폴과 애자일을 합친 형태의 프로세스를 소개하며 변화된 프로세스를 적용하는 형태도 고려해 보라고 소개합니다. 물론 기존의 두 프로세스가 나쁘다고도 말하지 않습니다. 모든 프로젝트는 저마다의 관리 형태에 장단점이 있고 꼭 한 가지 형태에 국한될 필요가 없기 때문입니다. 애자일에 대해 많이 공부를 해본 사람들도 방법론에 대해서는 스크럼이나 칸반 같은 정례화된 방법이 정답이라고 생각하지 않는다고 합니다. 방법론은 셀 수 없이 많은 게 맞고 그 기준은 그 방법론을 적용할 도메인이 기준이 된다고 말합니다. 즉, 어떤 업계에서 어떤 업무를 하느냐에 따라 애자일은 적절할 수도 혹은 적절하지 않을 수도 있습니다.
그리고 외부에서 소개하는 모든 형태를 그대로 사용해야 하는지 마는지는 실제 그 업을 담당하시는 분께서 판단해야만 합니다. 사람과 사람이 모두 다르듯이 사람들의 모임인 조직, 회사도 회사마다 그리고 그 내부의 조직마다 모두 다릅니다. 그래서 조직의 형태와 업무의 형태를 빠르게 파악하고 어떤 형태의 방법론을 사용하는 게 맞을지 스스로 찾아보고 결정을 내려야 합니다.
저는 사람들이 애자일을 마법의 단어로 생각하지 않았으면 합니다. 애자일은 그저 하나의 단어일 뿐입니다. 사람들이 애자일을 하고자 하는 이유는 일이 더 잘되었으면 하는 바람에서 시작되는 것이라고 생각합니다. 그래서 그 본질을 잘 이해하고 일이 더 잘 되기 위해 무엇을 해야 할지를 알아가는 것이 애자일을 적용하는 것보다 먼저라고 생각합니다.
우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다.
애자일 선언문에서 알 수 있듯, 나와 팀이 함께 일할 때 우리에게 더 좋은 방법이 무엇인지를 찾아가는 것이 우선입니다. 그래야 나의 팀에 더 적절한 방법이 무엇인지를 알 수 있기 때문입니다.
