생산성 지표가 최고의 엔지니어링 성과를 해치는 이유

대부분의 소프트웨어 생산성 지표는 잘못된 것을 측정하며, 기계가 코드를 작성하기 시작하기 전부터 이미 잘못되었습니다. 커밋 수, 추가된 라인 수, 해결된 티켓 수, 그리고 총 코드 볼륨은 모두 더 많은 결과물을 만드는 것에 보상합니다. 하지만 최고의 엔지니어링 작업은 보통 더 적은 결과물을 만듭니다. 사용하지 않는 모듈을 삭제하고, 복잡하게 얽힌 세 개의 서비스를 하나의 명확한 서비스로 교체하며, 버그를 임시방편으로 해결하는 대신 근본 원인을 수정합니다. 이러한 모든 성공은 볼륨 지표상에서 음수 또는 0으로 기록됩니다. 사람들에게 결과물에 대해 보상하면 결과물을 얻게 되며, 결과물은 발전과 같지 않습니다. 이 글은 어떤 지표가 좋은 작업을 왜곡하는지, 왜 AI 코딩이 이 문제를 더 심화시키는지, 그리고 대신 무엇을 측정해야 하는지에 관한 것입니다.

잘못된 행동에 보상을 주는 지표

가장 흔한 대시보드부터 시작해 봅시다. 추가된 코드 라인 수. 커밋 수. 소모된 스토리 포인트. 주당 해결된 티켓 수. 병합된 풀 리퀘스트. 이들 각각은 가치를 나타내는 대리 지표처럼 보이지만, 조용히 여러분이 원하는 것과 정반대의 행동에 보상을 줍니다.

실제 작업의 한 형태를 생각해 봅시다. 한 엔지니어가 더는 아무도 이해하지 못하는 하위 시스템을 읽는 데 4일을 보낸 후, 600줄을 삭제하고 80줄로 대체합니다. 이제 시스템은 동일한 작업을 수행하고, 장애 지점은 더 적으며, 다음 사람이 읽을 수 있게 되었습니다. 대시보드에는 이것이 -520 라인, 1개의 커밋, 그리고 해결된 기능 티켓이 없는 한 주로 표시됩니다. 모든 양적 지표로 보면, 그 엔지니어는 나쁜 한 주를 보낸 셈입니다. 실제로는 그 분기에 팀의 누군가가 보낼 수 있는 가장 가치 있는 주 중 하나였습니다.

이제 같은 티켓을 받아 기존 더미 위에 새로운 서비스를 급하게 덧붙인 엔지니어를 생각해 봅시다. 2,000줄 추가, 14개의 커밋, 새로운 설정 파일, 새로운 배포 대상. 대시보드는 녹색 불이 켜집니다. 이제 시스템은 추론하기 더 어려워지고 고장 날 수 있는 부분이 더 많아졌지만, 숫자에는 그중 어느 것도 보이지 않습니다. 그리고 보상 구조는 두 접근 방식 중 어느 것이 주목받는지 모든 사람에게 방금 알려주었습니다.

삭제와 단순화가 항상 손해인 이유

삭제는 지표가 거꾸로 작동하는 가장 명확한 사례입니다. 코드를 제거하는 것은 종종 시스템에 할 수 있는 가장 영향력 있는 일입니다. 왜냐하면 삭제하는 모든 코드 라인은 더 이상 버그를 유발하거나, 빌드를 느리게 하거나, 읽는 사람을 혼란스럽게 하거나, 유지보수를 요구할 수 없는 라인이기 때문입니다. 기능을 유지하면서 크기가 줄어드는 코드베이스는 더 건강해지는 것입니다. 하지만 어떤 표준 지표도 삭제를 긍정적인 기여로 평가하지 않습니다. 기껏해야 무시하는 정도입니다. 보통은 아무것도 하지 않은 것보다 일을 덜 한 것으로 평가합니다.

근본 원인 해결도 마찬가지로 손해를 봅니다. 이틀간의 조사 끝에 어려운 버그를 완전히 해결하면 세 줄짜리 변경사항이 나올 수 있습니다. 증상만 가리는 임시방편적인 패치는 50줄의 코드와 3개의 커밋을 만들어낼 수 있으며, 나중에 다시 문제가 발생하면 더 많은 티켓을 생성하게 될 것입니다. 지표는 그 패치를 선호합니다. 미래의 티켓 또한 선호하는데, 이는 다음 달에 해결된 항목이 하나 더 늘어나는 것이기 때문입니다.

'아니오'라고 말하는 것도 손해를 봅니다. 유지보수 부담이 되었을 기능을 만들지 않도록 팀을 설득한 엔지니어는 실질적인 일을 한 것입니다. 그들은 비용 발생을 막았습니다. 하지만 막은 비용은 보이지 않습니다. 당신이 작성하지 않은 2천 줄의 코드, 배포하지 않은 서비스, 결코 받지 않을 온콜 호출에 대한 항목은 없습니다. 지표는 존재하는 것만 볼 수 있으므로, 불필요한 것을 만든 사람이 그것을 막은 사람보다 더 높은 점수를 받습니다.

이 세 가지 기저에 있는 패턴은 동일합니다. 양적 지표는 덧셈만 측정할 수 있지만, 최고의 엔지니어링 상당수는 뺄셈입니다.

굿하트의 법칙이 나머지 피해를 주는 방식

이것이 단순히 부정확한 상태에 머무르지 않고 시간이 지남에 따라 왜 더 나빠지는지를 설명하는 법칙이 있습니다. 척도가 목표가 되면, 그것은 더 이상 좋은 척도가 아니게 됩니다. 사람들은 수동적이지 않습니다. 숫자가 당신의 평가, 보너스, 또는 지위를 결정하는 순간, 당신은 그 숫자를 향해 움직이기 시작하고, 그 숫자는 현실을 설명하는 것을 멈춥니다.

커밋 수 목표는 사람들에게 하나의 변경 사항을 여덟 개의 커밋으로 나누도록 가르칩니다. 추가된 줄 수 문화는 보상이 명확성이 아닌 양에 있기 때문에, 사람들에게 더 많이 작성하여 문제를 해결하도록 가르칩니다. 종료된 티켓 수 목표는 사람들에게 작업을 많은 작은 티켓으로 자르고, 주간 집계를 떨어뜨릴 수 있는 깊이 있는 단일 티켓 문제를 피하도록 가르칩니다. 이 중 어떤 것도 누군가가 부정직할 것을 요구하지 않습니다. 그것은 단지 그들이 인센티브에 반응할 것을 요구할 뿐이며, 모든 사람이 그러합니다.

그래서 양적 지표는 좋은 작업을 포착하는 데 실패할 뿐만이 아닙니다. 그것은 점수를 잘 받는 종류의 작업, 즉 부풀려지고, 과도하게 구축되고, 쉽게 계수되는 종류의 작업을 생산하도록 팀을 적극적으로 훈련시킵니다. 그 지표는 관찰하기로 되어 있던 대상을 저하시킵니다. 결국 대시보드에 최적화된 코드베이스를 갖게 됩니다.

AI 코딩이 양적 지표를 완전히 무너뜨리는 이유

위에서 말한 모든 것은 인간이 모든 라인을 직접 작성했을 때의 이야기입니다. AI 코딩 도우미는 이 똑같이 망가진 지표를 가져와 그나마 남아있던 마지막 의미마저 없애버립니다.

그 이유는 AI가 양(volume)을 거의 공짜로 만들어버리기 때문입니다. 모델은 1분 안에 500줄을 생성할 수 있습니다. 점심시간 전에 커밋 10개 분량의 변경 사항을 만들어낼 수 있습니다. 만약 지표가 추가된 라인 수나 이루어진 커밋 수에 보상을 한다면, 이제 도우미는 스스로 그 지표를 만족시킬 수 있고, 그 옆에 앉은 인간은 거의 생각하지 않고도 3년 전이었다면 영웅적으로 보였을 결과물을 만들어낼 수 있습니다. 결과물은 노력과 분리되었고, 가치와는 훨씬 더 분리되었습니다.

기계가 하지 못하는 일은 무엇이 존재해야 하는지를 결정하는 것입니다. AI 보조 엔지니어링에서 희소한 작업은 바로 판단력입니다. 문제를 올바르게 구성하는 것. 무엇을 만들지 않을지 결정하는 것. 생성된 코드를 비판적으로 읽고 잘못되었거나, 안전하지 않거나, 불필요하게 큰 부분을 버리는 것. 모델이 과도하게 생성한 솔루션을 실제로 시스템에 맞는 버전으로 축소하여 삭제하는 것. 이것들이 바로 AI가 코드베이스를 더 좋게 만들었는지 아니면 단지 더 크게 만들었는지를 결정하는 작업들이며, 이 중 어느 하나도 양으로 나타나지 않습니다. 오히려 이 작업들을 잘 해낼수록 라인 수와 커밋 수는 줄어듭니다. 왜냐하면 생성된 코드에 대한 좋은 리뷰는 대부분 코드를 거부하고 줄이는 것을 의미하기 때문입니다.

따라서 양적 지표는 AI 시대에도 단순히 틀린 상태로 남아있는 것이 아닙니다. 이제 이 지표들은 저렴해진 것에는 보상하고 희소해진 것에는 불이익을 줍니다. 산출물(output)로 측정되는 팀은 AI를 사용해 코드로 스스로를 넘치게 할 것입니다. 성과(outcomes)로 측정되는 팀은 똑같은 AI를 사용하고도 더 적은 양의 코드로 더 많은 일을 해낼 것입니다.

대신 무엇을 측정해야 하는가

해결책은 작업을 생산하는 움직임이 아니라 작업의 결과를 측정하는 것입니다. 결과 지표는 바쁘게 보이는 활동이 아니라 현실이 나아지는 것과 연결되어 있기 때문에 조작하기가 더 어렵습니다.

가장 강력한 신호는 시스템이 작동하는지 그리고 얼마나 빨리 안전하게 변경할 수 있는지에 관한 것입니다. 서비스가 얼마나 안정적인가. 변경 사항이 아이디어에서 프로덕션까지 가는 데 얼마나 걸리는가. 배포가 얼마나 자주 인시던트를 유발하는가. 변경 사항 중 어느 정도의 비율이 되돌려지는가. 무언가 고장 났을 때 복구하는 데 얼마나 걸리는가. 이것들은 시스템의 건전성과 작업 흐름을 설명하며, 커밋을 부풀리는 것으로는 개선할 수 없습니다. 시스템을 진정으로 더 좋게 만들어야 개선할 수 있으며, 이것이 바로 핵심입니다.

그와 함께, 단순화를 명시적으로 가치 있게 여기십시오. 동작을 보존하는 삭제를 일급 기여로 취급하고 리뷰와 승진에서 그렇게 언급하십시오. 출시한 범위뿐만 아니라 거절한 범위도 세십시오. 누군가 부담이 되었을 기능을 막았다면, 그 결정은 출시된 기능과 마찬가지로 가시적이고 공로로 인정받아야 합니다. 보상받는 유일한 동사가 "구축했다"라면, 일어나지 말았어야 할 구축을 포함하여 구축만 하게 될 것입니다.

쉬운 말로 대비하면 다음과 같습니다.

오른쪽의 지표 중 어느 것도 단순히 코드를 더 많이 작성하는 것만으로는 충족될 수 없습니다. 대부분은 코드를 더 적게 작성할 때 개선됩니다. 그것이 바로 여러분이 원하는 속성입니다. 좋은 지표는 삭제, 단순화, 자제가 실제로 그런 것처럼 좋게 보이도록 만들어야 합니다.

메트릭은 스코어보드가 아니라 대화입니다

마지막 요점은 이 모든 것을 어떻게 사용하느냐에 관한 것입니다. 더 나은 메트릭이라도 목표가 되는 순간 독이 되는데, 이는 굿하트의 법칙이 당신이 어떤 숫자를 선택했는지 신경 쓰지 않기 때문입니다. 되돌려진 변경 비율은 위험한 것을 전혀 배포하지 않음으로써 조작될 수 있습니다. 리드 타임은 리뷰를 생략함으로써 조작될 수 있습니다. 급여와 지위를 결정하는 스코어보드가 된 단일 숫자는, 그것이 의미했던 바를 잃을 때까지 최적화될 것입니다.

따라서 메트릭의 올바른 역할은 판단의 끝이 아니라 질문의 시작입니다. 증가하는 인시던트 발생률은 무엇이 바뀌었는지 물어볼 이유이지, 채찍이 아닙니다. 일주일간의 마이너스 라인 수는 무엇이 단순화되었는지 살펴볼 계기이지, 빨간 표시가 아닙니다. 숫자는 어디를 봐야 할지 알려줍니다. 사람이 여전히 들여다봐야 합니다. 그 단계를 건너뛰고 대시보드가 직접 사람들을 평가하게 하면, 양적 메트릭이 항상 만들어냈던, 부풀려지고 과도하게 구축된 대시보드 모양의 작업을 얻게 됩니다. 이제는 당신이 요구하는 모든 양을 기꺼이 제공하는 기계에 의해 그 어느 때보다 빠르게 생성됩니다.

이 모든 것은 하나의 지침으로 요약됩니다. 기계가 양을 거의 무료로 만드는 시대에, 얼마나 많이 만들어졌는지를 측정하는 것을 멈추십시오. 시스템이 더 나아졌는지 측정하고, 시스템을 더 단순하게 만든 작업을 인정하며, 모든 숫자를 쫓아야 할 대상이 아니라 이야기해야 할 대상으로 다루십시오. 더 적게, 제대로 하는 것이 바로 일입니다. 메트릭이 그렇게 말해야 합니다.