서론
요즘 거의 모든 조직이 소프트웨어를 개발할떄, 방법론인 애자일 방법론을 주로 쓴다. 요즘 MZ세대들이 너도나도 인스타그램을 하면서 허세주의에 빠진 것처럼, 작은 IT기업이든 큰 IT기업이든, 주니어 개발자든, 시니어 개발자든, 프로젝트의 업무량이 많든 적든, 무턱대고 사전준비 없이 일단 요즘 트렌드라고 하니까 그냥 사용하려고 하는데, 정작 그들이 적용한게 애자일의 정석이 맞는지에 대해서는 의문이 든다.
인스타가 서로의 일상을 공유하며 다양한 사람들의 친목을, 멀리 떨어진 친구들과도 서로 소통과 공감을 추구하는 것이었지만, 요즘 세대들에게는 단순히 자랑과 허세를 부리는 용도로 변질된 양상이 강한 것처럼 애자일이 추구하는 이상은 간단명료하면서도 강력하지만, 정작 이 방법론을 제대로 적용하여 실행하는 조직을 찾아보기 힘들게 사실이다.
내가 전달하고 싶은 메시지
애자일 개발의 역사, 전통적인 폭포수 방법론의 차이점을 간략히 알아보자. 그리고 요즘 이 방법론이 트렌드, 대세가 된 이유에 대해서도 이해해보자.
애자일 이전: 폭포수 방법론
이전 세대들의 개발자들은 폭포수방법론에 대해서 모를수가 없을 것이다. 그만큼 유일하고 꾸준히 적용되어 왔던 부동의 1위, 방법론이었기 때문이다. 이 방법론을 사용하려면 코딩에 들어가기 전에 상당한 문서 작업이 필요했다.
기업에 상주해 있는 business analyst라 불리는 사람들이 필요한 기능들을 문서로 작성후, 프로세스가 작성되기 시작했다. 이 문서는 길고 세부적이고, ux/ui 디자인부터 비즈니스 로직까지 모든 요소를 포함했다. 엔지니어들을 이 문서를 보고 중간중간 막히는 일들이 생기더라도 산을 하나하나 넘어가면서 기능 설계를 해나갔다. 이후 마지막에 통합과 배포가 이루어졌다.
요즘과 같이 지속적 통합(CI)과 지속적배포(CD)가 일상인 오늘날과는 대조되는 양상이라 볼 수 있다.
실무에서의 폭포수 방법론
Analyst들이 구현한 문서를 '사양', '스펙'이라고도 흔히 부른다. 개발자들은 이 스펙을 제대로 분석해서 적용하지 못하면, 질책을 받기 때문에, 200페이지짜리 스펙이라도 허투로 봐서는 안되었다. (이 당시 개발자들의 삶의 애환과 고통이 간접적으로 느껴진다)
참고로 나 또한 이전에 SI부대에서 개발할때, 이렇게 요구사항에 적힌 내용과 추후에 회의를 통해 수정되고 추가된 기능을 기억했다가 작업할때 하나하나 구현했어야 했는데, 마지막에 배포하기 이틀전에 기능 하나를 빼먹은 것이었다. 그때 간부님이 '여기에 이 기능이 왜 없냐?'라고 물었을때, '어 그러게요? 왜 없죠? 아! 제가 안넣은것 같습니다'라고 말했다가 멱삭을 잡혔던 기억이 있다.(그래도 지금 전역하고 나서는 친한 형,동생 사이로 지내고 있다)
아무튼 이렇게 스펙을 분석하는게 힘들었을 뿐만 아니라, tool 역시 다양하지 못했고, 지금에 비하면 활용하는데 한계가 분명히 있었으며, 다루기가 힘들어 별도의 사전교육이 필요하기도 헀다. 이 당시는 오픈소스라는게 당연시 되지도 않았기에 지금이면 비전공자들도 어렵지 않게? 할 수 있는 DB연결, MultiThread로 데이터 처리하기 등의 모든 저수준 동작을 직접 개발해야 했다.(지금은 이런걸 수동으로 하는 경우도 거의 없고, 왠만하면 깃허브에서 해당 기능을 복사·붙여넣기하는 경우가 비일비재하기 때문에 개발의 진입장벽이 많이 낮아진건 사실이다)
이런 상황에서 개발자들이 고생고생해서 Main Artifact와 Dependent Artifact를 개발하고 MVP(최소기능제품)까지 만들었다고 해도, 예상한대로 작동하지 않는 것도 종종 있었고, 유지·보수를 거쳐 정식 서비스 이후 사용자들이 아예 사용하지 않는 기능들도 생겨나기 시작했다. 이후 몇개월간 사용되다가 기능 추가 및 삭제가 요청되어 리엔지니어링이 요청되는 상황이 발생하는 것은 흔한 일이었다. 이처럼 Waterfall 방법론에서는 일단 이론적으로 개발을 하지만, 결국 마지막에 판도라의 상자가 열리고 예상치 못한 에러가 터져나오고 사용자들에게서 예상치못한 반응이 나오기 때문에 SI공급사에서는 매우 고통스러웠을 것으로 짐작한다.
관련 영상 : 애자일 방법론의 원리
이런 개발자들에게 있어 한줄기의 빛이 되어 탄생한 것이 애자일 방법론이라고 볼 수 있다.(아래 영상참고)
https://www.youtube.com/watch?v=1iccpf2eN1Q&t=2s
물이 아래로 떨어지는 것이 절대적인 것처럼 한번 아래 단계로 넘어가면 다시는 위로 거슬러 올라갈 수 없다는 뉘앙스를 갖고 있는 것이 폭포수 방법론이라면, 애자일은 이와 반대로 일정주기로 꾸준히 프로토타입을 만들어선보이며 고개의 요구사항을 매번 반영하면서 수정해나가는 방식이다.
ex)고객 요구사항 확인 -> 프로토타입 배포 -> 고개개의 수정 요청사항 확인 -> 수정사항 반영 후 배포 -> 고객의 수정 요청사항확인 -> 수정사항 반영 후 배포 -> ...
애자일을 적용할 때 크게 두가지 템플릿 중 하나를 선택하게 되는데, 바로 <칸반>과<스크럼>이다.
1)칸반
위 그림에서 알 수 있듯이, <칸반>은 to-do-list에 쌓인 일들을 하나씩 해결해나가면서 포스트잇을 오른쪽으로 옮겨나가는 방식인데, 이것의 핵심은 칼럼위에 써있는 숫자(3-2-4-2-5)이다.
작업량을 위 수에 맞게 제한하여 흐름을 통제, 세게 말하면 강제로 제어하면서 팀원들이 급하게 일을 해치우는 게 아니라, 하나하나의 일에 몰입할 수 있도록 유도한다.이 템플릿을 써서 다른 팀원들이 현재 어떤 작업중인지 내가 뒤쳐져 있는지, 앞서가 있는지, 따라서 다른 팀원들을 어시스트해야 하는지 어시스트 받아야 하는지도 알 수 있을 것이라 생각한다.
2)스크럼
<스크럽>방식의 흐름은 다음과 같다.
- 제품 책임자가 백로그를 통해 고객 요구사항을 뽑아내서 만들어야 할 제품을 정한다.
- 스프린트 기간을 정하고 매일 스프린트 회의를 통해 상황을 공유하며 스프린트 기간 동안 제품 개발에 몰두한다.
- 스프린트 기간이 끝나면 제품리뷰를 통해 피드백을 받고 제품 개선사항을 파악하고, 회의를 통해 개발 프로세스 등의 팀의 단점을 보완한다.
- 다름 스프린트 때 처리할 Back_log를 제품 책임자와 필요 인원들이 결정&계획 시간을 갖는다.
애자일 개발이 더 나은 소프트웨어로 이어지는 이유
애자일은 반복적이고 협력적인 접근 방식을 통해 소프트웨어 개발을 진행하며 더 나은 이유로 소프트웨어 개발을 이끌어내는데 기여한다.
마지막으로 '애자일 소프트웨어 개발 선언'문에 대해서 한번씩 읽어보기를 바라며 이 포스팅을 마치겠습니다. <애자일 소프트웨어 개발 선언>
출처: https://www.itworld.co.kr/news/232234
참고:
https://www.youtube.com/watch?v=pdZNjNTyr8Q
https://www.youtube.com/watch?v=3y5rCRys4t0
https://medium.com/@rlatla626/waterfall%EA%B3%BC-agile-7dc603dbd3e8
https://brunch.co.kr/@eunmee910/46
https://brunch.co.kr/@insuk/5
Ghost