요구사항 문서를 능동적으로 읽는 법

개념

같은 문장을 두 사람이 읽는다

기획 문서에 이런 한 줄이 있다고 하자.

"사용자는 주문을 취소할 수 있다."

이 한 줄을 읽은 두 QA의 머릿속을 나란히 들여다보자.

민수 — "아, 주문 취소 기능이 들어가는구나. 취소 버튼을 눌러서 주문이 취소되는지 확인하면 되겠네. 테스트 케이스 한 줄 추가하고 다음 문장으로."

지연 — "잠깐. 여기서 사용자가 누구지? 주문한 본인만인가, 같은 계정을 공유하는 가족도 되나, 고객센터 상담원이 대신 취소해주는 경로도 있나? 취소는 정확히 어떤 상태로 바뀌는 거지? 결제 취소까지 자동으로 따라가나, 주문만 취소 상태가 되고 환불은 따로 도는 건가? 할 수 있다는 언제까지 할 수 있다는 뜻이지? 배송이 시작된 뒤에도? 이미 출고됐다면? 그리고 취소를 눌렀는데 결제사 서버가 응답하지 않으면 사용자 화면에는 뭐가 보이지?"

두 사람이 읽은 문장은 같다. 다른 것은 읽는 방식 이다. 그리고 이 차이는 2주 뒤에 아주 구체적인 형태로 드러난다.

레슨 1에서 배운 일찍 찾을수록 싸다 는 곡선이 여기서 실현된다. 지연이 쓴 것은 코드 한 줄이 아니라 질문 스무 개였고, 그게 며칠치 재작업을 없앴다.

수동적 읽기 vs 능동적 읽기

수동적 읽기는 문장을 있는 그대로 받아들인다. "사용자가 프로필 사진을 업로드할 수 있다"를 읽고 "업로드 기능을 만들면 되는구나"로 끝낸다. 문서를 정보를 받는 창구 로 대한다.

능동적 읽기는 문장을 읽으면서 계속 질문을 던진다. 문서를 정보를 받는 창구가 아니라 아직 완성되지 않은 초안 으로 대한다. 같은 문장을 능동적으로 읽으면 이런 질문들이 나온다.

• 파일 형식은 무엇을 허용하는가? (JPG만? PNG도? GIF는? HEIC는?)
• 파일 크기 제한이 있는가? 넘으면 막는가, 자동으로 줄이는가?
• 업로드 중 실패하면 어떻게 되는가? 다시 시도할 수 있는가?
• 이미 사진이 있는 상태에서 다시 업로드하면 기존 사진은 어떻게 되는가?
• 업로드 권한은 누구에게 있는가? (본인만? 관리자도 가능한가?)
• 부적절한 이미지를 올리면? 검수 절차가 있는가, 신고 기능이 있는가?

이 질문들은 요구사항 문서 어디에도 안 적혀 있을 수 있다. 적혀 있지 않다는 것이 "신경 안 써도 된다"는 뜻이 아니다 — 개발자가 코드를 짜다가 혼자 결정하게 되거나, 아무도 결정하지 않은 채 구현이 끝나버릴 수 있다는 뜻이다.

여기서 핵심을 하나만 가져간다면 이것이다. 요구사항 문서에 없는 내용도 언젠가 누군가는 반드시 결정한다. 그 결정을 회의 테이블 위에서 할 것인지, 개발자 자리에서 조용히 할 것인지, 아니면 출시 후 CS 문의를 받고 나서 할 것인지의 차이만 있을 뿐이다. 능동적 읽기는 그 결정을 가장 싼 시점으로 끌어오는 기술 이다.

쉬운 비유로 다시 보기 — 레시피

전문 용어를 다 걷어내고 요리 레시피 한 줄로 생각해보자.

"달걀을 적당히 익힌 뒤 소금으로 간한다."

레시피를 쓴 사람은 20년 경력의 요리사다. 그 사람 머릿속에서 이 문장은 전혀 모호하지 않다. 자기 부엌, 자기 프라이팬, 자기가 늘 쓰는 중불이 이미 전제로 깔려 있기 때문이다. 쓴 사람에게는 완벽한 문장 이다.

그런데 이 레시피를 처음 요리하는 사람이 받으면 질문이 쏟아진다.

• 적당히 가 몇 분인가? 반숙인가 완숙인가?
• 불 세기는? 센 불에서 1분과 약한 불에서 5분은 완전히 다른 결과다
• 달걀은 냉장고에서 막 꺼낸 것인가, 실온인가?
• 소금으로 간한다 는 몇 꼬집인가?
• 익히다가 노른자가 터지면 실패인가, 그대로 진행해도 되는가?

여기서 두 가지를 알 수 있다.

첫째, 모호함은 글쓴이의 실력 부족이 아니다. 20년 경력 요리사가 대충 써서 그런 게 아니라, 자기에게 너무 당연한 것은 원래 글로 안 적힌다. 기획서도 똑같다. 기획자 머릿속에는 정책이 다 있는데, 그중 "당연한" 부분이 문서에서 빠진다.

둘째, 질문을 던질 수 있는 사람은 요리사가 아니라 처음 요리하는 사람이다. 당연하다고 느끼지 않기 때문에 물을 수 있다. QA가 요구사항 리뷰에서 가치를 만드는 지점이 정확히 여기다. 기획자보다 도메인을 더 잘 알아서가 아니라, 당연하게 느끼지 않는 위치에 서 있기 때문 이다.

이 레시피 비유를 기억해두면 이 모듈 전체가 훨씬 편해진다. 다음 레슨의 "테스트 가능한 요구사항"은 적당히 를 "중불에서 3분"으로 바꾸는 일이고, 그다음 레슨의 "모호함 찾기"는 적당히 같은 단어를 문서에서 찾아내는 일이다.

다섯 가지 질문 틀

질문을 잘 던지려면 감이 아니라 틀이 있어야 한다. 모든 요구사항 문장에 아래 다섯 질문을 습관적으로 던지면 빠진 부분이 눈에 잘 들어온다.

표의 마지막 칸에 나온 동시성 은 "여러 사람이 같은 것을 동시에 건드릴 때" 를 가리킨다. 두 사람이 같은 좌석을 같은 순간에 예약하면 어떻게 되는가 — 혼자 써 볼 때는 절대 안 보이고, 사용자가 늘면 반드시 터지는 종류다.

다섯 개를 순서대로 외우는 게 부담이라면 "누가·무엇을·언제·어떻게"까지는 육하원칙이라 자연스럽고, 마지막 예외는 하나만 더 붙였다고 기억하면 된다. 그리고 실무에서 가장 많은 결함이 나오는 곳은 언제나 마지막 칸이다.

사례 연구 — 한 문장에서 질문 스물세 개

앞에 나온 그 문장으로 실제로 해보자. 다섯 질문을 하나씩 적용하며 나오는 질문을 전부 적어본다.

"사용자는 주문을 취소할 수 있다."

① 누가 — 주어인 사용자 를 의심한다.

1. 주문한 본인만 취소할 수 있는가?
2. 비회원 주문(주문번호+전화번호로 조회)도 취소가 되는가?
3. 고객센터 상담원이 사용자를 대신해 취소할 수 있는가? 그 경로는 어디인가?
4. 관리자가 강제로 취소하는 경우(재고 부족, 이상 거래)도 이 요구사항에 포함되는가?
5. 탈퇴한 사용자의 주문은 누가 취소하는가?

② 무엇을 — 동사인 취소 를 의심한다.

6. 취소하면 주문 상태가 정확히 무엇으로 바뀌는가? (취소완료? 취소요청? 취소처리중?)
7. 결제 취소(환불)까지 자동으로 이어지는가, 별도 프로세스인가?
8. 부분 취소가 되는가? 세 개 주문 중 하나만 취소할 수 있는가?
9. 사용했던 쿠폰과 적립금은 돌아오는가? 쿠폰 유효기간이 이미 지났다면?
10. 재고는 즉시 복구되는가?

③ 언제 — 할 수 있다 의 시점 조건을 의심한다.

11. 결제 완료 직후부터 가능한가? 결제 진행 중(승인 대기)에는?
12. 배송 준비중까지만 가능한가, 출고 후에도 가능한가?
13. 배송 완료 후에는 취소가 아니라 반품으로 분류되는가? 그 경계는 어느 상태값인가?
14. 취소 가능 기한이 있는가? (예: 주문일로부터 7일)
15. 예약 주문이나 정기 배송처럼 결제 시점이 다른 주문은 어떻게 되는가?

④ 어떻게 — 경로와 형태를 의심한다.

16. 취소 버튼은 어디에 있는가? 주문 상세 화면만? 주문 목록에서도?
17. 취소 사유를 입력받는가? 필수인가 선택인가? 사유 목록은 누가 정하는가?
18. 확인 팝업이 뜨는가? 사용자가 실수로 누르는 것을 어떻게 막는가?
19. 취소 결과를 알림(푸시·문자·이메일)으로 알려주는가?
20. 앱과 웹 모두에서 되는가? 앱에만 있는 경로가 있는가?

⑤ 예외는 — 실패와 경계를 의심한다.

21. 결제사 서버 오류로 환불이 실패하면 주문 상태는 어떻게 되는가? 사용자에게는 뭐라고 보이는가?
22. 취소 버튼을 두 번 빠르게 누르면? 환불이 두 번 되지는 않는가?
23. 사용자가 취소를 누른 순간 창고에서 출고 처리가 동시에 일어나면 어느 쪽이 이기는가?

한 문장에서 스물세 개. 이게 능동적 읽기의 실제 밀도다. 처음에는 "이렇게까지 해야 하나" 싶지만, 이 중 몇 개가 실제 결함으로 이어지는지 보면 생각이 달라진다.

스물세 개를 전부 회의에서 물어보라는 뜻은 아니다. 그건 오히려 역효과다. 여기서 할 일은 일단 다 뽑아낸 뒤 리스크 순으로 추리는 것 이고, 추리는 방법과 회의에서 전달하는 방법은 이 모듈 마지막 레슨과 모듈 4(리스크 기반 테스트)에서 이어서 다룬다. 지금 단계의 목표는 스물세 개를 뽑아낼 수 있는 눈 을 만드는 것이다.

왜 기획자는 해피 패스만 쓰는가

해피 패스(happy path) 는 "아무 문제 없이 잘 풀리는 경우" 를 가리키는 말이다. 돈도 충분하고, 통신도 멀쩡하고, 사용자가 순서대로 누르는 경우. 문서에 적히는 것은 거의 언제나 이 경우뿐이다.

여기서 QA가 흔히 빠지는 함정이 있다. 질문이 스물세 개나 나오는 문서를 보면 "기획자가 일을 대충 했다"는 생각이 들기 쉽다. 이 생각은 틀렸고, 무엇보다 실무에서 손해다. 구조적인 이유를 알아두면 대화의 온도가 달라진다.

첫째, 예외를 상상하는 것은 원래 어려운 일이다. 사람의 머리는 목표를 향한 하나의 흐름을 그리도록 되어 있다. 기획자가 "주문 취소"를 떠올릴 때 머릿속에서는 사용자가 버튼을 누르고 취소되는 장면이 재생된다. 결제사 서버가 죽는 장면은 재생되지 않는다. 이건 성실함의 문제가 아니라 인지의 기본 작동 방식이다.

둘째, 기획자는 이미 다른 것을 보고 있다. 기획자의 주된 책임은 "이 기능이 사용자에게 가치가 있는가", "우선순위가 맞는가", "비즈니스 지표가 개선되는가"다. 그 판단만으로도 하루가 다 간다. 예외 케이스를 100개 나열하는 일은 그 사람의 성과 지표에 잡히지 않는다.

셋째, 문서 작성에 쓸 수 있는 시간이 애초에 짧다. 스프린트 일정 안에서 기획 문서를 완결적으로 쓰는 조직은 거의 없다. 모든 예외를 문서에 적으려면 문서가 세 배로 길어지는데, 그러면 아무도 안 읽는다. 읽히는 문서와 완전한 문서는 상충한다.

넷째, 도메인 지식이 이미 머릿속에 있어서 안 적힌다. 앞의 레시피 비유 그대로다. "당연히 배송 시작하면 취소 안 되죠"가 기획자에게는 상식이라 문서에 쓸 생각조차 안 든다. 그런데 그 "상식"은 회사마다 다르고, 신입 개발자에게는 상식이 아니다.

그래서 이 구도는 누구의 잘못이 아니라 역할 분담 으로 이해하는 게 맞다.

QA가 예외를 잡아내는 것은 기획자의 부족함을 메우는 일이 아니라, 애초에 QA가 맡은 몫 이다. 이 관점을 가지고 있으면 질문의 어투부터 달라진다. "이거 안 써 있는데요?"가 아니라 "출고 후 취소는 어떻게 처리할까요? CS 쪽에 미리 알려둘 것 같아서요"가 나온다. 표현을 바꾸는 구체적인 방법은 이 모듈의 리뷰 회의 레슨에서 따로 연습한다.

요구사항은 문서 한 종류가 아니다

실무에서 요구사항은 깔끔한 명세서 한 장으로 오지 않는다. 오히려 한 기능의 요구사항이 대여섯 곳에 흩어져 있는 것이 정상 이다.

표에 처음 나온 말 셋을 짚고 가자. PRD 는 "무엇을 왜 만드는가" 를 적은 기획 문서를 가리키는 흔한 이름이고, 사용자 스토리 는 "누가, 무엇을, 왜 원하는가" 를 한 줄로 적은 요구사항 형식이다("구매자로서 주문을 취소하고 싶다, 잘못 주문했을 때 되돌리기 위해"). 목업 은 실제로 동작하지는 않는 화면 그림이다 — Figma 는 그 그림을 그리는 도구 이름이다.

디자인 목업이 특히 중요하다. 기획 문서에는 없는 정보가 화면에는 그려져 있는 경우 가 많기 때문이다. "취소 사유 선택" 드롭다운이 목업에는 있는데 문서에는 한 줄도 없다면, 그 목록의 항목이 무엇이고 어느 것이 기본값인지는 아무도 정하지 않은 상태일 가능성이 높다. 반대로 문서에는 있는데 목업에는 버튼이 없다면 진입 경로 자체가 빠진 것이다. 문서와 목업의 차이 자체가 질문거리 다.

능동적 읽기는 문서 한 장을 잘 읽는 기술이 아니라, 이 흩어진 정보를 하나로 모아 서로 어긋나는 곳을 찾아내는 습관 이기도 하다.

흩어진 요구사항을 모으는 법 — 요구사항 소스 목록

머릿속으로 모으려 하면 반드시 새어나간다. 실무에서 잘 통하는 방법은 아주 단순하다. 기능 하나당 소스 목록 표 하나를 만드는 것이다.

이 표가 주는 이득은 세 가지다.

• 문서화되지 않은 결정을 추적할 수 있다. 슬랙과 회의에서 나온 합의는 일주일이면 아무도 기억하지 못한다. 표에 한 줄 적어두면 "그때 이렇게 정했었죠"의 근거가 된다.
• 불일치가 눈으로 보인다. 위 표에서 이미 두 건이 잡혔다. 이건 그대로 리뷰 회의 안건이 된다.
• 나중에 요구사항이 바뀔 때 어디를 다시 봐야 하는지 알 수 있다. 이 연결이 이 모듈 뒤쪽의 추적성 으로 이어진다. 추적성이란 요구사항 한 줄과 그것을 확인하는 테스트를 서로 이어 두어, 한쪽이 바뀌면 다른 쪽에서 무엇을 다시 봐야 하는지 바로 찾을 수 있게 해 두는 것이다(레슨 5).

한 가지 실무 팁을 더하면, 구두로 합의된 내용은 그 자리에서 슬랙에 한 줄로 남기는 것 이 가장 확실하다. "방금 회의에서 출고 후에는 취소가 아니라 반품으로 처리하기로 정한 것 맞을까요?" 한 문장이면 된다. 이건 기록이면서 동시에 재확인이고, 누군가 다르게 이해했다면 바로 그 자리에서 드러난다.

코드와 API 요구사항에도 같은 틀을 쓴다

다섯 질문 틀은 화면 기능에만 쓰는 도구가 아니다. 백엔드 요구사항에도 그대로 적용된다. 오히려 여기서 더 잘 먹힌다.

"주문 취소 API는 취소에 성공하면 200을 반환한다."

여기서 멱등성 질문(같은 요청을 두 번 보내면 어떻게 되는가)은 API 요구사항에서 거의 항상 빠지는 항목이다. 그런데 네트워크가 불안하면 클라이언트가 재시도를 하고, 사용자는 버튼을 두 번 누른다. 즉 같은 요청이 두 번 오는 것은 예외가 아니라 일상 이다.

스테이지 3에서 코드 읽기를 배우고 나면 이 틀을 코드에도 그대로 쓸 수 있다. 조건문 하나를 보고 "이 조건의 반대쪽은 요구사항 어디에 적혀 있지?"라고 묻는 것이 바로 코드에 적용한 능동적 읽기다. 다만 지금 단계에서는 API 문서에 쓰인 문장 하나에 다섯 질문을 던져보는 것 만으로 충분하다.

질문은 반드시 기록으로 남긴다

능동적 읽기의 결과물은 머릿속의 찜찜함이 아니라 질문 목록 이어야 한다. 읽으면서 떠오른 질문은 30분이면 사라지고, 사라진 질문은 3주 뒤 결함으로 돌아온다. 형식은 거창할 필요 없다.

원문 문장 칸 이 있는 이유가 있다. 나중에 요구사항이 바뀌었을 때 어느 질문을 다시 물어야 하는지 바로 찾을 수 있기 때문이다. 그리고 답변 칸이 비어 있는 항목 이 곧 지금 팀이 모르고 있는 것의 목록이다 — 이 표가 그대로 리뷰 회의 안건지가 되고, 답변이 채워지면 그다음 레슨의 수용 기준 재료가 된다. 수용 기준 은 "이 조건들을 만족하면 다 된 것으로 친다" 를 미리 글로 못 박아 둔 목록이다 — 다 만든 뒤에 "이게 된 거냐" 로 싸우지 않기 위해서다 (레슨 4).

어디까지 파고들 것인가

마지막으로 균형을 하나 잡고 가자. 능동적 읽기를 배우면 처음에는 모든 문장에서 스무 개씩 질문을 만들고 싶어진다. 문장이 40개인 문서라면 질문이 800개가 되고, 그 목록은 아무도 읽지 않는다.

읽으면서 다음 세 가지에 해당하는 문장에 시간을 더 쓰면 효율이 좋다.

• 돈·개인정보·권한이 걸린 문장. 결제, 환불, 정산, 탈퇴, 권한 부여. 여기서 나는 결함은 되돌리기가 가장 어렵다.
• 상태가 바뀌는 문장. "로 변경된다", " 처리된다". 상태가 있는 곳에는 항상 "그 중간에 다른 일이 일어나면?"이 따라붙는다.
• 여러 역할이 등장하는 문장. 등장인물이 둘 이상이면 권한 조합이 생긴다.

반대로 "목록은 최신순으로 정렬된다" 같은 문장은 질문 한두 개면 충분하다. 모든 문장을 똑같이 깊게 읽는 것은 능동적 읽기가 아니라 시간 낭비 다. 어디에 깊이를 배분할지 정하는 감각은 모듈 4의 리스크 기반 테스트에서 본격적으로 다룬다.

실무에서 왜 필요한가

요구사항이 확정되기 전에만 할 수 있는 일이다. PM이나 기획자는 대부분 정상적으로 잘 되는 경우(해피 패스)를 기준으로 요구사항을 쓴다. 실패 상황, 권한 예외, 경계 조건은 의도적으로 빠뜨리는 게 아니라 쓰는 사람이 미처 생각하지 못해서 빠진다. 이걸 개발이 시작되기 전에 질문으로 만들어내는 것이 QA가 상류에서 할 수 있는 가장 저비용 고효율 활동이다. 레슨 1에서 배운 "일찍 찾을수록 싸다"가 바로 여기서 실현된다.

테스트 설계의 재료가 여기서 만들어진다. 능동적으로 읽으며 만든 질문 스물세 개는 답변을 받는 순간 스물세 개의 테스트 케이스 후보가 된다. 반대로 수동적으로 읽으면 테스트 설계 단계에서 "뭘 테스트해야 하지"를 백지에서 다시 고민하게 된다. 요구사항을 읽는 시간과 테스트를 설계하는 시간은 따로 있는 것이 아니라 겹쳐 있다.

"이게 버그인가 스펙인가" 논쟁이 사라진다. QA 업무에서 가장 소모적인 갈등이 이것이다. 출고 후 취소가 막혀 있을 때, 정책으로 정해둔 적이 없으면 QA는 결함이라 하고 개발자는 의도라고 한다. 앞 단계에서 질문이 오갔다면 이 논쟁 자체가 생기지 않는다. 레슨 1에서 본 세 번째 결함 유형(이해관계자 간 기대 불일치)을 미리 없애는 방법이 바로 능동적 읽기다.

QA의 신뢰가 여기서 쌓인다. 결함을 많이 찾는 QA보다, 만들기 전에 좋은 질문을 던지는 QA가 팀에서 더 크게 평가받는다. 전자는 이미 만들어진 것을 되돌리게 하고 후자는 애초에 안 만들게 하기 때문이다. 실제로 경력이 쌓일수록 QA의 업무 비중은 "테스트 실행"에서 "상류 개입"으로 옮겨간다.

실습 과제

과제 1 — 다섯 질문 적용하기 (10분)

다음 요구사항 문장에 다섯 가지 질문(누가/무엇을/언제/어떻게/예외는)을 각각 적용해 최소 10개 의 질문을 만들어본다. 사례 연구처럼 질문마다 어느 칸에서 나왔는지 표시한다.

"사용자는 게시글에 댓글을 작성할 수 있다."

과제 2 — 수동/능동 읽기 대비하기 (10분)

아래 문장을 두 번 읽는다. 첫 번째는 수동적으로 읽고 떠오른 테스트 케이스를 적고, 두 번째는 다섯 질문 틀을 대며 다시 읽는다. 두 결과물의 개수와 성격 을 비교한다.

"관리자는 회원 등급을 변경할 수 있다."

과제 3 — 요구사항 소스 목록 만들기 (10분)

최근에 참여했던(또는 최근에 써본) 서비스의 기능 하나를 골라, 본문의 요구사항 소스 목록 표를 그대로 만들어본다. 소스를 최소 4개 채우고, 그중 문서화되지 않은 소스(구두 합의, 슬랙, 목업) 를 반드시 하나 이상 포함한다. 각 소스에서 어떤 정보가 나왔을지, 어긋날 만한 지점은 어디일지 한 줄씩 적는다.

과제 4 — API 문장에 다섯 질문 던지기 (10분)

아래 API 요구사항 한 줄에 다섯 질문을 적용해 최소 6개의 질문을 만든다.

"회원가입 API는 이메일과 비밀번호를 받아 사용자를 생성한다."

과제 5 — 실제 문서에서 해피 패스 비율 세어보기 (선택, 15분)

지금 팀에서 쓰는 기획 문서 하나를 열어, 문장을 정상 흐름 / 예외·실패 흐름 두 가지로 분류해 개수를 센다. 대부분의 문서에서 예외 흐름은 전체의 10~20%를 넘지 않는다.

그 비율을 확인한 뒤, 예외 흐름이 가장 부족한 기능 하나를 골라 질문 목록 표를 만들어본다. 이 표는 다음 레슨들에서 계속 쓰는 재료가 된다.

자가 체크리스트

• 수동적 읽기와 능동적 읽기의 차이를 예시로 설명할 수 있다
• 다섯 가지 질문 틀(누가/무엇을/언제/어떻게/예외는)을 요구사항 문장에 적용할 수 있다
• 요구사항 문장 하나에서 질문 10개 이상을 만들어낼 수 있다
• 요구사항이 문서 한 종류로만 오지 않는다는 것을 알고, 소스를 5개 이상 나열할 수 있다
• 문서화되지 않은 요구사항(구두 합의, 슬랙)을 추적하는 방법을 안다
• "적혀 있지 않다"가 "신경 안 써도 된다"는 뜻이 아닌 이유를 설명할 수 있다
• 기획자가 해피 패스만 쓰게 되는 구조적 이유를 세 가지 이상 말할 수 있다
• 다섯 질문 틀을 API 요구사항에도 적용할 수 있다
• 어떤 문장에 깊이를 더 배분해야 하는지 기준을 말할 수 있다
• 능동적 읽기의 결과물이 질문 목록이라는 것을 알고, 그 형식을 만들 수 있다

흔한 실수

• 요구사항을 한 번 훑어보고 바로 테스트 케이스 작성으로 넘어간다. 질문을 만드는 단계를 생략하면, 나중에야 빠진 조건을 발견해 재작업이 생긴다.
• 질문을 마음속으로만 하고 기록하지 않는다. 능동적 읽기의 결과물은 질문 목록이어야 한다 — 이게 뒤에 나올 리뷰 회의 레슨에서 쓸 재료가 된다.
• 모든 질문을 한 번에 PM에게 쏟아낸다. 질문이 너무 많으면 무엇이 정말 중요한지 묻힌다. 리스크가 큰 질문부터 추리는 법은 모듈 4(리스크 기반 테스트)와 연결된다.
• 모든 문장을 똑같은 깊이로 읽는다. 돈·권한·상태 변화가 걸린 문장에 시간을 더 쓰고, 나머지는 가볍게 지나가야 전체를 다 볼 수 있다.
• 기획자 탓으로 돌린다. "문서가 부실하다"는 태도는 협업을 망가뜨리고, 다음번에 QA를 앞 단계 회의에 부르지 않게 만든다. 예외를 찾는 것은 원래 QA의 몫이다.
• 문서만 읽고 목업·슬랙·기존 코드를 안 본다. 실제 결정의 절반 이상은 문서 밖에 있다. 문서와 목업이 어긋나는 지점 자체가 좋은 질문거리다.
• 답이 없는 질문을 그냥 넘긴다. 아무도 답을 모르는 질문이 가장 위험하다. "아직 안 정해짐"이라고 적어두는 것만으로도 그 항목은 추적 대상이 된다.
• 질문을 결함처럼 던진다. 요구사항 단계의 질문은 아직 아무것도 틀리지 않은 상태에서 던지는 것이다. "이건 잘못됐는데요"가 아니라 "이 경우는 어떻게 할까요"가 맞는 어투다.

참고 자료

• ISTQB Foundation Level Syllabus — Requirements Analysis — 요구사항 분석에서 테스터의 역할
• Gojko Adzic, Specification by Example — 요구사항을 구체적 예시로 바꿔 모호함을 줄이는 접근법의 대표 저작
• Karl Wiegers, Software Requirements — 요구사항 유도(elicitation)와 누락 탐지의 고전
• Michael Bolton, Testing vs. Checking — 질문을 던지는 활동(testing)과 확인하는 활동(checking)의 구분