요구사항 리뷰 회의 참여법과 질문 설계

개념

이 모듈의 마지막 관문 — 찾아낸 것을 회의실에서 통과시키기

앞선 다섯 레슨에서 요구사항을 능동적으로 읽고(레슨 1), 테스트할 수 있는 형태인지 판단하고(레슨 2), 모호함과 누락을 찾아내고(레슨 3), 수용 기준으로 다시 쓰고(레슨 4), 추적성을 붙이는 법(레슨 5)을 배웠다. 다섯 가지 모두 혼자 책상에서 하는 일 이었다.

이 레슨은 그 결과물을 사람들 앞에 올리는 법이다. 그리고 여기가 실제로 가장 많이 무너지는 지점이다. 노트에는 날카로운 질문이 열두 개 적혀 있는데 회의가 끝나고 나면 그중 하나도 논의되지 않은 채 남아 있는 일이, 신입 QA에게는 아주 흔하다.

비유하자면 재료 손질과 같다. 아무리 잘 손질해도 식탁에 올리지 않으면 아무도 먹지 않는다. 그리고 한꺼번에 열두 접시를 쏟아 놓으면 사람들은 무엇부터 집어야 할지 몰라 결국 아무것도 먹지 않는다. 좋은 질문 열두 개를 적어온 사람보다, 질문 세 개를 순서와 표현까지 정해서 들어온 사람이 회의를 바꾼다.

요구사항 리뷰는 원래 무엇을 하는 자리인가

요구사항 리뷰는 코드가 한 줄도 나오기 전에, 문서 단계에서 결함을 찾는 활동이다. 프로그램을 실행하지 않고 산출물을 검토하기 때문에 정적 테스팅으로 분류되고, 모듈 1에서 배운 결함 비용 곡선의 가장 왼쪽 끝에 해당한다 — 같은 결함을 여기서 잡으면 몇 분, 운영에서 잡으면 며칠이 든다.

그런데 실무에서 이 회의는 자주 문서 승인식으로 오해된다. 발표자가 읽고, 아무도 반대하지 않고, "그럼 확정하겠습니다"로 끝난다. 리뷰의 진짜 목적은 승인이 아니라 다음 세 가지다.

세 번째가 특히 QA의 몫이다. 기획자와 개발자는 "만들 수 있는가"에 집중하지만, QA는 "확인할 수 있는가" 를 본다. 확인할 수 없는 문장은 대부분 아직 아무도 정하지 않은 것이 남아 있다는 신호다(레슨 2의 테스트 가능성).

회의가 끝났을 때 성패는 이렇게 갈린다.

준비 없이 참여하면 생기는 일

준비 없이 리뷰에 들어가면 대부분 이렇게 흘러간다. 발표자가 요구사항을 쭉 읽고, "질문 있으신가요?"라고 물으면 정적이 흐르고, 회의는 형식적으로 끝난다. 문제는 이 조용함이 "요구사항이 완벽하다"는 뜻이 아니라 그 자리에서 즉흥적으로 문제를 찾기는 원래 어렵다 는 뜻이라는 것이다.

이유는 인지적인 것이다. 발표자가 문장을 읽는 속도는 우리가 그 문장의 예외 상황을 상상하는 속도보다 훨씬 빠르다. "사용자는 주문을 취소할 수 있다"는 한 문장이 지나가는 데 3초가 걸리지만, "배송이 시작된 뒤에도 되나", "부분 취소는 되나", "결제 수단이 포인트면 환불은 어디로 가나"를 떠올리는 데는 그보다 오래 걸린다. 회의 중에는 늘 문장이 먼저 지나간다.

그래서 원칙은 하나다. 회의는 문제를 찾는 자리가 아니라, 미리 찾아둔 문제를 확인받는 자리다. 모호함과 누락은 레슨 1·3의 방법으로 미리 읽고 분석해야 보인다.

워크스루와 인스펙션 — 무게가 다른 두 가지 리뷰

리뷰라는 말 하나에 아주 가벼운 것부터 아주 무거운 것까지 다 들어 있다. 양쪽 끝을 먼저 잡아두면 중간은 저절로 감이 온다.

워크스루(Walkthrough) 는 저자가 문서를 화면에 띄우고 참석자와 함께 훑어 내려가는 형식이다. 저자가 직접 진행하고, 사전 준비가 거의 필요 없다. 목적은 결함 색출보다 이해 공유와 초기 피드백에 가깝다.

인스펙션(Inspection) 은 가장 무거운 형식이다. 저자가 아닌 별도 진행자(moderator)가 회의를 이끌고, 참석자는 회의 전에 문서를 각자 읽고 와야 하며, 정해진 체크리스트와 규칙에 따라 결함을 기록한다. 목적이 명확히 결함 검출과 그 수의 집계다. 아래 표의 품질 게이트 는 "여기를 통과해야 다음 단계로 넘어간다" 고 정해 둔 관문을 뜻한다.

이 둘 사이에 비공식 리뷰(동료 한 명에게 슬쩍 봐 달라고 하는 것)와 기술 리뷰(전문가들이 기술적 타당성을 따지는 것)가 놓인다. 형식이 무거울수록 더 많이 찾아내지만 그만큼 사람의 시간을 쓴다. 그래서 실무의 판단은 늘 이 문서가 틀렸을 때의 대가로 결정된다. 마케팅 배너 문구는 워크스루로 충분하고, 환불 정산 규칙은 인스펙션 값을 한다.

국제 표준이 리뷰 유형을 어떻게 정의하고 각 역할을 어떻게 규정하는지는 모듈 8(ISO/IEC/IEEE 29119)에서 자세히 다룬다. 지금은 가벼운 리뷰부터 무거운 리뷰까지 스펙트럼이 있고, 무거울수록 사전 준비가 필수가 된다는 감만 가져가면 충분하다.

우리 팀의 리뷰가 어느 쪽인지는 세 가지만 물어보면 알 수 있다. 회의 전에 문서가 배포되는가, 진행자가 저자인가 아닌가, 회의록에 담당자가 붙은 액션 아이템이 남는가. 셋 다 아니라면 사실상 비공식 리뷰이고, 그렇다면 QA가 준비해 가는 질문 목록 하나가 회의의 질을 통째로 끌어올린다.

리뷰 회의에도 역할이 있다

무거운 리뷰일수록 역할이 분명하다. 신입이라도 이 구조를 알고 들어가면 자기가 어디에 서 있는지 감이 잡힌다.

마지막 줄이 실전 팁이다. 발언이 부담스러운 시기에는 서기를 자원하면 좋다. 기록을 맡으면 "방금 그 부분, 결론이 A인가요 B인가요?"처럼 확인 질문을 던지는 것이 자연스러운 역할이 되고, 그 확인 질문이 사실상 가장 중요한 리뷰 질문인 경우가 많다. 게다가 회의록을 쓰는 사람이 액션 아이템의 문구를 정하게 되므로, 영향력은 오히려 크다.

준비 — 회의 전 30분에 하는 다섯 가지

1. 문서를 끝까지 한 번 통독한다. 이때는 지적하지 않고 전체 흐름만 잡는다.
2. 두 번째 읽으며 질문을 전부 적는다. 레슨 3의 모호함·누락 체크리스트를 그대로 쓴다. 여기서는 개수 제한 없이 다 적는다.
3. 우선순위를 매긴다. 아래 세 기준으로 판정한다.
4. 상위 세 개의 문장을 다듬는다. 실제로 말할 문장 그대로 적어둔다.
5. 가능하면 회의 전에 공유한다. 채널이나 문서 코멘트로 미리 던져 둔다.

우선순위는 취향이 아니라 기준으로 정한다.

• 높은 우선순위: 답에 따라 설계·구현 방향이 완전히 달라지는 질문 — "동시에 두 명이 마지막 재고 1개를 주문하면 어떻게 처리하나요", "취소 가능 기간이 결제일 기준인가요 배송 시작 기준인가요"
• 낮은 우선순위: 세부 문구나 UI 디테일 — "버튼 색이 이게 맞나요", "안내 문구 마침표를 붙이나요" — 회의에서 빼고 문서 코멘트나 채널로 옮긴다

그리고 질문 세 개 규칙을 권한다. 회의에서 입으로 던질 질문은 세 개까지만 고르고, 나머지는 문서 코멘트로 남긴다. 이유는 단순하다. 사람이 한 회의에서 기억하고 처리할 수 있는 새 논점이 대략 그 정도이기 때문이다. 열 개를 던지면 열 개가 다 흐려지지만, 세 개를 던지면 세 개가 다 결론에 도달한다.

질문을 비난이 아니라 정보로 전달한다

같은 지적도 표현에 따라 회의 분위기가 완전히 달라진다. 그리고 분위기가 나빠지면 정보가 덜 나온다 — 방어적으로 바뀐 저자는 "그건 나중에 정하죠"로 논점을 닫아버린다. 표현을 다듬는 것은 예의의 문제가 아니라 정보 수집 효율의 문제다.

오른쪽 문장들의 공통점은 네 가지다.

1. 주어가 사람이 아니라 문장·현상이다. "당신이 놓쳤다"가 아니라 "이 문장이 두 가지로 읽힌다"다.
2. 끝이 질문이나 요청으로 열려 있다. 단정으로 닫지 않으면 상대가 설명할 여지가 남는다.
3. 근거가 붙어 있다. 절 번호, 이전 이슈, 판정 기준 같은 것이 붙으면 개인 의견이 아니라 확인 요청이 된다.
4. 선택지를 준다. "포함인가요, 다음 단계인가요"처럼 답할 형태를 같이 주면 결론이 훨씬 빨리 난다.

이 원칙은 모듈 6(결함 관리와 보고)에서 결함을 전달할 때 그대로 다시 쓰인다. 지금 회의 문장으로 익혀두면 나중에 리포트 문장으로 자연스럽게 이어진다.

화상 회의와 채팅에서의 톤

요즘 리뷰는 상당수가 화상으로 진행된다. 화상에서는 표정과 어조가 거의 전달되지 않아서, 대면에서는 부드럽게 들렸을 문장이 차갑게 읽힌다. 특히 채팅으로 던지는 짧은 문장이 그렇다.

화상 리뷰에서 통하는 실전 요령 세 가지다.

• 끼어들기 대신 채팅을 쓴다. 발표 흐름을 끊지 않고 논점을 남길 수 있고, 기록으로도 남는다. 발표가 끊긴 틈에 "채팅에 두 개 남겼는데 볼까요"로 올리면 된다.
• 질문에 번호와 위치를 붙인다. "3.2절 관련 1번", "4절 관련 2번"처럼 적으면 진행자가 순서대로 처리하기 쉽다.
• 결론을 채팅에 한 줄로 되쓴다. "정리하면 결제일 기준, 부분 취소는 이번 범위 밖 — 맞을까요?" 이 한 줄이 나중에 회의록보다 정확한 근거가 된다.

신입 QA가 리뷰 회의에서 실제로 겪는 것들

앞의 내용을 다 알아도 실제 회의실에서는 잘 안 된다. 흔한 네 가지 상황과 처방이다.

1. 목소리가 작아 말이 묻힌다. 말을 꺼내려는 순간 다른 사람이 먼저 말하고, 두세 번 그러고 나면 포기하게 된다. 처방은 발성 연습이 아니라 경로를 바꾸는 것이다. 회의 전에 채널이나 문서 코멘트로 질문을 미리 공유해두면, 회의에서는 이미 텍스트로 존재하는 항목을 "아까 올린 두 번째 질문인데요"로 꺼내게 된다. 진행자가 대신 읽어주는 경우도 많다. 텍스트로 먼저 존재하는 질문은 묻히지 않는다.

2. 시니어가 이미 다 알고 있는 것 같아 위축된다. 그래서 "이건 나만 모르는 걸 거야"라고 판단하고 삼킨다. 그런데 한 사람이 헷갈린 문장은 대개 여러 사람이 헷갈린다. 요구사항의 모호함은 개인의 지식 부족이 아니라 문장의 결함이기 때문이다. 이때 쓰기 좋은 문장 형태가 있다. "제가 잘못 이해했을 수도 있는데요"로 시작하면 심리적 비용이 크게 내려가고, 실제로 문서에 문제가 있었을 때도 아무도 무안해지지 않는다.

3. 질문했더니 "그건 나중에 정하죠"로 끊긴다. 여기서 물러나면 그 질문은 영원히 사라진다. 물러나지 않는 방법은 반박이 아니라 기록 요청이다. "네, 그럼 이건 미정으로 회의록에 남겨둘게요. 누구에게 언제까지 확인하면 될까요?" 이 한마디가 질문을 액션 아이템으로 바꾼다.

4. 회의가 이미 결론으로 달려가고 시간이 없다. 이럴 때 질문을 통째로 포기하는 대신, 가장 비싼 것 하나만 고른다. "시간이 얼마 없으니 하나만 여쭐게요. 취소 기한 기준만 정해주시면 나머지는 코멘트로 남기겠습니다." 남은 질문은 문서 코멘트로 옮기고, 회의록에 "코멘트로 이관"이라고 적는다.

공통점이 보인다. 네 상황 모두 해법이 말을 더 잘하는 것이 아니라 채널을 바꾸거나 기록에 남기는 것이다. 신입에게 유리한 무기는 목소리가 아니라 글과 기록이다.

답이 그 자리에서 안 나올 때 — 액션 아이템으로 착지시키기

좋은 질문일수록 그 자리에서 답이 안 나오는 경우가 많다. 답이 바로 나온다면 애초에 별로 중요하지 않은 질문이었을 가능성이 높다. 미결정의 이유는 보통 셋 중 하나다.

세 경우 모두 그 자리에서 답을 내는 것이 목표가 아니다. 목표는 질문이 추적 가능한 상태로 남는 것이다. 그러려면 네 가지가 다 있어야 한다.

1. 무엇을 — 질문을 한 문장으로 (모호하면 나중에 아무도 못 알아본다)
2. 누가 — 반드시 사람 한 명. "기획팀"은 담당자가 아니다
3. 언제까지 — 날짜. "다음 주"가 아니라 특정 날짜
4. 어디에 — 회의록·이슈 트래커·요구사항 문서 코멘트 중 어디에 남기는지

회의 마지막 2분에 QA가 이 한마디를 하면 리뷰의 결과물이 완전히 달라진다.

"정리하면 오늘 확정된 건 A와 B이고, 미정 두 건은 취소 기한 기준(김OO, 25일)과 동시 주문 처리(박OO, 23일)입니다. 이 두 개는 답이 나와야 수용 기준을 확정할 수 있어서, 정해지면 알려주시면 제가 문서에 반영하겠습니다."

이 발언에는 세 가지가 들어 있다. 결론 요약, 담당자와 기한이 붙은 미결정 목록, 그리고 왜 그것이 필요한지의 근거(수용 기준을 못 쓴다). 마지막 근거가 있어야 "QA가 깐깐하게 군다"가 아니라 "그거 없으면 진행이 막힌다"로 들린다. 여기서 말한 수용 기준은 레슨 4에서 쓴 그 형식이고, 미결정 항목이 남은 요구사항은 레슨 5의 추적성 표에서 테스트가 아직 연결되지 않은 행으로 드러난다.

비동기 리뷰 — 문서에 코멘트를 다는 방식

요즘 실무에서 아주 흔한 형태다. 회의를 잡지 않고 요구사항 문서(Confluence, Notion, Google Docs, 이슈 트래커 등)에 각자 코멘트를 달고 저자가 답하는 방식이다. 원격·시차 근무가 늘면서 오히려 기본값이 된 팀도 많다.

비동기 리뷰를 잘 쓰는 요령은 이렇다.

• 문장에 정확히 앵커를 건다. 문서 상단에 뭉뚱그려 쓰지 말고, 문제가 되는 그 문장에 코멘트를 단다. 어느 문장인지 찾는 데 드는 시간이 사라진다.
• 한 코멘트에 한 질문만. 세 가지를 한 코멘트에 쓰면 저자는 보통 첫 번째만 답하고 닫는다.
• 답하기 쉬운 형태로 쓴다. "A인가요 B인가요"처럼 선택지를 주면 왕복이 한 번에 끝난다.
• 해결되면 스스로 닫는다. 열린 코멘트가 쌓이면 무엇이 남았는지 아무도 모른다. 닫으면서 "결론: 결제일 기준"이라고 한 줄 남긴다.

그리고 3회 왕복 규칙을 기억하면 좋다. 같은 코멘트 스레드에서 세 번 왕복했는데도 결론이 안 나면, 그건 글로 풀 문제가 아니라 15분 통화로 풀어야 할 문제다. 비동기의 최대 함정은 결론 없는 스레드가 길어지면서 서로 감정이 상하는 것이다. "이건 짧게 통화하는 게 빠를 것 같은데 15분 잡아도 될까요?"로 옮기는 판단이 실력이다.

사례 연구 — 같은 요구사항, 두 개의 리뷰

같은 요구사항 문서를 두고 두 개의 리뷰가 열렸다고 하자.

요구사항 4.1 — 사용자는 주문을 취소할 수 있다. 취소 시 결제 금액이 환불된다. 단, 배송이 시작된 주문은 취소할 수 없다.

리뷰 A — 준비 없이 들어간 회의. QA는 회의 5분 전에 문서 링크를 처음 열었다. 기획자가 4.1을 읽고 "질문 있으신가요?"라고 묻는다. QA는 뭔가 걸리는 느낌은 있지만 무엇인지 정리가 안 돼서 "네, 괜찮습니다"라고 답한다. 회의는 예정보다 10분 일찍 끝나고 모두 만족한다.

3주 뒤 테스트 단계. QA가 케이스를 쓰다가 막힌다. 부분 취소가 되는지 문서에 없다. 개발자에게 물으니 "그건 안 되는 걸로 만들었는데요"라고 하고, 기획자는 "당연히 되는 거 아니었어요?"라고 한다. 포인트로 결제한 주문의 환불처도 정해진 게 없어서, 개발자는 일단 포인트로 돌려주도록 만들어 두었는데 CS팀은 현금 환불을 기대하고 있었다. 결국 릴리즈가 일주일 밀리고, 이미 만든 환불 로직의 절반을 다시 짠다.

리뷰 B — 준비하고 들어간 회의. QA는 전날 문서를 두 번 읽고 질문 일곱 개를 뽑아, 그중 세 개를 골라 회의 전날 채널에 올려 두었다.

1. 배송 시작 시점의 기준이 무엇인가 — 송장 번호 등록 시점인가, 물류센터 출고 시점인가 (두 시점 사이에 보통 몇 시간 차이가 난다)
2. 부분 취소가 이번 범위에 포함되는가
3. 포인트·쿠폰이 섞인 결제의 환불은 무엇으로 돌아가는가

회의에서 1번은 그 자리에서 "송장 번호 등록 시점"으로 확정됐다. 2번은 기획자와 개발자의 답이 갈려서 미정으로 남았고, "부분 취소 이번 범위 포함 여부 결정 — 김OO — 8/25 — 문서 4.1 코멘트"로 액션 아이템이 됐다. 3번은 정산 담당자가 자리에 없어 "환불 수단 규칙 확인 — 박OO — 8/23 — 이슈 #412"로 남았다. 나머지 네 개 질문은 문서 코멘트로 옮겼다.

핵심은 리뷰 B의 QA가 더 똑똑했다는 것이 아니다. 전날 30분을 썼을 뿐이다. 그 30분이 일주일을 아꼈고, 이것이 모듈 1에서 배운 결함 비용 곡선의 가장 실감 나는 형태다.

실무에서 왜 필요한가

요구사항 리뷰는 QA가 가장 이른 시점에 개입할 수 있는 자리다. 테스트 실행 단계에서 아무리 잘해도 이미 만들어진 것에서 결함을 찾을 뿐이지만, 리뷰에서는 결함이 만들어지는 것 자체를 막는다. 모듈 1에서 본 비용 곡선의 가장 왼쪽 끝이 여기다. 리뷰 준비 30분이 재작업 일주일을 없애는 계산은 과장이 아니라 사례 연구에서 본 그대로다.

앞선 다섯 레슨의 결과물은 회의를 통과해야 효력이 생긴다. 모호함을 찾아내도(레슨 3) 문서가 안 바뀌면 그대로 개발된다. 수용 기준을 써도(레슨 4) 기획자가 동의하지 않으면 내 노트일 뿐이다. 리뷰 회의는 개인의 분석을 팀의 합의로 승격시키는 유일한 장치다.

이 자리에서 QA에 대한 팀의 인식이 결정된다. 개발이 끝난 뒤에만 나타나서 "안 됩니다"를 말하는 QA는 어떤 사람이 앉아도 품질 경찰처럼 보인다(모듈 1 레슨 6). 반대로 요구사항 단계에서 좋은 질문을 던지는 QA는 "테스트하는 사람"이 아니라 "제품 방향에 영향을 주는 사람" 으로 인식된다. 같은 능력이라도 등장 시점에 따라 평가가 갈린다.

여기서 익히는 표현 기술이 이후 모든 소통에 재사용된다. 비난이 아니라 정보로 전달하는 문장 형태는 결함 리포트(모듈 6), 릴리즈 판단 회의, 개발자와의 일상 대화에 그대로 쓰인다. 이건 회의 기술이 아니라 QA의 기본 문법이다.

채용시장에서의 위치

주니어 QA 채용에서 "요구사항 리뷰 참여 경험"은 지원자를 가르는 항목이다. 테스트 실행 경험은 대부분 갖고 있지만, 요구사항 단계에 개입해 본 사람은 훨씬 적기 때문이다. 면접에서 실제로 이렇게 물어본다.

이력서에도 표현 차이가 크다.

• 약한 표현: "요구사항 리뷰 회의에 참석했습니다."
• 강한 표현: "요구사항 리뷰 전 문서를 사전 검토해 회차당 평균 5건의 모호·누락 항목을 제기했고, 미결정 항목에 담당자와 기한을 붙여 회의록에 남기는 방식을 도입해 개발 중 재확인 요청이 줄었습니다."

두 번째가 강한 이유는 행동과 결과가 다 들어 있어서다. 참석은 누구나 하지만, 준비하고 기록으로 착지시키는 것은 방법을 아는 사람만 한다.

실습 과제

과제 1 — 질문 우선순위화 (10분)

다음 요구사항을 읽고, 떠오르는 질문을 최소 6개 적은 뒤 높은 우선순위 2개와 낮은 우선순위로 나눈다. 판정 근거(영향 범위·되돌리기 비용·차단 여부)도 함께 적는다.

"사용자는 리뷰를 작성할 수 있다. 리뷰에는 별점과 텍스트가 포함된다."

과제 2 — 표현 바꾸기 (10분)

다음 다섯 문장을 비난처럼 들리지 않는 정보 전달형 질문으로 바꿔 쓴다. 앞서 배운 네 가지 원칙(주어를 현상으로 / 끝을 질문으로 / 근거를 붙여 / 선택지를 주고)을 모두 적용해본다.

1. "이거 테스트 안 해보신 거 티 나는데요."
2. "요구사항이 왜 이렇게 애매하게 적혀있죠?"
3. "이 부분 완전히 빠뜨리셨네요."
4. "이렇게 만들면 저는 테스트 못 합니다."
5. "저번 스프린트에도 똑같은 문제 있었잖아요."

과제 3 — 액션 아이템으로 착지시키기 (10분)

회의에서 다음 대화가 오갔다. 이 상황을 추적 가능한 액션 아이템 문장으로 바꿔 쓴다. 무엇을·누가·언제까지·어디에 네 가지가 다 들어가야 한다.

QA: 포인트로 결제한 주문을 취소하면 환불은 포인트로 가나요, 현금으로 가나요? 기획자: 어… 그건 정산팀이랑 얘기해봐야 할 것 같은데요. 일단 넘어가죠.

과제 4 — 리뷰 형식 고르기 (5분)

다음 세 문서를 워크스루로 볼지, 인스펙션으로 볼지 정하고 이유를 한 줄로 적는다.

1. 신규 이벤트 페이지의 배너 문구와 이미지 배치 기획서
2. 정기 결제(구독) 갱신·해지·부분 환불 정산 규칙 명세
3. 아직 방향이 정해지지 않은 신규 기능의 초안 아이디어 문서

과제 5 — 다음 리뷰 준비하기 (15분)

실제로(또는 가상으로) 다음 리뷰 회의를 하나 정해 준비 절차를 그대로 밟아본다.

1. 문서를 통독한 뒤 두 번째 읽으며 질문을 전부 적는다
2. 세 기준으로 우선순위를 매기고 상위 3개를 고른다
3. 그 3개를 실제로 말할 문장 그대로 적는다
4. 회의 전 공유용 텍스트를 3~5줄로 만든다
5. 회의 마지막 2분에 할 정리 발언 초안을 미리 써 둔다

5번까지 해두는 것이 핵심이다. 대부분의 리뷰가 마지막 정리 없이 끝나므로, 그 자리를 QA가 채우면 회의의 결과물이 달라진다.

자가 체크리스트

• 요구사항 리뷰의 목적이 승인이 아니라 합의·조기 결함 발견·미결정 가시화임을 설명할 수 있다
• 준비 없이 리뷰에 참여했을 때 왜 침묵이 흐르는지 인지적 이유로 설명할 수 있다
• 워크스루와 인스펙션을 진행자·사전 준비·결과물 기준으로 구분할 수 있다
• 세 가지 기준(영향 범위·되돌리기 비용·차단 여부)으로 질문 우선순위를 매길 수 있다
• 비난형 표현을 정보 전달형 표현으로 바꿔 쓸 수 있고, 그 네 가지 원칙을 말할 수 있다
• 답이 나오지 않은 질문을 무엇·누가·언제까지·어디에가 포함된 액션 아이템으로 남길 수 있다
• 비동기 코멘트 리뷰의 장단점을 알고, 언제 통화나 회의로 전환해야 하는지 판단할 수 있다
• 회의 마지막에 결론과 미결정을 요약하는 발언을 스스로 할 수 있다

흔한 실수

• 회의 중 즉흥적으로 질문을 찾으려 한다. 모호함과 누락은 미리 읽고 분석해야 보인다. 회의는 "찾는 자리"가 아니라 "미리 찾은 걸 확인받는 자리"다.
• 모든 질문을 우선순위 없이 다 던진다. 회의 시간은 한정적이다. 중요한 질문이 사소한 질문들 사이에 묻히면, 실제로는 아무것도 결론이 나지 않는다.
• 질문이 비난으로 들려 방어적인 반응을 유발한다. 방어적으로 바뀐 상대는 정보를 덜 준다. 표현을 다듬는 것은 예의가 아니라 정보 수집의 문제다.
• 답이 안 나온 질문을 그대로 흘려보낸다. "나중에 정하죠"에서 물러나면 그 질문은 사라지고, 3주 뒤 테스트 단계에서 훨씬 비싼 모습으로 돌아온다.
• 담당자를 팀 이름으로 적는다. "기획팀 확인"은 아무도 자기 일이라고 생각하지 않는다. 액션 아이템의 담당자는 반드시 사람 한 명이다.
• 말로만 승부하려 한다. 목소리가 작아 묻힌다면 텍스트로 먼저 공유하고, 회의록에 남기고, 코멘트로 이관한다. 신입에게 유리한 무기는 글과 기록이다.
• 비동기 코멘트 스레드를 끝없이 이어간다. 세 번 왕복해도 결론이 안 나면 글로 풀 문제가 아니다. 짧은 통화로 옮기는 판단이 필요하다.
• 회의가 일찍 끝난 것을 성공으로 여긴다. 리뷰가 예정보다 빨리 끝났다면 대개 아무도 준비하지 않았다는 뜻이다.

참고 자료

• ISTQB Foundation Level Syllabus — Static Testing — 리뷰 유형(비공식 리뷰, 워크스루, 기술 리뷰, 인스펙션)의 공식 분류와 리뷰 프로세스의 역할 정의
• Gerald Weinberg, Perfect Software and Other Illusions About Testing — 소프트웨어 리뷰와 커뮤니케이션에 대한 고전적 통찰
• Karl Wiegers, Peer Reviews in Software — 리뷰 형식별 절차와 조직 도입 방법을 다룬 표준적인 참고서
• Karl Wiegers & Joy Beatty, Software Requirements — 요구사항 리뷰 체크리스트와 미결정 항목(TBD) 관리 방법
• 모듈 6(결함 관리와 보고) — 여기서 익힌 비난 없는 전달 방식이 결함 리포트 양식으로 이어진다