Agile 프로젝트의 조직 구성에 대해 알아봅시다.

Agile 프로젝트의 조직 구성에 대해 알아봅시다.

‘멘붕’의 징조

Agile한 조직은 어떠한 모습이어야 할까요? 아아.. 그 전에 먼저, 그 동안의 프로젝트 막바지에 종종 발생하는 고객과의 ‘실갱이’를 떠 올려보죠. 그간의 경험에 비춰볼 때, 테스트까지 마친 시점에 대량의 요건이 추가된다든지 재개발의 요구를 받는 경우가 그리 드물지 않다는 점은 다들 동의하실 겁니다. 수행사인 우리의 입장에서 보자면, 고객이 원하던 게 제대로 구현이 안됐다는 핑계 아닌 핑계로 인해 우리의 ‘롤아웃(Roll-out)’이 몇 개월은 늦춰지는 거죠;;;

‘아 몰랑! 질척댈거양~’

그렇다면 ‘고객’은 왜들 그리 ‘비정하게’ 일 폭탄을 던지는 걸까요? 우리가 미워서? 아니면 들인 돈이 있는데 수행사 빠지기 전에 ‘뽕’ 뽑으려고? 일부는 정말 그런 이유일 수도 있겠지만… 가장 큰 원인은 아마 ‘고객’ 스스로도 프로젝트 초기에는 자기가 뭘 만들어야 하는지 제대로 모르고 있었기 때문일 겁니다. 당연히도 프로젝트를 띄우는 대부분의 경우는 기존에 있던 제품보다는 더 나은 더 새로운, 즉 ‘기존에 없던 제품의 출시’를 목적으로 합니다. 그러니 그 최종적인 모습을 그누구도 모를 수 밖에요.. 프로젝트를 거의 마친 시점에 와서야 자신들의 예측이 틀렸음을 깨닫거나, 시장이 급변하는 경우가 더러 발생하게 됩니다. 그래서 ‘고객’도 무리한 요구인줄 알면서도 프로젝트 막바지에 대량의 수정을 요구하게 되는거죠.

기존 조직과 Agile 한 조직의 모습은 어떻게 다를까?

그럼 다시 Agile한 조직의 이야기로 돌아가 볼까요? 위와 같이 길~~~게 기존 프로젝트에서 답습해 온 우리의 모습을 써 놓은 이유는 우리가 지금 처해 있는 상황을 설명하기 위함이었습니다. 바로 예측 불가능하고 변화무쌍한 시장이 우리의 앞에 놓여 있다는 것이죠. 다들 아시다시피 Agile한 개발은 이러한 상황인식을 바탕으로 이에 대한 적절한 대응을 위해 최근 각광받고 있고, Agile 한 개발을 위해서는 개발을 위한 조직부터 Agile의 모습을 갖추고 있어야 한다는 건 어쩌면 ‘추운 겨울에 눈 내리는 이야기’ 일겁니다. 그럼 우리에게 익숙한 사일로(Silo) 조직과의 비교를 통해 Agile 조직의 특징과 장점을 자세히 알아보도록 하겠습니다.

아래 그림은 기존 워터폴 방식의 인력구성을 나타내고 있습니다. 그리고 이를 곡물저장고인 사일로(Silo)에 빗대어 사일로 조직이라고 칭합니다.

사일로(Silo) 조직은 프로젝트 관리를 위한 단방향의 명령체계를 특징으로 하며 ‘상명하복’식의 하향적 위계질서이자 관료조직의 보편적인 모습이라 할 수 있습니다.

이 조직은 업무 진행을 위한 지시와 통제, 리스크 관리 체계의 단일화 등에서 뚜렷한 장점을 가질 수 있으나, 단계가 많은만큼 의사결정이 느리고 책임의 소재가 불분명하다는 단점이 있습니다. 이로 인하여 사일로 조직은 예측불가능한 비지니스 환경에 대한 대응력이 떨어지는 조직이란 평가를 받고 있습니다.

반면, Agile 조직은 ‘수평성’에 초점을 둡니다. Agile 프로젝트 조직은 ‘고객 리더’, ‘PM’, ‘PMO’ 조직을 중심으로 각 개발팀에 ‘PO’, ‘SM’, ‘개발자(디자이너 포함)’이 함께 참여하여 보다 신속하고 효율적인 개발이란 공통의 목표를 위해 상호 협력합니다.

자, 아래 그림을 보시죠.

그림을 보시면 알 수 있듯, 기존 조직대비 Agile 조직의 가장 큰 특징으로 ‘고객’ 중 일부를 ‘PO’라 명명하여 개발팀의 일원으로 참여시킨 다는 점을 들 수 있습니다. 제품을 기획하는 ‘고객’에게 제품개발 단계 막바지 검수만을 맡기는 것이 아니라 개발 과정에 직접 참여하도록 하여 고객의 제품에 대한 책임의식(Responsibilry)과 주인의식(Ownership)을 높이기 위함입니다. 이렇게 개발팀에 참여하는 ‘고객’을 ‘Product Owner(줄여서 PO)’ 라고 칭하는 이유가 여기에 있습니다. 이렇게 함으로써 ‘PO’는 제품에 대한 애정을 갖게 되고 개발에 대한 책임을 공유합니다. 더불어 중간결과물을 검토하는 리뷰 활동을 통해 도출된 개선사항을 개발 과정 중에 노출되게 함으로써 보다 효율적인 개발에 기여할 수 있게 합니다.

또 다른 특징으로는 기존에 개발 중간책임자를 맡던 PL 인력에게 팀원이 갖는 장애요소를 제거하고 보다 쾌적한 개발환경을 조성하는 Agile Facilitator로서의 ‘SM’이라는 역할을 부여하는 점입니다. 구체적으로는 기존 PL이 갖고 있던 명령하고 지시하는 ‘관리자’의 역할을 팀 내 개발자를 위한 생산성 향상에 초점을 둔 ‘코칭’의 역할로 변화시키는 것으로써, 구체적으로는 ‘PO’와 함께 요건을 분석하고 소요되는 공수 등을 협의한 후 적합한 개발자에게 할당하는 등의 ‘업무 조정자’ 역할도 맡게 됩니다. 이런 ‘SM’이 조성해 주는 개발환경에서 디자이너를 포함한 개발자들은 매 스프린트마다 맡은 User Story 에 따라 ‘잠재적 출시 가능 제품’을 개발하는 역할을 맡습니다. 여기서 말하는 개발이라는 역할에는 개발 요건 혹은 User Story에 대한 분석, 설계, 개발, 테스트가 모두 포함되며, 일반적으로 2주~4주 간의 스프린트 계획에 따라 하나의 개발 사이클을 완료하개 됩니다. 개발자 개인별 업무 성과를 우선 시 하던 기존의 프로젝트 조직과 달리 Agile 조직에서는 팀 공통의 성과를 더욱 중요하게 여기는데, 이는 Jira 및 Confluence 와 같은 Agile 프로젝트 Tool을 통해 각 개발자의 업무, 진행단계, 결과가 투명하게 공유되고 이를 바탕으로 협업함으로써 실현됩니다. 이렇게 ‘PO’와 ‘SM’, ‘개발자(디자이너 포함)’로 구성된 Agile팀은 실행에 초점을 맞춘 전략을 바탕으로 짧은 시간 내에 가시적인 성과를 만들어 내기 위해 노력합니다.

마지막으로 개발팀 외부에 존재하는 ‘고객 리더’와 수행사 ‘PM’, 그리고 ‘PMO’ 조직은 각 개발팀을 대상으로 프로젝트를 위한 비전을 제시하고 적극적인 참여를 위한 동기를 유발합니다. 이들이 프로젝트 전체를 지휘하고 책임지는 것은 기존의 조직과 동일하나, 개발팀의 위에서 일방적으로 명령하고 지시하는 것이 아닌 개발팀 구성원들이 보다 의욕적으로 프로젝트에 참여할 수 있는 환경을 조성하고 프로젝트 전체에 영향을 미칠 수 있는 Risk 를 사전에 예측하고 제거할 목적의 ‘Scrum of Scrum(SOS)’를 운영합니다.

자! 이제 다같이 열린 마음으로!

지금까지 Agile한 프로젝트를 위한 조직 구성은 어떻게 이루어지는가에 대한 이야기를 나눠봤습니다. 그동안 IT프로젝트를 주도해 온 워터폴(Waterfall) 방식의 방법론과 이에 입각한 사일로(Silo) 조직은 민첩한 대응을 요구하는 현 시장 상황에 대응하기에는 너무 느리고 비효율적인 프로젝트 방식이자 조직구조입니다. 이에 대한 대안으로 나온 것이 Agile 방식의 개발 방법론이고 이를 수행하는 사람들의 모임이 Agile 한 조직입니다. 앞서 이야기했듯 Agile 한 조직의 궁극적인 목표는 보다 효율적이고 민첩하며 상호협력적인 유기적인 조직을 이루어 변화무쌍한 시장의 니즈(Needs)에 적합하게 대응하는 프로젝트의 성공입니다.

하지만 여기서 꼭 짚고 나가야 할 점이 있다면 이런 Agile 프로젝트도 Agile한 조직구성도 모두 다 사람이 하는 일이라는 것입니다. 다들 눈치채셨겠지만.. 효율적인 조직을 만들기 위해 무엇보다 중요한 것은 Agile 프로젝트에 참여하는 전통적인 ‘역할론’에 얽매이기 보다는 조금은 더 열려있고 팀을 우선하는 협력적인 마음가짐을 먼저 가져야 한다는 것입니다. 당연하게도 이러한 열린 자세를 가진 사람들이 모여야 Agile 조직이 성공적으로 구성될 수 있습니다. 이제는 지시와 순응이 아닌 이해와 동의가 앞서는 보다 수평적인 자세로 우리가 직면하고 있는 예측 불가능한 세상에 대응하셨으면 한다는 말로 이번 포스팅을 마치겠습니다.

간략 정리:

1. Agile한 조직은 기존 사일로 조직에 비해 ‘수평성’, ‘적극성’, ‘신속성’, ‘실용성’, ‘유기성’ 측면에서 강점을 갖고 있습니다.

2. Agile 한 조직은 수평적이고 상호협력적인 관계를 만들기 위한 열린 마음을 지닌 사람들이 모여야 성공할 수 있습니다.

3. Agile 프로젝트를 이루는 기본 인력구성과 대략적인 역할은 다음과 같습니다.

   • Product Owner - 프로젝트에서 생성되는 제품의 최종 책임자로서 스프린트가 진행됨에 따라 갖추어지는 제품에 대한 중간 피드백, 요건 제시, 최종 제품에 대한 컨펌 등을 담당하는 플레이어
   • Project Manager - 프로젝트의 관리자로서 스크럼과 스크럼을 이루는 모든의 스프린트가 진행되는데 문제점을 찾아내고 해결하는 플레이어
   • Scrum Master - 자신이 담당하는 스크럼 팀의 책임자로서 그 팀의 User Story 진행 상황을 체크하고 문제점을 해결하며, 개발자와 PL, PM 사이의 브릿지 역할을 하는 플레이어
   • Developer(UI/UX Designer 및 Tester 포함) - 자신의 고유한 디자인 및 개발 역량을 지니고 스크럼 팀을 구성하는 기본 인력으로 실제 개발 및 테스트를 담당하며 Scrum Master, PL, PM 및 PO와의 리뷰, 회고 및 문제해결 작업에 참여하는 플레이어

출처 구글