AI로 코드는 빨리 짰는데, 배포는 왜 기다려야 할까요?

핵심 요약

• AI로 코드 변경이 늘어나면 테스트 처리 능력이 개발 속도를 제한할 수 있습니다.
• 테스트를 병렬로 실행하면 대기는 줄지만, 비용은 총 실행량과 과금 방식에 따라 달라집니다.
• 캐시와 테스트 분산으로 검증 시간을 줄일 때는 검사가 정확한지도 함께 살펴야 합니다.
• 생산성은 코드를 얼마나 썼는지보다 검증을 마치고 배포할 수 있는 변경이 얼마나 되는지로 봐야 합니다.

AI가 코드를 빠르게 작성해도 배포까지 해야 할 일은 남아 있습니다. 변경 사항이 한꺼번에 몰리면 개발자는 코드를 쓰는 대신 테스트 결과를 기다리게 됩니다. AI 코딩이 얼마나 도움이 되는지 알려면 검증에 걸리는 시간과 인프라 비용도 함께 봐야 합니다.

코드를 만드는 속도와 확인하는 속도는 다릅니다

코드를 수정했다고 바로 사용자에게 전달할 수는 없습니다. 먼저 프로그램이 정상적으로 만들어지는지 확인해야 합니다. 그 과정에서 기존 기능을 망가뜨리지 않았는지도 검사해야 하고요.

이런 검사를 자동으로 실행하는 체계가 CI, 즉 지속적 통합입니다. 코드에 변경 사항이 들어올 때마다 빌드와 테스트 등을 실행해 문제가 없는지 확인하는 자동 검사대라고 보면 됩니다.

코드를 작성하는 시간이 줄었다고 검사 시간까지 저절로 줄지는 않습니다. AI가 몇 초 만에 고친 한 줄이 여러 기능에 영향을 줄 수도 있습니다. 수정한 줄이 적다고 확인할 부분도 적은 것은 아닙니다.

변경 사항이 검사를 처리하는 속도보다 빠르게 들어오면 대기열이 생깁니다. 개발자는 테스트가 실행되는 시간에 시작을 기다리는 시간까지 더해 기다려야 합니다. 테스트 자체는 10분이어도 실행 전 대기가 길면 결과를 확인하는 시점은 그만큼 늦어집니다.

실행기를 늘리면 빨라지지만, 비용 계산은 따로입니다

각각 10분이 걸리는 독립적인 검사 6개가 동시에 들어왔다고 가정해보겠습니다.

검사를 돌리는 실행기가 하나라면 마지막 검사는 60분 뒤에 끝납니다. 실행기가 6개라면 준비 시간 등을 제외하고 모두 10분 만에 끝낼 수 있습니다. 여러 검사를 동시에 돌려 대기 시간을 줄이는 셈입니다.

다만 두 경우 모두 총 실행 시간은 60분으로 같습니다. 검사를 모두 끝내는 데 걸리는 시간과 실행기마다 사용한 시간을 더한 값은 다릅니다. 실행기 수를 늘렸다는 이유만으로 사용 시간에 비례하는 요금이 반드시 6배가 되는 것은 아닙니다.

비용을 더 직접적으로 늘리는 것은 검사 횟수입니다. 같은 자원으로 10분짜리 검사를 하루 20번 돌리면 총 200분을 사용합니다. 60번 돌리면 600분이고요. 실패한 검사를 다시 실행하면 그만큼 사용량도 더 늘어납니다.

실제 청구액은 과금 방식에 따라 달라집니다. 직접 서버를 운영한다면 바쁜 시간에 맞춰 마련해둔 장비를 평소 얼마나 쓰지 않고 두는지도 비용에 영향을 줍니다. 따라서 대기 시간을 줄이는 문제와 총 사용량을 줄이는 문제는 각각 따져봐야 합니다.

테스트를 더 돌리기 전에, 반복 작업부터 살펴봅니다

검증 속도를 높이려면 실행기를 늘리는 것 외에도 할 일이 있습니다. 매번 똑같은 준비 작업을 되풀이하고 있지는 않은지 살펴보는 겁니다.

캐시를 쓰면 이런 반복 작업을 줄일 수 있습니다. 이미 내려받은 의존성이나 다시 쓸 수 있는 빌드 결과를 보관해두는 방식입니다. 다만 재사용 조건을 잘못 정하면 현재 변경을 검사하면서 이전 결과를 쓰는 문제가 생길 수 있습니다. 캐시로 속도를 높이려면 어떤 결과를 다시 써도 되는지 정확히 정해야 합니다.

테스트를 여러 실행기에 나눠 맡길 수도 있습니다. 이때는 테스트를 몇 개씩 배정했는지보다 각각 얼마나 걸리는지가 중요합니다. 오래 걸리는 테스트가 한쪽에 몰리면 다른 실행기가 먼저 끝나도 전체 검증이 끝날 때까지 기다려야 합니다.

변경과 관련된 테스트만 골라 실행하는 방법도 있습니다. 하지만 여러 기능이 함께 쓰는 공통 코드를 바꿨다면 영향을 받는 범위도 넓어집니다. 어떤 테스트를 생략해도 되는지 판단하려면 코드 사이의 의존 관계를 알아야 합니다.

간헐적으로 실패하는 테스트도 살펴봐야 합니다. 같은 코드인데도 실행할 때마다 결과가 달라지는 테스트입니다. 통과할 때까지 다시 돌리는 일이 반복되면 컴퓨팅 자원을 더 쓰게 됩니다. 실패 원인을 확인하는 사람의 시간도 그만큼 들어가고요.

AI의 성과를 보려면 ‘검증을 통과한 변경’을 봐야 합니다

AI가 코드를 얼마나 작성했는지만으로 개발 생산성을 설명하기는 어렵습니다. 코드가 늘어난 만큼 검토하고 테스트할 일도 많아질 수 있기 때문입니다.

팀에서 먼저 확인할 것은 변경 제출부터 검증 완료까지 걸리는 시간입니다. 이 시간을 대기 시간과 실제 실행 시간으로 나누면 어디서 지체되는지 알 수 있습니다. 대기가 길다면 동시에 처리할 수 있는 양이 충분한지 살펴보고, 실행이 길다면 테스트 구성과 반복 작업을 들여다볼 수 있습니다.

비용을 볼 때도 월 청구액과 함께 검증을 통과한 변경당 비용을 살펴볼 만합니다. 변경량이 늘어서 총비용이 커진 것인지, 재실행과 중복 작업이 늘어난 것인지 구분하는 데 도움이 됩니다. 다만 변경마다 크기와 위험도가 다르므로 이 수치 하나만 목표로 삼기는 어렵습니다.

속도를 높인 뒤에는 배포 후 오류나 되돌리기가 늘지 않았는지도 확인해야 합니다. 검사를 줄여 아낀 시간만 계산하면, 나중에 문제를 고치느라 쓴 시간을 놓칠 수 있습니다.

AI로 코드 작성 시간을 줄였다면 그 변경이 검증을 거쳐 배포되기까지 얼마나 걸리는지도 봐야 합니다. 팀에서 시간을 많이 쓰는 곳이 코드 작성인지, 코드가 안전한지 확인하느라 기다리는 과정인지에 따라 다음에 손볼 곳도 달라집니다.