Showing Posts From

리스크

• 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년 축적한.내일도 리스크 분석이다. 데이터가 쌓인다. 또.

• 03 Dec, 2025
• • 품질전략

리스크 기반 테스트, 예산 없이 시작하다

리스크 기반 테스트, 예산 없이 시작하다 또 반려됐다 자동화 투자 건의서 작성했다. 세 번째다. 이번엔 ROI 계산도 넣었다. 예상 절감 시간, 인건비 환산, 장애 감소율까지. 경영진 답변: "내년에 검토하겠습니다." 작년에도 들었다. 재작년에도. 회의실 나오면서 생각했다. 예산 없으면 못 하나? 아니다. 해야 한다. 품질은 돈으로만 사는 게 아니니까. 팀원들한테 말했다. "우리 방식으로 한다."전부 테스트는 환상 월요일 아침 팀 미팅. "이번 릴리즈 테스트 케이스 850개입니다." 신입 팀원이 말했다. 표정이 밝다. 나는 물었다. "일정은?" "3일입니다." 계산했다. 팀원 8명. 하루 8시간. 총 192시간. 케이스당 13분. 불가능하다. "다 못 한다." 팀원들 표정이 굳었다. "그래서 선택한다. 중요한 것만." 이게 리스크 기반 테스트다. 전부 하는 게 아니라 중요한 것부터. 예산 없으면 더 중요하다. 13년 전엔 나도 전부 하려 했다. 밤새워서라도. 지금은 안다. 그건 착각이다. 리스크 매트릭스 그리기 화이트보드 꺼냈다. 가로축: 발생 확률. 세로축: 영향도. 4사분면으로 나눴다. "우선순위 1: 높은 확률, 큰 영향" "우선순위 2: 낮은 확률, 큰 영향" "우선순위 3: 높은 확률, 작은 영향" "우선순위 4: 낮은 확률, 작은 영향" 팀원들이 포스트잇 붙이기 시작했다. 결제 로직 → 1사분면 로그인 → 1사분면 신규 AI 추천 기능 → 2사분면 관리자 통계 페이지 → 3사분면 이용약관 텍스트 수정 → 4사분면 850개 케이스가 정리됐다. 1사분면이 120개. 이것만 해도 충분하다.영향도 측정하는 법 개발팀 리드한테 물었다. "이번 릴리즈에서 결제 로직 변경 있나?" "네, 할부 옵션 추가했습니다." "작년 결제 장애 때 CS 문의 몇 건이었지?" "2300건이요. 환불 처리만 3일 걸렸습니다." 영향도는 이렇게 잰다. 과거 데이터. Jira에서 검색했다. 지난 6개월 Critical 버그. 결제 관련: 12건 로그인 관련: 8건 추천 관련: 2건 Confluence에서 장애 포스트모템 찾았다. 평균 복구 시간, CS 비용, 매출 손실. 숫자가 있으면 설득이 된다. 경영진한테도, 팀원들한테도. "이번엔 결제부터 집중 테스트합니다." 누구도 반대 안 했다. 발생 확률 판단하기 확률은 어떻게 아나. 코드 변경량 본다. Git diff 줄 수. 새 기능 > 기존 기능 수정 > 버그 픽스. 개발자 경력 본다. 시니어가 짠 코드 < 주니어가 짠 코드. 미안하지만 통계적 사실이다. 기술 스택 본다. 검증된 라이브러리 < 새로 도입한 라이브러리. 이번 릴리즈 분석했다.결제 로직: 500줄 변경, 주니어 개발, 새 PG사 연동 → 높음 로그인: 100줄 변경, 시니어 개발, 기존 OAuth → 중간 추천 AI: 신규 기능, 외부 API 의존 → 높음숫자로 보면 명확하다. 감이 아니라 근거다.850개를 120개로 팀 미팅 2일차. "4사분면 케이스는 스킵합니다." "3사분면은 스모크 테스트만." "2사분면은 핵심 시나리오만." "1사분면은 풀 테스트." 팀원 하나가 물었다. "4사분면 버그 나오면요?" "나온다. 근데 치명적이지 않다." "우리가 못 찾으면 유저가 찾는다. CS가 처리한다." "그게 현실이다." 13년 전 나라면 이 말 못 했다. 완벽주의였으니까. 지금은 안다. 완벽은 없다. 우선순위만 있다. 120개 케이스 배분했다. 시니어 팀원 → 1사분면 복잡한 시나리오 주니어 팀원 → 1사분면 단순 시나리오 각자 하루 15개씩. 3일이면 된다. 야근 없이. 자동화는 나중에 팀원이 또 물었다. "자동화하면 더 빠른데요." 맞다. 근데 자동화에도 비용이 든다. 스크립트 작성 시간: 케이스당 1시간 유지보수 시간: 월 20시간 CI/CD 파이프라인 구축: 80시간 툴 라이선스: 연 500만원 예산 없다. 인력도 부족하다. "지금은 수동으로 간다. 효율적으로." "1사분면 테스트만 반복되면 그때 자동화한다." 실제로 작년에 그랬다. 로그인 테스트 3달 연속 1사분면. 그때 Selenium으로 자동화했다. 개인 시간 써서. 경영진은 몰랐다. 팀 생산성만 올랐다고 봤다. 그걸로 충분했다. 개발팀이랑 협상 리스크 매트릭스 들고 개발 리드 만났다. "1사분면 기능 버그 나오면 배포 연기합니다." "2사분면은 핫픽스 가능하면 배포 진행합니다." "3, 4사분면은 다음 스프린트로 미룹니다." 개발 리드가 고개 끄덕였다. "합리적이네요." 리스크 기반 접근의 장점이다. 협상 카드가 생긴다. "전부 테스트해야 해요" → 개발팀: "일정 늦어지는데?" "1사분면만 보장합니다" → 개발팀: "그럼 배포 가능하겠네요." 예산 없어도 영향력은 키울 수 있다. 테스트 실행 3일 일정 시작했다. 첫날: 1사분면 결제/로그인 테스트 둘째날: 2사분면 신규 기능 핵심 시나리오 셋째날: 리그레션, 통합 테스트 팀원들 야근 안 했다. 120개만 하니까 가능했다. 버그 발견: 18건 Critical: 3건 (전부 1사분면) Major: 8건 (2사분면 5건, 1사분면 3건) Minor: 7건 (3사분면) Critical 3건 개발팀에 전달했다. "배포 블로커입니다. 수정 필요합니다." 개발 리드가 우선순위 올렸다. 이틀 만에 픽스 완료. Minor 7건은 백로그로. "다음 스프린트에서 처리하겠습니다." 경영진 보고: "치명적 버그 사전 차단, 일정 준수" 칭찬받았다. 배포 후 모니터링 배포 당일 저녁. 슬랙 알람 울렸다. CS팀에서. "결제 오류 문의 들어왔습니다." 심장 내려앉았다. 1사분면인데. 확인했다. 특정 카드사 무이자 할부 오류. 우리는 테스트했다. 근데 그 카드사는 안 했다. 테스트 환경에 그 카드 없었다. PG사에서 제공 안 했다. 밤 10시에 개발팀이랑 회의했다. 원인 파악, 핫픽스 배포. 새벽 2시 종료. 다음 날 포스트모템 작성했다. "테스트 환경 카드사 목록 확대 필요" "PG사 연동 시 전체 카드사 검증 프로세스 추가" 완벽은 없다 회고 미팅 했다. "우리가 못 잡은 버그 나왔습니다." "그래도 잘했습니다." 팀원들 표정이 어두웠다. "850개 다 했으면 잡았을까요?" 고개 저었다. "모르겠습니다. 테스트 환경 문제니까." "우리는 제한된 리소스로 최선을 다했습니다." "1사분면 집중해서 Critical 3건 사전에 잡았습니다." "하나 놓쳤지만 빠르게 대응했습니다." 이게 현실이다. 예산 없는 QA의 현실. 완벽은 환상이다. 우선순위가 전부다. 경영진 설득 분기 보고 때 자료 만들었다. 슬라이드 1: 리스크 기반 테스트 도입 전후 비교테스트 커버리지: 100% → 15% (숫자는 솔직하게) 치명적 버그 차단율: 75% → 90% 장애 복구 시간: 평균 8시간 → 4시간 팀 야근 시간: 월 80시간 → 월 20시간슬라이드 2: 비용 절감 효과장애 대응 인건비 절감: 월 300만원 CS 비용 감소: 월 150만원 예산 투입: 0원슬라이드 3: 향후 제안1사분면 자동화 투자 시 추가 절감 예상: 연 5000만원CFO가 물었다. "예산 없이 이렇게 했다고?" "네. 팀원들이 똑똑하게 일했습니다." "내년 자동화 예산 검토하겠습니다." 처음으로 긍정적 답변 들었다. 다른 팀에 전파 타 팀 QA 리드가 찾아왔다. "리스크 매트릭스 어떻게 만드나요?" 화이트보드 다시 꺼냈다. 설명했다. "과거 데이터 찾으세요. Jira, 장애 로그, CS 문의." "영향도는 숫자로. 발생 확률은 코드 변경량으로." "4사분면 나누고 1사분면만 집중하세요." 그 팀도 예산 없었다. 우리 방식 적용했다. 두 달 뒤 만났다. "팀 야근 절반 줄었어요." QA 커뮤니티에도 올렸다. 노하우 공유. 댓글 많이 달렸다. "우리도 예산 없는데 해볼게요." "리스크 매트릭스 템플릿 공유 가능한가요?" Confluence에 정리해서 링크 걸었다. 1년 후 올해 자동화 예산 나왔다. 3000만원. 적다. 근데 시작할 수 있다. 1사분면 케이스부터 자동화했다. 우선순위대로. 6개월 만에 40개 케이스 자동화. 수동 테스트 시간 30% 줄었다. 그 시간에 2사분면 커버리지 올렸다. 리스크 기반 접근은 계속한다. 예산 있어도. 효율의 문제니까. 경영진이 이제 묻는다. "리스크 1사분면 몇 개죠?" 전부 테스트했냐고 안 묻는다. 팀원들도 바뀌었다. 케이스 수로 자랑 안 한다. "Critical 버그 3건 잡았습니다" 이렇게 말한다. 예산은 핑계다 솔직히 말한다. 예산 있으면 좋다. 툴 사고, 교육받고, 인프라 구축하고. 근데 예산 없다고 품질 포기할 순 없다. 우리한테 있는 건 머리다. 리스크 분석, 우선순위, 과거 데이터. 13년 하면서 배웠다. 비싼 툴보다 똑똑한 전략이 낫다. 물론 둘 다 있으면 최고다. 근데 하나만 고르라면 전략. 내년엔 예산 더 받을 것이다. 리스크 기반으로 성과 냈으니까. 그때도 이 방식은 유지한다. 돈으로 품질 사는 게 아니니까.예산 없어도 머리는 있다. 그걸로 이긴다.