AI 가속의 역설: 테스트 리드타임을 분해하고 배속 주장을 계산하기

개념

병목이 옮겨갔다 — 이번엔 숫자로

레슨 9는 "이제 어려운 것은 소프트웨어를 만드는 일이 아니라, 그것을 믿어도 된다고 말할 근거를 만드는 일"이라는 문장으로 시작했다. 직관적으로는 맞는 말이다. 그런데 이 문장을 들고 팀장이나 CTO 앞에 서면 곧바로 질문이 돌아온다.

"그래서 얼마나 병목인데요? 사람을 늘리자는 겁니까, 도구를 사자는 겁니까?"

이 레슨은 그 질문에 숫자로 답하는 법을 다룬다. 순서는 셋이다.

1. 업계 조사로 현상을 확인한다 — 그리고 조사 자체를 의심하며 읽는다
2. 우리 팀의 테스트 리드타임을 쪼개 병목이 어디에 있는지 찾는다
3. 벤더가 내미는 "몇 배 빨라진다"는 주장을 계산으로 검증한다

출발점은 2026년 9월에 열린 한 엔터프라이즈 테스트 플랫폼(UiPath Test Cloud) 웨비나다. 발표는 "테스트가 왜 느린가"를 그림 한 장으로 설명하고 "현재 6배, 6개월 뒤 9배, 12개월 뒤 12배"라는 숫자를 제시했다. 이런 발표를 들었을 때 QA가 해야 할 일이 이 레슨의 주제다. 제품 자체는 모듈 24(레슨 3)에서 따로 해부한다.

두 개의 조사 — 빨라졌는데 불안정해졌다

AI 도입과 소프트웨어 전달 성과를 다룬 대표적인 조사 두 개가 같은 방향을 가리킨다.

두 조사를 한 문장으로 줄이면 이렇다. 코드 생산은 사람 속도를 넘어섰는데, 검증은 여전히 사람 속도다. 리뷰 없이 머지되는 PR이 늘었다는 건 검증이 따라가지 못한 만큼을 건너뛰고 있다는 뜻이고, 그 격차가 결함과 인시던트로 새어 나간다.

조사 숫자를 QA 눈으로 읽는다

모듈 18b(레슨 11)에서 지표를 의심하는 법 — 분모를 확인하고, 상관과 인과를 구분하는 것 — 을 배웠다. 업계 보고서도 똑같이 읽는다.

그래서 "AI 때문에 인시던트가 세 배가 됐다"고 말하면 틀린다. 말할 수 있는 것은 "AI 도입이 늘어난 시기에 생산량과 함께 버그·인시던트·리뷰 부담이 늘었고, 방법이 다른 두 조사가 같은 방향을 가리킨다"까지다.

숫자를 인용할 때 그 숫자의 한계를 함께 말하는 것 이 QA의 신뢰를 지킨다. 경영진 보고에서 틀린 숫자 하나가 보고서 전체를 무너뜨린다는 것은 어느 조직에서나 같다.

테스트 라이프사이클 지도 — 대부분이 회색이다

웨비나는 가로축에 라이프사이클 네 단계를, 세로축에 세부 활동을 놓고 누가 하는지 로 칠했다. 회색은 사람, 빨간색은 규칙 기반 자동화다.

            설계                자동화              실행               관리
          ───────────────   ───────────────   ───────────────   ───────────────
사람      요구사항 동기화      자동화 대상 선정     환경 구성           결과 검토
(회색)    테스트 케이스 작성   스크립트 작성        데이터 준비         실패 원인 분석
          우선순위 지정        검토·리팩터링        실행 트리거         커버리지 개선
                                                 케이스 안정화       알림·보고서 작성
 
규칙 기반                                         ▶ 테스트 실행
자동화 (빨강)

전통적인 자동화가 맡아 온 것은 맨 뒤 "실행" 칸 하나 뿐이다. 모듈 11에서 자동화 ROI를 계산할 때 대부분 "실행 시간이 얼마나 줄었나"를 셌던 이유도 여기 있다. 나머지 칸은 여전히 사람 손이고, 칸과 칸 사이에서 기다리는 시간 이 쌓인다.

에이전트가 들어오면 지도가 어떻게 바뀌나

웨비나가 그린 두 번째 그림은 회색 칸의 상당수가 에이전트로 넘어간 모습이다.

오른쪽 열이 핵심이다. 사람은 사라지지 않고 승인·예외 처리·리스크 판단 으로 자리를 옮긴다. 웨비나의 표현을 빌리면 에이전트는 사람을 대체하는 게 아니라 증폭 한다. 모듈 18b(레슨 10)에서 본 "중요한 작업일수록 반자율이 기본값"이라는 원칙과 같은 이야기다.

리드타임을 쪼갠다 — 작업·대기·재작업

"테스트가 느리다"는 말은 측정하기 전에는 의미가 없다. 회귀 사이클 한 번에 걸린 시간을 세 덩어리로 나눈다.

테스트 리드타임 = 작업 시간 + 대기 시간 + 재작업 시간

예를 들어 한 릴리즈의 회귀 사이클이 이랬다고 하자.

릴리즈 회귀 1회 (AS-IS)
  요구사항 변경 확인          3h 작업  +  8h 대기 (기획 답변)
  테스트 케이스 갱신          6h 작업
  자동화 스크립트 수정        8h 작업  +  4h 대기 (코드 리뷰)
  환경·데이터 준비            2h 작업  +  6h 대기 (인프라 요청)
  실행                        3h 작업
  실패 분석·재실행            6h 작업               +  4h 재작업
  리포트                      2h 작업  +  8h 대기 (다음 날 회의)
  ─────────────────────────────────────────────────────────
  합계                       30h 작업  + 26h 대기  +  4h 재작업 = 60h

이 예에서 실행은 60시간 중 3시간, 5% 에 불과하다. 대기는 26시간으로 전체의 43%다. 그런데 팀이 "테스트 속도를 올리자"고 할 때 가장 먼저 손대는 곳은 대개 실행이다. 병렬 실행, 더 빠른 러너, 더 비싼 CI 머신.

대기는 어디서 생기는가

대기 시간에는 이상한 성질이 있다. 아무도 일하지 않는 시간이라 누구의 업무 보고에도 잡히지 않는다. 그래서 직접 찾아야 한다. QA 현장에서 대기가 생기는 곳은 대체로 다섯 가지다.

측정은 생각보다 쉽다. 모듈 22에서 다룬 Jira의 상태 변경 이력, PR의 생성· 승인 시각, CI 실행 로그의 시작·종료 시각을 이어 붙이면 된다. "기억으로 적은 시간"보다 "기록에 남은 시각"을 쓴다. 기억은 대기를 짧게, 작업을 길게 기록하는 경향이 있다.

암달의 법칙 — 일부만 빠르게 하면 전체는 한계가 있다

원래 컴퓨터 구조에서 나온 법칙이지만 모든 흐름에 똑같이 적용된다.

전체 중 비율 p 인 구간만 아무리 빠르게 만들어도
전체 속도 향상은 최대  1 / (1 − p)  배다.

위 60시간 예에 대입해 보자.

실행을 완전히 0초로 만들어도 1.05배다. 실행 시간을 절반으로 줄이는 현실적인 개선이라면 60시간이 58.5시간이 된다 — 2.5% 개선이다.

거꾸로 계산하면 더 선명하다. 6배가 되려면 1 / (1 − p) = 6 을 풀어야 하고, p는 약 0.83이다. 리드타임의 83%를 사실상 없애야 6배가 나온다. 12배라면 약 92%다.

이 계산이 주는 결론은 하나다. 몇 배 단위의 개선은 실행 속도로는 절대 나오지 않는다. 설계·분석·대기를 함께 줄여야만 가능한 숫자다. 벤더가 배속을 말하면 첫 질문은 "어느 구간을 줄였습니까"여야 한다.

웨비나의 6배·9배·12배를 읽는다

웨비나가 제시한 숫자와 그 원천 설명은 이랬다.

측정 정의도 밝혔다. 동일한 회귀 테스트 세트를 한 번 돌려 결과 리포트가 나올 때까지의 총 소요 시간을 AS-IS와 TO-BE로 비교한 값.

좋은 신호가 두 가지 있다. 정의를 공개했다는 점, 그리고 원천 설명이 암달의 법칙과 맞는다는 점이다 — 실행이 아니라 설계·대기를 줄인다고 말하고 있다. 그래도 이 숫자를 우리 조직으로 옮기기 전에 확인할 것이 있다.

□ AS-IS 기준선은 몇 번 측정했나 (한 번인가, 여러 사이클의 평균인가)
□ 테스트 세트 규모와 앱 유형이 우리와 비슷한가 (웹? SAP? 모바일?)
□ 초기 구축·학습 시간이 TO-BE에 포함됐나
□ 유지보수(깨진 테스트 수정) 시간이 포함됐나
□ 사람의 검토·승인 시간이 포함됐나
□ 6개월·12개월 수치는 측정값인가, 로드맵 목표인가

마지막 항목이 특히 중요하다. 발표 맥락상 9배와 12배는 앞으로의 목표 로 읽는 것이 맞다. 목표치를 측정값처럼 옮겨 적는 순간, 보고서는 벤더의 마케팅 자료가 된다.

사례 연구 — "12배면 인력 계획을 다시 짜자"

앞의 조각들을 하나의 흐름으로 이어 보자.

1단계 — 상황. 웨비나를 본 CTO가 QA 리드에게 메시지를 보냈다. "12배면 내년 QA 채용 계획은 다시 봐야겠네요. 검토 부탁합니다."

2단계 — 측정. QA 리드는 지난 세 번의 릴리즈 회귀를 Jira 상태 변경 이력과 CI 로그로 재구성했다. 평균 리드타임은 72시간이었다.

실행            6h   (8%)
실패 분석      10h  (14%)
대기           32h  (44%)   ← 기획 답변 14h, 환경 요청 10h, Go/No-Go 회의 8h
나머지 작업    20h  (28%)
재작업          4h   (6%)

3단계 — 계산. 실행을 0으로 만들면 1/(1−0.08) 로 약 1.09배. 대기를 전부 없애도 1/(1−0.44) 로 약 1.8배. 12배가 되려면 72시간 중 66시간을 없애야 한다.

4단계 — 해석. 그렇다고 도구가 쓸모없다는 결론도 아니다. 대기 32시간 중 환경 요청 10시간과 결정 대기 일부는 오케스트레이션으로 줄일 수 있는 종류다. 실패 분석 10시간은 에이전트 분류로 줄일 여지가 있다. 그 둘을 합리적으로 절반씩 줄이면 약 17시간이 빠진다 — 72시간이 55시간, 약 1.3배 다. 의미 있는 개선이지만 12배와는 거리가 멀다.

5단계 — 보고. 모듈 6에서 배운 대로 결론을 먼저 둔다.

결론: 현재 우리 회귀 리드타임(평균 72h)에서 실행은 8%, 대기는 44%입니다. 실행 자동화만으로는 최대 약 1.1배이고, 에이전트·오케스트레이션을 도입해 분석과 대기를 절반씩 줄이는 현실적 가정에서 약 1.3배입니다.

근거: 최근 3회 릴리즈 기록 재구성(첨부). 웨비나의 12배는 12개월 후 로드맵 목표이며 측정 조건이 우리와 다를 수 있습니다.

요청: 인력 계획 변경 전에, 대기가 가장 긴 두 구간(환경 요청·결정 대기)을 대상으로 한 2주 PoC를 승인해 주십시오. 기준선과 성공 기준은 시작 전에 합의하겠습니다.

이 보고서는 도구 도입을 막지 않는다. 기대치를 현실로 되돌리고, 무엇을 검증할지 정해 주었을 뿐이다. PoC를 어떻게 설계하는지는 모듈 24(레슨 3)에서 다룬다.

이 레슨 다음에 무엇이 오나

리드타임을 쪼개면 병목의 위치가 보이고, 위치에 따라 다음 레슨이 갈린다.

실무에서 왜 필요한가

도입 논의의 출발점이 바뀐다. "AI 도구를 써 보자"는 제안은 흔하다. 하지만 "우리 리드타임의 44%가 대기이고 그중 환경 요청이 가장 크다"로 시작하는 제안은 드물다. 병목의 위치를 숫자로 들고 가면, 무엇을 살지가 아니라 무엇을 풀지 로 대화가 바뀐다.

과대 기대를 막는다. 도구 도입이 실패하는 가장 흔한 경로는 기술이 아니라 기대치다. 데모에서 본 12배를 경영진이 믿고 계획을 세우면, 실제로 1.3배가 나왔을 때 "도입 실패"로 기록된다. 사실은 성공적인 개선인데도 그렇다. 암달의 법칙 계산 한 줄이 이 사고를 미리 막는다.

QA의 발언권이 커진다. 레슨 9에서 "병목이 우리 쪽으로 왔다"고 했다. 병목에 있는 직무는 사라지지 않지만, 병목을 숫자로 설명하지 못하는 직무는 비용으로만 보인다. 대기 시간을 드러내는 일은 QA 혼자의 문제가 아니라 기획·인프라·의사결정 구조의 문제를 보이게 만드는 일이기도 하다.

업계 조사를 무기로 쓰되 과신하지 않는다. DORA와 Faros 같은 조사는 경영진을 설득할 때 강력하다. 동시에 방법의 한계를 함께 말할 수 있어야 한다. 그 균형이 "데이터를 아는 QA"와 "기사를 퍼 나르는 QA"를 가른다.

채용시장에서의 위치

QA 리드·매니저 공고에 "AI 기반 테스트 체계 도입", "릴리즈 리드타임 단축" 같은 문구가 성과 목표로 적히기 시작했다. 면접에서는 이렇게 묻는다.

• "AI로 개발 속도가 빨라졌는데 QA는 어떻게 따라가야 한다고 보나요?"
• "테스트 자동화 도구를 도입하면 얼마나 빨라질지 어떻게 추정하겠습니까?"

좋은 답변은 절차 로 말한다. "먼저 최근 사이클의 리드타임을 작업·대기· 재작업으로 기록에서 재구성하고, 가장 큰 덩어리가 어디인지 봅니다. 도구가 줄일 수 있는 구간의 비율로 암달의 법칙을 적용해 최대 개선 폭을 계산하고, 그 범위 안에서 PoC 성공 기준을 잡습니다." 여기에 DORA 2025의 "AI는 증폭기"라는 결론을 한 줄 곁들이면 업계 흐름까지 아는 사람으로 보인다.

실습 과제

과제 1 — 우리 팀 리드타임 분해 (20분)

최근 회귀 사이클 한 번을 골라 아래 표를 채운다. 기억 대신 기록된 시각 을 쓴다 — 이슈 상태 변경 이력, PR 생성·승인 시각, CI 실행 로그.

다 채웠으면 대기 시간이 작업 시간보다 긴 활동 에 표시한다.

과제 2 — 암달 계산 (10분)

어느 팀의 회귀 리드타임이 80시간이고, 구성은 이렇다.

실행 6h · 실패 분석 10h · 대기 34h · 나머지 작업 26h · 재작업 4h

1. 실행을 0으로 만들면 최대 몇 배인가
2. 실행과 실패 분석을 모두 0으로 만들면 몇 배인가
3. 대기를 절반으로 줄이면 몇 배인가
4. 3배가 되려면 리드타임에서 몇 시간을 없애야 하나

과제 3 — 배속 주장 질문지 (10분)

개념 절의 체크리스트 여섯 항목에 우리 조직에만 해당하는 질문 두 개 를 더해 벤더 미팅용 질문지를 만든다.

과제 4 — CTO에게 보내는 한 문단 (10분)

과제 1(또는 과제 2)의 숫자로 사례 연구의 보고 형식을 채운다. 결론·근거·요청 세 덩어리를 지키고, 조사 수치를 인용한다면 방법의 한계를 한 구절 덧붙인다.

자가 체크리스트

• DORA 2025가 말하는 "AI는 증폭기"의 의미를 처리량·불안정성으로 설명할 수 있다
• Faros 2026 보고서의 핵심 수치 중 세 가지를 조사 방법과 함께 말할 수 있다
• 업계 조사 수치를 인용할 때 상관과 인과를 구분해 한계를 밝힐 수 있다
• 전통적 규칙 기반 자동화가 라이프사이클에서 "실행" 칸만 맡아 왔다는 것을 설명할 수 있다
• 에이전트 도입 후에도 사람에게 남는 세 가지(승인·예외 처리·리스크 판단)를 말할 수 있다
• 테스트 리드타임을 작업·대기·재작업으로 분해할 수 있다
• 대기 시간의 다섯 유형과 각각의 시각 기록이 남는 곳을 말할 수 있다
• 암달의 법칙으로 부분 개선의 최대 배속을 계산할 수 있다
• 목표 배속에서 없애야 할 리드타임 비율을 역산할 수 있다
• 웨비나의 6·9·12배 측정 정의와, 이를 옮기기 전에 확인할 질문을 말할 수 있다
• 로드맵 목표치와 측정값을 구분해 보고할 수 있다

흔한 실수

• 실행 시간부터 줄이려 한다. 가장 눈에 보이고 도구로 사기 쉬운 구간이지만, 대개 리드타임의 한 자릿수 퍼센트다. 먼저 쪼개 보고 가장 큰 덩어리부터 본다.
• 리드타임을 기억으로 적는다. 사람의 기억은 대기를 짧게, 작업을 길게 기록한다. 이슈 이력·PR 시각·CI 로그 같은 기록된 시각을 쓴다.
• 대기를 개인의 게으름으로 해석한다. 기획 답변이 늦은 것은 기획자가 느려서가 아니라 질문이 몰리는 구조 때문일 수 있다. 대기는 구조의 신호로 읽는다.
• 조사 수치를 인과로 인용한다. "AI 때문에 인시던트 3배"는 조사가 말하지 않은 문장이다. 반문 한 번에 보고서의 신뢰가 무너진다.
• 벤더의 로드맵 목표를 측정값처럼 옮긴다. 6개월·12개월 뒤 수치는 약속이지 결과가 아니다. 보고서에는 시점과 성격을 함께 적는다.
• 계산 결과로 도입 자체를 반대한다. 1.3배도 의미 있는 개선이다. 목적은 도입을 막는 것이 아니라 기대치를 맞추고 검증 범위를 정하는 것이다.
• 재작업을 따로 세지 않는다. 재실행과 재오픈은 작업 시간에 섞여 사라진다. 플래키 테스트나 요구사항 변경의 비용이 여기 숨어 있다.

참고 자료

• DORA — 2025 State of AI-assisted Software Development — AI 도입과 처리량·불안정성의 관계
• Faros AI — AI Engineering Report 2026: Ten Takeaways — Acceleration Whiplash의 수치와 조사 방법
• UiPath — The dark testing factory — 개발 속도와 테스트 역량의 격차를 벤더 관점에서 설명한 글
• Amdahl's law (Wikipedia) — 부분 개선의 상한