테스트 공정관리
증적은 무엇을 증명하고, 무엇을 증명하지 못하는가
증적은 그 시점을 증명한다. 케이스가 충분했는지, 다른 입력에서도 그런지, 지금도 그런지는 증명하지 않는다.
테스트 결과서에 화면 캡처 스무 장이 붙어 있다. 전부 정상 화면이다. 검수는 통과했다. 두 달 뒤 운영에서 결함이 터진다.
“테스트했다면서요. 증적도 있잖아요.”
증적은 거짓말을 하지 않았다. 다만 증적이 증명한 것과, 우리가 증명됐다고 믿은 것이 달랐을 뿐이다.
이 글은 그 차이를 정리한다.
1. 증적이 실제로 증명하는 것
화면 캡처 한 장이 증명하는 것을 정확히 쓰면 이렇다.
2026년 8월 20일 14시 32분에
이 화면에서
이 입력으로
이 결과가 나왔다그게 전부다. 그리고 이것은 결코 사소하지 않다. 분쟁이 생겼을 때, 인수인계를 할 때, “그때 무엇을 봤는가”를 답할 수 있는 유일한 기록이다.
문제는 여기서부터다. 우리는 저 문장을 자주 이렇게 읽는다.
❌ "이 기능은 정상이다"
❌ "이 화면은 테스트되었다"
❌ "이 부분은 문제없다"세 문장 모두 증적이 말한 적 없는 내용이다.
2. 증명하지 못하는 것 — 세 가지
① 그 케이스가 충분했는가 — 설계의 문제
증적은 실행한 케이스만 보여준다. 실행하지 않은 케이스는 증적에 없다. 없는 것은 보이지 않는다.
"케이스 20건 전부 통과"
= 우리가 생각한 20가지 상황에서는 문제가 없었다
≠ 문제가 없다생각하지 못한 스물한 번째 상황은 증적 어디에도 나타나지 않는다. 증적이 없다는 사실 자체가 기록되지 않기 때문이다.
증적의 개수는 커버리지가 아니다. 200장짜리 결과서가 20장짜리보다 더 넓게 확인했다는 보장은 없다. 같은 경로를 열 번 찍었을 수도 있다.
② 다른 입력에서도 그런가 — 표본의 문제
할인율 10%로 테스트했다면, 증명된 것은 10%뿐이다.
확인함 할인율 10% → 최종금액 9,000원 ✅ 캡처 있음
확인 안 함 0% · 100% · −5% · 소수점 · null · 최대값 초과경계값과 예외가 빠진 증적은 “가운데만 확인했다”는 기록이다. 그리고 결함은 대부분 가운데가 아니라 가장자리에 있다.
③ 지금도 그런가 — 시점의 문제 ⭐
가장 중요하고, 가장 자주 잊히는 항목이다.
증적은 캡처한 순간의 스냅샷이다. 코드가 바뀌면 증적은 자동으로 낡는다. 그런데 결정적인 문제가 있다.
증적은 스스로 낡았다고 알려주지 않는다.
이 비대칭이 핵심이다.
| 코드가 바뀌어 결과가 달라지면 | |
|---|---|
| 자동화 테스트 | 빨간불이 켜진다. 누군가 반드시 본다 |
| 증적 이미지 | 아무 일도 일어나지 않는다. 파일은 그대로 정상 화면이다 |
자동화 테스트는 살아 있는 증거이고, 증적 이미지는 박제된 증거다. 박제는 썩지 않는다. 그래서 언제 죽었는지 알 수 없다.
3. 그래서 생기는 실무 문제 — 증적의 역설
증적이 많을수록 → 안심한다
증적이 오래될수록 → 위험해진다
그런데 이 둘은 같이 간다.1년 전에 만든 증적 500장은 1년 전 품질에 대한 500개의 진술이다. 그 사이 SR이 서른 건 반영됐다면, 그 500장 중 몇 장이 아직 참인지 아무도 모른다.
그리고 검수는 그 증적을 본다.
여기서 흔한 오해가 하나 더 생긴다.
❌ "증적이 있으니 회귀는 걱정 없다"증적은 과거를 증명한다. 회귀는 현재의 문제다. 과거의 기록으로 현재를 보증할 수 없다. 증적 기반 테스트는 구조적으로 회귀 방지 수단이 될 수 없다.
4. 그럼 왜 증적을 남기는가
여기까지만 읽으면 증적이 쓸모없다는 말로 들릴 수 있다. 그렇지 않다. 증적은 목적이 다른 도구일 뿐이다.
| 증적이 잘하는 일 | 설명 |
|---|---|
| 사실 확인 | 분쟁 시 “그때 무엇을 봤는가”에 답할 수 있는 유일한 기록 |
| 수행의 규율 | 증적을 요구하면 최소한 화면을 한 번은 연다. 안 하면 증적이 안 생긴다 |
| 인수인계 | 다음 사람이 어떤 화면을 어떤 값으로 봤는지 알 수 있다 |
| 재현 단서 | 결함 신고 시 조건을 좁혀 준다 |
증적은 품질 보증 수단이 아니라 커뮤니케이션·기록 수단이다.
이 구분이 이 글 전체의 결론이다. 증적을 품질 보증으로 쓰려 하면 실패하고, 기록으로 쓰면 제 몫을 한다.
5. 증적을 더 쓸모 있게 만드는 다섯 가지
① 언제 찍었는지를 코드 버전과 함께 남긴다
❌ 캡처 파일 하나
⭕ 캡처 + 커밋 해시 · 빌드 번호 · 배포 버전이것 하나만으로 §2-③(시점 문제)의 절반이 해결된다. 증적이 어느 코드에 대한 것인지 알 수 있으면, 그 코드가 바뀌었을 때 낡았음을 판단할 수 있다.
② 무엇을 확인하려 했는지를 함께 적는다
❌ 정상 화면 캡처
⭕ 기대: 할인율 10% 입력 시 최종금액 9,000원
실제: 9,000원 [캡처]기대값 없는 스크린샷은 증적이 아니라 그림이다. 무엇이 맞다고 판단한 근거가 없으면, 나중에 그 판단을 검증할 수 없다.
③ 실패도 남긴다
성공만 모인 증적은 통과율이 항상 100%가 되어 어떤 품질 지표도 만들 수 없다. 다만 이것은 조직의 목적에 따라 답이 갈리는 문제라 별도 글에서 따로 다룬다.
④ 증적에 유효기간을 둔다
가장 실효성이 큰 제안이다.
증적을 대상 코드(또는 화면·기능)와 연결해 두고,
그 코드가 바뀌면 해당 증적을 자동으로 "만료" 표시한다.
→ 결과서를 열었을 때 "이 중 12장은 그 뒤 코드가 바뀌었습니다" 가 보인다증적을 없애자는 것이 아니라, 낡았다는 사실이 보이게 하자는 것이다. 박제에 채취 날짜를 붙이는 일에 가깝다.
⑤ 회귀는 다른 수단에 맡긴다
증적으로 회귀를 막으려 하면 반드시 실패한다. 회귀는 반복 실행되는 것만 막을 수 있다.
증적 → 그 시점의 확인 · 기록 · 커뮤니케이션
자동화 → 반복 실행 · 회귀 방지두 가지를 하나로 하려 들지 않는 것이 중요하다.
6. 이 글이 말하지 않는 것
- 조직마다 증적의 정의가 다르다. 화면 캡처만 뜻하는 곳도 있고, 로그·데이터·영상을 포함하는 곳도 있다. 이 글은 이미지 중심 증적을 전제로 썼다.
- 자동화가 항상 대안은 아니다. UI 자동화는 그 자체로 유지비가 크고, 화면이 바뀌면 함께 깨진다. “자동화하면 된다”는 결론은 이 글의 주장이 아니다.
- 증적이 실제로 결함을 얼마나 잡는지는 측정하지 않았다. 그 답은 의견이 아니라 숫자로만 낼 수 있다. 단위테스트를 통과한 뒤 다음 단계에서 발견되는 결함의 비율(누수율)이 그 실마리가 되는데, 이후 글에서 다룰 예정이다.
정리
① 증적이 증명하는 것
"그 시점에, 그 화면에서, 그 입력으로, 그 결과가 나왔다" — 그게 전부다
② 증명하지 못하는 것
케이스가 충분했는가 (설계) · 다른 입력에서도 그런가 (표본) · 지금도 그런가 (시점)
③ 가장 위험한 것은 세 번째다
증적은 스스로 낡았다고 알려주지 않는다.
자동화 테스트는 깨지면 빨간불이 켜지지만, 증적은 틀려도 아무 일도 일어나지 않는다
④ 그래서 증적은 품질 보증 수단이 아니라 기록 수단이다
그 용도로 쓰면 제 몫을 한다
⑤ 가장 효과가 큰 개선은 증적에 시점을 붙이는 것이다
코드 버전과 연결하면, 낡았다는 사실이 보이기 시작한다이 글은 「테스트 공정관리」 시리즈입니다.
이전 글 — 한국 SI의 단위테스트는 JUnit의 unit test가 아니다 다음 글 예정 — SI와 SR, 개발 요청의 두 갈래와 테스트 성격의 차이
※ 이 글은 개인의 견해이며 소속 회사의 공식 입장이 아닙니다. 특정 고객사나 프로젝트의 정보를 포함하지 않으며, 일반적으로 통용되는 절차를 정리한 것입니다.
이 글은 개인의 견해이며 소속 회사의 공식 입장이 아닙니다. 특정 고객사나 프로젝트의 정보를 포함하지 않습니다.