Showing Posts From
버그
- 28 Dec, 2025
버그 수정 확인 - 개발자와의 그 짧은 대화
버그 수정 확인 - 개발자와의 그 짧은 대화 그 한마디 "민수씨, 수정했어요." 슬랙 메시지다. 오전 10시 43분. 어제 등록한 버그. JIRA-4521. 로그인 후 프로필 사진 안 뜨는 거. Priority: High. 배포 2일 전이다. "확인하겠습니다." 답장 보내고 빌드 받는다. 20분 걸린다.설치 완료. 로그인한다. 프로필 사진 뜬다. "오, 됐네?" 근데 뭔가 이상하다. 로그아웃했다가 다시 들어간다. 안 뜬다. 다시 켜본다. 뜬다. 앱 강제 종료. 재실행. 안 뜬다. "아..." 두 번째 메시지 "재현 스텝이요." 슬랙에 쓴다. 스크린샷 3장 첨부.로그인 앱 강제 종료 재실행 프로필 사진 안 뜸개발자 답장. 5분 후. "아 그건 캐시 문제일 거예요. 다음 빌드에서 볼게요." Priority가 High에서 Critical로 바뀐다. 배포 2일 전인데. 점심 먹으러 간다. 김치찌개 맛이 없다. 오후의 반복 오후 2시. 새 빌드 온다. "이번엔 진짜 고쳤습니다." 설치한다. 같은 시나리오 돌린다. 된다. 10번 반복한다. 다 된다. "좋아." 근데 직감이 있다. 뭔가 더 해봐야 할 것 같다. 네트워크 끊어본다. 와이파이 껐다 켠다. 프로필 사진 깨진다. 엑스박스 아이콘. "하..."그 짧은 대화 개발자 자리로 간다. 3미터 거리. "저기요, 네트워크 상태 변경하면..." "아 맞다. 그것까지는 못 봤네요." "언제 가능할까요?" "음... 내일 오전?" 배포 하루 전이다. "네, 기다릴게요." 자리 돌아온다. TestRail에 체크한다. "Fixed (Partial)". 커피 마신다. 네 번째다. 신뢰의 문제가 아니다 '수정했어요'를 못 믿는 게 아니다. 개발자가 거짓말하는 것도 아니다. 그냥 '수정했다'의 정의가 다른 거다. 개발자: "코드 수정했다 = 수정 완료" QA: "모든 시나리오 통과 = 수정 완료" 이 간극. 매번 경험한다. 신입 때는 속상했다. "왜 대충 고쳐?" 3년 차쯤 깨달았다. 개발자는 자기가 고친 케이스만 본다. 당연하다. 시간도 없고, 엣지 케이스는 생각 안 난다. 그게 QA 역할이다. 근데 이걸 설명하기 힘들다. "의심해서 죄송합니다" 같은 느낌 들 때 있다. 체크리스트 버그 수정 확인할 때 내가 하는 것.리포트한 시나리오 그대로 (기본) 반대 순서로 빠르게 연속으로 느리게 하나씩 네트워크 끊고 백그라운드 갔다가 권한 꺼보고 다른 기기에서 이전 빌드랑 비교 관련 기능 리그레션10개 다 하면 30분 걸린다. 시간 없으면? 줄인다. 근데 줄이고 나서 배포하면 불안하다.내일 오전 다음 날. 9시 30분. 빌드 온다. "네트워크 이슈 수정" 설치. 테스트 시작. 로그인. 정상. 앱 종료. 재실행. 정상. 네트워크 끊기. 정상. (캐시된 이미지 표시) 와이파이 켜기. 정상. (이미지 갱신) 비행기 모드. 정상. LTE 전환. 정상. 10번 반복. 다 정상. "됐다." JIRA 상태 변경. "Verified". 개발자한테 슬랙. "확인 완료했습니다." 답장. "감사합니다 ㅎㅎ" 이 'ㅎㅎ'에 안도가 느껴진다. 그래도 나오는 버그 배포했다. 다음 날 아침. CS 문의 들어온다. "프로필 사진이 다른 사람 걸로 나와요." "...뭐?" 재현 안 된다. 우리 계정으로는. CS팀이랑 통화한다. 자세한 상황 듣는다. "아, 계정 두 개로 번갈아 로그인하셨구나." 테스트 안 한 시나리오다. 핫픽스 들어간다. 개발자: "QA에서 확인 안 하셨어요?" "..." 말 안 한다. '계정 두 개 케이스는 스펙 문서에 없었는데요' 같은 거. 버그 등록한다. JIRA-4527. "계정 전환 시 프로필 사진 캐시 이슈" Priority: Critical. 완벽한 검증은 없다 4년 했다. 깨달은 거. 모든 케이스 다 볼 수 없다. 시간도 부족하고, 상상력도 한계 있다. 그래도 최대한 본다. 개발자가 '수정했어요' 하면, 믿으면서도 의심한다. 이상한 관계다. 근데 이게 QA다. 신뢰는 '맹신'이 아니라 '검증 후 확신'이다. 대화가 쌓이면 6개월 함께 일한 개발자가 있다. 처음엔 서로 불편했다. 나: "여기 또 재현돼요." 개발자: "제 폰에선 안 그러는데요." 이게 한 달 반복됐다. 근데 어느 순간부터. 개발자: "민수씨, 이 케이스도 확인 부탁드려요." 자기가 놓칠 수 있는 거 미리 말한다. 나: "네트워크 전환이랑 권한 쪽 집중적으로 볼게요." 확인 범위 얘기한다. 대화가 짧아졌다. 근데 신뢰는 더 깊어졌다. '수정했어요'의 의미를 서로 안다. "코드는 고쳤고, 기본 케이스는 확인했다. 나머지는 QA가 봐줄 거다." 이걸 말 안 해도 안다. 금요일 저녁 배포 직전. 6시. 마지막 빌드 확인 중이다. 개발자가 지나가다 묻는다. "민수씨, 그거 됐어요?" "네, 확인 중이에요. 10분 후에 답 드릴게요." "네, 감사합니다." 10분 후. 슬랙. "최종 확인 완료. 배포 가능합니다." "고생하셨습니다!" 배포 버튼 누른다. PM이. 모니터링 시작한다. 나랑 개발자랑. 30분 후. 특이사항 없다. "오늘은 괜찮은가 봐요." 개발자가 웃는다. "민수씨가 확인해서 그런 거죠." "에이, 뭘요." 근데 기분 좋다. 그 짧은 대화의 무게 "수정했어요." 세 글자다. 네 음절. 근데 이 뒤에 30분 검증이 있다. 10가지 시나리오가 있다. 불안과 확신이 있다. 개발자는 코드를 고친다. QA는 수정을 검증한다. 둘 다 필요하다. '수정했어요'를 믿는 건 맹신이 아니다. 검증하겠다는 약속이다. 퇴근길 7시 반. 집에 간다. 지하철에서 앱 켠다. 우리 서비스 아닌 거. 로그인한다. 프로필 사진 확인한다. "잘 뜨네." 앱 종료했다가 다시 켠다. 프로필 사진 안 뜬다. "..." 다른 회사 QA 생각한다. '쟤도 지금 야근 중이겠네.''수정했어요' 뒤에는 '확인하겠습니다'가 따라온다. 이 짧은 대화가 품질을 만든다.
- 23 Dec, 2025
버그 심각도 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건 영향." "오케이. 당장 본다." 기준 있으니까 빠르다. 협상 아니라 합의. 이게 맞는 것 같다.
- 07 Dec, 2025
모니터링 중 발견한 버그 vs 사용자가 먼저 발견한 버그
모니터링 중 발견한 버그 vs 사용자가 먼저 발견한 버그 배포 후 30분 배포가 끝났다. 오후 2시. 개발자들은 점심 먹으러 갔다. 나는 모니터 3개 앞에 앉아 있다. 왼쪽 모니터: 실서버 로그 중앙 모니터: 앱스토어 리뷰 오른쪽 모니터: 고객센터 문의 심장이 빨리 뛴다. 배포 후 한 시간이 가장 무섭다.새로고침을 누른다. 로그에 에러가 없다. 다시 누른다. 여전히 없다. 5분마다 새로고침. 괜찮은가 보다. 그런데 불안하다. 배포 후 1시간까지는 내가 먼저 찾아야 한다. 그게 QA의 자존심이다. 내가 먼저 발견했을 때 오후 2시 40분. 로그에 이상한 게 보였다. "결제 API 타임아웃 20건." 앱을 켰다. 결제 화면으로 들어갔다. 로딩이 조금 길다. 다시 시도. 또 길다. 세 번째. "오류가 발생했습니다." 찾았다. 재현 스텝을 정리했다.앱 실행 상품 선택 결제 버튼 클릭 3초 후 타임아웃스크린샷 3장. 로그 캡처. Charles Proxy 패킷 덤프. Jira에 티켓을 등록했다. 제목: [긴급] 결제 API 타임아웃 발생 우선순위: Critical 담당자: 백엔드 팀장 슬랙에 메시지를 보냈다. "@channel 결제 장애 확인. 티켓 확인 부탁드립니다." 10분 후 회신이 왔다. "확인했습니다. 서버 스케일업 중." 30분 후 해결됐다. "민수님 덕분에 빨리 잡았네요." 이럴 때 기분이 좋다. 사용자가 모르게 해결했다. 이게 진짜 QA다.사용자가 먼저 발견했을 때 최악의 시나리오. 오후 3시. 아직 점심 안 먹었다. 모니터링 중이었다. 슬랙 알림이 울렸다. 고객센터 채널이다. "결제가 안 된다는 문의 들어왔어요." "저도 방금 받았습니다." "저도요. 3건." 심장이 멎었다. 앱을 켰다. 결제를 시도했다. 에러가 났다. 로그를 확인했다. 30분 전부터 에러가 쌓여 있었다. 왜 못 봤지. 로그 필터를 잘못 걸었나. 아니다. 그냥 못 본 거다. Jira에 티켓을 급하게 올렸다. 슬랙에 메시지를 보냈다. "@channel 결제 장애 발생. 사용자 리포트 들어왔습니다." 분위기가 다르다. "언제부터였어요?" "30분 전부터요." "왜 이제 알렸어요?" 할 말이 없다. 백엔드 개발자가 말했다. "모니터링 뭐 하고 있었어요?" QA 팀장이 들어왔다. "민수씨, 잠깐 얘기 좀." 1시간 후 해결됐다. 하지만 기분이 다르다. 앱스토어 리뷰에 별 1개가 3개 달렸다. "업데이트 후 결제 안 됨" "환불해주세요" "테스트 안 하나요?" 마지막 리뷰가 제일 아프다.30분의 차이 똑같은 버그다. 똑같은 심각도다. 똑같은 해결 시간이다. 하지만 평가가 다르다. 내가 먼저 발견: "민수님 덕분에" 사용자가 먼저: "모니터링 뭐 했어?" 30분 차이다. 억울하다고 생각했다. 같은 버그인데 왜. 근데 맞는 말이다. 사용자가 겪기 전에 막는 게 QA다. 죄책감의 무게 사용자가 먼저 발견한 버그는 무겁다. 테스트는 완벽하게 했다. 배포 전 체크리스트 다 통과했다. 리그레션 테스트도 했다. 그런데 나왔다. 누구 잘못일까. 개발자는 말한다. "테스트 환경에선 안 그랬는데." 기획자는 말한다. "스펙대로 만들었는데." 디자이너는 말한다. "디자인은 문제없는데." 그럼 QA 잘못인가. 명확한 답은 없다. 하지만 사용자는 생각한다. "테스트 안 하나?" 그 한 줄이 제일 아프다. 모니터링의 압박 배포 후 모니터링은 전쟁이다. 새로고침을 200번 넘게 누른다. 에러 로그를 실시간으로 본다. 앱스토어 리뷰를 5분마다 확인한다. 점심도 못 먹는다. 화장실도 빨리 다녀온다. 왜 이렇게까지 하냐고. 30분 차이 때문이다. 내가 먼저 발견하면 영웅. 사용자가 먼저 발견하면 무능. 극단적이다. 알고 있다. 하지만 현실이 그렇다. 완벽한 배포는 없다 4년 차 QA다. 배포를 100번 넘게 했다. 완벽한 배포는 한 번도 없었다. 크고 작은 버그가 항상 나온다. 테스트 환경과 실서버는 다르다. 사용자 패턴은 예측 불가다. 그래서 모니터링이 중요하다. 내가 먼저 발견하는 게 최선이다. 사용자보다 1분이라도 빨리. 사용자 리포트의 무게 고객센터에서 버그 리포트가 올라오면. 그날은 집에 가도 찝찝하다. 샤워하면서도 생각난다. "내가 뭘 놓쳤지?" 자기 전에 테스트 케이스를 다시 본다. 어디서 놓쳤는지 찾는다. 대부분은 찾지 못한다. 엣지 케이스였거나. 실서버 환경 이슈였거나. 타이밍 이슈였거나. "이건 못 찾을 수밖에 없었어." 스스로 위로한다. 근데 별로 위로가 안 된다. 다음 배포 다음 배포 때는 더 꼼꼼히 본다. 체크리스트를 늘린다. 모니터링 시간을 늘린다. 새로고침 주기를 줄인다. 그래도 버그는 나온다. 완벽은 없다. 하지만 계속 노력한다. 내가 먼저 발견하기 위해서. QA의 자존심 사용자보다 먼저 버그를 찾는 것. 이게 QA의 자존심이다. 개발자에게 물어봤다. "QA 왜 필요한 것 같아요?" "버그 찾아주니까요." 반만 맞다. 사용자보다 먼저 찾아주니까다. 오늘의 배포 오늘도 배포가 있다. 오후 2시. 점심은 간단히 먹었다. 모니터 앞에 앉았다. 새로고침 준비 완료. 이번엔 내가 먼저 찾을 거다.30분 먼저 발견하는 게 QA의 일이다.