애자일 마스터 책 리뷰 및 감상평

개발자라면 애자일 방식, 워터폴 방식 등등을 들어본 적이 있다고 생각이 드는데요. 그중에서도 애자일 방식이 많은 선호를 받고 있다고 이야기를 들었었습니다. 인터넷에 검색을 해 보고 그냥 '그런가 보다' 하고 넘어갔지만, 사실 예전 상사로부터 읽어봐라고 추천을 받고 나서도 꽤나 긴 시간 동안 전혀 읽지 않았던 책 '애자일 마스터'의 내용과 간단한 감상평을 알려드리겠습니다.

 

목차

 

 

'애자일이란 무엇인가?' 에 대한 저자의 답

애자일 마스터 책 내용 요약

1. 애자일 소개

매주 고객에게 가치를 전달하는 소프트웨어 개발 방법이라고 저자는 이야기합니다. 큰 문제들을 작은 문제로 나누고 가장 중요한 것에 먼저 집중하고, 다른 것들은 잊어버리며、소프트웨어가 제대로 작동하는지 확인하며, 고객에게 피드백을 구하고 필요하다면 계획을 바꾸는 방식입니다.

 

여기에서 강조하는 방식은 멋진 계획서나 우아한 디자인 등은 거의 아무 쓸모가 없다는 것입니다. 프로젝트 초기에 요구사항을 모두 수집하기는 불가능 하니, 우선순위를 세워 작은 형태로 계속 릴리즈를(주 단위 혹은 2주 길어도 1달은 넘지 않게) 하며 고객에도 적극적인 참여를 요청해서 계속적으로 피드백을 받는 것이 중요하다고 합니다.

 

그렇기 때문에 참가하는 멤버들도 완벽하게 한 가지의 역할만 하는 것이 아닌 전체가 한 팀으로 움직이는 것이 중요하다고 합니다. 애자일에서 가장 중요한 것은 '고객의 만족' 이기 때문에 개발팀에 소속된 모두가 같이 일해야 하며, 한 가지 역할만 하는 것이 아닌 제너럴리스트가 되어야 된다고 합니다.

 

2. 애자일 프로젝트 인셉션

이제 애자일 프로젝트를 실행하기 전에 팀 안에서 어떤 프로젝트를 실시하고 있는지 모두에게 명확하게 이해시키는 것이 중요합니다. 이를 위해 프로젝트가 성공했을 때 무언이 가능해지는 건지, 실패했을 때는 무언이 가능해지지 않는 것인지 팀에 참여한 모두가 명확하게 이해하여야 합니다.

 

인셉션 덱을 이용하여 프로젝트가 무엇을 위한 것인지에 대해 명확하게 하는 것이 중요하다고 합니다.

인셉션 덱의  핵심 내용은 아래와 같습니다.

1. 우리가 왜 여기 모였는지 물어보라.
2. 엘리베이터 피치를 만들라.
3. 제품의 광고를 디자인하라.
4. NOT 리스트를 작성하라.
5. 프로젝트에 관계된 다양한 사람들과 알고 지내자.
6. 해결책을 보여주라.
7. 미리 야근 거리가 될 만한 것을 찾아보자.
8. 규모를 정하라.
9. 우선순위를 파악하라.
10. 기회비용이 무엇인지 파악하라.

등의 내용입니다. 각각의 내용들을 간단한 인덱스카드에 적어서 그것들에 대해서 모두가 명확히 이해하도록 하는 것입니다. 그리고 어떤 기술로 문제를 해결할 것인지, 또한 각각의 일들을 작은 단위로 나누어서 세분화하였을 때 문제가 될만한 일이 어느 곳에 있을 것인지 파악하는 것이 이 인셉션의 핵심이라고 볼 수 있습니다.

 

그러면서 마지막으로 강조하는 4가지 항목이 있습니다. 바로

시간, 비용, 품질, 범위입니다. 모든 프로젝트는 바로 이 4가지의 항목에서 문제가 발생하게 됩니다. 그럼 이때 리더는 어떤 결정을 해야 할까요? 시간을 줄이기는 힘들고 비용을 더 올리기도 힘들며 품질을 낮추면 완성된 시스템은 엉망이 됩니다. 범위를 줄이면 고객이 만족하지 않게 됩니다. 

저자는 범위를 줄이는 게 최선의 방법이라고 이야기합니다. 계획했던 대로 현실이 따라주지 않는다면, 현실이 아니라 계획을 바꿔야 한다고 합니다.

 

3. 애자일 프로젝트 계획하기

요구사항을 지나치게 문서화하는데 공을 들이지 않는 것이 중요하다고 이야기합니다. 그리고 저자는 요구사항이 아니라 스토리라는 개념을 이야기하는데요. 바로 고객이 만들고자 하는 기능 서비스 등을 스토리라고 이야기합니다. 그런 고객의 스토리들을 묶어서 스토리 보드로 만들어 그 스토리 보드를 기반으로 앞으로의 작업을 예측해야 한다고 합니다.

 

실제로 사용자의 요구사항을 모아 프로젝트가 절반 정도 흘러갔음에도 불구하고 사용자(고객)가 지금 만들고 있는 것이 본인이 원하는 것이 아니라는 것을 깨닫는 경우가 많이 있다는 것이죠. 그래서 고객의 스토리를 들을 때는 설명할 때도 고객이 충분히 이해할 수 있는 용어로 설명을 해야 한다고 말합니다.

 

또한 무조건 서류 작업을 하면 안 된다의 개념이 아니라 최소화하는 것이 핵심입니다. 정말 중요한 것은 문서로 남기는 것이 중요합니다만, 그 문서를 작성하기 위해서 과도한 시간과 에너지가 들어가는 것을 경계하는 것이 중요하다고 합니다. 그래서 요구사항은 나중에 만들더라도 우선은 작고 간단하게 고객의 스토리들을 빠르게 만들어 어떤 작업을 해야 하는지 효율적으로 파악하는 게 중요하다고 합니다.

 

고객의 스토리들을 파악하고 나면 각각의 스토리를 비슷한 기능들로 묶어서 각 스토리당 구현 점수를 매기는 것이 중요하다고 합니다. 스토리를 다 만들면 사용자(고객)에게 이 스토리들이 맞는지 재 확인하고 팀원 전원을 모아 각각의 스토리를 구현하는데 얼마나 어려울지 시간이 걸릴지를 다 같이 상의하는 것이 중요하다고 합니다. 그렇게 각각의 스토리별로 각각의 점수를 매기고 작업 완성 추정치를 만들어 실제로 프로젝트를 실행합니다.

 

실제로 프로젝트를 진행하면 높은 확률로 계획했던 속도보다 실제 속도가 빠르지 않다는 것을 깨닫게 됩니다. 그럼 낙심할게 아니라 실제 한 개의 작업량을 팀의 업무 속도로 나누어서 각각의 이터레이션을 재 계산합니다. 이렇게 하면 구현할 수 없는 몇 개의 기능들이 생길 수 있는데요. 이때 고객과 다시 재 논의를 하는 게 중요합니다.

 

프로젝트에서 정말로 중요한 핵심 기능을 가리는 우선순위를 명확하게 하고 '있으면 좋지만 없어도 딱히..'라는 생각이 드는 기능들을 고객에게 버릴 수 있도록 설득하는 게 중요하다는 의미입니다. 물론 설득이 되지 않으면 필수 기능이 아닌 기능까지 포함하여 실제로 배포하는데 까지 걸리는 시간이 얼마인지 고객에게 솔직하게 이야기해야 합니다.

 

4. 애자일 프로젝트 실행

이제 실제 프로젝트를 시작합니다. 실제 프로젝트를 시작하면 이터레이션(고객에게 가장 가치 있는 스토리를 작동하는 소프트웨어로 개발하는 1~2주간의 기간)을 관리해야 합니다. 그리고 매주 고객에게 스토리를 전달해야 합니다.(1~2주간을 이야기합니다.)

 

분석, 개발 그리고 테스트 이러한 과정으로 프로젝트는 실행이 되는데요. 분석에 과도하게 힘을 빼면 안 된다고 이야기하며, 서류화는 정말 꼭 필요할 때 1장 정도의 분량으로만 만들어라고 합니다. 물론 팀의 규모에 따라 이 부분은 달라질 수 있지만, 요지는 최소한으로 분석하고 필요한 만큼만 적당히 분석하라는 것입니다. 

 

순서도로 단순하고 시각적이며 시스템이 어떻게 작동하는지 사람들이 거쳐야 하는 단계를 한눈에 모여주고 디자인 등도 종이에 간단한 프로토 타입을 그려가면서 생각하라는 것입니다.(이때 여러 명이 같이 하는 것이 좋다고 이야기합니다.) 그리고 스토리가 완성된걸 어떻게 알 수 있는지 고객에게 물어보고, 테스트 기준이 무엇인지에 대해서 스토리가 성공적으로 완성되려면 무엇을 어떻게 만족해야 하는지 분명하게 이해하여야 한다고 합니다.

 

그리고 프로젝트를 실행하면서 테스트를 베이스로 개발하고 마지막에는 고객에게 인수 테스트를 맡겨야 한다고 합니다. 인수 테스트를 할 때쯤에는 시스템에서 아무런 문제도 찾을 수 없어야 한다는 것이 핵심이라고 합니다.

 

애자일 커뮤니케이션 계획을 세워 팀원 간에 커뮤니케이션을 어떻게 해야 하는지 효과적으로 이야기하는 것이 중요하다고 합니다. 이때 고객에게 피드백을 받는 부분도 포함됩니다. 팀원들과는 스토리 계획 회의를 가져 각각의 스토리를 해결해 가면서 고객에게 완성한 스토리들을 보여주고, 내부에서는 다음 이터레이션을 계획하는 과정들을 반복하는 것이 중요하다고 말합니다.

 

그리고 내부적으로 미니 회고를 진행하여 잘하고 있는 게 무엇인지, 좀 더 향상해야 할 부분은 무엇인지 알아보아야 합니다.

 

5. 애자일 소프트웨어 만들기

애자일 방식에서는 테스트를 매우 중요하게 생각하고 있습니다.

• 단위 테스트
• 리팩터링
• 테스트 주도 개발
• 지속적인 통합

이것들이 바로 여기에 해당합니다. 개발을 할 때 단위 테스트는 마치 갑옷과 같이 본인을 보호해 주는 도구로 생각하여야 한다고 합니다. 개발이 잘 되었는지 단위 테스트를 통해 확인할 수 있기 때문이죠. 그리고 구현이 되었더라도 기술적인 부채를 갚아야 한다고 합니다.

 

바로 리팩터링을 이야기하는 것입니다. 간단한 변수명을 바꾸는 것 부터해서 메서드 호출명 그리고 읽고 파악하기 쉽게 유지 보수하기에 좋게 모든 코드들을 리팩터링 하여야 한다고 합니다. 빚(코드 부채)이 많이 쌓이기 전에 매일, 매 순간 리팩터링을 하는 것이 중요하다고 이야기합니다.

 

이제 드디어 논란의 테스트 주도 개발입니다. 코드를 쓰기 전에 만들고자 하는 코드로 무엇을 성취하고자 하는지 명확하게 하는 실패하는 단위 테스트와 성공하는 단위 테스트를 먼저 만드는 것이 바로 이 테스트 주도 개발입니다. 말도 많고 탈도 많은 개발 방법이죠.

 

미리 테스트 부분을 만들고 그리고 그 테스들이 통과하도록 코드를 짠다는 개념입니다. 제가 프로그래밍을 처음 배울 때 for문과 if문을 제대로 이해하지 못했을 때 나름대로 꾀를 내어 사용했던 방법이 이와 유사했었는데요. 여기에서는 실패하는 테스트 코드를 쓰고 이 테스트를 통과시킬 코드를 쓰고, 리팩터링을 합니다. 그리고 그 과정을 반복하는 것입니다.

 

마지막으로 지속적인 통합입니다. 보통 릴리즈 단계, 즉 출시 단계에서 많은 문제들이 일어나게 됩니다. 저자는 이에 대한 해결책을 간단하게 이야기합니다. 매일 코드들을 통합해라는 것입니다. 매일 소스코드들을 통합하면 자잘한 문제들은 초반에 해결이 되고, 각각의 코드들이 문제를 일으킬 확률이 현저하게 낮아진다고 이야기합니다. 마치 TDD(테스트 통합 개발)을 하는 것과 같이 매일, 매 순간 코드들이 통합을 하는 것이 좋다고 이야기합니다.

 

애자일 마스터 책 감상평

애자일 방법이 얼마나 효과적인지 이 방식으로 일하는 것이 얼마나 효율적인지에 대해서 설명하고 있는 책입니다. 하지만 저자는 세상에 완벽한 애자일 방식은 없다고 단언하고 있습니다. '당신이 완벽하게 애자일을 실행하고 있다고 생각한다면 그것은 애자일 방식이 아니다.'라고 이야기하는데요. 

 

요지는 조금 더 효율적인 개발 방식, 좀 더 효율적인 커뮤니케이션 방식, 팀이 마치 하나의 생물체처럼 움직일 수 있도록 계속해서 고민하고 노력하고 있다면 그것이 애자일 방식이며 거기에 따로 정해진 형식은 없다는 것이 저자의 주장입니다. '개발과 관련된 서류들도 물론 중요하지만 그보다는 정상적인 움직이는 소프트웨어를 개발하는 것이 더 중요하다'는 저자의 생각에 깊은 공감을 하였습니다.

 

또한 TDD 방식(테스트 주도 개발) 혹은 2인 1조로 코드를 만드는 것 등은 이전에 제가 생각해보지도 못했던 개념들이었습니다. 나름 신선(?)한 방식이라는 생각이 들었으며, 실현 가능성과는 별도로 저자가 말하고자 하는 의도에는 공감이 되었습니다.

 

개발자라면 한 번쯤 읽어보면 좋을 책이며 PM, PL 등의 프로젝트 매니저 혹은 관리자의 위치라면 꼭 한 번쯤 읽어보면 좋을 것 같습니다. 그럼 여러분의 프로젝트가 부디 안녕하기를 기원하면서 마치겠습니다.