Showing Posts From

팀관리

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

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

전부 테스트할 순 없다 출근했다. 슬랙 메시지 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년 축적한.내일도 리스크 분석이다. 데이터가 쌓인다. 또.

'품질 메트릭스 보면' - 데이터로 말하는 QA

'품질 메트릭스 보면' - 데이터로 말하는 QA

품질 메트릭스 보면 오전 10시. 경영진 보고 미팅이다. 준비했다. 엑셀 3개, PPT 15장, 그래프 7개. 어젯밤 11시까지 걸렸다. "이번 분기 결함 유입률이 전 분기 대비 18% 증가했습니다." 슬라이드를 넘긴다. CFO가 눈썹을 찌푸린다. "그래서 품질이 나빠졌다는 거야?" "아닙니다. 검출률이 올라간 겁니다. 배포 후 결함은 23% 감소했습니다." 다음 슬라이드. 초록색 그래프가 뜬다. "개발 단계에서 더 많이 잡았다는 얘기죠."개발 본부장이 끄덕인다. CFO는 여전히 찌푸린다. "그럼 QA 기간이 길어진 건가?" "평균 2.3일 증가했습니다. 하지만 장애 대응 시간이 평균 8시간 줄었습니다." 계산기를 두드린다. 시연하듯이. "장애 한 건당 투입 인력 평균 15명, 시급 5만원 기준으로 장애 20건 감소하면... 월 1200만원 절감입니다." CFO의 표정이 풀린다. 숫자로 말해야 한다. 관리자가 되고 배운 것. "품질이 좋아요"는 안 먹힌다. "NPS가 3.2점 상승했습니다"는 먹힌다. "버그가 많았어요"는 약하다. "치명도 High 결함이 전월 대비 34% 증가했습니다"가 강하다. 엑셀과의 동거 매주 월요일 오전. 데이터 정리하는 시간이다. Jira에서 추출한다. TestRail에서 가져온다. 슬랙 대화 로그도 뒤진다.총 테스트 케이스: 2,847개 실행률: 94.3% 통과율: 87.6% 결함 검출률: 12.4% 재테스트 비율: 8.9% 회귀 결함: 3건엑셀 시트가 8개다. 피벗 테이블이 12개다. 팀원들은 묻는다. "팀장님, 이거 왜 매주 해요?" "경영진이 요청하면 바로 줘야 해서." 진짜 이유는 다르다. 데이터 없으면 진다. 조직 정치에서. "QA 기간 줄입시다." 개발 본부장이 말한다. "품질 메트릭스 보면..." 내가 대응한다. "지난 3개월간 테스트 기간 단축한 스프린트는 평균 배포 후 결함이 2.8배 높았습니다. 이번 분기 장애 중 67%가 테스트 기간 부족 때문이었고요." 그래프를 보여준다. 빨간색으로 강조된. "한 번의 Critical 장애가 평균 3,200만원의 비용을 발생시킵니다. 고객 이탈률까지 포함하면..." 말을 흐린다. 계산은 이미 해뒀다. 개발 본부장이 물러선다.데이터는 방패다. 내 팀을 지키는. 메트릭스의 정치학 목요일 오후. 제품 기획팀과 미팅이다. "이번 기능, 다음 주 배포 가능할까요?" 기획 리드가 묻는다. 웃으면서. "품질 메트릭스 보면..." 내가 답한다. "현재 미해결 결함 37건. High 우선순위가 12건입니다. 커버리지는 78%고요." 기획 리드의 웃음이 굳는다. "78%면 괜찮은 거 아닌가요?" "내부 기준은 85%입니다. 결제 관련 기능이라 더 높아야 하고요." 노트북을 돌린다. 화면을 보여주면서. "지난 분기 커버리지 80% 미만 상태로 배포한 기능 중 73%에서 운영 이슈가 발생했습니다." 그래프가 말한다. 내 대신. 기획 리드가 한숨을 쉰다. "그럼 언제 가능해요?" "High 결함 해결되면 월요일. 커버리지 85% 채우면 수요일." "수요일은 너무 늦어요." "그럼 리스크 수용하시는 겁니까?" 메모를 꺼낸다. 만년필로 쓴다. "리스크 수용 결정하시면 문서로 남겨야 합니다. 배포 후 이슈 발생 시 책임 소재 명확히 해야 해서요." 기획 리드가 말을 멈춘다. "...수요일에 배포하죠." 데이터는 무기다. 협상의. 회의가 끝나고. 복도에서 개발 리드를 만났다. "리스크 수용 문서 이야기는 좀 과했던 거 아니에요?" 웃었다. 쓸쓸하게. "13년 하면서 배웠어. 데이터 없이는 안 들어. 문서 없이는 책임만 떠안아." "품질 지키려면 정치를 해야 하나요?" "정치가 아니야. 생존이지."숫자로 말하는 법 밤 11시. 아직도 사무실이다. 다음 주 경영 회의 자료를 만든다. 제목: "Q3 품질 개선 성과 및 Q4 전략" 1페이지: 요약배포 후 결함 23% ↓ 고객 불만 15% ↓ 테스트 자동화율 41% ↑ 평균 장애 대응 시간 8시간 ↓숫자만 있다. 설명은 없다. 2페이지: 비용 절감 효과장애 대응 인건비: 월 1,200만원 절감 고객 이탈 방지: 분기 8,500만원 가치 반복 테스트 자동화: 인력 1.2명 효율화회계 용어로 번역했다. CFO가 좋아하는 언어로. 3페이지: 벤치마크업계 평균 테스트 커버리지: 76% 우리 회사: 89% 업계 Top 10%: 92%비교 데이터. 경쟁심을 자극하는. 4페이지: 리스크 매트릭스High Risk & High Impact: 2개 항목 Medium Risk: 7개 항목 대응 방안: 각 항목별 구체적 계획리스크는 숨기지 않는다. 관리한다는 걸 보여준다. 저장했다. 백업도 세 군데에. 팀원 메시지가 온다. "팀장님 아직도 회사세요? 자료 만드시는 거예요?" "응. Q4 전략 발표 준비." "매번 저렇게 준비하세요?" "안 하면 밀려. 데이터 없으면 '느낌'으로 판단당해." "힘드시겠어요." 웃었다. 쓴웃음. "이게 관리자야. 현업은 코드로 말하지. 관리자는 엑셀로 싸워." 데이터의 그림자 금요일 오전. 팀 회의다. "다들 수고했어. 이번 주 배포 무사히 끝났어." 박수를 친다. 팀원들이 따라 친다. "품질 메트릭스 보면..." 슬라이드를 켠다. 팀원들이 웃는다. 내 입버릇이 됐다. "이번 주 테스트 실행률 96.2%. 지난주보다 2.1%p 상승. 결함 검출률 14.3%. 평균보다 1.9%p 높아." 칭찬한다. 구체적으로. "특히 민준씨 담당 결제 모듈. 엣지 케이스 3건 추가로 잡아줬어. Critical 결함 2건 사전 방지했고." 민준이 쑥스럽게 웃는다. "수진씨 자동화 스크립트 덕분에 회귀 테스트 시간 4.2시간 단축됐어. 이거 이번 분기 성과로 강조할게." 수진이 고개를 끄덕인다. 숫자로 칭찬한다. 애매한 칭찬보다 강하다. "근데 팀장님." 다희가 손을 든다. "왜?" "저희가 일 잘하는 건... 숫자로만 보여야 하나요?" 멈칫했다. "무슨 뜻이야?" "제가 이번에 UX 개선 의견 3개 냈잖아요. 그거는 품질 메트릭스에 안 잡히는데..." 말이 막혔다. 다희 말이 맞다. 품질은 숫자만이 아니다. 사용자 경험, 직관적 UI, 부드러운 인터랙션. 하지만 경영진은 그걸 모른다. "너 의견 좋았어. 기획팀도 채택했잖아." "네. 근데 그게 제 성과 평가에..." "반영할게. 정성 평가에." 약한 대답이다. 나도 안다. 정량 평가가 강하다. 숫자가 들어간 성과가. "다희야. 솔직히 말할게." 팀원들이 집중한다. "회사는 숫자로 판단해. 불공평하지. 근데 현실이야." "그럼 숫자로 안 나오는 일은 안 하는 게 나은 건가요?" 대답하지 못했다. 데이터의 그림자다. 측정되지 않는 가치는 인정받지 못한다. 메트릭스 너머 주말이다. 집에서 쉰다. 딸아이가 묻는다. "엄마는 회사에서 뭐 해?" "품질 확인하는 일." "품질이 뭔데?" 설명하려다 멈췄다. "물건이 잘 작동하는지 보는 거야." "그럼 고장 나면 엄마가 고쳐?" "아니. 고치는 건 아빠 같은 개발자가 해. 엄마는 고장 날 것 같은 거 미리 찾아내." "그럼 엄마가 없으면 어떻게 돼?" 생각했다. "물건이 자주 고장 나. 사람들이 짜증 내지." "그럼 엄마 중요하네!" 웃었다. 아이는 단순하다. 남편이 옆에서 커피를 내민다. "어제도 늦게 왔더라. 자료 만들었어?" "응. Q4 전략 발표." "또 품질 메트릭스?" "웃기지. 13년 했는데 아직도 증명해야 해." "개발도 비슷해. 코드 리뷰 통과해도 성능 지표 안 나오면 인정 안 받아." "너는 그래도 결과물이 보이잖아. 기능이 생기잖아." "너도 결과물 있어. 장애가 안 나는 거." 한숨을 쉬었다. "장애 안 나는 게 성과야. 웃긴 거지. 안 나야 정상인데." "그럼 메트릭스는 왜 만들어?" "안 만들면 'QA가 뭐 하는지 모르겠다'고 해." "만들면?" "'숫자에 집착한다'고 하지." 남편이 웃는다. 씁쓸하게. "딜레마네." "관리자의 숙명이야." 데이터가 말하지 못하는 것 월요일 아침이다. 출근했다. 메일이 와 있다. CEO 이름으로. "지난 분기 품질 성과 우수팀 선정: QA팀" 상품권 50만원어치다. 팀원들과 나눠 가지라고. 기쁘다. 솔직히. 인정받은 기분이다. 숫자가 증명해줬다. 하지만 찝찝하다. 우리 팀이 한 일이 숫자만은 아닌데. 개발팀과 새벽까지 이슈 분석했던 것. 기획팀 요구사항 명확히 하려고 5번 미팅 잡았던 것. 신입 개발자 온보딩 도와줬던 것. 품질 메트릭스에 안 나온다. 팀 회의에서 공유한다. "이번 분기 우수팀 받았어. 다들 수고했어." 환호성이다. 박수가 터진다. "상품권은 똑같이 나눠. 회식도 하자." "팀장님 덕분이에요!" 아니다. 팀원들 덕분이다. 하지만 경영진이 본 건 내가 만든 자료다. "이번 성과가 데이터로 입증됐어. 근데..." 말을 이었다. "우리가 한 일이 숫자만은 아니야. 협업하고, 소통하고, 문제 해결한 거." "근데 그게 평가되려면 결국 숫자로..." 수진이 말한다. "맞아. 현실은 그래. 그래서 내가 메트릭스 만들어." "타협하시는 거예요?" "타협 아니야. 번역이지." 팀원들이 고개를 갸우뚱한다. "우리가 한 일을 회사가 이해하는 언어로 바꾸는 거야. 숫자로." "그럼 숫자가 안 나오는 일은?" "그것도 중요해. 계속 해. 근데 성과 어필할 땐 숫자 필요해." "이중 잣대 같은데요." 웃었다. 쓴웃음. "관리자가 되면 알아. 이상과 현실 사이에서 줄타기하는 거야." 메트릭스라는 도구 점심시간이다. 혼자 먹는다. 핸드폰을 본다. QA 커뮤니티에 글이 올라왔다. "QA는 왜 항상 증명해야 하나요?" 댓글이 달린다. "개발은 기능으로 보여주잖아요. QA는 뭘로 보여줘요?" "품질 메트릭스 만들어 보세요." "숫자로 말하면 인정받아요." 내가 댓글을 단다. "메트릭스는 도구일 뿐입니다. 품질 그 자체는 아니에요." 누군가 답글을 단다. "그럼 왜 만드세요?" 타이핑한다. 지우고. 다시 쓴다. "안 만들면 우리 일이 안 보여요. 보이지 않으면 인정받지 못해요. 인정받지 못하면 투자받지 못하고요." "그럼 결국 정치 아닌가요?" 멈칫했다. 정치라는 단어가 불편하다. 하지만 틀린 말은 아니다. "정치라기보다... 커뮤니케이션이에요. 경영진이 이해하는 방식으로 말하는 거죠." "피곤하시겠어요." "피곤하죠. 근데 내 팀 지키려면 해야 해요." 답글을 올렸다. 핸드폰을 내려놓았다. 13년 했다. 여전히 증명한다. 언제쯤 QA의 가치가 당연하게 인정받을까. 언제쯤 메트릭스 없이도 신뢰받을까. 모르겠다. 지금은 엑셀을 켜야 할 시간이다.품질 메트릭스는 내 방패이자 무기다. 하지만 가끔 묻는다. 숫자 너머의 가치는 언제쯤 보일까.

13년 경력인데 여전히 '품질 검사 담당'으로만 불리나

13년 경력인데 여전히 '품질 검사 담당'으로만 불리나

13년차 팀장 오늘 경영진 보고가 있었다. 개발 팀장, 기획 팀장, 나. 한 시간 발표했다. 개발 팀장은 "신기술 도입"으로 칭찬받았다. 기획 팀장은 "비즈니스 임팩트"로 인정받았다. 내 차례가 왔다. "QA는 배포 일정 맞춰주기만 하면 돼요." 13년 했다. 여전히 이렇다.같은 팀장인데 우리는 같은 급여 테이블이다. 팀장 직급, 연봉 8500만원. 관리자 수당도 같다. 그런데 회의에서 다르다. 개발 팀장: "기술 부채 해소하려면 3개월 필요합니다." 경영진: "알겠습니다. 계획 세워주세요." 기획 팀장: "사용자 리서치 기간 2주 더 주세요." 경영진: "필요하면 하세요." 내 차례. 나: "리그레션 테스트 자동화하려면 인력 2명 더 필요합니다." 경영진: "그거 꼭 해야 해요? 수동으로 하면 안 돼요?" 나: "품질 전략 재수립하려면 시간이..." 경영진: "일정은 지켜야죠. 품질은 당연한 거고." 같은 팀장이다. 왜 나만 이럴까. 전략가가 아니라 검사자 리스크 기반 테스트 전략. 13년 동안 갈고 닦았다. 어느 기능을 집중 테스트할지. 어느 영역을 자동화할지. 리소스를 어떻게 배분할지. 데이터 기반으로 판단한다. 과거 장애 이력, 변경 빈도, 비즈니스 임팩트. 엑셀에 정리한 게 아니다. TestRail, Jira 연동해서 실시간 대시보드다. 지난주 전략 회의. 신규 기능 20개, 일정 2주. 불가능하다. "우선순위 기반으로 테스트 범위 조정하겠습니다." 내가 말했다. 개발 팀장이 웃었다. "QA는 다 테스트하는 거 아니에요?" 전략이 아니다. 그냥 검사다. 내가 하는 건 체크리스트 체크. 그들 눈엔 그렇다.장애는 QA 책임 지난달 장애 났다. 금요일 밤 10시. 결제 모듈 오류. 토요일 새벽 3시까지 대응했다. 원인 분석, 재발 방지책, 포스트모템. 월요일 보고서 20페이지 작성했다. 회의에서 질문 받았다. "왜 QA에서 못 잡았어요?" 변경 사항 300개. 테스트 일정 3일. 자동화 커버리지 40%. 인력 8명. 설명했다. 리소스 한계, 우선순위 결정 과정, 리스크 평가 근거. "그래도 QA 아니에요?" 개발 팀장은 안 물어본다. "왜 버그를 만들었냐"고. 기획 팀장도 안 물어본다. "왜 요구사항이 애매했냐"고. 나만 묻는다. "왜 못 잡았냐"고. 품질은 협업의 결과다. 입버릇처럼 말한다. 아무도 안 듣는다. 투자는 안 되는 영역 올해 예산 회의. 각 팀 투자 계획 발표했다. 개발팀: "클라우드 인프라 확장, 3억" 승인. 기획팀: "사용자 분석 툴 도입, 5천만원" 승인. QA팀: "테스트 자동화 인프라, 1억" 보류. "수동으로 하면 안 돼요?" 또 그 질문. 자동화하면 회귀 테스트 시간이 2주에서 2시간으로 준다. 설명했다. 리소스 절감 효과, ROI 계산, 벤치마크 데이터. "일단 올해는 보류요. 꼭 필요하면 내년에." 내년에도 똑같다. 매년 보류다. 개발은 투자. 기획은 투자. QA는 비용. 그들 눈엔 그렇다.팀원들한테 미안하다 우리 팀 8명. 다들 열심히 한다. 막내는 자동화 공부한다. 야근하면서 셀레니움 돌린다. "팀장님, 이거 정식으로 도입하면 안 될까요?" 중견은 성능 테스트 전문가다. JMeter로 병목 잡아낸다. "부하 테스트 환경 제대로 갖추고 싶어요." 다 들어주고 싶다. 예산이 없다. 아니, 예산은 있다. 우선순위가 낮다. 지난주 1on1. 5년차 팀원이 물었다. "팀장님, QA도 커리어 전망 있나요?" 할 말이 없었다. "있다"고 말했다. 거짓말은 아니다. 하지만 확신도 없다. 13년 했다. 팀장까지 왔다. 그래도 '검사 담당'이다. 팀원들은 뭘 보고 희망을 가질까. 다른 회사도 똑같다 QA 커뮤니티 모임. 한 달에 한 번 만난다. 타사 QA 리드들. 다들 똑같다. "우리도 그래요." "저희도 예산 안 나와요." "장애는 무조건 QA 책임이래요." 한 명이 말했다. "외국계는 좀 나아요. QA를 전략 파트너로 봐요." 부럽다. 이직할까. 아니다. 여기서도 13년 걸렸다. 다시 시작하기엔 나이가. 38세다. QA 시작한 게 25세. 그때는 테스터였다. 지금은 팀장이다. 호칭만 바뀌었다. 역할은 그대로다. 인정받고 싶다 거창한 거 아니다. "QA 덕분에 품질이 좋아졌어요." 이 말 듣고 싶다. "테스트 전략 탄탄하네요." 이 인정 받고 싶다. "투자할 만한 가치가 있네요." 이 평가 받고 싶다. 13년 했다. 장애 막은 건 몇 번인지 모른다. 배포 전에 치명적 버그 잡은 것도 수십 건. 아무도 모른다. 장애가 안 난 건 당연한 거다. 품질이 좋은 건 개발을 잘한 거다. QA는 보험이다. 있어야 하지만 티 나면 안 되는. 티 나면 "왜 못 잡았냐"는 질문. 안 나면 "필요 없는 거 아니냐"는 의심. 그래도 계속한다 어제 배포 있었다. 신규 기능 15개. 2주 테스트. 팀원들이랑 밤샜다. 리그레션 돌리고, 시나리오 검증하고, 성능 체크했다. 배포 성공. 장애 없었다. 슬랙에 올라왔다. "배포 성공했습니다. 수고하셨습니다." QA 언급 없다. 괜찮다. 익숙하다. 팀원들한테 말했다. "다들 고생했어. 우리가 잘해서 문제없었던 거야." 팀원들이 웃었다. "팀장님 덕분이죠." 아니다. 다들 잘했다. 퇴근하면서 생각했다. 13년 했다. 앞으로 몇 년 더 할까. 모르겠다. 하지만 오늘은 했다. 내일도 할 거다. 품질 검사 담당이어도. 전략가로 인정 안 받아도. 투자 우선순위 낮아도. 누군가는 해야 한다. 내가 하는 게 낫다. 13년 경력이니까.13년차 팀장인데, 여전히 '검사나 하는 사람'이다. 그래도 내일도 출근한다.

테스트 케이스 작성 vs. 팀 운영, 무엇이 내 일인가

테스트 케이스 작성 vs. 팀 운영, 무엇이 내 일인가

아침 9시, 두 개의 창 출근했다. 모니터 두 개를 켠다. 왼쪽 화면은 Jira. 팀원 8명의 티켓이 쫙 깔려 있다. 빨간색 우선순위가 벌써 다섯 개. 누가 어디 막혔는지 파악해야 한다. 리소스 재배분해야 한다. 오늘 1on1 두 건 있다. 오른쪽 화면은 TestRail. 내가 직접 짜던 테스트 케이스. 3주 전에 손댄 게 마지막이다. 결제 시스템 리뉴얼 프로젝트. 리스크 높은 영역인데 내가 직접 봐야 편하다. 아니, 봤어야 했다.커피 마신다. 팀장실 문 열어둔다. 누가 들어올 거다. 항상 그렇다. 10분도 안 돼서 막내가 온다. "팀장님, 이 케이스 어떻게 해야 할까요?" 나는 알고 있다. 3분이면 설명할 수 있다. 하지만 물고기 잡아주기가 아니라 낚시 방법을 알려줘야 한다. 15분 쓴다. TestRail 창은 그대로다. 경력 13년, 코드 친 지 7년 QA 13년 했다. 처음 5년은 손으로 다 클릭했다. 엑셀에 테스트 케이스 정리했다. 버그 찾는 게 재미있었다. 6년차에 자동화 시작했다. Selenium 배웠다. Python 독학했다. 밤새워 프레임워크 짰다. 회사에서 유일하게 자동화 돌릴 수 있는 사람이었다. 8년차에 시니어 됐다. 테스트 전략 짜는 사람. 리스크 기반 테스트 설계하는 사람. 품질 메트릭스 정의하는 사람. 그때가 제일 재미있었다. 10년차에 팀장 제안 받았다. "당신이 적임자입니다." 거절 못 했다. 아니, 안 했다. 연봉도 올랐다. 8500만원. 관리자 수당 포함. 그때부터 코드를 안 쳤다. 정확히는 못 쳤다.팀원 한 명이 퇴사했다. 충원 요청서 썼다. HR이랑 실랑이했다. 면접 봤다. 온보딩 계획 세웠다. 한 달 걸렸다. 개발팀이 일정 당긴다고 했다. 경영진이 품질 리포트 달라고 했다. QA 자동화 투자 제안서 썼다. 예산 안 나왔다. 다시 썼다. 어느 날 후배가 물었다. "팀장님, 요즘 테스트는 안 하세요?" 뭐라고 대답했는지 기억 안 난다. 전문가 트랙이라는 환상 회사에 전문가 트랙이 있다. Principal QA Engineer. 관리 안 하고 전문성으로 가는 길. 연봉도 팀장급 받는다. 이론상으로는. 실제로 그 직급 달고 있는 사람 봤다. 한 명. 그 사람은 자동화 프레임워크 3개 회사에 구축했다. 컨퍼런스에서 발표한다. 회사 밖에서도 유명하다. 나는? 3년 동안 자동화 코드 한 줄 안 짰다. 깃헙 프로필 들어가 봤다. 초록색 잔디가 없다. 2021년에 멈춰 있다. 그해에 팀장 됐다. 테스트 자동화 트렌드 찾아봤다. Playwright가 뭔지 모른다. Cypress는 들어봤는데 써본 적 없다. AI 테스팅 툴들이 나오는데 하나도 모른다.옆 회사 QA 리드 만났다. 나이 비슷하다. 그 사람은 여전히 코드 짠다. "팀은 3명만 보고, 나는 아키텍처 설계에 집중해요." 부럽다고 했다. "당신은 관리 잘하잖아요. 저는 못해요." 위로인지 모르겠다. 집에 와서 남편한테 말했다. 개발자인 남편은 말했다. "그럼 다시 하면 되지." 쉽게 말한다. 13년 차가 주니어처럼 다시 시작한다고? 팀원의 성장, 나의 정체 1on1 했다. 3년 차 팀원이다. 자동화 열심히 한다. 최근에 CI/CD 파이프라인에 테스트 붙이는 거 혼자 했다. "팀장님 덕분에 많이 배웠어요." 고맙다고 했다. 근데 속으로 생각했다. 내가 뭘 가르쳤지? 방향 제시했다. 리소스 확보해줬다. 막히는 거 뚫어줬다. 그게 다다. 기술은 본인이 배웠다. 다른 팀원은 컨퍼런스 발표 준비 중이다. 테스트 전략 수립 사례 공유한다고. 발표 자료 검토해줬다. 좋다고 했다. 진심이다. 근데 그 자료 내가 발표하면 안 되나? 아니, 전략 세운 건 나인데. 이런 생각 하는 내가 싫다. 팀원들은 자란다. 나는? 회의만 한다. 일정 조율한다. 리포트 쓴다. 경영진 설득한다. 이게 성장인가? 작년 연말 평가 때 적었다. "팀 품질 지표 30% 개선, 자동화 커버리지 60%로 상승, 팀원 2명 시니어 승진." 내 개인 성과는? "팀 관리 우수." 그게 다다. 금요일 저녁 장애 금요일 7시. 퇴근하려는데 슬랙 울린다. 배포 후 장애. 결제 실패율 급증. 팀원들 불러 모았다. 로그 분석한다. 원인 찾는다. 개발팀이랑 협업한다. 9시에 해결됐다. 포스트모템 회의 잡았다. 월요일 오전. 내가 진행한다. 일요일 밤에 자료 정리했다. 타임라인, 원인 분석, 재발 방지책. 꼼꼼하게 적었다. 13년 경력은 여기서 나온다. 회의 시작했다. 개발 리드가 말했다. "QA 테스트에서 왜 못 잡았어요?" 예상한 질문이다. "결제 서버 부하 테스트는 스테이징에서 프로덕션 수준으로 재현이 어렵습니다. 다만 리스크는 사전에 공유했고, 모니터링 강화 요청드렸었습니다." 증거 자료 보여줬다. 2주 전 회의록. 내가 작성한 리스크 리스트. 개발 리드는 더 안 물었다. 이게 내 일이다. 팀 지키기. 책임 떠넘기기 아니라, 품질 책임 구조 명확히 하기. 근데 이런 회의 준비하는 동안, 누가 테스트 케이스 개선하지? 팀원들이다. 선배의 조언 QA 커뮤니티 모임 갔다. 나보다 5년 선배가 있다. Principal QA로 전환했다고 한다. 물어봤다. "어떻게 하셨어요?" "팀장 3년 하다가 내려놨어요. 전문가 트랙 신청했고요. 연봉 협상 빡세게 했어요. 깎이긴 했는데, 감수했죠." "후회는요?" "없어요. 저는 사람 관리가 안 맞더라고요. 코드 짜는 게 좋아요." 부러웠다. 근데 나는 사람 관리가 싫은가? 아니다. 어렵지만 보람 있다. "그럼 관리가 맞는 거 아니에요?" 선배가 말했다. "근데 기술은요?" "관리자도 기술 아는 게 중요하죠. 근데 직접 안 해도 돼요. 방향 알고, 판단할 수 있으면 돼요. 그게 리더십이에요." 위로처럼 들렸다. 근데 납득은 안 됐다. 집에 오는 길에 생각했다. 나는 뭘 원하는 거지? 이미 늦었나 38살이다. QA 13년 차다. 팀장 3년 차다. 지금 다시 전문가 트랙 가려면? 자동화 프레임워크 새로 배워야 한다. AI 테스팅 공부해야 한다. 컨퍼런스 발표해야 한다. 오픈소스 기여해야 한다. 가능한가? 시간 있나? 체력 있나? 회사 끝나고 저녁 7시. 딸 숙제 봐줘야 한다. 남편이랑 저녁 먹어야 한다. 주말에 공부한다고? 매주? 20대 후배들 본다. 밤새워 공부한다. 사이드 프로젝트 한다. 나도 그랬다. 10년 전에. 지금은 장애 전화 오면 심장 먼저 뛴다. 체력 아니라 책임감 때문에. 이게 늙는 거다. 아니, 경력이 쌓이는 거다. 관점의 차이다. 근데 왜 불안하지? LinkedIn 본다. 같은 연차 QA들. 절반은 리드 매니저다. 절반은 Principal이다. 나는? QA Lead. 어정쩡하다. 이력서 업데이트했다. "13년 경력의 QA 전문가. 팀 리딩 및 품질 전략 수립." 전문가 맞나? 3년 동안 손으로 테스트 한 번 안 했는데? 월요일 아침, 같은 창 출근했다. 모니터 켰다. 왼쪽 화면 Jira. 오늘도 빨간 우선순위. 오늘도 팀원 이슈. 오늘도 리소스 배분. 오른쪽 화면 TestRail. 여전히 3주 전 화면. 커피 마신다. 슬랙 메시지 온다. 개발 리드다. "이번 스프린트 일정 논의 좀 해요." 회의 잡는다. 오전 10시. 그 전에 30분 있다. TestRail 열었다. 결제 시스템 테스트 케이스. 손 좀 봐야 한다. 5분 지났다. 팀원이 들어온다. "팀장님, 이거 좀 봐주세요." TestRail 창 내린다. 이게 내 선택이다. 매일 하는. 의식하지 않고 하는 선택. 어쩌면 이미 선택한 거다. 3년 전에. 질문의 끝 "테스트 케이스 작성이 내 일인가, 팀 운영이 내 일인가?" 잘못된 질문이었다. 둘 다 내 일이 될 수는 없다. 시간이 물리적으로 부족하다. 그럼 하나를 선택해야 하나? 그것도 아니다. 진짜 질문은 이거다. "나는 어떤 임팩트를 만들고 싶은가?" 내가 직접 테스트 케이스 100개 짜면, 100개의 버그를 잡는다. 내가 팀원 8명 잘 키우면, 그들이 1000개의 버그를 잡는다. 내가 자동화 프레임워크 하나 만들면, 우리 팀만 쓴다. 내가 테스트 문화를 바꾸면, 회사 전체가 바뀐다. 이렇게 생각하면 답은 나온다. 관리가 맞다. 근데 왜 계속 불안한가? 인정받고 싶어서다. "전문가"로. "관리 잘한다"는 말은 기술이 없다는 말처럼 들린다. 편견이다. 내 편견. 사실 알고 있다. 좋은 관리자는 더 어렵다. 기술은 공부하면 된다. 사람은 공식이 없다. 내일도 두 개의 창 내일도 모니터 켤 거다. 왼쪽 Jira, 오른쪽 TestRail. TestRail은 계속 3주 전 화면일 거다. 한 달 전이 될 거다. 그리고 어느 날, 그 창을 닫을 거다. 아니면 팀원 한 명에게 넘길 거다. "이거 네가 봐줘. 네가 나보다 더 잘 알아." 그게 성장이다. 내가 아니라 팀의. 그리고 나는? 새로운 창을 열 거다. 품질 문화. 테스트 전략. 조직 성숙도. 손으로 안 만지는 것들. 하지만 더 큰 것들. 13년 차의 일. 팀장의 일. 선택이 아니라 진화다.여전히 불안하긴 하다. 근데 오늘은 TestRail 안 봤다.