테스트 자동화의 우선순위는 스크립트로 만들 수 있는지만으로 정하면 안 된다. 가장 먼저 자동화할 대상은 자주 실행되고 실패했을 때 사용자나 사업에 미치는 영향이 크며 기대 결과를 기계가 명확하게 판정할 수 있고 환경과 데이터를 반복해서 재현할 수 있는 검증이다. 여기에 구축·유지보수·실패 분석 비용보다 빠른 피드백의 가치가 커야 한다.
반대로 의미, 사용성, 예외의 맥락을 해석하는 일이 검증의 본질이라면 사람의 판단을 남겨야 한다. 자동화가 규칙 위반이나 화면 차이를 찾아주더라도 그것이 실제 사용자에게 문제인지 사람이 결정해야 한다면 자동화 + 인간 검토가 맞다. 환경과 데이터가 불안정해 자동화 결과 자체를 믿기 어렵다면 중요도가 낮아서가 아니라 아직 자동화할 준비가 되지 않은 상태로 분류해야 한다. ISTQB 역시 자동화 후보를 고를 때 반복 실행 가치, ROI, 반복 가능성, 유지보수성과 자주 사용되는 업무 흐름을 함께 보도록 한다. (istqb.org)
이 글은 어떤 요구사항을 테스트할지, 이번 변경에서 무엇을 회귀 범위에 넣을지, 테스트 결과로 출시할지를 결정하지 않는다. 검증 목적과 대상이 정해진 다음, 그 검증을 자동화할지 사람에게 맡길지를 정하는 방법만 다룬다.
자동화율보다 테스트 포트폴리오를 관리해야 한다
자동화된 테스트도 코드다. 처음 만들 때 비용이 들고 제품과 환경이 바뀌면 수정해야 하며 실패했을 때 제품 결함인지 테스트 코드·데이터·환경 문제인지 분석해야 한다. 자동화는 더 많은 테스트를 빠르고 일관되게 실행하고 피드백을 앞당길 수 있지만 초기 투자와 지속적인 유지보수, 변화에 대한 경직성도 함께 가져온다. (istqb.org)
따라서 자동화 투자 여부는 다음 관계로 보는 편이 낫다.
반복 피드백 가치 + 위험 감소 가치 > 구축 비용 + 환경·데이터 비용 + 유지보수 비용 + 실패 분석 비용
이 식은 모든 항목을 숫자로 환산하라는 뜻이 아니다. 자동화 개수를 늘리는 것보다 어떤 비용과 가치를 빠뜨렸는지 확인하기 위한 장부에 가깝다.
예를 들어 매번 수작업으로 30분이 걸리는 테스트도 한 번만 수행하고 버릴 기능이라면 자동화 가치가 작을 수 있다. 반대로 실행 자체는 드물어도 권한 우회나 데이터 손상처럼 피해가 큰 시나리오는 빈도만으로 뒤로 미뤄서는 안 된다. 위험은 발생 가능성과 발생했을 때의 영향으로 함께 평가해야 하기 때문이다. (istqb.org)
GUI 자동화부터 시작할 이유는 없다
테스트 자동화를 화면 클릭의 재현으로만 생각하면 유지보수 비용이 큰 UI 테스트부터 쌓이기 쉽다. 그러나 자동화는 UI가 없는 시스템, 네트워크 연결, 컴포넌트, API와 통합 지점에도 적용된다. 계약 테스트는 서로 다른 서비스가 합의한 상호작용과 데이터 규칙을 지키는지 확인하는 통합 테스트의 한 형태다. (istqb.org)
자동화 계층은 유행하는 도형에 맞추기보다 같은 위험을 가장 빠르고 안정적으로 관찰할 수 있는 지점에서 고르는 편이 낫다.
- 금액 계산이나 상태 전이 규칙은 컴포넌트 수준에서 직접 확인할 수 있다.
- 인증·권한과 데이터 불변 조건은 API 응답과 저장 상태로 확인할 수 있다.
- 서비스 사이의 호환성은 계약 또는 통합 테스트로 확인할 수 있다.
- 사용자가 실제 화면에서 여러 단계를 거쳐야만 드러나는 위험은 UI 여정으로 남길 수 있다.
- 시각적 차이, 접근성 의미, 사용성은 기계가 수집한 증거와 사람의 판단을 결합할 수 있다.
하나의 사용자 여정을 한 개의 거대한 UI 스크립트로만 검증할 필요도 없다. 계산, 권한, 계약과 데이터 상태는 더 안정적인 지점에서 확인하고 UI에서는 실제 연결과 핵심 행동만 검증하는 식으로 나눌 수 있다.
자동화 우선순위를 정하는 12개 축
아래 표는 ISTQB의 자동화 적합성·비용·환경·오라클 기준과 W3C의 접근성 평가 원칙을 바탕으로 재구성한 IXC Insights의 포트폴리오 프레임이다. 단일 공식 문서가 이 12개 축을 그대로 제시하는 것은 아니며 여러 근거를 한 번의 결정에 사용할 수 있도록 통합한 것이다. (istqb.org)
| 평가 축 | 먼저 물을 질문 | 자동화 쪽으로 기우는 조건 | 혼합·사람·보류 쪽 신호 |
|---|---|---|---|
| Execution Frequency | 이 검증은 어떤 Trigger로 얼마나 반복되는가? | Commit·PR·Build·배포마다 실행하거나 다수 환경·조합에서 반복 | 일회성 검증. 다만 낮은 빈도만으로 고위험 항목을 제외하지 않음 |
| Business / User Risk | 실패하면 사용자와 사업에 어떤 피해가 생기는가? | 권한, 결제, 데이터 손상, 핵심 업무 중단처럼 피해가 큼 | 영향이 작거나 쉽게 발견·복구 가능. 높은 위험도 자체가 자동 오라클을 만들어주지는 않음 |
| Deterministic Oracle | 기대 결과를 규칙·상태·허용 오차로 명확히 판정할 수 있는가? | 값, 상태 전이, 불변 조건, Schema, 응답 코드가 객관적 | “보기 좋다”, “편하다”, “상황에 적절하다”처럼 맥락적 판단이 필요 |
| Environment Stability | 버전·시간·네트워크·외부 의존성을 통제할 수 있는가? | 환경을 재생성하고 Mock·Stub·Test Interface로 의존성을 통제 | 외부 Sandbox가 자주 멈추거나 시간·기기·네트워크를 통제하지 못함 |
| Test Data Cost | 데이터를 생성·격리·초기화하는 데 얼마가 드는가? | Seed와 Reset이 가능하고 독립된 계정·데이터를 반복 생성 | 수동 승인, 유료 외부 데이터, 개인정보, 복구 어려운 공유 상태가 필요 |
| Maintenance Cost | 제품 변경 때 자동화 코드가 얼마나 자주 깨지는가? | 관찰 지점이 안정적이고 공통 동작을 재사용하며 Owner가 명확 | UI·계약·환경이 자주 바뀌고 수정 책임자가 없거나 한 테스트가 너무 많은 구현 세부에 결합 |
| Speed / Feedback Value | 결과가 얼마나 빨리 나와야 다음 행동을 바꿀 수 있는가? | 변경 직후 결과가 나와 병합·수정·추가 조사에 바로 사용 | 결과가 의사결정 이후에 나오거나 실패 원인 분석이 실행보다 오래 걸림 |
| Human Judgment Requirement | 통과 여부에 해석·정책·맥락·상담이 필요한가? | 규칙이 명확하고 예외가 구조화됨 | 실제 사용자 의미, 규제 해석, UX, 복합 예외 판단이 필요 |
| Exploratory Value | 이미 알고 있는 결과를 확인하는가, 새로운 문제를 발견하는가? | 잘 알려진 위험과 반복 가능한 기대 결과를 확인 | 새 기능, 불완전한 요구, 예상하지 못한 상호작용을 발견하는 것이 목적 |
| Accessibility / Visual Judgment | 규칙 위반 탐지와 실제 사용 경험을 구분할 수 있는가? | 기계로 검사 가능한 속성, 대비, 구조 규칙 또는 이미지 차이 탐지 | 대체 텍스트의 의미, 키보드 흐름의 자연스러움, 정보 계층, 실제 사용성 판단 |
| Rare but High-risk Scenario | 드물지만 실패하면 피해가 큰가? | 안정적인 불변 조건·사전 조건·복구 결과를 자동 확인할 수 있음 | 조직 협업, 복구 판단, 비상 의사소통처럼 훈련과 사람의 결정이 핵심 |
| Flakiness Risk | 같은 조건에서 같은 결과가 나오는가? | 반복 결과가 안정적이고 실패를 재현·진단할 수 있음 | Race Condition, 공유 데이터, 네트워크, 시간 의존성으로 결과가 흔들림 |
어느 한 축이 자동화 여부를 결정하지는 않는다. 특히 높은 사업 위험은 테스트 우선순위를 높이지만 판정 가능성과 환경 안정성이 부족하면 완전 자동화보다 혼합 검증이나 테스트 가능성 개선이 먼저일 수 있다.
가치·신뢰·책임의 세 Gate로 분류한다
12개 축을 모두 정밀 채점할 필요는 없다. 실무에서는 세 개의 Gate를 순서대로 통과시키면 된다.
Gate 1. 반복할 가치가 있는가
실행 빈도, 사용자·사업 위험, 빠른 피드백의 가치를 본다.
반복 횟수가 많거나 변경 직후 결과가 필요하다면 자동화의 가치가 커진다. 낮은 빈도라도 피해가 크면 다음 Gate로 넘긴다. 빈도 하나로 제외하지 않는다.
Gate 2. 결과를 믿을 수 있는가
자동 오라클, 환경 안정성, 테스트 데이터와 Flakiness를 확인한다.
기계가 판정할 기대 결과가 없거나, 같은 조건에서 결과가 계속 달라진다면 실행 속도가 빨라도 유용한 신호가 아니다. 먼저 요구·오라클·환경·데이터를 개선하거나 별도 격리해야 한다.
Gate 3. 누가 유지하고 해석할 것인가
구축·유지보수 비용과 인간 판단·탐색 가치를 비교한다.
검증의 주된 가치가 의미 해석이나 새로운 문제 발견에 있다면 사람 중심으로 둔다. 반복 준비와 증거 수집은 기계에 맡기되 결론은 사람이 내릴 수 있다.
세 Gate의 결과는 다음처럼 연결된다.
- 가치가 높고 신뢰할 수 있으며 인간 판단 필요성이 낮다 → 자동화 우선
- 가치가 높지만 판정 일부에 사람의 해석이 필요하다 → 자동화 + 인간 검토
- 탐색·사용성·맥락 판단 자체가 검증의 핵심이다 → 사람 중심
- 가치가 있더라도 현재 환경·데이터·유지보수·Flakiness 때문에 신뢰할 수 없다 → 현재 자동화하지 않음
Test Portfolio Matrix
| 포트폴리오 | 들어가는 조건 | 실행 방식 | 대표 예시 | 다음 관리 행동 |
|---|---|---|---|---|
| 자동화 우선 | 반복 가치와 위험이 높고 오라클·환경·데이터가 안정적이며 유지보수 가능 | Pipeline 또는 예약 실행 후 기계가 직접 PASS·FAIL 판정 | 계산·상태 전이 Unit Test, API 인증·권한, 데이터 불변 조건, 계약 호환성, 통제된 통합 시나리오, 기계 측정 가능한 성능 조건 | 빠른 실행 유지, Owner 지정, 실패 원인과 유지보수 시간 추적 |
| 자동화 + 인간 검토 | 증거 일부는 기계가 수집할 수 있지만 의미·맥락·예외 판단이 남음 | 자동 실행·분석·Diff 후 사람이 결과와 잔여 위험 검토 | 핵심 사용자 여정, 접근성 자동 점검과 수동 사용성 평가, 시각 회귀 Diff와 디자인 검토, 복구 시뮬레이션과 사람 중심 훈련 | 기계 판정과 인간 판정의 경계를 명시하고 검토 기록 보존 |
| 사람 중심 | 탐색, 학습, 사용성, 정책·업무 맥락이 검증의 본질 | Charter·Timebox·기록을 갖춘 탐색 및 전문가 검토 | 새 기능 탐색, 모호한 요구의 Edge Case, 사용자 수용, 정성적 UX, 복합 업무 예외, 실제 사용자 관찰 | 자유 검증으로 방치하지 말고 목적·범위·발견·후속 테스트를 기록 |
| 현재 자동화하지 않음 | 오라클·환경·데이터가 준비되지 않았거나 유지보수·실패 분석 비용이 반복 가치보다 큼 | 수동 보완 통제와 Testability Backlog 유지 | 불안정한 외부 Sandbox, 매번 수동 승인이 필요한 데이터, 초기화할 수 없는 공유 상태, 원인 미확인 Flaky test, 곧 폐기될 임시 흐름 | 왜 지금 안 하는지와 재검토 조건을 기록하고 환경·데이터·관찰성 개선 |
사람 중심과 현재 자동화하지 않음은 다르다.
사람 중심 테스트는 사람의 관찰과 해석이 품질을 만든다. 탐색적 테스트, 사용성 검토, 모호한 기대의 확인이 여기에 해당한다. 이를 자동화 실패로 보아서는 안 된다.
현재 자동화하지 않는 테스트는 결과가 객관적일 수 있지만 지금은 환경·데이터·유지보수 구조가 준비되지 않은 상태다. 테스트 가능성을 개선하면 나중에 다른 포트폴리오로 이동할 수 있다.
계층별로 보면 같은 테스트 유형도 분류가 달라진다
| 검증 대상 | 기본 포트폴리오 | 판단 근거 |
|---|---|---|
| 가격·세금·포인트 계산 규칙 | 자동화 우선 | 입력과 결과가 결정적이며 컴포넌트 수준에서 빠르게 반복 가능 |
| API 인증·권한 | 자동화 우선 | 사용자 역할별 기대 응답과 데이터 접근 조건을 객관적으로 판정 가능 |
| API·이벤트 계약 | 자동화 우선 | Schema뿐 아니라 허용된 요청·응답 상호작용을 반복 확인 가능 |
| 주문 생성·재시도·중복 방지 통합 흐름 | 조건부 자동화 우선 | 상태 초기화와 외부 의존성을 통제할 수 있을 때 가치가 큼 |
| 로그인부터 결제 완료까지의 핵심 UI 여정 | 자동화 + 인간 검토 | 핵심 연결은 반복 확인하되 사용성·예외 탐색은 별도 사람 검토 필요 |
| 화면 배치와 디자인 일관성 | 자동화 + 인간 검토 | Diff는 기계가 찾지만 변경이 결함인지 의도인지 사람에게 남음 |
| 접근성 적합성 | 자동화 + 인간 검토 | 자동 규칙 검사는 일부 장벽을 찾지만 전체 접근성과 사용자 경험은 결정하지 못함 |
| 요구가 불명확한 신규 기능 | 사람 중심 | 무엇을 확인해야 하는지 학습하고 새로운 위험을 찾는 단계 |
| 재해복구·Failover | 자동화 + 인간 검토 | 상태·복구 결과는 자동 확인하되 판단·역할·의사소통은 훈련으로 검증 |
| 외부 기관 승인과 비정상적으로 불안정한 Sandbox | 현재 자동화하지 않음 | 자동 실행보다 환경 대기와 오탐 분석 비용이 커질 수 있음 |
| 같은 조건에서 결과가 흔들리는 UI·네트워크 테스트 | 현재 자동화하지 않음 | 원인 분석 전에는 신뢰할 수 있는 품질 신호가 아님 |
이 표의 분류는 테스트 유형에 영구적으로 붙는 라벨이 아니다. 같은 API 테스트라도 공유 데이터와 외부 Sandbox에 강하게 의존하면 현재 자동화하지 않음으로 갈 수 있고 같은 UI 테스트라도 안정적인 핵심 여정이라면 자동화 우선순위가 높아질 수 있다.
접근성과 시각적 판단은 반자동화가 기본에 가깝다
접근성 도구는 많은 페이지를 빠르게 스캔하고 기계가 판단 가능한 위반을 찾는 데 유용하다. 그러나 W3C는 모든 접근성 측면을 자동으로 확인할 수 없고 도구 결과가 부정확하거나 오해를 만들 수도 있으므로 인간 판단과 실제 사용자 경험을 대체해서는 안 된다고 설명한다. (w3.org)
따라서 다음처럼 일을 나누는 편이 낫다.
- 기계: 구조적 규칙, 속성 누락, 반복되는 위반, 페이지 간 차이 수집
- 사람: 대체 설명의 의미, 키보드 이동의 자연스러움, 정보 순서, 업무 수행 가능성 판단
- 사용자 또는 전문가: 실제 보조기술과 맥락에서 과업이 가능한지 검토
시각 회귀도 같다. 이미지 차이 탐지는 자동화할 수 있지만 의도된 디자인 변경과 결함을 구분하는 오라클은 별도로 필요하다. Look and Feel처럼 주관적인 품질은 인간 검토가 필요하다는 점도 공식 자동화 전략 자료에 명시돼 있다. (istqb.org)
드물지만 위험한 시나리오는 빈도 규칙의 예외다
비밀번호 초기화, 대량 데이터 삭제, 권한 승격, Failover, 백업 복구처럼 자주 실행하지 않는 시나리오는 “반복 빈도가 낮다”는 이유만으로 자동화 후보에서 제외하기 쉽다.
하지만 위험은 가능성과 영향의 조합이다. 드물어도 실패 영향이 크다면 적절한 검증과 통제가 필요하다. (istqb.org)
이때 모든 과정을 하나의 자동화 스크립트로 만들 필요는 없다.
- 삭제 후 참조 무결성이 유지되는지 자동 확인
- 복구 후 핵심 데이터와 서비스 상태가 맞는지 자동 비교
- Failover 전에 필요한 사전 조건이 충족됐는지 자동 점검
- 사람의 역할, 승인, 비상 연락과 복구 판단은 정기 훈련으로 검증
안정적인 불변 조건은 자동화하고 상황 판단과 협업은 사람에게 남기는 식이다.
Flaky test는 자동화 자산이 아니라 신뢰 부채다
같은 코드와 설정에서 통과와 실패가 바뀌는 테스트는 빠르게 실행돼도 믿을 수 있는 신호가 아니다. 실패가 나올 때마다 제품 결함인지 테스트·환경·네트워크 문제인지 다시 조사해야 하고 시간이 지나면 팀은 실패 알림을 무시하기 시작한다.
ISTQB는 반복 결과를 신뢰할 수 없는 테스트를 활성 자동화 Suite에서 분리하고 별도로 원인을 분석하도록 권한다. 예상 밖의 간헐적 실패는 테스트 코드, 대상 시스템, 자동화 Framework, 하드웨어 또는 네트워크에서 발생할 수 있다. (istqb.org)
재실행 후 통과했다는 이유만으로 성공 처리하면 원인은 남는다. 재실행은 재현 정보를 얻는 수단일 수 있지만 신뢰성 문제를 해결하는 판정 규칙은 아니다.
Flaky test가 발견되면 다음 중 하나로 처리한다.
- 활성 Gate에서 격리한다.
- Race Condition, 공유 데이터, 시간, 비동기 처리, 네트워크 의존성을 조사한다.
- 테스트 결과에 환경 오류와 제품 실패를 구분할 수 있는 로그를 남긴다.
- 원인을 해결한 뒤 반복 안정성을 확인하고 다시 편입한다.
- 해결 비용이 반복 가치보다 크다면
현재 자동화하지 않음으로 재분류한다.
Google Research도 Flaky test가 테스트 결과를 신뢰할 수 없게 하고 개발 흐름을 방해한다고 설명한다. (research.google)
자동화 개수 대신 포트폴리오의 건강도를 본다
좋은 자동화 포트폴리오는 테스트 수가 계속 증가하는 포트폴리오가 아니다. 필요한 신호를 제때, 신뢰할 수 있는 비용으로 제공하는 포트폴리오다.
| 운영 지표 | 확인할 질문 |
|---|---|
| Change-to-Signal Time | 변경 후 팀이 행동할 수 있는 결과를 받기까지 얼마나 걸리는가 |
| Failure Analysis Time | 테스트 실행보다 원인 분석에 더 많은 시간이 들고 있지는 않은가 |
| Maintenance Time | 제품 변경마다 자동화 코드 수정 비용이 반복 가치보다 커지고 있지는 않은가 |
| Environment / Data Blockage | 실행하지 못하거나 판정 불가가 된 원인이 환경과 데이터에 집중돼 있는가 |
| Flaky / Inconclusive Trend | 신뢰할 수 없는 결과가 늘고 있는가 |
| Human Review Yield | 자동화가 놓친 의미·사용성·새로운 위험을 사람 검토가 계속 발견하는가 |
| Portfolio Movement | 현재 자동화하지 않음이 방치되고 있는가, Testability 개선 후 이동하고 있는가 |
| Ownership | 실패와 유지보수를 맡을 사람이 명확한가 |
ISTQB의 자동화 지표에도 자동화 스크립트의 평균 유지보수 시간, 실행 시간, 실패한 스크립트와 실행 횟수 등이 포함된다. (istqb.org)
각 지표에 모든 조직이 따라야 할 동일한 목표치를 둘 필요는 없다. 팀의 배포 주기, 시스템 위험, 환경 비용과 비교해 추세와 병목을 보는 편이 낫다.
자동화는 반복을 맡고, 사람은 의미와 발견을 맡는다
테스트 자동화는 사람이 하던 클릭을 그대로 복제하는 작업이 아니다. 반복 가능한 검증을 더 빠르고 일관된 증거로 만드는 투자다.
자동화하기 좋은 테스트는 자주 실행되고 위험 감소 가치가 크며 결과와 환경·데이터를 안정적으로 재현할 수 있다. 자동화하기 어려운 테스트는 반드시 덜 중요한 것이 아니다. 사람의 맥락 판단이 핵심이거나, 현재 시스템이 신뢰할 수 있는 자동화를 지원하지 못할 수 있다.
포트폴리오는 네 가지 상태를 모두 가져야 한다.
- 반복 가능한 판정은 자동화한다.
- 기계가 증거를 모으고 사람이 의미를 판단해야 하면 두 방식을 결합한다.
- 탐색과 사용성 판단은 사람 중심으로 운영한다.
- 신뢰할 수 없는 자동화는 억지로 Suite에 넣지 않고 준비 조건을 개선한다.
그리고 이 분류는 영구적이지 않다. 제품이 성숙하고 요구와 인터페이스가 안정되면 사람 중심 테스트에서 반복 가능한 확인 항목이 나올 수 있다. 반대로 유지보수와 Flakiness가 커진 자동화는 혼합 검토나 보류 상태로 돌아갈 수 있다. 초기 제품에서는 탐색적 테스트가 더 높은 정보가치를 주고 제품이 성숙하면 유지 가능한 자동화 투자가 커질 수 있다는 최근 ISTQB 지침도 같은 방향을 가리킨다. (istqb.org)
자동화의 목적은 사람을 없애는 것이 아니다. 사람이 반복 실행에 쓰던 시간을 줄여, 기계가 판정하지 못하는 위험과 의미를 더 잘 살피게 만드는 것이다.