QA 일을 하다 보면 이런 말을 정말 많이 들어요.
“이건 dev에서 확인했어요?”
“stage에는 반영됐나요?”
“운영(prod)에는 아직 안 올라갔죠?”
그런데 막상 회사에 가보면 이런 생각이 들기도 해요.
“우리 회사는 dev / qa / live 인데?”
“stage라는 환경이 없는데…”
“test 서버 하나뿐인데 이건 뭐지?”
그래서 이번 글에서는 특정 회사 기준의 환경 설명이 아니라,
👉 QA가 어떤 회사에 가도 적용할 수 있는 ‘환경 이해 방법’을 정리해볼게요.
1️⃣ QA에게 테스트 환경이 중요한 이유
QA에게 테스트 환경은 단순히 서버 이름이 아니에요.
- 지금 이 이슈가 릴리즈 전에 막아야 하는지
- 어느 단계까지 검증이 끝난 상태인지
- 개발자·기획자와 같은 맥락으로 소통할 수 있는지
이걸 판단하는 기준이에요.
👉 그래서 QA는
“이게 dev냐 stage냐”보다,
“이 환경이 어떤 역할을 하는지”를 이해해야 합니다.
2️⃣ 먼저 짚고 가자: 테스트 환경 이름은 회사마다 다르다
이 글에서 사용하는 dev / stage / prod는 가장 흔하게 쓰이는 예시일 뿐이에요.
실무에서는 이렇게 다양해요.
- dev / qa / prod
- local / dev / stage / live
- test / real
- 테스트 서버 1개 + 운영 서버 1개
👉 이름이 다른 건 전혀 문제 아니에요. 중요한 건, 그 환경이 아래 중 어디에 해당하느냐예요.
3️⃣ QA는 테스트 환경을 ‘역할’로 구분한다
QA 관점에서 테스트 환경은 보통 3가지 역할로 나눌 수 있어요.
✔ ① 개발 중인 기능을 확인하는 환경
(보통 dev, local 등)
- 개발자가 기능을 구현하면서 사용하는 환경
- 코드가 자주 바뀜
- 데이터가 불완전할 수 있음
👉 QA 관점에서는 “기능이 돌아가는지 흐름을 빠르게 확인하는 곳”
✔ ② 릴리즈 전 검증을 하는 환경
(보통 stage, qa, test 등)
- 운영 환경과 가장 유사
- QA의 메인 테스트 공간
- 테스트 케이스 수행
- 이슈 리포팅의 대부분이 여기서 발생
👉 실무에서 말하는 “QA 완료”, “테스트 통과”는 대부분 이 환경 기준이에요.
✔ ③ 실제 사용자가 쓰는 운영 환경
(보통 prod, live, real 등)
- 실사용자 데이터 존재
- 서비스 장애와 직결됨
- QA의 직접적인 테스트는 최소화
👉 QA에게 운영 환경은 “테스트하는 곳”이 아니라 “품질을 감시하고 대응하는 곳”에 가까워요.
4️⃣ 역할 기준으로 다시 정리한 테스트 환경 표
| 환경의 역할 | 흔히 쓰는 이름 예시 | QA가 주로 하는 일 |
| 개발 중 확인 | dev / local | 흐름 테스트, 빠른 확인 |
| 릴리즈 전 검증 | stage / qa / test | 테스트 케이스, 이슈 리포팅 |
| 운영 | prod / live | 모니터링, 장애 대응 |
👉 이 표 기준으로 보면 회사마다 이름은 달라도 역할은 거의 같다는 걸 알 수 있어요.
5️⃣ QA는 환경마다 테스트 깊이를 다르게 가져간다
🔹 개발 중 환경
- 세세한 검증 ❌
- 큰 흐름 위주 ⭕
- “이 방향이 맞는지” 확인
🔹 릴리즈 전 검증 환경
- 기획서 기준 검증 ⭕
- 회귀 테스트 ⭕
- 예외 케이스 ⭕
🔹 운영 환경
- 테스트 목적 접근 ❌
- 장애 재현 확인 ⭕
- 로그·모니터링 중심
👉 이 차이를 이해하면 “왜 dev에서는 괜찮고 stage에서 문제냐” 같은 질문에도 설명력이 생겨요.
6️⃣ 실무에서 자주 헷갈리는 질문들
Q. dev에서만 발생하는 이슈도 리포트해야 할까?
👉 Yes. 단, “stage 미반영 상태에서 확인됨”이라는 맥락을 꼭 남겨야 해요.
Q. 우리 회사에는 stage가 없는데, 그럼 QA는 어디서 하나요?
👉 이름이 없어도 괜찮아요. “릴리즈 전 최종 검증을 하는 환경”이 있다면, 그게 QA 환경이에요.
Q. QA는 운영 환경 접근 권한이 꼭 필요할까?
👉 회사 정책마다 다르지만, 로그 확인이나 장애 대응 목적의 제한적인 권한은 있으면 확실히 도움이 됩니다.
7️⃣ 환경을 이해하는 QA는 신뢰를 얻는다
환경을 이름이 아니라 역할로 설명할 수 있는 QA는 회의에서 이런 말을 자연스럽게 할 수 있어요.
“이 이슈는 현재 릴리즈 전 검증 환경 기준으로 봤을 때
운영 반영 전에 반드시 수정이 필요합니다.”
이 한 문장은
- 개발자에게는 명확하고
- 기획자에게는 설득력 있고
- 팀 전체에는 신뢰를 줘요.
🔗 함께 보면 좋은 글
'QA 실무 가이드' 카테고리의 다른 글
| 📌 QA 실무 가이드 8편 — QA가 기획서를 리뷰하는 방법 (실무 체크포인트 정리) (0) | 2025.12.31 |
|---|---|
| 📌 QA 실무 가이드 7편 — 버그 Severity / Priority 실전 기준 (1) | 2025.12.29 |
| 📌 QA 실무 가이드 5편 — QA가 개발자·기획자와 소통하는 법 (0) | 2025.12.25 |
| 📌 QA 실무 가이드 4편 — 이슈(버그) 리포팅 가이드 (0) | 2025.12.23 |
| 📌 QA 실무 가이드 3편 — 탐색적 테스트(Exploratory Testing) 제대로 하기 (1) | 2025.12.21 |