테스트 자동화·CI·환경·데이터

1. 자동화한 테스트는 많을수록 좋은가

실행할 때마다 사람이 10분씩 반복하는 안정된 회귀검사는 자동화 가치가 클 수 있다. 반면 사양이 매일 바뀌고 결과를 사람의 탐색적 판단으로 읽어야 하는 케이스를 억지로 자동화하면 스크립트 유지비와 거짓경보가 더 커질 수 있다.

이번 절은 자동화를 반복가치·피드백속도·결정가능한 오라클·유지비·실패격리로 판단하고, CI·테스트환경·데이터를 같은 신뢰성 문제로 다룬다.

기획한 위험과 시험수준을 자동화 후보로 가져온다

테스트 기획·계획·분석·설계는 위험·조건·케이스를 설계했고 단위·통합·시스템·인수와 기능·비기능 시험에서는 수준과 유형별 관찰지점을 구분했다. 자동화는 그 설계를 대체하지 않고 반복 가능한 부분을 빠르게 실행하는 수단이다.

이 절의 담당 경계

테스트 관리는 테스트 자산·환경·데이터·실행상태와 실패를 통제하여 신뢰할 수 있는 피드백을 유지하는 활동이고, 테스트 자동화는 판정 가능한 반복 시험을 도구로 실행·수집·비교하여 피드백시간과 반복비용을 줄이는 구현 방식이다.

자동화된 결과도 환경·데이터·오라클이 틀리면 신뢰할 수 없다.

자동화는 CI 안의 한 단계가 아니라 피드백 계약이다

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

빠른 검사·단위 및 통합 시험·패키징·선별 시스템 시험의 실행 결과를 식별한 변경과 연결한다. 결과 누락·실패·판정 불명확을 보류하고 원인을 격리한다. 이 범위의 녹색 결과는 전체 제품 품질의 완성 증거가 아니다.

변경·검사·병합 판단을 말로 확인하기

변경 판본을 식별한 뒤 빌드·빠른 검사 → 단위·통합 → 패키지 → 선택된 시스템시험을 따른다. 각 단계의 결과·로그·아티팩트·실패원인을 모아 merge / 보류 판단에 연결한다.

어떤 실패가 어떤 변경과 환경에서 나왔는지 재현할 수 있어야 한다.

2. 무엇을 자동화할지는 ROI보다 먼저 판정 가능성을 본다

자동화 후보를 고를 때는 시험을 자주 반복하는지, 입력과 기대결과가 명확한지, 실행환경을 안정적으로 준비할 수 있는지, 실패가 중요한 위험을 가리키는지 본다. 단순 실행횟수만으로 우선순위를 정하지 않는다.

자동화 우선순위 판단표

탐색시험은 자동화하지 않는 것이 아니라 자동화가 대신할 수 없는 학습 역할을 따로 남긴다.

AU-1: 1회 8분 수동검사를 매일 20회 반복한다면

가상 회귀검사 하나가 수동 8분, 하루 20회면 160분이 든다. 자동화 작성·유지에 주 180분이 든다고 가정하면 단순 시간만 보면 반복가치가 충분할 수 있다. 그러나 자동결과가 자주 오판한다면 절약시간보다 신뢰비용이 커지므로 거짓실패율과 유지시간을 함께 본다.

3. CI는 변경마다 동일한 검증 순서를 재현한다

DevOps·CI/CD·가치흐름에서 배운 CI는 개발자의 변경을 공유 기준선에 자주 통합하고 자동 빌드·시험으로 문제를 빨리 찾아 복구하는 실천이다. 이 절은 그 통합을 뒷받침할 검증 순서와 환경을 다룬다. 변경을 정해진 빌드·정적검사·시험·패키징에 넣고 결과를 연결하되, 자동 실행만 있고 실제 통합·실패 복구가 없으면 CI의 목적을 충족했다고 볼 수 없다.

빠른 실패와 단계별 비용을 배치한다

컴파일 오류·정적검사·빠른 단위시험을 앞에 두고, 느린 통합·시스템 시험을 뒤에 둘 수 있다. 앞 단계 통과가 뒤 단계를 생략한다는 뜻은 아니며, 각 단계는 서로 다른 위험을 담당한다.

‘초록색 파이프라인’을 품질 전체와 동일시하지 않는다

CI가 초록색이라는 것은 그 판본이 정의된 자동검사를 통과했다는 뜻이다. 아직 자동화되지 않은 위험, 실제 운영환경 차이, 탐색시험, 사람 인수판단까지 통과했다는 뜻은 아니다.

4. 테스트환경은 코드와 함께 판본화해야 한다

DB 스키마, 메시지브로커 설정, 시간대, 언어권, 외부서비스 대역, 네트워크 정책이 바뀌면 같은 코드도 다른 결과를 낼 수 있다. 환경 구성과 초기상태를 자동 생성하고 실행 후 정리할 수 있게 한다.

ENV-1: 로컬에서는 통과하고 CI에서만 실패하는 시간대 예

가상 코드가 날짜를 서버 로컬시간으로 자르고 로컬은 Asia/Seoul, CI는 UTC라고 하자. 자정 근처 입력은 서로 다른 날짜로 분류될 수 있다. 테스트는 시간대를 명시하거나 시간 의존성을 주입해 같은 조건을 재현해야 한다.

공유 테스트환경은 순서 의존성을 만들 수 있다

테스트 A가 남긴 주문행을 테스트 B가 읽거나, 병렬 실행 두 케이스가 같은 계정을 수정하면 개별 케이스는 맞아도 결과가 실행순서에 따라 달라진다. 격리된 데이터·고유 식별자·정리 규칙을 둔다.

5. 테스트데이터는 대표성보다 목적과 경계를 먼저 정의한다

정상값, 경계값, 오류값, 상태전이, 관계무결성에 필요한 최소 데이터를 설계한다. 운영 데이터를 그대로 복제하면 개인정보·비밀·보존정책 위험이 커지므로 합성·가명·최소범위 데이터를 기본으로 검토한다.

DATA-1: 1,000만 행이 필요한 것이 아니라 분포와 경계가 필요할 수 있다

성능시험에 큰 데이터가 필요해도 실제 고객 레코드가 꼭 필요한 것은 아니다. 가상 주문 크기 분포, 인덱스 선택에 영향을 주는 카디널리티, 경계값을 재현한 합성데이터로 목적을 충족할 수 있는지 먼저 본다.

6. Flaky Test는 ‘가끔 실패하는 귀찮은 시험’이 아니라 신뢰채널 장애다

같은 코드·입력에서 비결정적으로 통과와 실패가 바뀌면 개발자는 실제 회귀도 무시하기 시작한다. 시간·난수·병렬성·공유환경·외부서비스·비동기 대기처럼 비결정 원인을 기록하고 제거한다.

FL-1: 1% 거짓실패도 반복되면 무시하기 쉬워진다

독립이라고 단순 가정한 자동시험 200개가 각각 1% 확률로 환경 때문에 거짓실패하면 모두 통과할 확률은 0.99^200 ≈ 0.134다. 적어도 하나가 거짓실패할 확률은 약 86.6%다. 이 계산은 실제 독립성을 주장하는 것이 아니라 작은 불안정성이 대규모 스위트에서 증폭될 수 있음을 보여주는 자체 예다.

먼저 시험 두 개로 식의 뜻을 읽어 보자. 각 시험이 거짓실패하지 않을 확률은 1−0.01=0.99다. 두 결과가 독립이라는 가정 아래 둘 다 거짓실패하지 않을 확률은 0.99×0.99=0.9801이고, 반대 사건인 ‘적어도 하나 거짓실패’는 1−0.9801=0.0199, 즉 1.99%다. 0.99^200의 ^200도 0.99를 200번 곱한다는 뜻이므로 200개에서 전체 통과 약 13.4%를 뺀 약 86.6%가 된다. 200×1%=200%라고 답하면 겹칠 수 있는 실패 사건을 단순 합산한 것이므로 두 시험 예로 돌아가 둘 다 실패할 경우가 중복 계산되는지 확인한다. 86.6%는 이 가정의 묶음에서 하나 이상 거짓실패할 확률이며 각 시험의 실패율이 86.6%라는 뜻은 아니다.

재실행 통과를 자동으로 성공으로 바꾸지 않는다

첫 실패 후 재실행이 통과하면 제품 결함인지 테스트 불안정인지 조사할 증거가 생긴 것이다. 원인을 모른 채 “2번 중 1번 통과”를 초록색으로 만들면 실제 경쟁조건과 간헐 결함을 숨길 수 있다.

7. 테스트 대역은 경계 계약을 단순화하되 현실을 지우지 않는다

이 절의 결제 예에서 stub은 승인·거절 등 미리 정한 응답을 돌려주는 대역, fake는 메모리 안에서 주문을 저장·조회하는 등 단순화한 작동 구현, mock은 정한 호출·인자·횟수가 맞았는지 확인하는 대역으로 구별한다. 예를 들어 승인 stub으로 주문 완료 분기를 시험한 것과 실제 결제망에 돈이 한 번 청구됐음을 확인한 것은 다르다. 이런 대역은 느리거나 불안정한 의존성을 격리하는 데 유용하다. 하지만 대역이 실제 API의 오류코드·지연·스키마·순서를 잘못 흉내 내면 통합위험을 가릴 수 있으므로 계약시험이나 실제 통합시험으로 경계를 보완한다.

mock 호출횟수만 맞고 업무결과가 틀릴 수 있다

payment.charge()가 한 번 호출되었다는 사실은 최종 주문상태와 결제금액이 올바르다는 뜻이 아니다. 구현 세부 호출에 과도하게 결합된 시험은 리팩터링 때 불필요하게 깨지고, 중요한 결과는 놓칠 수 있다.

8. 자동화 결과는 변경·환경·데이터·아티팩트와 함께 보존한다

실패 로그에는 commit, 도구판본, 테스트 ID, 환경, 입력 데이터 식별자, 오류 메시지와 필요한 산출물을 연결한다. “어제 CI가 빨갰다”만 남으면 재현과 추세분석이 어렵다.

품질게이트는 위험과 우회규칙을 함께 정의한다

핵심 단위·통합시험 실패, 보안 정책 위반, 패키징 실패처럼 병합을 막을 조건을 정하고 예외승인 경로를 별도로 둔다. 게이트를 너무 많이 두어 상시 우회하게 만들면 통제 자체가 무의미해진다.

느린 파이프라인은 검증을 건너뛰게 만들 수 있다

피드백이 수십 분·수 시간씩 걸리면 개발자가 큰 변경을 한 번에 모으거나 로컬 우회경로를 선택할 수 있다. 실행시간을 단계별로 측정하고 병렬화·캐시·선택실행을 적용하되 위험 담당 시험을 조용히 삭제하지 않는다.

공식 범위 연결 — IT테스트 관리

테스트 자산·환경·데이터·실행상태·불안정성을 관리하고, 실패를 변경과 추적하여 신뢰 가능한 피드백 채널을 유지한다.

공식 범위 연결 — IT테스트 자동화

반복가치와 판정가능성을 기준으로 자동화 대상을 선택하고 CI에서 재현 가능한 실행·수집·게이트로 구성한다.

출처와 적용 경계

자동화의 이익과 위험은 ISTQB와 CTFL 저자들의 Foundation Level Syllabus v4.0.1 §6.2를 참고한다(2024-09-15 판본, 확인 2026-10-06). 도구 도입만으로 성공이 보장되지 않으며 유지비와 사람 판단의 필요를 함께 검토한다. 시간비용·거짓실패·시간대·합성데이터 예시는 교육용 자체 가정이며 실제 조직의 CI 지표나 운영 데이터가 아니다.

9. 한 장으로 정리하기

1. 자동화는 반복가치·판정가능성·유지비·위험을 함께 본다.
2. CI는 동일한 검증 순서를 변경과 연결하는 피드백 계약이다.
3. 환경·데이터·도구판본이 달라지면 자동결과도 달라질 수 있다.
4. Flaky Test는 실제 회귀 신호를 약화시키는 신뢰성 결함이다.
5. 테스트 대역은 빠른 격리를 돕지만 실제 경계 검증을 완전히 대체하지 않는다.
6. 결과에는 변경·환경·데이터·아티팩트와 우회근거를 남긴다.

독립 연습 — 시험 수를 늘리기 전에 신뢰채널을 계산한다

다음은 본문 사례의 조건을 적용하거나 바꾼 자체 연습이다. 먼저 판단과 근거를 적고 풀이를 펼친다.

FL-1과 같은 단순 모형에서 독립 시험 100 개가 각각 1% 확률로 환경에 의한 거짓 실패를 일으킨다. 한 번의 실행에서 적어도 하나가 거짓 실패할 확률을 구하라. 별도로 모든 시험이 같은 외부 서비스 장애에 함께 영향을 받는 경우에는 같은 독립식을 그대로 써도 되는지 설명하라.

• 전체가 거짓 실패하지 않는 사건에서 시작해 반대 사건의 확률을 계산하라.
• 실패 격리 기록에 변경·환경·데이터·오라클을 어떻게 연결해야 재현할 수 있는지 적어라.

풀이와 오답 교정 보기

독립 가정에서는 1−0.99^100≈0.634, 즉 약 63.4%다. 100×1%=100%로 단순 합산하면 겹치는 사건을 중복 센다. 공통 외부 장애가 결과를 묶으면 독립 가정이 깨지므로 이 곱셈을 그대로 적용하지 않는다. 코드 판본·환경 및 데이터 판본·실행 로그·판정 오라클을 같은 실행에 연결하여 제품 결함과 시험 채널 문제를 분리한다.

단일 시험 1%를 묶음 전체 1%로 썼다면 반대 사건 계산, 공통 원인을 독립으로 썼다면 같은 절의 가정 표시를 고친다. 재실행 통과만으로 원인을 지우지 않는다.

10. 자체 10점 문제

테스트 자동화 대상을 선정하는 기준과 CI에서 Flaky Test, 테스트환경, 테스트데이터를 관리해야 하는 이유를 설명하시오.

요구어는 선정, 설명이다. 자동화 비율보다 신뢰 가능한 피드백 조건을 중심으로 답한다.

10점 풀이와 답안 구성 보기

10점 답안 목차

1. 반복가치·판정가능성·유지비
2. CI의 변경–검증 연결
3. 환경 판본화와 격리
4. 합성·최소 테스트데이터
5. Flaky Test 원인·재실행 함정
6. 품질게이트와 예외통제

10점 답안 도식

반복가치 + 판정 가능한 오라클 + 안정환경을 먼저 확인하여 자동화 대상을 고른다. 이후 CI 그림의 변경 → CI → 결과·로그 → 병합 판단을 추적한다.

10점 모범답안

자동화는 자주 반복되고 입력·기대결과가 명확하며 환경을 재생성할 수 있고 실패가 중요한 위험을 가리키는 케이스부터 선택한다. CI는 변경마다 같은 빌드·검사·시험 순서를 실행하고 결과를 commit과 연결한다. 환경·DB·시간대·도구판본을 고정하거나 명시하지 않으면 코드가 같아도 결과가 달라질 수 있다. 테스트데이터는 정상·경계·오류 목적에 맞게 합성·가명·최소범위로 준비하고 케이스 사이 상태를 격리한다. 같은 조건에서 비결정적으로 깨지는 Flaky Test는 실제 회귀 신호를 약화하므로 재실행 통과로 숨기지 않고 시간·난수·병렬·외부의존 원인을 제거한다. 품질게이트와 예외승인도 위험 기준으로 관리한다.

11. 자체 25점 문제

하루 200회 실행되는 주문서비스 CI를 개선하려 한다. 전체 파이프라인이 35분이고 간헐 실패가 많으며 공유 DB와 운영 복사데이터를 사용한다. 자동화 포트폴리오, 단계배치, 환경·데이터 격리, Flaky Test 처리, 테스트 대역·계약시험, 품질게이트와 결과추적 방안을 설계하시오.

요구어는 개선, 설계다. 속도만 줄이지 말고 신뢰성과 데이터 위험을 함께 다룬다.

25점 풀이와 답안 구성 보기

25점 답안 목차

1. 위험·반복가치 기반 자동화 분류
2. 빠른 검사→단위→통합→선택 시스템 단계
3. 변경·도구판본·아티팩트 추적
4. 일회성 환경과 독립 데이터
5. 운영데이터 제거·합성데이터 설계
6. Flaky Test 탐지·격리·원인제거
7. 대역 + 계약/실통합 보완
8. 위험기반 품질게이트·예외승인
9. 실행시간·거짓실패·유지비 지표

25점 답안 도식

CI 그림의 빠른 검사 → unit → integration → selected system을 commit과 연결한다. 각 단계는 env / data / version / artifact를 식별한 기록으로 남겨 신뢰 가능한 gate의 근거로 사용한다.

25점 모범답안

하루 200회는 CI 파이프라인 실행 횟수이며 테스트케이스 수가 아니다. 먼저 각 실행에 포함되는 케이스와 실제 실행빈도·오라클·위험·유지비를 조사해 자동화 포트폴리오를 만든다. FL-1의 독립 테스트 200개 가정도 이 서비스의 케이스 수로 옮기지 않는다. 컴파일·정적검사·빠른 단위시험을 앞에 배치하고 실제 경계가 필요한 통합시험과 선택된 시스템시험을 뒤에 둔다. 각 실행은 commit, 도구판본, 환경, 데이터세트, 로그와 아티팩트를 연결한다. 공유 DB 대신 실행별 스키마·컨테이너·고유키를 사용해 상태를 격리하고 운영 복사데이터는 목적에 맞는 합성·가명 데이터로 대체한다. 간헐 실패는 재실행 통과로 초록색 처리하지 않고 시간·난수·병렬·외부서비스 원인을 분류하여 격리 후 수정한다. 빠른 시험에는 대역을 쓰되 실제 API 계약과 통합시험으로 대역의 현실성을 검증한다. 핵심 회귀·보안·패키지 실패를 품질게이트로 두고 예외는 승인자·사유·만료를 남긴다. 개선효과는 총 시간뿐 아니라 거짓실패율·재현시간·유지비와 놓친 회귀를 함께 본다.