애자일 방법론. SI에 적용해보았다?!

직전 프로젝트의 전력화(서비스 오픈)가 실패했다고 한다.

여러가지 복합적인 이유가 있었겠지만, 클라이언트 측은 프로그램의 품질 관리가 원인이었다고 결론을 지었다. 그리고 사업 수행 방식에 있어서 변화를 모색했다. 그들이 찾아낸 키워드는 애자일 방법론이었다. 기존의 워터폴 방식에서 애자일 방식으로 변경되는 시도가 최초로 일어난 것이다. 그리고 그 시도의 시작점에는 내가 소속된 업체, 소속된 팀이 있었다.

결국 애자일 방법론을 선택하게 된 이유는 프로그램의 품질 개선이었다.

문제는 모두가 애자일 방법론을 처음 경험한다는 것이었다. 공공기관 SI라는 환경에 애자일을 적용한다는 건, 쉽지 않은 시도였다. 벌써 2년 전인 22년도 SI 사업. 여름이었다.

---

1. 설계에 대한 오해.

애자일 이전에 설계 부분에 적용하고 싶은 말이다. 초기에 계획했던 설계는 실제로 개발에 들어가면 쉽게 뒤집어지고는 했다. 그 때마다 이미 구현해둔 컴포넌트들까지 뜯어고치는 경우가 얼마나 빈번했던가. 변화에 민감하게 반응하는 애자일 방법론은 이런 문제를 해결할 수 있을 것이라는 기대감이 들었다.

더군다나 코로나 판데믹으로 시작된 개발자 구인난으로 인해 PL 포지션까지 나에게 맡겨지게 되었다.

진보적인 방법론에 PL이라는 권한까지, 잘 해내고 말겠다는 기대감이 부풀어올랐다.

애자일 방법론은 컴포넌트, 혹은 그보다 더 작은 단위로 분석-설계-구현-테스트-배포가 이루어진다. 이러한 단위를 스크럼, 그리고 스크럼 단위로 진행되는 프로세스를 스프린트라고 한다. 여기서 우리가 오해했던 점은, 애자일 방법론은 초기 설계 단계 없이 스크럼 단위로만 설계가 가능할 것이라 생각했던 점이다.

기본적으로 스프린트는 아래와 같은 절차로 진행된다. (애자일 스프린트 희망 편)

스크럼 단위로 프로세스가 나뉘어져 있다. 그리고 스크럼 단위로 분석/설계 ~ 배포 까지 프로그램 개발의 모든 과정을 끝마친 후, 다음 스크럼으로 넘어가게 된다.

즉, 모든 스크럼은 서로 독립된 작업 영역이며 서로에게 영향을 주어서는 안되는 것이다. 하지만 세상 어느 프로그램이 이렇게 딱딱 떨어지게 나뉜다는 말인가.

애초에 무슨 기준으로 스크럼을 나눌 것인가. 이 질문에 대해서 너무 간단하게 생각하고 말았다.

실제로 진행된 스프린트는 이론과는 조금 달랐다. (애자일 스프린트 현실 편)

워터폴처럼 하나의 거대한 덩어리 내에서 벌어진 일이라도 골치가 아팠을 것이다. 더군다나 스크럼이라는 단위로 일정을 나눠놓은 상황에서 이런 일이 벌어지니 더더욱 골치가 아팠다.

서로에게 영향을 주지 않는 범위에서 프로세스를 나눈다는 것. 더군다나 분석/설계부터 배포까지 모든 과정을 끝마칠 때까지 서로에게 영향을 주지 않는다는 것. 완전히 다른 컴포넌트라면 충분히 가능한 일이겠지만 같은 컴포넌트의 기능들을 스크럼으로 나눈다는 것은 너무나도 어려운 일이었다.

워터폴이 됬던, 애자일이 됬던 기본적으로 전체적인 초기 설계를 건너뛸 수는 없었다.
스크럼 단위로 보는 시선이 아닌, 전체적인 그림을 볼 수 있는 시선이 필요했다.

---

2. 스크럼(Scrum)에 대한 오해.

하나의 스크럼에는 프로젝트의 모든 과정이 담겨있다고 해도 무방하다. 실제로 스크럼은 프로젝트를 여러 개의 중간 프로젝트로 나눈다는 느낌이었다.

스크럼 하나가 곧 하나의 프로젝트나 다름이 없었다. 그렇기 때문에 하나의 스크럼을 수행하기 위해서는 PM - PL - 개발자 모든 인력이 달라붙어 제 역할을 해야만했다.

특히 스크럼을 수행하는 스프린트의 특징은 매우 템포가 빠르다는 점이다. 보통은 주 단위로 결과물을 만들어내고 배포해야 했기 때문에 거의 매일 결과물에 대한 점검과 공유가 이뤄져야 했다.

그렇기 때문에 PM,PL의 피로도가 매우 극심했으며, 개발자들 역시 매일매일 결과물을 점검 당한다는 점에서 큰 부담감을 느끼고 있었다.

처음에는 하루 단위로 결과물을 점검하고 공유했지만 하루에 나오는 결과물의 양이 점검까지 해야 할 정도가 되지 못하는 경우가 많았다.

하나의 스크럼이 끝났을 때, 산출물이 어떻게 나올 것인지도 난감했다. 스크럼이 끝날 때마다 배포가 이뤄졌으며 그에 대한 산출물도 제출되어야 했다. 특히 테스트나 평가 자료에 대한 산출물은 애자일에 있어서 필수나 다름 없었다. 고객 입장에서는 스크럼마다 프로그램을 평가해야 했기 때문에 반드시 필요한 산출물이었다.

산출물이야 구현 단계 이후에 반드시 나와야하는 것이었지만, 문제는 그 하나로 이루어진 산출물이 스크럼마다 제출해야 하는 여러 개의 산출물로 분리가 되었다는 점이었다.

애자일 방법론은 각 개발자들의 영향력이나 역량이 고스란히 드러날 뿐만 아니라, 매니저들이 끊임없이 이를 체크하고 문서화 해야 했다. 한 마디로, 에너지를 갈아넣어 각 인력들의 역량을 최고조로 이끌어내는 구조였다.

---

3. 강력한 매니징(Managing)의 필요성.

"PL님! 그냥 게시판에 글 올리고, 파일 다운로드 하고, 댓글 달고, 지우고 이게 다잖아요. 이거 테스트 하려고 제가 매 주마다 확인을 해야 해요?"

애자일 방법론은 고객 중심으로 흘러가는 방법론이다. 일정 단위로 빠르게 결과물을 만들어서 고객에게 보여주고 고객이 빠르게 판단할 수 있도록 유도하는 취지로 만들어진 것이다.

그렇기 때문에 필연적으로 고객의 적극적이고 능동적인 스프린트 참여가 필요했다. 또한 고객 측에서도 빠르고 명확한 피드백이 도출되어야 했다.

"PL님! 그 지난 번에 완성된 부분 확인해봤는데.. 이거 이 정도는 바꿔주셔야겠는데요."

문제는 그 피드백의 수용 범위를 어디까지 잡을 것이냐다. 사람이라는게 원래 프로토타입을 보게되면 없던 요구사항도 생기는 법 아니겠는가. 특히 스크럼 단위가 크면 클수록, 고객의 피드백을 반영하기가 어려워졌다. 그만큼 바꿔야 할 부분이 많아졌기 때문이다.

피드백을 어디까지 수용할 것이냐. 그리고 언제까지 수용할 것이냐. 이미 끝나버린 스크럼에 대한 피드백을 받을 수는 없는 노릇 아닌가.

SI 환경에서 애자일은 고객에게 칼자루를 쥐어 준 좋은 명분이나 다름없었다.

고객의 협조를 이끌어내고 적당한 수용 선을 그을 수 있는 강력한 매니징이 필요했다.

---

4. 다시 애자일 방법론을 적용 한다면.

회고에 대한 결론을 내보고자 한다. 실무에 애자일을 적용해본 결과 몇 가지 느낀 점들을 정리해봤다.

애자일 방법론은.

• 프로젝트의 품질을 높이기 위한 방법론이다.

• 스크럼은 과정에 불과하다. 전체적인 설계와 WBS가 초기에 나와야 한다는 점은 워터폴과 동일하다.

• 스프린트는 관리자의 강력한 관리와 조율이 불가피하며. 테스트, 피드백 등 스프린트 종료에 대한 기준을 고객과 조율해야 한다.

• 애자일 방법론은, 각 구성원 개개인의 역할이 중요한 방법론이다. 그렇기 때문에 각 포지션에 Man/Month가 공백이 있어서는 아니되며, 각 포지션의 역량을 최고조로 이끌어내야 한다.

• 스크럼은 하나의 프로젝트를 여러 프로젝트로 쪼개는 개념으로 접근할 수 있다.

그렇다면 애자일 방법론을 다시 적용한다면 고려해야 할 점은 무엇인가?

애자일 방법론을 적용할 때 고려해야 할 부분은.

• 결제, 혹은 플랫폼 인프라 등과 같이 서비스 안정성과 품질이 중요한 프로젝트인가.

• 일정 마감에 대한 엄격함보다는, 고객의 만족도가 더 중요한 프로젝트인가.

• 고객 측에 개발자와 같은 전문 인력이 있으며, 제시 된 테스트 전략 등이 존재하는가.

• 모든 포지션에 대해서 Man/Month가 보장이 된 프로젝트인가. (인력 공백이 없는가.)

• 한 번에 모든 부분을 검토하기 힘들 정도로 대규모의 프로젝트인가.