안녕하세요. (주)이노핀의 CTO를 맡고 있는 김한울 입니다. 이번에 리멤버 인플루엔서 1기로 선정되면서, "꼭 개발 영역에 국한되지 않고 많은 분이 볼 수 있는 주제가 무엇일까?"라는 고민하다가 '개발 일정관리'라는 주제를 선정하게 되었습니다. 굉장히 방대한 내용의 주제이지만, 최대한 짧은 호흡으로 제가 시행착오를 하며 겪은 경험과 깨달음을 나누어보겠습니다.
편의상 본문은 말을 낮추어 글을 적겠으니 모쪼록 양해 부탁드립니다.
—
“언제까지 개발 가능하세요?”
개발자의 연차가 올라가면서 가장 답하기 곤란한 질문 Best에는 바로 이 질문이 포함될 것이다. 나뿐만이 아닐 것이다. 주니어 때는 팀장으로부터 저 질문을 받을 것이고, 개발팀을 담당하게 되면 그 위의 매니저로부터, 그리고 개발부서 자체를 담당하게 되면 회사의 대표로부터 저 질문을 듣게 될 것이다. 즉 일정관리는 개발자의 삶을 시작하면서부터 결코 떼어놓을 수 없는 필수불가결한 요소가 되는 것이다.
—
"왜 일정관리는 두려운 것인가?"
일정관리가 두려운 이유는 그것이 ‘미래'를 관리하는 일이며, 미래와 연관된 이상 ‘불확실성'이 따라온다는 것이다. 그리고 그 불확실성이 담보하는 것은, 사업 혹은 프로젝트의 ‘완료'와 직결된다는 아주 무거운 책임이다.
기획, 디자인, 개발 등으로 이루어진 개발프로세스에서, 개발은 대부분 끝에 위치한다. Waterfall 방식이 아니라 Agile 방식 등에서 작은 사이클로 나누어진 프로세스를 보더라도 어찌 됐든 개발은 끝에 위치한다. 그리고 끝에 위치한다는 것은, 개발이 밀리면 프로젝트의 종결이 같이 지연된다는 것을 의미한다.
그게 다가 아니다. 프로젝트 전체의 일정에서 기획, 디자인 등 타 직군보다 개발의 리소스(인건비, 개발 기간 등)가 훨씬 더 많이 들어가기에 해당 프로젝트의 일정에서 차지하는 지분율이 가장 높다.
2015년에 Standish CHAOS Report에서 발행된 리포트( ) 에는 10,000개 이상의 SW 프로젝트를 분석한 매우 귀중한 통계자료가 담겨 있다. 여기서 주요 2부분의 사진으로 첨부했는데, 앞으로 [사진1], [사진2]라고 칭하겠다.
[사진1]을 보면 모든 SW 프로젝트 중 60%가 일정을 맞추지 못했다고 한다. [사진2]에서는 Agile과 Waterfall 방식의 비교 및 프로젝트의 사이즈에 따라 성공/어렵게 달성(Challenged)/실패의 통계를 확인할 수 있는데, 결과는 매우 끔찍하다.
Large size의 프로젝트의 경우 '성공'이라 할만한 수치는 Agile 방식으로는 18%, Waterfall 방식으로는 겨우 3%밖에 되지 않는다. 개발 경험이 꽤 있는 사람은 이 통계가 전혀 과장되지 않았음을 알 수 있을 것이다. 어쩌면 ‘뭐? 40%나 제시간에 맞춘다고?’라는 말이 나올지도 모르겠다. 수백 명의 개발자가 투입되는 흔히 말하는 ‘AAA급 게임’ 같은 경우, 업계 최고의 회사라도 일정이 늦춰지는 경우는 비일비재하다는 것은 잘 알려진 사실이다.
—
자, 그러면 정리해보자.
- 과반수의 S/W 프로젝트가 일정을 맞추지 못한다.
- S/W 일정 전체에서 가장 큰 지분을 차지하고 있는 것은 개발 파트이다.
- S/W 프로젝트의 프로세스의 마지막에 개발이 위치한다.
이러한 사실을 보고 어떠한 생각이 드는가? SW 프로젝트의 일정을 제대로 맞춘다는 것은 쉽지 않은 일인데, 그 일정 지연의 가장 큰 책임은 개발이 담당하고 있으며, 그 위치 또한 마지막이다.
“한마디로 말해서, 성공하기 쉽지 않은 프로젝트의 가장 무거운 책임을 개발분야가 져야 한다는 것이다.”
이것이 개발 일정관리가 두려운 이유이다.
—
"개발 일정관리는 왜 쉽지 않은가?"
개발 기간이 지연되는 데는 여러 가지 요소가 있지만, 나는 다음 3가지로 정리해보겠다.
1. 요구사항에 대한 일정 산정의 어려움
2. (반드시)변화되는 요구사항
3. 개발 업무의 특수성
—
1. 요구사항에 대한 일정 산정의 어려움
하루에 100개의 상품을 찍어내는 공장에서, 1만 개를 찍어내기 위해 어느 정도의 일정이 필요한지 산정하는 것은 어려울 것이 전혀 없다. 공장이 불타거나, 직원들이 갑자기 파업하는 매우 특수한 상황 정도만 변수일 정도로, 변수도 매우 적은 편이다.
그러나 개발은 그렇지 않다. SRS(Software Requirement Specification, 소프트웨어 요구사양서)를 개발자가 작성하는 경우는 흔치 않다. 예를 들면, 그냥 ‘회원 가입 기능’을 요구한다. 그러나 개발 단계로 ‘회원 가입’을 구현하기 위해서는 고려해야 할 것들이 매우 많아진다.
로그인을 세션 방식으로 진행할 것인가? 토큰 방식으로 진행할 것인가? SNS 가입을 추가할 것인가? 본인인증을 넣어야 하는가? 이메일 인증을 넣어야 하는가? 문자 방식 인증을 진행하는가?
프로젝트를 시작할 때는, 이렇듯 구체적인 기획과 화면이 나오지 않은 이 SRS 단계에서, 1차적인 개발 일정을 산정할 수밖에 없다. 설령 정확하게 UI/UX까지의 화면이 다 나와 있는 상태에서 개발 일정을 산정할 수 있는 행운을 누릴 수 있다고 해도, 그 산정은 사실 쉬운 일이 아닐 텐데, 그조차도 없는 상황에서는 두말할 것도 없이 어려운 것이다.
그러나 다들 예상하다시피 이 최초의 일정은 위태롭기 그지 없다. 실제 기획과 디자인이 나오면, 해당 화면의 레이아웃과 UI/UX에 따라 개발 기간은 처음 산정한 것과 달라지기 마련이다. 개발 입장에서 8페이지 정도의 분량일 거라 생각한 것이, 실제로 개발할 때가 되면 15페이지 분량이 되곤 하는 것은 흔한 일이다(안타까운 것은, 이러한 결과는 기획/디자인 쪽에서 ‘더 좋은 결과물’을 고객에게 주고자 하는 선한 동기로 나타난다는 것이다).
결론을 내자면, 최초 요구사항에 대한 일정이 산정에 실패는, 그 산정을 하기 위한 ‘근거'인 요구사항이 명확하지 않기 때문인 경우가 크다는 것이다.
—
2. (반드시)변화되는 요구사항
요구사항에 따른 개발일정을 환상적으로 잘 산정했다고 해도, 이 두 번째 문제는 여전히 가장 큰 두려움으로 남는다.
"요구사항은 변한다. 반드시."
나는 요구사항이 변하지 않는 프로젝트를 본 기억이 없다. 그런 프로젝트는 판타지 소설에나 나올 수 있을 것이다. 최초의 기획과 구성을 그대로 프로젝트 완료까지 가져갈 수는 없으며, 그것은 바람직하지도 않다.
기획의 신이 와서 기획해도, 기획은 변화할 것이며 변해야 한다. 마치 시장의 상황에 따라 내 투자 포트폴리오를 변경해야 하는 것처럼, 그것은 자명한 일이다.
그런데 여기서 가장 어려운 것은, 요구사항이 N만큼 변할 때, 개발은 N², 혹은 N³ 등 기하급수적으로 변화하곤 한다는 것이다. 이것은 그야말로 예측할 수 없는 일이다. 과장 조금 하자면 기획/디자인 쪽에서 페이지 하나 추가하고(혹은 빼고), 기능 하나 그려 넣는 것이 개발 쪽에서는 폭탄으로 돌아오기도 한다.
그런데 만약 개발 일정에 치명적인 요구사항의 변경 요청이 있다면, 그로인해 개발 일정을 재산정하겠는가? 아니면 일정에 껴맞춰서 어떻게든 그것을 구현해내겠는가?
여기에는 많은 어려움이 있다. 일정 산정은 그 자체가 또 하나의 꽤 큰 업무에 해당한다. 변화된 요구사항을 분석하고, 실제로 어떤 식으로 구현해야 할지 개발자는 머리를 굴려야 한다. 팀장은 팀원들을 다독여야 하고, 업무를 적절하게 재분배 해야 한다. 프로젝트 담당자는 대표/임원들에게 일정이 변경될 수밖에 없는 이유를 설명하며 (그들에게는)듣기 싫은 소리를 해야 한다.
이러한 일은 구성원들의 의지력을 소모시키며, 현재 진행하고 있는 개발 업무의 연속성에 영향을 준다. 실제 개발에 써야 할 리소스가 분산되는 것이다.
일정 산정을 안 하고 그대로 밀고 가자니 문제가 만만치 않다. 이미 구현한 코드를 폐기하거나 변경해야 하는 것은 개발자에게 대단히 큰 스트레스이다. 리팩토링 급으로 아예 구조를 변경해야 하는 경우도 생긴다. 개발자의 사기가 떨어진다. 억지로 일정을 유지한다면 코드의 질이 떨어진다.
어떤 경우든, 이런 선택은 반드시 대가를 치르게 된다. 개발자의 눈치채기 어려운 태업이나 QA를 진행하는 시점에서 테스트 기간의 긴 연장 등으로 말이다.
그럼 요청을 거부해야 할까? 내가 프로젝트 담당자인데, 그 요청이 매우 합리적이고 서비스 품질 향상에 큰 영향을 주는 요청이라면? 혹은 대표/투자자로부터 직접 내려온 요청이라면?
정리해보겠다. 20챕터 짜리 책을 일주일에 1챕터씩 공부한다고 하면, 이 책을 끝내기 위한 일정을 산정하기는 매우 쉽다. 그러나 공부를 하고 있는데 갑자기 특정 챕터가 다른 챕터의 3배 정도의 양으로 변하고, 챕터 전체의 숫자도 중간에 25챕터, 30챕터로 변경된다면? 심지어 이미 내가 끝냈던 챕터의 내용이 변경되어 다시 공부해야 한다면? 우리는 과연 이 책을 언제 끝낼 수 있을까? 이것이 개발 일정관리의 현실이다.
위 2가지 요소에서 볼 수 있듯, 개발 일정관리는 매우 어려운 일이다(위에서 언급한 3번째 요소, '개발 업무의 특성'은 매우 방대한 내용이라 나중에 따로 다루도록 하겠다).
그러나 어려운 것은 어려운 것이고, 불가능한 것은 아니다. 그 비율이 낮다고 한들, 일정 관리에 '성공'하는 회사/팀은 있다. 향후 연재해나갈 글들을 통해서는 이러한 일정 산정에 대한 대안을 제시하고 나의 경험을 나눠보도록 하겠다.
