코드는 빨라졌는데
작성 속도가 두 배가 됐습니다. PR 수가 늘었습니다.
배포 주기는 그대로였습니다.
코드는 빨라졌는데 배포는 그대로다
개발 조직은 AI 도입이 가장 빠른 곳입니다. 코드 생성 도구는 이미 일상이고, 개인 생산성 향상은 체감됩니다.
그런데 조직 단위 지표를 보면 이상한 일이 생깁니다. 코드를 쓰는 시간은 줄었는데 기능이 배포되기까지의 시간은 그대로입니다.
이게 개발 조직 AX의 핵심 문제이고, 앞선 첫 글에서 다룬 "병목은 옮겨 다닌다"의 가장 선명한 사례입니다.
작성
빨라짐
리뷰
양이 늘어남
테스트
그대로
배포
그대로
병목이 어디로 갔는가
코드 작성이 빨라지면 그 뒤 단계로 부하가 몰립니다.
리뷰
생성된 코드는 양이 많고, 작성자 본인도 완전히 이해하지 못한 상태로 올라오는 경우가 있습니다. 리뷰어의 부담이 늘어납니다.
테스트
커버리지가 없는 코드가 빠르게 늘어나면 회귀 위험이 커집니다.
통합과 배포
원래부터 병목이었다면, 앞단이 빨라져도 전체 리드타임은 안 변합니다.
의사결정
무엇을 만들지 정하는 속도는 그대로입니다.
앞선 업무 지도 글의 원칙이 그대로 적용됩니다. 조각이 아니라 흐름 전체를 봐야 합니다. 코드 생성 속도만 개선하면 개선분이 뒤쪽 대기열에 쌓입니다.
실제로 효과가 나는 지점
개발 조직에서 조직 단위 효과가 확인되는 곳은 코드 생성보다 오히려 주변부입니다.
리뷰 보조
사람 리뷰를 대체하는 게 아니라, 기계적으로 확인 가능한 것(스타일, 명백한 버그 패턴, 누락된 에러 처리)을 먼저 걸러 사람이 설계 문제에 집중하게 만듭니다.
테스트 생성
특히 기존 코드에 커버리지를 붙이는 작업. 사람이 가장 미루는 일이고, 결과 검증이 비교적 쉽습니다.
장애 대응 보조
로그와 변경 이력을 모아 초기 가설을 세우는 일. 앞선 관측 글에서 다룬 실패 로그가 갖춰져 있어야 작동합니다.
레거시 코드 설명
아무도 모르는 코드가 무엇을 하는지 요약. 속인성 해소 효과가 큽니다.
문서화
만들고 나면 아무도 안 쓰는 그 문서.
공통점이 보입니다. 결과 검증이 쉽고, 사람이 미루던 일입니다. 앞선 우선순위 기준 — 자주 일어나고, 틀려도 복구 가능하고, 판단과 반복이 구분되는 — 과 정확히 겹칩니다.
측정을 개인 생산성으로 하지 않기
"개발자가 코드를 30% 빨리 쓴다"는 지표는 조직에 거의 의미가 없습니다. 봐야 할 것은 흐름 지표입니다.
표가 넓으면 좌우로 스크롤하여 확인하세요.
| 지표 | 의미 |
|---|---|
| 리드타임 | 착수부터 배포까지 |
| 배포 빈도 | 실제로 얼마나 자주 나가는가 |
| 변경 실패율 | 배포 후 문제 발생 비율 |
| 복구 시간 | 문제 발생 시 되돌리는 데 걸리는 시간 |
| 리뷰 대기 시간 | 새로 생기는 병목 |
특히 변경 실패율과 복구 시간을 함께 봐야 합니다. 배포가 빨라졌는데 실패율이 올랐다면 그건 개선이 아니라 위험 이전입니다.
이 영역 특유의 함정
리뷰 없이 머지되는 흐름
생성 속도가 올라가면 리뷰가 형식화됩니다. 앞선 90일 측정 글에서 다룬 "승인 거부율이 0에 가까우면 위험 신호"가 여기서도 똑같이 적용됩니다.
아무도 이해 못 하는 코드의 축적
6개월 뒤 수정할 때 비용으로 돌아옵니다. 이해 못 한 코드를 머지하지 않는다는 규칙이 필요합니다.
보안 검토 누락
생성된 코드의 의존성과 권한 처리는 사람이 쓴 코드와 같은 기준으로 검토되어야 합니다.
컨텍스트 비용
대규모 코드베이스에서 모델 호출 비용이 예상보다 빨리 늘어납니다. 앞선 글에서 다룬 "비용 상한"을 여기서도 정해두는 편이 안전합니다.
개발 조직에서 코드 생성은 가장 눈에 띄는 변화지만 가장 작은 변화이기도 합니다.
작성이 빨라지면 리뷰가 밀립니다. 리뷰를 늘리면 사람이 지칩니다. 결국 남는 질문은 "얼마나 빨리 쓰느냐"가 아니라 "얼마나 안전하게 내보내느냐"입니다.
측정을 개인 생산성으로 하면 이 질문이 보이지 않습니다.
