초과는 예외가 아니라 기본값입니다
프리랜서로 일하거나, 소규모 스탤타트업에서 시간을 견적으로 내는 사람이라면 이 글이 대상입니다. 견적이 실제로는 1.5에서 2배가 된 경험이라면, 다음 견적부터 바로 쓸 4단계 과정을 얻게 됩니다. 결론부터 드립니다. 견적이 낮게 나오는 원인은 불성실이나 실력 부족이 아닙니다. 숫자를 만들어내는 과정이 일만 세고 일이 일어나는 환경은 세지 않기 때문입니다.
식당 앱에 모바일 주문을 넣기로 했습니다. 디자인 1주, 개발 2주, 테스트 1주. 4주, 정직한 계획입니다. 실제로는 9주에 끝났습니다 [추정]. 결제 대행사 승인을 기다리느라 3주, 식당 대표가 메뉴 구조를 두 번 바꾸느라 2주, 기존 예약 시스템의 버그를 정리하느라 2주. 이 세 가지는 계획이라는 형식에 들어가지 않는 것들이었습니다.
해결은 네 단계입니다. 밖에서 보기, 버퍼에 이름 붙이기, 체크포인트 재추정, 로그로 자기 계수 만들기. 초과가 기본값이던 계산은 다음 견적부터 바뀝니다.
글의 핵심 개념을 형상화했습니다.
계획은 일만 셉니다
계획을 세울 때 머릿속에서 도는 경로는 하나입니다. 어떤 기능이 들어가는지, 어떤 기술로 하는지, 어떤 순서로 흐르는지. 그 경로에서 나온 숫자가 견적이고 이 시선을 인사이드 뷰라고 부릅니다.
인사이드 뷰에는 생각한 장애물만 들어 있고 초과한 이유의 대부분은 생각하지 못한 후자입니다. 4주차에 드러난 것은 승인 기다리기, 기준 변경, 예상하지 못한 버그였습니다. 간트 차트에 칸을 만들 수 있는 것만 일이라 불리기 때문입니다.
MVP도 마찬가지였습니다. 프로토타입 2주, 백엔드 2주, 통합과 테스트 2주. 6주 계획이 4개월 뒤에 출시됐습니다 [추정]. 유저 인터뷰 잡는 데 3주, 범위는 예약에서 좌석 선택과 리뷰까지로 자랐고 핵심 개발자가 한 명 다른 팀으로 옮겼습니다. 계획은 거짓이 아니었습니다. 다만 일만 들어 있었고, 환경은 빠져 있었습니다.
초과는 한 곳에서 생기지 않습니다. 2주차에 나흘을 기다린 승인이 4주차를 미루고, 4주차가 5주차를 미루듯, 지연은 주를 따라 이동합니다. 첫 주에 버퍼가 없으면 4주차에 무릎을 꿇습니다.
더 큰 손실은 주수가 아닙니다. 500만 원짜리 사이트가 3주 견적에 6주 끝난 경우, 시간당 단가는 반으로 줄어듭니다 [추정]. 상대의 첫인상은 시간을 못 잡는다는 것이었습니다. 기술은 별개로 평가되고 후자의 평판이 다음 견적의 가격을 결정합니다.
안다는 것이 막아주지 않는다
유명한 실험이 있습니다. 졸업 논문 종료까지 걸 날을 추측하게 했더니, 결과는 일관되게 짧았습니다. 지난 학기 평균을 통째로 알려준 집단도 여전히 부족하게 추정했습니다. 밖의 숫자를 알면서 이번엔 다르다고 믿은 것입니다.
기한을 딱 맞춰 끝낸 프로젝트는 또렷하게 남습니다. 3주가 9주가 된 프로젝트는 상대가 난폭했기 때문으로 정리됩니다. 기술이 다르고 상대가 다르고 범위가 다르니, 뇌는 과거의 통계가 이번에도 적용된다고 생각하지 않습니다. 선별 기억과 독창성 착시가 같은 결과를 만들었습니다.
확신이 강할수록 추정 숫자는 낮아집니다. 고객에게 계획을 설명하는 순간, 뇌는 이미 그것을 팔고 있습니다. 믿는 것은 경로를 짧게 만듭니다. 그래서 가장 자신 있는 견적일수록 정확하지 않은 경우가 많습니다.
경험도 고쳐주지 않습니다. 10년 차 개발자는 자기 코딩이 얼마나 걸리는지 잘 압니다. 그런데 경험이 성장하지 않는 부분이 프로젝트 밖입니다. 외부 서비스의 승인 시간, 상대의 검토 사이클, 벤더의 출시 일정. 실력으로는 빨라지지 않고 데이터로만 빨라집니다. 대부분은 그 데이터를 모으지 않습니다.
낮은 견적이 일을 따냅니다. 응찰할 때 3주를 말한 쪽이 5주를 말한 쪽보다 유리합니다. 낮게 부른 대가는 즉각 작아 보이고 초과한 대가는 큽니다. 열 건이면 계산은 뒤집힙니다. 늘 초과하는 낮은 견적은 다음 일 자체를 죽이고, 지키는 숫자는 신뢰를 만듭니다. 앵커링도 한 겹 더 얹힙니다. 먼저 말한 숫자가 기준점이 되어, 상대는 그 주변에 마케팅, 예산, 팀 일정을 세웁니다. 4주를 말한 순간, 상대의 운영 사실이 됩니다.
비슷한 프로젝트는 어떻게 끝났나
아웃사이드 뷰는 다른 질문을 합니다. 이런 프로젝트는 보통 어떻게 끝났나입니다. 비슷한 과거 사례의 실제 소용일을 나열하고, 분포 위에서 견적을 내면 됩니다. 이 사례 모임이 레퍼런스 클래스입니다.
클래스는 규모, 도메인, 팀, 환경으로 정의합니다. 3년 차 서비스의 신규 기능, 3주에서 6주, 1인 팀, 서드파티 API 포함. 이 한 줄이 클래스입니다. 70퍼센트 겹치면 되고 나머지는 보정입니다. 클래스는 견적을 보기 전에 정합니다. 견적이 나온 다음에 사례를 찾으면, 자기 숫자를 지지하는 사례만 고르게 되고 사후 정당화입니다.
소스는 순서가 있습니다. 자기 기록이 우선이고 다음이 동료, 고객의 과거, 업계 자료입니다. 동료에게 그거 몇 주 걸렸어라고 물으면, 답은 대개 실제 소용일이어서 견적보다 낫습니다. 고객의 과거도 데이터입니다. 비슷한 기능 했을 때 몇 주 걸렸다는 질문은, 상대가 3주면 되지라고 말하는 그 3주가 상대 클래스의 최솟값이라는 것도 보여 줍니다. 업계 자료는 자기보고가 대부분이라 낙관이 이미 섞여 있습니다. 평균 6주는, 6주가 넘을 가능성이 높다는 신호 정도로만 씁니다.
숫자를 고르는 위치가 핵심입니다. 사례 8건의 실제 소용일이 3주, 4주, 4주, 6주, 8주, 9주, 11주, 14주라면, 유혹은 최솟값 3주나 중앙값 6주인데, 둘 다 같은 이유로 틀립니다. 초과한 프로젝트는 견적에 포함할 실제 가능한 시나리오입니다. 75퍼센트 부근, 9주에서 11주 사이에서 견적을 냅니다. 퍼센타일을 고르는 질문은 넘으면 무엇을 지불하나입니다. 내부 도구라면 중앙값, 지연 벌금 조항이 있는 계약이라면 같은 데이터에서도 11주입니다. 대가가 변한 것입니다.
사례가 없으면 클래스를 넓히고 보정을 명시합니다. 배달 앱의 구독 기능 클래스가 비어 있으면, 내가 만든 구독 결제로, 그래도 부족하면 결제 연동이 있던 기능으로 넓힙니다. 75퍼센트가 15주이고 이번 범위가 60퍼센트 작으면, 15주에 60퍼센트를 곱해 약 9주를 냅니다 [추정]. 보정은 견적서에 문장으로 씁니다. 범위가 클래스 평균의 60퍼센트라 60퍼센트 보정. 그 문장이 있으면 상대가 물을 수 있고 답할 수 있습니다. 대충 7주라면 아무도 묻지 못하고 초과 시점에 싸움이 됩니다.
인사이드 뷰가 이길 수 있는 경우는 한정적입니다. 상대가 협조적이니까 빠를 거야, 이 생각을 거르지 않고 검사합니다. 협조적인 상대를 클래스에서 빼면, 남은 사례도 4주에서 14주까지 흩어져 있을 가능성이 큽니다. 기저일 뿐입니다. 진짜 차이는 숫자로 말할 수 있는 것뿐입니다. 범위가 클래스 평균보다 40퍼센트 작다, 이 라이브러리에 2년 경험이 있다. 이번엔 진지하다는 말은 숫자를 움직이지 않습니다. 견적 옆에 클래스를 적어 두세요. 9주. 근거: 사례 8건의 75퍼센트. 이 한 줄이 첫 협상에서 숫자를 지킵니다.
버퍼는 이름을 가져야 합니다
버퍼는 계산할 수 없는 리스크에 붙이는, 명시적 비용입니다. 거짓은 숫자 속에 숨고 버퍼는 숫자 옆에 놓입니다. 기본 추정 6주, 버퍼 3주, 합계 9주는 9주와 다른 문장입니다. 상대가 구성을 이해하고 협상하게 됩니다. 버퍼를 2주로 줄이자는 말에, 어떤 리스크를 자신이 흡수하는지 알 수 있습니다. 숨은 부풀리기는 협상할 수 없고 불신으로만 남습니다.
이름도 붙입니다. 결제 대행사 승인 기다리는 동안 2주는 버퍼입니다. 혹시 모를 것에 대비해 2주는 아닙니다. 이름을 안 붙인 버퍼는 패딩이고 첫 돌발 사건에 소모되고 끝입니다. 이름을 붙인 버퍼는 만들어진 리스크에 맞춰 소모되니, 버티는 이유가 있습니다.
기준은 불확실성입니다. 디자인은 10퍼센트거나 없고 코어 개발은 20에서 30퍼센트, 외부 서비스 연동은 50퍼센트 이상, 상대의 검토 사이클은 100퍼센트 이상입니다. 불확실성이 낮은 태스크에는 적게, 높은 태스크에는 많이 배분됩니다. 검토 사이클은 가장 큰 숨은 소모자입니다. 버전을 보내면 상대가 일주일째 침묵하고 열 건의 변경 요구와 함께 돌아옵니다. 그중 두 건은 처음부터 이게 의도였다는 겁니다.
5개 태스크로 쪼개 보겠습니다.
| 태스크 | 중간값 | 가장 빠를 때 | 가장 느릴 때 | 버퍼 |
|---|---|---|---|---|
| 디자인 | 1주 | 1주 | 2주 | 없음 |
| 코어 개발 | 2주 | 1.5주 | 3주 | 3일 |
| 외부 서비스 연동 | 1.5주 | 1주 | 3주 | 1.5주 |
| 내부 테스트 | 0.5주 | 0.5주 | 1주 | 2일 |
| 상대 검토 2회 | 1주 | 1주 | 2.5주 | 1주 |
중간값 합이 기본 추정 6주, 버퍼 합이 3주, 견적 9주입니다 [추정]. 2.5주가 연동과 검토, 즉 스프레드가 넓고 통제권이 없는 두 태스크에 집중되어 있습니다. 가장 느릴 때 숫자를 쓸 때, 실제로 일어난 최악을 쓰는 것이 핵심입니다. 지난 3건의 연동에서 실제로 4주를 먹은 기록이 있어 4주를 쓰면, 그것이 버퍼입니다.
버퍼는 당신의 소유입니다. 상대가 1주 줄여줘라고 하면, 침묵하고 자르는 것은 프로의 동작이 아닙니다. 버퍼를 자르는 건 리스크를 빼는 것이니까요. 답은 메뉴입니다. 범위를 줄이면 2주, 검토 버퍼를 1주로 줄이면 1주, 4주 고정이고 초과분은 시간 단가입니다. 할인은 당신이 리스크를 흡수하는 것이고 위임은 상대가 떠안는 것입니다. 검토 버퍼 1주는 귀사 위임이라는 한 줄이 3개월 뒤의 분쟁을 막습니다.
80퍼센트 진행률은 남은 20퍼센트가 아닙니다
재추정의 가장 큰 적은 거의 끝났다라는 감각입니다. 80퍼센트 완료 시점에 뇌는 남은 20퍼센트를 결론 짓지만 실제로는 그렇지 않습니다. 앞의 80퍼센트는 계획한 부분이었고, 마지막 20퍼센트는 계획하지 않은 부분입니다. 통합, 엣지 케이스, 조미 요청, 프로덕션에서만 드러나는 버그. 버퍼는 대개 정확히 여기에서 소모됩니다.
재추정은 남은 작업이 무엇이고 각각 얼마나 걸리는지 묻습니다. 남은 일은 기존 리스트를 재사용하지 않고 새로 나열합니다. 기존 리스트는 거의 끝난 태스크로 가득하고 그 항목이 가장 비쌉니다. 검증이 남고 검증은 계획에 없던 일이니까요. 남은 작업에 다시 밖에서 보고 버퍼를 붙이고, 합이 새 견적입니다.
새 견적이 남은 시간보다 클 때가 있습니다. 9주 견적에 6주가 흘렀다면, 남은 작업이 5주는 합계 11주입니다. 선택지는 두 개, 마감을 미루거나 범위를 줄입니다. 둘 다 합법입니다. 위법인 선택지는 하나뿐입니다. 아무것도 고르지 않은 채 더 열심히 하는 것. 버퍼를 태우기만 하고 늦은 사실조차 모른 채 늦게 만들어낼 뿐입니다.
침묵은 가장 비쌉니다. 새 견적이 나빠진 걸 알면서 말하지 않고 계속 일하는 것. 1주일, 2주일 침묵. 그리고 납품일에, 조금 늦어질 것 같아요. 그 순간 상대가 잃는 것은 신뢰 전체입니다. 미리 알았던 지연에는 놀랍니다. 납품일에야 발견한 지연에는 화를 냅니다. 침묵한 1주는 보고한 1주보다 10배 비쌉니다.
체크포인트가 이 침묵을 제도적으로 끊습니다. 견적을 낼 때 미리 정합니다. 9주 프로젝트면 3주, 6주, 9주. 새 견적이 같아도 합니다. 6주차에 남은 일을 새로 나열하면, 연동 검증 2주, 내부 테스트 1주, 검토 2주. 합계 5주, 원래 남은 시간은 3주. 보고는 세 줄입니다. 6주차부터 5주가 더 걸릴 것으로 보입니다. 원인은 벤더 스테이징 지연과 지난 검토의 변경 세 건입니다. 마감을 2주 늘리거나, 두 번째 검사를 출시 후로 돌리고 원래 마감이 1차 버전으로 갑니다. 상대는 후자를 고릅니다. 5분 재추정과 3줄 보고가 납품일의 대면을 피하게 했습니다.
마감이 고정된 프로젝트는 반전됩니다. 시간을 먼저 고정하고 전체 버퍼를 빼고 남은 시간에 범위를 맞춥니다. 버퍼를 줄이는 유혹은 최악입니다. 달력과 협상할 수 있는 건 범위뿐이니까요. 핵심 기능만 넣고 나머지는 다음 단계로 갑니다. 이것까지는 이 날짜까지 보장합니다.
자기 숫자는 로그에서 나옵니다
핵심 자산은 자기 실제 데이터입니다. 가장 싸게 모으는 방법은 로그 하나입니다. 프로젝트 이름, 견적 날짜, 버퍼 포함 견적, 실제 소용일, 레퍼런스 클래스, 편차 이유. 열은 이 정도면 됩니다. 추정할 때 한 줄을 만들고 끝날 때 실제와 이유를 채웁니다. 편차 이유는 한 줄이면 됩니다. 대행사 승인이 예상보다 2주 걸림, 상대가 범위 절반으로 줄임.
두 가지 규정이 있습니다. 실제로 한 것만 씁니다. 머릿속으로는 9주, 입으로는 6주를 말했다면, 6주를 기록합니다. 이상적인 나를 기록하면 한 달 만에 중단됩니다. 작아서 견적이라고 부르기 힘든 것도 씁니다. 2일짜리 작업, 1시간짜리 견적. 작은 사례는 편차가 적고 쌓이는 속도가 빨라, 큰 것을 기록하는 습관으로 이어집니다.
10에서 20건이 쌓이면 패턴이 보입니다. 연동을 늘 부족하게 부르고 검토 사이클은 늘 1.5배구나. 12건에서 견적 총 78주, 실제 총 179주면, 179를 78로 나눈 약 2.3이 개인 보정계수입니다 [추정]. 계수는 기본 추정치에 곱해 sanity check로 쓰고 클래스 분포가 실제의 것인지 견적의 것인지 구분할 때 씁니다. 4주짜리 기본이 2.3배면 9주가 되어야 하고, 6주를 견적하려면 근거가 필요합니다. 10건마다 다시 계산하면, 2.3은 1.7로, 1.7은 1.3으로 내려갑니다. 계수가 내려가는 게 시스템이 작동하는 증거입니다.
목표는 조금 높은 쪽의 꾸준함입니다. 낮은 쪽으로 틀리는 대가가 크니까요. 클래스의 75퍼센트에 10에서 20퍼센트 여유를 더한 곳이 좋은 시작점입니다 [추정]. 꾸준히 조금 높게 부르면 상대가 믿습니다. 그 사람이 6주라면 6주겠지. 그 신뢰는 자본이고 다음 견적이 높아도 묻지 않습니다. 조금이 크게로 바뀌면 안 됩니다. 2배씩 높게 부르는 견적은 일을 잃습니다. 이 시스템의 끝은 5퍼센트 안에서 높은 견적입니다.
얼마나 걸리나요에는 범위와 조건으로 답합니다. 4주에서 7주입니다. 검토 2회 포함. 결제 연동이 빨리 되면 아래쪽. 단일 숫자를 들은 상대는 확신하는 줄 알고, 그 확신으로 계획을 세웁니다. 조건은 정보입니다. 확신을 원하면 위쪽을, 속도를 원하면 리스크를 감수하고 아래쪽을 고릅니다. 범위가 정해지지 않은 프로젝트에 숫자를 붙이는 것만은 피하세요. 포함되는 게 안 정해지면, 숫자를 드리기 어렵습니다. 초과한 일은 잃은 일보다 비쌉니다.
오늘 할 일 하나. 최근 끝난 프로젝트를 로그에 넣는 것입니다. 견적, 실제, 편차 이유. 3분이면 됩니다. 그 한 줄에서 시작됩니다. 다음 견적은 네 단계를 밟고 버퍼는 이름을 갖고 체크포인트는 캘린더에 있고 실제가 다음 줄을 채웁니다. 열 줄이 쌓이면 당신만의 보정계수가 생깁니다. 추정 실력은 같은 과정을 반복한 기록입니다.
더 깊이 보고 싶으면, 이 논증을 확장한 전자책 추정 규율이 있습니다. 퍼센타일 선택, 버퍼 실습, 프리모템, 협상 메뉴까지 31페이지입니다.
참고 자료
- 플래닝 폴러시: Buehler, Griffin, Ross (1992) 연구 개요
- 레퍼런스 클래스 포캐스팅: 개념 개요
- 앵커링 효과: 개념 개요