필자가 다니고 있는 회사는 소위 매트릭스 조직으로 운영을 하고 있다. 개발자는 교차 기능팀(Cross-functional Team)에서 공동의 목표를 가지고 가설과 실험을 통해 신규 기능 개발을 하거나 기존 기능의 개선 업무를 수행하거나 기능팀(Functional Team)에서 개발자들의 생산성 향상을 위한 레거시 개선 및 개발 환경 개선을 위한 업무를 수행할 수 있다.
대부분의 IT기업에서 개발자는 한정적이고 하고 싶은 혹은 해야만 하는 일들은 많기 때문에 어떤 일을 우선적으로 해야 하는지에 대한 가치 판단 및 우선순위 설정은 매우 중요하다. 교차 기능팀의 경우 서비스의 가치를 높이는 것이 주요한 목표이므로 최근 많은 스타트업들이 사용자 데이터에 기반하여 가설을 세우고 사람들의 반응을 살펴보며 방향성을 잡거나 우선순위를 매긴다. 그럼 생산성 향상을 목표로 해야 하는 경우에는 어떤 방식으로 우선순위를 설정해야 할까? 고민을 하던 중 최근 Software Engineering at Google 에서 ‘Measuring Engineering Productivity’ 라는 챕터의 내용을 보며 들었던 생각을 책의 내용과 함께 적어보고자 한다.
생산성을 꼭 측정해야 하는가?
어떤 작업으로 인해 향상되는 생산성을 어떻게 측정해야 하는지를 이야기하기 전에 매우 중요한 질문이다. 왜냐하면, 생산성을 측정하는 것은 측정하는 것 자체에도 많은 비용이 들어가기 때문에 생산성을 측정함으로 인해 얻을 수 있는 가치에 대해 생각해봐야 한다. 또한 측정한 결과가 긍정적이든 부정적이든 그 결과에 따른 행동이나 결정에 변화가 없다면 측정할 가치가 없을 가능성이 높다.
생산성을 어떻게 측정할 것인가?
과거에는 정해진 시간 안에 얼마나 많은 코드를 생산했는지(LOC)를 판단하던 시기도 있었지만, 최근엔 아무도 코드의 라인수를 통해서 생산성을 측정하려 하지 않을 것이다. 그렇다면 구글에서는 어떤 방식을 사용했을까? 구글에서는 GSM(Goals/Signals/Metrics) Framework를 이용한다고 한다. 개인적으로 요즘 많은 스타트업이 도입하고 있는 OKR과 비슷한 관점이라는 생각이 든다. GSM 이 어떤 것인지 더 알아보자.
목표(Goals)
목표는 그 자체로는 측정할 수 없지만 모든 사람이 동의하는 것이여야 한다고 한다. 다만 생산성에 영향을 끼치는 요소는 다양하고 하나의 요소를 향상시키는 작업이 다른 요소는 저하시키는 상황이 벌어질 수 있기 때문에 구글에서는 “QUANTS” 라고 하는 다섯 가지의 요소로 분류하여 판단한다고 한다.(특성에 따라 해당하지 않는 항목이 있을 수도 있다고 한다)
Quality of the code(코드의 품질)
이 작업을 통해서 코드의 품질이 개선되는지를 의미한다.
Attention from engineers(엔지니어의 집중)
엔지니어들의 집중도를 향상시키는지 혹은 산만하게 만드는지를 의미한다.
Intellectual complexity(지적 복잡성)
업무를 완수하는데 있어서 어느 정도의 인지적 부하를 발생시키는지, 문제를 해결하기 위해 불필요한 처리를 하거나 내재되어 있는 복잡도를 얼마나 이해해야 하는지에 대한 상태를 의미한다.
Tempo and velocity(주기와 속도)
개발을 완료하는데 드는 속도와 주기의 측면을 의미한다.
Satisfaction(만족)
자신의 작업이나 제품에 대해 얼마나 만족감을 느끼는지에 대한 부분을 의미한다.
신호(Signals)
신호는 목표를 달성했는지를 판단할 수 있는 기준이다. 다만 이 단계에서 모든 신호가 측정 가능한 것은 아니라고 한다. 즉, 정량적으로 측정되지 않아도 정성적으로 판단되거나 보여지는 어떤 현상을 의미할 수 있다. 하나의 목표에는 최소한 하나 이상의 신호가 존재하며 하나의 신호가 여러 목표에 공유될 수도 있다고 한다.
측정항목(Metrics)
측정항목은 신호의 측정 가능한 proxy 라고 한다. proxy 라는 것이 완전히 일치함을 뜻하는 것은 아니기 때문에 하나의 신호에는 그것을 대표하는 여러 측정항목이 존재할 수 있으며, 일부 신호에는 측정항목이 존재하지 않을 수도 있다. 신호가 나타내는 것과 측정항목이 다른 경우가 발생할 수도 있는데 이는 잘못된 측정항목이 문제일 수도 있고, 인지적 편향에서 발생할 수도 있기 때문에 다양한 측정 항목등을 통해 검증이 필요할 수 있다.
훌륭한 엔지니어링 환경 만들기
IT 기업에서 새로운 기능을 추가하는 일은 비지니스 관점에서의 가치와 쉽게 연결되며 전사레벨에서의 목표 과제가 되는 반면 엔지니어링 환경 개선을 위한 작업들은 개발자들 개개인의 의지로 짬짬이 이루어지거나 특별한 우선 순위 없이 개인의 흥미 위주나 하기 쉬운 과제 중심으로 이루어지기 쉽다.
하지만 엔지니어링 환경 개선을 위한 작업들은 단순히 개개인의 취향의 문제로 다루어져서는 안 되며 조직의 생산성 향상에 얼마나 기여하는지에 따라 우선순위가 정해져야 할 것이다. 또한 그 작업을 수행하는 개발자들 역시 그러한 작업이 가져오는 효과와 의미에 대해 잘 이해하고 내가 그 작업을 통해 조직에 어느 정도의 기여를 하고 있는지 이해하는 것이 동기부여에도 중요하다고 생각한다.
IT 조직 내에서 개발 환경 개선을 위한 작업을 계획하고 있다면 위의 내용들을 고려해서 그에 대한 중요성을 설명하고 우선순위를 잡아보면 어떨까 싶다.