8장. 애자일팀의 지속적인 개선#5

#8-5 대규모 애자일팀을 위한 애자일 선언의 진화

#8-5 대규모 애자일 선언의 진화 

하지만 궁금증이 여전히 해소되지 않는 것이 있었다. 대형 프로젝트에서 애자일 방식으로 일할 수 있는지에 대한 것이었다. 몇몇 사람들은 여전히 "결국 애자일은 작은 프로젝트에만 사용할 수 있는 게 아닌가?"라는 의문점을 가지고 있었다. 과거 대형 프로젝트에서 몇 차례 애자일을 써보려다 문제가 됐던 사례는 생각보다 깊숙이 사람들의 머릿속에 박혀 있었다. 

ACT가 처음에 수행했던 20개의 프로젝트는 대부분 20명 안쪽의 3~4개월 정도 제품을 만드는 프로젝트였다. 사람들이 이야기하는 대형 프로젝트라 함은 개발 기간이 1년~2년 정도 되는 100~300명의 개발자가 동시에 들어가서 개발하는 형태의 큰 규모를 가진 프로젝트였다. 

5장 1절 에서 다룬 마틴 파울러의 글 '범위를 유연하게 만들기(Scoping limbering)'처럼 크게 계약하지 말고 작은 모듈에 대해 고정 가격계약으로 계약하여 장기적으로 함께 일할 수 있는 구조를 만들어야 한다라고 외치긴 했지만, 회사가 얻고 싶은 매출 목표와 치열한 입찰 경쟁에서 이는 쉬운 방법이 아니었다. 

마틴 파울러의 방식은 영업에게 1000억의 매출 대신에 10억짜리를 먼저 고정 가격으로 해보자고 고객에게 이야기하는 방식을 제안하라는 것이었다. 이를 성취해내기 위해서는 고객과 정말 좋은 신뢰관계를 가지고 일할 수 있어야 했다. 또한 기업의 매출 목표 달성에 큰 도움을 줄 수 있는 프로젝트를 내년을 위해 포기하라는 말로 받아들여졌다. 

"과연, 시작부터 애자일 팀으로 대형 프로젝트를 소화할 수 있는 방법은 무엇일까? 그런 방법이 있긴 한 것일까?"

위의 질문들은, 필자가 1장에서 언급했던 XP2007에 참석했을 때 많은 참석자들에게 들었던 질문과 동일한 것이다. 당시 애자일은 대형 프로젝트에 적용할 수 없다는 의견이 시장에 지배적이었고, 실제 애자일을 한다는 사람조차 대형 프로젝트에서의 애자일 방식에 대해서는 회의적인 경우가 많았다.

애자일은 작은 팀을 위한 방법론이라고 회자되는 가장 큰 이유는, '01년 “애자일 선언”이 만들어질 때 애자일의 기원 자체가 작은 팀을 중심으로 일하는 프로세스에서 기초되었기 때문이었다. 스크럼, XP, 린 S/W 개발 등은 7~9명 단위의 작은 팀을 기반으로 설명되어 있었고, 이 인원으로 최고의 생산성과 품질을 낼 수 있다 라고 언급하였다. 그나마 스크럼 프로세스 정도가 여러 스크럼 팀으로 확장될 때 작은 팀들을 여러 개 만들고 이를 스크럼의 스크럼이라는 형태의 회의로 이슈를 해결하면 된다라는 확장에 대한 고민을 담았다.

하지만 심지어 스크럼 조차도 개발 외에 요구사항을 받는 방법이라던지, 릴리즈의 구체적인 방법에 대한 언급은 없었기 때문에, 규모가 큰 프로젝트에서 적용하는 데는 제약이 있다는 생각들이 많았다.

그 때문이었을까… 십 년 이상 동안 대형 프로젝트에서 애자일을 활용하는 극복의 과정은 꽤나 고통스러웠다.

작은 팀 위주에 초점을 맞추던 기존의 프랙티스에서 벗어나 대형 프로젝트에 맞게 일부 변경된 시도를 하던 사람들에게는 많은 비난이 쏟아졌다. 이전의 오리진(Origin)을 버리는 것이라 비난하는 이도 많았고 조금이라도 문서화에 초점을 맞추면 “이건 애자일이 아냐”라고 비난하는 사람들이 생겨났다. “무늬만 애자일”, “하이브리드”, “미니 워터폴” 등 다양한 용어들로 변형된 프로세스에 대해 부정적이었다.

하지만, 이에 대한 변화는 결국 시장이 주도하게 되는데, 기존 프로세스에 대한 불만과 클라우드로 전환하는 시장의 흐름에 따라, 애자일의 확산 니즈는 점점 커졌다. 이와 함께 애자일 또한 일반화/정형화/대중화되기 위한 움직임들이 나타났다. 그리고 다양한 조직의 더 많은 사람들이 애자일 방식을 기반으로 한 나름대로의 프로세스를 만들어 나갔다. 기존의 한계를 극복하며 현실적인 접근을 시도했던 것이다.

우선 대표적으로 공통적으로 활용할 수 있는 엔터프라이즈 애자일을 위한 프로세스들이 생겨났다. 이의 대표적인 프로세스가 DaD(Disciplined Agile development), SAFe(Scaled Agile framework), LeSS(Large Scaled Scrum), Nexus 등이다. 심지어 SAFe는 미국 정부를 비롯하여 애자일을 하는 회사의 30% 이상이 활용할 정도로 큰 인기를 얻고 있는 애자일 프로세스이다.

SAFe(Scaled Agile Framework):150명 이상의 Portfolio 관리가 필요한 대형 애자일 방식

LESS(Large Scaled Scrum): MAX 80명 애자일 조직을 대상으로 수행하는 대형 스크럼 방식

Nexus: 스크럼을 확장한 5~8개의 스크럼팀이 활용할 수 있는 대형 스크럼 방식

마찬가지로 각 회사들마다 회사 나름대로의 문화와 현실을 엮어 보다 적합한 형태의 엔터프라이즈 애자일 방식을 내놓고 있다. 가장 대표적인 프로세스는 세일즈포스(Salesforces)의 ADM(Adaptive delivery Methodology), IBM의 이클립스 웨이(eclipse way) 등이 있다. 

IBM의 이클립스 웨이

이러한 프로세스들은 기존의 도그마(Dogma: 독단적인 학설, 이성적으로 증명되지 않은 가설)라고 이야기되던 순수 애자일 추구에서 벗어나 현실 속에서 기존 문화와 다양한 프랙티스들을 섞는 것을 시도하는 내용들이 담겨 있었다. 시장 상황, 이해관계자들의 일해오던 방식 등을 일부 존중하면서, 애자일 방식을 통해 가치를 얻을 수 있는 중간 단계의 무엇인가를 찾는 노력들의 결과물이었다. 

이제는, 디자인 싱킹으로 대표되는 디자인 방식의 변화, 린스타트업으로 대표되는 스타트업 바람이 더해져 바탕으로 이제는 소프트웨어 회사의 94% 이상이 본인들은 애자일을 하는 회사라 말하고 있다. 전체적으로 스펙트럼이 소/중/대형을 넘나드는 애자일 방식들이 생겨나게 된 내용은 지금까지 설명한 바와 같다.

그렇다면 과거의 소규모를 향한 애자일과 중/대형 사업의 애자일과의 구체적인 차이는 무엇일까? 현실과 맞물린 일하는 방법이란 과연 무엇일까? 이를 효과적으로 설명하려면 2001년의 애자일 선언을 다시 한번 재조명하는 것이 필요하다.

과거 작은 팀을 중심으로 진행하는 애자일 방식은 오른쪽 노란색 부분은 마치 금기처럼 인정하지 않음을 넘어 무시하는 분위기가 강했다. 그래서 조금이라도 오른쪽에 접근하는 것을 경계했다. 하지만 현실과 맞물리며 왼쪽보다는 확실히 덜 중요하나 오른쪽 부분 또한 중요하다는 인식으로 발전되어 갔다. 이를 설명하면 다음과 같다.  

* 공정과 도구보다 개인과 상호작용을: 

대규모 프로젝트에서 개인과 상호작용만 강조하면, 두 개 이상의 팀이 되었을 때 효과적인 커뮤니케이션을 하기 힘들다. 때문에 툴을 사용하는 것이 좋다  

* 포괄적인 문서보다 작동하는 소프트웨어를: 

동작하는 소프트웨어에 집중하면 팀 내에서는 진행상황에 대해 잘 이해할 수 있으나 두 개 이상의 팀이 되었을 때 서로의 진행사항을 확인하기 어렵다. 애자일팀들이 아주 쉽게 말하는 “우리 팀에 와서 언제든 제품을 보세요”라는 말은 두 팀 이상을 관장하는 관리자에게는 눈살을 찌푸리게 만드는 대화가 될 수도 있다. 때문에 적당한 문서화는 커뮤니케이션에 도움이 될 수 있다.  

* 계약 협상보다 고객과의 협력을:

고객과의 협업만 강조하면 다양한 이해관계자를 모두 포용하지 못할 수 있다. 때문에 계약과 협상을 통해 전체 이해관계자와 동일한 비전/생각을 갖으며 일을 해야 한다.  

* 계획을 따르기보다 변화에 대응하기를: 

상황에 따라 변화를 하는 것은 중요하지만, 주변 팀에 이야기하지 않으면 두 팀 이상이 될 경우 의존관계를 무시하게 되어 고객의 비즈니스 가치를 늦게 딜리버리 하는 상황을 만날 수 있다.  함께 공감하는 계획은 반드시 있어야 하고 여러 팀들이 존중해야 한다. 물론 함께 합의하여 계획을 변경하는 것은 필요하다.  

혹시나 대형 프로젝트, 대규모 조직에서 애자일을 적용하다 현실의 벽에 부딪혀 고민하고 있는 독자가 있었다면 위 이야기를 듣고 반가운 생각이 들 수 있다. 하지만, 다시 한번 강조하여 이야기하고 싶다. 개인과 상호작용, 동작하는 소프트웨어, 고객과의 협업, 상황에 따른 변화가 여전히 더 중요하다. 그래야 애자일 방식이다.

필자가 몸담고 있는 회사 또한 위와 비슷한 과정을 겪었다. 하지만 프로세스 자체를 공개하여 이야기할 수 없기에 대신에 비슷한 형태로 프로젝트를 수행하는 해외 사례 한 가지를 이야기해보고자 한다. 아래 이야기는 필자가 실제 그 팀 리더들에게 들은 이야기다. 

------------------------------------

P사의 C 소프트웨어 개발팀은 기존의 솔루션을 새로운 것으로 탈바꿈하기 위해 다음과 같은 극단적인 방법을 썼다. 이전부터 많은 고객들이 사용하던  V라는 온프라미스와 SaaS 두 가지 형태로 제공하는 제품은 100명이 데밥스 환경에서 거의 10년 동안 개발 및 유지 보수하던 것이었다. 

늘 여러 고객으로부터 오는 납기에 압박받으면서, 어느 날인가부터 기술적인 부채가 많아지고, 소스코드는 점점 스파게티가 되어갔다. 심지어, 일부라도 수정이 필요할 때 시스템적 의존성이 많아 어디에서 오류가 날 지 확인이 불가능한 상황까지 일어났다. 이쯤 되고 보니, 점점 고객들의 피드백을 업데이트하는 속도가 늦어지고, 고객들은 불만을 토로했다. 큰 의사결정을 통해 제품 라인을 없앨 수도 없었다. 이미 많은 고객들이 사용하고 있었기 때문이다. 

P사는 이 문제를 극복하고 경쟁력을 다시 찾고자 CEO에 의해 중대한 결정을 한다. 이 솔루션을 처음부터 좋은 소스코드 베이스로 다시 만드는 것이었다. 이를 위해 다음과 같은 방식으로 팀을 만들고 키워나갔다. 

초기 인력 구성은 다소 극단적인 방식으로 정리했다. 좋은 기법으로 개발할 개발자가 필요하다는 판단에, 우선 100명의 인력 중에 업무 도메인에 핵심 전문가인 기획자들과 핵심 개발자들 20명 정도만 남기고 나머지 인원은 타 부서로 전배 시켰다. 그리고 애자일 기법에 충실한 개발자들을 동수로 투입시킨다. 40명의 인원은 4개의 팀으로 나누고, 이 팀들의 기획자들은 긴밀히 협업하여 가장 이 솔루션이 수행해야 할 중요 시나리오를 기반으로 놓고 함께 개발했다. 4개의 팀으로 나누었을 때 각 팀은 각각 다른 소스코드 레파지터리와 다른 데이터베이스를 활용했다.

독립적으로 배포가 가능한 시스템을 만든 것이다. 각각 배포 파이프라인을 구축하여 개발, 스테이징, 프로덕션 단계로 자동 빌드가 가능하도록 했다. 이 방식의 기반은 짝 프로그래밍과 테스트 주도 개발이었다. 이를 통해 탄탄한 소스코드의 품질을 구축했다. 이들은 짝 프로그래밍과 테스트 코드를 읽는 방식으로 쉽고 빠르게 업무를 파악해 나갔다. 각 개발자가 개발한 내용에 오류가 있을 때는 이전에 작성해둔 테스트 코드가 자동으로 찾아주었다. 

[P사의 C 소프트웨어 개발팀]

그리고 3개월 정도 지나 팀이 일하는 방법이 안정되자 추가 인력을 투입한다. 팀 별로 5명 정도의 애자일 개발자들을 투입했다. 그리고 팀이 10명이 넘으면 이전과 마찬가지로 팀과 모듈을 쪼개 나갔다. 각각의 모듈은 독립적인 배포가 가능하도록 환경을 구축했다. 이러한 방식을 여러 차례 거쳐 팀을 분할하여 소프트웨어 개발팀은 계속해서 확장된다. 3년이 지난 당시 250명의 인력이 한 시스템을 구축하는 형태로 자리 잡았다. 하지만 이는 엄밀히 말하면 12개의 다른 시스템을 독립적으로 개발하는 것과 동일했다. 

점점 팀이 커지면서, 새로운 역할자가 필요하게 되었다. 각 팀의 부분 부분이 조합되어 만들어지는 전체의 큰 시나리오 흐름을 관장하면서, 개발할 기능에 대해 우선순위 화하고 팀들 사이의 기능들을 조율해줄 수 있는 사람이 필요했다. 또한 여러 모듈들을 개발하고 있는 팀들이 자신들의 개발에 집중하고 있을 때, 전체적인 아키텍처 관점에서 성능에 대하여 좀 더 고민하고 더 나은 기술적 제안을 해줄 수 있는 사람이 필요했다. 이들은 각각 프로그램 매니저와 테크니컬 아키텍트라고 불렀다. 

이러한 역할자는 처음 4개의 팀일 때는 크게 필요하지 않았다. 필요한 협업이 있으면 기획자 또는 개발자가 함께 만나 이야기하면 되었다. 하지만, 팀의 수가 5개로 늘어나면서 커뮤니케이션을 효율화하기 위해 반드시 필요한 역할자가 되었다. 또한 독립적인 모듈의 숫자가 늘어나면서 기술적인 문제도 늘어났다. 이 때문에 250명 팀 안에는 현재 5명의 프로그램 매니저와 7명의 테크니컬 아키텍트가 있었다. 그리고, 현재까지 이러한 체계를 유지하며, 전 세계적으로 수많은 사용자가 있는 제품을 만들고 유지하고 있다. 

------------------------------------

위의 이야기를 읽으면서, 여러분에게 떠오르는 단어가 있는가? 그렇다 위의 팀은 마이크로 서비스 아키텍처라는 것을 기반으로 일하는 팀이다. 

Wix.com의 엔지니어링 수장인 아비란 모르도는 잭스 엔터(Jaxenter)와의 인터뷰에서 자신들의 시스템을 마이크로 서비스 아키텍처로 구성한 것에 대해 다음과 같이 이야기했다.

"우리는 마이크로 서비스 아키텍처를 쓰려고 계획하지는 않았다. 이는 우리의 시스템이 자연스럽게 진화한 형태이다. 2010년에 우리가 이 시스템을 구축했을 때는 "마이크 서비스"라는 말이 존재하지도 않았다. 너무 많은 엔지니어가 '모노리스' 시스템을 사용해서 수많은 의존성과 안정성 이슈가 있었다. 시스템을 더 크게 성장시키기 위해 어쩔 수 없이 선택했다. 큰 '모노리스' 시스템을 쪼개 작은 서비스들로 나누면서 우리의 소프트웨어 릴리즈 주기는 매우 빨라졌다. 마이크로 서비스는 데밥스 문화와 지속적인 딜리버리 두 가지의 엔지니어링 기법이 한꺼번에 녹아든 방식이다." 

데밥스 문화와 지속적인 딜리버리가 한꺼번에 녹아든 방식이란 개발팀과 운영팀이 합쳐져 클라우드에서 지속적이고 독립적으로 배포될 수 있는 서비스들의 집합으로 기본적으로 애자일 개발 방식이 기본이 된 방식이다. 과거라면, 그가 했던 이야기가 이상적인 내용으로 느껴질 수 있겠으나, 1년 이상의 협업 기간 동안 애자일 방식 개발 방식은 꽤나 유연하게 개발할 수 있는 인력들이 다수 생겨났다. 

또한 P사의 C 소프트웨어 개발팀과 마찬가지의 문제를 안고 있는 상황은 조직 내 여러 곳에 있었다. ACT는 이러한 문제에 대해 비슷한 접근 방식으로 대형 프로젝트의 애자일 방식을 적용하고 있다.