EngThrive: Make It Fast and Easy to Do Great Work
본 논문은 마이크로소프트에서 개발된 다차원 측정 및 개선 시스템인 EngThrive 를 소개하며, 이는 개발자 생산성을 속도, 편의성, 품질을 중심으로 조직화하고 웰빙을 우선시하며, 활동이 아닌 실제 결과와 정렬되도록 메트릭을 조정하기 위해 원격 데이터와 설문 조사를 결합하여 활용합니다.
원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기
거대한 배의 선장이라고 상상해 보세요. 당신의 목표는 배를 가능한 한 빨리 목적지까지 운항하는 것입니다. 수년 동안 당신은 성공을 측정하는 방법으로 선원들이 조타輪을 몇 번 돌렸는지, 또는 몇 통의 물을 퍼냈는지를 세어 왔습니다. 당신은 "더 많은 물을 퍼낼수록 배가 더 빨라진다"고 생각했습니다.
하지만 이상한 점을 발견합니다. 선원들은 미친 듯이 조타輪을 돌리고 물을 퍼내는데, 배는 더 이상 빨라지지 않습니다. 오히려 선원들은 지쳐 있고, 화가 나 있으며, 배를 버리고 떠나려 합니다.
이것이 바로 마이크로소프트의 엔지니어링 리더들이 직면한 문제였습니다. 그들은 개발자들이 실제로 훌륭한 일을 하고 있는지 측정하는 방법으로 '활동'(코드 줄 수나 풀 리퀘스트 등) 을 세는 것은 잘못된 방법임을 깨달았습니다.
이 논문은 소프트웨어 엔지니어링을 공장 조립라인이 아닌 살아있는 생태계로 취급하는 새로운 생산성 측정 방법인 EngThrive를 소개합니다. 이것이 어떻게 작동하는지 간단히 설명해 보겠습니다.
큰 실수: 잘못된 것을 세는 것
이 논문은 오랫동안 기업들이 '코드 줄 수'와 같은 단일 숫자로 생산성을 측정하려 했다고 설명합니다.
- 함정: 작가를 단어 수로 대우하면 그들은 더 많은 돈을 받기 위해 길고 지루한 문장을 쓸 것입니다. 개발자를 코드 줄 수로 대우하면 그들은 숫자를 맞추기 위해 messy 하고 비효율적인 코드를 작성할 것입니다.
- '원격 근무' 역설: 팬데믹 기간 동안 마이크로소프트는 개발자들이 이전보다 20% 더 많은 코드를 제출하는 것을 보았습니다. 옛날 계산법으로는 모두가 슈퍼스타였습니다. 하지만 개발자들에게 "어떻게 느끼시나요?"라고 물었을 때, 78%가 번아웃을 겪고 있다고 답했습니다. 배는 빠르게 움직이고 있었지만, 선원들은 익사하고 있었습니다.
해결책: '속도, 용이성, 품질'의 삼각대
하나의 숫자 대신 EngThrive 는 세 개의 다리가 있는 의자를 사용합니다. 한 다리가 짧으면 의자는 넘어집니다. 똑바로 서 있으려면 세 가지가 모두 필요합니다.
- 속도 (경주): 이것은 단순히 빠르게 타이핑하는 것이 아닙니다. 아이디어에서 고객까지의 시간입니다.
- 비유: 페인트가 도착하는 데 3 주가 걸리거나 관리자가 색상을 계속 변경한다면 차를 얼마나 빠르게 칠하든 중요하지 않습니다. 속도는 아이디어를 가지고 고객이 실제로 사용할 때까지의 총 시간을 측정합니다.
- 용이성 (매끄러운 길): 이는 마찰을 측정합니다.
- 비유: 차를 운전한다고 상상해 보세요. 브레이크가 걸리고 라디오가 고장 나며 빨간불마다 서류를 작성해야 한다면 엔진이 강력하더라도 빠르게 운전하는 것이 아닙니다. '용이성'은 개발자들이 새로운 것을 실제로 만드는 것 대비 도구와 싸우고, 회의를 기다리고, 고장 난 빌드를 수정하는 데 보내는 시간을 측정합니다.
- 품질 (내구성): 이는 작업이 견고한지 여부를 측정합니다.
- 비유: 하루 만에 집을 짓고 (속도) 번거로움 없이 (용이성) 지었지만 비가 올 때마다 지붕이 새는다면 당신은 생산적인 것이 아닙니다. 당신은 단지 나중에 더 많은 작업을 만들어낸 것입니다. 품질은 얼마나 자주 무너지는지와 고치는 데 얼마나 시간이 걸리는지 측정합니다.
안전 장치: '번영 (Thriving)'
'번영 (Thriving)'이라는 네 번째 요소가 있습니다. 이는 극대화해야 할 목표가 아니라 안전 장치입니다.
- 비유: 자동차의 속도계를 생각해 보세요. 가속 페달을 밟아 빠르게 갈 수는 있지만, 엔진에서 연기가 나고 운전자가 고통으로 비명을 지르면 브레이크를 밟아야 합니다.
- 만약 어떤 변화가 팀을 더 빠르게 만들지만 불행하게 만든다면 (번아웃, 나쁜 날), '번영' 지표는 경보를 울립니다. 논문은 불행한 개발자가 생산성이 없다고 말할 가능성이 25 배 높고, 사직할 가능성이 두 배 높다고 밝혔습니다. 선원이 떠나면 빠른 배를 가질 수 없습니다.
측정 방법: '혼합 방법'
EngThrive 는 컴퓨터 로그 (텔레메트리) 만 보거나 사람들의 감정을 묻는 설문조사만 하지 않습니다. 둘을 결합합니다.
- 텔레메트리는 피트니스 트래커와 같습니다. 무엇이 일어났는지 알려줍니다 (예: "회의에 4 시간을 보냈습니다").
- 설문조사는 사람에게 묻는 것과 같습니다: "그게 어떻게 느껴졌나요?" (예: "그 회의들은 쓸모없고 짜증났습니다").
- 함께 그들은 전체 이야기를 알려줍니다: "우리는 회의에 4 시간을 보냈고, 그것은 시간 낭비처럼 느껴졌습니다."
논문 속 실제 사례
이 논문은 마이크로소프트에서 이것이 어떻게 작동했는지 세 가지 이야기를 공유합니다:
- '회의' 수정: 한 팀은 개발자들이 회의에溺하고 있음을 깨달았습니다. 그들은 모두에게 더 많은 '집중 시간'을 주기 위한 목표를 세웠습니다.
- 결과: 개발자들은 주당 2 시간의 추가 집중 시간을 얻었습니다. 그들은 단순히 더 빠르게 일한 것이 아니라, 그들을 괴롭혀 왔던 오래되고 고장 난 코드 (기술 부채) 를 수정했습니다. 결과는 무엇일까요? '나쁜 날'이 줄어들고 실제 산출물이 13% 증가했습니다.
- '게임' 실험: 한 팀은 '첫 번째 풀 리퀘스트까지의 시간'(신입이 코드를 제출하는 속도) 이라는 지표를 속이기 위해 첫날에 작고 쉬운 작업을 주는 방식으로 '치트'를 시도했습니다.
- 결과: 놀랍게도 이것이 작동했습니다! 그들이 지표를 '조작'했음에도 불구하고, 신입들은 더 자신감을 얻고 도구를 더 빨리 배우며 다음 해에 더 많은 코드를 작성하게 되었습니다. 그 '게임'이 올바른 행동을 강제했습니다.
- '건강의 날' 실험: 번아웃 위기 동안 한 팀은 모두에게 계획되지 않은 이틀의 휴가를 주었습니다.
- 결과: 코드 산출물은 이틀 동안 감소했습니다 ('속도'에 나쁜 일). 하지만 번아웃 완화 효과는 몇 달간 지속되었고, 팀은 잃어버린 작업을 단 이주일 만에 모두 따라잡았습니다. '번영' 안전 장치가 없었다면 리더들은 첫날에 '실패'처럼 보였다는 이유로 휴가를 취소했을지도 모릅니다.
AI 는 어떨까요?
이 논문은 AI 가 새로운 망치나 더 빠른 자동차와 같은 또 다른 도구일 뿐이라고 주장합니다.
- AI 가 사람들이 코드를 더 빠르게 작성하게 만들 수 있지만 (활동), EngThrive 는 이렇게 묻습니다: 실제로 제품을 고객에게 더 빨리 전달합니까 (속도)? 일을 덜 짜증나게 합니까 (용이성)? 무너뜨리는 일이 덜 자주 발생합니까 (품질)?
- 이 프레임워크는 사무실 건물, 휴가 정책, 회의 규칙에 적용되는 것처럼 AI 에게도 동일하게 적용됩니다.
결론
단일 숫자로 인간을 측정할 수 없습니다. EngThrive 는 다음과 같은 시스템입니다: "훌륭한 일을 하기를 빠르고, 쉽고, 고품질로 만들고, 그 일을 하는 사람들이 그 과정에서 행복하고 건강하도록 합시다."
이는 기업들을 "얼마나 많은 코드 줄을 작성했나요?"에서 "우리는 얼마나 많은 가치를 창출했으며, 그것을 창출하는 과정은 어떻게 느껴졌나요?"로 이동시킵니다.
연구 분야의 논문에 파묻히고 계신가요?
연구 키워드에 맞는 최신 논문의 일일 다이제스트를 받아보세요 — 기술 요약 포함, 당신의 언어로.