AI 코딩 에이전트는 이전 패치의 검사가 아직 실행 중일 때 다음 패치를 끝낼 수 있습니다. 엔지니어링 관리자에게는 곤란한 차이가 생깁니다. 팀이 코드를 더 많이 만들었지만 고객은 아직 아무것도 받지 못한 상태입니다.

Linear의 사례가 유용합니다. 9월 21일자 엔지니어링 설명에서 Mufeez Amjad는 2026년 초 이후 테스트 모음이 거의 네 배가 됐지만, 지속적 통합(CI)을 기다리는 풀 리퀘스트 시간은 6분 이상에서 5분을 조금 넘는 수준으로 줄었다고 밝혔습니다. 테스트당 실행기 시간은 대략 절반이 됐습니다. 이는 서로 다른 개선이며 마지막 수치가 전체 CI 비용이 절반이 됐다는 뜻은 아닙니다. Linear는 에이전트 보조 개발로 검증 부담이 커졌다고 설명하지만, 이 내용은 AI의 생산성 효과를 입증하는 통제 실험이 아닙니다. Linear 엔지니어링 설명.

지속적 통합(Continuous Integration, CI)은 제안된 소프트웨어 변경에 자동 검사를 실행합니다. 그럴듯한 패치와 팀이 수용할 준비가 된 변경 사이에 놓입니다. AI 코딩이 패치 공급을 늘리면 검사 용량은 사업상 문제로 이어집니다. 조직은 유용한 작업을 안전하게 얼마나 받아들일 수 있을까요?

관리자는 신뢰할 수 있는 피드백까지 걸리는 시간, 전체 컴퓨팅 작업량, 출시 변경의 안정성이라는 세 가지 결과를 함께 보이게 해야 한다고 봅니다. 더 빠른 답변도 그 답이 무엇을 입증하는지 팀이 이해할 때만 가치가 있습니다.

대기 시간 단축은 작업량 증가를 동반할 수 있습니다

한 대의 컴퓨터에서 12분이 걸리는 테스트 모음을 생각해 보겠습니다. 이를 네 대의 컴퓨터에 균등하게 나누면 3분 만에 끝날 수 있습니다. 이 가상 예시는 완벽하게 분배된다고 가정하며 다른 요소는 무시합니다. 컴퓨터가 수행하는 작업량은 여전히 총 12분입니다.

이제 각 컴퓨터에 준비 시간이 1분씩 필요하다고 해 보겠습니다. 네 대를 쓰면 4분 만에 끝나지만 실행기 사용량은 16분입니다. 한 대를 쓰면 13분이 걸리고 사용량은 13분입니다. 전체 기계 사용량은 늘면서 대기는 크게 줄어듭니다. 실제 청구액은 실행기 종류, 가격, 과금 규칙에도 달려 있습니다.

대시보드의 초록 막대가 짧아졌다고 축하할 때 이 구분이 중요합니다. 병렬 처리 용량을 늘리는 관리자는 더 빠른 피드백을, 경우에 따라 추가 비용을 들여 사는 것입니다. 실제 병목을 없앤다면 훌륭한 맞교환일 수 있습니다. 하지만 완료된 변경이 검토자를 몇 시간씩 기다린다면 정당화하기 어렵습니다.

분석 단위는 CI 실행 한 번을 넘어야 합니다. 반복 수정, 재실행, 2차 검토를 거친 패치는 개별 실행 중 가장 빨랐던 시간보다 훨씬 많은 작업을 소비할 수 있습니다. 포기한 시도까지 포함해 변경이 승인되기까지 필요한 시도 횟수를 세세요. 그렇지 않으면 효율적으로 보이는 파이프라인이 비싼 개발 과정을 감출 수 있습니다.

대기 시간 1분이 모두 같은 인건비 손실을 뜻하지도 않습니다. 검사가 돌아가는 동안 개발자가 다른 유용한 일을 시작했다면 그 시간을 전부 잃은 것은 아닐 수 있습니다. 잦은 중단과 미완성 작업으로 돌아오는 일은 여전히 부담이 될 수 있습니다. 이를 측정하려면 경과 시간에 급여를 곱하는 대신 팀의 실제 작업 방식을 관찰해야 합니다.

연구가 보여 주는 것은 복합적인 결과입니다

DORA의 2026년 3월 분석은 서로 다른 두 근거를 보고합니다. 2025년 연구에서는 AI 도입이 높을수록 소프트웨어 배포 처리량이 커지는 동시에 불안정성도 증가하는 연관성이 나타났습니다. 별도로 연구진은 2025년 3분기 Google 엔지니어 1,110명이 작성한 자유 응답을 분석했습니다. 엔지니어들은 초안 작성 등에서 도움을 받는 한편 검증 부담도 언급했습니다. 이 내부 질적 연구의 참여자는 DORA의 광범위한 연관성 분석 대상과 같지 않으며, 어느 결과도 AI가 특정 팀의 출시 문제를 일으켰다고 입증하지 않습니다. DORA 분석과 방법론.

범위가 더 좁지만 실험 근거가 강한 연구도 있습니다. METR은 2025년 7월 무작위 연구에서 익숙한 저장소를 다루는 경험 많은 오픈소스 개발자 16명에게 작업 246개를 배정했습니다. 2025년 초 AI 도구 사용을 허용하자 작업 완료에 19% 더 오래 걸렸습니다. 그런데도 참여자들은 AI가 더 빨리 일하도록 도왔다고 믿었습니다. 이 결과는 해당 개발자, 작업, 도구에 관한 것이며 오늘날 이용 가능한 모든 코딩 에이전트의 가치를 결정하지는 않습니다. METR 원 실험.

2026년 2월 METR은 후속 연구에서 현재 생산성 효과를 신뢰성 있게 추정할 수 없었다고 밝혔습니다. 개발자들이 AI 없이 하는 작업을 점점 거부하거나 제출할 작업을 선택했고, 여러 에이전트가 동시에 작동해 시간 측정도 복잡해졌습니다. 연구진은 더 큰 가속이 가능하다고 보면서도 자료가 그 규모를 뒷받침하는 증거는 약하다고 했습니다. 이런 한정을 빼고 과거의 작업 지연 수치만 반복하면 독자를 오도하게 됩니다. METR 후속 연구.

관리자는 실용적인 태도를 취할 근거가 있습니다. 유용한 도구는 유지하되 효과를 조사하고, 낙관이나 회의론을 보편적인 인력 산정 공식으로 바꾸지 않는 것입니다. 한 종류의 작업에서 큰 이익을 얻고 다른 작업에서는 시간을 잃을 수 있습니다. 배포 과정은 그 차이를 드러내야 합니다.

제약 요인마다 별도의 해결책을 두세요

CI 용량을 더 구매하기 전에 첫 패치 제안부터 프로덕션까지 변경 하나를 따라가 보세요. 실제 작업과 대기 시간을 구분하세요. 결정을 지연시키는 검사, 주의가 필요한 검토자, 이후에도 남는 출시 조건을 파악하세요.

간단한 시간 기록만으로도 잘못된 투자를 드러낼 수 있습니다. 검토가 시작되기 전 대부분의 지연이 생긴다면 테스트를 몇 초 줄여도 해결되지 않습니다. 검토자가 필수 검사를 오래 기다린다면 해당 검사를 개선하는 데 직접적인 목적이 있습니다. 배포 뒤 주로 실패가 발생한다면 검증에서 무엇을 놓치는지 살펴야 합니다.

의존성 캐싱은 익숙한 최적화도 측정이 필요한 이유를 보여 줍니다. GitHub 문서에 따르면 캐싱은 새 실행기에서 다시 만드는 데 비용이 큰 파일을 재사용할 수 있습니다. 캐시가 없을 때 작업이 해당 파일을 다시 만들거나 내려받을 수 있어야 한다고도 설명합니다. 따라서 캐시 적중과 실패를 모두 평가해야 합니다. GitHub 의존성 캐싱 문서.

관리자에게 유용한 질문은 피드백의 예측 가능성이 얼마나 높아지는가입니다. 평균이 훌륭해도 가끔 출시를 방해할 만큼 대기가 길 수 있습니다. 분포의 느린 쪽도 추적하고, 정당한 테스트 실패와 다운로드 실패 또는 실행기 부족을 구분하세요. 각각 다른 대응이 필요합니다.

빠르고 신뢰할 수 있는 피드백은 사람과 에이전트 모두에게 실수를 일찍 바로잡을 기회를 줍니다. 이런 공동 기반 시설을 개선하면 AI 없이 작성한 변경을 포함해 여러 개발 작업에 도움이 됩니다. 코딩 도구 선택이 바뀌더라도 관리자가 여기에 투자할 이유가 있습니다.

One large stopwatch beside a task card contrasts with three separate worker trays, each with its own small clock.
AI-generated conceptual illustration by BIG CHANGE. Left: elapsed time waiting for a run. Right: machine work accumulated across its workers. Parallel checks can shorten the wait without reducing total work. Clock positions, sizes and worker counts are schematic, not measured times or a cost ratio.

테스트가 빨라도 실수를 잡아내야 합니다

일부 성능 개선은 테스트가 실행되는 조건을 바꿉니다. 더 빠른 프로세서보다 이런 변화에 더 주의를 기울여야 합니다.

JavaScript 및 TypeScript 테스트 도구인 Vitest는 한 파일의 상태가 다른 파일에 영향을 주지 않도록 기본적으로 테스트 파일을 격리합니다. 문서에는 적합한 테스트에서 선택적으로 격리를 끌 수 있다고 나와 있지만, 변경 가능한 모듈 상태, 수정된 전역값 등 의존성이 있으면 격리를 유지해야 한다고 설명합니다. 준비 시간을 줄이는 설정이 정확성의 경계를 바꿀 수 있습니다. Vitest 격리 지침.

Linear는 공유 상태를 선택적으로 허용하고 정리 작업을 추가했으며, 안전하게 이전할 수 없는 파일은 계속 격리했습니다. 성능 개선은 어떤 테스트가 해당 환경을 안전하게 공유할 수 있는지 판단한 데서 나왔습니다. Linear의 구현 사례.

에이전트가 변경 사항과 테스트를 모두 작성할 때는 별도의 문제가 생깁니다. 연간 구독에만 적용되는 할인 규칙을 가정해 보겠습니다. 에이전트가 이를 월간 요금제에도 잘못 적용한 뒤 자기 해석을 확인하는 테스트를 작성할 수 있습니다. 테스트를 통과해도 그 실수와 일치한다는 사실만 입증됩니다.

검토자는 그 구현 밖의 근거를 확인해야 합니다. 합의된 요구 사항, 의도된 동작의 사례, 실패해야 할 사례입니다. 에이전트에게 테스트를 더 요청하면 도움이 될 수 있지만 테스트 수가 늘었다는 것만으로 잘못 이해한 요구 사항에 이의를 제기했다고 볼 수는 없습니다. 소프트웨어가 무엇을 해야 하는지, 근거가 그 질문에 답하는지는 사람이 판단해야 합니다.

테스트가 무엇을 입증하는지 살피지 않고 개수만 보상하는 팀은 검토자에게 자료를 더 주면서 확신은 낮출 수 있습니다. 관리자는 에이전트가 작업을 끝낸 뒤 설명되지 않는 지연으로 취급하지 말고, 일을 배정할 때 검토 시간을 확보해야 합니다.

고객에게 전달되는 변경을 측정하세요

DORA 배포 지표는 유용한 후속 점검을 제공합니다. 커밋된 코드가 프로덕션에 도달하는 시간, 배포 빈도, 배포 실패 후 복구 시간, 즉각적인 개입이 필요한 배포 비율, 계획되지 않은 사고 관련 재작업 비율이 포함됩니다. 이는 테스트 통과를 넘어선 배포 결과를 설명합니다. DORA 지표 정의.

AI 코딩 워크플로를 조사하는 팀이라면 이런 결과와 함께 간단한 진단 기록을 살펴보겠습니다.

  • 피드백: 느린 실행과 용량 대기를 포함해 필수 검사를 완료하는 데 걸린 시간.
  • 사용량: 승인된 변경에 든 실행기 총 작업량과 반복 시도.
  • 검토: 검토자를 기다린 시간, 요청된 주요 수정, 수정 요청 사유.
  • 고객 영향: 출시된 변경이 의도된 동작을 제공했는지와 수정 작업이 필요했는지.

이 기록으로 특정 워크플로를 조사하세요. 작은 문서 수정과 데이터베이스 이전을 같은 생산성 단위로 취급해서는 안 됩니다. 가능하다면 시간이 지나도 유사한 작업을 비교하고 새 실행기 업체나 바뀐 출시 절차처럼 다른 변화도 기록하세요. AI 도입과 함께 개선이 일어났다고 해서 원인이 입증되는 것은 아닙니다.

관리자는 이제 구체적인 선택을 할 수 있습니다. 충분한 확신을 가지고 유용한 변경이 고객에게 도달하지 못하게 막는 제약에 투자하는 것입니다. 때로는 컴퓨팅 용량 증대가 답일 수 있습니다. 때로는 더 명확한 요구 사항, 나은 테스트, 이미 들어오는 제안을 이해할 숙련된 검토 시간이 필요할 수 있습니다.