기획서가 떨어지면 나는 이렇게 합니다 — 일정이 터지지 않는 개발 프로젝트 운영법

기획서를 혼자 읽고 이해했다고 생각하는 순간이 제일 위험합니다. 문서에 명시되지 않은 전제와 우선순위가 반드시 존재하기 때문입니다. 기획서를 검토한 뒤 기획자 또는 상위 조직장과 반드시 대화 자리를 마련합니다.

이 자리에서 확인해야 할 세 가지:

• 필수 개발 범위 — 이번 배포에서 반드시 들어가야 하는 것과, 빠져도 되는 것을 명확히 구분합니다. "있으면 좋은" 기능에 일정을 허비하지 않기 위해서입니다.
• 주어진 시간 — 외부 일정(이벤트 론칭, 규제 대응, 타 팀 의존성 등)으로 인해 데드라인이 고정되어 있는지 먼저 파악합니다. 데드라인이 고정이면 범위를 조정해야 하고, 데드라인이 유연하면 정확한 추정을 기반으로 일정을 제안합니다.
• 함께할 팀원 — 나 혼자 하는 프로젝트인지, 팀원이 있다면 몇 명이고 어느 영역을 담당할 수 있는지 파악합니다. 초기 Task 분배와 병렬 작업 가능 여부가 여기서 결정됩니다.

기획서 전체를 처음부터 Task로 쪼개면 방향을 잃기 쉽습니다. 먼저 큰 카테고리를 먼저 도출하고, 그 안에서 세부 Task를 뽑아내는 방식을 씁니다.

예를 들어 알림 발송 파이프라인 프로젝트라면 카테고리는 이렇게 잡을 수 있습니다.

공수는 혼자 한다고 가정했을 때 0.5day 단위로 작성합니다. 0.5day(반나절)보다 작은 단위로 나누면 오버헤드가 커지고, 1day보다 큰 단위로 묶으면 추정 오차가 커집니다. 이 granularity가 실제로 가장 잘 맞았습니다.

모든 Task의 공수를 합산해 총 개발 일수를 구합니다. 이것이 T-shirt Sizing — 소(S), 중(M), 대(L), 특대(XL) 중 어느 규모인지 판단하는 기준이 됩니다. 전체 공수가 윤곽이 잡히면 거기에 30% 버퍼를 추가합니다.

이론상 순수 개발에만 집중할 수 있는 날은 전체 근무일의 약 70% 수준입니다. 나머지 30%는 위와 같은 항목들로 자연스럽게 소모됩니다. 버퍼 없이 짠 일정은 항상 터집니다. 30% 버퍼는 안전망이 아니라 현실을 반영한 계획입니다.

예를 들어 순수 개발 공수가 13.5day라면:

• 버퍼 포함 추정: 13.5 × 1.3 ≈ 약 18day (약 3.5주)
• T-shirt 사이즈: M 규모

총 공수가 나오면 배포 목표일을 확정하고, 거기서 역산으로 각 마일스톤 일정을 뽑아냅니다. 순서대로 기획하면 현실적이지 않은 뒷단 일정이 생기기 쉽습니다. 역산은 각 단계에 필요한 최소 기간을 보장하면서 데드라인을 지킬 수 있게 해줍니다.

일정 확정 시 반드시 명시해야 할 마일스톤:

• 코드 완료일 (Code Complete) — 개발이 완전히 끝나는 날. 이후 신규 기능 추가는 없습니다.
• 개발자 테스트 완료일 — 개발자가 직접 시나리오 기반 테스트를 돌리는 기간. QA에 넘기기 전 버그를 걸러냅니다.
• QA 시작일 / 완료일 — QA팀과 일정을 사전에 협의합니다. QA는 항상 큐가 있으므로 늦게 통보하면 병목이 됩니다.
• 최종 배포일 — 인프라 팀, 운영팀과 사전 조율이 필요한 경우 최소 1~2주 전에 공유합니다.

일정이 잡히면 혼자 확정하지 않습니다. 상위 조직장과 별도 미팅을 잡아 일정표와 Task 목록을 공유합니다. 이 자리의 목적은 "보고"가 아니라 "조율"입니다.

• 조직장이 알고 있는 외부 제약(타 팀 의존성, 경영진 요청 데드라인 등)을 파악합니다.
• Task를 함께 검토하면서 빠진 항목이나 과도하게 잡힌 항목을 걸러냅니다.
• 팀원이 있다면 Task 분배와 병렬 처리 계획을 함께 논의합니다.
• 이 대화에서 "이 일정은 너무 촉박하다"는 피드백이 나온다면, 범위 조정 또는 인력 투입에 대한 의사결정을 이 시점에 가져옵니다.

조직장이 일정을 인지하고 있다는 것 자체가 강력한 리스크 완충재입니다. 이후 변수가 생겼을 때 이미 컨텍스트를 공유한 상태이므로 빠른 의사결정이 가능합니다.

일정을 한 번 세우고 잊어버리면 의미가 없습니다. 주 1회 정기 리뷰를 통해 계획 대비 실제 진행 상태를 점검합니다.

리뷰에서 확인하는 항목:

• 진행률 vs 계획 — 완료된 Task를 체크하고, 이번 주 목표 달성 여부를 확인합니다.
• Blocked 항목 — 진행이 막힌 Task가 있다면 원인과 해소 방안을 정의합니다. 외부 의존성이라면 에스컬레이션 여부를 결정합니다.
• 리스크 분석 — 현재 페이스로 코드 완료일을 지킬 수 있는지 판단합니다. 슬리피지(지연)가 감지되면 즉시 조직장에게 공유하고 범위 조정 또는 지원 여부를 논의합니다.
• 다음 주 계획 — 다음 주에 완료해야 할 Task와 우선순위를 명확히 정합니다.

"일정 지연의 9할은 '이미 알고 있었지만 말하지 않았던' 문제에서 온다. 작은 신호를 무시하지 않는 것이 전부다."

방법론이 아무리 좋아도 실행 도구가 엉망이면 유지되지 않습니다. 저는 두 가지 도구로 프로젝트를 관리합니다.

Jira 활용 원칙:

• Step 2에서 도출한 모든 Task를 Jira 티켓으로 생성합니다. 구두로만 존재하는 Task는 없어야 합니다.
• 각 티켓에는 예상 공수(Story Points)를 기재해 번다운 차트로 진행률을 추적합니다.
• 티켓 상태는 To Do → In Progress → In Review → Done으로 실시간 업데이트합니다. 일주일에 한 번 정리하는 방식은 통하지 않습니다.

Wiki 활용 원칙:

• 개발하면서 결정한 모든 정책과 스펙은 Wiki에 기록합니다. "왜 이렇게 구현했는가"를 3개월 뒤 팀원이 이해할 수 있어야 합니다.
• 기획서에서 불명확했던 엣지케이스와 그 처리 방식도 남깁니다. 코드 안에만 있는 지식은 팀의 자산이 아닙니다.
• Jira 티켓에 Wiki 링크를 걸어, Task와 상세 문서가 연결되도록 합니다.