by
Feb 08. 2021
3장: 애자일 전도사#1
#3-1 오해
이번 장은, 필자가 본격적으로 전사를 대상으로 하는 애자일 전도사(에반젤리스트)로 나서게 되면서 겪은 다양한 경험을 담고 있다. 특히 대형 프로젝트에서 억지로 애자일 방식을 수행해서 얻은 것과 잃은 것에 대해 상세히 다룬다. 그리고 SI 구축형 사업에서 프로세스만 애자일로 변경했을 때 어떠한 결과가 있었는지의 경험 등을 함께 이야기해보겠다.
가장 먼저 #3-1은 애자일에 대한 여러 가지 오해에 대해 다룬다. 앞서 언급된 애자일의 본질인 '지속적인 개선'과 거리가 먼 형태로 진행된 프로젝트 경험을 전달하면서 이 오해들을 한 가지씩 설명한다. 두 번째로 #3-2에서는 100명 이상의 대규모 프로젝트를 애자일 코칭할 때의 시도와 경험을 담았다. #3-3 에서는 애자일 아키텍처라는 개념과 이를 적용한 현장에 대한 이야기를 담았다. 마지막으로 #3-4는 우리가 습관처럼 작성해온 문서에 대해 함께 생각해볼 수 있는 내용을 넣었다.
['09 ~ '10년: 애자일 전도사]#3-1 오해
'09년 초였다. 필자는 보다 큰 도전을 위해 팀을 이동하게 된다. 전사적 관점에서 다양한 프로젝트들을 경험하고 시었고, 이를 통해 애자일 전문가로 성장하고 싶은 욕심이 컸다.
같은 시기에, '애자일'이라는 용어는 사내에 유행처럼 번져가기 시작했다. 이곳저곳에서 애자일을 적용해보겠다는 곳들이 생겨났고, '저는 사실 한쪽 도메인의 프로젝트밖에 해본 적이 없어요'라고 말해도, 당시 사내 경험자가 전무한 터라 필자를 찾았다.
갑자기 전문가가 된 격이었다. 하지만, 어려서 그랬을까? 이 일을 잘하고 싶었고 잘할 수 있다는 근거 없는 자신감이 있었다. 이곳저곳을 열심히 다니며 프로젝트 구성원들과 대화하며 필자의 애자일 경험을 이야기하고 도움이 될 수 있는 방법을 찾아다녔다. 이 즈음부터 필자는 실질적인 애자일 코치의 역할을 수행하며 프로젝트들을 다니게 된다.
당시 프로젝트들을 다니며 필자는 아래와 같은 다양한 질문들을 들었다.
“포스트잇으로 이슈 공유하는 게 애자일 아닌가요?”
“지속적인 통합 하면서 테스트 코드를 쓰면 애자일이죠?"
“문서를 하나도 쓰지 않아도 되는 기가 막힌 개발 방법론이 있다면서요?"
“짝 프로그래밍은 한 명의 공수를 고스란히 낭비하는 것 아닌가요?”
“아침마다 서서 이야기하는 방법론 아닌가요?”
1, 2장의 이미 읽은 여러분들에게 위와 같은 질문들은 가벼운 농담처럼 들릴지도 모른다. 하지만, 여전히 많은 사람들이 “지속적인 개선”이라는 애자일의 본질을 모르는 경우가 많았다. 당시, 심지어 애자일을 통해 기존의 상명하복의 문화를 보다 강력하게 추진하는데 쓰려는 관리자들도 있었다. (물론 현재도 그렇다.)
이번 장에서는 이러한 오해들에 대해 이야기해보고 싶다. 위에 코멘트들을 대상으로 실제 경험한 프로젝트 들의 상황을 이야기해보려고 한다. 이를 통해 이 책을 읽는 분들은 비슷한 문제를 겪지 않으면 좋겠다. 그럼 시작해보자.
* 오해#1
“포스트잇으로 이슈 공유하는 게 애자일 아닌가요?”
이 내용이 잘못된 생각이라는 것을 증명하기 위해 실 사례를 예로 들어보겠다.
A 프로젝트는 200여 명의 개발자가 일하는 규모이다. 14개월간의 프로젝트 기간 동안 많은 사람들이 프로젝트 성공을 위해 노력했지만 워낙 대규모 작업이다 보니 이슈도 많고 탈도 많다. 이러한 상황을 지켜보던 당시 프로젝트의 총괄 관리자가 고심 끝에 무언가를 결심한다. 그리고 이젤 패드를 전체 벽면에 붙이라고 지시한다. 그리고 모든 중간관리자들을 모아 다음과 같은 이야기를 한다.
“오늘부터 우리는 애자일을 하겠습니다. 포스트잇을 이용하여 이슈를 벽에 붙이고 공유해 주세요. 이슈는 작성자, 담당자, 이슈 내용 이렇게 간단히 세 가지만 적죠? 해결되지 않는 이슈에 대해서는 작성자 및 담당자와 제가 직접 면담을 하며 해결하겠습니다."
모든 중간관리자들이 이 내용에 대해 동의하고, 중간관리자들은 해당 내용을 각 팀의 개발자들에게 전달한다. 하지만 며칠이 지나도 아무런 이슈가 붙지 않는다. 누구든 먼저 작성하여 그 하얀 바탕의 이젤 패드에 뭔가를 적어 문제를 만들려고 하지 않는다. 며칠간 이 현상을 지켜보던 프로젝트 관리자는 자신의 지시를 듣지 않는 팀원들에 대해 짜증이 난다. 기다리다 못해 한 팀에 찾아가 다음과 같이 말한다
“오늘까지 자기 팀 벽에 이슈 전체 채워!”
그 날이 다 가기 전, 커다란 이젤 패드 한 장에 다닥다닥 소프트 잇으로 작성된 이슈들이 꽉 채워진다. 다음 날 더 놀라운 일이 벌어진다. 나머지 팀들의 이젤 패드 전체가 이슈들로 꽉꽉 차게 된다.
[사진#1: 프로젝트의 이슈 보드]이젤 패드 전체에 이슈가 꽉꽉 차게 된 이유는 무엇일까? 갑자기 하루 사이에 정말 많은 이슈가 발생한 것일까?
물론, 아니다. 우리는 이렇게 많은 이슈가 전체를 채우게 된 이유를 그 이슈들을 살펴보면서 알 수 있었다. 대분의 이슈 내용을 보면 이슈를 해결해야 할 책임자들이 작성자가 속한 팀에 없었다. 다시 말해, 그들이 붙여 놓은 이슈에는 해결해야 할 담당자가 언제나 다른 팀에 있다. 이를 통해 '우리 팀은 잘하고 있는데, 다른 팀의 도움이 부족해 우리 팀이 제대로 일할 수 없는 것이다'라는 책임 회피를 이 이슈들을 통해 진행하고 있는 것이다. 물론 이슈를 적고 이젤 패드에 붙일 때, 타깃이 된 다른 팀과의 사전 논의는 없다.
우선 채우라고 했으니, 어쩔 수 없다는 모종의 합의로 그냥 일단 적는다. 해당 이슈를 본 다른 팀의 팀원들은 자신들이 해결하지 못해 무엇인가가 안되고 있다는 이슈 내용을 보고, 그 이슈를 해결하기보다는 그 이슈를 작성한 팀이 발생시킨 또 다른 문제를 이슈로 제기하여 이젤 패드에 붙인다. 이슈를 공유하여 협업을 하려는 팀이 아닌, 이슈를 통해 팀 간 전쟁을 하고 있는 것이다.
이 팀은 애자일을 하는 팀인가? 여러분은 동의하기 어려울 것이다. 애자일을 이야기하는 사람들은 늘 동시에 긴밀한 협업과 자율화 시스템(Autonomous System)에 대해 이야기하는데, 위 사례는 분명히 그런 모습은 아니다. 분명히 적극적으로 이슈를 공유하고 커뮤니케이션하고 있으나, 무엇인가 애자일을 구성하는 큰 것이 결핍된 느낌이 들 것이다.
* 오해#2
비슷한 사례로, “지속적인 통합을 통해 테스트 코드를 작성하다”에 걸맞은 프로젝트 사례를 한 개 이야기해보겠다.
“지속적인 통합 하면서 테스트 코드를 쓰면 애자일이죠?”
B 프로젝트는 솔루션을 구축하는 사업이다. 프로젝트의 전체 아키텍처 표준을 정하는 소프트웨어 아키텍트는 프로젝트 시작 시점에 매우 강력한 주장을 한다. 솔루션에 걸맞은 자동화된 테스트 코드를 만들어야 한다는 것이다. 일정이 빠듯하지만, 관리자들은 그의 의견을 존중하여 모두가 테스트 코드를 만들기로 결정한다. 여기까지는 좋았으나, 실제 문제는 테스트 코드 작성에 대해 익숙한 개발자가 프로젝트 내부에 거의 없다는 것에서 시작한다.
이를 상쇄하기 위해, 자동으로 생성해주는 테스트 코드 프레임웍을 도입한다. 스프링 프레임웍의 서비스에서 실제 데이터 베이스까지 생성/수정/삭제/조회를 하는 모든 메서드를 대상으로 만들기로 한다. 하지만 실제로 테스트 코드가 데이터 베이스에 데이터를 수정해버리면, 문제가 발생할 수 있기 때문에 테스트 코드를 위한 공통 코드를 만들어 커밋(Commit) 하지 않고 롤백(Roll Back)하는 코드를 삽입하였다.
소프트웨어 아키텍트는 이 테스트 케이스들은 실제 데이터를 수정하지 않는 테스트 케이스기 때문에 시스템 운영에 아무런 문제가 되지 않을 것이라 자신한다. 개발자들은 기계적으로 자동화된 툴을 이용하여 각 서비스의 메서드에 맞는 20~30개의 파라미터의 집합인 데이터 셋의 값들을 아무런 의미가 없는 값들로 넣고 테스트 케이스를 생성한다. 심지어 Null 값을 넣기도 한다. 그리고 테스트 실행을 해보고, 항상 성공할 테스트 케이스라 확신하는 테스트 케이스를 만들어낸다. 테스크 코드에 어떤 값을 넣는지는 누구도 감독하지 않는다. 전사에서 나온 품질 담당자 또한 본인들이 세운 체크리스트와 품질 기준인 테스트 커버러지만 신경을 쓴다. 개발자들은 커버러지를 충족시키면서 동작하는 한 테스트 코드는 품질 기준으로 볼 때 부족함이 없는 코드이다.
이후 이상한 일들이 계속된다. 테스트 코드를 생성했을 당시에는, 항상 성공하던 테스트 코드가 자주 실패하기 시작한 것이다. 되다가 안 되다 하는 결함(Flaky Test라고 함)이 발견된다. 그리고 실패가 나는 테스트가 여기저기서 목격된다. 이러한 일이 발생하는 이유는 테스트 코드가 데이터에 종속되기 때문이다. 즉, 아무리 롤백을 하더라도, 더미 값으로 파라미터의 값을 채우는 순간 이미 존재하는 값들과 중복될 수 있는 가능성이 발생하는 것이다.
200명의 개발자 중 한 명이라도 파라미터의 더미 값과 비슷한 값을 테스트를 위해 데이터 베이스에 직접 넣으면 특정 테이블 속성의 값이 중복되는 경우가 발생할 수 있는 것이다. 결국 앞서 말한 이유로, 개발자들은 테스트 코드의 결함이 품질을 관리하는데 큰 도움이 되지 않는다는 인상을 받게 된다.
자, 이 팀은 테스트 코드를 짜고 있고, 지속적인 통합 툴에 엮어 이 테스트 코드들을 실행하고 있다. 과연 이 팀은 애자일을 하는 팀인가? 쉽게 긍정하기 어려울 것이다. 분명히 애자일에서 말하는 테스트 코드를 작성하고 있지만, 무엇인가 다른 중요한 가치가 부족한 것으로 보인다.
* 오해#3
“문서를 하나도 쓰지 않아도 되는 개발 방법론이 있다면서요? “
“문서를 쓰지 않는 개발 방법론”이라는 말은 애자일에서 이야기되는 가장 큰 오해 중 하나다.
우선 개발 방법론이라는 말에 대해 잠깐 생각해보자. 개발 방법론이란 무엇인가? 위키피디아에서는 소프트웨어에서의 개발 방법론을 다음과 같이 정의한다.
“소프트웨어 엔지니어링에서 소프트웨어 개발 프로세스는 설계, 제품 관리, 프로젝트 관리를 수행하는 공정을 명확한 단계로 나타낸 프로세스를 의미한다. 이는 소프트웨어 개발 라이프사이클이라고도 말한다. 이 방법론은 일반적으로 프로젝트 팀이 개발 또는 유지보수를 위해 필요한 상세한 딜리버리 결과물이나 산출물 등을 포함한다"
지속적인 딜리버리라는 개념을 최초로 정리한 제즈 험블은 GOTO 2016 콘퍼런스에서 개발 방법론에 대해 다음과 같이 이야기했다.
“소프트웨어 개발 방법론이란 인덱스가 있는 사전과 같은 것이다. 내가 현재 수행하는 어떤 단계에 무엇을 해야 하는지 찾고 싶으면, 그 사전에서 내가 수행하는 단계의 무엇을 하고 있는지 찾을 수 있다. 거기에는 그 무엇(Activity)에 대한 정의, 수행하는 방법, 그 내용을 수행하는데 필요한 입력 물과 결과물을 찾을 수 있다. “
1, 2장에서 읽은 내용을 여러분이 함께 공감한다면, 먼저 이렇게 이야기하고 싶다. 우선 애자일은 개발 방법론이 아니다. 때문에 내가 어떤 액티비티를 하고 있는데, 입력은 무엇이고 결과는 무엇인지 정의되지 않았고, 이 부분을 실제 수행하는 사람에게 맡긴다. 현재 상태를 진단하고 더 낫게 만들기 위해 팀이 판단하고 개선하기를 기대한다.
이러한 개선을 바탕으로 소프트웨어를 개발할 때 가장 좋은 방식이라고 주장하는 사람들의 의견을 패턴으로 묶어놓은 레퍼런스이다. 때문에 스크럼, XP, 린 소프트웨어 개발, 크리스털 클리어와 같은 형태로 다양한 프로세스로 현장에서 실현된 것이고 당연히 그 프로세스들마다 작성해야 할 문서도 상이하다. 때문에 애자일이면 반드시 작성해야 하는 문서 같은 것은 그 회사가 정하지 않는 한 없다.
대신에 문서 자체의 본질을 강조한다. 문서는 본래, 커뮤니케이션을 위해 작성하는 것이다. 다른 사람에게 정보를 전달하기 위한 것이 문서의 주목적이다. 때문에, 문서가 없더라도 커뮤니케이션이 가능하고 지속적으로 보관할 필요가 없다면 문서화하지 않고 직접 그 사람을 찾아가 이야기하길 권장한다. 만약 코드로 모든 것을 말할 수 있다면, 문서 자체도 필요가 없어질 것이다.
그렇다면 왜 다들 애자일 필수 문서를 찾는가? 애자일에서 필수 문서가 필요한 경우는 보통 이를 회사의 필요로 방법론화 할 때 생겨난다. 세일즈포스의 ADM(Adaptive Delivery Methodology), IBM의 이클립스 웨이처럼 회사는 소프트웨어 개발 생산성을 높이기 위해 애자일 방법론을 회사에 맞게 표준화하기도 한다. 하지만 이들도 애자일의 철학은 그대로 따른다. 문서 자체보다 본질을 추구한다. 즉, 불필요한 문서를 지양하고 필요한 문서를 만든다. 또한 프로세스보다 제품 중심의 사고에 집중한다.
가장 대표적인 필요한 문서는 프로젝트 차터이다. 이 문서를 통해 개발팀원들 간 함께 인지해야 할 제품에 대한 비전을 명시하고 이를 기반으로 커뮤니케이션하게 만든다.
프로젝트 목표
프로젝트 추친 배경 및 산출물, 기간
프로젝트 범위
프로젝트 추진 계획(단계별 세부 활동)
프로젝트 팀 소개
프로젝트 전체 추진 일정
품질 관리 및 커뮤니케이션 계획
방법론화를 하더라도 애자일의 경우 가장 큰 차이로 중점을 두는 것은 프로덕트에 대한 관리이다. 가장 빠른 시기에 동작하는 제품을 보여주고, 그것 중심으로 이터레이션을 통해 진척과 이슈를 공유하기에 이전에 설계문서가 어떻게 쓰였는지에 대한 고민은 사실 크게 중요하지 않다. (물론 비즈니스 로직이 매우 복잡하고 코드만으로도 내용을 파악하기 어려운 제품은 예외로 두자)
또한 일반적으로 형태에 대한 제약이 없다. 문서는 커뮤니케이션을 위한 것이기에, 꼭 종이 문서로 프린트하지 않아도 된다. 위키 형태로 보관하거나 사용자 스토리 아래 함께 추가 정보를 넣거나 해서, 팀원들과 함께 공유할 수 있으면 되는 것이다. 보통 회사의 거버넌스와 엮여 보관에 대해서는 표준화되는 경우가 많은데, 이는 전사로 보면 더 큰 가치를 만들 수도 있기에 필요하다.
만약 주변 누군가가 “문서가 없는 방법론"을 찾는다면, 해당 프로젝트 도메인에 대해 먼저 질문하고 프로젝트 수행 내내 문서가 없어도 이해관계자와의 원활한 정보공유가 가능한 지 물어보자. 만약 아니라고 한다면, 어떠한 형태로든 문서는 필요할 상황이고, 애자일을 활용한다고 해서 문서가 사라질 수는 없다고 이야기해야 한다.
* 오해#4
“페어 프로그래밍은 한 명의 공수를 고스란히 낭비하는 것 아닌가요?”
XP를 이야기하면 가장 먼저 들을 질문이 바로 페어 프로그래밍에 대한 공수 낭비이다. 표면적으로 보면 두 사람이 한 컴퓨터를 가지고 일하는 것이기 때문에 이에 대한 질문은 어찌 보면 당연한 것이다. 이에 대한 경제성에 대해 1995년부터 2010년까지 다양한 조사가 이루어졌는데, 논문들에 따르면 두 명이 개별로 코딩하는 것이 200%의 생산성이라면, 페어 프로그래밍을 수행할 때 115% 에서 400% 까지 생산성을 낼 수 있는 것으로 실험이 되었다.
생산성은 무엇을 위해 페어 프로그래밍을 하느냐에 따라 구분 지어진다. 예를 들어 아래 그림에서 보면, 만약 해야 할 일이 너무 쉬운데, 두 명의 개발자의 개발 실력이 뛰어날 경우 이는 분명한 공수를 낭비하는 것이고, 만약 해야 할 일이 너무 어려운 경우에, 두 명의 개발자 개발 실력이 부족할 경우에도 진도가 나가지 않는 것으로 관찰되었다. 이 두 경우가 아니라면 대부분의 경우에 짝 프로그램이 도움이 된다.
