개발자의 역량측정 메트릭은 개인의 역량만 측정할까?
21년도에 쓴 글을 읽어보고 다시 든 생각을 정리 해 봤다.
21년도에 썼던 글 내용
정거장 단톡방에서 다음과 같은 주제로 대화가 이루어졌다.
위의 기사를 보고 학원 등에서 개발자 교육 이수 후 실무에 투입되는 분들이 많은데, 개발자 부족현상이 해소되어 인원조정을 해야할 시 어떻게 될 지 걱정된다는 말을 시작으로 대화가 이루어졌다.
그러자 20년 전부터 계속 같은 상황이 반복이라며, 하지만 진짜 필요한 개발자가 늘어난 건 아니다, 유사개발자가 많다, 학원에서 찍어내는 '개발자'만 많다, 그냥 코더이다. 등등....
다양한 의견들이 나왔는데, 다음과 같은 개발자의 미래 예언을 하신 분이 있었다.
지금 막 개발을 시작한 사람들은 10년내에 큰 고생을 하게될겁니다.
월급은 정체되거나 깍이고 회사에서는 찬밥 신세고,,,,
그걸 대략5년정도 버티고나면 다시 대우받는 시절이 올겁니다.
이유는 절반이상의 '개발자'가 개발을 때려치고 다른 길로 가게되고
더 이상 신규 개발자가 들어오지 않는 상황이 되니까요
그리고 아래의 링크를 주셨는데 두고두고 체크해보면서 발전 방향을 잡아가면 좋을 것 같아 기록해둔다.
(원래 글이 사라져서 다른 글로 대체함.)
이전 고과 평가에서의 역량측정 경험
이전 회사에서 고과를 평가할 때 위 글에서 말했던 효과적이지 않은 메트릭인 코드 줄 수, Git 커밋 으로 성과를 측정했던 경험이 있다.
내가 수행했던 프로젝트는 기존에 운영되고 있는 커머스서비스의 새로운 버전을 만드는 구축 작업이었는데, 매 스프린트마다 내가 해야 할 목표치가 정해져 있었지만 API설계부터 완료되지 않았었고, 퍼블리싱도 나오지 않았던 상태여서 이렇다 할 결과물을 내기엔 애매한 상황이었다.
하지만 뭐라도 작업을 해야했기에 SB만 보고 기능을 구현했었는데, 프로젝트로 돌아가는 모습을 보았을 때도 굳이 한 번더 일하 는 것이기도 했고 다른 부서 진척상황이 우리 마음같지 않아서 답답했던 경험이 있다.
그런 프로젝트에서는 그나마 역량을 측정할 수 있는 메트릭이 코드 줄 수와 Git 커밋이었던 것 같다.
개발자의 역량측정 메트릭의 중요성
위의 글을 보고 느낀 점은, 개발자의 역량측정 메트릭은 단순히 개발자 개인의 기술적 실력을 평가하는 게 아니라는 것이다.
이전 회사의 경험으로 그런 프로젝트는 다시는 경험해보고 싶지 않다는 생각이었지만, 지금 생각해보니 그때에는 그 상황이 최선의 상황이었다고 판단된다. 그리고 프로젝트는 절대 계획대로 되지않는다는 점을 이제 깨달았다.
그렇기에 가변적인 프로젝트에도, 속해있는 팀원들에게도, 개발자 개인에게도 프로젝트 수행이라는 하나의 목표를 위해서는 역량측정 메트릭이 나침반 역할을 하기에 필요해보인다.
상위 10가지 개발자 성과 메트릭
글에서 말하는 상위 10가지 개발자 성과 메트릭은 다음과 같다.
- 배포 빈도
- 배포 빈도는 팀이 얼마나 자주 코드를 프로덕션에 릴리스 할 수 있는지를 측정한다.
- 배포 빈도가 높다 => 소프트웨어 개발 프로세스와 배포 파이프라인이 효율적이다라는 것을 의미
- 리드 타임
- 기능의 작업 시작 ~ 프로덕션에 적용될 때까지 걸리는 시간
- 개발 주기 내에서 속도와 효율성을 측정하는 핵심 메트릭이다.
- 사이클 시간
- 프로젝트 시작부터 완료됨으로 표시하는 것까지 팀이 얼마나 빨리 작업을 완료할 수 있는지를 보여주는 메트릭
- 짧을수록 효율적으로 일하고 길수록 비효율성을 암시한다.
- 변화를 위한 리드 타임
- 팀이 코드 변경사항을 초기 커밋에서 프로덕션에 적용하는 데 얼마나 빨리 이동할 수 있는지를 측정함.
- Velocity
- 스프린트동안 팀이 완료할 수 있는 일을 측정하는 애자일 메트릭
- 팀의 용량에 대한 인사이트를 제공하고 향후 스프린트에 대한 현실적인 기대치를 설정하는 데 도움이 됨
- 진행 중인 작업(WIP Working in Progress)
- WIP 한도를 설정하면 과부하를 방지하고 집중력을 유지할 수 있고, 멀티태스킹을 줄이는데 도움이 됨.
- 변경 실패율
- 배포 후 버그, 중단같은 문제가 얼마나 자주 발생하는지 추적하여 릴리즈의 안정성을 명확하게 파악할 수 있음.
- 서비스 복구시간
- 팀이 프로덕션에서 문제를 얼마나 빨리 해결하는지를 측정
- 고객 만족도 (CSAT)점수
- 일반적으로 설문조사와 피드백을 통해 수집되며, 제품이 사용자의 요구를 얼마나 잘 회의하고 있는지에 대한 직접적인 인사이트를 제공
- 팀 상태
- 팀의 건강과 사기는 프로젝트에서도 중요하지만 개발자 개인에게도 매우 중요합니다.
- 이를 추적하려면 커뮤니케이션, 사기, 스트레스 수준 등에 주의를 기울여야 합니다. 정기적인 체크인, 설문조사, 회고를 통해 팀의 기분과 협업이 얼마나 잘 이루어지고 있는지에 대한 귀중한 인사이트를 얻을 수 있음.
앞선 메크릭을 통해 얻을 수 있는 프로젝트를, 팀원을, 개발자개인을 이끄는 가치들은 무엇일까
앞선 개발자의 역량 평가 기준은 결국 프로젝트의 성공과 팀의 효율성을 우선시한다. 가치를 우선순위로 생각하게 되면, 일반적으로 다음과 같은 기준이 중요하게 여겨진다고 할 수 있다.
- 사용자 중심: 개발 결과물이 실제 사용자에게 어떤 가치를 제공하는가?
- 효율성: 주어진 자원과 시간 내에 얼마나 효과적으로 문제를 해결했는가?
- 적응력: 요구사항 변화나 예기치 못한 상황에 얼마나 잘 대응했는가?
- 협력과 소통: 프로젝트 전반의 커뮤니케이션과 팀워크 수준은 어떠했는가?
결론
개발자의 역량 측정 메트릭은 개 인의 기술적 성취를 넘어 팀과 프로젝트의 성공을 위한 기여도와 가치를 포함해야한다