AI 코딩 성과 지표를 볼 때 요즘 제일 찝찝한 건 숫자가 좋아 보일수록 더 조심해야 한다는 점이다. 생성된 코드 줄 수, 닫힌 티켓 수, PR 개수, 개발자 만족도만 보면 팀이 빨라진 것처럼 보인다. 근데 막상 운영 로그, 리뷰 대기열, QA 재작업을 보면 다른 그림이 나올 때가 있다.
이번 주 GeekNews에 올라온 AI 보조 코딩에 대해 틀리는 열두 가지 방식을 읽다가 이 불편함이 꽤 정확히 정리돼 있다고 느꼈다. 글의 핵심은 “AI 코딩이 좋다/나쁘다”가 아니다. 우리가 AI 코딩을 평가하는 방식이 너무 쉽게 삐끗한다는 얘기다.
나도 이 얘기가 남 일처럼 느껴지지 않는다. 요즘 팀 단위로 AI 도구를 들여오면 질문이 거의 정해져 있다. “얼마나 빨라졌나?”, “ROI가 나오나?”, “도구 비용을 정당화할 수 있나?” 그런데 정작 이 질문에 답하려고 꺼내는 숫자들이 너무 납작하다.
그래서 이번 글은 도구 추천이 아니다. AI 코딩 성과 지표를 팀에서 어떻게 덜 위험하게 볼지에 대한 정리다. 특히 Gemini CLI 전환과 Antigravity CLI처럼 에이전트형 도구가 터미널과 CI에 더 깊게 들어오는 흐름에서는, “빨라졌다”는 말만으로는 부족하다.
AI 코딩 성과 지표가 흔들리는 이유
줄 수와 티켓 수는 너무 쉽게 속는다
제일 흔한 함정은 줄 수다. AI가 코드를 많이 만들면 생산성이 올라간 것처럼 보인다. 하지만 소프트웨어에서 줄 수는 오래전부터 애매한 지표였다. 2,000줄짜리 복잡한 구현을 200줄로 줄이는 게 더 좋은 일인데, 줄 수만 보면 생산성이 떨어진 것처럼 보인다.
AI 코딩에서는 이 문제가 더 심해진다. 모델은 빠르게 코드를 만든다. 그리고 빠르게 만든 코드는 읽히고, 고쳐지고, 테스트되고, 문서화되고, 나중에 유지보수된다. 이 후행 비용이 지표 밖으로 밀려나면 팀은 “생산성 증가”라는 이름으로 미래의 리뷰 부채를 사는 셈이 된다.
티켓 수나 PR 수 역시 비슷하다. 작은 작업을 많이 닫는 팀이 꼭 더 좋은 팀은 아니다. 특히 AI가 쉬운 작업을 빠르게 처리해주면 티켓 수는 늘 수 있다. 그런데 그 사이 어려운 설계 문제, 장기 품질, 장애 예방 같은 일은 더 뒤로 밀릴 수도 있다.
체감 속도와 실제 완료 시간은 다르게 움직인다
AI 도구를 쓰면 일이 덜 힘들게 느껴질 때가 많다. 빈 파일 앞에서 멈춰 있는 시간이 줄고, 초안이 생기고, 낯선 라이브러리를 읽는 속도가 빨라진다. 이건 분명히 좋다. 나도 이런 부분 때문에 AI 코딩 도구를 계속 쓴다.
문제는 “덜 힘들다”와 “더 빨리 끝났다”가 같은 말은 아니라는 점이다. 초안이 빨리 생기면 기분상 진도가 난 것처럼 느껴진다. 하지만 그 초안을 검증하는 데 더 오래 걸리면 전체 완료 시간은 줄지 않는다. 오히려 리뷰어가 더 오래 붙잡히거나, 테스트가 늦게 깨지거나, 배포 후 디버깅이 늘어날 수 있다.
그래서 팀에서 자기보고식 만족도만 보면 위험하다. 만족도는 필요한 지표지만, 단독으로 쓰면 도구의 심리적 효과와 실제 성과를 섞어버린다. 개발자가 “확실히 편해졌다”고 말하는 것과 회사가 “그래서 릴리스 품질이 좋아졌다”고 말하는 건 다른 층위의 주장이다.
최근 자료들이 같은 방향을 가리킨다
Harness 조사는 보이지 않는 일을 숫자로 끌어냈다
Harness의 2026 State of Engineering Excellence 발표는 꽤 현실적인 데이터를 던졌다. 리더들은 AI 도입 후 생산성과 만족도가 좋아졌다고 말하지만, 동시에 코드 리뷰, 버그 수정, 컨텍스트 전환 같은 보이지 않는 일이 커졌다고 답했다.
내가 여기서 중요하게 본 건 “AI가 무조건 느리다”가 아니다. 더 정확히는 기존 대시보드가 새로 생긴 일을 못 본다는 점이다. PR이 빨리 열리는 건 보이는데, 그 PR을 믿을 수 있을 때까지 사람이 쓴 시간이 잘 안 보인다. 생성 비용은 모델 요금으로 나오지만, 검증 비용은 사람의 집중력으로 빠진다.
이게 누적되면 리더와 개발자의 체감이 갈라진다. 리더는 티켓 흐름을 보고 “빨라졌다”고 느낀다. 개발자는 리뷰 부담과 재작업을 보고 “이상하게 더 바빠졌다”고 느낀다. 둘 다 거짓말을 하는 게 아니다. 서로 다른 계기판을 보고 있을 뿐이다.
DORA는 AI를 증폭기로 본다
DORA의 2026년 AI SDLC 분석도 비슷한 얘기를 한다. AI는 코드 생성, 정보 탐색, 테스트, 문서 작성 같은 여러 작업에서 속도를 올린다. 그런데 그 속도는 검증 부담, 환각, 지식 한계, 기술 부채와 같이 움직인다.
여기서 마음에 남은 표현은 AI가 조직의 상태를 증폭한다는 관점이다. 테스트가 좋고, 내부 플랫폼이 안정적이고, API 경계가 선명한 팀에서는 AI가 꽤 잘 붙는다. 반대로 도구가 흩어져 있고, 문서가 낡았고, 리뷰 기준이 모호한 팀에서는 AI가 빠르게 혼란을 키울 수 있다.
이건 내 경험과도 맞다. AI 도구는 깔끔한 저장소에서 더 똑똑해 보인다. 테스트가 촘촘하고 명령어가 명확하면 에이전트도 덜 헤맨다. 반대로 사람이 봐도 이상한 레포에서는 모델도 이상하게 일한다. 결국 성과 지표는 도구 성능만 보는 게 아니라 팀 시스템의 상태까지 같이 봐야 한다.
METR과 arXiv 연구는 단순한 결론을 막아준다
METR의 2026년 업데이트는 더 조심스럽다. 초반 연구에서는 숙련된 오픈소스 개발자가 익숙한 코드베이스에서 AI를 쓸 때 작업 시간이 늘어난 결과가 나왔고, 이후에는 도구와 사용 방식이 바뀌면서 측정 자체가 더 어려워졌다고 설명한다.
이 대목이 중요하다. AI 코딩 생산성은 고정된 숫자가 아니다. 모델이 바뀌고, 에이전트가 바뀌고, 개발자가 학습하고, 팀이 작업을 AI에 맞게 쪼개면서 계속 변한다. 그래서 작년 연구 하나로 “AI는 느리다”고 단정하는 것도 틀리고, 데모 하나로 “AI는 10배 빠르다”고 외치는 것도 틀리다.
AI 코딩 생산성에 대한 arXiv 메타분석은 전체적으로는 적당한 생산성 개선을 보지만, 효과가 맥락에 크게 의존한다고 정리한다. 또 개발자 관점의 생산성 측정 연구는 단기 속도뿐 아니라 기술 숙련, 업무 소유감, 장기 유지보수 같은 요소를 같이 봐야 한다고 말한다.
팀에서 바로 바꿔야 할 측정 방식
AI 작업과 사람 작업을 분리해서 기록한다
처음부터 완벽한 대시보드를 만들 필요는 없다. 대신 AI가 만든 일과 사람이 검증한 일을 분리해서 기록해야 한다. 한 PR 안에서도 “AI가 초안을 만든 시간”, “사람이 방향을 잡은 시간”, “리뷰에서 되돌아간 시간”, “테스트 실패를 고친 시간”은 다르다.
나는 최소한 이런 필드를 남기는 게 좋다고 본다.
ai_assisted: true
ai_role: draft | refactor | test | review | debug
human_review_minutes: 35
rework_reason: unclear_requirement | missing_context | wrong_api | test_failure | style_mismatch
escaped_defect: false
이 정도만 있어도 대화가 달라진다. “AI를 쓰니 빨라졌나?”가 아니라 “어떤 작업에서 빨라졌고, 어떤 작업에서 검증 비용이 늘었나?”로 질문이 바뀐다. 이 차이가 크다.
검증 시간을 비용으로 올려야 한다
AI 도구 비용을 계산할 때 토큰 요금만 보면 안 된다. 실제로 더 비싼 건 검증 시간일 때가 많다. 시니어가 애매한 diff를 40분 동안 읽고 있다면, 그건 이미 비용이다. 리뷰어가 AI가 만든 테스트의 의미를 다시 해석하고 있다면, 그것도 비용이다.
그래서 팀 대시보드에는 생성량 옆에 검증량이 붙어야 한다. AI PR 비율, AI PR의 리뷰 라운드 수, 평균 리뷰 시간, 테스트 실패율, 배포 후 수정률, 되돌림 비율을 같이 봐야 한다. 이 숫자가 없으면 생성 속도는 너무 쉽게 마케팅 숫자가 된다.
간단히 보면 이런 식이다.
| 지표 | 혼자 보면 위험한 이유 | 같이 봐야 할 것 |
|---|---|---|
| 생성된 코드 줄 수 | 장황한 코드도 증가로 보임 | 삭제된 코드, 복잡도, 리뷰 시간 |
| 닫힌 티켓 수 | 쉬운 작업 쏠림을 숨김 | 작업 난도, 재오픈율 |
| AI PR 비율 | 사용량만 보여줌 | 실패 테스트, 되돌림, 장애 연결 |
| 개발자 만족도 | 체감 편의와 성과를 섞음 | 완료 시간, 품질, 피로도 |
개인 감시 지표로 쓰면 바로 망가진다
이 얘기에서 사람들이 잘 안 보는 지점이 있다. AI 성과 지표는 개인 평가 도구가 되는 순간 거의 망가진다. 개발자가 “AI 사용률”로 평가받는다고 느끼면, 필요한 곳이 아니라 보이는 곳에 AI를 쓰게 된다. 리뷰 시간이 평가에 불리하게 작동하면, 사람들은 덜 꼼꼼하게 본다.
성과 지표는 팀의 시스템을 고치기 위한 것이어야 한다. 어느 작업 유형에서 AI가 잘 먹히는지, 어떤 레포에서 자꾸 실패하는지, 어떤 문서가 부족해서 모델이 헛도는지 찾는 용도여야 한다. 개인을 줄 세우는 순간, 데이터는 현실을 보여주는 게 아니라 사람들의 방어 행동을 보여준다.
그래서 지금은 덜 흥분하고 더 잘 재야 한다
좋은 AI 도입은 속도보다 계측에서 시작한다
AI 코딩 도구는 분명히 유용하다. 나는 이 흐름을 부정할 생각이 없다. 코드 초안, 테스트 뼈대, 낯선 API 읽기, 로그 해석, 마이그레이션 계획 같은 작업에서는 이미 손에서 놓기 어렵다. 특히 에이전트형 도구는 혼자 하기 싫은 반복 작업을 꽤 많이 가져간다.
하지만 팀 단위 도입은 다르다. 개인이 “이거 편하다”고 느끼는 것과 조직이 “품질과 속도가 같이 좋아졌다”고 말하는 건 별개의 증명이다. 전자는 경험이고, 후자는 계측이다.
지금 필요한 건 AI를 덜 쓰자는 얘기가 아니다. 오히려 제대로 쓰려면 더 잘 재야 한다. 생성 속도, 검증 시간, 재작업, 리뷰 부담, 테스트 신뢰도, 배포 안정성을 같은 화면에 올려야 한다. 그래야 AI가 팀을 빠르게 만드는지, 아니면 빠르게 바쁘게 만드는지 구분할 수 있다.
내 기준에서는 이게 2026년 AI 코딩 도입의 가장 현실적인 질문이다. “어떤 도구가 제일 똑똑한가?”도 중요하지만, 더 오래 남는 질문은 이거다. 우리 팀은 그 똑똑함이 만든 비용까지 볼 수 있는가.