테스트 케이스 3000개를 쓰고 나서 깨달은 것

테스트 케이스 3000개를 쓰고 나서 깨달은 것

3000개 테스트 케이스 3000개를 썼다. 정확히는 3247개다. TestRail에 다 기록돼 있다. 4년 동안 쌓인 숫자다. 처음엔 뿌듯했다. 지금은 그냥 숫자다. 어제도 케이스 20개 추가했다. 결제 플로우 개편이래서. 오늘도 15개 더 써야 한다.반복의 늪 로그인 테스트 케이스만 80개다. 회원가입은 65개. 결제는 120개. 매번 비슷하다. 정상 케이스, 에러 케이스, 엣지 케이스. 이메일 형식 체크, 비밀번호 자릿수, 특수문자 입력. 복붙하고 수정한다. 또 복붙하고 수정한다. 이게 내 일의 70%다. 신규 기능 나올 때마다 똑같은 패턴. "이 필드는 필수인가요?" "최대 입력 길이는요?" "서버 에러 나면 어떻게 되나요?" 물어보고, 케이스 쓰고, 실행하고, 버그 등록. 다음 기능 나오면 또.자동화라는 단어 팀장이 말했다. "자동화 좀 해봐." 알고 있다. Selenium, Appium, Cypress. 이름은 다 안다. 유튜브에 강의도 봤다. "Hello World" 찍는 데까지 해봤다. 그다음이 문제다. 퇴근하면 9시다. 집 가면 10시. 씻고 밥 먹으면 11시. 공부 시작하면 12시. 한 시간 보면 1시. 내일 9시 출근이다. 주말? 토요일은 빨래하고 청소하고 여자친구 만난다. 일요일은 부모님 전화하고 밀린 드라마 본다. 그러다 월요일. 테스트 케이스 30개 써야 한다는 메시지. 자동화는 다음 주로.시간이 없다는 변명 동료 하나가 자동화로 넘어갔다. 6개월 공부했다고. 연봉 800만원 올랐다. 부럽다. 나도 할 수 있다고 생각한다. 근데 6개월이 없다. 배포 주기가 2주다. 2주마다 리그레션 테스트. 핵심 케이스만 500개. 하루 8시간 테스트해도 모자란다. 야근하면 끝낸다. 공부할 시간은 어디서 나오나. 팀장은 말한다. "업무 시간에 조금씩 해." 조금씩? 오전엔 버그 재현. 오후엔 개발자 미팅. 저녁엔 빌드 테스트. 점심시간에 하라는 건가. 딜레마 자동화 안 배우면 도태된다. 알고 있다. 채용 공고 보면 다 Selenium 우대다. 근데 지금 당장은 매뉴얼이 필요하다. 이번 주 배포 앞뒀다. 누가 테스트하나. 자동화 공부하면 당장 일이 밀린다. 일 하면 공부할 시간 없다. 뫼비우스의 띠다. 유튜브에 'QA 자동화 전환' 검색했다. 다들 말한다. "퇴근 후 3개월만 투자하세요." 3개월. 90일. 하루 2시간이면 180시간. 해봤다. 3일 하고 포기했다. 배포 주간이었다. 3000개의 무게 3247개 테스트 케이스. 내 4년이다. 무게가 느껴진다. 이거 다 의미 있나? 80% 통과. 10% 페일. 10% 블락. 매번 비슷한 비율. 매번 비슷한 버그. Null 체크 안 함, 엣지 케이스 미처리. 이걸 자동화하면? 3시간이면 끝날 걸 3일 한다. 근데 자동화 스크립트 짜는 데 일주일 걸린다. 그럼 언제 본전이냐. 계산해봤다. 10번 돌려야 본전. 우리 앱은 2주마다 배포. 5개월 후 본전. 그때까지 스크립트 유지보수는? 현실 어제 신입이 들어왔다. 25살. 컴공 출신. "Python 할 줄 아세요?" 물어봤다. "네, 학교에서 배웠어요." 부럽다. 나는 독학이다. 유튜브랑 구글이 선생님. 신입한테 테스트 케이스 작성법 알려줬다. "이렇게 스텝 쪼개고요." "예상 결과는 이렇게 쓰고요." 설명하면서 생각했다. 이거 언제까지 하나. 30살 넘어서도 이거 하나. 점심 먹으면서 신입이 물었다. "자동화는 언제 배워요?" "나도 배우는 중이야." 거짓말이다. 배우는 중이 아니다. 배워야지 하는 중이다. 깨달은 것 3000개 쓰고 나니 안다. 양으로는 안 된다는 걸. 테스트 케이스 1만 개 써도 자동화 모르면 그냥 매뉴얼 QA다. 연봉 협상할 때 팀장이 말했다. "올해는 7% 인상입니다." "자동화 역량 키우시면 내년엔 더 드릴게요." 당근이다. 근데 당근 먹을 시간이 없다. 퇴근길 지하철에서 생각한다. 내년에도 똑같을 거다. "내년엔 더 드릴게요." 악순환 매뉴얼 테스트가 많으니 바쁘다. 바쁘니 공부 못 한다. 공부 못 하니 자동화 못 한다. 자동화 못 하니 매뉴얼이 늘어난다. 빠져나갈 구멍이 안 보인다. 커뮤니티에 물어봤다. "다들 어떻게 시간 내세요?" 답변들. "새벽에 일어나서 2시간." "주말에 8시간." "회사 그만두고 부트캠프." 새벽? 나는 12시에 잔다. 6시에 일어난다. 이미 수면 부족이다. 주말 8시간? 여자친구가 화낸다. "또 공부해?" 회사 그만두고? 월급 없으면 월세 못 낸다. 타협 결론 냈다. 완벽하게 전환은 무리다. 조금씩 섞어가자. 이번 주부터 시작했다. 하루 30분. 점심 먹고 30분. Selenium 기초 강의 듣는다. 한 강의가 20분이다. 10분은 따라 쳐본다. 일주일에 2.5시간. 한 달이면 10시간. 6개월이면 60시간. 적다. 그래도 0보단 낫다. 어제 첫 스크립트 짰다. 로그인 자동화. ID 입력, PW 입력, 로그인 버튼 클릭. 10줄짜리 코드. 돌려봤다. 됐다. 신기했다. 내가 짠 코드가 앱을 조작한다. 4년 만에 처음 느끼는 감정. 3000개의 의미 3247개가 무의미한 건 아니다. 이게 있어서 앱이 돌아간다. 이게 있어서 버그를 잡는다. 근데 여기서 멈추면 안 된다. 3000개는 시작이다. 끝이 아니다. 이 케이스들을 자동화하는 게 다음 단계. 느려도 간다. 하루 30분씩. 동료가 물었다. "자동화 언제 마스터해?" "모르겠어. 1년? 2년?" 중요한 건 시작했다는 것. 어제보다 오늘 10줄 더 안다. 내일은 20줄 알 것이다. 솔직한 고백 겁난다. 따라잡을 수 있을까. 신입들은 이미 Python 안다. 나는 4년 차인데 이제 시작. 늦은 건 아닐까. 커뮤니티에서 봤다. "30살에 개발 시작해서 시니어 됐어요." 위로가 된다. 동시에 압박이다. 나도 해야 한다. 매일 밤 생각한다. 오늘도 공부 못 했다고. 내일은 꼭 하겠다고. 내일 되면 또 핑계. "오늘 배포라서." "내일부터 시작." 이제 그만하려고. 핑계 대지 말자. 하루 30분, 무조건.3247개 테스트 케이스. 이제 3248번째는 자동화 스크립트다. 느리지만 간다.

스펙이에요, 버그예요? - QA의 영원한 의문

스펙이에요, 버그예요? - QA의 영원한 의문

스펙이에요, 버그예요? - QA의 영원한 의문 오늘도 똑같은 질문 출근했다. 커피 마시고 어제 빌드 확인. 로그인 화면에서 이메일 입력창이 있다. 근데 띄어쓰기가 들어간다. test @gmail.com 이런 식으로. 당연히 로그인 안 된다. 버그다. Jira 티켓 올리려고 했다. 근데 생각이 든다. '이거 원래 막아야 하는 거 맞나?' 스펙 문서 찾아봤다. 이메일 유효성 검사 항목이 있다. 근데 띄어쓰기에 대한 언급은 없다. 개발자한테 물어봤다. "이거 띄어쓰기 들어가는데요." "아, 그거요? 스펙에 없어서 안 막았는데요." 그렇다. 시작됐다.스펙이 명확하지 않을 때 이메일 띄어쓰기 건으로 기획자한테 물었다. "이메일에 띄어쓰기 들어가도 되나요?" "어? 그건 당연히 막아야죠." "스펙에는 없는데요." "그 정도는 당연한 거 아닌가요?" 당연한 게 어디 있나. 개발자는 스펙에 없으면 안 만든다. 기획자는 당연한 건 안 쓴다. QA는 그 사이에서 '이게 버그인지 스펙인지' 판단해야 한다. 티켓을 올렸다. 'Critical' 등급으로. 개발자가 댓글 달았다. "이거 스펙 추가 아닌가요? 원래 구현 범위 아닌데." 기획자도 댓글 달았다. "이건 기본적인 유효성 검사인데요." 나는 그 사이에서 우선순위 협의 중이다. 결국 회의가 잡혔다. 30분짜리. 결론: 버그로 등록, 다음 스프린트에서 수정. 회의 시간 30분. 구현 시간 10분. 효율적이다.'당연한 것'의 함정 QA 4년 하면서 배운 게 있다. '당연한 것'은 없다. 비밀번호 입력창에서 복사 붙여넣기가 된다. 보안상 막아야 할까? 누군 막아야 한다고 하고, 누군 편의성이라고 한다. 결제 버튼을 두 번 누르면 두 번 결제된다. 버그다. 근데 스펙에는 '중복 결제 방지' 항목이 없다. "그 정도는 당연히 막아야죠." 당연하면 스펙에 쓰든가. 검색창에서 특수문자 입력하면 앱이 죽는다. 버그 티켓 올렸다. 개발자: "서버에서 필터링하는 거 아닌가요?" 서버 개발자: "클라이언트에서 먼저 걸러주는 거 아닌가요?" 기획자: "둘 다 해야 하는 거 아닌가요?" 나: "누가 하든 일단 고쳐주세요." 결국 또 회의다. 이런 일이 하루에 세 번씩 일어난다. 스펙 문서의 현실 우리 회사 스펙 문서는 Confluence에 있다. 작성자: 기획자 최종 수정일: 2개월 전 실제 구현: 3주 전 일치율: 70% 나머지 30%는 QA가 찾아낸다. "이거 스펙이랑 다른데요?" "아, 그거 개발하면서 바꿨어요. 문서는 아직 안 고쳤네요." 그러면 나는 뭘 기준으로 테스트하나. 스펙 문서인가, 실제 구현인가, 기획자 말인가, 개발자 말인가. 정답: 전부 다 봐야 한다. 스펙 읽고, 실제 앱 써보고, 기획자한테 물어보고, 개발자한테 확인받고, 그래도 애매하면 유사 기능 참고하고, 경쟁사 앱 확인하고. 그렇게 판단한다. '이건 버그다' 또는 '이건 스펙 누락이다'애매한 경계선 가장 어려운 건 UX/UI 관련이다. 버튼을 눌렀을 때 반응 속도가 느리다. 0.8초 걸린다. 버그인가? 스펙인가? 스펙에는 "즉시 반응" 이라고만 쓰여 있다. 0.8초는 즉시인가? 기획자는 "좀 느린 것 같은데요" 한다. 개발자는 "서버 응답 기다려야 해서 어쩔 수 없어요" 한다. 나는 티켓을 올린다. "UX 개선" 등급으로. 우선순위: Low 결과: 3개월째 백로그에 있다. 또 다른 예시. 팝업 닫기 버튼이 왼쪽 위에 있다. 근데 다른 화면들은 전부 오른쪽 위다. 일관성 문제다. 버그인가? "이 화면만 디자인이 달라요." "의도된 건가요?" "글쎄요. 디자이너한테 물어볼게요." 디자이너: "어? 그거 실수인데요. 오른쪽으로 바꿔주세요." 실수였다. 그럼 버그다. 근데 이미 2주 전에 배포됐다. 아무도 신고 안 했다. 그래도 고쳐야 한다. 일관성은 중요하니까. 회색지대 판단법 4년 하면서 나름의 기준이 생겼다. 1. 사용자 관점 사용자가 이상하다고 느낄까? 느낀다 → 버그 가능성 높음 안 느낀다 → 우선순위 낮음 2. 일관성 다른 화면/기능과 다른가? 다르다 → 버그 또는 스펙 누락 같다 → 의도된 것일 수 있음 3. 비즈니스 영향 이게 돈/사용자에 영향을 주나? 준다 → Critical 안 준다 → Low 4. 재현율 항상 발생하나? 항상 → 버그 가끔 → 환경 이슈 가능성 5. 경쟁사 비교 다른 앱들은 어떻게 하나? 대부분 막음 → 우리도 막아야 할 듯 제각각 → 정답 없음 이 기준으로 판단한다. 그래도 애매하면 티켓 올리고 우선순위는 팀에서 정하게 한다. 내가 전부 판단할 순 없으니까. 개발자와의 대화 "이거 버그 같은데요." "스펙에 없는데요." "그래도 이상하지 않아요?" "스펙에 추가해주시면 해드릴게요." 이 대화를 일주일에 다섯 번은 한다. 개발자 입장도 이해한다. 스펙에 없는 걸 왜 만들어야 하나. 그건 추가 작업이니까. 하지만 QA 입장에서는 답답하다. 상식적으로 이상한 걸 왜 놔두나. 결국 기획자 불러서 스펙 추가한다. 개발자: "스펙 추가됐으니 다음 스프린트에 할게요." 나: "이번에 못 해요? Critical인데." 개발자: "이번 스프린트 이미 꽉 찼어요." 나: "배포 후에 사용자가 발견하면 어떡해요?" 개발자: "그럼 핫픽스 하죠." 핫픽스는 내가 밤새서 테스트한다. 미리 고치는 게 낫지 않나. 이 논리가 안 먹힌다. 일정이 우선이니까. 기획자와의 대화 "이거 스펙에 없는데요." "당연한 거 아닌가요?" "당연한 게 어딨어요. 명시해주세요." "그럼 스펙 문서가 너무 길어지는데요." 길어지면 어때. 명확한 게 중요하지. 기획자는 큰 그림을 그린다. 세부사항은 '알아서' 하는 거라고 생각한다. 하지만 개발은 명시된 것만 만든다. 그 사이 갭을 QA가 메운다. "이 경우는 어떻게 해요?" "이 경우는 안 쓰여 있는데요." "에러 메시지는 뭘로 해요?" "로딩 시간이 길면 어떻게 해요?" 전부 물어봐야 한다. 안 물어보면 나중에 버그가 된다. 실제 사례: 로그인 타임아웃 최근에 겪은 일이다. 로그인 API 타임아웃이 30초로 설정됐다. 스펙에는 "로그인 실패 시 에러 메시지 표시" 라고만 있다. 30초 동안 로딩만 돈다. 아무 메시지도 없다. 사용자는 앱이 죽은 줄 안다. 버그 티켓 올렸다. 개발자: "타임아웃은 서버 설정이에요. 클라이언트는 응답 기다리는 거고요." 나: "30초는 너무 긴데요. 사용자가 기다릴까요?" 개발자: "서버팀한테 말해보세요." 서버 개발자: "30초는 표준이에요. 네트워크 느릴 수 있으니까." 나: "그럼 중간에 로딩 메시지라도 보여주면 안 될까요?" 기획자: "좋은 생각이네요. 스펙에 추가할게요." 2주 후 적용됐다. "로그인 중입니다... 잠시만 기다려주세요." 이게 없었으면 사용자는 앱 끄고 재설치했을 거다. 이런 게 스펙에 없었다. 당연하지 않았나? 당연하지 않다. 누군가 생각하고 제안해야 한다. 그게 QA 일이다. 버그 vs 스펙 판단 기준표 내가 만든 체크리스트다. 명확한 버그:앱이 죽음 데이터 유실 보안 문제 스펙 문서와 다름 이전 버전에서 됐는데 안 됨스펙 누락:엣지 케이스 미처리 에러 케이스 없음 일관성 문제 UX 불편함 경쟁사는 다 하는데 우리만 안 함애매한 영역:성능 (얼마나 빨라야 빠른가?) 디자인 (얼마나 예뻐야 예쁜가?) 편의성 (꼭 필요한가?) 우선순위 낮은 버그애매한 건 팀 논의로 간다. 혼자 판단하려 하지 않는다. 책임 분산도 중요하니까. QA가 해야 할 일 명확하지 않은 요구사항이 오면 QA가 해야 할 일: 1. 재현 가능한지 확인 이게 항상 발생하나? 특정 조건에서만 발생하나? 재현 스텝을 명확히 한다. 2. 스펙 문서 확인 문서에 뭐라고 나와 있나? 없으면 유사 기능 찾는다. 3. 기획자에게 질문 "이 경우는 어떻게 의도하신 건가요?" 예/아니오로 답할 수 있게 구체적으로 묻는다. 4. 개발자에게 확인 "기술적으로 가능한가요? 얼마나 걸리나요?" 일정과 난이도를 파악한다. 5. 우선순위 제안 Critical / High / Medium / Low 비즈니스 영향과 사용자 경험을 고려해서 제안한다. 6. 티켓 등록 재현 스텝, 스크린샷, 로그, 기대 동작, 실제 동작 명확하게 쓴다. 추가 질문 없게. 이게 루틴이다. 하루에 이런 판단을 10번은 한다. 스펙 명확화 요청 요즘은 아예 스펙 리뷰를 미리 한다. 기획 단계에서 QA도 참여한다. "이 경우는요?" "저 경우는요?" "에러는요?" "로딩은요?" 처음엔 기획자가 귀찮아했다. "그건 개발하면서 정하면 되죠." 안 된다. 개발하면서 정하면 전부 버그가 된다. 지금은 기획자도 인정한다. "QA 리뷰 안 거치면 나중에 티켓 폭탄 맞아요." 맞다. 미리 물어보는 게 서로 편하다. 스펙이 명확하면 개발도 빠르고, 테스트도 명확하고, 버그도 줄어든다. Win-win이다. 판단의 책임 가끔 생각한다. 내가 '이건 버그 아니에요' 라고 판단했는데, 배포 후에 사용자가 불편해하면? 내가 '이건 Critical이에요' 라고 했는데, 실제론 아무도 신경 안 쓰면? 판단의 책임이 무겁다. 틀릴 수도 있다. 나도 사람이니까. 그래서 중요한 건 기록이다. "기획자에게 확인했으나 스펙 외라고 판단" "개발팀과 논의 후 우선순위 Low로 조정" "사용자 시나리오상 발생 가능성 낮음" 근거를 남긴다. 나중에 문제되면 그때 다시 논의한다. 완벽한 판단은 없다. 최선의 판단만 있을 뿐. 개발자가 이해하는 날 신기한 경험을 했다. 개발자가 먼저 물어봤다. "민수님, 이거 어떻게 생각하세요? 버그 같긴 한데 스펙에는 없거든요." 오. 개발자도 이제 안다. 스펙에 없다고 다 아닌 건 아니라는 걸. "그거 버그 맞죠. 사용자 불편할 것 같은데요." "그쳤죠? 제가 미리 고쳐놨어요. 다음 빌드에 들어가요." 감동이다. 4년 만에 개발자가 먼저 버그를 판단했다. 협업의 승리다. 서로 이해하는 데 4년 걸렸다. 기획자가 변하는 날 최근 기획서를 받았다. 놀랐다. 엣지 케이스가 전부 적혀 있다. "입력값이 100자 초과 시 에러 메시지: '100자 이내로 입력해주세요'" "네트워크 끊김 시: 재시도 버튼 표시" "로딩 3초 이상 시: 로딩 메시지 변경" 완벽하다. 기획자한테 물었다. "갑자기 왜 이렇게 자세히 쓰셨어요?" "매번 민수님이 물어보시잖아요. 미리 쓰는 게 빠르더라고요." 그렇다. 협업은 서로 배우는 거다. 나도 배웠고, 팀도 배웠다. 이제 '스펙이에요 버그예요?' 질문이 조금 줄었다. 조금만. 여전히 애매한 것들 그래도 여전히 애매한 게 있다. "이 애니메이션 자연스러워요?" 자연스러움은 주관이다. "이 색깔 괜찮아요?" 색깔은 취향이다. "이 문구 이상하지 않아요?" 어감은 사람마다 다르다. 이런 건 여러 명이 봐야 한다. 디자이너, 기획자, 개발자, QA 전부 의견 내고, 최종 결정은 PM이 한다. 그래도 배포 후에 누군가는 불만이다. 완벽한 제품은 없다. 최선을 다할 뿐. 배포 후 발견되는 것들 조심스럽게 배포했다. 테스트 다 했다. 2주 후 고객센터에서 연락 왔다. "OO 상황에서 앱이 이상하게 동작한다는 문의가 들어왔어요." 재현해봤다. 진짜다. 버그다. 근데 테스트 때는 안 나왔다. OO 상황이 테스트 시나리오에 없었다. 스펙에도 없었다. 기획자도 생각 못 했다. 사용자는 우리가 생각 못 한 방식으로 쓴다. 그게 현실이다. 핫픽스 들어갔다. 밤샘했다. 이럴 때마다 생각한다. '내가 놓쳤나?' 아니다. 우리 모두 놓쳤다. 함께 놓친 건 함께 책임진다. 그게 팀이다. 4년 차 QA의 결론 '스펙이에요 버그예요?' 이 질문은 앞으로도 계속될 거다. 명확한 답이 없는 경우가 많으니까. 하지만 4년 하면서 배운 건: 판단은 혼자 하는 게 아니다. 기획자, 개발자, 디자이너, PM 모두 함께 판단한다. QA는 그 과정을 촉진하는 사람이다. 질문하고, 확인하고, 기록하고, 제안한다. 틀릴 수도 있다. 괜찮다. 다시 논의하면 된다. 완벽한 스펙은 없다. 스펙은 계속 보완된다. 개발하면서, 테스트하면서, 출시하면서. 그 과정에서 QA가 많은 걸 발견한다. 사용자 관점이 답이다. 애매하면 사용자 입장에서 생각한다. 불편한가? 이상한가? 위험한가? 그게 기준이다. 오늘도 질문한다. "이거 스펙인가요, 버그인가요?" 대답은 회의실에서 나온다. 그게 QA의 일상이다.내일도 누군가는 물을 거다. "이거 버그 맞죠?" 나는 대답할 거다. "회의 잡을게요."

Jira 티켓 200개, 어디부터 시작해야 할까?

Jira 티켓 200개, 어디부터 시작해야 할까?

월요일 아침의 선물 출근했다. Jira 열었다. 미해결 티켓 203개. 금요일에 180개였는데. 주말 사이 23개가 더 생겼다. 핫픽스 배포했다가 새 버그가 나온 거다. 예상했다. 커피 한 잔 마시고 화면을 봤다. P1, P2, P3, P4가 뒤섞여 있다. 어떤 건 상태가 "재확인 필요", 어떤 건 "개발 완료 대기". 정리 안 된 티켓이 반은 넘는다. 팀장이 슬랙 보냈다. "민수야, 이번 주 목표 티켓 30개 처리. 가능하지?" 30개. 하루에 6개씩이다. 재현 시간, 확인 시간, 리포트 작성 빼면 불가능하다. 하지만 "네" 라고 답장했다. 어차피 할 거니까.우선순위라는 이름의 정치 P1부터 봤다. 41개다. 심각도 높음, 긴급 처리. 그런데 진짜 긴급한 건 10개도 안 된다. 나머지는 누군가 급하다고 우긴 것들이다. "로그인 안 됨" - P1 맞다. "프로필 이미지 안 뜸" - P2인데 기획자가 P1 박았다. "특정 기종에서 폰트 이상" - P3이다. 근데 대표님 폰이라서 P1. 우선순위는 기술적 판단이 아니다. 정치다. 개발팀장은 자기 팀 버그는 P3로 낮추고 싶어 한다. 기획팀은 자기가 만든 기능 버그는 P1로 올리고 싶어 한다. 영업팀은 클라이언트가 말한 건 뭐든 P1이다. 결국 내가 판단해야 한다. 실제 사용자 영향도로. 기준을 만들었다. 엑셀에 정리했다. P1 (10개)앱 크래시 핵심 기능 동작 안 함 데이터 손실 가능성 보안 이슈P2 (35개)주요 기능 오작동 특정 기종 크래시 UI 심각하게 깨짐 결제 관련 오류P3 (98개)부가 기능 오류 텍스트 오타 디자인 의도와 다름 특정 상황에서만 재현P4 (60개)개선 제안 극히 드문 케이스 차기 버전 고려 스펙 논의 필요재분류했다. 기획자한테 메신저 왔다. "민수님, 제가 P1 올린 건데요?" "사용자 영향도 낮아서 P2로 조정했습니다." "근데 팀장님이 중요하다고 하셨거든요." "팀장님께 제가 말씀드릴게요." 이런 대화를 5번 했다. 점심 전에.현실적인 처리 계획 10개 P1부터 시작했다. 하지만 순서가 있다. 재현 가능한 것부터다. "특정 조건에서 크래시" - 재현 스텝 불명확. 개발자한테 물어봐야 함. 나중. "로그인 실패" - 바로 재현 가능. 지금. "결제 오류" - QA 서버에서 테스트 가능. 지금. 엑셀에 컬럼 추가했다.재현 가능 여부 예상 소요 시간 의존성 (다른 티켓이나 개발자 답변 필요) 테스트 환경 (Dev/QA/Prod)P1 10개 계획 세웠다.즉시 처리 가능: 4개 (2시간) 개발자 확인 필요: 3개 (대기 후 1시간) 특수 환경 필요: 2개 (내일 오전) 재현 불가: 1개 (리포터 추가 정보 요청)4개부터 시작했다. 첫 번째 버그. 로그인 화면에서 백버튼 누르면 크래시. 재현했다. Charles로 네트워크 확인했다. API 응답은 정상. 앱 로그 확인. Null Pointer Exception. 스크린샷 3장, 로그 파일, 재현 스텝 정리해서 Jira 업데이트. 개발자 assign. 20분 걸렸다. 두 번째 버그. 결제 완료 후 화면 멈춤. 재현 안 됨. QA 서버에서는. Prod에서만 발생한다는 리포트. 운영팀한테 Prod 로그 요청. 대기. 세 번째로 넘어갔다. 효율이다. 막힌 건 넘어가고 진행 가능한 것부터. 하루 종일 한 티켓만 붙잡고 있을 수 없다. 오후 3시. P1 4개 처리했다. P2 시작했다.리소스 관리의 현실 하루에 처리 가능한 티켓 수는 정해져 있다. 단순 계산. 근무 8시간.회의 1시간 점심 1시간 이메일/슬랙 응대 1시간 실제 작업 시간 5시간버그 하나당 평균 소요 시간.재현: 15분 원인 파악: 20분 리포트 작성: 15분 개발자 커뮤니케이션: 10분 총 60분하루 5개가 현실적이다. 근데 예상 밖 변수가 있다.재현 안 되는 버그: +30분 디바이스 세팅 시간: +20분 긴급 이슈 터짐: +1시간 기획 스펙 확인: +30분실제로는 하루 3-4개다. 주 5일이면 15-20개. 팀장이 원하는 30개가 안 된다. 솔직하게 말했다. "30개는 어렵습니다. 현실적으로 20개 목표 잡겠습니다." "왜 안 돼?" "평균 처리 시간이 1시간인데, 예상 외 이슈 대응 시간 빼면 하루 4개가 한계입니다." "야근하면 되지 않아?" "야근해도 집중력 떨어지면 버그 놓칩니다. 그럼 배포 후 더 큰 문제 됩니다." 팀장 표정이 안 좋았다. 하지만 인정했다. "알았어. 20개 목표로 하자." 숫자로 말하니까 통했다. 감정이 아니라 데이터로. 배치의 기술 200개를 20개씩 나눴다. 10주 걸린다. 현실성 없다. 그 사이 새 티켓이 100개는 더 생긴다. 다른 방법이 필요하다. 배치 처리. 비슷한 버그끼리 묶었다. 로그인 관련 (8개)한 번에 테스트 환경 세팅 연속으로 처리하면 컨텍스트 스위칭 없음 2시간 안에 끝결제 플로우 (12개)QA 서버 결제 테스트 계정 필요 한 번에 몰아서 테스트 3시간UI 버그 (25개)디바이스별 확인 스크린샷 찍으면서 체크리스트 2시간특정 기종 이슈 (15개)해당 디바이스 세팅 한 번만 4시간월요일: 로그인 + 회원가입 관련 화요일: 결제 플로우 수요일: UI 버그 집중 목요일: 특정 기종 테스트 금요일: 긴급 이슈 대응 + 정리 효율이 올라갔다. 컨텍스트 스위칭이 줄었다. 테스트 환경 세팅을 반복 안 해도 됐다. 첫 주에 23개 처리했다. 목표보다 3개 더. 커뮤니케이션 비용 버그 처리보다 시간 많이 드는 게 있다. 설명이다. 개발자: "이거 재현 안 되는데요?" 나: "재현 스텝 Jira에 있습니다." 개발자: "그대로 했는데 안 돼요." 나: "화면 공유 해드릴까요?" 개발자: "네." 화면 공유 10분. 재현 보여줌. 개발자: "아 제 빌드가 달라서 그런가 봐요." 나: "..." 이런 일이 하루에 5번. 그래서 리포트 양식 만들었다. [재현 스텝] 1. 앱 실행 2. 로그인 (테스트 계정: qa_test01) 3. 마이페이지 진입 4. 프로필 수정 버튼 탭 5. 닉네임 입력 (20자 이상) 6. 저장 버튼 탭 → 크래시 발생[환경] - 빌드: v2.3.1 (build 451) - OS: Android 13 - 기기: Galaxy S23 - 서버: QA 서버[로그] (첨부)[기대 동작] 닉네임 저장 후 완료 토스트 메시지[실제 동작] 앱 크래시, 재실행 시 닉네임 변경 안 됨[추가 정보] iOS에서는 정상 동작 확인이렇게 쓰니까 "재현 안 돼요" 가 줄었다. 하지만 여전히 질문은 온다. 기획자: "이거 버그예요 스펙이에요?" 나: "스펙 문서에는 A인데 실제는 B입니다." 기획자: "음... 원래 B가 맞는 것 같은데." 나: "그럼 스펙 문서 수정해주세요." 기획자: "네, 근데 이미 개발된 거 바꾸기 애매한데..." 이런 대화 20분. 결론은 "다음 회의 때 논의". 티켓 상태를 "Pending - 스펙 확인 중"으로 바꿨다. 내 할 일 목록에서 뺐다. 안 그러면 계속 신경 쓰인다. 포기의 기술 200개를 다 할 수 없다는 걸 인정했다. P4 60개는 사실상 안 한다. "차기 버전 검토" 라벨 붙이고 백로그로 보냈다. P3 중에서도 "재현 불가" 30개는 "추가 정보 필요" 상태로 리포터한테 돌려보냈다. 1주일 안에 답 안 오면 자동 종료. 실제 처리 대상은 110개. 이것도 많다. 하지만 200개보다 심리적으로 낫다. 팀장한테 보고했다. "P4 60개는 다음 분기로 이관하겠습니다." "왜?" "리소스 대비 사용자 영향도가 낮습니다. 대신 P1, P2를 2주 안에 정리하겠습니다." "음... 알았어." 전부 다 하려고 하면 중요한 것도 못 한다. 포기할 걸 정하는 것도 능력이다. 진행 상황 추적 매일 아침 30분. 엑셀 업데이트했다. [주간 목표] 목표: 20개 완료: 23개 진행중: 5개 블록: 3개[티켓 상태] Open: 176개 (203→176, -27) In Progress: 8개 Pending: 12개 Resolved: 15개 (이번 주)숫자가 보이니까 뿌듯했다. 203에서 176. 한 주만에 27개 줄었다. 물론 새로 생긴 것도 있다. 하지만 처리 속도가 더 빠르다. 팀장한테 주간 리포트 보냈다. 슬랙에 공유했다. 개발팀장이 답했다. "오 민수님 고생 많으시네요." 인정받는 기분. 나쁘지 않다. 자동화의 유혹 P3 중에 반복 작업이 많다. "5개 기종에서 UI 확인" - 30분씩 5번, 2시간 반. "20개 화면 레이아웃 체크" - 1시간. 자동화하면 30분으로 줄어든다. 문제는 자동화 스크립트 짜는 데 5시간 걸린다는 거다. 계산했다. 이 테스트를 앞으로 10번 이상 할 거면 본전이다. UI 회귀 테스트는 매 배포마다 한다. 2주에 한 번. 1년이면 26번. 투자 가치 있다. 퇴근 후 집에서 Appium 튜토리얼 봤다. 2시간. 간단한 스크립트 짰다. 5개 화면 자동 캡처. 1시간 걸렸다. 아직 완벽하지 않다. 하지만 시작했다. 다음 주부터 하나씩 자동화 케이스 늘리기로 했다. 실전 팁 200개 티켓 앞에서 멘붕 안 오려면. 1. 일단 분류부터 우선순위 재조정. 30분 투자해서 전체 보기. 2. 배치 처리 비슷한 것끼리 묶어서. 컨텍스트 스위칭 줄이기. 3. 블로킹 이슈 따로 관리 진행 안 되는 건 Pending 처리. 내 리스트에서 빼기. 4. 매일 목표 작게 하루 5개. 달성 가능한 숫자. 5. 숫자로 추적 엑셀이든 뭐든. 진행 상황 시각화. 6. 커뮤니케이션 효율화 리포트 템플릿. 반복 질문 줄이기. 7. 포기할 것 정하기 P4는 과감히 백로그로. 집중력 분산 방지. 8. 자동화 조금씩 반복 작업부터. 5시간 투자해서 20시간 아끼기. 한 달 후 4주 지났다. Jira 티켓 128개. 203에서 75개 줄었다. 물론 새로 생긴 것도 있다. 하지만 관리 가능한 수준이다. 팀장이 말했다. "민수야, 이번 달 티켓 처리율 좋던데?" "네, 배치 처리 방식 바꿔서요." "다른 팀원들도 좀 공유해줘." 오후에 팀 회의. 내 방법 설명했다. 15분. 신입 QA가 물었다. "그럼 우선순위는 누가 정해요?" "우리가 정해야죠. 사용자 영향도 기준으로." "근데 기획팀에서 P1 올리면요?" "데이터로 설명하세요. 사용자 몇 명한테 영향 가는지, 얼마나 자주 발생하는지." 신입이 고개 끄덕였다. 회의 끝나고 슬랙에 정리 문서 공유했다. 내가 쓴 엑셀 템플릿이랑 우선순위 기준표. 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는 안 그만둔다. 이게 내 일이다. 자부심 있다.야근 수당은 숫자다. 자존감은 선택이다. 나는 후자를 택했다.

금요일 오후 5시 59분, 배포 요청이 들어왔다

금요일 오후 5시 59분, 배포 요청이 들어왔다

5시 59분 금요일 오후 5시 59분. 슬랙이 울렸다. "민수님, 급한 배포 건이 있어서요. 월요일 아침까지 올려야 해요." 기획팀 김과장이다. 배포는 내일 토요일 오전 10시래. 내일. 10시. 지금부터 15시간.무슨 변경인데 "어떤 기능이요?" "결제 플로우 일부 수정이요. UX 개선." 결제. 플로우. 가장 건드리면 안 되는 부분이다. "스펙 문서 있어요?" "아, 지금 정리 중이에요. 30분 뒤에 드릴게요." 30분. 6시 30분이면 된다는 거다. 개발은 언제 끝나냐고 물었다. "밤 10시쯤요? 늦어도 11시?" 밤 11시. 그럼 테스트 시작은 자정. 토요일 새벽부터 오전 10시까지. 10시간. 결제 플로우 전체를 10시간 안에. 계산 책상 앞에 앉았다. 계산기를 켰다. 결제 테스트 케이스: 총 147개. 풀 테스트하면 8시간. 리그레션까지 하면 12시간. 시간이 4시간 부족하다. 범위를 줄여야 한다. 어디를.스펙 문서 7시 10분. 스펙이 왔다. 40분 늦었다. 열어봤다. 4페이지. "결제 버튼 위치 변경" "카드 선택 UI 개선" "쿠폰 적용 로직 수정" 로직 수정? "쿠폰이랑 포인트 동시 사용 가능하게" 이건 단순 UI가 아니다. 비즈니스 로직이다. 쿠폰, 포인트, 할인율, 최종 금액. 경우의 수가 몇 개지. 쿠폰 3종류, 포인트 전액/일부, 상품 할인... 최소 20개 케이스. 개발자 호출 개발팀 이대리한테 전화했다. "대리님, 쿠폰이랑 포인트 동시 사용. 테스트 어디까지 해야 돼요?" "음... 일단 정상 케이스만요. 시간 없잖아요." 정상 케이스만. "근데 쿠폰 여러 개 적용은요?" "아, 그건 원래 안 되는 거라 괜찮아요." 원래 안 되는 게 괜찮다는 게 아니라, 이번에 안 건드렸다는 거다. "포인트 부족하면요?" "그것도 기존 로직 그대로요." 기존 로직. 그럼 새로 테스트 안 해도 되나. "근데 화면은 바뀌잖아요." "네, 화면만요." 화면만. 그래도 확인은 해야 한다. 범위 결정 화이트보드에 적었다. 필수:쿠폰+포인트 동시 사용 (정상) 결제 버튼 위치 확인 카드 선택 UI 동작준필수:포인트 부족 시나리오 쿠폰 단독 사용 최종 금액 계산 검증제외:쿠폰 여러 개 조합 배송지 변경 (이번 건 무관) 리워드 적립 (서버 로직, 별도)제외 항목을 보니 불안하다. 배송지는 정말 무관할까. 최종 금액이 배송비에 영향 주지 않나.PM한테 물었다 "배송비 로직은 변경 없죠?" 기획팀 김과장이 답했다. "네, 그건 안 건드렸어요." "확실해요?" "...개발팀한테 확인할게요." 5분 뒤. "아, 배송비 무료 조건이 '할인 전 금액' 기준으로 바뀌었대요." 바뀌었다고. "그럼 쿠폰 쓰면 배송비 나올 수 있다는 거네요?" "네... 그렇네요?" 그렇네요가 아니다. 테스트 케이스 15개 추가다. 8시 30분 여자친구한테 문자 왔다. "저녁 먹자. 치킨?" "오늘 야근. 미안." "또? 금요일인데." "배포." "배포가 뭐길래 매번." 설명할 기운이 없다. "내일 저녁에. 내가 살게." "...ㅇㅇ" ㅇㅇ. 화났다는 거다. 빌드 대기 밤 10시. 빌드를 기다렸다. 개발팀 단톡방을 봤다. "빌드 언제 나와요?" "조금만요. 충돌 해결 중." "11시는 될 것 같아요." 11시. 또 늦는다. 컵라면을 끓였다. 사무실 비상 재고. 매운 맛. 밤샘할 때 먹는 맛. 11시 47분 빌드가 올라왔다. 바로 다운로드. 설치. 앱 실행. 로그인. 상품 담기. 결제 화면 진입. UI가 바뀌었다. 버튼 위치가 아래로. 카드 선택 탭이 깔끔해졌다. 쿠폰 선택. 포인트 입력. 최종 금액 확인. 정상이다. 첫 번째 케이스 통과. 시간은 자정 넘어 12시 3분. 두 번째 케이스 포인트만 사용. 쿠폰 없이. 결제 진행. "오류가 발생했습니다." 터졌다. 재현해봤다. 또 터진다. 찰스 프록시 켰다. 로그 확인. "couponId: null" null을 못 받는다. 개발팀 단톡에 올렸다. "포인트만 쓰면 에러나요. couponId null 처리 안 됨." 이대리가 답했다. "아... 수정할게요. 30분?" 새벽 1시에 30분. 1시 30분이면 다시 빌드. 대기 시간 책상에 엎드렸다. 30분. 잘 수는 없다. 테스트 케이스를 다시 봤다. 우선순위를 재조정했다. null 처리 버그. 심각도 높음. 다른 곳에도 있을까. 배송지 null, 카드 정보 null, 쿠폰 코드 invalid... 체크리스트를 만들었다. Null/Empty 체크:쿠폰 미선택 포인트 0원 배송 메모 없음 카드 없을 때전부 확인해야 한다. 2시 10분 빌드가 또 올라왔다. 1시 30분 약속은 지켰다. 다시 설치. 로그인. 포인트만 사용. 테스트. 통과. 쿠폰만 사용. 통과. 둘 다 사용. 통과. 쿠폰+포인트+배송비. 금액 계산 확인. 9,800원 상품. 2,000원 쿠폰. 3,000원 포인트. 결과: 4,800원 + 배송비 3,000원. 맞다. 근데 할인 전 금액 기준 배송비 무료는 10,000원부터. 9,800원은 300원 모자라니까 배송비 나온다. 이게 맞나. 유저는 혼란스러울 것 같은데. PM한테 물었다 새벽 2시 30분에 슬랙을 보냈다. "배송비 무료 기준이 할인 전 금액이면, 9,800원 상품에 쿠폰 써도 배송비 나와요. 의도 맞아요?" 답이 없다. 당연하다. 잘 시간이다. 기획 의도를 모르겠으면 테스트를 어떻게 하나. 일단 버그는 아니니까 통과 처리. 이슈로 남겼다. "배송비 정책 UX 혼란 가능성 있음. 기획 검토 필요." 3시 47분 결제 완료까지 갔다. 주문 내역 확인. 정상. 쿠폰 차감됨. 포인트 차감됨. 리워드 적립. 확인. 여기까지 8개 케이스 완료. 남은 건 7개. 배송지 변경 케이스, 카드 여러 개 케이스, 할부 개월 수... 눈이 감긴다. 커피를 마셨다. 네 번째. 결제 취소 환불 테스트를 시작했다. 쿠폰 쓴 주문 취소. 쿠폰 복구돼야 함. 취소 완료. 쿠폰함 확인. 없다. 쿠폰이 안 돌아왔다. 다시 해봤다. 또 안 돌아온다. 심각하다. 단톡에 올렸다. "결제 취소 시 쿠폰 복구 안 됨. Blocker." 4시 21분 개발자가 답했다. 이대리가 아니라 팀장이다. "확인했습니다. 수정 중. 5시까지." 5시. 배포까지 5시간 남았다. 5시 13분 빌드 올라왔다. 다시 테스트. 쿠폰 결제. 취소. 쿠폰함 확인. 돌아왔다. 포인트도 확인. 정상. 통과. 남은 케이스 6개. 시간은 5시간. 할 수 있다. 7시 카드 할부 케이스 테스트 중. 3개월 할부. 정상. 6개월. 정상. 12개월. 금액 계산 이상함. 수수료가 두 번 붙었다. 또 버그다. 심각도는 중간. Blocker는 아니다. 12개월 할부 쓰는 사람 많지 않음. 하지만 금액 오류는 민감하다. 올렸다. "12개월 할부 수수료 중복 계산." 답이 없다. 아직 개발팀이 안 왔다. 8시 40분 개발팀이 출근했다. 이대리가 단톡 확인했다. "12개월 할부 버그는 배포 후 핫픽스 가능할까요?" 가능할까요가 아니라. PM이 답했다. "일단 배포하고 다음 주에 수정해요." 다음 주. 유저가 12개월 할부 쓰면 손해 본다. 그냥 배포한다고. 9시 20분 남은 케이스 2개. 배송 메모 특수문자, 긴 텍스트. 둘 다 통과. 테스트 완료. 총 15개 케이스. 버그 3건. Blocker 1건 수정 완료. 중간 심각도 1건 다음 주 수정. 낮은 심각도 1건 이슈 등록. 배포 승인 PM한테 보고했다. "테스트 완료. 배포 가능합니다. 단, 12개월 할부 버그 있음. 다음 주 수정 예정." "고생하셨어요. 10시에 배포 진행할게요." 고생하셨어요. 15시간 일하고 듣는 말. 10시 배포 앱스토어에 올라갔다. 배포 완료. 모니터링 시작. 슬랙, 센트리, 파이어베이스 크래시 리포트. 에러 없다. 30분 지났다. 아직 조용하다. 1시간. 여전히 조용하다. 다행이다. 11시 30분 집에 왔다. 샤워하고 침대에 누웠다. 여자친구한테 문자 보냈다. "끝났어. 저녁 먹자. 7시?" 답이 바로 왔다. "ㅇㅇ 어디?" 아직 화났나. "네가 고르면 내가 살게." "그럼 스테이크." 비싸다. 근데 어쩔 수 없다. "ㅇㅇ" 월요일 출근했다. 슬랙에 알림 하나. CS팀이다. "결제 관련 문의 들어왔어요. 12개월 할부 금액이 이상하대요." 시작됐다. 개발팀 단톡에 포워딩했다. "금요일에 리포트한 버그입니다. 수정 일정 알려주세요." 이대리가 답했다. "오늘 수정해서 내일 배포 가능해요." 내일 배포면 내가 또 테스트한다.금요일 5시 59분. 그 1분이 주말을 날렸다. 근데 배포는 성공했다. 그게 다행인 건가, 불행인 건가. 모르겠다.