[개발 일정관리] #1 개발 일정관리는 왜 어려운가?

이 글은 ‘개발 일정관리'라는 주제로 연재하는 첫 번째 글입니다.

가장 두려운 질문

“언제까지 개발 가능하세요?”

내가 개발자로 일하면서 가장 답하기 곤란한 질문 첫 번째를 뽑자면 바로 위 질문이다. 나뿐만이 아닐 것이다. 주니어 때는 팀장으로부터 저 질문을 받을 것이고, 개발팀을 담당하게 되면 그 위의 매니저로부터, 그리고 개발부서 자체를 담당하게 되면 회사의 대표로부터 저 질문을 듣게 될 것이다. 즉 일정관리는 개발자의 삶을 시작하면서부터 결코 떼어놓을 수 없는 필수불가결한 요소가 되는 것이다.

일정관리가 두려운 이유

일정관리가 두려운 이유는 그것이 ‘미래'를 관리하는 일이며, 미래와 연관된 이상 ‘불확실성'이 따라온다는 것이다. 그리고 그 불확실성이 담보하는 것은, 사업 혹은 프로젝트의 ‘완료'와 직결된다는 아주 무거운 책임이다.

기획, 디자인, 개발 등으로 이루어진 개발프로세스에서, 개발은 대부분 끝에 위치한다. Waterfall 방식이 아니라 Lean, 혹은 Agile 방식 등에서 작은 싸이클로 나누어진 프로세스를 보더라도 어찌됐든 개발은 끝에 위치한다. 그리고 끝에 위치한다는 것은, 개발이 밀리면 프로젝트의 종결이 같이 지연된다는 것을 의미한다.

그게 다가 아니다. 프로젝트 전체의 일정에서 기획, 디자인 등 타 직군에 비해 개발의 리소스(개발에 투입되는 숫자, 개발 기간 등)가 훨씬 더 많이 들어가기에 해당 프로젝트의 일정에서 차지하는 지분율이 가장 높다.

2015년에 Standish CHAOS Report에서 발행된 리포트(https://www.standishgroup.com/sample_research_files/CHAOSReport2015-Final.pdf)에 따르면 Agile 방법론으로 진행한 소프트웨어 프로젝트의 61%가 deadline에 맞추지 못하거나 실패한다고 한다. 같은 문서에서 Waterfall 방식으로 개발했을 때를 보면 그 실패율은 더 올라간다. 개발 경험이 꽤 있는 사람은 이 통계가 전혀 과장되지 않았음을 알 수 있을 것이다. 어쩌면 ‘뭐? 39%나 제 시간에 맞춘다고?’라는 말이 나올지도 모르겠다.

이 위험성은 프로젝트의 규모가 커질수록 더 높아진다. 위 리포트에서도 큰 규모의 프로젝트이면서 복잡도가 높아지면 프로젝트의 성공률은 처참하게 낮아짐을 볼 수 있다.

수백 명의 개발자가 투입되는 흔히 말하는 ‘AAA급 게임’ 같은 경우, 일정이 늦춰지는 경우는 비일비재하며, 일정에 맞춰 나오더라도 버그 투성이인 경우가 상당하다. 업계 최고의 회사라도 예외가 아닌 것이다.

자, 그러면 정리해보자.

• 과반수 이상의 S/W 프로젝트가 일정을 맞추지 못한다.
• S/W 일정 전체에서 가장 큰 지분을 차지하고 있는 것은 개발 파트이다.
• S/W 프로젝트의 프로세스의 마지막에 개발이 위치한다.

이러한 사실을 보고 어떠한 생각이 드는가? 어떤 주식이 61% 확률로 주가가 내려갈 거라면, 나는 절대 투자하지 않을 것이다. 그만큼 일정을 제대로 맞춘다는 것은 쉽지 않은 일인데, 그 일정 지연의 가장 큰 책임은 개발이 담당하고 있으며, 그 위치 또한 마지막이다.

“한마디로 말해서, 성공하기 쉽지 않은 프로젝트의 가장 무거운 책임을 개발분야가 져야 한다는 것이다.”

사실이 이러할진대, 어찌 일정관리가 두렵지 않을 수 있을까?

개발 일정관리는 왜 쉽지 않은가?

개발 기간이 지연되는 데는 여러 가지 요소가 있지만, 크게 다음 2가지로 정리할 수 있겠다.

1. 최초 요구사항에 대한 일정 산정의 실패
2. 변화된 요구사항으로 인한 변수 대응 실패

두 가지 각각의 요소에 대해 좀 더 깊게 살펴보도록 하자.

1. 최초 요구사항에 대한 일정 산정의 실패

하루에 100개의 상품을 찍어내는 공장에서, 1만개를 찍어내기 위해 어느 정도의 일정이 필요한지 산정하는 것은 어려울 것이 전혀 없다. 공장이 불타거나, 직원들이 갑자기 파업하는 매우 특수한 상황 정도만 변수일 정도로, 변수도 매우 적은 편이다.

그러나 개발은 그렇지 않다. SRS(Software Requirement Specification, 소프트웨어 요구사양서)를 개발자가 작성하는 경우는 흔치 않다. 예를 들면, 그냥 ‘회원 가입 기능’을 요구한다. 그러나 개발 단계로 ‘회원 가입’을 구현하기 위해서는 고려해야 할 것들이 매우 많아진다.

로그인을 세션 방식으로 진행할 것인가? 토큰 방식으로 진행할 것인가? SNS 가입을 추가할 것인가? 본인인증을 넣어야 하는가? 이메일 인증을 넣어야 하는가? 문자 방식 인증을 진행하는가?

프로젝트를 시작할 때는, 이렇듯 구체적인 기획과 화면이 나오지 않은 이 SRS 단계에서,1차적인 개발 일정을 산정할 수밖에 없다. 설령 정확하게 UI/UX까지의 화면이 다 나와 있는 상태에서 개발 일정을 산정할 수 있는 행운을 누릴 수 있다고 해도, 그 산정은 사실 쉬운 일이 아닐텐데, 그조차도 없는 상황에서는 두말할 것도 없이 어려운 것이다.

그러나 다들 예상하다시피 이 최초의 일정은 위태롭기 그지 없다. 실제 기획과 디자인이 나오면, 해당 화면의 레이아웃과 UI/UX에 따라 개발 기간은 처음 산정한 것과 달라지기 마련이다. 개발 입장에서 8페이지 정도의 분량일거라 생각한 것이, 실제로 개발할 때가 되면 15페이지 분량이 되곤 하는 것은 흔한 일이다(안타까운 것은, 이러한 결과는 기획/디자인 쪽에서 ‘더 좋은 결과물’을 고객에게 주고자 하는 선한 동기로 인해 나타난다는 것이다).

결론을 내자면, 최초 요구사항에 대한 일정이 산정에 실패는, 그 산정을 하기 위한 ‘근거'인 요구사항이 명확하지 않기 때문인 경우가 크다는 것이다.

2. 변화된 요구사항으로 인한 변수 대응 실패

요구사항에 따른 개발일정을 환상적으로 잘 산정했다고 해도, 이 두 번째 문제는 여전히 가장 큰 두려움으로 남는다.

“요구사항은 변하기 마련이기 때문이다.”

나는 요구사항이 변하지 않는 프로젝트를 본 기억이 없다. 그런 프로젝트는 판타지 소설에나 나올 수 있을 것이다. 최초의 기획과 구성을 그대로 프로젝트 완료까지 가져갈 수는 없으며, 그것은 바람직하지도 않다.

기획의 신이 와서 기획해도, 기획은 변화할 것이며 변해야 한다. 마치 시장의 상황에 따라 내 투자 포트폴리오를 변경해야 하는 것처럼, 그것은 자명한 일이다.

그런데 여기서 가장 어려운 것은, 요구사항이 N만큼 변할 때, 개발은 N², 혹은 N³ 등 기하급수적으로 변화하곤 한다는 것이다. 이것은 그야말로 예측할 수 없는 일이다. 기획/디자인 쪽에서 페이지 하나 추가하고(혹은 빼고), 기능 하나 그려 넣는 것이 개발 쪽에서는 폭탄으로 돌아오기도 한다.

그런데 만약 요구사항이 2주일마다 추가되거나 변경된다고 하면, 그로 인해 개발 일정을 2주일마다 재산정하겠는가? 아니면 일정에 껴맞춰서 어떻게든 그것을 구현해내겠는가?

여기에는 많은 어려움이 있다. 일정 산출은 그 자체가 또 하나의 꽤 큰 업무에 해당한다. 변화된 요구사항을 분석하고, 실제로 어떤 식으로 구현해야 할지 개발자는 머리를 굴려야 한다. 의지력이 소모되며, 현재 진행하고 있는 개발 업무의 연속성에 영향을 준다. 그렇게 나온 일정을 WBS에 반영하거나 Jira 등에서 이슈수정을 하기도 해야 한다. 실제 개발에 써야 할 리소스가 분산되는 것이다.

일정 산출을 안 하고 그대로 밀고 가자니 문제가 만만치 않다. 이미 구현한 코드를 폐기하거나 변경해야 하는 것은 개발자에게 대단히 큰 스트레스이다. 리팩터링 급으로 아예 구조를 변경해야 하는 경우도 생긴다. 개발자의 사기가 떨어진다. 억지로 일정을 유지한다면 코드의 질이 떨어진다. 어떤 경우든, 이런 선택은 반드시 대가를 치르게 된다. 개발자의 눈치채기 어려운 태업이나 QA를 진행하는 시점에서 테스트 기간의 긴 연장 등으로 말이다.

그럼 요청을 거부해야 할까? 내가 프로젝트 담당자인데, 그 요청이 매우 합리적이고 서비스 품질 향상에 큰 영향을 주는 요청이라면? 혹은 대표/투자자로부터 직접 내려온 요청이라면?

정리해보겠다. 20챕터 짜리 책을 일주일에 1챕터씩 공부한다고 하면, 이 책을 끝내기 위한 일정을 산정하기는 매우 쉽다. 그러나 공부를 하고 있는데 갑자기 특정 챕터가 다른 챕터의 3배 정도의 양으로 변하고, 챕터 전체의 숫자도 중간마다 30챕터, 40챕터로 변경된다면? 심지어 이미 내가 끝냈던 챕터의 내용이 변경되어 다시 공부해야 한다면? 우리는 과연 이 책을 언제 끝낼 수 있을까? 이것이 개발 일정관리의 현실이다.

이렇듯, 개발 일정관리는 매우 어려운 일이다. 그러나 어려운 것은 어려운 것이고, 어려우니 ‘어쩔 수 없다'는 태도를 견지하는 것은 매우 비생산적이다. 향후 연재해나갈 글들을 통해서는 이러한 문제에 대한 대안을 제시하고 나의 경험을 나눠보도록 하겠다.