개념
환경이 다르면 결과도 다르다
"내 컴퓨터에서는 됐는데요"라는 말은 QA와 개발 모두에게 익숙한 문장이다. 대부분의 원인은 코드가 아니라 환경 차이다 — OS 버전, 설정값, 연결된 외부 서비스, 데이터베이스 상태가 다르면 같은 코드도 다르게 동작한다.
환경의 종류
- 개발(Dev) — 개발자가 코드를 짜면서 바로 확인하는 환경. 자주 바뀌고 불안정해도 괜찮다
- 스테이징(Staging) — 운영과 최대한 비슷하게 맞춘 환경. QA가 주로 테스트하는 곳
- 운영(Production) — 실제 사용자가 쓰는 환경
환경 패리티(Environment Parity)
스테이징 환경이 운영 환경과 얼마나 비슷한지를 환경 패리티라고 한다. 패리티가 낮으면(예: 스테이징은 서버 1대, 운영은 10대로 부하분산) 스테이징에서는 안 보이던 문제(동시성, 부하)가 운영에서만 드러난다. 반대로 패리티가 완벽하면 비용이 커진다 — 실무에서는 어느 정도까지 패리티를 맞출지가 항상 트레이드오프다.
모듈 5(레슨 9)에서 배운 생태계 다이어그램을 떠올려보자. 외부 결제 게이트웨이도 환경마다 "테스트 모드"와 "운영 모드"가 다를 수 있다 — 스테이징에서 결제 테스트를 할 때 진짜 돈이 오가지 않는 테스트 모드로 연결되어 있는지 확인하는 것도 환경 관리의 일부다.
환경 격리와 플래키 테스트
같은 스테이징 환경을 여러 팀이나 여러 자동화 파이프라인이 동시에 쓰면, 한쪽의 데이터 변경이 다른 쪽의 테스트에 영향을 준다. 이렇게 환경 공유로 인해 어떤 때는 통과하고 어떤 때는 실패하는 테스트를 플래키 테스트(Flaky Test)라 부른다. 플래키 테스트는 코드 결함처럼 보이지만, 원인이 환경 격리 부족인 경우가 실무에서 매우 흔하다 — 이 개념은 스테이지 4(자동화)에서 본격적으로 다시 다룬다.
환경 관리 체크포인트
- 이 환경의 데이터베이스는 어떤 데이터로 채워져 있는가(레슨 2의 시딩과 연결)?
- 이 환경에 연결된 외부 서비스는 테스트용인가, 실제 서비스인가?
- 이 환경을 지금 나 혼자 쓰고 있는가, 다른 사람과 공유하고 있는가?
- 설정값(환경변수, 피처 플래그)이 운영과 어떻게 다른가?
실무에서 왜 필요한가
"스테이징에서는 문제없었는데 운영 배포하자마자 장애"는 QA 조직에서 가장 뼈아픈 실패 패턴 중 하나다. 대부분 환경 패리티가 낮았거나, 환경 격리가 안 돼서 테스트 자체가 오염된 상태로 진행된 경우다. 환경을 제대로 이해하고 관리하는 QA는 "이 테스트 결과를 얼마나 신뢰할 수 있는가"를 스스로 판단할 수 있다 — 이건 테스트 케이스 설계 능력만큼 중요한, 그러나 자주 간과되는 역량이다.
실습 과제
과제 1 — 패리티 격차 찾기 (10분)
"스테이징은 서버 1대, 캐시 없음, 실제 결제사 대신 가짜 결제 응답을 주는 목(mock) 서버 연결"이라는 스테이징 환경 설정에서, 운영 환경과의 차이로 인해 스테이징에서는 절대 못 잡을 만한 문제 유형을 2가지 예상해 적는다.
과제 2 — 플래키 원인 진단하기 (10분)
"같은 자동화 테스트가 어제는 통과했는데 오늘은 실패했다. 코드 변경은 없었다"는 상황에서, 환경 격리 부족이 원인일 가능성을 확인하기 위해 무엇을 먼저 점검할지 체크리스트 3개를 적는다.
자가 체크리스트
- 개발·스테이징·운영 환경의 역할 차이를 설명할 수 있다
- 환경 패리티가 무엇이고 왜 트레이드오프가 있는지 설명할 수 있다
- 환경 공유가 플래키 테스트의 원인이 될 수 있는 이유를 설명할 수 있다
- 테스트 결과를 신뢰하기 전에 점검해야 할 환경 체크포인트를 나열할 수 있다
흔한 실수
- 스테이징에서 통과했으니 운영에서도 무조건 통과할 것이라 가정한다. 환경 패리티가 낮으면 이 가정은 위험하다.
- 테스트 실패를 코드 결함으로만 단정하고 환경 문제 가능성을 배제한다. 플래키 테스트의 상당수는 환경 격리 부족이 원인이다.
- 외부 서비스가 테스트 모드로 연결되어 있는지 확인하지 않고 테스트를 진행한다. 실제 결제나 실제 이메일 발송이 일어나는 사고로 이어질 수 있다.
참고 자료
- ISTQB Glossary — Test Environment — 테스트 환경의 공식 정의
- Martin Fowler — Eradicating Non-Determinism in Tests — 플래키 테스트의 원인과 대응을 다룬 글