대시보드가 초록불인데 팀은 왜 지치는가
"AI 도구 도입 후 PR이 두 배 늘었습니다." 이 말을 자랑처럼 꺼내는 팀 리드를 만날 때마다 나는 속으로 같은 질문을 한다. 그래서 재작업은 얼마나 늘었나요?
Dev.to에 올라온 'Measuring AI-Assisted Velocity Without Lying to Yourself'는 내가 현장에서 느끼던 불편함을 데이터로 정확히 짚어냈다. AI 도구를 쓰면 처리량(throughput)은 분명히 오른다. 에이전트는 5분 만에 PR을 열고, 사이클 타임은 줄고, 스토리 포인트 완료율은 치솟는다. 문제는 이 숫자들이 '싼 부분'만 측정한다는 것이다. PR을 여는 건 쉽다. 숨겨진 문제를 만들지 않는 코드를 쓰는 게 진짜 작업이다.
throughput과 velocity는 다르다
처리량은 'X개 피처를 출시했다'고 말한다. 속도(velocity)는 'X개를 출시했고, 시스템은 여전히 유지보수 가능하며, 팀은 번아웃 상태가 아니고, 다음 변경이 이번보다 어렵지 않을 것'이라고 말한다. AI 도구가 처리량을 높이는 건 이미 증명됐다. 진짜 질문은 그것이 velocity를 높이는가, 아니면 낮추는가다.
차이는 숨겨진 작업에서 드러난다. AI 생성 코드가 만든 버그를 고치는 데 얼마나 쓰는가. 에이전트가 끝낸 PR이 리뷰 후 대규모 수정을 요구하는 빈도. 테스트는 통과하지만 아키텍처 컨벤션을 위반하는 코드가 얼마나 병합되는가. 이 중 어느 것도 PR 수나 사이클 타임 대시보드에는 나타나지 않는다. 대시보드가 거짓말을 하고 있고, 아무도 진실 탐지기를 설치하지 않은 상태다.
내일 당장 쓸 수 있는 세 가지 메트릭
이론적으로 좋은 메트릭이 아니라, 현장에서 바로 꽂을 수 있는 것들만 고른다.
rework ratio: 코드가 작성된 후 30일 이내에 수정되는 비율을 추적한다. AI 지원 변경과 비AI 변경의 rework ratio를 비교하라. AI 코드의 비율이 유의미하게 높다면, '생산성 향상'은 신기루다. 작업을 쓰기에서 고치기로 옮겼을 뿐이다. 비율이 비슷하거나 낮다면 AI가 실제 레버리지를 추가하고 있는 것이다.
review depth ratio: 변경된 코드 라인당 리뷰 코멘트 수를 추적한다. AI 도입 후 이 숫자가 크게 떨어진다면 코드 품질이 나아진 게 아니라 리뷰가 얕아진 것일 수 있다. 에이전트는 설득력 있는 글을 쓴다. 그럴싸하게 보인다. 리뷰어가 더 강하게 밀어붙여야 한다.
incident attribution: AI 생성 변경이 사후 분석(postmortem)에서 과잉 대표되는지 추적한다. AI 코드가 전체 변경의 50%를 차지하는데 장애의 30%를 유발한다면 신호가 아니다. 반대 패턴이 나타날 때 조사를 시작하라. 에이전트에 더 강한 제약이 필요한지, 리뷰 프로세스에 가드레일이 필요한지, 아니면 에이전트가 코드베이스의 특정 영역을 건드리지 않아야 하는지를 판단하는 근거가 된다.
Goodhart의 법칙은 AI 시대에도 작동한다
조직이 'AI velocity'를 측정하기 시작하면 반드시 대시보드가 보여주는 것을 최적화하려 든다. PR 수를 측정하면 품질 따위는 신경 쓰지 않고 PR을 더 많이 만든다. 사이클 타임을 측정하면 리뷰 따위는 신경 쓰지 않고 빨리 병합한다. Goodhart의 법칙은 AI보다 오래됐다.
게임하기 어려운 메트릭이 답이다. 릴리스 후 평균 수정 시간(MTTR), 90일간 수정 없이 살아남는 코드 비율, 지난 분기 변경으로 인한 장애 수, 대규모 재작업 없이 채택 목표에 도달한 피처 비율. 이 숫자들은 완벽하지 않다. 하지만 시스템을 악화시키면서 수치만 올리려는 유인에 저항한다.
AI 에이전트 사고에서 배우지 못하는 이유
측정 실패는 코드 품질에서 끝나지 않는다. Geeknews에서 다룬 PocketOS AI 에이전트 운영 데이터 파괴 사고를 보자. 온라인 반응의 상당수는 "어떻게 AI에게 운영 DB 관리자 권한을 줄 수 있나"였다. 이 반응이 문제다.
Richard Cook과 David Woods가 말한 'distancing through differencing' — 사고 당사자와 자신의 차이에 집중해 '그 사고는 우리에게는 일어날 수 없다'고 결론 내리는 패턴이다. 그 결론을 내리는 순간 조직의 학습은 멈춘다. PocketOS 사고를 '무책임한 AI 사용'으로 끝내면 진짜 교훈인 '시스템이 API를 통한 무확인 삭제를 허용했다'는 사실을 놓친다. 실제로 Railway는 이후 전체 시스템 안전성을 높이는 변경을 단행했다.
AI 워크플로우 도입 초기에 측정 체계를 갖추지 않으면, 사고가 나도 원인을 파악할 데이터가 없다. "AI 에이전트가 이상한 짓을 했다"는 결론만 남고, 어느 단계에서 가드레일이 필요했는지는 영원히 모른다.
CI/CD 파이프라인은 신뢰가 아니라 검증으로 지킨다
Geeknews가 다룬 CVE-2024-YIKES 사고 보고서(픽션이지만 현실을 날카롭게 해부한다)는 측정 부재가 어떻게 연쇄 실패로 이어지는지 보여주는 교과서다. 핵심 구조는 이렇다: 자격 증명 유출 → 의존성 탈취 → CI 파이프라인 통과 → 420만 대 악성코드 배포. 가장 섬뜩한 대목은 Dependabot이 CI를 통과한 후 PR을 자동 병합했다는 것이다. CI가 통과한 이유는 악성코드가 volkswagen 패키지를 설치해 테스트 환경을 속였기 때문이다.
이게 AI-First 팀에 시사하는 바는 명확하다. AI 생성 코드가 테스트를 통과한다는 사실과 그 코드가 안전하다는 사실은 다른 명제다. CI/CD 파이프라인의 '녹색 불'은 품질 보증이 아니라 최소 기준 통과일 뿐이다. 산출물 서명, 전이 의존성 감사, 파괴적 작업의 이중 승인—이것들이 백로그에 수년간 방치되는 동안 시스템은 공격 표면을 넓히고 있다.
측정 체계 없는 AI 도입은 팀 부채다
세 가지 소스를 엮으면 하나의 서사가 나온다. AI 도구는 처리량을 올린다. 측정하지 않으면 그게 velocity 향상인지 부채 축적인지 알 수 없다. 측정 없이 사고가 나면 시스템의 공통 패턴을 학습하지 못하고 개인 탓으로 끝난다. 학습이 멈춘 팀의 CI/CD 파이프라인은 신뢰로 운영되다가 한 번의 연쇄 실패로 무너진다.
내일 당장 시작할 수 있는 것은 단순하다. 첫째, AI 도입 전 베이스라인 데이터를 먼저 확보하라. 비교할 기준이 없으면 어떤 숫자도 의미가 없다. 둘째, 처리량 대시보드와 품질 대시보드를 분리하라. 하나의 'velocity 점수'로 평균 내는 순간 진실이 숨는다. 셋째, AI 생성 변경을 주니어 엔지니어 코드 수준으로, 아니 그보다 더 비판적으로 리뷰하라. 에이전트는 설득력 있게 보이도록 훈련됐다.
앞으로 이 문제는 더 커진다
AI 에이전트가 더 많은 코드베이스에 더 깊이 들어올수록, 측정하지 않은 팀의 부채는 기하급수적으로 쌓인다. 지금은 PR 수가 두 배 늘어나는 단계다. 다음은 에이전트가 배포 파이프라인에 직접 접근하는 단계다. 그 단계에서 rework ratio도, incident attribution도, review depth도 없는 팀이 마주할 사고는 CVE-2024-YIKES가 픽션으로 풍자한 그것과 크게 다르지 않을 것이다.
"AI가 더 빨라졌나요?"라는 질문을 버려라. "에이전트가 지난 분기보다 재작업을 덜 만들고 있나요?" "빠른 출력에도 리뷰 깊이를 유지하고 있나요?" "출시 후 유지보수 부담이 줄고 있나요?" 이 질문들이 실행 가능한 답을 준다. 나머지는 대시보드가 팀에게 하는 거짓말이다.