SPACE Framework 분석 및 활용방법
GitHub 에서 발표되어 Microsoft Research 팀이 관리하고 있는 SPACE 프레임워크는 개발자들의 엔지니어링 생산성을 측정하고 이해하여 최적화하고 평가하기 위해 사용됩니다.
대표적인 개발자 생산성 측정 도구인 DORA Metrics 와 다른점은 이 문서에서도 언급 하였듯이, 측정되는 특정 지표가 아닌 생산성을 측정하는 “방법” 이라는 것입니다.
종종 SPACE Metrics 라고 쓰는 사람들이 있는데 이는 틀린 표현입니다.
SPACE Framework
SPACE Framework 에서는 생산성을 5가지 지표로 분류합니다.
- [S]atisfaction and wellbeing(만족도와 웰빙)
- [P]erformance(성능)
- [A]ctivity(활동)
- [C]ommunication and collaboration(의사소통과 협업)
- [E]fficiency and flow(효율성과 흐름)
지금까지 정량화된 데이터를 추구해왔던 Metrics 들과는 다르게 정성적인 느낌의 것들이 많이 보입니다.
니콜박사는 이에 대하여 개발자의 생산성은 개발속도나 결과물 만으로는 알 수 없고 플래닝의 실패로 인한 업무과다로 겪는 번아웃, 불규칙적인 업무패턴 등 생산성에 영향을 끼칠 수 있는 다양한 요소들이 더 있다고 말합니다.
뿐만 아니라 개발자 개인의 업무역량이 높더라도 그렇지 않은 팀원과의 협업( 또는 팀) 그리고 비효율적인 문화의 회사에서라면 해당인원의 생산성이 격하될 수 있는 점도 강조합니다.
고로 SPACE Framework 를 적용하면 장기적으로 더 퀄리티 높은 서비스를 만들 수 있고, 서비스를 더 효율적으로 개발할 수 있으며, 더 스마트한 프로젝트 플래닝과 의사결정을 할 수 있고, 개발자들의 업무 만족도를 올려주며, 팀에서의 협업과 성공을 촉진시킬 수 있다고 합니다.
SPACE Framework 는 다음과 같은 경우에 유용합니다
- 개발자 성과를 평가하고 싶은 개발 팀 또는 리더
- 지금 하고있는 성과 측정에 공백이 없는지 확인하려는 팀 또는 리더
- 개발자 성과를 측정하고 개선할 방법을 찾고 있는 팀 또는 리더
- 함께 보며 논의할 수 있는 더 객관적인 측정방법을 찾고 있는 팀 또는 리더
이렇게나 좋다는건 알았으니 이제부터는 이 다섯 가지 요소를 하나씩 순서대로 차근차근 살펴보겠습니다.
SPACE 의 다섯 가지 요소
Satisfaction and Well-Being(만족도와 웰빙)
생산성과 만족도는 높은 상관관계를 가지고 있습니다. 이제는 거의 10년에 걸쳐 DORA 팀에서 발행하고 있는 Accelerate 보고서에도 끊임없이 언급 되었던 설문결과로, 개발자 만족도를 이해하는 것이 생산성을 이해하고 예측하는 데 도움이 된다는 것입니다.
만족도와 웰빙은 개발자가 얼마나 회사에 만족하고 있는지에 대한 측정입니다. 이는 설문조사를 통해 측정할 수 있습니다.
eNPS, 직원 몰입조사 같은 도구들이 널리 쓰이고 있으며 개발자의 직무 만족도, 지금 근무시간이 적합한지, 필요한 도구(ide 등)를 제대로 제공받고 있는지 등의 항목들을 물어볼 수 있습니다. 이런 항목들은 다른매체의 개발자 설문조사 결과(ex: Programmers Dev Survey 2023)들을 참고하면 좋습니다.
만족도와 웰빙 요소는 포괄적인 개발자 만족도 뿐만 아니라 개별적인 항목(ex: 업무 시스템에 대한 만족도)을 측정하는 것에도 유효합니다.
Performance(성능)
짧은 시간안에 많은 양의 코드를 작성하는 것만으로는 높은 성능의 개발자라고 볼 수 없습니다. 깔끔하고 품질 높은 코드를 작성하는 것도 마찬가지이고 설계를 잘하는 것도 그렇습니다. 그럼 대체 뭐가 중요하냐?
중요한 것은 팀, 그리고 회사의 목표에 연관되어있는 방향입니다. 물론 그렇다고 비즈니스 목표와 직접적으로 연관되어 있는 일만 중요한것은 절대 아닙니다. 기존 서비스를 유지하고 보수하는 일을 맡고있는 개발자, 전체 시스템의 안정성을 책임지고 있는 개발자 등 직접적인 서비스를 개발하지 않는 역할또한 절대 없어서는 안되는 역할입니다.
따라서 개발자의 성능이라고 볼 수 있는 것은 예정된대로 개발해내는 신뢰성, 버그를 내지 않는 안정성, 서비스 유지보수를 문제 없이 해내는 것, 고객만족도/유치/리텐션 등의 비즈니스 지표를 상승시키는 기능개발, 비용절감 작업 등이 있지만 이것들을 모두 측정하는 것이 아닌 각자가 맡고있는 역할에 적합한 것들을 선택하여 성능의 지표로 측정해야 합니다.
Activity(활동)
많은 사람들이 성과를 측정 하라고 한다면 곧바로 활동의 결과물을 뒤져보고는 합니다. 물론 활동도 중요한 요소이지만 그만큼 익숙하고 이미 귀가 아프게 중요하다는 말을 들어왔으니 그 대신 활동이 성과의 전부는 아니라는 것을 다시 한번 강조하고 시작하겠습니다.
활동을 측정하는 방법은 “세는 것” 입니다. 넓게 보면 완료된 일의 수량을 손으로 꼽아볼 수 있으며 쪼개보면 코드 라인 수, 푸시한 횟수, 커밋한 횟수, 리뷰를 요청하고 코멘트한 횟수 등이 될 수 있습니다.
Communication and Collaboration(의사소통과 협업)
의사소통과 협업은 얼마나 문서화를 잘 하는지, 필요한 정보를 잘 찾아내는지, 업무협조를 잘 해주는지, 코드리뷰를 잘 해주는지 등 우리가 사람들에게 정보를 어떻게 얻고, 전달 하는지에 관한 요소입니다.
이 요소 또한 설문조사를 통해 측정할 수 있습니다. 물론 만족도와 웰빙과 다르게 당사자를 설문하는 것이 아닌 이 사람과 협업하고 의사소통하는 사람들에게 설문하는 방식으로 측정합니다.
Efficiency and Flow(효율성과 흐름)
효율성과 흐름은 얼마나 일에 집중할 수 있는지에 대한 요소라고 볼 수 있습니다. 그리고 집중과 집중 사이에 끊임이 없는 것에 대해서도 다룹니다.
대부분의 사람들은 멀티태스킹에 능하지 않습니다. 또한 사람이라는 것이 원래 멀티태스킹하지 못하게 설계되어있습니다. IT 업계에서는 이것을 컨텍스트 스위칭이라고들 합니다.
업무를 진행할 때에 얼마나 많은 사람들과 얼마나 자주 일을 주고받아야 하는지(handoff), 그로인해 기다리게 되는 시간은 얼마나 되는지, 그 시간동안 다른 일을 할 경우에 대한 기회비용은 얼마나 되는지 를 측정할 수 있으며 사람과의 관계 뿐만 아니라 시스템에서 빌드 누르고 기다리는시간, 기계학습을 돌리고 기다리는 시간 등의 시스템을 기다리는 시간도 해당될 수 있습니다.
총 다섯가지 요소를 살펴보았고 어떤 지표들을 어떻게 측정해야 하는지도 알았습니다. 또한 이 방법이라면 니콜박사가 강조한 것 처럼 코드를 작성하는 개발자 뿐만이 아니라 Site Reliability Engineer 나 Quality Assurance Engineer 등 기술에 관련된 다른 직무, 그리고 비 기술 직무까지도 폭넓게 활용할 수 있을 것 같은 느낌이 듭니다.
이제는 예시와 함께 SPACE Framework 를 실제로 활용해보겠습니다.
SPACE 실전활용
SPACE Framework 는 업무방식과 지표 등 생소하고 광범위한 다양한 항목들을 동시에 고려해야 하기 때문에 실제로 이것을 활용하는 방법을 이해하는 것이 어려울 수 있습니다.
SPACE 는 측정할 항목이 제공되지 않는 “프레임워크” 입니다. 때문에 먼저 측정할 항목들을 정하고 팀이 말하는 생산성의 의미를 정의해야 합니다. 이것을 위해서 팀원 모두가 함께할 수 있는 화이트 보드와 포스트잇을 활용하면 좋습니다.
먼저 팀에서 생산성이라고 생각하는 항목들을 나열하고 각 영역에 배치합니다.
다섯 가지 요소를 동시에 모두 사용할 필요는 없습니다. 니콜박사는 이 중에서 최소 세가지 이상만 활용하면 된다고 말합니다.
SLA(서비스 수준 협약서)를 잘 지켰는지, 버그 수, DAU, 커밋 수, 완료된 PR, 빌드 횟수, 배포 횟수, 배포된 기능 개수, 티켓 처리량, 집중한시간, 코딩한 시간, 리뷰시간, QA시간
이 팀의 경우 이는 [만족도와 웰빙] 또는 [의사소통과 협업] 에 대한 측정은 생산성에 영향을 끼치지 않는다고 생각하고 있습니다. 과거에 개발자 생산성을 정의할 때에 S 및 C 범주에 대한 중요성이 대두되지 않았기에 자연스러운 일입니다.
- 게임을 출시하기 위해 한달 내내 크런치모드를 돌리면서 출시이후 많은 팀원이 번아웃을 경험하게 만든다면 이 방법은 생산적이라고 볼 수 있을까요?
- 대규모 프로젝트를 성공적으로 완료했지만 기능을 문서화하는데에 시간을 투자하지 않아 유지보수 리소스로 인해 이후의 모든 프로젝트 속도가 느려진다면, 과연 좋은 성과라고 볼 수 있을까요?
이 부분에서 알 수 있는 것은 SPACE 를 도입한다면 지금까지 잘못 측정되고 있던 성과를 바로잡을 수도 있다는 것입니다.
정량적 데이터는 전체 그림을 제공하지 않으므로 전체 그림을 얻으려면 정성적 정보와 결합하는 것이 좋습니다.
그렇게 하면 개발 팀의 생산성을 전반적으로 파악하고 절반의 진실과 부당한 결론의 함정에 빠지는 것을 방지할 수 있습니다. 정량화 가능한 지표 외에도 설문조사, 회의, 1:1 미팅 등을 통해 정성적 데이터를 수집해야 합니다. 이번 활용으로 알게된 부족한 요소들을 보충한 후 각 항목들을 측정할 수단을 마련합니다.
데이터는 최대한 정확해야 합니다. 실제 조직의 성과를 보고 싶다면 정보를 정확하고 일관되게 측정하는 것이 중요합니다. 또한 측정이 늦어질 수록 문제를 파악하고 개선할 수 있는 시기도 늦어집니다.
다행히 위 화이트보드에 있는 정량적인 항목들은 대부분 개발툴에서 가져올 수 있는 데이터들입니다. 개발 생애주기의 다양한 활동에서 자동으로 데이터를 계측하는 프로세스를 만들고 소스 코드, 프로젝트 관리, 사고 관리 도구 등과 같은 여러 데이터 소스를 수집하여 통합하고 시각화합니다.
이 작업을 내부적으로 수행하려면 해당되는 개발자들의 협조를 구하고 도입 뿐만 아니라 유지 및 보수를 위해서도 인하우스 개발 리소스를 지속적으로 들여야 합니다.
마지막으로 측정과 평가 이상으로 중요한 것은 SPACE 프레임워크 도입의 목표가 개발자를 감시하는 것이 아니라 조직 차원에서의 개선을 위한 것임을 팀원들에게 이해시켜 다같이 발전하는 방향을 도모해야 한다는 말로 마무리 짓겠습니다.
워낙 방대한 프레임워크라 그런지 최대한 글을 줄이려고 해도 꽤 긴 글이 나왔습니다 😋
프루퍼(Proofer)팀은 이렇게 적용하기 어려운데 그렇다고 하지 않을 수도 없는 성과측정을 원클릭으로 회사에 적용할 수 있는 서비스를 만들고 있습니다.
프로덕트의 MVP 버전이 완성되었을 때 proofer.tech 를 구독 중이신 분들에게 먼저 사용해볼 수 있도록 제공 해드릴 예정이니 조금만 기다려주세요!
SPACE Framework 분석 및 활용방법 was originally published in 프루퍼 블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.