개념
왜 QA가 프로젝트 관리를 알아야 하나
테스트 일정이 늘 압축되는 이유를 따라가 보면 대부분 프로젝트 계획 단계에 있다. WBS에 테스트가 "통합 테스트 2주" 한 줄로 들어가 있고, 결함 수정·재확인 시간은 없고, 개발 지연은 테스트 기간에서 흡수된다. QA가 프로젝트 관리의 언어를 모르면 이 구조에 끌려다닌다. 알면 계획 단계에서 테스트가 제대로 들어간 계획 을 요구할 수 있다.
또 프로젝트·사업 관리는 QA 경력이 넓어지는 자연스러운 방향 중 하나다(모듈 42). 품질 위험을 아는 프로젝트 관리자는 드물고, 그래서 가치가 있다.
PMBOK 8판 — 원칙과 성과 영역
PMI의 PMBOK 가이드 8판은 2025년 11월 발행됐고, PMP 시험은 2026년 7월부터 새 판을 반영한다. 7판이 12개 원칙·8개 성과 영역으로 원칙 중심 전환을 했다면, 8판은 이를 6개 원칙, 7개 성과 영역 으로 정리하고 5개 초점 영역(착수·기획·실행·감시통제·종료)에 40개의 비규범적 프로세스를 다시 넣어 실무 적용성을 높였다.
6개 원칙
| 원칙 | 품질 담당자에게 주는 의미 |
|---|---|
| 전체론적 관점을 갖는다 | 테스트를 따로 떨어진 단계가 아니라 시스템의 일부로 본다 |
| 가치에 집중한다 | 테스트 범위를 사용자·사업 가치로 우선순위화한다 |
| 품질을 프로세스와 산출물에 내재화한다 | 품질은 마지막 검사가 아니라 전 과정에 들어간다 |
| 책임 있는 리더가 된다 | 위험 감수 결정의 책임을 분명히 한다 |
| 모든 영역에 지속가능성을 통합한다 | 유지보수 가능한 테스트 자산, 기술 부채 관리 |
| 권한을 위임하는 문화를 만든다 | 팀과 이해관계자의 자율과 참여 |
세 번째 원칙이 품질 담당자에게 가장 반가운 문장이다. "품질을 마지막에 검사한다"가 아니라 "프로세스에 내재화한다"는 것이 프로젝트 관리 표준의 원칙으로 명시되어 있다. 테스트 활동을 앞단으로 옮기자는 제안(모듈 44 레슨 5)의 근거로 쓸 수 있다.
7개 성과 영역: 거버넌스, 범위, 일정, 재무, 이해관계자, 자원, 위험.
WBS에 테스트를 제대로 넣는다
WBS(Work Breakdown Structure, 작업 분할 구조)는 프로젝트의 모든 작업을 산출물 중심으로 쪼갠 것이다. 테스트가 WBS에서 한 줄이면 일정과 비용에서도 한 줄로 취급된다.
[나쁜 WBS]
3. 개발
4. 테스트
4.1 통합 테스트 (2주)
5. 오픈
[좋은 WBS — 테스트를 산출물 단위로]
2. 설계
2.4 테스트 전략·계획 수립
2.5 요구사항 리뷰(수용 기준 확정)
3. 개발
3.x 기능별 개발 + 단위 테스트
3.9 테스트 환경·데이터 준비
3.10 테스트 케이스 설계
4. 테스트
4.1 통합 테스트 1차 실행
4.2 결함 수정 기간(개발)
4.3 재확인·회귀 2차
4.4 성능·보안 테스트
4.5 인수 테스트 지원
4.6 테스트 결과 보고·Go/No-Go
5. 이행·오픈
5.1 이행 리허설 및 이행 검증좋은 WBS의 특징은 세 가지다. 테스트 준비 작업(계획·설계·환경·데이터)이 개발과 병렬로 있다. 결함 수정 기간이 별도 작업 으로 있다. 재확인·회귀가 1차 실행과 분리 되어 있다.
크리티컬 패스와 테스트 일정
크리티컬 패스는 프로젝트에서 여유(float)가 0인 작업들의 연결이다. 이 경로의 작업이 하루 늦으면 프로젝트 전체가 하루 늦는다.
테스트 실행은 거의 항상 크리티컬 패스 위에 있다. 개발이 끝나야 시작하고, 끝나야 오픈하기 때문이다. 그래서 개발이 늦으면 테스트 기간이 압축된다. 이를 막는 방법은 크리티컬 패스를 바꾸는 것이다.
- 테스트 준비(설계·환경·데이터)를 크리티컬 패스 밖으로 빼서 개발과 병렬로 진행한다
- 기능을 단계적으로 인도 받아 테스트를 조기에 시작한다(부분 인도)
- 테스트 기간에 완충(buffer) 을 명시적으로 둔다 — 크리티컬 체인 방식의 프로젝트 버퍼
획득가치(EV) — 진척과 비용을 함께 본다
모듈 43 레슨 5의 번업이 테스트 진척을 봤다면, 프로젝트 관리자는 획득가치 관리(EVM)로 일정과 비용을 동시에 본다.
| 용어 | 뜻 |
|---|---|
| PV(계획가치) | 지금까지 하기로 계획한 일의 예산 |
| EV(획득가치) | 지금까지 실제로 완료한 일의 예산 |
| AC(실제원가) | 지금까지 실제로 쓴 비용 |
| SPI = EV / PV | 1보다 작으면 일정 지연 |
| CPI = EV / AC | 1보다 작으면 비용 초과 |
[예] 테스트 단계 예산 60인일, 오늘까지 계획 30인일(PV=30)
실제 완료한 작업의 예산 가치 24인일(EV=24), 실제 투입 32인일(AC=32)
SPI = 24/30 = 0.80 → 일정 20% 지연
CPI = 24/32 = 0.75 → 같은 일에 계획보다 33% 더 들고 있음
해석: 인원을 더 넣어 일정은 맞추려 했지만 효율이 떨어짐(환경·차단 문제 의심)품질 담당자에게 EV의 함정도 알아야 한다. "완료"의 정의가 느슨하면 EV가 부풀려진다. 테스트 케이스를 "실행했다"로 완료 처리하고 결함 재확인이 남아 있다면 실제 진척보다 높게 보인다. 완료의 정의에 품질 조건을 넣는 것이 품질 담당자의 역할이다.
프로젝트 위험과 테스트 위험
프로젝트 위험 관리(PMBOK의 위험 성과 영역)와 테스트의 위험 기반 테스트(모듈 4)는 같은 말을 쓰지만 대상이 다르다.
| 프로젝트 위험 | 제품 위험(테스트 위험) | |
|---|---|---|
| 대상 | 프로젝트 목표(일정·비용·범위) | 제품 품질(기능·성능·보안) |
| 예 | 핵심 개발자 이탈, 외부 연동사 일정 지연 | 결제 금액 계산 오류, 동시 접속 시 장애 |
| 대응 | 회피·전가·완화·수용 | 테스트 강도 조정, 설계 변경 |
두 위험은 연결된다. "외부 연동사 일정 지연"(프로젝트 위험)이 현실화되면 "연동 테스트 기간 부족"으로 이어지고 "연동 장애 처리 오류"(제품 위험)가 커진다. 품질 담당자는 프로젝트 위험 목록을 보며 어떤 프로젝트 위험이 제품 위험을 키우는지 연결해 표시한다.
예측형·적응형·하이브리드
PMBOK은 개발 접근을 예측형(워터폴), 적응형(애자일), 하이브리드로 나눈다. 모듈 7 레슨 4에서 방법론별 테스트를 봤다. 프로젝트 관리 관점에서 선택 기준은 이렇다.
| 조건 | 적합한 접근 |
|---|---|
| 요구사항이 안정적이고 규제·계약으로 고정됨 | 예측형(금융 차세대, 공공 SI) |
| 요구사항이 불확실하고 빠른 피드백이 필요 | 적응형(신규 서비스, 스타트업) |
| 전체 범위는 계약으로 고정, 세부는 반복 | 하이브리드(대부분의 실무) |
국내 대형 프로젝트는 계약은 예측형, 개발은 반복형인 하이브리드가 많다. 이때 테스트 계획은 계약상의 테스트 단계(통합·인수) 와 반복 안의 테스트(스프린트) 를 모두 가져야 한다.
실무에서 왜 필요한가
프로젝트 관리의 언어를 쓰는 QA는 계획 회의에서 발언권을 얻는다. "테스트 기간이 부족합니다"는 호소로 들리지만, "현재 WBS에 결함 수정 기간이 없어 크리티컬 패스상 테스트가 5일 압축될 위험이 있고, 현재 SPI 0.8을 감안하면 오픈 일정 위험이 큽니다"는 판단 자료로 들린다.
채용시장에서의 위치
"테스트 PM", "QA PL", "PMO 품질 담당" 공고는 PMP나 프로젝트 관리 경험을 우대한다. 대형 SI·금융 프로젝트에서 품질 관리자(QA)는 PMO의 일원으로 일하는 경우가 많아 WBS·EVM·위험 관리의 언어가 기본이다. QA 경력에 PMP를 더하면 프로젝트·사업 관리 경로로 넘어가는 확실한 증거가 된다.