개념
모든 회의에는 세 가지가 있어야 한다
회의가 길어지고 아무것도 정해지지 않는 이유는 대개 같다. 왜 모였는지, 끝나면 무엇이 남아야 하는지, 누가 어떻게 정하는지가 없기 때문이다. 리드가 여는 회의에는 다음 세 가지를 초대장에 적는다.
| 요소 | 질문 | 예(결함 트리아지) |
|---|---|---|
| 목적 | 왜 모이는가 | 신규 결함의 심각도·우선순위·담당 결정 |
| 산출물 | 끝나면 무엇이 남는가 | 결함마다 우선순위·담당·목표 수정일이 채워진 목록 |
| 결정 규칙 | 누가 어떻게 정하는가 | 심각도는 QA 리드, 우선순위는 제품 책임자, 합의 안 되면 제품 책임자가 결정 |
결정 규칙이 특히 중요하다. 규칙이 없으면 가장 목소리 큰 사람이 정하거나, 아무도 정하지 않는다.
결함 트리아지 — 20분 안에 끝내기
트리아지는 QA 리드가 가장 자주 진행하는 회의다. 흔한 실패는 회의 중에 결함을 처음 읽는 것이다. 결함 하나에 5분씩 쓰면 열두 건에 한 시간이 간다.
사전 분류(회의 전 30분). 리드가 신규 결함을 미리 읽고 세 무더기로 나눈다.
| 무더기 | 기준 | 회의에서 |
|---|---|---|
| A. 이견 없음 | 심각도·담당이 명확 | 목록으로 한 번에 확인만 (1~2분) |
| B. 논의 필요 | 우선순위 판단이 필요하거나 여러 팀이 걸림 | 건당 최대 3분 |
| C. 정보 부족 | 재현 불가, 기대 결과 근거 없음 | 회의에서 다루지 않고 보고자에게 보완 요청 |
진행 규칙.
- 건당 3분 시간 상자. 넘으면 "별도 논의"로 빼고 담당과 시한만 정한다
- 결함 설명은 보고자가 아니라 리드가 제목과 영향만 한 줄로 읽는다
- 결정은 화면에 띄운 이슈 트래커에서 그 자리에서 필드에 입력한다
[트리아지 20분 구성 예 — 신규 14건]
2분 A 무더기 8건 일괄 확인
12분 B 무더기 4건 × 3분
2분 C 무더기 2건 보완 요청 공지
4분 미해결 치명 결함의 수정 일정 점검스탠드업 — 진척 보고가 아니라 차단 해소
스탠드업이 "어제 한 일, 오늘 할 일" 낭독이 되면 15분이 누구에게도 쓸모없다. 테스트 팀 스탠드업은 보드를 보며 오른쪽(완료에 가까운 것)부터 진행하고, 질문을 바꾼다.
- "완료 직전인데 막힌 것은?"
- "차단 표시된 것은 무엇이고, 누가 오늘 풀 수 있나?"
- "오늘 도움이 필요한 사람은?"
긴 논의가 필요하면 스탠드업에서 하지 않고 "끝나고 관련자만 남기"로 뺀다. 스탠드업의 산출물은 오늘 풀 차단 이슈와 그 담당 이다.
회고 — 행동 하나로 끝낸다
회고가 불만 성토로 끝나면 다음 회고도 같은 불만이 나온다. 회고의 산출물은 다음 주기에 실제로 할 행동 한두 개와 담당 이다.
간단한 형식 하나: 잘된 것 / 아쉬운 것 / 다음에 시도할 것. 모두 포스트잇(또는 온라인 보드)에 쓰고, 비슷한 것을 묶고, 점 투표로 하나를 고르고, 그 하나를 구체적인 행동으로 만든다.
[나쁜 행동] 커뮤니케이션을 개선한다
[좋은 행동] 요구사항 변경이 생기면 기획자가 QA 채널에 변경 요약 3줄을 남긴다.
담당: 기획 리드와 합의(QA 리드), 다음 회고에서 몇 번 지켜졌는지 확인이전 회고의 행동이 지켜졌는지 확인하는 것으로 다음 회고를 시작한다. 이 5분이 회고를 실제 개선 장치로 만든다.
이견 조율 — 입장이 아니라 근거와 기준
QA 리드가 가장 자주 맞닥뜨리는 이견은 이런 것들이다.
- "이건 결함이 아니라 사양입니다"
- "이 결함은 이번 릴리스에 안 고쳐도 됩니다"
- "심각도가 너무 높게 잡혔습니다"
이견은 입장("고쳐야 한다" vs "안 고쳐도 된다")으로 부딪히면 끝나지 않는다. 입장 뒤의 관심사 와 근거 로 내려간다. 하버드 협상 프로젝트의 원칙(입장이 아니라 이해관계에 집중하고, 객관적 기준을 쓴다)이 그대로 적용된다.
| 단계 | 리드의 질문 |
|---|---|
| 1. 사실 맞추기 | "재현 조건과 실제 결과는 우리 둘 다 같게 이해하고 있나요?" |
| 2. 기준 찾기 | "기대 결과의 근거가 되는 요구사항·정책·표준이 있나요?" |
| 3. 관심사 듣기 | "이번에 안 고치자는 이유는 일정인가요, 위험이 낮다고 보는 건가요?" |
| 4. 선택지 만들기 | "이번엔 우회 안내를 넣고 다음 릴리스에 고치는 건 어떨까요?" |
| 5. 결정권자 확인 | "이 판단은 누가 하는 게 맞을까요?" |
"결함이냐 사양이냐"는 기준 문서가 없어서 생기는 경우가 가장 많다. 이때 결론은 결함 여부가 아니라 "기준이 없다"는 사실을 기록하고 기획이 기준을 정하게 하는 것 이다. QA가 사양을 정하려 들면 역할 충돌이 생긴다.
이견을 다루는 말투
모듈 6 레슨 3(결함 커뮤니케이션)의 원칙이 회의에서도 그대로 쓰인다. 몇 가지 문장을 준비해 두면 긴장된 순간에 도움이 된다.
- "제가 이해한 게 맞는지 확인하고 싶어요. 말씀하신 건 ○○라는 거죠?"
- "이 판단의 근거를 기록에 남기고 싶은데, 어떤 문서를 기준으로 할까요?"
- "지금 결론이 안 나면 ○○님이 내일까지 정해 주시는 걸로 할까요?"
- "제 우려는 이 결함이 ○○ 사용자에게 ○○ 영향을 준다는 점이에요. 이 위험을 감수하는 결정이라면 기록해 두겠습니다."
마지막 문장이 중요하다. QA는 릴리스를 막는 권한이 없는 경우가 많다. 대신 위험을 명시적으로 감수하는 결정 을 기록으로 남길 수 있다. 이것이 품질 경찰이 되지 않으면서 책임을 분명히 하는 방법이다.
결정 기록
회의의 결정은 짧게라도 남긴다. 형식은 단순할수록 좋다.
[결정 기록 2026-09-18 트리아지]
D-031 BUG-812 결제 완료 후 영수증 금액 반올림 차이(1원)
결정: 이번 릴리스 제외, 9월 30일 핫픽스
근거: 영향 사용자 0.3%, 결제 금액 자체는 정확, 영수증 표시만 차이
감수한 위험: 고객 문의 증가 가능 → CS 공지 문구 준비(담당 CS 리드)
결정자: 제품 책임자 김OO결정 기록은 Confluence(모듈 7 레슨 7) 같은 공유 공간에 모아 둔다. 석 달 뒤 "왜 이걸 안 고쳤냐"는 질문이 오면 링크 하나로 답할 수 있다.
실무에서 왜 필요한가
리드의 시간은 회의에서 가장 많이 샌다. 트리아지가 60분에서 20분으로 줄면 매주 몇 시간이 돌아온다. 그보다 중요한 것은 회의의 결정 품질이다. 결정 규칙과 기록이 없는 회의에서는 같은 논쟁이 반복되고, 나중에 책임 소재가 흐려진다.
또 이견 조율은 QA 팀의 위상을 결정한다. 근거와 기준으로 이견을 다루는 QA는 "까다로운 팀"이 아니라 "판단을 돕는 팀"으로 인식된다.
채용시장에서의 위치
"개발팀과 이견이 있었을 때 어떻게 했나요"는 QA 면접의 단골 질문이다. 사실 맞추기 → 기준 찾기 → 관심사 → 선택지 → 결정권자의 흐름으로 답하고, 결정 기록을 남겼다는 것까지 말하면 성숙한 답이 된다.