애자일(Agile) 방법론이란 소프트웨어 개발하는 접근법/개발 기법 중 하나이다.
무엇인지 알아보자.

등장배경

초기 개발 방법

초기 소프트웨어 개발 방법은 계획 중심의 프로세스였다.

마치 도시 계획으로 건축에서 사용하는 방법과 유사하며, 당시에는 이런 프로세스를 활용하는 프로젝트가 대부분이었다.

이러한 프로세스를 폭포수(waterfall) 개발 모델이라고 하며 아래와 같은 한계점을 가진다.

• 한 과정이 제대로 되지 않으면 다음으로 못넘어간다.
• 다음 단계가 되더라도 전 단계가 문제가 생기면 다시 처음으로 돌아가게 된다.
• 요구분석단계에서 사용자가 개발자에게 한 번에 모든 요구사항을 정확하게 전달하는 것을 가정하고 있으나, 현실적으로 불가능하다.
• SW의 비가시성으로 사용자의 요구사항이 프로젝트 진행 시 지속적으로 변경된다.

하지만 지금은?

90년대 이후, 소프트웨어 분야가 넓어지면서 소프트웨어 사용자(end user)들이 '일반 대중들'로 바뀌기 시작했다.
즉, 이제 모든 사람들이 소프트웨어 사용자들의 대상으로 되면서 트렌드가 급격하게 빨리 변화하는 시대가 도달한 것이다.

이로인해 비즈니스 사이클(제품 수명)이 짧아졌고, SW 개발의 불확실성이 높아지게 되었다.

새로운 개발 방법 등장

개발의 불확실성이 높아지면서 예전의 전통적 개발 방법 적용이 어려워졌고 사람들은 새로운 자신만의 SW 개발 방법을 만들어 사용하게 된다.

• '창의성'이나 '혁신'은 계획에서 나오는 것이 아니라고 생각했기 때문

따라서 '경량 방법론 주의자(lightweight methodologies)'들은 일단 해보고 고쳐나가자는 방식으로 개발하게 되었다.

규칙을 적게 만들고, 가볍게 대응을 잘하는 방법을 적용하는 것

이런 경량 방법론 주의자들이 모여 자신들이 사용하는 개발 방법론을 공유하고, 공통점을 추려서 애자일(Agile)이라는 용어에 의미가 담기게 된 것이다.

불확실성

애자일에서는 소프트웨어 개발의 불확실성이 중요하게 작용한다.
불확실성이 높으면, 우리가 생각한거랑 다르다.라는 상황에 직면하게 된다.
이때, 전통적인 방법론과 애자일의 방법론의 차이는 아래와 같다.

전통적 방법론 
: '그때 계획 세울 때 좀 더 잘 세워둘껄.. 
이런 리스크도 생각했어야 했는데... 일단 계속 진행하자'

애자일 방법론
: '이건 생각 못했네. 어쩔 수 없지. 다시 빨리 수정해보자'

전통적 방법에 속하는 '폭포수 모델'은 요구분석단계에서 한번에 모든 요구사항을 정확하게 전달하는 것이 원칙이다. 하지만 요즘같이 변화가 많은 프로젝트에서는 현실적으로 불가능에 가깝다.

이런 한계점을 극복해주는 애자일은, 개발 과정에 있어서 시스템 변경사항을 유연하게 or 기민하게 대응할 수 있도록 방법론을 제공해준다.

애자일(Agile) 이란?

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

우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을
도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고
있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:

공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를

가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만,
우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.

http://agilemanifesto.org/

애자일은 위 '애자일 소프트웨어 개발 선언문'에 나와있는 것이 전부이다.

해당 선언문을 좀 더 정리하자면 '협력'과 '피드백'을 더 자주하고, 일찍하고, 잘하는 것이라고 할 수 있다.
즉, 애자일의 핵심은 바로 '협력'과 '피드백'이다.

애자일이 될 조건 (Agile Manifesto)

애자일이 되기 위해 필요한 조건을 좀 더 풀어 말하자면 애자일은 4가지 가치를 수호해야 한다.

1. Individuals and interactions over Process and tools (프로세스나 도구보다 개인과 상호 작용)
2. Working software over Comprehensive documentation (포괄적인 문서보다 작동 소프트웨어)
3. Customer collaboration over Contract negotiation (계약 협상보다 고객과의 협력)
4. Responding to change over Following a plan (계획 고수보다 변화에 대응)

4 가지 모두 뛰어넘어야 하는 대상을 명시하고 있으며, 비교 대상은 기존의 개발 방법론에서 거쳤던 과정이다. 즉, Agile 방법론은 기존의 다른 프로젝트 개발 방법론의 문제점을 극복하기 위해 탄생한 것임을 알 수 있다.

애자일과 전통적인 개발방법론의 차이점 및 특징

애자일의 핵심 요소

협력

소프트웨어를 개발한 사람들 안에서의 협력을 말한다.(직무 역할을 넘어선 협력)

협력을 통해 스스로 느낀 좋은 통찰은 협력을 통해 다른 사람에게도 전해줄 수 있으며, 예상치 못한 기회 또는 기대 효과를 가져올 수 있다.

ex) 좋은 일은 x2가 된다.

어떤 사람이 2배의 속도로 개발할 수 있는 방법을 발견함

협력이 약하면? 
→ 혼자만 좋은 보상과 칭찬을 받음
→ 하지만 그 사람 코드와 다른 사람의 코드의 이질감이 생겨서 시스템 문제 발생 가능성 존재

협력이 강하면? 
→ 다른 사람과 공유해서 모두 같이 빠르게 개발하고 더 나은 발전점을 찾기에 용이
→ 팀 전체 개선이 일어나는 긍정적 효과 발생

또한 협력을 통해 문제가 발생하는 부분을 찾기 쉬워지며, 고칠 수 있다.
그리고 예상치 못한 문제를 협력으로 막을 수도 있다.

ex) 안 좋은 일은 /2가 된다.

내가 생각지 못한 실수를 했는데 아무리 다시 봐도 모르겠거나 더 나은 방법이 생각나지 않을 때가 있다. 

협력이 약하면?
→ 개발 지연
→ 또 다른 문제점 발생 가능성 존제

협력이 강하면?
→ 다른 사람과 공유해서 빠르게 문제점을 발견하여 고칠 수 있다.
→ 다양한 의견으로 추가적인 문제점이 발생할 가능성을 낮출 수 있다.

피드백

피드백은 학습의 가장 큰 전제조건이다. 내가 어떻게 했는지 확인하면서 학습을 진행해야 한다.

또한 모르는 게 많으면 더 빨리 배워나가야 하기 때문에 소프트웨어의 불확실성이 높을 수록 학습의 중요도는 올라간다.

일을 잘하는 사람은 이처럼 피드백을 찾는 능력(feedback seeking)이 뛰어나다. 즉, 더 많은 사람들에게 피드백을 구하고 발전시켜 나간다.

피드백 진행 방법

1. 내부적 피드백
   • 내가 만든 것이 어떻게 됐는지 확인해보는 것
2. 외부적 피드백
   • 내가 만든 것을 고객이나 다른 부서가 사용해보고 나온 산출물을 통해 또 다른 것을 배워나가는 것

애자일 적용/진행 방법

1. 개발자와 고객 사이의 지속적 커뮤니케이션을 통해 변화하는 요구사항을 수용한다.
2. 고객이 결정한 사항을 가장 우선으로 시행하고, 개발자 개인의 가치보다 팀의 목표를 우선으로 한다.
3. 팀원들과 주기적인 미팅을 통해 프로젝트를 점검한다.
4. 주기적으로 제품 시현을 하고 고객으로부터 피드백을 받는다.
5. 프로그램 품질 향상에 신경쓰며 간단한 내부 구조 형성을 통한 비용절감을 목표로 한다.

애자일의 종류

애자일을 적용하여 여러 개발 방법론이 존재한다.

1. 익스트림 프로그래밍 (Extreme Programming, XP)
   • 의사소통, 단순성, 피드백, 자신감을 모토로 한다.
   • 애자일 개발 프로세스의 대표자로 애자일 개발 프로세스의 보급에 큰 역할을 하였다.
   • 고객과 소통하며 2주 정도의 반복개발을 하고, 테스트와 우선 개발을 특징으로 하는 명시적인 기술과 방법을 가지고 있다.
2. 스크럼 (Scrum)
   • 백로그(backlog)와 스프린트(sprint)를 특징으로 한다.
   • 30일마다 동작 가능한 제품을 제공하는 스플린트를 중심으로 하고 있다.
   • 매일 정해진 시간에 정해진 장소에서 짧은 시간의 개발을 하는 팀을 위한, 프로젝트 관리 중심의 방법론이다.
3. 익스트림 모데링 (Extreme Modeling)
   • UML을 이용한 모델링 중심 방법론이다.
   • 모델링 방법들과는 달리, 언제나 실행할 수 있고 검증할 수 있는 모델을 작성하는 공정을 반복해서, 최종적으로는 모델로부터 자동적으로 제품을 생성하게 한다.
4. 크리스털 패밀리 (Crystal Family)
   • 이 방식은 프로젝트의 규모와 영향의 크기에 따라 여러 종류의 방법론을 제공한다.
   • 그 중 가장 소규모 팀에 적용하는 크리스털 클리어(Crystal Clear)는 XP만큼 엄격하지도 않고 효율도 높지 않지만, 프로젝트에 적용하기 쉬운 방법론이다.
5. FDD (Feature-Driven Development)
   • 기능 중심 개발을 모토로하는 방법론이다.
   • Peter Coad의 접근 방식에 크게 영향을 받았으며, UML을 이용한 설계 기법과도 밀접한 관련을 가진다.

UML(Unified Modeling Language)

• 프로그램 설계를 표현하기 위해 사용하는, 주로 그림으로 된 표기법을 의미한다.
• 소프트웨어 시스템, 업무 모델링, 시스템의 산출물을 규정하고 시각화하며 문서화하는 '언어'이다.
• 모델링 언어일뿐 방법론이나 프로그래밍 언어는 아니다.

참고 자료
애자일 소프트웨어 개발 선언문
https://gmlwjd9405.github.io/2018/05/26/what-is-agile.html
https://ememomo.tistory.com/126
https://asfirstalways.tistory.com/95
https://github.com/gyoogle/tech-interview-for-developer/blob/master/Computer%20Science/Software%20Engineering/%EC%95%A0%EC%9E%90%EC%9D%BC(Agile).md
https://github.com/gyoogle/tech-interview-for-developer/blob/master/Computer%20Science/Software%20Engineering/%EC%95%A0%EC%9E%90%EC%9D%BC(Agile)2.md