환경·상태 통제 전략
preview, integration, prod-like, sandbox와 seed·clock·queue·reset 전략을 테스트 환경 표준으로 만드는 방법
핵심 요약
- 테스트 신뢰도는 테스트 코드보다 환경과 상태 통제에서 더 자주 무너집니다.
- 환경은 local sandbox·preview·shared integration·prod-like·canary로 나눠 한 환경에 모든 질문을 몰지 않습니다.
- 상태 통제는 reference seed·scenario data·external sandbox·time·event/queue 5개 레이어로 나눠 봅니다.
- seed는 전역·suite·scenario-local 3단으로 두고, 데이터뿐 아니라 clock과 queue까지 통제해야 합니다.
- production 계정·실제 고객 데이터는 테스트에 쓰지 않고 trace/screenshot의 PII는 redaction합니다.
테스트 환경의 신뢰도는 테스트 코드보다 환경과 상태 통제에서 더 자주 무너집니다. 에이전틱 시대에는 특히 "어디서 돌렸는가", "무슨 상태였는가", "어떤 시간과 이벤트 흐름이었는가"를 설명할 수 있어야 합니다.
환경 토폴로지
| 환경 | 목적 | 특징 | 권장 용도 |
|---|---|---|---|
| local sandbox | 빠른 재현과 디버깅 | 개발자/agent 전용, 강한 통제 | root cause 확인 |
| preview | PR 단위 검증 | 짧은 수명, 빠른 생성/폐기 | smoke subset |
| shared integration | 팀 간 통합 확인 | 여러 변경이 충돌 가능 | critical 일부 |
| prod-like | 최종 승인 | production과 유사한 구성 | release gate |
| canary / shadow | 실제 배포 관찰 | read-safe probe 중심 | rollout 판단 |
권장 원칙
한 환경에 모든 질문을 몰아넣지 마세요. preview는 빠르게, shared integration은 협업용으로, prod-like는 게이트용으로, canary는 실제 이상 탐지용으로 분리해야 합니다.
상태 통제의 5개 레이어
| 레이어 | 예시 | 실패하면 생기는 문제 |
|---|---|---|
| reference seed | 조직, 권한 role, feature flag 기본값 | 테스트 시작조차 불가능 |
| scenario data | 주문, 구독, 만료 상태, 권한 변경 리소스 | 같은 흐름이 매번 다르게 보임 |
| external sandbox | 결제, 이메일, OAuth, webhook | 외부 의존성 때문에 원인 분리 실패 |
| time control | 만료, 예약 작업, polling, cron | wait/sleep 남발, 비결정성 증가 |
| event / queue drain | async worker, webhook, retry queue | 최종 상태가 언제 맞는지 알 수 없음 |
테스트가 안정적이려면 데이터뿐 아니라 시간과 이벤트 흐름까지 통제할 수 있어야 합니다.
seed / reset 전략
1. 전역 seed
- 서비스 부팅에 필요한 최소 reference data
- 조직, 플랜, role, feature flag 기본값
- 환경 생성 시 1회 적용
2. suite seed
- smoke/critical가 공통으로 쓰는 계정과 상태
- 테스트 간 경쟁 조건이 없도록 namespace 분리
- 읽기 전용 확인이 가능해야 함
3. scenario-local seed
- 특정 probe에서만 필요한 데이터
- API, admin endpoint, job helper로 생성
- 종료 시 cleanup하거나 TTL로 자동 정리
clock과 queue를 통제하지 못하면 생기는 문제
- polling 기반 화면이 환경마다 다르게 보임
- 예약 작업 완료 시점이 랜덤해져 sleep이 늘어남
- webhook / async job 완료 이전에 assertion이 실행됨
- queue backlog가 다른 팀 실행과 섞여 false negative가 생김
권장 방식:
- fake clock 또는 controllable clock 도입
- queue drain endpoint 또는 admin signal 제공
- async completion을 log/event로 확인 가능한 상태로 외부화
- "이 작업이 끝났는지"를 UI가 아니라 시스템 이벤트로도 검증
외부 의존성 통제
| 의존성 | 기본 정책 | 예외 |
|---|---|---|
| 결제 | sandbox 또는 provider mock | 실제 gateway는 canary 수준만 |
| 이메일 | test inbox / sink | production inbox 사용 금지 |
| SMS / push | mock gateway | 전송 결과 검증용 sandbox만 허용 |
| analytics | noop 또는 stub | 태그 존재 여부만 확인 |
| LLM / agent provider | frozen prompt/model config 또는 recorded stub | online eval은 별도 gate로 분리 |
개인정보와 보안
- production 계정이나 실제 고객 데이터는 테스트 환경에 사용하지 않습니다.
- secret은 secret manager로만 배포하고 로컬
.env공유를 금지합니다. - trace, screenshot, logs에 PII가 남을 수 있으면 redaction 또는 제한 보관을 적용합니다.
- 외부 벤더와 artifact를 공유할 때는 접근 범위를 분리합니다.
흔한 실패 패턴
- 여러 suite가 같은 계정을 동시에 써서 상태가 꼬인다
- preview는 빨리 올라오지만 seed가 늦게 적용된다
- shared integration에서 다른 팀 배포가 같은 시간대에 겹친다
- sandbox quota 초과와 제품 회귀를 구분하지 못한다
- queue backlog나 scheduled job 지연이 flaky로 잘못 분류된다