7장. 애자일팀의 탄생#1
#7-1 클라우드 시대
7장. 애자일팀의 탄생
두번째 애자일 전환 시도가 무산되었다. 이 즈음 세상은 급격하게 변화하고 있었다. 클라우드 시대를 맞이한 것이다. 이에 따라 많은 회사들도 새로운 변화를 준비하고 있었고 필자의 회사 경영진들도 새로운 시대에 더 나은 경쟁력을 만들고 싶어했다. 필자는 정말 운이 좋았다. 이 기회를 통해 애자일 전문 회사인 P사와 협업하고 이를 통해 한국에서 최초의 애자일 팀을 만들어낼 수 있었다. 이번 장은 이 전체과정을 설명한다. 이를 통해 독자들은 한국 최초로 대기업 내에서 애자일 개발 컨설팅 조직이 만들어진 과정을 이해할 수 잇다.
7장은 7개의 절로 나누어져 있다. #7-1에는 클라우드 시대가 도래하면서, 소프트웨어 개발 환경이 어떻게 큰 변화를 겪었는지를 이야기한다. 당시 미국 정부가 변화하는 모습을 예로 들어 한국 IT 소프트웨어 개발 환경이 상대적으로 얼마나 느렸는지를 알 수 있다. #7-2~6은 소프트웨어 개발 경쟁력을 얻기 위해 P사와 협업한 동기와 과정을 이야기한다. 마지막으로 #7-7에서는 한국 최초의 애자일 전문 팀 애자일코어팀(ACT)이 어떻게 생겨났는지 설명한다.
#7-1 클라우드 시대
* 세 가지의 변화
두 번째 애자일 전환이 실패한뒤 2년이 흘렀다.
그동안 시장에는 거대한 변화가 감지되고 있었는데, 그것은 SaaS(Software as a service) 서비스를 중심으로 하는 클라우드 시대가 도래한 것이다. 클라우드는 모든 것을 변화시켰다.
먼저, 고객이 변화했다. 고객들은 더 이상 스스로만 만족하는 시스템을 원하지 않았다. 대신에 고객이 제공하는 시스템을 사용하는 실제 사용자들의 목소리에 귀를 기울였다. 사용자의 피드백이 날이 갈수록 고객에게 중요해졌다.
[클라우드의 SaaS, PaaS, IaaS 개념]두 번째로, 일하는 사람들 또한 변화했다. IT 기술 트렌드가 워낙 빠르게 변하다 보니 그들이 일터에서 기대하는 배움에 대한 눈높이가 매우 높아져 있었다. 이들에게는 예전처럼 회사에 대한 충성을 기대하기는 어려웠다. 대신에 늘 배울 수 있는 일터라는 느낌을 주는 것이 중요했고 자주 새로운 기술을 경험할 수 있게 배려하는 것이 필요했다. 또한 지루해지지 않도록 3~4개월에 한 번씩 일하는 내용의 변화를 주어야 했다.
세 번째로, 품질과 생산성의 개념이 변화하고 있었다. 과거에는 소프트웨어를 전달하기 전에 고객이 100%의 품질을 요구했더라도 IT 벤더들은 120%의 품질을 만들어 제공하려고 노력했다. 그게 그들의 경쟁력을 보여주는 방법이었다. 하지만 이제는 70% 정도의 품질 수준만 되더라도 최종 딜리버리 전에 먼저 고객에게 가져가 제품을 보여주며 물어보고 고객이 원하는 것에 부합한 지에 대한 피드백을 먼저 듣는 것이 필수적인 시대가 되었다. 주기적으로 고객을 만나 소프트웨어에 대해 묻고 그에 따라 개선하는 것이 보다 더 나은 품질의 소프트웨어를 만드는 것이라고 이야기되기 시작했다.
또한 과거에 우리가 알던 생산성의 개념 또한 달라졌다. 과거에는 소프트웨어업에서도 제조업의 생산성 개념이 그대로 사용되고 있었다. 즉, 짧은 기간 안에 얼마나 많은 기능을 만들었느냐가 중요했다. 구현한 기능의 개수가 생산성의 지표였다. 하지만 이제는 고객 또는 사용자가 준 피드백을 소프트웨어에 얼마나 빨리 소프트웨어에 반영하느냐가 더 중요해졌다. 우리는 이를 기준에 따라 ‘‘사이클 타임’ 또는 ‘리드타임'이라고 부르고 관리하고 있다.
[리드타임과 사이클 타임]시장이 클라우드 중심으로 변화함에 따라, 필자의 회사 내에서도 여러 가지 변화가 감지되었다. 가장 큰 변화는 회사 솔루션 비즈니스를 확장하기 시작한 것이다. 또한 직원들의 마인드셋도 변화하기 시작했는데, 솔루션 비즈니스를 보다 경쟁력 있게 하기 위해 스스로의 생각과 일하는 방법을 이전과 달리해야 한다고 느끼기 시작했다. 가장 상위의 경영층뿐만이 아니라 말단의 개발자까지 이 고민을 함께 공감했다.
솔루션 비즈니스를 보다 성공적으로 수행하기 위해 무엇을 해야 하는지에 대한 토론의 자리도 자주 열렸다. 이 토론자리에서 사람들은 그동안 과거에 묻어두었던 애자일 방식에 대해 다시 이야기 하기 시작했다. 그리고 그들은 경쟁력 있는 솔루션을 만들기 위해서 시장의 흐름에 빠르게 반응할 수 있게 만드는 애자일 방식만이 유일한 일하는 방법의 대안이라고 결론지었다. 적어도 솔루션을 만들 때는 애자일 방식으로의 변화가 필수적이다라고 이야기하고 있었다.
하지만, 이 변화를 상세하게 어떻게 실천해야 하는지에 대해서는 의견이 갈렸다. 다양한 의견들이 나왔다. 예전에 일하던 방법과 새로운 방법에 대한 니즈가 섞이면서 일대 혼란이 일어났다. 영업, 기획에서 개발까지 전체적인 혼란이 있었다. 하지만 많은 사람들이 알고 있었다. 솔루션의 애자일은 영업, 기획, 개발까지 전체적으로 일하는 방법의 탈바꿈을 요구했다.
회사도 극적으로 변화하기 위해 많은 노력을 하기 시작했다. 해외 벤치마킹을 통해 자료를 수집했다. 선진 솔루션 회사의 일하는 방법에 대해 연구하고 진지하게 고민했다. 이를 통해 회사 전체적으로 더 나은 소프트웨어 솔루션을 만들기 위한 영업-기획-개발-운영 흐름의 체계를 갖추어 나갔다. 문제는 사람들이었다. 그들의 변화는 생각보다 오래 걸렸다. 그동안의 관성 때문인지 사람들은 체계와 함께 맞물려 움직이지 못하고 있었다. 그들을 위한 보다 상세한 가이드들이 필요했다.
이를 극복하기 위해, '13년도에 교육을 통해 제안했던 기획/개발시 애자일 분석/설계 방식이 회사 표준으로 사용하기 시작했다. 이를 통해 비전을 세우는 것으로부터 사용자 스토리를 작성하는 방법까지 함께 활용했다. 우리는 이 방식을 ‘사용자 스토리 워크숍'이라고 불렀다. 애자일 전도사를 중심으로 이를 전문적으로 리딩 하는 팀이 꾸려지고 이 방식은 계속해서 개선되며 활용되기 시작했다.
사람들은 이를 그대로 적용하기보다 보다 회사에 적합하게 적용되기를 원했다. 조직에 따라 최적화하며 다르게 적용하고 이를 다시 모아 정리했다. 전체적으로 모든 솔루션에 추가로 해야 할 기법들도 스스로 해보면서 만들어냈는데, 예를 들어 우리는 ‘역할과 목표'라는 기법을 진행한 후 도출된 기능에 대해 수준을 맞출 필요가 있었고 이 기법을 추가했다. 이 기법을 통해 도출된 기능의 크기가 서로 너무 다른 경우 조절하는 방법을 스스로 익혔다. 이제는 회사 스스로 응용할 수 있는 역량이 관찰되었다.
최적화된 방법을 활용하여 메이저 릴리즈에 대해 기획과 개발이 함께 ‘사용자 스토리 워크숍'을 수행하며 비전을 정의하고 사용자 스토리까지 도출했다. 그리고 이터레이션 별로 목표를 세우며 소프트웨어를 만들기 시작했다.
하지만 여전히 무엇인가가 부족했다. 여전히 릴리즈 주기는 6개월 단위 또는 1년 단위 었고, 엔지니어링 기법은 다양한 측면에서 부족했다. 우리는 시장의 변화에 맞게 개발팀까지 빠르게 움직여야 할 무엇인가를 갈구하고 있었다.
* GSA의 해커톤
[린스타트업 전문가 제이슨 프레이저]이즈음 필자는 제이슨 프레이저라는 분을 만났다. 당시 백악관에서 대통령의 리더십이라는 퍼실리테이션 과정을 진행하던 명망 있는 린스타트업 전문가였다. 그는 필자에게 GSA(General service administration)라는 미국 정부기관에서 주최하는 해커톤에 대해 이야기해 주었다. 그리고 필자는 그날 큰 충격을 받았다.
GSA는 우리나라의 조달청과 비슷한 기관으로 여러 가지 하는 일 중에 미국 정부가 발주하는 IT사업을 관장하는 일을 하고 있었다. 정부 기관이 자신들이 구축한 IT 인프라의 활용을 극대화하기 위해 해커톤을 개최하는 것은 종종 보는 일이었지만, 그들이 '15년 5월에 개최한 해커톤은 취지와 목적이 이전과 달랐다. 관련된 해커톤의 취지를 확인하기 위해, GSA가 '15년 1월 포스팅한 블로그를 함께 읽어보자
------------------------------------------------------------------------
미국 정부가 일하는 방법이 구식이고 리스크가 있다. (워싱턴 포스트, '13년 10월)
성공적인 정부의 조달 방식을 막는 가장 큰 요소가 기술의 빠른 진화이다. (정부 기술, '14년 3월 4일)
수년간 연방 정부와 산업 커뮤니티는 기술의 흐름과 보조를 맞출 수 있도록 소프트웨어를 제때에 얻을 수 있는 방법에 대해 이야기해 왔다. 보통 이 기간은 1년에서 3년이 걸렸다. 하지만, 오늘날의 극적인 환경에서 이는 충분히 빠르지 못하다. 현실적으로 비즈니스 우선순위, 사용자의 니즈, 기술들은 진화하고 지속적으로 만들어지고 있다. 이 흐름에 발을 맞추기 위해, 소프트웨어의 획득은 애자일 개발 사이클의 속도에 맞추어 움직일 필요가 있다. 이상적으로 이것은 제안 후 계약서에 사인한 뒤 4주보다 짧은 시간을 의미하며 3개월 안에 MVP를 전달하는 것을 의미한다.’
------------------------------------------------------------------------
[GSA의 해커톤 관련 블로그 2015년 1월]위의 블로그 글에 따르면 미국 정부가 일하는 방법이 시장의 IT 벤더들에 비해 낙후되어, 이를 개선하고 싶고 이를 위해 해커톤을 개최한다고 했다. 실제로 GSA는 이 해커톤을 통해 역량 있는 70개의 벤더들을 찾아냈다. 그리고, 그들만 참여 가능한 마켓플레이스에 정부가 발주한 딜을 공지했다. 이를 통해 정부의 소프트웨어를 보다 사용자 친화적이며 직관적으로 업그레이드하는 역량을 키웠다.
제이슨은 당시 해커톤에서 입상한 소프트웨어 한 개를 직접 보여주었다. 그가 참여한 팀에서 만든 제품은 세이프 메즈(Safemeds)라는 안전하게 약을 복용하는 방법을 알려주는 웹 앱이다.
누구나 나이를 먹으면서 복용하는 약의 종류와 양이 많아지기 마련이기 때문에, 세이프 메즈를 통해 먹는 약이 혹시나 부작용이 생기지 않을지를 사전에 확인할 수 있다. 매우 단순하지만 거의 모든 사람들에게 사용할 가치가 있는 앱이다. 화면 자체가 매우 직관적으로 되어 있어서 누구나 쉽게 사용할 수 있다. 이 소프트웨어를 만들 때 약의 효능 관련한 API를 활용했으며, 이 제품은 모바일, 태블릿 PC, PC 어느 해당도의 어느 브라우저에서도 잘 동작한다.
[GSA 해커톤 입상 제품 세이프 메즈]사실 필자가 주목했던 것은 이 제품 자체는 아니었다. 대신에 미국 정부기관인 GSA가 내건 IT 벤더들을 향해 이렇게 일해야 한다고 이야기하는 프로세스의 프레임이었다.
과거 필자가 함께 일했던 정부기관은 세상에서 가장 느린 곳이었다. 그들은 늘 안정적이고 수동적인 선택을 해왔다. 늘 정책적 결정 또는 법제화와 연관되어 있었기에 혁신적인 제품 개발 방식을 받아들이기 어려운 곳으로 비추어졌다.
[Safemeds의 Wireframe]하지만, 이와는 판이하게 다르게 미국의 정부 GSA가 내세운 해커톤의 수행 조건은 다음과 같았다. 이들은 시장에서 찾을 수 있는 가장 최신의 일하는 방법을 그대로 접목했다.
사용자 중심 개발
애자일 개발방식 활용
데밥스(DevOps) 체계 적용
GSA가 제공하는 API를 활용한 서비스 개발
한국에서 사용자 중심 개발, 애자일 개발방식, 데밥스 체계 등은 스타트업 기업조차도 전반적으로 활용하는 것들이 아니었다. 몇몇 기술력이 뛰어난 회사들이 시도하고 있는 방법이었다.
그런데 미국에서는 필자가 생각하기에 세상에서 가장 느린 조직인 정부가 IT벤더들에게 일하는 방법을 위와 같이 강요하고 있다는 것은 매우 놀라운 일이었다.
“정부가 일하는 방법을 이런 식으로 프레임으로 규제화하고 있다면 미국의 스타트업, 중소기업, 대기업들은 도대체 어떻게 일하고 있는 것인가? “
고민이 되면서 두려움도 생겼다. 사용자의 피드백을 받기까지 체감되는 속도의 차이가 커도 너무 컸다. 대한민국도 일하는 방법이 바뀌어야 했다.
