[clearfix]
1. 개요
Agile Software Development소프트웨어 개발 방법론의 하나로, 처음부터 끝까지 계획을 수립하고 개발하는 폭포수(Waterfall) 방법론과는 달리 개발과 함께 즉시 피드백을 받아서 유동적으로 개발하는 방법이다.
정식 명칭은 애자일 소프트웨어 개발(Agile[1] Software Development). 한국에서는 주로 애자일 방법론 이라고 부른다. 켄트 벡이 주창한 익스트림 프로그래밍(XP, Extreme Programming)과 테스트 주도 개발이 대표적이다.
2. 애자일 선언문
Manifesto for Agile Software DevelopmentWe are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
© 2001, the Agile Manifesto authors
This declaration may be freely copied in any form, but only in its entirety through this notice.
애자일 선언문 전문Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
© 2001, the Agile Manifesto authors
This declaration may be freely copied in any form, but only in its entirety through this notice.
애자일 소프트웨어 개발 선언
우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다.
이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:
공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를
가치 있게 여긴다.
이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler,
James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin
Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
© 2001, 상기 저자들
이 선언문은 어떤 형태로든 자유로이 복사할 수 있지만, 본 고지와 함께 전문으로서만 가능하다.
한국어판 애자일 선언문 [2]우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다.
이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:
공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를
가치 있게 여긴다.
이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler,
James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin
Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
© 2001, 상기 저자들
이 선언문은 어떤 형태로든 자유로이 복사할 수 있지만, 본 고지와 함께 전문으로서만 가능하다.
보다시피 "왼쪽에 있는 것들도 가치가 있지만"을 간과해서는 안 된다. "애자일을 사용하니까 그 어떤 공정도 도구도 문서도 계획도 만들지 않겠다"라고 딱 잘라 말할 수는 없다는 것. 애자일 프레임워크를 설명하고 있는 각 단체의 자료를 살펴보면 거기서도 각종 공정과 도구와 문서를 심심찮게 다루고 있다. 물론 그것들을 우측에 언급된 것들에 대해 가중치를 두려는 목적으로 사용하기는 하지만.
3. 기원
애자일 방식의 소프트웨어 개발에 대한 방법론들이 처음 등장하기 시작한 것은 90년대 중반으로 기존의 무겁고 규범적인 방법론에서 탈피하여 가벼운 방법론을 지향하며 등장하였다. 처음부터 애자일(Agile)이라고 불렸던 것은 아니고 경량방법론 등으로 불리다 애자일 선언문(Agile Manifesto)을 만들면서 비로소 Agile로 불리게 되었다. 이후부터 애자일은 소프트웨어 개발의 한가지 특징적인 개발 방식으로 의미를 갖기 시작하였다.4. 현장에서의 애자일 개발의 현실
빠르고 기민한, 이라는 이름 덕인지 수많은 기업들이 나서서 애자일로 개발한다고 떠들고 있지만, 정작 실상은 애자일이 뭔지도 모르면서 기획서를 통과시키기 위해 붙이는 전문용어중 하나의 취급일 뿐이다. 애자일을 제대로 하려면 QA 인력도 필요한데, 애초에 애자일 방법론은 하나의 개발 모델이 아니라, 여러 개의 개발 방법론이 있는 개발 방법론 집합체의 원칙에 가깝다. 만약 회의실에서 사업이나 기획자가 애자일 방법론을 언급 한다면 이렇게 물어보길 바란다. 애자일 방법론중 어떤 방법론 말인가요?이렇게 된 배경에는 다음과 같은 설이 존재한다.
원래 컴퓨팅서비스는 1990년 대 후반까지만 해도 IBM등의 공룡사업자가 만드는 메인프레임 판이었고, 이 메인프레임에 더미터미널 콘솔을 붙여 서비스를 했다. 그 때는 검은 화면에 초록 또는 회색 글씨만 가득찬 화면 구성이라, 키보드 입력 편의성 개선이 제일 중요했다. 그런데, 이후 PC가 보급되면서, 메인프레임이 독점했던 상당량의 컴퓨팅 자원을 굳이 메인프레임이 사용하지 않고, 최종 사용자 단의 PC가 나눠져도 되는 환경이 되었으며, 이에 따라, 클라이언트/서버 환경으로 변화(라고 쓰고, 업계에서는 다운사이징이라 불렀다)했다. 이러한 컴퓨팅 환경이 재차 웹시대로 진화하고, 모바일 시대로 흘러가지만, 지금까지도 개발/관리 방법론은 폭포수 모형[3]일 때의 그것을 그대로 쓰고 있었다. 기술의 변화에 따라, 개발 환경이 변했지만, 25년 동안 방법론의 변화가 없었던 것이다.
4.1. 한국
한국개발 시장, 특히 SI 에서의 애자일은 정식적인 설명과는 전혀 다른 모습을 드러내곤 한다. 실제로 애자일 형태로 개발할 능력도 없고, 있다 해도 시간적, 금액적 한계 때문에 애자일을 쓰면 안되지만, 큰 규모의 사업 / 대기업에서 사용되었다는 미명으로 소형 개발 업무에서도 사용하겠다는 기괴한 포부와 함께 사용되곤 한다. 실제 개발 시작전에는 애자일을 응용한 엄청난 개발을 해줄게! 로 시작하지만 막상 개발을 시작하면 한국 특유의 노예관리 형태로 변질된다.[4] 여전히 대한민국 대부분의 기술개발자들은 애자일은 커녕 타임어택 형식의 개발 지옥에서 살아가고 있다.애자일이 제대로 돌아가기 어려운 것은, 말만 애자일이지 결국 워터폴 방식으로 운영을 하게 되기 때문이다. 애자일의 장점은 예측이 어려운 부분을 대응하는 데에 있어서 어느정도의 해답을 준다는 부분인데, 대다수의 한국 업체들은 모든 것을 다 짜둔 상태에서 프로젝트를 시작하며, 설사 준비가 제대로 안 된 상태에서 일을 시작하더라도 이를 애자일 방법론대로 나중에 결정하게 놔두는 경우가 없고 불확실한 부분을 최대한 빨리 확정부터 하려고 한다. 갑을 관계가 희박한 분야에서도 이러한데, SI의 경우는 말할 것도 없다. 일을 주는 쪽에서는 내부적으로 개발 과정이 어떻게 돌아가는지 전혀 관심이 없고, 현재 개발자측 가용자원이 어떻게 되든지도 당연히 아웃 오브 안중이고, 돈을 틀어쥐고 "시간 내로 끝내지 않으면 끝장이야!" 하는 엄포를 놓는다. 이런 역학구조는 활발한 의사소통, 끊임없는 프로세스 개선, 단순한 사이클의 반복을 통해 실제로 동작하는 기능을 조금씩 늘려나가는 것이 핵심인 애자일 방법론과 영 맞지가 않는다. 계약서대로 정해진 시간 내에 정해진 스펙대로 물건을 만들면 되는 상황에 애자일을 끼워넣을 이유가 도대체 뭐가 있단 말인가. 결국 앞뒤 다 자르고 "중간에 요구사항 추가가 있겠지만 추가 금전 보상이나 가용 자원 조정은 없음."을 애자일이란 이름하에 에둘러 표현하는 것이나 다름 없다. 상술한대로 이는 야근을 의미할 뿐이다.
메시지 전달방향이 고정되어 있다면 시간낭비 자원낭비하지 말고 애자일의 A도 꺼내지 말고 그냥 기존대로(워터폴) 하는 게 낫다. 도구에는 죄가 없고, 모든 것은 사용하는 사람에게 달렸을 뿐이다. 이 글을 읽는 사람이 의사 결정권자라서 이 부분을 조절할 수 있는 상황이라면, "요구사항을 추가하고자 할 때, 새 리소스를 얻어다주거나 대신 다른 기능을 기꺼이 포기할 준비가 되어 있는가?", "개발 진행이 예측대로 잘 되지 않은 상태에서 릴리즈 날짜가 다가올 때, 야근을 요구하지 않고 완성된 기능만 가지고 릴리즈를 하거나 출시일을 미룰 수 있는가?" 이 두 가지 질문에 대해 스스로 답변을 내어 보길 바란다. 둘 중 하나라도 No가 나온다면, 애자일을 할 이유가 전혀 없고 해봤자 역효과[5]만 날 것이다.
폭포수 모델과 같이 애자일 또한 만능이 아닐 것이다. 하지만 왜 폭포수 이후 애자일이 탄생했을지도 충분히 돌아봐야한다. 지금보다 더 열악하면 열악했을 과거의 개발 환경에서 누구에 의해 애자일 선언문이 탄생되었고, 현재에 이르러 전파되는지는 비단 한쪽만의 요구라고 할 수 없을 것이다. 이 또한 스스로 답변을 내어 보길 바란다. 폭포수든 애자일이든 둘 중 하나라도, 없는 것보다 나은 결과를 가져온다면, 그 장점들을 어떻게 활용할 지 생각해나가야 한다.
4.2. 일본
애자일 방법론의 기원[6]이라 할 수 있는 나라지만 정작 애자일과는 거리가 한참 먼 나라이기도 하다.혹여 일본 IT 업체에 취직하거나, 혹은 파견을 나갈 일이 있다면, 프로젝트 진행을 설명할 때 높은 확률로 애자일 방법론으로 진행 할 건데, 할 수 있겠습니까? 라는 말을 들을 수 있다. 그리고 이것은 우리는 네가 개발할때 수시로 아무때나 설계와 스펙 변경을 끝도 없이 요구 할 작정인데 거기에 불평불만 없이 응해 줄 수 있습니까? 이란 소리로 해석하면 된다.
관료주의적 성향이 극도로 심한 일본 대기업은 IT라고 해도 엄청난 양의 문서를 남기는 경향이 있는데, 이것은 위에 말한 애자일 방법론의 기본 원칙중 포괄적인 문서보다 작동하는 소프트웨어를에 정면으로 위배된다. 기본 틀이 되는 기업 문화 부터가 이러하니 애자일 방법론이 먹힐 가능성 자체가 없다.[7]
4.3. 영미권
인간관계 및 업무 협력이 동양권 회사들보다 훨씬 수평적이고, 소프트웨어 공급 면에서도 갑과 을이 칼같이 정해져있는 경우가 많지 않은 영미권 회사들은 애자일을 도입하기가 훨씬 수월한 상황. 그래서 애자일이 요구하는 직급을 회사에 신설까지 해가며물론 이 문서 전체적인 분위기가 그렇듯 애자일이 만능은 아니다. 마케팅 활동을 겸해서 성공한 사례가 지나치게 고평가, 과대평가 되어 있는 경우도 있다. 서구권에서도 애자일 어프로치를 적용한 실패 사례나 오히려 워터폴을 적용해야 할 프로젝트, 예컨데 회사 합병 과정에서의 기간 시스템 통합처럼 납기일이 정해져 있는데 비해 양 회사의 업무 프로세스 통합 등 요건 정의에 필요한 제반 준비가 제대로 이뤄지지 않는 프로젝트를 애자일로 진행하는 바람에 1~2년만에 끝내야 할 회사 통합이 수년에 걸쳐 미뤄지면서 막심한 금전적 손해를 내는 사례도 엄연히 존재한다. 그러나 이런 실패를 바탕으로 지속적인 방법론의 개선과 자기들의 체질 개선, 필요할 경우에는 상술된 조직의 리스트럭처링까지 감수하는, CIO나 그 이상의 경영층의 커미트먼트가 있었기에 성공 사례도 나오고 있는 것이다. 어떤 방법론이든 마법은 없고 그저 누가 어떻게 활용하느냐에 달렸을 뿐이라는 평범한 진리다.
[1] 기민한 내지는 민첩한 등으로 번역된다.[2] 번역 상태가 그리 썩 좋지는 않다. 번역 과정에서의 의미 변질 논란을 피하기 위해 자연스러움을 희생하고 최대한 직역에 가까운 표현을 의도적으로 사용한 것일 수 있다.[3] https://ko.wikipedia.org/wiki/%ED%8F%AD%ED%8F%AC%EC%88%98_%EB%AA%A8%EB%8D%B8[4] 애자일에서 중시하는것은 개발시작단계부터 이해당사자의 적극적 참여를 요구한다. 외주환경에 차이는 있겠지만, 대부분의 경우 개발을 요청한 쪽은 명세서 만들어 던져놓고 결과물만 받기를 원하므로 정상적인 애자일 프로세스가 돌아가기 힘들다.[5] 다만, 애자일이 지향하는 바는 여전히 의미가 있고, 이러한 시도 속에서 페어 프로그래밍과 같은 긍정적인 효과도 분명 있고 활용되고 있다. 그리고 애자일 선언이 위 두가지 질문에 대한 답변은 아니다. 답변은 사용하는 사람에게 달렸다. 이 문단의 저자와 같이. 마지막으로 기획자도 야근한다[6] 카이젠 원칙을 비롯해 애자일이란 방법론이 구성되는데 가장 큰 영향을 끼친 혁신이 일어난 곳이다.[7] 단, 소규모 사업장이나 게임 회사는 예외인 경우도 많다[8] 물론 애자일이 아니라 애자일 할아버지라도 아예 모르는 걸 알아낼 방법은 없다. 단지 변화하는 상황에 좀 더 유연하게 대처할 수 있을 뿐이다.