애자일(Agile) 개발 방법론
회사에서 일하실 때 어떻게(어떤 개발 방법론으로) 개발 하시나요?
이 질문에 대한 나의 답은 항상 '애자일로 하고 있습니다! (당당)' 라고 말했다.
왜냐면 우리팀은 개발할 때 스크럼 방식을 사용하고 있기 때문이다. (스프린트 단위로 개발하니까)
근데 내가 (또는 우리가) 하고 있는 방식은 애자일이 아니었다.
왜 아닌 지 알아보자.
애자일 개발 방법론으로 성공한 대표적인 소프트웨어
'카카오'
- 2011년에 4명(개발자 2명, 기획, 디자이너)이 2개월 동안 개발한 프로토타입으로 시작
- 신속한 시장 진입
- 완벽하지 않은 계획과 기능
- 고객과 소통하면서 개발
- 소수 인원
- 프로젝트 초기에 과도한 기획이나 분석을 지양하고 빠르게 시제품 개발
- 고객의 반응을 확인하면서 점진적으로 제품 개발
애자일 개발 방법론이란?
소프트웨어 개발 프로세스에서 유연성과 적응성을 강조하는 프로젝트 관리 방법론
엄격한 선형적인 방법이 아니라, 애자일 방법론은 자기 조직화된 팀과 다기능적인 팀원들의 공동 노력을 통해 요구사항과 솔루션을 반복적이고 점진적으로 개발하는 과정을 통해 진행
애자일 방법론은 짧은 시간 내에 작동하는 소프트웨어를 전달하고 빠르게 변경에 대응하여 고객 만족도를 우선시
이는 고객과의 자주 있는 커뮤니케이션과 피드백 루프, 그리고 팀 내에서의 정기적인 회고를 통해 달성
애자일 개발 방법론의 핵심 원칙은 프로세스와 도구보다는 개인과 상호작용을 중시하고, 포괄적인 문서보다는 작동하는 소프트웨어를 우선시하는 것
여기서 우리가 생각해 볼 것
- 우리는 짧은 주기로 작동하는 소프트웨어를 고객에게 전달(배포)하나?
- '고객'에게 직접적으로 그리고 주기적으로 피드백을 받아서 개선하고 개발하여 배포하나?
애자일 개발 방법론의 종류
스크럼 (Scrum)
팀 기반의 애자일 방법론으로, 스프린트를 이용하여 반복적인 개발 사이클을 진행합니다. 스크럼 마스터, 제품 책임자, 개발 팀 등의 역할로 구성되어 있습니다.
익스트림 프로그래밍 (Extreme Programming, XP)
빠르게 변화하는 요구사항에 대응하기 위해 테스트 주도 개발, 지속적인 통합, 짝 프로그래밍 등의 기법을 사용합니다.
칸반 (Kanban)
시각화된 작업 보드를 통해 작업 진행 상황을 관리합니다. 유연한 개발 방식을 적용하여 고객 요구사항에 대응합니다.
전통적 개발 방법과 애자일 개발 방법의 차이
전통적 개발
제품 기획 -> 요구분석 -> 설계 -> 구축 -> 테스트 -> 배포
애자일 개발
제품 기획 -> '최소' 제품 출시 (고객 피드백) -> 추가 개발 후 출시 -> 다시 피드백 -> 다시 개발 -> 반복
*스프린트를 진행하면서 고객 리뷰 및 요구사항을 반영한다.
*요구사항의 불확실성을 인정한다.
전통적 프로젝트 관리의 한계
분석 + 고객 리뷰 -> 설계 -> 구현 -> 테스트 + 고객리뷰 (이때, 요구사항 변경이 발생) -> 비용/일정 부족 -> 갈등
요구변경의 원인
- 요구사항의 불명확성 (사용자도 뭘 원하는 지 모름)
- 사용자와 기획/개발자의 상호 이해 부족
- 사용자의 참여 부족
그럼 애자일 개발 방법이 최고네?
아시겠지만 그런건 없습니다.
장점
빠르게 변화하는 고객 요구사항에 유연하게 대응할 수 있습니다.
작은 주기로 개발을 진행하므로 개발 일정과 예산을 효율적으로 관리할 수 있습니다.
팀원들 간 소통과 협업을 강화하여 개발 효율을 높일 수 있습니다.
피드백을 적극적으로 수용하여 지속적인 개선을 추구할 수 있습니다.
단점
빠른 속도로 개발을 진행하는 만큼, 기술 부채(Technical debt)가 쌓일 수 있습니다.
프로세스와 문서화가 부족할 경우, 개발의 방향성이 불명확해질 수 있습니다.
팀 내에서의 결정권이 높아질 수 있으므로, 조직 문화와 팀원 간의 충돌 등이 발생할 수 있습니다.
Technical debt가 뭐지?
간단하게 말해서 '지금은 안해도 되니까 나중에 해야지 ~ (내가 안함)' 입니다.
Technical debt는 소프트웨어 개발에서 발생하는 개발 비용에 대한 메타포로, 비유적으로 현재 소프트웨어 개발 프로젝트에서 당장은 고려하지 않고 향후에 상환할 필요가 있는 개발 비용을 의미합니다. 즉, 개발자가 코드를 작성할 때 일부 코너를 단축하거나, 나중에 처리해야 하는 문제를 미루는 등의 일을 하게 되면 발생합니다. 이러한 일은 빠른 개발을 위해서나 급한 프로젝트 일정을 충족시키기 위해 발생하는 경우가 많습니다.
또한, 시스템 아키텍처나 프레임워크와 같은 기초 인프라를 충분히 고민하지 않고 개발하는 경우에도 발생합니다. 이러한 개발 방식은 빠른 개발을 가능하게 하지만, 나중에 유지보수 및 업그레이드를 할 때 문제가 발생할 수 있습니다. 이러한 비용은 결국 소프트웨어 개발자들이 나중에 상환해야 하므로 '기술 부채(Technical debt)'라고 불립니다.
기술 부채는 초반에는 개발 효율성과 생산성을 높여주지만, 나중에 유지보수와 수정에 많은 비용이 들게 됩니다. 따라서, 개발자는 기술 부채를 최소화하고 나중에 비용이 많이 들지 않도록 시스템 아키텍처 및 디자인을 깊이 생각하며 코드를 작성하는 것이 좋습니다.
우리는 애자일 개발 방법론으로 개발하고 있나?
아니.
우리는 개발 주기만 스크럼(스프린트)으로 가져갈 뿐.
아직까지 전통적인 개발 방법론으로 개발하고 있다.
우리가 완벽한 애자일 개발을 안하는 건 알겠다. 그래서?
우리가 완벽한 애자일 개발 방법으로 개발하려면 아래와 같은 작업이 이루어 져야한다.
- 고객, 기획자, 개발자, 테스터가 모두 애자일 개발 방법론을 이해하고 실행해야 한다.
- 고객은 짧은 주기로 제품이 업데이트 되며 피드백이 적극 반영된다는 것을 이해해야 한다.
- 기획자는 수 개월 치 기능을 한번에 고민하는 것이 아니라 큰 방향만 잡고 고객의 피드백을 중심으로 기획해야 한다.
- 개발자는 확장성을 고려하면서 요구사항을 빠르게 개발해야 한다.
- 테스터는 짧은 주기로 개발되는 기능을 테스트 해야한다.
- 특정 기간에만 테스트를 몰아서 한번에 할 수 없다.
- 개발 주기와 같은 주기로 테스트를 진행해야 한다.
될까?
글쎄..
개발자는 이미 애자일 개발 방식을 적용했다.
하지만, 기획자와 테스터는 여전히 전통적인 개발 방식의 주기를 가져가고 있다.
기획자와 테스터는 우리팀의 우리 서비스만 기획하거나 테스트 하는 게 아니다.
기획자와 테스터가 우리 팀이 개발하는 서비스만 '애자일 하게' 관리해 줄 수 있을까?
결론
- 우리는 애자일 개발 방법론이 뭔지 알았다.
- 그리고 우리가 완벽한 애자일 개발 방법론을 따르지 않는 다는 것도 알았다.
- 완벽한 애자일 개발 방법론을 적용하려면 어떻게 해야 하는 지도 알았다.
앞으로도 계속 완벽한 애자일 방법론으로 개발하지 못하더라도 현재 상황을 정확하게 이해하고 있다는 것에 의미를 두자!