Showing Posts From

품질

배포 1시간 전, 갑자기 '테스트 범위 줄여주세요'

배포 1시간 전, 갑자기 '테스트 범위 줄여주세요'

배포 1시간 전, 갑자기 '테스트 범위 줄여주세요' 오후 4시, 슬랙 메시지 배포는 6시다. 2시간 남았다. 리그레션 테스트 중이다. 핵심 플로우 80% 완료. 슬랙 알림 떴다. 개발팀장: "민수님, 5시까지 테스트 마무리 가능하세요? 배포 1시간 앞당겨야 할 것 같아요." 손이 멈췄다. 화면을 쳐다봤다. 테스트 케이스 234개. 완료 187개. 남은 거 47개. 계산했다. 1시간. 불가능하다. "범위 줄여야 할까요?" 내가 먼저 물었다. 항상 이렇다. "핵심만 보고 넘어가죠." 대답은 빠르다. 준비된 답처럼. 키보드 앞에 앉아있다. 어떤 걸 빼야 하지.4년차의 판단 테스트 범위를 줄인다. 말은 쉽다. 실제론 어렵다. 체크리스트 열었다. 빨간색으로 핵심 플로우 표시되어 있다. 로그인, 결제, 주문. 이건 무조건이다. 노란색은 중요. 프로필 수정, 장바구니, 검색. 파란색은 부가 기능. 공유하기, 즐겨찾기, 알림 설정. 파란색부터 지운다. 47개가 32개로 줄었다. 아직도 많다. 노란색을 본다. 프로필 수정은 이번 배포에 안 건드렸다. 패스. 장바구니는... 결제랑 연결된다. 건드리면 위험하다. 남긴다. 검색은 UI만 바뀌었다. 로직은 그대로. 간단히만. 32개가 21개로. 1시간이면 가능하다. 빡빡하지만. 엑셀에 정리한다. "테스트 제외 항목" 시트 만들었다. 제외 사유 적었다. "이번 배포 미반영", "회귀 위험도 낮음", "시간 제약". 문서화한다. 항상. 나중에 버그 나면 내 방어막이다.머릿속 시뮬레이션 테스트 시작 전에 생각한다. 만약 이거 안 하고 배포하면? 검색 기능. UI만 바뀌었다. 근데 검색 결과 정렬 로직은? 혹시 건드렸나? 지라 티켓 다시 확인했다. "UI 개선"만 적혀있다. 코드 변경 범위는 안 적혀있다. 개발자한테 물었다. "지훈씨, 검색 UI 수정할 때 정렬 로직도 건드렸어요?" "아뇨, CSS만 바꿨어요." "확실해요?" "네." 믿는다. 근데 테스트는 한다. 검색 한 번, 정렬 한 번, 필터 한 번. 3분이면 된다. 즐겨찾기는 뺀다. 이번 배포랑 상관없다. 2주 전부터 안 건드렸다. 근데 찜찜하다. 항상 이렇다. 머릿속으로 시나리오 그린다. 유저가 즐겨찾기 눌렀다. 안 된다. 컴플레인 들어온다. "QA는 뭐 했어요?" "이번 배포랑 무관한 부분이라..." "그래도 테스트는 했어야죠." 변명처럼 들린다. 항상. 그래도 뺀다. 시간이 없다. 리스크 관리다. 완벽한 QA는 없다.4시 30분, 실전 타이머 켰다. 1시간 30분. 집중한다. 로그인. 일반 로그인, 소셜 로그인, 자동 로그인. 통과. 회원가입. 이메일 중복, 약관 동의, 인증번호. 통과. 결제. 카드, 간편결제, 쿠폰 적용. 여기서 5분 더 걸렸다. 쿠폰 할인율이 이상하다. 슬랙 보냈다. "지훈씨, 쿠폰 10% 할인인데 9%만 적용돼요." "아 그거 반올림 이슈요. 수정할게요." 기다린다. 10분. 빌드 다시 받았다. 재테스트. 통과. 시계 봤다. 5시 20분. 남은 테스트 6개. 가능하다. 주문 내역. 취소, 환불, 배송 조회. 빠르게. 푸시 알림. 받음, 안 받음, 클릭 시 이동. 확인. 장바구니. 추가, 삭제, 수량 변경. 마지막. 5시 48분. 끝났다. 슬랙에 보고했다. "핵심 플로우 테스트 완료했습니다. 이슈 1건 수정 완료 확인. 배포 가능합니다." 개발팀장: "고생하셨습니다." 짧다. 항상 짧다. 배포 후, 6시 30분 배포 완료 메시지 떴다. 모니터링 시작한다. 센트리 확인. 에러 없다. 앱 리뷰 확인. 아직 조용하다. 슬랙 공지방 확인. 이상 없다. 긴장 풀렸다. 조금. 근데 찝찝하다. 테스트 안 한 26개 기능. 머릿속에 남아있다. 즐겨찾기, 공유하기, 프로필 수정... 만약 여기서 버그 나면? 확률적으론 낮다. 이번 배포에 안 건드렸으니까. 근데 완벽하게 안전한 건 아니다. QA는 항상 이렇다. 100% 확신은 없다. 확률 게임이다. 저녁 먹으면서 생각했다. '테스트 범위를 줄인다'는 건 '리스크를 떠안는다'는 거다. 내가 판단한다. 내가 책임진다. 무섭다. 가끔. 품질 vs 속도 4년 동안 배웠다. 완벽한 테스트는 불가능하다. 시간은 한정되어 있다. 리소스도 한정되어 있다. 버그는 무한하다. 선택해야 한다. 무엇을 테스트할 것인가. 무엇을 포기할 것인가. 회사는 속도를 원한다. 빨리 배포하고, 빨리 피드백받고, 빨리 수정한다. 애자일이라고 한다. 그럴듯하다. 나는 품질을 원한다. 버그 없는 앱, 매끄러운 경험, 안정적인 서비스. 이상적이다. 현실은 아니다. 타협한다. 매번. 중요한 건 기준이다. 어떤 기준으로 범위를 줄일 것인가. 내 기준은 이렇다.이번 배포 변경 범위 유저 영향도 과거 버그 히스토리 회귀 위험도이 네 가지로 판단한다. 결제는 무조건이다. 유저 영향도 최상. UI 변경은 가볍게. 로직 변경은 무겁게. 과거에 버그 많았던 기능은 꼼꼼히. 연관 기능 많으면 회귀 테스트 필수. 문서화한다. 항상. 판단 근거를 남긴다. 나중에 내 방어막이다. 개발자와의 대화 테스트 범위 줄일 때 제일 중요한 건 커뮤니케이션이다. 개발자한테 물어본다. "이번에 정확히 뭘 고쳤어요?" "연관된 부분은 없어요?" "어디까지 테스트하면 될까요?" 대답은 다양하다. 어떤 개발자는 친절하다. "여기 로직 바꿨고, 여기는 안 건드렸어요. 이 부분만 보면 돼요." 고맙다. 같이 일하기 좋다. 어떤 개발자는 애매하다. "음... 대충 다 봐주세요." 도움 안 된다. 내가 알아서 해야 한다. 어떤 개발자는 방어적이다. "제 로컬에선 문제없는데요." 알아. 근데 QA 환경에선 문제야. 신뢰 관계가 중요하다. 개발자를 믿어야 범위를 줄일 수 있다. "로직 안 건드렸어요" 말을 믿고 테스트를 패스한다. 근데 가끔 배신당한다. "안 건드렸다"는데 버그가 난다. 의도치 않은 사이드 이펙트. 그럴 땐 어쩔 수 없다. 다음부턴 더 꼼꼼히 본다. 4년 동안 배웠다. 말보다 코드 커밋 로그를 본다. "UI만 바꿨다"는데 로직 파일도 수정됐으면 의심한다. QA는 믿음과 의심 사이다. 배포 후 3일째 버그 없다. 다행이다. 테스트 안 한 26개 기능도 문제없다. 판단이 맞았다. 근데 항상 운이 좋은 건 아니다. 지난달 생각난다. 비슷한 상황이었다. 시간 없어서 범위 줄였다. 공유하기 기능 테스트 패스했다. 이번 배포 무관이라고 판단. 배포 3시간 후. 앱 리뷰 터졌다. "공유가 안 돼요." 확인했다. 새로 추가된 권한 체크 로직이 공유 기능을 막았다. 개발자도 몰랐다. 의도치 않은 버그. 팀장한테 불려갔다. "이번 테스트 범위에 공유 기능 없었나요?" "네, 이번 배포 변경 사항이 아니라서..." "그래도 기본 기능은 봐야죠." 할 말이 없었다. 핫픽스 나갔다. 야근했다. 집에 가면서 생각했다. 내 판단이 틀렸나? 시간이 부족했던 건가? 회사가 무리한 건가? 답은 없었다. QA는 이렇다. 버그 안 나오면 당연한 거고, 버그 나오면 QA 책임이다. 억울하다. 가끔. 내가 만든 체크리스트 실수 반복하고 싶지 않았다. 체크리스트 만들었다. "긴급 테스트 범위 축소 가이드" 절대 빼면 안 되는 것로그인/회원가입 결제 플로우 핵심 비즈니스 로직 법적/보안 관련 기능 이번 배포 직접 수정 항목조건부로 축소 가능UI만 변경된 기능 (로직 미변경 확인 필수) 부가 기능 (공유, 알림 등) AB 테스트 대상 (일부 유저만 노출)축소 시 문서화 필수 항목제외한 테스트 케이스 목록 제외 사유 잠재 리스크 배포 후 모니터링 계획이걸 팀 위키에 올렸다. 팀장이 좋다고 했다. "다음엔 이거 기준으로 합시다." 동료 QA가 물었다. "근데 이것도 지켜지지 않으면?" 웃었다. "그럼 또 야근하지 뭐." 현실은 그렇다. 가이드가 있어도 압박은 온다. "그냥 빨리 해주세요." 근데 있는 것과 없는 것은 다르다. 최소한 근거는 있다. 여자친구와의 대화 주말에 여자친구 만났다. 간호사라 바쁘다. 나도 바쁘다. 한 달에 두세 번 본다. 저녁 먹으면서 말했다. "요즘 일이 힘들어." "왜? 야근?" "그것도 있는데... 테스트 시간을 자꾸 줄이래." 그녀가 물었다. "그럼 뭐가 문제야?" "버그 놓칠 수 있잖아. 내 책임이 되고." "근데 시간 없으면 어쩔 수 없는 거 아니야?" "그래도..." 그녀가 웃었다. "나도 비슷해. 환자 많으면 한 명당 시간 줄어들어. 다 못 봐. 그래도 최선은 다해." "그게 되게 와닿네." "중요한 거 먼저 보고, 나머지는 다음에 보는 거지. 완벽은 없어." 간호사도 비슷하구나. 한정된 시간, 무한한 일. 우선순위 정하고, 트리아지하고, 최선을 다한다. 좀 위로됐다. "그래도 내가 놓친 버그로 유저가 피해 보면..." "너 혼자 책임 아니잖아. 팀이 있는 거고." 맞는 말이다. 근데 막상 당하면 혼자 책임지는 느낌이다. "다음에 그런 일 있으면 나한테 푸념해. 들어줄게." "고마워." 집에 오면서 생각했다. 완벽한 QA는 없다. 완벽한 간호사도 없다. 한정된 시간 안에서 최선을 다하는 것. 위로가 됐다. 조금. 4년차의 생존 전략 테스트 범위를 줄이는 건 기술이다. 경험이 쌓여야 한다. 신입 때는 몰랐다. 모든 걸 다 봐야 한다고 생각했다. 안 보면 불안했다. 2년차 때는 혼났다. 테스트 너무 오래 걸린다고. "핵심만 보세요." 3년차 때는 배웠다. 어떻게 줄이는지. 무엇을 봐야 하는지. 4년차인 지금은 안다. 완벽한 테스트는 환상이다. 리스크 관리가 현실이다. 내 생존 전략: 1. 문서화 모든 판단을 기록한다. 왜 이걸 제외했는지. 회의록, 지라 코멘트, 슬랙 메시지. 증거를 남긴다. 2. 커뮤니케이션 개발자한테 계속 물어본다. 정확히 뭘 고쳤는지. 어디까지 봐야 하는지. 애매하면 다시 물어본다. 3. 우선순위 기준 내 기준을 명확히 한다. 팀원들과 공유한다. 판단 근거를 설명할 수 있어야 한다. 4. 배포 후 모니터링 테스트 못 한 부분은 배포 후 바로 확인한다. 센트리, 앱 리뷰, 유저 문의. 빠르게 감지하고 대응한다. 5. 회고 배포 끝나면 복기한다. 놓친 게 있나, 개선할 점은 뭔가. 혼자 또는 팀과 함께. 이렇게 해도 완벽하지 않다. 그래도 최선이다. 밤 11시, 혼잣말 배포 끝나고 집에 왔다. 샤워하고 침대에 누웠다. 오늘도 살아남았다. 테스트 범위 줄이라는 말 들을 때마다 떨린다. 품질을 포기하는 것 같아서. 내 존재 이유가 흔들리는 것 같아서. 근데 이게 현실이다. 모든 걸 다 볼 수는 없다. 시간은 한정되어 있다. QA의 가치는 모든 걸 테스트하는 게 아니다. 중요한 걸 골라내는 거다. 리스크를 관리하는 거다. 4년 동안 배웠다. 완벽한 앱은 없다. 완벽한 QA도 없다. 그래도 나는 최선을 다한다. 주어진 시간 안에서. 내 판단을 믿고. 때로는 틀릴 수도 있다. 버그가 나갈 수도 있다. 그럼 배우고 개선한다. QA는 그런 일이다. 불확실성 속에서 판단하고, 책임지고, 다시 일어서는 것. 내일도 출근한다. 또 비슷한 일이 있을 것이다. "테스트 범위 줄여주세요." 괜찮다. 준비됐다. 핸드폰 꺼두고 잔다. 내일 또 싸운다."배포 1시간 전"은 QA의 일상이다. 완벽보단 최선을 택한다.

버그 심각도 S1, S2, S3, S4 - 우리는 왜 싸우나?

버그 심각도 S1, S2, S3, S4 - 우리는 왜 싸우나?

버그 심각도 S1, S2, S3, S4 - 우리는 왜 싸우나? 오전 10시, 또 시작됐다 회의실에 앉았다. 개발자 민호형, PM 수진누나, 나. 테이블 위에 노트북 세 대. 화면엔 Jira 티켓 #3847. "이거 S2 아니에요." 민호형이 먼저 쏘아붙였다. "로그인 안 되는 게 S2가 아니면 뭔데요?" 내가 받았다. "특정 기기에서만 그러잖아. 갤럭시 S20. 점유율 3%." 수진누나가 한숨 쉬었다. "일단 S3으로 타협하죠." 타협. 맨날 이거다. 버그 심각도. S1부터 S4까지. 겉으론 객관적 기준처럼 보인다. 실제론 협상 테이블이다.우리 회사 기준, 종이에만 있다 입사할 때 받았다. QA 가이드 문서. 40페이지짜리 PDF. 14페이지에 나온다. S1 - Critical서비스 전체 다운 결제 불가 데이터 손실S2 - Major주요 기능 장애 다수 사용자 영향 임시 우회 방법 없음S3 - Normal일부 기능 장애 우회 가능 사용자 불편S4 - MinorUI 오류 텍스트 오타 사용성 개선깔끔하다. 명확하다. 실전에선 쓸모없다. "로그인 안 되는 거 S2죠." "특정 기기잖아. S3." "그 기기 쓰는 사람도 사용자예요." "전체 0.8%래. 로그 확인했어." 가이드엔 없다. 점유율 얼마부터 "다수"인지. 우회 방법이 "로그아웃 후 재설치"면 진짜 우회인지. 결국 목소리 큰 사람이 이긴다. 아니면 직급 높은 사람.개발자의 논리, QA의 논리 민호형 입장은 이해한다. 버그 심각도 높으면 당장 고쳐야 한다. 다른 작업 밀린다. 일정 늦어진다. S1 붙으면 핫픽스 배포. 주말에도 나와야 한다. 그래서 S1은 정말 아껴 쓴다. 개발팀 내부에도 기준 있다. "서버 죽었어?" → S1 "앱 크래시?" → S2 "버튼 안 눌려?" → S3 "글자 깨짐?" → S4 QA 입장은 다르다. 사용자 관점이다. 갤럭시 S20 점유율 0.8%. 전체 사용자 50만 명이면 4천 명. 4천 명이 로그인 못 한다. "0.8%니까 S3요." "4천 명이요, 형." "통계적으론 소수지." "그 4천 명한테는 100%잖아요." 말싸움 시작.숫자 게임 작년 12월. 결제 버그 발견했다. "결제 완료" 떴는데 실제론 실패. 30분 뒤에 다시 결제하면 중복 결제. 나: "S1이요." 민호형: "발생 빈도 확인했어?" 나: "3건 리포트 들어왔어요." 민호형: "3건? 하루 거래 5만 건인데?" PM 수진누나가 계산기 두드렸다. "0.006%. S3 맞네요." 기가 막혔다. "돈 문제인데요?" "발생률 낮잖아." "한 번이라도 당하면 민원 폭탄인데." 결국 S2로 낙점. 2주 뒤 수정. 그 2주 동안 중복 결제 37건 더 발생. 고객센터 난리 났다. 환불 처리, 사과문, 쿠폰 보상. 회의 때 수진누나가 말했다. "이거 S1이었네요." 민호형은 아무 말 없었다. 숫자는 거짓말 안 한다. 해석이 거짓말한다. 직급과 심각도의 상관관계 신입 때는 몰랐다. 버그 심각도가 정치라는 걸. S1 버그 등록하면 회의 소집된다. CTO까지 올라간다. 누가 이 버그를 놓쳤나 추적 시작. 그래서 개발팀은 S1 싫어한다. QA팀도 부담스럽긴 하다. "이거 진짜 S1 맞아?" 팀장한테 물어본다. 작년 3월. 앱 크래시 발견. 재현율 100%. 특정 화면 진입 시. 나: "S1이죠?" 팀장: "사용자 얼마나 그 화면 가?" 나: "통계 봐야 알 것 같은데요." 팀장: "일단 S2로 올려. 확인 후 조정." S2로 등록했다. 다음 날 통계 나왔다. 일 방문자 200명. "S1으로 올릴까요?" "이미 S2로 올렸잖아. 그냥 두자." 2주 뒤 수정됐다. 그 2주간 400명이 크래시 경험했다. 리뷰에 별점 1점 달렸다. "앱 켜자마자 꺼져요. 쓰레기." 심각도는 기술적 판단이 아니다. 조직 내 협상력이다. 배포 2일 전의 법칙 배포 일정 잡힌다. D-7부터 분위기 바뀐다. D-7: "버그 있으면 다 올려." D-5: "S1, S2만 급해." D-3: "S1만 본다." D-2: "이거 진짜 S1 맞아?" D-1: "이거 S2 아니야?" D-day: "일단 배포하고 다음 버전에." 심각도가 시간에 따라 변한다. 같은 버그. 다른 평가. 지난달 있었다. D-5에 발견한 버그. 검색 필터 작동 안 함. 나: "S2요." 민호형: "이틀 안에 못 고쳐." PM: "우회 방법 있어?" 나: "필터 안 쓰고 스크롤." PM: "그럼 S3 아닌가?" 나: "검색이 주요 기능인데요." PM: "배포 밀리면 안 돼. 다음 버전." S3으로 강등. 다음 버전 때 다시 S2. 버그는 안 변했다. 일정이 심각도를 결정했다. 고객 민원이 진짜 심각도 앱스토어 별점 3.2. 예전엔 4.1이었다. 리뷰 읽으면 안다. 우리가 S3, S4 처리한 것들. 사용자한테는 S1이다. "뒤로가기 누르면 앱 꺼짐" → 우리는 S3 "매번 로그인 풀림" → 우리는 S4 "알림 안 옴" → 우리는 S2 리뷰는 가차없다. 별 하나. "못 쓰겠어요." 고객센터 통계 받았다. 지난 3개월 불만 접수 1위. "검색 필터 오류" 우리가 S3 처리한 거다. 사용자 4만 명이 민원 넣었다. 4만 명한테는 S1이었다. 회의 때 수진누나가 보여줬다. "이거 다음 버전에 꼭 고쳐야 해요." 민호형이 중얼거렸다. "진작 S1로 할 걸." 우리 기준과 사용자 기준. 언제나 다르다. 심각도 회의, 매주 1시간 QA팀이 제안했다. "심각도 판정 회의 만들자." 매주 목요일 2시. QA 2명, 개발 2명, PM 1명. 지난주 올라온 버그 리뷰. 처음엔 효과 있었다. 명확한 케이스들 정리됐다.결제 관련 → 무조건 S1 검토 로그인/회원가입 → S1 또는 S2 크래시 → 재현율에 따라 S1/S2 UI 오류 → S4, 단 주요 버튼은 S3하지만 애매한 건 여전했다. "푸시 알림 안 옴" 개발: "OS 권한 문제 아닌가?" QA: "앱 버그예요. 로그 있어요." 개발: "얼마나 발생해?" QA: "20건 리포트." 개발: "일 사용자 10만인데 0.02%." QA: "알림이 핵심 기능인데요." 한 시간 회의. 결론은 "다음 주 재논의". 다음 주엔 다른 버그로 또 싸운다. 객관 기준을 찾아서 팀장이 자료 가져왔다. 해외 회사들 사례. 구글 기준 (추정)P0: 사용자 5% 이상 영향, 또는 수익 차단 P1: 주요 기능 장애, 우회 없음 P2: 부분 기능 장애, 우회 있음 P3: 개선 사항아마존 기준 (추정)SEV1: 서비스 다운, 즉시 대응 SEV2: 주요 기능 실패, 24시간 내 SEV3: 불편 사항, 1주일 내 SEV4: 개선, 백로그핵심은 숫자다. "사용자 5% 이상" "24시간 내" 우리도 기준 만들기로 했다. S1 - Critical일 사용자 5% 이상 영향 (2500명) 결제/환불 오류 (금액 무관) 개인정보 유출 가능성 서비스 접속 불가 → 즉시 수정, 핫픽스 배포S2 - Major일 사용자 1% 이상 영향 (500명) 주요 기능 장애 (로그인, 검색, 주문) 우회 방법 어려움 앱 크래시 (재현율 30% 이상) → 3일 내 수정S3 - Normal일 사용자 1% 미만 영향 부분 기능 오류 우회 방법 있음 사용자 불편 → 다음 정기 배포S4 - MinorUI 깨짐, 오타 기능 동작하나 비효율 개선 제안 → 백로그 관리종이에 적었다. 회의실에 붙였다. 3개월 후, 여전히 싸운다 새 기준 적용 12주. 완벽하진 않다. 여전히 애매한 케이스 나온다. "이거 주요 기능 맞아?" "우회가 쉬운 거야 어려운 거야?" "1% 직전이면 어쩌고?" 하지만 달라졌다. 협상이 데이터 기반으로 바뀌었다. "이거 S2 아니에요?" "사용자 몇 명 영향받아?" "350명이요." "기준이 500명이니까 S3." "근데 로그인 관련인데." "주요 기능 조항 해당. S2 인정." 숫자로 말한다. 기분이 아니라. 버그 처리 속도도 빨라졌다. S1은 진짜 S1만 남았다. 개발팀도 집중한다. S3, S4는 우선순위 밀려도 이해한다. 명확한 기준 있으니까. 완벽한 기준은 없다. 하지만 없는 것보단 낫다. 결국 사람이 판단한다 기준 있어도 예외는 생긴다. 지난주 있었다. 특정 지역 사용자만 영향받는 버그. 서울/경기 OK. 부산/경남만 오류. 영향 사용자 230명. 0.4%. 기준상 S3. 하지만 올렸다. S2로. 이유는 간단했다. "부산 사용자한테는 100%잖아." 민호형이 동의했다. "맞아. 고치자." 기준은 출발점이다. 최종 판단은 사람이 한다. 중요한 건 근거다. "왜 이게 S2인가?" "부산 지역 사용자 전원 영향, 우회 불가" 설명 가능하면 된다. 서로 납득하면 된다. 심각도 협상의 미래 요즘 고민한다. AI가 심각도 판정하면 어떨까. 로그 데이터 던져주면 "영향 사용자 1237명, S2 권장" 이렇게 나온다. 공정할 것 같다. 싸움도 줄어들 것 같다. 하지만 찝찝하다. 버그는 숫자만이 아니다. 맥락이 있다. 타이밍이 있다. 배포 하루 전 S2 버그와 배포 2주 후 S2 버그. 같은 S2가 아니다. 결제 버그 3건 발생과 UI 버그 300건 발생. 어느 게 더 심각한가. 이건 사람이 판단해야 한다. 데이터 + 상황 + 경험. AI는 보조다. 결정은 우리가. 싸움보단 대화 QA 4년 하면서 배웠다. 개발자랑 싸워서 좋을 건 없다. 버그 심각도 논쟁. 결국 같은 목표다. 좋은 제품 만들기. 차이는 관점. 개발자: 일정, 리소스 QA: 사용자, 품질 둘 다 맞다. 둘 다 필요하다. 중요한 건 대화. "왜 이게 S2라고 생각해?" "사용자 경험 측면에서 치명적이라서." "알겠어. 그럼 우선순위 올려볼게." 명확한 기준 있으면 대화 쉽다. 감정 아니라 사실로 말한다. "너는 맨날 S1이래"가 아니라 "이건 기준상 S1 조건 충족해" 팀 분위기 달라진다. QA vs 개발이 아니라 우리 vs 버그.오늘 S1 버그 하나 올렸다. 민호형이 물었다. "근거 있어?" "결제 실패율 8%, 하루 400건 영향." "오케이. 당장 본다." 기준 있으니까 빠르다. 협상 아니라 합의. 이게 맞는 것 같다.

오전 9시 첫 번째 업무 - 어제 빌드 확인

오전 9시 첫 번째 업무 - 어제 빌드 확인

오전 9시 첫 번째 업무 - 어제 빌드 확인 출근 5분 후 사무실 도착. 8시 58분. 가방 내려놓고 컴퓨터 켠다. 부팅 기다리면서 커피 타러 간다. 인스턴트. 설탕 빼고. 돌아오니 로그인 화면. 비밀번호 치고 Slack 먼저 연다. 개발팀 채널 확인. 새벽 3시 메시지. "v2.4.1 빌드 업로드 완료했습니다." 심장이 조금 빠르다. 어제 크리티컬 버그 3개 픽스했다고 했는데. TestFlight 들어간다. 빌드 번호 확인. 231. 어제가 229였으니까. 다운로드 시작. 143MB. 3분 걸린다.기도하는 마음 빌드 다운로드 중에 어제 이슈 리스트 다시 본다. QA-2847: 결제 화면 크래시 (Critical) QA-2851: 로그인 토큰 만료 안 됨 (Major) QA-2853: 푸시 알림 중복 발송 (Major) 개발자 민호 형이 어제 저녁 7시에 "다 됐어요" 했다. 믿는다. 근데 100% 믿진 않는다. 4년 동안 배운 거. 개발자 말을 믿되, 반드시 확인한다. "제 PC에선 잘 되는데요?"를 몇 번이나 들었는지. 빌드 다운로드 완료. 앱 실행. 스플래시 화면. 로딩. 메인 화면 뜬다. 일단 켜지긴 한다. 좋은 시작. 5분의 룰 QA 4년 하면서 만든 나만의 규칙. 첫 빌드 확인은 5분 안에 끝낸다. 깊게 들어가지 않는다. 표면만 훑는다.앱 실행되나? 로그인 되나? 메인 기능 터치 반응 있나? 어제 고친 화면 열리나? 크래시 안 나나?이 5분이 하루를 결정한다. 빌드가 아예 망가졌으면 개발팀한테 바로 돌려보낸다. 테스트 시간 아깝다. 빌드가 괜찮으면 본격적으로 테스트 계획 짠다. 스톱워치 켠다. 5분 시작.첫 번째 체크 - 크리티컬 버그 결제 화면부터 본다. QA-2847. 메인 → 상품 선택 → 구매하기. 결제 수단 선택 화면. 뜬다. 카드 선택. 안 죽는다. 간편결제 선택. 정상. 뒤로가기. 괜찮다. 다시 들어가기. 또 괜찮다. 5번 반복. 아무 문제 없다. "오케이." 혼잣말 한다. 사무실에 아직 사람 별로 없다. 두 번째. 로그인 토큰. QA-2851. 로그아웃 한다. 다시 로그인. 타이머 맞춰놓는다. 30분 뒤에 다시 확인해야 한다. 토큰 만료 시간이 30분이니까. 일단 패스. 세 번째. 푸시 알림. QA-2853. 이건 테스트 서버에서 푸시 쏴봐야 한다. 지금은 스킵. Charles Proxy 켜놓고 API 로그 보면서 확인할 예정. 3분 30초 지났다. 괜찮다. 두 번째 체크 - 연관 기능 크리티컬 버그 고치다가 다른 거 망가뜨리는 경우 많다. 결제 고쳤으니까 주문 내역도 봐야 한다. 마이페이지 → 주문 내역. 리스트 뜬다. 스크롤 해본다. 부드럽다. 주문 상세 들어가기. 괜찮다. 환불 버튼 눌러보기. 팝업 뜬다. 취소. 정상. 로그인 고쳤으니까 자동 로그인도 확인. 앱 종료. 다시 켠다. 로그인 유지. 좋다. 4분 50초. 세 번째 체크 - 느낌 이건 말로 설명 안 된다. 그냥 앱을 만진다. 이것저것 눌러본다. 화면 전환 속도. 버튼 반응. 로딩 시간. 뭔가 이상하면 느낌이 온다. 오늘은... 괜찮다. 로딩이 어제보다 빠른 것 같기도 하고. 5분 10초. 끝. 스톱워치 끈다.슬랙 메시지 개발팀 채널에 친다. "v2.4.1 빌드 확인했습니다. 크리티컬 이슈 재현 안 됨. 오전 중으로 풀 테스트 진행하겠습니다." 30초 뒤에 민호 형 답장. "고생하셨습니다 👍" 이모지 하나에 기분이 좋아진다. 우리 사이 괜찮은 편이다. QA-2847 상태 바꾼다. "Fixed - Testing"으로. 노트에 적는다. "09:10 - v231 빌드 1차 확인 완료. 크리티컬 픽스 확인됨. 토큰 만료 09:40 재확인 예정. 푸시 테스트 오전 중." 테스트 케이스 리스트 연다. 체크박스 54개. 오전에 30개는 끝내야 한다. 오후 2시에 기획자랑 미팅 있다. 5분이 결정하는 것들 이 5분 루틴 만들기까지 2년 걸렸다. 신입 때는 빌드 받자마자 풀 테스트 시작했다. 2시간 테스트하고 나서 앱이 아예 안 켜지는 거 발견한 적 있다. 빌드가 잘못 올라온 거였다. 2시간 날렸다. 그 다음부터는 30분 먼저 테스트하고 본격 시작했다. 근데 30분도 길다. 빌드가 망가졌으면 30분도 아깝다. 지금은 5분. 딱 좋다. 빌드 상태 파악하고, 하루 계획 세우고, 개발팀한테 피드백 주기. 이 5분이 하루 8시간을 결정한다. 빌드가 좋으면 오늘 테스트 많이 한다. 빌드가 불안하면 중요한 거만 본다. 개발자도 마찬가지다. 내가 빨리 피드백 주면 오전에 픽스 가능하다. 점심 전에 재배포 받으면 오후에 한 번 더 테스트 돌린다. 배포일 전날이면 이 루틴이 더 중요하다. 토큰 만료 확인 9시 40분. 알람 울린다. 앱 다시 켠다. 메인 화면 뜬다. 로그인 유지된다. "어?" 이상하다. 토큰 만료돼야 하는데. API 로그 확인한다. Charles Proxy. Access Token이 갱신됐다. Refresh Token 쓴 거다. "아..." 로그아웃 안 되는 게 아니라 자동 로그인 된 거다. 버그 아니네. 의도된 거였나? 기획자한테 물어봐야겠다. 스펙 확인. 지라 이슈 다시 본다. 기획자 코멘트 있다. "토큰 만료 시 자동 갱신 필요. 사용자가 재로그인하지 않도록." 아. 내가 놓쳤다. QA-2851 상태 바꾼다. "Won't Fix - Spec"으로. 민호 형한테 메시지. "2851 확인했습니다. 스펙이었네요. 제가 잘못 봤습니다." "괜찮습니다. 저도 헷갈렸어요 ㅎㅎ" 다행이다. 안 까칠하게 구는 개발자 만나서. 하루의 방향 9시 45분. 커피 한 모금 더 마신다. 식었다. 오늘 할 일 정리됐다.결제 플로우 풀 테스트 푸시 알림 중복 확인 리그레션 테스트 30개 기획자 미팅 2시 새 기능 스펙 리뷰 4시빌드가 괜찮아서 계획대로 간다. 어제는 빌드가 3번 깨졌다. 하루 종일 테스트 못 했다. 오늘은 다르다. 오전 5분이 그걸 알려줬다. 테스트 시작한다. 첫 번째 케이스. "TC-001: 비회원 결제 - 카드 결제 성공 케이스" 실행 버튼 누른다. 루틴의 힘 4년 전에는 몰랐다. QA가 뭔지도 모르고 들어왔다. 테스트? 그냥 클릭하면 되는 거 아냐? 천만의 말씀. 테스트는 전략이다. 우선순위다. 시간 관리다. 아침 5분이 그걸 만든다. 빌드 상태 파악 → 하루 계획 → 개발팀 커뮤니케이션. 이게 매일 반복되면 리듬이 생긴다. 개발자도 내 패턴 안다. "민수 씨 피드백 오전 9시 15분쯤 오겠네." 기획자도 안다. "오전에 빌드 확인 끝나면 오후에 미팅 잡아야지." PM도 안다. "민수가 오케이 했으면 빌드 괜찮은 거야." 루틴이 신뢰를 만든다. 신뢰가 쌓이면 일이 편해진다. "이거 테스트 됐어요?" "네, 오전에 확인했습니다." 끝. 더 물어보지 않는다. 망가진 날들 물론 매일 이렇진 않다. 5분 체크하다가 앱 크래시 3번 나는 날도 있다. 로그인 안 되는 날도 있다. 화면이 하얗게 뜨는 날도 있다. 그럴 땐 개발팀 채널에 바로 친다. "v231 빌드 크리티컬 이슈 있습니다. 로그인 크래시. 테스트 보류합니다." 스크린샷 첨부. 로그 첨부. 개발자들 출근하면 바로 본다. 픽스 시작한다. 나는 어제 빌드로 돌아가서 다른 테스트 한다. 시간을 아낀다. 망가진 빌드에 8시간 쓸 순 없다. 5분 체크가 없었으면 오전 내내 헤맸을 거다. "왜 이게 안 되지? 내가 뭘 잘못한 건가?" 아니다. 빌드가 잘못된 거다. 5분이면 안다. 개발자와의 관계 민호 형은 좋은 개발자다. 버그 리포트 올리면 바로 본다. 재현 안 되면 물어본다. 고치면 알려준다. 근데 모든 개발자가 그런 건 아니다. "제 갤럭시에선 안 그러는데요?" "이거 엣지 케이스 아닌가요?" "테스트 환경 문제 아니에요?" 지금은 대응법 안다. 재현 스텝 더 자세히 쓴다. 스크린샷 더 찍는다. 로그 더 붙인다. 감정 빼고 팩트만 쓴다. "iPhone 12, iOS 16.1, 와이파이 환경, 신규 설치 상태에서 100% 재현됩니다." 그럼 할 말 없다. 고친다. 오전 5분 체크 후 빠른 피드백이 관계를 만든다. 개발자도 사람이다. 빨리 알려주면 고맙다. 늦게 알려주면 짜증 난다. 금요일 저녁 6시에 "이거 버그요" 하면 다 죽는다. 월요일 아침 9시 10분에 "이거 버그요" 하면 괜찮다. 한 주 시작이니까. 타이밍이다. 숫자로 보는 5분 계산해봤다. 하루 8시간 근무. 480분. 첫 5분 체크로 아끼는 시간: 평균 2시간. 망가진 빌드 걸러내서 120분 절약. 한 달 20일 근무하면 2400분. 40시간. 1년이면 480시간. 일주일치 근무 시간을 아낀다. 물론 매일 망가진 건 아니다. 한 달에 5일 정도? 그래도 120시간. 3주치. 5분이 3주를 만든다. 오늘의 결과 오후 5시 30분. 테스트 케이스 54개 중 52개 완료. 2개는 내일. 외부 API 연동이라 시간 걸린다. 버그 3개 발견. 모두 Minor.텍스트 오타 1개 UI 정렬 어긋남 1개 로딩 인디케이터 늦게 사라짐 1개크리티컬 없다. 좋다. 내일 배포 가능하다. 슬랙에 친다. "v2.4.1 테스트 완료. Minor 3건 외 이슈 없음. 배포 가능 판단합니다." PM 답장. "고생하셨습니다. 내일 오전 배포 진행하겠습니다." 뿌듯하다. 오전 9시 5분의 시작이 오후 5시 30분의 결과를 만들었다. 내일 아침 내일도 8시 58분에 출근한다. 컴퓨터 켜고 커피 타러 간다. Slack 확인한다. 새벽 빌드 메시지 있을 거다. TestFlight 들어간다. 다운로드 시작한다. 스톱워치 켠다. 5분. 빌드 상태 확인한다. 하루가 시작된다. 이게 QA의 아침이다. 화려하지 않다. 반복적이다. 근데 이 반복이 품질을 만든다. 오전 9시 5분. 매일 똑같지만 매일 다르다.오늘 빌드는 괜찮았다. 내일도 그러길.

주말 카페에서 다른 앱을 테스트한다

주말 카페에서 다른 앱을 테스트한다

주말 카페에서 다른 앱을 테스트한다 일요일 오후 3시 카페에 앉았다. 아이스 아메리카노 한 잔. 여자친구는 병원 당직이다. 혼자 시간이 난다. 폰을 꺼냈다. 요즘 핫하다는 배달 앱을 깔았다. 그냥 쓰려고 깔았다. 진짜다. 근데 로그인 화면 보자마자 손가락이 움직였다. 이메일 칸에 스페이스 막 눌러봤다. 허용된다. '공백 체크 안 하네.' 버튼 연타했다. 두 번 눌렸다. 로딩 막지 않았다. '중복 요청 방지 없네.'아. 시작했다. 또. 직업병은 치료가 안 된다 처음엔 아니었다. 진짜 그냥 썼다. 1년차 때까지는 일 끝나면 폰 보기도 싫었다. 변한 건 2년차 겨울이다. 배달 앱에서 주문했는데 같은 메뉴가 두 번 들어갔다. 버튼 잘못 눌렀나 싶었다. 근데 카드 승인 문자도 두 번 왔다. '아 이거 버그네.' 그때부터다. 앱 쓰면서 자동으로 분석한다.이 버튼 연타하면? 네트워크 끊으면? 뒤로가기 막 누르면? 특수문자 넣으면?머릿속에서 테스트 케이스가 자동 생성된다. 끌 수가 없다. 스위치가 없다. 여자친구가 그랬다. "앱 하나 쓰는데 왜 그렇게 열심히 만져?" 설명했다. 습관이라고. 직업병이라고. 이해 못 한다. 당연하다. 오늘의 타겟: 새로 나온 금융 앱 이번 주에 광고 많이 봤다. 대출 비교 앱. UI 예쁘다. 다운로드 100만. 실행했다. 스플래시 3초. 좀 길다. 권한 요청 팝업. 카메라, 위치, 연락처. '왜 연락처까지? 명분은?'일단 전부 거부했다. 진행된다. 좋다. 근데 매 화면마다 권한 재요청 팝업. 'UX 별로네. 한 번 거부하면 그만 물어봐야지.' 회원가입 시작했다. 이름 칸에 'ㄱㄴㄷ' 입력. 막힌다. 좋다. 숫자 입력. 막힌다. 좋다. 특수문자. 들어간다. 음? '!@#$%' 입력했다. 제출 버튼 활성화. 눌렀다. '올바른 이름을 입력하세요.' '그럼 입력할 때 막아야지 왜 지금 알려줘?' 메모장 켰다. 기록한다. [금융앱A] 1. 이름 입력 - 특수문자 입력은 되는데 제출 시 에러 → 입력 시점에 실시간 검증 필요 2. 권한 거부 후 매번 재요청 → 한 번 거부하면 세션 동안은 묻지 않기좋은 패턴을 배우는 시간 나쁜 거만 보는 건 아니다. 잘 만든 앱도 많다. 저번 주에 쓴 뱅킹 앱. 비밀번호 입력 칸에 페이스트 막아놨다. 보안 때문이다. 이해한다. 근데 재입력 칸은 페이스트 된다. '어? 이거 일부러 그런 건가?' 찾아봤다. 실제로 그런 UX 패턴이다. 첫 입력: 외워서 쳐야 함 (복사 금지) 재입력: 페이스트 허용 (사용성 고려) 메모했다. [좋은 패턴] - 비밀번호 첫 입력은 paste 금지 - 확인 입력은 paste 허용 - 보안과 편의성 균형우리 앱에도 적용하면 좋겠다고 생각했다. 월요일에 제안해야지. 버그 발견의 쾌감 30분쯤 만졌나. 금융 앱 대출 상품 비교 화면에 들어갔다. 필터 적용했다. '5000만원 이하'. 3개 나온다. 정상이다. 필터 해제했다. 전체 보기. 근데 아까 본 상품 하나가 안 보인다. '어?' 다시 필터 걸었다. 나온다. 필터 해제. 안 보인다. 재현했다. 3번. 동일하다. '이거 필터 해제할 때 데이터 갱신 안 되는 버그네.'심장이 뛴다. 이 느낌. 남들은 모른다. 버그 찾을 때 이 쾌감. 보물찾기 같다. 숨겨진 거 찾는 기분. 내가 처음 발견한 것 같은 느낌. 스크린샷 5장 찍었다. 재현 스텝 정리했다. [심각도: 중] 대출 상품 필터 해제 시 일부 상품 미노출 재현율: 100% Steps: 1. 상품 리스트 진입 2. 금액 필터 적용 (5000만원 이하) 3. 상품 3개 노출 확인 4. 필터 전체 해제 5. Expected: 전체 상품 노출 Actual: 1개 상품 누락앱 설정에서 '문의하기' 찾았다. 이메일로 보낼까 고민했다. 근데 답 안 올 확률 90%. 그냥 내 메모장에만 남겼다. 패턴 라이브러리 집에 노트가 있다. A4 공책. '좋은 테스트 패턴 모음'이라고 썼다. 주말마다 앱 쓰면서 발견한 거 정리한다. 입력 검증 패턴실시간 검증 vs 제출 시 검증 (언제가 적절한가) 에러 메시지 위치 (입력 칸 아래 vs 상단 토스트) 자동 포맷팅 (전화번호, 카드번호)버튼 상태 패턴로딩 중 비활성화 연타 방지 (디바운싱, 스로틀링) 제출 후 상태 유지 (재전송 방지)네트워크 에러 패턴타임아웃 처리 (보통 30초) 재시도 로직 (자동 vs 수동) 오프라인 모드 안내권한 요청 패턴필요 시점에 요청 (앱 시작이 아닌) 거부 후 처리 (재요청 주기, 설정 이동) 필수 vs 선택 권한 구분회사에서 테스트할 때 이 노트 본다. '저기서 본 방식이 낫지 않나?' 제안한다. 다 받아들여지진 않는다. 개발 일정이 빠듯하거나. 기획 의도가 다르거나. 그래도 30%는 반영된다. 그것만으로도 의미 있다. 개발자들은 모르는 것들 개발자들이랑 얘기하면 신기해한다. "주말에도 테스트해요?" 아니다. 테스트가 아니다. 그냥 쓰는 거다. 근데 보이는 거다. 개발자들은 자기 기능만 본다. 로그인 개발자는 로그인만. 결제 개발자는 결제만. 근데 사용자는 전체를 쓴다. 로그인하고, 상품 보고, 결제하고, 리뷰 쓴다. 플로우가 중요하다. 이 플로우를 제일 많이 타는 사람. QA다. 우리다. 그래서 다른 앱 쓰는 게 공부다. 어떻게 플로우 설계했나. 어디서 막히나. 어떻게 에러 처리하나. 교과서가 없다. 다른 앱이 교과서다. 월요일 아침 회의 출근했다. 주간 회의. PM이 물었다. "이번 주 개선 제안 있어요?" 손 들었다. "비밀번호 재입력 칸, 페이스트 허용하면 어떨까요?" 개발자 한 명이 물었다. "보안 이슈 아닌가요?" 설명했다. 첫 입력은 막고 재입력만 푼다고. 뱅킹 앱들이 그렇게 한다고. 보안과 사용성 균형이라고. PM이 끄덕였다. "괜찮네요. 다음 스프린트에 넣죠." 기분 좋았다. 주말 공부가 회사에 도움됐다. "또 뭐 있어요?" "상품 필터 해제할 때 데이터 새로고침 확인 필요합니다. 제가 본 앱은 필터 해제 시 일부 아이템이 안 보이더라고요." 개발자가 웃었다. "민수님 주말에 뭐 하세요?" "앱 씁니다." "우리 앱요?" "아뇨. 다른 앱들이요." 다들 웃었다. 근데 진짜다. 직업병의 장점 처음엔 스트레스였다. 앱 하나 편하게 못 쓴다고. 항상 뭔가 찾는다고. 근데 이제는 장점이다. 실력이 늘었다. 테스트 시나리오 짜는 속도가 빨라졌다. 다양한 패턴을 알게 됐다. 어디를 집중적으로 볼지 안다. 제안이 구체적이다. "이렇게 하면 좋겠어요"가 아니라. "A앱은 이렇게 하던데, 우리도 적용하면 어떨까요?" 실제 사례가 있으니 설득력 있다. 버그 찾는 감이 생겼다. '여기 뭔가 있을 것 같은데.' 이 직감이 70% 맞는다. 경험이 쌓인 거다. 면접 볼 때도 도움됐다. 저번에 이직 면접 봤다. (결국 안 갔지만) "평소에 어떻게 공부하세요?" "주말에 다른 앱들 써보면서 좋은 패턴 연구합니다. 노트에 정리하고 있습니다." 면접관 표정이 달라졌다. "오 그런 사람 처음 봤는데요?" 떨어지진 않았다. 연봉 협상 단계까지 갔다. (연봉이 별로 안 올라서 포기했지만) 카페를 나서며 시계 봤다. 5시. 2시간 앉아 있었다. 폰에 메모 5개 추가됐다. 집 가서 노트에 정리해야지. 카페 나서면서 생각했다. 다른 직군은 뭐 하나. 개발자들은 코드 짠다. 토이 프로젝트. 디자이너들은 작업물 본다. 포트폴리오 준비. QA는 뭐 하지? 앱 쓴다. 버그 찾는다. 패턴 공부한다. 이게 맞나 싶기도 하다. 이게 성장인가 싶기도 하다. 근데 월요일 되면 알게 된다. 회의 때 한 마디 던지면. "저기요, 제가 주말에 본 앱은요." 다들 듣는다. 참고한다. 그럼 된 거다. 의미 있는 거다.주말 2시간, 5개 앱, 20개 테스트 케이스. 이게 내 공부법이다.

여자친구에게 설명할 수 없는 일상 - QA 엔지니어의 한숨

여자친구에게 설명할 수 없는 일상 - QA 엔지니어의 한숨

여자친구에게 설명할 수 없는 일상 - QA 엔지니어의 한숨 오늘 뭐 했어? 퇴근하고 여자친구 만났다. 항상 묻는 질문이 온다. "오늘 뭐 했어?" 나는 3초 멈춘다. 머릿속으로 돌아간다. 오늘 아침 9시부터 저녁 7시까지. 앱 빌드 20개 받았다. 테스트 케이스 147개 실행했다. 버그 8개 등록했다. 개발자랑 재현 영상 3번 주고받았다. 크래시 로그 10개 분석했다. 리그레션 테스트 2회차 돌렸다. "...일했지." 여자친구 표정이 묘해진다. "구체적으로?" 구체적으로. 이게 문제다.설명의 늪 "앱 테스트했어." "앱 만드는 거 아니었어?" "아니, 난 만드는 사람이 아니라..." 시작부터 꼬인다. "개발자가 만든 앱을 내가 확인하는 거야." "확인?" "버그 찾는 거지." "버그가 뭔데?" 숨을 크게 들이쉰다. "프로그램이 잘못 작동하는 거." "그럼 개발자가 잘못 만든 거네?" "...뭐 그렇게 볼 수도." "그럼 개발자가 고치면 되는 거 아냐?" 맞다. 논리적으로 맞다. 근데 내 직업을 부정당한 기분이다. "버그를 먼저 찾아야 고치지." "개발자가 자기가 만든 건 자기가 확인하면 되는 거 아니야?" 5초 침묵. 이 대화를 몇 번째 하는 건지 모르겠다.간호사는 다르다 여자친구는 간호사다. 그녀가 오늘 한 일을 말할 때는 다르다. "오늘 응급실 진짜 바빴어. 환자 10명 왔는데 2명은 중증이었어." 고개를 끄덕인다. 이해된다. "링거 꽂고, 활력징후 체크하고, 의사 선생님한테 보고하고..." 구체적이다. 명확하다. "한 환자분이 고마워요 하시는데 진짜 보람찼어." 감동적이기까지 하다. 내 차례가 온다. "나도 오늘 바빴어. 빌드 20개 받았거든." "빌드가 뭐야?" "...개발자가 만든 프로그램?" "하루에 20개를 만들어?" 설명이 길어진다. 빌드는 버전이고, 수정할 때마다 올라오고, 내가 확인해야 하고... 여자친구 눈빛이 흐려진다. "아 그래. 힘들었겠다." 공감이 아니다. 이해 포기의 눈빛이다. 버그 설명의 한계 어제 찾은 버그가 재밌었다. 누군가에게 말하고 싶었다. "어제 대박 버그 찾았어." 여자친구가 관심을 보인다. "어떤 거?" "로그인하고 프로필 들어가서 설정 누르고 알림 켜면 앱이 죽어." "...죽어?" "크래시. 꺼지는 거." "그럼 그냥 안 켜면 되는 거 아냐?" 논리적이다. 하지만 포인트를 놓쳤다. "사용자가 그렇게 생각하고 안 켜면 되는 게 아니라..." "왜?" "그냥 켜야 하는데 안 켜지면 문제잖아." "음..." 그녀는 고개를 끄덕인다. 이해한 게 아니라 대화를 끝내려는 끄덕임이다. 간호사 친구들 만나면 다르다고 한다. "오늘 중환자실에서 심정지 왔는데 5분 만에 소생시켰어!" "대박! 어떻게?" 직업의 드라마가 다르다. 내 드라마는 모니터 안에만 있다.야근의 의미 "오늘 야근해야 돼." "왜?" "배포 전이라서." "배포가 뭔데?" 또 시작이다. "앱스토어에 올리는 거." "그거 버튼 하나 누르면 되는 거 아냐?" "...그 전에 확인해야 하니까." "뭘 확인해?" "버그 있는지." "아직도 버그가 있어? 맨날 확인하는 거 아니었어?" 맞다. 맞는 말이다. 근데 설명할 수가 없다. 회귀 테스트, 스모크 테스트, 최종 검증. 이 단어들을 어떻게 설명하나. "그냥 마지막으로 한 번 더 보는 거야." "그럼 한 시간이면 되는 거 아냐?" "...3시간?" "왜 그렇게 오래 걸려?" 케이스가 많아서, 디바이스별로 봐야 해서, 네트워크 환경 바꿔가면서 봐야 해서. 말이 길어진다. 여자친구는 한숨을 쉰다. "알았어. 조심히 들어와." 조심히 들어와. 야근하는 사람한테 하는 말이 아니다. 밤길 조심하라는 말이다. 성취감의 차이 여자친구는 환자를 살린다. 나는 버그를 죽인다. 그녀는 "고맙습니다" 소리를 듣는다. 나는 "이거 버그 맞아요?" 소리를 듣는다. 그녀는 퇴근하면 뿌듯하다고 한다. 나는 퇴근하면 '내일 또 버그 나오면 어쩌지' 생각한다. "오늘 환자분이 퇴원하셨어. 일주일 전만 해도 많이 아프셨는데." 눈이 반짝인다. 보람이 보인다. "나도 오늘 치명적 버그 잡았어." "...그래?" "앱 결제할 때 두 번 결제되는 버그였어. 사용자들 돈 두 번 빠질 뻔했어." 잠깐 침묵. "그럼 그거 원래 만든 사람이 잘못한 거네?" "...응." "근데 넌 뭘 한 거야?" "발견한 거지." 발견. 그게 내 일이다. 근데 왜 이렇게 작게 들릴까. 연봉 이야기 친구들 만나면 연봉 얘기가 나온다. 여자친구 간호사 친구들도 온다. "저는 3년 차인데 야간 포함하면 4800 정도 받아요." "오 괜찮네요." 내 차례. "저는 4년 차고 4200이요." "어? 개발자 아니었어요?" "QA요." "...뭐 하는 건데요?" 여자친구가 대신 설명한다. "버그 찾는 거래요." "아~ 개발자 밑에서 일하는 거?" 밑이라는 표현. 틀린 말은 아닌데 기분이 묘하다. "같이 일하는 거죠." "그래도 개발자가 더 중요한 거 아니에요?" "...뭐." 여자친구가 내 손을 잡는다. 위로의 손길이다. 근데 위로받고 싶지 않다. 설명하고 싶다. 내 일의 중요성을. 말이 안 나온다. 직업의 무게 택시 타면 기사님이 묻는다. "무슨 일 하세요?" "IT 회사 다녀요." "아~ 개발자시구나. 요즘 잘 나가죠?" "...네." 개발자라고 말한다. 정정하기 귀찮다. 여자친구 부모님 만났을 때도 그랬다. "따님 남자친구 뭐 하는 사람이에요?" "IT 회사 다녀요." "요즘 IT가 대세죠. 연봉도 좋고." 여자친구 어머니 표정이 밝다. "정확히는 QA 엔지니어예요." "...큐에이?" "품질 관리요." "아~ 그래요." 표정이 살짝 어두워진다. 미묘한 변화다. 하지만 느껴진다. 여자친구가 나중에 말했다. "엄마가 개발자인 줄 아셨대." "그렇구나." "괜찮아. 뭐 하든 상관없어." 상관없다는 말. 위로 같지만 상처다. 이해받고 싶은 순간 배포 다음 날이었다. 새벽 3시까지 일했다. 아침에 출근했다. 모니터링한다. 크래시 리포트 확인한다. 0건. 가슴이 뛴다. 내가 잡은 버그들 덕분이다. 팀장님이 지나가면서 말한다. "어제 수고했어. 깔끔하게 배포됐네." 이 순간을 여자친구한테 말하고 싶었다. 저녁에 만났다. "어제 밤샘한 보람 있었어. 배포 완벽하게 됐어." "그래? 다행이다." "버그 하나도 안 나왔어." "원래 안 나와야 하는 거 아냐?" 숨이 막힌다. 맞다. 원래 안 나와야 한다. 근데 그게 당연한 게 아니라는 걸 어떻게 설명하나. "내가 미리 다 잡았으니까 안 나온 거야." "그럼 잘한 거네." "응." 잘한 거네. 끝이다. 더 이상 할 말이 없다. 간호사는 다르다. "오늘 응급 처치 완벽하게 해서 환자분 살렸어." "대단해!" 개발자도 다르다. "오늘 알고리즘 최적화해서 속도 30% 빨라졌어." "와 천재 아냐?" QA는? "버그 안 나왔어." "...원래 안 나와야 하는 거 아냐?" 자동화 공부 요즘 자동화 공부한다. Selenium, Appium 독학 중이다. 여자친구한테 말했다. "나 요즘 자동화 공부해." "자동화? 뭐가?" "테스트 자동화. 내가 손으로 하던 걸 프로그램이 하게." "그럼 네 일을 없애는 거네?" 뜨끔. "그게 아니라 더 효율적으로..." "그럼 나중에 너 자리 없어지는 거 아냐?" 말문이 막힌다. 맞을 수도 있다. 하지만 안 배우면 도태된다. "배워야 살아남아." "힘들겠다." 힘들겠다는 말. 공감이지만 해결책은 아니다. 간호사는 면허가 있다. 개발자는 코드가 있다. QA는 뭐가 있나. 경력? 4년 차 경력이 과연 무기가 될까. 잠이 안 온다. 그래도 어제 여자친구가 물었다. "너 왜 그 일 해?" 3초 생각했다. "재밌어서." "뭐가 재밌어?" "버그 찾는 게." 진심이었다. 엣지 케이스 생각하는 거. 아무도 생각 못 한 시나리오 찾는 거. 크리티컬 버그 잡았을 때 그 쾌감. "이상한 사람이네." 이상한 사람. 인정한다. 일반 사용자들은 앱 쓰면서 버그 만나면 짜증 낸다. 나는 버그 보면 신난다. "어떻게 재현되지?" "어떤 조건에서 터지지?" 이게 내 직업병이고 특기다. 설명할 순 없어도 나는 안다. 내 일이 중요하다는 걸. 평행선 여자친구와 나는 평행선이다. 그녀는 사람을 살린다. 나는 서비스를 살린다. 그녀는 환자를 본다. 나는 버그를 본다. 그녀는 감사받는다. 나는 당연시된다. 하지만 둘 다 필요한 일이다. 언젠가 여자친구가 말했다. "네가 하는 일 완벽히 이해는 못 하지만, 네가 열심히 하는 건 알아." 그거면 된다. 완벽한 이해는 바라지 않는다. 같은 업계 사람도 QA를 오해한다. 다만 인정. 내가 하는 일이 의미 있다는 것. 그것만 있으면 된다. 마무리 오늘도 여자친구가 물을 것이다. "오늘 뭐 했어?" 나는 또 3초 멈출 것이다. 그리고 말할 것이다. "일했지." 구체적으로 설명할 순 없다. 하지만 열심히 했다. 그거면 된다. 사랑하는 사람이 내 일을 이해 못 해도 괜찮다. 나는 안다. 내 일의 가치를. 버그 없는 세상. 그게 내가 만드는 세상이다. 보이지 않아도 중요하다.설명 못 해도 계속한다. 이게 내 일이니까.

야근 수당보다 소중한 것 - QA의 자존감 찾기

야근 수당보다 소중한 것 - QA의 자존감 찾기

연봉 명세서를 펼친 밤연봉 협상 메일을 받았다. 4200만원에서 4500만원. 300만원 올랐다. 월 25만원. 기뻐야 하나. 같은 날 입사한 개발자 친구는 5800만원이 됐다고 한다. 작년에 이미 5500만원이었다. 나랑 똑같이 4년 차다. 대학도 같이 나왔다. "너도 개발 배워. QA는 한계 있어." 친구는 악의 없이 말했다. 근데 그게 더 아프다. 야근 수당 포함하면 4700만원 정도 된다. 배포 전날은 거의 매번 새벽까지다. 수당이 없으면 난 뭐지. 개발자는 야근 안 해도 기본이 높다. QA는 야근해야 겨우 따라간다. 이게 맞나. 회의실의 온도차오늘 연봉 협상 미팅이었다. 팀장님이 말했다. "민수씨 열심히 하는 거 안다. 근데 QA 시장 단가가 그래." 시장 단가. 이 말을 세 번째 듣는다. "개발은 구하기 어렵잖아. 경쟁이 심해서 어쩔 수 없이." 그럼 QA는 쉽게 구하냐. 제대로 할 수 있는 사람이 몇이나 되냐. 테스트 케이스 짜고, 엣지 케이스 찾고, 재현 스텝 정리하고, 개발자 설득하고. 이게 아무나 하는 일이냐. "자동화 배우면 연봉 더 올릴 수 있어." 자동화. 맨날 듣는다. 근데 언제 배우라는 거지. 매일 야근하는데. 주말에 공부하라는 건가. 개발자는 회사에서 React 새 버전 배우면 업무 시간에 한다. QA는 Selenium 배우려면 개인 시간 써야 한다. 이것도 시장 단가냐. 팀장님은 좋은 분이다. 근데 설득이 안 된다. "다른 회사도 비슷할 거야." 알아봤다. 맞다. 다 비슷하다. 그래서 더 화난다. 버그 900개의 가치 지난 1년간 내가 등록한 버그는 917개다. Jira에 다 있다. Critical 52개, Major 284개, Minor 581개. Critical 버그 중 28개는 배포 전에 발견했다. 출시됐으면 서비스 터졌을 것들이다. 로그인 무한 루프, 결제 금액 오표시, 푸시 중복 발송, 개인정보 노출 취약점. 이거 하나만 나가도 회사 망한다. 뉴스 나온다. 주가 떨어진다. 근데 내 연봉엔 안 보인다. 개발자는 "이 기능 제가 만들었어요" 할 수 있다. 눈에 보인다. QA는? "이 버그 제가 찾았어요" 말하면 "그게 네 일이잖아" 돌아온다. 맞다. 내 일이다. 근데 왜 개발자 일은 대단하고 내 일은 당연한 건데. 기능 하나 추가하는 것보다 서비스 안 터지게 하는 게 더 중요한 거 아닌가. 퇴근길의 자문자답9시에 퇴근했다. 배포 일주일 전이라 요즘 이렇다. 지하철에서 생각했다. 나 왜 이 일 하지. 돈? 아니다. 개발 배우면 더 번다. 적성? 글쎄. 테스트는 좋은데 인정은 별로다. 그럼 뭐지. 홍대입구역에서 한 할머니가 스마트폰 보고 계셨다. 우리 회사 앱이다. 결제하시다가 멈추셨다. 네트워크 끊겼나 보다. 근데 3초 후에 다시 진행됐다. 그거 내가 찾은 버그다. 2주 전에. "네트워크 끊기면 무한 로딩 도는데요. 타임아웃 처리 필요합니다." 개발자는 귀찮아했다. "확률 낮은데 꼭 해야 해요?" "할머니가 지하철에서 쓸 수도 있잖아요." 결국 고쳤다. 지금 할머니가 불편 없이 쓰신다. 그게 내 일이다. 연봉 명세서엔 안 나온다. 근데 가치는 있다. 개발자와의 대화 사무실로 돌아왔다. 핫픽스 확인 요청이 왔다. 개발자 성진이가 물었다. "민수야, 너 이직 생각 없어?" "왜?" "QA는 연봉 한계 있잖아. 개발 배워." 웃었다. 오늘만 몇 번째 듣는 소린지. "나도 알아. 근데 나는 개발보다 이게 맞는 것 같아." "그래도 돈은 중요하잖아." 맞다. 중요하다. 여자친구랑 결혼 생각하면 더 그렇다. 근데 성진이한테 말했다. "너 지난주에 만든 기능 있잖아. 가입 플로우." "응." "내가 테스트하면서 17개 버그 찾았어. 그 중에 회원가입 안 되는 거 3개." "...그랬지." "그거 내가 안 찾았으면 출시됐어. 신규 가입 0명이었겠지." "고마워." "난 그게 좋아. 너희가 만든 거 완성시키는 거." 성진이가 웃었다. "그래도 연봉은 나보다 적잖아." "알어. 근데 니가 내 돈 벌어다 줄 거 아니잖아." 둘이 웃었다. 근데 진짜다. 내가 선택한 일이다. 돈이 전부는 아니다. 자존감의 정의 밤 11시. 핫픽스 확인 끝났다. 테스트 리포트 작성한다. "총 23개 테스트 케이스, 모두 Pass. 배포 가능." 이 한 줄을 쓰기 위해 3시간 테스트했다. 개발자들은 이 메시지 보고 안심하고 배포한다. 내가 확인했으니까. 그 믿음이 내 가치다. 연봉 명세서에는 안 나온다. 근데 없으면 안 된다. 작년에 신입 QA가 왔었다. 2개월 만에 관뒀다. "버그 찾아도 인정 안 해주고, 개발자들이 무시하고, 연봉도 낮고. 뭐 하러 이 일 해요?" 이해한다. 나도 맨날 생각한다. 근데 안 그만둔다. 왜냐면 알기 때문이다. 서비스 품질을 지키는 마지막 사람이 나라는 걸. 개발자가 놓친 버그를 찾는 사람이 나라는 걸. 사용자가 불편 없이 쓸 수 있게 하는 사람이 나라는 걸. 그게 내 자존감이다. 야근 수당의 의미 야근 수당 들어온다. 이번 달 110만원. 배포 3번 있었다. 새벽까지 3번 남았다. 시급으로 계산하면 얼마 안 된다. 근데 이게 있어서 연봉이 개발자를 조금이라도 따라간다. 슬픈 일이다. 친구가 말했다. "야근 수당으로 연봉 메꾸는 거 이상하지 않아?" 이상하다. 근데 이게 현실이다. QA 시장 단가. 개발자보다 낮은 대우. 아무나 할 수 있다는 인식. 다 알고 있다. 그래도 계속한다. 왜냐면 야근 수당보다 소중한 게 있으니까. 배포 후에 모니터링하는 30분. 심장 쫄깃하다. 버그 없이 지나가면 안도한다. "이번에도 잘 넘어갔네." 그 안도감. 그게 내 보상이다. 돈으로 환산 안 된다. 근데 가치 있다. 여자친구가 물었다. "개발자가 돈 더 버는데 왜 안 배워?" "나는 지키는 게 좋아. 만드는 것보다." "그게 뭔데?" "품질. 사용자 경험. 서비스 안정성." "그게 돈이 돼?" "안 돼. 근데 의미 있어." 여자친구는 이해 못 한다. 괜찮다. 나도 가끔 이해 못 한다. 내일의 선택 내일도 출근한다. 9시. 어제 올라온 빌드 확인한다. 테스트 시작한다. 버그 찾으면 등록한다. 개발자가 "제 PC에선 안 그러는데요?" 말하면 재현해준다. 배포 일주일 전이면 야근한다. 새벽에 최종 확인한다. 연봉은 개발자보다 낮다. 야근 수당이 없으면 더 낮다. 그래도 한다. 왜? 품질을 지키는 사람이 필요하니까. 아무나 못 하니까. 내가 할 수 있으니까. 자동화 배울 거다. 연봉 더 올릴 거다. 이직도 알아볼 거다. 근데 QA는 안 그만둔다. 이게 내 일이다. 자부심 있다.야근 수당은 숫자다. 자존감은 선택이다. 나는 후자를 택했다.

새벽 2시, 라이브 버그 대응 중인 QA 엔지니어의 혼잣말

새벽 2시, 라이브 버그 대응 중인 QA 엔지니어의 혼잣말

새벽 2시, 라이브 버그 대응 중인 QA 엔지니어의 혼잣말 배포 완료 30분 후 새벽 1시 40분. 배포 완료. 슬랙에 '배포 완료' 메시지 올라왔다. CTO가 이모지 달았다. 개발팀장도 '수고하셨습니다' 남겼다. 난 아직 퇴근 못 한다. 모니터링이 남았다. 최소 1시간. 이게 QA의 숙명이다.센트리 대시보드 켜놨다. 파이어베이스 크래시리틱스도 띄웠다. 찰스 프록시 돌리고, 테스트 계정으로 주요 플로우 돌린다. 로그인. 메인 화면. 상품 검색. 장바구니. 결제. 다 정상이다. 응답 속도도 괜찮다. 여자친구한테 카톡 왔다. "아직 일해?" 읽씹했다. 지금은 집중해야 한다. 새 버전 설치한 유저가 1200명 넘었다. 크래시 0건. 좋다. 이대로 가자. 커피 한 모금. 식었다. 상관없다. 2시 11분, 센트리 알람 띠링. 센트리에서 알람 왔다. 'NullPointerException in PaymentActivity' 심장 내려앉는다. 결제 화면에서 크래시다. 제일 중요한 곳이다. 빠르게 로그 확인한다. 스택 트레이스 읽는다. at com.company.payment.PaymentActivity.updateUI(PaymentActivity.java:247)247번째 줄. 뭔가 null이다. 문제는 재현이다. 내 폰에선 안 난다. 테스트 계정 5개로 다 해봤다. 전부 정상이다.슬랙에 조용히 메시지 올린다. "결제 크래시 1건 발생했습니다. 재현 중입니다." 1분도 안 돼서 답장 온다. 개발자 '지훈'이다. "어떤 상황에서요?" "파악 중입니다." 센트리 로그 다시 본다. 유저 정보 확인한다.안드로이드 9 갤럭시 S9 신규 가입 유저 결제 수단: 카카오페이카카오페이. 우리가 이번에 추가한 거다. 테스트 계정으로 카카오페이 선택한다. 결제 진행한다. 정상이다. 뭐가 다른 거지. 로그 더 파고든다. 유저 플로우 추적한다. 앱 설치 → 회원가입 → 상품 담기 → 결제 시도 → 크래시 회원가입 직후 바로 결제한 유저다. 테스트 계정은 전부 기존 계정이었다. 신규 가입 플로우로 다시 해본다. 회원가입한다. 카카오 간편가입 쓴다. 상품 담는다. 카카오페이 선택한다. 결제하기 누른다. 앱이 꺼진다. "씨발." 재현됐다. 2시 27분, 핫픽스 회의 슬랙에 '@channel' 멘션 날린다. "결제 크래시 재현 완료. 신규 가입 + 카카오페이 조합에서 발생합니다." 30초 만에 단톡방 난리 났다. 지훈: "지금 코드 확인 중" 팀장: "영향 범위 얼마나 되나요" CTO: "핫픽스 해야 하나" 난 센트리 보고 답한다. "현재까지 크래시 3건. 전부 같은 패턴입니다." 3건. 많지 않다. 하지만 결제다. 한 건도 놓칠 수 없다.지훈이 원인 찾았다. "신규 유저는 포인트 정보가 null인데, 카카오페이 선택하면 포인트 차감 로직이 실행돼요. null 체크 안 했습니다." 간단한 버그다. 하지만 치명적이다. CTO가 결정한다. "핫픽스 갑니다. 지훈님 수정하고, 민수님 검증 부탁드립니다." "네." 지훈이 코드 수정 시작한다. 난 테스트 케이스 정리한다.신규 가입 + 카카오페이 결제 신규 가입 + 신용카드 결제 신규 가입 + 네이버페이 결제 기존 유저 + 카카오페이 결제 포인트 있는 유저 + 카카오페이 결제최소 5가지는 확인해야 한다. 여자친구한테 카톡 보낸다. "미안 오늘 못 갈 것 같아" 읽씹 당한다. 당연하다. 2시 58분, 빌드 나옴 지훈이 수정 완료했다. "빌드 올렸습니다." 바로 다운받는다. 설치한다. 테스트 시작한다. 신규 가입한다. 이메일 아무거나. test_20250601_0258@test.com 상품 담는다. 9900원짜리 테스트 상품. 카카오페이 선택한다. 결제 진행한다. 결제 완료 화면 뜬다. 크래시 없다. "1차 확인 완료. 정상입니다." 나머지 케이스도 돌린다. 신용카드. 네이버페이. 포인트 있는 계정. 포인트 없는 계정. 전부 정상이다. 기존 기능도 확인한다. 리그레션이다. 일반 결제. 쿠폰 적용. 배송지 변경. 장바구니 수정. 20분 걸린다. 다 정상이다. 슬랙에 보고한다. "핫픽스 검증 완료. 배포 가능합니다." 팀장이 답한다. "고생하셨습니다. 바로 배포하겠습니다." 3시 23분, 재배포 완료 배포 완료 메시지 뜬다. 이번엔 조마조마하다. 또 뭐 나오면 어쩌나. 센트리 지켜본다. 크래시리틱스 모니터링한다. 5분 지난다. 알람 없다. 10분 지난다. 여전히 조용하다. 신규 설치 유저 500명 넘었다. 크래시 0건. 가슴 쓸어내린다. 살았다. CTO가 슬랙에 쓴다. "민수님 덕분에 큰 사고 막았네요. 고생 많으셨습니다." 지훈도 쓴다. "민수님 재현 안 해주셨으면 큰일 날 뻔했습니다." 기분은 좋다. 하지만 복잡하다. 이게 칭찬받을 일인가. 배포 전에 못 잡은 게 내 잘못 아닌가. 3시 40분, 퇴근 준비 모니터 끈다. 가방 챙긴다. 사무실 아무도 없다. 지훈도 퇴근했다. CTO도 접속 종료했다. 난 1시간 더 있었다. 마지막까지 확인했다. 엘리베이터 타면서 생각한다. '테스트 케이스에 신규 가입 플로우 추가해야겠다.' '카카오페이 테스트 계정 새로 만들어야겠다.' '다음 스프린트 때 자동화 시나리오에 포함시켜야겠다.' 이게 QA다. 사고 막아도 티 안 난다. 사고 나면 제일 먼저 욕먹는다. 택시 탄다. 기사님이 묻는다. "야근하셨어요?" "네. 급한 일 있었어요." "요즘 젊은 분들 고생 많으시네요." 대답 안 한다. 창밖 본다. 새벽 거리는 조용하다. 편의점 불만 켜져 있다. 핸드폰 본다. 센트리 알람 없다. 크래시 0건 유지 중이다. 여자친구한테 카톡 온다. "조심히 들어와. 내일 저녁은 꼭 같이 먹자." "그래. 미안해." "괜찮아. 고생했어." 고마운 사람이다. 4시 12분, 집 도착 집 도착했다. 샤워한다. 침대에 눕는다. 핸드폰 한 번 더 본다. 센트리 확인한다. 여전히 조용하다. 알람 끈다. 눈 감는다. 내일 출근하면 또 테스트다. 또 버그 찾는다. 또 재현한다. 반복이다. 끝없는 반복이다. 근데 이상하다. 싫지 않다. 버그 잡았을 때 쾌감. 사고 막았을 때 안도감. 이게 날 버티게 한다. 'QA는 아무나 하는 거 아니다.' 스스로 되뇌인다. 눈 감힌다. 의식 꺼진다. 내일 또 싸운다. 버그랑.새벽 핫픽스 끝나고 집 가는 택시 안, '오늘도 살았다' 생각했다.

제 PC에선 안 그러는데요? - 개발자와의 영원한 신경전

제 PC에선 안 그러는데요? - 개발자와의 영원한 신경전

제 PC에선 안 그러는데요? - 개발자와의 영원한 신경전 이 말을 들으면 심장이 철렁한다. 버그 리포트 올렸다고 개발팀 슬랙 채널에 댓글 달면, 정확히 이 말이 돌아온다. 매번이다. 정말 매번이다. 어제도 마찬가지였다. 로그인 화면에서 비밀번호 입력 후 뒤로가기 버튼 누르면 앱이 크래시 되는 버그를 찾았다. 갤럭시 S21, 안드로이드 12, 특정 네트워크 환경에서만 재현됐다. 재현 스텝 6줄, 스크린샷 3장, 로그 파일까지 첨부했다. 서툴지 않다고 생각했다. 개발자 김인호가 답했다. "어? 제 PC에선 안 그러는데요? 그리고 저 버튼 눌러본 적도 없는데 왜 누르시는 거예요?" 이게 뭐 하는 말이야.재현 못 하는 버그의 무력함 문제는 간단해 보이는데 복잡하다. 나는 진짜 버그를 찾은 거다. 스크린샷도 있고, 재현 스텝도 명확하고, 로그에도 에러 메시지가 떴다. 근데 개발자 PC에선 안 나온다. 이게 뭐 하는 일인가.처음엔 이게 일반적인 일인 줄 몰랐다. 신입 때는 모든 버그가 재현되는 줄 알았다. 테스트 케이스 만들고, 실행하고, 버그 나오고, 개발자가 고치고 끝. 그렇게 단순할 줄 알았다. 하지만 QA 4년차인 지금 안다. 재현 못 하는 버그가 더 많다는 걸. 이게 진짜 일이구나. 이게 진짜 스트레스구나. 재현 못 하면 뭐가 되냐? 버그 등록도 애매해진다. Jira에 어떻게 쓸까. "확인 됨? 미확인? Known Issue? Needs More Information?" 이것도 고민이다. 개발자는 Needs More Information이라고 달면서 나한테 더 자세한 정보를 달라고 한다. 근데 더 뭘 주지. 내가 이미 다 줬는데. 배포 이후 사용자한테서 버그 리포트 들어오면 더 답답하다. "사용자가 보고한 버그를 재현 못 했습니다"라고 개발팀에 보고하면, 그럼 뭐하냐는 눈빛으로 본다. 너희 QA는 뭐 해주는 건데, 재현도 못 했어? 내가 뭐를 해야 하는 거다.환경 변수의 악마 이 모든 게 환경 때문이다. 개발자가 쓰는 PC와 테스트 기기, 사용자 폰이 다르다. 네트워크 상태도 다르고, 안드로이드 버전도 다르고, 제조사별 커스텀도 다르다. 심지어 캐시 상태, 저장소 용량, 백그라운드에 돌고 있는 앱까지도 영향을 준다. 나는 이 모든 걸 고려해서 테스트한다. 갤럭시, LG, 삼성, 소니 폰. 안드로이드 8부터 13까지. Wi-Fi, 4G, 5G, 약한 신호 상태. 특정 앱이 백그라운드에서 돌 때. 저장소 용량이 거의 없을 때. 화면 회전. 다크모드. 폰트 크기 조정. 접근성 옵션 활성화. 개발자는 주로 최신 Mac에서 에뮬레이터로 테스트한다. 깔끔한 환경. 캐시도 없고, 다른 앱도 거의 없고, 저장소는 충분하다. 그 환경에선 안 나온다. 당연하지. "제 PC에선 안 그러는데요"라는 말은 사실 말이다. 진짜 안 나온다. 내가 거짓말하는 게 아니고, 개발자가 거짓말하는 것도 아니다. 그냥 환경이 다르다.근데 이 말을 들으면 진짜 화난다. 왜? 왜냐하면 내가 하는 일을 폄하하는 것처럼 들리기 때문이다. "너네 테스트가 이상한 거 아니야? 내가 개발한 코드는 완벽한데 너네 환경에서만 문제 나는 거지 뭐"라는 뉘앙스다. 아니다. 사용자들이 다양한 환경에서 쓴다. 그게 내가 테스트하는 이유다. 개발자가 완벽하게 만든 코드도, 사용자 환경에서는 문제가 날 수 있다. 그 문제를 먼저 찾아주려고 나는 여기 앉아 있는 거다.버그인지 스펙인지 헷갈릴 때 어제 또 다른 버그가 올라왔다. 이번엔 결제 화면에서 상품 개수를 99개까지 조정할 수 있는데, 100개를 넘어가는 경우를 테스트했다. EditText에 직접 100을 입력할 수 있었다. 이게 버그인가? 스펙인가? 나는 버그라고 생각했다. 일반적으로 상품 개수는 최대 99개까지만 가능하게 UI를 제한한다. 그런데 여기선 뭔가 숨을 쉴 수 있는 구멍이 있었다. 이걸 막아야 한다고 생각했다. 개발자는 달랐다. "아, 그건 스펙이에요. 관리자를 위해서 100개 이상도 가능하도록 열어뒀어요." 처음 들었다. 그런 스펙은 어디에 있나. 요구사항 문서엔 없다. 기획서엔 없다. 슬랙 채널 어딘가에 있나? 아니다. 개발자가 임의로 정한 것 같다.이게 QA의 제일 어려운 부분이다. 버그인지 스펙인지 판단하는 거. 개발자들은 스펙이라고 하면 일단 스펙인 거고, 버그는 버그인 거다. 근데 스펙이 명확하지 않으면 어떻게 하나. 나는 기획팀에 물어본다. 기획팀도 처음 본다고 한다. 그럼 개발자한테 다시 물어본다. "어디서 이 스펙이 나왔어요?" "아, 제가 임의로 추가했어요." 그럼 버그지 뭐. 하지만 이미 개발된 상태다. 다시 고치려면 리뷰도 해야 하고, 테스트도 다시 해야 한다. 번거롭다. 보통 "일단 Known Issue로 두고 다음 버전에서 수정하자"고 된다. 근데 다음 버전에서도 안 고쳐진다.신뢰를 만드는 방법 그런데 정말로 일 잘하는 QA와 개발자의 팀은 다르다. 신뢰가 있는 팀 말이다. 우리 팀에는 테스트리드 박수진이가 있다. 3년 전에 들어온 사람인데, 지금은 거의 QA 리더 역할을 한다. 그 사람이 버그를 올리면 개발자들이 다르다. 바로 확인한다. 재현 못 했어도 "확인해볼게"라고 한다. 왜? 박수진이의 버그 리포트는 정확하기 때문이다. 박수진이의 비결을 봤다. 첫째, 버그 재현 스텝이 정말 명확하다. "1단계: 로그인. 2단계: 비밀번호 입력 창에서 복붙 실행. 3단계: 백스페이스로 모두 삭제. 4단계: 뒤로가기 버튼 클릭." 이런 식이다. 복잡한 말은 없다. 둘째, 스크린샷과 로그를 잘 찍는다. 버그가 나타나는 정확한 순간의 스크린샷. 그리고 logcat에서 관련 에러 메시지만 추출해서 코드 스니펫처럼 첨부한다. 셋째, 개발자를 존중한다. 버그를 올릴 때도 "혹시 제 테스트 환경 문제일 수도 있지만"이라고 시작한다. 그리고 개발자가 "제 PC에선 안 그러는데요"라고 해도, 바로 함께 재현해본다. 개발자 PC에도 설치해보고, 개발자 환경에 맞춰서 테스트한다. 그러다 보니 "아, 이 환경에서만 나오네요"라고 발견하거나, 때론 정말로 내 환경 문제인 걸 알 수도 있다. 그럼 개발자들이 박수진이를 다르게 본다. "수진아, 버그 올려줄래? 너 올린 건 믿고 가"라고 한다. 심지어 개발자들이 자기 코드에 자신 없으면 박수진이에게 먼저 테스트해달라고 부탁한다. [IMAGE_4] 나도 그렇게 하려고 한다. 근데 정말 힘들다. 하루에 테스트할 게 너무 많다. 요구사항 문서를 다시 읽고, 개발자들과 미리 회의하고, 재현 스텝을 정리하고... 시간이 없다. 그래도 최근 3개월간 노력했다. 주 1회 개발팀과 테스트 전략 회의를 했다. "이번 스프린트에선 어떤 부분을 집중해서 테스트할까?"라고. 개발자들과 의논해서 고위험 영역을 미리 파악했다. 그 결과 버그 재현율이 올라갔다. 개발자들도 내 버그 리포트를 더 빨리 처리하기 시작했다. 뭐가 달라졌냐? 신뢰다.버그가 안 나오는 게 가장 무서운 일 역설적이지만, QA로서 가장 무서운 건 테스트할 때 버그가 안 나오는 거다. 배포하고 나서 사용자한테서 버그가 들어오는 게 가장 답답하다. 어제는 새로운 결제 모듈을 배포했다. 3주간 매일 테스트했다. 아침 9시부터 저녁 6시까지. 점심시간만 빼고. 결제 프로세스의 모든 경로를 테스트했다. 정상 결제, 결제 실패, 취소, 환불, 네트워크 끊김. 심지어 결제 중에 앱을 강제 종료하고 다시 켜봤다. 결과? 버그 없음. 배포 완료. 그리고 오늘 아침, 사용자 1명이 "결제 후 영수증이 없어요"라고 신고했다. 영수증? 내가 뭘 놓쳤지. 다시 확인해봤다. 오 맞다. 결제 완료 후 영수증 페이지가 없었다. 근데 내가 왜 테스트 안 했지? 요구사항 문서를 다시 읽어봤다. 있다. "결제 완료 후 영수증 페이지 표시"라고. 내가 빠뜨렸다. 나는 결제 성공까지만 확인했다. 그 다음은 테스트하지 않았다. 체크리스트에 없었다. 아니, 있었나? 다시 봐도 없다. 그럼 내가 만드지 않았나? 3주 전 테스트 플랜을 찾아봤다. 아, 있네. 뭔가 했던 메모가. "영수증 페이지 테스트 완료"라고. 그럼 뭐가 문제야. [IMAGE_5] 개발자한테 물었다. "영수증 페이지, 스펙이 변경되지 않았나요?" 개발자가 답했다. "아, 그건 나중에 추가되는 거 아닌가요?" 그게 뭐 하는 소리야. 너가 구현한 기능인데. "몰라요. 정의 안 됐어요." 결국 나 때문이다. 내가 체크리스트에 넣고도 테스트를 빠뜨렸거나, 개발자가 아직 구현하지 않았는데 내가 완료했다고 체크했거나. 둘 다 내 책임이다. 이게 QA의 일이다. 버그를 찾는 것도 일이지만, 버그를 놓치지 않는 게 더 중요한 일이다.다음 주는 또 다른 싸움 내일 또 새로운 빌드가 나온다. 소셜 로그인 기능. 마찬가지로 3주간 테스트할 거다. 체크리스트를 만들었다. 사실 이미 만들어놨다. 지난주에. 테스트 항목: 50개. 테스트 케이스: 150개. 예상 테스트 시간: 30시간. 실제 주어진 시간: 2주. 다시 말해서, 하루에 8시간을 테스트에만 써야 한다. 버그 리포팅, 개발자와의 미팅, 기타 업무는 따로다. 즉, 야근은 필수다. 개발자가 또 말할 거다. "제 PC에선 안 그러는데요." 나는 또 알 거다. 그건 너의 PC가 아니라는 거. 사용자의 환경이 다르다는 거. 그리고 내 일은 그 환경에서 버그를 찾는 거라는 거. 하지만 여전히 답답할 거다. 왜? 왜냐하면 의사소통이 부족하기 때문이다. 스펙이 명확하지 않기 때문이다. 개발자와 나 사이의 신뢰가 완벽하지 않기 때문이다. 그래도 한 가지는 안다. 내가 놓친 영수증 버그가 100명 사용자한테는 영향을 미치지 않았다는 거. 왜? 왜냐하면 1명만 신고했으니까. 즉, 79명의 사용자는 이미 마주쳤는데 신고하지 않았거나, 아직 그 경로를 지나가지 않았을 수도 있다. 최악의 경우, 조용히 앱을 삭제했을 수도 있다. 내가 할 수 있는 건 다음 번엔 더 꼼꼼히 하는 거다.제 PC에선 안 그러는데요 - 그래, 알겠어요 이 말을 들으면 아직도 짜증난다. 하지만 이제는 안다. 이건 싸움이 아니라는 거. 누가 잘못했는지를 판단하는 자리가 아니라는 거. 개발자는 자기 환경에서 코드가 제대로 작동하는 걸 본 거다. 그게 거짓이 아니다. 나는 사용자 환경에서 코드가 제대로 작동하지 않는 걸 봤다. 이것도 거짓이 아니다. 둘 다 진짜다. 그냥 환경이 다른 거다. 그래서 이제는 이렇게 대답한다. "네, 저도 알고 있어요. 그래서 저는 다양한 환경에서 테스트하는 거고, 개발자님은 PC 환경에서 테스트하시는 거예요. 저희가 함께 이 버그를 재현해볼까요?" 그럼 개발자도 다르게 반응한다. "아, 그럼 같이 해볼까요?" 신뢰는 이렇게 만들어진다. 하지만 여전히 밤샘 배포는 무섭고, 영수증 버그 같은 실수는 반복될 거고, 개발자와의 신경전은 계속될 거다. 그게 QA의 일이니까. 내일도 새벽까지 테스트해야 한다. "제 PC에선 안 그러는데요"라는 말을 준비하면서.아, 커피 더 마셔야겠다. 오늘도 길 거 같다. [IMAGE_6]