IT 프로젝트, 왜 항상 일정에 쫓기는가?
“시간이 없다”는 말, IT 프로젝트에서 하루에도 열 번은 듣습니다. PM은 조급하고, 개발자는 버거우며, QA는 테스트 일정이 밀려 화가 나 있죠. 그런데 왜 우리는 매번 이렇게 일정에 쫓길까요? 처음부터 부족한 일정이었을까요? 아니면 일정 관리 자체에 문제가 있었던 걸까요? 이 글에서는 SI 프로젝트 실무자이자 품질 관점에서, IT 프로젝트가 늘 일정에 쫓기는 근본적인 이유들을 들여다보고, 그 현실적 대안을 제시해보려 합니다.
목차
처음부터 잘못된 일정 산정
IT 프로젝트가 일정에 쫓기는 가장 큰 이유는, 애초에 일정이 '거꾸로 짜이기' 때문입니다. 계약일에 맞춰 거꾸로 배분한 일정은 실제 난이도, 리소스, 변수 등을 반영하지 못하죠. 특히 개발 일정은 주간 단위로 쪼개놓고 QA는 2~3일만 배정되는 경우도 허다합니다. 일정 산정은 '이론적 낙관'이 아니라 '실제 데이터 기반'이 되어야 합니다.
숨겨진 버퍼의 환상과 실체
“여기 일정은 넉넉하게 잡았어요”라는 말, 사실일까요? 실무에선 그 '버퍼'가 PM 마음속에만 존재하는 경우가 많아요. 특히 공공 프로젝트에서는 ‘낙찰 후 조정’이라는 이름으로 일정이 축소되는 일이 다반사죠. 실제 버퍼를 확보하려면 WBS 단계에서부터 명시적인 시간 블록으로 넣어야 합니다.
| 버퍼 종류 | 특징 | 위험 요소 |
|---|---|---|
| 심리적 버퍼 | PM 머릿속 예상 여유 | 팀원은 존재 자체를 모름 |
| 이력 기반 버퍼 | 유사 과제 평균 일정 기반 | 이전 과제와 다른 리스크 간과 |
| 문서상 버퍼 | 계획서에 명시된 완충 일정 | 실행 단계에서 삭제되는 경우 다수 |
작업 범위의 확장 – 스코프 크리프
“요 정도는 서비스 차원에서…”라는 말로 시작된 스코프 크리프는 일정의 가장 큰 적입니다. 초기 계획에는 없었지만, 고객의 요구 혹은 내부 판단으로 인해 기능이 추가되면서도 일정은 그대로 유지되죠. 품질 보장을 위한 QA는 ‘시간 없으니 나중에’로 밀려나기 십상입니다.
- 문서화되지 않은 요구 반영
- 내부 회의에서 은근히 정해진 기능
- 계약 외 요청에 대한 거절 실패
병렬화의 환상 – 모든 작업은 동시에 될까?
간트차트에서는 모든 작업이 깔끔하게 병렬로 진행됩니다. 하지만 실무에서는 의존성(Dependency)이라는 벽이 존재하죠. A기능 개발이 끝나야 QA가 들어가고, API가 나와야 프론트개발이 시작돼요. 일정이 병렬인 듯 보여도 사실상 직렬 구조일 때가 많습니다. 일정표가 실현 가능한 시나리오인지, 반드시 검토해야 합니다.
가장 많이 희생되는 QA 일정
일정이 밀릴 때 가장 먼저 줄어드는 건 QA 일정입니다. 개발이 하루 늦어지면 QA는 하루씩 줄어드는데, 문제는 이 영향이 고스란히 품질 저하로 이어진다는 점이죠. 특히 테스트 계획 없이 투입되는 경우, 테스트는 '하루짜리 작업'이 되어버립니다. QA 일정은 독립된 단계로 명확히 확보되어야 하며, 개발과 동일한 수준의 중요도를 가져야 합니다.
| 현상 | 문제점 | 영향 |
|---|---|---|
| QA 일정 후순위 배치 | 일정 밀릴 경우 QA 시간이 줄어듬 | 테스트 부실, 결함 미발견 증가 |
| 단일 QA 리소스 | 동시 다건 테스트 불가 | 병목 발생 및 일정 연쇄 지연 |
| 테스트 시나리오 부재 | 테스트 시작 후 작성 시작 | 결함 재현 어려움, QA 효율 저하 |
일정 계획 시 꼭 챙겨야 할 체크리스트
- 일정 산정 기준이 ‘추정’이 아닌 ‘이력 데이터’ 기반인가?
- 개발, QA, 검수 일정이 분리되어 있는가?
- 주요 의존성(Task Dependency)은 검토되었는가?
- 스코프 크리프 방지책(요구사항 변경관리)이 준비되었는가?
- 실제 여유 일정(Buffer)이 명시적으로 확보되었는가?
과거 유사 프로젝트 이력, WBS 기반 Task 분해, 인력 배치 등을 고려하여 산정합니다. 그러나 실제로는 계약일에 맞춰 ‘역산’되는 경우가 많습니다.
예산과 계약 기한을 맞추기 위한 ‘거꾸로 일정’은 프로젝트 리스크를 키울 수 있어요.
개발, 디자인, 테스트는 의존 관계가 존재하며, 하나의 결과물이 다음 작업의 입력이기 때문입니다. 병렬화는 이상적 시나리오일 뿐 실제에선 병목이 발생합니다.
‘병렬로 보이는 직렬 구조’는 일정 지연의 주요 원인이기도 해요.
일정 산정 기준을 ‘추정’이 아닌 ‘데이터 기반’으로 전환해야 하며, QA 일정을 독립적인 단계로 인정하고 보장하는 게 시작입니다.
정확한 산정 없이는 어떤 일정도 의미가 없어요. 특히 QA는 줄여도 된다는 인식부터 바꿔야 합니다.
과거 유사 프로젝트 이력, WBS 기반 Task 분해, 인력 배치 등을 고려하여 산정합니다. 그러나 실제로는 계약일에 맞춰 ‘역산’되는 경우가 많습니다.
예산과 계약 기한을 맞추기 위한 ‘거꾸로 일정’은 프로젝트 리스크를 키울 수 있어요.
개발, 디자인, 테스트는 의존 관계가 존재하며, 하나의 결과물이 다음 작업의 입력이기 때문입니다. 병렬화는 이상적 시나리오일 뿐 실제에선 병목이 발생합니다.
‘병렬로 보이는 직렬 구조’는 일정 지연의 주요 원인이기도 해요.
일정 산정 기준을 ‘추정’이 아닌 ‘데이터 기반’으로 전환해야 하며, QA 일정을 독립적인 단계로 인정하고 보장하는 게 시작입니다.
정확한 산정 없이는 어떤 일정도 의미가 없어요. 특히 QA는 줄여도 된다는 인식부터 바꿔야 합니다.
단축에 따른 리스크를 수치화하고, 기능 우선순위 조정 또는 리소스 추가로 대응 가능한 시나리오를 제시해야 합니다.
“예, 알겠습니다” 대신 “이 경우 기능 X는 제외해야 하며, QA는 병렬 운영이 필요합니다”라는 대응이 필요해요.
프로젝트 초기부터 QA 일정을 명확히 분리하고, 문서화하며, QA 활동이 전체 프로젝트 성공에 필수임을 이해시키는 교육이 필요합니다.
“테스트는 마지막 날 하는 게 아니다”라는 인식을 조직 전체가 공유해야 합니다.
IT 프로젝트 일정은 절대 우연히 정해지는 게 아닙니다. 잘못된 시작, 숨겨진 버퍼, 병렬화 착각, QA 희생... 이 모든 조각들이 일정 지연의 퍼즐을 만듭니다. 우리는 더 이상 ‘어쩔 수 없는 일정’을 핑계 삼을 수 없습니다. 데이터 기반의 일정 산정, 명확한 스코프 관리, QA의 독립적 지위 확보