Agile Devops & Culture

[Agile] 전통적 프로젝트 수행방식의 한계

기존 전통적 프로젝트 수행방식의 한계점에 대해서 살펴보자.

“필자가 쓰는 글들은 책이나 교육, 기타 여러 매체를 통해서 접하고 공부한 내용들을 정리하여 누군가에게 정보를 전달하기 위한 목적도 있지만, 필자가 애자일(agile)을 공부하면서 느꼈던 점이나 이렇게 적용했었으면 어땠을까하는 점 혹은 프로젝트는 아니지만 SM업무에 이런식으로 적용해보고 있다와 같은 ‘주관적인 생각’도 많이 들어있는 글임을 밝힙니다.”

요즘 회사 뿐만 아니라 온라인 매체에서 ‘애자일’이라는 단어를 생각보다 자주 접하게 된다. (필자는 애자일을 2019년에 처음 접했는데 그 때 최근에 나온 새로운 방법론인가? 하고 찾아봤다가 생각보다 오래전에 나온 방법론이라 놀랐던 기억이 있다.) 그럼 도대체 ‘애자일’이란 무엇인가? 라는 질문에 대한 답을 알아보기 전에 왜 요즘 애자일에 대한 관심이 많아지고 회사에서도 애자일을 적용하라는 이야기가 나오는걸까? 라는 의문에서부터 시작을 해보려고 한다. 필자가 받았던 애자일 개발 방법론 교육이나 애자일 관련 도서와 영상 등에서도 먼저 짚고 넘어가는 내용이기도 하다.

* 전통적 프로젝트 수행 방식

대부분의 프로젝트에서는 계획 중심 방법론인 ‘폭포수 방법론(waterfall method)’를 적용하여 순차적으로 개발을 진행해 나간다.

예를 들어 프로젝트를 하나 진행하게 되면 가장 먼저 고객이 어떤 대상에게 어떤 기능들을 제공하고 싶어하는가와 같은 1. 고객의 요구사항을 확인한다. 요구사항 확인을 통해 이 프로젝트에서 만들어야할 목표와 구현 범위가 정해지면 개발을 위해 2. 요구사항 분석 및 설계 단계를 가지게 되는데 보통 이 부분은 그 프로젝트의 리더급이나 메인 개발자 분들이 진행하게 될 것이다.

분석 및 설계가 완료되면 프로젝트 관리자(PM)는 팀원들에게 개발 업무를 분배하게 되고, 개발자들은 정해진 일정에 맞춰서 각자 3. 개발을 시작한다. 다양한 이슈와 오류들을 해결하고 잦은 야근도 해가면서 개발이 완료되면 통합테스트, 사용자 테스트 등의 4. 테스트에 들어가는데 이때 고객도 테스트에 참여함으로써 그동안의 요구사항에 대한 결과물을 직접 접해볼 수 있게 된다. 테스트를 통해 발견된 문제점이나 변경사항들을 수정하고 테스트를 반복한 끝에 더 이상 문제가 없다고 판단이 되면 5. 오픈을 하게 되는데 이처럼 분석, 설계, 개발, 테스트와 같은 일련의 단계에 따라 순차적으로 프로젝트를 진행하게 되는 것이다.

필자가 아직 년차가 적어 프로젝트 경험이 많진 않지만 아마 대다수의 분들이 비슷한 프로세스를 경험해보았거나 이 글을 읽고 계신 지금 이 순간도 어디선가 이와 비슷한 방식으로 프로젝트나 개발을 진행 중 이실거라고 생각한다. 그럼 이처럼 익숙하고 여기저기 흔히 사용될 뿐만 아니라 단계도 명확해서 관리하기도 쉬워보이는 이 전통적 프로젝트 수행방식에는 한계점이 없는 것일까??

* 전통적 프로젝트 수행방식의 한계

처음부터 요구사항이 명확하고 프로젝트 기간이 한참 지난 후반부에 가서도 요구사항에 대한 변경이 거의 없으며, 일정이 여유롭고 프로젝트의 결과물이 예측 가능한 범위 내에서 큰 변화가 없다면 기존 전통적 프로젝트 수행방식으로 진행해도 큰 무리는 없을 것이다. 하지만 프로젝트 중간중간 혹은 심지어 프로젝트 막판까지도 변경되고 새로 추가되는 요구사항들을 따라가기에는 기존 전통적 프로젝트 수행방식으로는 한계가 있다고 생각한다. (물론 갑작스런 많은 요구사항의 변경 속에서도 정해진 일정 내 훌륭하게 프로젝트를 끝낸 분들도 분명 있을 것이다.)

그럼 어떤 한계점이 있을지 생각을 해보자.

1) 프로젝트 초기 구체적인 요구사항 도출이 힘들다.

앞서 언급한 거처럼 전통적 프로젝트 수행방식은 각 단계를 순차적으로 진행해 나간다. 그렇기 때문에 모든 요구사항에 대한 분석과 설계가 끝나야 그 다음 단계인 개발로 넘어갈 수 있다. 보통 프로젝트 예산과 일정에 여유가 있지 않기 때문에 정해진 기간 내에 프로젝트를 완료하기 위해서는 빠른 기간 내에 요구사항을 충분히 도출하고 이를 기반으로 양질의 설계를 해야하지만, 대다수의 프로젝트는 초기 요구사항에 불확실한 부분이 많다.

다시 말해 요구사항 분석이 제 때 되기 위해서는 고객(사업부서)이 구체적이고 명확한 요구사항을 제시해야하지만 초기에는 추상적이고 큰 덩어리의 요구사항들을 이야기하기 때문에 상세한 요구사항 도출이 힘들다.

2) 프로젝트 중간에 발생하는 요구사항 변경을 반영하기 힘들다.

프로젝트를 진행하면서 스토리보드나 UI 정의서, 프로토타입 등을 활용하여 고객의 요구사항을 정확히 파악하려고 노력한다. 하지만 이것만으로는 고객이 원하는 최종 모습을 이해하기에는 한계가 있다. 그동안 고객도 여러 회의나 산출물을 통해 예상하던 모습이 있었겠지만 어느 정도 완성된 시스템을 직접 눈으로 보고 눌러보면 생각했던 부분과 다르거나 아쉬웠던 부분들이 생기기 마련이기 때문이다.

폭포수 개발 방식은 프로젝트 후반부에 시스템이 완성되기 때문에 고객의 피드백을 다 반영해주기에는 일정 상 무리가 있다. 버튼이나 폰트 크기 변경과 같은 단순 변경은 반영을 바로 해줄 수 있겠지만 보통 요구사항 변경 시 영향도 분석부터 개발, 테스트를 다시 진행해야 하고 그 과정에서 난이도에 따라 일정에 큰 영향을 미칠 수 있다. 하지만 프로젝트 일정 변경은 곧 비용과 연관되기 때문에 정해진 일정 내에 프로젝트를 끝내기 위해 개발팀 입장에서는 가능한 범위 내로 요구사항 변경을 최소화하려고 노력할 수 밖에 없다. (현실은 결국 일정 내 모든 요구사항 반영을 위해 개발자들이 매일 야근을… )

3) 프로젝트 팀원들 간의 커뮤니케이션 부족

여기서 말하는 커뮤니케이션은 개발 이슈와 같은 업무적 커뮤니케이션을 말한다. (개인적인 잡담은 잘한 거라도 생각한다.) 아무리 계획이 잘 세워지고 설계가 잘 되어있는 프로젝트라도 예상치 못한 문제가 발생할 수 있고, 역량에 따라 해결하지 못하는 이슈가 발생하기 마련이다.

PM, 개발 리더와 같은 관리자와 팀원 간에는 업무적인 커뮤니케이션이 잘 일어나더라도 팀원들 간의 커뮤니케이션이 부족하다보니 현재 서로가 무엇을 개발하고 있고 그에 따른 진행상황이나 어떤 문제점을 가지고 있는지 잘 몰라 도와주기 쉽지 않다. 결국 팀원 간의 소통을 통해 간단하게 해결할 수 있는 문제도 관리자나 리더의 역량에 따라 처리하는 속도가 달라질 수 밖에 없다.

주간 미팅 등은 개발 일정이 촉박해 질수록 미팅 시간과 횟수가 점점 줄어들어 어느순간 중요 이슈만 리더에게 별도 보고를 하게 되기도 하며, 여담이지만 필자가 주변에 프로젝트 하면서 이슈가 생기면 어떻게 해결하냐고 물어본 적이 있는데 “기술적이든 업무적이든 막혔을 때 그걸 해결해주면 좋을텐데 리더급들은 무한 회의로 자리에 없고, 회의 다 끝나고 나중에 물어보려고 해도 그 분은 또 밀린 개인 업무를 해야하니 물어보기 눈치 보인다.” 는 이야기를 들은 적도 있다.

마무리

많은 산출물 등 프로젝트를 진행하면서 힘들거나 불만사항을 나열하기 시작하면 끝이 없을거다. (필자가 글을 쓰면서 도움을 구하고자 주변에 질문을 하면 마치 기다렸다는 듯이 불만사항이 끊임없이 나온다..)

필자가 작성한 한계점 이외에도 더 많은 문제점들이 존재하며, 이러한 전통적 프로젝트 수행방식의 한계점을 보완하고자 나온 새로운 접근 방식이 ‘애자일 개발 방법론’ 이라고 하지만 사실 이런 내용은 관리자가 아닌 개발자 입장에서는 큰 공감을 얻지 못할지도 모른다.

애자일을 설명하기 위한 첫번째 글로 ‘전통적 프로젝트의 한계’부터 작성 하였지만 애자일 방법론이 꼭 프로젝트에만 적용되는 내용이 아니며, SM업무에도 응용하여 적용이 가능한 부분도 있고 알아두면 언젠가 도움이 되는 부분도 있을거라고 생각한다. 필자의 글솜씨가 많이 부족할 순 있지만 최선을 다해볼 것을 다짐하며 다음 글을 통해 애자일의 ‘4대 가치’와 ’12대 원칙’에 대해서 살펴보도록 하자.

참고

  • 도서 : 애자일&스크럼 프로젝트 관리(저자 : 이재왕)

댓글 남기기

이 사이트는 스팸을 줄이는 아키스밋을 사용합니다. 댓글이 어떻게 처리되는지 알아보십시오.

%d 블로거가 이것을 좋아합니다: