애자일(Agile) 소프트웨어 개발

Computer Science/Software Engineering 2012. 4. 12. 21:56

애자일 소프트웨어 개발(Agile software development) 혹은 애자일 개발 프로세스는 소프트웨어 엔지니어링에 대한 개념적인 얼개로, 프로젝트의 생명주기동안 반복적인 개발을 촉진한다. 최근에는 애자일 게임 보급 등의 여파로 소프트웨어 엔지니어링 뿐 아니라 다양한 전문 분야에서 실용주의적 사고를 가진 사람들이 애자일 방법론을 적용하려는 시도를 하고 있다.

[편집]개념

애자일 개발 프로세스란 어느 특정 개발 방법론을 가리키는 말은 아니고 "애자일(Agile=기민한, 좋은것을 빠르고 낭비없게 만드는 것) 개발을 가능하게 해 주는 다양한 방법론 전체를 일컫는 말이다. 예전에는 애자일 개발 프로세스는 "경량(Lightweight)" 프로세스로 불렸다. 익스트림 프로그래밍 (XP:eXtreme Programming)이 애자일 개발 프로세스의 대표적인 방법이라 볼 수 있다

[편집]개발 배경

애자일 프로세스의 배경에는 소프트웨어 개발 자체가 다른 공학적인 프로세스와는 큰 차이가 있음을 인지하는 데에서 부터 시작되었다. 이는 소프트웨어 위기의 원인과 해결방안을 찾는 데에서 부터 시작되었다.

90년대 후반까지의 소프트웨어 공학과 개발방법론은 장기간에 걸쳐 많은 사람들을 투입하고 충분한 비용을 투입하여 진행하는 다른 공학의 프로세스와 비슷한 맥락에서 진행되었다.

그러나 소프트웨어는 유동적이고 개방적이다. 또한, 요구사항의 변경에 따른 작업량을 예측하기 힘들다. 그래서 이미 고전적인 소프트웨어 공학이나 관리 기법만으로는 대처할 수 없게 되었다.

이런 문제에 대한 기술적인 해결책으로 객체지향이 있다. 객체지향 기술은 그동안의 개발 문제를 적절하게 대처해 주었다. 그리고 객체지향 개발을 하기 위해서는 그에 적합한 개발 프로세스가 필요했다. 그래서 수많은 애자일 개발 프로세스가 이러한 필요에 따라 만들어졌다. 따라서 애자일 개발 프로세스의 상당수는 객체지향 기술을 기반으로 한다.

애자일 개발 프로세스는 제한된 시간과 비용 안에서 정보는 불완전하고 예측은 불가능하다는 전제를 가진다. 그리고 그 전제 아래에서 합리적인 답을 내도록 하는 것이 애자일 개발 프로세스이다.

[편집]애자일 개발 프로세스와 전통적인 개발 프로세스와의 차이

전통적인 개발 프로세스들은 폭포수 모델과 계획 기반 개발을 따르는 반면, 애자일 개발 프로세스는 그에 반한다는 점에서 가장 큰 차이를 가진다.

폭포수 모델과 계획 기반 개발 기법들은, 일련의 차례와 탄탄한 계획을 기반으로 하여 개발을 진행시킨다. 이것은, 이해하기도 쉽고 사용하기도 쉬운 바람직한 기법이기도 하지만, 이로 인해서 많은 부작용이 생길 수 있다. 가장 큰 부작용이 발생할 때는, 계획대로 진행되지 않을 경우이다. 이럴경우에는 다음과 같은 부작용이 발생하게 된다.

납기일 전 철야
철야에도 불구하고 납기일 지연
지연에 따른 비난과 스트레스가 개발자에게 향하여 에너지 소진
결국 납품된 솔루션은 고객의 요구를 충족하지 못함

이런 부작용은 근본적인 개발 프로세스 접근법의 차이에서 나타난다. 전통적인 개발 프로세스들은 공업에서 사용하는 정형적 프로세스 제어 모델을 따르고 있다. 정형적 프로세스 제어모델은, 동일한 입력에 대해서 동일한 결과가 기대 될 경우에 적합하다. 하지만, 소프트웨어를 포함한 IT의 개발은 경험적 프로세스 제어 모델로 접근할 필요가 있다. 경험적 프로세스 제어 모델은 항상 불확실성을 수반하고 포용하고 있다. 애자일 개발 프로세스는 경험적 프로세스 제어모델로 개발을 관리한다.

[편집]종류

애자일 개발 프로세스로 불리는 개발 방법론에는 다음과 같은 것들이 있다.

익스트림 프로그래밍(Extreme Programing, XP) - 애자일 개발 프로세스의 대표자로 애자일 개발 프로세스의 보급에 큰 역할을 하였다. 이 방법은 고객과 함께 2주 정도의 반복개발을 하고, 테스트와 우선 개발을 특징으로 하는 명시적인 기술과 방법을 가지고 있다.

스크럼 - 30일마다 동작 가능한 제품을 제공하는 스플린트를 중심으로 하고 있다. 매일 정해진 시간에 정해진 장소에서 짧은시간의 개발을 하는 팀을 위한, 프로젝트 관리 중심의 방법론이다.

크리스털 패밀리 - 이 방식은 프로젝트의 규모와 영향의 크기에 따라서 여러종류의 방법론을 제공한다. 그중에서 가장 소규모 팀에 적용하는 크리스털 클리어는 익스트림 프로그래밍 만큼 엄격하지도 않고 효율도 높지 않지만, 프로젝트에 적용하기 쉬운 방법론이다.

Feature-Driven Development - feature마다 2주정도의 반복 개발을 실시한다. Peter Coad가 제창하는 방법론으로써, UML을 이용한 설계 기법과도 밀접한 관련을 가진다.

Adaptive Software Development, ASD - 소프트웨어 개발을 혼란 자체로 규정하고, 혼란을 대전제로 그에 적응할 수 있는 소프트웨어 방법을 제시하기 위해 만들어진 방법론이다. 내용적으로는 다른 방법론들과 유사하지만, 합동 애플리케이션 개발(Joint Application Development, 사용자나 고객이 설계에 참가하는 개발 방법론)을 사용하고 있는것이 조금 다르다.

익스트림 모델링 - 익스트림 모델링은 UML을 이용한 모델링 중심 방법론이다. 다만, 여타 모델링 방법들과는 달리, 언제나 실행할 수 있고 검증할 수 있는 모델을 작성하는 공정을 반복해서, 최종적으로는 모델로부터 자동적으로 제품을 생성하게 한다.

상기 소개된 애자일 개발 프로세스들은 각자 다른 특징과 적용 범위가 있으며, 서로 조합도 가능하다. 애자일 개발 프로세스를 채용하고 있는 프로젝트에서는 특정 방법론만을 채택해서 매뉴얼대로 흉내만 내는 것이 아니라, 여러 방법중에서 자신의 프로젝트에 맞는 부분을 취사 선택하여 조합하고, 또 독자적인 방법을 만들어 냄으로써 큰 효과를 올리고 있다. 이러한 애자일 개발 프로세스의 제창자들은 애자일 연합이라는 자유로운 조직을 만들고, 애자일 개발 프로세스의 보급에 힘쓰고 있다.

[편집]애자일 선언문

애자일 연합에서 추구하는 사상은 그들이 선언한 아래와 같은 글에서 잘 나타난다.

우리는 스스로 행하고 다른 이들도 이를 행할 수 있도록 도움을 줌으로써 소프트웨어 개발의 더 나은 방법을 전파한다. 이러한 작업을 통해 우리는 아래와 같은 가치에 도달하게 되었다.

절차와 도구를넘어선 개성과 화합
종합적인 문서화를 넘어선 동작하는 소프트웨어
계약과 협상을 넘어선 고객과의 협력
계획 준수를 넘어서 변화에의 대응

이들의 앞선 가치들을 인정하면서도 뒤에 오는 가치들에 보다 큰 무게를 둔다.

[편집]적용 대상

애자일 개발 프로세스를 필요로 하는 조직은 크게 두 가지로 나뉜다.

하나는 목표 달성을 위한 프로세스를 가지지 않고, 임기응변적인 소프트웨어 개발로 인해 혼란에 빠져있는 조직이다. 이러한 프로젝트 팀에게 있어 애자일 개발 프로세스는, 개선을 위한 좋은 힌트가 될 것이다. 애자일 개발 프로세스는 작고 쉽게 도입할 수 있으며, 그것에 들어가는 비용과 위험도 낮다.
두 번째는 이미 전통적인 소프트웨어 프로세스를 도입하고 있지만, 제대로 동작하지 않는(또는 프로세스 실시를 위한 오버헤드가 너무 커서 오히려 업무에 부담을 주고 있는) 조직이다. 프로세스의 도입은 조직의 문화를 바꾼다. 효과가 크면 클수록 조직문화에 대한 영향은 커지고, 도가 지나치게 되면 고유의 문화를 파괴해 버리기도 한다. 그러나 조직에 있어서 애자일 개발 프로세스는 좋은 결과를 가져다 줄 것이다. 또한 CMMI나 SPICE등의 인증을 얻으려고 하는 조직에서는 그들의 요구를 충족시킬 아이디어를 제공해 줄 수 있을 것이다.

[편집]같이 보기

[편집]외부 연결

===================================================================================

소프트웨어 위기(software crisis)

소프트웨어 위기(software crisis)란 소프트웨어 공학 초기에 사용되던 용어로 정돈된 주제가 되기 이전에 사용되었다. 이 용어는 급격한 컴퓨터 계산 용량과 문제의 복잡성이 급격히 증가함에 따라 발생한 충격을 서술하기 위하여 사용되었다. 본질적으로, 이는 정확하고 이해할 수 있고, 검증 가능한 컴퓨터 프로그램을 작성하는 것이 얼마나 어려운가를 뜻한다. 소프트웨어 위기의 뿌리는 복잡성, 기대, 그리고 변화 이다.

상충하는 요구조건들은 항상 소프트웨어 개발 과정에 지장이 되어 왔다. 예를 들어, 사용자는 많은 수의 기능을 요구해온 반면 구매담당자는 일반적으로 소프트웨어의 가격과 개발 시간을 최소화하기를 원했다.

소프트웨어 위기라는 용어는 F. L. 바우어가 처음 1968년 독일 가미시에서 열린 첫 번째 나토 소프트웨어 공학 학회^[1]에서 사용되었다. 에츠허르 데이크스트라의 1972년 ACM 튜링상 수상 연설^[2]에서도 이 용어가 등장하였다.

소프트웨어 위기의 주요한 위기는 컴퓨터 성능이 몇수십배나 더 강력해졌기 때문입니다! 심하게 말하면: 컴퓨터가 없었을 때는 프로그래밍에는 전혀 문제가 없었습니다; 느린 컴퓨터 몇 개 뿐이었을 때는 프로그래밍이 조금 문제가 되었고, 이제는 거대한 컴퓨터에 프로그래밍도 비슷하게 거대한 문제가 되었습니다.
– 에츠허르 데이크스트라, 겸손한 프로그래머 (EWD340)

소프트웨어 위기의 원인은 전반적인 소프트웨어 프로세스의 복잡성과 소프트웨어 공학이 전문분야로서 상대적으로 미성숙한점에 관련되어 있다.

소프트웨어 규모의 대규모화, 복잡화에 따른 개발비용 증대
하드웨어 비용에 대한 소프트웨어 가격 상승폭 증가
유지보수의 어려움과 개발적체 현상 발생
프로젝트 개발 및 소요예산 에측의 어려움
신기술에 대한 교육 및 훈련의 부족

위기는 여러 가지 증상으로 나타났다:

프로젝트 예산이 초과되었다.
프로젝트 일정이 지연되었다.
소프트웨어가 비효율적이었다.
소프트웨어 품질이 낮았다.
소프트웨어가 요구 사항을 만족시키지 못하는 일이 빈번히 일어났다.
프로젝트는 관리 불가능했고 코드 관리는 힘들었다.
소프트웨어가 고객의 손에 전달 되지 못했다.

소프트웨어 위기를 "길들이고자" 다양한 과정과 방법론이 지난 수십 년간 개발되어 다양한 수준의 성공을 보였다. 그러나, 널리 양해된 견해는 "만병 통치약은 없다" 즉, 단일한 접근 방식으로 프로젝트 초과와 실패를 모든 경우에서 방지할 수 있는 것은 없다는 것이다. 일반적으로, 소프트웨어 프로젝트가 대규모이고, 복잡하고, 요구 조건이 명확하지 않고, 낯선 측면을 내포할 경우 여전히 사실상 커다랗고 예측 불가능한 문제에 취약하다.

[편집]대응 방안

여러 소프트웨어 공학 수단을 더 적극적으로 활용하는 것이 한가지 해결책이 될 수 있다.

[편집]임베디드 시스템 소프트웨어 위기

최근 소프트웨어를 포함하는 임베디드시스템이 증가하면서 관련 사고와 문제가 증가, 사회적으로 작지 않은 영향을 끼칠 가능성이 증가하는데, 이도 소프트웨어 위기와 관련되어 있다.^[3] ^[4]

[편집]원인

임베디드시스템에는 실시간성 하드웨어에 대한 이해를 비롯, 다양한 분야에 대한 고도의 스킬이 필요하나 전산개발자에 대한 열악한 처우로 다수의 이직자가 발생, 베테랑이 부족한 가운데 필요 기술 수준은 상승하고 있다.
휴대전화, 디지털 가전등의 예에서 보듯이 소프트웨어 규모가 비약적으로 증대하고 있으나 하드웨어 자원의 제약과 실시간성 구현의 문제로 IT 업계에서 지금까지 이용되어 왔던 방안들이 그대로 적용되기는 쉽지 않다.
이공계기피 현상, 가전기기의 블랙박스화로 전자공학과 하드웨어 관련 흥미를 쌓을 기회가 감소하고 있다.

[편집]대책

단기적 경쟁 입찰 보다는 장기적 전략 필요
소프트웨어 공학의 근본적 문제점을 재조명
- 요구사항, 재사용, 척도, 시각화, ...
소프트웨어 시험 자동화^[5]
규모 가변성 프로세스와 인프라 도입^[5]
Microsoft Windows CE와 임베디드 리눅스 등 IT계열에 더 가까운 OS를 탑재하여 IT계통 개발 방안의 도입을 더 쉽게 하여 IT계열 소프트웨어 엔지니어의 활용도를 늘린다.
여러 회사에서 펌웨어를 공통화하여 공동개발한다.
인재 파견 회사에서 임베디드 엔지니어 양성 프로그램을 실시한다.

[편집]같이 보기

인공지능 겨울

[편집]참고문헌

↑ NATO Software Engineering Conference 1968
↑ 에츠허르 데이크스트라. 겸손한 프로그래머. 2009년 6월 30일에 확인.
↑ Mikio Aoyama (2004년 5월 26일). 일본내 소프트웨어 공학의 도전. 2009년 6월 30일에 확인.
↑ 홍성수 (August 2000). Coping with Embedded Software Crisis using Real-Time Operating Systems and Embedded Middleware (PDF). 2009년 6월 30일에 확인.
↑ ^가 ^나 Mark Underseth (08 Jun 2007). Addressing the hidden embedded software crisis in the industry. 2009년 6월 30일에 확인.

저작자표시

'Computer Science > Software Engineering' 카테고리의 다른 글

Multitier architecture (0)	2012.11.22
DRY(Don't repeat yourself) (0)	2012.11.22
상관 모델링(CRUD MATRIX) (0)	2012.04.09
프로그래밍 순서 및 순서도(Flowchart) (0)	2012.03.12
요구사항정의서(명세서) (0)	2012.03.07

Posted by linuxism

linuxism