개념
"각자 한번 읽어보고 의견 주세요"의 문제
리뷰 회의 전에 문서를 공유하고 "읽어보고 오세요"라고 하는 것을 애드혹 리뷰(ad hoc review) 라고 부른다. 기법이 아니라 기법의 부재다. 애드혹 리뷰에는 세 가지 구조적 문제가 있다.
① 중복 세 사람이 전부 1~3페이지만 꼼꼼히 읽고 뒤는 훑는다
② 공백 아무도 안 본 절이 생기는데, 아무도 그 사실을 모른다
③ 편향 각자 자기가 잘 아는 관점으로만 본다 — 그 관점이 겹치면 겹친 채로 끝난다모듈 43 레슨 2에서 리뷰 기준 (체크리스트)과 리뷰 유형 (ISO/IEC 20246의 비공식 리뷰·워크스루·기술 리뷰·인스펙션)을 다뤘다. 유형은 "얼마나 형식을 갖출 것인가"의 축이다. 이 레슨은 다른 축, 읽기 기법(reading technique) 을 다룬다. 같은 인스펙션이라도 참가자가 문서를 어떤 절차로 읽느냐에 따라 결과가 달라진다.
리뷰 유형 (형식의 정도) × 읽기 기법 (읽는 절차)
비공식 / 워크스루 / 애드혹 / 체크리스트 기반 /
기술 리뷰 / 인스펙션 퍼스펙티브 기반(PBR) / 결함 기반체크리스트 기반 읽기
체크리스트 기반 읽기(CBR, checklist-based reading)는 문서 유형별 질문 목록을 들고 읽는다. 모듈 43 레슨 2의 리뷰 체크리스트가 이 계열이다. 요구사항 문서용 체크리스트의 예시는 이렇게 생겼다.
| 번호 | 질문 |
|---|---|
| RQ-1 | 각 요구사항이 검증 가능한 형태인가(관측 가능한 값으로 진술되어 있는가) |
| RQ-2 | "빠르게", "적절히", "사용자 친화적" 같은 모호어가 정량 기준 없이 쓰였는가 |
| RQ-3 | 오류·예외·경계 상황의 동작이 명시되어 있는가 |
| RQ-4 | 상충하는 요구사항 쌍이 있는가 |
| RQ-5 | 용어가 문서 안에서 일관되게 쓰였는가(같은 개념에 두 이름) |
| RQ-6 | 기존 기능에 미치는 영향이 언급되어 있는가 |
| RQ-7 | 비기능 요구사항(성능·보안·접근성)에 수치 기준이 있는가 |
| RQ-8 | 데이터 생명주기(생성·수정·삭제·보존)가 정의되어 있는가 |
체크리스트의 강점은 지식 축적 이다. 운영 장애가 날 때마다 항목이 하나씩 늘고, 그 항목이 팀의 기억이 된다. 약점은 두 가지다.
- 체크리스트에 없는 결함은 안 보인다. 리뷰어의 시야가 목록으로 수렴한다.
- 리뷰어 간 분담이 안 된다. 세 명이 같은 체크리스트를 들면 세 명이 같은 곳을 본다.
퍼스펙티브 기반 읽기(PBR)
퍼스펙티브 기반 읽기(PBR, perspective-based reading)는 다른 접근을 쓴다. 리뷰어마다 다른 이해관계자 역할을 맡기고, 그 역할이 실제로 하는 작업을 문서로 수행하게 한다.
핵심은 "읽어라"가 아니라 "만들어 보라" 다. 무언가를 만들다 보면 문서의 공백이 드러난다.
| 퍼스펙티브 | 수행할 작업 | 작업 중 드러나는 결함 |
|---|---|---|
| 테스터 | 각 요구사항에 대한 테스트 케이스와 기대 결과를 초안한다 | 검증 불가능한 요구사항, 기대 결과를 특정할 수 없는 구간(오라클 공백) |
| 설계자 | 문서를 근거로 상위 설계·데이터 모델을 스케치한다 | 데이터 흐름의 단절, 정의되지 않은 개체·관계, 성능 제약 부재 |
| 사용자 | 대표 사용자 시나리오를 끝까지 따라가 본다 | 빠진 단계, 되돌리기 경로 없음, 오류 상황의 안내 부재 |
PBR은 1990년대 미국 NASA 고다드 우주비행센터의 소프트웨어 공학 연구소(SEL)에서 Basili 연구진이 실증 실험한 기법이다. 전문 개발자를 대상으로 한 실험에서 PBR 팀이 기존의 비공식 읽기 방식보다 문서 커버리지와 팀 단위 결함 검출에서 더 나은 결과를 보였다 는 것이 반복해서 보고됐다. 개인 단위 효과보다 팀 단위 효과 가 크다는 것이 특징인데, 이유가 중요하다 — 퍼스펙티브가 다르면 찾는 결함의 집합이 겹치지 않기 때문이다.
애드혹 3인 PBR 3인
┌────┐ ┌──────┐
│ ██ │ ← 겹침이 크다 │ █ │ 테스터
│ ██ │ │ █ │ 설계자
│ ██ │ │ █│ 사용자
└────┘ └──────┘
합집합이 작다 합집합이 크다퍼스펙티브별 시나리오 — 실제로 쓸 수 있는 형태
PBR을 도입할 때 가장 자주 실패하는 이유는 "테스터 관점으로 보세요"라고만 말하고 끝내기 때문이다. 퍼스펙티브는 절차(시나리오)로 적혀 있어야 작동한다.
[테스터 퍼스펙티브 시나리오]
1. 문서에서 요구사항을 하나씩 번호를 붙여 뽑아낸다
2. 각 요구사항에 대해 정상 케이스 1건과 오류 케이스 1건의
"입력 / 기대 결과 / 기대 결과의 근거"를 적는다
3. 기대 결과를 특정할 수 없으면 그 자리에 [Q] 표시를 남긴다
4. 질문
- 이 요구사항의 합격/불합격 기준을 문장으로 쓸 수 있는가?
- 이 기능이 언제 실패하는지 문서가 말하는가?
- 이 요구사항을 검증하려면 어떤 데이터·권한·환경이 필요한가?
그것이 문서에 있는가?[설계자 퍼스펙티브 시나리오]
1. 문서에 등장하는 개체(엔티티)와 관계를 종이에 그린다
2. 주요 흐름 하나를 골라 컴포넌트 간 호출 순서를 그린다
3. 질문
- 각 개체의 생명주기(생성·수정·삭제·보존 기간)가 정의돼 있는가?
- 외부 시스템 호출이 실패하면 무엇을 해야 하는지 적혀 있는가?
- 동시에 두 사용자가 같은 대상을 바꾸면 어떻게 되는가?
- 이 요구를 만족하려면 기존 어느 부분을 바꿔야 하는가?[사용자 퍼스펙티브 시나리오]
1. 대표 사용자 유형을 둘 고른다(예: 신규 가입자, 관리자)
2. 각 유형이 이 기능으로 달성하려는 목표를 한 문장으로 적는다
3. 문서만 보고 그 목표를 처음부터 끝까지 따라간다
4. 질문
- 중간에 막히는 지점이 있는가? 문서가 그 지점을 말하는가?
- 실수했을 때 되돌릴 수 있는가?
- 오류 메시지가 사용자가 다음에 할 일을 알려주는가?
- 이 흐름을 처음 쓰는 사람이 학습 없이 할 수 있는가?세 기법의 검출 특성 비교
같은 문서에 세 기법을 적용하면 결함의 종류 가 다르게 나온다. 수치는 팀·문서마다 다르므로 남의 숫자를 인용할 게 아니라 우리 팀 데이터를 쌓는 것 이 목적이다.
| 애드혹 | 체크리스트 기반 | 퍼스펙티브 기반 | |
|---|---|---|---|
| 준비 비용 | 없음 | 체크리스트 작성·유지 | 시나리오 작성·역할 배정 |
| 리뷰어 간 중복 | 큼 | 큼 | 작음 |
| 잘 잡는 결함 | 리뷰어가 잘 아는 영역 | 과거에 겪은 유형 | 누락·모호함·검증 불가 |
| 놓치는 결함 | 예측 불가 | 목록에 없는 유형 | 시나리오가 안 다루는 축 |
| 신규 팀원 | 기여 어려움 | 기여 가능 | 기여 가능(역할이 가이드) |
| 적합한 문서 | — | 반복되는 형식의 산출물 | 요구사항·설계서처럼 새로운 문서 |
실무 결론은 둘 중 하나가 아니라 겹쳐 쓰는 것 이다. 요구사항·설계 문서는 PBR로 역할을 나누고, 각 역할의 시나리오 끝에 그 역할용 체크리스트를 붙인다. 테스트 케이스·결함 보고서처럼 형식이 반복되는 산출물은 체크리스트만으로 충분하다.
리뷰를 측정한다
리뷰가 실제로 효과가 있는지는 네 지표로 본다.
| 지표 | 계산 | 읽는 법 |
|---|---|---|
| 리뷰 검출 결함 수 | 리뷰에서 합의된 결함 건수 | 절대값보다 추세 |
| 리뷰 효율 | 검출 결함 수 ÷ 투입 시간 | 페이지당 읽기 속도가 너무 빠르면 효율이 떨어진다 |
| 결함 유형 분포 | 누락·모호·상충·오류·개선 | 특정 유형 편중은 기법 편중의 신호 |
| 탈출률 | 나중 단계에서 발견된 결함 중 그 문서에 있었던 비율 | 이 지표가 체크리스트와 시나리오를 진화시킨다 |
탈출률 분석이 핵심이다. 운영 장애가 날 때마다 "이 결함의 뿌리가 그 요구사항 문서에 있었는가, 있었다면 어느 퍼스펙티브가 봤어야 했는가" 를 묻는다. 답이 나오면 그 퍼스펙티브의 시나리오에 질문을 한 줄 추가한다.
리뷰 회의 진행 — 검출과 합의를 분리한다
PBR이든 CBR이든 결함 검출은 개인 작업 이다. 회의에서 처음 문서를 펴는 순간 그 회의는 낭독회가 된다. 진행 규칙은 셋이다.
① 개인 준비 (회의 전)
각자 자기 퍼스펙티브 시나리오를 수행하고 발견 목록을 제출한다
→ 제출물이 없으면 회의를 연기한다. 이 규칙이 없으면 PBR은 정착하지 않는다
② 회의 (60분 이내)
중복 항목을 먼저 병합하고, 판정이 갈리는 항목만 토론한다
"결함인가 아닌가"만 판정하고 해결책은 논의하지 않는다
③ 후속
판정 결과를 문서 담당자에게 넘기고, 반영 여부를 추적한다②의 "해결책을 논의하지 않는다"가 회의 시간을 가장 크게 줄인다. 해결책 토론이 시작되면 참가자 절반이 방관자가 된다.
실무에서 왜 필요한가
요구사항·설계 단계에서 잡은 결함은 코드가 되기 전에 사라진다. 이건 오래된 상식이지만, 상식이 실행으로 바뀌지 않는 이유는 리뷰가 기법 없이 수행되기 때문 이다. 기법 없는 리뷰는 효과가 사람에 붙고, 사람에 붙은 효과는 재현되지 않으며, 재현되지 않으면 조직이 리뷰에 시간을 배정하지 않는다.
QA에게 PBR이 특히 중요한 이유가 하나 더 있다. 테스터 퍼스펙티브 시나리오의 산출물이 곧 테스트 케이스 초안 이라는 것이다. 리뷰 참여가 부수 업무가 아니라 테스트 설계의 첫 단계가 된다. 리뷰 시간을 별도로 확보하기 어려운 팀에서 이 논리가 설득에 잘 먹힌다.
또한 테스터 퍼스펙티브에서 남긴 [Q] 표시는 레슨 1의 "오라클 출처 없음"과 같은 것이다. 두 레슨의 산출물이 같은 질문 목록으로 합쳐진다.
채용시장에서의 위치
시니어 QA 공고의 "설계 문서 리뷰를 통한 결함 조기 발견", "요구사항 분석 및 리뷰 주도" 같은 문구가 이 레슨의 영역이다. 면접에서 "리뷰에 참여하셨나요"는 대부분 "네"로 끝나지만, "요구사항 리뷰에 PBR을 도입해 역할을 셋으로 나눴고, 테스터 시나리오 산출물을 그대로 케이스 초안으로 썼습니다" 는 다른 답이다. ISTQB Advanced Level Test Analyst와 Foundation Level 모두 정적 테스트·리뷰를 별도 장으로 다룬다.