애자일은 신속한 반복 작업을 통해 실제 작동 가능한 소프트웨어를 개발하여 지속적으로 제공하기 위한 소프트웨어 개발 방식입니다.
그러나 "애자일 방법론"이라는 문구는 애자일이 독특한 소프트웨어 개발 방식임을 나타내기 때문에 오해의 여지가 있습니다. 애자일은 정확히 말하자면 소프트웨어 개발에 필요한 작업을 알려주는 일련의 규정이 아닙니다. 그보다는 협업과 워크플로우를 바라보는 하나의 관점이며 우리가 무엇을 어떻게 만들지에 관한 선택을 안내하는 가치 체계입니다.
구체적으로 말하자면, 애자일 소프트웨어 개발 방법론의 핵심은 작동하는 소프트웨어의 작은 구성 요소를 신속하게 제공하여 고객의 만족도를 개선하는 것입니다. 이러한 방법은 적응형 접근 방식과 팀워크를 활용한 지속적인 개발에 중점을 두고 있습니다. 일반적으로 애자일 소프트웨어 개발은 소프트웨어 개발자와 비즈니스 담당자가 자체적으로 조직한 소규모 팀으로 이루어지며, 이들은 소프트웨어 개발 라이프사이클 전체에 걸쳐 정기적으로 직접 만나 협업합니다. 애자일 개발은 소프트웨어 도큐멘테이션에 대한 경량화 방식을 선호하며 라이프사이클의 모든 단계에서 변화를 적극 수용합니다.
애자일의 가치
오늘날 우리가 알고 있는 애자일은 2001년부터 시작되었습니다. 소프트웨어 프로젝트를 일련의 선형적 순서로 구성하는 워터폴(Waterfall)방식의 프로젝트 관리에 대응하여 소프트웨어 개발자 그룹이 애자일 소프트웨어 개발에 대한 선언문(The Manifesto for Agile Software Development)을 작성했습니다. 이 문서에서 프로그래머는 소프트웨어 개발에 대한 새로운 접근 방식을 제안하고 다른 고려 사항보다 가치가 있다고 생각하는 4가지 주요 특성을 설명합니다. 간단히 요약하면 애자일 소프트웨어 개발팀은 다음과 같은 부분에 가치를 두어야 합니다.
- 개인과 개인 간의 상호작용이 프로세스 및 툴보다 우선
- 작동하는 소프트웨어가 포괄적인 문서보다 우선
- 고객과의 협업이 계약 협상보다 우선
- 변화에 대응하는 것이 계획을 따르는 것보다 우선
선언문을 작성한 이들은 위의 모든 항목에 본질적인 가치가 있다고 분명히 밝히고 있지만 왼쪽 항목을 오른쪽 항목보다 중시하면 제품 개발에 있어 더 좋은 결과로 이어질 수 있다고 제시하고 있습니다. 애자일 선언문은 일련의 프랙티스를 규정하지는 않으며 소프트웨어 개발에 대한 새로운 관점을 제시하는 길잡이에 가깝습니다.
애자일 선언문에서 비롯된 실제 성과는 많습니다. 예를 들면, 단계별로 순차적으로 소프트웨어를 개발하여 제품 품질을 확보하는 워터폴 방법과 달리 애자일 방법에서는 개발과 테스트를 동시에 연속적인 프로세스로 추진할 수 있습니다. 달리 말하면, 워터폴 개발은 한 단계 전체를 먼저 완료해야 다음 단계로 이동할 수 있다는 입장인 반면, 애자일 개발은 동시에 발생하는 여러 시퀀스를 지원합니다.
애자일의 기원
애자일 작업 방식은 Henry Ford의 1913년 생산 라인의 제조 방법에서 파생되어 나중에 소프트웨어 개발에 적용된 워터폴 방법의 한계를 해결하기 위해 고안되었습니다. 애자일 개발은 2001년에 기반을 다진 아래 다양한 방식이 있긴 하지만 소프트웨어 산업과 프로젝트 관리 부문에서 널리 활용되었습니다.
애자일은 많은 소프트웨어 개발자가 워터폴의 프로덕션 주기와 협업 방법이 원하는 결과를 내지 못한다는 점에 주목하기 시작했을 때 시작되었습니다. 이 문제는 조직의 비즈니스 요구 사항 검증에서 작동 가능한 애플리케이션 제공에 이르기까지 수년간 지체되는 일이 일반적이었던 1990년대 초까지 만연했습니다. 그동안 비즈니스 요구 사항과 시장 상황은 소프트웨어 프로젝트의 상당 부분이 구현되기도 전에 취소될 정도로 변하곤 했습니다. 이처럼 시간과 자원이 낭비되자 많은 소프트웨어 개발자가 대안을 모색하기 시작했습니다.
와해의 위협에 직면한 조직에서는 비즈니스의 빠른 속도를 따라잡기 위해 점차 디지털 트랜스 포메이션 전략을 도입합니다. 그리고 이때 애자일 소프트웨어 개발이 종종 중요한 역할을 합니다.
애자일은 오늘날 많은 디지털 워크플로우의 기반을 형성합니다. 유연하고 확장 가능한 IT 인프라를 갖춘 클라우드 컴퓨팅이 애자일 소프트웨어 개발의 수요 증가와 맞물려 성장하고 있습니다. 클라우드 네이티브 개발은 비즈니스 요구에 따라 확장할 수 있는 일련의 상호 연결 서비스로서 애자일과 비슷한 소프트웨어 개념을 수용합니다.
DevOps라는 개념은 소프트웨어 개발과 운영 사이의 오래된 벽을 무너뜨립니다. SRE는 소프트웨어 툴로 활용하여 시스템을 관리하고, 운영 태스크를 자동화하는 DevOps를 구현합니다. CI/CD 방법은 소프트웨어가 계속 변화하며 새 코드를 배포할 수 있는 속도를 가속하는 툴을 개발자에게 제공한다는 사실을 수용합니다.
이제 "애자일 방법론"이라는 개념 자체가 시간에 따라 변화하는 고객(즉, 소프트웨어 개발자) 요구사항에 대응하는 민첩한(agile) 아이디어라는 것을 눈치채셨을 겁니다. 이 점을 참고해 여러 가지 이름으로 불리며 구현마다 달라지는 경우가 많은 다양한 애자일 프레임워크를 간단히 살펴보겠습니다.
애자일 프레임워크
Scrum, kanban, XP(eXtreme Programming)와 같은 애자일 소프트웨어 개발 프레임워크는 DevOps 및 CI/CD(지속적 통합/지속적 배포)와 같은 대중적인 소프트웨어 개발 프로세스의 기반을 형성합니다.
Scrum이 아마도 오늘날 사용 중인 가장 대중적인 애자일 프레임워크이겠지만, 모든 애자일이 Scrum인 것은 아니며 모든 Scrum이 애자일인 것도 아닙니다. Scrum은 스프린트라는 일정 기간 내에 완료할 수 있는 작업으로 업무를 분할하는 5~9명의 소규모 복합 기능(cross-functional)팀을 위해 설계뙨 작업 관리 프레임워크입니다. Scrum 팀은 여러 명의 팀원과 제품 소유자인 Scrum 마스터로 구성됩니다. 일반적으로 Scrum은 대규모 프로젝트를 2~4주 스프린트로 분할할 수 있을 때 구현됩니다. Scrum은 "후향적 평가"라는 방식을 통한 피드백 루프에 집중합니다. "점검과 적응"을 Scrum의 비공식적 모토로 볼 수도 있을 것입니다.
Kanban을 비롯한 다른 애자일 프레임워크는 애자일 선언문보다 오래되었습니다. 그러나 이러한 프레임워크는 애자일 선언문에 간략히 설명된 가치를 증진하므로 애자일로 간주합니다. 애자일 프레임워크와 애자일 확장에 대한 접근 방식은 여기에 모두 나열할 수 없을 정도로 많습니다.
