Json Media
Back to posts

비관적으로 추정하기

여유롭게 추정하는 편이 빡빡하게 추정하는 것보다 더 나을지도


소프트웨어 개발자가 뭔가 1년 정도 걸린다고 말할 때는 실제로 2년 정도가 필요하다는 뜻이다. 그들이 무능해서도 아니고 날짜를 몰라서도 아니다. 단지 우리는 이전에 해 보지 않은 일들에 대해 시간이 얼마나 걸릴지 추정해 보는 일 자체를 못할 뿐이다.

<사용자 스토리 맵 만들기> 중

많은 스타트업 개발자들이 일정을 낙관적으로(빡빡하게) 추정하지만, 그보다는 비관적으로(여유롭게) 추정하는 편이 더 낫다고 생각한다.

빡빡한 추정을 하는 이유

왜 개발자들은 일정을 빡빡하게 추정할까? 두 가지 이유가 있을 것 같다.

스타트업은 항상 바쁘다

스타트업이 항상 바쁜 이유는 간단한데, 머리로 생각하는 것이 실제로 실행하는 것보다 훨씬 쉽기 때문이다. 이미 머리 속에서는 세계 정복이 끝난 상태일 것이다. 그래서 개발자가 아무리 일을 빨리 해도 일이 없어서 노는 상황 같은 것은 잘 생기지 않는다.

회사에서 만들고 싶은 것들이 항상 밀려 있으니 개발자들은 자신이 병목인 것 같이 느끼게 되고, 그래서 일정을 잡을 때 일을 빨리 끝내야 할 것 같은 압박감을 갖고 빡빡한 일정을 잡기 쉽다.

멋진 개발자이고 싶다

아무래도 스타트업서 일하는 사람들은 편하게 다니기 보다 멋지게 일하는 사람이 되고 싶은 경우가 많고, 이는 개발자도 마찬가지이다.

‘1주일요? 3일이면 됩니다.’ 라고 말하고, 이틀 동안 설렁설렁 하다가 하루 만에 후다닥 일을 끝낸다면 얼마나 멋지겠는가.

빡빡한 추정의 결과

빡빡한 추정은 어떤 결과를 가져올까?

The result of optimistic estimation
빡빡한 추정의 결과

일을 제 때 하지 못하면 협업에 차질이 생긴다. 예를 들어 내가 API 를 제공해야하는 Backend 를 맡았었다면, Frontend 를 담당하는 사람은 예상하지 못했던 딜레이가 생긴다. 다음 업무를 계획하던 PO 가 이 일에 신경 쓰느라 자신의 업무를 잘 수행하지 못한다.

그러면 결국 전체 업무가 추정보다 늦게 완료되고, 비지니스 일정에 차질이 생길 수 있다. 예를 들어 새 feature 를 홍보하기 위해 외부 대행사와 marketing 을 준비해놓은 경우 비용이 낭비되거나, B2B 클라이언트와의 계약이 어긋나서 비지니스 신뢰를 잃는다든지 등의 일이 발생할 수 있다.

이런 일이 반복되면 회사와 팀으로부터 신뢰도를 잃는다.

회사와 팀으로부터 신뢰도 잃고 스스로도 일정을 제대로 맞추지 못하니 자존감이 떨어진다.

그러면 점점 일을 기존에 하던 만큼 보다도 더 늦게 완료하게 된다. 행복하지 않기 때문이다.[1]

결국 원래 목적이었던 ‘병목 탈출하기’, ‘멋진 개발자 되기’ 모두 실패하는 방향으로 가게 된다.

몇 번은 일을 제 때 해냈다고 하더라도, 초과 근무를 하거나 급하게 코드를 작성하느라 코드 품질을 낮춰서 해냈다면 개발 생산성이 낮아져 같은 결과로 귀결된다.

여유로운 추정을 한다면?

반대로 여유로운 추정을 한다면 어떻게 될까?

여기서 전제는 추정을 여유롭게 했다고 해서 더 여유롭게 일하지는 않는 다는 것이다. 추정이 빡빡하든 여유롭든 하루에 주어진 근무 시간 안에서는 동일한 일을 처리한다.

The result of pessimistic estimation
여유로운 추정의 결과

일을 정해진 시간보다 일찍 끝마친다. 협업이 필요한 동료는 내 일이 끝나길 기다릴 필요가 없이 일정대로 진행하고 바로 이어서 협업을 진행하면 된다.

약간의 문제가 발생하더라도 여유로운 일정 덕분에 전체 업무가 제 시간 안에 끝난다. 비지니스는 문제 없이 진행된다.

서로 일정에 대한 신뢰를 가지고 일할 수 있게 된다.

지속적인 성공 경험으로 자존감이 올라간다.

결론적으로 오히려 점점 일을 더 빨리 끝낼 수 있게 된다. 행복하기 때문이다.

물론 항상 일이 생각한 대로 되는 것은 아니지만, 이렇게 될 확률이 높다는 것은 부정할 수 없다.


일을 점점 더 빨리 처리하는 개발자가 되고 싶다면 추정을 여유롭게 하자.

얼마나 여유롭게 추정해야할지 잘 모르겠다면, 일단 머리 속에 떠오르는 시간보다 두 배로 늘려서 말해보고 차츰 조정해보는 것을 추천한다.

[1]: Happiness and the Productivity of Software Engineers