샘플 – 에필로그

에필로그 –
애자일로 이동하기

등불 하나는 수천 년의 어둠을 물리치며, 번득이는 지혜는 수만 년의 무지를 멸한다. – 혜능

 

번득이는 지혜. 이것이 우리가 설명한 전부다. 이러한 애자일 실천방법에 대한 설명을 즐겁게 만끽하고 적어도 한두 개는 여러분의 지혜에 번득이는 불꽃으로 작용했기를 바란다.
지금까지 어떤 경험을 했든(경험이 매우 성공적이었거나 다소 도전적이었건 간에) 단 하나의 새로운 실천방법이 혼란을 날려 버리고 여러분의 삶과 경력을 진짜 다르게 만들 수 있다. 곤경에 빠진 프로젝트를 구해내기 위해서 이러한 실천방법의 부분 집합을 사용할 수도 있고 시간이 흐르면서 더 많은 실천방법을 도입할 계획을 세울 수도 있다.

 

새로운 실천방법 하나

실례로, 앤디의 이전 고객 사례 가운데 하나를 검토해 보자. 이 팀은 우뚝 솟은 유리로 만든 사무실에서 근무하고 있었고, 사무실은 빌딩 바깥쪽 벽의 우아한 곡선에 맞춰져 있었다. 모든 팀원이 창밖의 경치를 볼 수 있었고, 전체 팀은 빌딩의 절반을 고리 모양으로 차지했다. 그러나 문제가 있었다. 릴리스는 늦어지고, 버그는 손쓸 수 없게 늘어났다.
보통의 방법처럼, 실용주의 프로그래머들은 사무실 한 끝에서 출발해 팀원들이 무슨 작업을 하고 있는지, 어떤 것이 잘 작동하는지, 무엇이 방해하는지 알아내기 위해서 팀을 인터뷰했다. 팀은 클라이언트 서버 애플리케이션을 만들고 있다고 첫 번째 사람이 설명했다. 즉, 씬(razor-thin) 클라이언트와 모든 비즈니스 로직과 데이터베이스 접속을 포함하는 팻(fat) 서버를 포함한 애플리케이션이었다.
그러나 사무실의 긴 줄을 따라서 인터뷰를 진행하면서, 이야기는 조금씩 변했다. 사람마다 프로젝트의 비전이 약간씩 달랐다. 마지막으로, 줄의 끝에 있는 마지막 사람은 자랑스럽게 팻 클라이언트 같은 시스템이라고 설명했다. 즉, 클라이언트는 모든 GUI, 비즈니스 로직을 담고 있었으며, 간단한 데이터베이스를 제외하고 서버에는 아무것도 없었다.
프로젝트에 대해서 이야기하기 위해서 팀이 같이 모인 적이 전혀 없다는 사실이 명백해졌다. 그 대신에 각 팀원은 바로 옆에 있는 사람과만 이야기했다. 마치 초등학생의 ‘전화’ 놀이처럼, 메시지는 필연적으로 잘못 전해졌고 이 사람에서 저 사람으로 전달되면서 왜곡되었다.
실용주의적 충고는 무엇일까? ‘즉시 스탠드 업 미팅을 사용하라’였다(225쪽의 실천방법 38, 「정규 대면회의를 가져라」를 살펴보자). 그 결과는 빠르고도 놀라웠다. 아키텍처 이슈가 재빨리 해결되었을 뿐만 아니라, 더욱 심오한 일이 생겼다. 팀이 뭉치기 시작했다. 응집력 높은 단위를 형성하기 시작했고, 함께 일했다. 버그 비율은 떨어지고, 제품은 더욱 안정되었으며, 데드라인은 치명적이지 않았다.
오래 걸리지 않았으며, 많은 노력을 들이지도 않았다. 회의를 지키는 규율이 필요했지만, 곧 습관이 되었다. 단지 새로운 실천방법 한 가지였지만, 이 실천방법은 팀에 커다란 차이를 만들었다.

 

실패하는 프로젝트 구출하기

하나의 실천방법이 좋다면, 실천방법 전부는 더 좋을 것이다. 그렇지 않나? 결국에는 옳은 말이다. 그러나 한번에 모두는 아니다. 이미 문제에 빠진 프로젝트라면 특히 아니다. 한번에 모든 개발 실천방법을 바꾸는 것은 프로젝트를 죽이는 최선의 방법이다.
의학적 비유를 사용하여 가슴 통증이 있는 환자가 있다고 상상해보자. 물론, 환자가 정기적으로 운동을 하고 잘 먹는다면, 문제에 빠지지 않았을 것이다. 그러나 다음처럼 말해서는 안 된다. “침대에서 엉덩이를 떼고, 러닝 머신에서 달리세요.” 이것은 치명적이며 의료 과실 보험율을 높이는 확실한 원인이 된다.
최소한의(그러나 필수적인) 약과 절차를 사용해서 환자를 안정시켜야 한다. 일단 환자가 안정되고 나서 튼튼한 건강을 유지하기 위한 처방을 제시할 수 있다.
프로젝트가 어려움에 처했을 때, 우선 그 상황을 안정시키기 위해서 실천방법 몇 가지를 도입하기 원할 것이다. 예를 들어서, 벤캣은 장래의 고객에게서 공포심에 사로잡힌 전화 한 통을 받은 적이 있다. 그들의 프로젝트는 엉망진창이었다. 그들은 할당된 시간의 반을 사용했지만 인도해야 하는 프로젝트의 90펴센트가 아직 끝나지 않았었다.
개발자가 많은 코드를 빨리 만들어내지 못했기 때문에 관리자는 불쾌해 했다. 관리자가 너무나 심하게 몰아 붙여서 개발자도 맘이 조지 않았다. 그들이 하루 중 남은 시간을 버그 수정하거나 새로운 기능을 작성하는데 보내야 했을까? 이러한 위기상황에도 불구하고 팀은 진정으로 성공하기를 바라로 있었다. 그러나 그들은 어떻게 해야 할지 몰랐다. 그들이 하는 일마다 잘 안되었고 압박을 느꼈으며 편하게 의사 결정하지 못했다.
모든 것을 한꺼번에 고치려고 노력하는 대신에, 벤캣은 우선 환자를 안정시켜야 했다. 즉, 45쪽의 실천방법 3,「사람이 아니라 생각을 비판하라」, 225쪽의 실천방법 38,「정규 대면회의를 가져라」, 244쪽의 실천방법 43,「준비되었을 때만 코드를 공유하라」, 252쪽의 실천방법 45,「다른 사람에게 계속해서 알리기」와 같은 대화와 협업 중심적인 실천방법부터 시작해서 말이다. 안정되고 나서, 다음 단계는 간단한 릴리스 실천방법을 소개했다. 이러한 실천방법으로 96쪽의 실천방법 13,「코드를 릴리스할 수 있게 유지하라」, 101쪽의 실천방법 14,「일찍, 자주 통합하라」가 있다. 마지막으로 고객은 유용한 코딩 실천방법 몇 가지를 시작했다. 이러한 실천방법으로 203쪽의 실천방법 34,「경고는 진짜 에러다」, 208쪽의 실천방법 35,「문제를 격리해서 공격하라」가 있다. 이것들은 위기를 막아내기에 충분했다. 결국 계획보다 2주 앞당겨서 프로젝트가 끝났으며 상위 관리자에게서 갈채를 받았다.
이상은 응급 구조 모델이다. 상황이 급박하지 않다면, 애자일 실천방법을 도입하기 위해서 더 상세하고 더 신중한 접근 방법을 택할 수 있다. 여러분이 조직 안에서 앞서 가려고 노력하는 호기심 많은 개발자냐, 아니면 관리자나 팀 리더냐에 따라서 몇 가지 아이디어를 제시할 수 있다.

 

애자일 도입하기 : 관리자 지침

관리자나 팀 리더라면, 팀 전체를 하나로 모으는 데서 시작해야 한다. 애자일 개발은 개발자들이 일을 쉽게 하도록 지원하는 것이라는 사실을 명확하게 하자. 애자일 개발은 무엇보다 개발자의 이익을 위한 것이다(그리고 궁극적으로 사용자와 조직의 이익도 위한 것이다). 더 쉬워지지 않는다면, 무언가가 잘못된 것이다.
천천히 진행하자. 리더가 하는 어떤 작은 행동이라도 시간이 흐르면 확대되고 팀에 영향을 준다는 사실을 명심하자.
이러한 아이디어를 팀에 소개하며서, 33쪽의 2장「애자일 소개하기」에서 설명하였듯이 애자일 프로젝트에 기본 원칙을 반드시 도입하자. 이 기본 원칙이 프로젝트를 운영할 방법이라는 것을 모든 사람이 이해하게 하자. 즉, 단지 듣기에 좋은 소리가 아니라고 말이다.
스탠드 업 회의로 시작하자(225쪽의 실천방법 38,「정규 대면회의를 가져라」를 살펴보자). 팀이 서로 이야기를 나누고 중요한 이슈에서 동기화하는 기회를 스탠드 업 회의가 제공할 것이다. 고립된 아키텍트를 그룹에 데려 와서 아키텍트가 팔을 걷어붙이고 참여하게 하자(230쪽의 실천방법 39,「아키텍트는 코드를 작성해야 한다」를 살펴보자). 비공식 코드 리뷰를 시작하고(248쪽의 실천방법 44,「코드 리뷰」), 고객과 사용자를 관여시킬 계획을 작성하자(82쪽의 실천방법 10,「고객이 결정하도록 하라」).
다음으로 개발 기반(infrastructure) 환경을 차례로 도입해야 한다. 이것은 기본적인 시작 도구(Starter Kit) 실천방법을 채택하는(개선하는) 것을 의미한다.

– 버전관리
– 단위테스트
– 빌드 자동화

버전 관리는 다른 어떤 것보다 선행해야 한다. 이는 어떤 프로젝트에서도 제일 먼저 설정하는 인프라다. 일단 설치하면, 개발자가 사용하고 단위테스트를 운영하는 일관된 로컬 빌드 스크립트를 준비해야 한다. 스크립트가 돌아가면 개발이 진행 중인 모든 새로운 코드에 단위테스트를 만들 수 있으며, 필요하다면 기존 코드에 새로운 테스트를 추가할 수도 있다. 마지막으로, 남아있는 어떤 문제라도 생기자마자 잡아내기 위한 ‘안전그물’인 뒤에서 돌아가는 지속적인 빌드 머신을 추가하자.
이것이 여러분에게 낯선 분야라면, 가까운 서점(혹은 www.pragmaticbookshelf.com)으로 달려가서 『Ship It! A Practical Guide to Successful Software Projects』을 구입하자. 전체적인 설정을 하는데 이 책이 도움을 줄 것이다. Starter Kit 시리즈는 특정 환경에서 상세한 버전 관리, 단위테스트, 자동화와 관련해서 도움이 될 것이다.
이러한 인프라가 제자리를 잡으면, 리듬있는 개발 방식으로 틀을 잡아야 한다. 프로젝트의 타이밍과 리듬에 대한 감을 잡기 위해서, 79쪽의 4장「사용자가 원하는 내용을 제공하기」대부분을 다시 읽어 보자.
지금쯤은 기초가 모두 자리잡았기 때문에, 팀을 위해서 실천방법이 작동하도록 실천방법을 조정해야 한다. 125쪽의 5장「애자일 피드백」에 있는 내용을 검토하자. 설정하면서, 매일의 이슈룰 다루는 애자일 접근 방법에 대해서는 155쪽의 6장「애자일 코딩」과 197쪽의 7장「애자일 디버깅」을 다시 한번 살펴보자.
그리고 끝으로 중요한 것을 말하자면, 57쪽의 3장「애자일 키우기」에서 개략적으로 설명한 다른 실천방법과 점심 도시락을 도입하자. 팀이 반드시 함께 작업하게 만들기 위해서 223쪽의 8장「애자일 협력」에 있는 실천방법에 착수하자.
자주 프로젝트 회고(retrospective) 시간을 갖자(각 반복주기 끝이나 각 릴리스 끝에서 말이다). 팀에서 피드백을 받자. 무엇을 잘 했고, 무엇을 조정해야 하고, 어떤 일이 잘 되지 않았는지 말이다. 시도한 실천방법이 잘 되지 않았다면, 이 실천방법에 대한 ‘어떻게 느껴야 하는가?’와 ‘균형 유지하기’를 재검토하자. 그리고 어떤 점이 균형에서 멀어졌으며 어떤 점을 고칠 수 있는지 살펴보자.

 

애자일 도입하기 : 프로그래머 지침

팀에서 책임을 지고 있지 않지만 이러한 방향으로 팀을 몰아가고 싶다면, 여러분 앞에는 어느 정도의 도전이 놓여있다. 앞 절에서 나열한 실천방법을 모두 완수해야 한다. 명령이 아니라 실례를 보여줌으로써 이끌어야 한다.
속담에서 이르는 것처럼, “말을 물가에 데려갈 수 있지만… 여러분이 가장 좋아하는 코드 편집기를 사용하게 할 수는 없다.” 물론 이를 사용해서 진짜로 유익한 시간을 보내는 것처럼 보일 수 있다. 이익이 명확하다면, 팀 동료는 이러한 행동에 동참하기를 원할 것이다.
예를 들어서, 단위테스트는 시작하기에 적당한 지점이다. 자신의 코드에 단위테스트를 사용하는 것으로 시작할 수 있다. 짧은 시간 안에(몇 주 안에) 자신의 코드가 개선되는 것을 본다. 에러 숫자가 줄고 품질이 나아지며 코드의 건강 상태가 개선된다. 5시에 퇴근하기 시작하고 모든 작업이 완료된다. 한밤에 버그를 수정해달라는 공포의 전화를 받지 않는다. 여러분 옆 자리에 앉은 개발자는 여러분이 무엇을 다르게 하는지 알고 싶어하고, 소문이 퍼진다. 팀을 납득시키기 위해서 싸우는 대신에, 이제 그들이 최신의 실천방법을 습득하길 열망한다.
팀을 새로운 분야로 인도하고 싶다면, 여러분이 먼저 가는 것이 당연하다. 따라서 지금 당장 할 수 있는 실천방법부터 시작하자. 33쪽의 2장「애자일 시작하기」에 있는 대부분의 실천방법은 좋은 출발이다. 그러고 나서 코딩 지향적인 실천방법인 127쪽의 실천방법 19,「수호천사를 곁에 두기」, 133쪽의 실천방법 20,「만들기 전에 사용하라」와 155쪽의 6장「애자일 코딩」과 197쪽의 7장「애자일 디버깅」을 따르자. 여러분의 머신에 지속적인 빌드를 실행하여 문제가 일어나자마자 이것을 알 수 있다. 팀 동료들은 여러분이 예지력을 지녔다고 생각할지도 모른다.
얼마 지난 후 비공식적인 점심 도시락 세션(63족의 실천방법 6,「팀에 투자하라」)을 시작할 것이며, 애자일 프로젝트의 리듬이나 관심 있는 다른 주제에 대해서 이야기할지도 모른다.

 

책의 마지막 부분에 도달했다. 다음에 무슨 일이 생길지는 전적으로 여러분에게 달렸다. 자신에게 이러한 실천방법을 적용해서 개인적인 이득을 볼 수 있다. 아니면 팀 전체를 모이게 해서 더 좋은 소프트웨어를 더 빠르고 더 쉽게 개발할 수도 있다.
www.pragmaticprogrammer.com을 방문하길 바란다. 여기서 우리의 블로그나 다른 글뿐만 아니라 관련된 자료의 링크도 얻을 것이다.

 

여러분에게 감사의 말을 전한다.