개념
모듈 1(레슨 5)에서 확인했듯 모든 조합을, 모든 기능을 완전히 테스트하는 건 불가능하다. 리스크 기반 테스트(Risk-Based Testing, RBT)는 이 현실 위에서 어디에 제한된 시간을 쓸지 근거 있게 정하는 방법 이다.
여기서 "근거 있게" 가 핵심이다. 시간이 부족할 때 사람은 어차피 무언가를 포기한다. RBT를 쓰지 않는 팀도 포기는 한다 — 다만 무엇을 포기했는지 모른 채 포기한다. RBT의 진짜 산출물은 완벽한 테스트가 아니라 "우리가 무엇을 덜 봤고 왜 그렇게 정했는지"에 대한 기록 이다. 그 기록이 있어야 레슨 4의 종료 조건과 레슨 5의 Go/No-Go 판단이 가능해진다.
리스크 = 발생 가능성 × 영향도
리스크는 두 축으로 평가한다.
- 발생 가능성(Likelihood): 결함이 실제로 존재할 가능성이 얼마나 높은가. 신규로 짠 코드, 복잡한 로직, 최근에 자주 바뀐 영역일수록 높다.
- 영향도(Impact): 결함이 실제로 터졌을 때 피해가 얼마나 큰가. 자주 쓰이는 기능, 매출과 직결된 기능, 되돌리기 어려운 동작(결제, 삭제)일수록 높다.
두 축을 곱하면(또는 조합하면) 리스크 수준 이 나온다. "발생 가능성은 낮지만 영향도가 극단적으로 큰" 경우(예: 결제 이중 청구)와 "발생 가능성은 높지만 영향도가 작은" 경우(예: 자주 안 쓰는 설정 화면의 사소한 UI 오류)는 다르게 다뤄야 한다.
두 축을 반드시 따로 매겨야 한다 는 점을 먼저 못 박아두자. 한 기능을 보면서 "이건 중요하니까 위험하겠지"라고 한 번에 판단하면 두 축이 붙어버린다. 실제로는 "중요한데 안 바뀐 기능"(로그인)과 "안 중요한데 방금 새로 짠 기능"(관리자용 통계 필터)이 전혀 다른 대응을 요구한다. 축을 분리해서 매겨야 이 차이가 보인다.
제품 리스크와 프로젝트 리스크는 다른 것이다
RBT를 처음 배울 때 가장 자주 엉키는 지점이다. 리스크에는 성격이 다른 두 종류가 있고, 줄이는 수단이 완전히 다르다.
| 제품 리스크(Product Risk) | 프로젝트 리스크(Project Risk) | |
|---|---|---|
| 무엇이 걱정인가 | 만들어진 물건이 잘못 동작한다 | 물건을 만드는 과정이 어그러진다 |
| 예 | 결제가 안 된다, 포인트가 두 번 쌓인다, 개인정보가 노출된다 | 개발자 한 명이 이탈했다, 스펙이 계속 바뀐다, 테스트 환경이 아직 없다 |
| 줄이는 수단 | 테스트 — 더 깊이, 더 일찍, 더 다양한 기법으로 | 계획 — 일정 재조정, 인력 배치, 범위 축소, 환경 선확보 |
| 주 책임자 | QA가 평가하고 제안한다 | PM·개발 리드가 관리한다 |
| 이 레슨의 범위 | ⬅ 여기 | 인지하고 에스컬레이션까지 |
RBT에서 매트릭스에 올리는 것은 제품 리스크다. "결제 모듈이 새로 짜였다"는 제품 리스크이고, "결제 담당 개발자가 다음 주에 휴가다"는 프로젝트 리스크다. 둘을 같은 표에 섞으면 "그래서 뭘 테스트하자는 거냐"는 질문에 답할 수 없게 된다.
그렇다고 프로젝트 리스크를 무시하라는 뜻은 아니다. QA가 가장 먼저 눈치채는 프로젝트 리스크도 많다 — 테스트 환경이 릴리즈 3일 전까지 준비되지 않는다든가, 스펙이 확정되지 않아 TC를 못 쓴다든가. 다만 말하는 자리와 문장 형태를 구분 해야 한다.
- 제품 리스크: "환불 로직 리스크가 높아 탐색적 테스팅을 하루 더 넣겠습니다." → 테스트 계획에 반영한다.
- 프로젝트 리스크: "스테이징에 결제 테스트 계정이 없어 D-2까지 환불을 검증할 수 없습니다. 계정 발급이 언제 가능한지 확인이 필요합니다." → 계획 회의·이슈로 에스컬레이션한다. 테스트를 더 한다고 해결되지 않는다.
QA가 이 둘을 섞어서 "리스크가 높아요"라고만 말하면, 듣는 사람은 무엇을 해달라는 건지 알 수 없다. 분류가 곧 요청의 명확함 이다.
리스크 매트릭스
3×3 매트릭스로 시각화하면 우선순위가 한눈에 보인다.
| 영향도: 낮음 | 영향도: 중간 | 영향도: 높음 | |
|---|---|---|---|
| 가능성: 높음 | 중간 | 높음 | 매우 높음 |
| 가능성: 중간 | 낮음 | 중간 | 높음 |
| 가능성: 낮음 | 매우 낮음 | 낮음 | 중간 |
예: 신규로 개발된 결제 모듈(가능성 높음 — 새 코드, 영향도 높음 — 매출 직결) → 매우 높음 . 반면 안정적으로 운영되던 다국어 설정 화면(가능성 낮음, 영향도 낮음) → 매우 낮음 .
3×3과 5×5 중 무엇을 쓸지는 취향이 아니라 평가 대상 개수 로 정한다.
| 3×3 | 5×5 | |
|---|---|---|
| 적당한 규모 | 기능 10~20개, 스프린트 단위 | 기능 30개 이상, 분기 릴리즈·대형 프로젝트 |
| 장점 | 빠르다. 회의에서 즉석으로 합의된다 | 같은 등급 안에서도 줄 세우기가 된다 |
| 단점 | 대부분이 "중간"에 몰려 우선순위가 안 갈린다 | 3과 4의 차이를 설명하기 어려워 논쟁이 길어진다 |
| 권장 | 대부분의 팀은 여기서 시작 | 3×3이 한계에 부딪혔을 때만 |
처음 도입한다면 3×3으로 시작하는 것을 권한다. 5×5는 정밀해 보이지만, 등급 정의가 팀 안에서 공유되지 않은 상태에서 쓰면 "이건 4인가 3인가"를 놓고 30분을 쓰게 된다. 칸을 늘리기 전에 등급의 정의를 문장으로 먼저 합의 하는 게 훨씬 효과가 크다.
리스크 매트릭스를 실제로 작성하는 절차
개념은 간단한데 막상 빈 표를 앞에 두면 손이 멈춘다. 순서를 정해두면 된다.
1단계 — 평가 단위를 정한다. 너무 크면(예: "쇼핑몰") 의미가 없고 너무 작으면(예: "쿠폰 코드 입력창 placeholder") 끝나지 않는다. 실무에서 잘 맞는 단위는 사용자가 인식하는 기능 하나 다. "쿠폰 적용", "주문 취소", "회원가입" 정도. 한 릴리즈에 10~20개면 적당하다. 이번 릴리즈의 변경 목록(PR 목록, 스프린트 백로그)에서 뽑아내는 게 가장 빠르다.
2단계 — 각 축의 등급 정의를 문장으로 적는다. 이게 가장 자주 생략되고, 가장 많은 논쟁을 만드는 단계다. "높음"이 사람마다 다르면 표는 의미가 없다.
발생 가능성
높음 — 이번 릴리즈에서 새로 짰거나 대폭 수정, 또는 최근 3개 릴리즈에서
결함이 반복 발생한 영역
중간 — 부분 수정, 또는 수정은 없지만 의존하는 모듈이 바뀜
낮음 — 변경 없음 + 최근 6개월 결함 없음
영향도
높음 — 돈이 잘못 나가거나, 되돌릴 수 없거나, 전체 사용자가 막힌다
중간 — 일부 사용자가 불편하지만 우회 경로가 있다
낮음 — 눈에 거슬리지만 업무는 진행된다
3단계 — 두 축을 따로, 순서대로 매긴다. 기능 목록 전체에 대해 발생 가능성만 쭉 매기고, 그다음 영향도만 쭉 매긴다. 기능 하나씩 두 축을 동시에 보면 "중요한 기능이니 가능성도 높겠지" 같은 후광 효과가 섞인다.
4단계 — 표에 근거를 같이 적는다. 등급만 적힌 표는 3일 뒤에 본인도 왜 그렇게 매겼는지 모른다. 근거 한 줄이 있어야 나중에 등급을 조정할 때 무엇이 달라졌는지 말할 수 있다.
5단계 — 매트릭스 칸에 배치하고 줄을 세운다. 같은 "높음" 안에서도 순서를 정해야 시간이 떨어졌을 때 어디서 멈출지 알 수 있다.
6단계 — 팀에 회람하고 이견을 받는다. 여기가 실제로 가장 값어치가 큰 단계다. 등급이 바뀌는 것보다, 개발자가 "그 기능이면 저는 오히려 여기가 불안한데요"라고 말해주는 것 이 소득이다.
등급을 무엇을 근거로 매기는가
"신규 코드니까 높음"처럼 감으로 매기지 않으려면 볼 신호가 정해져 있어야 한다.
발생 가능성을 올리는 신호
| 신호 | 어디서 확인하나 | 높게 보는 경우 |
|---|---|---|
| 과거 결함 이력 | 지라에서 컴포넌트·라벨별 결함 집계 | 최근 3개 릴리즈에서 결함이 반복 발생한 영역 |
| 코드 복잡도 | PR diff, 조건 분기 개수 | 조건문·예외 경로가 많고 한 함수가 긴 로직 |
| 변경 빈도 | git 이력, 이번 스프린트 PR 목록 | 최근에 여러 번 손댄 파일 |
| 신규성 | 아키텍처·스펙 | 처음 쓰는 라이브러리, 처음 붙이는 외부 연동 |
| 개발자의 자신감 | 직접 물어본다 | "여기는 저도 좀 불안해요"가 나오는 지점 |
| 요구사항 명확도 | 스펙 문서 | 스펙이 애매하거나 회의 중 여러 번 바뀐 기능 |
마지막 두 줄이 특히 중요하다. "개발자가 불안해하는 곳"은 통계보다 정확한 경우가 많다. 그리고 모듈 2에서 배운 것처럼, 애매한 요구사항은 그 자체로 결함의 씨앗이다 — 개발자와 QA가 서로 다르게 이해한 채 구현·검증되기 때문이다.
영향도를 올리는 신호
| 신호 | 던질 질문 | 높게 보는 경우 |
|---|---|---|
| 사용자 규모 | 하루에 몇 명이 이 경로를 지나가나 | 로그인·홈처럼 전원이 지나는 공통 경로 |
| 금전적 영향 | 돈이 잘못 나갈 수 있나 | 결제·정산·쿠폰·환불·포인트 |
| 복구 가능성 | 잘못되면 되돌릴 수 있나 | 데이터 삭제, 이메일·푸시 발송, 이중 청구 |
| 대체 경로 | 막혔을 때 우회할 방법이 있나 | 우회로가 없으면 영향도가 올라간다 |
| 법·규제·평판 | 이게 터지면 뉴스가 되나 | 개인정보 노출, 결제 정보, 접근성·약관 위반 |
| 감지 가능성 | 잘못돼도 아무도 모르나 | 조용히 틀린 값이 쌓이는 배치·정산 로직 |
감지 가능성 은 초보자가 거의 항상 빠뜨리는 축이다. 화면이 깨지면 5분 안에 제보가 들어오지만, 정산 금액이 0.1% 틀리게 쌓이면 몇 달 뒤 회계에서 발견된다. "터져도 아무도 모르는 결함"이 가장 비싸다. 이건 모듈 1에서 본 결함 수정 비용 곡선과 같은 이야기다 — 발견이 늦어질수록 비용이 커진다.
완결 사례 — 기능 6개를 실제로 평가해본다
이번 릴리즈의 변경 목록에서 뽑은 기능 6개다. 위의 등급 정의를 그대로 적용한다.
| 기능 | 가능성 근거 | 가능성 | 영향도 근거 | 영향도 | 리스크 |
|---|---|---|---|---|---|
| 간편결제 신규 연동 | 새 코드 + 처음 붙이는 외부 PG | 높음 | 돈, 이중 청구 가능, 우회로 없음 | 높음 | 매우 높음 |
| 포인트 적립 로직 리팩터링 | 대폭 수정, 조건 분기 다수 | 높음 | 돈에 준함, 틀려도 즉시 감지 안 됨 | 높음 | 매우 높음 |
| 주문 취소·환불 | 부분 수정(결제 모듈 의존) | 중간 | 환불 실패는 되돌리기 어렵고 CS 폭증 | 높음 | 높음 |
| 로그인 | 이번 릴리즈 변경 없음, 6개월 무결함 | 낮음 | 막히면 전 사용자가 아무것도 못 함 | 높음 | 중간 |
| 프로필 이미지 업로드 | 이미지 라이브러리 버전 교체 | 중간 | 실패해도 다른 기능에 영향 없음 | 낮음 | 낮음 |
| 다국어 설정 화면 | 변경 없음, 오래 안정적 | 낮음 | 표기 오류 수준 | 낮음 | 매우 낮음 |
여기서 읽어야 할 것이 세 가지 있다.
첫째, 로그인이 "중간"으로 내려온 것이 이 표의 핵심이다. 영향도만 보면 최상위지만 이번에 아무도 손대지 않았다. 감으로 정하면 로그인은 늘 1순위가 되고, 매번 같은 회귀 테스트에 시간을 쓰게 된다. 두 축을 분리했기 때문에 "중요하지만 이번엔 덜 위험하다"는 판단이 나온다.
둘째, 포인트 적립이 결제와 같은 등급으로 올라온 것도 감지 가능성 때문이다. 포인트는 결제만큼 무겁게 다루지 않는 팀이 많은데, 틀려도 조용하다는 점에서 오히려 더 위험할 수 있다.
셋째, 이제 시간을 배분할 수 있다. 테스트에 쓸 수 있는 시간이 5일(약 40시간) 이라면 이렇게 나뉜다.
| 기능 | 리스크 | 배정 | 테스트 접근 |
|---|---|---|---|
| 간편결제 연동 | 매우 높음 | 12h | 결정테이블 + 경계값 + 탐색적 + 실패 주입(타임아웃·중복 요청) |
| 포인트 적립 | 매우 높음 | 10h | 경계값 + 상태전이 + DB 값 직접 검증 |
| 주문 취소·환불 | 높음 | 8h | 결정테이블 중심, 결제와의 연계 시나리오 |
| 로그인 | 중간 | 4h | 회귀 스모크 + 주요 경로 |
| 프로필 이미지 | 낮음 | 3h | 대표값 + 파일 크기 경계 1~2건 |
| 다국어 설정 | 매우 낮음 | 1h | 화면 진입·저장만 확인 |
| (예비) | 2h | 위 과정에서 나온 추가 확인 |
예비 시간을 남겨두는 것 을 잊지 말자. 리스크가 높다고 본 곳에서 결함이 쏟아지면 재테스트가 필요하고, 그 시간은 원래 계획에 없다.
리스크 수준에 따라 테스트 깊이를 다르게 한다
| 리스크 수준 | 테스트 접근 |
|---|---|
| 매우 높음 | 여러 기법을 조합, 여러 테스트 레벨(모듈 1), 탐색적 테스팅까지 동원 |
| 높음~중간 | 핵심 기법(동등분할·경계값 등) 위주로 견고하게 |
| 낮음~매우 낮음 | 스모크 테스트 수준(정말 기본 동작만 확인)으로 최소화 |
이게 "왜 어떤 기능은 꼼꼼히 보고 어떤 기능은 대충 보는가"에 대한 답이다 — 대충 보는 게 아니라, 리스크에 비례해 노력을 배분 한 것이다.
깊이는 기법의 개수만이 아니라 네 가지 방향 으로 조절할 수 있다.
- 기법의 다양성 — 모듈 3의 어떤 기법을 몇 개 쓸 것인가. 리스크가 높으면 경계값에 결정 테이블·상태전이·페어와이즈까지 겹친다.
- 테스트 레벨 — 단위·통합·시스템 중 어디까지 볼 것인가. 리스크가 높으면 개발자에게 단위 테스트 보강을 요청하는 것까지 포함된다.
- 검증 지점의 수 — 화면만 볼 것인가, DB·로그·외부 연동 응답까지 볼 것인가. 금전 관련 기능은 화면 표시가 맞아도 DB 값이 틀릴 수 있다.
- 반복 횟수 — 한 번만 볼 것인가, 빌드마다 회귀로 볼 것인가.
리스크가 낮은 영역에서 줄이는 것은 깊이지 존재가 아니다. 스모크 한 건이라도 남겨두는 이유는, 배포 자체가 깨진 경우(빌드 실패, 설정 누락)를 잡기 위해서다. 이런 결함은 리스크 등급과 무관하게 어디서든 터진다.
리스크를 식별하는 방법
혼자 판단하지 않는다. 팀 브레인스토밍, 과거 결함 이력(이 영역에서 결함이 자주 났었는가), 코드 복잡도, 최근 변경 빈도, 그리고 이해관계자에게 "이 기능이 잘못되면 가장 걱정되는 게 뭔가요?"라고 직접 묻는 것도 좋은 리스크 식별 방법이다.
혼자 하면 안 되는 이유는 성실함의 문제가 아니라 정보 접근의 문제 다.
- QA는 코드 내부의 변경 이력을 개발자만큼 알지 못한다. "화면은 그대로인데 내부를 통째로 갈아엎은" 기능이 가장 위험한데, 화면만 보면 알 수 없다.
- QA는 운영 데이터를 CS·운영팀만큼 알지 못한다. 어떤 기능에 문의가 몰리는지, 어떤 오류가 반복 제보되는지는 그쪽에 쌓여 있다.
- 사람은 최근에 본 것과 익숙한 것을 과대평가한다. 지난주에 고생한 영역을 실제보다 위험하게 보게 된다.
- 그리고 실무적으로 가장 중요한 이유 — 혼자 정한 우선순위는 나중에 방어되지 않는다. 결함이 터졌을 때 "왜 거기를 안 봤냐"는 질문에, 합의된 리스크 문서가 있으면 팀의 결정이 되고 없으면 QA 개인의 실수가 된다.
리스크 식별 워크숍을 어떻게 진행하나
가장 확실한 방법은 짧은 워크숍을 한 번 여는 것이다. 계획 단계 초반에 60~90분이면 충분하다.
누구를 부르나
| 참석자 | 이 사람만 아는 것 |
|---|---|
| 개발자(해당 영역) | 실제로 무엇을 얼마나 고쳤는지, 어디가 불안한지 |
| 기획·PO | 이 기능이 왜 필요한지, 어떤 실패가 사업적으로 치명적인지 |
| CS 담당 | 사용자가 실제로 어디서 막히는지, 문의가 몰리는 곳 |
| 운영·인프라 | 장애 이력, 트래픽 패턴, 배포·롤백 난이도 |
| QA(진행) | 표를 만들고 질문을 던지고 기록한다 |
전원이 다 모이지 않아도 된다. 못 오면 비동기로라도 같은 질문을 던진다. 슬랙에 "이번 릴리즈에서 가장 불안한 곳 하나만 꼽아주세요"라고 물어보는 것만으로도 혼자 추측하는 것보다 훨씬 낫다.
어떤 질문을 던지나 — 추상적으로 "리스크가 뭘까요"라고 물으면 침묵만 흐른다. 구체적인 상황을 상상하게 만드는 질문이어야 한다.
- "이 기능이 새벽 3시에 죽으면 누가 가장 먼저 아나요?" — 아무도 모른다면 그 자체가 큰 리스크다. 모니터링·알림이 없다는 뜻이다.
- "돈이 잘못 나가는 경로는 어디인가요?" — 결제만이 아니라 쿠폰·포인트·정산· 환불까지 끌어낸다.
- "이번에 손댄 것 중 되돌리기 가장 어려운 게 뭔가요?" — 롤백 난이도를 묻는 질문이다.
- "지난 6개월 동안 핫픽스가 나갔던 영역은 어디인가요?" — 과거 결함 이력을 기억에서 꺼내는 가장 빠른 방법이다.
- "CS에 가장 많이 들어오는 문의 세 개는 뭔가요?" — 사용자가 실제로 걸려 넘어지는 지점.
- (개발자에게) "배포 버튼 누르기 직전에 가장 마음에 걸리는 게 뭔가요?" — 경험상 이 질문의 답이 가장 자주 실제 결함으로 이어진다.
어떻게 진행하나
- 기능 목록(10~20개)을 미리 만들어 공유한다. 회의 자리에서 목록을 만들면 시간이 다 간다.
- 처음 10분은 각자 조용히 자기 등급을 적는다. 먼저 말한 사람 의견에 전원이 쏠리는 걸 막는 장치다.
- 등급이 갈린 항목만 골라 논의한다. 전원이 같게 매긴 항목은 넘어간다.
- 논쟁이 5분을 넘기면 높은 쪽으로 올리고 넘어간다. 등급을 정확히 맞추는 게 목적이 아니라 순서를 정하는 게 목적이다.
- 끝나면 표를 그대로 테스트 계획서(레슨 1)의 "우선순위 근거"에 붙인다.
이견이 나온 항목은 지우지 말고 "개발팀은 중간, CS는 높음"처럼 남겨두는 것이 좋다. 나중에 그 항목에서 결함이 나면 누구의 감이 맞았는지가 기록되고, 다음 번 평가의 정확도가 올라간다.
리스크는 고정값이 아니다
리스크 평가는 한 번 만들고 끝내는 문서가 아니다. 시간이 지나면 값이 변한다.
| 리스크를 낮추는 사건 | 리스크를 높이는 사건 |
|---|---|
| 계획한 테스트를 실행해 통과했다 | 예상보다 복잡한 로직이었음이 드러났다 |
| 개발자가 단위 테스트를 보강했다 | 그 영역에서 결함이 연달아 발견됐다 |
| 스펙 애매함이 해소됐다 | 릴리즈 직전 급한 수정이 들어왔다 |
| 롤백 절차가 준비됐다 | 의존하는 외부 API 스펙이 바뀌었다 |
재평가 시점은 미리 정해두는 게 좋다. 그렇지 않으면 아무도 하지 않는다.
- 스프린트 종료 시 — 이번에 확인된 것과 새로 들어온 변경을 반영한다.
- 주요 변경 직후 — 범위에 없던 기능이 추가되거나 큰 수정이 들어왔을 때.
- 결함이 한 영역에 몰릴 때 — 한 곳에서 결함이 계속 나오면 그 주변 영역의 발생 가능성도 같이 올려 잡는다. 결함은 뭉쳐서 나온다(모듈 1 — 결함 집중).
- 릴리즈 D-2~D-3 — 남은 리스크를 정리해 레슨 5의 Go/No-Go 자료로 만든다.
등급을 낮출 때는 근거가 필요하다. 여기서 가장 흔한 오류가 "테스트를 했으니 이제 안전하다"는 판단이다. 실행했다는 사실은 근거가 아니다. 낮추려면 최소한 이 세 가지가 말해져야 한다.
- 무엇을 어느 깊이로 확인했는가 — "결제 테스트 12건 통과"가 아니라 "정상 결제·취소·부분환불·중복 요청·타임아웃 5개 시나리오를 결정 테이블로 덮었고 전부 통과"처럼.
- 원래 걱정하던 실패 시나리오를 실제로 덮었는가 — 리스크를 "이중 청구"로 적어놓고 정상 결제만 테스트했다면 리스크는 그대로다.
- 그 뒤로 코드가 바뀌지 않았는가 — 테스트 이후 수정이 들어갔다면 낮췄던 등급은 원복된다.
반대로 끝까지 낮아지지 않는 리스크도 있다. 실제 결제 환경에서만 재현되는 문제처럼 테스트로 줄일 수 없는 항목이 그렇다. 이건 숨기지 말고 "남은 리스크"로 명시해 모니터링·단계적 배포·롤백 계획으로 넘긴다. 테스트로 못 줄이는 리스크를 줄인 척하는 것이 가장 위험하다.
사례 연구 — "전부 테스트할 수 없다"에서 중대 결함까지
앞의 조각들을 하나의 흐름으로 이어보자.
상황. 릴리즈까지 3일. 변경된 파일이 40개가 넘고, 스프린트 백로그에는 기능 항목이 14개다. 전부 제대로 볼 수 없다는 게 명백하다.
1단계 — 제보를 모은다. 혼자 목록을 노려보는 대신 세 곳에서 정보를 긁는다. 스탠드업에서 개발 리드가 "포인트 적립 로직을 이번에 리팩터링했다, 화면은 그대로" 라고 지나가듯 말했다. 지라를 뒤져보니 지난 분기 이 영역에서 핫픽스가 두 번 나갔다. CS에 물으니 지난달 "포인트가 두 번 쌓였다"는 문의가 2건 있었는데 원인을 못 찾고 수동 보정으로 종결됐다.
2단계 — 평가한다. 14개를 3×3에 올린다. 포인트 적립은 발생 가능성 높음 (대폭 수정 + 과거 결함 반복), 영향도 높음(금전에 준하고 틀려도 즉시 감지되지 않는다 ) → 매우 높음. 반면 함께 들어간 "공지사항 목록 정렬 변경"은 가능성 중간, 영향도 낮음 → 낮음.
3단계 — 집중한다. 3일 중 하루 반을 상위 2개(포인트 적립, 결제 연동)에 쓴다고 계획서에 적고 팀에 공유한다. 이때 "공지사항 정렬은 스모크만 봅니다"를 명시적으로 적어두는 것 이 중요하다. 나중에 방어할 지점이 바로 여기다.
4단계 — 깊이 파고든다. 리스크가 높다고 판단했으므로 화면 확인에서 멈추지 않는다. 적립 시나리오를 상태전이로 그려보니 "결제 완료 → 적립"만이 아니라 "결제 취소 → 적립 회수", "부분 취소 → 부분 회수" 경로가 있다. DB의 포인트 이력 테이블을 직접 열어 값을 확인하기로 한다.
5단계 — 발견. 두 가지가 나왔다.
결함 A — 주문 완료 버튼을 빠르게 두 번 누르면 적립이 2회 기록된다. 화면에는 한 번만 표시되지만 DB 이력에는 두 줄이 남는다.
결함 B — 부분 취소 시 회수 포인트가 원래 적립액 전체로 계산된다. 3만원 중 1만원어치를 취소했는데 적립분 300P가 전액 회수된다.
결함 A가 CS에 접수됐던 그 문의의 정체였다. 화면상으로는 정상이라 지난번에 원인을 못 찾았던 것이다. 리스크 평가에서 "감지 가능성이 낮다"고 본 판단이 "화면 말고 DB를 보자"는 행동으로 이어졌기 때문에 잡혔다.
6단계 — 결과. 릴리즈 전 두 건 모두 수정됐다. 대신 낮은 리스크로 분류해 스모크만 본 공지사항 정렬에서 운영 중 사소한 결함이 하나 나왔다 — 특정 조건에서 정렬 순서가 뒤집혔다. CS 응대와 다음 릴리즈 수정으로 처리됐고, 아무도 QA를 탓하지 않았다. 계획서에 "이 영역은 리스크 낮음으로 판단해 스모크 수준으로 봅니다"가 적혀 있었고 팀이 그것에 동의했기 때문이다.
이 마지막 문단이 RBT의 본질이다. RBT의 성공은 "결함을 다 잡았다"가 아니라 "무엇을 포기했는지 팀 전체가 알고 있었다"이다.
실무에서 왜 필요한가
시간은 항상 부족하다. RBT가 없으면 "익숙한 것부터", "쉬운 것부터", 혹은 그냥 "요구사항 문서에 적힌 순서대로" 테스트하게 되기 쉬운데, 이건 리스크와 아무 상관이 없다. 반대로 RBT를 명시적으로 적용하면, 릴리즈가 촉박해서 일부를 못 보고 넘어가야 할 때도 "가장 리스크가 낮은 부분을 남겼다" 고 근거 있게 말할 수 있다. 이건 이후 레슨(종료 조건, Go/No-Go)의 판단 근거가 그대로 된다.
첫째, 일정이 깎일 때 협상 가능한 언어가 생긴다. "5일 걸립니다"에는 반박이 "3일에 해주세요"뿐이다. 하지만 리스크 표가 있으면 대화가 달라진다 — "3일이면 간편결제와 포인트는 계획대로 보고, 주문 취소는 정상 경로만, 프로필과 다국어는 빼겠습니다. 주문 취소의 예외 경로가 검증되지 않은 채 나갑니다." 범위를 줄이는 결정을 QA 혼자 떠안지 않고 팀의 결정으로 만드는 것 이 핵심이다.
둘째, 결함이 새어나갔을 때 회고가 가능해진다. 리스크 평가 기록이 없으면 "왜 못 잡았지"에서 대화가 끝난다. 기록이 있으면 훨씬 유용한 질문이 나온다 — "이 영역을 왜 낮게 봤을까? 어떤 신호를 놓쳤을까?" 다음 번 평가가 조금 더 정확해진다. 리스크 평가는 틀려도 되는 문서다. 다만 틀린 이유를 배울 수 있게 남아 있어야 한다.
셋째, 신입 QA의 "얼마나 테스트해야 충분한가" 불안이 절차로 바뀐다. 경력이 적을 때 가장 힘든 순간은 시간이 부족한데 무엇을 줄여야 할지 모를 때다. 매트릭스는 그 판단을 개인의 감이 아니라 팀이 합의한 규칙 으로 만들어준다.
넷째, 다른 활동의 입력값으로 재사용된다. 레슨 3의 커버리지 계획은 규모 × 리스크로 짜이고, 레슨 4의 종료 조건은 "고위험 영역의 TC 100% 실행"처럼 리스크 등급을 그대로 인용한다. 스테이지 4에서 무엇부터 자동화할지 정할 때도, 리스크 높고 반복 실행되는 영역이 1순위다. 한 번 만든 표가 모듈 전체에서 계속 쓰인다.
다섯째, QA의 역할이 바뀐다. "테스트를 실행하는 사람"에서 "의사결정에 근거를 제공하는 사람"으로 넘어가는 지점이 정확히 여기다. 경력 면접에서 "제한된 시간에 테스트 범위를 어떻게 정하나요"를 묻는 이유도 같다 — 답에 리스크의 두 축과 이해관계자 합의 절차가 들어 있는지를 본다.