자동화 도입 제안서 — ROI 계산과 파일럿 범위

개념

제안서는 한 장이다

모듈 11 레슨 5가 자동화 전략을, 레슨 3이 ROI 의 기본 계산식을 다뤘다. 이 레슨은 그 전략을 결재 가능한 문서 한 장 으로 바꾸는 작업이다. 길이 제한이 핵심 제약이다 — 열 장짜리 제안서는 읽히지 않고, 읽히지 않은 제안서는 "검토 중" 으로 끝난다.

문서의 맨 위 세 줄에 결정에 필요한 전부 가 들어가야 한다. "수동 회귀 1회 6시간, 월 4회 = 월 24시간. 핵심 12케이스를 6주간 자동화하면 회귀 1회가 40분으로 줄고 11회차에 회수된다. 승인 요청: 2인 × 3주." 이 세 줄로 결정이 나고, 나머지는 질문이 왔을 때 펼치는 근거다.

비용을 전부 센다 — 작성비는 빙산의 꼭대기다

ROI 계산이 거짓말이 되는 가장 흔한 경로는 수동 실행 비용만 세는 것 이다. 자동화 쪽에도 비용이 있고, 그중 대부분은 작성 이후에 발생한다.

유지보수를 0 으로 잡으면 손익분기가 낙관적으로 왜곡된다(모듈 11 레슨 3). 그래서 실무에서는 보수적인 자리값을 쓴다 — 유지보수는 연간 작성 공수의 일정 비율, 플래키 대응은 유지보수와 별도 항목. 비율의 정답은 없고, 팀마다 실측해 갱신한다. 중요한 것은 0 이 아닌 값을 적고 그 근거를 쓰는 것 이다. 제안서에 "유지보수 월 8시간 (근거: 지난 분기 기존 스위트 실측 평균)" 이 적혀 있으면 숫자를 믿을 수 있다.

손익분기 회차 — 실제 숫자로

가정부터 테이블로 적는다. 가정이 보이지 않는 계산은 검증할 수 없다.

이제 계산한다. 커버하지 못한 2건은 여전히 수동 이므로 절감에서 빼야 한다.

자동화로 대체되는 수동 시간 = 110분 × 83% = 91분
자동화 후 남는 사람 시간    = 25분(확인·트리아지) + 19분(미커버 2건 수동) = 44분
회당 순절감               = 110분 − 44분 = 66분 ≈ 1.1시간
 
월 순절감 = 1.1h × 4회 = 4.4시간
월 운영비 = 유지보수·플래키 10h + 인프라 2h = 12시간
→ 월 순효과 = 4.4 − 12 = −7.6시간 (적자)

이 계산이 이 레슨의 핵심이다. 정직하게 세면 적자가 나오는 경우가 많다. 숫자를 마주한 뒤 선택지는 셋이다.

1. 실행 빈도를 올린다 — 자동화는 "매 PR 실행" 처럼 사람이 못 하는 빈도 에서 값이 난다. 월 4회를 주 5회(월 20회)로 올리면 월 순절감 22시간으로 흑자가 된다.
2. 대상을 바꾼다 — 수동 비용이 큰 케이스, 실패 비용이 큰 케이스로 교체한다.
3. 자동화하지 않는다 — 7번 블록에 쓴다.

여기서 반드시 피할 유혹이 결함 발견 가치를 임의 금액으로 환산해 흑자를 만드는 것 이다. "장애 1건 예방 = 2천만 원" 같은 숫자는 검증 불가능하고, 한 번 들키면 제안서 전체의 신뢰가 사라진다. 정량화할 수 없는 편익은 별도 항목에 정성적으로 적고 손익분기 계산에는 넣지 않는다 — 릴리스 전 확인 시간 단축, 야간·주말 실행 가능, 수동 반복으로 인한 누락 감소처럼.

자기 숫자를 교차 검증한다

제안서를 내기 전에 두 번 되짚는다. 혼자 만든 계산은 거의 항상 한쪽으로 기울어 있다.

역산 검증 — 손익분기 회차를 달 수로 환산해 상식과 맞는지 본다. "11회차에 회수" 가 월 4회 실행이면 약 3개월, 월 1회 실행이면 1년에 가깝다. 후자라면 그 기간 동안 대상 화면이 그대로 남아 있을 확률부터 따져야 한다. 회수 기간이 대상의 수명보다 길면 그 계산은 의미가 없다.

민감도 검증 — 가장 불확실한 값 하나를 2배로 올려 보고 결론이 바뀌는지 본다. 보통 유지보수 시간이 그 값이다. 유지보수를 10시간에서 20시간으로 올렸을 때 흑자가 적자로 뒤집히면, 제안서에 그 사실을 먼저 적는다 — "유지보수가 월 20시간을 넘으면 이 계획은 성립하지 않으며, 그 시점에 중단합니다." 이 문장은 약점 고백이 아니라 중단 조건의 근거이고, 실제로 제안서의 신뢰를 올린다.

두 검증을 합치면 숫자 하나가 아니라 범위와 조건 을 제시하게 된다. 결정권자가 묻는 질문도 "이 숫자 맞아요?" 에서 "실행 빈도를 올릴 수 있나요?" 로 바뀐다 — 후자가 훨씬 생산적인 대화다.

파일럿 범위 — 세 축으로 점수를 낸다

파일럿은 "가장 어려운 것" 도 "가장 쉬운 것" 도 아니다. 반복 빈도 × 안정성 × 실패 비용 이 모두 높은 것을 고른다.

세 점수를 곱한다(더하지 않는다). 하나가 1점이면 전체가 낮아져야 하기 때문이다 — 실패 비용이 커도 다음 달에 개편될 화면은 파일럿 대상이 아니다. 곱으로 상위 10~15건을 추리고, 거기서 제외 조건에 걸리는 것을 뺀다.

제외 조건은 미리 공개한다 — 캡차·OTP 등 우회 수단이 없는 흐름, 외부 연동 스텁이 없는 결제·배송, 다음 분기 UI 개편이 확정된 영역, 시각적 판단이 본질인 검증, 그리고 레슨 4의 요구가 거절돼 제어성이 없는 시나리오. 제외 목록이 제안서에 있으면 "왜 그건 안 했냐" 는 질문이 사후에 오지 않는다.

파일럿 크기의 실무 기준은 4~6주 안에 결론이 나는 분량 이다. 그보다 길면 조직의 관심이 식고, 그보다 짧으면 유지보수 비용이 드러나지 않는다 — 파일럿의 목적 절반은 자기 숫자를 실측으로 교정하는 것 이기 때문이다.

성공·중단 판정 기준을 착수 전에 못 박는다

파일럿이 실패하는 가장 흔한 방식은 끝나지 않는 것 이다. 판정 기준이 없으면 "조금만 더 하면 될 것 같은데" 가 반복되고, 1년 뒤 아무도 안 쓰는 스위트가 남는다.

중단 조건(kill criteria)을 쓰는 것이 승인 확률을 높인다. 결정권자가 두려워하는 것은 비용이 아니라 끝을 알 수 없는 투자 다. "6주 뒤 플래키율이 20%를 넘으면 중단하고 회고만 남깁니다" 는 문장이 리스크를 유한하게 만든다. 그리고 이 기준은 파일럿이 끝난 뒤 확장 제안의 근거가 그대로 된다 — 지표가 이미 정의돼 있으니까.

자동화가 답이 아닌 경우를 제안서에 쓴다

7번 블록은 생략하고 싶어지는 항목이고, 생략하면 안 되는 항목이다.

• 1회성·단기 기능 — 손익분기 회차에 도달하지 못한다
• UI 대규모 개편이 예정된 영역 — 작성한 것을 곧 다시 쓴다
• 탐색적 테스팅이 본질인 영역 — 자동화는 아는 것만 확인한다
• 시각·감성 판단 — 레이아웃 미세 깨짐, 디자인 일관성
• 제어성이 없는 시나리오 — 레슨 4의 요구가 거절된 흐름. 억지로 자동화하면 플래키 생산지가 된다
• 실행 빈도가 낮은 긴 흐름 — 유지보수비가 절감을 넘는다

이것을 쓰면 신뢰를 얻는 이유는 단순하다. 한계를 아는 사람의 숫자는 검증된 것처럼 읽힌다. 모든 것을 자동화하겠다는 제안서는 ROI 표가 아무리 정교해도 "낙관적이겠지" 로 할인되고, "이 여섯 영역은 자동화 대상이 아니며 수동 유지가 합리적" 이라고 적힌 제안서는 나머지 숫자가 액면가로 읽힌다. 덧붙여, 이 목록이 나중에 범위 확대 압력을 막는 방어선 이 된다 — "그건 처음부터 제외 영역으로 합의했다" 고 가리킬 문서가 있다.

실무에서 왜 필요한가

첫째, 자동화는 승인되지 않으면 시작되지 않는다. 기술적으로 완벽한 설계를 들고도 "공수가 없어서" 로 막히는 일이 대부분이다. 제안서는 자동화 역량의 일부이고, 레슨 1~4의 설계가 실행으로 넘어가는 유일한 통로다.

둘째, 정직한 숫자가 길게 간다. 낙관적 ROI 로 승인을 받으면 3개월 뒤 "약속한 절감이 안 나온다" 는 추궁이 온다. 적자가 나오는 계산을 그대로 보여주고 실행 빈도를 올려 흑자로 만드는 설계 를 제시한 제안서는, 숫자가 어긋날 때도 가정 테이블을 함께 고치는 대화가 된다.

셋째, 판정 기준을 미리 정하는 습관이 자동화 부채를 막는다. 중단 조건이 없는 파일럿은 실패해도 종료되지 않고, 아무도 안 보는 빨간 스위트로 남아 다음 자동화 제안까지 막는다.

실습 과제

과제 1 — 우리 조직용 총비용 모델 만들기 (35분)

본문의 비용 항목 표를 가져와 우리 팀의 실제 숫자 로 채운다. 작성 시간은 최근에 쓴 테스트 5개의 실제 소요로, 유지보수와 플래키 대응은 지난 분기 커밋·이슈 이력에서 역산한다. 실측이 불가능한 항목은 추정값을 쓰고 추정임을 표시 한다. 결과물은 재사용 가능한 계산 시트이며, 다음 과제에 그대로 쓴다.

과제 2 — 손익분기 계산과 흑자 전환 설계 (40분)

담당 제품의 회귀 케이스 중 상위 10~15건을 골라 본문 형식으로 손익분기를 계산한다. 커버율을 100%로 잡지 말 것 — 자동화 못 하는 케이스는 수동으로 남겨 절감에서 뺀다. 적자가 나오면 세 선택지(실행 빈도 상향 / 대상 교체 / 하지 않음) 중 하나를 고르고 근거를 적는다. 보고할 것은 적자에서 흑자로 넘어가는 임계 실행 빈도 다.

과제 3 — 한 장 제안서 완성 (40분)

과제 1·2의 결과와 레슨 4의 과제 3(테스트 용이성 제안)을 합쳐 7개 블록을 한 장으로 쓴다. 완성 조건은 둘 — (1) 맨 위 세 줄만 읽고 승인·반대를 결정할 수 있고, (2) 7번 블록에 자동화하지 않을 영역이 셋 이상 적혀 있다. 다 쓴 뒤 자동화에 관심 없는 동료에게 30초만 보여주고 "무엇을 해 달라는 문서인지" 되물어 확인한다.

자가 체크리스트

• 제안서 7개 블록을 외워 말할 수 있고, 맨 위 세 줄에 무엇이 들어가야 하는지 안다
• 작성비 외의 비용 항목을 다섯 개 이상 들 수 있다
• 유지보수·플래키 대응·인프라를 0 이 아닌 값으로 잡고 근거를 적을 수 있다
• 자동화 커버율을 반영해 미커버 케이스의 수동 비용을 절감에서 뺄 수 있다
• 손익분기 계산의 가정을 테이블로 노출해 검증 가능하게 쓸 수 있다
• 결함 발견 가치를 임의 금액으로 환산하면 안 되는 이유를 설명할 수 있다
• 파일럿 후보를 반복 빈도·안정성·실패 비용의 곱 으로 순위 낼 수 있다
• 성공 기준과 중단 조건을 착수 전에 지표·기한까지 정해 본 적이 있다
• 자동화가 답이 아닌 경우를 셋 이상 들고, 그것을 쓰면 신뢰가 오르는 이유를 말할 수 있다

흔한 실수

수동 실행 비용만 센다. 자동화 쪽 비용을 작성비만 넣고 유지보수·플래키·인프라· 트리아지를 빼면 손익분기가 실제보다 몇 배 앞으로 당겨진다. 이 제안서로 승인을 받으면 3개월 뒤에 신뢰를 잃는다.

실행 빈도를 현재 기준으로 고정한다. 자동화의 값은 사람이 못 하는 빈도 에서 나온다. 월 4회 수동 회귀를 월 4회 자동 실행으로 바꾸는 계획은 거의 항상 적자다. 매 PR 스모크처럼 빈도를 바꾸는 설계 가 제안서의 핵심이어야 한다.

커버율을 100%로 가정한다. OTP·외부 연동 때문에 못 하는 케이스는 남는다. 미커버 케이스의 수동 비용을 빼지 않으면 절감이 과대 계상된다.

결함 예방 가치를 금액으로 환산해 흑자를 만든다. 검증 불가능한 숫자가 하나 들어가면 표 전체가 의심받는다. 정성적 편익은 별도 항목에 적는다.

파일럿 후보를 쉬운 것으로 고른다. 로그인 화면만 자동화한 파일럿은 성공해도 아무도 설득하지 못한다. 반복 빈도와 실패 비용이 큰 영역에서 작게 고른다.

성공 기준을 "잘 되면" 으로 둔다. 기한·지표·측정 방법이 없으면 파일럿은 끝나지 않는다. 중단 조건까지 함께 쓰는 쪽이 승인 확률도 높다.

모든 것을 자동화하겠다고 쓴다. 한계가 없는 제안서는 할인돼 읽히고, 나중에 범위 확대 압력을 막을 근거도 남지 않는다.

참고 자료

• ISTQB, Certified Tester Test Automation Engineering (CT-TAE) Syllabus v2.0, 2024 — 자동화 도입 계획과 파일럿 프로젝트, 자동화 배포·전개 절차. 장·절 번호는 판본마다 달라 원문 확인 이 필요하다
• 모듈 11 레슨 3 — 자동화 ROI 의 기본 계산식과 손익분기 개념. 이 레슨은 그 식에 운영 비용을 더해 제안서로 옮긴 것이다
• 모듈 11 레슨 5 — 자동화 전략 문서. 전략이 먼저 있고 제안서가 그 실행 요청이다
• 모듈 14 레슨 4 — 품질 게이트. 파일럿의 "매 PR 실행" 설계가 닿는 자리
• 레슨 2(구축 공수의 근거), 레슨 3(진단 시간 지표), 레슨 4(테스트 용이성 요구를 제안서에 묶기)