프로젝트 전에 예측하는 개발 비용과 일정은 농담에 불과하다

양치기 소년은 "그 기능은 이틀이면 충분히 짭니다"라고 말한다. 프로젝트 전에 예측하는 개발 비용과 일정은 농담에 불과하다. 이런 헛소리를 진심으로 믿는 사람은 바보 아니면 풋내기 관리자다. 예측 값은 부정확한 값을 넘어 위조된 값이기 때문이다. 물론 세상에는 코딩이라는 업무를 잘만 다듬으면 일정과 품질을 예측할 수 있고 공정도 재현 가능하다고 믿는 사람들이 있게 마련이다. 뭐, 우리 아들도 아직은 산타를 믿으니까. 진실을 말하자면, 10줄짜리 코드를 짜거나 옛날 코드를 그대로 복사하는 경우가 아니라면, 프로젝트가 실제로 얼마나 걸릴지 예측하기는 일은 불가능하다.

– HARD CODE. 1장. 35쪽.

에릭 브레히너의 일정 관리.

  • 중간 목표 점검일, 베타 날짜, 출시일만 따진다.
  • "우수한 개발 일정은 모든 날짜를 정해놓고 꼬치꼬치 추적하지 않는다. 대신 각 중간목표 내에 구현할 기능을 단순히 열거만 한다."
  • 세 번째 중간목표 둘째 주 쯤 됐을 때 '희망하는' 기능과 '있으면 좋은' 기능의 절반을 날린다.

위험 관리가 날짜 관리보다 더 중요하다.

  • 위험: 필수 기능을 제때 제공하지 못하는 것.
  • 필수 기능을 우수한 품질로 적기에 출시하지 못할 위험을 줄이는 방향으로 자원을 조정해야 한다.
    • 나머지는 모두 겉치레로, 도전욕을 자극한다 해도 인턴에게 맡기라고 한다.
  • 팀이 각 기능별 완료일들에 집착하면 위험을 관리하기 어려워짐.
    • 진짜 중요한 날짜는 프로젝트 마감일 하나 밖에 없다.

위험 요인.

  • 과도한 업무량
  • 서두르는 바람에 품질이 떨어진 기능
  • 자원 안배를 잘못해서 잃어버린 시간

나는 팀에게 '반드시 출시할' 기능, 즉 가장 먼저 완성할 기능 목록을 분명히 밝혔다. 나머지는 필요에 따라 쳐낼지도 모른다고 통보했다.

– HARD CODE. 1장. 43쪽.

각 기능의 추정치 잡기

  • UML, 실전에서는 이것만 쓴다. 7장.

너무 추정치가 큰 스토리는 쪼개야 하고, 너무 추정치가 작은 스토리들은 합쳐야 한다. 전체 팀이 구현하는 데 사나흘보다 더 걸리는 스토리는 없어야 한다. 마찬가지로 전체 팀이 구현하는 데 채 반나절이 안 걸리는 스토리도 없어야 한다. 너무 짧은 스토리는 과대평가하기 쉽고, 너무 긴 스토리는 과소평가하기 쉽다. 그러므로 스토리를 자르고 합쳐서 정확한 추정치 근처에 고루 분포되도록 해야 한다.

추정은 숫자가 아니라 분포다

  • 클린 코더. 10장.

마이크가 피터에게 사흘이란 추정이 어느 정도 맞을지 물어봤다면 어땠을까?

마이크: "사흘 만에 끝난다고 어느 정도 확신하나요?"
피터: "꽤나 많이요."
마이크: "숫자로 말해줄 수 있나요?"
피터: "50% ~ 60%요."
마이크: "그 정도면 나흘이 걸릴 가능성도 상당하네요."
피터: "네, 사실 5일이나 6일이 걸릴지도 몰라요. 그럴 리는 없다고 생각하지만요."
마이크: "그럴 리 없다고 어느 정도 확신하시나요?"
피터: "글쎄요. 잘 모르겠어요. 6일이 지나기 전에 끝난다고 95% 정도 확신해요."
마이크: "7일이 될지도 모른다는 말이네요."
피터: "흠, 모든 일이 잘 안 풀리면요. 아니 근데 모든 일이 다 꼬이면 10일이나 11일이 될 수도 있겠죠. 하지만 그럴 가능성은 거의 없어요."

이제서야 진실을 새롭게 인식하기 시작했다. 피터의 추정은 확률 분포다. 피터는 머릿속에서 그림 10.1 같은 완료 가능성을 본다.

image

보다시피 피터가 낸 최초 추정은 3일이었다. 그림 10.1에서 가장 높은 값이다. 그래서 피터의 머릿속에서는 3일이 가장 업무가 끝날 듯한 기간이었다. 하지만 마이크는 다르게 봤다. 마이크는 그림의 오른쪽 끝을 보고 11일이 걸릴지도 모른다고 걱정했다.

코드를 새로 짜기보다 기존 코드를 활용하자

  • 초난감 기업의 조건. 조엘 스폴스키 인터뷰 중에서.

조엘: 찰스 퍼거슨이 쓴 멋진 책 [High St@kes, No Prisoners]에서 제가 배운 교훈은 기업의 비즈니스 목표를 이해하는 프로그래머를 고용해야 한다는 점입니다. "다시 구현할 경우에 회사가 치루는 진짜 비용은 얼마인가?", "제품 출시가 몇 달이나 늦어질까?", "시간 손실과 시장 점유율 하락을 만회할 정도로 제품 매출이 상승할까?" 등과 같은 질문에 답할 수 있는 사람들 말입니다. 그래도 다시 짜야 한다고 우긴다면, 필경 회사 재무나 경쟁 상황을 이해하지 못하는 탓입니다. 잘 설명해 주십시오 그런 다음 재구현에 들어가는 노력을 정직하게 예측해 달라고 요청하십시오. 비용 대 편익을 상세하게 분석하여 대조표를 만들라고 요구하십시오.

솔루션: 아, 그것도 괜찮은 생각입니다만, 믿거나 말거나, 프로그래머들이 이런 문제에 부닥치면, 흠 뭐랄까, "진실을 축소"한다고 하죠.

조엘: 프로그래머가 사용하는 유명한 개발 꼼수 말이군요. 내가 구현하고픈 기능은 모두 1시간 짜리이고, 내가 싫어하는 기능은 모두 99년짜리다. 프로그래머가 거짓말 한다 싶으면 단도직입적으로 정곡을 찌르십시오. 개월이 아니라 시간 단위로 일정을 쪼개라고 하십시오. 각 항목이 이틀 미만이어야 한다고 요구하십시오. 이틀이 넘게 걸리는 업무는 작게 나누어야 합니다. 그렇지 않으면 현실적인 일정을 얻기가 어렵습니다.

솔루션: 코드를 뒤엎고 다시 짜기가 올바른 선택일 경우는 없습니까?

조엘: 거의 없다고 봅니다. 굳이 들자면 새 플랫폼으로 옮겨가는 동시에 코드 아키텍처를 완전히 뜯어고치는 정도가 아마 가장 극단적인 예겠지요. 하지만 이런 경우라도 대개는 코드를 새로 짜기보다 기존 코드를 활용하는 편이 낫습니다. 1

참고문헌

  • [Chapman] - 초난감 기업의 조건 / 릭 채프먼 지음 / 박재호 역 / 에이콘출판사 / 발행 2007년 11월 20일 / 원제: In Search of Stupidity
  • [ROB2] 클린 코더 - 로버트 마틴 저 / 정희종 역 / 에이콘출판사 / 2016년 07월 20일 / 원서 : The Clean Coder: A Code of Conduct for Professional Programmers
  • [ROB] - UML, 실전에서는 이것만 쓴다 / 로버트 C. 마틴 (지은이), 이용원, 정지호 (옮긴이) / 인사이트 / 초판 2쇄 2004년 10월 5일 / 원제: UML for Java Programmers
    • HARD CODE / 박재호 역 / 에이콘출판사 / 발행 2009년 06월 30일 / 원제 : I. M. Wright's Hard Code

주석

  1. [Chapman] 523쪽. ↩