본문으로 건너뛰기
중급20

자동화 ROI 계산하기: 손익분기점 추정하기

자동화 스크립트를 만드는 데 드는 시간과, 그걸로 아끼는 반복 실행 시간을 비교해서 "이 자동화가 언제부터 이득인지" 숫자로 계산하는 법을 익힌다.

  • #자동화ROI
  • #손익분기점
  • #비용계산

개념

ROI(Return on Investment)란

투자한 것 대비 얻는 이득을 뜻한다. 자동화의 맥락에서는, 자동화 스크립트를 만드는 데 드는 비용그 자동화 덕분에 절약되는 반복 수동 테스트 시간을 비교하는 것이다.

기본 계산식

초기 구축 비용 = 자동화 스크립트를 작성하는 데 드는 시간
1회 절감 시간 = 수동으로 테스트하는 데 드는 시간 - 자동화 실행·확인에 드는 시간
손익분기점(횟수) = 초기 구축 비용 / 1회 절감 시간

로그인 흐름을 수동으로 테스트하면 매번 5분이 걸린다. 이걸 자동화하는 데 2시간(120분)이 든다고 하자. 자동화 후에는 결과 확인까지 포함해도 1분이면 충분하다.

1회 절감 시간 = 5분 - 1분 = 4분
손익분기점 = 120분 / 4분 = 30회

즉 이 로그인 테스트를 30번 이상 반복 실행하면 자동화 투자를 회수하고 그 이후부터는 순이익이다. 매 배포마다 한 번씩 돌린다면 30번의 배포, 대략 몇 달 안에 손익분기점을 넘긴다.

유지보수 비용을 빼먹지 않는다

이 계산에서 자주 빠지는 항목이 유지보수 비용이다. UI가 바뀌거나 로직이 바뀔 때마다 자동화 스크립트도 함께 고쳐야 한다.

실질 손익분기점 = (초기 구축 비용 + 예상 유지보수 비용 총합) / 1회 절감 시간

유지보수 비용을 무시하고 계산하면 실제보다 손익분기점을 낙관적으로 추정하게 된다 — 모듈 6(레슨 5)에서 배운 "지표를 정직하게 계산해야 한다"는 원칙이 여기서도 적용된다.

ROI가 낮게 나오는 경우

  • 반복 횟수가 적다: 레슨 2에서 배운 "반복성"이 낮은 테스트는 아무리 절감 시간이 커도 손익분기점을 넘기지 못한다
  • 유지보수 비용이 크다: 기능이 자주 바뀌면(레슨 2의 "안정성" 기준) 매번 스크립트를 다시 고쳐야 해서 실질 비용이 계속 늘어난다
  • 자동화 자체가 복잡하다: 초기 구축 비용이 예상보다 훨씬 크면 손익분기점이 뒤로 밀린다(예: 복잡한 로그인 캡차, 다단계 인증이 있는 흐름)

ROI 계산이 완벽한 답은 아니다

ROI는 어디까지나 투자를 정당화하는 근거를 만드는 도구다. 실제로는 숫자로 딱 떨어지지 않는 가치도 있다 — 예를 들어 자동화된 회귀 테스트가 있으면 릴리스 직전 QA 팀의 심리적 부담이 줄어드는 효과는 계산식에 잘 안 잡힌다. 숫자는 의사결정을 돕는 참고 자료로 쓰되, 그것만으로 모든 걸 결정하지는 않는다.

실무에서 왜 필요한가

"이거 자동화하는 데 시간이 얼마나 걸려요?"라는 질문에 "글쎄요, 해봐야 알아요"라고만 답하면 관리자를 설득하기 어렵다. ROI 계산을 할 수 있는 QA는 "이 테스트는 스프린트마다 반복되니 3개월 안에 투자를 회수합니다"처럼 숫자 근거로 자동화 우선순위를 설득할 수 있다. 이건 모듈 4(레슨 4)에서 배운 일정 산정 능력과도 직결된다.

실습 과제

과제 1 — 손익분기점 계산하기 (10분)

다음 조건으로 손익분기점(반복 횟수)을 계산한다.

  • 수동 테스트 소요 시간: 회당 10분
  • 자동화 구축 시간: 4시간(240분)
  • 자동화 실행·확인 시간: 회당 2분

과제 2 — 유지보수 비용 반영하기 (10분)

과제 1의 조건에, "이 기능은 UI가 자주 바뀌어서 분기마다 자동화 스크립트를 30분씩 수정해야 한다"는 조건을 추가한다면, 1년(4분기) 동안의 실질 손익분기점이 어떻게 달라지는지 다시 계산해본다.

자가 체크리스트

  • 자동화 ROI의 기본 계산식(초기 비용, 절감 시간, 손익분기점)을 설명할 수 있다
  • 유지보수 비용을 빼먹으면 손익분기점이 낙관적으로 왜곡되는 이유를 설명할 수 있다
  • 어떤 상황에서 자동화 ROI가 낮게 나오는지 예시로 설명할 수 있다
  • ROI 계산이 자동화 결정의 유일한 근거가 아니라는 것을 이해한다

흔한 실수

  • 초기 구축 비용만 계산하고 유지보수 비용은 빼먹는다. 실질 손익분기점을 과소평가하게 된다.
  • 반복 횟수를 낙관적으로 과대추정한다. 실제 배포·테스트 주기를 근거로 현실적으로 추정해야 한다.
  • ROI가 낮다고 계산되면 무조건 자동화를 포기한다. 숫자로 안 잡히는 가치(심리적 안정감, 빠른 피드백)도 함께 고려해야 한다.

참고 자료

  • Dorothy Graham & Mark Fewster, Experiences of Test Automation — 자동화 ROI 계산 사례를 다룬 실무서
  • ISTQB CTFL — Test Automation 관련 개념(비용·이득 분석)의 공식 정의