QA 커뮤니티 멘토로서 같은 고민을 듣는 날

QA 커뮤니티 멘토로서 같은 고민을 듣는 날

목요일 저녁 7시 판교역 카페에 앉았다. QA 커뮤니티 정기 모임. 3개월에 한 번 모인다. 오늘 참석자 5명. 나 포함. 다들 팀장급. 회사는 제각각이다. 네이버 계열사, 카카오 자회사, SI 업체, 스타트업, 대기업 SI 부서. 다들 퇴근하고 왔다. 나도 7시에 나왔다. 남편한테 미리 말해뒀다. 주문한 아메리카노 받았다. 네 번째 커피다. 오늘.자기소개부터 신규 멤버가 한 명 있다. 30대 중반. 스타트업 QA 리드. "저희는 개발자 12명에 QA는 저 혼자예요." 익숙한 시작이다. "배포 주기가 2주인데 테스트는 3일 주고요." 역시. "자동화 하고 싶은데 개발자들이 API 문서를 안 써서..." 웃음이 나왔다. 다들 웃는다. 나도 13년 전에 똑같은 말 했다. 지금도 한다. 카카오 자회사 팀장이 말했다. "우리도 똑같아요. 근데 우리는 개발자 30명." 네이버 계열사는 개발자 50명에 QA 4명이란다. 나는? 개발자 80명에 QA 8명. 비율은 비슷하다.고민 1: 일정 vs 품질 SI 업체 팀장이 먼저 꺼냈다. "이번 프로젝트 PM이 테스트 기간 반 자르래요." "원래 4주였는데 2주로." "근데 기능은 똑같고요." 다들 고개를 끄덕인다. 나도 지난달에 똑같은 일 겪었다. 개발 지연을 QA 기간에서 메꾸라고. "PM한테 뭐라고 했어요?" 스타트업 리드가 물었다. "리스크 문서 작성해서 올렸죠. 놓칠 수 있는 버그 유형이랑 영향도." "그래서요?" "읽기는 했대요. 근데 일정이 우선이래요." 침묵. 카카오 팀장이 말했다. "우리도 똑같았어요. 작년에." "리스크 문서 올리고, 서명받고, 그래도 밀어붙이더라고요." "결국 장애 터졌고." "그때 누가 욕먹었냐면..." 말 안 해도 안다. QA다. 나도 5년 전에 겪었다. 리스크 알렸는데 무시당하고, 결국 장애 나고, 포스트모템에서 'QA 미흡'이라고 적혔다. 그때 밤새 울었다. 고민 2: 자동화 투자 네이버 계열사 팀장이 얘기했다. "자동화 투자 제안서 올렸어요. 3년째." "올해도 반려됐고요." "이유가 ROI가 안 나온대요." 스타트업 리드가 맞장구쳤다. "ROI 어떻게 증명해요? 안 터진 장애를 어떻게 숫자로?" 정확하다. 나도 작년에 자동화 툴 도입 제안했다. 3개월 작성했다. 시뮬레이션 돌렸다. 인건비 절감, 배포 리드타임 단축, 회귀 테스트 자동화율. 다 숫자로 만들었다. 결과? 보류. "내년에 다시 검토하겠습니다." 내년 되면 또 내후년. SI 업체 팀장이 한숨 쉬었다. "우리는 아예 제안도 못 올려요." "프로젝트 끝나면 팀 해체되는데 뭘 투자해요." "매번 새 프로젝트마다 맨땅에서 시작이에요." 카카오 팀장이 고개 저었다. "그나마 우리는 좀 나은가..." "작년에 셀레늄 그리드 구축했거든요." "근데 유지보수할 사람이 없어요. 개발자들은 관심 없고." 결국 똑같다.고민 3: 팀원 성장 내가 물었다. "팀원들 성장시키는 거 어떻게 해요?" 다들 표정이 어두워졌다. 스타트업 리드가 먼저 말했다. "저는 혼자라서..." "성장도 뭐도 일 돌리기도 바빠요." 네이버 계열사는 다르다. "우리는 4명인데요." "한 명은 주니어, 나머지는 3년차들." "주니어 교육하면서 내 일 하려니까..." "결국 내가 다 하게 되더라고요." 안다. 나도 그렇다. 팀원 8명 중에 2명은 신입. 1년차랑 2년차. 1on1 하고, 코드 리뷰해주고, 테스트 전략 같이 세우고. 시간 빠진다. 내 일은 밤에 한다. SI 업체 팀장이 말했다. "근데 키워놔봤자 이직해요." "작년에 3년 키운 애 네이버 갔어요." "축하는 해줬는데... 속으론 허무하더라고요." 카카오 팀장도 고개 끄덕였다. "우리도 작년에 두 명 나갔어요." "한 명은 쿠팡, 한 명은 토스." "연봉 2천 올려준대요." 침묵이 길었다. 나도 작년에 팀원 하나 보냈다. 당근으로. 연봉 1500 올려줬다고. 기뻤다. 진심으로. 근데 동시에 허무했다. 3년 키웠는데. 고민 4: 커리어 고민 카카오 팀장이 조심스럽게 꺼냈다. "저... 이직 고민 중이에요." "팀장 5년 했는데 더 갈 곳이 없어요." "본부장? QA 본부장은 없잖아요." 맞다. 없다. "그렇다고 다시 실무로 돌아가기엔..." "관리만 5년 했더니 손 놓친 게 너무 많아요." 스타트업 리드가 물었다. "CPO 같은 쪽은요?" "QA에서 CPO 간 사람 못 봤어요. 주변에." "다들 PM 출신이거나 개발 출신." 네이버 계열사 팀장이 말했다. "저는 테스트 자동화 전문가로 가볼까 해요." "근데 그것도... 시장이 작잖아요." "결국 또 팀장 하게 되더라고요." 나는? 13년 했다. 8년은 실무, 5년은 팀장. 다음은 뭐지? 모르겠다. SI 업체 팀장이 씁쓸하게 웃었다. "QA는 경력 쌓을수록 애매해져요." "시니어 개발자는 있는데 시니어 QA는..." "뭐라고 불러야 할지도 모르겠어요." 다들 웃었다. 쓴웃음. 고민 5: 인정받기 네이버 계열사 팀장이 말했다. "이번에 부서 평가에서 우리 팀 B 받았어요." "장애 한 건도 없었는데." "개발팀은 A 받았고요." "기능 많이 만들었대요." 익숙하다. 스타트업 리드가 격하게 공감했다. "맞아요. 안 터지는 게 당연한 거래요." "근데 한 번 터지면 QA 뭐했냐고." SI 업체 팀장이 말했다. "프로젝트 회고할 때요." "개발자들은 '이런 기술 썼다' 자랑하잖아요." "우리는 뭐라고 해요? '버그 몇 개 찾았다?'" "허무해요." 카카오 팀장이 한숨 쉬었다. "경영진 보고할 때도 그래요." "품질 지표 올려도 반응이 없어요." "배포 성공률 99%라고 해도 '당연한 거 아니냐'고." "근데 개발팀이 신기술 도입했다 그러면 박수 쳐요." 나도 안다. 지난달 경영진 보고. 2분기 품질 지표 발표했다. 장애 건수 전년 대비 40% 감소. 회귀 버그 제로. 반응? "수고했습니다." 그 다음 발표는 개발팀. AI 모델 도입. 반응? 30분 토론. "혁신적이다." 그날 밤에 남편한테 투덜댔다. "QA는 혁신이 없대." 남편이 말했다. "장애 안 나는 게 혁신 아니야?" 고마웠다. 근데 회사는 그렇게 안 본다. 해결책은 없다 스타트업 리드가 물었다. "선배님들은... 어떻게 버티세요?" 침묵. SI 팀장이 먼저 답했다. "그냥... 버텨요." "다른 방법이 없어서." 카카오 팀장이 말했다. "저는 팀원들 생각하면서." "얘네라도 잘 키워야지." 네이버 계열사 팀장은 솔직했다. "사실 잘 모르겠어요." "그냥 출근해요. 매일." 나는? "저도 모르겠어요. 13년 했는데도." "근데 이상하게 계속하게 돼요." 다들 웃었다. 스타트업 리드가 말했다. "오늘 와서 좋았어요." "나만 힘든 게 아니구나 싶어서." 네이버 계열사 팀장이 고개 끄덕였다. "저도요." "혼자 고민하면 내가 못난 건가 싶은데." "다들 비슷하니까 좀..." 카카오 팀장이 웃었다. "위로는 안 되는데 위안은 돼요." 맞다. 정확한 표현이다. 해결책은 없다. 오늘도 없었다. 근데 혼자가 아니라는 걸 확인했다. 그게 뭔가는 했다. 9시 반 모임 끝났다. 다들 일어났다. "다음 달에 또 봐요." "네, 수고하세요." "조심히 들어가세요." 판교역으로 걸어갔다. 지하철 탔다. 핸드폰 봤다. 슬랙 알림 3개. 개발팀에서 내일 핫픽스 배포한대. "QA 가능한가요?" 시간 봤다. 9시 43분. 답장 쳤다. "네, 내일 오전에 확인하겠습니다." 지하철 창문에 내 얼굴이 비쳤다. 피곤해 보인다. 38살. 13년차. 여전히 답은 모르겠다. 근데 내일도 출근한다. 카페에서 만난 사람들도 마찬가지겠지. 다들 답 없이 내일 출근한다. 그게 QA 리드다.혼자가 아니라는 걸 아는 것. 그게 전부였다. 오늘도.

'우선순위가' - 내 입버릇이 된 그 말의 무게

'우선순위가' - 내 입버릇이 된 그 말의 무게

'우선순위가' - 내 입버릇이 된 그 말의 무게 아침 9시, 리스트 작성 출근했다. 커피 뽑고 앉았다. 오늘도 리스트부터 쓴다.배포 전 최종 검증 팀원 1on1 (3건) 경영진 품질 리포트 신규 기능 테스트 전략 회의 자동화 환경 장애 대응5개다. 하루는 8시간이다. 계산이 안 맞는다. 매일 그렇다. "우선순위가 뭐야?" 혼잣말이다. 13년 차의 입버릇. 이제 자동으로 나온다. 숨 쉬듯. 중요한 게 5개면 우선순위가 없는 거다. 중요한 게 1개가 되어야 우선순위다. 그래서 4개를 포기해야 한다. 아니, 포기가 아니다. '미루는' 거다. 그렇게 생각하면 덜 무겁다. 조금.오전 10시, 첫 번째 선택 개발팀 리드가 슬랙 보냈다. "배포 일정 하루 당깁니다. 가능할까요?" 불가능하다. 테스트 시간이 부족하다. 하지만 "불가능"이라고 답할 수 없다. 그러면 협업 안 하는 팀이 된다. "우선순위 정리해서 답변드릴게요." 또 나왔다. 우선순위. 지금 하던 일을 멈췄다. 배포 범위를 확인했다. 30개 기능 변경. 리스크 분석했다. 고위험 7개, 중위험 15개. 핵심만 테스트하면 된다. 나머지는... 운에 맡긴다. "핵심 기능 7개는 검증 가능합니다. 나머지는 배포 후 모니터링으로." 답장 보냈다. 속은 불편하다. 하지만 이게 현실이다. 우선순위를 정한다는 건 뭔가를 포기한다는 뜻이다. 팀원들한테 공유했다. "이번 배포는 고위험 케이스 위주로." 다들 안다. 완벽한 테스트는 없다는 걸. 그래도 말해야 한다. 책임은 내 거니까. 오후 2시, 두 번째 선택 1on1 시간이다. 3년 차 팀원. "팀장님, 자동화 공부하고 싶어요." 좋다. 당연히 지원해야 한다. 팀의 미래다. 투자해야 한다. "근데 지금 당장은 수동 테스트가 급해서..." 또 나왔다. 우선순위. 팀원의 성장 vs 당장의 일정. 미래 vs 현재. 투자 vs 실행. 항상 이 선택이다. 정답은 없다. 둘 다 중요하다. "일단 이번 스프린트는 수동 위주로. 다음 달부터 자동화 시간 30% 배정할게." 팀원이 고개를 끄덕였다. 표정은... 실망이 섞였다. 나도 안다. 다음 달에도 급한 게 생긴다는 걸. 30%는 20%가 되고, 10%가 된다. 결국 안 된다. 하지만 지금 당장 배포가 막히면 팀 전체가 욕먹는다. 우선순위를 정한다는 건 누군가를 실망시킨다는 뜻이다.오후 4시, 세 번째 선택 경영진 보고 준비했다. 이번 분기 품질 메트릭스.배포 성공률: 87% 장애 재발률: 12% 테스트 커버리지: 63%숫자가 안 좋다. 이유는 안다. 테스트 시간이 부족했다. 자동화 투자가 없었다. 보고서에 쓴다. "품질 개선을 위해 자동화 투자 필요" 그리고 지운다. 경영진은 숫자를 원한다. "얼마나 걸려? 효과는?" 대답 못 하면 승인 안 난다. 다시 쓴다. "현재 일정 내 최선의 결과. 지속 모니터링 중" 우선순위를 정한다는 건 하고 싶은 말을 참는다는 뜻이다. 회의 들어갔다. 30분. 임원이 물었다. "장애율이 왜 올랐죠?" "일정이 촉박해서 테스트 범위를 조정했습니다." "그럼 일정을 지키는 게 우선순위였단 거네요?" 그렇다. 맞다. 하지만 그렇게 말하면 무능해 보인다. "리스크 기반으로 우선순위를 정했습니다. 치명적 장애는 없었습니다." 임원이 고개를 끄덕였다. 회의 끝났다. 복도 걸어 나온다. 숨이 답답하다. 품질이 우선이다. 맞다. 하지만 일정도 우선이다. 비용도 우선이다. 팀 사기도 우선이다. 전부 우선이면 뭐가 우선인가. 오후 6시, 네 번째 선택 배포 1시간 전이다. 개발팀에서 연락 왔다. "기능 하나 더 넣어도 될까요? 작은 거예요." 안 된다. 절대 안 된다. 배포 직전 변경은 재앙이다. 13년 경험이 말한다. 하지만 물었다. "얼마나 중요한 거예요?" "CEO가 오늘 데모 보고 싶대요." 그렇구나. 다시 계산한다. 리스크: 높음. 일정: 불가능. 정치: 중요. "30분 줄 테니 빠르게 확인만 할게요. 풀 테스트는 못 해요." 전화 끊었다. 팀원한테 말했다. "미안한데 급한 거 하나만..." 팀원이 웃었다. 쓴웃음. "괜찮아요. 늘 그렇잖아요." 늘 그렇다. 우선순위를 정한다는 건 원칙을 꺾는다는 뜻이다.밤 9시, 다섯 번째 선택 배포 끝났다. 장애 없었다. 다행이다. 정말 다행이다. 팀원들한테 메시지 보냈다. "수고했어요. 내일 점심 제가 살게요." 답장 온다. 고맙다고. 미안하다는 말은 안 한다. 너무 많이 해서. 집에 가는 길. 지하철에서 리스트를 본다. 오늘 아침에 쓴 5개. 실제로 한 건 15개다. 계획한 건 2개뿐이다. 나머지는 전부 '급한 거'. 우선순위가 바뀐 거다. 10번. 그게 내 일이다. 우선순위를 정하는 게 아니다. 우선순위가 바뀌는 걸 관리하는 거다. 현관문 열었다. 딸이 달려온다. "엄마 늦었어!" 늦었다. 맞다. 남편이 저녁 차려놨다. "힘들었어?" 힘들었다. "내일은 일찍 와?" 모른다. 내일도 우선순위가 바뀔 거다. 항상 그랬다. 밤 11시, 마지막 생각 침대에 누웠다. 핸드폰 본다. 습관이다. 슬랙에 메시지 왔다. 내일 새벽 배포 추가래. 급하대. 한숨 나온다. 답장은 내일 하자. '우선순위'라는 말 생각한다. 13년 동안 몇 번이나 했을까. 하루 평균 10번이면... 계산하기 싫다. 이 말의 무게. 포기, 실망, 타협, 책임. 전부 여기 들어있다. QA 팀장의 일은 완벽한 품질을 만드는 게 아니다. 현실과 이상 사이에서 매일 우선순위를 정하는 거다. 뭘 지키고 뭘 포기할지. 누굴 실망시키고 누굴 설득할지. 어떤 리스크를 안고 어떤 리스크를 피할지. 정답은 없다. 그냥 선택만 있다. 내일도 선택할 거다. 모레도 선택할 거다. 핸드폰 내려놓는다. 눈 감는다. "우선순위가..." 잠들기 전 마지막 생각이다. 내 입버릇이 된 이 말. 무겁다.매일 우선순위를 정한다. 그게 내 일이다. 완벽은 없다. 선택만 있다. 내일도 똑같겠지.

팀원이 자동화 테스트를 짜지 않고 수동으로 진행했다

팀원이 자동화 테스트를 짜지 않고 수동으로 진행했다

또 수동으로 했다 월요일 아침이다. 스탠드업 미팅에서 민준이가 말했다. "금요일 배포된 기능, 수동 테스트 완료했습니다." 순간 머리가 아팠다. 저번 주에 말했다. 저번 달에도 말했다. "이거 반복되는 거니까 자동화 스크립트 짜두자." 민준이 대답은 똑같다. "네, 다음엔 꼭 하겠습니다." 다음은 안 온다. 항상 지금이다.회의 끝나고 민준이 붙잡았다. "왜 또 수동으로 했어?" 민준이가 말한다. "자동화 짜는 게 2시간 걸리는데, 수동으로 하면 30분이면 돼요." 맞는 말이다. 지금 당장은. 그런데 이 테스트, 매주 한다. 한 달이면 4번. 1년이면 48번. 30분 × 48번 = 24시간. 자동화 2시간 투자하면 22시간 세이브다. 이 계산을 설명했다. 민준이가 고개를 끄덕인다. "아, 그렇네요." 그런데 다음 주에 또 수동으로 한다. 설득이 일이 됐다 점심 먹으면서 팀원들한테 또 말했다. "자동화 가능한 건 자동화하자. 우리가 수동 테스트만 하려고 QA 한 거 아니잖아." 다들 고개를 끄덕인다. 이해는 한다. 실천을 안 할 뿐이다. 지현이가 말한다. "팀장님, 자동화 스크립트 짜면 나중에 유지보수도 해야 되잖아요." 맞다. 유지보수는 필요하다. 그런데 수동 테스트는 유지보수가 없나? 매번 똑같은 걸 클릭하는 게 유지보수 아닌가? "UI 바뀌면 스크립트 다 고쳐야 돼요." "그럼 테스트케이스 엑셀도 다 고쳐야 되잖아." "근데 엑셀은 빨리 고치잖아요." "스크립트도 잘 짜두면 빨라." 이런 대화를 3년째 하고 있다.팀장 된 지 3년. 처음엔 직접 자동화 스크립트 짰다. 팀원들한테 보여주면서 "이렇게 하는 거야" 했다. 효과는 있었다. 한 달 정도. 그 다음엔 다시 수동 테스트로 돌아간다. 왜일까. 고민했다. 결론은 간단했다. 당장 급한 일이 자동화보다 많다. 버그 터지면 수정 확인해야 되고. 기획 바뀌면 테스트 다시 짜야 되고. 개발팀에서 "이거 테스트 좀 급하게" 하면 달려가야 되고. 자동화는 중요한데 급하지 않다. 그래서 영원히 미뤄진다. 기술 부채가 쌓인다 우리 팀 자동화 커버리지 37%. 작년에 35%였다. 2% 올랐다고 자랑할 순 없다. 기능은 매달 늘어나는데 자동화는 제자리걸음이다. 계산해봤다. 지금 수동으로 돌리는 테스트 케이스 650개. 한 케이스당 평균 3분. 650 × 3분 = 1950분 = 32.5시간. 배포 전에 풀 테스트 돌리면 팀원 8명이 하루 종일 달라붙는다. 그래서 요즘엔 풀 테스트 안 한다. 리스크 높은 것만 골라서 한다. 리스크 낮다고 판단한 곳에서 버그가 나온다. 그럼 또 내 책임이다. 경영진한테 보고할 때마다 물어본다. "자동화율이 왜 이렇게 낮죠?" 설명한다. "인력 대비 기능 증가 속도가 빨라서, 자동화 짤 시간이 없습니다." "그럼 자동화 전담 인력 뽑으시죠." "예산 승인 부탁드립니다." "지금은 어렵고요." 이 대화도 2년째다.개발팀은 기술 부채 쌓이면 리팩토링 스프린트 만든다. QA팀은 그런 거 없다. 테스트 자동화 부채는 눈에 안 보인다. 배포는 된다. 품질이 낮아질 뿐이다. 품질이 낮아지면 장애가 난다. 장애 나면 포스트모템 쓴다. "재발 방지 대책: 해당 케이스 테스트 자동화" 그 자동화, 누가 언제 하나. 또 급한 일 밀려온다. 악순환이다. 다른 회사는 어떨까 QA 리드 모임에서 만난 선배가 말했다. "우리 회사는 자동화 안 하면 코드 리뷰에서 반려해." 부럽다. 그 회사는 자동화가 문화다. 우리 회사는? 자동화는 "하면 좋은 것". 필수가 아니라 옵션이다. 옵션은 항상 스킵된다. 다른 선배는 말했다. "자동화 전담팀 만들었어. 3명." 더 부럽다. 우리 팀은 8명 전부 기능 테스트에 매달린다. "그 전담팀이 자동화 프레임워크 다 구축해놨어. 다른 팀원들은 거기다 케이스만 추가하면 돼." 완벽한 구조다. 우리 팀은 프레임워크도 제각각이다. Selenium 쓰는 사람, Playwright 쓰는 사람, Cypress 쓰는 사람. 통일하자고 했는데 각자 익숙한 게 다르다. "그냥 편한 거 쓰세요." 이렇게 말한 내가 문제다. 내가 할 수 있는 건 고민했다. 팀원들 탓할 수는 없다. 바쁜 건 사실이니까. 그럼 뭘 바꿔야 하나.자동화 시간을 업무 시간에 명시적으로 넣기.매주 금요일 오후는 자동화 작업 시간. 다른 일 시키지 않기.자동화 성과를 평가에 반영.수동 테스트만 하면 보통. 자동화 구축하면 좋음.작은 것부터 시작.30분짜리 테스트부터 자동화. 성공 경험 쌓기.템플릿 만들기.자동화 스크립트 시작 템플릿. 복붙해서 시작할 수 있게.이걸 이번 주 1on1 때 팀원들한테 말할 것이다. 그래도 답답하다 솔직히 말하면. 이런 걸 내가 챙겨야 한다는 게 피곤하다. 자동화는 기본이어야 한다. "자동화 하세요"가 아니라 "자동화 안 한 이유가 뭐죠?"가 되어야 한다. 그런데 현실은 반대다. 개발자들은 테스트 코드 안 짜면 리뷰 통과 안 된다. QA는 자동화 안 해도 아무도 안 물어본다. 이게 QA의 현실이다. 13년 했는데 이건 안 바뀐다. 개선은 되는데 본질은 그대로다. 자동화는 여전히 옵션이고. 품질은 여전히 QA만의 책임이고. 기술 부채는 여전히 눈에 안 보인다. 퇴근길에 생각했다. 내년에도 똑같은 고민 할 것 같다. 그래도 해야 한다. 안 하면 더 심해지니까.수동 테스트는 빠르지만, 반복되면 가장 느리다.

금요일 오후 4시, 배포 리스트를 받았다

금요일 오후 4시, 배포 리스트를 받았다

금요일 오후 4시 슬랙이 울렸다. 개발팀 리드가 배포 리스트를 공유했다. 12개 항목. 금요일 오후 4시에. "이번 주 금요일 밤 11시 배포 예정입니다. QA 확인 부탁드립니다." 커피잔을 내려놨다. 손에 힘이 들어갔다. 금요일 배포. 13년 동안 제일 싫어하는 단어다.배포 리스트 뜯어보기 일단 항목을 확인했다. 12개 중 8개는 이미 테스트 완료. 문제없다. 남은 4개가 문제다.결제 모듈 성능 개선 (High) 회원가입 프로세스 변경 (Medium) 관리자 대시보드 UI 수정 (Low) API 타임아웃 설정 변경 (Critical)API 타임아웃이 Critical이다. 이게 잘못되면 전체 서비스가 멈춘다. 개발팀 리드한테 슬랙을 보냈다. "API 타임아웃 테스트 완료됐나요? 부하 테스트 결과 공유 부탁드립니다." 답장이 왔다. "로컬에서는 확인했습니다. 스테이징 배포는 내일 오전 예정이었는데..." 내일 오전. 배포는 오늘 밤 11시. 숨을 깊게 들이쉬었다. 토요일에 장애 터지는 게 보였다. 긴급 회의 소집 팀원들한테 슬랙을 날렸다. "4시 30분 회의실. 금요일 배포 건." 5명이 모였다. 나머지는 재택이라 화상으로. 화이트보드에 4개 항목을 적었다. 우선순위를 다시 매겼다. "결제 모듈이랑 회원가입은 테스트 완료. 문제없어. 관리자 UI는 리스크 낮아. 패스." 마커로 API 타임아웃에 동그라미를 그렸다. "이게 문제야. Critical인데 스테이징 테스트도 안 했어." 막내가 물었다. "그럼 이거 빼고 배포하면 안 돼요?" 고개를 저었다. "이미 프로덕션에 타임아웃 이슈 있어. 고객 컴플레인 들어왔고. 월요일까지 못 기다려." 시니어가 말했다. "지금 스테이징에 올려서 테스트하죠. 6시간 있으면 충분해요." 시계를 봤다. 4시 40분. 배포까지 6시간 20분. "좋아. 개발팀한테 지금 바로 스테이징 배포 요청해. 우리는 시나리오 준비."리스크 평가표 작성 회의가 끝나고 자리로 돌아왔다. 엑셀을 켰다. 리스크 평가표를 만들기 시작했다. 항목별로 리스크 레벨을 매겼다. 영향도, 발생 가능성, 복구 시간. API 타임아웃: 영향도 9/10, 발생 가능성 6/10, 복구 시간 2시간. 결제 모듈: 영향도 10/10, 발생 가능성 2/10, 복구 시간 4시간. 회원가입: 영향도 7/10, 발생 가능성 3/10, 복구 시간 1시간. 관리자 UI: 영향도 3/10, 발생 가능성 1/10, 복구 시간 30분. 표를 보니까 명확했다. API 타임아웃이 최대 리스크다. CTO한테 메일을 썼다. 제목은 "금요일 배포 리스크 분석". 본문에 표를 붙였다. 마지막에 한 문단 추가했다. "API 타임아웃 항목의 경우, 스테이징 테스트 미완료 상태입니다. 금요일 밤 배포 시 주말 장애 리스크가 높습니다. 권장사항은 해당 항목만 월요일로 연기하는 것입니다." 전송 버튼을 눌렀다. 5분 후에 답장이 왔다. "고객 컴플레인이 심각합니다. 월요일까지 기다릴 수 없어요. 스테이징 테스트 완료 후 배포 진행하세요." 노트북 화면을 내려다봤다. 결국 내 책임이다. 스테이징 배포 테스트 6시. 개발팀이 스테이징에 배포했다. 팀원들이랑 테스트 시나리오를 나눴다. 각자 30분씩 돌리기로 했다. 내가 맡은 건 API 타임아웃 시나리오. 부하를 걸어봐야 한다. Postman으로 API를 반복 호출했다. 100회, 500회, 1000회. 응답 시간을 체크했다. 평균 200ms. 최대 350ms. 타임아웃은 500ms로 설정돼 있다. 여유가 있어 보였다. 근데 프로덕션은 트래픽이 다르다. 개발자한테 물었다. "프로덕션 평균 TPS가 얼마죠?" "보통 1500 정도요. 피크 타임엔 3000까지 올라가요."스테이징에서 그만큼 부하를 못 준다."부하 테스트 툴 돌릴 수 있어요?" "JMeter 세팅하면 30분 걸려요." 시계를 봤다. 6시 40분. 배포까지 4시간 20분. "지금 바로 시작하세요."7시 30분, 테스트 결과 JMeter 테스트가 끝났다. TPS 3000으로 5분간 돌렸다. 결과를 봤다. 에러율 0.3%. 타임아웃 에러 9건. 많지 않다. 근데 0은 아니다. 개발자가 로그를 확인했다. "DB 커넥션 풀 부족인 것 같은데요. 설정값 올리면 될 것 같습니다." "지금 고칠 수 있어요?" "10분이면 됩니다." "바로 해주세요." 10분 후에 다시 테스트를 돌렸다. 이번엔 에러 없이 통과했다. 팀원들한테 물었다. "다른 항목 테스트 어때?" "결제 모듈 이상 없습니다." "회원가입도 문제없어요." "관리자 UI 확인했습니다. 괜찮습니다." 고개를 끄덕였다. 체크리스트를 하나씩 체크했다. 8시. 배포까지 3시간. 저녁을 먹을 시간이다. "다들 밥 먹고 와. 10시에 다시 모이자." 배포 직전 체크 10시 30분. 회의실에 다시 모였다. 배포 체크리스트를 스크린에 띄웠다. 30개 항목. 하나씩 확인했다.테스트 완료: ✓ 리스크 평가 완료: ✓ 롤백 플랜 준비: ✓ 모니터링 대시보드 확인: ✓ 장애 대응 가이드 공유: ✓ 비상 연락망 업데이트: ✓개발팀 리드가 물었다. "QA 승인 가능한가요?" 노트북을 내려다봤다. 손가락이 키보드 위에 있었다. API 타임아웃이 걸렸다. 스테이징에서 한 번 에러가 났었다. 근데 수정 후에는 통과했다. 프로덕션 트래픽이 다르긴 하지만. 월요일까지 기다리면 고객 컴플레인이 쌓인다. 기다려도 리스크는 같다. "승인합니다. 배포 진행하세요." 개발자가 고개를 끄덕이고 배포 스크립트를 실행했다. 11시 5분. 배포가 완료됐다. 모니터링 대시보드를 켰다. API 응답 시간, 에러율, TPS를 지켜봤다. 5분. 10분. 15분. 이상 없다. 팀원들이 하나둘 자리를 떴다. "고생하셨습니다." 나는 30분을 더 지켜봤다. 11시 50분까지. 여전히 이상 없었다. 노트북을 닫았다. 집에 가는 길에 남편한테 전화했다. "배포 끝났어. 지금 가." "고생했어. 내일 주말인데 괜찮아?" "모르겠어. 내일 봐야지." 토요일 아침 알람 없이 일어났다. 8시 30분. 습관이다. 침대에 누워서 폰을 켰다. 슬랙을 확인했다. 메시지 0건. 이상 없다는 뜻이다. 모니터링 대시보드 앱을 켰다. 어젯밤부터 지금까지 그래프를 봤다. API 응답 시간: 평균 180ms. 에러율: 0.001%. TPS: 새벽 3시에 피크 2800. 이상 없다. 숨을 내쉬었다. 긴장이 풀렸다. 남편이 커피를 들고 왔다. "괜찮아?" "응. 이상 없어." "다행이네. 오늘 뭐 해?" "일단 12시까지 지켜볼 거야." 남편이 웃었다. "알았어. 점심은 내가 할게." 12시까지 30분마다 대시보드를 확인했다. 계속 정상이었다. 12시 15분. 딸이랑 같이 점심을 먹었다. 남편이 만든 김치찌개. 딸이 물었다. "엄마 오늘 회사 안 가?" "응. 토요일이잖아." "그런데 왜 계속 폰 봐?" 말문이 막혔다. 습관이라고 해야 하나. "엄마 일이 그래. 주말에도 확인해야 돼." 딸이 고개를 끄덕였다. "나도 엄마처럼 회사 다닐 거야." "...그래. 근데 주말엔 쉬는 회사 다녀." 남편이 웃었다. 나도 쓴웃음이 나왔다. 일요일 오전 일요일 아침에도 폰을 먼저 확인했다. 슬랙 메시지 없다. 대시보드를 봤다. 토요일 저녁 피크 타임에도 이상 없었다. API 타임아웃 에러: 0건. 안도감이 왔다. 이제 진짜 괜찮은 것 같다. 오전에 가족이랑 공원에 갔다. 딸이 자전거를 탔다. 벤치에 앉아서 지켜봤다. 30분마다 폰을 확인했다. 습관이다. 남편이 말했다. "이제 그만 봐도 될 것 같은데." "응. 근데 월요일 아침까지는 봐야 해." "금요일 배포가 제일 힘들지?" 고개를 끄덕였다. "응. 주말 내내 불안해." "그럼 왜 금요일에 배포해?" "...고객이 기다리니까." 대답하고 나서 씁쓸했다. 고객도 중요하지만 내 주말도 중요한데. 13년 동안 금요일 배포를 몇 번이나 했을까. 50번? 100번? 매번 이렇게 주말을 보냈다. 폰을 확인하면서. 월요일 아침 월요일 아침 9시. 출근해서 제일 먼저 한 일은 주말 리포트 확인. 모니터링 팀이 보낸 메일을 열었다. "금요일 배포 후 48시간 모니터링 결과".API 평균 응답시간: 185ms 에러율: 0.001% 타임아웃 에러: 0건 사용자 컴플레인: 0건완벽했다. 문제없이 끝났다. CTO한테 메일을 썼다. 제목은 "금요일 배포 완료 리포트". 본문에 주말 모니터링 결과를 붙였다. 마지막에 한 문단 추가했다. "금요일 밤 배포가 성공적으로 완료되었습니다. 주말 동안 모니터링 결과 이상 없음을 확인했습니다. 다만 향후 Critical 항목의 경우 스테이징 테스트 기간을 충분히 확보할 것을 권장합니다." 전송 버튼을 눌렀다. 10분 후에 답장이 왔다. "고생하셨습니다. 팀 회식비 신청하세요." 회식비. 고맙긴 한데 주말 반납한 보상치고는 부족하다. 팀 회고 오후 3시. 팀 회고 미팅을 잡았다. 화이트보드에 세 가지를 적었다. "잘한 점, 아쉬운 점, 개선할 점". 팀원들이 포스트잇을 붙였다. 잘한 점:긴급 회의 빠른 소집 리스크 평가 정확했음 스테이징 테스트로 에러 사전 발견 모니터링 체계 잘 작동아쉬운 점:금요일 오후 4시에 배포 리스트 받음 API 타임아웃 스테이징 테스트 미완료 상태 부하 테스트 시간 부족 주말 내내 긴장 상태개선할 점:배포 리스트 목요일까지 확정 Critical 항목은 수요일까지 스테이징 테스트 완료 자동화 부하 테스트 환경 구축 금요일 배포 최소화 정책마지막 항목을 동그라미 쳤다. "금요일 배포 최소화 정책". "이거 개발팀이랑 협의해보자. 금요일은 Low 리스크만 배포하는 걸로." 시니어가 말했다. "좋은데 경영진 설득이 어려울 거예요." "알아. 근데 계속 제안은 해야지." 회고 내용을 컨플루언스에 정리했다. 다음 주 전사 회의에서 공유할 예정이다. 퇴근길 생각 7시에 퇴근했다. 엘리베이터에서 개발팀 리드를 만났다. "금요일 배포 고생 많으셨어요." "네. 다행히 이상 없었네요." "다음부턴 Critical 항목은 금요일 배포 피하는 게 어떨까요?" 개발팀 리드가 난처한 표정을 지었다. "그러고 싶은데 고객 요청이 급하면..." 말을 잘랐다. "고객 요청이 급해도 장애 나면 더 큰 문제잖아요." "...맞는 말씀이에요. 위에 건의해볼게요." 엘리베이터 문이 열렸다. 서로 인사하고 헤어졌다. 지하철을 타고 가면서 생각했다. 13년 동안 똑같은 말을 몇 번이나 했을까. "금요일 배포 피하자." 근데 여전히 금요일에 배포한다. 고객이 급하니까. 일정이 촉박하니까. 결국 QA 팀장이 주말에 폰을 붙들고 있는다. 창밖을 봤다. 월요일 저녁 7시. 사람들이 퇴근하고 있다. 나도 퇴근이다. 근데 금요일 오후 4시부터 지금까지 진짜 쉰 시간이 얼마나 될까. 핸드폰을 꺼냈다. 슬랙을 확인했다. 습관이다. 남편한테 메시지를 보냈다. "지금 퇴근. 저녁 뭐 먹지?" 답장이 왔다. "치킨 시켜놨어. 맥주도." 웃음이 나왔다. 좋은 사람이다. 그래도 다음 금요일 오후 4시에 또 배포 리스트를 받으면. 또 똑같이 할 것이다. 리스크 평가하고, 테스트하고, 주말에 폰 확인하고.금요일 배포는 끝나지 않는다. 주말도 같이.

테스트 케이스 작성 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 안 봤다.