본문 바로가기
Development/Common

애자일(Agile) 방법론 - 오늘의 애자일

by du.it.ddu 2023. 11. 4.
반응형

이 포스팅은 "애자일 조직은 이렇게 일합니다" 도서를 읽고 작성한 글입니다.

 

여러 스타트업부터 네카라쿠배 중 어느 대기업까지, 개발자로 일한지도 6년이 다 되어갑니다.

대부분의 회사에서 애자일 방법론을 기반으로 한 개발 프로세스를 가져가고 있었는데, 생각해보니 애자일 방법론에 대해 공부한 적은 딱히 없는 것 같습니다.

그저 "짧은 주기로 개발을 반복하는 것" 정도로 이해했던게 아닐까 합니다.

 

그럼 그저 2주 정도의 단위로 개발하고 배포하고 버그를 수정하는 것을 반복한다면 우리는 애자일 방법론을 잘 지키고 있는걸까요?

잘 하고 있을수도 있겠지만, 뭔지도 모른채 잘 하고 있다면 썩 좋은 것만은 아닐겁니다.

또한 스타트업이든 대기업이든 애자일 방법론을 잘 수행하고 있다고는 장담할 수 없습니다.

 

돌이켜봤을 때 가장 최악의 애자일 경험은, 그저 짧은 주기로 프로세스를 가져간다는 명목하에 도저히 짧은 주기로는 어려운 기획을 가져오고 개발자를 갈아넣는 그런 경험이 있습니다.

저는 앱 개발이다보니 기획과 디자인, 백엔드 개발까지 되고 나서야 마지막이어서 더더욱 그랬던 것 같습니다.

 

아무튼, 이 애자일 방법론에 대해 좀 더 정확히 알아보고자 합니다. :)

 

폭포수(Waterfall) 방법론

애자일 방법론을 알아보기 전에 반대 개념인 폭포수 방법론을 떠올려봅시다.

 

폭포수 방법론은 소프트웨어 개발의 모든 진행이 순차적으로 진행되는 것을 말합니다.

즉, 기획하고 디자인하고 개발하고 배포하는 것이 모두 순차적으로 완료되고 다시 돌아가지 않습니다.

 

따라서 모든 단계가 100% 이루어져야 하는데, 실제로 이렇게 하기는 불가능에 가깝겠죠.

이것을 반대로 생각하면 애자일 방법론을 이해하기 쉽습니다.

 

애자일(Agile) 방법론

애자일(Agile)은 날렵한, 기민한, 민첩한 이라는 뜻을 가지고 있습니다.

이름만 봐도 무언가를 빠르게 하는 방법에 대한 이론이라는 것을 짐작할 수 있습니다.

 

애자일 방법론을 접하다보면, 필연적으로 애자일 선언을 확인하게 됩니다.

자세한 내용을 여기다 풀지는 않겠습니다만, 한번쯤 확인해보면 좋겠습니다.

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

 

애자일 소프트웨어 개발 선언

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

agilemanifesto.org

선언과 함께 애자일 소프트웨어의 12가지 원칙도 있습니다.

대략 요약해보면, 소프트웨어를 짧은 주기로 민첩하고 신속하게 전달하고 이를 위해 기술적으로, 팀적으로 노력해야 한다고 볼 수 있습니다.

아마 내용이 이렇다보니 애자일 방법론을 잘 적용하지 못하는 회사는 그저 "빠르게 개발"에만 초점을 맞추는게 아닌가 합니다.

 

애자일 방법론은 기획과 디자인, 개발, 테스트 배포와 같은 단계들을 굉장히 짧은 주기로 반복됩니다.

개발로 치면 무한루프 같은 느낌이 되겠죠.

출처 : https://pptxtemplates.com/download/agile-methodology/

이 이미지를 보시면 충분히 이해가 될 것이라 생각합니다.

 

애자일(Agile) 개발의 특징

애자일 개발은 어떤 특징이 있을지 알아보겠습니다.

  • 짧은 배포 주기
  • 적시에 세우는 계획, 적시에 세우는 요구사항
  • 적시 설계
  • 지속적이고 자동화된 테스트와 통합
  • 빈번한 체계적인 협업
  • 경험적, 반응적, 개선 지향적인 접근 방식

아마 이렇게 특징만 나열하면 와닿지는 못할겁니다.

실제 애자일 방법론을 사용하는 팀과 함께하면 피부로 느끼게 됩니다.

 

짧은 배포 주기를 위해 무엇을 해야할까요?

적절한 시기에 계획이 세워져야 하고 요구사항이 세워져야 합니다. 그래야 빠르게 개발을 할 수 있으니까요.

그럼 개발자들은 설계를 하고 개발을 합니다.

그리고 개발이 완료되면 자동화된 시스템을 통해 주기적으로 배포가 되고 테스트 코드를 수행하거나 QA를 수행합니다.

이런 과정에서 다양한 직군과 협업을 해야하고, 이 과정은 반드시 체계가 필요합니다. 신속하게 해야하는데 중구 난방이면 답이 없겠죠.

그리고 이런 과정을 통해 경험이 쌓이고 어떤 점을 개선해야 할지 반드시 고민하게 됩니다.

 

애자일(Agile) 개발이 무조건 좋은가?

애자일 개발은 좋은 개발 방법입니다. 하지만 어떤것이든 간에 "항상 옳다" 라는 생각에 빠지면 안된다고 생각합니다.

회사 또는 팀에 맞는 방법을 선택하는게 가장 좋은 선택이라고 봅니다.

애자일 개발을 놓고 순차개발과 비교하면서 "아, 애자일은 신속하고 빠르게 개발하고 배포할 수 있으니까 무조건 좋네!" 라고 하는건 잘못된 생각이겠죠.

 

우수한 구성원들과 우수한 관리, 우수한 품질 등을 갖춘다면 좋은 프로젝트가 되고, 이것은 방법론과 무관한 얘기입니다.

하지만 애자일 방법론이 더 좋은 선택이 될 수 있습니다.

 

빠른 개발과 배포를 통해 버그를 더 빠르게 수정한다거나, 어떤 기능을 더 빨리 제공할 수 있게 된다거나, 사용자의 반응을 더 빠르게 파악하고 의사결정을 할 수 있다거나 등등 다양한 이점이 있죠.

이것들은 배포하기까지 오래 걸리는 순차개발에서는 어려운 부분입니다.

 

이번 포스팅에서는 애자일 방법론에 대한 이론적인 부분, 그리고 개인적으로 회사생활을 하면서 들었던 생각, 느낌을 작성 해 보았습니다.

여러분의 애자일은 어떠신가요? :)

 

 

반응형