재현 스텝이 없는 버그 리포트는 범죄다

재현 스텝이 없는 버그 리포트는 범죄다

아침 9시 30분, 슬랙 알림 출근했다. 커피 뽑았다. 슬랙 켰다. "@민수님 버그요! 앱 안 돼요 ㅠㅠ" 심장이 철렁했다. 배포한 지 이틀째다. 메시지 클릭했다. 내용 전부다. "앱 안 돼요 ㅠㅠ" 뭐가 안 되는데? 어디서? 언제? 어떻게? 답장 쳤다. "어떤 기능에서 문제가 발생했나요? 재현 스텝 부탁드립니다." 10분 후. "로그인이요." 아... 진짜. 로그인이 뭐가 안 된다는 건지. 버튼이 안 눌리는 건지, 에러가 뜨는 건지, 앱이 꺼지는 건지. "구체적으로 어떤 증상인가요? 스크린샷 있으실까요?" 30분 지나도 답 없다. 테스트 못한다. 버그 재현 못하면 리포트 못 올린다. 개발자한테 뭐라고 전달하나. 점심시간 되어서야 답장 왔다. "아 제 폰에선 이제 되네요." 되네요가 아니라.재현 스텝 없는 리포트는 쓰레기다 냉정하게 말한다. 재현 스텝 없는 버그 리포트는 쓰레기통 직행이다. 4년 차 하면서 깨달은 거. QA의 핵심은 버그를 찾는 게 아니다. 버그를 전달하는 거다. 버그를 찾았어도 개발자가 재현 못 하면 소용없다. "제 PC에선 안 그러는데요?" 듣고 끝이다. 실제로 있었던 일이다. 지난달에 결제 버그 발견했다. 특정 상품에서 할인이 안 먹혔다. 처음엔 나도 당황했다. 어? 왜 안 되지? 근데 차근차근 해봤다.앱 실행 로그인 (테스트 계정: test001) 홈 > 카테고리 > '전자제품' 상품 A 선택 (상품코드: ELEC-1234) 수량 2개 선택 장바구니 담기 결제하기 클릭 할인 쿠폰 적용 (쿠폰코드: SALE20) 결제 금액 확인→ 기대값: 20% 할인 적용 (19,200원) → 실제값: 할인 미적용 (24,000원) 이렇게 정리해서 Jira에 올렸다. 디바이스 정보도 넣었다. 갤럭시 S23, Android 14, 앱 버전 2.4.1. 스크린샷 3장. 영상도 첨부했다. 개발자가 30분 만에 재현했다. 1시간 만에 수정했다. 이게 정상이다. 근데 보통은? "결제가 이상해요" 이런 식이다. 뭐가 이상한데.정보 없으면 시간만 버린다 재현 스텝 없는 리포트 받으면 뭐가 문제냐. 시간 낭비다. 실제로 계산해봤다. 불완전한 버그 리포트 하나당 평균 2시간 쓴다.리포터한테 추가 정보 요청: 30분 답변 기다리기: 1시간 재현 시도: 30분2시간이면 테스트 케이스 20개는 돌린다. 한 달에 이런 리포트 10개만 받아도 20시간이다. 20시간이면 2.5일이다. 일주일에 반나절씩 날리는 거다. 더 큰 문제는 타이밍이다. 버그 리포트가 늦게 완성되면 픽스도 늦어진다. 배포 일정 밀린다. 그럼 누구 책임이냐. QA다. "QA가 제대로 확인 안 했네" 소리 듣는다. 억울하다. 정보를 안 줬는데 어떻게 확인하나. 지난주에 PM이 물었다. "이 버그 심각도 어떻게 돼요?" 모른다. 재현도 못 했는데 심각도를 어떻게 매기나. 결국 개발 회의 때 "확인 중입니다" 했다. 다음 날 PM이 또 물었다. "아직도 확인 중이에요?" 짜증 났다. 정보 없으면 확인할 수가 없다고. 최소한의 정보 5가지 정리했다. 버그 리포트에 꼭 들어가야 할 정보. 1. 재현 스텝 가장 중요하다. 1단계부터 끝까지. "앱 켜고 → 로그인하고 → 설정 들어가고 → 알림 토글 끄면 → 앱 꺼짐" 이 정도는 되어야 한다. "설정에서 문제 생김" 이건 안 된다. 2. 기대 결과 vs 실제 결과 뭐가 나와야 하는데 뭐가 나왔는지. "저장 완료 팝업 떠야 하는데 → 에러 메시지 뜸" 명확하다. "저장이 안 됨" 이건 애매하다. 무슨 의미인지 모른다. 3. 환경 정보 디바이스, OS 버전, 앱 버전. 갤럭시냐 아이폰이냐에 따라 다르다. Android 12냐 14냐에 따라 다르다. "폰에서요" 이러면 곤란하다. 4. 계정 정보 테스트 계정이 뭔지. 어떤 권한인지. 일반 회원이냐 프리미엄 회원이냐. 로그인 상태냐 비로그인이냐. 차이가 크다. 5. 재현 빈도 항상 되는지, 가끔 되는지. "10번 중 10번" vs "10번 중 1번" 심각도 판단에 중요하다. 이 5가지만 있어도 80%는 해결된다.실제 사례: 좋은 리포트 vs 나쁜 리포트 비교해본다. 나쁜 리포트 사례: "제목: 앱 오류 내용: 앱에서 오류 나요. 확인 부탁드립니다." 이게 끝이다. 뭘 확인하라는 건지. 어디서 오류가 났는지. 어떤 오류인지. 개발자한테 이거 전달했다가 욕먹는다. 좋은 리포트 사례: "제목: [결제] 포인트 사용 시 최종 금액 계산 오류 재현 스텝:앱 실행 후 로그인 (테스트 계정: test_user_01, 보유 포인트: 5,000P) 홈 화면 > 추천 상품 섹션 진입 '무선 이어폰' 상품 선택 (상품번호: PROD-9876, 가격: 89,000원) '구매하기' 버튼 클릭 결제 화면에서 '포인트 사용' 체크박스 선택 사용할 포인트 입력: 5,000P '결제하기' 버튼 클릭기대 결과:최종 결제 금액: 84,000원 (89,000원 - 5,000P) 결제 완료 후 보유 포인트: 0P실제 결과:최종 결제 금액: 89,000원 (포인트 차감 안 됨) 결제 완료 후 보유 포인트: 5,000P (그대로 유지)환경:디바이스: iPhone 14 Pro OS: iOS 17.1.2 앱 버전: 3.2.1 (빌드 #245) 네트워크: WiFi재현 빈도:5회 시도 중 5회 동일 증상 발생추가 정보:스크린샷 첨부 (결제 화면, 완료 화면) 영상 첨부 (재현 과정 30초) 로그 파일: payment_error_20250114.log"차이가 보이나. 두 번째 리포트는 그대로 개발자한테 넘긴다. 추가 질문 없다. 첫 번째 리포트는 30분 동안 추가 정보 뽑아내야 한다. 버그 리포트 템플릿 만들었다 귀찮아서 템플릿 만들었다. Jira에 커스텀 필드로 박아뒀다. ## 재현 스텝 1. 2. 3. ## 기대 결과## 실제 결과## 환경 정보 - 디바이스: - OS 버전: - 앱 버전: - 계정:## 재현 빈도 [ ] 항상 (10/10) [ ] 자주 (7~9/10) [ ] 가끔 (3~6/10) [ ] 드물게 (1~2/10)## 첨부 - [ ] 스크린샷 - [ ] 영상 - [ ] 로그이거 공유했다. 팀 전체에. 처음엔 귀찮아했다. "너무 복잡한 거 아니냐"고. 근데 2주 지나니까 다들 쓴다. 이유는 간단하다. 버그 처리 속도가 2배 빨라졌다. 예전엔 버그 하나당 평균 2일 걸렸다. 지금은 1일 안에 끝난다. 개발자들도 좋아한다. "이제 뭔지 알겠다"고. PM도 만족한다. 진척도 파악이 쉽다고. 그래도 안 쓰는 사람들 문제는 외부다. 고객센터에서 올라오는 버그 리포트. CS팀 통해서 오는 거. 여전히 "앱이 이상해요" 수준이다. CS팀 탓은 아니다. 고객이 그렇게 말하니까. 그래서 CS팀이랑 미팅했다. "고객한테 이렇게 물어봐 주세요" 했다.어떤 화면에서 문제가 생겼나요? 어떤 버튼을 눌렀나요? 화면에 뭐라고 떴나요? 스크린샷 찍어주실 수 있나요?CS팀장이 고개 끄덕였다. "그럼 스크립트 만들어주시면 좋겠어요." 만들었다. A4 한 장짜리. "버그 접수 시 체크리스트" CS팀 모니터에 붙여놨다. 효과 있었다. 고객 리포트 질이 올라갔다. 완벽하진 않아도 전보다 낫다. 개발자도 마찬가지다 거꾸로 생각해봤다. 개발자가 나한테 "이거 테스트 부탁해요" 할 때. 가끔 정보가 없다. "로그인 수정했어요. 테스트 부탁드려요." 뭘 수정했는데? 물어본다. "어떤 부분 수정하셨어요?" "코드 리팩토링이요." 그래서 뭐가 바뀐 건데. "기능은 똑같은데 내부 로직만 바꿨어요." 그럼 테스트 범위가 다르잖아. 리팩토링이면 리그레션 테스트다. 기존 기능 전부 확인해야 한다. 새 기능 추가면 신규 기능만 집중 테스트하면 된다. 정보 없으면 테스트 계획 못 세운다. 그래서 개발팀이랑도 약속했다. "테스트 요청할 때 이거 써주세요." ## 변경 사항 - 무엇을 수정했나요? - 왜 수정했나요?## 테스트 범위 - 어느 부분 테스트하면 되나요? - 연관 기능은 뭐가 있나요?## 주의사항 - 특별히 확인해야 할 케이스가 있나요?지금은 잘 지켜진다. 서로 편하다. 왜 안 쓰는 걸까 생각해봤다. 왜 사람들은 재현 스텝을 안 쓸까. 이유 1: 귀찮다 솔직히 귀찮다. 1~10까지 쓰는 게. "대충 말하면 알아서 하겠지" 생각한다. 근데 그게 더 오래 걸린다. 이유 2: 중요성을 모른다 "버그 있다"고만 하면 된다고 생각한다. 재현 스텝이 왜 필요한지 모른다. 교육이 필요하다. 이유 3: 시간이 없다 급하다. 빨리 올려야 한다. 근데 불완전한 리포트는 결국 더 느리다. 이유 4: 방법을 모른다 뭘 써야 할지 모른다. 템플릿 주면 해결된다. 내가 하는 방식 나는 이렇게 한다. 버그 발견하면 바로 메모한다. 폰 메모장에. 실시간으로. "1. 앱 켬 2. 로그인 3. 설정 4. 알림 5. 토글 끔 6. 앱 꺼짐" 짧게. 나중에 정리하려면 기억 안 난다. 그리고 녹화한다. iOS는 화면 녹화 기본 기능 쓴다. Android는 AZ Screen Recorder 쓴다. 영상 있으면 스텝 빠뜨릴 일 없다. 스크린샷도 찍는다. 문제 발생한 순간. 로그도 뽑는다. Android는 adb logcat. iOS는 Xcode Console. 이 모든 게 5분이면 된다. 그리고 Jira에 정리한다. 10분. 총 15분이면 완벽한 버그 리포트 완성된다. 이게 습관이 되면 자동이다. 재현 안 되는 버그도 있다 현실적으로 말한다. 재현이 안 되는 버그도 있다. 간헐적 버그. 타이밍 이슈. 네트워크 지연. 이런 건 스텝 써도 재현이 안 된다. 그럼 어떻게 하나. 최대한 정보를 모은다.언제 발생했나? (정확한 시각) 몇 번 시도 중 몇 번 발생했나? 발생 직전에 뭐 했나? 네트워크 상태는? (WiFi/LTE/5G) 다른 앱 켜져 있었나?패턴을 찾는다. "WiFi에선 안 되고 LTE에선 됐다" "백그라운드에서 돌아왔을 때만 그렇다" "특정 계정에서만 발생한다" 이런 정보가 힌트가 된다. 개발자가 원인 찾는 데 도움 된다. 재현 안 돼도 포기하면 안 된다. 버그 리포트는 커뮤니케이션이다 깨달은 게 있다. 버그 리포트는 단순한 기록이 아니다. 커뮤니케이션이다. 나와 개발자 사이의. 명확하게 전달해야 명확하게 해결된다. 애매하게 말하면 애매하게 처리된다. "앱이 느려요" → 개발자: "제 폰에선 빠른데요?" "홈 화면 로딩 시간이 3초 → 5초로 늘었어요 (이전 버전 대비)" → 개발자: "확인하겠습니다" 차이가 크다. QA는 통역가다. 사용자의 불편함을 개발자가 이해할 수 있는 언어로 바꿔주는 거. 재현 스텝은 그 언어의 문법이다. 품질은 디테일에서 나온다 결국 품질이다. 앱 품질은 버그를 얼마나 빨리 정확하게 고치느냐에 달렸다. 정확하게 고치려면 정확하게 전달해야 한다. 재현 스텝은 그 시작이다. "대충" 하면 결과도 "대충"이다. 꼼꼼하게 하면 결과도 탄탄하다. 사용자는 모른다. 뒤에서 얼마나 꼼꼼하게 했는지. 그냥 "앱 잘 되네" 하고 쓴다. 그게 우리 일이다. 보이지 않는 곳에서 디테일 챙기는 거. 마지막으로 재현 스텝 없는 버그 리포트는 범죄다. 과장 아니다. 시간 낭비, 품질 저하, 팀 스트레스. 모두의 발목 잡는다. 템플릿 만들어라. 5분이면 된다. 습관 들여라. 2주면 자동이다. 공유해라. 팀 전체가 같은 언어 쓰게. 그럼 달라진다. 배포가 편해진다. 버그가 줄어든다. 팀워크가 좋아진다. 나도 처음엔 귀찮았다. 지금은? 이게 없으면 일 못 한다.재현 스텝은 선택이 아니다. 필수다.

Known Issue vs 진짜 버그 - 그 미세한 경계선

Known Issue vs 진짜 버그 - 그 미세한 경계선

Known Issue vs 진짜 버그 - 그 미세한 경계선 오늘도 이 질문 "민수씨, 이거 버그예요?" 개발자 재훈이가 슬랙으로 물었다. 스크린샷 첨부. 나는 이미 안다. Known Issue다. 작년에 올라왔던 거. "PROJ-2847이요. Known Issue." "아 맞다. 고마워요." 하루에 세 번은 답하는 질문이다.오전 10시, 빌드 확인 새 빌드가 올라왔다. v2.3.45. 테스트 시작하자마자 발견했다. 결제 화면에서 카드사 로고 안 나온다. 첫 반응: "이거 버그네." 두 번째 생각: "아니 잠깐, 이거 전에도..." Jira 검색했다. "결제 카드 로고" 나왔다. PROJ-3201. Status: Known Issue. 작성일: 2024년 11월 12일. Comment 6개. 마지막 코멘트: "카드사 API 문제. 우리 쪽에서 못 고침." 휴. 새 버그 등록할 뻔했다. 진짜 새 버그였던 경우 근데 어제는 달랐다. 장바구니 아이템 삭제 안 됨. 버튼 눌러도 반응 없음. Jira 검색: "장바구니 삭제" 비슷한 이슈 3개 나왔다. 다 Closed. 재현 스텝 비교했다.PROJ-2156: iOS 14에서만 발생 → 나는 iOS 17 PROJ-2489: 특정 상품에서만 → 나는 모든 상품 PROJ-2801: 네트워크 끊겼을 때 → 내 와이파이 멀쩡다른 버그다. 새 이슈 등록했다. PROJ-3412: "[iOS 17] 장바구니 아이템 삭제 버튼 무응답" Priority: High 30분 뒤 재훈이가 픽업했다. "헐 이거 진짜네요." 그날 오후에 핫픽스 나왔다. 뿌듯했다. 제대로 구분해낸 거다.Known Issue 판단 기준 내 나름의 체크리스트가 생겼다. 1단계: 키워드 검색증상 위주로 검색: "삭제 안됨", "화면 멈춤" 기능명 검색: "장바구니", "결제" 에러 메시지 있으면 그대로 검색2단계: 재현 환경 비교OS 버전 같은가 디바이스 같은가 네트워크 상태 같은가 앱 버전 같은가3단계: 타이밍 확인이 빌드에서 처음 발견했나 이전 빌드에서도 있었나 배포 후 유저 리포트 있었나4단계: 개발 히스토리최근 관련 기능 수정 있었나 연관된 다른 이슈 있나 Dependency 변경 있었나이 과정 3분. 3분이면 구분 가능하다. 애매한 케이스 근데 정말 애매할 때가 있다. 지난주 금요일이었다. 프로필 사진 업로드가 느리다. 10초 걸린다. 작년부터 계속 느렸다. PROJ-1845에 기록돼 있다. 근데 이번엔 15초 걸렸다. 이게 Known Issue의 연장선인가, 아니면 새로운 성능 저하인가. 고민했다. 5분 동안. 결론: 새 이슈로 등록. "PROJ-3425: 프로필 사진 업로드 시간 증가 (10초→15초)" 링크 걸었다. "Related to PROJ-1845" PM 수진이가 코멘트 달았다. "이거 모니터링 필요할 듯." 맞다. 트렌드가 중요하다. 점점 느려지는 건 새 문제다.버그 트래킹 시스템 활용법 우리는 Jira 쓴다. 근데 Jira는 도구일 뿐. 중요한 건 어떻게 쓰느냐다. 필터 설정"내가 만든 이슈" 필터: 내 히스토리 확인용 "Known Issue" 필터: 라벨로 구분 "현재 버전 이슈" 필터: 배포 전 체크용매일 아침 이 세 개 필터 확인한다. 라벨 활용Known_Issue: 알려진 문제 Cannot_Fix: 외부 요인으로 못 고치는 것 Low_Priority: 알지만 안 고치는 것 Regression: 재발한 버그라벨만 봐도 대충 안다. 새 버그인지 아닌지. 코멘트 히스토리이슈마다 히스토리가 쌓인다 언제 발견됐고, 왜 안 고쳤고, 재발 여부 코멘트 읽으면 맥락이 보인다신입 때는 코멘트 안 읽었다. 지금은 필수로 읽는다. 링크 연결"Duplicates": 완전히 같은 버그 "Related to": 연관된 이슈 "Blocks": 이거 때문에 못 고치는 이슈링크 따라가다 보면 전체 그림이 보인다. 중복 리포트의 민망함 작년 여름이었다. 신나서 버그 리포트 작성했다. 재현 스텝 10단계. 스크린샷 5장. 동영상까지. 올리자마자 재훈이가 코멘트 달았다. "Duplicate of PROJ-2156" Status: Closed as Duplicate. 얼굴이 화끈거렸다. 검색을 제대로 안 한 거다. 그날 이후로 무조건 검색부터 한다. 3개 키워드로. 지금은 중복 리포트 거의 안 만든다. 한 달에 한 번? 그마저도 재현 환경이 달라서 의도적으로 올리는 경우다. "이건 스펙이에요" 가장 난감한 순간이다. 내가 버그라고 생각한 게 스펙일 때. 지난달에 있었다. 로그인 화면에서 비밀번호 틀리면 에러 메시지 2초 후 사라진다. "이거 너무 빨리 사라지는데요? 버그 아닌가요?" 수진이가 답했다. "스펙이에요. UX팀에서 그렇게 정했대요." "근데 유저가 못 읽을 수도..." "알아요. 근데 스펙이에요." Jira에 올렸다. Status: Known Issue (By Design). 찜찜하지만 어쩔 수 없다. 스펙은 스펙이다. 이것도 Known Issue의 일종이다. 고칠 수 없는. 버전별 Known Issue 앱 버전마다 Known Issue가 다르다. v2.2에서는 있었는데 v2.3에서 고쳐진 것. v2.3에서 새로 생긴 것. TestRail에 버전별로 정리해뒀다. "v2.3.0 Known Issues"프로필 사진 느림 (PROJ-1845) 카드사 로고 안 나옴 (PROJ-3201) iOS 15 이하 크래시 (PROJ-2901) - 지원 종료"v2.2.8 Known Issues (Fixed in v2.3)"장바구니 간헐적 오류 (PROJ-2734) 푸시 알림 중복 (PROJ-2889)배포 전에 이 리스트 확인한다. v2.3 배포하면서 v2.2 이슈들 다시 테스트한다. 정말 고쳐졌나. 안 고쳐진 게 있으면? 그게 Regression이다. Regression의 공포 제일 무서운 게 Regression이다. 고쳐졌던 버그가 다시 나타나는 것. 두 달 전에 경험했다. PROJ-2156. 장바구니 삭제 버그. v2.1.3에서 고쳐졌다. v2.3.12 빌드에서 다시 나타났다. 헐. Regression이다. "PROJ-3501: [Regression] 장바구니 삭제 버튼 무응답 - PROJ-2156 재발" Priority: Critical. 재훈이 멘붕했다. "분명히 고쳤는데..." 코드 확인했더니 다른 기능 수정하다가 그 부분 코드를 덮어쓴 거다. 그날 밤 11시까지 핫픽스 작업했다. Regression은 Known Issue가 아니다. 새 버그다. 심각한. 팀원들 교육하기 신입 QA 지영이가 들어왔다. 3개월 됐다. 처음엔 중복 리포트 많이 만들었다. 하루에 세 개씩. 앉혀서 알려줬다. "버그 발견하면 흥분하지 마. 일단 검색." "키워드 3개로 검색해. 증상, 기능명, 에러 메시지." "비슷한 이슈 나오면 재현 환경 비교." "완전히 같으면 코멘트 달아. 새 이슈 만들지 말고." "다르면 새 이슈 만들되 Related 링크 걸어." 지금은 지영이도 중복 거의 안 만든다. 팀 전체가 이렇게 움직이면 Jira가 깔끔해진다. Known Issue 리뷰 미팅 월요일 오전 10시. 고정 미팅이다. "Known Issue Review" QA팀 3명, PM 수진이, 개발 리드 재훈이. 지난주 쌓인 Known Issue 리스트 리뷰한다. "이거 아직도 못 고쳐요?" "이거 정말 스펙 맞아요?" "이거 우선순위 올려야 하는 거 아닌가요?" 한 시간 동안 20개 이슈 검토한다. 결정:5개: 다음 스프린트에 수정 3개: 우선순위 높임 7개: Known Issue 유지 5개: Close (더 이상 재현 안 됨)이 미팅 없으면 Known Issue가 무한정 쌓인다. 유저 리포트와 Known Issue 고객센터에서 문의 온다. "결제 화면에서 카드사 로고가 안 보여요." 내가 답한다. "PROJ-3201입니다. Known Issue예요. 카드사 API 문제." 고객센터: "유저한테 뭐라고 답해요?" 나: "일시적 현상이며 결제는 정상 진행된다고 안내해주세요." Known Issue를 알면 고객 대응도 빨라진다. 매주 금요일에 Known Issue 리스트를 고객센터에 공유한다. "이번 주 알려진 이슈 5건" FAQ 작성할 때도 쓴다. 통계로 보는 Known Issue 지난 분기 통계 뽑아봤다.전체 이슈: 247개 새 버그: 183개 (74%) Known Issue 재확인: 41개 (17%) 중복 리포트: 23개 (9%)중복을 9%로 줄였다. 작년엔 20%였다. 검색 습관 덕분이다. Known Issue 처리 시간:새 버그 리포트: 평균 15분 Known Issue 확인: 평균 3분시간 절약이 크다. 한 달에 5시간. 내 Known Issue 체크리스트 매일 쓰는 체크리스트다. 포스트잇에 붙여뒀다. [ ] 키워드 3개로 검색했나 [ ] 재현 환경 비교했나 [ ] 버전 히스토리 확인했나 [ ] 코멘트 읽었나 [ ] 링크된 이슈 확인했나5개 다 체크하고 나서 결정한다. 새 버그인지 Known Issue인지. 이 습관 들이는 데 6개월 걸렸다. 지금은 자동으로 한다. 생각 안 하고. 경계선을 지키는 일 QA는 경계를 지킨다. 새 버그와 Known Issue의 경계. 스펙과 버그의 경계. 수정 가능과 불가능의 경계. 이 경계를 명확히 하는 게 내 일이다. 애매하면 물어본다. PM한테, 개발자한테. "이거 Known Issue 맞죠?" "이거 새 버그로 봐야 하나요?" 확실하지 않으면 일단 올린다. 틀려도 괜찮다. 중요한 건 놓치지 않는 것. Known Issue라고 생각했는데 새 Critical 버그면? 그게 제일 무섭다. 그래서 매번 확인한다. 검색하고, 비교하고, 판단한다."PROJ-3412 Closed. 민수씨 덕분에 빠르게 잡았네요." 재훈이 코멘트를 보니 뿌듯하다. 이 판단, 틀리지 않았다.

회의실 안 '스펙 토론' vs 카톡 '스펙 변경' - 소통의 미로

회의실 안 '스펙 토론' vs 카톡 '스펙 변경' - 소통의 미로

회의실 안 '스펙 토론' vs 카톡 '스펙 변경' - 소통의 미로 오전 10시, 기획 회의 회의실에 앉았다. 기획자, 디자이너, 개발자, 그리고 나. "이번 업데이트 스펙입니다." 기획자가 화면을 띄운다. 1시간 동안 이야기했다. 로그인 플로우 변경, 버튼 위치 수정, 에러 메시지 개선. 꼼꼼히 적었다. 엣지 케이스 질문했다. "네트워크 끊기면요?" "로그인 실패 3번 하면요?" 회의록이 공유됐다. Confluence에 올라갔다. 깔끔하다. 이제 이대로 테스트하면 된다. 그게 아니었다.오후 3시, 카톡이 울린다 "민수님~ 로그인 화면 버튼 색깔 바뀌었어요 ㅎㅎ" 기획자 카톡이다. 개인 톡으로 왔다. 아침 회의에서 파란색이라고 했는데 이제 빨간색이란다. "디자이너님이 UX 고려해서 바꿨대요~" 적었다. 메모장에. 하지만 이건 시작이었다. 4시. 개발팀 단톡방. "에러 메시지 텍스트 좀 바꿨습니다. '네트워크 오류' → '연결 실패' 더 직관적이죠?" 누가 결정했지? 회의에선 안 나온 이야기다. 그런데 이미 코드에 반영됐단다. 5시. 디자이너 개인 톡. "민수님 아이콘 사이즈 2px 줄였어요. 전체적 밸런스 위해서요." 2px. QA가 확인해야 할까? 해야 한다. 다른 화면에서 깨질 수 있다. 6시. 기획자가 전체 톡방에. "아 맞다, 로그아웃 후 자동 로그인 팝업 빼기로 했어요. CEO님 피드백이요." 언제 결정났지? 오전 회의 후 점심때 CEO랑 얘기했단다.퇴근 전, 테스트 범위 재정리 노트북 앞에 앉았다. 테스트 케이스를 다시 봤다. 아침에 정리한 거다. 이제 절반이 틀렸다. 버튼 색깔, 메시지 텍스트, 아이콘 사이즈, 팝업 제거. 전부 카톡으로 통보됐다. TestRail 들어갔다. 케이스 수정한다. 20개가 영향 받는다. 한 시간 걸렸다. 문제는 따로 있다. 내가 못 본 톡이 있을까? 개인 톡, 팀 톡, 전사 톡. 3개 채널을 다시 확인했다. 있었다. 오후 2시, 개발자 A가 개발팀 톡방에 올린 거다. "로딩 인디케이터 라이브러리 바꿨습니다. 디자인은 같은데 애니메이션이 좀 달라요." 나는 기획 톡방만 보고 있었다. 놓쳤다. 이게 3번째다. 이번 달만. 왜 카톡으로 바뀌는가 생각해봤다. 회의는 무겁다. 시간 잡아야 하고, 사람 모아야 하고, 안건 만들어야 한다. 작은 변경에는 과하다. 카톡은 가볍다. 생각나면 바로 보낸다. 30초 걸린다. "아 이거 바꿔야겠다" 싶으면 타이핑한다. 문제는 QA는 무거운 일을 한다는 거다. 작은 변경도 전체 시나리오를 확인해야 한다. 버튼 색깔 하나 바뀌어도 명암비 체크, 다크모드 확인, 장애인 접근성 검토. 가볍게 넘길 수 없다. 개발자는 코드 한 줄이다. 기획자는 문서 한 줄이다. QA는 테스트 케이스 20줄이다. 온도 차이가 크다. 그리고 실시간성. 카톡은 지금 당장이다. "이거 오늘 반영할게요~" 확인 요청이 아니라 통보다. 이미 PR 올라갔다. 내일 배포 예정이다. 회의는 합의다. "이렇게 하면 어떨까요?" 의견 묻는다. 카톡은 공지다. "이렇게 했어요." 사후 통보다.놓치지 않으려고 한 것들 처음엔 그냥 열심히 봤다. 모든 톡방을 10분마다 확인했다. 일이 안 됐다. 테스트하다가 톡 보고, 톡 보다가 테스트하고. 집중이 안 된다. 그래서 규칙을 만들었다. 1. 톡 확인 시간 정하기 오전 11시, 오후 3시, 퇴근 전. 3번만 본다. 긴급한 건 전화 오라고 했다. 실제로 긴급한 건 거의 없었다. 효과는 있었다. 테스트 집중도가 올라갔다. 하지만 변경사항 놓치는 건 그대로였다. 오후 3시에 확인하는데 2시에 올라온 변경이 4시 빌드에 들어간다. 2. '스펙 변경' 키워드 검색 퇴근 전에 했다. 모든 톡방에서 '변경', '수정', '바꿨', '추가' 키워드 검색. 30분 걸렸다. 건졌다. 개발자가 "참고로 이거 수정했습니다" 하고 지나간 거. 기획자가 "아 이거 빼는 걸로" 한 거. 전부 찾아냈다. 문제는 매일 30분이 들어간다는 거다. 그리고 키워드 없이 올라온 건 못 찾는다. "네 알겠습니다" 하고 끝난 대화. 뭘 알겠다는 건지 위로 스크롤해야 안다. 3. 변경사항 정리 스레드 만들기 팀 톡방에 제안했다. "스펙 변경은 여기에만 올려주세요." 고정 메시지로 공지했다. 일주일 갔다. 그 다음 주엔 다들 잊었다. 여기저기 흩어졌다. 습관이 안 됐다. 4. 회의록에 실시간 업데이트 Confluence 페이지를 살려보려고 했다. "변경사항 로그" 섹션을 만들었다. 카톡 내용을 직접 복사해서 붙였다. 나만 했다. 다른 사람은 안 했다. 결국 내가 모든 톡을 확인해서 옮기는 일이 됐다. 이중 작업이다. 개발자 민준이와 대화 커피 마시러 나갔다. 민준이를 만났다. 시니어 개발자다. "형, 스펙 변경 왜 톡으로만 말해요?" "아 그거? 회의록 수정하기 귀찮아서요." 솔직하다. "그런데 제가 놓치면 버그 되잖아요." "그러게요. 근데 작은 건데 또 회의 잡기는..." 이해는 간다. 회의는 무겁다. 30분 회의 잡으려면 시간 조율에 1시간 걸린다. 그냥 톡으로 끝내면 1분이다. "그럼 톡방 하나 만들까요? 변경사항 전용." "이미 톡방 10개인데요." 맞다. 전사 톡, 팀 톡, 프로젝트 톡, 배포 톡, 긴급 톡. 또 만들면 혼란만 더하다. "Jira 티켓에 코멘트는요?" "음... 티켓 번호 찾기 귀찮아요." 결국 편의성이다. 카톡이 제일 쉽다. 앱 열면 바로 있다. 생각나면 바로 친다. 그럼 QA가 적응해야 하나? 아니면 프로세스를 바꿔야 하나? 기획자 지은이와 점심 지은이는 기획 3년차다. 같이 도시락 먹었다. "지은아, 스펙 바뀔 때 QA한테 어떻게 알려주는 게 좋을까?" "음... 톡으로 말하면 안 돼요?" "그런데 제가 못 볼 수도 있잖아요." "아 그럼 멘션 달게요?" 멘션. 생각 못 했다. "근데 톡방이 여러 개라서요. 어디에 달아야 하는지..." "그것도 그렇네요." 지은이도 고민이 있었다. 작은 변경을 회의록에 쓰려면 Confluence 들어가야 한다. 로그인하고, 페이지 찾고, 수정 권한 확인하고. 5분 걸린다. "그냥 빠르게 전달하고 싶거든요. 그래야 까먹기 전에..." 까먹기 전에. 여기 핵심이 있다. 스펙은 생각의 흐름이다. 회의 끝나고 점심 먹다가 생각난다. "아 저거 이렇게 하는 게 낫겠다." 메모 안 하면 잊는다. 그래서 바로 카톡 친다. 기획자 입장에선 합리적이다. QA 입장에선 파편화다. 결국 찾은 방법들 완벽한 답은 없었다. 그래도 조금 나아졌다. Daily Sync 15분 매일 오전 10시. 서서 한다. 기획자, 개발자, QA. 어제 바뀐 것들 빠르게 공유. 톡으로 올린 것도 여기서 다시 말한다. 처음엔 귀찮아했다. "톡으로 했는데 또요?" 그래도 밀어붙였다. 2주 지나니 자연스러워졌다. 효과가 있다. 민준이가 "아 그거 로딩 바 바꿨어요" 하면 내가 바로 묻는다. "애니메이션 속도도 달라졌어요?" "네." 바로 확인된다. 톡에선 이런 대화가 안 된다. 물어보면 답이 30분 뒤 온다. 일하다가 까먹는다. 변경사항 라벨링 톡에 규칙 하나 만들었다. 스펙 변경 메시지 앞에 "[변경]" 붙이기. "[변경] 로그인 버튼 색상 빨강으로 수정" 이러면 검색이 쉽다. "[변경]" 키워드로 찾으면 다 나온다. 100% 지켜지진 않지만 60% 정도는 된다. 처음보단 낫다. 빌드 노트 강제화 개발자가 빌드 올릴 때 변경사항 써야 한다. TestRail에 자동으로 올라간다. 안 쓰면 빌드 배포 안 된다. "버튼 색상 변경", "에러 메시지 텍스트 수정", "팝업 제거". 짧아도 좋다. 있으면 된다. 민준이가 처음엔 짜증냈다. "이거 쓰는 시간에 코드 한 줄 더 쳐요." 그래도 지금은 쓴다. 익숙해졌다. QA 입장에선 생명줄이다. 빌드 받으면 제일 먼저 본다. 뭐가 바뀌었는지 알아야 테스트한다. 주간 스펙 리뷰 금요일 4시. 1시간. 이번 주 바뀐 것들 전체 리뷰. 회의록 업데이트한다. 톡에 흩어진 내용들을 정리한다. 귀찮다. 하지만 안 하면 더 귀찮다. 다음 주에 "이거 언제 바뀌었어요?" 물으면 아무도 모른다. 톡 검색하면 3주 전 나온다. 문서화는 미래의 나를 위한 거다. 여전히 어려운 것들 나아졌지만 완벽하진 않다. CEO 직접 지시는 막을 수 없다. "이거 이렇게 바꿔" 하면 기획자가 바로 반영한다. QA 거치지 않는다. 배포 전날 알게 된다. 디자이너 판단 변경도 그렇다. "이게 더 예쁘잖아요" 하면서 바뀐다. 미학적 결정은 회의 안 거친다. QA는 나중에 본다. 개발 중 발견한 기술적 한계. "이거 안 돼요. 다르게 할게요." 이미 코드 바뀌었다. QA는 테스트하면서 안다. "어? 스펙이랑 다른데?" "아 그거 안 돼서 바꿨어요." 실시간 협업이 좋은 건지 나쁜 건지 모르겠다. 빠르게 바뀌는 건 좋다. 시장 반응 보고 즉시 수정한다. 경쟁사 기능 보고 바로 추가한다. 민첩하다. 하지만 QA는 따라가기 힘들다. 품질 확인은 시간이 필요하다. 빠른 변경과 꼼꼼한 테스트는 반대 방향이다. 어디서 균형을 잡아야 할까? 결국 사람 문제 프로세스를 아무리 만들어도 안 지켜지면 끝이다. "Daily Sync 하자" → 2주 뒤 흐지부지 "변경사항 라벨 붙이자" → 반만 지켜짐 "빌드 노트 쓰자" → 형식적으로만 왜 안 될까? 귀찮아서다. 개발자는 코드 짜는 게 일이다. 문서 쓰는 건 부가 업무다. 기획자는 기획하는 게 일이다. 회의록 업데이트는 귀찮다. QA만 문서를 생명처럼 여긴다. 테스트 케이스가 없으면 일을 못 한다. 변경사항 모르면 버그를 놓친다. 그래서 QA가 더 적극적으로 물어봐야 한다. "혹시 바뀐 거 있어요?" 매일 묻는다. 귀찮게 군다. 안 그러면 놓친다. 좋은 QA의 조건: 귀찮은 사람. 농담 아니다. 계속 확인하고, 계속 물어보고, 계속 문서화한다. 안 그러면 품질이 무너진다. 다른 회사는 어떨까 QA 커뮤니티에 물어봤다. A사: Jira 티켓 필수. 스펙 변경은 무조건 티켓. 카톡 금지. 티켓 없으면 테스트 안 함. 엄격하다. 부럽다. 우리 회사는 안 될 것 같다. "티켓 만들기 귀찮아요" 할 게 뻔하다. B사: Slack 스레드 활용. 변경사항은 특정 채널에만. 봇이 자동으로 문서 업데이트. 좋다. 하지만 우리는 카톡이다. Slack 도입 제안했다가 거절당했다. "익숙한 게 카톡인데..." C사: 주간 빌드만 테스트. 일일 변경 추적 안 함. 큰 변경만 확인. 이건 포기 아닌가? QA가 할 일을 줄인 거다. 품질은? D사: QA가 기획 회의 필참. 모든 결정 자리에 있음. 이상적이다. 하지만 회의가 너무 많아진다. 하루 종일 회의만 하다가 끝날 수도. 정답은 없다. 회사마다 다르다. 우리 회사에 맞는 걸 찾아야 한다. 내가 배운 것 완벽한 프로세스는 환상이다. 사람이 하는 일이라 늘 구멍이 있다. 카톡으로 통보되고, 회의록은 늦게 업데이트되고, 작은 변경은 놓친다. 그래도 할 수 있는 것:매일 물어보기. "바뀐 거 있어요?" 빌드마다 변경사항 확인. 눈으로 직접. 톡방 검색. 매일 키워드 검색. 문서화. 내가 직접. 남 기대 안 함. 관계 유지. 개발자, 기획자랑 친하게. 그래야 먼저 말해줌.특히 5번이 중요하다. 민준이랑 친하니까 "아 민수님, 이거 바꿀 건데 확인해주세요" 미리 말해준다. 지은이랑 친하니까 "민수 오빠, 이거 변경 예정인데 큰 거예요?" 물어본다. 프로세스보다 관계가 강하다. QA는 까칠하면 안 된다. "왜 말 안 했어요?" 따지면 다음엔 더 안 말해준다. "아 그랬구나, 알려줘서 고마워요" 해야 다음에도 말해준다. 버그 찾는 일도 중요하지만, 사람 사이에서 정보 찾는 일도 중요하다. 오늘도 카톡이 온다 퇴근 10분 전이다. 카톡이 울렸다. "민수님~ 내일 배포인데 버튼 텍스트 살짝 바꿨어요. '확인' → '완료'. 뉘앙스 차이요 ㅎㅎ" 한숨 나온다. 또 케이스 수정해야 한다. 하지만 화내지 않는다. "알겠습니다~ 확인할게요" 답장 보낸다. 노트북 연다. TestRail 들어간다. '확인' 검색한다. 7개 케이스가 나온다. 전부 '완료'로 바꾼다. 10분 걸렸다. 내일 아침 빌드 받으면 확인한다. 정말 바뀌었는지. 다른 곳은 안 바뀌었는지. 버튼 크기는 괜찮은지. 이게 내 일이다. 회의실에서 결정되든, 카톡으로 통보되든, 내가 확인해야 한다. 놓치면 버그가 된다. 유저가 발견한다. 별점 1점 리뷰 올라온다. "업데이트 후 이상해요." 그게 싫다. 그래서 오늘도 톡방을 확인한다. 검색한다. 물어본다. 문서화한다. 완벽할 순 없지만 최선을 다한다.카톡 알림 끄고 싶다. 하지만 그럼 놓친다. 딜레마다.

QA도 개발자인가? - 커리어 고민 밤샘 일지

QA도 개발자인가? - 커리어 고민 밤샘 일지

QA도 개발자인가? - 커리어 고민 밤샘 일지 새벽 2시, 자동화 코드 새벽 2시다. 파이썬 코드를 본다. Selenium 자동화 강의를 듣는다. 3개월째다. 주말마다 4시간씩 투자한다. 오늘은 로그인 자동화를 구현했다. ID 입력, 비밀번호 입력, 버튼 클릭. 10줄짜리 코드다. 근데 이게 개발인가? 아니면 그냥 스크립트인가?코드가 돌아간다. 로그인 성공. 기분이 묘하다. 수동으로 했으면 30초 걸렸을 것이다. 코드 짜는 데 2시간 걸렸다. 개발자들이 이런 기분인가. 스터디 모임에서 들은 질문 지난주 토요일. QA 자동화 스터디였다. 5명이 모였다. 다들 비슷한 고민이다. "너 나중에 뭐 될 거야? QA? 개발자?" 30대 형이 물었다. 6년차 QA다. "저는... 잘 모르겠어요." 솔직히 대답했다."나도 그랬어. 4년차 때." 형이 말했다. "근데 결국 선택해야 돼. 애매하게 가면 둘 다 안 되더라." 무겁게 다가왔다. 채용 공고를 본 날 월요일 오전. 점심시간에 사람인을 켰다. '자동화 QA 엔지니어' 공고였다. 우대사항:Python, Java 능숙자 CI/CD 구축 경험 API 테스트 자동화 성능 테스트 도구연봉 5000~6500만원. 다음 공고. '주니어 백엔드 개발자'였다. 자격요건:Python, Java 능숙자 RESTful API 개발 경험 데이터베이스 설계 Git, 협업 도구연봉 4500~6000만원. 요구사항이 비슷했다. 근데 커리어 방향은 다르다. 나는 뭘 준비해야 하나. 개발팀 민호 형과의 점심 화요일. 민호 형이랑 점심 먹었다. 4년차 백엔드 개발자다. 나랑 동갑이다. "형, 개발 재밌어?" 물었다. "재밌지. 근데 너도 코드 짜잖아. 자동화." "그게 개발이야?" "개발이지. 왜?"민호 형이 말했다. "QA도 개발자야. 요즘은. 자동화 못 하면 QA 아니잖아." "근데 나는 기능 개발은 안 하잖아." "그게 뭐 중요해? 코드로 문제 해결하면 개발자지." 설득력 있게 들렸다. 근데 마음 한구석이 불편했다. 팀장님과의 1:1 미팅 수요일 오후 4시. 팀장님과 분기 면담이었다. "민수씨 요즘 자동화 공부한다며?" "네. 주말마다 조금씩요." "좋아. 우리 팀도 자동화 전환 계획 있거든." 기대했다. 드디어 자동화를 할 수 있나. "근데 민수씨는 어떻게 가고 싶어? QA? 개발?" 똑같은 질문이었다. "저는... 아직 잘 모르겠습니다." "솔직히 말해볼까? 회사 입장에서는." 팀장님이 말했다. "자동화 QA는 애매해. 개발자만큼 대우 못 해주거든. 근데 매뉴얼 QA보다는 높게 쳐주지." 현실적인 이야기였다. "근데 자동화 잘하면 개발 전환도 가능해. 우리 회사에서 그런 케이스 있어." 선택지를 제시했다. "천천히 생각해봐. 급하지 않아." 급한 건 나였다. 연봉 계산기를 돌려본 밤 그날 밤. 연봉 계산기를 열었다. 현재: 4200만원 (세전) 실수령: 350만원 자동화 QA (5년차 예상): 5000만원 백엔드 개발자 (신입 전환 후): 4500만원 백엔드 개발자 (3년차): 6000만원 숫자만 봤다. 미래는 안 보였다. 돈만이 아니었다. QA로 10년 가면 뭐가 될까. 시니어 QA? QA 리드? 품질 관리자? 개발자로 전환하면? 주니어부터 다시 시작. 근데 천장이 높다. 머리가 아팠다. 여자친구의 질문 목요일 저녁. 지현이랑 통화했다. "오빠 요즘 고민 많지?" "어떻게 알았어?" "목소리 들으면 알지. 말해봐." 커리어 고민을 털어놨다. QA냐 개발이냐. "오빠는 뭐가 더 재밌어?" "버그 찾는 건 재밌어. 근데 코드 짜는 것도 재밌고." "그럼 둘 다 하면 안 돼?" "그게 쉽지 않대. 전문성이 떨어진다고." 지현이가 웃었다. "오빠 생각 너무 많이 해. 일단 해보고 판단하면 안 돼?" 간호사답게 현실적이었다. "나도 처음엔 내과 갈지 외과 갈지 고민했거든. 근데 둘 다 해보니까 알겠더라." 맞는 말이었다. 금요일 오전, 버그 하나 금요일 오전 10시. 새 빌드가 올라왔다. 로그인 후 프로필 화면으로 이동하는 시나리오. 테스트 시작했다. 3번째 시도. 화면이 안 넘어간다. 버그다. 재현 스텝을 정리했다. Jira에 등록했다. 우선순위 High. 재현율 100%. 민호 형한테 슬랙 보냈다. "형, 로그인 후 프로필 이동 안 돼. #1234 확인 부탁." 10분 후. 답장 왔다. "확인했어. API 응답 지연 이슈야. 30분 안에 고칠게." 30분 후. 새 빌드. 테스트 통과. 이게 내 일이다. 문제를 찾고 전달한다. 개발자는 고친다. 역할이 다르다. 근데 둘 다 필요하다. 문득 생각했다. 나는 버그 찾는 걸 좋아한다. 스터디 과제, Python 크롤러 금요일 밤. 스터디 과제를 했다. 앱스토어 리뷰 크롤링하는 스크립트다. 100줄짜리 코드를 짰다. 3시간 걸렸다. 에러가 났다. 디버깅했다. 변수명 오타였다. 고쳤다. 돌렸다. 리뷰 500개가 CSV로 저장됐다. 희열을 느꼈다. 이게 개발이구나. 근데 동시에 생각했다. 이걸 매일 하고 싶나? 기능 설계하고, 코드 짜고, 리뷰 받고, 배포하는 일. 좋아 보였다. 근데 버그 찾는 재미를 포기할 수 있나. 토요일 오후, 커뮤니티 글 토요일 오후. QA 커뮤니티에 글을 올렸다. "QA로 계속 가시는 분들, 어떤 이유인가요?" 댓글이 달렸다. "저는 품질 관리가 적성에 맞아서요. 개발보다 재밌어요." "자동화 QA 10년 했는데 후회 없습니다. 전문성 충분해요." "개발 전환했다가 다시 QA 왔어요. 제 길은 여기였어요." "둘 다 해봐야 압니다. 정답은 없어요." 다들 다른 길을 갔다. 근데 만족하는 사람도 있었다. 희망적이었다. 일요일 아침, 자동화 스크립트 수정 일요일 아침 10시. 지난주 짠 로그인 스크립트를 열었다. 개선하고 싶었다. Wait 조건을 추가했다. 에러 핸들링을 넣었다. 코드가 깔끔해졌다. 실행 속도도 빨라졌다. 뿌듯했다. 이게 코드 리팩토링이구나. 개발자가 된 기분이었다. 잠깐이지만. 그리고 생각했다. 나는 QA고 개발자다. 월요일 출근길, 결론 아닌 결론 월요일 아침 8시 30분. 2호선을 탔다. 고민이 정리됐다. 완벽하진 않지만. 나는 QA다. 버그를 찾는 게 좋다. 품질을 지키는 게 의미 있다. 근데 자동화도 한다. 코드도 짠다. 그것도 개발이다. 'QA 개발자'라는 길이 있다. 애매하지 않다. 그냥 다른 길이다. 백엔드 개발자처럼 연봉이 높진 않을 수 있다. 근데 내 적성에 맞는다. 개발 전환은 언제든 할 수 있다. 지금 당장 정할 필요 없다. 일단 자동화를 배운다. QA 전문성을 쌓는다. 코드 실력도 키운다. 그러다 보면 답이 나온다. 지현이 말대로 해보면 안다. 회사에 도착했다. 9시였다. 새 빌드를 확인했다. 테스트를 시작했다. 오늘도 버그를 찾는다. 코드로 자동화한다. 나는 QA 개발자다.정답은 없다. 그냥 내 길을 간다.

배포 날씨 예보 - 오전 9시 빌드, 오후 2시 테스트 시작

배포 날씨 예보 - 오전 9시 빌드, 오후 2시 테스트 시작

배포 날씨 예보 - 오전 9시 빌드, 오후 2시 테스트 시작 오전 7시 - 출근 전 기상 확인 눈 뜨자마자 슬랙 확인했다. 개발팀장 메시지. "민수님 오늘 2.3.1 배포 예정입니다. 9시 빌드 나갑니다." 아직 집이다. 샤워도 안 했다. 일단 답장부터. "네 확인했습니다. QA 완료 예상 시간은요?" "5시까지요. 6시 스토어 등록 목표입니다." 9시간이다. 체인지로그 확인했다. 항목 12개. 새 기능 2개, 버그 픽스 10개. 아 씨. 새 기능 있으면 시간 더 걸리는데.커피 내렸다. 진하게. 오늘 세 잔은 마실 거다. 배포 날은 전쟁이다. 아니 날씨 같다. 예보는 맑음인데 갑자기 폭우 쏟아지는 날 있잖아. 그런 날. 지난달 생각난다. "간단한 수정"이래서 1시간 보고 했더니 결제 플로우 전체가 깨졌다. 밤 11시까지 테스트했다. 배포 날은 예측이 중요하다. 체인지로그만 믿으면 안 된다. 날씨 예보처럼 여러 지표를 본다.마지막 커밋 시간 (새벽 4시면 위험) 수정한 개발자 (A개발자면 안심, B개발자면 긴장) 변경 파일 개수 (5개 넘으면 연관 버그 각오) 지난 배포 핫픽스 여부 (있었으면 이번에도 있다)오늘 체크했다. 마지막 커밋: 어제 저녁 7시. 괜찮다. 개발자: C님. 중간이다. 50% 확률. 변경 파일: 18개. 많다. 위험. 지난 배포: 핫픽스 1번. 경고. 종합 예보: 흐림. 소나기 가능성 60%. 오전 9시 - 빌드 도착, 초기 점검 회사 도착. 9시 5분. 빌드 슬랙 알림 왔다. "QA 빌드 #234 업로드 완료" 다운로드 시작. 커피 한 모금. 설치. 첫 실행이 중요하다. 크래시 나면 하루 끝이다. 앱 켰다. 로딩. 메인 화면. 됐다. 일단 한숨. 초기 점검 시작. 체크리스트 꺼냈다. 항상 똑같이 한다. 빌드 도착 직후 10분 체크리스트앱 설치/실행 (크래시 확인) 로그인 (계정 3개 돌려가며) 메인 기능 3개 (결제, 검색, 내정보) 이전 버전 Known Issue (재발 확인) 새 기능 진입 (UI 깨짐 체크)10분 만에 끝냈다. 이상 없음. 개발자한테 메시지. "빌드 받았습니다. 초기 점검 OK. 본 테스트 들어갑니다." 답 왔다. "감사합니다~" 물결 많다. 불안하다는 뜻이다.오전 10시 - 체인지로그 분석 본격 시작 전에 체인지로그 뜯어봤다. 2.3.1 변경 사항 새 기능:위시리스트 공유 기능 다크모드 UI 개선버그 픽스:iOS 결제 실패 이슈 검색 필터 안 먹히는 문제 프로필 이미지 안 나오는 버그 푸시 알림 중복 발송 리뷰 작성 시 키보드 안 내려감 상품 상세 로딩 느린 문제 장바구니 수량 변경 오류 쿠폰 적용 안 되는 케이스 로그아웃 후 재로그인 오류 설정 화면 스크롤 버벅임12개다. 4시간에 끝낼 수 있나. 우선순위 정했다. 경험상 알다. Critical (반드시)결제 관련 (1번, 8번) 로그인/로그아웃 (9번) 새 기능 전체 플로우 (위시리스트, 다크모드)High (꼭)푸시 알림 (4번) 장바구니 (7번) 검색 (2번)Medium (시간 되면)UI 버그들 (3, 5, 10번) 성능 (6번)Low는 없다. 배포 날에 Low는 없다. 다 High다. 테스트 케이스 정리했다. 엑셀 켰다. 총 87개 케이스. 새 기능 30개, 리그레션 57개. 4시간이면... 케이스당 3분. 불가능하다. 리그레션 줄였다. 변경 영향 있는 것만. 38개로. 총 68개. 케이스당 3.5분. 빡빡하지만 가능하다. 단, 버그 안 나왔을 때. 오전 11시 - 위시리스트 공유 지옥 새 기능부터 했다. 위시리스트 공유. 간단해 보였다. "공유" 버튼 누르면 링크 복사. 끝. 그게 아니었다. 테스트 시나리오 1: 기본 공유위시리스트 생성 상품 3개 추가 공유 버튼 클릭 링크 복사 확인 카톡으로 전송 링크 클릭 위시리스트 표시됐다. 다음. 테스트 시나리오 2: 비로그인 수신로그아웃 링크 클릭 로그인 유도 팝업 로그인 후 위시리스트 확인안 됐다. 로그인 후에 메인 화면으로 간다. 위시리스트 안 뜬다. 버그 1번. Jira 등록. BUG-1847: 비로그인 상태 위시리스트 링크 클릭 후 로그인 시 딥링크 미작동 재현 스텝 썼다. 스크린샷 5장 첨부. 영상도 찍었다. 개발자한테 슬랙. "위시리스트 공유 버그 올렸습니다. 확인 부탁드려요." 5분 후 답 왔다. "아 그거 스펙 아닌가요? 딥링크는 로그인 상태에서만..." 아니다. 기획서 확인했다. 명시돼 있다. "비로그인도 지원" 기획자한테 물었다. "위시리스트 공유, 비로그인도 되는 거 맞죠?" "네 맞아요. 로그인 후 자동으로 이동해야 해요." 개발자한테 다시. "기획 확인했습니다. 버그 맞습니다." "아... 네 확인할게요."30분 지났다. 아직 시나리오 2다. 테스트 시나리오 3: 품절 상품 포함위시리스트에 품절 상품 추가 공유 수신자 확인품절 상품이 안 보인다. 의도인가 버그인가. 기획자한테 또 물었다. "품절 상품도 보여야 하나요?" "당연하죠. 품절 표시하고 보여줘야죠." 버그 2번. BUG-1848: 위시리스트 공유 시 품절 상품 미표시 개발자 반응. "?? 품절은 필터링하는 게 맞는 거 아닌가요" 기획자 반응. "아니요. 보여줘야 해요." 이래서 스펙 문서가 중요하다. 근데 스펙 문서에 없다. 당연한 거라고 생각해서. 당연한 게 없다. QA한테는. 테스트 시나리오 4-10 계속했다. 엣지 케이스.위시리스트 삭제 후 링크 클릭 상품 전체 삭제된 위시리스트 공유 링크 만료 (7일) 동일 링크 재사용 위시리스트 100개 상품 (대량) 특수문자 포함 상품명 이미지 없는 상품버그 4개 더 나왔다. 11시 30분. 새 기능 하나에 1시간 반. 아직 다크모드 안 했다. 오후 12시 - 점심 거른다 식당 갈 시간 없다. 편의점 갔다. 삼각김밥 2개. 바나나우유. 에너지바. 책상에서 먹으면서 다크모드 테스트. 다크모드는 UI 테스트다. 모든 화면 봐야 한다. 다크모드 체크리스트메인 화면 (배경, 텍스트, 아이콘) 상품 리스트 (카드, 이미지 경계) 상품 상세 (리뷰, 문의, 구매) 마이페이지 (프로필, 설정) 결제 화면 (폼, 버튼) 팝업/토스트 (대비, 가독성) 에러 메시지 (빨간색 가독성)화면 50개. 하나씩 라이트/다크 전환하며. 삼각김밥 먹으면서 스크린샷 찍었다. 버그 발견. 결제 화면. 다크모드에서 입력 필드 테두리가 안 보인다. 배경이랑 같은 색. 버그 등록. BUG-1853: 다크모드 결제 화면 입력 필드 테두리 미표시 심각도 High. 결제는 Critical 경로다. 개발자 반응. "헉 확인했습니다. 바로 수정할게요" 빠르다. 좋다. 근데 또 있다. 리뷰 별점. 라이트모드에선 노란 별. 다크모드에선... 흰 별. 배경이 어두운 회색인데 흰 별이면 안 예쁘다. 이건 버그인가 디자인인가. 디자이너한테 물었다. "다크모드 별점 색상 흰색 맞나요?" "어? 노란색이어야 하는데요." 버그다. BUG-1854: 다크모드 리뷰 별점 색상 오류 (노란색→흰색) 12시 40분. 점심 시간 끝났다. 다크모드 30개 화면 남았다. 오후 1시 - 리그레션의 압박 새 기능만 하면 안 된다. 리그레션 해야 한다. 기존 기능이 안 깨졌는지. 이게 더 무섭다. "새 기능 버그는 찾아도 괜찮다. 기존 기능 버그는 QA 책임이다." 누가 그랬나. 나다. 리그레션 리스트 38개. 우선순위 높은 것부터. 결제 플로우 (30분)일반 결제 쿠폰 적용 포인트 사용 복합 결제 (쿠폰+포인트) 결제 실패 환불다 됐다. 이상 없음. 근데 이상하다. iOS 결제 실패 이슈 수정했다는데 테스트 케이스가 없다. 개발자한테 물었다. "iOS 결제 실패 이슈, 어떤 상황에서 실패했던 건가요?" "아 그거요. 카드 할부 선택 시 크래시 나던 거요." 할부? 내 테스트 케이스에 없었다. 급하게 테스트. 할부 3개월. 결제. 됐다. 할부 6개월. 결제. 됐다. 할부 12개월. 결제. 크래시. "결제 정보를 불러올 수 없습니다." 아직 안 고쳐졌다. 아니 부분만 고쳐졌다. 버그 리오픈. BUG-1799: [RE-OPEN] iOS 12개월 할부 결제 시 크래시 개발자 반응. "?? 3개월이랑 6개월은 되는데요?" "12개월은 안 됩니다. 재현 영상 첨부했어요." "아... 확인할게요." 1시 30분. 배포까지 4시간 반. 리그레션 30개 남았다. 오후 2시 - 핫픽스 빌드 온다 개발자가 급하게 수정했다. "민수님 핫픽스 빌드 올렸습니다. #235" 30분 만에 왔다. 빠르다. 불안하다. 빠른 게 좋은 게 아니다. 꼼꼼한 게 좋은 거다. 다운로드. 설치. 핫픽스 확인 항목수정된 버그 (비로그인 딥링크, 결제 필드, 별점, 12개월 할부) 주변 기능 (혹시 다른 거 깨졌나) 전체 플로우 재확인 (빠른 수정은 실수 동반)하나씩. 비로그인 딥링크: 됐다. 결제 필드: 됐다. 별점 색상: 됐다. 12개월 할부: 됐다. 좋다. 근데 방심하면 안 된다. 주변 확인. 로그인 플로우 전체 다시. 일반 로그인. 됐다. 소셜 로그인. 됐다. 회원가입. 됐다. 비밀번호 찾기. 됐다. 결제도 전체 다시. 일반 결제. 됐다. 할부 전체. 됐다. 됐다. 됐는데. 위시리스트 공유 다시 해봤다. 로그인 상태에서 링크 받기. 됐다. 근데 앱을 강제 종료하고 링크 클릭하면? 앱 실행. 로딩. 메인 화면. 위시리스트 안 뜬다. 또 버그다. BUG-1855: 앱 미실행 상태 위시리스트 딥링크 미작동 개발자 멘션. "딥링크 한 가지 더 확인 부탁드립니다." 답이 없다. 5분 후. "아... 콜드 스타트 케이스 놓쳤네요. 수정할게요." 또 기다린다. 오후 3시 - 두 번째 핫픽스 빌드 #236 왔다. 이번엔 더 꼼꼼하게. 콜드 스타트 딥링크: 됐다. 웜 스타트 딥링크: 됐다. 백그라운드 딥링크: 됐다. 모든 상황 테스트했다. 이제 진짜 됐다. 리그레션 재개. 25개 남았다. 검색 기능 (20분)키워드 검색 필터 (카테고리, 가격, 평점) 정렬 (인기순, 최신순, 가격순) 최근 검색어 자동완성됐다. 장바구니 (15분)상품 추가/삭제 수량 변경 옵션 변경 선택 삭제 전체 삭제수량 변경에서 걸렸다. 100개 입력. 저장. 확인. 수량이 1로 돌아갔다. 버그인가? 체인지로그 확인. "수량 변경 오류 수정" 이게 수정된 거다. 100개는 최대 수량 초과라서 1로 리셋. 그럼 에러 메시지가 떠야 하는 거 아닌가? 기획자한테. "장바구니 최대 수량 초과 시 동작이요?" "최대 수량으로 자동 조정하고 토스트 띄워요." 토스트 없다. 버그. BUG-1856: 장바구니 최대 수량 초과 시 안내 메시지 미표시 개발자. "토스트까지 해야 하나요? 간단한 수정인데..." 기획자. "네 사용자가 왜 수량이 바뀌었는지 알아야죠." 추가 수정 들어갔다. 3시 40분. 배포까지 3시간 20분. 리그레션 15개 남았다. 오후 4시 - 마지막 빌드의 공포 세 번째 핫픽스. 빌드 #237. 이제 지친다. 커피 네 번째. 토스트 확인. 됐다. 근데 불안하다. 세 번째 핫픽스. 경험상 알다. "세 번 고치면 네 번째 버그가 온다." 전체 플로우 다시. 처음부터. 로그인. 검색. 상품 담기. 위시리스트. 공유. 결제. 전부 됐다. 괜찮다. 이번엔 괜찮다. 리그레션 나머지. 프로필 (10분)정보 수정 이미지 업로드 배송지 관리 리뷰 목록됐다. 설정 (10분)알림 설정 약관 확인 버전 정보 로그아웃됐다. 푸시 알림 (15분) 이게 제일 귀찮다. 실제 발송 테스트 해야 한다. 개발자한테. "푸시 테스트 발송 부탁드려요." 발송 왔다. 확인. 앱 꺼진 상태: 알림 옴. 클릭. 해당 화면 이동. 됐다. 앱 켜진 상태: 인앱 알림. 클릭. 이동. 됐다. 중복 발송 확인. 안 온다. 수정 확인. 성능 체크 (10분) 상품 상세 로딩. 2초. 괜찮다. 리스트 스크롤. 부드럽다. 이미지 로딩. 빠르다. 메모리 사용량. 정상. 배터리 소모. 측정 불가. 시간 없다. 4시 50분. 리그레션 완료. 오후 5시 - 최종 보고서 테스트 끝났다. 최종 결과 총 테스트 케이스: 68개 실행: 68개 통과: 59개 실패: 9개 (모두 수정 완료) 발견 버그: 11개 Critical: 0개 High: 3개 Medium: 8개 빌드: #237 (3차 핫픽스) 배포 가능 여부: 조건부 승인 조건: 모니터링 필수 항목위시리스트 딥링크 (신규 기능) 12개월 할부 결제 (iOS) 장바구니 수량 변경 (토스트)보고서 작성. 슬랙에 공유. "QA 완료했습니다. 배포 승인합니다. 단, 위 3개 항목 모니터링 부탁드립니다." 팀장 반응. "고생하셨습니다. 6시 배포 진행하겠습니다." 개발팀장. "민수님 덕분에 큰 버그 잡았네요. 감사합니다." 기분 좋다. 이럴 때 보람 느낀다. 근데 아직 끝 아니다. 오후 6시 - 스토어 배포 모니터링 개발자가 빌드 업로드했다. 앱스토어: 심사 대기 플레이스토어: 심사 중 플레이스토어는 빠르다. 1시간이면 통과. 앱스토어는 느리다. 길면 24시간. 오늘은 빨랐다. 2시간 만에 둘 다 통과. 배포 시작. 단계별 배포. 1단계: 5% (1시간) 2단계: 25% (2시간) 3단계: 100% 5% 배포. 모니터링 시작. Firebase Crashlytics 켰다. 크래시 리포트 확인. 없다. 좋다. GA4 켰다. 실시간 사용자. 위시리스트 공유 이벤트. 5건. 성공 5건. 결제 이벤트. 12건. 성공 11건, 실패 1건. 실패 로그 확인. 카드사 오류. 우리 버그 아니다. 슬랙 모니터링. CS 문의 없다. 1시간 지났다. 이상 없음. 25% 배포. 2시간 더 모니터링. 크래시 없음. CS 문의 없음. 괜찮다. 이번 배포는 안정적이다. 오후 9시 - 퇴근 전 회고 100% 배포 완료. 총 사용자 50만. 크래시율 0.1%. 정상. 배포 성공이다. 오늘 배운 것. 배포 날 생존 법칙체인지로그를 믿지 마라. 직접 확인해라. 첫 빌드에 모든 버그가 있다. 각오해라. 핫픽스는 또 다른 버그를 부른다. 빠른 수정보다 정확한 수정이 낫다. 엣지 케이스를 놓치지 마라. 개발자와 기획자 사이에서 팩트로 말해라. 리그레션을 절대 건너뛰지 마라. 마지막까지 방심하지 마라. 모니터링까지가 배포다. 커피는 필수다.책상 정리했다. 테스트폰 5대. 노트북. 체크리스트. 여자친구한테 카톡. "끝났어. 배고파 죽겠다." "고생했어 ㅠㅠ 뭐 먹을래?" "고기. 무조건 고기." 가방 챙겼다. 불 껐다. 내일 출근하면 또 버그 리포트가 쌓여 있겠지. CS팀에서 "이거 버그 아닌가요?" 하는 문의. 개발자는 "다음 버전에 넣을게요" 하는 답변. 그게 QA 일상이다. 그래도 오늘은 잘했다. 큰 버그 다 잡았다. 사용자는 모를 거다. 모르는 게 최고다. 모르게 하는 게 QA 실력이다.배포 날씨는 예보할 수 있다. 100% 정확하진 않지만. 대비는 할 수 있다. 그게 경력이다.