왜 개발자의 성과를 정확히 측정해야 하는가?
시리즈: 개발자 성과평가, 어떻게 해야할까?
시작하며
대체 개발자의 성과를 측정하는게 뭐고, 왜 해야 되는지 어렴풋이 알고 있지만 뚜렷하지 않았던 과거를 뒤로하며 글을 시작 해봅니다.
미디엄블로그 프루퍼 (Proofer) 는 개발자의 성과를 정확히 측정하고 평가하기 위한 서비스를 만들기 위해 연구하고 서비스를 만드는 과정을 공유하기 위해 만들어졌습니다.
프루퍼팀이 왜 이런 서비스를 계획하게 되었고 이런 내용들을 발행하게 되었는지에 대해 알기 위해서 이 아티클을 쓰고 있는 필자의 경험을 떠올려 보겠습니다.
왜 개발자의 성과를 평가해야할까?
한때는 평가받는 개발자로써, 한때는 평가하는 매니저로써 지내오며 지속해서 쌓아온 고민이 있습니다.
개발자에게 “오늘 하루는 어땠나요?” 라고 물어본다면 누구나 대답할 수 있을 것입니다. 하지만 “이번 한 주는 어땠나요?” 라고 물어본다면 조금 생각을 해야하고 “이번 한 달은 어땠나요?” 라거나 “이번 상반기는 어땠나요?” 라고 물어본다면 막막합니다.
하물며 이런 개발자를 평가하는 매니저의 입장이 되어서는 개발자 본인도 모르는 성과를 평가 해야하는 아주 곤란한 상황에 맞닥뜨리게 되었습니다.
당연히 평가는 받는 개발자에게도, 하고 있는 매니저에게도 만족스럽지 않았고 더욱이 만족스럽지 않은 평가는 개발자가 회사와 팀에 대해 느끼는 만족도에도 큰 영향을 끼칠 것입니다. 그리고 끝내 자신의 능력을 제대로 봐주지 않는 회사를 나와 다른 회사로의 이직을 고민합니다.
이제는 대부분의 비즈니스에 소프트웨어가 필요하게 되고 있고 그렇지 않은 전통 비즈니스 또한 디지털 트랜스포메이션 되는 추세입니다. 때문에 매니저는 이런 귀중한 인재들을 최대한 놓치지 않아야 하는 상황입니다.
그렇다고 개발자를 기준없이 모두 고용하기에는 천정부지로 높아지고 있는 개발자의 인건비를 감당 하는것은 어느 회사에게나 어려운 일이고 특히 아직 비즈니스도 안정되지 않은 스타트업들에게는 너무나 큰 고민입니다.
지금까지의 개발자 성과평가
지금까지는 직원의 성과를 측정하려고 할때, 그리고 그 성과에 대한 보상을 하려고 할 때에 대부분 프로젝트가 얼마나 성공했는지, 돈을 얼마나 벌어냈는지 등 비즈니스적인 지표들을 직접 활용해왔습니다. 개발자가 아닌 대부분의 직무 성과는 합리적으로 측정할 수 있다고 하며 심지어 일부 직무의 성과는 단 한가지의 측정 항목 만으로 측정할 수 있는 경우도 있습니다.
이런 움직임은 개발자에게도 다르지 않았습니다. 실제로 여러 회사의 CTO 들을 인터뷰해본 결과 개발자의 성과측정을 포기하고 비즈니스 성과 지표로만 평가하고 있다는 공통된 다수의 답변을 받기도 하였습니다.
“개발” 은 비즈니스에 직접적인 기여를 하지 않는다.
하지만 우리는 개발자가 개발을 잘 하는 것과 비즈니스가 성공하는 것이 직결 되지는 않는다는 것을 모두 알고 있습니다. 개발자가 퀄리티 있고 협업가능한 코드를 빠르게 작성하여 안정성있게 배포한다고 해도 비즈니스가 제대로 받쳐주지 않는다면 비즈니스적인 지표는 오르지 않습니다. 또한 이런 서비스를 보는 고객들에게는 마치 빛좋은 개살구로 비쳐질 것입니다.
때문에 시장은 개발만 잘하는게 아닌 비즈니스까지 잘하는 개발자를 원하기도 하고 이것이 최근에는 개발자들의 커리어 방향에도 고려되고 있습니다. 하지만 여전히 모든 개발 업무가 비즈니스와 연관된 것은 아닙니다. 서비스를 안정적으로 운영하는 일, 레거시 서비스 코드를 리팩토링하는 일, DevOps 로 업무 효율을 올리는 일 등 개발자가 하는 일들에는 비즈니스와 직접적인 연관이 없는 일들이 더 많습니다.
비즈니스 성과로는 개발자의 성과를 평가하지 못한다는 것을 알았습니다. 그럼 대체 왜 지금까지의 회사에서는 개발자의 성과를 비즈니스 성과로 평가해왔던 걸까요?
개발자 성과는 측정할 수 없다?
개발자 성과를 측정하는 것이 어렵다는 점은 차마 부인할 수가 없습니다.(정말 어려우니깐요)
소프트웨어 개발은 다양하고 많은 사람들의 협력 아래 진행되어 고도로 복잡하며 창의적인 작업이고 개발자 개인 뿐만이 아니라 규모(예: 시스템, 팀, 개인)에 대해서도 각각 서로 다른 측정 기준이 필요합니다.
게다가 각각의 기준에 맞추어 성과를 추적 해보려고 해도 성과를 나타내줄 수 있는 기반 데이터들이 굉장히 다양하고 무수히 많이 생산되고 있어 이것들을 수작업으로 모두 측정하는 것은 거의 불가능하다고 할 수 있습니다.
몇몇 성실한 매니저들은 그럼에도 개발자들의 성과를 정확히 측정해내기 위해 끊임없이 팀의 생산물들을 검토하고 리뷰하며 피드백한다고 합니다. 하지만 이는 10명 이하의 개발자를 가진 팀에 해당 했으며 팀의 인원이 많아질 수록 이 방식은 물리적인 한계에 봉착할 수밖에 없었습니다.
그렇다고 이걸 불가능으로 단정 지어 아예 측정을 포기하고 비즈니스 성과로만 평가하거나 감에 의존하는것은 개발자를 고용하고 관리하는 데에 장기적으로 큰 실책이 될 수 있어 마냥 안주할 수는 없는 노릇입니다.
이 고민은 이 글을 보고 있는 여러분, 그리고 프루퍼팀만 하고 있던 것이 아닙니다. 개발자를 매니징하고 성과에 대한 보상을 해야 하는 많은 조직에서 같은 고민들을 오랫동안 해왔으며 그 연구에 대한 결과물들이 이제는 분명히 개발자의 성과는 측정할 수 있다 라고 말하고 있습니다.
개발자 성과평가, 어떻게 해야할까?
그래서 개발자 성과평가, 어떻게 해야할까? 시리즈를 통하여 이렇게 파악하기 어려운 개발자의 성과를 어떻게 측정하고 평가해야 하는지에 대하여 지금까지 해온 깊은 고민과 다양한 연구를 통해 얻어낸 인사이트를 다뤄보려고 합니다.
같이 고민해봅시다.
이 아티클에 댓글 혹은 hsol@campersground.kr 으로 이메일 주세요! 저희와 함께 이 문제에 대해 고민해보아요.
이 글에서는 프루퍼팀이 왜 개발자의 성과를 정확히 측정하려 하는가? 에 대해 다루었고, 다음 시리즈 글로는 그래서 개발자 성과는 어떻게 평가해야 할까? 에 대해 작성해보겠습니다.
왜 개발자의 성과를 정확히 측정해야 하는가? was originally published in 프루퍼 블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.