헐.. 얼마나 더 걸리는데요?(일정지연 대처하기)
일정지연 원인 알아보고 적절히 대처하기
문제가 생기고 일정이 지연되는 일은 권장사항은 아니지만, 자주 발생한다. 예상하지 못한일이 발생하기 마련이고 의심하지 않았던 부분에서 문제도 발생한다. 일정 지연이 발생하지 않도록 계획을 세우는것 만큼 이슈가 발생했을때 적절히 대처하는것이 중요하다.
게임사에서 맡았던 프로젝트 중에 A게임이 있었다. 시장에서 잘 알려진 제작사가 개발했고 다른 플랫폼에서 이미 좋은 평가도 받은 기대작이었다. 오픈 3달을 앞두고 프로젝트 멤버들이 꾸려졌다. 차근차근 서비스를 준비하던중 QA팀에서 간간이 경고 메시지를 알려왔다. 온라인게임의 필수요소들이 미완성 상태이며 게임 빌드가 나오는 일정과 계획한 작업들의 반영속도를 봤을때 제시간에 개발완료가 될 수 있는지 걱정된다고 했다. 전달받은 사업팀은 외부개발사와 소통했고 회의 결과를 디브리프하며 이슈 없을거라고 이야기했다. 하지만 내가 감지하기에 개발사는 온라인게임에 필수요소인 커뮤니티와 편의기능에 대해 우선순위가 높다고 판단하지 않고 있었고, 동시에 필요한 작업을 수행해 낼 개발자 리소스도 충분하지 않은 상황이었다. 오픈 2주를 앞두고 QA팀은 현 상태로 오픈할 수 없다는 의사결정을 내렸다. 예상한대로 유저들이 소통할수 있는 기능들은 오픈이 코앞에 다가왔어도 미완성 상태였다.
대책회의가 열렸고 결과는 오픈을 1달 뒤로 미루되 개발사에서 못 하겠다고 알려온 부분에 대해서 웹에서 기능을 구현하는 방향으로 설정됐다. 개발이야 할 수 있지만 주요 기능이 웹에서 구현되면 유저가 너무 불편할거라는 생각에 반대의견을 냈지만 소용없었다. 급한 일정에 맞춰 부랴부랴 친구 접속여부 확인/채팅/주요일정 확인 캘린더 등 기능을 만들었다. 사용자는 게임을 하다가 웹에있는 기능을 사용하려면 Alt+Tab을 눌러 게임밖으로 나와야했다. 나중에 인게임 웹브라우저로 대체되었지만 사용자의 반응은 냉담했고, 오픈한지 1년만에 서비스를 종료했다. 일정의 지연은 발생할 수 있다. 하지만 위 사례를 봤을때 적절한 시점에 정확한 진단을 내려 적절히 대처할 수 있는 기회는 있었다고 생각한다. 만약 앞으로 프로젝트를 진행하다가 일정 지연이 감지되었을때 어떻게 대처해야할지 알아보자.
일정지연의 정확한 원인 진단하기.
왜 일정지연이 발생하는지 주요 지점을 미리 알아두면, 빠르게 감지하는데 도움이 된다. 우선 인력(리소스)가 부족한건 대표적인 지연 요소이다. 일정을 협의하는 시점에는 합리적으로 소요시간을 산정해 결정했더라도 중간에 프로젝트 멤버가 업무로 차출 된다거나 다른 이슈들이 발생해 해야할 업무목록에 새치기해서 들어오면 물리적인 시간은 줄어들고 자연스럽게 일정지연의 요소가 된다.
개발도중 예상하지못한 기술적 어려움이 발생할 수도 있다. 일정 산정 시점에 사용하려고 생각한 라이브러리가 특정 버전 이상에서만 사용이 되는데, 우리 시스템은 옛날버전이라 사용이 불가능한 경우가 여기 해당한다. 동료들이 만들어둔 프로그램을 재사용하려고 했으나 사용하려고 열어보니 엉망진창이라 도저히 사용할수 없어 다시 만들어야하는 경우도 심심치않게 있다. 이럴때마다 개발일정을 몇시간단위로 추가해달라고 요청할 수 없으니, 이역시 쌓이다보면 일정지연의 원인이 된다.
프로덕트의 설계가 발목잡는 경우도 있을 수 있다. 초기에 설계한 범위 밖의 스펙을 개발해야하는 상황이 생기면 데이터베이스 테이블 설계를 새로 해야할 수 있고 전체 설계를 바꿔야 할 수도 있다. 간단하게 라면을 하나 끓여먹으려고 냄비에 물을 받아서 끓이는 도중에 냉장고에 있던 바지락이 몇개 있다는걸 발견한 상황을 상상해보자. 처음에는 바지락을 몇개 넣어서 국물을 조금 시원하게 해볼까? 하며 시작했지만 국물을 내다보니 그냥 라면으로 끝내기는 아깝다는 생각에 메인재료로 승격시켜 바지락술찜이나 최소한 바지락이 메인이 된다면 고쳐야할것이 많아진다. 준비한 작은 냄비는 큰 것으로 교체 해야하고 레시피도 찾아봐야하며 들어가는 재료도 더 준비해야한다. 더 맛있는 식사가 될 수는 있겠지만, 계획한 시간보다 훨씬 더 많은 시간이 걸리는건 피할 수 없는 일이 된다. 이처럼 설계된 바를 넘어선 기획은 프로젝트 일정에 지연요소가 될 수 있다.
이 외에도 함께 일하고있는 협력사에서 예상치못한 문제를 일으켜 며칠동안 아무것도 할 수 없는 상황에 빠지거나 새로운 규제법안이 발효되는 등 지연이 발생할 수 있는 많은 원인들이 있다. 각 원인별로 대응방식은 달라야 하며 미리 진단하기 위한 방법들도 준비해야한다.
조기 경고신호 감지와 즉각 대응
프로젝트 리듬과 흐름을 이해하는 것은 일정 지연의 조기 경고 신호를 감지하는 첫 단계다. 처음 조직에 합류하면 일하는 리듬을 파악하는데 시간이 걸린다. 하지만 점차 팀의 속도와 패턴을 이해하게 되면, 무언가 잘못되고 있다는 신호를 더 빨리 알아차릴 수 있다. 예를 들어, 일반적으로 2일 걸리던 작업이 갑자기 1주일 이상 지연된다면, 이는 분명한 경고 신호다.
일정 지연의 조기 경고 신호는 다양한 형태로 나타난다. 가장 흔한 신호로는 데일리 스크럼이나 주간 보고에서 동일한 작업이 반복적으로 언급되는 경우가 있다. "아직 작업 중입니다"라는 말이 여러 번 반복된다면 주의 깊게 살펴볼 필요가 있다. 또한 개발자가 갑자기 기술적 용어를 과도하게 사용하며 설명하거나, 질문에 명확히 답변하지 않고 회피하는 모습을 보인다면 문제가 있을 가능성이 높다.
QA 팀의 피드백은 특히 중요한 조기 경고 신호다. A게임 사례에서 보았듯이, QA 팀은 종종 최종 사용자 관점에서 제품을 평가하기 때문에 실제 문제점을 가장 먼저 발견하는 경우가 많다. QA 팀이 "이 기능은 사용자 경험에 문제가 있다" 또는 "이 상태로는 출시할 수 없다"고 말한다면, 이는 단순한 의견이 아닌 심각한 경고 신호로 받아들여야 한다.
경고 신호를 무시했을 때의 결과는 A게임 오픈 지연 사례에서 확인했다. 초기 경고를 무시하고 계속 진행한 결과, 출시 직전에 큰 위기를 맞았고, 타협안으로 인해 사용자 경험이 저하되었으며, 결국 조기 서비스 종료라는 결과를 맞았다. 경고 신호를 조기에 인식하고 대응했다면, 더 나은 결과를 얻었을 가능성이 높다고 생각한다.
조기 감지를 위한 모니터링 시스템을 구축하는 것도 중요하다. 이는 공식적인 보고 체계일 수도 있고, 비공식적인 소통 채널일 수도 있다. 예를 들어, 지라 티켓을 보고 진행 상황을 직접 체크하거나 작업자들이 스스로 리스크 를 리포트하는 공식적인 자리를 만들어활용할 수 있다. 또한 개발자들과의 1:1 대화 시간을 정기적으로 가져 솔직한 피드백을 들을 수 있는 환경을 조성하는 것도 효과적이다.
경고 신호를 감지했다면 즉각적인 대응이 필요하다. 첫째, 문제의 심각성과 영향 범위를 빠르게 평가해야 한다. 둘째, 관련 이해관계자들에게 투명하게 상황을 공유해야 한다. 셋째, 해결 방안을 모색하기 위한 소규모 태스크포스를 구성하면 효과적이다. 이때 중요한 것은 비난이나 책임 추궁이 아닌, 문제 해결에 초점을 맞추는 것이다. A게임 사례로 돌아가보면, QA 팀의 초기 경고를 받았을 때 즉시 개발사와 함께 핵심 기능의 우선순위를 재조정하고, 필요하다면 일정 조정을 더 일찍 결정했다면 더 나은 결과를 얻었을 수 있었을 것이다. 결국 조기 경고 신호 감지와 즉각 대응은 프로젝트 성공의 핵심 요소 중 하나다.
투명한 커뮤니케이션과 회의 최소화 전략
일정 지연이 감지되었을 때 가장 중요한 것은 투명한 커뮤니케이션이다. 문제를 숨기거나 축소하는 것은 결국 더 큰 위기로 이어진다. “우리가 계획했던 일정보다 2주 정도 지연될 것 같습니다”라고 솔직하게 말하는 것이 “아직 진행 중입니다”라는 모호한 표현보다 훨씬 건설적이다. 투명한 소통은 신뢰를 구축하고, 모든 이해관계자가 현실적인 기대치를 가질 수 있게 한다.
그러나 여기서 주의해야 할 역설적 상황이 있다. 일정 지연 문제를 해결하기 위해 소집된 회의가 오히려 개발자들의 실제 문제 해결 시간을 빼앗는 경우가 많다. 개발자들이 코드를 작성하고 버그를 수정하는 대신, 회의실에 앉아 상황 설명을 반복하는 데 시간을 쓰게 되면 일정은 더욱 지연된다. 이는 문제를 해결하려는 시도가 오히려 문제를 악화시키는 전형적인 사례다.
효과적인 회의 최소화 전략으로는 다음과 같은 방법이 있다. 첫째, 의사결정권자와 필수적인 인원만 회의에 참여하도록 통제해야 한다. “이 문제에 대해 의견을 제시하거나 결정을 내릴 수 있는 사람만 참석해주세요”라는 원칙을 세우면 불필요한 참석자를 줄일 수 있다. 둘째, 불가피한 회의는 스탠딩 미팅 형식으로 짧게 진행한다. 셋째, 회의 전에 명확한 안건과 목표를 설정하고, 이를 벗어나는 논의는 별도로 다루도록 한다.
일정 지연 상황에서 가장 피해야 할 것은 ‘마녀사냥’이다. “누구 때문에 이렇게 되었나?“라는 질문은 문제 해결에 전혀 도움이 되지 않으며, 오히려 팀의 사기를 저하시키고 방어적인 태도를 유발한다. 대신 “어떻게 하면 이 상황을 함께 해결할 수 있을까?“라는 접근법을 취해야 한다. 책임 소재를 따지는 것은 문제가 완전히 해결된 후, 재발 방지를 위한 회고 과정에서 건설적인 방식으로 다루어야 한다.
마지막으로, 일정 지연 상황에서도 정기적인 진행 상황 공유는 필수적이다. 다만 이것이 개발 시간을 침해하지 않도록 간결하고 효율적인 형태여야 한다. 예를 들어, 매일 오전 10분간의 스탠드업 미팅이나, 주 2회 15분간의 진행 상황 보고 등의 형식이 효과적이다. 이러한 정기적인 소통은 추가적인 지연을 조기에 감지하고, 모든 이해관계자가 같은 페이지에 있도록 돕는다.
상황별 신속 대응 전략
일정 지연의 원인이 정확히 진단되었다면, 상황에 맞는 신속한 대응이 필요하다. 각 상황별 대응 전략을 살펴보자.
첫째, 인력 부족 문제가 발생했을 경우다. 이는 양적인 문제로, 해결 방법은 크게 두 가지다. 하나는 외부 리소스를 투입하는 것이다. 프리랜서 개발자 고용, 협력사 지원 요청, 또는 다른 팀에서 일시적으로 인력을 차출하는 방법 등이 있다. 다른 하나는 범위를 축소하는 것이다. 모든 기능을 구현하는것을 잠시 접어두고 핵심 기능에만 집중하여 일정 내에 완료하는 전략이다. 출시 일정을 조정하거나, 정말 필수적인 기능만 선별하여 게임 내에 구현하는 방법이 있을 수 있다.
둘째, 기술적 난관에 직면했을 경우다. 이는 질적인 문제로, 전문가 자문이나 대안 기술 검토가 필요하다. 예를 들어, 특정 알고리즘이 예상보다 복잡하거나 성능 이슈가 발생한 경우, 해당 분야 전문가의 도움을 받거나 다른 접근 방식을 검토해야 한다.
셋째, 구조적 한계가 발견된 경우다. 설계나 아키텍처에 한계가 인지되었다면 다시 검토 하거나 단계적 구현계획을 세울 필요가 있다. 예를 들어, 초기 설계가 확장성 요구사항을 충족하지 못하는 것으로 밝혀진 경우, 전체 아키텍처를 재설계하거나 단기적 해결책과 장기적 개선 계획을 분리하여 접근할 수 있다. 담당하던 프로젝트에서 트랜잭션 처리 시스템의 구조적 한계가 발견되어 기획내용을 모두 담기 어려운 일이 있었다. 이때 완전한 재설계 대신 기획을 바꿔서 현재 설계의 한계 안에서 최적화하고 동시에 새로운 아키텍처로의 전환 계획을 수립했다. 최종 개선을 이루는데는 오랜시간이 걸렸지만 구성원들의 동의를 얻고 안전하게 제품을 발전시킬 수 있었다.
넷째, 외부 의존성 문제가 발생한 경우다. 이는 3rd party 연동 등의 문제로, 대체 솔루션이나 내재화를 검토해야 한다. 예를 들어, 외부 API 서비스가 불안정하거나 예상과 다르게 작동하는 경우, 다른 서비스로 전환하거나 해당 기능을 직접 구현하는 방안을 고려할 수 있다. 외부에 의존성이 있는 API들은 언제든 문제가 발생할 수 있다는 인식을 하고 플랜B를 항상 염두해 둘 필요가 있다.
각 상황별 대응 전략의 핵심은 문제를 정확히 파악하고, 가능한 해결책의 장단점을 신속하게 평가한 후, 현실적인 대안을 선택하는 것이다. 이 과정에서 기술적 완벽함과 비즈니스 요구 사항 사이의 균형을 찾는 것이 중요하다.
우선순위 조정과 범위 조정의 기술
일정 지연이 불가피한 상황에서는 우선순위 재설정과 범위 조정이 필수적이다. 이는 단순히 기능을 줄이는 것이 아니라, 전략적으로 무엇을 유지하고 무엇을 포기할지 결정하는 과정이다.
80/20 법칙(파레토 법칙)은 이러한 상황에서 매우 유용하다. 이 법칙에 따르면, 20%의 기능이 80%의 가치를 창출한다. 따라서 일정 지연 상황에서는 이 핵심 20%에 집중하는 것이 현명하다. 예를 들어, A게임 사례에서 모든 커뮤니티 기능을 구현하기보다 게임 플레이에 직접적인 영향을 미치는 핵심 기능만 선별했다면, 더 나은 사용자 경험을 제공할 수 있었을 것이다.
MVP(최소 기능 제품) 접근법도 효과적인 전략이다. 이는 제품의 핵심 가치를 전달할 수 있는 최소한의 기능 세트를 정의하고, 이를 우선적으로 구현하는 방식이다. 나머지 기능은 후속 업데이트로 미루는 것이다. 이 접근법은 특히 신규 서비스 출시 시 유용하다. 초기 버전에는 계획했던 고급 편의기능 대신 기본적인 사용자 기능에 집중함으로써, 출시 일정을 맞추고 이후 사용자 피드백을 기반으로 후속 개발 방향을 결정할 수 있다.
범위 축소 시 고려해야 할 요소로는 사용자 영향, 비즈니스 가치, 기술적 의존성, 마케팅 약속 등이 있다. 특히 이미 외부에 공개된 기능은 제외하기 어려울 수 있으므로, 초기 커뮤니케이션 시 유연성을 확보하는 것이 중요하다.
이해관계자와의 범위 조정 협상도 중요한 기술이다. 이때는 데이터와 사실에 기반한 논의가 효과적이다. “이 기능을 포함하면 출시가 2주 지연됩니다”와 같이 구체적인 영향을 제시하고, 대안과 트레이드오프를 명확히 설명해야 한다. 또한 범위 축소가 단순한 ‘포기’가 아닌 ‘전략적 선택’임을 강조하는 것이 중요하다.
결론: 일정 지연을 통한 학습과 성장
일정 지연은 프로젝트 관리에서 피할 수 없는 현실이지만, 이를 실패로 간주하기보다는 학습과 성장의 기회로 삼아야 한다. 일정 지연 자체보다 이에 대한 대응 방식이 프로젝트의 성공과 실패를 가른다.
프로젝트 회고(Retrospective)는 일정 지연 경험에서 교훈을 도출하는 중요한 과정이다. "무엇이 잘 작동했는가?", "무엇이 잘 작동하지 않았는가?", "다음에는 무엇을 다르게 할 것인가?"라는 세 가지 질문을 중심으로 솔직한 논의를 진행해야 한다. 이 과정에서 비난이 아닌 학습에 초점을 맞추는 것이 중요하다.
도출된 교훈은 반드시 문서화하고, 다음 프로젝트에 적용할 구체적인 개선 사항으로 발전시켜야 한다. 예를 들어, A게임 사례에서는 "QA 팀의 경고 신호를 더 진지하게 받아들이고, 개발사의 리소스 상황을 더 면밀히 모니터링하며, 사용자 경험을 저해하는 타협안은 신중하게 검토한다"와 같은 교훈을 도출할 수 있다.
일정 지연 관리의 핵심은 빠른 인지, 정확한 진단, 적절한 대응이다. 문제가 발생했을 때 이를 숨기거나 무시하는 것이 아니라, 빠르게 인정하고 투명하게 소통하며, 상황에 맞는 대응 전략을 수립하는 것이 중요하다.
마지막으로, 장기적 관점에서의 제품 성공을 위한 균형 잡힌 의사결정이 필요하다. 단기적인 일정 준수와 장기적인 제품 품질 사이에서 적절한 균형점을 찾아야 한다. A 프로젝트가1년 만에 서비스를 종료한 것은, 출시 일정을 맞추기 위한 단기적 결정이 장기적 성공을 저해했음을 보여주는 사례다.
결국, 일정 지연은 프로젝트 관리의 일부분이며, 이를 효과적으로 다루는 능력은 뛰어난 PM이 갖추어야 할 핵심 역량이다. 지연 상황을 두려워하기보다는, 이를 통해 더 나은 프로젝트 관리자로 성장하는 기회로 삼아야 할 것이다.
