좋은 SW개발을 위한 지속적인 개선 '애자일은 무엇인가?'

여러분이 생각하는 애자일은 무엇인가요?
마틴 파울러, 켄트벡, 켄 슈와버 등 쟁쟁한 엔지니어들이 모여 2001년 애자일 선언(Agile Manifesto)을 제정한지 17년의 시간이 지났습니다.

과거 애자일 관련 많은 논란을 등지고 2017년 현재, 대부분의 기업들이 애자일 방식을 사용한다고 말합니다.
IT 솔루션 벤더 또는 서비스 업체들 뿐만이 아니라 최근 빠르게 만들고 사라져가는 스타트업 기업들도 애자일 방식을 기반으로 제품을 만들고 있습니다.
이러한 변화를 고려한다면, ‘애자일이 무엇인가?’ 라는 질문이 시대에 맞지 않는 것을 수도 있습니다.

하지만, 여전히 우리가 일하는 IT 개발 현장에는 애자일에 대해 조직을 운용하는 것에나 팀을 이끌어나가는 방식이 아닌 노하우만 강조되는 경향이 있습니다.
예를들면 다음과 같습니다.

1. 포스트잇으로 이슈를 공유하는 방식
2. 문서가 없는 방법론
3. 개발자들만의 전유물 프로세스
4. 테스트 코드를 만드는 것
5. 아침마다 회의 하는 것

위에 언급한 다섯 가지를 보면서, ‘나도 애자일에 대하여 이렇게 생각하고 있었는데…’ 라고 이야기하는 독자들도 있을 것이다. 하지만 특별히 걱정 할 필요는 없습니다.

언급한 다섯 가지 내용은 필자가 현장에서 애자일에 대해 자주 듣는 이야기들입니다.
또한 위 다섯 가지 설명 방법이 완전히 틀린 것은 아닙니다.
다만, 애자일을 전파하는 역할을 수행하는 필자 생각에는 위의 예제는 애자일의 핵심을 이야기하는 것이 아니기 때문에, 이 설명보다 보다 좋은 설명 방법을 함께 이야기 해보고자 합니다.

과거 필자는 실제 프로젝트에서 다음과 같은 경험을 한 적이 있습니다.

A 프로젝트는 200여명의 개발자가 일하는 규모입니다.
14개월간의 프로젝트 기간동안 많은 사람들이 프로젝트 성공을 위해 노력했지만 워낙 대규모 작업이다 보니 이슈도 많고 탈도 많습니다. 이러한 상황을 지켜보던 당시 회사 PM이 무엇인가를 하겠다는 판단을 스스로 내립니다.
그리고 이젤 패드를 전체 벽면에 붙이라고 지시한다. 그리고 모든 PL들을 모아 다음과 같은 이야기를 합니다.

“오늘부터 우리는 애자일을 하겠습니다. 포스트잇을 이용하여 이슈를 벽에 붙이고 공유해 주세요. 이슈는 작성자, 담당자, 이슈 내용 이렇게 간단히 세 가지만 적죠? 해결되지 않는 이슈에 대해서는 작성자 및 담당자와 제가 직접 해결을 하겠습니다.”

모든 PL들이 이 내용에 대해 동의하고, PL 들은 해당 내용을 각 팀의 개발자들에게 절달합니다.
하지만 며칠이 지나도 아무런 이슈가 붙지 않습니다. 누구든 먼저 작성하여 그 하얀 바탕의 종이에 뭔가를 적어 문제를 만들려고 하지 않는습니다.
며칠간 이 현상을 지켜보던 PM은 자신의 지시를 듣지 않는 팀원들에 대해 짜증이 납니다. 기다리다 못해 한 팀에 찾아가 다음과 같이 말한다.

“오늘까지 자기 팀 벽에 이슈 전체 채워.”

그 날이 다 가기 전, 이젤 패드 한 장에 다닥다닥 이슈들이 꽉 채워집니다.
다음 날 더 놀라운 일이 벌어집니다. 나머지 팀들의 이젤 패드 전체가 이슈들로 꽉꽉 차게 됩니다.

| 프로젝트의 이슈보드

이젤 패드 전체에 이슈가 꽉꽉 차게 된 이유는 무엇일까요? 갑자기 하루 사이에 정말 많은 이슈가 발생한 것일까요?

물론, 아닙니다. 우리는 그 이유를 최초 PM의 강요에 의해 이슈를 적은 팀의 이슈들을 살펴보면 알 수 있습니다.
그 이슈들은 항상 팀 밖을 향하고 있습니다. 즉, 내부적으로 해결해야 할 이슈는 드러내지 않고, 다른 팀이 해결해야 하는 일에 대해서만 이슈를 적은 것입니다. 다시 말해, 그들이 붙여 놓은 이슈에는 해결해야 할 담당자가 언제나 다른 팀에 있습니다. 하지만, 이슈를 적고 이젤 패드에 붙일 때, 해당 팀과의 사전 논의는 없습니다.

그냥 일단 이젤 패드를 채웁니다. 해당 이슈를 본 다른 팀의 팀원들은 자신들이 해결하지 못해 무엇인가가 안되고 있다는 이슈 내용을 보고, 그 이슈를 해결하기보다는 그 이슈를 작성한 팀이 발생시킨 또 다른 문제를 이슈로 제기하여 이젤 패드에 붙입니다. 이슈를 공유하여 협업을 하려는 팀이 아닌, 이슈를 통해 팀 간 전쟁을 하고 있는 것입니다.

위 내용을 읽어본 독자에게 다시 한번 묻고 싶습니다.
이슈를 포스트잇으로 공유하면 애자일을 하는 것인가?

조금 이상하다는 생각을 하게 될 것입니다. 애자일에 대해 설명할 때 많은 책들에 협업(Collaboration)과 자기 조직화(Self Organization)에 대해 이야기 하는데, 위 사례는 분명히 그런 모습은 아닙니다.
분명히 적극적으로 이슈를 공유하고 커뮤니케이션 하고 있으나, 무엇인가 애자일을 구성하는 큰 것이 결핍된 느낌이 들 것입니다.

마찬가지로, 다른 프로젝트 사례를 한번 더 보기로 합시다.

‘B 프로젝트는 솔루션을 구축하는 사업입니다. 책임감이 강한 소프트웨어 아키텍트는 프로젝트 시작 시 매우 강력한 주장을 한다. 솔루션에 걸맞은 테스트 코드를 만들어야 한다는 것입니다.
일정이 빠듯하지만, 그의 의견을 존중하여 모두가 테스트 코드를 만들기로 결정합니다. 테스트 코드는 스프링 프레임웍의 서비스에서 실제 데이터 베이스까지 생성/수정/삭제/조회를 하는 모든 메소드를 대상으로 만들기로 합니다. 하지만 실제로 테스트 코드가 데이터 베이스에 데이터를 수정해버리면, 문제가 발생할 수 있기 때문에 테스트 코드를 위한 공통 코드를 만들어 커밋(Commit)하지 않고 롤백(Roll Back)하는 코드를 삽입하였습니다.

소프트웨어 아키텍트는 이 테스트 케이스들은 실제 데이터를 수정하지 않는 테스트케이스기 때문에 시스템 운영에 아무런 문제가 되지 않을 것이라 자신합니다. 개발자들은 기계적으로 자동화된 툴을 이용하여 각 서비스의 메소드에 맞는 20~30개의 파라메터의 집합인 데이터 셋의 값들을 아무런 의미가 없는 값들로 넣고 테스트 케이스를 생성합니다. 심지어 Null 값을 넣기도 합니다. 그리고 테스트 실행을 해보고, 항상 성공할 테스트 케이스라 확신하는 테스트 케이스를 만들어냅니다.

테스크 코드에 어떤 값을 넣는지는 누구도 감독하지 않습니다. 전사에서 나온 품질 담당자 또한 본인들이 세운 체크리스트와 품질 기준인 테스트 커버러지만 신경을 씁니다. 개발자들은 커버러지를 충족 시키면서 동작하는 한 테스트 코드는 품질 기준으로 볼 때 부족함이 없는 코드입니다.

이후 이상한 일들이 계속됩니다. 테스트 코드를 생성했을 당시에는, 항상 성공하던 테스트 코드가 자주 실패하기 시작한 것입니다. 되다가 안 되다 하는 결함(Flaky Test라고 함)이 발견됩니다. 그리고 실패가 나는 테스트가 여기저기서 목격됩니다.
이러한 일이 발생하는 이유는 테스트 코드가 데이터에 종속되기 때문입니다. 즉, 아무리 롤백을 하더라도, 더미 값으로 파라메타의 값을 채우는 순간 이미 존재하는 값들과 중복될 수 있는 가능성이 발생하는 것입니다.

200명의 개발자 중 한 명이라도 파라메터의 더미값과 비슷한 값을 테스트를 위해 데이터 베이스에 직접 넣으면 특정 테이블 속성의 값이 중복되는 경우가 발생 할 수 있는 것입니다. 결국 앞서 말한 이유로, 개발자들은 테스트 코드의 결함이 품질을 관리하는데 큰 도움이 되지 않는다는 인상을 받게 됩니다.’

자, 이 팀은 테스트 코드를 짜고 있고, 지속적인 통합 툴에 엮어 이 테스트 코드들을 실행하고 있습니다. 과연 이 팀은 애자일을 하는 팀인가? 쉽게 긍정하기 어려울 것입니다. 분명히 애자일에서 말하는 테스트코드를 작성하고 있지만, 무엇인가 다른 중요한 가치가 부족한 것으로 보입니다.

앞서 말한 두 사례는 애자일이라고 말하기에는 동일한 문제점을 가지고 있습니다. 다음 챕터에서 그 문제점과 실제 애자일이라고 말할 수 있는 팀과 프로세스에 대해 이야기해 보기로 합시다.

F1 Ferrari SW 개발 팀

필자는 2007년 소중한 경험을 했습니다.

많은 헐리우드 배우들이 별장을 소유하고 휴가를 즐긴다는 이탈리아의 아름다운 도시 '코모'라는 도시에 방문한 것인데, 당시 애자일의 큰 기조 중 하나였던 익스트림 프로그래밍에 관련된 컨퍼런스(XP 2007)가 이곳에서 열리고 있었습니다.
실제로 필자를 흥분시킨 가장 큰 이유는 기조 연설을 위해 F1 페라리 레이싱 팀의 소프트웨어 개발자들이 온다는 것이었습니다. 키노트 연설이 시작되기 전 F1 페라리의 애자일 방식을 듣고 배울 수 있는 기회를 얻게 된 것에 필자는 매우 즐거워하고 있었습니다.

수십 년 동안 최고의 자동차 소프트웨어를 만들어온 페라리 레이싱 팀의 수석 엔지니어인 피에르죠지 그로시(Piergiorgio Grossi) 와 니콜라 카날리니(Nicola Canalini)는 특이하게도 둘이 함께 발표하는 짝 프리젠테이션 방식으로 키노트를 시작하고 있었다. 이 또한 애자일의 짝 프로그래밍과 비슷한 모습이라 흥미로웠습니다.

하지만, 기조 연설을 시작하자마자 던진 그들의 첫 마디는 필자를 혼란 속에 빠트렸습니다.

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

XP 컨퍼런스에 기조 연설을 하려고 온 팀이 XP를 모른다니, 도대체 무슨 말일까?
하지만, 세션이 시작되고 그 혼란은 점차 정리되기 시작했습니다. 그리고, 기조 연설을 들은 많은 사람들이 그들이 하는 이야기에 귀를 기울이고 있었스빈다. 필자 또한, 당시 애자일을 처음 시작하는 사람으로서, 애자일에 대하여 많은 것을 이해하는 계기가 되었습니다.

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

이들이 제품을 개발하는 프로세스는 다음과 같습니다.

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

프로세스의 6번째 단계를 “우리가 만든 자동차는 역사가 된다”로 적을 수 있는 자신감이 어디에서 나오는 것일까요?
이제부터 그들의 개발 프로세스를 좀 더 상세하게 살펴봅시다. 아래의 내용은 당시 2007년에 필자가 키노트 내용을 작성하여 보관해 두던 것입니다.

- 과거에 했던 실패의 원인을 찾고 고치기 위해 3주의 이터레이션 마다 20명의 팀원이 모두 참여하는 투표를 실시하고 서로의 의견을 교환하는 프로세스를 만들었습니다

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

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

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

- 우리는 지속적인 통합(Continuous Integration)을 사용합니다. 우리 시스템은 한번 클릭하면 100개 이상의 레거시 시스템과 새로 만든 시스템이 함께 통합되며 딜리버리 될 수 있게 구성되어 있습니다.
딜리버리를 너무 자주 수행하면, 문제가 생길 때마다 수정하는 시간이 늘어나고 요구사항이 밀려들며, 이 딜리버리 주기를 너무 길게 가져가면 요구사항은 상대적으로 줄어들더라도 통합할 때 엄청난 리스크가 발생합니다.
여러 시도에 의해 우리는 3~4일 정도의 빌드 및 딜리버리 주기를 가져가고 있다. 주로 밤에 자동으로 빌드를 돌립니다.

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

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

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

이들이 일하는 방법을 살펴보면, 약간씩 형태는 다르지만 마치 애자일을 한다는 팀에서 볼 수 있는 많은 수의 비슷한 노하우들이 녹아져 있습니다. 수십 년 동안 갈고 닦으며 만들어온 일하는 방식들이 마치 애자일의 스크럼이나 XP와 매우 유사한 형태로 발전하게 된 것입이다.

과연 어떻게 이러한 프로세스의 정착이 가능했던 것일까요?
필자가 생각하기에 이것이 가능했던 근본 원인은 위에서 언급한 내용 중 첫 번째 내용 때문입니다.

‘과거에 프로젝트를 실패하게 만든 원인을 규명하기 위해…(중략). 3주의 이터레이션 마다…(중략) 20명 모두가…(중략) 서로의 의견을 교환하는 프로세스를 만들었습니다.’

이 한가지 활동이 다른 모든 활동들을 만들어 내게 된 것이라고 할 수 있습니다.
이 핵심적인 활동으로 F1 페라리 팀은 스스로 점점 나아질 수 있는 팀이 되었습다. F1 페라리 팀은 3주마다 자신의 일하는 방법을 개선하기 위해 팀원 모두가 함께 참여하여 이야기를 했습니다.

그 이야기의 결과로 조금씩 개선해 나가는 ‘팀 단위의 지속적인 개선’의 방법들을 스스로 찾아 낼 수 있었다. 그 ‘팀 단위의 지속적인 개선’의 결과로 ‘고객과의 커뮤니케이션 단일화’, ‘위키를 통한 커뮤니케이션’, 지속적인 통합’, ‘스토리 카드’, 짝 프로그래밍’, ‘3개의 테스트 제품 만들기’ 등의 노하우가 쌓이게 된 것입니다.

사실 애자일 선언으로 모이게 된 XP, 스크럼, 린 소프트웨어 개발, 크리스탈 클리어 등의 방식들이 각자 다른 모습으로 프로세스화가 된 과정에는 F1 페라리 팀과 같은 동일한 과정이 있었습니다.

‘급속도로 바뀌는 환경에서 고객의 만족을 위해 짧은 주기 별로 개선해가며 노하우를 쌓는 방식’ 그것이 애자일의 핵심입니다. 그리고 이 과정으로 모인 노하우(애자일에서는 주로 프랙티스(Practice) 라고 한다)를 함께 공유하는 형태로 각각 프로세스의 적용이 이루어 집니다. XP 2007에 F1 페라리 팀이 초대된 이유도, ‘지속적인 개선’을 통해 자신의 팀이 세계 최고의 자동차를 만들어온 사례를 공유하기 위해서 였던 것입니다.

많은 사람들이 애자일을 한다고 하여, 앞서 언급했던 포스트잇을 통해 이슈를 공유하거나, 테스트 코드를 짜는 것, 또는 아침마다 서서 회의 하는 것 자체에 집착하는 경우가 많은데, 실제로 그 행위들 자체 보다 팀이 스스로 개선하는 문화를 가져가는 것이 훨씬 중요합니다.
실제로 XP 프로세스를 만든 켄트 백은 그의 책 ‘익스트림 프로그래밍’ 마지막에 다음과 같은 말을 남겼습니다.

“XP와 비슷한 모양새를 만들기 위해 XP를 흉내 내려고 하지 마세요. 대신에 XP를 실제로 발생하는 문제들을 해결하기 위해 적용하세요. 당신의 옷에 멋지게 적은 문구처럼 사용하지 마세요. XP는 지속적인 개선입니이다. “

XP와 비슷한 모양새를 만든다 라는 것은 지속적인 개선이라는 애자일의 가치 및 원리를 이해하기 보다 노하우 들 자체만을 따라 하는 내용이라고 볼 수 있습니다. 가치를 이해 하지 않고, 남들이 한다는 ‘테스트 주도개발’, ‘이터레이션’, ‘스탠드업 회의’ 들을 따라 하는 것입니다.

앞서 언급했던 두 가지 프로젝트 사례 즉, ‘포스트잇으로 이슈를 공유’하는 프로젝트와 ‘모든 코드에 테스트 코드를 작성’하는 프로젝트는 노하우를 ‘팀 단위의 지속적인 개선’의 사이클 없이 적용하는 사례입니다.
공감대를 가지고 팀이 함께 더 나아지기 실험하고 개선하는 과정을 겪지 않는 프로젝트는 애자일을 적용했다고 말하기 어려운 프로젝트입니다.

이 글을 읽는 분들은 앞으로 남들이 실천하여 만든 노하우 자체보다, 지금보다 나아지기 위해 무엇을 해야 하는가에 대한 고민을 할 수 있도록 해보기로 합시다.
이제부터 여러분의 애자일은 패어프로그래밍, 테스트코드, 포스트잇이 아닌 ‘좋은 SW 개발을 위한 지속적인 개선’이면 하는 바램이 있습니다.



▶   해당 콘텐츠는 저작권법에 의하여 보호받는 저작물로 기고자에게 저작권이 있습니다.
▶   해당 콘텐츠는 사전 동의없이 2차 가공 및 영리적인 이용을 금하고 있습니다.