Showing Posts From

언제까지

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

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

"언제까지 돼요?"에 논리적으로 대답하는 법 그 질문이 올 때마다 "이거 언제까지 돼요?" 월요일 아침 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분 걸린다. 그럼 대답할 수 있다. "언제까지 돼요?"에. "○일 예상됩니다. 근거는 이렇습니다.""언제까지 돼요?" 이제 무섭지 않다. 숫자로 말하면 된다.