Agile(애자일) 개발방법론

출처 : http://blog.naver.com/s9258024/50017398327


Agile 방법론은 과거 방법론의 위험 및 실패요소를 바탕으로 더 효과적인 프로젝트를 수행하기 위해 만들어졌는데,
여기서 말하는 Agile이란 기본적으로 소프트웨어를 빨리 개발하여 비즈니스에 적용한다는 것..

비즈니스의 요구에 유연하고 민첩하게 대응한다

소프트웨어 Agile 개발 방법론

 

Agile 방법론의 등장 배경

분석, 설계, 개발, 검증, 이관 등의 단계를 순차적으로 거치는 전통적인 개발 방식인 폭포 모델(waterfall model)은
1960년대 복잡한 군사용 소프트웨어 개발을 위해 미국 해군에서 고안됐다. 폭포 모델에서 프로젝트는 정해진 순서를
따르게 된다. 각 단계의 끝에서 프로젝트 팀은 최종 점검까지 모두 끝낸 후 고객의 승인을 받게 되고, 고객이 만족하지
않는 한 다음 단계로 넘어가지 않는다.

이 때문에 소프트웨어의 구현 및 테스트 단계에 이를 때까지 잠재적인 문제들과의 대면을 미루게 되며 요구 사항,
디자인, 코딩에 숨어있는 모든 문제들이 프로젝트가 끝나기 직전에 갑자기 부상되어 고통스러운 현실을 만들어 버리는
경우가 발생하곤 한다.

이러한 전통적 폭포 모델 구현 프로세스의 문제점을 정리해 보면 아래와 같다.

● 사용자의 요구를 정확하게 반영하기 힘듦 : 각 단계를 진행하는 중에 주기적으로 요구사항을 조율할 수 있는 체계적인
    방법이 없으며 사용자들은 시스템이 동작되는 것을 보기 전에 자신이 원하는 것을 정확히 알지 못한다.

● 지속적으로 변화하는 요구사항을 적절히 처리할 수 없음 : 하나의 단계를 완결하고 다음 단계로 진행하는 방식이기
    때문에 요구사항 단계를 지나 새롭게 추가되는 요구사항을 반영하려면 프로젝트 일정에 상당한 부담을 주게 된다.

● 개발된 소프트웨어 모듈들이 잘 조합되지 않을 수 있음 : 개발자들이 각자 개발한 모듈들은 테스트 단계에까지 가야
    서로 연동시켜 볼 수 있는데 이러한 모듈 사이의 인터페이스에 문제가 발생할 수 있다. 대부분의 중대한 시스템 결점은
    프로젝트 막바지에 발견되며 이를 처리하는 것은 매우 힘든 작업이 된다.

 ● 품질 저하 : 추가적인 요구사항을 반영하기에 절대적으로 시간이 부족하기 때문에 버전에 따라 산출물들의 관계와
     정보들을 체계적이고 독립적으로 관리하기 힘들어 유지보수에 큰 부담을 주며 반영시킨 요구사항에 대한 프로그램의
     품질 역시 떨어지게 된다.전통적인 개발 방식은 소프트웨어 개발주기가 길며 사용자의 요구사항을 효과적으로
     반영하기가 어렵다. 더욱이 기업에서는 최소의 소프트웨어 개발 투자를 통해 극대화된 효과를 원하기 때문에 새로운
     개발 방식을 찾게 하는 동기를 제공하게 되었다. 이러한 배경으로 대두되고 있는 것이 Agile 방법론이다.

 

RTE와 Agile 방법론

Agile 방법론은 과거 방법론의 위험 및 실패요소를 바탕으로 더 효과적인 프로젝트를 수행하기 위해 만들어졌는데 여기서
말하는 Agile이란 기본적으로 소프트웨어를 빨리 개발하여 비즈니스에 적용한다는 것 이상의 내용을 포함하고 있다.
그 내용을 살펴보면 아래와 같다.

● 프로젝트에 해를 끼칠 수 있는 것들에 대해 미리 대처할 수 있는 것

● 지속적으로 발생하는 변화에 대하여 적절하게 대처할 수 있는 것

Agile 방법론은 소프트웨어 개발을 수행하는 개념적인 프레임워크라 할 수 있다. 대부분의 Agile 방법론에서는 짧은 개발
주기를 반복(iteration)하고, 의도된 방향으로 프로젝트가 진행되는지 수시로 확인하여 위험요소를 최소화 시키고 있다.
반복은 계획수립, 요구사항 분석, 디자인, 개발, 테스트, 문서작업 등의 모든 태스크(task)를 포함한 작은 단위의 프로젝트
개념이다. 이러한 반복은 요구사항을 다 반영하지 못하더라도 릴리즈(release)하는 경향이 있는데 이것은 각 반복
주기마다 구현된 기능들을 확인하고 새로운 요구사항을 받아들이기 위함이다.

또한 Agile 방법론은 실시간 커뮤니케이션과 고객과의 밀착된 개발 분위기를 강조하며 다른 방법론과 비교하여 문서화
작업에 큰 비중을 두지 않는다.실시간 기업(Real Time Enterprise)의 중요성이 더욱 커지고 있는 IT 환경 하에서
애플리케이션 개발팀에게는 짧은 시간에 저렴한 비용을 통해 모든 요구사항을 만족시키며, 효과적으로 비즈니스 수행을
가능하게 해주는 애플리케이션 개발에 대한 압력이 더욱 커지고 있다. 이러한 압력에 효과적으로 대응하기 위한
여러 방법들 중 하나로 Agile 소프트웨어 개발에 대한 관심이 더욱 증가하고 있다.

 

Agile 방법론의 종류

RUP (Rational Unified Process) 대부분의 Agile 방법론과 마찬가지로 RUP 역시 반복적인 소프트웨어 개발
프로세스가 핵심 개념이다. 과거 실패한 프로젝트로부터 실패 원인을 파악하여 그와 유사한 상황에 빠져들지 않도록
최적의 프로세스를 도출하는 것이다. RUP는 미리 정의된 단 하나의 프로세스가 아니라 개발조직이나 프로젝트 팀에서
각자 필요에 의해 프로세스의 요소를 선별해서 사용할 수 있는 프로세스 프레임워크를 제공한다.

무엇인가 혁신적인 것을 만들기 위해서는 완성품을 구현하는 과정 동안 같은 객체에 대해 많은 반복이 필요하다.
반복적인 개발을 통해서 프로젝트는 작은 단계들을 통해 진행되다가 점점 보다 완벽한 시스템을 만들게 되는 것이다.
반복적 개발에서 각 반복 개발주기(Life Cycle)는 과정(Discipline)과 단계(Phase)로 구성된 전체적인 작업흐름 내에서
결정되며 각 개발주기에서는 단계의 진행에 따라 강조점이 달라진다. [그림1]

[그림 1] RUP 작업흐름

RUP에서의 반복은 과정을 통과하는 것이다.
(RUP에서 과정은 서로 관련된 Activity와 객체의 그룹핑 또는 결과물을 의미한다).
마치 작은 폭포 모델 같은 각각의 단계는 요구 사항들의 새로운 부분들을 검토하고 오류를 수정하고 이전 반복의 결과를
재작업 할 수 있는 기회를 제공한다. 반복을 통해 솔루션은 사용자가 원하는 결과물에 더 가까워지는 것이다.[그림2]

[그림2] RUP의 반복 개발 프로세스

XP(Extreme Programming) XP는 다른 개발방법론과 달리 개발자가 지켜야 할 프로세스를 하나하나 지정하지는
않는다. 정규화된 프로세스 대신 기본 철학을 정의하고 있는데, 그래서 수동적인 프로세스보다 능동적인 의지로 개발에
참여할 수 있게 한다. 이러한 기본 철학은 의사소통, 단순성, 피드백, 용기로 구성되어 있으며 각각의 내용은 아래와 같다.

● 의사소통 : 고객, 개발자, 관리자들 간의 원활한 의사소통을 통해 왜곡된 결과를 미연에 방지하는 것이다.
    이를 위해 Pair Programming, 고객 상주 및 단위 테스트와 같은 방법을 제시하고 있다.

● 단순성 : 당장 필요한 기능만 최대한 잘 만드는 것을 의미하며, 단순성은 의사소통과 맞물려서 간결한 디자인과
    프로그램에 대한 불필요한 의사소통을 최소화해서 전체적인 효율성을 높여준다.

● 피드백 : XP에서의 피드백은 개발대상 시스템이며 즉각적인 피드백을 확인하기 위해서 항상 시스템을 구성하는
    프로그램이 실행 가능한 상태를 유지하도록 한다.

● 용기 : 의사소통, 단순성, 피드백 등을 통해 다른 사람이 작업한 내용을 수정할 때 개발자들이 부정적이거나 소극적인
    모습을 보이지 않도록 유도한다.

[그림3]은 XP 개발의 전체적인 수행 과정을 나타낸 것이다. XP 역시 사용자 요구사항을 지속적으로 반영하기 위한 반복
개발의 개념을 가지고 있다. 주기 및 승인 테스트를 통한 이러한 반복은 고객의 요구사항을 보다 정확하게 시스템에
반영하여 프로젝트의 위험요소를 사전에 제거한다.
 

[그림3] XP 수행 과정

 XP는 고객에게 고객이 원하는 소프트웨어를 빨리 전달하는 것을 목표로 한다. 최소한 1~3주 내에 구현할 수 있는 수많은
요구사항(유저 스토리) 가운데 고객이 가장 중요하게 생각하는 것을 먼저 구현하고, 시간이 모자라면 유저 스토리 안에서
고객이 가장 중요시하는 과제를 먼저 구현한다. 프로젝트가 예측한 시일 안에 끝날 수 있도록 1~3주마다 진행상황을
점검하고 다음 1~3주 동안 할 일을 계획한다(릴리즈 계획 회의).

승인 테스트를 통해 구현된 코드가 유저 스토리를 만족한다는 것을 확인하고 틈틈이 리팩토링을 통해 코드의 질을 높여
고객의 요구사항을 효과적으로 프로그램에 반영할 수 있도록 한다. 개발자 사이에 의사소통을 원활히 하는 한 방법으로
페어 프로그래밍을 하며 코드와 동떨어지게 되거나 읽어 볼 사람이 없는 문서라면 만들지 않는다.

SCRUM

SCRUM은 또 하나의 Agile 개발 방법론으로 작은 개발 팀, 짧은 개발 주기, 팀의 집중력과 생산성을 유지시켜 점진적으로
소프트웨어를 산출하는 것에 초점을 맞추고 있다. SCRUM 프로젝트는 하나 이상의 스프린트(Sprint)로 나누어지는데,
스프린트는 통상적으로 4~6주 정도의 기간을 가지는 잘 정의된 개발 주기를 의미한다. 초기 프로젝트 계획 수립이
완료된 후 고객과 개발 팀이 공동으로 첫 번째 스프린트에 해당하는 산출물을 결정한 후 개발팀은 스프린트를 시작하는데
모든 다른 작업을 제쳐놓고 여기에 집중한다.  

스프린트는 기간이 짧으므로 긴급하다는 것을 느끼도록 팀에게 자극을 주게 된다. 스프린트는 짧은 몇 주 만에
종료되므로 팀에게 항상 끝이 보이게 해준다. 각 스프린트는 팀이 스프린트가 어떻게 지나갔는지를 재검토하고
다음 스프린트를 향상시키기 위한 아이디어를 모색하는 회고(retrospective)로 끝난다.
한 스프린트가 종료되었다는 것은 다음 스프린트를 시작하라는 신호이다.
이 사이클은 프로젝트가 종료될 때까지 계속된다. [그림4]

[그림4] SCRUM 스프린트 사이클

SCRUM 방법론은 다른 Agile 방법론과 마찬가지로 반복 개발을 한다. SCRUM은 XP와 매우 유사한 방식을 취하고 있다.
SCRUM의 Backlog는 XP의 유저 스토리와, 스프린트는 주기와 비슷하다. 그러나 SCRUM은 XP와 달리 요구사항에 변화가
발생하면 그것을 시스템에 적용하기 힘들기 때문에 최대한 빨리 발견하여 처리하자는 관점에서 접근한다.
따라서 변화 감지를 위한 회의를 SCRUM Master를 통해 매일 진행하지만 XP는 리팩토링을 통해 코드를 늘 수정하기 쉬운
상태로 유지하면서 언제든지 변화를 수용하겠다는 관점을 가지고 있다. 또한 SCRUM은 SCRUM Master를 통해 매일
프로젝트 진행상황을 확인하기 때문에 효과적인 프로젝트 운영을 유도할 수 있다.

 

Agile 방법론과 SOA의 관계

Agile 방법론은 소프트웨어 개발 생산성을 효과적으로 높여주며 SOA는 소프트웨어의 유연성과 재사용성을 높여준다는
점에서 서로 연관성 있는 목표를 공유하고 있다. 이런 연관성을 인식한 기업은 Agile 방법론과 SOA를 병행하여 시너지
효과를 얻으려 하고 있는데 [그림5]에서 나타나듯이 전사적으로 SOA를 적용하는 기업에서 Agile 방법론을 적용하는
비율이 SOA를 부분적으로 또는 적용하지 않는 기업보다 높음을 알 수 있다.

[그림5] SOA와 Agile 방법론 적용 연관성
(Forrester, ‘Agile Process Enable SOA Success’, Carey Schwaber, et al,. 2006.02.07)

SOA 프로젝트는 비즈니스 프로세스를 재사용 가능한 서비스로 만드는 것인데 여기서의 서비스는 웹 서비스가 가능한
소프트웨어 모듈 개발을 의미한다. 이러한 개발에 Agile 방법론을 사용하면 좀더 효과적인 서비스 개발이 가능한데
이와 같이 SOA와 Agile 방법론을 동시에 사용할 때 기대되는 시너지 효과를 살펴보면 아래와 같다.

비즈니스 및 기술 요구사항에 대한 신속한 대응

Agile 방법론은 일반적으로 짧은 주기의 반복 개발을 하기 때문에 비즈니스 및 기술 요구사항이 자주 바뀌어 최종적인
소프트웨어의 모습이 잘 드러나지 않을 때 사용하기 적합하다. SOA 서비스를 소프트웨어 모듈 단위로 구현할 때
Agile 방법론을 적용한다면 수시로 바뀌는 요구사항의 변화에도 적절하게 대응할 수 있다.
뿐만 아니라 요구사항을 전달하는 고객들도 반복 개발 주기마다 작성된 서비스(소프트웨어 모듈)를 실제 확인하는 경험을
통해 스스로 서비스 디자인에 대한 개념이 생기게 되고 이러한 경험을 바탕으로 향후 요구하는 서비스에 대해 보다
정확히 나타낼 수 있기 때문에 개발팀이 서비스를 생산할 수 있는 시간을 단축할 수 있게 해준다.

효과적인 리스크 관리

Agile 방법론의 짧은 개발 주기는 마치 하나의 작은 프로젝트를 완성하는 것과 같다. 개발 주기가 반복되어
작은 프로젝트의 완성도를 높여가면 전체적인 프로젝트의 완성도를 높일 수 있다. 이것은 레거시 시스템이나 암묵적으로
진행되는 비즈니스 프로세스를 SOA 서비스 모듈로 개발해야 하는 경우 모든 비즈니스 프로세스를 한꺼번에 서비스화
하지 않고 점진적인 구현을 유도하여 수시로 확인할 수 있기 때문에 효과적인 리스크 관리를 가능하게 한다.

서비스 품질 향상

SOA의 비즈니스 서비스는 재사용을 위해 만들어진다. 이러한 서비스의 재사용을 높이기 위해서는 실제 사용자 의견이
최대한 반영 되어야 하는데 이를 위해서는 서비스를 실제 적용하기 전에 사용자들에게 확인하는 것이 가장 좋은 방법일
것이다. Agile 방법론은 반복 개발할 때마다 작성된 서비스를 사용자들이 직접 확인할 수 있도록 해준다. 이러한 과정은
실제 사용자들에 대한 생생한 피드백을 얻게 되고 이를 반영하여 작성된 서비스들의 재사용성은 높아질 수밖에 없다.

 

맺음말

기업환경은 지속적으로 변화하고 있으며 그 변화의 주기도 짧아지고 있다. 또한 그 변화의 방향 역시 예측하기 어려운 상황이다. 이러한 환경에서 기업이 생존하기 위해서는 변화에 대한 신속한 대응을 필요로 하며 이를 위해 기업 시스템은 어떠한 비즈니스 요구사항에도 유연하고 민첩하게 지원할 수 있어야 한다. 그 대응방법의 하나로 등장한 Agile 방법론은 비즈니스 요구사항에 대하여 업무에 빠르게 적용될 수 있도록 신속하게 소프트웨어를 개발하며, 이렇게 전달되는 소프트웨어의 품질을 향상시키고, 비즈니스 관련자와의 협업 및 관계를 강화시켜주는 역할을 한다.

결국 이러한 과정을 통해 그동안 문제시 되어왔던 기업 비즈니스와 IT와의 원활한 연계를 향상시키는 것이다. Agile 방법론의 궁극적인 목적은 SOA와 같다. 다만, 그 방식이 다를 뿐인데 Agile 방법론이 신속한 소프트웨어 개발에 초점을 맞춘다면 SOA는 서비스 재사용을 통한 유연한 시스템 구축에 중점을 둔다. 이에, SOA 서비스 개발에 Agile 방법론을 접목시킨다면 좀 더 빠르게 재사용이 가능한 서비스를 개발하여 제공할 수 있을 것이다.

또한 이러한 서비스들은 반복 개발 주기마다 고객이 확인할 수 있기 때문에 품질 높은 서비스를 개발할 수 있으며 효율적인 리스크 관리도 가능해 진다. 이제 기업이나 IT 서비스 업체는 Agile 방법론과 SOA를 병행하여 소프트웨어의 개발에서부터 구축된 시스템까지 유연성과 민첩성을 확보할 수 있도록 고려해야 할 것이다.

글＿이영진 (LG CNS 정보기술연구소 책임연구원 yngjeanlee@lgcns.com)