오늘은 소프트웨어 개발방법론 중 하나인 애자일에 대해서 알아보겠다. 먼저 개발 프로세스에 대해 알아야 한다. 소프트웨어를 개발함에 있어서도 전형적인 단계가 있지 않겠는가. 일반적으로
- Requirements - 요구 분석
- Design - 설계 (이전에 분석 단계가 있을 수 있다)
- Development - 구현
- Testing - 테스트
- Deployment - 배포
- Maintenance - 유지 관리
순으로 진행된다고 한다. 위 싸이클이 한 번의 개발 프로세스이다. 자, 이제 대표적인 개발 방법론인 워터폴과 애자일을 보자. 어떤 앱의 개발 기간이 6개월이라고 가정해보자.
waterfall 방식
워터폴, 폭포수 방식은 6개월 동안 1번의 개발 프로세스만 발생했다.
단순히 말하면 한 번의 배포를 위해 수개월동안 철저히 개발하는 방식이다.
계획에 의존한다
Agile 방식
애자일 방식은 6개월 동안 N번의 개발 프로세스가 발생했다.
단순히 말하면 자주 앱을 배포하면서 앱을 보완시켜나가는 방식이다.
계획에 의존하지 않고, 변화에 대응한다.
왜 트렌드는 애자일인가
애자일 소프트웨어 개발 선언
해당 링크는 Kent Beck을 비롯한 12인의 '애자일 소프트웨어 개발 선언'이다. 애자일의 궁극적 탄생 이유가 적혀있다. 또한 방식에 대한 원칙도 존재한다.
애자일의 12가지 원칙
해당 원칙들을 읽어보면 애자일 개발 방식에 대한 설명이 따로 필요없다.
- 가치 있는 소프트웨어를 조기에 지속적으로 제공함으로써 고객을 만족시키는 것을 최고 우선순위로 한다.
- 개발 작업 후반부일지라도 요구사항 변경을 기꺼이 수용한다. 애자일 프로세스는 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.
- 2주에서 2개월 주기로 작동하는 소프트웨어를 자주 제공하되, 더 짧은 시간 단위를 선호한다.
- 프로젝트 전반에 걸쳐 비즈니스 담당자들과 개발자들이 매일 함께 작업해야 한다.
- 동기가 부여된 개인들을 중심으로 프로젝트를 구성한다. 구성원들이 필요로 하는 환경과 지원을 제공하고, 담당 업무를 완수할 것임을 신뢰한다.
- 개발팀에 그리고 팀 내부에서 가장 효과적, 효율적으로 정보를 전달하는 방법은 대면 대화이다.
- 작동하는 소프트웨어가 진처의 주된 척도이다.
- 애자일 프로세스는 지속 가능한 개발을 장려한다. 스폰서와 개발자, 사용자들이 일정한 속도를 계속 유지할 수 있어야 한다.
- 기술적 탁월성과 좋은 설계에 대한 지속적인 관심으로 기민함을 향상시킨다.
- 단순성 - 아직 하지 않은 작업량을 최대한 세분화하는 기술 - 은 필수적이다.
- 최고의 아키텍처, 요구사항 및 설계는 자율구성팀에서 비롯된다.
- 팀은 정기적으로 더 효과적인 방법을 찾아서 반영한 다음, 그에 따라 업무 활동을 조율하고 조정한다.
- Agile : 민첩함, 기민함
전체 요구사항을 작은 단위로 쪼개서 개발 프로세스를 반복하는 것이 핵심이다.- 소수의 요구사항을 분석, 설계, 구현, 배포(개발 프로세스)하여 고객에게 피드백을 받고 그 다음 요구사항에 대해 진행한다.
- 한 번의 개발 프로세스 단위를 스크럼에서는 스프린트라고 하는데, 2~3주를 한 스프린트 단위로 가져가는 경우가 많다.
- 고객과 소통하며 빠른 피드백을 받고 빠르게 수용하는 것이 중요하다.
- 이러한 요구사항 충족들이 앞선 반복 단계에서 반영되어왔기 때문에 고객의 만족도가 높은 최종 결과물이 나올 것이라는게 애자일 방식이다. 이러한 이유로 애자일이 트랜드이다.
- 애자일도 못 말리는 것
- 실제 개발 부서가 아닌 다른 부서의 스케줄 때문에 빠른 요구사항 충족이나 배포 단계에서 막히는 경우도 있다.
- 따라서 개발 부서 차원에서 개발부터 배포까지 모두 가능하게, 또한 애자일 개념을 잘 녹여낸, 개발방법론인 DevOps가 등장한다.
DevOps
Development + Operations
개발과 운영이 하나로 묶여진 개발방법론이다. 소프트웨어를 자주 제공하자는 주된 목표는 애자일과 동일하다. 개발, 운영, 검증에 대한 세 가지 분야를 공유한다는 개념이다. 위의 개발, 운영, 검증의 세 가지 부서들이 한 팀이 된다기보단 유기적으로 공유하고 동작하는 것이 목표이다. 이 개발방법론을 프로젝트에 잘 적용하려면 소프트웨어 빌드, 테스트, 검증, 배포에 대한 과정들에 대해 대부분 자동화가 이루어져야 한다.
CI/CD
자동화가 잘 되어 있고, 단계마다 이력(히스토리)들이 잘 남아 있으면 해당 시스템을 믿고 배포 자동화까지 실현할 수 있다. 데브옵스 방식이 잘 구현된 회사에선 개발자가 개발해서 스스로 배포까지 가능하게 된다. 또, 이러한 과정들은 지속적인 배포와 빠른 고객 니즈 충족을 가능케 한다.
그럼 애자일이나 데브옵스 방식을 채택하면 되는가
'애자일은 단순히 자주 제품을 제공하면 된다'는 착각에 빠진 경우를 생각해보자. 문서도 없어도 되고, 그냥 배포하고 잘못됐다면 고쳐서 다시 제공하고, 이러한 애자일 방식으로 제공하는 회사가 있다면. 이 같은 경우는 애자일을 완전히 잘못 이해한, 오히려 독이 된 사례일 것이다. 애자일, 데브옵스의 궁극적 목표가 단순히 자주 배포라는 개념이 아닐 뿐더러, 프로젝트에 해당 방법론들의 목적을 분명하게 적용하기 위해선 많은 노력과 비용이 든다는 것을 알고 있어야 할 것이다.
또한, 개발방법론 채택에 대하여 어떤 개발방법론이 제일 좋다라고 말할 수 없다. 회사마다, 팀마다, 프로젝트마다, 해당 상황에 각 개발방법론들을 비교 후 채택하면 된다. 추후 우리 프로젝트에 가장 적절한 개발방법론을 찾을 수 있도록 다양한 개발방법론들에 대해 알아놓는다면 그걸로 OK다!
