리스크 기반 테스트 전략, 이게 내 특기다

05 Jan, 2026
- 팀관리

전부 테스트할 순 없다

출근했다. 슬랙 메시지 27개. 개발팀 리드가 쪽지 보냈다. “이번 주 배포인데 테스트 범위 좀…”

또 시작이다.

신입 개발자가 물었다. 지난주에. “이거 다 테스트하나요?” 웃었다. “다 하면 좋지.” 할 수 없다는 게 문제다.

2주에 한 번 배포한다. 우리 팀 8명. 변경사항 평균 150개. 관련 기능까지 치면 500개 넘는다. 물리적으로 불가능하다.

그래서 선택한다. 무엇을 테스트하고, 무엇을 넘어갈 것인가. 13년 하면서 익힌 거다. 이게.

리스크부터 찾는다

오전 회의. 기획팀장이 말한다. “이번에 결제 로직 바꿨어요.”

귀가 쫑긋해진다.

“어느 부분이요?” “PG사 연동 방식이요. API 버전업이랑.” “테스트 일정은?” “이틀이요.”

웃음 나온다. 참았다.

화이트보드에 적는다.

결제 실패 시나리오: 최우선
PG 연동 타임아웃: 최우선
환불 로직 영향도: 최우선
결제 금액 검증: 최우선

개발자가 말한다. “UI도 바꿨는데요.” “어디요?” “버튼 색깔이요.”

적는다. 하단에.

버튼 색상 변경: 하

이게 리스크 기반이다. 돈 관련은 무조건 위. 색깔은 아래.

단순하다. 사실. 근데 이걸 못하는 팀이 많다.

영향도를 계산한다

점심 먹고 돌아왔다. 팀원이 묻는다. “이 기능은 어떻게 해요?” 신규 추천 알고리즘이다.

질문한다. “사용자 몇 명한테 노출돼?” “전체요.” “장애 나면?” “추천이 안 뜨죠.” “그럼 서비스는?” “그래도 쓸 순 있어요.”

적는다.

영향 범위: 전체 사용자
장애 영향도: 중
비즈니스 임팩트: 중상
복구 난이도: 중

계산한다. 머릿속으로. 중상 정도면 중점 테스트다.

“시나리오 10개 뽑아. 엣지케이스 위주로.” “네.”

또 묻는다. 다른 팀원이. “관리자 페이지 수정 건은요?”

“사용자 몇 명?” “CS팀 5명이요.” “장애 나면?” “수동으로 처리해요.” “얼마나 걸려?” “한 10분?”

적는다.

영향 범위: 내부 5명
장애 영향도: 하
비즈니스 임팩트: 하
복구 난이도: 하

“스모크만 돌려. 메인 시나리오만.” “알겠습니다.”

이게 영향도 계산이다. 전부 같은 무게로 보면 안 된다.

3년 차 때는 몰랐다. 다 중요해 보였다. 지금은 안다. 뭐가 진짜 중요한지.

과거 데이터가 답이다

오후 3시. 리스크 분석 시간.

Jira 연다. 지난 6개월 장애 기록. 필터링한다. Critical 이상만.

나온다. 32건.

결제 관련: 8건
로그인 관련: 6건
데이터 동기화: 5건
API 타임아웃: 4건

또 본다. 배포 후 핫픽스 기록.

결제 로직 변경 시: 핫픽스율 40%
검색 로직 변경 시: 핫픽스율 35%
UI 변경 시: 핫픽스율 5%

데이터는 거짓말 안 한다.

이번 배포 체크한다. 결제 로직 수정 있다. API 변경 있다. 로그인 쪽은 없다.

테스트 시간 배분한다.

결제: 40%
API 연동: 30%
기타 핵심: 20%
나머지: 10%

팀원한테 공유한다. “이번에 결제랑 API 집중이야.” “네.”

신입이 묻는다. “왜요?” “작년에 결제 장애 8번 났어. API 타임아웃 4번.” “아…” “UI는 5%야. 장애율이.” “그럼 UI는 대충?” “아니. 효율적으로.”

차이를 아는 게 중요하다. 대충이 아니라 효율적으로.

컨텍스트를 읽는다

회의 끝나고 복도에서 만났다. CTO. “이번 배포 괜찮아요?” “결제 로직 바뀌어서 좀 더 봐야 해요.” “얼마나?” “이틀 더 주시면 좋겠어요.”

표정이 굳는다. “일정이 빠듯한데.”

안다. 알아. 근데 말해야 한다.

“작년 결제 장애 기억하시죠?” ”…” “그때 복구에 4시간 걸렸어요.” “알아요.” “이번 변경 범위가 그때보다 커요.”

침묵.

“이틀은 줄게요.” “감사합니다.”

이게 컨텍스트다. 단순히 ‘더 테스트해야 해요’ 말하면 안 먹힌다. 왜 필요한지, 리스크가 뭔지, 과거에 뭐가 있었는지.

데이터 기반으로 말한다. 항상. 그래야 설득된다. 경영진이.

신입 QA들한테 말한다. “느낌으로 말하지 마. 숫자로 말해.” “네.”

나도 처음엔 몰랐다. ‘이거 위험할 것 같아요’ 이렇게 말했다. 씹혔다. 당연히.

지금은 다르다. ‘작년 동일 변경 시 장애율 40%, 복구 평균 3시간, 비즈니스 임팩트 추정 2억’ 이렇게 말한다. 먹힌다.

자동화는 도구다

저녁 6시. 팀원이 묻는다. “이거 자동화하면 안 돼요?” 회귀 테스트 케이스다. 300개.

“할 거야.” “언제요?” “다음 분기.”

실망한 표정.

“지금은 리스크 높은 거부터 손으로.” “비효율적인데요.” “알아. 근데 자동화도 리스크 기반이야.”

화이트보드에 적는다. 자동화 우선순위:

회귀 테스트 (매 배포 반복)
결제 시나리오 (장애 임팩트 대)
로그인/인증 (전체 사용자 영향)
API 검증 (연동 많음)

“UI 테스트는요?” “나중에. 깨지기 쉬워서.”

자동화는 만능이 아니다. 비용이다. 시간도, 유지보수도.

무엇을 자동화할지도 선택이다. 리스크 기반으로.

이것도 13년 하면서 배웠다. 초반엔 다 자동화하려 했다. 망했다. 유지보수 지옥.

지금은 안다. 핵심만 자동화한다. 나머지는 손으로 하는 게 빠르다.

팀원도 배운다

1on1 시간. 5년 차 팀원. “요즘 뭐가 어려워?” “우선순위 정하기요.” “예를 들면?” “이번 배포도. 뭘 먼저 할지 모르겠어요.”

노트북 켠다. “이번 변경사항 봐.”

같이 본다.

신규 기능 A: 베타 유저 100명
기존 기능 B 수정: 전체 유저
관리자 페이지 C: 내부 10명

“어떻게 할 거야?” “음… 신규 기능이 중요할 것 같은데요.” “왜?” “새 기능이니까요.”

고개 젓는다.

“영향도 봐. B는 전체 유저야.” “아…” “A는 베타 100명. 장애 나도 롤백 쉬워.” “그럼 B부터요?” “응. B 80%, A 15%, C 5%.”

적어준다. 판단 기준.

영향 받는 사용자 수
장애 시 비즈니스 임팩트
복구 난이도
과거 장애 이력

“다음부턴 이렇게 생각해봐.” “네.”

팀원 키우는 것도 리스크 관리다. 언제까지 내가 다 판단할 순 없다.

실패도 데이터다

작년 여름. 큰 장애 났다. 배포 후 2시간 만에.

검색 기능 먹통. 전체 사용자 영향. 복구 5시간 걸렸다.

포스트모템 회의. 개발팀장이 말한다. “테스트 안 했어요?” “했어요.” “뭘?” “메인 시나리오 위주로요.”

CTO가 묻는다. “왜 못 잡았어요?” “엣지케이스였어요. 특수문자 입력 시.” ”…”

내 실수다. 인정한다. 리스크 판단 잘못했다.

그날 밤 분석했다.

검색 로직 변경: 고위험으로 재분류
특수문자 테스트: 필수 케이스 추가
검색 자동화: 다음 분기 최우선

실패는 데이터가 된다. 다음 리스크 판단에 쓴다.

지금은 검색 관련 변경 있으면 무조건 중점 테스트다. 작년 덕분이다. 그 장애.

신입들한테 말한다. “장애 두려워하지 마. 배워.” “네.”

완벽한 리스크 판단은 없다. 계속 보정한다. 데이터로.

혼자 하는 게 아니다

오전 회의. 기획팀 리드가 묻는다. “이 기능 어때요? 위험해요?”

신규 알림 시스템이다.

“단독으로는 중간이에요.” “그럼 괜찮네요?” “근데 푸시 서버랑 연동되죠?” “네.” “푸시는 작년에 장애 3번이에요.” “아…” “전체적으론 중상 리스크예요.”

개발팀 리드가 끼어든다. “그럼 어떻게 해요?” “푸시 실패 시나리오 중점 테스트요.” “시간은?” “3일이요.” “2일 안 돼요?” “푸시 서버 불안정하면 안 돼요.”

결국 3일 받았다.

리스크 판단은 혼자 하는 게 아니다. 기획, 개발, 인프라 다 같이 본다.

내 역할은 정리하는 거다. 뿔뿔이 흩어진 정보를. 리스크로 엮는 거.

13년 하면서 배운 거다. QA는 통합 시점이다. 모든 정보가 모이는.

숫자로 말한다

경영진 보고. 분기 1번. 품질 현황 발표한다.

슬라이드 켠다.

전분기 대비 장애 감소율: 32%
리스크 기반 테스트 적용 후: 핫픽스 40% 감소
테스트 효율: 30% 향상 (같은 시간, 더 높은 커버리지)
비용 절감: 장애 복구 비용 분기당 1.2억 감소

CFO가 묻는다. “어떻게 했어요?” “한정된 리소스를 리스크 높은 곳에 집중했어요.” “구체적으로?” “과거 장애 데이터 기반으로 우선순위 정했어요.”

고개 끄덕인다.

“좋네요. 계속 해주세요.” “감사합니다.”

숫자 없으면 안 먹힌다. 경영진한테. ‘열심히 했어요’ 소용없다. ‘32% 줄였어요’ 이게 먹힌다.

그래서 기록한다. 다. 장애 건수, 복구 시간, 테스트 커버리지.

리스크 기반 전략의 효과를 증명한다. 숫자로.

이게 내 특기다

퇴근 전. 팀원들 모았다. “수고했어. 이번 배포.” “감사합니다.”

배포 성공했다. 리스크 높았던 결제, API, 다 통과. 장애 없었다.

신입이 묻는다. “어떻게 알았어요?” “뭘?” “어디가 위험한지요.”

웃었다.

“13년 했어.” “그것만으로요?” “아니. 매번 데이터 쌓고, 분석하고, 보정했어.” ”…” “너도 하다 보면 돼.”

거짓말 아니다. 초반엔 나도 몰랐다. 감으로 했다.

지금은 다르다. 시스템이 있다. 판단 기준이. 리스크 기반 사고방식이.

이게 13년의 무게다. 경력이란 게.

완벽하진 않다. 여전히. 가끔 놓친다. 리스크를. 장애 난다. 예상 못 한 곳에서.

그래도 괜찮다. 다시 배운다. 또. 데이터 쌓는다. 더.

리스크 기반 테스트 전략. 이게 내 특기다.

한정된 시간과 리소스로. 최고의 품질 뽑아낸다.

전문가의 자부심이다. 13년 축적한.

내일도 리스크 분석이다. 데이터가 쌓인다. 또.