Showing Posts From

협업

데이터로 증명하라 - 기획자가 SQL을 배워야 하는 이유

데이터로 증명하라 - 기획자가 SQL을 배워야 하는 이유

데이터로 증명하라 - 기획자가 SQL을 배워야 하는 이유 오늘도 데이터팀에 요청했다 "이 기능 사용자 몇 명이에요?" 개발자가 물었다. 나는 대답을 못 했다. 예상은 있다. 많지 않을 것 같다. 근데 숫자는 모른다. "데이터팀에 요청했어요." 개발자는 한숨을 쉬었다. 3일 걸린다는 걸 안다. 그 사이에 우선순위는 또 바뀐다.이게 3번째다. 이번 주에만. 매번 데이터팀 눈치를 본다. "저기... 혹시 이것도 가능할까요?" 하면서. 데이터팀도 바쁘다. 나만 바쁜 게 아니다. 그들은 대시보드 만들고, 경영진 보고서 쓰고, 데이터 파이프라인 관리한다. 내 요청은 우선순위에서 밀린다. 당연하다. 근데 문제는 그 사이에 일정이 간다는 거다. 직관은 있는데 증명이 안 된다 대표님이 물었다. "이 기능 왜 넣어야 해요?" 나는 설명했다. 유저 플로우를 그렸다. 경쟁사 사례를 보여줬다. 사용자 인터뷰 내용도 공유했다. "좋아요. 근데 데이터는요?" 말문이 막혔다. 직관적으로는 확신이 있다. 6년 동안 쌓인 감각이 있다. 이건 필요한 기능이다. 유저들이 원한다. 근데 숫자가 없다. "한 30%는 쓸 것 같은데요." "같은데요가 아니라 데이터로 보여주세요." 회의는 다음 주로 미뤄졌다. 데이터팀에 또 요청했다.집에 오면서 생각했다. 언제까지 이럴 건가. 내 직감을 증명할 방법이 필요하다. 스스로. SQL을 배우기로 했다 주말이다. 노션에 '공부' 페이지를 만들었다. "SQL 기초부터." 검색했다. 자료는 넘친다. 유튜브, 인프런, 유데미, 블로그. 문제는 뭐부터 봐야 하는지 모른다는 거다. 데이터 분석가가 되려는 게 아니다. 나는 기획자다. 필요한 건 복잡한 분석이 아니다.이 기능 사용자 몇 명? 이탈률 얼마? 어느 시간대에 많이 써? A/B 테스트 결과는?이 정도만 뽑을 수 있으면 된다.첫 주는 개념만 봤다. SELECT, FROM, WHERE. 테이블이 뭔지. 데이터베이스가 뭔지. 하나씩 따라 쳤다. Notion에 정리했다. SELECT user_id, created_at FROM users WHERE created_at > '2024-01-01'이게 돌아갔다. 짜릿했다. 개발자한테 부탁했다 "혹시 테스트 DB 접근 권한 받을 수 있을까요?" 개발자가 의외라는 표정을 지었다. "SQL 배우려고요?" "네. 매번 데이터팀 귀찮게 하기 싫어서요." 5분 만에 권한이 생겼다. DBeaver를 설치했다. 테이블 목록을 봤다. users, orders, payments, logs... 어지러웠다. 이게 뭐고 저게 뭔지. "이 테이블에 뭐가 들어있어요?" 개발자가 옆에 앉았다. 30분 동안 설명해줬다.users: 회원 정보 user_actions: 유저 행동 로그 feature_usage: 기능 사용 기록"여기서 대부분 뽑을 수 있을 거예요." 감사했다. 진심으로. 첫 쿼리를 짰다 "이번 달 신규 가입자 수" 손이 떨렸다. 근데 써봤다. SELECT COUNT(*) as new_users FROM users WHERE created_at >= '2024-11-01' AND created_at < '2024-12-01'실행. 3초. 숫자가 나왔다. 1,247명. 이걸 이제 내가 직접 뽑는다. 다음 쿼리. "이 기능 사용자 수" SELECT COUNT(DISTINCT user_id) as active_users FROM feature_usage WHERE feature_name = 'wishlist' AND used_at >= '2024-11-01'832명. 전체 DAU 대비 18%. 이 숫자가 내 손으로 나왔다. Notion에 정리했다. 쿼리를 저장했다. 다음에 또 쓸 거다. 회의가 달라졌다 다음 주 회의. 대표님이 물었다. "이 기능 얼마나 써요?" 노트북을 열었다. 쿼리를 돌렸다. 20초. "지난주 기준 일평균 1,200회 사용됩니다. 전체 사용자의 22%가 최소 1회 이상 이용했고요." 회의실이 조용해졌다. "시간대별로는 오후 2시에서 4시 사이가 피크고, 모바일이 73%입니다." 대표님이 고개를 끄덕였다. "좋아요. 이 방향으로 가시죠." 회의는 30분 만에 끝났다. 결론이 났다. 전에는 3일 기다리고, 데이터 받아서, 다시 회의 잡고, 그랬다. 이제는 즉석에서 확인한다. 개발자가 나중에 슬랙을 보냈다. "기획자님 SQL 하시는 거 멋있어요. 소통이 빨라져서 좋네요." 저장했다. 이 칭찬. 내가 자주 쓰는 쿼리 5개 Notion에 템플릿을 만들었다. "자주 쓰는 쿼리 모음" 1. 기능별 사용자 수 SELECT feature_name, COUNT(DISTINCT user_id) as users, COUNT(*) as total_uses FROM feature_usage WHERE used_at >= '2024-11-01' GROUP BY feature_name ORDER BY users DESC우선순위 정할 때 쓴다. 어떤 기능을 먼저 개선할지. 2. 일자별 트렌드 SELECT DATE(created_at) as date, COUNT(*) as count FROM user_actions WHERE action_type = 'purchase' AND created_at >= '2024-11-01' GROUP BY DATE(created_at) ORDER BY date그래프 그릴 때 쓴다. 트렌드를 본다. 3. 유저 세그먼트별 비교 SELECT u.user_tier, COUNT(DISTINCT o.user_id) as purchasers, AVG(o.amount) as avg_amount FROM users u LEFT JOIN orders o ON u.user_id = o.user_id WHERE o.created_at >= '2024-11-01' GROUP BY u.user_tier페르소나별 차이를 본다. VIP는 어떻게 쓰나. 일반 유저는 어떤가. 4. 퍼널 분석 SELECT COUNT(DISTINCT CASE WHEN step = 'view' THEN user_id END) as views, COUNT(DISTINCT CASE WHEN step = 'click' THEN user_id END) as clicks, COUNT(DISTINCT CASE WHEN step = 'purchase' THEN user_id END) as purchases FROM user_funnel WHERE date >= '2024-11-01'어디서 이탈하나. 어느 단계를 개선해야 하나. 5. 코호트 리텐션 WITH first_action AS ( SELECT user_id, MIN(DATE(created_at)) as first_date FROM user_actions GROUP BY user_id ) SELECT fa.first_date, COUNT(DISTINCT fa.user_id) as cohort_size, COUNT(DISTINCT CASE WHEN DATE(ua.created_at) = fa.first_date + INTERVAL 7 DAY THEN ua.user_id END) as week_1_retained FROM first_action fa LEFT JOIN user_actions ua ON fa.user_id = ua.user_id GROUP BY fa.first_date이건 좀 복잡하다. 개발자가 도와줬다. 근데 이제 이해한다. 이 5개면 웬만한 건 커버된다. 나머지는 응용이다. 틀리는 것도 배움이다 처음엔 많이 틀렸다. SELECT COUNT(user_id) FROM users WHERE signup_date > '2024-11-01'이게 왜 안 되지? 10분을 고민했다. 칼럼명이 틀렸다. signup_date가 아니라 created_at이었다. SELECT user_id, COUNT(*) FROM orders GROUP BY user_id HAVING COUNT(*) > 5이건 왜 느리지? 3분이 걸렸다. 인덱스가 없었다. 개발자가 알려줬다. "WHERE 절에 자주 쓰는 컬럼은 인덱스가 있어야 빨라요." 배웠다. 메모했다. JOIN을 처음 썼을 때. SELECT u.name, o.amount FROM users u, orders o WHERE u.user_id = o.user_id결과가 이상했다. 중복이 너무 많다. LEFT JOIN을 써야 했다. INNER JOIN과 뭐가 다른지. 그때 알았다. 틀릴 때마다 검색했다. 스택오버플로우, 블로그, GPT. 그렇게 3개월이 지났다. 이제는 A/B 테스트도 직접 본다 마케터가 물었다. "A안이 나아요, B안이 나아요?" 전에는 데이터팀에 요청했다. 이제는 직접 본다. SELECT variant, COUNT(DISTINCT user_id) as users, COUNT(DISTINCT CASE WHEN converted = 1 THEN user_id END) as conversions, ROUND(100.0 * COUNT(DISTINCT CASE WHEN converted = 1 THEN user_id END) / COUNT(DISTINCT user_id), 2) as cvr FROM ab_test_results WHERE test_id = 'homepage_cta_test' GROUP BY variant결과가 나왔다.A안: CVR 3.2% B안: CVR 4.1%"B안이 27% 더 높네요." 마케터가 놀랐다. "어떻게 이렇게 빨리?" "SQL 좀 배웠어요." 30분이면 끝난다. 전에는 하루 이틀 걸렸다. 속도가 경쟁력이다. 빠르게 확인하고, 빠르게 결정하고, 빠르게 실행한다. SQL이 이걸 가능하게 했다. 여전히 데이터 분석가는 아니다 착각하면 안 된다. 나는 여전히 기획자다. 복잡한 통계 분석은 못 한다. 회귀분석, 머신러닝, 이런 건 데이터팀의 영역이다. 내가 하는 건 '기본 집계'다.COUNT: 몇 개 SUM: 합계 AVG: 평균 GROUP BY: 그룹별로 JOIN: 테이블 연결이 정도만 쓴다. 근데 이게 내 일의 80%를 커버한다. 나머지 20%는 여전히 데이터팀에 요청한다. 그들의 전문성이 필요한 부분. 근데 그 20%를 요청할 때도 달라졌다. "이 두 테이블을 조인해서 이런 결과를 보고 싶은데, 제 쿼리가 맞나요?" 데이터 분석가가 말했다. "거의 맞는데 여기만 수정하면 돼요." 소통이 빨라졌다. 같은 언어를 쓴다. 기획자에게 SQL이 필요한 이유 정리해봤다. 내 경험 기준으로. 1. 속도 데이터팀 요청 → 대기 → 결과 받기: 2-3일 직접 쿼리: 5분 의사결정 속도가 10배 빨라진다. 2. 자율성 "이것도 가능할까요?" 하면서 눈치 볼 필요 없다. 궁금하면 바로 확인한다. 밤 11시에도. 3. 정확성 내가 원하는 게 뭔지 정확히 안다. 설명할 필요가 없다. "아 그게 아니라 이걸로 봐주세요" 하는 왕복이 사라진다. 4. 신뢰도 "데이터 기반으로 얘기하네" 하는 인식이 생긴다. 회의에서 발언권이 달라진다. 숫자로 말하니까. 5. 성장 데이터를 보는 눈이 생긴다. 어떤 지표가 중요한지. 어떻게 측정할지. 기획 실력이 올라간다. 당연히. 시작하는 법 주변 기획자들이 묻는다. "어떻게 시작했어요?" 내 방법은 이랬다. 1주차: 기본 개념SELECT, FROM, WHERE 유튜브 '생활코딩 SQL' 시리즈 하루 30분씩2주차: 실습 환경개발자한테 테스트 DB 권한 요청 DBeaver 또는 TablePlus 설치 우리 회사 테이블 구조 파악3-4주차: 기본 쿼리COUNT, SUM, AVG GROUP BY, ORDER BY 회사 데이터로 직접 실습2개월차: JOININNER JOIN, LEFT JOIN 테이블 두 개 연결하기 실무에서 자주 쓰는 패턴 익히기3개월차: 응용서브쿼리 CASE WHEN 날짜 함수여기까지면 충분하다. 나머지는 필요할 때 찾아보면 된다. 추천 자료 내가 실제로 도움받은 것들. 온라인 강의인프런 '모두를 위한 SQL' (입문) 유데미 'SQL for Data Analysis' (실무)책'모두의 SQL' (길벗, 입문자용) 'SQL 첫걸음' (한빛미디어)도구DBeaver (무료, 추천) TablePlus (유료지만 이쁨) SQL Fiddle (온라인 연습)커뮤니티생활코딩 SQL 오픈채팅방 데이터 분석 스터디 모임혼자 하면 힘들다. 같이 하는 사람을 찾아라. 3개월 후 오늘 주간회의. 대표님이 물었다. "이번 분기 KPI 진행률은?" 노트북을 열었다. 저장해둔 쿼리를 실행했다. "가입자 목표 대비 87%, 매출은 92% 달성 중입니다. 예상대로면 이번 주 목요일에 100% 도달합니다." 5초 만에 대답했다. 대표님이 웃었다. "준비성이 좋으시네요." 준비한 게 아니다. 매일 보고 있다. SQL로. 퇴근길에 생각했다. SQL을 배우기 전과 후. 전에는 데이터가 '누군가 주는 것'이었다. 이제는 '내가 뽑는 것'이다. 이 차이가 크다.데이터로 증명할 수 있다는 건, 내 의견이 아니라 사실로 말할 수 있다는 것이다. SQL은 그 도구다.

경쟁사 앱 분석, 퇴근 후의 나의 일상

경쟁사 앱 분석, 퇴근 후의 나의 일상

알림 울리면 조건반사 퇴근하고 집 와서 샤워하고 배달 음식 시켰다. 치킨. 지난주에도 치킨. 핸드폰 진동. 토스 업데이트. 또. 이번 주만 세 번째다. 일단 다운로드. "뭐가 바뀌었지?" 릴리즈 노트 읽는다. '사용자 경험 개선'이래. 구체적으로 뭔데. 앱 켜본다. 홈 화면. 레이아웃 바뀜. 주요 기능 위로 올렸네. 스크롤 깊이 줄였구나. 메뉴 구조 바뀜. 3뎁스를 2뎁스로. 똑똑하다. 신규 기능. '빠른 송금'. 최근 송금 내역에서 바로. 탭 수 2개 줄었네. 노트 앱 켠다. 스크린샷 5장 찍었다. 폴더에 저장. '토스_241204_홈개편'.치킨 먹으면서 본다. 노션 펼친다. '경쟁사 분석' 페이지. 토스, 카카오뱅크, 뱅크샐러드. 우리 앱도. 표 정리돼 있다. 업데이트 날짜, 변경 내용, 내 해석, 우리 적용 가능성. 토스 항목 추가한다. - 날짜: 2024.12.04 - 주요 변경: 홈 레이아웃 개편, 빠른 송금 추가 - 장점: 사용자 동선 단축, 주요 기능 접근성 상승 - 단점: 기존 사용자 혼란 가능성 (공지 없었음) - 우리 적용: 홈 개편 제안서에 벤치마크로 쓸 것이게 벌써 습관이다. 퇴근 후 루틴. 분석하는 나만의 프레임 노션에 템플릿 만들어뒀다. 6개월 전에. 처음엔 막 봤다. 그냥 '좋네', '별로네'. 그게 다였다. 3개월 차쯤 깨달았다. 체계 없으면 의미 없다는 걸.템플릿 구조는 이렇다. 1. 첫인상 (30초)뭐가 달라졌나 어디부터 눈에 들어오나 사용자가 제일 먼저 알아챌 변화2. UI 분석 (5분)레이아웃 변경점 컬러/폰트/아이콘 변화 정보 위계 구조 스크린샷 저장 (Before/After 비교)3. UX 분석 (10분)사용자 플로우 변화 (피그잼에 그림) 탭 수 계산 인터랙션 변경점 에러 처리 방식 온보딩 있는지4. 기능 분석 (10분)신규 기능 목록 개선된 기능 삭제된 기능 (있으면 주목) 핵심 기능과의 연결성5. 데이터 추론 (5분)왜 이렇게 바꿨을까 어떤 데이터를 봤을까 우리 데이터와 비교하면 효과 예상6. 적용 가능성 (5분)우리 서비스에 쓸 수 있나 바로 쓸 것 / 변형해서 쓸 것 / 참고만 제안서 작성 필요 여부 우선순위 (상/중/하)총 30분 이내. 더 길어지면 산으로 간다. 치킨 다 먹었다. 손 씻고 노트북 앞 앉는다. 오늘의 분석: 카카오뱅크 카카오뱅크 업데이트 어제 떴다. 아직 안 봤다. 다운로드. 로그인. 첫인상. 하단 탭바 바뀜. 5개에서 4개로. '혜택' 탭 없어짐. 재밌네. 혜택을 왜 뺐지. 사용률 낮았나. 아니면 홈에 통합했나. 홈 들어간다. 역시. 혜택 섹션 홈 중간에 있다. 스크롤 깊이 체크. 3.5스크롤. 전엔 혜택 탭 누르면 바로였는데. 사용자 입장. 혜택 보려면 홈 켜고 스크롤. 탭 하나 줄었지만 액션은 늘었다. 왜 이렇게 했을까.노션에 적는다. 가설 1: 혜택 탭 사용률 낮음 → 탭 공간 효율화 가설 2: 홈 체류 시간 늘리기 전략 (다른 기능 노출 위해) 가설 3: 주요 기능 집중 (송금/조회/카드)우리 앱은. 하단 탭 5개다. 홈, 거래내역, 혜택, 자산, 전체. 혜택 탭 사용률. 지난달 GA 데이터 봤었다. 8.3%. 낮다. 홈이 62%, 거래내역 21%, 자산 5.4%, 전체 3.3%. 혜택 빼면. 나머지 탭 더 눈에 띈다. 자산 탭 활성화 전략 쓸 수 있다. 메모 추가. 우리 적용 가능성: 상 - 다음 분기 홈 개편 때 혜택 통합 제안 - A/B 테스트 필요 (탭 4개 vs 5개) - 예상 효과: 홈 체류시간 15% 상승, 자산 탭 유입 20% 상승피그잼 켠다. 플로우 그린다. 기존: 홈 → 하단 혜택 탭 → 혜택 목록 (2탭) 변경: 홈 → 스크롤 → 혜택 섹션 (1탭 + 스크롤) 트레이드오프 명확하다. 접근성 vs 공간 효율. 우리 선택은 뭘까. 내일 팀 회의 때 물어볼 것. 다른 앱들도 체크 카카오뱅크만 보면 편향된다. 경쟁사 3개 이상은 봐야 트렌드가 보인다. 토스, 카카오뱅크, 뱅크샐러드. 오늘은 네이버 페이도. 네이버 페이 켠다. 2주 전 업데이트. 홈. 세로 스크롤에서 가로 캐러셀로 바뀜. 주요 기능 카드들. 스와이프로 빠르게 훑는다. 좋네. 우리 앱도 고민했었다. 세로 vs 가로. 결론은 세로였다. 정보량 많아서. 근데 네이버는 가로로 갔다. 왜. 앱 UX 컨셉이 다르다. 네이버는 '빠른 실행'. 우리는 '정보 제공'. 타겟도 다르다. 네이버는 20-30대 중심. 우리는 30-40대. 메모. 트렌드: 가로 캐러셀 증가 추세 - 토스: 하단 퀵메뉴 - 네이버: 홈 메인 - 카카오: 혜택 섹션이유 추정: - 모바일 네이티브 세대 증가 - 숏폼 콘텐츠 영향 (스와이프 익숙) - 정보 밀도 높이기우리 적용: 중 - 세로 레이아웃 유지하되 부분 적용 검토 - 이벤트/프로모션 영역에 캐러셀 테스트시계 본다. 밤 11시. 벌써. 분석 3개 끝. 30분씩 90분. 계획대로. 쌓이는 인사이트 노션 '경쟁사 분석' 페이지. 스크롤 내린다. 항목이 127개다. 6개월간. 처음엔 막막했다. '이거 언제 써먹지'. 근데 쓸 일 생긴다. 생각보다 자주. 지난달. 대표님이 물었다. "홈 개편하면 사용자 어떻게 반응할까요?" 자료 꺼냈다. 경쟁사 5개 홈 개편 사례. "토스는 체류시간 18% 올랐고, 카카오는 초기 이탈 12% 줄었습니다. 다만 뱅크샐러드는 첫 주 CS 문의 30% 증가했습니다." 대표님 표정 바뀌었다. "준비 많이 했네요." 아니다. 그냥 매일 보는 거다. 기획서 쓸 때도. 레퍼런스 찾는 시간 줄었다. 예전엔 구글링 1시간. 지금은 내 노션 10분. "이 기능 다른 데는 어떻게 구현했어요?" 폴더 열면 된다. 스크린샷 다 있다. 개발팀도 좋아한다. 말로 설명하는 것보다 화면 보여주는 게 빠르니까. "이런 느낌이에요. 토스처럼." "아 이거요? 가능하겠는데요." 대화 끝. 스펙 명확해진다. 데이터 없을 때도 쓴다. 우리 서비스는 신규라 데이터 적다. "이 기능 효과 있을까요?" "유사 사례 보면 전환율 5-8% 향상됐습니다." 근거 있는 추정. 아무것도 없는 것보단 낫다. 함정도 있다 주의할 것들. 6개월간 배웠다. 1. 맥락 없이 따라하기 경쟁사가 했다고 다 좋은 건 아니다. 그들의 사용자와 우리 사용자는 다르다. 서비스 단계도 다르다. 토스 따라했다가 망한 앱 많다. 토스는 토스니까 되는 거다. 우리 데이터, 우리 상황에 맞게 변형해야 한다. 2. 최신만 보기 새 업데이트만 쫓으면 트렌드 놓친다. 가끔 1-2년 전 버전도 본다. '왜 이렇게 바뀌었나' 흐름이 보인다. 서비스 진화 방향. 그게 더 중요하다. 3. 겉만 보기 화면만 보면 50%다. 실제로 써봐야 한다. 회원가입부터 주요 기능까지. 불편한 점, 좋은 점. 사용자 입장에서 느껴지는 게 진짜다. 4. 기록 안 하기 분석하고 머릿속에만 있으면 1주일 후 까먹는다. 기록해야 쓴다. 체계적으로 쌓아야 자산이 된다. 귀찮아도 한다. 미래의 나를 위해. 효율 올리는 팁 30분 안에 끝내려면 방법이 있다. 매일 하지 않는다 업데이트 알림 올 때만. 주 2-3회. 매일 하면 번아웃. 일도 아닌데. 템플릿 따른다 즉흥으로 보면 시간 잡아먹는다. 정해진 틀. 30분 타이머. 끝나면 끝. 스크린샷 깔끔하게 폴더 구조 정리.경쟁사별 폴더 날짜_기능명으로 파일명 관련 파일끼리 묶기나중에 찾기 쉽다. 핵심만 메모 장황하게 쓰지 않는다. 변경점 이유 추정 우리 적용세 줄이면 된다. 주간 리뷰 일요일 저녁. 이번 주 분석 훑어본다. 패턴 보인다. "아, 요즘 다들 이런 거 하네." 그게 트렌드다. 월요일 회의 때 꺼낸다. 팀과 공유하기 혼자 보면 아깝다. 2주마다 '경쟁사 트렌드' 세션 연다. 30분. 슬랙에 요약 올린다. 📱 경쟁사 업데이트 (12/1-12/15)주요 트렌드: 1. 홈 레이아웃 간소화 (토스, 카카오) 2. 가로 캐러셀 증가 (네이버, 뱅크샐러드) 3. AI 추천 기능 강화 (토스, 케이뱅크)우리 적용 제안: - 홈 개편 시 레퍼런스로 활용 - Q1 로드맵에 캐러셀 실험 추가 검토반응 온다. 디자이너: "캐러셀 레퍼런스 더 주실 수 있어요?" 개발자: "이거 구현 난이도 어느 정도죠?" 팀장: "다음 스프린트 때 논의해봅시다." 공유하면 가치 생긴다. 혼자 알면 내 지식. 팀이 알면 회사 자산. 지라 티켓도 만든다. '경쟁사 벤치마크 반영' 나중에 기획서 쓸 때 티켓 링크 건다. 히스토리 남는다.노트북 닫는다. 자정 넘었다. 내일 데일리 스크럼 9시 반. 7시간 후. 경쟁사 앱 분석. 퇴근 후 루틴. 피곤하지만 안 하면 불안하다. 뒤처지는 것 같아서.

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

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

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