[클린소프트웨어#1] 애자일(Agile) 방법론과 4가지 가치와 12개의 원칙

# 시작하기 전

 근래 디자인패턴이라는 것에 관심이 많았고, 학부에서 소프트웨어 디자인패턴이라는 수업을 수강중에 있다. 해당 수업에서는 "클린 소프트웨어"라는 책과 "GOF 디자인패턴" 이라는 책을 교과서로하여 수업을 진행 중이다. 클린 소프트웨어에서는 중간절까지 배우며 애자일과 SOLID원칙에 대해서 공부하고, GoF에서는 실제 디자인 패턴들에 대해서 공부한다. 시험기간이 다가 오고, 시험 문제가 다 서술형이라는 것을 감안했을 때 책을 요약해보고 정리하는 시간이 시험공부에 대해서도 꽤 도움이 될 것이라 생각함과 동시에 아카이브화 하여 나중에 필요하면 다시금 돌아 볼 수 있도록 해당 블로그에 정리해보려고 한다.

 이게 수업하면서 1회독했을때와 지금 다시 읽으니까 한층 이해가 쉽고 안보이던게 보여서 좋다.

 

# 애자일(Agile)이 뭐길래?

 [쏘카 개발 문화를 소개합니다]
• 권위적인 리더가 없습니다
• 오로지 권한을 위임하고, 장애물을 제거해주고, 조직원의 성장을 지원하는 리더만 존재합니다.
• 밀어내기가 아닌 당겨오기로 일합니다
• 개발자를 생산 기계 취급하며 데드라인을 고정하고 일감을 우겨 넣지 않습니다.
• 개발팀은 비즈니스 우선순위로 정렬된 백로그에서 자신들의 Cycle time에 맞추어 업무를 당겨와 구현합니다.
• 진척도를 묻는 질문에 답하기 위해 하던 일을 멈추지 않습니다.
• 하던 일을 멈추고 다른 일을 하라고 요구 받지 않습니다.
• 개발자는 담당한 업무 완수에 온전히 집중할 수 있습니다.
• 데드라인이 아닌 높은 품질이 목표입니다
• 데드라인을 맞추기 위해 품질을 포기하지 않습니다.
• 데드라인을 맞추기 위해 개발자를 희생시키지 않습니다.
• Cycle time 안에서 구현할 기능의 수를 개발자가 결정합니다.
• 우선순위를 기반으로 품질 높은 기능을 지속적으로 구현합니다.
• 개인의 성장이 조직의 목표입니다
• 개인의 성장 없이 조직이 성장할 수 없습니다.
• 좋은 동료, 리더와의 협업을 통해 고객 가치가 높고 도전적인 과제를 해결하며 지속적으로 성장할 수 있습니다.
• 지식의 습득과 전파가 조직의 핵심 역량이며 이를 기반으로 개인, 조직, 문화가 점진적으로 진화합니다.
• 긴밀하게 협업하는 동료만 있습니다
• 상대보다 좋은 성과를 얻으려는 내부 경쟁을 혐오합니다.
• 촘촘히 협업하고 지원하여 함께 성공하고 성장합니다.
• 상호 신뢰 하에 존중하고 존중받으며 일합니다.
• 성장을 공유합니다

 개발직군의 채용공고를 보면 회사의 개발문화를 소개한다. 요즘 뜬다는 스타트업이나 IT회사들의 채용 공고를 보면 내가 성장 할 수 있을 것 같다는 생각을 한다. 사내에 "2주마다 회의를 가집니다"와 같은 정기회의일도 있다. 이런걸 보면서 와 요즘 회사들은 정말 다르구나라고 느끼곤 했다. 그런데 사실 이러한 개발문화 자체가 "애자일의 실천방법" 중 하나였던 것이다. 

 애자일이 뭐길래 이러한 것들이 애자일의 실천 방법이라고 하는 것일까? 애자일의 궁극적인 목표와 지향점은 한가지이다. "소프트웨어 팀이 빠르게 일하고 변화에 반응을 할 수 있도록 하는 가치와 원칙"이다. 결국 돈을 쫒는 회사의 수익을 결정하는 것은 팀들이 보다 효율적으로 일하고 변화에 쉽게 대처하며 반응하도록 하는 것일 것이다. 더군다나 요즘 같은 트랜드를 쫒아야하는 시대에는 더욱더 일 것이다. 

 

# 애자일 탄생배경

 개발자들은 프로젝트를 이끌어가기 위한 별다른 실천방법 없이 프로젝트를 진행해왔고, 이러한 방식은 예측 불가능, 반복되는 에러와 노력의 낭비문제를 발생시켰다. 결국 클라이언트(고객)은 일정이 지연되고 그에 따른 예산 증가와 낮은 품질에 실망을 하게 됐다. 이러한 것을 방비하기위해 프로세스를 세우고 그 프로세스에는 몇몇 제약사항을 걸어 에러를 방지하도록 했다. 근데 결국 프로젝트는 점점 커지게 될 것이고 이러한 제약사항이 늘어남에 따라 더 많은 문제를 맞이 하게 된다. 문제를 막기 위해서 세운 까다롭고 많은 프로세스가 일정을 지연시키며 팀을 느리게 만드는 것이다.

 그래서 2001년 애자일 소프트웨어 개발 선언문이 작성 됐다.

https://agilemanifesto.org/iso/ko/manifesto.html // 놀랍게도 공식문서다.

애자일을 위한 4가지 큰 가치를 정했고, 이 가치들은 12가지의 원칙을 이끌어 낸다. 

• 공정(프로세스)와 도구(툴)보다 개인과 상호작용이 우선이다.
• 포괄적인 문서보다 작동하는 소프트웨어가 우선이다.
• 계약 협상보다 고객과의 협력이 우선이다.
• 계획을 따르는 것보다 변화에 대한 반응이 우선이다.

 

# 애자일 소프트웨어 개발 선언문

## 공정(프로세스)와 도구(툴)보다는 개인과 상호작용이 우선이다.

 책의 저자 마틴은 사람(개발자)의 중요성에 대해서 강조했다. 물론 이러한 개인의 능력또 중요하겠지만, 이들이 얼마나 융화되어 하나의 팀으로써 유기적으로 돌아가는 것이 중요하진 설명한다. 개발자들 채용을 보면 문제해결능력과 의사소통을 늘 강조하듯이 동료와 조화롭게 일하는 것이 첫째로 중요하며 이러한 팀원들로 구성된 팀들이 상호작용이 되지 않는 슈퍼스타모임보다 성공 가능성이 높다고 했다.

 개발툴또한 자신의 실력에 맞는 툴을 사용하라고 했다. 지나치게 거대하고 많은 툴을 사용하기 보다는, 간소한 것을 가진 툴에서 시작해서 내가 더 큰 기능의 필요성을 느낄때 바꾸라고 했다. 좀 더 크고 좋은 툴이 더 나은 작업을 보장한다고 생각하면 안된다는 것이다. 

 

## 포괄적인 문서보다 동작하는 소프트웨어가 우선이다.

 내가 많은 개발을 경험해보진 못했지만, 어떤 이유에서든 개발을 하면서 뭔가를 배우기 위해서는 문서화된 페이지를 보곤 한다. API명세를 받을때도 이러한 문서를 전해주고 받고는 한다. 코드는 이론적 해석과 시스템 구조에 대한 의사소통에 있어 이상적인 매체가 아니기에 소프트웨어는 문서화 되어야 한다. 

 그러나 지나친 문서화는 작성할때 시간을 잡아먹음과 동시에 동기화를 유지하는데 많은 시간을 잡아 먹는다. 복잡한 문서는 유기적으로 작성되어 동기화가 쉽지 않을 것이며 내용이 맞지 않아 좋지 않은 곳으로 흘러갈 가능성이 높다.

 그래서 문서는 짧고(12~24페이지) 간결하게 요약적으로 작성되어야 한다. 문서는 포괄적인 설계 원리와 가장 높은 시스템의 단계 구조만 담는다. 팀원들은 소프트웨어(시스템)에 적응하기 위해서 이러한 문서가 아닌 긴밀하고 친밀하게 팀원들끼리 일하면서, 즉 바로 옆에 앉아 도와주면서, 이러한 내용을 공유하고 상호작용하여 하나의 팀원이 된다.

 

## 계약 협상보다는 고객 협력이 우선이다.

 클라이언트(고객)과의 계약을 체결하고 끝이 아닌, 그때 부터 시작이다. 일회성이 아닌 계속해서 고객과 협력해야 한다. 성공적인 프로젝트를 위해선 규칙적으로 자주 고객의 피드백을 받아야한다. 결국 이러한 계약사항들은 개발팀과 고객이 함께 만들어 가는 것이다. 클라이언트(고객)은 개발자와 협력함으로써 매주 소프트웨어가 발전해가는 모습을 직접 보며 자신의 요구를 어느정도 만족해가는지도 확인이 가능하다는 것이다. 

 

## 계획을 따르는 것보다 변화에 대한 반응이 우선이다.

 내가 생각하기에 이 가치가 애자일의 가장 핵심적인 가치이지 않을까 싶다. 계획에 집착하기보다는 변화에 유연하게 대처할 수 있는 방법이 되어야 한다.

 개발을 해나가면서도 트랜드는 바뀌고, 계획과는 다르다는 것을 느낄 수 있다. 결국 우리는 소프트웨어 프로젝트의 최종 도착지를 예상할 수 없고 그렇기에 계획할 수도 없을 것이다. 클라이언트(고객)은 계속해서 변경된 요구사항을 반영하도록 요청 할 것이다. 

간트 차트

 프로젝트에 대한 계획안을 보면 이러한 차트를 본적이 있을 것이다. 그러나 현실은 이러한 마감날짜를 잘 지 킬 수 없다. 계속해서 변화해야 하니까!

 그래서 애자일이 추구하는 전략은 3가지의 Term을 잡는다. 

1. 다음 2주간 세부적인 계획 수립
2. 다음 3개월간의 개략적인 계획
3. 그 이후는 아주 대강의 계획( 1년 후 작업할 시스템에 대해서 흐릿한 개념)

 

 세부 계획이 세워지면 그 계획에 맞추기 위해서 수많은 팀들이 추진력과 책임으로 일하고 있을테고 변경에 대처하기 힘들어질 것이다. 그렇기 때문에 계획은 가까운 시일 내에 수행할 테스크에 대해서만 세부적이게 짜야 한다. 나마지 부분은 탄력적으로 조정한다. 채용공고에서 볼 수 있듯이 이러한 데드라인에 집착하고 지나친 세부적인 계획에 집착하는 것은 높은 품질의 결과를 낼 수 없다는 것이다.

 

# 가치에서 이끌어낸 12가지 원칙

앞에서 본 4가지 가치들은 12가지의 세부적인 원칙을 이끌어 낼 수 있다. 특별한 설명보다는, 이들이 제시한 원칙이 뭐가 있는지 살펴보자. 글을 읽으면 이해가 되지 않는 것은 없을 것이다.

1. 우리의 최고 가치는 유용한 소프트웨어의 빠르고 지속적인 공개를 통해 고객을 만족시키는 것이다.
2. 개발 후반부에 접어들었다 할지라도 요구사항 변경을 환영하라. 애자일 프로세스는 고객의 경쟁 우위를 위해 변화를 이용한다.
3. 개발 중인 소프트웨어를 2주에서 2달 사이, 혹은 더 짧은 시간 간격으로 자주 공개하라.
4. 업무를 하는 사람과 개발자는 프로젝트를 통틀어 계속 함께 일해야 한다.
5. 의욕적인 개인들을 중심으로 프로젝트를 구성하라. 환경과 필요로 하는 지원을 제공하고, 그들이 그 일을 해낼 것이라고 믿고 맡겨둬라
6. 개발 팀 내에서 정보를 전달하고 공유하는 가장 효율적이고 효과적인 방법은 직접 일대일로 대화하는 것이다.
7. 개발 중인 소프트웨어가 진척 상황의 일차적 척도다.
8. 애자일 프로세스는 지속 가능한 개발을 촉진한다. 스폰서, 개발자, 그리고 사용자는 무한히 지속적인 속도(pace)유지할 수 있어야 한다.
9. 우수 기술과 좋은 설계에 대한 지속적인 관심은 속도를 향상한다.
10. 단숭성(아직 끝내지 않은 일의 양을 최대하하는 예술)은 필수적이다.
11. 최고의 아키텍처, 요구사항, 그리고 설계는 자기 조직적인 팀에서 나온다.
12. 규칙적으로 팀은 좀 더 효과적인 방법을 반영해야 하고, 적절히 그 행위를 조율하고 조정해야한다.

 

 프로젝트를 성공적으로 완료하기 위해선, 의욕넘치는 개인들이 조화로운 팀을 이루고, 고객과 지속적인 협력을 통해서 계속해서 변화하는 프로젝트를 수행하고 그로 인해서 빠르게 개발 할 수 있도록 하는 것이 내가 이해한 애자일 방법론이다. 멋사에서 일할때 PM님이 애자일이라는 것을 처음 소개해주셨다. 그땐 그러한 용어도 처음 들어 봤을때 였는데, 스타트업들이 폭포(water-fall)방법이 아닌 애자일 방법론을 사용해야 하는 이유는 12가지 원칙 중 3번에 해당하는, 짧은 간격으로 공개 하는 것에 대한 장점 때문이었다. 스타트업은 아닌건 빨리 빨리 쳐내야했기에 중요한 기술들에 대해서 먼저 출시하고 QA를 거치고 user test를 거쳐 서비스를 빠르게 안정화에 이뤄야 했기 때문이었다. 

 

# 마치며

 난 그저 애자일이 빠르게 출시하도록 개발하는 것이라고 알고 있었는데, 그 발단 과정에 대해서 알 수 있었다. 이러한 방법들이 결국에는 프로젝트의 성공을 빠르게 해준다는 사실이 신기하기도 하다. 

 애자일 방법론은 딱 한가지만 존재하는 것이 아닌 애자일 방법론을 지키는 여러 프로세스가 있다. 책에서는 크럼, 크리스털, 기능 중심 개발, 어댑티브 소프트웨어 개발, 익스트림 프로그래밍 개발과 같은 프로세스가 있다는 것을 알려 주고, 다음 장에서는 익스트림 프로그래밍 개발(Extreme Programming)에 대해서 알아 본다!