[소프트웨어공학] 6. Agile Software Development

Agile

Software Process글에서 Agile을 Plan-Driven 방식과 비교하며 사용자의 요구사항 변경에 민첩하게 반응하는 개발 방법론이라고 정리했었다.

이번 글에서는 이 애자일 방법론에 대해 더 자세히 정리해본다.

 

애자일 개발 방법론이 등장한 배경은 기존 개발 방법론에서 발생하는 오버헤드에 대한 부담이었다.

예를 들어 waterfall 방식은 각 단계가 끝날 때마다 document가 나오는 것이 장점이었지만, 고객의 요구사항이 빠르게 바뀌는 상황에서 매번 바뀌는 요구사항에 맞춰 문서화를 하고나서 개발하는 것은 오버헤드가 존재한다.

 

그래서 애자일은 요구사항이 변화할 때 부가적인 작업 없이 빠르게 대응해서 software delivery time을 줄이는 것을 목표로 한다.

 

 

기존의 Plan-Driven 방식에서는 요구사항을 분석하고 명세를 작성한 뒤 설계하고 개발하다가 요구사항 수정이 발생하면 다시 요구사항 분석부터 들어갔다.

하지만 애자일에서는 요구사항 수정이 발생하면 요구사항을 분석하고 명세 작성없이 바로 설계와 개발에 들어간다.

(위 그림에서 각진 직사각형이 '문서화'를 의미한다.)

 

애자일 개발 방법론은 다음과 같은 특징을 가진다.

 

1. incremental development

여러 버전 또는 increment 의 연속적인 개발을 통해 하나의 소프트웨어를 개발해나간다.

따라서 시스템 배포의 규모가 작고 자주 일어나며, 반복적이다.

 

2. Customer Involvement

소프트웨어를 개발하는 전체 프로세스에 고객이 팀으로서 함께 참여한다.

(이렇게 개발된 소프트웨어는 generic 보다는 customized 소프트웨어 일 것이다.)

 

3. 문서화를 최소화하여 프로세스 오버헤드 줄이기

 

애자일 방법론은 작은 규모의 소프트웨어를 개발할 때 유용하고,

소프트웨어의 종류 중에서는 특히 Customized 소프트웨어를 개발할 때 적용하기 좋다.

 

Extreme Programming (XP)

애자일 개발 방법론의 구체적인 예시 중 하나로 XP가 있다.

XP에서 extreme 이라는 단어는 개발 단위가 매우 작음을 나타낸다.

개발 단위가 매우 작기 때문에 하루에도 여러 개의 세부 버전이 개발될 수 있고, 2주마다 새로운 increment가 배포된다.

 

 

XP의 개발 과정을 그래프로 보면 위와 같다.

먼저 현재 release 를 개발함에 있어 관련된 유저 관점에서의 story를 파악하고, 각각의 story를 task로 나눈다.

(XP에서는 requirement 를 story 로 파악한다.)

다음으로 어떻게 release 할 지 계획을 세우고 개발/통합/테스트를 거친 뒤 소프트웨어를 배포하고 유저 반응을 평가한다.

 

XP 방식에는 다음의 4가지 핵심 요소들이 존재한다.

user story / refactoring / test-first development / pair programming

 

User Story

XP 에서는 requirement 를 user story 로 파악한다.

애자일 특징에서 적은대로, XP팀에는 고객이 함께 있기 때문에 요구사항을 파악하거나 의사결정할 때 고객도 함께 참여한다.

(그리고 의사결정 뿐만 아니라 테스트에도 고객이 관여한다.)

 

XP 에서는 고객의 요구사항을 user story 또는 user 시나리오로 나타내며, 카드에 적힌 story 는 개발할 때 세부 구현에 대한 task 로 쪼개진다.

그리고 고객은 자신이 생각하는 우선순위나 스케줄에 맞춰 현재 release에 어떤 story 를 포함할 지 직접 선택한다.

 

예를 들어 쇼핑몰 사이트를 만든다고 했을 때, 고객에 사이트에 로그인하고나서 어떻게 페이지를 이동하고 사이트를 탐색하기를 원하는지 파악해서 user story로 만든다.

 

 

Refactoring

기존에 존재하는 코드를 다시 구조화하는 기법

외부에서 보이는 동작의 변화없이 코드를 개선하는 것을 말한다.

 

리팩토링은 추후 변경사항이 생겼을 때 코드의 수정을 더 쉽게 할 수 있도록 도와준다.

당장 필요한 요소가 생기지 않았더라도 개발 팀에서 코드의 구조를 미리 개선하는 것이기도 하고,

리팩토링 과정에서 계속 코드를 보다보면 전체 시스템에 대한 이해도가 자연스럽게 올라가기 때문이다.

그래서 문서화를 하지 않아도 팀 전체의 코드 이해도를 꾸준히 유지할 수 있는 효과가 있다.

 

리팩토링의 예시는 기존 클래스 계층 구조를 바꾸고 중복되는 코드를 제거할 수도 있고, 기존 코드를 더 읽기 쉽게 함수명이나 변수명을 바꾸기도 한다.

 

Test-First Development

구현 코드를 작성하기 전에 테스트 코드를 먼저 작성하는 것을 말한다.

애자일 특성상 specification 문서를 만들지 않기 때문에, 테스트 코드를 먼저 작성하면서 유저 관점에서 잘 동작해야 하는 기능들을 생각할 수 있어 문서가 없는 문제점을 보완하는 효과가 있다.

 

그리고 새로운 기능이 추가될 때마다 모든 컴포넌트에 대한 테스트를 진행하며, 테스트는 보통 코드로 작성하여 자동화한다.

 

그리고 XP에서는 테스트에 유저가 함께 참여하므로 acceptance test 에 도움이 된다.

 

 

Pair Programming

이름 그대로 2명이 짝을 지어 함께 프로그래밍하는 방법을 말한다.

(정말 하나의 컴퓨터 앞에 두 명이 같이 앉아 코드를 작성한다.)

 

이 과정을 통해 옆에서 지켜보는 사람이 코드를 함께 보면서 눈으로 사전에 리뷰할 수 있고,

하나의 코드를 2명이 보기 때문에 팀 내에 코드에 대한 이해도가 더 잘 퍼지는 효과도 있다.

(이 역시 문서화가 되지 않는 점을 보완한다.)

 

 

XP에서 user story, refactoring, test-first development, pair programming 모두

문서화를 하지 않는 애자일 방법에서 문서의 부재를 보완하는 방식의 활동인 것이다.

 

---

Agile & Plan-Driven

애자일 방식의 개발 프로세스는 문서화가 잘 되지 않고, 개발 팀의 구성원이 유지되지 않고 바뀔 때 대응하기 힘들다는 문제점이 있다.

그래서 XP 에서는 리팩토링, TDD, 페어 프로그래밍의 방법으로 보완하고자 하였다.

 

그리고 애자일 개발 방법론을 오해하면 안된다.

애자일 아이디어를 잘못 적용하면 대충 빠르게 개발하는 것에만 집중하여 개발자에게 부담만 가중시킬 수도 있다.

그리고 이는 결과적으로 전체적인 소프트웨어 개발 속도를 더욱 더디게 만든다.

따라서 애자일 방법론을 사용할 때는 제대로 이해하고 사용해야 한다.

 

애자일은 서로 다른 버전이 수시로 나오므로 각 기능을 개발하는 작은 팀들이 서로 같이 있어야 하고,

개발 과정에 customer가 관여할 수 있을 때 적용하기 좋다.

 

애자일과 Plan-Driven 방식 중에서 하나를 선택할 때는 다음 사항을 고려해야 한다.

 

1. 프로그램 설계에 앞서 매우 상세한 스펙이 필요한가?

2. incremental delivery 를 현실적으로 적용할 수 있는 환경인가?

3. 개발하려는 시스템의 규모가 큰가?

4. 개발팀이 한 공간에 같이 있는가?

 

그리고 대부분의 프로젝트는 애자일과 plan-driven 방식을 함께 사용한다.

예를 들어 UI나 게임을 개발할 때는 애자일 방법을 사용하면 좋고, 자율주행과 같이 시스템의 안정성이 중요한 경우에는 plan-driven 을 적용하는 것이 좋다.

 

지금까지는 Plan-Driven 과 애자일 그리고 애자일의 예시로 XP 에 대해서 정리하였지만, 실제로는 더 다양한 개발 프로세스 모델이 존재한다. 그리고 그런 각각의 프로세스 모델 중에서 어떤 것을 적용할지 요구사항의 유연성, 소프트웨어 규모 등 현재 상황에 맞춰서 골라야 한다.