에자일 방법론(Agile)

[ 폭포수 방법론 ]

과거 폭포수 모델(Waterfall Model)을 많이 사용했다고 한다. 폭포수 방법론은 다음 단계를 진행하기 전 현재 단계를 완료해야 다음 단계로 넘어갈 수 있는 방법론입니다. 폭포수 모델의 장점은 복잡성이 낮고 진행 과정을 세분화 하여 관리가 용이하며 과거부터 계속 사용해 오던 방법이기에 사례가 풍부하며 전체 과정에 대한 이해가 용이합니다.

하지만 소프트웨어가 커지면서 요구사항의 구체화가 어려워졌고, 초반에 예상치 못한 큰 오류의 발생 시에 전체 설계를 뒤엎어야 된다는 단점도 있습니다.

 

요즘 프로그램을 살펴보면 단순하게 A = B와 같은 방식으로 작동하지 않습니다. 프로그램 안에 수없이 많은 로직이 존재하며 처음 기획(계획)과 중간 구현 혹은 테스트 단계에서 치명적으로 작동할 수 있는 부분이 생길 수도 있습니다. 그렇기 때문에 폭포수 방법론도 과거와 현재는 다른 양상을 띄고 있는 부분도 있습니다.

첨부 1

첨부 1을 보면 알 수 있는 과거에는 개발을 진행한 후 테스트를 하며 디버깅을 하는 등 하나로 이어지는 폭포수의 모양을 했다고 봐도 무방합니다. 하지만 최근 폭포수 모델의 경우 간략하게 본다면 에자일과 거의 비슷한 양상을 띄고 있는 것을 확인할 수 있습니다.

 

개발을 모두 끝낸 후 테스팅을 하며 디버깅을 할 경우 큰 문제에 직면했을 때 해결 방안을 찾는데 오랜 시간이 걸릴 수 있습니다. 하지만 특정 프로세스 개발을 완료하고 테스트를 진행하면서 오류의 오차범위를 줄이고 계획에 맞게끔 수정을 하면서 갈 수 있다는 점이 장점입니다. 그렇다면 저렇게 현대화된 폭포수를 쓰면 되지 않냐라고 하실 수도 있는데 이에 대해 알아보기 전에 에자일에 대해 짚고 넘어가도록 하겠습니다.

 

[ 에자일 방법론 ]

에자일 방법론은 에자일의 가치에 대해 먼저 알아볼 필요가 있습니다.

• 개인과 개인 간의 상호작용이 프로세스 및 툴보다 우선
• 작동하는 소프트웨어가 포괄적인 문서보다 우선
• 고객과의 협업이 계약 협상보다 우선
• 변화에 대응하는 것이 계획을 따르는 것보다 우선

위의 4가지가 에자일을 통해 개발을 하면서 어디에 가치를 두어야 할지 잡아주는 지표와 같습니다.

에자일은 보다 효율적인 개발과 협업을 위해서도 사용을 하지만 소프트웨어를 잘 만들고 클라이언트의 요구를 맞추며 변화를 두려워하지 않고 대응하며 개인 간의 상호작용을 중요하게 여기고 있습니다.

 

에자일 프로세스라는 것이 워터풀과 같이 정해져 있는 프로세스를 지칭하는 것이 아닌 Agile (기민한, 좋은 것을 빠르고 낭비 없게 만드는 것) 말 그대로를 의미합니다. 하지만 어느 정도의 중요한 프로세스가 있습니다.

 

• 스프린트
  • 일반적으로 1~2주 정도의 단위로 기간을 잡으며 정해진 기간 동안 정해진 만큼의 프로젝트를 완료하는 것을 반복하여 프로젝트를 마무리하도록 하는 방법입니다.
  • 워터풀의 경우 프로젝트의 데드라인을 제일 중요시 여기지만 에자일에서는 에자일 속도. 즉, 스프린트가 얼마나 빠르게 잘 반복되고 있냐를 중요하게 여깁니다.
• 스크럼
  • 럭비의 스크럼에서 나온 단어로 잠시 럭비 룰을 보고 넘어가자면 경기중 반칙이 생기면 경기를 멈추고 반칙 장소에서 다시 경기를 재개합니다. 그때 공을 뺏기 위해 여러 명의 선수들이 뭉쳐있는 모습을 보고 협력하는 팀원의 모습과 비슷하다고 하여 단어를 스크럼으로 정했다고 합니다.
  • 스크럼의 경우 이미 충분한 경험이 있는 전문가 그룹의 경우 적절합니다. 각 스토리의 포인트를 예측하는데 이견이 많이 발생하지 않을 것이기 때문인데 그렇지 않고 기술개발을 한다면 칸반 보드의 사용이 더욱 효율적일 것입니다.

 

마지막으로 장점은

• 점진적으로 테스트할 수 있어서 버그를 더 빠르게 발견할 수 있다.
• 수정과 변경에 유연하다.
• 프로젝트를 시작할 때 계획에 버리는 시간을 줄일 수 있다.
• 서비스가 더 빨리 출시된다.

 

[ 폭포수 VS 에자일 ]

사실 회사에서 실무를 한다면 개발 이외에도 여러 변수가 생기기 마련입니다. 그런 변수들 때문에 에자일을 도입하는 것이 어려울 수도 있다고 생각합니다. 하지만 에자일의 4가지 가치를 생각하고 TDD와 같은 방법론을 조금씩 도입해가며 전체적인 프로세스를 에자일로 바꿔나가는 것이 좋은 소프트웨어를 더욱 빠른 시간에 정교하게 만들어 나갈 수 있다고 생각합니다.

 

단순하게 혼자 하는 개발에서는 어떤 방법을 써도 개인의 실력만 좋다면 좋은 결과물이 빠르게 나오겠지만 협업의 경우 항상 모든 팀원에 완벽할 수는 없기 때문에 여러 방법론이 나온다고 생각합니다. 결국 저희 개발자들은 좋은 소프트웨어를 빠른 시간에 정교하게 만들어내는 것이 중요하기 때문에 각각의 상황에 맞게 방법론을 선택하는 것이 좋지 않을까라고 생각합니다.