AI 코딩 에이전트는 변경 사항을 만드는 일을 쉽게 하지만, 검토와 테스트, 변경 사항을 받아들일지 결정하는 데 필요한 주의력까지 늘려주지는 않는다. 개발팀이 생산하는 PR 수가 늘어도 병합 시간이 길어질 수 있어, 개발 생산성을 측정하는 방식도 달라져야 한다는 주장이다.
에이전트는 시작을 쉽게 하지만 끝내는 일은 아니다
엔지니어링 리더는 보통 PR 처리량, 주기 시간, 배포 빈도 같은 지표를 본다. 처리량이 늘면서 주기 시간이 악화되면 자동화를 더 해야 한다고 생각하기 쉽다. 하지만 처리량이 늘었다고 해서 전달 속도도 빨라진 것은 아니다. 작업이 얼마나 동시에 진행 중인지가 빠져 있기 때문이다. 리틀의 법칙은 이 지표들의 관계를 다음과 같이 나타낸다.
진행 중인 작업량 = 처리량 × 주기 시간
진행 중인 작업이 처리량보다 빠르게 늘면, 팀은 PR을 훨씬 더 많이 병합하면서도 각각의 PR을 병합하는 데 더 오래 걸릴 수 있다. PR을 병합하는 속도보다 더 빠르게 만들면 대기열은 계속 커진다. 작업을 시작할 때 제동을 걸지 않는다면 주기 시간이 나빠지는 것은 놀라운 일이 아니다. 에이전트는 작업 착수를 저렴하게 만들지만, 검토자에게 하루 중 더 많은 시간을 주지는 않는다.
그동안 구현 역량을 병목으로 여겼지만, 에이전트가 확산되면서 이 전제가 덜 믿을 만해지고 있다. 변경 사항을 만드는 비용은 낮아지는 반면, 변경 사항을 이해하고 결정을 내리며 복잡성을 감당하는 역량은 같은 속도로 늘지 않았다. 과거의 병목을 기준으로 최적화하면 새로운 병목을 악화시킬 수 있다.
생산성 대시보드의 역설
벤치마크를 포함한 생산성 지표는 다른 회사와 수치가 어떻게 다른지는 보여주지만, 그 차이가 해결할 문제인지, 왜 차이가 생겼는지는 알려주지 않는다.
검토가 느린 이유는 승인이 불필요해서일 수도 있고, 비용이 큰 실수를 잡아내고 있기 때문일 수도 있다. 팀이 처리할 수 있는 것보다 많은 일을 시작해 주의가 분산된 것일 수도 있다. 같은 수치라도 필요한 대응은 크게 다를 수 있다.
생산성을 좁은 관점으로 보면 실속 없는 지표를 최적화하기 쉽다. 주기 시간을 줄이려고 모든 검토를 자동화한 뒤, 검토에서 놓친 문제를 다음 주 내내 고칠 수도 있다. 개발자 경험(DX) 지표는 개선되더라도 실제 업무는 더 어려워질 수 있다.
생산성 측정에는 조사와 판단이 필요하다. 이 일을 전부 DX나 대시보드에 맡긴다고 해서 직접 따져봐야 할 일이 사라지는 것은 아니다.
하지 않을 일을 선택하는 것이 중요하다
처리량이 늘고 주기 시간이 길어지는 상황이 감수할 만한 절충일 수도 있다. 더 유용한 변경 사항을 배포하고 있고 대기 시간이 누구에게도 피해를 주지 않는다면, 주기 시간을 꼭 개선해야 할까?
지연이 문제라면 무엇을 없앨 수 있는지 살펴봐야 한다. 위험이 낮은 변경 사항에는 필수 검토를 줄이고, 반복적이고 기계적인 검사는 자동화할 수 있다. 끝낼 수 있는 양보다 더 많은 일을 시작하지 않는 방법도 있다. 어딘가에서는 투입량을 줄여야 한다.
중요한 것은 하지 않을 일을 선택하는 것이다. 새로운 PR은 만드는 비용이 거의 들지 않더라도 주의를 요구한다.
천 가지 일을 할 수 있게 되면, 무엇에 주의를 쏟을지 고르는 일이 업무에서 더 큰 비중을 차지한다. 엔지니어링 리더는 팀이 일을 덜 시작하고 더 많이 끝내며, 어떤 변경 사항이 만들어질 가치가 있는지 신중하게 판단하도록 해야 한다.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요