10월 3일 토요일

AI 도입의 성과를 코드 생성량이 아니라 실제 일의 흐름에서 어떻게 판단해야 할까?

400개가 넘는 기업과 약 20만 명 엔지니어의 관찰은 한 방향의 성공담을 보여주지 않는다. 배포는 잦아졌지만 코드 변경을 운영 환경에 내보내도 된다는 확신은 약 6% 낮아졌고, 평균 변경 묶음은 44줄에서 72줄로 커졌다. 코드를 고치기 쉽다는 평가는 약 4% 좋아졌는데도 품질의 변동성은 더 커졌다. 구현 속도만 끌어올리면 검토와 배포, 복구가 뒤따라오지 못할 수 있다는 뜻이다. 다른 현장 보고는 해법을 코드 이후에서 찾는다. 무엇을 만들지, 어떤 업무 규칙을 지킬지, 실패의 위험이 어디에서 큰지를 사람이 읽고 검토할 수 있는 스펙으로 먼저 남기는 것이다. AI가 코드를 쓰는 시간은 줄어도 요구사항과 도메인을 분명히 하는 일은 사라지지 않는다. 오히려 조직의 중심 업무로 올라온다.

1. 01

   속도 지표만으로는 성공을 판정할 수 없다

   배포 빈도와 처리량은 일이 조직을 통과하는 방향을 보여주지만 고객 가치나 결함을 대신 말해주지는 않는다. 관찰된 조직에서는 체감 전달 속도가 약 4.5% 올랐지만 변경 실패율의 기업별 흔들림도 커졌다. 코드 생성이 전체 가치 흐름에서 차지하는 비중은 약 14~16%에 불과했다. 회의, 맥락 전환, 승인, 리뷰, 온보딩, 운영 대응이 그대로라면 앞단의 가속은 대기열을 뒤로 옮길 뿐이다. 사용량과 활성 이용자 수를 성과로 삼기보다 배포, 실패, 복구, 비용, 실제 업무 결과를 한 화면에서 보아야 한다.

2. 02

   작은 변경과 신뢰가 새로운 생산성 규율이다

   AI는 한 번에 더 많은 코드를 만들게 하지만 큰 변경은 리뷰와 되돌리기를 어렵게 한다. 평균 변경 묶음이 44줄에서 72줄로 커졌다는 수치는 생성량의 이익과 검증 부담이 함께 늘었음을 보여준다. 주니어는 AI를 더 많이 쓰고, 시니어는 더 적은 토큰으로 비슷한 시간 절약을 얻는다는 차이도 있다. 따라서 모든 사람에게 같은 사용량 목표를 주는 대신, 작은 단위로 나누는 능력, 환각과 위험을 가려내는 능력, 변경을 안전하게 운영 환경에 넣는 능력을 함께 길러야 한다.

3. 03

   스펙은 문서가 아니라 사람과 AI의 공동 작업면이다

   스펙 기반 개발에서 스펙은 긴 요구사항 문서 한 장이 아니다. 사용자가 어떤 순서로 일하는지, 정상 흐름과 예외는 무엇인지, 성공 전후 상태가 어떻게 달라지는지, 데이터와 화면과 외부 연결은 어떤 약속을 지켜야 하는지를 함께 묶는다. 이 구조는 비즈니스 담당자에게는 업무 설명이고 AI에게는 실행 가능한 경계가 된다. 기존 시스템도 코드와 테스트를 역으로 읽어 같은 언어로 정리하면 기술 교체가 업무 규칙의 손실로 이어지는 일을 줄일 수 있다.

4. 04

   검토의 양은 실패 비용에 맞춰 다르게 배치한다

   모든 기능에 같은 자동화와 같은 검토를 적용하는 것은 안전하지도 효율적이지도 않다. 조회 기능과 주문 처리처럼 실패 손실이 다른 영역은 사람의 승인, 테스트, 관찰 수준도 달라야 한다. AI가 다룰 업무 경계를 작게 나누고, 공식 도구로 기본 토대를 만든 뒤, 준비된 경계 안에서 기능과 테스트를 생성하게 하는 편이 낫다. 구현이 분 단위로 짧아질수록 팀은 코드를 기다리기보다 무엇을 승인할지, 어떤 위험은 자동화하지 않을지에 시간을 더 써야 한다.

도입의 첫 질문을 ‘얼마나 많이 생성했는가’에서 ‘어느 병목이 줄고 어느 위험이 커졌는가’로 바꾸자. 요구사항과 업무 경계를 검토 가능한 자산으로 만들고, 작은 변경과 품질 지표를 지키며, 위험이 큰 곳에 사람의 판단을 집중해야 한다. 그러면 AI는 개발자를 재촉하는 속도계가 아니라 기획부터 운영까지 막힌 흐름을 드러내고 고치는 도구가 된다.