Showing Posts From

버그

어? 이 버그 지난 달에도 나왔는데?

어? 이 버그 지난 달에도 나왔는데?

또 이 버그 아침 9시. 슬랙 알림이 울렸다. "결제 페이지에서 금액이 안 넘어와요." 손이 멈췄다. 이 문장, 어디서 봤다. 지난달 장애 리포트를 뒤졌다. 있었다. 똑같은 증상. 똑같은 모듈. 팀원에게 물었다. "이거 지난번에 고쳤잖아." "네, 근데 또 났어요." 커피를 마셨다. 벌써 두 번째다.포스트모템은 뭐하러 쓴 건지 지난달 장애 포스트모템을 열었다. 3페이지짜리 문서. 원인 분석, 근본 원인, 재발 방지책까지 다 있다. 재발 방지책 3가지:API 파라미터 검증 로직 강화 결제 모듈 통합 테스트 케이스 추가 배포 전 해당 시나리오 필수 체크1번은 했다. 2번은 반만 했다. 3번은 안 했다. 개발 리드에게 물었다. "체크리스트 왜 안 따른 거예요?" "일정이 빡빡해서요. 근데 이건 다른 이슈 아닐까요?" 로그를 봤다. 같은 이슈였다. 일정이 빡빡하면 품질은 뒤로 가는 게 이 조직의 공식이다. 재발 방지책이 지켜지지 않는 이유 점심 먹고 팀원들이랑 얘기했다. "또 똑같은 거 났어." "아... 그거요? 저번에 포스트모템 썼는데." "응. 근데 아무도 안 지킴." 이유는 간단하다. 첫째, 바빠서. 일정 지키는 게 최우선이니까. 둘째, 책임이 없어서. 재발 방지책 안 지켜도 징계 없음. 셋째, 추적이 안 돼서. 누가 체크해야 하는지 모호함. 넷째, 문화가 없어서. "이번만"이 모든 걸 정당화함. 팀원이 물었다. "팀장님, 이거 어떻게 해요?" "모르겠어. 나도." 솔직히 모르겠다. 13년 했는데 답이 없다.경영진한테 보고 오후 3시. CTO 리포트 미팅. "같은 이슈가 재발했습니다." "어떻게 된 거죠?" "재발 방지책이 제대로 이행되지 않았습니다." "왜요?" "일정 압박이 있었고, 체크리스트가 강제가 아니었습니다." 침묵이 흘렀다. 5초쯤. "그럼 이번엔 어떻게 할 건가요?" 또 물어본다. 어떻게 할 거냐고. "배포 전 필수 체크리스트를 강제화하겠습니다. 승인 프로세스를 추가하고, QA 팀장 사인 없으면 배포 못 하게 하겠습니다." "그럼 일정은요?" "지켜야죠. 품질이랑 일정 둘 다." 불가능한 걸 약속했다. CTO는 고개를 끄덕였다. "기대하겠습니다." 미팅이 끝났다. 나왔다. 화장실 갔다. 거울을 봤다. 피곤한 얼굴. "재발 방지책 강제화." 말은 쉽다. 현실은 어렵다. 강제화가 답일까 퇴근 전에 테스트 전략 회의를 잡았다. "이제부터 배포 전 체크리스트 필수입니다. QA 팀장 승인 없으면 배포 안 됩니다." 개발 리드가 물었다. "그럼 시간 더 걸리는데요?" "당연하죠. 품질 체크하려면." "일정은 어떻게 하고요?" "그건 PM이랑 조율해야죠." PM이 끼어들었다. "우리 일정 못 미루는 거 아시잖아요." 알지. 다 안다. 일정은 못 미루고, 품질은 지켜야 하고, 리소스는 그대로. 이게 내가 13년간 들은 말의 요약이다. "그럼 어떻게 해야 하는데요?" 개발 리드가 물었다. "자동화를 늘려야죠. 수동 테스트 줄이고, 회귀 테스트 자동화하고." "예산은요?" "신청했어요. 작년부터." 승인 안 났다. 올해도 아마 안 날 거다.시스템의 문제 퇴근길 지하철에서 생각했다. 재발 방지책이 안 지켜지는 건 개인의 문제가 아니다. 시스템의 문제다. 개발자가 게을러서? 아니다. 다들 밤늦게까지 일한다. PM이 무책임해서? 아니다. 일정 압박받는 건 그쪽도 마찬가지. QA가 제대로 안 해서? 우리는 했다. 다 했다. 문제는 구조다. 일정이 최우선이고, 품질은 부차적이고, 재발 방지는 선택 사항인 구조. 장애 터지면 난리 나지만, 터지기 전엔 아무도 신경 안 쓰는 구조. 포스트모템은 쓰지만 아무도 안 읽는 구조. "다음엔 조심하자"가 재발 방지책이 되는 구조. 이 구조를 바꾸려면 뭐가 필요한가. 경영진의 의지? CTO는 관심 없다. 숫자만 본다. 프로세스 강화? 이미 충분히 강하다. 안 지켜서 문제지. 문화 개선? 13년 해봤는데 문화는 안 바뀐다. 그래도 해야 하는 일 다음 날 아침. 출근했다. 재발 방지책 강제화 문서를 작성했다.배포 전 필수 체크리스트 30개 항목 각 항목별 담당자 지정 QA 팀장 최종 승인 프로세스 미이행 시 배포 중단 권한개발팀에 공유했다. 항의가 들어왔다. "이거 다 하려면 시간이 2배로 걸리는데요." "그럼 자동화하세요. 제가 도와드릴게요." "자동화 구축할 시간도 없는데요." "그럼 계속 똑같은 장애 터지겠네요." 말을 멈췄다. 더 할 말이 없었다. PM한테 따로 메시지를 보냈다. "이번 스프린트에 자동화 구축 일정 넣어주세요. 3주면 회귀 테스트 80% 커버 가능합니다." "다음 스프린트에 넣을게요." "이번 스프린트요." "기능 개발이 우선이잖아요." "품질도 기능입니다." 읽씹당했다. 팀원들과의 대화 점심시간에 팀원들이랑 밥 먹었다. 막내가 물었다. "팀장님, 재발 방지책 강제화하면 진짜 달라질까요?" "모르겠어. 근데 안 하는 것보단 낫지." "저는... 회의적이에요." "나도." 다들 웃었다. 쓴웃음. 10년차 팀원이 말했다. "저도 예전 회사에서 비슷한 거 해봤어요. 처음엔 다들 따르다가 한 달 지나면 형식적으로 바뀌더라고요." "알아. 근데 그래도 해야지." "왜요?" "안 하면 뭐라도 바뀌냐?" 대답이 없었다. 우리는 알고 있다. 이 방법도 완벽하지 않다는 걸. 하지만 안 하는 것보단 낫다. 매번 같은 장애 보고 가만히 있는 것보단. "어? 이 버그 지난 달에도 나왔는데?"라고 말하고 아무것도 안 하는 것보단. 조직 문화라는 벽 퇴근 전에 CTO한테 메일을 보냈다. 제목: 재발 장애 근본 원인 및 개선 방안 내용은 3페이지.최근 6개월간 재발 장애 통계: 전체 장애의 37% 재발 원인: 재발 방지책 미이행 82% 미이행 원인: 일정 압박 65%, 프로세스 부재 23%, 리소스 부족 12% 개선 방안: 배포 프로세스 강화, 자동화 투자, 품질 메트릭스 KPI 반영마지막 문장: "품질은 선택이 아닌 필수입니다. 재발 방지책 이행을 조직 KPI에 포함시켜주시기 바랍니다." 보내고 나니 허무했다. 이런 메일, 매 분기마다 보낸다. 13년 동안. 답장은 늘 비슷하다. "중요한 의견 감사합니다. 검토하겠습니다." 검토만 하고 끝이다. 왜 안 바뀔까. 품질보다 속도가 중요해서? 맞다. 장애 터져도 큰일 안 나니까? 맞다. QA가 알아서 막아주니까? 맞다. 조직 문화는 바뀌지 않는다. 위에서 바꾸지 않으면. 그래도 기록은 남긴다 밤 10시. 집에 왔다. 노트북을 켰다. 개인 기록을 작성했다. "2024년 X월 X일. 결제 모듈 재발 장애. 지난달과 동일. 재발 방지책 미이행." 이런 기록이 쌓인 지 3년. 왜 쓰냐고? 모른다. 누가 볼 것도 아닌데. 나조차 다시 안 읽는데. 그래도 쓴다. 언젠가 누군가 물어볼 때 보여주려고. "왜 품질이 안 좋아졌나요?" 그때 이 기록을 보여줄 거다. "재발 방지책을 안 지켰습니다. 계속. 반복적으로." 증거는 남겨야 한다. 안 그러면 나중에 QA 탓이 된다. "QA가 제대로 테스트 안 해서 장애 났다." 아니다. 우리는 했다. 다 했다. 기록이 증명한다. 13년 차의 회의감 솔직히 말하면 회의적이다. 재발 방지책 강제화해도 달라질까? 모르겠다. 프로세스 만들어도 안 지키면 끝이다. 자동화 구축해도 예산 안 나오면 끝이다. 조직 문화 바꾸자고 해도 위에서 관심 없으면 끝이다. QA 13년 했다. 나아진 것도 있다. 툴은 좋아졌다. Jira, TestRail, CI/CD. 방법론도 발전했다. 애자일, DevOps, 시프트 레프트. 하지만 본질은 안 바뀌었다. "일정이 급해서", "이번만", "다음엔 제대로 하자". 이 말들은 13년 전이나 지금이나 똑같다. 그래도 해야 한다. 이게 내 일이니까. 팀원들이 보고 있으니까. "팀장님도 포기하면 우리는 뭐 하나요?" 포기하면 안 된다. 아직은. 내일도 내일 아침 9시에 긴급 회의가 잡혔다. 안건: 재발 장애 대응 방안 논의. 또 같은 얘기 할 거다. "원인이 뭡니까?" "왜 또 났습니까?" "어떻게 할 겁니까?" 나는 같은 대답을 할 거다. "재발 방지책이 지켜지지 않았습니다." "이번엔 강제화하겠습니다." "프로세스를 개선하겠습니다." 그리고 한 달 뒤, 또 같은 장애가 날 거다. 또 같은 회의를 하겠지. 이게 내 일이다. QA 팀장. 재발 장애를 막는 사람이 아니라, 재발 장애를 기록하는 사람. 변화를 만드는 사람이 아니라, 변화를 요청하는 사람. 씁쓸하다. 하지만 내일도 출근한다. 커피 마시고, 슬랙 확인하고, 또 싸울 거다. "어? 이 버그 지난 달에도 나왔는데?" 이 말을 더 이상 안 하는 날이 올까. 모르겠다. 13년 했는데도.재발 장애는 품질 문제가 아니라 조직 문화 문제다. 근데 문화는 안 바뀐다.

TestRail에 기록된 버그, 결국 배포되었다

TestRail에 기록된 버그, 결국 배포되었다

빨간 딱지, 초록 사인 TestRail 열었다. 빨간 딱지 17개. 심각도 High 3개, Medium 14개. Low는 세지도 않았다. 배포일은 금요일. 오늘이 수요일. 개발팀 리드가 슬랙 보냈다. "팀장님, 내일 QA 사인 가능할까요?" 17개를 이틀 안에. 불가능하다. 물리적으로.회의실, 오후 4시 경영진 보고 회의. 개발 리드, 기획 리드, PM, 나. PM이 말했다. "이번 릴리즈는 꼭 나가야 합니다." "IR 자료에 들어갑니다." 기획 리드가 거들었다. "사용자 임팩트는 크지 않아요, 아마도." 아마도. 나는 테스트 결과 공유했다. "결제 플로우에서 간헐적 오류." "재현율 30%. 특정 환경에서만." "로그 분석 결과 DB 커넥션 이슈." 개발 리드가 답했다. "모니터링 강화하겠습니다." "장애 터지면 핫픽스 바로 올리겠습니다." PM이 물었다. "배포 가능한가요?" 모두가 나를 봤다.내가 할 수 있는 말 "리스크는 전달했습니다." "결제 성공률 2-3% 떨어질 수 있습니다." "주말 모니터링 필요합니다." PM이 고개 끄덕였다. "그 정도면 괜찮겠네요." 그 정도. 주문 100건 중 2-3건. 하루 1000건이면 20-30건. 괜찮다고 했다. 나는 더 말하지 않았다. "배포 승인하겠습니다." "단, 조건부입니다." 조건.모니터링 대시보드 실시간 확인 에러율 5% 넘으면 즉시 롤백 핫픽스 준비 완료 상태 유지PM이 웃었다. "물론이죠. 당연하죠." 회의 끝났다. 40분 걸렸다. 내 13년이 40분에 정리됐다.Jira 티켓, 업데이트 회의실 나와서 자리 앉았다. TestRail 열고 버그 상태 업데이트. Status: Known Issue Resolution: Will Not Fix (This Release) Deployment Risk: Acknowledged Comment 달았다. "배포 승인. 조건: 실시간 모니터링, 롤백 준비." "장애 발생 시 우선순위 1로 핫픽스." 팀원들한테 슬랙 보냈다. "금요일 배포 진행합니다." "알려진 이슈 있으니 주말 모니터링 부탁드립니다." 막내가 답했다. "팀장님, 저 결제 버그요?" "응. 그거." "괜찮을까요?" 나도 모른다. "모니터링 잘하자." 집에 가는 길 지하철에서 폰 봤다. QA 커뮤니티에 누가 글 올렸다. "버그 알면서 배포하는 거, 어떻게 생각하세요?" 댓글 20개 달렸다. "현실이죠." "리스크 전달했으면 된 거 아닌가요?" "저도 자주 겪어요. 익숙해지네요." 익숙해진다. 13년 하면 익숙해진다. 그게 문제다. 남편한테 얘기했다. "오늘 버그 있는데 배포 승인했어." "심한 버그야?" "결제. 30% 확률로 실패." "롤백 준비는 돼 있어?" "응." "그럼 됐네. 뭐." 됐다고 했다. 금요일, 배포 오전 11시 배포 시작. Blue-Green 배포. 30분 걸렸다. 모니터링 대시보드 열었다. Datadog, Sentry, 결제 성공률 그래프. 처음 1시간. 정상. 2시간. 정상. 점심시간 지나고. 정상. 오후 3시쯤 슬랙 알림 왔다. 개발팀에서. "결제 에러 스파이크 확인됩니다." 내가 예상한 그 버그. TestRail에 기록된 그 버그. 에러율 8%. 롤백 기준인 5% 넘었다. PM한테 전화했다. "롤백 진행하겠습니다." "잠깐만요, 좀 더 지켜봐요." "조건이 5%였습니다." "고객 문의는 안 들어오는데요?" "에러율이 8%입니다." "월요일까지 버티면 핫픽스 올릴 수 있어요." 버틴다. 월요일까지. 나는 말했다. "저는 롤백 의견입니다." "최종 결정은 PM이 하세요." PM이 선택했다. "일단 모니터링 강화하겠습니다." 전화 끊었다. 주말, 모니터링 토요일 아침 일어나서 폰 확인. 슬랙 알림 12개. 에러율 10%. 고객센터 문의 3건. "결제가 안 돼요." 일요일 오후. 에러율 15%. 고객센터 문의 18건. PM한테 메시지 보냈다. "월요일 오전 핫픽스 올리시죠?" "네, 준비 중입니다." 준비 중. 월요일 오전 10시. 핫픽스 배포됐다. 에러율 정상으로 돌아왔다. 고객센터 문의는 총 47건 들어왔다. PM이 슬랙에 올렸다. "빠른 대응 감사합니다. 고생하셨습니다." 빠른 대응. 포스트모템 화요일, 장애 분석 회의. RCA 작성했다. Root Cause: DB 커넥션 풀 설정 오류. Detection: QA 테스트 단계에서 발견. Decision: 일정상 배포 진행, 모니터링 강화로 대응. Impact: 주문 실패 건수 약 150건, 고객 문의 47건. Action Items:DB 커넥션 설정 가이드 문서화 배포 전 체크리스트 강화 알려진 이슈 배포 시 의사결정 프로세스 정립마지막 항목. 내가 넣었다. PM이 물었다. "이 프로세스 누가 정리하죠?" 다들 나를 봤다. "제가 하겠습니다." 회의 끝나고. 혼자 남았다. 프로세스 정립. 13년 동안 몇 번을 정립했나. 다음에도 똑같을 거다. TestRail, 버그 클로즈 화요일 저녁. TestRail 열어서 그 버그 찾았다. Status: Closed Resolution: Fixed in Hotfix Actual Impact: 150 failed orders Comment 달았다. "QA 단계에서 발견. 배포 후 장애 발생. 핫픽스로 해결." "예상한 리스크 그대로 발현됨." 마지막 줄은 지웠다. "예상한 리스크 그대로 발현됨." 의미 없다. Status만 Closed로 바꿨다. 팀원과의 대화 수요일 오후, 막내랑 1on1. "팀장님, 질문 있어요." "응." "저번 결제 버그요." "테스트에서 찾았는데 왜 배포한 거예요?" 어떻게 설명하지. "일정이 급했어." "그럼 버그 찾아도 소용없는 거 아니에요?" 소용없다. 그렇게 느껴질 수 있다. "소용없진 않아." "우리가 찾아서 기록했잖아." "그래서 장애 났을 때 빨리 대응했고." 막내가 말했다. "그럼 결국 장애는 나는 거잖아요." 맞다. "QA는 버그를 막는 게 아니야." "리스크를 알리는 거지." "최종 결정은 비즈니스가 하는 거고." 막내는 고개 끄덕였다. 납득한 얼굴은 아니었다. 나도 5년차 때 그랬다. 지금도 가끔 그렇다. 또 다른 버그, 또 다른 배포 목요일 오후. 다음 스프린트 계획 회의. PM이 말했다. "이번 릴리즈도 타이트합니다." "2주 안에 나가야 해요." 기획 리드가 말했다. "피처가 5개인데 QA 일정이 며칠이죠?" "3일 잡혀 있습니다." "3일이면 충분하죠?" 충분하지 않다. 하지만 말했다. "최선을 다하겠습니다." 회의 끝나고 자리 돌아왔다. TestRail 새 테스트 케이스 만들기 시작했다. 팀원들한테 슬랙 보냈다. "다음 주 릴리즈 일정 공유합니다." "테스트 기간 3일입니다." "우선순위 기반으로 진행하겠습니다." 시니어 팀원이 답했다. "3일이요? 빡세겠네요." "응. 빡세다." 퇴근길, 혼잣말 지하철 타고 집 가는 길. 창밖 보면서 생각했다. TestRail에 기록된 버그들. Closed, Known Issue, Won't Fix. 내가 찾은 버그들. 결국 배포되는 버그들. 13년 했다. 익숙해졌다. 하지만 익숙해지면 안 되는 것 같다. 집 도착해서 남편한테 말했다. "나 이 일 언제까지 할 수 있을까." "왜? 이직하게?" "아니, 그냥." "그냥?" "그냥 궁금해서." 남편이 웃었다. "너 스타일에 평생 하겠네." 평생. 씨어터 들어가서 샤워했다. 물 맞으면서 생각했다. 내일도 출근한다. TestRail 열 거다. 버그 기록할 거다. 어떤 건 고쳐지고. 어떤 건 배포될 거다. 그게 내 일이다. 다음 주, 또 월요일 아침. 출근해서 컴퓨터 켰다. 슬랙 알림 5개. 주말에 온 메시지들. TestRail 열었다. 새 버그 3개 추가돼 있다. 커피 마셨다. 세 번째다. 테스트 시작했다.버그는 기록된다. 그리고 어떤 건 배포된다. 나는 서명한다. 그게 팀장이다.