페라리 F1 소프트웨어 개발팀을 만나다.

[XP2007 키노트 사진]

 

필자가 주니어 개발자 시절, 과거 할리우드 스타들이 별장을 소유하고 휴가를 즐긴다는 이탈리아의 아름다운 도시 ‘코모’를 찾게 되었다. 애자일 콘퍼런스 중 한 축이었던 XP 콘퍼런스 (XP는 컨트벡이 만든 대표적 애자일 프로세스 중 하나이다.) 가 이곳에서 열리고 있었다. 그리고 심지어 이 이벤트의 키노트 연사가 페라리 F1의 소프트웨어 팀이었다. 

 

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

방법론

 

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

 

1. 개념적인 설계를 한다.

2. 논리/물리 설계를 한다.

3. 실제 자동차를 만든다.

4. 테스트를 한다.

5. 레이스를 한다.

6. 우리가 만든 자동차는 역사가 된다.

 

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

 

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

일상  

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

지속적인 개선

 

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

 

이를 30년간 뚝심 있게 지속해 온 결과로 ‘고객과의 커뮤니케이션 단일화', ‘위키를 통한 커뮤니케이션', 지속적인 통합', '짝 프로그래밍', ‘3개의 테스트 제품 만들기' 등의 노하우가 쌓이게 된 것이다.

 

'01년 애자일 선언 때 함께 언급된 프로세스들 XP, 스크럼, 린 소프트웨어 개발, 크리스털 클리어 등도 위와 비슷한 과정을 통해 발전되었다. 각자 다른 모습의 시도와 실패를 통해 프로세스화 되었다. 결국 ‘급속도로 바뀌는 환경’에서 ‘고객을 만족시키기 위해 짧은 주기 별로 개선해가며 경쟁력을 쌓는 방식’으로 발전한 것이다.

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

 

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

 

내일 당장 애자일을 해야 한다면 다음의 두 가지를 해 보자. 먼저 지난 일주일에 대해 함께 팀원들과 이야기해 보자. 그리고 문제점을 찾아 오늘부터 시작되는 일주일에 이를 해결해 보는 방법을 시도하는 것이다.