Difficulty of deadline estimation

어느 영화에 주인공이 한 번도 해보지 않은 업무를 맡아서 수차례 마감 기한을 미루는 장면이 나왔다.

이미 마감 기한을 다섯 번쯤 미뤘을 때 제품의 심각한 결함을 발견했지만, 마감 기한을 더 미루면 안 된다는 심리적 압박감과, 잘못될 확률이 현저히 낮다는 생각에 제품을 출시했다가 결국 인명 사고가 발생했다.

영화에 나온 장면이지만 난 비현실적이라고 생각하지 않는다. 물론 Tim Urban의 TED 강연^[Link]에서처럼 내 머릿속 안에 망할 원숭이가 자꾸 다른 거 하라고 꼬드겨서 그럴 수도 있지만, 누군가는 완성도를 위해, 누군가는 피치 못할 사정으로 마감을 미룬다.

문득 아래와 같은 궁금증들이 머릿속에 맴돌아서, 나의 생각을 적어보았다.

우리는 왜 마감을 미룰까?
그리고 언제 미뤄도 되는 걸까?

마감을 미루는 이유

여기 내가 아주 좋아하는 말이 있다.

Done is better than perfect
완성이 완벽보다 낫다

난 이 말을 특히 주니어 개발자들에게 주로 한다. 그들은 여태 이론으로만 배운 내용들을 실제 제품에 구현하는 것에 즐거움을 느끼는 경우가 많다. 그래서 최대한 제품에 이것저것 녹여내려고 하다 보니, 실제로는 고객이 쓰지도 않을 기능을 구현하거나 요구사항 이상의 완성도를 높이느라 마감을 놓치는 경우가 더러 있다.

물론 제품의 완성도가 높아지는 것은 지향해야 할 바이지만, 실제로 제품의 성공 여부는 제품의 완성도보다 제품이 시장에 나오는 타이밍이 더 중요한 경우가 많다.

즉, 제품을 만드는 사람은 ‘하고 싶은 것’과 ‘해야 하는 것’을 구분할 줄 알아야 한다. 일단은 제품을 출시하고, 여유가 생겼을 때 보완을 해도 괜찮은 것들을 구분할 수 있어야 한다.

개발자 입장에선 완벽하지 않을 수 있지만 고객의 요구사항을 이미 만족하고 있다면, 고객 입장에선 완벽한 제품 일 수 있는 것이다. 즉, 개발자 눈이 아니라 고객의 눈에 맞춰야 한다. 제품은 나를 위한 것이 아니라 고객을 위한 것이다.

마감을 미뤄야 하는 경우

단순 완성도를 높이는 것이 아니라 고객의 요구사항을 만족하지 못하거나, 혹은 고객이 인지하지 못한 치명적인 결함을 발견한 경우에는 과감하게 마감을 미뤄야한다.

하지만, 개발자에게 마감 기한을 미뤄야 한다는 말은, 특히나 이미 몇 번 기한을 미룬 상황에서는 입 밖으로 쉬이 나오지 않는다. 나조차도 저년차에는 기한을 미룬다는 것이 내 자신이 무능하고 불성실하다는 것을 인정하는 것 같아 밤을 새서라도 최대한 기한 안에 끝내려고 노력했다.

그러나 성실하게 업무를 수행해도 여러번 반복한 업무가 아니라면, 심지어 여러번 반복한 업무라 하더라도 예상치 못한 상황들은 왕왕 발생한다. 이때, 절대로 스스로를 책망하지 말고 상급자에게 최대한 빨리 보고하고 의논을 하는 것이 바람직하다.

하지만 실제로는 그렇지 못한 경우가 훨씬 많긴 하다. 사실 이건 조직 문화와도 연관이 있다. 에이미 에드먼슨의 <두려움 없는 조직>에서는 “심리적 안정감”이 없는 조직 일수록 이러한 ‘의사소통 단절’현상이 빈번하게 일어난다고 한다.

“심리적 안정감”이란 ‘구성원이 업무와 관련해 그 어떤 의견을 제기해도 벌을 받거나 보복당하지 않을 거라고 믿는 조직 환경’을 말한다. 이러한 환경에서는 사실 근거에 기반하여 상급자와 논의하여 위험요소를 사전에 제거 할 수 있으며 궁극적으로 조직의 성과를 극대화 할 수 있다.

불확실성 핸들링

어떤 개발자들은 ‘이 업무 얼마나 걸릴까요?’라는 물음에 ‘해봐야 알겠는데요’. 라고 대답한다. 그런 모습을 보고 있노라면, ‘회사 입장에서도 당신이 하는거 보고 연봉 주고 싶었을 거에요..’라는 생각이 든다.

물론 모든것은 해봐야 정확히 안다. 내가 제일 좋아하는 영화인 <뷰티풀 마인드> 에서 아래와 같은 대사가 나온다.

Nothing’s ever for sure, John
확실한 건 아무것도 없어, 존
That’s the only sure thing I do know
그게 내가 확실히 아는 단 한가지야

이 세상에 확실한 것 단 하나는, 확실한 것은 없다는 것이다.

바야흐로 우리는 불확실성이 가득한 세상 속에서 산다. 하지만 그렇다고 연봉을 싯가로 정할 수 없듯이, 개발자는 마감 기한을 스스로 말 할 수 있어야 한다.

하지만 개발자가 스스로 정한 마감 기한이 스스로에게 족쇄가 되고, 지키지 못했을때 죄책감이 되어서는 안된다. 또한 조직에서는 마감 기한을 지키지 못한 개발자를 이해관계 없이 다그치거나 책임을 묻지 말고, 앞서 말한 심리적 안정감을 제공하여 ‘왜 마감 기한을 지키지 못했는가?’를 분석하고 재발방지를 해야 한다.

정리

정리하자면,

• 데드라인 측정은 어렵지만 해야한다.
• 개발자는 완성도를 높이는 것을 지향해야 한다. 하지만 오버엔지니어링은 지양해야 한다.
  • 현재 하고 있는 업무가 오버엔지니어링인지 구분하기가 어렵다면, 매니저 혹은 동료와 의논해보자