칼럼 | 개발자 타임 트래킹이 비생산적인 이유

고등학교 역사 시간에 배운 것처럼, 산업혁명은 기계 중심의 제조 공정을 탄생시켜 생산량을 크게 늘리고 제조 비용을 낮춰 모든 사람의 생활 수준을 높였다. 또한 중산층을 크게 확대하고 기술이 우리의 삶을 개선할 수 있다는 생각을 불러일으키면서 사회 구조의 변화까지 가져왔다.

산업혁명이 가져온 변화 중 하나는 일하는 방식이었다. 규모의 경제라는 개념은 점점 더 큰 규모의 공장으로 이어졌다. 산업화가 진행되면서 우리는 생산성을 쉽게 측정할 수 있다는 것을 깨달았다. 작업자가 치약 튜브의 뚜껑을 조이는 모습을 쉽게 관찰할 수 있었고, 성공적으로 뚜껑을 부착한 횟수를 계산할 수 있었다. ‘더 싸게 더 많이’로 유명한 프랭크 길브레스 같은 효율성 전문가는 공장을 더 효율적으로 운영할 수 있는 방법을 찾아냈다.

>ENIAC 컴퓨터가 미군에 납품된 날, 산업혁명은 끝났고 디지털 시대의 시작을 알렸다고 주장하는 사람들도 있다. 그날 이후 소프트웨어 개발 업계는 소프트웨어 개발을 효과적으로 관리하기 위해 고군분투해 왔다.

그 고민의 근원은 “과거와 같은 방식으로 싸우기(fighting the last war)”에서 비롯됐다. 군대에서 잘 알려진 문제점은 다음 전쟁을 준비할 때 지난 전쟁에 너무 많은 시간을 할애해 과거에는 효과적이었지만 결국에는 효과가 없는 구식 기술과 전략에 의존하는 것이다. 정확도가 높은 소총 개발과 돌격 전술을 비교해 보라. 소프트웨어 개발 업계도 마찬가지다.

이런 경향은 여러 가지 방식으로 증명되고 있다. 우리는 모두 공장에서 호루라기를 불며 공장 입구를 지나가는 사람들이 “시계에 맞춰” 움직이고, 관리자가 면도 크림 캔의 뚜껑이 효율적으로 놓여 있는지 확인하기 위해 바닥을 돌아다니는 모습을 본 적이 있을 것이다. 어느 정도 일리가 있는 말이었다. 작업자는 생산량으로 평가됐고 생산량은 쉽게 측정할 수 있었다. 표준 교대 근무를 위해 조립 라인에 서 있는 노동자의 수는 성공의 좋은 지표가 됐다. 조립 라인에서 더 많은 시간을 보낸다는 것은 더 많은 생산량을 의미했다.

엉덩이로 만드는 소프트웨어 

안타깝게도 우리는 이를 소프트웨어 개발 비즈니스에서 의자에 엉덩이를 붙이고 앉아 있는 시간으로 해석했다. 이런 현상은 가장 최근에는 직원들이 사무실로 돌아오도록 강요하는 회사에서 나타나고 있다. 공장 현장의 노동자처럼 소프트웨어 개발자는 책상에 앉아 키보드를 두드리며 정확히 무엇을 생산해야 할까? 코드? 기능? 

드라이버 공장의 성공 여부는 일정량의 입력이 주어졌을 때 생산할 수 있는 드라이버의 수로 측정된다. 이렇게 보면 소프트웨어 개발자가 생산하는 것을 측정하는 것이 합리적일 것 같았다. 우리는 작성한 코드 라인의 수를 측정하는 것이 얼마나 큰 재앙이었는지 알고 있다. 하지만 소프트웨어 개발자는 정확히 무엇을 생산할까? 우리가 개별 개발자의 생산성을 측정하는 데 어려움을 겪는 이유는 대부분 이 질문에 제대로 답할 수 없기 때문이다.

관리자들은 칸막이로 나눠진 책상에서 무언가 계산할 수 있는 일이 일어나고 있고, 개발자가 더 많은 시간을 그곳에서 보낼수록 생산되는 것이 무엇이든 더 많이 생산될 것이라 생각한 것 같다. 

끔찍한 팬데믹도 한 가지 좋은 점이 있었는데, 바로 이런 구식 관리자들에게 각성을 불러일으킨 것이었다. 때로는 소프트웨어 개발자가 할 수 있는 최선의 방법은 3시간 동안 코드를 쳐다보고 15분 동안 타이핑하는 것일 수도 있다. 또는 1,300줄의 스파게티 코드를 없애고 200줄의 우아하고 우수한 솔루션으로 대체하는 개발자가 있을 수도 있다. 또는 개발자가 ‘올바른 방법’으로 무언가를 구축하는 데 일주일을 소비하는 것이 향후 유지보수 시간을 절약하는 것이기 때문에 시간을 잘 쓴 것일 수도 있다. 

산업화가 남긴 최악의 유산은 아마도 타임 트래킹 개념일 것이다. 관리자는 무언가를 측정하고 싶은 강한 충동을 느끼며, ‘작업에 소요된 시간’은 거부하기 어려운 강력한 반짝이가 된다. 따라서 개발팀은 버그를 수정하거나 개별 작업을 완료하는 데 걸리는 시간을 추적해야 하는 경우가 많다. 그런 다음 이런 시간을 개발자 간에 비교해 생산성을 측정하고 성공을 판단하는 수단을 제공한다. 평균 버그 수정 시간이 짧으면 좋은 것일까? 아니면 나쁜 것일까?

최악의 지표

소프트웨어 개발자의 타임 트래킹은 한마디로 끔찍하다. 똑같은 버그는 없으며, 경험이 부족한 개발자는 쉬운 버그는 빠르게 수정할 수 있지만 일반적으로 더 어려운 문제를 맡게 되는 숙련된 개발자는 더 오래 걸릴 수 있다. 아니면 주니어 개발자가 처리할 수 없는 버그를 배정받았을 수도 있다. 더 나쁜 것은 타임 트래킹이 개발자로 하여금 시스템을 게임화하도록 부추긴다는 점이다. 작업이 얼마나 오래 걸릴지 걱정하는 개발자는 ‘예상’ 시간보다 오래 걸릴 수 있는 작업과 온갖 ‘비생산적인’ 활동을 피하려 할 것이다. 

특정 소프트웨어 작업 단위가 얼마나 오래 걸릴지 또는 얼마나 오래 걸릴지 결정할 방법이 없다는 것을 인정해야 하지 않을까? 하루의 매 순간을 고려해야 하는 것은 시간을 아끼려는 나쁜 인센티브를 만들 뿐이다. 또한 똑똑하고 유능한 개발자가 “한 줄만 바꾸면 될” 어려운 문제를 해결하는 데 “너무 오래 걸린다”는 불안감이나 걱정을 느끼게 만들 수도 있다.

우리는 마요네즈 병에 라벨을 붙이는 데 얼마나 걸리는지 알고 있다. 하지만 사소한 버그를 수정하거나 새로운 기능을 구현하는 데 걸리는 시간은 누구도 정확하게 예측할 수 없다. 시간이 불확실한 작업에 대해 시간을 추적하도록 강요하는 것은 단점은 많고 장점은 없다.

디지털 제품은 물리적 제품이 아니다. 소프트웨어는 이전의 제품과는 전혀 다른 제품이다. 산업혁명 시대에 배운 동일한 기술을 사용해 소프트웨어를 만들고 관리하고 실행할 수 있다고 생각하는 것은 근본적으로 잘못된 생각이다. 다행히도 점점 더 많은 조직이 더 이상 ‘마지막 전쟁’을 준비하지 않고 있으며, 자동차 공장의 조립 라인에서 작동하던 방식이 소프트웨어 개발 현장에서는 작동하지 않는다는 사실을 깨닫고 있다.
[email protected]