대기업 실전 애자일 1장 #1-4 지속적인 개선

#1-4 지속적인 개선 

* 스크럼이란 무엇인가?

엔지니어링 기법들을 하나씩 경험을 통해 체득하게 될 즈음, 필자는 애자일에 대해 본격적으로 공부하기 시작했다. 당시 애자일이라는 용어와 함께 새로운 프로세스들이 하나 둘 대한민국의 소프트웨어 업계에 들어오기 시작했는데, XP(Extreme programming)와 스크럼이라는 프로세스가 대표적이었다.

스크럼은 한 달의 짧은 개발 주기를 반복적으로 활용하며 팀이 수행해야 할 역할과 책임을 정의한 프로세스다. 주로 엔지니어링 기법을 강조하는 XP와는 다르게 일하는 동료 간 함께 일하는 관리적 기법을 주로 다룬다. 스크럼은 XP에 비해 상대적으로 설명하기 쉽다. 때문에, 발표 후 업계에서 가장 널리 쓰이는 애자일 프로세스가 되었다. 스크럼은 여러 가지 기법들로 이루어져 있다. 반대로 말하면 이 기법들의 조합이 스크럼이다. '스프린트'라 불리는 짧은 기간 동안 아래와 같은 기법들이 서로 입력값과 출력 값이 되어 진행된다.

1. 릴리즈 플래닝: 3개월 정도의 기간 후에 어떠한 목표를 이루고 싶은지 팀이 함께 토론하는 워크숍이다.
2. 스프린트: 한 달 정도의 짧은 개발 주기를 의미한다.
3. 스프린트 플래닝: 릴리즈 플래닝 때 세운 목표를 팀 전체에 다시 한번 알리고, 스프린트 기간 동안 목표에 다다르기 위한 계획을 짜는 회의이다.
4. 데일리 스크럼: 매일 팀원들이 모여 공유가 필요한 팀의 이슈를 짧게 논의하는 회의이다.
5. 스프린트 리뷰: 스프린트 기간 동안 만든 제품을 고객에게 시연하고 피드백을 듣는 자리이다.
6. 회고: 팀 전체가 모여 금번 스프린트 동안 좋았던 점과 아쉬웠던 점을 공유한다. 그리고 다음 스프린트에 시도할 액션 아이템을 만든다.
7. 스크럼 보드: 목표를 이루기 위해 팀원들이 수행해야 할 태스크를 포스트잇으로 보드에 붙이고 함께 정보를 공유한다.

용어 자체가 영어로 되어 있어서, 바로 와 닿기 어렵다. 이런 경우 다음과 같이 생각을 전환하면 된다. 우선, 주변에서 특별히 일 잘하는 동료를 찾아보자. 그리고 그가 일하는 방법을 한번 잘 관찰해 보라. 그가 일하는 방법을 보면 스크럼에서 말하는 기법들과 비슷한 형태의 습관을 실천하고 있을 가능성이 크다.

예를 하나 들어보겠다. 필자는 과거 매우 인상적인 방식으로 일하는 개발자를 만난 적이 있다. 그 개발자는 여러 시행착오를 거쳐, 스스로 성장하면서 업무를 잘할 수 있는 방식을 체득하였다. 업무에서 주로 포스트잇을 많이 사용했는데, 그의 일하는 하루의 루틴은 다음과 같았다.

“저는 매일 아침 8시 50분에 출근합니다. 그리고 10분간 하루의 계획을 세웁니다. 우선 포스트잇 8장을 책상에 붙입니다. 그리고 오늘 하루 무슨 일들을 해야 하나 고민해보죠. 한 장을 1시간이라고 보고 30분 단위로 해야 할 2가지 태스크들을 포스트잇 1장씩 적습니다. 이렇게 14가지의 태스크를 7장의 포스트잇에 붙입니다. 그리고는 1장의 특별한 포스트잇을 준비하죠. 보통 다른 색깔을 씁니다. 그 다른 색 포스트잇에는 제가 1시간 동안 공부하고 싶은 내용을 붙입니다. 뭐... 다른 사람들은 업무 시간 중에 자신의 공부를 한다고 생각하겠지만 전혀 그렇지 않습니다. 저는 그 1시간을 제가 하고 있는 프로젝트 일을 어떻게 하면 더 잘할 수 있는지 관련된 일을 검색하거나, 책을 읽거나 기술을 사용해보는데 씁니다. 그리고 전 하루 동안 수행한 일에 대해 제 주변 사람들에게 메일로나 또는 직접 이야기하고 하루를 마무리 짓습니다.”

그는 나와 함께 있던 8개월 동안 늘 포스트잇을 책상에 붙이며 일을 했다. 업무시간을 업무 외로 쓰는 것에 극도로 자제했으며, 커피를 마시거나, 담배를 피우는 시간도 일과 중에는 거의 쓰지 않았다. 대신, 정확하게 8시간 동안 집중해서 일을 하고 14가지의 태스크를 모두 온전히 마치는데 공을 들였다. 야근을 생활화하며 긴 시간 휴식을 중간중간 즐기는 개발자들에 비해 필자의 눈에 그는 정말 훌륭한 엔지니어였다.

그가 말한 내용을 다시 한번 생각해보자. 스크럼에서 말하는 대표적인 기법들과 맞물리는 방식들이 함께 있다.

10분간의 하루의 계획 시간 => 스프린트 플래닝

하루 시간 단위 => 스프린트

주변에 메일 또는 직접 이야기 하기 => 스프린트 리뷰

달리 말하면 스크럼은 매우 상식적인 수준의 일하는 방법들을 모아 정형화한 것이라고도 볼 수 있다. 스크럼의 창시자 켄 슈와버는 심지어 스크럼을 “바보도 할 수 있는 방법"이라고 설명했다.

* 애자일 선언

당시 필자는 스크럼에 대해 공부하다가 스크럼과 늘 함께 얘기되는 '애자일 선언'이라는 것에 대해서도 알게 되었다.

애자일 선언은 2001년 당시 XP, 스크럼, 크리스털 클리어 등의 프로세스를 고안한 사람들이 '소프트웨어 개발 프로세스는 이래야 한다'라는 내용을 합의하에 작성한 글이다. 그 내용을 살펴보면 다음과 같다.

"우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾는다. 이 작업을 통해 우리는 다음을 가치 있게 여긴다:

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

복잡한 문서보다 동작하는 소프트웨어를,

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

계획을 무조건 따르기보다 변화에 대응하기를 가치 있게 여긴다.

위 네 가지 내용의 왼쪽도 가치가 있지만, 우리는 오른쪽보다 더 높은 가치를 둔다."

여러 프로세스를 기반으로 한 공통적인 문건을 만들다 보니, 애자일 선언은 가치에 중심을 둔 추상적인 수준의 문건으로 작성되었다. 당시 현장에서 일하는 필자에게는, 위 글은 매우 어려웠다. 이 말들이 현실과 엮여 어떻게 팀으로 녹아들어 가는 것인지 명확히 이해하기 어려웠다.

* XP2007 - 페라리 F1 소프트웨어개발팀

이 즈음, 필자는 커리어에서 가장 중요한 마일스톤을 경험하게 된다. 좋은 기회를 얻어 ‘07년 할리우드 스타들이 별장을 소유하고 휴가를 즐긴다는 이탈리아의 아름다운 도시 코모를 찾게 되었다. XP 2007 콘퍼런스가 이곳에서 열리고 있었다. 그리고 심지어 이 이벤트의 키노트 연사가 페라리 F1 소프트웨어 팀이었다.

XP 콘퍼런스 의장의 개회사가 끝나고 드디어 수십 년 동안 최고의 자동차 소프트웨어를 만들어온 수석 엔지니어 피에르 죠지 그로시(Piergiorgio Grossi)와 니콜라 카날리니(Nicola Canalini)가 키노트 스피치 연설을 시작했다. 그들은 마치 개발 시 짝 프로그래밍을 하듯 둘이 함께 발표하는 짝 발표 방식을 사용했다.
 

피에르의 첫마디는 다음과 같았다.

“저는 XP를 적용해보려고 하지 않습니다. 사실 저는 XP에 대해 잘 알지도 못합니다."

키노트 연설을 시작하자마자 던진 그들의 첫마디에 나는 혼란 속에 빠졌다.

'응? XP 콘퍼런스에 기조연설을 하려고 온 팀이 XP를 모른다니, 무슨 말이야?'

하지만, 그들의 키노트 연설에 빠져들면서 나는 그가 이렇게 키노트를 시작한 것이 얼마나 멋진 것인지 이해하게 되었다. 당시 필자는 애자일을 시작하는 사람으로서, 이 키노트를 통해 애자일의 본질을 이해할 수 있었다.

그들은 페라리 F1 소프트웨어 개발팀의 개발 상황에 대해 다음과 같이 설명했다.

“페라리 F1 소프트웨어 개발팀의 전체 개발자는 20명이다. 우리가 해야 할 일은 20명이 하기엔 현실적으로 너무나 많다. 다양한 종류의 프로그래밍 언어로 만들어진 100개 이상의 레거시 시스템들이 있고 이들 레거시 시스템들은 각기 다른 개발 프레임웍을 사용한다. 이들이 모두 통합되어 F1 자동차 한 대를 구성하는 SW로 딜리버리 된다. 거의 매주 레이싱이 있으며, 레이싱은 각기 다른 나라에서 열린다. 때문에, 우리는 경주 당시의 날씨와 도로 노면의 상태 및 환경에 따라 다르게 동작하는 프로그램을 만들어야 한다. 또한 우리는 전 세계 수십 개의 지사로 이 소프트웨어를 딜리버리하고 하드웨어와 함께 테스트한다. 다양한 지사에 요구사항이 달라 다른 브랜치들을 관리하는 것도 큰 일이다. 항상 예상하지 못한 일이 발생하고, 초 단납기에 제품을 완성해야 하며, 이런 상황에서도 늘 동작하는 소프트웨어를 만들어야 한다. 우리의 개발 방법론을 이야기하면 다음의 6단계로 이루어진다.”

1. 개념적인 설계를 한다.
2. 논리/물리 설계를 한다.
3. 실제 자동차를 만든다.
4. 테스트를 한다.
5. 레이스를 한다.
6. 우리가 만든 자동차는 역사가 된다.

"우리가 만든 자동차는 역사가 된다"라니... 그 자신감은 정말로 훌륭했다. 필자도 언젠가 스스로 그런 이야기를 하고 싶다는 욕구가 샘솟았다. 그들은 이 키노트를 통해 어떻게 역사가 되는 자동차를 만들 수 있었고, 그 자동차 안의 소프트웨어 개발 방식에 대해 설명했다.

* XP2007 - 페라리 F1 소프트웨어개발팀의 일하는 방법

아래의 내용은 필자가 당시의 키노트 내용을 메모하여 보관해 두던 것이다.

과거에 했던 실패의 원인을 찾고 개선하기 위해 3주의 개발 주기마다 20명의 팀원이 모두 참여하는 투표를 실시하고 서로의 의견을 공유하는 프로세스를 만들었다.

고객과의 커뮤니케이션을 단일화하는 것이 매우 필요했다. 고객이 시도 때도 없이 연락하여 요구사항을 냈기 때문에 제대로 개발에 집중할 시간이 부족했다. 이를 개선하기 위해 우리는 고객과의 커뮤니케이션을 전담할 수 있는 드라이버라는 역할을 만들었다.

드라이버가 대표로 문제를 확인하고 수정할 책임을 진다. 이 드라이버는 특정 프로젝트의 특정 일을 맡지 않으며, 문제 해결만의 고유의 역할을 수행한다. 그가 하는 일이 워낙 힘들었기에 우리끼리는 그를 전사(Warrior)라고 부르곤 한다. 처음 이 방법을 도입할 때는 20명 중 2명의 드라이버가 필요했지만 여러 시행착오 끝에 현재는 이 역할자가 1명으로도 충분하다는 것을 알게 됐다. 현재 1명의 드라이버가 프로젝트 내에 존재하며 일정 기간이 되면 이 역할을 프로젝트 내 적절한 사람에게 넘긴다.

우리는 위키(Wiki)를 사용한다. 위키에 프로젝트 전체 담당자들의 역할 및 하루하루 벌어지는 일을 정리하고 정보를 공유한다. 특히나 드라이버의 정보는 반드시 상세하게 작성되어야 한다. 드라이버는 고객이 내어놓은 문제 제기, 해결 방식에 대해 공유할 책임이 있기 때문이다. 이 위키가 프로젝트의 열쇠 역할을 한다.

우리는 지속적인 통합(Continuous Integration)을 사용한다. 우리 시스템은 한번 클릭하면 100개 이상의 레거시 시스템과 새로 만든 시스템이 함께 통합되며 딜리버리 될 수 있게 구성되어 있다.

배포를 너무 자주 수행하면, 문제가 생길 때마다 수정하는 시간이 늘어나고 요구사항이 밀려들며, 이 배포 주기를 너무 길게 가져가면 요구사항은 상대적으로 줄어들더라도 통합할 때 엄청난 리스크가 발생한다. 여러 시도에 의해 우리는 3~4일 정도의 빌드 및 배포 주기를 가져가져가고 있다. 주로 새벽시간에 자동으로 빌드를 돌린다.

우리는 하드웨어에 소프트웨어를 녹이는 제조 단계에서 공식 버전이 나오면 3개 이상의 약간씩 변경을 가한 베타 버전을 가지고 테스트한다. 그리고 이중 한 개를 선택한다

두 명씩 짝이 되어 작업하다가 업무 공유를 보다 원활히 하기 위해 네 명이 그룹을 지어 일을 하는 방식을 채택했다. 다시 말하면 4명이 2개의 프로젝트를 수행하는 셈이다. 두 가지 플래닝 게임을 함께 하고 두 프로젝트 각각 절반씩의 일들을 서로 다른 짝이 수행한다. 또한 필요할 때마다 역할을 변경하며 작업한다.

우리는 스토리 카드라는 것을 사용한다. 또한 스토리 보드를 사용하는데 일의 단계마다 ‘현재’,’ 다음',’ 창고(warehouse)'로 구분하여 수행하는 일, 예정된 일, 해야 할 일을 모니터링한다.

위 메모의 내용을 살펴보면, 약간씩 형태는 변형되었지만 XP나 스크럼에서 말하는 기법과 매우 유사한 노하우들이 녹아져 있다. 수십 년 동안 스스로 실험하고 갈고닦으며 발전시켜온 기법들이 마치 애자일의 XP나 스크럼의 형태로 발전한 것이다. 어떻게 이러한 프로세스의 정착이 가능했던 것일까? 필자가 생각하는 그들의 경쟁력은 가장 위에서 언급한 내용 때문이라 생각했다.

"과거에 했던 실패의 원인을 찾고 개선하기 위해 3주의 개발 주기마다 20명의 팀원이 모두 참여하는 투표를 실시하고 서로의 의견을 공유하는 프로세스를 만들었다."

페라리 F1 소프트웨어개발팀은 3주마다 자신의 일하는 방법을 개선하기 위해 팀원 모두가 함께 참여하여 회의를 했다. 그 회의의 결과로 조금씩 개선해 나가는 ‘팀 단위의 지속적인 개선’의 방법들을 스스로 찾아낼 수 있었다. 이때의 액션 아이템을 하나하나 실천하며 페라리 F1 소프트웨어개발팀은 스스로 일하는 방법을 개선할 수 있는 팀이 되었다.

이를 30년간 뚝심 있게 지속해 온 결과로 ‘고객과의 커뮤니케이션 단일화', ‘위키를 통한 커뮤니케이션', 지속적인 통합',  '짝 프로그래밍', ‘3개의 테스트 제품 만들기' 등의 노하우가 쌓이게 된 것이다. 애자일 선언 때 함께 언급된 프로세스들 XP, 스크럼, 린 소프트웨어 개발, 크리스털 클리어 등도 위와 비슷한 과정을 통해 발전되었다. 각자 다른 모습으로 시도와 실패를 통해 프로세스화 되었다. 결국 ‘급속도로 바뀌는 환경에서 고객을 만족시키기 위해 위해 짧은 주기 별로 개선해가며 경쟁력을 쌓는 방식’으로 발전되었다.

세상의 많은 팀들이 애자일을 한다. 하지만 그들을 만나보면 앞서 몇 개의 기법 자체에만 집착하는 경우가 많다. 애자일을 한다는 것은 실제로 그 기법 체보다 팀이 스스로 개선하는 문화를 유지하는 것이다.

XP 프로세스를 창시한 켄트 백은 그의 책 ‘익스트림 프로그래밍' 마지막에 다음과 같은 말을 남겼다. “XP와 비슷한 모양새를 만들기 위해 XP를 흉내 내려고 하지 말자. 대신에 XP를 당신의 현장에서 실제로 발생하는 문제들을 해결하기 위해 적용하라. 당신의 옷에 멋지게 적은 문구처럼 사용하지 말아라. XP는 지속적인 개선이다.“

사용자 스토리라는 기법을 정의한 마이크 콘은 다음과 같은 말을 남겼다.

“지금 당신이 얼마나 잘하는지는 별로 중요하지 않다. 다음 달에 지금보다 당신이 나아지지 않는다면, 그건 더 이상 애자일이 아니다"

애자일이 중요한 게 아니다. 당신과 당신의 팀이 지속적인 개선하고 성장하는 것이 훨씬 더 중요하다.