Showing Posts From
Issue
- 13 Dec, 2025
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. 민수씨 덕분에 빠르게 잡았네요." 재훈이 코멘트를 보니 뿌듯하다. 이 판단, 틀리지 않았다.