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

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

릴리즈 전야의 야근, 피할 수 없다면 준비하자 수요일 밤 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시간 했다. 별일 없다. 이제 맥주 마실 시간이다.

MVP 한 마디로 프로젝트가 살아난다

MVP 한 마디로 프로젝트가 살아난다

MVP 한 마디로 프로젝트가 살아난다 대표님의 10개 피처 월요일 오전 10시. 기획 검토 미팅. 대표님이 말했다. "이번 릴리즈에 이거 다 넣으면 좋겠는데." 화면을 보니 피처가 10개다.소셜 로그인 3종 추가 알림 설정 상세화 프로필 편집 고도화 추천 알고리즘 개선 채팅 기능 결제 수단 추가 다크모드 언어 설정 튜토리얼 리뉴얼 통계 대시보드개발 기간은 6주. 나는 계산했다. 이거 다 하려면 최소 4개월이다.첫 반응 "네, 검토해보겠습니다." 회의실 나왔다. 개발팀장한테 슬랙 보냈다. "10개 피처, 6주. 가능?" 답장은 5초 만에 왔다. "ㅋㅋㅋㅋㅋ 농담이죠?" 디자이너한테도 물었다. "UI 작업만 2개월이요." 예상했다. 이제 대표님을 설득해야 한다. 어떻게? "안 됩니다" 는 답이 아니다. 대안을 줘야 한다. 그게 MVP다. MVP가 뭔데 Minimum Viable Product. 최소 기능 제품. 핵심만 남긴 버전이다. 10개 피처 중에서 진짜 필요한 거. 유저가 당장 써야 하는 거. 나머지는 다음 스프린트. 이게 스코프 관리의 핵심이다. 나는 회의록을 다시 봤다. 10개 피처의 목적을 정리했다.소셜 로그인: 가입률 올리기 (중요도 상) 알림 설정: 이탈 방지 (중) 프로필 편집: 사용성 개선 (중) 추천 알고리즘: 체류시간 증가 (상) 채팅: 커뮤니티 활성화 (하, 아직 유저 적음) 결제 수단: 매출 (상) 다크모드: 요청 많음 (하, 급하진 않음) 언어 설정: 해외 진출 (하, 올해 계획 없음) 튜토리얼: 신규 유저 온보딩 (중) 통계 대시보드: 내부 운영용 (하)가입률, 매출, 추천. 이 3개가 핵심이다. 나머지는 좋으면 좋은 거다. 없어도 서비스는 돌아간다.대표님 설득법 다음날 미팅을 다시 잡았다. 준비물:우선순위 매트릭스 개발 공수 추정 릴리즈 로드맵 (3개 버전)"대표님, 검토했습니다." 화이트보드에 표를 그렸다. 중요도 vs 긴급도[높음/높음] [높음/낮음] 소셜로그인 알림설정 결제수단 프로필편집 추천알고리즘 튜토리얼[낮음/높음] [낮음/낮음] (없음) 채팅 다크모드 언어설정 통계대시보드"10개 다 하면 4개월입니다. 6주 안에 하려면 3개만 가능합니다." 대표님 표정이 굳었다. "그럼 나머지는 언제?" "일단 MVP로 가시죠. 소셜로그인, 결제수단, 추천 알고리즘. 이 3개만 6주 안에 릴리즈합니다." "나머지 7개는?" "버전을 나눕니다. v1.1에 중요도 중간인 것들, v1.2에 나머지." 화이트보드에 타임라인을 그렸다.v1.0 (6주): 소셜로그인 + 결제 + 추천 v1.1 (8주 후): 알림 + 프로필 + 튜토리얼 v1.2 (12주 후): 채팅 + 다크모드 + 언어 + 통계"이렇게 하면 6주 안에 핵심 기능은 나갑니다. 매출도 올리고, 가입률도 높이고." 대표님이 잠시 생각했다. "채팅은 왜 나중에?" "지금 DAU가 500명입니다. 채팅 쓸 사람이 없어요. v1.1로 유저 늘리고 나서 넣는 게 맞습니다." "다크모드는?" "요청이 30건이에요. 전체 유저 5000명 중 0.6%. 우선순위가 낮습니다." 숫자로 말하니까 설득이 됐다. "알겠어. MVP로 가자." MVP의 힘 이 한 마디가 프로젝트를 살렸다. 10개 피처를 6주에 하면 어떻게 됐을까?개발팀 번아웃 QA 시간 부족 버그 투성이 릴리즈 유저 불만 폭증 결국 핫픽스 지옥실제로 전 회사에서 겪었다. 대표님이 "다 넣어" 해서 다 넣었다. 릴리즈 당일 서버가 터졌다. 앱스토어 리뷰 평점이 4.2에서 2.8로 떨어졌다. 복구하는 데 3개월 걸렸다. 그때 배웠다. 스코프 관리는 협상이 아니다. 생존이다.MVP 정하는 법목적을 먼저 정한다피처가 아니라 목표다. "채팅 기능을 넣는다" (X) "유저 체류시간을 20% 늘린다" (O) 목표가 명확하면 피처는 자동으로 정해진다. 채팅이 정말 체류시간을 늘릴까? 데이터는? 가설은? 이렇게 물으면 우선순위가 보인다.임팩트 vs 공수가로축: 비즈니스 임팩트 세로축: 개발 공수 [높은 임팩트 / 낮은 공수] → 당장 해라 [높은 임팩트 / 높은 공수] → MVP로 쪼개라 [낮은 임팩트 / 낮은 공수] → 시간 나면 해라 [낮은 임팩트 / 높은 공수] → 하지 마라 소셜 로그인: 높은 임팩트 / 중간 공수 → MVP 포함 다크모드: 낮은 임팩트 / 중간 공수 → 제외 이게 합리적 판단이다.유저 관점에서 생각한다내가 유저라면 뭐가 제일 필요할까? 이번 프로젝트의 타겟 유저는 "처음 가입하는 사람"이었다. 그럼 소셜 로그인은 필수다. 회원가입 장벽을 낮춰야 한다. 채팅? 친구도 없는데 누구랑 채팅해? 다크모드? 일단 가입부터 하고 나서 생각할 문제다. 유저 여정을 그려보면 답이 나온다.데이터로 검증한다감이 아니라 숫자다. "다크모드 요청이 많아요" → 몇 건? "채팅이 필요해요" → 사용률 예측은? "추천 알고리즘이 중요해요" → 현재 클릭률은? 구글 애널리틱스, 믹스패널, 앰플리튜드. 데이터를 보면 우선순위는 명확해진다. 실제로 알림 설정은 데이터 보고 v1.1로 밀었다. 현재 알림 수신율이 72%였다. 충분히 높았다. "알림 상세 설정"은 급한 게 아니었다. 개발팀 반응 개발팀장이 말했다. "10개에서 3개로 줄여줘서 고맙습니다." 진심이었다. 개발자는 완성도를 원한다. 대충 10개보다 제대로 3개가 낫다. 프론트엔드 개발자도 좋아했다. "소셜 로그인 3종만 하면 되니까 OAuth 제대로 구현할게요." 백엔드 개발자는 이렇게 말했다. "추천 알고리즘에 집중할 수 있어서 좋네요. A/B 테스트도 붙일게요." QA 담당자도 만족했다. "3개면 테스트 케이스 제대로 짤 수 있어요." 모두가 행복한 스코프. 이게 MVP의 힘이다. 디자이너 입장 디자이너도 스코프가 줄어서 좋아했다. "10개 화면 러프하게 그리는 것보다, 3개 화면 디테일 잡는 게 낫죠." 실제로 소셜 로그인 화면은 A안, B안, C안까지 뽑았다. 유저 테스트도 했다. 결제 화면은 UX 라이팅까지 신경 썼다. "결제하기" 대신 "3,000원 결제하기". 전환율이 8% 올랐다. 10개 피처를 급하게 했으면 이런 디테일은 불가능했다. MVP는 퀄리티를 보장한다. 릴리즈 결과 6주 후. v1.0이 나갔다. 3개 피처만 들어갔지만 반응은 좋았다.소셜 로그인: 가입률 32% 상승 결제 수단: 첫 주 매출 47% 증가 추천 알고리즘: 평균 체류시간 6분 → 9분앱스토어 리뷰에 이런 댓글이 달렸다. "업데이트 후 진짜 편해졌어요. 카카오로 바로 가입했습니다." "결제가 이제 되네요. 기다렸어요." "추천이 정확해요. 계속 보게 되네요." 3개만 했는데 만족도는 높았다. 왜? 제대로 했으니까. 대표님도 만족했다. "다음은 v1.1 준비하자. 잘했어." MVP로 일하는 법 이제 나는 모든 프로젝트에 MVP를 적용한다.피처 리스트를 받으면 일단 질문한다"이 기능의 목적이 뭐죠?" "유저가 정말 원하나요?" "데이터 있나요?" "안 하면 어떻게 되죠?" 질문하면 절반은 우선순위에서 빠진다.Must Have / Should Have / Nice to Have피처를 3단계로 나눈다. Must: 없으면 서비스가 안 됨 Should: 있으면 좋음 Nice: 나중에 해도 됨 Must만 MVP에 넣는다.로드맵을 그린다v1.0, v1.1, v1.2. 이렇게 버전을 나누면 대표님도 이해한다. "일단 v1.0 나가고, 다음 거는 8주 후에요." 시간 축이 명확하면 협상이 쉽다.개발팀과 미리 소통한다기획서 쓰기 전에 개발팀장한테 물어본다. "이거 공수 얼마나 나올 것 같아요?" 대략적인 추정치를 받는다. 그걸 기반으로 스코프를 조정한다. 나중에 "이거 안 돼요" 듣는 것보다 훨씬 낫다.데이터를 모은다구글 애널리틱스, 유저 인터뷰, CS 문의 내역. "요청이 많아요" 말고 "246건 요청 들어왔어요" 라고 말한다. 숫자가 있으면 설득력이 생긴다. 실패 사례 물론 실패도 있었다. 작년에 채팅 기능을 MVP에 넣었다. 대표님이 강하게 원했다. "경쟁사는 다 있어." 나는 밀어붙였다. MVP에 포함시켰다. 결과? 개발 기간 8주 → 12주로 늘어남. 릴리즈 후 채팅 사용률 3%. 유저들은 채팅을 안 썼다. 왜? 우리 서비스는 커뮤니티가 아니었다. 정보 검색 앱이었다. 채팅이 필요 없었던 거다. 나는 데이터를 무시하고 대표님 의견을 따랐다. 실수였다. 그 이후로 나는 더 단호해졌다. "근거가 없으면 MVP에 안 넣습니다." MVP는 타협이 아니다 처음엔 생각했다. MVP는 어쩔 수 없이 줄이는 거라고. 아니다. MVP는 전략이다. 핵심에 집중하는 전략. 10개를 대충 하는 것보다, 3개를 제대로 하는 게 낫다. 유저도 그걸 안다. "이것저것 다 있는데 다 별로" 보다 "기능은 적은데 하나하나 완벽해" 가 낫다. 애플이 그렇게 일한다. 아이폰 첫 버전에는 복붙도 없었다. MMS도 안 됐다. 하지만 터치 인터페이스는 완벽했다. 그래서 성공했다. 지금도 오늘도 대표님이 말했다. "이번 분기에 이거 5개 넣을 수 있지?" 나는 웃으며 말했다. "일단 MVP로 가시죠. 2개만 제대로 합시다." 대표님도 이제 안다. 내가 왜 이러는지. "알았어. 네 말대로 하자."MVP 한 마디로 프로젝트가 산다. 스코프 관리는 협상이 아니라 생존이다.

'언제까지 돼요?'에 논리적으로 대답하는 법

'언제까지 돼요?'에 논리적으로 대답하는 법

"언제까지 돼요?"에 논리적으로 대답하는 법 그 질문이 올 때마다 "이거 언제까지 돼요?" 월요일 아침 9시 45분. 커피도 안 마셨다. 슬랙에 대표님 멘션이 떴다. 새 피처 아이디어다. "다음 주까지 가능할까요?" 심장이 쿵 내려앉는다. "확인해보고 말씀드릴게요." 타이핑한다. 손이 떨린다. 이번엔 제대로 대답하고 싶다. 또 "한 3일?" 이러다가 2주 걸린 거 들키고 싶지 않다. 입사 초기엔 그랬다. "금방이요!" 했다가 개발자한테 "이거 API 3개 새로 만들어야 하는데요?" 들었다. 디자이너는 "화면이 7개예요. 컴포넌트도 신규고요." 했다. QA는 "테스트 시나리오만 이틀이요." 했다. 결국 2주 걸렸다. 모두가 날 쳐다봤다. 지금은 다르다. 6년 차가 됐다. 배웠다. 논리적으로 대답하는 법을.일단 멈춘다 "확인해보고 말씀드릴게요." 이 한 문장이 생명줄이다. 바로 대답하지 않는다. 절대. 아무리 급해 보여도. "대충 언제쯤일까요?"라고 재촉해도. "정확한 일정은 개발팀 확인 후 2시까지 드리겠습니다." 구체적 시간을 준다. "나중에"는 안 된다. "오늘 중"도 애매하다. "2시"라고 한다. 그럼 상대도 기다린다. 1시간 반이 생긴다. 이 시간에 모든 걸 확인한다. 가장 먼저 노션을 연다. '일정 추정 체크리스트' 템플릿이 있다. 이걸 만드는 데 3개월 걸렸다. 프로젝트마다 틀어진 일정 복기하면서 하나씩 추가했다. 체크리스트는 19개 항목이다. 첫 번째는 "이거 정말 해야 하나?"다. 진짜 중요하다. 때로는 안 해도 되는 일이다. 대체 방안이 있다. 우선순위가 낮다. 이걸 먼저 확인한다. 두 번째는 "유저 플로우 그려봤나?"다. 머릿속으로 아는 것과 그려보는 건 다르다. 그려보면 빠진 화면이 보인다. 예외 케이스가 튀어나온다. 세 번째부터 본격적이다.쪼갠다 "로그인 기능 추가해주세요." 간단해 보인다. 3일? 아니다. 피그마를 연다. 화면을 그린다. 실제로 그려본다. 대충 머릿속으로 안 한다.로그인 화면 (이메일/비번) 회원가입 화면 비밀번호 찾기 화면 이메일 인증 화면 약관 동의 화면 프로필 설정 화면벌써 6개다. 각 화면마다 생각한다. 로그인 화면: 이메일 유효성 검사 비밀번호 보이기/숨기기 버튼 로그인 실패 시 에러 메시지 로딩 인디케이터 소셜 로그인 버튼 (구글, 카카오) 자동 로그인 체크박스한 화면에 6개 기능이다. 소셜 로그인만 따로 본다.구글 OAuth 연동 카카오 OAuth 연동 소셜 계정 연결 해제 이미 가입된 이메일 처리4개 더 나온다. 이렇게 쪼갠다. 끝까지. 더 이상 안 쪼개질 때까지. 엑셀을 연다. 태스크 리스트를 만든다.태스크 담당 공수(일) 선행 태스크로그인 화면 디자인 디자인 1 -회원가입 화면 디자인 디자인 1 -로그인 API 개발 백엔드 2 -회원가입 API 개발 백엔드 2 -이메일 인증 API 백엔드 1 회원가입 API구글 OAuth 연동 백엔드 1.5 로그인 API로그인 화면 구현 프론트 1.5 로그인 화면 디자인, 로그인 API회원가입 화면 구현 프론트 2 회원가입 화면 디자인, 회원가입 APIQA 테스트 QA 2 전체 구현 완료총 14일이 나온다. 병렬로 하면 8일이다. 하지만 현실은 다르다.버퍼를 넣는다 8일이면 2주다. 틀렸다. 3주다. 왜냐면. 첫째, 사람들은 하루 8시간 일 안 한다. 미팅이 있다. 데일리 스크럼 30분. 위클리 리뷰 1시간. 갑작스런 버그 픽스 2시간. 점심 1시간. 슬랙 확인 1시간. 실제 작업 시간은 4시간이다. 많아야 5시간. 그럼 8일은 16일이다. 둘째, 의존성이 있다. 디자인 끝나야 프론트 시작한다. API 끝나야 연동한다. 완벽하게 병렬 안 된다. 크리티컬 패스를 그린다. 노션에 간트 차트 플러그인을 쓴다. 아니면 손으로 그린다. 디자인(2일) → 프론트 구현(7일) → QA(2일) = 11일 백엔드(7일)는 병렬로 돌아간다. 그럼 11일이다. 실 작업시간 감안하면 22일. 한 달이다. 셋째, 리뷰가 있다. 디자인 리뷰 2회. 코드 리뷰 매일. 기획 검토 1회. QA 리뷰 2회. 각 리뷰마다 수정이 나온다. "이 버튼 위치 바꿔주세요." "이 API 응답 포맷 변경해주세요." 리뷰 + 수정 = 3일 추가. 넷째, 예상 못한 일. 항상 생긴다.휴가 (여름휴가 시즌이면 +2일) 아픈 날 (한 달에 평균 0.5일) 레거시 코드 문제 (+2일) 외부 라이브러리 버그 (+1일)평균 5일 추가된다. 22일 + 3일 + 5일 = 30일. 한 달이다. 정확히. 하지만 "한 달 걸립니다"라고 말하면 "뭐가 그렇게 오래 걸려요?"라고 듣는다. 그래서 버퍼를 설명한다. 숫자로 말한다 "한 달 정도 예상됩니다." "왜요?" 이제 설명한다. 준비한 자료를 연다. "일단 태스크를 쪼개봤습니다. 총 9개 항목이 나왔어요." 노션 페이지를 공유한다. 표가 있다. "디자인이 2일, 백엔드 API 개발이 7일, 프론트 구현이 7일입니다. 여기에 QA 테스트 2일 추가됩니다." "병렬로 하면 안 돼요?" "백엔드는 병렬 가능한데요, 프론트는 디자인 끝나야 시작할 수 있습니다. 크리티컬 패스가 디자인 → 프론트 → QA로 이어져서 11일이 나옵니다." 피그마 화면을 보여준다. 의존성 화살표가 그려져 있다. "근데 실 작업시간은 하루 4~5시간이에요. 미팅이랑 리뷰 시간 빼면요. 그래서 11일이 22일이 됩니다." "그럼 3주네요?" "거기에 리뷰 사이클 3일, 예상치 못한 이슈 대응 5일 더하면 30일입니다. 지난 3개 프로젝트 평균 버퍼가 5일이었어요." 노션에 과거 프로젝트 데이터를 보여준다. 실제 기록이다.프로젝트 예상 실제 차이 이유찜하기 기능 10일 14일 +4일 레거시 코드 이슈검색 필터 15일 21일 +6일 디자인 수정 3회알림 설정 8일 12일 +4일 API 스펙 변경"평균 버퍼가 4.7일이에요. 그래서 5일 잡았습니다." 침묵이 흐른다. 3초. "알겠습니다. 그럼 한 달로 잡겠습니다." 끝이다. 숫자가 이긴다. 논리가 이긴다. "제 경험상" 같은 말은 안 통한다. "보통"도 안 통한다. 표와 데이터가 통한다. 체크포인트를 만든다 한 달은 길다. 중간에 불안해한다. "잘 되고 있나요?" 체크포인트를 만든다. 일정을 쪼갠다.1주차 금요일: 디자인 초안 리뷰 2주차 수요일: API 개발 완료 + 프론트 50% 3주차 금요일: 전체 구현 완료 4주차 수요일: QA 완료매 체크포인트마다 슬랙에 업데이트한다. "[로그인 기능] 1주차 체크포인트 완료 ✅ 디자인 초안 리뷰 완료 ✅ 백엔드 API 30% 진행 중 ⚠️ 소셜 로그인 라이브러리 선정 중 (내일 결정) → 전체 일정 영향 없음" 이렇게 쓴다. 3줄이다. 완료된 것, 진행 중인 것, 리스크. 리스크는 솔직하게 쓴다. "다 잘되고 있어요!" 같은 말 안 한다. 문제가 생기면 바로 공유한다. "⚠️ 레거시 코드 이슈 발견. 로그인 세션 관리 부분 리팩토링 필요. +2일 예상. 전체 일정 29일 → 31일로 조정 제안드립니다." 미리 말한다. 마지막에 "아 그거 문제 있어서 늦어졌어요" 하지 않는다. 체크포인트를 지키면 신뢰가 쌓인다. 다음 프로젝트 때 "K님 말씀이면 믿습니다" 듣는다. 못 지키면 왜 못 지켰는지 복기한다. 노션에 기록한다. "1주차 체크포인트 미달 원인:디자이너 병가 2일 → 다음엔 백업 디자이너 미리 지정 OAuth 라이브러리 deprecated → 다음엔 사전 기술 검토 1일 추가"이게 쌓인다. 나중에 추정 정확도가 올라간다. 지금 내 정확도는 85%다. 예상 일정의 ±15% 안에 끝난다. 2년 전엔 60%였다. 불가능한 일정이 오면 가끔 온다. "이거 이틀 안에 돼요?" 안 된다. 물리적으로 불가능하다. "불가능합니다." 단호하게 말한다. "힘들긴 한데..." 이러지 않는다. "한번 해볼게요..." 절대 안 한다. "왜 안 돼요?" 이제 설명한다. "태스크가 9개인데요, 각각 최소 0.5일씩 걸립니다. 병렬로 해도 3일이 최소입니다. 2일은 물리적으로 불가능해요." "그럼 범위를 줄이면요?" "가능합니다. MVP로 가면 되는데요." 화이트보드를 꺼낸다. 기능을 나열한다.이메일 로그인 (필수) 소셜 로그인 (제거 가능) 비밀번호 찾기 (제거 가능) 자동 로그인 (제거 가능)"소셜 로그인, 비밀번호 찾기, 자동 로그인을 빼면 5일로 줄어듭니다. 이틀은 여전히 불가능하지만 일주일이면 가능합니다." "일주일도 길어요." "그럼 2가지 옵션이 있습니다." 손가락을 편다. "첫째, 다른 프로젝트를 멈추고 이거에 올인합니다. 개발자 2명 풀로 투입하면 3일 가능합니다. 대신 OO 프로젝트가 2주 밀립니다." "둘째, 임시 방편을 씁니다. 로그인 없이 게스트 모드로 먼저 오픈하고, 로그인은 다음 주에 추가합니다." 침묵. "...일주일로 갑시다." 대부분 이렇게 끝난다. 불가능하다고 명확하게 말하면 알아듣는다. 애매하게 "어렵긴 한데..." 하면 계속 요구한다. 핵심은 대안을 주는 것이다. "안 됩니다" 만 말하면 안 된다. "안 되는데, 이렇게 하면 됩니다" 까지 말한다. 개발자와 동기화한다 일정 추정은 혼자 안 한다. 개발자랑 같이 한다. 필수다. "이거 며칠 걸릴까요?" 물어본다. "음... 3일?" "근데 로그인 API, 회원가입 API, 이메일 인증, 소셜 연동 다 포함이에요. 각각 얼마나 걸려요?" "아 그럼... 로그인 1일, 회원가입 1일, 이메일 인증 0.5일, 소셜 연동 1.5일?" "그럼 총 4일이네요. 코드 리뷰랑 수정 시간은요?" "하루 더?" "5일로 잡을게요. 괜찮으세요?" "네." 이렇게 한다. 구체적으로 쪼개서 물어본다. 뭉뚱그려 물어보면 뭉뚱그린 답이 온다. 그리고 기록한다. 노션에 바로 적는다. "로그인 기능 일정 협의 (24.01.15)참석: K (기획), J (백엔드) 총 5일 합의 로그인 API: 1일 회원가입 API: 1일 이메일 인증: 0.5일 소셜 연동: 1.5일 리뷰+수정: 1일"나중에 "그런 적 없는데요?" 할 때 보여준다. 실제로 그런 적 있다. 기록이 날 살렸다. 디자이너도 마찬가지다. "화면 6개면 며칠이에요?" "3일?" "각 화면마다 인터랙션이랑 예외 케이스까지 그려야 하는데, 괜찮아요?" "음... 그럼 5일?" "5일로 잡고, 중간에 리뷰 한 번 할까요? 2일 차에?" "좋아요." 중간 리뷰를 꼭 넣는다. 끝까지 기다렸다가 "이거 아닌데..." 하지 않는다. QA도 미리 물어본다. "이번 기능 테스트 며칠 걸려요?" "시나리오 작성 1일, 테스트 1일, 리그레션 1일. 총 3일요." "3일 잡을게요. 테스트 시나리오는 개발 끝나기 전에 미리 공유 가능해요?" "가능해요." 이렇게 모든 팀원과 일정을 맞춘다. 추측하지 않는다. 물어본다. 실제로 해본 결과 이 방법으로 지난 6개월간 8개 프로젝트를 했다.프로젝트 예상 실제 정확도푸시 알림 15일 16일 93%장바구니 20일 22일 91%쿠폰 10일 9일 110%리뷰 25일 27일 93%검색 개선 12일 13일 92%필터 8일 10일 80%찜하기 6일 6일 100%공유 5일 7일 71%평균 정확도 91%. 가장 틀린 건 '공유 기능'이었다. 예상 5일, 실제 7일. 40% 차이. 이유는 명확했다. 카카오톡 공유 SDK 업데이트가 있었다. 문서가 잘못되어 있었다. 개발자가 2일 헤맸다. 다음부턴 외부 SDK 쓸 때 버퍼를 +1일 더 넣는다. 반대로 가장 정확한 건 '찜하기'였다. 예상 6일, 실제 6일. 100%. 단순 CRUD였다. 외부 의존성 없었다. 화면도 명확했다. 교훈: 단순할수록 정확하다. 복잡할수록 버퍼를 늘린다. 지금은 프로젝트 복잡도를 3단계로 나눈다.단순 (CRUD, 화면 3개 이하): 버퍼 20% 보통 (로직 있음, 화면 5개 이하): 버퍼 30% 복잡 (외부 연동, 신규 기술): 버퍼 50%복잡한 프로젝트는 버퍼를 2배 가까이 넣는다. 경험상 그게 맞다. 일정이 틀어질 때 그래도 틀어진다. 지난주에도 틀어졌다. '알림 설정' 기능. 예상 10일, 7일째인데 60%밖에 안 됐다. 이유: iOS 푸시 인증서 문제. 애플 개발자 계정 이슈. 2일 날아갔다. 7일째 아침, 데일리 스크럼에서 말했다. "iOS 인증서 이슈로 2일 지연됐습니다. 현재 진행률 60%. 이대로면 12일 소요 예상됩니다. 2일 초과입니다." 대표님이 물었다. "줄일 수 있어요?" "2가지 방안 있습니다. 첫째, AOS만 먼저 오픈하고 iOS는 2일 뒤 오픈. 둘째, 알림 설정 UI는 먼저 오픈하고 실제 푸시는 나중에 연결. 어느 쪽이 나을까요?" "첫 번째로 갑시다." 그날 오후에 일정을 업데이트했다.AOS 오픈: D+10 iOS 오픈: D+12슬랙에 공유했다. 이해관계자 전원 태그했다. 빠르게 말하는 게 핵심이다. 7일째 말했다. 10일째 말하면 늦다. 기준은 이렇다. 진행률이 예상보다 10% 이상 차이 나면 즉시 공유한다. 5일째 50% 되어야 하는데 40%면 공유. 7일째 70%인데 60%면 공유. 그럼 사람들이 준비한다. 일정을 조정한다. 마케팅을 미룬다. 공지를 수정한다. 10일째 "아 안 될 것 같아요" 하면 모두가 패닉이다. 지금 쓰는 템플릿 노션에 템플릿을 만들었다. 새 프로젝트마다 복사한다. # [프로젝트명] 일정 추정## 1. 범위 정의 - [ ] 유저 플로우 그렸나? - [ ] 화면 목록 작성했나? - [ ] 예외 케이스 고려했나? - [ ] API 스펙 정의했나?## 2. 태스크 분해 | 태스크 | 담당 | 공수 | 선행 | 메모 | |--------|------|------|------|------| | | | | | |## 3. 크리티컬 패스 [의존성 다이어그램]## 4. 버퍼 적용 - 기본 공수: __일 - 리뷰 사이클: __일 - 예상 이슈: __일 - 총 예상 일정: __일## 5. 복잡도 - [ ] 단순 (20% 버퍼) - [ ] 보통 (30% 버퍼) - [ ] 복잡 (50% 버퍼)## 6. 체크포인트 - 1주차: - 2주차: - 3주차: - 완료: ## 7. 리스크 | 리스크 | 확률 | 영향 | 대응 | |--------|------|------|------| | | | | |## 8. 협의 기록 - 날짜: - 참석자: - 합의 내용: 이 템플릿을 채운다. 30분 걸린다. 그럼 대답할 수 있다. "언제까지 돼요?"에. "○일 예상됩니다. 근거는 이렇습니다.""언제까지 돼요?" 이제 무섭지 않다. 숫자로 말하면 된다.

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

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

지라 티켓 확인하는 순간 내 하루가 결정된다 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'에 있을 거다. 내 하루가 또 결정된다.지라가 거짓말을 하지 않는 유일한 이유는 그게 팀의 현실이기 때문이다.