SI 일정 지연, 도대체 왜 반복될까?

SI 프로젝트에 일정 지연이 따라붙는 건 더 이상 뉴스도 아니다. 프로젝트 킥오프 할 땐 다들 자신 있어 한다. 일정표도 말끔하게 짜여 있고, 계획도 훌륭하다. 그런데 이상하게도, 시간이 흐를수록 일정은 밀리고, 야근이 시작되고, 마감은 '이행일 기준'이라는 이름 아래 유예된다. 16년 동안 프로젝트를 겪어오면서, 이 일정 지연의 패턴은 생각보다 단순하지만 깊은 이유들이 있다.

원인은 '기술'보다 '사람'에서 시작된다

많은 사람들이 일정 지연의 원인을 기술적인 난이도에서 찾는다. API가 늦게 나왔네, 서버 세팅이 꼬였네, 연동 시스템이 예고 없이 바뀌었네 등. 물론 이런 문제들도 일정에 영향을 준다. 하지만 실제로 깊게 들어가 보면, 문제의 본질은 기술보단 '사람' 쪽에서 시작된다.

가장 흔한 건 요구사항의 불명확함이다. 처음엔 고객도 잘 모른다. 뭐가 필요한지, 어디까지 구현돼야 하는지. 그래서 애매하게 정의된 상태로 분석이 시작되고, 그 상태로 설계가 이어진다. 개발까지 끝났을 무렵, '이건 우리가 원한 게 아니다'라는 말이 나온다. 다시 고치고, 다시 설명하고, 다시 테스트. 이 반복만으로도 몇 주는 순식간이다.

커뮤니케이션, 그 사소하지만 결정적인 변수

SI에서는 PM, PL, 개발자, 고객, 외주업체, 연동업체 등 다양한 사람들이 얽힌다. 이들 사이의 커뮤니케이션이 조금만 어긋나도, 일정은 쉽게 무너진다. 특히 이메일이나 회의록 없이 말로만 주고받은 내용이 나중에 문제가 되는 경우가 많다. "그때 그렇게 말하지 않았냐"는 말이 오갈 때쯤엔 이미 일정은 한참 뒤로 밀려 있다.

이런 문제를 줄이기 위해 문서화, 기록, 회의록 정리가 중요하다고는 하지만, 현실에선 여전히 우선순위가 낮다. 개발이 급하니까, 회의록은 나중에. 회의는 길어지니까, 요약은 생략. 이런 조그마한 생략들이 쌓여 결국 일정 지연이라는 결과로 돌아온다.

숨은 복병, 테스트와 이행

개발이 끝났다고 프로젝트가 끝나는 건 아니다. 오히려 진짜 문제는 테스트 단계에서 드러난다. 예외 상황 하나로 인해 전체 로직이 다시 바뀌는 경우도 있고, 고객사가 내부 규정을 이유로 기능 일부를 바꾸기도 한다. 이건 대부분 일정 후반에 생긴다. 그러니까 수정을 위한 시간이 빠듯하고, 야근과 주말 근무가 시작되는 시점이다.

게다가 이행 과정은 언제나 리스크를 안고 있다. 운영 서버 이슈, 데이터 이관 오류, 권한 설정 누락 같은 건 흔한 일이다. 이런 문제들은 일정표에는 보이지 않지만, 프로젝트 마지막을 위협하는 복병이다.

일정이란, 단순히 '언제까지'가 아니다

일정을 맞춘다는 건 단순히 날짜를 지키는 게 아니다. '누가', '무엇을', '어떻게', '왜' 해야 하는지를 명확히 해야 지킬 수 있다. 일정 지연은 결국 그 모든 질문이 흐릿할 때 생긴다.

그래서 지금은 일정이란 단어를 볼 때마다, '협업의 완성도'라는 말이 함께 떠오른다. 일정이 자주 밀리는 프로젝트는 결국 '함께 일하는 방식'이 잘 안 맞는 경우가 많았다. 기술보다 중요한 건 흐름이고, 흐름을 만드는 건 사람이다.

---

마무리하며
SI 일정 지연은 피할 수 없는 숙명일까? 아니다. 하지만 줄일 수는 있다. 그 시작은 계획보다 '합의', 속도보다 '정확함', 기술보다 '소통'에 있다는 걸 잊지 않아야 한다.