UX AGILE 애자일

애자일(Agile)

애자일(Agile)은 ‘날렵한’, ‘민첩한’, ‘기민한’이란 뜻을 가진 형용사로, 애자일 개발 프로세스는 프로젝트의 생명주기 동안 반복적인 개발을 촉진하는 소프트웨어 엔지니어링에 대한 개념적인 얼개입니다. 최근에는 소프트웨어 엔지니어링뿐만 아니라 다양한 전문 분야에서 실용주의적 사고를 바탕으로 하는 많은 이들이 애자일 방법론을 적용하려는 시도를 하면서 어느 특정 개발 프로세스를 지칭하기보다는 정해진 계획에서 벗어나 개발주기 혹은 소프트웨어 개발환경에 따라 유연하게 대처하는 다양한 방법론 전체로 의미가 확장되어 가고 있습니다.

 

 

애자일 개발 프로세스 등장

90년대 후반까지 소프트웨어 공학의 개발방법론은 장기간에 걸쳐 많은 인력과 충분한 비용을 투입하여 진행하는 다른 공학의 프로세스와 비슷한 맥락에서 진행되었습니다. 이러한 방식은 대형 소프트웨어 개발 프로젝트엔 적합하나 소규모 프로젝트에서는 오히려 진행을 더디게 만드는 걸림돌로 작용하였습니다. 개발 환경이 점차 유동적이고 개방적으로 변화함에 따라 더 이상 정해진 계획에 의존하는 고전적인 소프트웨어 공학의 관리기법만으로는 대처할 수 없게 되었습니다. 이에 기술적인 해결책으로 객체지향 개발 기술 방법론이 사용되며 그에 적합한 새로운 프로세스 방법론의 필요성이 대두되었습니다.

 

<이미지 출처: 소프트웨어공학센터 ‘애자일 초심자를 위한 애자일 SW개발 101’>

 

2001년. 짐 하이스미스(Jim Highsmith)를 포함한 17명의 소프트웨어 개발자들이 ‘애자일 연합’을 결성하여 소프트웨어를 직접 개발하거나 또는 그와 관련된 사람들을 돕기 위한 더 좋은 방법을 알아내기 위해 ‘애자일 선언문’이라는 공동의 선언서를 만들어 냅니다. 이 문서는 지금까지도 애자일 소프트웨어 개발의 기초 원칙과 정신으로 이야기되고 있는 중요한 선언서입니다. 이들은 좀 더 빠르고 유연한 개발 방식을 논의하며 애자일 소프트웨어 개발이 무엇인지 정의하고, 이에 관련된 프로세스를 장려하기 위한 여러 활동을 시작하였습니다.

 

<이미지 출처 : 애자일 소프트웨어 개발 선언 http://agilemanifesto.org/iso/en/>

 

소프트웨어 개발은 인력이나 예산, 개발 환경과 같은 다양한 외부 조건에 영향을 받습니다. 애자일 방법론은 개발 환경을 고려해 고객과 개발자를 중심에 두어 고객이 개발 프로세스에 적극 참여하도록 하며 작업 우선 순위를 정하고 개발 과정을 평가할 수 있게 하였습니다. 그리고 계획에 집중하고 이를 강요하기 보다는 프로젝트 참여자의 능력에 따라 개발 환경이 유연하게 변경될 수 있도록 하였습니다.

 

 

 

폭포수 방법론과 애자일 방법론의 차이

고전적인 방법론의 대표주자 격으로 폭포수 방법론이 있습니다. 폭포수 방법론은 일련의 개별적인 단계로 구성됩니다. 진행과정이 세분화되어 관리가 용이하고 사례가 풍부하며, 전체 과정에 대한 이해가 쉽다는 장점이 있습니다. 

그러나 전체 프로젝트 팀에서 떨어져 나와 각 단계의 참여자가 격리된 채 프로젝트를 수행하게 되어 다른 단계의 참여자들과 협업하고 통합될 수 있는 기회는 거의 없습니다. 또한 각 단계에서 다음 단계로 이동되기 전에 최대한의 변수를 없애야 합니다. 각각의 분리된 단계는 이전 단계에서 산출물이 합의된 기준에 맞춰 완료되어 프로젝트 관리자가 수락하고 승인한 후에야 다음 단계로 실행될 수 있어 완료 시까지 긴 시간이 필요합니다. 그리고 고객과 사용자의 새로운 요구사항을 수용하기 위해서는 이전 단계, 혹은 처음 단계부터 다시 시작해야 하므로 즉각적인 대응이 어렵다는 단점이 존재합니다. 즉, 이전 단계에서의 기능적 의도가 다음 단계로 잘 유지하고 있는지에 따라 성공여부가 결정될 수 있습니다.

 

<이미지 출처: http://www.inqbation.com/waterfall-method-of-software-web-development/>

 

애자일 방법론은 더 작고 관리 가능한 단위의 업무로 나누어 반복적 개발방법과 테스트 주도 개발방법과 같은 개념을 사용한다는 것이 폭포수 방법론과의 차이점이라 할 수 있습니다. 두꺼운 프로젝트 문서에 의존하며 순차적으로 진행하는 폭포수 방법론과는 달리 애자일은 문서 작업에 들이는 시간을 줄여 각 참여자가 간단한 스케치나 메모로 의사소통을 진행함으로써 프로젝트 팀 구성원들 간에 프로젝트 생명 주기 내내 구두로 의사소통하고 협력할 수 있는 많은 기회를 제공합니다. 실질적인 작업 참여자들에게 작업 시간을 늘릴 수 있는 기회를 제공하고 프로젝트 전반에 대한 이해도를 공유해 나갈 수 있습니다.

애자일 프로젝트에서 성공의 주요 요소는 사실상 통합과 협력입니다. 기능에 맞춘 별개의 순차적 단계에서 벗어나 상호기능적인 협업과 동시 업무 진행 방식을 채택하여 프로젝트 초기 단계에서부터 전체 참여자가 최종 목표를 기억하고 끊임없이 공유할 시에 그 가능성을 더 높일 수 있습니다.

 

<이미지 출처: http://seanvail.wordpress.com/2014/09/10/what-is-agile-and-what-are-user-stories/>

 

 

 

애자일의 특징

애자일은 프로젝트 프레임워크를 넘어 지속적인 변화를 유지해야 하는 프로젝트에 유용한 방법론입니다. 많은 시간을 할애하며 큰 선행 과정을 요구하기보다는 저스트 인 타임(Just-in-time)과 저스트 이너프(Just enough)와 같은 접근법 원칙을 중요시하여 프로젝트 실제 수요에 맞추어 팀 내의 모든 구성원들을 적시에 다같이 참여시킵니다. 

출시까지 오랜 기간이 걸리던 고전 개발 방식에서 벗어나 계획과 개발, 출시로 이어지는 짧은 주기를 여러 번 반복하며 고객의 피드백에 짧은 시간 내에 민첩하게 반응할 수 있습니다. 또한 지연되는 상황에 관대하지 못한 빠른 변화를 요구하는 시장의 흐름에 맞추어 언제 필요한지, 어느 정도가 적절한지에 대해 인식하며 적기에 알맞은 제품을 내놓아 수익을 얻는 시간 동안 테스트 과정을 거칠 수 있습니다. 이 기간 동안 시장을 선점한 후에 실제 사용 환경에서의 지속적인 개선을 통해 사용자들의 꾸준한 참여와 높은 충성도를 유지할 수 있게 도와줍니다.

 

<이미지 출처: http://herdingcats.typepad.com/my_weblog/2011/02/>

 

 

 

애자일의 한계와 그 가능성

애자일 방법론은 소프트웨어 공학이 처음 등장한 1945년에 비하면 채 십여 년 정도 밖에 되지 않은 영역으로 대형 프로젝트에 적용하기에 적합하지 않은 면도 있으며, 관리 방법에 대한 가이드라인이 부족해 많은 보완이 필요합니다. 게임 개발 회사나 웹 애플리케이션을 만드는 솔루션 회사처럼 자 회사의 제품을 만드는 경우 채택하는 데에 큰 장벽이 없지만 SI 분야처럼 발주자와 수행 업체가 분리되어 있는 경우에 어떠한 근거로 감리를 해야 할지 그 경계가 모호하므로 도입 시 갖추어야 할 선수 조건에 따라 분명한 한계점을 가지고 있습니다.

그러나 ‘날렵한, 민첩한’이란 그 의미에 맞게 애자일은 프로젝트 전체 참여자에게 비전을 공유하고 원활한 의사소통을 도와 고객에게 빠른 시간 내에 산출물을 보여줄 수 있으며, 실제 사용환경에 적용하여 즉각적인 피드백을 바탕으로 제품을 더 빠른 주기 내에 향상시키고 지속적으로 개선시켜 시장에서의 생명주기를 오래 유지할 수 있다는 이점이 있습니다.

아직까지 애자일은 주류로 통하는 방법론이 아닙니다. 도입 분야에서의 성공과 실패 사례를 차용하여 그 장단점을 프로젝트 내부 환경에 적합하게 활용하며 그 경험을 바탕으로 개선시켜 나간다면 방법론으로서 매우 유용할 것입니다.

 

 

 

 

 

참고서적 및 인용자료

- ‘애자일 UX 디자인 – 지속적인 린 방식의 애자일 프로젝트 성공’, 가이드 린지 래트클리프, 마크 맥닐 저

- ‘애자일 초심자를 위한 애자일 SW개발 101’, 소프트웨어공학센터

- 위키백과 : http://ko.wikipedia.org/wiki/애자일_소프트웨어_개발

- 마이크로소프트웨어 : http://www.imaso.co.kr/?doc=bbs/gnuboard.php&bo_table=article&wr_id=34587

[출처] [바이널 X] UX 디자이너들의 필수 용어 사전: Agile (애자일)|작성자 바이널엑스