애자일(Agile) 이란

애자일(Agile) 이란

---

• 흔히 개발 ‘방법론' 혹은 ‘프로세스' 라고 얘기하지만 와닿지 않는다.
• ‘일하는 방식' 정도로 생각하자.
• 기존 소프트웨어 개발을 할 때 사용하던 전통적인 방식 (구닥다리 방식) 이 아닌 여러 거장들이 ‘유연하게 일하는 방식’ 을 정의한 것이다.
• 실제 애자일이라는 용어 자체가 ‘기만한', ‘재빠른', ‘민첩한' 이라는 뜻을 가지고 있다.

 

 

 

기존 전통적인 방식 (구닥다리 방식)

---

전통적인 방식 이라면, 정확히 어떤 방식인지 ‘책을 집필하고 출판하는 과정’ 을 예시로 설명해보겠다.

• 저자가 기술 서적을 쓰기로 마음 먹음
• 출판사에 저자의 기획안을 제출
• 출판사 는 책 출판을 결정
• 저자와 출판사는 계약을 하고 저자는 집필 시작
• 탈고일이 6개월 이라 가정, 출판사는 프로그레스를 중간 중간 점검함
• 저자와 출판사가 약속했던 책의 최종 모습이 있지만 처음 계획과는 틀어질 가능성이 있다.
• 초기에 출판사는 입문자가 볼 수 있는 쉬운 책을 요구하였으나, 6개월이 지난 후 전체 글을 읽어보니 너무 어려운 수준

⇒ 처음부터 저자와의 커뮤니케이션이 잘못된 것이다.

6개월이 지나서야 저자 와 출판사 는 다시 고민한다. 그대로 출판할 것인가? 다시 쓸 것인가?

 

 

위 문제의 근복전인 원인

1. 저자와 출판사는 각각 생각하는 것이 달랐음. 
2. 탈고 전까지 전체 내용을 확인 할 수 없었음. 
3. 6개월이 지난 후에 문제점이 발견되어 고치려하니 비용이 너무 많이 듬. 
4. 그냥 출판하자니 출판사가 원하는 모습이 아님.
5. 급하게 고친다 하더라도 책의 품질은 떨어짐.
6. 집필 초기에 문제점을 발견했다면, 쉽게 수정할 수 있었다.

 

 

위의 책을 만드는 과정은 소프트웨어 개발 방식 중 폭포수 개발 방식 과 매우 유사하다.

• 제안 -> 기획 -> 집필 -> 탈고 -> 교정 -> 출판
• 요구사항 분석 -> 설계 -> 개발 -> 테스트 -> 배포

폭포수 개발 방식은 해결하고자 하는 문제점이 무엇인지 명확하고, 솔루션도 구체적이라면 해당 방식도 유용한 면이 있다.

 

간단한 예로, 100권 짜리 백과사전에 있는 내용을 모두 전산화하는 프로젝트 일 경우 1권씩 차례대로 한장 한장 옮기면 된다.

화면이 복잡하지도 않을것이고, 개발하는 속도 측정도 무척 간단하다. (한 페이지 전환 시간 x 전체 페이지)

 

최종 결과물도 뚜렷하여 이런 경우엔 폭포수 개발 모델도 사용 가능하다. 하지만 대부분의 소프트웨어 개발은 고객의 요구사항 변경으로 인해 실패하는 경우가 대부분이다.

 

대부분의 개발 프로젝트는 고객의 Needs 에 의해 시작되는데, 고객 본인도 원하는 것을 잘 표현하지 못하고 잘 모르는 경우도 많다. 이유는 개발 과정이나 어려움을 잘 모르기 때문에 생기는 문제가 대부분이다.

 

예를들어, 어느 정도 개발이 된 화면을 고객이 보고 레이아웃을 바꿔보자는 제안를 한다던가, 일주일에 거쳐 수정을 하였는데 예전것이 더 좋다며 번복하는 상황들이 비일비재 하다.

 

해외의 경우엔 사전에 충분히 고객에게 인지를 시키고 비용을 추가적으로 지불해야 한다 는 대책을 세워 놓지만 그럼에도 변경요청이 들어오면 다시 철저하게 분석 후 변경을 진행하는데 좋은 대안이 되지는 못하였고 실패로 이어졌다.

 

이를 해결하고자 소프트웨어 세계의 거장들이 모여 선언문을 작성하게 되는데, 이것이 2001 년에 선언된 ‘애자일 소프트웨어 개발 선언' 이다.

 

[참고]

http://agilemanifesto.org/iso/ko/manifesto.html

 

 

켄트 백, 익스트림 프로그래밍 p.36  내용 

소프트웨어의 모든 것은 변한다.
요구사항은 변한다.
설계도 변한다.
비지니스도 변한다.
기술도 변한다.
팀도 변한다.
팀 구성원도 변한다.
변화는 반드시 일어나기 때문에 문제가 되는 것은 변화가 아니라 변화를 극복하지 못하는 우리의 무능력이 문제다.

 

 

변화는 반드시 일어나기 때문에 문제가 되는 것은 변화가 아니라 이를 극복하지 못하는 무능력이 문제라고 적혀있다.

 

그렇다면, 전통적인 방식으로 개발한다면 반드시 일어나는 변화를 대체하기 힘들다 라는 것은 알겠는데 유연하게 일하는 방식 즉, 애자일스럽게 개발한다는 것은 무엇을 말하는것일까?

 

 

 

애자일 방식을 적용한 집필

---

 

저자 는 애자일스럽게 책을 써보려한다.

 

여러 주제를 두고 어떤 책을 쓸지 고민하고는 있지만 어떤 책이 좋을지 확신이 서질 않는다. 그저 ‘책을 쓰고 싶을 뿐' 이다. 긴 시간을 낭비하고 싶지 않다. 저자 는 브런치 라는 글쓰기 폴랫폼에 관심이 많았고, 작가로 선정 되어야만 글을 쓸 수 있는 자격이 주어지고, 인기가 좋으면 책으로 출간도 해준다고 한다.

 

저자는 고민 끝에 ‘SW 개발자로 취업하기 위해서 필요한 지식' 을 주제로 글을 쓰기로 결정하였다. 3시간에 걸쳐서 첫 글을 썻고 인터넷에 공개하였다. 자고 일어나니 조회수와 공유수가 괜찮은 반응임을 확인할 수 있었다.

 

즉, 3시간 이라는 짧은 시간에 작성한 글을 통해 해당 주제가 가능성이 있음을 확인하였다.

 

두번째 글도 후속편으로 작성하였고 이 역시도 반응이 좋았다. 하지만 이 번 글에 문제가 있음을 파악하였고 내용 중 일부가 잘못되었다는 소식을 독자로 부터 전달 받았다. 저자는 자신의 지식이 일부 잘못된것을 알게되었고 쉽게 수정하여 업로드하였다.

 

저자는 학습을 했고, 쉽게 수정했다.

 

조기에 발견하지 못하여 저자가 학습하지 못했다면, 이후의 글에도 잘못된 정보들이 기재될 것이고 신뢰를 잃을 것이다. 이렇게 계속해서 써 나가다 보니 이를 엮어서 책으로 출판하고 싶어졌다. 저자는 이미 글을 쓴 상태였고, 출판사도 내용을 이미 알고 있고, 책의 내용에 대한 이해의 차이가 거의 없는 상황이다. 

 

즉, 고객의 변경을 실시간으로 반영하였다.

 

해당 글을 좋아해주는 팬도 생겼고, 댓글로 피드백을 준 것을 반영함으로써 검증도 끝마친 상황이였다. 서로가 원하고 만족하는 책을 성공적으로 출판하였다.

 

 

성공적으로 출판을 할 수 있었던 이유가 무엇일까

1. 주제를 명확하게 정하지 않은 상황에서 짧은 시간에 한 개의 글을 발행하여 독자의 반응을 살펴보았다.
2. 방향성에 확신을 가진 뒤에는 작업에 더 신중해졌고, 결과물에 대한 자신감이 생겼다.
3. 글에 문제가 있는 경우 학습할 수 있었고, 쉽게 수정하여 반영하였다.
4. 즉각적인 대응 덕분에 추후에 발생할 문제를 미리 방지 할 수 있었고 독자의 신뢰를 잃지 않았다.
5. 한 개 단위로 글을 발행하면서 독자의 피드백을 반영하니 독자가 원하는 글이 써졌고 품질이 높아졌다.
6. 출판사와 저자 사이에 커뮤니케이션 오류는 최소화 되었고 의견 차이로 인한 실수는 방지가 되었다.

 

짧은 주기로 고객이 사용 할 수 있는 소프트웨어를 만들어가면서 커뮤니케이션 비용을 최소화하고 이슈 사항들을 바로 제거하면서 개발하는 방식이 애자일 소프트웨어 개발 방식이다.

 

폭포수 개발 방식으로 6개월만에 만들어내던 방식 대신에 애자일 방식을 활용하여 1주일에 글 하나씩 작성하여 매번 책에 들어갈 내용을 확인 할 수 있었다. 작업의 단위는 작아졌고, 처음에 생각했던 방향성에서 크게 틀어질 가능성을 최소화 하였다.

 

수정할 필요가 있으면 바로 수정하기 때문에, 비용도 크게 들지 않고 쉽게 수정 할 수가 있다. 이것이 바로 애자일스럽게 개발하는 방식이다.

 

 

 

애자일을 정말 이해하고 있는가

---

애자일 소프트웨어 개발방식을 퍼즐 맞추기 처럼 단순하게 조각 조각내서 개발하는 것으로 오해 할 수 있다.

 

이 그림은 5일동안 '모나리자를 그려달라는 요청' 으로 그림을 그리는 과정인데 이런식으로 그림을 그리기 시작한다면 폭포수 모델의 단점과 같이 그림이 완성되기 전까지 문제점을 발견하기 어렵다.

 

5일차 전까지는 미완성이며, 5일차가 되어야만 전체 그림을 볼 수 있어 근복적으로 잘못된 부분에 대해서 조기 수정할 수 없다.

 

현실적인 요청으로 다시 비유하자면 의뢰자는 '모나리자를 그려주세요' 가 아닌 '야외에 있는 여성 초상화를 그려주세요' 라는 식의 모호한 경우가 많다. (소프트웨어 개발에 있어 요구사항은 대부분 구체적이지 않고 모호한 경우가 많다.)

 

첫 번째 날에 그린 그림을 보면 부분을 그린것이 아닌 전체에 대한 스케치를 그렸다.

이것이 애자일 선언문에서 말하는 동작하는 소프트웨어이다.

• 완벽하진 않지만 짧은 시간안에 고객의 요구사항을 증명 할 수 있는 그림을 선보인 것이다.

 

고객은 이 그림을 보고 손의 위치와 배경 중 산의 비중을 줄여 달라는 피드백을 주었고 2일차에는 해당 요구사항을 반영하여 확인 받을 수 있다. 이로써 최대한 빠른 시일내에 고객과 개발자의 방향성을 잡아주었다. 그 뒤에도 점점 진하게 색을 칠해가면서 작품을 완성한다면 옷 혹은 머리색 등도 언제든지 변경 될 수 있을 것이다.

 

 

 

정리

---

지금까지 설명한 것이 애자일의 기초적인 개념이다. 이런 개념들을 잘 실천 할 수 있도록 만들어 높은 도구들이 스크럼, 칸반, XP, Lean SW Development 등 이 있다.

 

애자일은 일하는 방식이며, 문화이다. 책에 쓰여진 대로 적용하려고만 하면 대부분 실패한다. 조직에 맞게 커스터마이징 되어야 하며 함께 일하는 개발자들과 즐겁게 일하는 문화를 만들기 위한 도구로 생각하자.

 

이러한 문화가 잘 갖춰져야 제대로 만들어진 높은 품질의 소프트웨어 제품이 나올 수 있다.

 

 

 

Script  

---

애자일 소프트웨어 개발 방식

 

기존 전통적인 개발 방식(폭포수 모델) 에서는 최종 결과물이 나오기 전까지 고객이 이를 확인할 수 없어 니즈를 완벽하게 충족시킬수 없었고, 중간 결과물 또한 볼 수 없어 잦은 요구사항을 변경으로 인해 많은 소프트웨어 프로젝트들이 실패하였다.

이를 해결하고자 소프트웨어 세계의 거장들이 애자일 선언문을 만들어 유연하게 일하는 방식을 정의하였고, 짧은 주기로 고객이 사용 할 수 있는 소프트웨어를 만들면서 커뮤니케이션 비용을 최소화하고 이슈 사항들을 바로 제거하는 개발 방식이다.