애자일(Agile)이 도대체 뭘까?

서론

최근에 많은 회사 또는 조직에서 애자일 프로세스(Agile Process)를 채택해 사용하고 있다.

그리고 애자일 프로세스를 쓰는 조직이 많아짐에 따라 그냥 단순히 이슈마다 스토리 포인트를 매겨 얼마나 걸릴 지 산출하고, 1~2주 단위 스프린트를 계속 돌리고, 매일 아침 스크럼 회의를 하는 것과 같이 표면적인 것들에 집중하고 있다.

누군가가 애자일하게 ~ 해라 또는 애자일한 업무 ~ 와 같은 말을 하는 것을 들어본 사람들도 있을 것이다.

이 포스팅에서는 도대체 어떤게 애자일한 방법인가? 에 대한 얘기를 해보려한다.

애자일이란?

우선 애자일(Agile)이란 날렵한, 민첩한 이란 뜻으로 수 많은 방법론과 프로세스들 사이의 균형을 잡아보자는 의도로 나온 개발 방법론이다.

전통적인 개발 방법론의 문제점

전통적인 개발 방법론으로 대표적인 것은 폭포수(Waterfall) 모델이 있는데 이와 같은 전통적인 개발 방법론은 다음과 같은 큰 틀을 가지고 있다.

서비스 기획 -> 디자인 -> 개발 -> 테스트 -> 배포 -> 유지보수

이 방법은 우리에게도 매우 익숙한 방법이고 현재 많은 사람들이 자신도 모르게 여러번 겪은 프로세스이다.

마감 기한을 정해놓고 각자가 할 일을 끝마친 후에 다음 차례로 넘긴다.

예를 들어, 총 개발 기간이 6개월일 때 1개월은 서비스 기획, 1개월 디자인, 4개월은 개발 및 테스트, 배포 후 유저의 피드백을 받아 유지보수를 한다.

이러한 방식의 단점은 진행한 프로젝트의 결과가 좋지 않았을 때 대응을 하는 비용이 크다는 것과 클라이언트가 프로토타입을 보고 수정을 요청할 수 없다는 것이다.

마찬가지로, 실제 개발 프로젝트에서는 많은 변수들이 존재한다.

마감 기한에 맞춰 열심히 개발하고 배포를 했더니 사용자의 반응이 예상과는 다르게 매우 안좋을 수도 있다.

이러한 상황에서 전통적인 개발 방법론은 팀원들 모두에게 큰 리스크를 강요한다.

그리고 만약 다음과 상황이 벌어지면 어떻게 할 것인가?

서비스 기획과 디자인을 완료하고 개발 단계에 들어섰는데 예상치 못한 문제로 구현이 불가능한 경우

당연히 다시 기획자에게 찾아가 불가능한 이유를 설명하고 처음부터 서비스 기획과 디자인을 다시 해야한다.

하지만 전통적인 개발 방법론 에 따라 각 단계를 진행하고 있었을 경우, 구현 단계 전 충분한 연구와 분석 단계를 거치기 때문에 다시 기획자와 디자이너에게 찾아가 이러이러한 이유로 인해 불가능하다는 이야기를 꺼내게 되면 시간을 낭비하게 된 것은 물론이고 팀원들 간의 감정 싸움까지도 발생할 수 있다.

이제 위와 같은 상황을 예방하고자 만들어진 애자일의 모토부터 알아보자.

애자일 선언

우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다.
이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다.

• 공정과 도구보다 개인과 상호작용을
• 포괄적인 문서보다 작동하는 소프트웨어를
• 계약 협상보다 고객과의 협력을
• 계획을 따르기보다 변화에 대응하기를

가치 있게 여긴다.
이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.

애자일 소프트웨어 개발 선언 한국어 버전

위 선언에서 애자일이 어떤 목표를 지향하는 지 알 수 있다.

애자일 선언 이면의 원칙

애자일은 애자일 선언 외에도 12개의 원칙을 세워놓고 이 원칙을 따른다.

우리는 다음 원칙을 따른다:

1. 우리의 최우선 순위는, 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.

2. 비록 개발의 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.

3. 작동하는 소프트웨어를 자주 전달하라. 두어 주에서 두어 개월의 간격으로 하되 더 짧은 기간을 선호하라.

4. 비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야 한다.

5. 동기가 부여된 개인들 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라.

6. 개발팀으로, 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대면 대화이다.

7. 작동하는 소프트웨어가 진척의 주된 척도이다.

8. 애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 일정한 속도를 계속 유지할 수 있어야 한다.

9. 기술적 탁월성과 좋은 설계에 대한 지속적 관심이 기민함을 높인다.

10. 안 하는 일의 양을 최대화하는 기술이 필수적이다.

11. 최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 창발한다.

12. 팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.

애자일 선언 이면의 원칙 한국어 버전

예를 들어, 스프린트(Sprint)는 3번 원칙을 따르고 매 스프린트가 끝날 때마다 하는 회고(Retrospective) 12번 원칙에 따른다.

서론에서 말한 것처럼 애자일하게 라는 개념은 위의 애자일 선언과 애자일 선언 이면의 원칙을 따르는 것이라고 할 수 있다.

스크럼(Scrum)

스크럼(Scrum)은 애자일 방법론에서 가장 많이 사용된 대표적인 개발 프로세스이다.

원래는 럭비 경기에서 반칙으로 경기가 중단되었을 때 쓰는 대형을 의미하는 용어라고 한다.

즉, SW 측면에서 팀이란 단어가 주는 의미를 상기시키고 효율적인 성과를 얻기 위한 방식을 의미한다.

백로그(Backlog)

프로젝트가 시작될 때 전체를 알지는 못하지만 할 일(백로그)을 정하고 여기에 우선 순위를 부여한다.

요구사항 리스트, 제품의 개발 대상 목록으로 이해하면 된다.

애자일에서의 요구 상항은 User Story 라고 한다.

스프린트(Sprint)

스프린트(Sprint)는 단거리 전력 질주라는 의미처럼, 스프린트의 단계마다 작은 단위의 업무를 단기간 내에 마치 단거리 전력 질주하는 것처럼 개발한다.

태스크를 너무 크게 잡지 않으며(보통 2~4주) 프로젝트를 진행한다.

스프린트를 반복하여 출시주기를 단축하며 팀과 사용자가 지속적으로 소통하고 의견을 반영하여 시스템을 향상시킨다.

스크럼 회의(Scrum Meeting)

모든 팀원이 참석하여 매일 15분간 하는 스크럼 회의(Scrum Meeting)에서 팀 구성원은 서로의 진도를 확인하고 상호 이해를 증진한다.

한 사람씩 어제 한 업무, 오늘 할 업무, 문제점 및 어려운 점을 공유하며 완료된 세부 작업 항목을 스프린트 현황판에서 업데이트한다.

스프린트 회고(Sprint Retrospective)

각 스프린트에서 수행한 활동과 개발한 것을 되돌아보며 개선점과 규칙 및 표준을 잘 준수했는지 검토한다.

스프린트 회고(Sprint Retrospective)를 통해 팀의 능력과 시스템을 향상시킬 수 있고, 팀의 단점보다는 강점과 장점을 찾아 더 극대화하는데 초점을 둔다.

스크럼의 장단점

장점

• 다른 프로세스 모델보다 소프트웨어를 빠르게 배포할 수 있어 고객이 그 가치를 얻을 수 있음

• 최종 결과만 아니라 요구 처리 시간이 적어 즉각적인 피드백을 받을 수 있음

• 변화에 더 잘 적응하고 빠르게 대응할 수 있는 장점이 있음

• 항상 최신 작업을 수행하기 때문에 자원의 낭비가 적음

• 문제와 결함을 더 빨리 감지하고 수정할 수 있음

• 계층적인 관료주의와 불필요한 문서화 등에 시간을 덜 씀

• 비용이 저렴하므로 아이디어를 실험하고 테스트 할 수 있음

단점

• 문서화가 등한시되어 새로 들어온 개발자의 속도를 높이기가 어려워질 수 있음

• 애자일 모델은 개발자와 고객이 지속적으로 상호 작용해야하므로 모든 사람에게 더 많은 시간과 에너지를 요구

• 명확한 끝이 정의되지 않으면 프로젝트가 종료되지 않고 계속될 수 있음

• UX 및 아키텍처 관점에서 전체적인 디자인이 부족하여 제품을 완성시키기 위한 작업이 더 많이 드는 문제가 발생할 수도 있음

• 제품에 대한 장기적인 비전이 필요하며 적극적으로 의사소통하기 위한 노력이 필요

• 제품에 응집력이 없으며 디자인이 조각화되어 사용하는 방법도 조각화

• 시간이 지날수록 소프트웨어의 연결이 끊어질 수 있음