9장. 애자일의 미래#3
#9-3 전통적인 역할의 통합과 소멸
#9-3 전통적인 역할의 통합과 소멸
이전 글에서 이야기한 마이크로 엔터프라이즈화와 더불어 전 세계적으로 일어나는 변화 중 역할이 통합되고 소멸되는 현상이 있다. 이는 특정 역할에만 국한되는 것이 아니고 전방위적으로 일어나는 현상이다.
특히 역할자로는 QA, 아키텍트, 프로젝트관리자 등이 개발자로 통합되거나 소멸되고 있다. 이 글에서 그 내용을 사례로 다뤄보자.
* 최대 클라우드 CRM 솔루션 업체의 사례
첫 번째로 전 세계에서 가장 큰 클라우드 기반 CRM 업체인 미국의 S사는 '17년 4월 내부적으로 매우 큰 변화를 단행했다. 그것은 QA를 다른 역할로 흡수, 통합시킨 것이다. 테스트를 그동안 매우 중시해왔던 회사가 QA를 개발자 또는 프로젝트 관리자 그룹으로 통합시킨 사례는 시장에 커다란 충격을 주었다. 왜 그런 일이 벌어졌는지는 S사가 성장한 과정을 이해할 필요가 있다..
S사는 '99년 아파트 1채에 두 명이 사업을 시작해서 급속도로 성장했고, '04년 IPO에 성공했다.
'05년에는 150명 규모로 성장했는데, 이때 커다란 사고가 발생했다. 중요 릴리즈가 15개월이나 늦어진 것이었다. 이 문제로 고객과의 신뢰에 커다란 오점을 남겼다. 원인을 파악해보니, 이는 성능을 중심으로 테스트하던 조직과 제품 조직 사이의 갈등으로 일어난 일이라 내부적인 갈등으로 야기된 결과였다.
이에 릴리즈 트레인(Release Train)이라는 개념을 도입하여 조직과 역할자의 통합을 위해 노력했다. 이 개념은 쉽게 말하면 고객의 요구사항을 받아 개발하고 배포하는 것까지의 일련의 과정을 자동화하는 것이었다. 이때 자동화 테스트를 중시하는 데밥스의 개념을 적용하는 시도들이 일어난다.
먼저 S사는 애자일 선언을 한다. 소수 팀을 중심으로 시작하여 빅뱅으로 전체 조직을 애자일 전환했고, 외부 컨설턴트들의 도움을 받았다. 하지만 외부 컨설턴트에 대한 시각은 그다지 좋지 않았다.
'06년에는 S사 자체의 애자일 방법론을 론칭한다. 이 방법론은 기존의 스크럼, 린, XP 등의 프로세스를 적절히 섞어 만들었다. 이와 함께 인력은 200명이 넘게 된다. 이때부터 협업을 강조하는 마인드 셋을 중요시하게 된다.
[S사의 애자일 방법론]'08년에는 600명의 조직으로 성장하면서 개발 조직과 QA조직을 통합한다. 그리고 600명의 인력을 크게 개발자+QA 조직과 제품 조직으로 변화시킨다. 이는 QA와 개발자 간의 극심한 마찰이 있었기 때문이다. 같은 비전을 보고 개발할 수 있도록 하기 위해 이러한 변화를 드라이브했다.
'12년에는 1500명 조직으로 성장했다. 흥미로운 점은 클라우드 기반의 인프라 담당자들은 애자일에 대해 극렬히 반대했다는 점이다. 스크럼, 칸반은 그들이 하는 일에 크게 도움이 안 된다는 생각이 지배적이었다는 것이다.
'17년은 7000명 조직으로 급격히 인력이 늘어난다. 이 7000명 조직은 450개의 애자일 팀으로 나뉘어 운영되었다. 그리고 이때 QA를 프로젝트 매니저와 개발자로 흡수 통합한다.
이러한 결정을 수행한 가장 커다란 이유는 개발자와 QA의 역할이 나누어져 있을 때 같은 목표를 보지 않고 역할자 간 마찰이 발생하는 것을 자주 발견했기 때문이다.
또다른 이유는 자동화 테스트의 성숙이었다. '05년부터 자동화 테스트를 강조한 S사는 유닛, 시스템, 통합, API, GUI 등에 충분한 자동화 테스트가 확보되어 있었고, 이는 기존에 QA가 하던 일을 프로젝트 매니저와 개발자가 나누어서 수행할 수 있을 만큼의 팀으로 진화할 수 있는 밑거름이 되었다.
* 보안 소프트웨어 업체의 사례
또 다른 예제로 독일의 보안 소프트웨어 개발 업체 A사의 예를 들어보려고 한다. 이 회사는 500명의 개발 조직을 '14년부터 애자일 전환하기 위해 노력했다.
시작점은 CTO, 인사, 개발자가 모인 TF 활동으로 변화를 만든 것인데, 이를 통해 팀 문화 --> 팀 기술 --> 조직 구조 형태의 순서로 진화시키려고 했다. 기존의 조직은 프런트 엔드 개발 조직, 백엔드 개발 조직, DB 설계조직, 아키텍트 조직 등으로 나뉘었는데, 시간이 갈수록 조직 간 협업이 어려워지고 있다는 것을 느낄 수 있었다. 이를 해결하기 위해 단계별 접근을 실시했다.
1) 1단계 (역할의 통합)
그리고 먼저 역할의 통합을 목표로 잡았는데, 사일로(Silo) 조직인 프런트 엔드, 백엔드, DB 설계, 아키텍트 조직의 프로젝트 관리자들을 개발자 또는 제품 책임자로 전환하기로 했다. 하지만, 이를 모두 한 번에 수행하면 일대 혼란이 일어날 것이라 생각되어, 파일럿을 수행하기로 했다.
우선 한 팀의 프로젝트 관리자를 개발자로 전환했다. 이 프로젝트 관리자는 이 전부터 이해관계자와의 협의보다 개발자를 더 선호하던 사람이었다. 이후 다기능 팀(Cross Functional Team)을 만들었다. 제품 책임자를 제외한 모든 역할자 즉 테크니컬 라이터, QA 등을 개발자로 전환했다.
그리고 사내에는 향후 본인의 전문성을 중심으로 하되 풀 스택 개발자로 일해야 한다고 이야기했다. 프로젝트 관리자들에게는 내년부터 프로젝트 관리자라는 역할이 모두 없어질 것이며, 파일럿을 수행하는 팀과 비슷한 형태로 업무를 수행하게 될 것이고 이를 회사는 배려할 것이라고 이야기했다.
2) 2단계 (평가제도의 혁신)
[A사의 2단계 변화]일부 직원들은 회사를 떠났으나, 대부분 인력들의 일하는 만족도는 높아졌다. 왜냐하면 회사가 기술 교육, 세미나 참석을 더 자유롭게 받아 개인들이 성장할 수 있도록 배려했기 때문이다. 그리고 개발 코치라는 역할자들 7명을 신규로 채용했다. 1명이 30명 정도를 담당하는 식으로 기술적인 어려운 점이 있을 때마다 짝 코딩을 실시하며 도움을 주었다.
그리고 팀 평가 방식을 변화했다. 회고 형식을 바꾸어 한 명의 퍼실리테이터와 함께 들어가서 미팅 룹에서 서로에게 모두 피드백을 주는 365 피드백 방식을 도입했다. 이를 통해 개인에게 성장을 위한 데이터를 제공했다. 또한 평가 방식도 개선했는데, 기술력, 팀 협업 능력, 팀 공헌도의 세 가지 측면에서 평가했다. 기술력은 특정 언어에 대한 기술력을 팀의 동료들이 평가하는 것이었는데, 개발자들 스스로 평가 항목을 정했다. 팀 협업 능력은 짝 프로그래밍의 실력이라던지, 코드 리뷰를 하는 능력, 팀에게 피드백을 얼마나 잘 제공하는지 정도의 항목을 평가했다. 마지막으로 팀 공헌도는 다른 팀원에 비해 얼마나 팀에 헌신하는지, 협업을 하는 능력이 얼마나 좋은지, 새로운 발상을 얼마나 잘할 수 있는지로 기준을 잡았다.
3) 3단계 (인사, 관리제도의 혁신)
[A사의 3단계 혁신]마지막으로 채용 프로세스를 변경했다. 채용 과정 시 이전에는 회사 전체적으로 채용을 실시하던 것에서 HR은 팀이 원하는 인력을 찾고 팀이 주축으로 인력 관리 예산 및 필요를 고려하여 인력을 채용하는 형태로 전환하였다. 또한 프로젝트의 예산 또한 과거 프로젝트 단위로 예산을 주던 것에서 역량 중심의 예산 부여 방식으로 변경하여 개발팀이 더 안전한 그물망에서 개발할 수 있도록 했다.
* 아키텍트의 감소
위 두 사례와 더불어 아키텍트의 역할도 변화되고 있다. 과거에는 코드를 쓰지 않더라도 전체 아키텍처를 조율하는 소프트웨어 아키텍트는 반드시 필요한 역할이었다. 25명의 개발자 중 한 명 꼴로 1명의 풀타임 소프트웨어 아키텍트가 필요했다.
그들의 일은 고객들과 이야기하고 주변 이해관계자들과 이야기들을 직접 대하며 계획, 비즈니스 변화, 기술적 설계, 설계 의사결정, 프레임웍, 아키텍처 원칙, 아키텍처 패턴, 품질 속성 정의 등에 대한 의사결정을 도왔다.
하지만 팀 규모가 점점 작아지면서, 이러한 역할의 필요성이 점차 감소되고 있다. 이는 채용 시장에서 특히 잘 나타나는데, 채용 과정에서 본인의 역할이 소프트웨어 아키텍트 역할이었다고 하면, 코딩을 안 하는 아키텍트(Non coding architect)의 경우 대형 팀이나 대형 회사가 아닌 경우는 채용되는 경우가 많이 줄었다.
대신에 클라우드 기반에 인프라까지 고려하여 환경을 잡을 수 있고, 환경과 더불어 코딩까지 할 수 있는 개발자(또는 '아키텍트의 역량을 가진 개발자')는 채용 수요가 급격히 늘어나고 있다.
