Showing Posts From

Pm

릴리즈 전야의 야근, 피할 수 없다면 준비하자

릴리즈 전야의 야근, 피할 수 없다면 준비하자

릴리즈 전야의 야근, 피할 수 없다면 준비하자 수요일 밤 11시, 슬랙이 울렸다 집에 도착한 지 20분. 샤워하고 치킨 시켰다. 슬랭 알림이 울렸다. "K님, 결제 모듈에서 이상한 버그 발견했어요." 금요일 오전 10시 릴리즈다. 내일 목요일은 QA 최종 점검 날이다. 오늘 안 잡으면 릴리즈 미룬다. 치킨은 식었다. 노트북 켰다. 예상 못한 버그는 항상 릴리즈 전에 온다.우선순위부터 판단한다 패닉하면 진다. 지라 티켓부터 만들었다. 우선 버그 정도를 확인한다.Critical: 서비스 불가능. 결제 안 됨. 회원가입 막힘. High: 주요 기능 오작동. 데이터 꼬임. 보안 이슈. Medium: 불편하지만 우회 가능. UI 깨짐. 로딩 느림. Low: 있으면 좋지만 없어도 됨. 오타. 디자인 미세 틀어짐.이번 건은 High였다. 특정 카드사에서 결제 실패. 재현율 30%. 금액이 10만원 넘으면 발생. Critical은 아니다. 다른 카드 쓰면 된다. 하지만 High는 맞다. 고객 불편 크다. 릴리즈 연기 vs 핫픽스 판단 금요일 릴리즈를 미루면?마케팅팀이 준비한 캠페인 날아감. 2주 스프린트 일정 전체 밀림. 다른 팀 일정까지 영향.핫픽스로 가면?내일 QA 시간 부족. 또 다른 버그 나올 위험. 개발자 야근 확정.30초 고민했다. CTO한테 슬랙 날렸다. "오늘 밤에 잡고, 내일 오전 집중 QA 하는 게 어떨까요? 릴리즈는 금요일 오후 3시로 미루고요." 5분 뒤 답왔다. "ㄱㄱ" 결정 끝.이슈 트래킹 체크리스트 야근할 거면 효율적으로 한다. 지라 티켓에 템플릿이 있다. 1. 버그 재현 조건 명확히 개발자가 제일 싫어하는 말. "어? 아까는 됐는데요?" 재현 조건을 구체적으로 적었다.디바이스: iOS 15.6, Safari 계정: 테스트 계정 3개로 확인 카드사: A카드, B카드 (C카드는 정상) 금액: 100,000원 이상 재현율: 10번 중 3번영상도 찍었다. Loom으로 화면 녹화. 슬랙에 공유. 2. 로그 확인 센트리 들어갔다. 에러 로그 3건. 전부 같은 API. payment_gateway_error: card_validation_failed timestamp: 23:14:32 user_id: test_user_03 amount: 150000개발자한테 이거 캡처해서 보냈다. "이거랑 관련 있을 것 같아요." 3. 영향 범위 체크 이 버그가 다른 기능에도 영향 주는지 확인했다.일반 결제: 정상 정기 결제: 정상 환불: 정상 부분 취소: 미확인 (내일 체크)영향 범위가 좁다. 다행이다. 4. 우회 방안 준비 만약 금요일까지 못 잡으면? 고객센터 공지 준비했다. "현재 일부 카드사에서 10만원 이상 결제 시 오류가 발생할 수 있습니다. 다른 카드를 이용하시거나 고객센터로 연락 주시면 도와드리겠습니다." 최악의 시나리오도 준비. 항상 플랜 B는 있어야 한다.커뮤니케이션이 반이다 야근할 때 제일 중요한 거. 커뮤니케이션이다. 개발팀 리드한테 먼저 연락 PM이 아니라 개발 리드한테 먼저 물었다. "오늘 밤에 이거 잡을 수 있을까요? 솔직하게 말씀해주세요." "3시간 정도면 될 것 같은데, 확실하진 않아요." "그럼 자정까지 해보시고, 안 되면 내일 오전으로 미뤄도 돼요. 무리하지 마세요." 개발자를 믿는다는 신호를 줬다. 압박하면 역효과다. 이해관계자 정리 슬랙 채널에 상황 공유했다. [긴급] 릴리즈 일정 변경 안내- 버그 발견: 결제 모듈 (High 우선순위) - 조치: 오늘 밤~내일 오전 수정 - QA: 내일 오전 집중 진행 - 릴리즈: 금요일 10시 → 15시로 변경 - 영향: 마케팅 캠페인 시간 조정 필요죄송합니다. 내일 아침 9시에 상황 업데이트 드리겠습니다.마케팅팀에서 답왔다. "오케이, 캠페인 3시 이후로 조정할게요." 디자이너는 이모지만 달았다. 👍 상황을 투명하게 공유하면 다들 이해한다. 숨기려고 하면 불신만 쌓인다. 진행 상황 주기적 업데이트 자정에 개발자한테 물었다. "어떻게 되고 있어요?" "70% 정도 왔어요. 1시간 더 하면 될 것 같아요." 1시에 또 물었다. "거의 다 왔어요. 로컬에서는 재현 안 되네요. 스테이징에 배포해볼게요." 1시 반에 슬랙 왔다. "배포 완료. 테스트 부탁드려요." 테스트 10번 돌렸다. 전부 정상. "완벽해요. 고생하셨습니다." 개발자는 이미 퇴근했다. 나도 노트북 덮었다. 새벽 2시. 치킨은 차가웠지만 기분은 좋았다. 야근 이후 할 일 다음 날 목요일. 9시에 출근했다. 회고 미팅 30분 개발팀이랑 간단히 회고했다. "왜 이 버그가 늦게 발견됐을까?"테스트 케이스에 10만원 이상 시나리오 없었음. 특정 카드사 테스트 계정 부족."다음엔 어떻게 하면 좋을까?"경계값 테스트 케이스 추가. 카드사별 테스트 계정 확보. 결제 모듈은 스테이징 배포 후 1일 대기 후 릴리즈.비난하지 않았다. 프로세스를 개선하는 데 집중했다. 지라 티켓 정리 버그 티켓을 닫기 전에 문서화했다.버그 내용 재현 조건 원인 분석 (개발자가 작성) 해결 방법 재발 방지책다음에 비슷한 일 생기면 참고한다. 지라는 우리 팀의 기억이다. 팀에게 감사 표현 슬랙에 메시지 남겼다. "어제 밤 고생하신 민수님, 정말 감사합니다. 덕분에 일정 지킬 수 있었어요. 점심 제가 쏠게요." 작은 것 같지만 중요하다. 야근은 당연한 게 아니다. 그리고 팀 전체에도. "모두 빠른 대응 감사합니다. 금요일 릴리즈 무사히 하고 회식 가시죠." 분위기가 풀렸다. 야근을 줄이는 방법 사실 야근은 안 하는 게 최선이다. 매번 야근하면 번아웃 온다. 릴리즈 일정에 버퍼 둔다 나는 이제 릴리즈 2일 전에 개발 완료를 잡는다.월요일~수요일: 개발 목요일: QA 금요일: 버퍼 + 최종 체크 다음 주 월요일: 릴리즈금요일에 버그 나와도 여유 있다. 중요한 기능은 스테이징 먼저 결제, 인증, 데이터 마이그레이션. 이런 건 스테이징에 먼저 배포한다. 2-3일 돌려보고 프로덕션 간다. 급하다고 바로 배포하면 야근한다. 테스트 시나리오 꼼꼼히 QA팀 없는 회사도 많다. 우리도 그렇다. 그래서 테스트 시나리오를 개발 시작 전에 만든다.Happy path: 정상 케이스 Sad path: 에러 케이스 Edge case: 경계값, 극단적 상황이거 안 하면 릴리즈 전날 버그 나온다. 개발자랑 사전 소통 "이거 언제까지 돼요?"가 아니라 "이 기능 개발하는 데 리스크 요인이 뭘까요?" 개발자가 불안해하는 부분을 미리 안다. 거기에 시간을 더 쓴다. 의외로 대화가 답이다. 결국 준비의 문제 릴리즈 전야 야근. 완전히 막을 순 없다. 소프트웨어는 항상 예측 불가능하다. 하지만 준비하면 덜 황당하다.우선순위 판단 기준 정해두기 이슈 트래킹 템플릿 만들기 커뮤니케이션 루트 정리하기 버퍼 포함한 일정 계획이것만 해도 야근이 반으로 준다. 그리고 야근했으면 회고한다. 같은 실수 두 번 하지 않는다.금요일 오후 3시. 릴리즈 완료. 모니터링 2시간 했다. 별일 없다. 이제 맥주 마실 시간이다.

지라 티켓 확인하는 순간 내 하루가 결정된다

지라 티켓 확인하는 순간 내 하루가 결정된다

지라 티켓 확인하는 순간 내 하루가 결정된다 9시 32분. 사무실에 도착했다. 가방을 내려놓고 물을 마시고 모니터를 켰다. 키보드는 아직 안 만졌다. 지라 대시보드를 연다. 그 순간이다. 내 하루의 온도가 결정된다. 초록색 'To Do', 파란색 'In Progress', 빨간색 'Blocked'. 티켓 수를 세지 않아도 느낀다. 오늘 좋은 하루가 될 건지, 아니면 밤 10시까지 야근할 건지. 지라가 말해준다.아침 9시 32분, 나의 운명의 대시보드 지라를 보는 것은 의식이다. 마치 점쟁이가 타로를 펼치는 것처럼. 먼저 빨간색부터 센다. 'Blocked' 상태의 티켓. 개발자가 막혀 있다는 뜻이다. 내가 뭔가 줘야 한다는 뜻이다. 스펙을 다시 정의하거나, 디자인을 재확인하거나, 대표님한테 의사결정을 받아야 한다. 어쨌든 내 책임이다. 어제 4개였는데 오늘 6개? 그럼 밤이 길어진다. 직관이 아니라 확률이다. 그 다음 보는 게 우선순위 태그다. P0, P1, P2. P0는 "비즈니스가 멈춘다"라는 뜻이다. 요청에 응할 기한이 있다는 뜻이다. 오늘은 P0가 3개다. 지난주에는 1개였다. 그럼 오늘은 다른 계획을 포기해야 한다는 뜻이다. 내 일정표를 버릴 준비를 한다. 10시 디자이너 미팅은 아마 30분 단축될 것 같다. 3시 이해관계자 미팅은... 최악의 경우 취소다.버그 vs 피처 vs 긴급, 우선순위의 재빠른 판단법 지라 티켓은 거짓말을 하지 않는다. 하지만 우선순위는 라벨만으로는 안 보인다. 그걸 읽어내는 게 기획자의 일이다. 버그 확인하는 법 티켓 제목에 '[BUG]'가 붙어 있다. 디스크립션을 읽는다. 스크린샷이 붙어 있는가? 재현 방법이 명확한가? "로그인 실패합니다" vs "로그인 화면에서 이메일+비밀번호 입력 후 엔터 누르면 다음 화면으로 안 넘어가고 같은 화면에 머물러 있음. 스크린샷: 첨부. 브라우저: Chrome 최신 버전. 디바이스: MacBook" 두 번째가 진짜 버그다. 첫 번째는 다시 쓰라고 comment를 달았다. 버그의 심각도(Severity)를 본다. 'Critical'이면 사용자가 앱을 못 쓴다는 뜻이다. 'Major'는 기능이 작동하는데 불편하다는 뜻이다. 'Minor'는 타이포 같은 거다. Critical 버그는 커피를 마실 시간도 없다. 피처 요청 읽기 '[FEATURE]' 라벨이 붙어 있다. 이건 개발팀의 티켓이 아니다. 보통 영업팀이나 마케팅팀에서 올린 거다. 또는 대표님이다. 스펙이 있나? 없으면 내가 1시간을 또 써야 한다는 뜻이다. "새로운 필터 기능 추가 필요" 이 정도면 스펙이 아니라 한 줄 소원이다. 내가 물어봐야 한다.어떤 필터를 원하나? 왜 필요한가? 언제까지인가? 사용자 수는 몇 명이 영향을 받나? 이걸 하면 기존 기능이 밀려도 괜찮나?마지막 질문이 핵심이다. 모든 피처 요청의 뒤에는 일정 압박이 숨어 있다. 긴급 요청의 냄새 맡기 긴급이라고 명시된 건 사실 드물다. 코맨트 섹션이 뜨거운 게 신호다. "@기획자K, 언제까지 돼요?" (어제 오후 5시) "오늘 안에 진행 가능할까요?" (오늘 아침 8시) "대표님이 확인해야 한다고 했어요" (오늘 아침 9시) 이런 메시지가 많으면 그건 긴급이다. 사실 중요도와 무관하게.지라 보고 3초 의사결정법 경험상 지라 대시보드를 3초 보면 오늘의 운명이 결정된다. 1초: Blocked 티켓 세기 5개 이상이면? 아침 회의에서 먼저 "뭐가 막혔어요?"를 물어야 한다는 뜻이다. 2초: P0 티켓 있나? 있으면 일정 재편성을 시작한다. 없으면 계획대로 간다. 3초: 어제와 비교하기 어제 'To Do'가 10개였는데 오늘 14개? 그럼 티켓 추가가 4개 들어왔다는 뜻이다. 스프린트 계획을 다시 봐야 한다. 이 3초가 내 하루를 결정한다.내가 매일 하는 지라 의식 출근 후 가장 먼저 지라를 본다. 슬랙 메시지는 이후다. 왜냐하면 지라는 사실(Fact)이고, 슬랙은 노이즈(Noise)일 수 있기 때문이다. 지라 필터를 내 역할별로 저장해두었다. 필터 1: "내가 Assignee이고 In Progress인 티켓" 이건 내가 끝내야 할 일이다. 보통 3~5개다. 필터 2: "나한테 할당되지 않았는데 내가 Reporter인 티켓" 이건 내가 만든 일인데 남이 하는 거다. 진행률을 체크해야 한다. 필터 3: "P0 or P1이고 To Do인 티켓" 이건 아직 시작 안 된 중요한 일이다. 왜 시작을 안 했는지가 중요다. 필터 4: "Blocked이고 3일 이상" 이건 내 책임이다. 3일 넘게 막혀 있으면 내가 뭔가 안 한 거다. 이 4개 필터만 봐도 오늘 뭘 할지 알 수 있다.지라 티켓을 쓸 때 나의 원칙 남도 이걸 본다. 개발자도, 디자이너도, 대표님도 본다. 그래서 글을 쓴다. 제목은 액션을 명확하게 "로그인 개선" (X) "로그인 실패 시 에러 메시지 개선" (O) 디스크립션은 문맥을 담는다 왜 하는가? 사용자가 로그인 실패 시 무슨 문제인가를 모르고 있다. 비즈니스 결과는 로그인 실패율이 20%다. 뭘 하는가? 로그인 실패 화면에 "비밀번호가 맞지 않습니다" 대신 구체적인 가이드를 보여준다. 어떻게 성공인가? 로그인 실패 후 retry 비율이 50%에서 70%로 올라가거나, 로그인 실패 문의가 30% 줄어든다. 수용 기준은 테스트 가능해야 한다 "좋아 보이면 OK" (X) "로그인 실패 시 에러 메시지가 3초 이상 표시되고, 클릭할 수 있는 '다시 시도' 버튼이 있어야 함" (O)지라를 못 읽으면 기획자가 아니다 말이 좀 강하지만, 나는 그렇게 생각한다. 지라는 팀의 현재 상태를 보는 창이다. 우리가 얼마나 바쁜지, 뭐가 막혔는지, 뭐가 우선인지 다 알 수 있다. 지라를 못 읽는 기획자는 감으로 일한다. "아, 중요할 것 같은데", "개발자가 바쁠 것 같은데" 이런 식으로. 그럼 언제나 핸드폰을 들어서 "근데 이거 언제까지 돼요?" 메시지를 받는다. 내가 아침에 지라를 본 이유는 이거다. 먼저 우리 팀의 상태를 알고, 내가 뭘 할지 정하기 위해서.오늘의 지라는 어땠나 아침 9시 32분. 지라를 봤다. Blocked: 2개 P0: 1개 P1: 3개 To Do: 12개 어제보다 Blocked가 줄었다. 어제 한 일들이 진행 중이라는 뜻이다. P0는 어제와 같다. 새로 들어온 P1이 2개다. 나쁘지 않다. 오늘 야근은 안 할 것 같다. 8시에 퇴근해도 될 것 같다. 일단 Blocked 2개부터 풀어보자. 하나는 디자인 확인이 필요하고, 하나는 대표님 의사결정이 필요하다. 디자이너한테 먼저 가서 "이 화면 어디까지 왔어요?"라고 묻겠다. 그리고 점심 후에 대표님 일정을 확인해서 30분짜리 빠른 회의를 잡겠다. P0 1개는 이미 진행 중이니까 개발자 상황만 확인하면 된다. 새로 들어온 P1 2개는 내일 진행 가능할지 스프린트 일정과 비교해서 판단하겠다. 이렇게 생각하는 데 5분이 걸렸다. 지라 한 번 보고 5분이면 내 하루 구조가 다 짜인다. 다른 기획자들한테 물어본 적 있다. 너희는 어떻게 하냐고. "아, 나는 그냥 슬랙 메시지 기준으로 우선순위를 정해" "대표님이 중요하다고 한 거 먼저 해" "개발자가 재촉한 것부터" 그렇게 하면 바쁘다. 충분히 바쁘다. 그리고 항상 뭔가 빠뜨린다. 지라를 기준으로 하니까 뭐가 빠진 게 없다. 물론 지라 자체가 완벽하지는 않다. 누군가 티켓을 안 만들 수도 있고, 우선순위를 잘못 매길 수도 있다. 하지만 지라는 거짓말을 하지 않는다. 그냥 현실이다.지라가 나의 일정표다 캘린더는 회의 시간만 적혀 있다. 진짜 일은 지라에 있다. 그래서 나는 매일 아침 9시 32분에 지라를 본다. 그 3초가 내 하루를 결정한다. 오늘 밤 10시까지 야근할지, 8시에 퇴근할지. 오늘 커피를 1잔 마실지, 5잔 마실지. 오늘 남자친구한테 "늦을 것 같아"라고 문자할지, 아니면 조용히 집에 갈지. 모든 게 지라 대시보드에 담겨 있다. 신기한 건, 경험이 쌓일수록 지라를 보는 시간이 줄어든다는 거다. 요즘은 진짜 3초면 충분하다. 패턴을 알기 때문이다. 스프린트 계획할 때 Blocked가 많으면? 팀의 의존성이 많다는 뜻이다. 다음 스프린트에서는 독립적인 일들을 선택해야 한다. P0이 자주 들어오면? 비즈니스 요구가 계획 없이 들어온다는 뜻이다. 제품 로드맵을 다시 짜야 한다. To Do가 자꾸 증가하면? 일 추가 속도가 일 처리 속도보다 빠르다는 뜻이다. 뭔가 줄여야 한다. 지라는 팀의 진짜 상태를 말해준다. 회의에서는 안 나오는 진실을 알려준다.기획자로 일한 6년, 지라의 진화 처음에는 지라를 싫어했다. 왜냐하면 일이 가시화되니까. 지라 없을 때는 슬랙으로 주고받고, 한두 개는 깜빡할 수 있었다. 지라를 쓰기 시작하니까 내가 얼마나 바쁜지, 계획이 얼마나 밀리는지 다 보였다. 불편했다. 그런데 지금은 반대다. 지라가 없으면 못 산다. 지라 없으면 내가 뭐를 해야 하는지, 팀이 뭐 하는지 모른다. 지라가 있으니까 데이터 기반으로 말할 수 있다. "지난주에 P0이 3개, 이번주에 5개 들어왔어요. 계획을 다시 짜면 좋겠어요." 감으로 말하는 것과 숫자로 말하는 것은 다르다.내일 아침 9시 32분 지라를 또 본다. 오늘 처리한 티켓들이 'Done'으로 이동했을 거다. 오늘 새로 들어온 일들이 'To Do'에 있을 거다. 내 하루가 또 결정된다.지라가 거짓말을 하지 않는 유일한 이유는 그게 팀의 현실이기 때문이다.