개념
앞선 다섯 레슨에서 능동적으로 읽고, 테스트 가능성을 판단하고, 모호함과 누락을 찾고, 수용 기준을 쓰고, 추적성을 이해했다. 이 레슨은 그 결과물을 실제 회의 자리에서 팀에 전달하는 법을 다룬다. 아무리 좋은 질문을 준비해도, 회의에서 제대로 전달하지 못하면 소용없다.
준비 없이 참여하면 생기는 일
준비 없이 요구사항 리뷰에 들어가면 대부분 이렇게 된다 — 발표자가 요구사항을 쭉 읽고, "질문 있으신가요?"라고 물으면 정적이 흐르고, 회의는 형식적으로 끝난다. 문제는 이 조용함이 "요구사항이 완벽하다"는 뜻이 아니라 **"그 자리에서 즉흥적으로 문제를 찾기 어렵다"**는 뜻이라는 것이다. 모호함과 누락은 미리 읽고 분석해야 보인다(레슨 1, 3) — 회의 중 실시간으로 찾기는 어렵다.
준비: 질문을 우선순위화한다
레슨 1, 3에서 배운 방법으로 질문을 미리 뽑았다면, 회의 전에 우선순위를 매긴다. 모든 질문을 다 던지면 회의 시간을 넘기고 정작 중요한 질문이 묻힌다.
- 높은 우선순위: 답에 따라 설계·구현 방향이 완전히 달라지는 질문 (예: "동시 주문 시 재고 처리는 어떻게 하나요?")
- 낮은 우선순위: 세부 문구나 UI 디테일에 관한 질문 (예: "버튼 색깔이 이게 맞나요?") — 별도 채널로 옮긴다
질문을 비난이 아니라 정보로 전달한다
같은 지적도 표현에 따라 회의 분위기가 완전히 달라진다.
| 비난처럼 들리는 표현 | 정보 전달형 표현 |
|---|---|
| "이거 빠졌는데요?" | "동시에 두 명이 주문하는 경우는 어떻게 처리할지 궁금합니다" |
| "이 요구사항 이상한데요" | "이 문장을 두 가지로 읽을 수 있을 것 같은데, 어느 쪽이 맞을까요?" |
| "이거 생각 안 하신 거죠?" | "이 경우도 범위에 포함되나요, 아니면 다음 단계로 미루나요?" |
정보 전달형 표현의 공통점은 "당신이 놓쳤다"가 아니라 "내가 확인하고 싶다"는 프레임이다. 이 원칙은 모듈 6(결함 관리와 보고)에서 결함을 전달할 때도 똑같이 적용된다 — 지금부터 익혀두면 나중에 자연스럽게 이어진다.
리뷰의 형식은 다양하다
가볍게는 회의 중 화면 공유로 함께 읽는 **워크스루(Walkthrough)**부터, 역할을 나눠 정해진 체크리스트로 검토하는 **인스펙션(Inspection)**까지 형식이 다양하다. 형식이 무거울수록 더 철저하지만 시간이 오래 걸린다. 어떤 형식을 언제 쓰는지, 그리고 국제 표준이 이를 어떻게 정의하는지는 모듈 8(ISO/IEC/IEEE 29119)에서 자세히 다룬다 — 지금은 "가벼운 리뷰부터 무거운 리뷰까지 스펙트럼이 있다"는 것만 가져간다.
실무에서 왜 필요한가
요구사항 리뷰는 시간에 쫓겨 형식적으로 흘러가기 쉬운 회의다. 참석자가 준비 없이 들어오면 "질문 있나요?"에 침묵만 흐르고, 정작 문제는 개발이 끝난 뒤 테스트 단계에서 터진다 — 모듈 1에서 배운 비용 곡선이 그대로 실현되는 순간이다. 준비된 질문 3개를 우선순위대로, 비난이 아닌 정보 요청으로 던지는 것만으로도 리뷰 회의의 실질적 효과가 크게 달라진다. 이건 QA가 "테스트나 하는 사람"이 아니라 "제품 방향에 영향을 주는 사람"으로 인식되는 계기이기도 하다.
실습 과제
과제 1 — 질문 우선순위화 (10분)
다음 요구사항을 읽고, 떠오르는 질문을 최소 4개 적은 뒤 높은 우선순위 2개와 낮은 우선순위 2개로 나눈다.
"사용자는 리뷰를 작성할 수 있다. 리뷰에는 별점과 텍스트가 포함된다."
과제 2 — 표현 바꾸기 (10분)
다음 세 문장을 비난처럼 들리지 않는 정보 전달형 질문으로 바꿔 쓴다.
- "이거 테스트 안 해보신 거 티 나는데요."
- "요구사항이 왜 이렇게 애매하게 적혀있죠?"
- "이 부분 완전히 빠뜨리셨네요."
자가 체크리스트
- 준비 없이 리뷰에 참여했을 때의 위험을 설명할 수 있다
- 질문을 높은/낮은 우선순위로 나눌 수 있다
- 비난형 표현을 정보 전달형 표현으로 바꿔 쓸 수 있다
- 리뷰 형식이 워크스루부터 인스펙션까지 스펙트럼으로 존재한다는 것을 안다
흔한 실수
- 회의 중 즉흥적으로 질문을 찾으려 한다. 모호함과 누락은 미리 읽고 분석해야 보인다. 회의는 "찾는 자리"가 아니라 "미리 찾은 걸 확인받는 자리"다.
- 모든 질문을 우선순위 없이 다 던진다. 회의 시간은 한정적이다. 중요한 질문이 사소한 질문들 사이에 묻히면 놓치기 쉽다.
- 질문이 비난으로 들려서 방어적인 반응을 유발한다. 같은 내용도 표현 하나로 회의 분위기가 협력적이 될 수도, 대립적이 될 수도 있다.
참고 자료
- ISTQB Foundation Level Syllabus — Static Testing — 리뷰 유형(비공식 리뷰, 워크스루, 기술 리뷰, 인스펙션)의 공식 분류
- Gerald Weinberg, Perfect Software and Other Illusions About Testing — 소프트웨어 리뷰와 커뮤니케이션에 대한 고전적 통찰