Agile과 RnR의 관계
흔히들 말하길 스타트업은 구성원에 대한 정확한 RnR이 없다고들 말한다. 회사도 작고 인원도 소수이고 아직 회사가 매출과 이익을 내지 못하는 경우가 대부분이므로 살아남는 생존이 당면한 우선과제이기 때문이다. 따라서 구성원들에 대한 정확한 역할과 책임 없이 모든 구성원이 무슨 일이든 닥치는 대로 해야 하는 것이다.
이러한 특징은 회사가 안정적으로 매출과 이익이 나기 시작하고 구성원이 늘어나면서 변화를 맞이하게 된다. 시작은 인사 및 총무팀이 생겨나고 IT시스템을 갖춘 전산팀이 생겨나고 영업조직이 체계를 갖추는 것에서부터다. 추가로 필요한 여러 부서들이 생겨나게 되면 비로소 RnR에 대한 논란 즉 역할과 책임에 대한 공방이 시작된다.
이는 회사가 조직체계를 갖추게 되고 조직별 KPI를 강조해 성과를 측정하면서 필연적으로 생겨나는 논란이기도 하다. 이러니 저러니 해도 결국 RnR이란 좋게 표현하면 역할과 책임을 명확히 하는 것이고, 나쁘게 표현하면 니일 내일을 나누기 시작하는 것이기 때문이다.
RnR에 강하게 집착하는 현상은 규모가 큰 대기업일수록 심하다. 회사에 다니고 있는 직원들도 다 알지 못할 만큼 많은 본부, 부서, 팀들로 구성되어 있기 때문이다. 직장인은 자신이 속한 본부와 부서와 팀의 매출과 성과를 통해 일 년의 업무 결과를 평가받게 된다. 따라서 타 본부 타 부서 타 팀의 매출과 성과는 전혀 관심의 대상이 아니다.
그 결과 회의를 하다 보면 어느 부서 혹은 어느 팀에서 할 일이냐를 가지고 옥신각신하는 모습을 흔히 볼 수 있다. 그나마 매출과 이익이 기대되는 달콤한 업무라면 서로 가져가려고 할 테니 다행이다. 매출 및 성과와 무관한 업무라면 불필요한 잡무로 분류되어 남에게 떠넘기기 위해 더더욱 열심히며, 간혹 부서 간 분쟁의 이유가 되기도 한다.
일단 조직에서 RnR이 누구에게 있는지, 니일인지 내일인지를 따지게 되는 순간부터 생겨나는 치명적인 현상은 업무의 지연이다. 스타트업이라면 2~3일이면 해결될 일이 대기업에서는 몇 달에 걸쳐 여러 번의 회의를 거치고도 결론에 이르지 못하고 표류하게 되는 경우가 흔하다.
자세히 들여다보면 업무 자체가 복잡하고 어려워서 발생하는 현상이 아니다. 그저 서로 내일이 아니라고 생각하고 방관하다 보니 생겨나는 현상이다. 자신이 속한 부서나 팀의 목표와 상관없는 업무라고 판단되면 추가적인 일감으로 인식해 배척한다. 굳이 나서서 해줘 봐야 일만 많아지고 성과에는 도움이 되지 않는다고 판단한다. 그 결과 의사결정이 늦어져 업무처리 기간이 길어지는 지연현상이 쉽사리 사라지지 않는다.
이런 문제를 해결하고자 IT분야에서는 언제부턴가 Agile 체계라는 것이 대두되기 시작했다. 지루하게 늘어지는 의사결정 과정을 단축해 업무의 효율성을 높이자는 목적을 가지고 있다. 그 대표적인 예가 DevOps 또는 DevSecOps라고 할 수 있다. 서로 다른 조직에 속해 있던 분야 담당자들을 하나의 조직으로 묶어 조직 내에서의 협의 및 의사결정을 통해 빠르게 업무를 처리하는 것을 목표로 한다.
"이건 우리 부서(팀)의 역할(RnR)이 아니다."
이 말이 나오는 순간 회사의 업무는 늦은 의사결정으로 지연되기 시작한다. 앞단계에서 결정이 되지 않아 막혀있으므로 당연히 다음 단계들은 대기 상태이다. 대부분의 회사들(특히 대기업일수록)은 이런 병목구간들을 가지고 있다. 이 구간들을 슬기롭게 처리해 Agile 하게 만드는 것이 경영진의 책임이다.